Snort Rule Clinic

I gave a Snort rule clinic this summer. Slides in pdf are here and in Open Office Impress form here . I believe Bleeding Snort is going to post them on their site as well.

Feel free to adapt and correct. I'd like to know if you find any errors, but no attribution is necessary. My understanding of the GPL is that I was required to apply it to the presentation since I included Snort Community rules as examples, and they are released under the GPL.

I ran into some content-free slides recently, which irked me. I know that graphically, these slides are horrorible, but they stand alone pretty well for content. They aren't just an outline. I hope to carve the audio of the clinic up into 10 minute sections and podcast it, but I don't think that is crucial. (I also need an editing suite with a macro to auto-delete "uh"s.)

Really, the best source is the Snort documentation, which is the clearest I've seen for any software. Sometimes a second look from another POV is helpful, though, and there are one or two points I clarified. I also focus on the most important rule features, as measured by frequency of use in the rule set.

Unsent Bugtraq Rant re: Web Vulnerability Checking

Someone asked Bugtraq about whether students in a security class should notify websites of vulnerabilities they have found. Most of the reaction was smarmy, bureaucrat CISSP types saying, "This is totally unethical!" I am sensitive to the problem of signal/noise on Bugtraq and decided against adding my own volume to it, but I did compose the following rant:

I will agree that this is probably the legal position; in Britain Daniel Cuthbert found to his regret that any interaction with a web server at all is fraught with peril. I think the legal position is pretty retarded, though.

Inspecting web sites for XSS is as valid and as ethical as fuzzing binaries. Get something straight: THE BAD GUYS ARE DOING THIS. They are no longer waiting for patches to reverse-engineer, if they ever were. Discovering vulnerabilities and disclosing them to vendors is a good thing.

Without disclosure, consumers are at the mercy of marketing weasels who value the perception of security much more than they value the reality, and FAR more than they value your well-being.

Even if it were not an indisputably Good Thing, you still have to construct an incoherent theory of trespass to craft a law disallowing certain types of interaction with a web server on the internet. Why did you set a web server up if you don't want interaction? Daniel Cuthbert simply added ../../../ to a URL. Web servers function by accepting URLs. That's what they do.

I'm not arguing for full-blown, unauthorized pen-tests. Nor am I arguing for the right to exploit vulnerabilities once found. I'm also trying really hard to stay away from argument by analogy. "Killing the messenger" is not an analogy; it's a precise description of the situation.

3 Book Reviews: Ubuntu Titles

Moving to Ubuntu - Marcel Gagne

The Official Ubuntu Book - Benjamin Mako et. al.

Ubuntu Unleashed - Andrew Hudson, Paul Hudson

I received 3 Ubuntu titles and thought it might be useful to compare them. Ubuntu is a fairly recent Linux distribution that strives to be usable out of the box, with strong support. It has deep pockets and a thriving community behind it. You can get a free, fully-functional installation and livecd just for asking, or downloading. I admire a lot of the design choices that went into Ubuntu, such as limiting the use of the all-powerful root account, which can get people into trouble. The bare-bones server install is the cleanest Linux server I've seen - *no* open ports, minimal services. Just enough to log in at a console and then install what you want. On the other hand, if you want a LAMP server (Linux, Apache, MySQL, and PHP - the most popular combination on the internet), that's a one button install! Brilliant!

The only thing I don't like is the iptables firewall. A "linux for everyone" needs an easier firewall to deal with. (I love pf, written for OpenBSD and now showing up on other systems.)

I think all three books are pretty good, and your choice will depend on your technical level and religious ferver. If you are uncomfortable with computers, I think _Moving to Ubuntu_ is your best choice. If you are somewhat comfortable and into the philosophy behind Ubuntu, _the Official Ubuntu book_ is your best choice. If you are unintimidated by the topic, _Ubuntu Unleashed_ has the most detailed technical coverage.

Moving to Ubuntu - Marcel Gagne

This is the most approachable of the three books. Gagne has an enthusiastic, conversational, even narrative approach to the material. The audience is people stuck using Windows desktops because they don't know any Linux nerds willing to help them. I think it's a terrific book, and it showed me some cool things to do on the desktop. I use Linux mainly for servers.

It covers productivity apps very well. One quibble: he introduces GAIM, for chatting on various systems, and then introduces another tool for IRC, which GAIM handles just fine. The multimedia coverage is the best of the three books. The section on games is good as well, and I like his approach of getting a teenage nephew to recommend the best Linux games.

