From fyodor at insecure.org Thu Oct 2 06:56:58 2008 From: fyodor at insecure.org (Fyodor) Date: Thu, 2 Oct 2008 03:56:58 -0700 Subject: [Dailydave] TCP Resource Exhaustion DoS Attack Speculation Message-ID: <20081002105658.GF11277@syn.lnxnet.net> Yesterday we saw many news reports of a "new" denial of service vulnerability in TCP. As seems to be getting more common, the researchers (Robert Lee and Jack Louis) declined to provide details until their presentation in Finland on the 17th. It is Kaminksy deja vu! While I don't favor this approach (or the media circus which always ensues), I don't presume to tell researchers how they should disclose vulnerabilities. But I also don't need to keep quiet until their talk if I figure out or independently discover an issue. There was lots of speculation on DailyDave about the DNS flaws, and I think I've figured out this "new" vulnerability. The vague description and symptoms match those for a DoS tool (Ndos) I wrote and used years ago. I just posted a detailed description of the problem and its implications here: http://insecure.org/stf/tcp-dos-attack-explained.html I hope Robert and Jack aren't mad at me, since I do respect them and their work. But they claim on their podcast that their goal is to get people thinking about the problem and solutions. For that to happen, you sort of have to describe the problem :). And if it is really such an important issue, why wait until October 17? Cheers, Fyodor From dave at immunityinc.com Mon Oct 6 08:50:43 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 06 Oct 2008 08:50:43 -0400 Subject: [Dailydave] VisualSploit in Japanese, EkoParty, BA-Con Message-ID: <48EA09A3.3090808@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those of you in Japan, Cyberdefense is teaching a great "How to write buffer overflows" class in Japanese! They even translated VisualSploit into Japanese (http://www.immunitysec.com/downloads/vs_jp.png). Once my Spanish gets better I'll try the Spanish translation as well. :> I did however add two presentations here (both of which don't make a TON of sense without the words to go along with them - sorry!): http://www.immunitysec.com/resources-papers.shtml - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6gmjtehAhL0gheoRAguHAJ9zI7hgFMb4uPEX1Lf02e5i5hCnVQCcCVah IFn2XnFgDvl8oSiPgLx+y+o= =TJYj -----END PGP SIGNATURE----- From sqlsec at yahoo.com Wed Oct 8 15:22:51 2008 From: sqlsec at yahoo.com (Cesar) Date: Wed, 8 Oct 2008 12:22:51 -0700 (PDT) Subject: [Dailydave] Token Kidnapping Win2k3 PoC exploit Message-ID: <910840.27447.qm@web33004.mail.mud.yahoo.com> http://nomoreroot.blogspot.com/2008/10/windows-2003-poc-exploit-for-token.html Enjoy. Cesar. From dave.korn at artimi.com Wed Oct 8 05:30:35 2008 From: dave.korn at artimi.com (Dave Korn) Date: Wed, 8 Oct 2008 10:30:35 +0100 Subject: [Dailydave] TCP Resource Exhaustion DoS Attack Speculation In-Reply-To: <20081002105658.GF11277@syn.lnxnet.net> References: <20081002105658.GF11277@syn.lnxnet.net> Message-ID: <02a101c92928$846964a0$9601a8c0@CAM.ARTIMI.COM> Fyodor wrote on 02 October 2008 11:57: > if I figure out or independently discover an issue. There was lots of > speculation on DailyDave about the DNS flaws, and I think I've figured > out this "new" vulnerability. The vague description and symptoms > match those for a DoS tool (Ndos) I wrote and used years ago. > > I just posted a detailed description of the problem and its > implications here: > > http://insecure.org/stf/tcp-dos-attack-explained.html Interesting idea, but I think that's not it. I think they're leaving the sockets on the victim in a closing state, either TIME_WAIT or CLOSE_WAIT, and I think they're manipulating the victim stack to prolong this state to arbitrary (ridiculously long, maybe years) durations, probably by playing games with sACKs or maybe PAWS, or by misleading the RTT measurements into coming out with silly values. cheers, DaveK -- Can't think of a witty .sigline today.... From dailydave at digitaloffense.net Mon Oct 13 11:29:51 2008 From: dailydave at digitaloffense.net (dailydave at digitaloffense.net) Date: Mon, 13 Oct 2008 10:29:51 -0500 Subject: [Dailydave] Uninformed Journal Release Announcement: Volume 10 Message-ID: <200810131029.51367.dailydave@digitaloffense.net> Uninformed is pleased to announce the release of its 10th volume which is composed of 4 articles: Engineering in Reverse - Can you find me now? Unlocking the Verizon Wireless xv6800 (HTC Titan) GPS Author: Skywing - Using dual-mappings to evade automated unpackers Author: skape Exploitation Technology - Analyzing local privilege escalations in win32k Author: mxatone - Exploiting Tomorrow's Internet Today: Penetration testing with IPv6 Author: H D Moore This volume of the journal can be found at: http://www.uninformed.org/?v=10 About Uninformed: Uninformed is a non-commercial technical outlet for research in areas pertaining to security technologies, reverse engineering, and lowlevel programming. The journal is published roughly three times a year and welcomes creative submissions from anyone who is interested in sharing knowledge. - The Uninformed Staff staff [at] uninformed.org From dave at immunityinc.com Tue Oct 14 10:53:18 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 14 Oct 2008 10:53:18 -0400 Subject: [Dailydave] The Static Analysis Market and You Message-ID: <48F4B25E.8070102@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So OWASP was dominated by lots of talk from and about static code analysis tools. I wandered around with a friend of mine at the various booths (CodeSecure [1], Fortify[2], IBM AppScan[3], Ounce Labs) and tried them all while listening to their sales pitches. My friend works for a financial institution that was looking to integrate static analysis into their code development process. Like many people, she thought the marketing sounded good. Keep in mind, a lot of the sponsors for OWASP were static analysis tool vendors, and the "Industry Panel" was heavily in favor of static analysis tools (until you talked to them off-stage). Here's my thoughts: 1. The technology's capabilities does not match the marketing pitch - ideally for my friend, the tools would find all the exploitable vulnerabilities in your code and then you would fix them, re-run it, and get a clean bill of health. All the tools provide you an interface that purports to fit into this workflow. None of them, however, work like that. One of the major problems with the technology is that you have to be a super genius code auditor to decide if the vulnerabilities are real or not. Also annoyingly the false positive rate is enormous even when run against the tiny test programs they are using to demo the tools with. So you end up with a ten page list of "bugs" that you may or may not be able to understand enough to fix. All the tools provide nice code browsers and a graph of data flow to help you with this process, but in practice it's not enough. 2. IBM has integrated their static analysis with AppScan's scanning and with their own dynamic analysis to try to help triage vulnerabilities. There aren't a lot of other companies with all these technologies ready to go, so I'd expect HP to pick up one of the static code analysis tools on the cheap to match this - Fortify would be a good fit. IBM's coverage is not as broad as the other vendors though, and they are mostly sticking to a J2EE application sweet spot. (.Net is coming soon, etc). 3. Ounce has exposed a really nice .Net API so if you ARE a code auditor as a professional you can do filtering and hard-core analysis using their internal knowledge base and data structures. 4. CodeSecure did a pretty good job on the PHP app I looked at, and was easy to use, but as far as I can tell is a bit of a newer player than some of the others. Not that it matters when the field is this crowded. The Nist Survey ____________________________________________________________________________________________________________________ Anyways, market stuff aside, NIST did a survey[5] (and presented at OWASP) of all the solutions they could get to play, and discovered that they basically don't work (not their words). They said not to use their survey to make decisions like that, but let me run down the conclusions as I saw them based entirely on the 1 hr OWASP presentation: 1. Running the tools against 6 programs (3 Java, 3 C) generated 47000 distinct "vulns" - in some cases (tinyhttpd) generating about 80% false positive rate. Imho anything over 5% makes the process unusable by developers. They estimated 1 man year to do false/true positive determination on the entire set - which is a LOT of time. 2. In many cases skilled engineers were unable to determine the false positive/true positive of a particular vulnerability warning (or were "wrong" about it). Imagine how well your developer team will do! 3. No 0days were found worth reporting to the open source projects. (!!!) Conclusions ___________________________________________________________________________________ Those are not good signs for the technology field as a whole. One possibility is that more research dollars will flood into the space and the technology will get better and live up to its marketing. Another possibility is that no matter how much you spend, pure static analysis can't do the things you want it to do (the IBM and to some extent Fortify bet). Which is it? - -dave [1] http://www.armorize.com/corpweb/en/products/codesecure [2] http://www.fortify.com/ [3] http://www.sdtimes.com/IBM_IMPLEMENTS_STATIC_ANALYSIS_IN_APPSCAN_UPDATE/About_ALM_and_SECURITY_and_IBM/32889 [4] http://www.ouncelabs.com/ [5] https://samate.nist.gov/index.php/SATE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI9LJetehAhL0gheoRAgVzAJ4qTwc4sJ1VEj1AGrDVyLf0QDz6gQCeIXsj cmdI/sBsk225x5V4qIl5jPk= =Y/wJ -----END PGP SIGNATURE----- From dave at immunityinc.com Tue Oct 14 12:35:33 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 14 Oct 2008 12:35:33 -0400 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem Message-ID: <48F4CA55.90900@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 D2's latest exploit pack has a couple cool tools in it: 1. a malicious PDF file creator 2. a malicious Java Applet If you're doing client side penetration tests, sometimes no exploit is the best exploit. Both of these are "one click to own" things. Immunity uses the D2 pack against our clients when we do penetration tests. No one can write everything! And of course Gleg continues to produce interesting remotes in things like J2EE servers. Luckily no one uses those, right? At this point they have 280 additional modules for CANVAS which almost doubles the size of CANVAS's standard exploit modules. And there are more third-party packs on the way! The value of these tools is in the content built on top of them. - -dave (hahaha at me at using the word ecosystem. Such a Microsofty word!) P.S. Everyone should have the cojones to post their static analysis responses to the list! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI9MpUtehAhL0gheoRAtUeAJ9/PAR7t2MTDG3n/kb5REqFixELcQCbBb+H VEOK6SFmBQpLO5FXHpa/rcs= =4b/h -----END PGP SIGNATURE----- From dailydave at digitaloffense.net Tue Oct 14 13:00:13 2008 From: dailydave at digitaloffense.net (H D Moore) Date: Tue, 14 Oct 2008 12:00:13 -0500 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <48F4CA55.90900@immunityinc.com> References: <48F4CA55.90900@immunityinc.com> Message-ID: <200810141200.13963.dailydave@digitaloffense.net> Dave, Would you mind providing an overview of each of the third-party module packs, how many new vulnerabilities they cover, and what the pricing is? If someone had an unlimited budget to buy CANVAS.*, what would they end up with? Genuinely curious, -HD On Tuesday 14 October 2008, Dave Aitel wrote: > And of course Gleg continues to produce interesting remotes in things > like J2EE servers. Luckily no one uses those, right? At this point > they have 280 additional modules for CANVAS which almost doubles the > size of CANVAS's standard exploit modules. From mhtajik at gmail.com Tue Oct 14 13:09:43 2008 From: mhtajik at gmail.com (Mohammad Hosein) Date: Tue, 14 Oct 2008 20:39:43 +0330 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <48F4CA55.90900@immunityinc.com> References: <48F4CA55.90900@immunityinc.com> Message-ID: <26f61db50810141009h6cbb58d2saedac0d640b2a494@mail.gmail.com> well , as much as i love one-click stuff ( which are by the way available on the wild side of the game . Russian Brothers , cool people from China , dangerous underground Romanian and Brazilian Crews , Hello! ) i have to bring up this issue now that its on the list the licensing model and price of these packs are really far away from what individuals and freelancers can afford . anyone else here thinks the same ? On Tue, Oct 14, 2008 at 8:05 PM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > D2's latest exploit pack has a couple cool tools in it: > 1. a malicious PDF file creator > 2. a malicious Java Applet > > If you're doing client side penetration tests, sometimes no exploit is > the best exploit. Both of these are "one click to own" things. > Immunity uses the D2 pack against our clients when we do penetration > tests. No one can write everything! > > And of course Gleg continues to produce interesting remotes in things > like J2EE servers. Luckily no one uses those, right? At this point > they have 280 additional modules for CANVAS which almost doubles the > size of CANVAS's standard exploit modules. > > And there are more third-party packs on the way! The value of these > tools is in the content built on top of them. > > - -dave > (hahaha at me at using the word ecosystem. Such a Microsofty word!) > P.S. Everyone should have the cojones to post their static analysis > responses to the list! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFI9MpUtehAhL0gheoRAtUeAJ9/PAR7t2MTDG3n/kb5REqFixELcQCbBb+H > VEOK6SFmBQpLO5FXHpa/rcs= > =4b/h > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081014/c49f4ee4/attachment.htm From dave.korn at artimi.com Tue Oct 14 14:25:13 2008 From: dave.korn at artimi.com (Dave Korn) Date: Tue, 14 Oct 2008 19:25:13 +0100 Subject: [Dailydave] The Static Analysis Market and You In-Reply-To: <48F4B25E.8070102@immunityinc.com> References: <48F4B25E.8070102@immunityinc.com> Message-ID: <00f401c92e2a$357bcde0$9601a8c0@CAM.ARTIMI.COM> Dave Aitel wrote on 14 October 2008 15:53: > One > possibility is that more research dollars will flood into the space > and the technology will get better and live up to its marketing. > Another possibility is that no matter how much you spend, pure static > analysis can't do the things you want it to do (the IBM and to some > extent Fortify bet). > > Which is it? You really asking, or is that just rhetorical? It's blatantly option B. If your code compiles without warnings and lint errors, you've probably already got 99% of what these tools can do for you, for free. And the other 1% is the stuff that needs a skilled human being to look at it, anyway; until we get a real AI working on it, none of this stuff is a great deal more subtle than "grep -R strcpy *". > [1] http://www.armorize.com/corpweb/en/products/codesecure Had to read the source just to even get a look at that one, and found a bit that made me LOLWTF: Heh. Disabled now, but it really does look a lot like at some point somebody had never heard of absolute paths ... cheers, DaveK -- Can't think of a witty .sigline today.... From mjw at cyberwart.com Tue Oct 14 14:27:46 2008 From: mjw at cyberwart.com (Matthew Wollenweber) Date: Tue, 14 Oct 2008 14:27:46 -0400 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <48F4CA55.90900@immunityinc.com> References: <48F4CA55.90900@immunityinc.com> Message-ID: <1224008866.14697.6.camel@melkor.cyberwart> Dave/Gleg, Every now and then some exploits, such as the below really interest me and my team. But it would be helpful if announcements contained a bit more information. I know you have to balance disclosure but a couple things that might help: 1. What versions of the software are affected? 2. Is the software in a common or default configuration? 3. What security zone is required for the exploit to work? 4. The exploit enables remote code execution? 5. How reliable is the exploit (ballpark -- for example a buffer overflow you've never seen fail or a complicated heap corruption bug that sometimes works). For me, that's the basic information I want before purchasing an exploit and IMO I don't think it gives away enough to easily go look for the bug myself. On Tue, 2008-10-14 at 12:35 -0400, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > D2's latest exploit pack has a couple cool tools in it: > 1. a malicious PDF file creator > 2. a malicious Java Applet > > If you're doing client side penetration tests, sometimes no exploit is > the best exploit. Both of these are "one click to own" things. > Immunity uses the D2 pack against our clients when we do penetration > tests. No one can write everything! > > And of course Gleg continues to produce interesting remotes in things > like J2EE servers. Luckily no one uses those, right? At this point > they have 280 additional modules for CANVAS which almost doubles the > size of CANVAS's standard exploit modules. > > And there are more third-party packs on the way! The value of these > tools is in the content built on top of them. > > - -dave > (hahaha at me at using the word ecosystem. Such a Microsofty word!) > P.S. Everyone should have the cojones to post their static analysis > responses to the list! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFI9MpUtehAhL0gheoRAtUeAJ9/PAR7t2MTDG3n/kb5REqFixELcQCbBb+H > VEOK6SFmBQpLO5FXHpa/rcs= > =4b/h > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -- Matthew Wollenweber mjw at cyberwart.com www.cyberwart.com/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081014/0d3a036f/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20081014/0d3a036f/attachment-0001.pgp From steingra at gmail.com Tue Oct 14 17:18:26 2008 From: steingra at gmail.com (Andy Steingruebl) Date: Tue, 14 Oct 2008 14:18:26 -0700 Subject: [Dailydave] The Static Analysis Market and You In-Reply-To: <48F4B25E.8070102@immunityinc.com> References: <48F4B25E.8070102@immunityinc.com> Message-ID: <490a979e0810141418v32fbb0b7l5e7c3684e503e059@mail.gmail.com> On Tue, Oct 14, 2008 at 7:53 AM, Dave Aitel wrote: > > Also annoyingly the false positive rate is enormous even when run > against the tiny test programs they are using to demo the tools with. > So you end up with a ten page list of "bugs" that you may or may not > be able to understand enough to fix. All the tools provide nice code > browsers and a graph of data flow to help you with this process, but > in practice it's not enough. > > 1. Running the tools against 6 programs (3 Java, 3 C) generated 47000 > distinct "vulns" - in some cases (tinyhttpd) generating about 80% > false positive rate. Imho anything over 5% makes the process unusable > by developers. They estimated 1 man year to do false/true positive > determination on the entire set - which is a LOT of time. > > 2. In many cases skilled engineers were unable to determine the false > positive/true positive of a particular vulnerability warning (or were > "wrong" about it). Imagine how well your developer team will do! > > I hear both of these points a lot but never get any insight into whether the items found are bugs, but not exploitable security vulnerabilities, or whether they aren't bugs at all. Most of the stats I've seen, and my own testing, tells me that for at least some of the analysis rules the false positive rate for a bug is actually quite low. Its just that it isn't necessarily on a vulnerable path, doesn't have untrusted inputs, etc. While this is an indictment of the promise of the vendors to help you fix security problems, it isn't necessarily an indictment of the technology's ability to find bugs. Whether they are the ones you'd want to prioritize is another question and obviously plays into the value of the tool, but at the same time an attitude that says you're only going to fix the known to be currently vulnerable bugs in your code rather than most bugs found, especially those that do potentially unsafe things, won't result in very high assurance software. Take for example a checker that finds "banned" api calls. It will potentially find a lot of cases strcpy() in your code. Are all of them unsafe? Probably not. Some are copying statically sized buffers, things from config files that you completely control, etc. Most of the findings of uses of strcpy() are in the strict sense going to be false positives. At the same time you might not want them in your code as they are hard to get right. strcpy() is an easy example of course because grep will find it. There are other cases though of more complicated checkers that will find issues in an automated fashion that are a lot harder to find with manual inspection. I'd like to see some better underlying data about these and how people are classifying their false positives. -- Andy Steingruebl steingra at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081014/9b2ce818/attachment.htm From steve.shockley at shockley.net Tue Oct 14 20:41:34 2008 From: steve.shockley at shockley.net (Steve Shockley) Date: Tue, 14 Oct 2008 20:41:34 -0400 Subject: [Dailydave] The Static Analysis Market and You In-Reply-To: <48F4B25E.8070102@immunityinc.com> References: <48F4B25E.8070102@immunityinc.com> Message-ID: <48F53C3E.8010208@shockley.net> On 10/14/2008 10:53 AM, Dave Aitel wrote: > So you end up with a ten page list of "bugs" that you may or > may not be able to understand enough to fix. The problem is people feel compelled to "fix" them, like http://svn.debian.org/viewsvn/pkg-openssl?rev=141&view=rev. From dphull at trustedsignal.com Tue Oct 14 22:25:32 2008 From: dphull at trustedsignal.com (Dave Hull) Date: Tue, 14 Oct 2008 21:25:32 -0500 Subject: [Dailydave] The Static Analysis Market and You In-Reply-To: <48F4B25E.8070102@immunityinc.com> References: <48F4B25E.8070102@immunityinc.com> Message-ID: <7bf0e6cb0810141925p3238c0cag18b60cc3bc8f96f3@mail.gmail.com> On Tue, Oct 14, 2008 at 9:53 AM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > One of the major problems with the technology is that you have to be a super > genius code auditor to decide if the vulnerabilities are real or not. For the most part, I agree with what you're saying, but I disagree with this statement. I work with Fortify. Maybe it's the code we're producing, but thus far most of the false positives have been easy to spot. What bothers me more is when developers follow the Fortify's recommendations to correct issues, re-scan the code and Fortify continues to flag it as vulnerable. We end up suppressing the issue and in the developer's mind the tool is called into question. I believe SCA tools should be considered another layer in the defense-in-depth strategy. Train developers. Build security into the development process, beginning with requirements gathering. Have security participate in the architecture and planning of the project. Do code reviews for security issues, both manually and with automated tools. Pen test the final product with automated tools and manually. I'm currently reading Brian Chess' and Jacob West's _Secure Programming with Static Analysis_. The author's are from Fortify and they lay out some ground rules early in the book. They refer to something they call the "exploitability trap," wherein the SCA tool flags a given piece of code as vulnerable and the developer says, "I won't fix that unless you can prove it's exploitable." The authors recommend avoiding this trap by categorizing vulnerable code as: 1. Obviously exploitable 2. Ambiguous 3. Obviously secure If something isn't obviously secure, it should be refactored until it is. As a developer, that's annoying. As a security person, it seems reasonable. It's more fun to refactor code than to send breach notifications to millions of customers. What keeps me up at night is not the false positives, but the false negatives. I can't find it at the moment, but one review of the big three products in this space said that they caught around 40% of the vulnerabilities. Another concern is what Gary McGraw has referred to as the Bug Parade. SCA tools may be useful for finding bugs, but they don't help us find logic flaws. > The Nist Survey Thanks for the synopsis. The web site says the results won't be published until Dec. I can't wait to see them. > Those are not good signs for the technology field as a whole. One > possibility is that more research dollars will flood into the space > and the technology will get better and live up to its marketing. Does anything ever live up to its marketing? I'd settle for continuous product improvement and honest claims. -- Dave Hull Public key: http://trustedsignal.com/pubkey.txt Fingerprint: 4B2B F3AD A9C2 B4E1 CBDF B86F D360 D00F C18D C71B From isaac.dawson at gmail.com Wed Oct 15 05:28:33 2008 From: isaac.dawson at gmail.com (Isaac Dawson) Date: Wed, 15 Oct 2008 18:28:33 +0900 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <1224008866.14697.6.camel@melkor.cyberwart> References: <48F4CA55.90900@immunityinc.com> <1224008866.14697.6.camel@melkor.cyberwart> Message-ID: <5ff6321e0810150228u2950558et9f52d5a207d76dd7@mail.gmail.com> > IMO I don't think it gives away enough to easily go look for the bug myself. It does for J2EE servers, those things are notoriously vulnerable and the bugs are usually very easy to spot, just decompile the default servlets and poke around for a few hours (or less, Much Less) and I guarantee you will find something of interest ;>. -isaac On Wed, Oct 15, 2008 at 3:27 AM, Matthew Wollenweber wrote: > Dave/Gleg, > > Every now and then some exploits, such as the below really interest me and > my team. But it would be helpful if announcements contained a bit more > information. I know you have to balance disclosure but a couple things that > might help: > > 1. What versions of the software are affected? > 2. Is the software in a common or default configuration? > 3. What security zone is required for the exploit to work? > 4. The exploit enables remote code execution? > 5. How reliable is the exploit (ballpark -- for example a buffer overflow > you've never seen fail or a complicated heap corruption bug that sometimes > works). > > For me, that's the basic information I want before purchasing an exploit and > > On Tue, 2008-10-14 at 12:35 -0400, Dave Aitel wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > D2's latest exploit pack has a couple cool tools in it: > 1. a malicious PDF file creator > 2. a malicious Java Applet > > If you're doing client side penetration tests, sometimes no exploit is > the best exploit. Both of these are "one click to own" things. > Immunity uses the D2 pack against our clients when we do penetration > tests. No one can write everything! > > And of course Gleg continues to produce interesting remotes in things > like J2EE servers. Luckily no one uses those, right? At this point > they have 280 additional modules for CANVAS which almost doubles the > size of CANVAS's standard exploit modules. > > And there are more third-party packs on the way! The value of these > tools is in the content built on top of them. > > - -dave > (hahaha at me at using the word ecosystem. Such a Microsofty word!) > P.S. Everyone should have the cojones to post their static analysis > responses to the list! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFI9MpUtehAhL0gheoRAtUeAJ9/PAR7t2MTDG3n/kb5REqFixELcQCbBb+H > VEOK6SFmBQpLO5FXHpa/rcs= > =4b/h > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > -- > > Matthew Wollenweber > mjw at cyberwart.com > www.cyberwart.com/blog > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From joanna at invisiblethingslab.com Wed Oct 15 09:21:57 2008 From: joanna at invisiblethingslab.com (Joanna Rutkowska) Date: Wed, 15 Oct 2008 15:21:57 +0200 Subject: [Dailydave] Paper: Adventures with a certain Xen vulnerability Message-ID: <48F5EE75.9070709@invisiblethingslab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Invisible Things Lab is proud to present: "Adventures with a certain Xen vulnerability (in the PVFB backend)" by Rafal Wojtczuk *** Starring Xen 3.2.0, DomU (an ordinary virtual machine, paravirtualized), Dom0 (privileged administrative domain) running on FC8 with NX, ASLR and SELinux enabled, The Evil Hacker, and a certain vulnerability in the Frame Buffer backend. Plot The Evil Hacker escapes from DomU and gets into Dom0. Using clever ret-into-libc technique he succeeds with his attack on x86 architecture, despite the NX and ASLR deployed in Dom0 OS (Fedora Core 8). The Evil Hacker is also not discouraged by the fact that the target OS has SELinux protection enabled - he demonstrates how the particular SELinux policy for Xen, used by default on FC8, can be bypassed. Ultimately he gets full root access in Dom0. Rafal also discusses variation of the exploitation on x86_64 architecture - he partially succeeds, but his x64 exploit doesn't work in certain circumstances. *** Curious individuals can get the full paper here: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf *** This paper is one of the outcomes of a broader research into Xen and virtualization security sponsored by Phoenix Technologies. *** This paper is also a teaser for our upcoming Virtualization Security Training, that is scheduled for Spring 2009. Stay tuned for more details. *** Sincerely, Joanna Rutkowska CEO (and Head of PR:) Invisible Things Lab http://invisiblethingslab.com/ -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj17nAACgkQORdkotfEW87AyACgmUTikRl2+tccYINOaGkLT+zJ XbQAoKE0RVf9aQdlsrgc5kulIWLv5cdd =AVVP -----END PGP SIGNATURE----- From piercede at pdx.edu Wed Oct 15 18:57:22 2008 From: piercede at pdx.edu (Dean Pierce) Date: Wed, 15 Oct 2008 15:57:22 -0700 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <1224008866.14697.6.camel@melkor.cyberwart> References: <48F4CA55.90900@immunityinc.com> <1224008866.14697.6.camel@melkor.cyberwart> Message-ID: <48F67552.5050902@pdx.edu> If they even listed the affected software, wouldn't the vendor just buy up the module and fix the 0day? It would be interesting to see a list of older vulnerabilities, and maybe some mention their reliability just to see how it stacks up against other exploitation frameworks. Anyway, when you buy CANVAS, the most important thing you get is every exploit they come up with for the next year, so not even the researchers know what it is you are really buying. - DEAN Matthew Wollenweber wrote: > Dave/Gleg, > > Every now and then some exploits, such as the below really interest me > and my team. But it would be helpful if announcements contained a bit > more information. I know you have to balance disclosure but a couple > things that might help: > > 1. What versions of the software are affected? > 2. Is the software in a common or default configuration? > 3. What security zone is required for the exploit to work? > 4. The exploit enables remote code execution? > 5. How reliable is the exploit (ballpark -- for example a buffer > overflow you've never seen fail or a complicated heap corruption bug > that sometimes works). > > For me, that's the basic information I want before purchasing an exploit > and IMO I don't think it gives away enough to easily go look for the bug > myself. > > On Tue, 2008-10-14 at 12:35 -0400, Dave Aitel wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> D2's latest exploit pack has a couple cool tools in it: >> 1. a malicious PDF file creator >> 2. a malicious Java Applet >> >> If you're doing client side penetration tests, sometimes no exploit is >> the best exploit. Both of these are "one click to own" things. >> Immunity uses the D2 pack against our clients when we do penetration >> tests. No one can write everything! >> >> And of course Gleg continues to produce interesting remotes in things >> like J2EE servers. Luckily no one uses those, right? At this point >> they have 280 additional modules for CANVAS which almost doubles the >> size of CANVAS's standard exploit modules. >> >> And there are more third-party packs on the way! The value of these >> tools is in the content built on top of them. >> >> - -dave >> (hahaha at me at using the word ecosystem. Such a Microsofty word!) >> P.S. Everyone should have the cojones to post their static analysis >> responses to the list! >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFI9MpUtehAhL0gheoRAtUeAJ9/PAR7t2MTDG3n/kb5REqFixELcQCbBb+H >> VEOK6SFmBQpLO5FXHpa/rcs= >> =4b/h >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 mhtajik at gmail.com Thu Oct 16 04:40:15 2008 From: mhtajik at gmail.com (Mohammad Hosein) Date: Thu, 16 Oct 2008 12:10:15 +0330 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <48F67552.5050902@pdx.edu> References: <48F4CA55.90900@immunityinc.com> <1224008866.14697.6.camel@melkor.cyberwart> <48F67552.5050902@pdx.edu> Message-ID: <26f61db50810160140o67ba4975k107d7752c09359e@mail.gmail.com> most of the 0days - if not all - are targeting very rare software like Novel stuff and when you buy Canvas you buy 3 month worth of updates not a year . like Parity mentioned in his email i'd like the developers know that a more flexible licensing model and price would help them with a new market consist of freelancers and individuals who are in the pentest business and do not have huge load of cash the same as they dont earn such money easy like a company can do with an enterprise-grade pentest project . On Thu, Oct 16, 2008 at 2:27 AM, Dean Pierce wrote: > If they even listed the affected software, wouldn't the vendor just buy > up the module and fix the 0day? It would be interesting to see a list > of older vulnerabilities, and maybe some mention their reliability just > to see how it stacks up against other exploitation frameworks. > > Anyway, when you buy CANVAS, the most important thing you get is every > exploit they come up with for the next year, so not even the researchers > know what it is you are really buying. > > - DEAN > > Speaking as a freelancer, this is a constant challenge for me. Among the > research costs I can't really pass directly on to customers, there's stuff > like: > > CanSec: ~ $1800.00 (Maybe if I wasn't too lazy to submit a talk...) > BinDiff: $1330 > MSDN subscription: another couple grand > > So instead of going to CanSec, I stick to the inexpensive conferences > (Shmoocon, Toorcon, etc). And I buy MS products @ the MSFT company store as > needs require. And I just do without cool stuff like Bindiff. :( > > Anyway, I guess I'm chiming in here to suggest to Dragos & Halvar & others > that I'd love to buy their products / services, but paying full price is > just not economical for an indy player like myself. They could easily > capture additional revenue from the little market segment that's made up of > guys like me (go read Joel Spolsky's essay on differential pricing called > Camels & Rubber Duckies for hints). I'm not sure there's enough people in > my position to justify their going to the trouble, but I wish they would. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081016/c664d861/attachment-0001.htm From halvar at gmx.de Thu Oct 16 14:47:19 2008 From: halvar at gmx.de (Halvar Flake) Date: Thu, 16 Oct 2008 20:47:19 +0200 Subject: [Dailydave] Stuff you might have missed in the CANVAS Ecosystem In-Reply-To: <26f61db50810160140o67ba4975k107d7752c09359e@mail.gmail.com> References: <48F4CA55.90900@immunityinc.com> <1224008866.14697.6.camel@melkor.cyberwart> <48F67552.5050902@pdx.edu> <26f61db50810160140o67ba4975k107d7752c09359e@mail.gmail.com> Message-ID: <48F78C37.5040405@gmx.de> Hey all, something that I have mentioned on my blog in the past, but that I wish to reiterate here: We have an academic licensing mode where you can get both BinDiff and BinNavi for 50 EU each if you satisfy the following conditions: 1) You're a student at either a university or high school 2) You're willing to provide full contact info and sign that you won't redistribute our stuff 3) You have a (semi-)cool idea for which you want to use our products, and you agree that you will write a 5-10 page paper on how you used our tools for your idea. You also allow us to put this paper on our webpage. 4) You promise to provide copious amounts of feedback. The idea behind this is the following: You get our tools for almost free, and we get stuff we can use for advertising, feedback, and motivated folks using our tools. Cheers, Halvar From coley at mitre.org Thu Oct 16 19:53:37 2008 From: coley at mitre.org (Steven M. Christey) Date: Thu, 16 Oct 2008 19:53:37 -0400 (EDT) Subject: [Dailydave] The Static Analysis Market and You Message-ID: <200810162353.m9GNrb6a009416@faron.mitre.org> (apologies if this was posted twice) I supported the NIST effort, primarily as part of my CWE work at MITRE. Mostly, I was an evaluator of the tool results, but I've also assisted in some of the design and interpretation of results. I'll assume that people have read the SATE page and are somewhat familiar with how this project was run. First and foremost: SATE was an "exposition," not a scientific "experiment." We were trying to figure out the things that could be done to evaluate tools, NOT to actually evaluate tools. We've learned a lot, but the resulting human analysis is neither reliable nor repeatable. I'm not talking about the raw data that was generated by tools and dumped into a shareable format - the raw data generated from the tools is what it is. It's only our interpretations of the results, and what conclusions that should be drawn, that pose the greatest challenge - especially because you know damn well that someone somewhere is going to stack stats against each other and compare tools using data that we keep saying is not appropriate for that purpose). Quick definitions: - "NIST" - the SATE project leads working at NIST, namely Paul Black, Vadim Okun, and Romain Gaucher. - "we" - me and other people who evaluated tool results in SATE, some of whom do not work at NIST. - "tool" - a code scanning tool or service that participated in SATE. - "test case" - one of the open source packages that was analyzed. - "bug report" - a single item as identified by a tool. - "raw data" - raw data generated from the tools, including bug reports and supporting documents. - "evaluation" - the HUMAN determination as to whether the tool's bug report is correct or not (e.g. true/false positive). OK. SATE was a big job and we did what we could with the resources we had. There were several major factors affecting the analysis: - Number of bug reports. We only manually reviewed about 10% of 47,000 individual bug reports. Yes, 47 thousand. There's a lot of reasons why the number was that high: running tools in default mode, running early-generation tools like flawfinder, running tools against software that wasn't written with security in mind, etc. - After the exposition was underway, we realized that we needed to more precisely define what a "true" and "false" positive really meant. Consider a buffer overflow in a command line argument to an application that's only intended to be run by the administrator. Sometimes this was evaluated as a false positive, sometimes as a true positive. It's a genuine bug - but how much do you care? Then there's stuff that's true, but it's not necessarily a bug, and you don't necessarily care - consider the failure to use symbolic names in security-critical constants (CWE-547) or general code-quality assessments (not security, but important for many people). That's some of the easy stuff. Eventually, we (the evaluator team) settled on a crude definition for true/false positives, but that was *after* we'd already been evaluating bug reports for a while. Due to the scale of the effort, we didn't always go back to fix our results. So, the evaluation data is inconsistent. Then there's the question of false negatives. If tool X doesn't even TEST for a specific type of issue, then is it really a false negative? - NIST designed a database/web interface for importing the results from various tools, and evaluating each bug report. They used a simple exchange format that, in retrospect, was not expressive enough. We did NOT run the tools live. I think NIST did a solid job in developing the database and web interface, especially in such a short amount of time. For example, you can look at a line of code and quickly find which other tools reported issues for surrounding lines of code. Since we used the database instead of the live tools, we did not have access to the analysis environment that the tools had. Some of these tools have powerful capabilities (e.g. navigation and visualization) that help to interpret results. So, this led to increased labor and a lot of ambiguous results (*you* try following a logic chain that's 20-deep. Well OK, *you* can because you're special, but I can't. Not all day anyway.) So, while the database was nice for browsing through multiple issues from multiple tools, and doing lots of basic data hacking, the lack of integration of live tools was really limiting. - We had a fairly large number of issues that we thought were ambiguous, i.e. we couldn't tell if they were correct or not, even accounting for the lack of live analysis environment from the tools. Sometimes, this was because we needed to know more about the test case's operating context than we had. For example, I remember one issue where I couldn't be sure if it was a true/false positive. The issue was a false positive on every platform but Solaris. But for Solaris, I had to know whether a certain field of a low-level OS data structure would ever exceed 47 bytes. The Solaris include files that I looked at didn't exceed 47 bytes, but neither did I look at every relevant version (then there's SPARC vs. x86). - We did not directly address potential sources of bias. There was a general focus on "high-priority" issues (however THAT's defined - tools varied), but there were lots of differences how we did the human evaluation. For example, during the course of my evaluation period (a few weeks), I concentrated mostly on the C programs, not Java; sometimes I concentrated on a single test case or one file, sometimes on a single type of vulnerability; sometimes just on a single tool (maybe I was trolling for new CWE entries, or just curious); and sometimes, I just casually browsed through the raw results and grabbed whatever I thought looked interesting. Generally, I stuck with one particular test case. Obviously, my individual approach was very informal. Others on the team were more focused, but there were still different biases at play. So, the evaluation data is NOT representative. - We did not schedule enough time for a review period, so tool vendors didn't have enough time to get back to us on the results of our evaluations. So the evaluation data - already imperfect for reasons I've discussed - has not been sufficiently validated. - As implied by previous results, false positive rates cannot be determined because we weren't always correct in identifying them, and our analysis only covered 10% of the data. - People are very interested in false negatives. A multi-tool evaluation could help estimate these rates (just see which true positives weren't mentioned by other tools) - however, you can't do this with incorrect data! Plus what I mentioned before - is it really a false negative if a tool doesn't look for that type of issue? All that said: - I'm glad to have participated in SATE. People will criticize it, and/or misinterpret the results, but hopefully everyone will learn from it. - I believe that one of the best outcomes of this exposition, which everybody will ignore, is the lessons learned with respect to the database, web interface, exchange format, and the improved awareness of how tools might generate different reports for the same thing. - We did find some examples of false positives. For my contribution to the December release, I plan to include specific code examples to help highlight some of these areas; if one tool missed it, then maybe others will, too. - We did find differences between tool results. In December, I'll provide more details on WHY I think some of those differences might exist. In one example, tool X flagged the failure to check the result of a malloc() call; tool Y flagged the line of code that did the NULL pointer dereference. They were reporting two links in the same chain, but it looks like the results are different. Consider layering issues. A software security auditor might flag the whole test case, saying "you don't have a centralized input validation mechanism." That design-level feature could translate into numerous XSS or SQL injection errors by a code-auditing tool. The issues are related, and kind of the same, but mostly not. There are other counting issues, too. Consider a library function that, if called incorrectly, contains a buffer overflow. One tool might flag the library function as one bug; a different tool might flag 20 distinct code paths, where each called that library function with potentially dangerous input. Is it one bug or 20? (Ask that question about strcpy() if you don't get my drift). Obviously, these differences will seriously affect your results. - If it was sometimes difficult for me to interpret the results (even allowing for the lack of access to live tools), then it will probably be a challenge for a lot of developers who don't do security all the time. Maybe the code samples we analyzed were particularly complex, but I don't think so. There will probably be significant disagreement with me on this sobering conclusion. - The SAMATE people at NIST hope to perform a modified "exposition" in 2009, and this will probably involve important design enhancements. In closing - we didn't do SATE to compare tools; we wanted to explore methods for understanding their capabilities. The evaluation data that was generated is not suitable for comparing tools because it's inaccurate and incomplete. But there was a lot of useful raw data, the database design and exchange format were a good start, and we learned a lot that will be covered more extensively in December. - Steve From dave at immunityinc.com Fri Oct 17 11:42:42 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 17 Oct 2008 11:42:42 -0400 Subject: [Dailydave] IPP +SMB FTW Message-ID: <48F8B272.50703@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some thoughts on the IPP vulnerability follow. C.F. http://www.kb.cert.org/vuls/id/793233 as quoted below. """ IPP is an IP-based network protocol that allows remote printing and printer management. On Windows 2000 and XP, IIS comes with IPP enabled by default. IPP is optional on Windows 2003 systems. IPP by default is configured to only allow authenticated users, however it may be configured to allow unauthenticated connections. The Microsoft Windows IPP component, which is provided by msw3prt.dll, contains an integer overflow vulnerability, which results in an overflow of heap memory. By creating a specific HTTP POST to the vulnerable server, the IPP server will attempt to connect to a printer that is specified by the attacker. If this printer returns a malformed JOB_INFO_2 structure, the integer overflow vulnerability in IPP may be triggered, resulting in a four-byte memory overwrite, and eventually code execution on the IPP server. This vulnerability is being exploited in the wild. """ So one thing that's interesting to see that the CERT note on this is the most informative of all the public notes. I still have a lot of questions though, even after Kostya wrote up the POC for CANVAS. (Both this bug and the SMB overflow are here: http://www.immunityinc.com/ceu-index.shtml) 1. What platforms were being exploited in the wild? Was it the "easy heap overflows" Windows 2000? Or the "Not easy and not default Windows 2003 and 2008". Was it XP SP2/3 on IIS 5.1? 2. Did some target have IPP set up as Non-Authenticated access? 3. How would you discover something like this in the wild considering that you can do HTTPS and possibly SEALED SMB/RPC? 4. How did the attackers find this? 5. Is there a complexity limit for data flow and control flow after which automated static analysis will fail but humans will succeed? - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI+LJytehAhL0gheoRAgDwAJ9Pzmm8JvnAxbKT3hM2N34gdGDHXwCfb/TC JxS/RdpZ/gzd4b0Igd8XJqk= =RJwy -----END PGP SIGNATURE----- From dave.korn at artimi.com Fri Oct 17 12:57:22 2008 From: dave.korn at artimi.com (Dave Korn) Date: Fri, 17 Oct 2008 17:57:22 +0100 Subject: [Dailydave] IPP +SMB FTW In-Reply-To: <48F8B272.50703@immunityinc.com> References: <48F8B272.50703@immunityinc.com> Message-ID: <015d01c93079$6f180130$9601a8c0@CAM.ARTIMI.COM> Dave Aitel wrote on 17 October 2008 16:43: > Some thoughts on the IPP vulnerability follow. IPP!!!! :) :) :) Aww, now I'm getting all nostalgic for the good ol' CodeRed days! > C.F. http://www.kb.cert.org/vuls/id/793233 as quoted below. I like this quote: "Block outbound SMB traffic This and other vulnerabilities may be mitigated by blocking outbound SMB traffic from your network to the internet." Allowing it in /either/ direction is utterly nutso if you ask me... > 2. Did some target have IPP set up as Non-Authenticated access? It would make sense to open up as much non-authenticated access as you can if you were running a honeypot. Then again, there have been plenty of reasonably-successful worms that spread by guessing common u:p combinations to get access to SMB file shares. > 3. How would you discover something like this in the wild considering > that you can do HTTPS and possibly SEALED SMB/RPC? Bet the attackers didn't bother. Only a very few seriously professional types make the least effort to conceal their traffic. > 4. How did the attackers find this? My guess would be msrpc fuzzing the printer protocol found them the overflow by malformed JOB_INFO2 struct, and then a bit of imagination was used to think up a way to tickle it remotely by using IIS/IPP. > 5. Is there a complexity limit for data flow and control flow after > which automated static analysis will fail but humans will succeed? Well as I said in the last thread, I reckon there is, and I reckon it's a whole lot closer to the "Hello World" end of the software-complexity spectrum than it is to the IIS.exe end. cheers, DaveK -- Can't think of a witty .sigline today.... From rodney at pnresearch.com Fri Oct 17 14:12:42 2008 From: rodney at pnresearch.com (Rodney Thayer) Date: Fri, 17 Oct 2008 11:12:42 -0700 Subject: [Dailydave] IPP +SMB FTW In-Reply-To: <48F8B272.50703@immunityinc.com> References: <48F8B272.50703@immunityinc.com> Message-ID: <48F8D59A.6000908@pnresearch.com> Dave Aitel wrote: > Some thoughts on the IPP vulnerability follow. > > 3. How would you discover something like this in the wild considering > that you can do HTTPS and possibly SEALED SMB/RPC? Printer drivers (on client systems) are fairly loud. If your office printer is networked, you're shouting it's IP address every time you connect to the wireless net at Defcon ;-) But seriously, I would think there would be plenty of printer/upnp/"plug-and-play-means-overshare-on-the-net" traffic around to identify these HTTP requests. HTTPS and sealed SMB/RPC would be running off the machine identity, wouldn't they? So they'd get properly authenticated into an encrypted IPP conversation for free, wouldnt' they? > 5. Is there a complexity limit for data flow and control flow after > which automated static analysis will fail but humans will succeed? Are you saying this sounds more complex than static code analysis would find? I assume that any place the vendor bleeds out network traffic (like printers, upnp, iphone multicast DNS, etc.) is an opportunity to identify a software component to statically analyze. From tomb at owasp.org Fri Oct 17 23:04:55 2008 From: tomb at owasp.org (Tom Brennan - OWASP) Date: Fri, 17 Oct 2008 23:04:55 -0400 Subject: [Dailydave] See Dave Talk.... Message-ID: Since this is the Daily Dave..... if you want to see Dave and others from the OWASP 2008 NYC event talk see: http://www.owasp.tv all the talks all the video and yes FREE brennan From prabu at hackinthebox.org Sat Oct 18 19:08:16 2008 From: prabu at hackinthebox.org (Praburaajan) Date: Sun, 19 Oct 2008 07:08:16 +0800 Subject: [Dailydave] HITBSecConf2008 - Malaysia: Online registration closes on 24th Oct Message-ID: <48FA6C60.5010508@hackinthebox.org> This is a reminder that online registration for HITBSecConf2008 - Malaysia, the largest network security conference in Asia and the Middle East, closes on the 24th of October - walk in registrations are still accepted thereafter but prices increase to MYR1099. To book your seats online, please register through: http://conference.hitb.org/hitbsecconf2008kl/register/ 27th & 28th October 2008 ======================== TECH TRAINING 1 - Structured Network Threat Analysis and Forensics Trainers: Meling Mudin (spoonfork) and Lee Chin Sheng (geek00l) Seats Left: 3 TECH TRAINING 2 - Bluetooth, RFID & Wireless Hacking - UPDATED COURSE CONTENTS! Trainers: Andrew 'Q' Righter (HacDC) and King Tuna Seats Left: 9 TECH TRAINING 3 - Web Application Security - Advanced Attacks and Defense Trainer: Shreeraj Shah (Director, BlueInfy) Seats Left: CLASS IS FULL TECH TRAINING 4 - The Exploit Laboratory 3.0 - UPDATED COURSE CONTENTS! Trainers: Saumil Shah (Founder/CEO, Net-Square) & SK Chong (Security Consultant, SCAN Associates Bhd.) Seats Left: 6 Keynote Address - 29th & 30th October 2008 ========================================== KEYNOTE 1 - "The Art of Click-Jacking" - Jeremiah Grossman (Founder & Chief Technology Officer, White Hat Security.) KEYNOTE 2 - "Cyberwar is Bullshit" - Marcus Ranum (Chief Security Officer, Tenable Network Security) KEYNOTE 3 - "Welcome to the 0wned World" - Dr. Anton Chuvakin (Chief Research Officer, Log Logic Inc.) KEYNOTE 4 - "Dissolving an Industry as a Hobby" - Peter Sunde [brokep] and Fredrik Neij [TiAMO] (Founders of The Pirate Bay - TPB) FULL CONFERENCE AGENDA: http://conference.hitb.org/hitbsecconf2008kl/agenda.htm From crioux at noctem.org Sun Oct 19 18:08:37 2008 From: crioux at noctem.org (Christien Rioux) Date: Sun, 19 Oct 2008 18:08:37 -0400 Subject: [Dailydave] Announcing SOURCE Boston 2009 In-Reply-To: <5680af290810091723g92f1c28q353464f8ee73b952@mail.gmail.com> References: <5680af290810091723g92f1c28q353464f8ee73b952@mail.gmail.com> Message-ID: <5680af290810191508s731ee77er8856328c09b3b0e@mail.gmail.com> ------------------------------------------------------------------------ ________ __ _____ _________ ___ ____ ______________ _ __ / __/ __ \/ / / / _ \/ ___/ __/ / _ )/ __ \/ __/_ __/ __ \/ |/ / _\ \/ /_/ / /_/ / , _/ /__/ _/ / _ / /_/ /\ \ / / / /_/ / / /___/\____/\____/_/|_|\___/___/ /____/\____/___/ /_/ \____/_/|_/ ___ ___ ___ ___ |_ |/ _ \/ _ \/ _ \ / __// // / // /\_, / /____/\___/\___//___/ /// ANNOUNCING SOURCE Boston 2009 /// March 9th-13th, 2009 www.sourceconference.com SOURCE Boston 2009 is taking place on March 9th-13th at our new location, the Seaport Hotel in downtown Boston. ---====/ Confirmed Speakers /=========--------- // Keynotes // Marcus Ranum Peter Kuper Amit Yoran // Sessions // Dino Dai Zovi James Atkinson Adam Shostack Jeremiah Grossman Rich Mogull David Mortman Ero Carrera Joe Grand (aka "Kingpin") Chris Hoff Marty Roesch Bruce Dang Jose Nazario, PhD Lee Kushner Peiter "Mudge" Zatko Call for Papers for SOURCE Boston 2009! Speakers wishing to participate should complete a proposal by November 30th. ---====/ Training /=========--------- This year, we will be adding two days of training (March 9th-10th) 1. Hardware Hacking ? Joe "Kingpin" Grand 2. Mobile Device Programming ? Christien Rioux 3. Practical Security Architecture - Rob Cheyne 4. Applied Security Visualization - Raffael Marty ---====/ Extras /=========--------- Security Business Competition Professional Networking Events Hardware Hacking Competitions Security Trivia Round Table Discussions Product Educations Talks Student/Mentor Program Live Podcasts Lightning Talks Expert Panels ------------------------------------------------------------------------ SOURCE Boston 2009 - March 9th-13th -- http://www.sourceconference.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081019/751e7edf/attachment.htm From dailydave at vuagnoux.com Mon Oct 20 06:45:40 2008 From: dailydave at vuagnoux.com (Martin Vuagnoux) Date: Mon, 20 Oct 2008 12:45:40 +0200 Subject: [Dailydave] All your keyboard are belong to us Message-ID: <48FC6154.3000402@vuagnoux.com> Hi list, Here you can find a video of our compromising electromagnetic emanations attacks on (wired) keyboards. The objective is to show that wired keyboards may be eavesdropped remotely and passively. PS/2, USB and Laptop keyboards have been tested. Since it's an academic research, the paper will come later. It's more related to hardware security but it works in practice, so why not exploit it ? http://lasecwww.epfl.ch/keyboard/ Best regards, Martin Vuagnoux From dailydave at vuagnoux.com Mon Oct 20 10:42:21 2008 From: dailydave at vuagnoux.com (Martin Vuagnoux) Date: Mon, 20 Oct 2008 16:42:21 +0200 Subject: [Dailydave] All your keyboard are belong to us In-Reply-To: <48FC8D91.7000308@packetfault.org> References: <48FC6154.3000402@vuagnoux.com> <48FC8D91.7000308@packetfault.org> Message-ID: <48FC98CD.8000500@vuagnoux.com> Francois ROPERT a ?crit : > Martin Vuagnoux a ?crit : > >> Hi list, >> >> > Hi Martin, > > Hi Francois, >> Here you can find a video of our compromising electromagnetic emanations >> attacks on (wired) keyboards. The objective is to show that wired >> keyboards may be eavesdropped remotely and passively. PS/2, USB and >> Laptop keyboards have been tested. Since it's an academic research, the >> paper will come later. >> >> It's more related to hardware security but it works in practice, so why >> not exploit it ? >> > > This looks like very 80's and reminds me > http://cryptome.org/tempest-leak.htm > > Anything new I can't catch under the switzerland sun ? > Of course we know cryptome and all TEMPEST stuff. These things motivated our research indeed. Our objective to see if these attacks can be applied to modern keyboards. If these attacks are known, why keyboards are still vulnerable ? We found that modern keyboards (especially USB and Laptop-based) use a different technology, which avoid (partially) known attacks. Even PS/2 keyboard changed since the 80's, the electromagnetic leaks are not the same. Our research shows that there is other ways to recover keystrokes even with new keyboards. Again, our objective was to give *practical* evidences that modern keyboards can still be remotely eavesdropped with accessible equipments. I heard that NSA is able to eavesdrop keyboards at a distance up to 200 meters. This paper shows (I hope for the first time in the open litterature) exactly how to do it at a much smaller range. However, this attack can be practically applied and exploited for real, with currently sold keyboards. So the danger is still here, isn't ? Note that TEMPEST compliant keyboards exist in the stores (~ 500$ the keyboard) proving that Agencies are probably protected against these attacks. I hope I answered to your question. Martin >> http://lasecwww.epfl.ch/keyboard/ >> >> Best regards, >> >> Martin Vuagnoux >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> >> > > Cheers, > From dailydave at vuagnoux.com Mon Oct 20 10:56:18 2008 From: dailydave at vuagnoux.com (Martin Vuagnoux) Date: Mon, 20 Oct 2008 16:56:18 +0200 Subject: [Dailydave] All your keyboard are belong to us In-Reply-To: <829578055.20081020162345@Zoller.lu> References: <48FC6154.3000402@vuagnoux.com> <829578055.20081020162345@Zoller.lu> Message-ID: <48FC9C12.4010806@vuagnoux.com> Thierry Zoller a ?crit : > Dear Martin, > > Very interesting, could you elaborate on your experiences, with a > running laptop (lcd/tft turned on) ? Is the attack still feasiable to > a 100% ? What influences does the emissions from the PC or Screen have > and do they make the attack "impossible" ? > > > Hi Thierry, We removed power supply and LCD monitor because there are already known attacks which use them. In the paper we show how they can be used to improve the eavesdropping rang. If you look at the video, you see three LCD displays in the room, with 3 computers (I don't count the laptop). They were all running and emitting electromagnetic waves, but the frequency range used by keyboards is preserved. It's generally not a problem. Printers may create bigger interferences when they are printing. In the paper, we show that we can even distinguish multiple keyboards (sharing the same model) in a computer room (our student computer which PC's with LCD and CRT monitors). We spend a lot of time to have a practical attack, which can be really used. These videos show the worst case for us: 802.11n base stations and something like 60 computers on the same floor with a computer cluster and printers just 2 room away. However, I cannot garantee that these attacks are 100% reliable. We tried to do our best to have more than just a proof of concept which works in an anechoidal room. I can say that it took a *lot* of time to go from the anechoidal room to a real one. Martin From dave at immunityinc.com Thu Oct 23 13:45:33 2008 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 23 Oct 2008 13:45:33 -0400 Subject: [Dailydave] A bad month for MS! Message-ID: <4900B83D.7050506@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Recently Kostya finished off the IPP exploit (MS08-062) which turns out to be much more useful than I expected for penetration tests. Although most penetration tests start out "blind" and you don't have a username and password, in the real world, a hacker WOULD have a username or password to the domain, if it's big enough. But since we rarely do , I was happy to see that on our latest penetration test there were several machines set up to offer internet printing anonymously. Of course, in this particular case, proper network exfiltration filtering prevented them from getting exploited, but it was interesting to see real world machines vulnerable to such a thing. The question you always have is "How reliable is reliable" and I'd have to say that Kostya's IPP exploit is probably 100% against standard IIS 5.0, for those of you still running that (welcome to 2008 :>!). MS08-062 is not a bug you would find with a fuzzer, so having people vulnerable by default makes it obvious that there was a lot of value to whoever found it, and they were probably using it pretty widely for them to have gotten caught. This is worse news for MS than it originally seemed. This server service bug, on the other hand, is exactly as bad as it would seem. It's the kind of news for Microsoft (and their customers, of course) that creates real-world sales problems (much like the RedHat compromise should have). The world has changed a lot since the last time a remote vulnerability of this nature came out - now the distribution of high quality exploits is going to be essentially instantaneous. It will be interesting to see how organizations react to this - or if they react at all. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJALg9tehAhL0gheoRAu9PAJ97HRWZbgR7Eia02u1oCysP8ah6KgCeJ1uI esxhUFYRvz9+6Wlj0nu774w= =Bv+0 -----END PGP SIGNATURE----- From olef.anderson at gmail.com Thu Oct 23 14:27:28 2008 From: olef.anderson at gmail.com (Olef Anderson) Date: Thu, 23 Oct 2008 11:27:28 -0700 Subject: [Dailydave] A bad month for MS! In-Reply-To: <4900B83D.7050506@immunityinc.com> References: <4900B83D.7050506@immunityinc.com> Message-ID: <9b4f936f0810231127gd129438u7ba884fc699497f6@mail.gmail.com> Funny! how you just said that! I can quote myself saying "what a bad month for China" just this morning, having 2 of your arsenal die in one month must hurt bad but certainly they should have plenty more handy. I am hopeful that U.S. will catch up on that front whenever the federal employees stop padding each other on the back and say how great they are just because they happen to use IOCTL's for Solaris shellcodes. Maybe when everybody is done blowing each other off, we can do some catching up ;> Also god forbid, we might even consider not reporting bugs anymore! regards, Olef On Thu, Oct 23, 2008 at 10:45 AM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Recently Kostya finished off the IPP exploit (MS08-062) which turns > out to be much more useful than I expected for penetration tests. > Although most penetration tests start out "blind" and you don't have a > username and password, in the real world, a hacker WOULD have a > username or password to the domain, if it's big enough. But since we > rarely do , I was happy to see that on our latest penetration test > there were several machines set up to offer internet printing > anonymously. Of course, in this particular case, proper network > exfiltration filtering prevented them from getting exploited, but it > was interesting to see real world machines vulnerable to such a thing. > > The question you always have is "How reliable is reliable" and I'd > have to say that Kostya's IPP exploit is probably 100% against > standard IIS 5.0, for those of you still running that (welcome to 2008 > :>!). MS08-062 is not a bug you would find with a fuzzer, so having > people vulnerable by default makes it obvious that there was a lot of > value to whoever found it, and they were probably using it pretty > widely for them to have gotten caught. This is worse news for MS than > it originally seemed. > > This server service bug, on the other hand, is exactly as bad as it > would seem. It's the kind of news for Microsoft (and their customers, > of course) that creates real-world sales problems (much like the > RedHat compromise should have). The world has changed a lot since the > last time a remote vulnerability of this nature came out - now the > distribution of high quality exploits is going to be essentially > instantaneous. > > It will be interesting to see how organizations react to this - or if > they react at all. > > - -dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJALg9tehAhL0gheoRAu9PAJ97HRWZbgR7Eia02u1oCysP8ah6KgCeJ1uI > esxhUFYRvz9+6Wlj0nu774w= > =Bv+0 > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081023/bbcbda0b/attachment.htm From deepsec at deepsec.net Thu Oct 23 14:31:40 2008 From: deepsec at deepsec.net (DeepSec IDSC Vienna) Date: Thu, 23 Oct 2008 20:31:40 +0200 Subject: [Dailydave] Last Call for DeepSec IDSC 2008 in Vienna Message-ID: <20081023203140.653ac657@agamemnon.luchs.at> The DeepSec In Depth Security Conference is happy to announce the planned schedule for this year's event from November 11th to 14th in Vienna, Austria. The schedule (which can be found at https://deepsec.net/schedule) covers a range of topics including botnet analysis, web application security, malware detection/analysis, legal and administrative issues, secure coding and code review, hardware and firmware attacks, attacking/hardening databases, social engineering, dealing with rich Internet applications (RIAs) and, of course, the Digital Armageddon (coming soon to a server near you). Key speakers include: - Adam Laurie (http://rfidiot.org/) - Ivan Krsti? (http://radian.org/) - Johnny Long (http://johnny.ihackstuff.com/) - Gadi Evron (http://gadievron.blogspot.com/) In addition Matt Jonkman will present a new project about the development of a next-generation intrusion detection and prevention engine. Feedback of the community is highly welcome! Registration is open at: https://deepsec.net/register/ Please make sure to book your tickets in time, we have only a _limited_ number! We also offer two days of in-depth workshops on selected topics, designed for software developers, security researchers and sysadmins: ? Improving Code with Destructive Data (Heikki Kortti and Jukka Taimisto) ? Security Audit and Hardening of Java based Software (Marc Schoenefeld) ? The Exploit Laboratory (Saumil Udayan Shah) ? Design and Implementation of Security Awareness Campaigns (Stefan Schumacher) ? Advanced Malware Deobfuscation (Scott Lambert) ? Protocol and Traffic Analysis for Snort Signature (Matt Jonkman) ? Secure Application Coding for Enterprise Software (Vimal Patel) The DeepSec IDSC is sponsored by CERT.at, Cisco, Microsoft, Sec Consult, Global Knowledge Austria/Germany and IronPort. DeepSec Organisation Team. https://deepsec.net/contact Internet Access at the conference is provided by: http://www.nets.at/ -- DeepSec In-Depth Security Conference November 11nd to 14th 2008, Vienna, Austria https://deepsec.net/ From dave at immunityinc.com Thu Oct 23 16:21:07 2008 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 23 Oct 2008 16:21:07 -0400 Subject: [Dailydave] Times up! Message-ID: <4900DCB3.2050303@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It takes two hours for Kostya to go from Bulletin to reliable control of EIP for MS08-067. What a great bug! I'm not going to spoil the fun for people still working on it, but it's very cute, like a new puppy, or an angry toddler! - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJANyztehAhL0gheoRAkagAJ9mfYTNm6MLge+7SpfyHdCxEm0sjwCfaX8Z UeOP62IUbC6sbB7qzKvE5wQ= =l7dt -----END PGP SIGNATURE----- From hybridus at gmail.com Thu Oct 23 16:57:35 2008 From: hybridus at gmail.com (Hybridus) Date: Thu, 23 Oct 2008 23:57:35 +0300 Subject: [Dailydave] Times up! In-Reply-To: <4900DCB3.2050303@immunityinc.com> References: <4900DCB3.2050303@immunityinc.com> Message-ID: <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> Excited. Do you also expect a worm-storm for this vulnerability? -BC On Thu, Oct 23, 2008 at 11:21 PM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It takes two hours for Kostya to go from Bulletin to reliable control > of EIP for MS08-067. What a great bug! I'm not going to spoil the fun > for people still working on it, but it's very cute, like a new puppy, > or an angry toddler! > > - -dave > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJANyztehAhL0gheoRAkagAJ9mfYTNm6MLge+7SpfyHdCxEm0sjwCfaX8Z > UeOP62IUbC6sbB7qzKvE5wQ= > =l7dt > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081023/9a23ca3e/attachment.htm From thouth at gmail.com Thu Oct 23 21:45:26 2008 From: thouth at gmail.com (Fionnbharr) Date: Fri, 24 Oct 2008 12:45:26 +1100 Subject: [Dailydave] Times up! In-Reply-To: <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> Message-ID: <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> http://blog.threatexpert.com/2008/10/gimmiva-exploits-zero-day-vulnerability.html "Critical vulnerability in Server Service has only been patched by Microsoft (MS08-067), as a new worm called Gimmiv.A has been found exploiting it in-the-wild." 2008/10/24 Hybridus : > Excited. > Do you also expect a worm-storm for this vulnerability? > > -BC > > On Thu, Oct 23, 2008 at 11:21 PM, Dave Aitel wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> It takes two hours for Kostya to go from Bulletin to reliable control >> of EIP for MS08-067. What a great bug! I'm not going to spoil the fun >> for people still working on it, but it's very cute, like a new puppy, >> or an angry toddler! >> >> - -dave >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFJANyztehAhL0gheoRAkagAJ9mfYTNm6MLge+7SpfyHdCxEm0sjwCfaX8Z >> UeOP62IUbC6sbB7qzKvE5wQ= >> =l7dt >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 mike at enoch.org Fri Oct 24 02:36:36 2008 From: mike at enoch.org (Mike Johnson) Date: Thu, 23 Oct 2008 23:36:36 -0700 Subject: [Dailydave] Times up! In-Reply-To: <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> Message-ID: <49016CF4.7000200@enoch.org> Fionnbharr wrote: > http://blog.threatexpert.com/2008/10/gimmiva-exploits-zero-day-vulnerability.html > > "Critical vulnerability in Server Service has only been patched by > Microsoft (MS08-067), as a new worm called Gimmiv.A has been found > exploiting it in-the-wild." Just to split hairs, Gimmiv is a trojan, not a worm. It's just a keylogger. It in and of itself does not spread. I have no idea why the Threatexpert blogger called it a worm, everyone else calls it a trojan. While I do not claim to be an expert, the samples I have seen with my own eyes are trojans and don't have the ability to spread. That said, it won't take much for someone to write self-replicating code exploiting this vulnerability. Mike From alex at sotirov.net Fri Oct 24 05:40:30 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Fri, 24 Oct 2008 02:40:30 -0700 Subject: [Dailydave] Times up! In-Reply-To: <4900DCB3.2050303@immunityinc.com> References: <4900DCB3.2050303@immunityinc.com> Message-ID: <20081024094030.GA74867@dsl093-068-005.sfo1.dsl.speakeasy.net> Here's the decompiled code of the function is anybody is curious: http://www.phreedom.org/blog/2008/decompiling-ms08-067/ #include // This is the decompiled function sub_5B86A51B in netapi32.dll on XP SP3 int ms08_067(wchar_t* path) { wchar_t* p; wchar_t* q; wchar_t* previous_slash = NULL; wchar_t* current_slash = NULL; wchar_t ch; // If the path starts with a server name, skip it if ((path[0] == L'\\' || path[0] == L'/') && (path[1] == L'\\' || path[1] == L'/')) { p = path+2; while (*p != L'\\' || *p != L'/') { if (*p == L'\0') return 0; p++; } p++; // make path point after the server name path = p; // make sure the server name is followed by a single slash if (path[0] == L'\\' || path[0] == L'/') return 0; } if (path[0] == L'\0') // return if the path is empty return 1; // Iterate through the path and canonicalize ..\ and .\ p = path; while (1) { if (*p == L'\\') { // we have a slash if (current_slash == p-1) // don't allow consequtive slashes return 0; // store the locations of the current and previous slashes previous_slash = current_slash; current_slash = p; } else if (*p == L'.' && (current_slash == p-1 || p == path)) { // we have \. or ^. if (p[1] == L'.' && (p[2] == L'\\' || p[2] == L'\0')) { // we have a \..\, \..$, ^..\ or ^..$ sequence if (previous_slash == NULL) return 0; // example: aaa\bbb\..\ccc // ^ ^ ^ // | | &p[2] // | | // | current_slash // | // previous_slash ch = p[2]; wcscpy(previous_slash, &p[2]); if (ch == L'\0') return 1; current_slash = previous_slash; p = previous_slash; // find the slash before p // BUG: if previous_slash points to the beginning of the // string, we'll go beyond the start of the buffer // // example string: \a\..\ q = p-1; while (*q != L'\\' && q != path) q--; if (*p == L'\\') previous_slash = q; else previous_slash = NULL; } else if (p[1] == L'\\') { // we have \.\ or ^.\ if (current_slash != NULL) { wcscpy(current_slash, &p[1]); goto end_of_loop; } else { // current_slash == NULL wcscpy(p, p+2); goto end_of_loop; } } else if (p[1] != L'\0') { // we have \. or ^. followed by some other char if (current_slash != NULL) { p = current_slash; } *p = L'\0'; return 1; } } p++; end_of_loop: if (*p == L'\0') return 1; } } // Run this program to simulate the MS08-067 vulnerability int main() { return ms08_067(L"\\a\\..\\"); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20081024/2a167e9e/attachment-0001.pgp From dan at geer.org Fri Oct 24 07:00:21 2008 From: dan at geer.org (dan at geer.org) Date: Fri, 24 Oct 2008 07:00:21 -0400 Subject: [Dailydave] Times up! In-Reply-To: Your message of "Fri, 24 Oct 2008 12:45:26 +1100." <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> Message-ID: <20081024110021.8585133E35@absinthe.tinho.net> In the department of small ironies, the official report http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx displays nothing whatsoever unless you have Javascript turned on, which just seems apt somehow. --dan From dennis at backtrace.de Fri Oct 24 09:46:55 2008 From: dennis at backtrace.de (dennis at backtrace.de) Date: Fri, 24 Oct 2008 15:46:55 +0200 Subject: [Dailydave] Times up! In-Reply-To: <49016CF4.7000200@enoch.org> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <49016CF4.7000200@enoch.org> Message-ID: <20081024154655.wyjia0pbcowsk4kg@webmail.df.eu> Zitat von Mike Johnson : > Just to split hairs, Gimmiv is a trojan, not a worm. It's just a > keylogger. It in and of itself does not spread. I have no idea why the > Threatexpert blogger called it a worm, everyone else calls it a trojan. > While I do not claim to be an expert, the samples I have seen with my > own eyes are trojans and don't have the ability to spread. > > That said, it won't take much for someone to write self-replicating code > exploiting this vulnerability. > It is a Trojan (a password stealer, downloader) which downloads an additional (exploit) component named "basesvc.dll" as mentioned by ThreatExpert on their blog. If you have a look at that file, it is pretty evident that it might (I haven't gotten that far with my analysis) exploit the vulnerability fixed with MS08-076 and thus may be used to spread the password stealing Trojan. From dennis at backtrace.de Fri Oct 24 10:36:06 2008 From: dennis at backtrace.de (dennis at backtrace.de) Date: Fri, 24 Oct 2008 16:36:06 +0200 Subject: [Dailydave] Times up! In-Reply-To: <49016CF4.7000200@enoch.org> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <49016CF4.7000200@enoch.org> Message-ID: <20081024163606.rbcdfqkcxwcsg4kg@webmail.df.eu> > > That said, it won't take much for someone to write self-replicating code > exploiting this vulnerability. I can now confirm what has been stated on the ThreatExpert blog. I found shellcode at file offset 0x4712A (or address 0x1004712A in IDA). Simple "sub 1" payload decoder, imports urlmon/UrlDownloadToFileA and WinExec to download a copy of the Trojan. MD5 of basesvc.dll: 82ba009746da8603c463f37e381a42a4 Cheers From emf1123 at gmail.com Fri Oct 24 08:36:35 2008 From: emf1123 at gmail.com (Erik Fichtner) Date: Fri, 24 Oct 2008 08:36:35 -0400 Subject: [Dailydave] Times up! In-Reply-To: <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> Message-ID: <4901C153.9060807@gmail.com> Fionnbharr wrote: > http://blog.threatexpert.com/2008/10/gimmiva-exploits-zero-day-vulnerability.html > > "Critical vulnerability in Server Service has only been patched by > Microsoft (MS08-067), as a new worm called Gimmiv.A has been found > exploiting it in-the-wild." http://blogs.technet.com/msrc/archive/2008/10/23/ms08-067-released.aspx The MSRC blog posting seems to suggest that Gimmiv.A was how this bug was detected in the wild in the first place. "We have also have detection for the malware we found used in attacks exploiting this vulnerability (TrojanSpy:Win32/Gimmiv.A and TrojanSpy:Win32/Gimmiv.A.dll) in the signatures the MMPC is releasing today and sharing that information with our partners." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20081024/ca5234fc/attachment.pgp From badzmanaois at gmail.com Fri Oct 24 12:02:28 2008 From: badzmanaois at gmail.com (Salvador III Manaois) Date: Sat, 25 Oct 2008 00:02:28 +0800 Subject: [Dailydave] Times up! In-Reply-To: <4901C153.9060807@gmail.com> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <4901C153.9060807@gmail.com> Message-ID: Strangely enough, there was a spike in reported issues on SVCHOST.exe in the MS forums since last week (high memory utilization for one of the processes invoked by svchost.exe). If these were due to the malware exploiting the reported vulnerability, then the extent of infection could be significantly high (provided, of course, if the proliferation mechanism of the malware is first-rate). I doubt if most enterprise applied the patch immediately after the release considering that today is Friday (not much IT support during the weekend, at least for most imho). Good thing most AVs are now catching the Gimmiv malware and hopefully all its variants. But still, the hole has got to be plugged. Btw, any figures showing the extent of infection at this point? Regards, Salvador Manaois III MCITP | Server/Enterprise Admin MCSE MCSA C|EH CIWA Bytes and Badz: http://badzmanaois.blogspot.com From dave at immunityinc.com Fri Oct 24 12:38:53 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 24 Oct 2008 12:38:53 -0400 Subject: [Dailydave] Times up! In-Reply-To: <20081024163606.rbcdfqkcxwcsg4kg@webmail.df.eu> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <49016CF4.7000200@enoch.org> <20081024163606.rbcdfqkcxwcsg4kg@webmail.df.eu> Message-ID: <4901FA1D.8050101@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is that exploit reliable? It doesn't look like it's using the reliable variant (according to our very brief RE efforts here - and by "our", I mean "Kostya's"). Why would someone find such a cool exploit and then not make it reliable? Does it even work on XP SP2/3? - -dave dennis at backtrace.de wrote: >> That said, it won't take much for someone to write self-replicating code >> exploiting this vulnerability. > > > I can now confirm what has been stated on the ThreatExpert blog. I > found shellcode at > file offset 0x4712A (or address 0x1004712A in IDA). Simple "sub 1" > payload decoder, > imports urlmon/UrlDownloadToFileA and WinExec to download a copy of > the Trojan. > > MD5 of basesvc.dll: 82ba009746da8603c463f37e381a42a4 > > Cheers > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJAfodtehAhL0gheoRAgfRAJ4ic1KT/O4CULl6KGW6INQkwWsC6ACeLu3n e69eB8w23tu6WsebmIVcufE= =5SgP -----END PGP SIGNATURE----- From dave at immunityinc.com Fri Oct 24 13:15:58 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 24 Oct 2008 13:15:58 -0400 Subject: [Dailydave] Win32 C++ Programmer - exciting! :> Message-ID: <490202CE.9090300@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So in the midst of all the MSRPC excitement, it turns out Immunity is doing some MSRPC work ourselves... JOB ALERT WIN32 C++ PROGRAMMER WANTED! MUST have familiarity with the following technologies: C++ , Win32 Api, MSRPC (midl), Windows impersonation and security tokens, Active Directory (ADSI), and MMC plugins. Work to be performed from either the Miami Beach, FL or Buenos Aires, AR offices. MUST be able to start immediately. This position is a temporary contract position (~3 months), however depending on the applicant's skill set and work history, it could turn into a permanent, full-time position. All qualified applicants are encouraged to apply. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJAgLNtehAhL0gheoRAoCdAJsEfWWO1LgFffBjgB18EE6Slk96zwCcDg6G tSwFnPSBZgJCMi4A4l7WAT0= =u7La -----END PGP SIGNATURE----- From bmenrigh at ucsd.edu Fri Oct 24 14:18:33 2008 From: bmenrigh at ucsd.edu (Brandon Enright) Date: Fri, 24 Oct 2008 18:18:33 +0000 Subject: [Dailydave] Times up! In-Reply-To: <4901FA1D.8050101@immunityinc.com> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <49016CF4.7000200@enoch.org> <20081024163606.rbcdfqkcxwcsg4kg@webmail.df.eu> <4901FA1D.8050101@immunityinc.com> Message-ID: <20081024181833.08c8bb44@moray> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 24 Oct 2008 12:38:53 -0400 or thereabouts Dave Aitel wrote: > > Is that exploit reliable? It doesn't look like it's using the reliable > variant (according to our very brief RE efforts here - and by "our", I > mean "Kostya's"). In my (also brief) testing, no, it isn't reliable. > > Why would someone find such a cool exploit and then not make it > reliable? Does it even work on XP SP2/3? > I haven't been able to get it to go on SP2/3. Here are a few other observations about the relative lack of sophistication of the worm component: * It appears to only scan the local segment * It scans sequentially * It scans with a 1 second delay between hosts * Sometimes it scans a live host but for whatever reason does not attempt to exploit * When it does attempt to exploit a host, it follows up with a bunch of HTTP to the C&C servers I think the above shows a pattern of decisions by the author to *not* be aggressive. I suspect the author was hoping to compromise just a handful of machines and go unnoticed by the security community. As currently written, this malware doesn't appear able to cause a mass outbreak -- it's simply too slow and too unreliable. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCEX8ACgkQqaGPzAsl94LIHQCgxm9v0poMN2Bw2GpEwcqkAFNZ 7NcAoJ97pMkWJnkBi0PaxMUeR3bcR7bc =YMuY -----END PGP SIGNATURE----- From kostya.kortchinsky at gmail.com Fri Oct 24 16:25:09 2008 From: kostya.kortchinsky at gmail.com (Kostya Kortchinsky) Date: Fri, 24 Oct 2008 16:25:09 -0400 Subject: [Dailydave] Times up! In-Reply-To: <4900DCB3.2050303@immunityinc.com> References: <4900DCB3.2050303@immunityinc.com> Message-ID: <2f54ad410810241325y76f95f70g7b4c3d85ac8dfd95@mail.gmail.com> It's pretty cool to see that the new SetProcessDEPPolicy API, introduced by Microsoft with the SP3 turned out to make my life a lot easier when exploiting this bug on that platform. Even if it's only a warpper to NtSetInformationProcess, it gets the job done quicker! Cool to see a semi-default (sharing or firewall interaction still needed as far as I understood) remote for XP SP3! Great MS week! Kostya 2008/10/23 Dave Aitel > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It takes two hours for Kostya to go from Bulletin to reliable control > of EIP for MS08-067. What a great bug! I'm not going to spoil the fun > for people still working on it, but it's very cute, like a new puppy, > or an angry toddler! > > - -dave > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJANyztehAhL0gheoRAkagAJ9mfYTNm6MLge+7SpfyHdCxEm0sjwCfaX8Z > UeOP62IUbC6sbB7qzKvE5wQ= > =l7dt > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20081024/f7a58d7b/attachment.htm From rand at csis.dk Fri Oct 24 17:33:24 2008 From: rand at csis.dk (Dennis Rand) Date: Fri, 24 Oct 2008 23:33:24 +0200 Subject: [Dailydave] Times up! In-Reply-To: <20081024181833.08c8bb44@moray> References: <4900DCB3.2050303@immunityinc.com> <4863d70b0810231357y13f9f56ak73ca80b3d8c21d99@mail.gmail.com> <5ae653bf0810231845s40ccafadyb203d58ac7d9be0b@mail.gmail.com> <49016CF4.7000200@enoch.org> <20081024163606.rbcdfqkcxwcsg4kg@webmail.df.eu> <4901FA1D.8050101@immunityinc.com> <20081024181833.08c8bb44@moray> Message-ID: <0305B6D149A3AB4CB1C9DABFB72C5D7A7EE7F136C6@sofia.csis.local> Maybe the reason for it not being reliable is that it was used in a targeted attack prior to MS detecting it :) Just a small idea Best Regards, Dennis Rand PGP ID: 0xD54EB59D -- Malware/Security Researcher @ Combined Security and Integrated Services [CSIS] Vestergade 14 | DK-8660 Skanderborg | www.csis.dk CSIS: +45 88 13 60 30 | Mobile: +45 60 11 55 06 -- 5581f85b25f0d80fa84c69e7ca24d983 44f5fbaec45b7707dccf139a8c065961 391d6e762516ee1db3137c4d82eca7fb c67c348c37ea0d615bb88161cf3b3008 -- -----Oprindelig meddelelse----- Fra: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] P? vegne af Brandon Enright Sendt: 24. oktober 2008 20:19 Til: Dave Aitel Cc: dailydave at lists.immunitysec.com Emne: Re: [Dailydave] Times up! * PGP Signed by an unknown key On Fri, 24 Oct 2008 12:38:53 -0400 or thereabouts Dave Aitel wrote: > > Is that exploit reliable? It doesn't look like it's using the reliable > variant (according to our very brief RE efforts here - and by "our", I > mean "Kostya's"). In my (also brief) testing, no, it isn't reliable. > > Why would someone find such a cool exploit and then not make it > reliable? Does it even work on XP SP2/3? > I haven't been able to get it to go on SP2/3. Here are a few other observations about the relative lack of sophistication of the worm component: * It appears to only scan the local segment * It scans sequentially * It scans with a 1 second delay between hosts * Sometimes it scans a live host but for whatever reason does not attempt to exploit * When it does attempt to exploit a host, it follows up with a bunch of HTTP to the C&C servers I think the above shows a pattern of decisions by the author to *not* be aggressive. I suspect the author was hoping to compromise just a handful of machines and go unnoticed by the security community. As currently written, this malware doesn't appear able to cause a mass outbreak -- it's simply too slow and too unreliable. Brandon * Unknown Key * 0x0B25F782(L) _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From meddington at gmail.com Sat Oct 25 16:45:28 2008 From: meddington at gmail.com (Michael Eddington) Date: Sat, 25 Oct 2008 13:45:28 -0700 Subject: [Dailydave] Announce: Peach 2.2 Released Message-ID: <2db0cefa0810251345v78441da3qb7a0ebb62c9b2426@mail.gmail.com> I'm pleased to announce the release of Peach 2.2 the most widely used open source fuzzer. Peach is an easily extended fuzzing platform that can fuzz just about anything from file parsers and network protocols to COM objects and SQL stored procedures. Whats new: * Win32: Binary distribution with no dependencies * State model paths * Enable/disable mutations by node * Offset support via: - Offset-of relation - Seek element - Placement element * Peach Validation hex view * Updated and new mutators * Improved App Verifier support - Exclude specific stop codes - Custom check model list * Major speed improvements * New/updated supporting tools: - minset - Find the minimum set of files - missing - Gap analysis between files and pit - struct2peach - Convert 010 Templates to Peach * Numerous bug fixes Peach Documentation: http://peachfuzzer.com http://peachfuzzer.com/PeachQuickstart Peach downloads: * Win32 installer: http://downloads.sourceforge.net/peachfuzz/Peach-2.2.exe * Python source: http://downloads.sourceforge.net/peachfuzz/Peach-2.2-src.zip * Python dependencies: http://downloads.sourceforge.net/peachfuzz/Peach-2.2-dependencies-src.zip Peach Training @ PacSec 2008 in Tokyo, JP A two day Peach training class is being offered at PacSec 2008 in Tokyo, JP. This will be the first time Peach training has been offered in Asia. For additional information please see the course description. http://pacsec.jp/dojopeachfuzz.html From info at d2sec.com Mon Oct 27 18:48:04 2008 From: info at d2sec.com (DSquare Security) Date: Mon, 27 Oct 2008 17:48:04 -0500 Subject: [Dailydave] Owning Lotus Notes Server & Client Message-ID: <20081027224804.GA20769@d2sec.com> There are several ways to get a Lotus Notes ID during a pentest (access to a share with all the IDs, client side exploitation, ...) After that, if needed, you can crack the password ID with commercial or free tools (ID Password Recovery for example) So what can you do with an admin ID? Potentially two things: 1) Compromise the Lotus Notes server 2) Compromise the computer of the Lotus Notes clients D2Lotus is designed to help you in this kind of work. Here are two demonstrations of this tool: 1) Remote code execution on a Lotus Notes server: http://www.d2sec.com/d2lotus_1.htm 2) Remote code execution on computer user via Lotus Notes Client: http://www.d2sec.com/d2lotus_2.htm This tool will be released in the next update of D2 Exploitation Pack. -- DSquare Security, LLC http://www.d2sec.com From capsecdc at hushmail.com Tue Oct 28 21:32:42 2008 From: capsecdc at hushmail.com (capsecdc at hushmail.com) Date: Tue, 28 Oct 2008 21:32:42 -0400 Subject: [Dailydave] CapSec DC / October / 10/29/2008 Message-ID: <20081029013242.9B914158046@smtp.hushmail.com> Greetings Dave / DailyDavers! CapSec DC is a monthly social event for security industry types, located in the Washington DC / Beltway area. We're a spin off, of the growingly popular bay-sec event out in SF, and have thus-far managed to attract a good mix of local security folk, some of whom are household industry names. If you're looking for an audience for your latest sales pitch then this probably isn't the place for you, however if you're interested in coming along to socialize, have a drink and talk a little shop, we look forward to seeing you! Generally, occurring on the last Wednesday of each month, we meet around 7PM at Stetsons Bar at 16th and U (NW). Details for this months gathering (tomorrow, Wednesday 29th) are as follows: ----- CapSecDC Wednesday October 29th, 7:00 PM Stetson?s 1610 U St NW Washington DC 20009 If we are not in the back yard, we?ll probably be at the big tables near the jukeboxes. We reserve the right to change venues as the evening wears on ? previously we have walked down U Street, other venues might include The Saloon or DC9. ----- If you would like to attend and have any questions, please just reply to capsecdc at hushmail.com, or leave a message/comment at our blog at: http://capsecdc.org/blog/ -- Click here to find the perfect picture with our powerful photo search features. http://tagline.hushmail.com/fc/Ioyw6h4dI2fnInkHE2TA2nyabq0B7LZ6OWBYFaAg0UsqUGe7V3lhNk/ From jlloret at dcom.upv.es Fri Oct 31 10:02:29 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 31 Oct 2008 15:02:29 +0100 Subject: [Dailydave] Deadline extension: ICNS 2009 + 1st Workshop LMPCNAP | April 21-25, 2009 - Valencia, Spain Message-ID: <200810311402.m9VE2TN4030266@smtp.upv.es> Note that the deadline for ICNS 2009 + 1st Workshop LMPCNAP has been extended to November 10. We would like to make ICNS 2009 a primary reference event. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Please note that extended versions of highly ranked papers will be invited for journals submission. Full contributions are expected by the submission deadline. =========== ICNS 2009 + 1st Workshop LMPCNAP | Call for Papers =========== CALL FOR PAPERS, TUTORIALS, PANELS - ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html - The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy Program (CNAP), LMPCNAP 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Important deadlines: Submission (full paper) November 10, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum special submission with on progress and challenging ideas. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks ================================= - ICNS General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain - ICNS 2009 Industry Chairs Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland Francisco Javier S?nchez, Administrador de Infraestructuras Ferroviarias (ADIF), Spain - ICNS 2009 Technical Program Committee Chair Giancarlo Fortino, Universit? della Calabria, Italy Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China - ICNS Advisory Chairs Wojciech Burakowski, Warsaw University of Technology, Poland Vicente Casares, Polytechnic University of Valencia, Spain Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Xiaohua Jia, City University of Hong Kong - Kowloon, Hong Kong Manuel Sierra-P?rez, Universidad Polit?cnica de Madrid, Spain - LMPCNAP 2009 General Chair Rafael Tomas, Mediterranean Cisco Academy Training Center (CATC), Spain - LMPCNAP 2009 Technical Program Commitee chair Prof. Tomeu Serra, Universitat de les Illes Balears, Spain ================================ From stephen_fewer at harmonysecurity.com Fri Oct 31 13:58:02 2008 From: stephen_fewer at harmonysecurity.com (Stephen Fewer) Date: Fri, 31 Oct 2008 17:58:02 +0000 Subject: [Dailydave] Reflective DLL Injection Message-ID: <490B472A.5040101@harmonysecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Just released a short paper on Reflective DLL Injection. Abstract: Reflective DLL injection is a library injection technique in which the concept of reflective programming is employed to perform the loading of a library from memory into a host process. As such the library is responsible for loading itself by implementing a minimal Portable Executable (PE) loader. You can download the paper here: http://www.harmonysecurity.com/files/HS-P005_ReflectiveDllInjection.pdf And the PoC code here: http://www.harmonysecurity.com/files/ReflectiveDllInjection_v1.0.zip Support for Reflective DLL Injection has been added to Metasploit in the form of a payload stage and a modified VNC DLL (both are currently in the development tree). Cheers Stephen Fewer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) iEYEARECAAYFAkkLRyoACgkQQIrmi1YdFr4jOgCfRcZn+XKIS36fzTOPhIcAfiQj e0IAoLmUxJqKZaUiticQ5nSCVFABeNjc =yQXH -----END PGP SIGNATURE-----