17 February, 2008

Shmoocon 2008 Notes

I attended my third Shmoocon in a row, Shmoocon 4. As with most conferences, there were some winning talks and some that struggled. I'll have more to say about over-all quality when I discuss the "0wn the Con" session. Since I find myself with a fairly fuzzy memory about specifics of talks I attended at previous Shmoocons, this post is mainly to prevent that from happening again.

I went to H1kari's talk titled "Intercepting Mobile Phone/GSM Traffic." Once again, he was talking about using FPGA, this time to assist in breaking GSM encryption. He also had a lot of nice tidbits about weaknesses in GSM, both in implementation and design. I didn't take notes, but I seem to recall that he mentioned some broadcasts occurring in plain text and that, for some reason, the last 10 bits of the A5 key are zeroed out. (Someone correct me if I am remembering incorrectly). After he finishes computing what are basically GSM rainbow tables, H1kari was talking about cracking GSM in as little as 30 seconds using 16 FPGA and a large amount of disk space. The rainbow tables are being computed using 68 FPGA.

He didn't really address 3G other than saying it is generally superior in terms of security when compared to GSM.

I wandered into the last few minutes of Deviant Ollam's "New Countermeasures to the Bump Key Attack". Although I didn't see enough to comment on the content of the talk, he was getting a great response from the audience and seemed like an entertaining speaker.

The keynote was supposed to be by Edward Felten of Princeton's Center for Information Technology Policy. He apparently had the flu, so one of his graduate students, J. Alex Halderman, had to stand in. Halderman did quite a good job talking about their experience auditing and exploiting voting machines, especially considering what was probably short notice. Most of the information from the talk was widely circulated by the media at one point or another. The keynotes have been consistently good at Shmoocon, so I plan on getting to the keynote at any future Shmoocon I attend.

On day two I attended "SIPing Your Network" by Humberto J. Abdelnur, Radu State and Olivier Festor. There was some very interesting technical content, including discussion of fuzzing, remote eavesdropping, crashing one particular phone using a single packet with an empty data field, and attacking HTTP-enabled phones with cross-site scripting and SQL injection. Their SIP fuzzer is called KiF.

The presenters stated that they can remotely eavesdrop by dialing an IP phone, having it pick up with no user interaction, and then leave the phone in a state where it appears that the call is hung up but the phone will still send voice data. They had technical difficulties with a demo, and really waited too long to skip the demo and push on. They lost some of the audience as a result, but other than that I thought it was a good presentation.

At the end, the presenters, who are French, had a slide with information on their SIP fuzzer's license. The presenters indicated that, since it could be classified as an attack tool and because of French law, there are some restrictive requirements including that the license agreement has to be signed and sent in by the end user via snail-mail.

Jay Beale presented "They're Hacking Our Clients! Why are We Focusing Only on the Servers?" I didn't see any of his opinions as particularly surprising, but it was well presented and he was engaging. It did surprise me when a comment from the audience accused him of fear-mongering. At least in my experience, it is so simple to exploit clients and get internal access that the notion of needing a smart attacker to write a custom exploit against locked-down servers is unnecessary. At this point, I agree with what I think Beale was trying to point out, which is that security has been so focused on Internet-facing servers that clients are relatively easy to exploit and leverage in an attack.

Beale talked about problems with small offices that have private information on client workstations, using the example of his dentist. This struck home for me since my friend mentioned sitting in his dentist's office once and finding their WAP wide open with the factory default administrator account and password.

During the portion of the talk devoted to the difficulty with keeping Windows clients up-to-date in an enterprise, he mentioned non-standard or non-Microsoft software, and vulnerable browser plugins, Adobe Acrobat's plugin for example. It made me think of Richard Bejtlich's posts about thin clients. Of course, thin clients present their own problems and aren't immune to all the security problems of stand-alone desktops, but they may offer advantages by reducing the burdens that are a part of updating.

"VoIP Penetration Testing" by John Kindervag and Jason Ostrom was another interesting talk about voice over IP. The main focus of the presentation was Ostrom's VoIP Hopper, which is a nice pen-test tool that he used to show how insecure VoIP implementations can be. With Cisco VoIP phones, he showed how their default install has the PC-port on the back enabled, it sends out CBP packets, and it has a sticker on it with the MAC address. Some or all of these defaults can be used along with VoIP Hopper to gain access to the VoIP VLAN.