Like Ubuntu Unleashed, this book has a lot of material lifted from earlier works. I don't think that's a bad thing if the material lifted is generic. In this case, Gagne uses material from the slightly earlier _Moving to Linux_, which mostly used on one (non-Ubuntu) distro and mentioned some differences. Unlike _Ubuntu Unleashed_, the material was applied carefully. They even updated some things that didn't have to be, like an illustration in _MTL_ that had a graphic with a logo reading, "Welcome to Linux". In _MTU_ they cared enough to change it to "Welcome to Ubuntu". The chapters on Open Office are the same - and that's appropriate because Open Office IS the same. The GIMP is the same. So I think it's appropriate for the chapters to be the same.

Gagne pays some attention to the Ubuntu community ethos, but he's mostly concerned with showing someone unfamiliar with the system how to do the things they are most likely to want to do.

A good book, GREAT for newbies.


The Official Ubuntu Book - Benjamin Mako Hill, et. al.

This is at a midpoint in complexity. It is the strongest of the three in describing Ubuntu the phenomenon, rather than Ubuntu the tool. They honor their antecedents (especially the Debian distribution on which Ubuntu is built) and support projects built off of an Ubuntu base. The committment to the Open Source/Free Software community is very strong: even the book is Open Source, meaning you can copy, improve, and distribute it! Good technical details, few editing mistakes.

One area where this exceeds even Ubuntu Unleased in technical detail is in the future of the server side. While not yet ready, there are features that will make Ubuntu more suitable for server farms and clusters than it currently is. They also describe high end features like support for Red Hat's Cluster suite. Ubuntu Unleashed doesn't mention that, even though it is a retailored version of Fedora Unleased.

There are good points and advice throughout, and I picked up some neat tricks and tools. For example, I hadn't heard about zcat, zgrep, and zless, which work on gzipped files without requiring you to unzip them. Cool!

In the installation section, they include some useful tips like how to switch to another console in case you need to do something in the middle of the install. (I had to do that last week.) There's great information on setting up partitions, including one tip to separate /var/spool and /var/log because both can fill up if there's a glitch of some kind. I've long put /var on a separate partition, but that's an additional level I may adopt.

KDE is another desktop environment (Gnome is the default). TOUB gives the KDE flavor of Ubuntu, Kubuntu, full and fair treatment. Ubuntu Unleashed crams in a little Kubuntu stuff here and there.

I liked the treatment of bug reports in Chapter 6. That's the most realistic way the average user can make a contribution - catching and describing bugs in a useful way.

The discussion of scheduling jobs through cron was very good. I learned some stuff I hadn't heard before, such as using lists and ranges of times.

A couple of issues:

There is some very bad password advice on page 40, where the authors essentially suggest running a dictionary word through a 'leet-speak' filter, turning something like 'password' into p455w0rd' (substituting 4 for A, 5 for S, 0 for O). The bad guys crack this easily.

The discussion of the X-windows client and server on page 53 probably only makes sense to those who already understand what's going on.

The troubleshooting section for hardware was a little weak. "Want to watch DVDs? Check the forums." "Want to install a Tivo-like package? Check the forums." The book does a good job of describing the approach to software licenses and the exclusion of packages that aren't 100% free. But it doesn't do such a good job of how an individual can add those parts after the install. For example, playing dvd movies requires some additional libraries and the book doesn't provide much guidance. (Google "decss ubuntu" for starters)

I mentioned the editing is pretty good, no huge glitches. The chapter subtopic is wrong on 319-329: an earlier topic got stuck, I guess.

In sum, a good book and a great introduction to the Ubuntu community. Get this book if you want a family as much as an operating system.



Ubuntu Unleashed - Andrew Hudson, Paul Hudson
This is the most detailed of the three titles. It's aimed at a more technically proficient audience than the other two. It has the highest page count, and there's more print on the page. It also has the most demanding writing style; the other two are more conversational (especially MTU). It's perfectly clear, but the tone is not as reassuring to newbies. I think a Linux newbie who was fairly technical would still be comfortable, and it presupposes very little knowledge. It's mostly a matter of tone.

Part I, Installation and Configuration is about 260 pages.

Part II, System Administration, is about 170 pages.

Part III, Ubuntu as a server, is about 175 pages. It introduces Apache, Postfix, and other services.

