tag:blogger.com,1999:blog-4088979.post3194438116405205533..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: ShmooCon 2007 Wrap-UpRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-4088979.post-33479212114737174602007-08-02T06:50:00.000-04:002007-08-02T06:50:00.000-04:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-62166186700137413332007-04-23T10:08:00.000-04:002007-04-23T10:08:00.000-04:00SIGVI:Vulnerability management and advisory has a ...SIGVI:<BR/>Vulnerability management and advisory has a free server to test it:<BR/><BR/>http://sigvi.upcnet.es<BR/><BR/>Source packages are available at:<BR/><BR/>http://sourceforge.net/projects/sigviAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-55586645168837382842007-03-30T20:36:00.000-04:002007-03-30T20:36:00.000-04:00More NAC weakness:Cisco's NAC Gets HackedMore NAC weakness:<BR/><BR/><A HREF="http://www.darkreading.com/document.asp?doc_id=120852&f_src=darkreading_default" REL="nofollow">Cisco's NAC Gets Hacked</A>Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-72334783703388155472007-03-28T10:21:00.000-04:002007-03-28T10:21:00.000-04:00Also:Beware of buzz, analyst says NAC is impossibl...Also:<BR/><BR/><A HREF="http://www.computerworld.com.au/index.php/id;253400432;fp;;fpid;;pf;1" REL="nofollow">Beware of buzz, analyst says NAC is impossible to manage</A><BR/><BR/><A HREF="http://www.networkworld.com/newsletters/vpn/index.html" REL="nofollow">Network World articles</A><BR/><BR/><A HREF="http://www.esj.com/news/article.aspx?EditorialsID=2506" REL="nofollow">Why NAC Alone Is Not Enough</A>Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-7466921748628931892007-03-28T10:19:00.000-04:002007-03-28T10:19:00.000-04:00This is a personal reference of recent articles cr...This is a personal reference of recent articles criticizing NAC:<BR/><BR/><A HREF="http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1248292,00.html" REL="nofollow">NAC panel says technology may not add up</A><BR/><BR/><A HREF="http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1246158,00.html" REL="nofollow">Expert: NAC not a network security cure-all</A><BR/><BR/><A HREF="http://www.computerworld.com/blogs/node/5065" REL="nofollow"> A sign of life for NAC</A><BR/><BR/><A HREF="http://techbuddha.wordpress.com/2007/02/20/the-current-failed-state-of-nac/" REL="nofollow">The Current Failed State of NAC</A><BR/><BR/><A HREF="http://securityincite.com/blog/mike-rothman/2007-doi-day-4-trust-no-one" REL="nofollow">2007 DOI Day 4 Trust No One</A><BR/><BR/><A HREF="http://techbuddha.wordpress.com/2007/02/21/stillsecure-insecure-about-nac/" REL="nofollow">StillSecure Insecure about NAC?</A>Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-16424939866373899742007-03-27T17:53:00.000-04:002007-03-27T17:53:00.000-04:00About the printer problem with NAC.By using SNMP m...About the printer problem with NAC.<BR/>By using SNMP monitoring you can conclude that it is the printer that you have placed on the port that answers.<BR/>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.)<BR/>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.<BR/><BR/>/JorgenAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-744736495918772882007-03-27T15:03:00.000-04:002007-03-27T15:03:00.000-04:00About NAC: To provide homogeneous protection you s...About NAC: To provide homogeneous protection you should move dummy devices (like printers) to a different zone and put a stateful fw between the dummy and the "trusted" zone (for dot1x enabled clients). So an attacker might get access to other printers but nothing else...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-61246659802514121222007-03-26T17:43:00.000-04:002007-03-26T17:43:00.000-04:00It's not surprising that Marcus S. didn't like you...It's not surprising that Marcus S. didn't like your TCP posting Richard...not like he doesn't have a vested interest in SANS's reputation:<BR/><BR/>http://sachs.us/marc/<BR/><BR/>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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-66825700801597177072007-03-26T12:18:00.000-04:002007-03-26T12:18:00.000-04:00Great writeup. Johnny was hilarious, and G. Mark ...Great writeup. Johnny was hilarious, and G. Mark Hardy was really cool to watch. Heck, he grew up where I did!<BR/><BR/>I did somewhat of a writeup too, excluding the massive partying.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-81723906023168772672007-03-26T09:25:00.000-04:002007-03-26T09:25:00.000-04:00The easier way to find the mac address is just to ...The easier way to find the mac address is just to print an "information page" off of the printer. You can do it from the menu and cause less of a stir then messing with the cables. Once you get that page just flip off the printer as you walk away.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-9022962115471317472007-03-25T23:53:00.000-04:002007-03-25T23:53:00.000-04:00you said, "Mike and Marc Sachs (who I saw independ...you said, "<I>Mike and Marc Sachs (who I saw independently) were not happy with my TCP options analysis. Oh well!</I>". i wonder what they had said?<BR/><BR/>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?<BR/><BR/>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!<BR/><BR/>while i'm here, i might as well address the NAC and Cisco vulnerability assessment tidbits.<BR/><BR/>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.<BR/><BR/>endpoint security is kind of like a new way of doing patch management and vulnerability management, and suffers from some of the same problems.<BR/><BR/>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).<BR/><BR/>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.<BR/><BR/>vulnerability management suffers a gap in time from discovery to disclosure/reporting to per-company incident to per-device remediation. some tools such as <A HREF="http://advchk.unixgu.ru" REL="nofollow"/>, <A HREF="https://cassandra.cerias.purdue.edu/main/index.html" REL="nofollow">Cassandra</A> and <A HREF="http://sigvi.sourceforge.net/index.php" REL="nofollow">SIGVI</A> provide some ways of sorting through all of the vulnerability management issues, including vendor (or even feature) specific notifications.<BR/><BR/>NAC has all of the above problems, plus a few more we already mentioned ;><BR/><BR/>finally, it may not be so wise to invest in cisco hardware in order to find vulnerabilities when <A HREF="http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator" REL="nofollow">simulators</A> 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).<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>this is why some investment banks patch every server and desktop immediately instead of waiting to test the patches.<BR/><BR/>sorry, i spent the weekend reading jacquith's new book and i'm all excited about security tonight.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-39212860547474792007-03-25T22:14:00.000-04:002007-03-25T22:14:00.000-04:00I saw Ofir's talk at blackhat a year ago and thoug...I saw Ofir's talk at blackhat a year ago and thought to myself..wow can it really be that easy to bypass these systems? The truth is of course yes. I guess the question truly is, what's the purpose of NAC and does it meet that purpose?hogflyhttps://www.blogger.com/profile/00741773109962883616noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-64991423023886935942007-03-25T20:14:00.000-04:002007-03-25T20:14:00.000-04:00Printers and fixed, "dumb" devices like VoIP phone...Printers and fixed, "dumb" devices like VoIP phones are a classic problem in NAC and often end up being the soft underbelly.<BR/><BR/>I'm actually evaluating <A HREF="http://www.verniernetworks.com" REL="nofollow">Vernier's NAC solution</A> 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.<BR/><BR/>Sure, this isn't foolproof, but it does raise the bar considerably.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-53092462947298125482007-03-25T16:38:00.000-04:002007-03-25T16:38:00.000-04:00Richard,Johnny Long's talk was easily the most ent...Richard,<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>H1kari's FPGA talk was one of the other 20-minute talks I found pretty interesting.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>NateAnonymousnoreply@blogger.com