ShmooCon 2007 Wrap-Up
ShmooCon 2007 ended today. Only four talks occurred today (Sunday), and only two of them (Mike Rash, Rob King/Rohlt Dhamankar) really interested me. Therefore, I went to church with my family this morning and took lead on watching the kids afterwards. I plan to watch those two interesting talks once they are released as video downloads. (It takes me 1 1/2 - 2 hours each way into and out of DC via driving and Metro, so I would have spent more time on the road than listening to speakers.)
I also left right after Bruce Potter's introductory comments on Friday afternoon. If it hadn't been for the NoVA Sec meeting I scheduled Friday at 1230, I probably would have only attended Saturday's sessions. I heard Avi Rubin's 7 pm keynote was good, and I would have liked to watch Johnny Long's talk. Otherwise I thought spending time with my family was more important.
That leaves Saturday. I spent the whole day at ShmooCon, from the first talk to the end of Hack or Halo. I began the day with Ofir Arkin from Insightix. (I actually spent about half an hour chatting with Ofir Friday afternoon, which was cool. I also spent time Friday speaking with several people I recognized.) Ofir demonstrated that just about all Network Admission Control concepts and implementations are broken. He only covered about half his material, but I left wondering who would bother spending thousands or millions on NAC when it doesn't seem to work and is fighting the last war anyway.
Ofir emphasized that knowledge of the enterprise is the key to network defense. He pointed out that NAC products which provide a shared medium quarantine area are exactly where an intruder wants his machine to be delivered. Once in that area he can attack the weakest, non-compliant systems on the same subnet or VLAN used by the quarantine. Using PVLANs an avoid this problem, but only if not subject to VLAN hopping attacks. Ofir questioned whether per-port security is ever feasible, especially in an age of increasing use of VMs.
One basic take-away for me was this: if I find myself on a network requiring NAC, do the following.
While this will not work everywhere, it's probably going to work in enough places to make NAC a questionable prospect for physical defense. Hosts connecting via VPN are another issue.
After Ofir spoke I saw Joel Wilbanks, Matt Fisher, and Mike Murphy talk about incident response when Web applications are attacked. They made the point that Web app incidents don't usually leave artifacts (think files on the hard drive) on the victim. Web app forensics becomes a log analysis exercise. If no logs exist (Web, database, OS, etc.), you're hosed. They recommended populating database tables with honeytokens and writing custom IDS signatures to alert on the presence of those tokens in network traffic.
During their presentation several attendees questioned the role of SSL for inbound connections. The speakers recommending terminating SSL at an accelerator, and passing clear text by an IDS before sending it to the Web server or re-encrypting it. At least one of the attendees was shocked -- shocked -- to consider passing "sensitive" data in the clear like that. I have never understood this argument. The question is simple: do you care to know what is being carried in SSL, or do you not care? If you do care (and you should), architect your enterprise so you have visibility into what's happening. If you don't care, tell me so I can avoid doing business with you.
As far as SSL is concerned, I consider inbound SSL a solved problem. Outbound SSL, as might be used for a command and control channel, is not solved -- unless you want to break SSL and teach users to accept a man-in-the-middle attack scenario. I worry about outbound SSL, not inbound.
I had lunch with Joe Stewart, so in some sense I didn't really miss his talk. He was nice enough to share his thoughts with me on his next Sandnet and other projects.
My talk happened at 1300. This means I missed Billy Hoffman release Jikto, so I plan to download his talk (and Joe's) when available. I was really pleased by the outcome. The room was totally filled and people were standing outside the room listening. Thanks to everyone who attended. I wish we had more time for questions, so feel free to leave a comment here or email if you have unanswered issues.
After my talk I listened to Raven talk about backbone security. She is fuzzing key routing protocols (RIP, OSPF, EIGRP, BGP, etc.) by mainly attacking open source implementations. She just got a Cisco 2600 series router so IOS is her next target. If she is getting results doing this work in her spare time sitting in airports, you can only imagine what funded, dedicated teams are doing with budgets for equipment and manpower.
I spent the next hour chatting with familiar faces in the area near the talks. Marty McKeay was there, along with Mike Rash, Jamie Butler, and Bret Padres and Ovie Carroll from the CyberSpeak Podcast. (Sorry I couldn't get back to you guys in time!)
At 1600 I squeezed into Dan Kaminsky's talk. Before he started I had a chance to chat briefly with Mike Poor and Ed Skoudis from Intel Guardians. Mike and Marc Sachs (who I saw independently) were not happy with my TCP options analysis. Oh well!
I felt bad for Dan. The poor guy showed remarkable resolve trying to speak, despite an attendee who felt compelled to interrupt every fifth sentence. Dan had to dodge plenty of Shmoo balls while explaining slides with way too many words on them. I think Dan's research is way outside the realm of what most security people do, but probably perfect for a paper at USENIX.
I stayed in the same room to listen to Josh Wright and Mike Kershaw talk about LORCON. As their Web page states: LORON is "a generic library for injecting 802.11 frames, capable of injection via multiple driver frameworks, without forcing modification of the application code." Basically, if you write a wireless packet injector, you should use LORCON. Don't write something for a specific wireless driver -- let LORCON handle that for you. I was really impressed, especially since I had never seen Mike (author of Kismet) and Josh (lots of tools, cool research) in person. In addition to LORCON they mentioned this WiFi frame injection patch for Wireshark.
When their talk was done I headed over to the Hack or Halo room. I set up my Hacom Lex Twister on a SPAN port (argh, yes, I forgot a tap) and captured the traffic from the Hack contest. I monitored it live with Sguil, which was fun.
Overall, I was again impressed by the organization and manpower demonstrated by ShmooCon. I was less impressed by the overall slate of talks, but I think the quality of attendees compensated for that. The first ShmooCon in 2005 attracted about 350 people. The second had about 800. This year nearly 1200 people attended. I was very thankful to attend and speak and I look forward to at least attending next year.
Update: I forgot to ask -- if you liked my talk, please send feedback to feedback [at] shmoocon [dot] org. Thank you!
I also left right after Bruce Potter's introductory comments on Friday afternoon. If it hadn't been for the NoVA Sec meeting I scheduled Friday at 1230, I probably would have only attended Saturday's sessions. I heard Avi Rubin's 7 pm keynote was good, and I would have liked to watch Johnny Long's talk. Otherwise I thought spending time with my family was more important.
That leaves Saturday. I spent the whole day at ShmooCon, from the first talk to the end of Hack or Halo. I began the day with Ofir Arkin from Insightix. (I actually spent about half an hour chatting with Ofir Friday afternoon, which was cool. I also spent time Friday speaking with several people I recognized.) Ofir demonstrated that just about all Network Admission Control concepts and implementations are broken. He only covered about half his material, but I left wondering who would bother spending thousands or millions on NAC when it doesn't seem to work and is fighting the last war anyway.
Ofir emphasized that knowledge of the enterprise is the key to network defense. He pointed out that NAC products which provide a shared medium quarantine area are exactly where an intruder wants his machine to be delivered. Once in that area he can attack the weakest, non-compliant systems on the same subnet or VLAN used by the quarantine. Using PVLANs an avoid this problem, but only if not subject to VLAN hopping attacks. Ofir questioned whether per-port security is ever feasible, especially in an age of increasing use of VMs.
One basic take-away for me was this: if I find myself on a network requiring NAC, do the following.
- Find the nearest printer.
- Unplug the network cable.
- Connect the network cable from the printer to a hub, and connect the hub to the network port.
- Connect my laptop to the hub.
- Sniff printer's MAC address and IP address.
- Disconnect the printer.
- Assign the printer's MAC and IP address to my laptop, and access the network.
While this will not work everywhere, it's probably going to work in enough places to make NAC a questionable prospect for physical defense. Hosts connecting via VPN are another issue.
After Ofir spoke I saw Joel Wilbanks, Matt Fisher, and Mike Murphy talk about incident response when Web applications are attacked. They made the point that Web app incidents don't usually leave artifacts (think files on the hard drive) on the victim. Web app forensics becomes a log analysis exercise. If no logs exist (Web, database, OS, etc.), you're hosed. They recommended populating database tables with honeytokens and writing custom IDS signatures to alert on the presence of those tokens in network traffic.
During their presentation several attendees questioned the role of SSL for inbound connections. The speakers recommending terminating SSL at an accelerator, and passing clear text by an IDS before sending it to the Web server or re-encrypting it. At least one of the attendees was shocked -- shocked -- to consider passing "sensitive" data in the clear like that. I have never understood this argument. The question is simple: do you care to know what is being carried in SSL, or do you not care? If you do care (and you should), architect your enterprise so you have visibility into what's happening. If you don't care, tell me so I can avoid doing business with you.
As far as SSL is concerned, I consider inbound SSL a solved problem. Outbound SSL, as might be used for a command and control channel, is not solved -- unless you want to break SSL and teach users to accept a man-in-the-middle attack scenario. I worry about outbound SSL, not inbound.
I had lunch with Joe Stewart, so in some sense I didn't really miss his talk. He was nice enough to share his thoughts with me on his next Sandnet and other projects.
My talk happened at 1300. This means I missed Billy Hoffman release Jikto, so I plan to download his talk (and Joe's) when available. I was really pleased by the outcome. The room was totally filled and people were standing outside the room listening. Thanks to everyone who attended. I wish we had more time for questions, so feel free to leave a comment here or email if you have unanswered issues.
After my talk I listened to Raven talk about backbone security. She is fuzzing key routing protocols (RIP, OSPF, EIGRP, BGP, etc.) by mainly attacking open source implementations. She just got a Cisco 2600 series router so IOS is her next target. If she is getting results doing this work in her spare time sitting in airports, you can only imagine what funded, dedicated teams are doing with budgets for equipment and manpower.
I spent the next hour chatting with familiar faces in the area near the talks. Marty McKeay was there, along with Mike Rash, Jamie Butler, and Bret Padres and Ovie Carroll from the CyberSpeak Podcast. (Sorry I couldn't get back to you guys in time!)
At 1600 I squeezed into Dan Kaminsky's talk. Before he started I had a chance to chat briefly with Mike Poor and Ed Skoudis from Intel Guardians. Mike and Marc Sachs (who I saw independently) were not happy with my TCP options analysis. Oh well!
I felt bad for Dan. The poor guy showed remarkable resolve trying to speak, despite an attendee who felt compelled to interrupt every fifth sentence. Dan had to dodge plenty of Shmoo balls while explaining slides with way too many words on them. I think Dan's research is way outside the realm of what most security people do, but probably perfect for a paper at USENIX.
I stayed in the same room to listen to Josh Wright and Mike Kershaw talk about LORCON. As their Web page states: LORON is "a generic library for injecting 802.11 frames, capable of injection via multiple driver frameworks, without forcing modification of the application code." Basically, if you write a wireless packet injector, you should use LORCON. Don't write something for a specific wireless driver -- let LORCON handle that for you. I was really impressed, especially since I had never seen Mike (author of Kismet) and Josh (lots of tools, cool research) in person. In addition to LORCON they mentioned this WiFi frame injection patch for Wireshark.
When their talk was done I headed over to the Hack or Halo room. I set up my Hacom Lex Twister on a SPAN port (argh, yes, I forgot a tap) and captured the traffic from the Hack contest. I monitored it live with Sguil, which was fun.
Overall, I was again impressed by the organization and manpower demonstrated by ShmooCon. I was less impressed by the overall slate of talks, but I think the quality of attendees compensated for that. The first ShmooCon in 2005 attracted about 350 people. The second had about 800. This year nearly 1200 people attended. I was very thankful to attend and speak and I look forward to at least attending next year.
Update: I forgot to ask -- if you liked my talk, please send feedback to feedback [at] shmoocon [dot] org. Thank you!
Comments
Johnny Long's talk was easily the most entertaining and interactive that I attended. The way he got the audience involved on his own terms (rather than the way the audience was involved during Dan Kaminsky's talk) was a big plus, in my opinion. Long's talk certainly was nothing groundbreaking but it was a good demonstration on an effective way to give an entertaining talk.
I also think the 20 minute talks with another 10 minutes for questions were great. It is much easier to give a talk that keeps people interested for 20 minutes compared to an hour.
H1kari's FPGA talk was one of the other 20-minute talks I found pretty interesting.
Avi Rubin's keynote was quite good. I have to say they've done a great job choosing the keynote speakers in the two years I've been. He had an amusing story about cracking the Exxon/Mobil Speedpass. When they demonstrated for reporters, they filled their cars with gas on the reporters' Speedpasses. :) He also had what seemed like great advice for vulnerability researchers in terms of law and protecting themselves.
Today, Sunday, the most talked about presentation was RFIDiots. My friend that made it to that talk said one of the best parts was the live demonstrations and that it was overall very entertaining.
Joe Stewart's talk was good. His demonstration of automating the malware network behavior analysis and using serial debug protocol in the third generation of truman was definitely cool
One thing I disagreed with was his opinion that the ratio of malware that won't run in VMs is going to stay about the same or drop because the authors will miss too many targets as production boxes are moved to virtual machines. He certainly has more experience than I, but most malware I see in the wild is infecting clients, not servers. I don't think we're going to see clients moved to VMs en masse anytime soon, so I don't think malware authors have more to gain by not allowing code to run in a VM than having it run.
I totally agree with your comments about Kaminsky. I thought his talk last year was much better suited for the Shmoocon audience than his talk this year.
Nate
I'm actually evaluating Vernier's NAC solution for this very reason. One thing that they do, at least for phones, is ensure that the devices act like phones -- SIP messages, a proper and positive response from the gateway, etc.
Sure, this isn't foolproof, but it does raise the bar considerably.
sorry i missed your earlier post about the tcp options analysis. after reading it now, it makes sense to me. what do you think you're missing?
just to be clear - the juno-z packet is exactly like a windows 2000 syn, except for the bad mss at the end. the nop is supposed to be there, and it is also seen in a normal win2k syn. nothing to see here, move along!
while i'm here, i might as well address the NAC and Cisco vulnerability assessment tidbits.
Cisco NAC employs a lot of different elements. the elements that matter IMO, are port-security plus DAI (which requires DHCP snooping and IP/MAC source-guard). it is my feeling that the scanning aspects are a security issue at this time, since most scanners are not secure themselves.
endpoint security is kind of like a new way of doing patch management and vulnerability management, and suffers from some of the same problems.
patch management has problems with zero-day because rootkits/backdoors today, especially as part of the payload of bleeding-edge malware, also may employ covert channels (see gray-world.net's http cookies as an example). if the patch mgmt agent (also see AV agent, NAC agent, Matasano's enterprise agents talk, etc) or even built-in OS features things like remediation through automatic update - then the system also suffers from what i coined as "call home through call home". these would be covert channels that look exactly like realistic traffic. there's all sorts of ways of doing this (also see nmrc's ncovert, shared library injection, syscall proxying, everything on rootkit.com|nl, ephemeral security's mosquito, et al).
along with patch management is exploit countermeasures (NOEXEC, ASLR, SafeSEH, Windows hardware DEP). some of these work in some places and sometimes they don't. exploits can be re-written easily (see: metasploit exploit builder, immdbg's !breakdep, etc), which makes chasing the exploit a zero-sum game.
vulnerability management suffers a gap in time from discovery to disclosure/reporting to per-company incident to per-device remediation. some tools such as , Cassandra and SIGVI provide some ways of sorting through all of the vulnerability management issues, including vendor (or even feature) specific notifications.
NAC has all of the above problems, plus a few more we already mentioned ;>
finally, it may not be so wise to invest in cisco hardware in order to find vulnerabilities when simulators exist for at least the MIPS and PowerPC platforms (and what other ones are there?). IOS and JunOS images can be plopped into Xen hardware virtual environments and tested at large in this way. the reasoning behind this is not only virtual machine introspection (i.e. XenAccess), but also to test devices in different states (non-standard configurations, varying protocol states, etc). we've already had binary analysis of these images for awhile now (see: IDA Pro + BugScam, Michael Lynn's BlackHat talk from 2004, Sabre-Security BinAudit, etc).
speaking of sabre-security, two months ago Halvar Flake announced support of remote-GDB to BinNavi for IOS and ScreenOS targets. thus, live analysis (i.e. run-time debugging, possibly memory debugging, core file debugging, and advances like hit tracking or process stalking) can also be performed along with fuzz testing that could include quite a bit of code coverage for nearly every parameter and input.
we also know that Cisco IOS source code has been floating around the Internet since about 1994... and that multiple versions have made their way into various underground trading circles. so static-code analysis outside of Cisco's development environment is not out of the question - we know it can be done. same with Windows source code.
and there's always the problem of pre-existing backdoors... let's say Ollie Whitehouse at Symantec finds a vulnerability in Cisco IOS, publishes it to Cisco, and they keep quiet and sit on it for 5 months before talking about it. well, let's say that Ollie was previously owned, or the channel between he and Cisco were owned, or Cisco itself is owned.
this is why some investment banks patch every server and desktop immediately instead of waiting to test the patches.
sorry, i spent the weekend reading jacquith's new book and i'm all excited about security tonight.
I did somewhat of a writeup too, excluding the massive partying.
http://sachs.us/marc/
Although he may be listed as a volunteer, he does quite a bit of teaching for them at SANS conferences ...so I'm sure he's receiving monetary compensation for his time with SANS as well.
By using SNMP monitoring you can conclude that it is the printer that you have placed on the port that answers.
If a hostile pc is connected with the printers mac address, then you will not get the correct SNMP information back and have an automaticaly action that closes the port. (serial number etc.)
There are a lot of variables to monitor on printers and a summary of these can fingerprint the printer. Then a Hacker has to have a complete working dump of all the variables of that printer or device to be invisible. I think thats a way to secure printers and other network devices.
/Jorgen
NAC panel says technology may not add up
Expert: NAC not a network security cure-all
A sign of life for NAC
The Current Failed State of NAC
2007 DOI Day 4 Trust No One
StillSecure Insecure about NAC?
Beware of buzz, analyst says NAC is impossible to manage
Network World articles
Why NAC Alone Is Not Enough
Cisco's NAC Gets Hacked
Vulnerability management and advisory has a free server to test it:
http://sigvi.upcnet.es
Source packages are available at:
http://sourceforge.net/projects/sigvi