Part IV, Programming, introduces Perl, Python, PHP, and some tools to use with C/C++ (but nothing on those languages themselves)

Part V, Housekeeping revists and amplifies Part II.

The good: I really like the organization. The other books are laid out for someone who has just installed, or is about to install,Ubuntu. This one expects that you will read much more material before hitting the keyboard. That's not a bad thing, for its audience. Home users won't have a lot of use for the mass deployment advice, for example, but IT folks might. In particular, this is the only book of the three to cover using Kickstart to automate installation.

I like how it gives two tables of contents, one brief, one detailed. (The detailed table of contents is 23 pages! The index is 62, but misses some keywords.) Each chapter recaps important commands, and provides links for further information. That's a great template I wish other books would adopt.

It briefly covers the history of Linux and the Ubuntu distribution of Linux. The other two books are a bit more evangelical about Ubuntu. This intro is more for the "Just the Facts, Ma'am" crowd. It is enthusiastic about Open Source and Linux in general.

They lift material from other books, especially Fedora Core Unleashed. That's not a bad thing - is it necessary come up with a new way to describe how TCP/IP works for each book you write? There's a lot of generic information that applies to most distros. A book that was only about Ubuntu and not general system administration would be pretty weak, in my opinion. This has a lot of good information about
running your system.

It introduces servers like the Postfix email server, and programming languages like Perl. Huge books are written on some of these topics, so you might wonder whether there was any point in a short chapter on them. In most cases, I'd say there is some point. You may not master Perl with what they give you, but you might be able to figure out some things. The Sguid proxy server treatment is short but could be very useful.

The Bad: The book was hastily thrown together, lifting or adapting a lot of material from Fedora Core Unleashed. As I said earlier, the repetition of material is not bad if the material is generic. But I don't expect to hear a lot about obtaining RPMs (software packages used by Fedora, among many other distros, but NOT by Ubuntu) in an Ubuntu book. At one point, they actually refer to Ubuntu Core! I'd lay odds there was a search and replace function used to swap "Ubuntu" for "Fedora" when it should have been for "Fedora Core." At another, they refer to different backup applications being available to the "business oriented" version. Ubuntu doesn't segment itself this way - that's a Redhat characteristic. There are tools mentioned that just aren't part of Ubuntu, as well.

The Security Chapter is terrible. It even describes itself as "all you need", but it isn't remotely enough. I give the other two books a pass because they are mostly aimed at users, not system administrators. This book needs a third coauthor who is well-versed in locking down internet-facing linux boxes.

A minor thing - the book is riddled with examples that will be dated before it goes out of print: hard drive prices and capacities, etc.

