From peter at adamantix.org Sat Aug 1 07:20:33 2009 From: peter at adamantix.org (Peter Busser) Date: Sat, 1 Aug 2009 13:20:33 +0200 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> Message-ID: <20090801112033.GA5782@adamantix.org> Hi, On Tue, Jul 28, 2009 at 01:44:38PM +0200, yersinia wrote: > FWIW, also "insane" > > http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326479/thread#mid-326479 Strong words indicate a weak cause. And it takes one to know one. Anyways, that is an interesting discussion. It is funny to see Theodor T'So mention that SELinux is insanely complex. Apparently it takes several years for certain Linux kernel hackers to reach conclusions which are totally obvious to others. To summerise the discussion: The only thing which counts is how many lines of code you write for the Linux kernel. It doesn't matter whether you have to work hard to find and understand security bugs so you don't have time left to hack Linux kernel code. And if dare to protest against that, we're going to kick you in the nuts for so long that you will eventually shut up. Then we'll steal your candy, do the Penguin dance, and boast to our friends about how cool we are. You cannot imagine how much respect I have for such people. The biggest problem I have with discussions like that is that they are totally boring, they never end, and they never produce anything useful. I cannot understand how seemingly intelligent people can waste their time on things like that. Groetjes, Peter. From peter at adamantix.org Sat Aug 1 07:46:07 2009 From: peter at adamantix.org (Peter Busser) Date: Sat, 1 Aug 2009 13:46:07 +0200 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <392650.22524.qm@web65409.mail.ac4.yahoo.com> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> <392650.22524.qm@web65409.mail.ac4.yahoo.com> Message-ID: <20090801114607.GB5782@adamantix.org> Hi! > Lets say there's a new bug introduced in the kernel. One that presents with the symptom of disclosing a user's password > when the kernel is given some invalid argument to printk while processing the shadow file. However, when processing > the etc/hosts file, it just discloses the contents of that file. Is that a security bug? You could argue yes; you could argue no. > At the end of the day, someone has to do the work to figure out that it either does or doesn't have security implications. Is the Linux kernel designed to disclose the contents of a file like /etc/hosts? If not, then it is a security bug. A secure system is one which is implemented to EXACTLY fit its specification, nothing more, nothing less. Therefore it doesn't matter whether it discloses one file or some other file or what the contents of these files are. What matters is that it provides more functionality than what the specification of the Linux kernel prescribes. That means that Linus' arguments are simply irrelevant. The biggest security issue in this case is that people take Linus' words seriously and try to bend the discussion in such a way as to fit his words. Or, in other words, these people seem to think that Linus is always right. They seem to forget that Linus is a human being and therefore makes mistakes. People seem to forget that Linus' primary interest is to motivate people to write code for the Linux kernel. And Linus, despite being a competent kernel hacker, doesn't understand security in general. People usually aren't motivated to put time in things which they aren't good at. Groetjes, Peter. From jlloret at dcom.upv.es Wed Aug 5 19:56:16 2009 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Thu, 6 Aug 2009 01:56:16 +0200 Subject: [Dailydave] [NPA] 1st Call for Papers: International Journal of Network Protocols and Algorithms Message-ID: <200908052356.n75NuGgO019760@smtp.upv.es> Dear Associate Editor, Please, disseminate this call for papers to your colleagues and distribution lists. Thank you very much. Best regards, Jaime Lloret Mauri ********************* Call for Papers ********************* International Journal of Network Protocols and Algorithms ISSN 1943-3581 http://www.macrothink.org/journal/index.php/npa/ Network Protocols and Algorithms is a free online international journal, peer-reviewed and published by Macrothink Institute. It publishes papers focused on the design, development, manage, optimize or monitoring any type of network protocol, communication system, algorithm for communication and any protocol and algorithm to communicate network devices in a computer network. The scope of the journal include, but are not limited to, the following topic areas: Distributed/Decentralized Algorithms for Networks Security Protocols and Algorithms QoS Protocols and Algorithms Ad-Hoc and Sensor Network Protocols and Algorithms Cluster-Based Protocols and Algorithms Routing Protocols and Algorithms Fault tolerant Protocols and Algorithms Wireless Protocols and Algorithms MAC Protocols and Algorithms for Wired Networks Mesh network protocols and algorithms Cognitive Radio Network Protocols and Algorithms Monitoring and management protocols and algorithms Optical networking protocols and algorithms Protocols and algorithms for Green Computing and Resource Allocation Power Efficient and Energy Saving Network Protocols and Algorithms Real-Time Protocols and Algorithms Tree-based Protocols and Algorithms Mobile wireless internet protocols and algorithms Protocols and algorithms for Mobile and Dynamic Networks P2P Protocols and Algorithms Synchronization Protocols and Algorithms Content Delivery Networks Protocols and Algorithms Delay Tolerant protocols and algorithms Protocols and algorithms for Voice over IP delivery Scalable Network Protocols and Algorithms You are welcome to submit a paper or forward this call for papers to the mailing lists you belong to and to any people working in Network Protocols and Algorithms that may be interested in working in this area. The topics suggested by the journal can be discussed in term of concepts, state of the art, standards, implementations, running experiments and applications. Proposals and deployments are also welcome. Important Dates for the first Issue: _ Manuscript Due: August 30, 2009 _ Notification: September 20, 2009 _ Final Manuscripts Due: October 4, 2009 _ Tentative Publication: October 2009 Submission Information: Only original and unpublished research papers will be considered in this journal. Manuscripts must be in English. All submissions will be reviewed based on technical merit and relevance. Instructions for authors and submissions can be found in http://www.macrothink.org/journal/index.php/npa/about/submissions Jaime Lloret Mauri Editor in Chief of the International Journal of Network Protocols and Algorithms Associate Professor Department of Communications Polytechnic University of Valencia From dave at immunityinc.com Thu Aug 6 15:36:40 2009 From: dave at immunityinc.com (dave) Date: Thu, 06 Aug 2009 15:36:40 -0400 Subject: [Dailydave] parsers fall down go boom? Message-ID: <4A7B30C8.50000@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good read: http://www.cert.fi/en/reports/2009/vulnerability2009085.html So fuzzing can find lots of cool bugs, and one of the things you eventually learn is that you don't want to attach a giant parser where you don't absolutely have to. This is the sort of global statement that leads you to believe that entire technology segments are a bit wonky (aka, NIDS, NIPS, AV, WAF ("Web Application Firewall"), etc.). Of course, "don't do it unless you absolutely have to" sometimes means you still do it. This morning when I got in, I read an email announcement from D2 about a new exploit they've released that targets a popular WAF. Lemme tell you, there's nowhere a hacker would rather be than on your WAF. If for no other reason than the irony, because hackers have good senses of humour. D2's CANVAS pack is like, less than 2K USD. Honestly, you'd have to be crazy not to buy it just to find out which WAF I'm talking about in this email. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkp7MMgACgkQtehAhL0ghep5gACdExaRDPaqwMn7hlhTdWDtHfTA qG0AnRZiyorZfJgpbGJMFhx6VaW8cMev =rR8P -----END PGP SIGNATURE----- From adrien at kunysz.be Thu Aug 6 16:42:53 2009 From: adrien at kunysz.be (Adrien Kunysz) Date: Thu, 6 Aug 2009 21:42:53 +0100 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <20090801114607.GB5782@adamantix.org> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> <392650.22524.qm@web65409.mail.ac4.yahoo.com> <20090801114607.GB5782@adamantix.org> Message-ID: <20090806204253.GY13769@baltika> On Sat, Aug 01, 2009 at 01:46:07PM +0200, Peter Busser wrote: > A secure system is one which is implemented to EXACTLY fit its specification, > nothing more, nothing less. Then we are back to "all bugs are security bugs and there is no point in trying to make any distinction". Linus is obviously not interested in trying to make the distinction, you are (although your argumentation seems broken). Linus manages the Linux kernel, you don't. You can keep arguing but I doubt it will make much change regardeless of who is right (not that I fully agree on how Linus is handling (security) bugs or people). Can we go back to discuss interesting technical stuff now please? I like this paper http://vanish.cs.washington.edu/research.html and I think it hasn't been posted here yet. It isn't really breakthrough research or anything (despite what you could expect from the title) but it's an interesting combination of existing technologies although the application field seems rather limited and not really corporate or government-friendly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090806/aa1b65c7/attachment-0001.pgp From treed at ultraviolet.org Thu Aug 6 17:13:40 2009 From: treed at ultraviolet.org (Tracy Reed) Date: Thu, 6 Aug 2009 14:13:40 -0700 Subject: [Dailydave] parsers fall down go boom? In-Reply-To: <4A7B30C8.50000@immunityinc.com> References: <4A7B30C8.50000@immunityinc.com> Message-ID: <20090806211340.GE17084@tracyreed.org> On Thu, Aug 06, 2009 at 03:36:40PM -0400, dave spake thusly: > Lemme tell you, there's nowhere a hacker would rather be than on > your WAF. If for no other reason than the irony, because hackers > have good senses of humour. I have been wondering about this very thing. NIDS don't bother me so much because it is usually on a mirror port and not really directly in the flow of things. A little harder to get ahold of and less useful. But a WAF...that's a different story. And things like PCI-DSS 6.6 require code review (expensive and a pain) OR a WAF (which nearly everyone chooses). I have never liked to deploy WAFs instead preferring to attempt to write more secure code although defense-in-depth etc can't hurt. But I have actually heard webapp developers use the WAF as a crutch ("Learn parameterized queries? But we have a WAF!"). -- Tracy Reed http://tracyreed.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090806/502f7207/attachment.pgp From pageexec at freemail.hu Fri Aug 7 05:22:17 2009 From: pageexec at freemail.hu (pageexec at freemail.hu) Date: Fri, 07 Aug 2009 11:22:17 +0200 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <20090806204253.GY13769@baltika> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu>, <20090801114607.GB5782@adamantix.org>, <20090806204253.GY13769@baltika> Message-ID: <4A7BF249.13966.270A8B8@pageexec.freemail.hu> On 6 Aug 2009 at 21:42, Adrien Kunysz wrote: > On Sat, Aug 01, 2009 at 01:46:07PM +0200, Peter Busser wrote: > > A secure system is one which is implemented to EXACTLY fit its specification, > > nothing more, nothing less. > > Then we are back to "all bugs are security bugs and there is no point in > trying to make any distinction". except we don't live in a black and white world. 'security bug' or heck, just 'bug' is not a binary property, there're many shades of grey in what exactly the bug accomplishes. it's clearly not enough to state that 'this commit fixes something but i did not want to bother to understand what', users of said commits need more information than that. fortunately not all developers share linus' mindset although their efforts are sometimes in vain when what he commits intentionally omits security relevant information. > Linus is obviously not interested in trying to make the distinction, even if he was, he's not qualified to do that so it's a moot point. but he can and should encourage active research because of his position instead of downplaying the issue or outright biting the proverbial hand that feeds him/them. From apconole at yahoo.com Fri Aug 7 13:41:09 2009 From: apconole at yahoo.com (Aaron) Date: Fri, 7 Aug 2009 10:41:09 -0700 (PDT) Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <4A7BF249.13966.270A8B8@pageexec.freemail.hu> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu>, <20090801114607.GB5782@adamantix.org>, <20090806204253.GY13769@baltika> <4A7BF249.13966.270A8B8@pageexec.freemail.hu> Message-ID: <65923.86516.qm@web65408.mail.ac4.yahoo.com> > except we don't live in a black and white world. 'security bug' or heck, > just 'bug' is not a binary property, there're many shades of grey in what > exactly the bug accomplishes. it's clearly not enough to state that 'this > commit fixes something but i did not want to bother to understand what', > users of said commits need more information than that. fortunately not all > developers share linus' mindset although their efforts are sometimes in > vain when what he commits intentionally omits security relevant information. Excuse me, but no one commits fixes without understanding what they've fixed. If someone fixes a segfault/oops they might not have done the investigation to determine whether or not something is theoretically or practically usable for something nefarious, but they understand that there was a null pointer dereference, or an invalid lock condition and they removed that problem. The 'shades of grey' only exist to security people. To no one else is it important that a bug disclose information, allow invalid root access, or escalate privileges. So the point still stands, why burden the average kernel developer/debugger to do security research work for the security researcher? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090807/87763840/attachment.htm From aoz.syn at gmail.com Fri Aug 7 23:17:54 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 7 Aug 2009 21:17:54 -0600 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <65923.86516.qm@web65408.mail.ac4.yahoo.com> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> <20090801114607.GB5782@adamantix.org> <20090806204253.GY13769@baltika> <4A7BF249.13966.270A8B8@pageexec.freemail.hu> <65923.86516.qm@web65408.mail.ac4.yahoo.com> Message-ID: <4255c2570908072017k744b4a62p273246c2f1ab503b@mail.gmail.com> On Fri, Aug 7, 2009 at 11:41, Aaron wrote: > The 'shades of grey' only exist to security people. To no one else is it > important > that a bug disclose information, allow invalid root access, or escalate > privileges. Rather, 'shades of grey' only exist to critical thinkers who actually understand the problems. If you really think privilege escalation and information disclosure are esoteric problems that should be relegated only to "security people", I know a few thousand non-security system administrators that would like you to stop whatever you're doing and go flip burgers. Pretending that there is no such thing as a security bug is a childish pretense and is the equivalent of closing your eyes and assuming nobody's there because you can't see them. > So the point still stands, why burden the average kernel developer/debugger > to do > security research work for the security researcher? Because, although rather vocal, researchers compose a numerically insignificant subset of the security "industry". The vast majority are sysadmins, engineers, and programmers that need to prioritize fixes based not only on functionality but on exposure as well. The expectation is not for kernel developers to perform ad-nauseum security analysis of bugs, but for them to exercise due diligence and not suppress security information. From dave at immunityinc.com Sat Aug 8 16:19:27 2009 From: dave at immunityinc.com (dave) Date: Sat, 08 Aug 2009 16:19:27 -0400 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <4255c2570908072017k744b4a62p273246c2f1ab503b@mail.gmail.com> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> <20090801114607.GB5782@adamantix.org> <20090806204253.GY13769@baltika> <4A7BF249.13966.270A8B8@pageexec.freemail.hu> <65923.86516.qm@web65408.mail.ac4.yahoo.com> <4255c2570908072017k744b4a62p273246c2f1ab503b@mail.gmail.com> Message-ID: <4A7DDDCF.7010200@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Normally I would, of course, kill this thread, but there's lots of the Linux Kernel/Vendor security community subscribed to the list, and I think it's important for them to hear the story. Right now, Linux kernel security is 5 years behind Windows. There's just no leadership on the issue - and it doesn't have to come from Linus Torvalds or the development leadership. Partially, Linus is right - there really is no way to have developers truly know the security ramifications of every change they commit or every bug they fix. But on the other hand, the GRSecurity team and others have shown that for very little additional investment, one small team of good people (throw a half million USD a year at it and be amazed at the results!), the Linux community could be vastly benefited. Modern software development DOES have to incorporate a security model, and Linux is no exception if it wants to be successful. It's always hard for security vendors to learn the lesson from Andrew Cushman about how to handle security researchers. Quite literally, no matter how much security researchers piss you off, you have to embrace and extend their efforts and their community. It's the only way. Every other way, from Denial, to Legal Threats, to Massive PR Effort, just results in continued failure. If a Linux kernel developer suspects their patch has security relevance, and deliberately hides that in their commit message, they are in the Denial phase. The fact that people can be mean when they point that out doesn't change the real failure. In this case, the best move for Linux as a whole is to develop a security center of excellence, possibly hosted somewhere where multiple vendors can contribute to it, and work together to help with Linux's (kernel) security problems. They can start by going through new kernels and pointing out which changes may be security relevant, while training up key Linux developers on modern security techniques. Otherwise it's just not a fair fight. I do so love a fair fight. :> - -dave RB wrote: > On Fri, Aug 7, 2009 at 11:41, Aaron wrote: >> The 'shades of grey' only exist to security people. To no one else is it >> important >> that a bug disclose information, allow invalid root access, or escalate >> privileges. > > Rather, 'shades of grey' only exist to critical thinkers who actually > understand the problems. If you really think privilege escalation and > information disclosure are esoteric problems that should be relegated > only to "security people", I know a few thousand non-security system > administrators that would like you to stop whatever you're doing and > go flip burgers. Pretending that there is no such thing as a security > bug is a childish pretense and is the equivalent of closing your eyes > and assuming nobody's there because you can't see them. > >> So the point still stands, why burden the average kernel developer/debugger >> to do >> security research work for the security researcher? > > Because, although rather vocal, researchers compose a numerically > insignificant subset of the security "industry". The vast majority > are sysadmins, engineers, and programmers that need to prioritize > fixes based not only on functionality but on exposure as well. The > expectation is not for kernel developers to perform ad-nauseum > security analysis of bugs, but for them to exercise due diligence and > not suppress security information. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkp93c8ACgkQtehAhL0ghergKACfYBZs1tJR+FKhk8Obw00fPGqB XzgAn04/qqbyl23yTBYGLlEc41r5mR/E =TPTv -----END PGP SIGNATURE----- From shane at security-objectives.com Sat Aug 8 21:15:09 2009 From: shane at security-objectives.com (Shane Macaulay) Date: Sat, 08 Aug 2009 18:15:09 -0700 Subject: [Dailydave] Security people are leaches. [sic] In-Reply-To: <4A7DDDCF.7010200@immunityinc.com> References: <4A6E33B4.30180.252B77B7@pageexec.freemail.hu> <20090801114607.GB5782@adamantix.org> <20090806204253.GY13769@baltika> <4A7BF249.13966.270A8B8@pageexec.freemail.hu> <65923.86516.qm@web65408.mail.ac4.yahoo.com> <4255c2570908072017k744b4a62p273246c2f1ab503b@mail.gmail.com> <4A7DDDCF.7010200@immunityinc.com> Message-ID: <4A7E231D.9040903@security-objectives.com> One idea I had for handling this issue is to train some baysiean classifier's on to all of the given bug's identified for any OSS (this is the fix set). Definitely you could also have a super set of all/any bug you can find, but the benefit of training against the self-similar coding style of some codebase would increase the hit rate. What would be handy, is to retroactively process the commit logs for every line of code, you can then identify the crappy dev's from the not-so-crappy or maybe the just-crappy-close-to-shipcommit dev's (OSS ship = when everyone else in my project says so :). Granted this would not get all security bugs and it will not even get all of anything, except for all that itself finds (hah), but you would be able to identify historically dodgy claims. You could go on to assign security impact ratings to source commits and identify the relative "secureness" of some set of code. You could surely find bugs by using this approach, you would need to modify the strategy a bit. So if we are already training on all "known" security fixes, these will likely be highly uniform in their structure (by the way, would treat the data as opaque really, only leveraging lines added/removed and combinations of that), these are the commits which will be under heavy public scrutiny, as such the dev in question would typically work hard to isolate the exact problem and fix only this 1 issue (fearing high regression or being accused of sitting on a security issue long enough to slip in 1 more feature!). To find future bugs, your going to have to do some root cause failure analysis, which is super easy in this case, by implementing a historyflow ((the best looking :) http://benfry.com/revisionist/, http://www.research.ibm.com/visual/projects/history_flow/, http://sourceforge.net/projects/historyflow/) engine. You can then go from fix (which is present day fact), back to original developer feature, this feature set (heh), looks to the future for bugs in OSS software (this is at the end of the day, the more "fun" work for security people, not arguing semantics with specification jock's (not sec ppl)), given that you can't have too much fun, the work part (or maybe the part to charge $ for), is the fix rater. You can then track the relative need or requirement for businesses to fix a bug in any given OSS codebase. Surely the other metrics are fun and interesting, like who copies who and who the top-worst/best developers are (real world, not some contrived coding competition) no doubt would make some great marketing. Give out all your data 3-6 months retroactively so nobody calls you a liar and sell current data. Seems like some COTS mashup would go far here to get results, I bing'd, citeseer'd and google'd around'd for a minute, did not really find too much of an attempt to do this in any serious way, frankly I'm shocked. I could go on, but really, security is not something for developers to play with, just like features are not something that security people should be playing with. Stay in your own sand box and we can all just get along. Given you can do one or the other, not both, any attempt to do so is an inherent conflict of interest which means that neither interest is being served (i.e. the bias will undo and waste any such effort). Stopping myself from going on now. Shane dave wrote: > Normally I would, of course, kill this thread, but there's lots of the > Linux Kernel/Vendor security community subscribed to the list, and I > think it's important for them to hear the story. Right now, Linux kernel > security is 5 years behind Windows. There's just no leadership on the > issue - and it doesn't have to come from Linus Torvalds or the > development leadership. > > Partially, Linus is right - there really is no way to have developers > truly know the security ramifications of every change they commit or > every bug they fix. But on the other hand, the GRSecurity team and > others have shown that for very little additional investment, one small > team of good people (throw a half million USD a year at it and be amazed > at the results!), the Linux community could be vastly benefited. Modern > software development DOES have to incorporate a security model, and > Linux is no exception if it wants to be successful. > > It's always hard for security vendors to learn the lesson from Andrew > Cushman about how to handle security researchers. Quite literally, no > matter how much security researchers piss you off, you have to embrace > and extend their efforts and their community. It's the only way. Every > other way, from Denial, to Legal Threats, to Massive PR Effort, just > results in continued failure. If a Linux kernel developer suspects their > patch has security relevance, and deliberately hides that in their > commit message, they are in the Denial phase. The fact that people can > be mean when they point that out doesn't change the real failure. > > In this case, the best move for Linux as a whole is to develop a > security center of excellence, possibly hosted somewhere where multiple > vendors can contribute to it, and work together to help with Linux's > (kernel) security problems. They can start by going through new kernels > and pointing out which changes may be security relevant, while training > up key Linux developers on modern security techniques. > > Otherwise it's just not a fair fight. I do so love a fair fight. :> > > -dave > > RB wrote: > > On Fri, Aug 7, 2009 at 11:41, Aaron wrote: > >> The 'shades of grey' only exist to security people. To no one else > is it > >> important > >> that a bug disclose information, allow invalid root access, or escalate > >> privileges. > > Rather, 'shades of grey' only exist to critical thinkers who actually > > understand the problems. If you really think privilege escalation and > > information disclosure are esoteric problems that should be relegated > > only to "security people", I know a few thousand non-security system > > administrators that would like you to stop whatever you're doing and > > go flip burgers. Pretending that there is no such thing as a security > > bug is a childish pretense and is the equivalent of closing your eyes > > and assuming nobody's there because you can't see them. > > >> So the point still stands, why burden the average kernel > developer/debugger > >> to do > >> security research work for the security researcher? > > Because, although rather vocal, researchers compose a numerically > > insignificant subset of the security "industry". The vast majority > > are sysadmins, engineers, and programmers that need to prioritize > > fixes based not only on functionality but on exposure as well. The > > expectation is not for kernel developers to perform ad-nauseum > > security analysis of bugs, but for them to exercise due diligence and > > not suppress security information. > > _______________________________________________ > > Dailydave mailing list > > Dailydave at lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From dave at immunityinc.com Mon Aug 10 23:29:07 2009 From: dave at immunityinc.com (dave) Date: Mon, 10 Aug 2009 23:29:07 -0400 Subject: [Dailydave] Two things your grandchildren will never read: Newspapers, and "Proceedings" Message-ID: <4A80E583.5060106@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's when you need sleep the most that you can't sleep. But the following twitter does make it worth it: spendergrsec: "It's like 8 pages documenting a team of 6 people's first exploit": http://bit.ly/grcUz Go read and enjoy. There's many institutions the Internet is going to destroy. Of all of them, perhaps Academia is going the quietest. Every time someone posts about the "Proceedings" of something, or a "peer reviewed journal" or posts a bibliography of a paper-bound book, it's like hearing the rasping sighs of the last dieing brontosaurus. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkqA5YMACgkQtehAhL0gheprjACfZsGtCbLr+sdEXbyJJQkjjQnt LCYAn1AVFpfnVGe4Bj9G5CuBhSwVi+d8 =bAvr -----END PGP SIGNATURE----- From eugeneteo at kernel.sg Mon Aug 10 23:33:16 2009 From: eugeneteo at kernel.sg (Eugene Teo) Date: Tue, 11 Aug 2009 11:33:16 +0800 Subject: [Dailydave] Security people are leaches. [sic] Message-ID: <28fa9c5e0908102033j45910dedu41e74652529fca52@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello pipacs, > also one cannot help but smile at the irony of divineint (put in charge of security > at RH, no less ;) asking for more proper disclosure. how times change ;). Heads up, I am not divineint, never was. Thanks, Eugene -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqAxAQACgkQ6oTGoljfiCOwRACfaPG6oUL8ZuULnoRFX5iJ/xxK Un4AoJ39ck2tYaNo3/fF7ZSjXS9Tlp5C =5mnf -----END PGP SIGNATURE----- From lists at robertlemos.com Tue Aug 11 09:34:13 2009 From: lists at robertlemos.com (Robert Lemos) Date: Tue, 11 Aug 2009 09:34:13 -0400 Subject: [Dailydave] Two things your grandchildren will never read: Newspapers, and "Proceedings" In-Reply-To: <4A80E583.5060106@immunityinc.com> References: <4A80E583.5060106@immunityinc.com> Message-ID: <8BFF826D-96B1-44A4-BEEE-CDC3AD29B6A7@robertlemos.com> On Aug 10, 2009, at 11:29 PM, dave wrote: > * PGP Signed by an unknown key > > It's when you need sleep the most that you can't sleep. But the > following twitter does make it worth it: > > spendergrsec: "It's like 8 pages documenting a team of 6 people's > first > exploit": http://bit.ly/grcUz > > Go read and enjoy. > > There's many institutions the Internet is going to destroy. Of all of > them, perhaps Academia is going the quietest. Every time someone posts > about the "Proceedings" of something, or a "peer reviewed journal" or > posts a bibliography of a paper-bound book, it's like hearing the > rasping sighs of the last dieing brontosaurus. Them's fighting words, Dave. I agree that neither will continue to exist in their current forms, but I would also argue that both are trying to bring some level of authentication/trust to the reporting of research -- a feature of peer review and newspapers that should survive, even when the monopoly does not. (In our own industry, Full-Disclosure versus Bugtraq is a good example of the options.) So I hope the end result is that we get the benefits of peer review without the drawbacks of monopoly (although, one could argue that peer review is inherently a monopoly-creating activity). There was an interesting interview on future of newspapers recently that covered some of this. I blogged about it yesterday: http://robertlemos.typepad.com/writingmachines/2009/08/journalism-is-an-artifact-of-the-printingpress-monopoly.html Cheers, -R robert lemos | mail at robertlemos.com | skype: rob.lemos science & technology journalist | http://www.robertlemos.com From arr at watson.org Tue Aug 11 10:25:01 2009 From: arr at watson.org (Andrew R. Reiter) Date: Tue, 11 Aug 2009 10:25:01 -0400 (EDT) Subject: [Dailydave] Two things your grandchildren will never read: Newspapers, and "Proceedings" In-Reply-To: <4A80E583.5060106@immunityinc.com> References: <4A80E583.5060106@immunityinc.com> Message-ID: I have to disagree in the sense that we should distinguish between conference proceedings and peer-reviewed journals. I think you're very much correct about proceedings and what's happening, but I think we can't say as much about the journals. Though, to support your statements, one should look at this little shared bit of logic: http://cis.jhu.edu/publications/papers_in_database/GEMAN/Ten_Reasons.pdf "Ten Reasons Why Conference Papers Should Be Abolished" Cheers, Andrew -- Andrew R. Reiter arr at watson.org On Mon, 10 Aug 2009, dave wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It's when you need sleep the most that you can't sleep. But the > following twitter does make it worth it: > > spendergrsec: "It's like 8 pages documenting a team of 6 people's first > exploit": http://bit.ly/grcUz > > Go read and enjoy. > > There's many institutions the Internet is going to destroy. Of all of > them, perhaps Academia is going the quietest. Every time someone posts > about the "Proceedings" of something, or a "peer reviewed journal" or > posts a bibliography of a paper-bound book, it's like hearing the > rasping sighs of the last dieing brontosaurus. > > > - -dave > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkqA5YMACgkQtehAhL0gheprjACfZsGtCbLr+sdEXbyJJQkjjQnt > LCYAn1AVFpfnVGe4Bj9G5CuBhSwVi+d8 > =bAvr > -----END PGP SIGNATURE----- > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From nicolas at immunitysec.com Thu Aug 13 16:53:50 2009 From: nicolas at immunitysec.com (Nicolas Waisman) Date: Thu, 13 Aug 2009 17:53:50 -0300 Subject: [Dailydave] EkoParty Reverse & Go challenge Message-ID: <4A847D5E.4060406@immunitysec.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The EkoParty Reverse && GO challenge #################################### Porque? ####### Don't have a ticket to EkoParty (EkoParty.org) yet? Don't Worry! The EkoParty organizers and Immunity, Inc. (immunityinc.com) would like to invite you to take part in the "Reverse && GO" challenge. The first five people to complete the challenge will obtain official tickets for EkoParty 2009, which takes place September 17-18, in beautiful Buenos Aires, Argentina. Como? ##### The Reverse & GO challenge consists of two significant parts: * Reversing: Immunity will give you a binary, that will contain at least one bug. Your job is to find the bugs, and crash the software to then determine its security impact. * Reporting: Write a simple advisory, include an introduction, how you found the bug, detailed information about the vulnerability, attack scopes, a proof of concept exploit (including source code) and a recommended solution to the problem. Donde? ###### The target binary is a simple win32 executable (with full symbols) that parses XML files. Run it without arguments and it will read a file called "immunity.xml" from the current working directory. You can download the binary here: http://www.immunityinc.com/downloads/immunity.zip Criterios ######### * Number of bugs found (there might be more than one!) * Bug originality * Understanding of the vulnerability * Clarity of advisory Plazo ##### The challenge deadline is the 1st of September. The winners will be announced the 7th of September on EkoParty.org. Send your results to argentina at immunityinc.com. For any questions and comments regarding EkoParty, please visit EkoParty.org, for any questions and comments regarding the Reverse && GO challenge please contact argentina at immunityinc.com Happy hunting! for more information: http://immunityinc.com/contest-en.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqEfVwACgkQnx8KWzmcRsGQ/QCfTD4dwrpCsdh/8b57VKTcG4mY fMEAn0yqtgQKXh5A12zeqaNtCxEq2NxS =mMxO -----END PGP SIGNATURE----- From dan at geer.org Thu Aug 13 13:40:32 2009 From: dan at geer.org (dan at geer.org) Date: Thu, 13 Aug 2009 13:40:32 -0400 Subject: [Dailydave] Two things your grandchildren will never read: Newspapers, and "Proceedings" In-Reply-To: Your message of "Mon, 10 Aug 2009 23:29:07 EDT." <4A80E583.5060106@immunityinc.com> Message-ID: <20090813174032.E597A33F3C@absinthe.tinho.net> Dave, This seems germane to the thread http://www.consortiuminfo.org/bulletins/jun09.php#considerthis --dan From robert_david_graham at yahoo.com Wed Aug 12 19:47:26 2009 From: robert_david_graham at yahoo.com (Robert Graham) Date: Wed, 12 Aug 2009 16:47:26 -0700 (PDT) Subject: [Dailydave] parsers fall down go boom? In-Reply-To: <20090806211340.GE17084@tracyreed.org> Message-ID: <514229.18967.qm@web51005.mail.re2.yahoo.com> The problem isn't in parsers themselves so much as people don't recognize the danger. It's like how hunting is a safer sport than skiing -- sure, guns are more dangerous than skis, but hunters tend to respect the danger and change their behavior accordingly. When you are working on a parser, you need to be paranoid and think to yourself that this is an inherently dangerous piece of code and that you need to take extra precautions. Better yet, you need to rethink what you are doing and do it in a completely different way. For example, writing parsers as "state-machines" is inherently safer than the normal way. Better yet, write parsers in an even higher level language, such as Java. People avoid safer languages like Java because they want speed. However, a carefully written parsing state-machine written in Java will typically outperform the normal way of writing parsers in C. More importantly, don't trust third parties. Most parsers are not written from the ground up, but are instead licensed or copied from other parties. That's why the same vulnerable unpacking code shows up in multiple competing anti-virus vendors. Lastly, most parsing errors are not in the parsers themselves, but in some deeper part of the code that reads parsed data. It's like how HTML forms do not filter quotes, which can then be passed to SQL queries to cause injections. It's like the how the MS-RPC parsing code happily passed a buffer to some deeper code that assumed a machinename would never be more than 16-characters, thus leading to the Blaster bug. Paranoid parser writers should therefore consider handling common problems themselves. For example, if the output of the parser might eventually appear on a webpage, maybe they should deal with the "less-than < <" stuff themselves instead of relying upon some other part of the code doing the right thing. --- On Thu, 8/6/09, Tracy Reed wrote: > From: Tracy Reed > Subject: Re: [Dailydave] parsers fall down go boom? > To: "dave" > Cc: dailydave at lists.immunityinc.com > Date: Thursday, August 6, 2009, 2:13 PM > On Thu, Aug 06, 2009 at 03:36:40PM > -0400, dave spake thusly: > > Lemme tell you, there's nowhere a hacker would rather > be than on > > your WAF. If for no other reason than the irony, > because hackers > > have good senses of humour. > > I have been wondering about this very thing. NIDS don't > bother me so > much because it is usually on a mirror port and not really > directly in > the flow of things. A little harder to get ahold of and > less > useful. But a WAF...that's a different story. And things > like PCI-DSS > 6.6 require code review (expensive and a pain) OR a WAF > (which nearly > everyone chooses). I have never liked to deploy WAFs > instead > preferring to attempt to write more secure code although > defense-in-depth etc can't hurt. But I have actually heard > webapp > developers use the WAF as a crutch ("Learn parameterized > queries? But > we have a WAF!"). > > -- > Tracy Reed > http://tracyreed.org > > -----Inline Attachment Follows----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From marco.ermini at gmail.com Wed Aug 12 03:57:19 2009 From: marco.ermini at gmail.com (Marco Ermini) Date: Wed, 12 Aug 2009 09:57:19 +0200 Subject: [Dailydave] Two things your grandchildren will never read: Newspapers, and "Proceedings" In-Reply-To: <4A80E583.5060106@immunityinc.com> References: <4A80E583.5060106@immunityinc.com> Message-ID: <90691a990908120057h5c91cae7q1a3baead0157a4aa@mail.gmail.com> 2009/8/11 dave: [...] > There's many institutions the Internet is going to destroy. Of all of > them, perhaps Academia is going the quietest. Every time someone posts > about the "Proceedings" of something, or a "peer reviewed journal" or > posts a bibliography of a paper-bound book, it's like hearing the > rasping sighs of the last dieing brontosaurus. [...] I don't see anything wrong with this paper. Looks like it's a good piece of education for novices. If only academias where so useful in Italy... :-) but none of this is explained in many, many Universities and computer programmed are on their own about security, before and after graduation. By the way, looks like some newspaper like the Seattle Times, are gaining back popularity, since they have cut on not useful staff and invested on local and inquiry journalism. The distribution media may change, but inquiry journalism is needed now more than before, and it is demonstrated that, ironically, the increased availability of information does not automatically increase its quality - quite the contrary, it is more difficult than before to find good quality information, since we are submerged with crap and the only allowed journalists are "embedded", and not only in wars... For instance, who knows that the suburbs of Paris are under riots since two days? no "major" (cnn, fox, bbc, etc.) media reports it. But, it was diffused by authoritative agencies like Associated Press. I personally learned it through my company's travel service that was advising about travelling to Paris. Did some research, and found it mainly on Al Jazeera... today looks like there is better coverage, but still nothing on cnn or bbc. This blog post: http://www.powerlineblog.com/archives/2009/08/024243.php makes a good point. I don't know if newspaper will disappear, but I think we need them more than ever. At least the good ones, and look like there are examples of business cases where you can really make a profit if you decide to stop being the usual reprint-from-agencies and really do your investigations. Cheers -- Marco Ermini root at human # mount -t life -o ro /dev/dna /genetic/research http://www.linkedin.com/in/marcoermini "Jesus saves... but Buddha makes incremental back-ups!" From auto793094 at hushmail.com Fri Aug 14 05:37:28 2009 From: auto793094 at hushmail.com (auto793094 at hushmail.com) Date: Fri, 14 Aug 2009 09:37:28 +0000 Subject: [Dailydave] RSA Conference in San Francisco Message-ID: <20090814093728.88D7AB0048@smtp.hushmail.com> I was wondering what people thought about the RSA Conference that is held annually in San Francisco. It's an unbelievably expensive conference and as far as I can tell, it's a shit con with basically no useful security content. Can anybody remember even a single useful presentation to ever come out of RSA? From dan at geer.org Fri Aug 14 19:19:25 2009 From: dan at geer.org (dan at geer.org) Date: Fri, 14 Aug 2009 19:19:25 -0400 Subject: [Dailydave] RSA Conference in San Francisco In-Reply-To: Your message of "Fri, 14 Aug 2009 09:37:28 -0000." <20090814093728.88D7AB0048@smtp.hushmail.com> Message-ID: <20090814231925.D773733EC2@absinthe.tinho.net> auto793094 at hushmail.com writes: -+----------------------------- | I was wondering what people thought about | the RSA Conference that is held annually | in San Francisco. | | It's an unbelievably expensive conference | and as far as I can tell, it's a shit con | with basically no useful security content. | | Can anybody remember even a single useful | presentation to ever come out of RSA? | it's a trade show --dan From arunkoshy at gmail.com Sat Aug 15 00:41:48 2009 From: arunkoshy at gmail.com (Arun Koshy) Date: Sat, 15 Aug 2009 14:41:48 +1000 Subject: [Dailydave] [ proof checking ] [ safer software ] [???] Message-ID: <1d0ba3070908142141me2b1b68pcdb5598e49245cd1@mail.gmail.com> check : http://ertos.nicta.com.au/research/l4.verified/ media etc : http://www.theengineer.co.uk/Articles/312631/Safer+software.htm Of course, the work is based on a set of interesting assumptions and fairly delimited universe ( given the understandable need to restrict scope ). Comments anyone ? From spender at grsecurity.net Fri Aug 14 14:53:06 2009 From: spender at grsecurity.net (Brad Spengler) Date: Fri, 14 Aug 2009 14:53:06 -0400 Subject: [Dailydave] Mr. Magorium's Wunderbar Emporium Message-ID: <20090814185306.GA11452@grsecurity.net> For those who have been living under a rock for the past two days, an exploit exists for Julien Tinnes/Tavis Ormandy's sendpage vulnerability in all Linux kernels since 2001. My exploit works on 2.4, 2.6, x86, x64, 4k stacks, 8k stacks, with/without cred framework, bypasses mmap_min_addr in any public way possible (auto-detecting which method to use). As always, while in ring0 it provides the added convenience of disabling auditing, SELinux, AppArmor, and all other LSM modules. If SELinux is enforcing, it will also rewrite the SELinux code to fool userland into thinking it remains in enforcing mode. And if the machine supports it, it'll play a nice video for you in your terminal. See http://www.youtube.com/watch?v=arAfIp7YzZ4 for a demo. I wanted to implement a more interactive sense of russian roulette in the exploit, with a randomly-generated 1 in 6 chance of hot rebooting the machine into FreeDOS (first exploit to reboot you into a secure operating system) but I don't have time -- I'm off to Miami! "Congrats" Linus on screwing over all the vendors and every Linux user by forcing disclosure of the bug before vendors could ship out updated kernels. Your patch applies well to their binary packages. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090814/ae037e5d/attachment.pgp From deepsec at deepsec.net Sat Aug 15 09:38:48 2009 From: deepsec at deepsec.net (DeepSec Conference) Date: Sat, 15 Aug 2009 15:38:48 +0200 (CEST) Subject: [Dailydave] DeepSec 2009 - Preliminary Schedule is online Message-ID: <20090815133848.365CAD010D24@majere.luchs.at> == DeepSec In-Depth Security Conference 2009 ?TripleSec? == The third DeepSec conference is taking place between 17th and 20th November at the Imperial Riding School Renaissance Hotel. The in-depth security conference will include two days of security talks during the conference and two days of trainings, covering the latest topics in network and IT security. There will be also a comprehensive social program around the event, including a dinner for speakers on the first day of the conference and a social event for selected guests of DeepSec 2009. == Sponsors == We would like to thank our sponsors that have supported the conference: Microsoft, Sourcefire, Global Knowledge, The British Bookshop, Viennese Chamber of Commerce == Topics & Speakers == We have published a preliminary schedule which can be found on our web site: https://deepsec.net/schedule/ The topics include social engineering, security of the GSM air interface, design of secure protocols, physical security, Web 2.0, exploit/malware analysis & design, security awareness, abusing device drivers, #twitter risks, attacks on smart-card secured online banking, security risks and defence for developers, advanced database exploits, abusing firmware, security analysis of the TCP & IP protocols, key management, incident response, e-voting, advanced keyboard sniffing, malware for routers, large-scale network attack simulation, cloud computing, next generation intrusion detection/prevention, among others. We also show a demonstration of an DoS attack against a GSM network by means of a phone with modified firmware. == About DeepSec == DeepSec IDSC is an annual European two-day in-depth conference on computer, network, and application security. The DeepSec Conference will be held from November 17th to 20th 2009 in Vienna, and aims to bring together the world's leading security professionals from academics, government, industry, and the underground hacking community. In addition to the conference with presentations we will offer a selection of two-day intense security training courses before the main conference. DeepSec is a non-product, non-vendor-biased conference. Our aim is to present the best research and experience from the fields' leading experts. Target Audience: Security Officers, Security Professionals and Product Vendors, IT Decision Makers, Policy Makers, Security-, Network-, and Firewall Administrators, Teachers, Academic Researchers and Software Developers. The last conference has been attended by: Ericsson, Commerzbank, Philips, RBT, GRZ IT, IERN Sierra Leone, SAP, Improware, Telekom Austria, Microsoft, BAWAG, T-Systems, Iphos, Sektion Eins, T-Mobile, Red Hat, SWITCH, Austrian National Bank, Daimler, Sentrigo, University of Vienna, SEC Consult, Tech Data, S21Sec, DHL, Bearing Point, Cygnos, wecon, YCO, Rolex SA, Austrian National Bank, US Army, Fraunhofer Institut, Kapsch CarrierCom AG, IronPort, Cisco, SonyDADC, T?V Austria, Telecom Italia, Vodafone, Siemens, BAWAG, CheckPoint, DHL, and many others. Best regards, DeepSec In-Depth Security Conference organisation team: Michael Kafka, DeepSec GmbH Ren? Pfeiffer, DeepSec GmbH Initiated by Paul B?hm, DeepSec GmbH Contact: https://deepsec.net/contact/ From nate at root.org Sun Aug 16 12:25:30 2009 From: nate at root.org (Nate Lawson) Date: Sun, 16 Aug 2009 09:25:30 -0700 Subject: [Dailydave] RSA Conference in San Francisco In-Reply-To: <20090814231925.D773733EC2@absinthe.tinho.net> References: <20090814231925.D773733EC2@absinthe.tinho.net> Message-ID: <4A8832FA.6050904@root.org> dan at geer.org wrote: > auto793094 at hushmail.com writes: > -+----------------------------- > | I was wondering what people thought about > | the RSA Conference that is held annually > | in San Francisco. > | > | It's an unbelievably expensive conference > | and as far as I can tell, it's a shit con > | with basically no useful security content. > | > | Can anybody remember even a single useful > | presentation to ever come out of RSA? > | > > it's a trade show Yes. It also has a split past. The original RSA conference that started in 1991 was a lot more like CRYPTO. There were academic papers on various crypto-related subjects with the traditional peer review. The other part is an IT security trade show. It's probably the largest gathering of vendors of security products. The talks for this audience are more oriented to CISSP. While both tracks are still present, the two don't mix. It's like two separate conferences in one location. I've given two talks at RSA: "Designing and Attacking Virtual Machines" (2004) and "Copy Protection Wars: Analyzing Retro and Modern Schemes" (2007). My main motivation was that my company was going to be there anyway, and these seemed like fun topics to try out, slightly off the beaten path. I got mixed reviews. Half the people said they enjoyed the break from yet another IT talk, and half said it wasn't relevant to them. -- Nate From no-reply at ekoparty.com.ar Mon Aug 17 06:54:37 2009 From: no-reply at ekoparty.com.ar (ekoparty staff) Date: Mon, 17 Aug 2009 07:54:37 -0300 Subject: [Dailydave] ekoparty Security Conference 2009 Announcements Message-ID: [*] ekoparty Security Conference and Trainings - 5th edition [*] www.ekoparty.org Trainings: September 14-16 / Conference: September 17-18, 2009 Ciudad Autonoma de Buenos Aires, Argentina [*] WHAT? ekoparty is a one-of-a-kind event in South America; an annual security conference held in Buenos Aires where security specialists from all over Latin America (and beyond) have the chance to get involved with state-of-art techniques, vulnerabilities and tools in a relaxed environment which has not been seen before. The fifth edition of ekoparty is expected to bring together over 500 security specialists from around the world in the most deep-knowledge technical conference of Latin America. This is not just a completely technical conference, it also has a lot of fun activities like lockpicking village organized by TOOOL, wardriving, CTF wargame, demoparty, after hours and even a awesome aftercon party!. On this edition we are going to have simultaneous translation of all the lectures offering the chance to attendies from foreign countries to understand spanish and portuguese speakers as well locals to understand english spoken talks. [*] Registration is now OPEN We are glad to announce that the registration to the event is now open! You can sign up for the 5th edition of ekoparty at http://www.ekoparty.org/en/registracion.html Remember that early registered assistants have a big discount on the price! If you are comming from outside Buenos Aires we can assist you in all we can for making your travel easier (i.e. find a hotel). Don?t hesitate in contacting us at organizacion [ AT ] ekoparty.org We hope to see you in this year edition :) [*] SPEAKERS Alfredo Ortega/Anibal Sacco: Deactivate The Rootkit Cesar Cerrudo: Opening Intranets to attacks by using Internet Explorer Charlie Miller: iPhone Hacking: Fuzzing and Payloads Chema Alonso: Connection String Attacks Deviant Ollam: Ten Things Everyone Should Know About Lockpicking & Physical Security Leonardo Nve: Playing in a Satellite environment 1.2 Luis Miras: Attacking SMS Moxie Marlinspike: More Tricks For Defeating SSL In Practice Nicol?s Economou: Applied Heuristics to Binary Diffing Philippe Langlois: SCCP hacking, attacking the SS7 & SIGTRAN applications one step further and mapping the phone system Sebasti?n N. Fernandez: POSIX Meterpreter *more lectures TBA [*] TRAININGS Breaking Windows, Damian Gomez (Immunity) COMBAT Training (NINJA edition), Leonardo Pig?er (BASE4 Security) Evaluating Secure Protocols and Intercepting Secure Communication, Moxie Marlinspike Hacking and Defending Oracle Databases, Esteban Mart?nez Fay? (ARGENISS) Lockpicking & Physical Security - from novice to master in one day, Deviant Ollam (TOOOL) Programing shellcodes from scratch, Pablo Sol? (Immunity) Blind Injection techniques on Web Applications, Chema Alonso (Inform?tica 64) Web Testing & Exploiting Workshop, Andr?s Riancho (Bonsai) [*] PRE-CONFERENCE CTF This year the CTF is going to be run by Bonsai-sec & Netifera as a warm-up the setup a 3 day CTF The pre-conference CTF game starts on Aug 17, 13:37 and ends Aug 21 13:37 (GMT-3). More information: http://ctf.ekoparty.org [*] WHEN? August 17 Pre-conference CTF opens August 21 Pre-conference CTF closes August 24 End of Early Bird Ticket Price September 14-16 - ekoparty Trainings September 17-18 - ekoparty Conference [*] GET IN TOUCH Website http://www.ekoparty.org Blog http://blog.ekoparty.org Mailing-list http://groups.google.com/group/ekoparty Twitter https://twitter.com/ekoparty Best regards, ekoparty security conference staff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090817/8eff006b/attachment.htm From dave at immunityinc.com Mon Aug 17 18:08:10 2009 From: dave at immunityinc.com (dave) Date: Mon, 17 Aug 2009 18:08:10 -0400 Subject: [Dailydave] More offensive security metrics and you Message-ID: <4A89D4CA.8010900@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I've spent my time on planes recently trying to figure out a metric for something a bit soft. I've noticed that there comes a point where a hacker has been in a system for X number of days, reading emails, learning about things, where it's not going to be possible to keep them out. There's a certain set of things they know that give them an infinite edge over the defence. This needs to be a hacker with some set of analysis attached to it of course. Example things you should know after X days: 1. Active Directory structure. 1a. Purpose of various OU's 1b. Administrators and their roles 1c. relationships to other active directory forests 1d. Corporate groups 1e. History (i.e. the "why" things are set up the way they are) 2. Password policies 2a. New user default passwords 2b. Passwords enforced by anything in particular? 3. internal terminology ("Yo, the EQT just exceeded our TOL - did you fill out a ETM for that?") 4. Backup programs, patching programs. 5. How tech support calls work 6. Intranet web apps users use. 7. Overall network layout and FW policies. etc. etc. I know there's a long list of these sorts of things, and when you have 80% of them, you can't get kicked out. Essentially, you'll have found strategic operational flaws that transcend any point-fixes the company may be able to put into place. So that's my offensive security metric of the week. :> And now, a brief message from our sponsor, Shari! ___________________________________________________________________ As a vendor at the upcoming Hacker Halted Conference in downtown Miami, FL, we are able to provide you with a special discounted registration rate of $999 (which is a $300 savings). If you are interested in attending this conference at the special discounted rate, please email admin at immunityinc.com to get the registration code needed for the discount to be applied. There are no strings or fine print attached in order to take part in this special offer. Below you will find more information about the conference. *Hacker Halted USA 2009, the 14th in the global series, will be hosted in Miami, Florida, from Sep 23 - 25. To be held at the Hilton Miami Downtown, Hacker Halted USA 2009 is set to be the perfect platform for information security professionals to enhance knowledge and exchange views, as well as network with other security professionals globally. This information security conference will feature some of the best security experts including the likes of Amit Yoran, Prof. Howard Schmidt, Dave Litchfield, Ari Takenen, Ira Winkler, Dr. Herbert H. Thompson, Ron Gula, Greg Hoglund and Edward Haletky, among others. It presents a comprehensive program comprising intriguing, thought provoking and current security topics such as Threats and Countermeasures, Virtualization Security, Computer Forensics and Investigations, Application Security and Secure Coding, Malware and Botnets, etc. There will be an exhibition showcasing the latest technologies, solutions and services in IT security as well. To make Hacker Halted USA 2009 a truly valuable conference for all attendees, EC-Council will be hosting three custom designed security workshops led by EC-Council Master Instructors. These full fledged one-day workshops on Sep 25, will cover three of the most popular security topics, namely *Identifying Threats and Deploying Countermeasures (Ethical Hacking)*; *Principles of Incident Handling*; and *Exposing Virtualization Security Threats*. All registrants for the conference will be entitled to attend one of these workshops, worth $599, at absolutely no additional cost. Presented by EC-Council, Hacker Halted has been hosted in different cities including Myrtle Beach, Dubai, Taipei, Singapore, Kuala Lumpur, Guangzhou, Mexico City, Tokyo among others. The objective of the global series of Hacker Halted conferences is to raise international awareness towards increased education and ethics in Information Security. *Hackers Are Ready. Are you?* http://www.hackerhalted.com - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkqJ1MoACgkQtehAhL0gheppAACfdd3VzMrwNjWpDSpib2i+yRmb mfQAnisJE11BYwMboTW37JAZCyYQQb49 =bVrQ -----END PGP SIGNATURE----- From dan at geer.org Mon Aug 17 23:25:36 2009 From: dan at geer.org (dan at geer.org) Date: Mon, 17 Aug 2009 23:25:36 -0400 Subject: [Dailydave] More offensive security metrics and you In-Reply-To: Your message of "Mon, 17 Aug 2009 18:08:10 EDT." <4A89D4CA.8010900@immunityinc.com> Message-ID: <20090818032536.A3ABA33C9A@absinthe.tinho.net> dave writes: -+---------- | | | I know there's a long list of these sorts of things, and when you have | 80% of them, you can't get kicked out. Essentially, you'll have found | strategic operational flaws that transcend any point-fixes the company | may be able to put into place. | Actually, it is a worthwhile goal to describe the tipping point of a penetration, the moment when, as you say, the penetrator can no longer be kicked out. I'm sure you'd like the catalog of what that takes, and you've begun it. Keep at the effort, please. I'm more interested in the rate constant -- how long does it take to reach the tipping point, is that time rising or falling, and is self-optimising automation feasible? I'm (more than) happy to measure "time" in something synthetic like clock cycles, function calls, number of training rounds, etc. I just want to know the first and second derivatives. Nothing much... --dan From jlloret at dcom.upv.es Wed Aug 19 21:55:48 2009 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Thu, 20 Aug 2009 03:55:48 +0200 Subject: [Dailydave] 2nd Call for Posters and Industrial Presentations | ComputationWorld 2009 / Athens-Greece, November 15-20, 2009 Message-ID: <200908200155.n7K1tmi1006516@smtp.upv.es> INVITATION Please consider to contribute and encourage your team members and fellow scientists to contribute to the following federated events. Thanks for forwarding the information on this Call for Posters and Industrial presentations to those potentially interested to submit. ===== Call for Posters and Industrial Presentations ======= ComputationWorld 2009, November 15-20, 2009 - Athens, Greece see: http://www.iaria.org/conferences2009/ComputationWorld09.html ComputationWorld 2009 is a federated event focusing on advanced topics concerning the areas of computation. The target topics cover future computing techniques (strategies, mechanisms, technologies), service computation (ubiquitous, web services, societal), cognitive support (AI, agents, learning, autonomy), adaptiveness (component/systems, self-features, metrics), creative content technologies, and patterns. Submission (Poster, Industrial presentations) deadline: October 1st, 2009. Acceptance notification: October 15, 2009 Submission form: 12-14 slide deck, free format; they will be posted, post-conference, at www.iaria.org. Submissions must be electronically done using the ?Submit a Paper? button on the entry page of each conference listed below. See a 'very preliminary program'. http://www.iaria.org/conferences2009/FUTURECOMPUTING09.html http://www.iaria.org/conferences2009/ProgramFUTURECOMPUTING09.html The events will feature well known Keynote Speakers: The Tempestuous Future of Computing - Every Cloud Engenders not a Storm by Paul J. Geraci, Director, TSG/DoD, USA Infrastructures and Technologies for Future Computing - Convergence of Bandwidth, Clouds, and Smart Devices by Wolfgang Gentzsch, EU Project DEISA & Board fo Directors OGF Services-- The Next Major Frontier for Research & Innovation by Krishna Singh, President, Service Research & Innovation Institute (SRII) / Strategic Programs Director, Service Science Research, IBM Almaden Research Center EXPERT PANEL: Services Computing: Challenge or Opportunity Moderators: Krishna Singh, IBM / SRII Petre Dini, IARIA / Concordia University A few access free tutorials will be provided for all participants. Scientific papers will be presented in more than 30 regular sessions. Special forum meetings on challenging topics will be organized, late, in the afternoons. We aim at some instructive Poster and Special Industrial presentations to complete the spectrum of topics covered by the events. The events are: >> FUTURE COMPUTING 2009, The First International Conference on Future Computational Technologies and Applications http://www.iaria.org/conferences2009/FUTURECOMPUTING09.html >> SERVICE COMPUTATION 2009, The First International Conferences on Advanced Service Computing http://www.iaria.org/conferences2009/SERVICECOMPUTATION09.html >> COGNITIVE 2009, The First International Conference on Advanced Cognitive Technologies and Applications http://www.iaria.org/conferences2009/COGNITIVE09.html >> ADAPTIVE 2009, The First International Conference on Adaptive and Self-adaptive Systems and Applications http://www.iaria.org/conferences2009/ADAPTIVE09.html >> CONTENT 2009, The First International Conference on Creative Content Technologies http://www.iaria.org/conferences2009/CONTENT09.html >> PATTERNS 2009, The First International Conferences on Pervasive Patterns and Applications http://www.iaria.org/conferences2009/PATTERNS09.html >> SELFTRUST 2009, The First Workshop on Computational Trust for Self-Adaptive Systems http://www.iaria.org/conferences2009/SELFTRUST.html -------------------------------- IARIA Publicity Board ComputationWorld Advisory Committees ------------------------------- From kiwicon at kiwicon.org Thu Aug 20 16:27:24 2009 From: kiwicon at kiwicon.org (Kiwicon <3) Date: Fri, 21 Aug 2009 08:27:24 +1200 Subject: [Dailydave] KIWICON ]|[ - 2009 Call For Papers Message-ID: <20090820202724.GA6708@kiwicon.org> A wise deadite captain once yelled "Cry Havoc and let loose the Dogs of War!". Quite frankly, we couldn't have said it better ourselves: ~~ ~~ || || @@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@\___ @@@@@@@@@@@@@@@@@@ \ @@@@@@@@@@@@@@@@@ X___/ \/ KIWICON ]|[ 28TH & 29TH NOVEMBER 2009 With a current record of three arrests, seven conceptions and one committal Kiwicon is back for 2k9. The time has come to fake up an abstract and submit it to the Kiwicon Crue for judgement. In the coming months, we predict you will spend more time dreaming of kudos and UID 0 than actually working on your slides, since you'll be doing them the night before anyway. It's not New Zealand's only security conference, but it is the one where you're more likely to get a standing ovation for scanning an entire country than pointed questions regarding whether you were, perhaps, a little reckless in accessing systems without authorisation. _ _-(")- `%%%%% `KIWICON` // \\ The Crue holds a special place in their bowels for those who are aggravated that Kiwicon is held on a weekend so they don't get time off work. It is a gathering for those who are passionate about security. It has been hacked together by the .nz security scene for the .nz security community. Following in the tradition of previous cons, the atmosphere is extremely laid back; even the feds don't wear suits. Kiwicon is about sharing information. It's about intersections and cross-pollination and dissemination and other nouns disturbing reminiscent of a pre-AIDs key party. Sure, you could bring your RFID readers, your lockpicks or even your back track DVD but mostly you just need to bring yourself and the willingness to learn. For a little con down under we don't do too bad. Previously, Kiwicon has featured: the Crackstation, iKat (last seen at a airport near you), layer two telco shenanigans, a video montage of boardrooms across Japan, old school phreaking on new school kit, exposure of RIM's failure to hide their snooping capabilities, fun with the SCADA systems, making Microsoft look like turkeys, nuking various heap protections from space, and of course fucking up the certificate chain of your new passport. _ _-(")- `%%%%% // \\ `THE VENUE` The Crue is aware that location is everything, so once again we will be invading the Pipitea Campus which is surrounded by prestigious Wellington buildings such as Parliament house, the (partly renovated and badly secured) High Court, Ministry of Defence and various telecommunication hubs. All services are handy to the venue as well (train station, taxi rank, burger caravan, police cells / court etc). Caffeination will be provided by the lovely folks at Sweet Fanny-Anne's. _ _-(")- `%%%%% // \\ `THE PRICE` A recession-proof fifty bucks for the employed. Students and those otherwise supported by our precious taxpayer dollars (this does not include Members of Parliament) will pay $30. GST receipts will be available on request. The Crue will endeavour to leverage its synergies to architect a compelling ROI solution. _ _-(")- `%%%%% // \\ `THE TOPICS` Social networking/automated stalking, Cellular Networks (GSM,2degrees, openbts), State-sponsored surveillance, Malware (Viruses, Botnets), The Scam of EAL Certification, Industrial Espionage, Reverse Engineering, The Failwhale Rider, Virtualisation, Flash mobs, WebApps, 0hday The schedule will be made up as we go, so fifteen minutes or thirty minutes worth of material should be submitted as fifteen or thirty minutes worth of talk. We do place an upper limit of an hour (including questions), as anything longer than that can continue at the pub. _ _-(")- `%%%%% // \\ `SUBMISSIONS` These need to be in by the Witching Hour of the 31st October (NZST). Expats and wanna-be Kiwis will want to get their submissions in by 10th October, when we're going to be announcing the first round of Interesting Stuff. To submit a presentation to Kiwicon2k9, send an email to cfp at kiwicon.org with the following information: * Name or Handle: * Country of Residence: * Employer (if applicable): * Presentation Title: * Presentation Length: * Presentation Synopsis: * Brief Bio: If you do not provide a bio, one will be provided for you. _ _-(")- `%%%%% // \\ `BOTTOM LINE` The Crue want you to submit your talk to Kiwicon or the cute little header sheep gets it. _ -(")- `%%%%% // \\ `CONTACT` Email us: kiwicon at kiwicon.org Check the site: https://www.kiwicon.org/ Drop by silc: silc.kiwicon.org:2706/kiwicon Join the list: hackers-subscribe at kiwicon.org CFP online at https://kiwicon.org/cfp2k9.txt From nicolas at immunitysec.com Fri Aug 21 09:25:50 2009 From: nicolas at immunitysec.com (Nicolas Waisman) Date: Fri, 21 Aug 2009 10:25:50 -0300 Subject: [Dailydave] Ekoparty Reverse & Go Challenge Message-ID: <4A8EA05E.10703@immunitysec.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A little help: Same challenge, compiled with symbols: http://www.immunityinc.com/downloads/immunity_symbols.zip sha1: 5dfd5eb7d3e7ebb0d298d70a7178fbd8114ffd31 Cheers Nico Waisman Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqOoF0ACgkQnx8KWzmcRsFL/ACfWqclqIfFyEWkHWb4+o4DIFvt k/0AoIxGzM4y7uPhsz47JmIomtrqNkWK =Di1w -----END PGP SIGNATURE----- From crioux at noctem.org Sun Aug 23 20:15:46 2009 From: crioux at noctem.org (Christien Rioux) Date: Sun, 23 Aug 2009 20:15:46 -0400 Subject: [Dailydave] SOURCE Barcelona 2009 Schedule Message-ID: <5680af290908231715u1464011dl5a7dd38e7c09bebf@mail.gmail.com> SOURCE Barcelona September 21th-22nd, 2009 10:00am - 6:30pm Museu Nacional D?art de Catalunya www.sourceconference.com Only 100 Tickets Available ? Register Today! // SOURCE Announces SOURCE Barcelona Speaker Line-Up // Full Schedule Available on SOURCE Website - www.sourceconference.com ________________________________________ KEYNOTES Adam Laurie Pete Herzog ________________________________________ SESSIONS Nico Fischbach, - Telco 2.0:Security of Next-Generation Telecom Services Matt Bartoldus, Gotham Digital Science - The Software Assurance Maturity Model - Introduction and Application Philippe Langlois, Telecom Security - Consumer B Gone - Shopping Cart Antitheft System Gone Wrong Peter Silberman, Mandiant and Ero Carrera - State Of Malware: Explosion of the Axis of Evil Jim Reavis, Cloud Security Alliance - Cloud Computing Threat Vector Dov Yoran, MetroSITE Group - A Look at Security Projects and Spending in the Current Recession Bernardo Damele Assumpcao Guimaraes, Portcullis Computer Security & Guido Landi- Expanding the Control over Operation System from the Database Travis Goodspeed, Radiant Machines - Half Blind Attacks against Microcontrollers Erin Jacobs, UCB, Inc - Scare them into Compliance - How Fear and Fines Motivate Organizations to Make Changes Fermin Serna, Microsoft - Windows Secure Kernel Development Julio Auto - Triaging Bugs with Dynamic Dataflow Analysis Christian Ketterer and Sebastian Porst - REIL Using Platform-Independent Automated Deobfuscation Michael Baentsch, IBM - Transacting online: What Might be Good Enough and What Isn?t Vicente Diaz, S21Sec and David Barroso, S21Sec - TBA Fyodor Yarochkin - What's New with XProbe Brian Honan, BH Consulting - Knowing Me, Knowing You Dr. Dieter Bartmann, Psylock - Keystroke Dynamics as the Basis for Secure Authentication Charles Henderson, Trustwave, The Future Application Security Landscape SOURCE Conference is the first and only conference combining advanced technology and security practices with the business of security. With thoughtful attention to detail and an emphasis on high quality and compelling content, SOURCE is committed to delivering valuable information in a high energy and fun environment. Questions or Comments? Email info at sourceconference.com www.sourceconference.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090823/b8a7134c/attachment.htm From andrzej.targosz at proidea.org.pl Mon Aug 24 17:34:53 2009 From: andrzej.targosz at proidea.org.pl (Andrzej Targosz) Date: Mon, 24 Aug 2009 23:34:53 +0200 Subject: [Dailydave] CONFidence 2009, November, Poland, CfP Message-ID: <1493580927.20090824233453@proidea.org.pl> Calling all practitioners in the field of IT security! The 6th edition of CONFIdence 2009 2.0, is taking place in Warsaw on November 19/20, 2009. http://2009.confidence.org.pl We invite all to send the proposed topic and abstracts of presentation till the 15th of September. Please, remember that CONFidence is an open, international conference and all presentations should be given in English. If you want to give your lecture in Polish, please send an e-mail to the address given below. The answer to CfP should include: # name, last name and e-mail address of the potential speaker # speakers short bio, describing his experience and skills # speakers place of residence # presentation topic with short description of proposed lecture (no more than 500 words) # non-standard technical requirements Applications should be sent to andrzej.targosz{@}proidea.org.pl till 15 September, 2009. We are especially interested in presentation concerning: # 3G/4G, SS7, WLAN, RFID, Bluetooth Security # Analysis and reverse engineering of malicious code # Analysis of vulnerability, attacks and defence against networks, hardware, software # Virtualization and operating systems security # Data recovery, Forensic and Incident Response # Physical security # Firewall technologies # Web applications security and cryptographic Caution! We do not accept marketing, non-technical presentations aimed at presenting and selling any products. If your lecture presents company or its product, please do not send it! CONFidence conference is a non-profit event and speakers are not being paid. However, we always try to provide financial help and cover travel expenses and accommodation if possible. -- Andrzej Targosz andrzej.targosz{@}proidea.org.pl CONFidence Team http://2009.confidence.org.pl From dave at immunityinc.com Tue Aug 25 17:46:28 2009 From: dave at immunityinc.com (dave) Date: Tue, 25 Aug 2009 17:46:28 -0400 Subject: [Dailydave] STONESOUP Message-ID: <4A945BB4.3090904@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 C.F.: http://www.iarpa.gov/solicitations_stonesoup.html To summarize the link above: """ The goal of the STONESOUP program is to develop and demonstrate technology to advance automated techniques for software analysis, to combine them with methods for confining software execution so that known weaknesses cannot be exploited, and to diversify software components so that residual vulnerabilities will be more difficult for attackers to discover or exploit. Tools that can operate on programs written in common, type-safe languages such as Java or C#, in flexible but harder-to-analyze languages such as C or C++, as well as programs only available in binary format are all of interest to the program. """ Lately I've noticed a trend towards finding a way to force offensive tools to become defensive tools. I think STONESOUP is one example of this. Assuming it's not just a cover for "We want to find better bugs in binaries" then STONESOUP is trying to take the unsolvable Google Native Client problem and adding the very hard binary analysis problem. But it is useful to learn how many teams there are with their own amazing static analysis tools and fantastic containment systems. :> Everyone go home! Problem solved! :> - -dave And now, a word from our sponsor that you should read and then respond to! :> _____________________________________________________________________ Immunity Inc. is offering the below special deal for the upcoming Hacker Halted Conference in Miami, FL. To get the special discounted rate you will need to email admin at immunityinc.com for the promo code to be used at time of registration online. 1. Special rate of just $999 (Normal is $1299) 2. Full Access to ALL open sessions of the conference from Sep 23 - 25, 2009 3. All lunches and coffee breaks provided for (Sep 23 - 25, 2009) 4. Attend a choice one of the 3 following one-day training on Sep 25, 2009, covering the following topics: a) Identifying Threats and Deploying Countermeasures b) Incident Response: Principles of Incident Handling c) Virtualization Security: Threats Exposed *These workshops are led by EC-Council Master Instructors and are worth $599! 5. Free EC-Council Certification Training Courseware and Exam Voucher! Choose one of the following: a. EC-Council Certified Secure Programmer (ECSP) Read HERE b. EC-Council Certified VoIP Professional (ECVP) Read HERE c. EC-Council Disaster Recovery Professionals (EDRP) Read HERE *These official electronic courseware and Prometric Prime Vouchers are worth a combined of $900! ($650 + $250) *Redeemable from Nov 1, 2009. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkqUW7QACgkQtehAhL0gheqouQCeJCHg7BS4janTGhC/kfWg9DFm 1LEAmwTwBAz+LbZExm4SCTSui3TgEC5J =15wB -----END PGP SIGNATURE----- From dr at kyx.net Tue Aug 25 22:11:08 2009 From: dr at kyx.net (Dragos Ruiu) Date: Tue, 25 Aug 2009 19:11:08 -0700 Subject: [Dailydave] WPA attack improved to 1min, MITM Message-ID: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> The Beck/Tews WiFi WPA attack presented at PacSec has been improved (down to 1 min, MITM) by 2 .jp researchers (Ohigashi, Morii) http://bit.ly/clCpm Remember: avoid WPA/TKIP and force AES only encryption in WPA2 - don't let your access point automatically fall back automatically to the insecure TKIP/WPA mode, to be safe. (At least until any WPA2 attacks are published ;-P) cheers, --dr P.S. CanSecWest registration is now up, and a new Japanese PacSec registration is live. June has been picked as the time for EUSecWest in Amsterdam. (hat tip: T Harada) url: http://jwis2009.nsysu.edu.tw/index.php/jwis/jwis2009/paper/view/80 A Practical Message Falsification Attack on WPA Toshihiro Ohigashi, Masakatu Morii Last modified: 2009-07-20 Abstract In 2008, Beck and Tews have proposed a practical attack on WPA. Their attack (called the Beck-Tews attack) can recover plaintext from an encrypted short packet, and can falsify it. The execution time of the Beck-Tews attack is about 12-15 minutes. However, the attack has the limitation, namely, the targets are only WPA implementations those support IEEE802.11e QoS features. In this paper, we propose a practical message falsification attack on any WPA implementation. In order to ease targets of limitation of wireless LAN products, we apply the Beck-Tews attack to the man-in-the-middle attack. In the man-in- the-middle attack, the user's communication is intercepted by an attacker until the attack ends. It means that the users may detect our attack when the execution time of the attack is large. Therefore, we give methods for reducing the execution time of the attack. As a result, the execution time of our attack becomes about one minute in the best case. -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June http://eusecwest.com pgpkey http://dragos.com/ kyxpgp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090825/80d6c13c/attachment.htm From shane at security-objectives.com Wed Aug 26 08:40:56 2009 From: shane at security-objectives.com (Shane Macaulay) Date: Wed, 26 Aug 2009 05:40:56 -0700 Subject: [Dailydave] [ proof checking ] [ safer software ] [???] In-Reply-To: <1d0ba3070908142141me2b1b68pcdb5598e49245cd1@mail.gmail.com> References: <1d0ba3070908142141me2b1b68pcdb5598e49245cd1@mail.gmail.com> Message-ID: <4A952D58.6060604@security-objectives.com> Looks interesting, reminiscent of http://singularity.codeplex.com/, also on codeplex is a series of tools, http://ccimetadata.codeplex.com/ and http://vcc.codeplex.com/, also http://llvm.org is fairly mature, some other related projects can also be found via those links. Full source included. I'm stressing that point as I was not able to find the compiler the team used to validate their 7500 lines of C code. If it is, I'd be interested to toy with it and have yet to find a system, aforementioned tools included, which lived up to the hype. Often evading the question by only supporting subset's of C (for the truly motivated http://www.aitcnet.org/isai/) or whatever other restricted scope ;), I believe I've used these tools all correctly and have produced working test cases which appear to validate or check the various tutorials or guides included, yet I've found it possible to construe valid C code which happily compiles and runs and evades AST/model checker logic, resulting in silent failures. I suppose the 7500 lines of C code was actually, 7500 lines of C* (astrix'd -- our C dialect and we made sure to not get too tricky with our syntax), nevertheless looks cool, but like I said, would be neat to see the compiler. Real technical security, highly nuanced, does not lend itself well for abstraction's. Perceived technical security, well, that's another matter entirely. Arun Koshy wrote: > check : > > http://ertos.nicta.com.au/research/l4.verified/ > > media etc : > > http://www.theengineer.co.uk/Articles/312631/Safer+software.htm > > Of course, the work is based on a set of interesting assumptions and > fairly delimited universe ( given the understandable need to restrict > scope ). Comments anyone ? > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From knoble at terremark.com Wed Aug 26 09:02:17 2009 From: knoble at terremark.com (Kevin Noble) Date: Wed, 26 Aug 2009 09:02:17 -0400 Subject: [Dailydave] More offensive security metrics and you Message-ID: <4DDAB4CE11552E4EA191406F78FF84D90D6040B1ED@MIA20725EXC392.apps.tmrk.corp> I tend to over clock on some of Dave's teaser comment so I will post what has come to mind. Achieving a persistent presence with a low probability of detection and a low probability of eradication is achieved in subverting hardware and out of band communication. I think of the condition as 'relative superiority' as all attacks (that I know of), are temporary in nature. At some point, entrenching makes the attacker switch to defender and only the dormant can really be non-temporary (think of human virus carriers). Many have spoken of subverting firmware as means to resiliency but these are all but single methods of persistence. No one or two techniques gives an attacker 'permanent residence' status, only the methodical entrenchment of getting enough information that you could run the place in absence of the IT staff will allow one to remain. It is the dedication of becoming intimate with an organization that is so effective. One of the more interesting techniques demonstrated by Rich Smith at Immunity was frequently overwrites of byte code or even wiping of byte code in memory leaving only the stub to inject the next byte code. On the chance of detection, the byte code does not reveal past presence or overall intent (not in itself). He explained this as just one disciplined technique among many. I can image an attacker exposing some systems with routine malware just to test an incident response and build up an 'immunity' (heh) to exposure. I don't pretend to be pulling back the curtain on the topic, but I find the concept intriguing. Knoble at Terremark.com From mpatters at ist.uwaterloo.ca Wed Aug 26 11:29:59 2009 From: mpatters at ist.uwaterloo.ca (Mike Patterson) Date: Wed, 26 Aug 2009 11:29:59 -0400 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> Message-ID: <4A9554F7.7020007@ist.uwaterloo.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dragos Ruiu wrote on 8/25/09 10:11 PM: > The Beck/Tews WiFi WPA attack presented at PacSec has been improved > (down to 1 min, MITM) by 2 .jp researchers (Ohigashi, Morii) > http://bit.ly/clCpm Remember: avoid WPA/TKIP and force AES only > encryption in WPA2 - don't let your access point automatically fall back > automatically to the insecure TKIP/WPA mode, to be safe. (At least until > any WPA2 attacks are published ;-P) At the risk of sounding like a troll, this paper looks suspiciously like one of those stuffy old useless academic style papers that Dave warned us about a month or so ago. I don't see any links to conference proceedings in the sidebar on the page, but that's about all that's missing. There's even a (useful!) abstract published. How academy is that? Could it be that perhaps the anti-academics with chips on shoulders about ivory towers aren't entirely correct? Or is this a spasm of the dieing[sic] brontosaurus? Mike - -- Whoever is out of patience is out of possession of his soul. Men must not turn into bees, and kill themselves in stinging others. - Sir Francis Bacon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqVVPcACgkQrqw9H9F0mCRIGQCdGp5729G9WhcHWijxEbKmL7Pi j5wAn1JTQtklInMHYFHyfg0q+KK/5Mdb =gYah -----END PGP SIGNATURE----- From dr at kyx.net Wed Aug 26 12:12:24 2009 From: dr at kyx.net (Dragos Ruiu) Date: Wed, 26 Aug 2009 09:12:24 -0700 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <4A9554F7.7020007@ist.uwaterloo.ca> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> Message-ID: <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> On 26-Aug-09, at 8:29 AM, Mike Patterson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dragos Ruiu wrote on 8/25/09 10:11 PM: >> The Beck/Tews WiFi WPA attack presented at PacSec has been improved >> (down to 1 min, MITM) by 2 .jp researchers (Ohigashi, Morii) >> http://bit.ly/clCpm Remember: avoid WPA/TKIP and force AES only >> encryption in WPA2 - don't let your access point automatically fall >> back >> automatically to the insecure TKIP/WPA mode, to be safe. (At least >> until >> any WPA2 attacks are published ;-P) > > At the risk of sounding like a troll, this paper looks suspiciously > like > one of those stuffy old useless academic style papers that Dave warned > us about a month or so ago. I don't see any links to conference > proceedings in the sidebar on the page, but that's about all that's > missing. There's even a (useful!) abstract published. How academy > is that? > > Could it be that perhaps the anti-academics with chips on shoulders > about ivory towers aren't entirely correct? Or is this a spasm of the > dieing[sic] brontosaurus? Should have put in this link to the full paper from the conf proceedings page as someone already correctly pointed out: http://bit.ly/8qwQt The research team is scheduled to present an implementation of the attack at a conference on Sept. 25. (http://www.ieice.org/ken/paper/20090925faPH/eng/ ). (via YM Chen) The attack seems to have wider applicability than the original Beck/Tews variant it is based on as it uses chopchop during MITM without relying on 802.11e QoS extensions like Beck/Tews does, but does require interfering with AP and MITM which are additional complexity to execution. (Hat tip: Cedric Blancher) cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From version5 at gmail.com Wed Aug 26 19:14:08 2009 From: version5 at gmail.com (nnp) Date: Thu, 27 Aug 2009 00:14:08 +0100 Subject: [Dailydave] [ proof checking ] [ safer software ] [???] In-Reply-To: <4A952D58.6060604@security-objectives.com> References: <1d0ba3070908142141me2b1b68pcdb5598e49245cd1@mail.gmail.com> <4A952D58.6060604@security-objectives.com> Message-ID: <28749c0e0908261614qdc674dan15e8ef4121bd8adc@mail.gmail.com> As far as I can tell there was no verification done by a compiler. The paper [1] describes the technique (sort of). It's a refinement proof from an abstract specification to C code. [1] http://ertos.nicta.com.au/publications/papers/Klein_EHACDEEKNSTW_09.pdf On Wed, Aug 26, 2009 at 1:40 PM, Shane Macaulay wrote: > Looks interesting, reminiscent of http://singularity.codeplex.com/, also > on codeplex is a series of tools, http://ccimetadata.codeplex.com/ and > http://vcc.codeplex.com/, also http://llvm.org is fairly mature, some > other related projects can also be found via those links. ?Full source > included. ?I'm stressing that point as I was not able to find the > compiler the team used to validate their 7500 lines of C code. ?If it > is, I'd be interested to toy with it and have yet to find a system, > aforementioned tools included, which lived up to the hype. ?Often > evading the question by only supporting subset's of C (for the truly > motivated http://www.aitcnet.org/isai/) or whatever other restricted > scope ;), I believe I've used these tools all correctly and have > produced working test cases which appear to validate or check the > various tutorials or guides included, yet I've found it possible to > construe valid C code which happily compiles and runs and evades > AST/model checker logic, resulting in silent failures. ?I suppose the > 7500 lines of C code was actually, 7500 lines of C* (astrix'd -- our C > dialect and we made sure to not get too tricky with our syntax), > nevertheless looks cool, but like I said, would be neat to see the compiler. > > Real technical security, highly nuanced, does not lend itself well for > abstraction's. ?Perceived technical security, well, that's another > matter entirely. > > > Arun Koshy wrote: >> check : >> >> http://ertos.nicta.com.au/research/l4.verified/ >> >> media etc : >> >> http://www.theengineer.co.uk/Articles/312631/Safer+software.htm >> >> Of course, the work is based on a set of interesting assumptions and >> fairly delimited universe ( given the understandable need to restrict >> scope ). Comments anyone ? >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> >> > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From jwright at hasborg.com Wed Aug 26 19:49:26 2009 From: jwright at hasborg.com (Joshua Wright) Date: Wed, 26 Aug 2009 16:49:26 -0700 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> Message-ID: <4A95CA06.40805@hasborg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Should have put in this link to the full paper from the conf proceedings > page as someone already correctly pointed out: http://bit.ly/8qwQt > > The attack seems to have wider applicability than the original Beck/Tews > variant it is based on as it uses chopchop during MITM without relying > on 802.11e QoS extensions like Beck/Tews does, but does require > interfering with AP and MITM which are additional complexity to > execution. (Hat tip: Cedric Blancher) The claim of 1 minute to break WPA seems unsupported in the paper. The authors have identified mechanisms by which they can reduce the amount of time to ARP plaintext recovery compared to the numbers presented by Beck/Tews, but the 1-minute claim assumes the attacker already has knowledge of the MIC, presumably by executing the Beck/Tews attack first, and then implementing this attack within the 65K packet PTK lifetime duration. Simplified, this attack can break WPA in 1 minute if it was already broken by the Beck/Tews technique (Hat tip: Beck, Tews). - -Josh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEUEARECAAYFAkqVygYACgkQapC4Te3oxYy8lACXbdWCWFYr/plNE/AU0KQrfgO/ NQCeKIC8fRLur5m/dHMx8wbPAGW5mY8= =JEEj -----END PGP SIGNATURE----- From blancher at cartel-securite.fr Thu Aug 27 04:21:00 2009 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Thu, 27 Aug 2009 10:21:00 +0200 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <4A95CA06.40805@hasborg.com> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> <4A95CA06.40805@hasborg.com> Message-ID: <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> Le mercredi 26 ao?t 2009 ? 16:49 -0700, Joshua Wright a ?crit : > Simplified, this attack can break WPA in 1 minute if it was already > broken by the Beck/Tews technique (Hat tip: Beck, Tews). Or their own "improvement", based on a MITM that is definitely not that trivial to implement. And actually not that useful compared to DoSing communication channel with a directional antenna. This claim of 1min makes me think of tons of misleading articles commenting Bittau, Handley and Lackey "The Final Nail in WEP's Coffin" paper (awesome paper BTW), stating WEP could be broken in 30sec or so using their technic, just forgetting that theses 30sec were only the first step. Ohigashi & Morii paper per se is not really misleading to me as it is quite clear when you read it about what they do and where they claim improvements. What I actually find very misleading is titling "MITM" (no offense meant Dragos ;), kind of meaning that their attack would allow one to MITM on TKIP, which is definitely not the case. One thing this paper also don't mention, although it might not be a big problem after all, is what happens after they release their black-out. They often refer to minimizing black-out duration, probably for being able to restore normal communication, but they don't refer to TSC resync issues. -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From dragorn at kismetwireless.net Thu Aug 27 12:28:04 2009 From: dragorn at kismetwireless.net (Mike Kershaw) Date: Thu, 27 Aug 2009 12:28:04 -0400 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> <4A95CA06.40805@hasborg.com> <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> Message-ID: <20090827162804.GF17156@drd1813.lan> On Thu, Aug 27, 2009 at 10:21:00AM +0200, Cedric Blancher wrote: > Le mercredi 26 ao?t 2009 ? 16:49 -0700, Joshua Wright a ?crit : > > Simplified, this attack can break WPA in 1 minute if it was already > > broken by the Beck/Tews technique (Hat tip: Beck, Tews). > > Or their own "improvement", based on a MITM that is definitely not that > trivial to implement. And actually not that useful compared to DoSing > communication channel with a directional antenna. I think MITM is actually quite trivial in this case (lets disregard the other components). If you assume MITM on the same channel, then you get all sorts of problems - you can maybe isolate an edge user on a large multi-ap network by replicating a far-away AP with a very strong signal to override local APs that the user would use, but it might still be tricky. However, beacon frames are still unprotected. As long as the BSSID and WPA IE fields are the same, there's no reason you can't rewrite them to advertise a different channel (or even a different band, jump from 2.4 up to 5). With a dual-radio repeater it should be trivial. If rewriting the packet makes you nervous, filter beacons entirely and generate your own with the same BSSID and WPA info. Combine with some disassoc/deauth packets on the original AP channel and you should be able to shuffle all the users over to your repeater without much fuss, and have them far enough away from the original that overlapping packet delivery is a non-issue. So at the least, it would seem like they've removed QoS as a restriction, so long as they can successfully maintain the repeater (and so long as the client doesn't wander away when it stops getting data packets for 10 minutes, of course). -m -- Mike Kershaw/Dragorn GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 TRANSLATE(:SITE,'pLA','Place','.') returns the value 'pivAviskA LAk. pLA..'. -- IBM Db2 Server SQL Reference SC09-2404-00 pp. 138 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090827/f4eafdfa/attachment.pgp From blancher at cartel-securite.fr Thu Aug 27 13:08:23 2009 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Thu, 27 Aug 2009 19:08:23 +0200 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <20090827162804.GF17156@drd1813.lan> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> <4A95CA06.40805@hasborg.com> <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> <20090827162804.GF17156@drd1813.lan> Message-ID: <1251392903.7047.37.camel@anduril.intranet.cartel-securite.net> Le jeudi 27 ao?t 2009 ? 12:28 -0400, Mike Kershaw a ?crit : > However, beacon frames are still unprotected. As long as the BSSID and > WPA IE fields are the same, there's no reason you can't rewrite them to > advertise a different channel. That's a very good point. When I was saying trivial, I was meaning no need to implement something specific to handle that situation. But that's only generating beacons and forwarding frames from one radio to another, no big deal indeed. And it is way easier to do than playing with QoS actually :) > So at the least, it would seem like they've removed QoS as a > restriction, so long as they can successfully maintain the repeater (and > so long as the client doesn't wander away when it stops getting data > packets for 10 minutes, of course). That's where their "1min improvement" might become useful. Because they don't use 802.11e, they can only inject 1 frame per keystream, against multiple ones (one per usable channel) for original Beck&Tews attack. But their ability to retrieve new ARPs more often partly compensate that. -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From dragorn at kismetwireless.net Thu Aug 27 16:35:28 2009 From: dragorn at kismetwireless.net (Mike Kershaw) Date: Thu, 27 Aug 2009 16:35:28 -0400 Subject: [Dailydave] WPA attack improved to 1min, MITM In-Reply-To: <002201ca2751$c58173b0$50845b10$@net> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> <4A95CA06.40805@hasborg.com> <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> <20090827162804.GF17156@drd1813.lan> <002201ca2751$c58173b0$50845b10$@net> Message-ID: <20090827203528.GH17156@drd1813.lan> On Thu, Aug 27, 2009 at 01:05:48PM -0700, George Ou wrote: > Not sure why we're spending time on this attack, when Moxie's SSL attack and > Joshua Wright's FreeRadius-WPE would pretty much completely break you into > most corporate wireless networks even if they were running WPA-AES. This > would be even better than injecting a few arbitrary packets because you'd > actually obtain user credentials. Possibly - it's strongly dependent on how the supplicant validates the certs. *IF* the supplicant uses the CN exclusively, then it's at risk, but this also assumes that they use a global CA chain to start their radius certs (instead of doing an internal CA for their private network). If the supplicant is configured to trust the parent CA of your marlinspike'd cert, then sure - definitely time to be afraid - but this is an insecure setup anyhow, as mentioned in Josh's presentation (some versions of WZC validate the signing authority only, regardless of CN). The moxie stuff is a big vuln in badly set up networks, but not necessarily any bigger of a vuln than the badly set up network was already. If you used a public CA and your users use a supplicant which doesn't check CN, you're just as owned. If I can spike a cert that matches your private CN, you're also... badly owned, without any of these games. It's much more interesting to combine the marlinspike stuff with, say, airpwn or dns hijacking on open networks down the road from your target. -m -- Mike Kershaw/Dragorn GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 Life is just Natures way of keeping meat fresh -- The Doctor -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090827/03d984a9/attachment.pgp From dr at kyx.net Fri Aug 28 00:08:23 2009 From: dr at kyx.net (Dragos Ruiu) Date: Thu, 27 Aug 2009 21:08:23 -0700 Subject: [Dailydave] WPA attack improved to 1min via MITM In-Reply-To: <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> References: <9F9E9AE3-2522-40A2-B618-6365BAD0411C@kyx.net> <4A9554F7.7020007@ist.uwaterloo.ca> <4543784B-1FE3-4CE6-8AC4-CCF2DBFD88DC@kyx.net> <4A95CA06.40805@hasborg.com> <1251361260.7316.24.camel@anduril.intranet.cartel-securite.net> Message-ID: <6A8FB63C-BD61-4EEC-88E8-825E7E315AC1@kyx.net> On 27-Aug-09, at 1:21 AM, Cedric Blancher wrote: > What I actually find very misleading is titling "MITM" (no > offense meant Dragos ;), kind of meaning that their attack would allow > one to MITM on TKIP, which is definitely not the case. Hey it was late at night, and I had just read the paper. Now I would s/,/via/ since it's more analyzed. What's a little inadvertent FUD here and there, anyways. It seems to be a rampant hazard in this industry, as well as the flipside to all the less than understood threats that are underestimated. ;-P Caveat Lector. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 http://cansecwest.com Amsterdam, Netherlands June http://eusecwest.com pgpkey http://dragos.com/ kyxpgp