"Advanced Protocol Fuzzing - What we learned when bringing Layer2 logic to SPIKE Land" by Enno Rey and Daniel Mende was a good example of two guys with a strong background in networking who decided to bring fuzzing into their area of expertise and share what they learned. Within a relatively short time, my impression was that they went from little experience fuzzing to customizing SPIKE, and they successfully did a live demonstration showing their ability to crash a Cisco 35xx-series remotely. Dave Aitel already mentioned it on his DailyDave mailing list. This was pretty cool stuff, and it will be interesting to see how quickly others jump into the game.

"0wn the Con" with the Shmoo Group is a talk they have every year that discusses their finances, selection process for talks, methods of collaboration, and more. They also took a lot of feedback from the audience. The main thing I want to point out is that it is really hard to get both consistently good presentations and not rely on the same few presenters every year. Shmoo doesn't want the same old thing, but they want good talks, so it is a difficult balance between risk and reliability. I would say the talks are inconsistent in quality, but it is worth it in my opinion to prevent the talks or presenters from being stale, or having too many repeats from other conferences.

One funny thing is that it took this long for someone to suggest making electronic feedback forms available on the Shmoocon website for each talk. Four years into it, and finally someone has the brilliant idea that people should be able to provide feedback from their laptops while they're listening to the talk instead of using a pen and paper and turning it in at the end of the conference. D'oh!

07 February, 2008

Kubuntu with Rhine-II NIC

My Windows XP system at home recently became unbootable with a system error. It's an old system running on an Iwill DVD266-Rn motherboard with dual P3 1.4GHz Tualatins. It is my desktop system designated for non-technical users. After a few brief attempts at a fix from the Windows recovery console, I decided to just install an Ubuntu variant, a fairly safe bet for non-technical users.

I booted to the Ubuntu CD and first backed up all the user profiles and other data to DVD. Then I installed Kubuntu. After installation, I made a few tweaks for my user profile and installed some Firefox plugins like Flash and Java for all users. The whole install and configuration process was fairly quick and painless.

I did have one issue. My network card is an onboard VIA VT6102 Rhine-II.

$ lspci | grep Eth
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 61)
It kept flaking out with errors in /var/log/messages.
kernel: [ 2904.217053] NETDEV WATCHDOG: eth0: transmit timed out
kernel: [ 2904.217210] eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
kernel: [ 2904.217848] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
The only way the NIC would start working again was a reboot. Removing and reinserting the modules did not help.

A web search revealed that this is a common problem with the NIC. Apparently, the NIC does not come back up after the hardware reset. I noticed various proposed solutions for the problem. The solutions included using "noapic" at boot time, using ethtool to disable tso (tcp segmentation offload), and playing around with IRQ settings in the system BIOS.

Next, I checked the kernel log. This error was a bit more informative.
kernel: [ 2064.587535] irq 11: nobody cared (try booting with the "irqpoll" option)
This message also led me to an Ubuntu bug report where a user confirmed that irqpoll solved the problem in at least one case and also where the Ubuntu team indicated the bug does not qualify for a stable release update.

Using "irqpoll" as a default option in my grub configuration seems to fix the problem for me. The NIC has been running without any error messages for about two days now.

06 February, 2008

Inline devices and fail open

There was a post to the sguil-users mailing list asking for recommended fail-open network cards in the hopes that it would be less expensive than alternatives. Richard Bejtlich pointed out that the long-term costs and lower downtime make bypass switches worth the initial expense. This make a lot of sense.

One thing people need to note when talking about inline devices and fail-open hardware is that many devices will only fail open in a powered off state. For example, if you're running Snort inline with a fail-open NIC and the Snort process dies, then the box will no longer pass traffic. Your link is down unless you fix the problem by restarting Snort or you shut off the system completely, which will then cause the fail-open NIC to cross-connect and pass traffic.

If a system only fails open when the power is off, you still need to be aware that an operating system or application failure can take down your link if the fail-open hardware remains powered on. NetOptics has some bypass switches that have a heartbeat feature to address this problem.

An exclusive Heartbeat feature monitors link status between the Bypass and monitoring tools for enhanced reliability. A configurable Heartbeat packet is injected into the monitor port link to help determine availability of attached monitoring tools. For instance, the Bypass Switch can automatically switch network traffic around an unresponsive IPS appliance – even if the IPS is still powered on. Once the IPS re-establishes a connection, traffic is re-routed to the monitor port for continued operation.
This is a better solution than a NIC that will only fail open when the power is off, but not all bypass switches have the feature. If anyone knows of other vendors or hardware that have a similar feature, please let me know.

It's also important to know that the use of the terms "fail open" and "fail closed" is not always consistent.