Chapter Notes - lots of nit-picks. Like I said, this is a good book overall.
Chapter One: Good short history, covers the bases of why this Matters.
Chapter Two: Good hardware compatibility resources. Useful USB incompatibility warning. Partition info is good - hint on partition for laptop suspend.
Chapter Three: it's customary when providing an example password to advise against using the example on your own systems - the examples often wind up in password cracking databases.
Chapter Four: Post-Install Config. Good tip on making a backup copy of each
Chapter Five: really nice description of the file system layout.
Chapter Six: X-Windows. It misses a chance to show how to set up a remote session. This is handled elsewhere, but why not here?
Chapter Seven: Software. This chapter is missing a section on dpkg, which is the underlying package management tool used by the other tools they talk about. They discuss it much later.
Chapter 8: Browsing/Email - good discussion of using mail from the command line (useful for scripts!)
Chapter 9: Productivity. Glosses over the use of Open Office, which is probably o.k. The audience can figure that out or get an Open Office book. Overstates coverage of groupware in Chapter 8 - it wasn't "in detail". Good call to plug Codeweavers for running native MS Office. Some people have to...
Chapter 10: Multimedia. This chapter suffers most from its origins in Fedora Unleashed. It's riddled with references to RPMs. Installing a t.v. card requires editing kernel modules, should refer to Chapter 35.
Chapter 11: Image Manipulation. VERY BAD ADVICE telling people to enable remote X sessions by entering xhost+ This is unfathomable!
Chapter 12: Printing. Pretty much just a UI run-through.
Chapter 13: Games. Good coverage, nice to know that the main first person shooters are available natively. Also good to know about Cedega, a games-oriented emulation package. Another Redhat-ism: Cedega is "not available via Yum"
Chapter 14: Users. Good coverage of user accounts, including those used by system services. Learned some stuff. User disk space quotas are mentioned, but I found the discussion unclear. User Accounting is a useful tool for security as well as old-fashioned timeshare billing, and they cover it pretty well. Really odd advice that you can edit /etc/shadow with a text editor. This is unsound.
Chapter 15: Automating Tasks. This was great. I learned new stuff, like scheduling jobs for a list or range of times. I liked the shell script introduction. There's an odd reference to Tripwire and Logwatch being included. You can install them, but they aren't included by default. Maybe another Fedora leakage? I liked the shell
script examples, but would have liked to see a few more, especially for the If clauses.
Chapter 16: System Monitoring. I learned good stuff about Top, time, and watch. Vmstat is a new one to me.
Chapter 17: Backups. It's arguably out of scope, but I think that they should mention that these days backup tapes have to be handled like evidence, with a chain of custody and logged distruction/wiping/disposal. Really liked the coverage of tar,
learned about incremental backups with it. dd coverage good, especially the warning about confusing source and target. Odd discussion of KDE gui backup tools - "archive has...function of system administrator...no GUI necessary" This applies equally to the Gnome tools like File Roller. Why say this in section on KDE tools? Liked the mc tool, but there is no package available for Ubuntu. They refer to obsolete rcp command, and say they previously mentioned it. I don't think they did! The index doesn't cover it. Big confusion in ext2/ext3 undelete: you can't undelete in
ext3 file system! ext2fs doesn't have the information available to do that. They need to make that VERY CLEAR, rather than misinforming you about undeleting. Good recovery information. GRUB boot floppy -great idea.
Chapter 18. Networking. Good explanation of purpose and use of loopback. Chapter needs editing. Private IP space handled twice, once incorrectly. They provide a good link to info on wifi adapters. Subnetting is pretty muddled, but should't hurt anyone who actually has to do it. The discussion of fiber optic cable is oddly wrong in one section, after getting it right in a previous section. It is not a 100 mbs media. It's 10mbps, 100mbps, 1 gig, 10 gig...depends on fiber characteristics, length, and the devices attached.
Chapter 20: Web Servers. Is C really one of the most popular CGI languages? I'd think PHP, C#, VN, Python...
Chapter 21: Nice comparison of MySQL vs. Postgres, and what type of tables you need in MySQL to get certain features.
Chapter 22: Good NFS intro, I think. Samba references really ought to include "The Official Samba How-to and Reference Guide" (TOSHARG). The section describes stand alone file servers, but you can set up a full-fledged NT 4.0 style domain with Samba. You should at least mention it and give a pointer to more info.
Chapter 23: ftp. Good emphasis on insecurity of this clear-text protocol.
Chapter 24: email. Typo/brain cramp in Qmail section: "Postfix is designed to be easier..." but we're reading about Qmail. Exim is claimed to be more secure than either Postfix or Qmail, but Qmail has an unclaimed bounty for any security related bugs. Word choice: "Postfix is...recommended client." An MTA is a client? Hmm. Good overview of Exchange alternatives.
Chapter 25: Proxy. Good examples for using access control lists in Squid to limit connections by source/destination and content. Should be useful to get up to speed.
Chapter 27: Perl is a backronym. The name was chosen and only later turned into an acronym. There are two, equally correct and they should have mentioned "Pathologically Eclectic Rubbish Lister" Lots of great Perl books, some as big as this one. This serves as a quick intro and maybe refresher.
Chapter 30: C/C++. Doesn't address language, unlike previous chapters on Python, PHP, etc. Just tools. Debuggers, development environments, etc.
Chapter 31: Securing the Host. Most disappointing chapter in the book. And there's even a claim that all you need is in this section. While Nessus may not identify weaknesses based on patch level as the book claims, it can do deeper tests and see if a vulnerability is really present. Nmap is NOT a substitute. For firewall configs, it claims that gnome-lokkit (for GUI) and lokkit (for cli) are included. They aren't and don't appear to be part of the Ubuntu repository. This looks like another Redhat-ism. There's nothing on mounting file systems with suid limitations, using a central log server so you can trust the logs, exporting the tripwire database so an intruder can't just register the trojanned binaries. There's so much you can and
should do, and it is not covered at all. CERT has checklists, SANS has checklists, there's a wealth of information out there that they could point us to if they aren't up to covering it themselves. I'd scrap the whole chapter and start fresh in another edition.
Chapter 32: Tuning. This has good info on hard drive tuning. Major clue - disable atime for partitions seeing many writes/second. Each atime update is another write.
Chapter 33: Shell Master Class. Revisits the command line, really good information. I learned a lot about the less command, and screen.
Chapter 34: Advanced Apt. Good coverage of (finally) dpkg and aptitude. I'd call it complete.
Chapter 35: Kernel maintenance. Good info on kernel modules. I can't swear the kernel patching stuff is good (no direct experience) but it looks complete.
Appendix A: references are good. Mailing lists, chat rooms, websites. Seems complete.

Tweaking IPS/IDS Vendors at Trade Shows

If you follow the NSM (Network Security Monitoring) philosophy, you focus on collecting and analyzing 4 types of data: statistical, flow/session data, full-content packet capture data, and alert data from an IDS (and possibly other sources of alert data). The best place to learn about the approach is here:

Snort is my choice for an IDS because it is Open Source (source code auditable, available for outside improvement especially feature development), which means it's Free-as-in-Beer as well as Free-as-in-Speech. Got a rant on the subject. It is incredibly flexible: I can read every signature and understand what it is trying to detect; I can get the output in any number of formats, which means the data winds up where I can use it best. Some vendors want you to buy a console that will cost as much as the sensor!

Sguil is my choice for viewing NSM data because it collects all the data I routinely need to look at and sticks it on a panel where I can use it. I've heard several analysts say sguil makes them four times as productive, with greater detection success. I won't go into all of why this works so well, but the big win is the database. Sguil stores data in a mysql database whose schema scales much better than other, similar projects. Here's an example of how it works: suppose you have an alert from your IDS. The state of the technology being what it is, you aren't sure if this is a real attack or not. By right-clicking on the source of the alert, you get a menu that offers options to see what other alerts this source has been involved with. If you see multiple attack signatures triggered, that's pretty good correlation and confirmation. You can also click a radio button to look up information about the owner of the network that source is from. You can click a button to display the rule that matched the traffic and triggered the alert. You can see the packet payload with another click. And - and this is the killer - you can right-click on the event id and either get a plain-text transcript of the connection, or get a bit-for-bit copy of the communication between source and destination. You can see the whole thing, as it transpired. You can send it to other, potentially wiser people for their analysis. You can replay the traffic to test solutions and defenses. You can extract any attack tools downloaded. Finally, if you confirmed that it was an attack, and the transcript showed it succeeded, you can easily bring up a record of all connections between the attacker and other hosts on your network. Even better, you can look at all the susequent network traffic of the compromised destination. It's very, very cool.

Back to the narrative.

I went to a local security expo where four vendors of IPS/IDS products had booths. They make what are essentially tricked-out firewalls. The most crude form of firewall, the packet filter, can make block/permit decisions based only on surface aspects of a single packet, like the source or destination IP address and/or port. Each packet is examined in isolation, which is not good.
A stateful firewall keeps a table of connections, so it can examine a packet in relation to other packets in the same conversation. For example, unlike a packet filter, a stateful firewall can look at a response packet and know that it is really in response to traffic initiated by a host allowed to have that kind of traffic. Stateful firewalls are still limited to surface aspects, but it can look at them in context, which is a big improvement. Application firewalls (Sometimes called "Layer 7") actually model/decode application level protocols. For example, one might be used to discriminate between legitimate HTTP traffic (web traffic), which usually travels to a web server on TCP port 80, and a P2P (Peer-peer) application like the old Napster, which might sneak out on TCP port 80 pretending to be web traffic. A half-step beyond the application level firewall is the IPS. They look deeper into the packet than an application firewall might. They use IDS approaches to looking for attack patterns and behaviors, and go beyond issuing an alert. There are pros and cons to this, among them that the behavior of the firewall may change in response to stimulous of an attacker's choice. An attacker may be able to issue stimuluous that will cause Bad Things to happen, like make blocking decisions that prevent necessary communication. On the other hand, they can keep other Bad Things from happening, like preventing malicious web sites from taking advantage of specific weaknesses in web browsers.

On to the tweaking: I already mentioned why I like Snort and Sguil. I went around asking the booth weasles for the IPS vendors if I could view the signatures and write my own. What kind of output options did I have for reporting. Could I get Flow data? Full content packet captures? The reps for McAfee, ISS, and RealSecure did not cover themselves with glory. For the most part, they had no idea what I was talking about. I don't think they would have recognized a packet dump. I got much blank look and repitition of previous points. (Kinda reminded my of my 3 year old son: "I want ice cream." "You can't have ice cream right now because blah blah blah." Blank look. Shake head to clear it of irrelevant and incomprehensible bullshit. "I want ice cream.") They might as well have been selling refrigerators. "Now, some people don't know that Maytag models give you cancer." The Tipping Point booth weasel did know what he was talking about, and even more, he knew what *I* was talking about. He was pretty comfortable defending the approach his company took. Most people don't do real IDS stuff.

Why You Shouldn't Work with Sharp Objects When You are Tired

The other day I was re-running some fiber optic patch cables on a rack in the server room. If you haven't worked with them, they are very thin, flexible, fragile. In many places, they are run through conduit even on a rack.

The reason for me rerunning them was that the person who did it originally wove them like it was basket-making class. Send one patch cord through this bundle of cables, that one around the bundle, and a third around the other way. Make sure this new bundle of fragile cables interferes with every bundle it crosses...

Ugh.

Anyway, after an hour* I get it all smooth, shipshape and Bristol-fashion. Not quite up to the standards exemplified here but pretty good. I am plugging the patch cords into the switch, when I deem that the patch cords need one more tie to keep them neatly bundled within 1 foot of the switch. I use a zip tie, and need to trim the excess. I get the snippers out.

I cut one of the fibers.

I cuss a bit. I know better than to leave a dead patch cord in the bundle, especially with a seemingly ok end on the other side. So I go to cut the dead one out of the bundle.

I cut another of the fibers.

I go home and fix it the next day. (No server outage - this was for new stuff.)

Lesson learned - watch for fatigue-brain. You can commit some unfathomable errors. If you can learn to recognize it, you can avoid being a Menace to Technology. Some tasks require my Good Brain, some are safe for Low Technology Days.

*This is a clue. It shouldn't have taken an hour, even with the other cleanup I did.

Training Plan

I'm crafting a proposal for the fu-acquisition I expect to accomplish by the end of the year. I'm asking to go to USENIX LISA http://www.usenix.org/events/lisa06/

I went last year and it revitalized my interest in my career. It was really cool to walk into the room and lower the average I.Q. (Yeah, yeah, I should be used to it :P ) Seriously: this was awesome. Most of the instructors literally wrote the (O'Reilly) book. The presentations that make it a real conference (unlike SANS, which has trappings of a conference but is really just training) are amazing. I was torn last year about whether to attend class or a talk. Again, this year. So I want to go again. The line up is again stellar.

I also want to go to Shmoocon, again in Washington, D.C. It's a small, high-end security conference. Only, not stuffy. A little bit of hacker underground to spice things up, but mostly real researchers.

One thing I don't want is Microsoft Authorized Training. Gawd. I was sent to one about 8 years ago that sucked out loud. "To open a file, click the 'file menu' and select the 'open' option." This was for a desktop and network management product. If you think McDonalds sells food, then you might regard this homogonized, standardized crap training. And another thing: Windows 2003 server is designed so that even MCSEs can use it. Training is superfluous. It would be a better use of dept. budget to send me to a triple feature of "Saw III", "Texas Chainsaw Massacre - the Beginning", and "Grudge II" for five days running. Including popcorn. I think that would be a more cost-effective way to induce a similar level of mental illness.

I will grant that actually making that stuff *work* is fairly complicated. But that's a function of shoddy software, and running through the user interface for 5 days is not going to address any of the REAL operational headaches of using the awful stuff from Redmond. What fails, fails under the hood where you can't get at it.

Another thing I don't want: glorified vendor trade shows aimed at non-technical CIOs. I want to see math. Exploit code. Configuration files and options. No "magic security spray."

I do pretty well with text books and web pages, but sometimes it's good to mingle with smart people who have solved hard problems so I don't have to.

Toorcon Report

This year I went to security/haxor conference Toorcon for the first time. I have attended USENIX LISA, which rocks, and SANS, which does good training in the guise of a conference. This was a little...different. Not as insane as Defcon, not as polished as I hear Black Hat is, it consisted of a few hundred self-identified members of the 'Digital Underground', mostly whitehats, but some definite criminals. (Note - don't take offense if you are a Black Hat. It's a crime. I'm not calling anybody a terrorist.)

Very serious presentations, even if some of them were hilarious. One was done remotely and anonymously. It was a little dry, but the technique works.

The Capture the Flag tournement drew three teams competing to hack servers in the tournament network. The Midnight Research Labs crew completely dominated the other two, which consisted of much less seasoned attackers. By dominated, I mean almost shut out. Hundreds of points to nil. Only toward the end of the second day did another team get any points at all, and one team LOST points for losing a server. I am acknowledging the MRL, not dissing the other two teams. Hell, I didn't even enter the damn thing and wouldn't have gotten far if I had. I just play defense.

A licensed private investigator who runs "the largest privately held investigation support service company in the country" gave a scary talk entitled, "Privacy is Dead: Get Over It."

Some points: You may one day lose insurance coverage if someone gets a list of your Amazon purchases and it includes "Recovering from H.I.V." Credit card companies track your purchases, and sell your profile to pretty much anyone. The Feds have outsourced profiling efforts to businesses like Choicepoint, so you can't get FOIA satisfaction. You can't make Choicepoint tell you what they do with your information. You can't even SEE their records of you. Subscribe to "Soldier of Fortune" ? That might get you on a list of suspects. It WILL get you on multiple marketing lists. Every place you have lived, all kinds of crap, is easily accessible. In a couple of hours at most, a fairly full dossier can be compiled for a background check or whatever, without any field work at all. This talk went an extra HOUR, twice the scheduled time, and rolled right through the lunch break. Hardly anybody left.

VOIP (Voice Over IP) vulnerabilities - this stuff isn't news, nor did the speaker claim they were. What he did was demonstrate some exploits, like retrieving voicemail by spoofing CallerID. Some cell phone service providers use nothing but CallerID to authenticate access to voicemail. Well, VOIP software and even hardware allows the user to set the CallerID to whatever s/he wants. Duh.

Bridging - you can spoof SIP (Session Initiation Protocol) packets and set up an unsolicited conference call between two people, who will each think that the other person called them. The speaker passes out cards showing how to do this to women he meets in bars.

He played some audio of these exploits in action, and tied it to a computer model of sound processing in the brain. The model had nothing to do with the topic, but was kind of cool. He had a 3-D application showing activity in the "brain" during playback.

I attended the "Deep Knowledge Seminars", which were basically just regular presentations, but an extra day of them you have to pay for. I gambled and registered early to avoid a steep price increase. The gamble was that the lineup and topics weren't announced....it turned out ok. I found one presentation kind of useless, but the rest were good, including one I planned to skip. That was a consistent refrain: the things I was inclined to dismiss were pretty good.

One highlight: Dan Kaminsky is not a serious researcher - he's too busy laughing his ass off to qualify as serious. But he finds very interesting and hilarious stuff. For example, when notorious criminal hacker Sony Corp. overrode user/owner action and installed a rootkit when someone inserted a Sony music CD (something that should have seen prosecution), Kaminsky analysed DNS traffic to track the scope and spread of the infection. He chucked his scheduled presentation and showed a truly sick hack that requires a little explanation. (Apologies if you already know this stuff) DNS is the service that translates a host name, like www.mywebsite.com, to an IP address a computer can use to connect to. It uses small packets, intentionally limited. (If you get a large enough DNS response, the protocol specifies using a different approach than usual.) A covert channel is where someone creates a communication link through a protocol not intended for that purpose. For example, AIM and Yahoo Messenger (et. al.) will try to use 'standard' ports to connect, but if they fail, will try to phone home using a port generally intended for web traffic. The reason is most networks allow web traffic, so you can use port 80 (assigned by the IANA(?) for HTTP, the web protocol). That's the simple model. More advanced covert channels will use the actual protocol, but take advantage of padding and the like to carry the secret information. Anyway, Kaminsky abused the DNS protocol and stuffed streaming video into a covert channel. Because video is large, and DNS packets are small (by default), this is the most extreme case I can imagine. Anyway, Dan is someone to watch. Very, very smart guy on a staggering array of topics.

It's not all serious stuff. There are massive parties and many of the participants regard drinking as a competitive event. After the Con, there were two trains north from San Diego. I was on the 8:20 PM train. I heard unconfirmed reports of drunk, large, hairy, naked guys from the con causing a ruckus on the 9:15 PM.

I'm pretty introverted and boring, and don't drink. So I didn't participate.

It was interesting to see folks I'd met elsewhere, some at LISA 2005.

I plan to go again. I'll have a new baby around then (if all goes well), but San Diego is a pretty awesome place to visit and I missed my family. So I'll try to bring them.