From dave at immunityinc.com Fri May 1 11:30:19 2009 From: dave at immunityinc.com (dave) Date: Fri, 01 May 2009 11:30:19 -0400 Subject: [Dailydave] The Joining (or "Why metrics are important") Message-ID: <49FB158B.8030206@immunityinc.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: PGP/MIME version identification Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090501/a9fc914e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 2246 bytes Desc: OpenPGP encrypted message Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090501/a9fc914e/attachment.obj From dave at immunityinc.com Fri May 1 13:08:26 2009 From: dave at immunityinc.com (dave) Date: Fri, 01 May 2009 13:08:26 -0400 Subject: [Dailydave] Try 2: The Joining (or "Why metrics are important") Message-ID: <49FB2C8A.9070006@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting briefs are linked here: http://outerdnn.outer.jhuapl.edu/rethinking/VideoArchives/tabid/94/Default.aspx For example, this one is good, especially slides 11,23. ftp://ftp.jhuapl.edu/nsadrethink/030409/goslerbrief.pdf One thing I notice as missing from all these types of presentations is that although they say "Join defence and office" they rarely explain what it would take to do that. In order to truly join defence and offence you need a single metric that can take newly discovered vulnerabilities from all parts of your organization, and tell you when to go to a vendor with it or go public with it, or use it offensively, or use it on only targeted offensive missions. Without that metric there is no joining of teams on this sort of thing. You are forever split down the middle, which is bad for both offence and defence. Dave Aitel Chief Metrician Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkn7LIoACgkQtehAhL0gherZVACfZUlvFN196DKOjUTB4HNMB+Qd EwUAn3P18Z/w9j+OYA8hiE928Fn1tBzy =768h -----END PGP SIGNATURE----- From dr at kyx.net Wed May 6 18:18:48 2009 From: dr at kyx.net (Dragos Ruiu) Date: Wed, 6 May 2009 15:18:48 -0700 Subject: [Dailydave] EUSecWest 2009 (May27/28) London Agenda and PacSec 2009 (Nov 4/5) Tokyo CFP deadline: June 1 2009 Message-ID: <200905061518.48586.dr@kyx.net> EUSecWest 2009 Speakers Efficient UAK Recovery attacks against DECT - Ralf-Philipp Weinmann, University of Luxembourg A year in the life of an Adobe Flash security researcher - Peleus Uhley, Adobe Pwning your grandmother's iPhone - Charley Miller, Independent Security Evaluators Post exploitation techniques on OSX and Iphone and other TBA matters. - Vincent Iozzo,Zynamics STOP!! Objective-C Run-TIME. - nemo Exploiting Delphi/Pascal - Ilja Van Sprundel, IOActive PCI bus based operating system attack and protections - Christophe Devine & Guillaume Vissian, Thales Thoughts about Trusted Computing - Joanna Rutkowska, Invisible Things Lab Nice NIC you got there... does it come with an SSH daemon? - Arrigo Trulzi Evolving Microsoft Exploit Mitigations - Tim Burrell & Peter Beck, Microsoft Malware Case Study: the ZeuS evolution - Vicente Diaz, S21Sec Writing better XSS payloads - Alex Kouzemtchenko, SIFT Exploiting Firefox Extensions -Roberto Suggi Liverani & Nick Freeman, Security-Assessment.com Stored Value Gift Cards, Magstripes Revisited - Adrian Pastor, Gnucitizen, Corsaire Advanced SQL Injection to operating system control - Bernardo Damele Assumpcao Guimaraes, Portcullis Cloning Mifare Classic - Nicolas Courtois, University of London Rootkits on Windows Mobile/Embedded - Petr Matousek, Coseinc PacSec 2009 CALL FOR PAPERS World Security Pros To Converge on Japan TOKYO, Japan -- To address the increasing importance of information security in Japan, the best known figures in the international security industry will get together with leading Japanese researchers to share best practices and technology. The most significant new discoveries about computer network hack attacks will be presented at the seventh annual PacSec conference to be discussed. The PacSec meeting provides an opportunity for foreign specialists to be exposed to Japanese innovation and markets and collaborate on practical solutions to computer security issues. In an informal setting with a mixture of material bilingually translated in both English and Japanese the eminent technologists can socialize and attend training sessions. Announcing the opportunity to submit papers for the PacSec 2009 network security training conference. The conference will be held November 4/5th in Tokyo. The conference focuses on emerging information security tutorials - it is a bridge between the international and Japanese information security technology communities.. Please make your paper proposal submissions before June 1st, 2009. Slides for the papers must be submitted for translation by October 1, 2009 (Which, oh so rarely, happens we are going to start asking for them earlier :-P --dr). A some invited papers have been confirmed, but a limited number of speaking slots are still available. The conference is responsible for bugtraq at securityfocus.com travel and accomodations for the speakers. If you have a proposal for a tutorial session then please email a synopsis of the material and your biography, papers and, speaking background to . Tutorials are one hour in length, but with simultaneous translation should be approximately 45 minutes in English, or Japanese. Only slides will be needed for the October paper deadline, full text does not have to be submitted. The PacSec conference consists of tutorials on technical details about current issues, innovative techniques and best practices in the information security realm. The audiences are a multi-national mix of professionals involved on a daily basis with security work: security product vendors, programmers, security officers, and network administrators. We give preference to technical details and education for a technical audience. The conference itself is a single track series of presentations in a lecture theater environment. The presentations offer speakers the opportunity to showcase on-going research and collaborate with peers while educating and highlighting advancements in security products and techniques. The focus is on innovation, tutorials, and education instead of product pitches. Some commercial content is tolerated, but it needs to be backed up by a technical presenter - either giving a valuable tutorial and best practices instruction or detailing significant new technology in the products. Paper proposals should consist of the following information: 1) Presenter, and geographical location (country of origin/passport) and contact info (e-mail, postal address, phone, fax). 2) Employer and/or affiliations. 3) Brief biography, list of publications and papers. 4) Any significant presentation and educational experience/background. 5) Topic synopsis, Proposed paper title, and a one paragraph description. 6) Reason why this material is innovative or significant or an important tutorial. 7. Optionally, any samples of prepared material or outlines ready. 8. Will you have full text available or only slides? 9. Language of preference for submission. 10. Please list any other publications or conferences where this material has been or will be published/submitted. Please include the plain text version of this information in your email as well as any file, pdf, sxw, ppt, or html attachments. Please forward the above information to to be considered for placement on the speaker roster. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques London, U.K. May 27/28 2009 ?http://eusecwest.com Tokyo, Japan November 4/5 2009 http://pacsec.jp Vancouver, Canada March 22-26 2010 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From dan at geer.org Thu May 7 10:48:32 2009 From: dan at geer.org (dan at geer.org) Date: Thu, 07 May 2009 10:48:32 -0400 Subject: [Dailydave] recommended reading: Hacking Wall Street Message-ID: <20090507144832.4B75733D80@absinthe.tinho.net> Hacking Wall Street Karlos Krinklebine CreateSpace, March 2009 The author is in a position to know, and the mechanisms discussed are, as one would guess, part technology and part fleecing the gullible ("social engineering"), neatly integrated... Whether disclaimer or endorsement, I wrote the Foreword. Available now through Amazon, etc., or go to https://www.createspace.com/3371321 and give this code ZKRK8YEC for a 40% discount. --dan From martin.zember at matfyz.cz Fri May 8 05:11:29 2009 From: martin.zember at matfyz.cz (Martin Zember) Date: Fri, 8 May 2009 11:11:29 +0200 Subject: [Dailydave] School project start: a fuzzer Message-ID: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Hi community, could you please give me some advice about a school project? It is an obligatory team project. We plan to create a fuzzer. I hope it makes sense to build another fuzzer, since different fuzzers find different bugs, right..? ;-) We have a lot of time (9 months, 5 people, 1day per week), but not more, so it is not a good ground for research. The project should be implemented, documented, finished, presented. The question is, how deep can we go (what to promise in the specification)? My guess is that detecting success during fuzzing only when application crashes is too lame. "Feedback fuzzing" is maybe too complicated. What is realistic? Even though it would be nice, we did not find a paid project, which is interesting enough. We are not obliged to do a fuzzer so other suggestions or warnings are welcome. Martin From jdemott at crucialsecurity.com Fri May 8 10:13:26 2009 From: jdemott at crucialsecurity.com (Jared DeMott) Date: Fri, 08 May 2009 10:13:26 -0400 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Message-ID: <4A043E06.4070001@crucialsecurity.com> Martin Zember wrote: > Hi community, > Hi Martin. I have lots of ideas on fuzzing projects. For example you could try to prove my hypothesis that it depends on the use case/target as to which type of fuzzer is best. Or you might use the simple file fuzzer from the back of our book, and compare that to one you create and see which one does better. Right now simple fuzzers still rock against soft file based targets like QuickTime. Speaking of which I'll be giving training and talking about such things at ShakaCon in a few weeks if you need a reason to visit Hawaii. Other ideas, you might use an existing framework like Peach and compare results against one you create. I'm a big fan of comparisons against known tools, because it gives a reference point when trying to understand the relative success of your project. Heck you might even resurrect EFS it wasn't that complex! Best wishes, Jared > could you please give me some advice about a school project? It is an > obligatory team project. > > We plan to create a fuzzer. I hope it makes sense to build another fuzzer, > since different fuzzers find different bugs, right..? ;-) > > We have a lot of time (9 months, 5 people, 1day per week), but not more, so it > is not a good ground for research. The project should be implemented, > documented, finished, presented. The question is, how deep can we go (what to > promise in the specification)? My guess is that detecting success during > fuzzing only when application crashes is too lame. "Feedback fuzzing" is maybe > too complicated. What is realistic? > > Even though it would be nice, we did not find a paid project, which is > interesting enough. We are not obliged to do a fuzzer so other suggestions or > warnings are welcome. > > Martin > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- __________________________________________ Jared D. DeMott Senior Security Researcher Crucial Security Business Area Harris Corporation http://crucialsecurity.com Phone 616.874.7810 Mobile 571.283.4163 From agustingianni at gmail.com Fri May 8 10:46:27 2009 From: agustingianni at gmail.com (Agustin Gianni) Date: Fri, 8 May 2009 11:46:27 -0300 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Message-ID: <4d9a2ed00905080746o36f080ddk61cc2df794fe3ba9@mail.gmail.com> Just an idea, try mixing up an aplication like valgrind and a fuzzer. That should be an interesting thing to do. Just a thought. http://agustingianni.googlepages.com/ffuzer.tar.bz2 That is an old version of my file fuzzer. It may help you. On Fri, May 8, 2009 at 6:11 AM, Martin Zember wrote: > Hi community, > > could you please give me some advice about a school project? It is an > obligatory team project. > > We plan to create a fuzzer. I hope it makes sense to build another fuzzer, > since different fuzzers find different bugs, right..? ;-) > > We have a lot of time (9 months, 5 people, 1day per week), but not more, so > it > is not a good ground for research. The project should be implemented, > documented, finished, presented. The question is, how deep can we go (what > to > promise in the specification)? My guess is that detecting success during > fuzzing only when application crashes is too lame. "Feedback fuzzing" is > maybe > too complicated. What is realistic? > > Even though it would be nice, we did not find a paid project, which is > interesting enough. We are not obliged to do a fuzzer so other suggestions > or > warnings are welcome. > > Martin > _______________________________________________ > 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/20090508/d1d78715/attachment.htm From arunkoshy at gmail.com Fri May 8 10:53:59 2009 From: arunkoshy at gmail.com (Arun Koshy) Date: Sat, 9 May 2009 00:53:59 +1000 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Message-ID: <1d0ba3070905080753i5bb4bd91g1b16b8ea36a3175c@mail.gmail.com> > documented, finished, presented. The question is, how deep can we go (what to > promise in the specification)? My guess is that detecting success during > fuzzing only when application crashes is too lame. "Feedback fuzzing" is maybe > too complicated. What is realistic? a couple of books on the topic that may be useful : http://www.amazon.com/Fuzzing-Software-Security-Assurance-Information/dp/1596932147/ref=sr_1_1?ie=UTF8&s=books&qid=1241794318&sr=1-1 http://www.amazon.com/Gray-Hat-Python-Programming-Engineers/dp/1593271921 The authors ( or at least some of them ) hang out on d/d - so perhaps you can expect responses from them as well ;) From version5 at gmail.com Fri May 8 11:01:01 2009 From: version5 at gmail.com (nnp) Date: Fri, 8 May 2009 16:01:01 +0100 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Message-ID: <28749c0e0905080801h28e86744h89f0a6d5de19c00f@mail.gmail.com> Are you building a fuzzer or a fuzzing framework? You should check out Peach to see what functionality it provides. It might be worth your while to extend the auxiliary functionality of Peach, to 'guided' fuzzing for example, rather than building a new framework. If you're doing it as a team and have 9 months, then building a fuzzer with a feedback loop is definitely do-able. If it were me, I'd probably build it on top of a dynamic binary analysis framework like Pin (http://www.pintool.org) or DynamoRIO (http://code.google.com/p/dynamorio/) both of which are probably fast enough to be used with a fuzzer as long as you don't have too much logic in your instrumentation code. DynamoRIO is entirely open source but Pin has better C++ support and a more active community of users. You might even consider feeding the information you harvest from the binary into a fitness function of a genetic algorithm (like Jared DeMott did with his evolutionary fuzzer) and using that to select the path/data to fuzz. A group of us have recently started a wiki aimed at gathering info on program analysis and verification (http://www.unprotectedhex.com/psv) that you might find useful. Some of the papers there contain some inspiration for ways to make a better fuzzer (esp. the paper on DART). nnp On Fri, May 8, 2009 at 10:11 AM, Martin Zember wrote: > Hi community, > > could you please give me some advice about a school project? It is an > obligatory team project. > > We plan to create a fuzzer. I hope it makes sense to build another fuzzer, > since different fuzzers find different bugs, right..? ;-) > > We have a lot of time (9 months, 5 people, 1day per week), but not more, so it > is not a good ground for research. The project should be implemented, > documented, finished, presented. The question is, how deep can we go (what to > promise in the specification)? My guess is that detecting success during > fuzzing only when application crashes is too lame. "Feedback fuzzing" is maybe > too complicated. What is realistic? > > Even though it would be nice, we did not find a paid project, which is > interesting enough. We are not obliged to do a fuzzer so other suggestions or > warnings are welcome. > > Martin > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- http://www.unprotectedhex.com http://www.smashthestack.org From adrien at kunysz.be Fri May 8 14:42:55 2009 From: adrien at kunysz.be (Adrien Krunch Kunysz) Date: Fri, 8 May 2009 19:42:55 +0100 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> Message-ID: <20090508184255.GD1023@baltika> On Fri, May 08, 2009 at 11:11:29AM +0200, Martin Zember wrote: > We have a lot of time (9 months, 5 people, 1day per week), but not more, so it > is not a good ground for research. The project should be implemented, > documented, finished, presented. The question is, how deep can we go (what to > promise in the specification)? My guess is that detecting success during > fuzzing only when application crashes is too lame. "Feedback fuzzing" is maybe > too complicated. What is realistic? If you don't have that much experience with managing software projects, a "simple" fuzzer with all the required flexibility to make it adaptable to real software seems like a good project that can keep five students busy for 9*4 = 36 days. However I see this more like an interface design challenge (how do you make it flexible enough to adapt to most targets while keeping it easy enough to configure?) than a coding challenge. > Even though it would be nice, we did not find a paid project, which is > interesting enough. We are not obliged to do a fuzzer so other suggestions or > warnings are welcome. Somewhat related to security, back when I had to find project for a compiler course at the uni I had this idea to write a pf to iptables converter. We went with another idea in the end but this may be interesting to you if that's the sort of thing you are into. I thing this project can be especially interesting for a uni course considering you can easily reduce/expand it by choosing to implement more or less of the iptables/pf options/syntax. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090508/d63d4857/attachment.pgp From jon at oberheide.org Fri May 8 15:57:05 2009 From: jon at oberheide.org (Jon Oberheide) Date: Fri, 08 May 2009 15:57:05 -0400 Subject: [Dailydave] School project start: a fuzzer In-Reply-To: <4d9a2ed00905080746o36f080ddk61cc2df794fe3ba9@mail.gmail.com> References: <7cd0845e0905080211y5ddf80c0kb9a454ccb795a729@mail.gmail.com> <4d9a2ed00905080746o36f080ddk61cc2df794fe3ba9@mail.gmail.com> Message-ID: <1241812625.10304.2.camel@jonojono.eecs.umich.edu> Flayer from Will and Tavis did a bit along those lines: http://code.google.com/p/flayer/ http://www.usenix.org/event/woot07/tech/full_papers/drewry/drewry_html/ Regards, Jon Oberheide On Fri, 2009-05-08 at 11:46 -0300, Agustin Gianni wrote: > Just an idea, try mixing up an aplication like valgrind and a fuzzer. > That should > be an interesting thing to do. > > Just a thought. > > http://agustingianni.googlepages.com/ffuzer.tar.bz2 > > That is an old version of my file fuzzer. It may help you. > > On Fri, May 8, 2009 at 6:11 AM, Martin Zember > wrote: > Hi community, > > could you please give me some advice about a school project? > It is an > obligatory team project. > > We plan to create a fuzzer. I hope it makes sense to build > another fuzzer, > since different fuzzers find different bugs, right..? ;-) > > We have a lot of time (9 months, 5 people, 1day per week), but > not more, so it > is not a good ground for research. The project should be > implemented, > documented, finished, presented. The question is, how deep can > we go (what to > promise in the specification)? My guess is that detecting > success during > fuzzing only when application crashes is too lame. "Feedback > fuzzing" is maybe > too complicated. What is realistic? > > Even though it would be nice, we did not find a paid project, > which is > interesting enough. We are not obliged to do a fuzzer so other > suggestions or > warnings are welcome. > > Martin > _______________________________________________ > 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 -- Jon Oberheide GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090508/40ed1ca1/attachment.pgp From dave.aitel at gmail.com Sun May 10 05:20:23 2009 From: dave.aitel at gmail.com (Dave Aitel) Date: Sun, 10 May 2009 05:20:23 -0400 Subject: [Dailydave] Syscan time! Message-ID: I envy Kostya's ability to sleep on planes. We're headed to Shanghai and then Hong Kong for Syscan which is probably the oldest security conference in Asia. It's good to recharge and speak to some people you normally would never hear from, even if there is a language barrier. Anyways, I'll be booth babe and helping teach our new shellcode class, so stop by and check out the new CANVAS, SILICA, or just chat about cloud security with Kostya (or lack therof). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090510/d0853aeb/attachment.htm From dave at kof.immunityinc.com Wed May 13 02:12:48 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Wed, 13 May 2009 02:12:48 -0400 Subject: [Dailydave] Cloud fuzzing. Message-ID: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> Today at SyScan Ben Nagy of COSEINC gave a talk on a fuzzing cluster he's built that does 1.2 million fuzz cases a day against Word 2007. As he mentioned, as software gets better, the problem shifts from fuzz case generation to crash analysis. If you're generating 200K crashes a day, you need to figure out which ones are "interesting". In the long run, the only answer is a program that writes real exploits. Only then can you say for sure something is "interesting". He's using !exploitable for WinDBG to get an approximation of the problem. It's a talk full of real metrics. 72 VM's doing Word 20 test cases run a second 10% cause crashes or so. Most of those are unexploitable (he had numbers, but I forget them), according to !exploitable. A small percentage say they are possibly exploitable, and out of those, largely false positives. The problem of fuzzing is exponential, but if you architect your fuzzer right, you can scale linearly with your budget. Perhaps your budget also grows exponentially? :> The problems for the future are interesting. Classification of potential exploitability is a problem that involves diffing program runs, examining programs deeply for structure and behavior, and all this has to scale up with your 200K cases a day. -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090513/d6eadff1/attachment-0001.htm From oh.jeongwook at gmail.com Wed May 13 03:42:20 2009 From: oh.jeongwook at gmail.com (Matt Oh) Date: Wed, 13 May 2009 00:42:20 -0700 Subject: [Dailydave] Cloud fuzzing. In-Reply-To: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> References: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> Message-ID: <88a7d89d0905130042v251de904wace4a4ff28f7be97@mail.gmail.com> Nagy works at COSEINC? He was my former colleage :) Anyway, I'm just curious he was doing format-aware fuzzing or just brute forcing all the bytes and dwords of the file. In the previous case, the FP rate will drop drastically compared to second one. On Tue, May 12, 2009 at 11:12 PM, Dave Aitel wrote: > Today at SyScan Ben Nagy of COSEINC gave a talk on a fuzzing cluster > he's built that does 1.2 million fuzz cases a day against Word 2007. > As he mentioned, as software gets better, the problem shifts from fuzz > case generation to crash analysis. If you're generating 200K crashes a > day, you need to figure out which ones are "interesting". > > In the long run, the only answer is a program that writes real > exploits. Only then can you say for sure something is "interesting". > He's using !exploitable for WinDBG to get an approximation of the > problem. It's a talk full of real metrics. > > 72 VM's doing Word > 20 test cases run a second > 10% cause crashes or so. > Most of those are unexploitable (he had numbers, but I forget them), > according to !exploitable. > > A small percentage say they are possibly exploitable, and out of > those, largely false positives. > > The problem of fuzzing is exponential, but if you architect your > fuzzer right, you can scale linearly with your budget. Perhaps your > budget also grows exponentially? :> > > The problems for the future are interesting. Classification of > potential exploitability is a problem that involves diffing program > runs, examining programs deeply for structure and behavior, and all > this has to scale up with your 200K cases a day. > > -dave > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > -- -matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090513/09c69939/attachment.htm From dave at kof.immunityinc.com Wed May 13 11:10:55 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Wed, 13 May 2009 11:10:55 -0400 Subject: [Dailydave] Cloud fuzzing. In-Reply-To: <88a7d89d0905130042v251de904wace4a4ff28f7be97@mail.gmail.com> References: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> <88a7d89d0905130042v251de904wace4a4ff28f7be97@mail.gmail.com> Message-ID: <4e1ef3e50905130810h64290038t150fd59a4a24b5ea@mail.gmail.com> He's doing pretty deep format aware fuzzing, from what I can tell. But you still will get false positives (as measured by "obviously exploitable bugs" versus "obviously not exploitable bugs") -dave On Wed, May 13, 2009 at 3:42 AM, Matt Oh wrote: > Nagy works at COSEINC? He was my former colleage :) > > Anyway, I'm just curious he was doing format-aware fuzzing or just brute > forcing all the bytes and dwords of the file. In the previous case, the FP > rate will drop drastically compared to second one. > On Tue, May 12, 2009 at 11:12 PM, Dave Aitel wrote: > >> Today at SyScan Ben Nagy of COSEINC gave a talk on a fuzzing cluster >> he's built that does 1.2 million fuzz cases a day against Word 2007. >> As he mentioned, as software gets better, the problem shifts from fuzz >> case generation to crash analysis. If you're generating 200K crashes a >> day, you need to figure out which ones are "interesting". >> >> In the long run, the only answer is a program that writes real >> exploits. Only then can you say for sure something is "interesting". >> He's using !exploitable for WinDBG to get an approximation of the >> problem. It's a talk full of real metrics. >> >> 72 VM's doing Word >> 20 test cases run a second >> 10% cause crashes or so. >> Most of those are unexploitable (he had numbers, but I forget them), >> according to !exploitable. >> >> A small percentage say they are possibly exploitable, and out of >> those, largely false positives. >> >> The problem of fuzzing is exponential, but if you architect your >> fuzzer right, you can scale linearly with your budget. Perhaps your >> budget also grows exponentially? :> >> >> The problems for the future are interesting. Classification of >> potential exploitability is a problem that involves diffing program >> runs, examining programs deeply for structure and behavior, and all >> this has to scale up with your 200K cases a day. >> >> -dave >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> >> > > > -- > -matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090513/1441be30/attachment.htm From dave at kof.immunityinc.com Wed May 13 20:15:44 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Wed, 13 May 2009 20:15:44 -0400 Subject: [Dailydave] Conover's BCE Message-ID: <4e1ef3e50905131715u2a1ace4nd6707ea50d1fba3a@mail.gmail.com> Matthew Conover's BCE talk was very interesting yesterday, and I had a chance to annoy him a bit more about it at dinner. Basically the idea is this: Apply virtualization techniques (code rewriting + page permissions) to run drivers in usermode. The goal here is to be able to control the driver such that it does not know it is running under BCE, and be able to analyze it. He has working code - this was not a theory talk so much as a demonstration and explanation, as were most of the talks at SyScan. This is a useful dynamic analysis tool (he demo'd running process explorer under it, which worked), and if he open sourced it I could see lots of people using it for rootkit analysis. One thing he did during his talk that I thought was good was stop every 5-10 slides for questions. With something as technical as this, it's a very good idea as it kept the audience on the same page. In order to run a driver in "usermode" he has to emulate a stack and a Kernel Pool for the driver. So for example, if you do a: call popme popme: pop eax Then EAX has a kernel address in it (a "fake eip" if you will), even though the driver is really running in userspace. One attack I think would be hard to stop would be for the driver to allocate kernel Pool data, then go search the kernel pool to make sure their data is there. If the data is not there, they are running under BCE and it's time to pretend to be innocous. I'm sure there's lots of other exciting attacks, but as Kostya says "in the real world, no one is ever going to attack this thing if you don't give it out to everyone". On the other hand, I kinda want one so I'm hoping he does. :> Today is Shellcode class day. We're giving out our latest shellcode library for everyone to use to learn how to create shellcode. It's fun for the whole family! -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090513/1cf79ebb/attachment.htm From romemeteor at gmail.com Wed May 13 21:13:23 2009 From: romemeteor at gmail.com (Billy Lee) Date: Thu, 14 May 2009 09:13:23 +0800 Subject: [Dailydave] Cloud fuzzing. In-Reply-To: <4e1ef3e50905130810h64290038t150fd59a4a24b5ea@mail.gmail.com> References: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> <88a7d89d0905130042v251de904wace4a4ff28f7be97@mail.gmail.com> <4e1ef3e50905130810h64290038t150fd59a4a24b5ea@mail.gmail.com> Message-ID: <260603320905131813j6091ae73hc1b88c7c480c33b4@mail.gmail.com> hi, all It's a good morning and welcome all of buddies on this Syscan 09 at Shanghai, Things usually work out fine, but it is rather difficult for me because it's not my normal routine. As opposed to just discussing the vulnerabilities, like tracing the rootkit behaviors with BCE etc. and hacking VMware, I have to worry about one question: ?????????????????????????????????????? What's the ultimate answer for us, as the security enablers, to deal with the 0Day attacks for our potential customers? If yes, we must pay a big bunch of money to get the details in an "legal" way; if not, we've to get a risky dark world to fight with a poor gun....? Is that true, it is really difficult to make choices. :( Maybe...or perhaps we could incorporate and facilitate coordination of all the security resources to reduce the attack surface, but it is still an endless war. Wish to enjoy the Shanghai trips, security guys. If you need any help in Shanghai, please contact me: Billy.Lee romemeteor at gmail.com Skype: meteorshow Antiy Labs http://www.antiy.net http://www.antiy.com On Wed, May 13, 2009 at 11:10 PM, Dave Aitel wrote: > He's doing pretty deep format aware fuzzing, from what I can tell. But you > still will get false positives (as measured by "obviously exploitable bugs" > versus "obviously not exploitable bugs") > > -dave > > > On Wed, May 13, 2009 at 3:42 AM, Matt Oh wrote: >> >> Nagy works at COSEINC? He was my former colleage :) >> >> Anyway, I'm just curious he was doing format-aware fuzzing or just brute >> forcing all the bytes and dwords of the file. In the previous case, the FP >> rate will drop drastically compared to second one. >> On Tue, May 12, 2009 at 11:12 PM, Dave Aitel >> wrote: >>> >>> Today at SyScan Ben Nagy of COSEINC gave a talk on a fuzzing cluster >>> he's built that does 1.2 million fuzz cases a day against Word 2007. >>> As he mentioned, as software gets better, the problem shifts from fuzz >>> case generation to crash analysis. If you're generating 200K crashes a >>> day, you need to figure out which ones are "interesting". >>> >>> In the long run, the only answer is a program that writes real >>> exploits. Only then can you say for sure something is "interesting". >>> He's using !exploitable for WinDBG to get an approximation of the >>> problem. It's a talk full of real metrics. >>> >>> 72 VM's doing Word >>> 20 test cases run a second >>> 10% cause crashes or so. >>> Most of those are unexploitable (he had numbers, but I forget them), >>> according to !exploitable. >>> >>> A small percentage say they are possibly exploitable, and out of >>> those, largely false positives. >>> >>> The problem of fuzzing is exponential, but if you architect your >>> fuzzer right, you can scale linearly with your budget. Perhaps your >>> budget also grows exponentially? :> >>> >>> The problems for the future are interesting. Classification of >>> potential exploitability is a problem that involves diffing program >>> runs, examining programs deeply for structure and behavior, and all >>> this has to scale up with your 200K cases a day. >>> >>> -dave >>> _______________________________________________ >>> Dailydave mailing list >>> Dailydave at lists.immunitysec.com >>> http://lists.immunitysec.com/mailman/listinfo/dailydave >>> >> >> >> >> -- >> -matt > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From joanna at invisiblethingslab.com Thu May 14 05:07:36 2009 From: joanna at invisiblethingslab.com (Joanna Rutkowska) Date: Thu, 14 May 2009 11:07:36 +0200 Subject: [Dailydave] Conover's BCE In-Reply-To: <4e1ef3e50905131715u2a1ace4nd6707ea50d1fba3a@mail.gmail.com> References: <4e1ef3e50905131715u2a1ace4nd6707ea50d1fba3a@mail.gmail.com> Message-ID: <4A0BDF58.7020802@invisiblethingslab.com> Dave Aitel wrote: > Matthew Conover's BCE talk was very interesting yesterday, and I had a > chance to annoy him a bit more about it at dinner. Basically the idea is > this: > > Apply virtualization techniques (code rewriting + page permissions) to run > drivers in usermode. The goal here is to be able to control the driver such > that it does not know it is running under BCE, and be able to analyze it. He > has working code - this was not a theory talk so much as a demonstration and > explanation, as were most of the talks at SyScan. This is a useful dynamic > analysis tool (he demo'd running process explorer under it, which worked), > and if he open sourced it I could see lots of people using it for rootkit > analysis. > This sounds like a simple light-weight software-based virtualization (read VMWare or VBox), but has an obvious problem that to avoid a simple detection via DMA (a rootkit sets up a DMA via one of the devices, e.g. SATA controller and checks if its code is indeed at kernel addresses), the tool needs to emulate as much I/O as possible. This way it is becoming more and more like a VMWare Workstation product, losing all it's light-weight benefits. In the end it comes down to the question -- why not simply use VBox (which is opensourced, so one can easily insert "probes" there and also change the I/O devices strings so they don't immediately look like VBox's ones)? On the other hand, if the tool simply decided to cut off all the I/O to unknown devices, this would make it just as easy for generic detection -- the DMAs would simply not work. Needles to say, every single device can have different ways of programming it for DMA transfers, so it is nearly impossible to come up with a generic DMA emulator. joanna. -- Joanna Rutkowska Founder/CEO Invisible Things Lab http://invisiblethingslab.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 226 bytes Desc: OpenPGP digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090514/87212cdd/attachment.pgp From mconover at gmail.com Thu May 14 13:42:12 2009 From: mconover at gmail.com (Matt Conover) Date: Fri, 15 May 2009 01:42:12 +0800 Subject: [Dailydave] Conover's BCE In-Reply-To: <4A0BDF58.7020802@invisiblethingslab.com> References: <4e1ef3e50905131715u2a1ace4nd6707ea50d1fba3a@mail.gmail.com> <4A0BDF58.7020802@invisiblethingslab.com> Message-ID: <3e08eefa0905141042g26a32394l863973940ae49715@mail.gmail.com> > This sounds like a simple light-weight software-based virtualization (read > VMWare or VBox), but has an obvious problem that to avoid a simple > detection via > DMA (a rootkit sets up a DMA via one of the devices, e.g. SATA controller > and > checks if its code is indeed at kernel addresses), the tool needs to > emulate as > much I/O as possible. This way it is becoming more and more like a VMWare > Workstation product, losing all it's light-weight benefits. In the end it > comes > down to the question -- why not simply use VBox (which is opensourced, so > one > can easily insert "probes" there and also change the I/O devices strings so > they > don't immediately look like VBox's ones)? Thanks for the feedback. I need to clarify Dave's original comment in order to respond to Joanna. In its current form, it's more of an analyst tool. The goal is to capture the rootkit's behavior, but it doesn't prevent the rootkit from doing anything. Mostly it's just a proxy that sits between an unmodified kernel driver running at ring3 and the kernel and records all the interactions between them. The tool doesn't actually emulate things like DMA or kernel APIs. Rather than trying to reverse engineer a packed driver with a disassembler, the analyst can look at its runtime behaviors. The basic idea is to run the driver in an isolated domain (non-executable pages + running at ring3) and capture the faults this causes. Calls into the rootkit from the kernel produce a fault, and all access from the rootkit to kernel will produce a fault. The tool simply detects the fault (caused by the driver running at ring3), records the event (i.e., the behavior), and then re-executes the code that caused the fault at ring 0. The intention is to make sure the driver cannot interact with the kernel on its own, it needs the tool to serve as the middleman. If the rootkit calls WRMSR, for example, it will cause an access violation at ring 3, so the tool will record the attempt to use WRMSR, and then execute the WRMSR (at ring 0) on behalf of the rootkit. The only instructions which are emulated/virtualized are the ones that would leak the ring3 state (like "mov ax, cs") or EIP (the rootkit should always see its virtual EIP). That was what Dave was referring to when he said "virtualized"-- but the tool doesn't attempt to do anything too sophisticated. The rootkit would still need to be run in a VM, because the rootkit will still work exactly as it would in a native environment (at least, it should). The rootkit could break out of the tool using bluepill or even the whole VM using cloudburst -- the tool would only be able to record the events up to that point. So, the tool would definitely be able to report that the rootkit did a bluepill/cloudburst, but it wouldn't attempt to prevent it and wouldn't know what it did after that. But for the tool's current purpose, that would be good enough.. the analyst would know its a malicious driver if tries to do a bluepill/cloudburst (at least, until there are some legitimate drivers using bluepill or cloudburst). Of course, there are a lot of other subtleties I didn't mention here (some drivers are probably impossible to run with this tool), but a lot of drivers work fine. The slides from the presentation could probably further clarify, so feel free to contact me. Side note: greets to Peter Ferrie :) BCE would not have been possible without him -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090515/d027b06a/attachment-0001.htm From desnos at esiea.fr Thu May 14 16:38:44 2009 From: desnos at esiea.fr (Anthony Desnos) Date: Thu, 14 May 2009 22:38:44 +0200 Subject: [Dailydave] iAWACS CFP - The no-limit workshop Message-ID: <4A0C8154.1090908@esiea.fr> First International Alternative Workshop on Aggressive Computing and Security The no-limit workshop "Enhancing security with the attacker's mind - Orthodoxy and self confidence are weaknesses" "There is no such thing as forbidden knowledge, only forbidden use of knowledge" iAWACS ESIEA - Laval - October 2009 Thinking security can not be done without adopting a preferential mode of thought of the attacker. A system cannot be defended if we do not know how to attack it. If the theory is still an interesting approach to formalize things, the operational approach must be the ultimate goal: to talk about security is meaningless if we do not actually do security. In recent years the major security conferences in the subjects preferred to select papers according to fashion topics, conforming to something like orthodoxy and organize selection as beauty contests. As a result excellent yet unorthodox scientific papers are often rejected and sink into oblivion. The first international Alternative Workshop in Aggressive Computing and Security (iAWACS'09) aims to focus on this vision and to allow researchers and specialists to present relevant research works, with interesting results and operational (theoretical and/or applied) in the field of security. The different points of view, away from unconventional fashion and orthodoxy are particularly welcome. The aim is also to promote discussion of ideas around these topics. Articles submitted will be selected according to the following criteria: # Interest and scientific/technical correctness/accuracy, # New results, # Operational quality Regarding this last point, the authors should give all information and conditions for reproducibility of results they intend to present. This may include, during the selection phase by the reviewers, assessments based on challenges to the authors by the reviewers. iAwacs is not just another hackers workshop where the last exploit is disclosed. The aim of the conference is to make security concepts evolves through both the attacker's view AND a thorough formalization backed by experimental results. The main topics covered (list not exhaustive) are: # Cryptanalysis techniques # Steganalysis techniques # Malicious cryptography # Advances computer virology techniques (malware, backdoor...) # Active security product analysis and testing # Active security auditing # Mathematical concepts and applications with respect to the attacker's view # Cyberwarfare techniques # Cryptographic and steganography techniques # Invisible trap/bacdoor techniques in algorithms and applications # Implementation attacks # Interception/eavesdropping techniques # Forensics and anti-forensics techniques # Tempest and anti-tempest techniques # InfoOps techniques # Satellite hijacking Articles should be submitted in electronic format, preferably in LaTeX format, in English. Submission of Word/OOwriter documents is accepted. The address for submission is iawacs2009 at esiea.fr. Submissions under hidden identities or aliases are not allowed.A technical challenge will be organized during the conference. Attendees who want to participate must register on site. For this first edition, the theme we have chosen is "Evaluation against active antivirus software to evaluate their resistance to removal by a malicious code." All results will be shared with publishers of antivirus concerned. The technical details of the challenge will be announced later. Important dates : # Submission deadline: July 15th, 2009 # Notification deadline: August 20th, 2009 # Final manuscript submission for inclusion into the proceedings: September 20th, 2009 # Conference dates: October 23rd - 25th, 2009 The conference proceedings will be published with ISBN by the Presses Techniques ESIEA. They will be given to registered participants at the conference and can then be bought on the conference homepage. The conference will be held at Ecole Sup??rieure en Informatique, Electronique et Automatique, in Laval from Friday 23rd to Sunday 25th, 2009 morning. Each author will have 45 minutes of speaking time, each presentation will be followed by a technical discussion between speakers and listeners. Laval is nice medieval city located 250 km west from Paris and can be reach by high speed train (TGV) from Paris International Airport. Conference registration amount to 400 euros (includes proceedings ,coffee breaks, lunches, cocktail reception, social events on Friday evening and Saturday evening, the conference, shuttle bus between the hotels and the conference venue). Program Chair : Eric Filiol Program Co-Chair : Robert Erra Contacts : # Program chair: iawacs2009 at esiea.fr # Organization comitee: iawacs2009_orga at esiea.fr # Press contact: iawacs2009_press at esiea.fr http://www.esiea-recherche.eu http://www.esiea-recherche.eu/iawacs_2009.html From bania.piotr at gmail.com Mon May 18 08:32:38 2009 From: bania.piotr at gmail.com (Piotr Bania) Date: Mon, 18 May 2009 14:32:38 +0200 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Message-ID: <6F8AE73807584314A5D7406BED4FB842@DIED> SpiderPig is a project created for performing and visualizing data flow analysis of a selected binary program. SpiderPig was created in the purpose of providing a tool which would be able to help vulnerability and security researchers with tracing and analyzing any necessary data and it's further propagation. Such tasks are very often crucial in the vulnerability discovering/identifying process and typically require a lot of time consuming manual work. Following paper discusses methods and techniques implemented in SpiderPig in order to perform semi-automatic data flow analysis. Paper is available here: http://piotrbania.com/all/spiderpig/pbania-spiderpig2008.pdf Simple video demo and some other things available on project website: http://piotrbania.com/all/spiderpig/ best regards, Piotr Bania -- -------------------------------------------------------------------- Piotr Bania - - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://www.piotrbania.com - Key ID: 0xBE43AC33 -------------------------------------------------------------------- - "The more I learn about men, the more I love dogs." P.S Did ya know adult pigs can run at speeds of up to 11 miles an hour? From version5 at gmail.com Mon May 18 13:24:53 2009 From: version5 at gmail.com (nnp) Date: Mon, 18 May 2009 18:24:53 +0100 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) In-Reply-To: <6F8AE73807584314A5D7406BED4FB842@DIED> References: <6F8AE73807584314A5D7406BED4FB842@DIED> Message-ID: <28749c0e0905181024h81baf52sde3da5bc267eba32@mail.gmail.com> Hey, I've got a few questions regarding your approach. 1) In section 4.4 you discuss predicting data propogation and you use the term 'symbolic execution'. Does this mean you treat all input as symbolic? e.g. everything from a recv() call is marked as 'tainted' 2) If the answer to the previous question is 'yes'; how do you deal with symbolic read/writes using your O_in/O_out register mechanism? I can't see this working for memory, as the size of those sets becomes potentially unbounded (well, bounded by the amount of usable memory) e.g how do you describe the memory written to by **mov dword ptr [eax], ebx** if eax is symbolic and dependent on user input? A more tangible situation might be the case where a child object is created, then written to memory at a symbolic offset and then later read again. 3) What DynamoRIO plugin are you comparing your code to? Cheers, and good work, nnp On Mon, May 18, 2009 at 1:32 PM, Piotr Bania wrote: > SpiderPig is a project created for performing and visualizing data flow > analysis of a selected binary program. SpiderPig was created in the purpose > of providing a tool which would be able to help vulnerability and security > researchers with tracing and analyzing any necessary data and it's further > propagation. Such tasks are very often crucial in the vulnerability > discovering/identifying process and typically require a lot of time > consuming manual work. Following paper discusses methods and techniques > implemented in SpiderPig in order to perform semi-automatic data flow > analysis. > > Paper is available here: > http://piotrbania.com/all/spiderpig/pbania-spiderpig2008.pdf > > > Simple video demo and some other things available on project website: > http://piotrbania.com/all/spiderpig/ > > > best regards, > Piotr Bania > > -- > -------------------------------------------------------------------- > Piotr Bania - - 0xCD, 0x19 > Fingerprint: 413E 51C7 912E 3D4E A62A ?BFA4 1FF6 689F BE43 AC33 > http://www.piotrbania.com ?- Key ID: 0xBE43AC33 > -------------------------------------------------------------------- > > ? ? ? ? ? ? ? - "The more I learn about men, the more I love dogs." > > > P.S Did ya know adult pigs can run at speeds of up to 11 miles an hour? > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- http://www.unprotectedhex.com http://www.smashthestack.org From bania.piotr at gmail.com Mon May 18 14:20:20 2009 From: bania.piotr at gmail.com (Piotr Bania) Date: Mon, 18 May 2009 20:20:20 +0200 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) References: <6F8AE73807584314A5D7406BED4FB842@DIED> <28749c0e0905181024h81baf52sde3da5bc267eba32@mail.gmail.com> Message-ID: <52EC952401824CCC81DEC8E23AC57470@DIED> Yo, >I've got a few questions regarding your approach. > >1) In section 4.4 you discuss predicting data propogation and you use >the term 'symbolic execution'. Does this mean you treat all input as >symbolic? e.g. everything from a recv() call is marked as 'tainted' >2) If the answer to the previous question is 'yes'; how do you deal >with symbolic read/writes using your O_in/O_out register mechanism? I >can't see this working for memory, as the size of those sets becomes >potentially unbounded (well, bounded by the amount of usable memory) >e.g how do you describe the memory written to by **mov dword ptr >[eax], ebx** if eax is symbolic and dependent on user input? A more >tangible situation might be the case where a child object is created, >then written to memory at a symbolic offset and then later read again. First of all, SpiderPig in current shape requires the user to pick the starting point (that was the main idea of it from the beginning). In other words user must specify the register or memory region which is tainted (pick a root of the taint). SpiderPig can taint either memory location or CPU elements like registers, flags etc. etc. Regarding the 4.4 section (Predicting Data Propagation) the symbolic execution approach (O_in/O_out variants) refers only to the elements of the CPU architecture - not the memory locations pointed by them. So if SpiderPig meets instruction like "mov dword ptr [eax], ebx", the "ProcessStandardInstruction()" function (see Algorithm 1, page 22) is used. So basically in this case it does following thing: 1) kills the 4 byte memory region pointed by EAX (saves all the information about the killer instruction) 2) if the EBX value is tainted then the 4 byte memory region pointed by EAX is also tainted To preserve some time the referenced memory address (in this case pointed by EAX) is computed by the instrumentation code (on the fly) inside of target process. Now if there are any possible data propagations afterwards in the Dataflow Region between CPU elements, the symbolic execution approach is used. I think it is important to notice that each Dataflow Region is considered as side-effect free (see Definition 4, page 24). > 3) What DynamoRIO plugin are you comparing your code to? If you refer to "Test application's performance" (page 39), it was a very simple plugin (made by myself) which task was to gather and save a CPU context for each executed instruction. Like i have stated in 5.2.3 section ("Analysis (Instrumentation) Performance", page 38) there is nothing really to compare. VCI is VCI, DBI is DBI and IMHO they should be treated separately. Shortly in case of VCI i dont need to waste time for dispatcher calls "every"* transfer instruction. Anyway personally DynamoRIO is my favorite DBI so far, and i really admire Derek and rest of the authors for providing such an excellent tool. I think it is quite possible I will port SpiderPig to DynamoRIO, especially after it became open source project[1]. >Cheers, and good work, I'm glad you liked it and i hope i have answered your questions. cheers, pb * i am aware DynamoRio has some optimizations for that [1] - http://code.google.com/p/dynamorio/ On Mon, May 18, 2009 at 1:32 PM, Piotr Bania wrote: > SpiderPig is a project created for performing and visualizing data flow > analysis of a selected binary program. SpiderPig was created in the > purpose > of providing a tool which would be able to help vulnerability and security > researchers with tracing and analyzing any necessary data and it's further > propagation. Such tasks are very often crucial in the vulnerability > discovering/identifying process and typically require a lot of time > consuming manual work. Following paper discusses methods and techniques > implemented in SpiderPig in order to perform semi-automatic data flow > analysis. > > Paper is available here: > http://piotrbania.com/all/spiderpig/pbania-spiderpig2008.pdf > > > Simple video demo and some other things available on project website: > http://piotrbania.com/all/spiderpig/ > > > best regards, > Piotr Bania > > -- > -------------------------------------------------------------------- > Piotr Bania - - 0xCD, 0x19 > Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 > http://www.piotrbania.com - Key ID: 0xBE43AC33 > -------------------------------------------------------------------- > > - "The more I learn about men, the more I love dogs." > > > P.S Did ya know adult pigs can run at speeds of up to 11 miles an hour? > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- http://www.unprotectedhex.com http://www.smashthestack.org From version5 at gmail.com Mon May 18 15:04:47 2009 From: version5 at gmail.com (nnp) Date: Mon, 18 May 2009 20:04:47 +0100 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) In-Reply-To: <52EC952401824CCC81DEC8E23AC57470@DIED> References: <6F8AE73807584314A5D7406BED4FB842@DIED> <28749c0e0905181024h81baf52sde3da5bc267eba32@mail.gmail.com> <52EC952401824CCC81DEC8E23AC57470@DIED> Message-ID: <28749c0e0905181204x1a2a4c2fv9e577d44dfb4ded@mail.gmail.com> On Mon, May 18, 2009 at 7:20 PM, Piotr Bania wrote: > Yo, > >> I've got a few questions regarding your approach. >> >> 1) In section 4.4 you discuss predicting data propogation and you use >> the term 'symbolic execution'. Does this mean you treat all input as >> symbolic? e.g. everything from a recv() call is marked as 'tainted' >> 2) If the answer to the previous question is 'yes'; how do you deal >> with symbolic read/writes using your O_in/O_out register mechanism? I >> can't see this working for memory, as the size of those sets becomes >> potentially unbounded (well, bounded by the amount of usable memory) >> e.g how do you describe the memory written to by **mov dword ptr >> [eax], ebx** if eax is symbolic and dependent on user input? A more >> tangible situation might be the case where a child object is created, >> then written to memory at a symbolic offset and then later read again. > > > First of all, SpiderPig in current shape requires the user to pick the > starting point (that was the main idea of it from the beginning). In other > words user must specify the register or memory region which is tainted (pick > a root of the taint). SpiderPig can taint either memory location or CPU > elements like registers, flags etc. etc. Regarding the 4.4 section > (Predicting Data Propagation) the symbolic execution approach (O_in/O_out > variants) refers only to the elements of the CPU architecture - not the > memory locations pointed by them. OK, but without considering tainting of memory what happens if the first thing the app does is pass the region marked as 'tainted' through a 'toUpper' function, and then operates exclusively on that data? In this case will your data flow graph be empty? I don't think I'd class what you're doing as symbolic execution, unless you're doing something not mentioned in the paper to take into account the semantics of the instructions and their effect on the data/flow control. If you're not, then the use of the term 'symbolic execution' tends to lead to confusion (or maybe I'm just easily confused ;-) ) -- http://www.unprotectedhex.com http://www.smashthestack.org From fosforo at gmail.com Mon May 18 16:09:09 2009 From: fosforo at gmail.com (Fosforo) Date: Mon, 18 May 2009 17:09:09 -0300 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) In-Reply-To: <6F8AE73807584314A5D7406BED4FB842@DIED> References: <6F8AE73807584314A5D7406BED4FB842@DIED> Message-ID: <6e285e810905181309o612827c5u975d38f559930a6d@mail.gmail.com> Am i the only one having a deja-vu on Z0mbie's work ? Of course isnt the same thing - i mean the integration part. http://andrewl.us/library/site_z0mbie/autorev.txt nice work. []s Fosforo On Mon, May 18, 2009 at 9:32 AM, Piotr Bania wrote: > SpiderPig is a project created for performing and visualizing data flow > analysis of a selected binary program. SpiderPig was created in the purpose > of providing a tool which would be able to help vulnerability and security > researchers with tracing and analyzing any necessary data and it's further > propagation. Such tasks are very often crucial in the vulnerability > discovering/identifying process and typically require a lot of time > consuming manual work. Following paper discusses methods and techniques > implemented in SpiderPig in order to perform semi-automatic data flow > analysis. > > Paper is available here: > http://piotrbania.com/all/spiderpig/pbania-spiderpig2008.pdf > > > Simple video demo and some other things available on project website: > http://piotrbania.com/all/spiderpig/ > > > best regards, > Piotr Bania > > -- > -------------------------------------------------------------------- > Piotr Bania - - 0xCD, 0x19 > Fingerprint: 413E 51C7 912E 3D4E A62A ?BFA4 1FF6 689F BE43 AC33 > http://www.piotrbania.com ?- Key ID: 0xBE43AC33 > -------------------------------------------------------------------- > > ? ? ? ? ? ? ? - "The more I learn about men, the more I love dogs." > > > P.S Did ya know adult pigs can run at speeds of up to 11 miles an hour? > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From bania.piotr at gmail.com Mon May 18 16:48:58 2009 From: bania.piotr at gmail.com (Piotr Bania) Date: Mon, 18 May 2009 22:48:58 +0200 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) References: <6F8AE73807584314A5D7406BED4FB842@DIED> <28749c0e0905181024h81baf52sde3da5bc267eba32@mail.gmail.com> <52EC952401824CCC81DEC8E23AC57470@DIED> <28749c0e0905181204x1a2a4c2fv9e577d44dfb4ded@mail.gmail.com> Message-ID: <60CA07C479E04CCFB8595B39361B8910@DIED> > On Mon, May 18, 2009 at 7:20 PM, Piotr Bania > wrote: >> Yo, >> >>> I've got a few questions regarding your approach. >>> >>> 1) In section 4.4 you discuss predicting data propogation and you use >>> the term 'symbolic execution'. Does this mean you treat all input as >>> symbolic? e.g. everything from a recv() call is marked as 'tainted' >>> 2) If the answer to the previous question is 'yes'; how do you deal >>> with symbolic read/writes using your O_in/O_out register mechanism? I >>> can't see this working for memory, as the size of those sets becomes >>> potentially unbounded (well, bounded by the amount of usable memory) >>> e.g how do you describe the memory written to by **mov dword ptr >>> [eax], ebx** if eax is symbolic and dependent on user input? A more >>> tangible situation might be the case where a child object is created, >>> then written to memory at a symbolic offset and then later read again. >> >> >> First of all, SpiderPig in current shape requires the user to pick the >> starting point (that was the main idea of it from the beginning). In >> other >> words user must specify the register or memory region which is tainted >> (pick >> a root of the taint). SpiderPig can taint either memory location or CPU >> elements like registers, flags etc. etc. Regarding the 4.4 section >> (Predicting Data Propagation) the symbolic execution approach (O_in/O_out >> variants) refers only to the elements of the CPU architecture - not the >> memory locations pointed by them. > > OK, but without considering tainting of memory what happens if the > first thing the app does is pass the region marked as 'tainted' > through a 'toUpper' function, and then operates exclusively on that > data? In this case will your data flow graph be empty? > Congratulations i ran SpiderPig for you, its quite something since i havent used it like in couple of months :-) Anyway simple scenario just to not produce weird graph - application does following things: 1) take 4 bytes (located at 0x0012FE7C...) 2) execute toupper() on them 3) then bytes are destroyed by simple overwrite ("00401091 MOV DWORD PTR SS:[ESP+4],41414141") Graph is available here: http://piotrbania.com/all/spiderpig/toupper.png As you can see initial bytes were destroyed by the same instruction that "creates" same memory regions after toupper is executed. Finally the memory regions created by toupper() function are destroyed by 0x401091. No doubt SpiderPig will require some additional modifications, it is still a prototype software. However now its time to get some sleep :-) - pb From bania.piotr at gmail.com Tue May 19 00:03:31 2009 From: bania.piotr at gmail.com (Piotr Bania) Date: Tue, 19 May 2009 06:03:31 +0200 Subject: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) References: <6F8AE73807584314A5D7406BED4FB842@DIED> <6e285e810905181309o612827c5u975d38f559930a6d@mail.gmail.com> Message-ID: <79A9667978184D85BE18C41957C7E52F@DIED> No doubt in z0mbie's technical skills and the innovation he brought to the world of viruses. However i think it is good to remember that binary translation/code rewriting techniques (either static or dynamic)/binary code manipulation tools were used in the past (before 2000) - like in for example QPT(1994), Shade(1994), ATOM(1994), NJMC(1994), EEL(1995), Freeport Express(1995), FX!32 (1996), UQBT(1997?) etc. etc. Like i have stated in section 3.1 (page 17), my code integration definition/model meets more or less the "Proposed 1997 Architecture of a Retargetable Binary Translator" [1]. cheers, pb [1] - Cristina Cifuentes, Mike Van Emmerik, Norman Ramsey, and Brian Lewis. The University of Queensland Binary Translator (UQBT) Frame- work. 1996-2001. ----- Original Message ----- From: "Fosforo" To: "Piotr Bania" Cc: Sent: Monday, May 18, 2009 10:09 PM Subject: Re: [Dailydave] PAPER: Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case) Am i the only one having a deja-vu on Z0mbie's work ? Of course isnt the same thing - i mean the integration part. http://andrewl.us/library/site_z0mbie/autorev.txt nice work. []s Fosforo On Mon, May 18, 2009 at 9:32 AM, Piotr Bania wrote: > SpiderPig is a project created for performing and visualizing data flow > analysis of a selected binary program. SpiderPig was created in the > purpose > of providing a tool which would be able to help vulnerability and security > researchers with tracing and analyzing any necessary data and it's further > propagation. Such tasks are very often crucial in the vulnerability > discovering/identifying process and typically require a lot of time > consuming manual work. Following paper discusses methods and techniques > implemented in SpiderPig in order to perform semi-automatic data flow > analysis. > > Paper is available here: > http://piotrbania.com/all/spiderpig/pbania-spiderpig2008.pdf > > > Simple video demo and some other things available on project website: > http://piotrbania.com/all/spiderpig/ > > > best regards, > Piotr Bania > > -- > -------------------------------------------------------------------- > Piotr Bania - - 0xCD, 0x19 > Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 > http://www.piotrbania.com - Key ID: 0xBE43AC33 > -------------------------------------------------------------------- > > - "The more I learn about men, the more I love dogs." > > > P.S Did ya know adult pigs can run at speeds of up to 11 miles an hour? > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From info at shakacon.org Tue May 19 18:42:33 2009 From: info at shakacon.org (Shakacon) Date: Tue, 19 May 2009 12:42:33 -1000 Subject: [Dailydave] Shakacon 2009 Update: Speakers and Trainers Finalized Message-ID: <0DAB602EAD833D44B10F51A28F258A11011CDA0F@helix1.secure-dna.com> Aloha from Hawaii: Due to the global economic meltdown there has never been a better time to travel to Hawaii. Why not take a cheap trip to paradise and catch some world class training and talks at the same time? Training and speakers are finalized for the conference. Some special discounts are in place so check the site for details - www.shakacon.org. Special hotel rates have been negotiated with the Ala Moana Hotel which is across the street from the convention center. SELECTED TRAINING COURSES: Deviant Ollam - 1 Day Course \__Mastery of Physical Security Joe McCray - 2 Day Course \__Crash Course on Penetration Testing & Web Application Security Jared DeMott - 3 Day Course \__Application Security: For Hackers and Developers Scott Lambert & Jason Geffner - 3 Day Course \__Introduction to Malware Analysis Ryan Wentzel - 3 Day Course \__Computer Forensics: Handling Live Systems with Open-Source Tools SELECTED SPEAKERS: Mark Ryan Talabis \__Dangerous Minds: The Art of Guerilla Data Mining Wendel Guglielmetti Henrique and Sandro Gauci \__The Truth about Web Application Firewalls Mark Stamford \__$1.7 Trillion Under Siege Jared DeMott \__Exploit or Exception? Riley Hassell \__Exploiting Rich Content Matthieu Suiche \__Challenge of Windows physical memory acquisition and exploitation Moti Joseph \__Microsoft patches little sister but forgets big brother Deviant Ollam \__Packing and the Friendly Skies Luke McOmie (Pyr0) \__The Art of Espionage Tiller Beauchamp \__Dynamic Tracing for Exploitation and Fuzzing Sarah Blankinship and Jon Pincus \__Securing With the Enemy: Social Strategy and Teams of Rivals Alberto Revelli and Nico Leidecker \__Playing with Heyoka: Spoofed Tunnels and Undetectable Data Daniel Blander \__Emerging Trends in Security and Risk Management Andrea Barisani & Daniele Bianco, Inverse Path \__Sniff keystrokes with lasers/voltmeters: Side Channel Attacks Paul Craig \__Rage Against the Kiosk Joe McCray \__Advanced SQL Injection http://www.shakacon.org ALOHA FROM THE SHAKACON CREW! Follow Status on: http://www.twitter.com/shakacon ####################################### ShakaCon III Crew Hawaii: Home of Sun, Surf, and C Shells ####################################### This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090519/ed1c5180/attachment.htm From dave at kof.immunityinc.com Tue May 19 19:44:15 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Tue, 19 May 2009 19:44:15 -0400 Subject: [Dailydave] entropicdata.com ? Message-ID: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Lots of people are doing things in web services (AJAX, etc) that require real crypto. So they implement RSA/twofish/etc in Javascript and run that in the browser. But this requires a way to generate a key which requires some entropy. There's no "feed of random numbers" that I know of on the web that you can use to seed your crypto, probably because of cross site restrictions. But it seems like either google gears, HTML5, or one of the other new extensions should offer it as a built-in API. Likewise if they allowed you to get data from other sites (which the new Firefox does sometimes?) then you could set up a web service for people to use to get their entropic data from (over SSL of course :>). What else are people using for this? It seems to be a bit of a theme here at SyScan (re: David Thiel's RIA presentation). Is there an API in Silverlight/Flash/etc that lets you get entropy and then give it back to the browser context? -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090519/7b5d654f/attachment.htm From kowsik at gmail.com Tue May 19 21:11:24 2009 From: kowsik at gmail.com (kowsik) Date: Tue, 19 May 2009 18:11:24 -0700 Subject: [Dailydave] entropicdata.com ? In-Reply-To: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: <7db9abd30905191811p318d2597vfb6cdaa10973e5e3@mail.gmail.com> Heh. I think we'll need a random.dv site which has a JSON API to return crap. :-) New startup idea right there. K. On Tue, May 19, 2009 at 4:44 PM, Dave Aitel wrote: > Lots of people are doing things in web services (AJAX, etc) that require > real crypto. So they implement RSA/twofish/etc in Javascript and run that in > the browser. But this requires a way to generate a key which requires some > entropy. There's no "feed of random numbers" that I know of on the web that > you can use to seed your crypto, probably because of cross site > restrictions. But it seems like either google gears, HTML5, or one of the > other new extensions should offer it as a built-in API. > > Likewise if they allowed you to get data from other sites (which the new > Firefox does sometimes?) then you could set up a web service for people to > use to get their entropic data from (over SSL of course :>). > > What else are people using for this? It seems to be a bit of a theme here at > SyScan (re: David Thiel's RIA presentation). Is there an API in > Silverlight/Flash/etc that lets you get entropy and then give it back to the > browser context? > > -dave > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From jon at oberheide.org Tue May 19 21:38:36 2009 From: jon at oberheide.org (Jon Oberheide) Date: Tue, 19 May 2009 21:38:36 -0400 Subject: [Dailydave] entropicdata.com ? In-Reply-To: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: <1242783516.16348.1.camel@apollo> On Tue, 2009-05-19 at 19:44 -0400, Dave Aitel wrote: > Lots of people are doing things in web services (AJAX, etc) that > require real crypto. So they implement RSA/twofish/etc in Javascript > and run that in the browser. But this requires a way to generate a key > which requires some entropy. There's no "feed of random numbers" that > I know of on the web that you can use to seed your crypto, probably > because of cross site restrictions. But it seems like either google > gears, HTML5, or one of the other new extensions should offer it as a > built-in API. > > Likewise if they allowed you to get data from other sites (which the > new Firefox does sometimes?) then you could set up a web service for > people to use to get their entropic data from (over SSL of course :>). random.org has had a HTTP interface available for a while but I can't say I've ever used it: http://random.org/clients/http/ Regards, Jon Oberheide -- Jon Oberheide GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090519/1cd42526/attachment-0001.pgp From jim at manico.net Wed May 20 02:17:51 2009 From: jim at manico.net (Jim Manico) Date: Tue, 19 May 2009 20:17:51 -1000 Subject: [Dailydave] entropicdata.com ? References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: > So they implement RSA/twofish/etc in Javascript and run that in the browser But can't we stop here? Once a solution depends on client-side, especially browser-based client-side encryption, aren't you dead in the water (ie: substancial risk) from the design itself? - Jim ----- Original Message ----- From: Dave Aitel To: dailydave at lists.immunitysec.com Sent: Tuesday, May 19, 2009 1:44 PM Subject: [Dailydave] entropicdata.com ? Lots of people are doing things in web services (AJAX, etc) that require real crypto. So they implement RSA/twofish/etc in Javascript and run that in the browser. But this requires a way to generate a key which requires some entropy. There's no "feed of random numbers" that I know of on the web that you can use to seed your crypto, probably because of cross site restrictions. But it seems like either google gears, HTML5, or one of the other new extensions should offer it as a built-in API. Likewise if they allowed you to get data from other sites (which the new Firefox does sometimes?) then you could set up a web service for people to use to get their entropic data from (over SSL of course :>). What else are people using for this? It seems to be a bit of a theme here at SyScan (re: David Thiel's RIA presentation). Is there an API in Silverlight/Flash/etc that lets you get entropy and then give it back to the browser context? -dave ------------------------------------------------------------------------------ _______________________________________________ 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/20090519/7b555bad/attachment.htm From dave at kof.immunityinc.com Wed May 20 04:39:57 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Wed, 20 May 2009 04:39:57 -0400 Subject: [Dailydave] Java is fun! Message-ID: <4e1ef3e50905200139o1333ccbfp4d5ec6d908f7629a@mail.gmail.com> So here are a couple of blog posts about a great bug that has been used to great effect and is in a CANVAS installation near you! http://blog.cr0.org/2009/05/write-once-own-everyone.html http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html Basically, you get to execute Java code as the user if they visit your web page and have Java turned on. This is default in Fedora, for example, and Bas handily owned my laptop with it. In CANVAS you don't execute commands so much as get a JavaNode connectback (which is somewhat similar to MOSDEF). Anyways, it's one of my favorite updates to CANVAS recently. Go Julian and his wacky ReplaceObject() tricks! :> -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090520/a038914a/attachment.htm From lcamtuf at coredump.cx Wed May 20 06:00:49 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Wed, 20 May 2009 12:00:49 +0200 Subject: [Dailydave] entropicdata.com ? In-Reply-To: References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: <448e9a320905200300t2d7450cfg1d2316f804c1a307@mail.gmail.com> > But can't we stop here? Once a solution depends on client-side, especially > browser-based client-side encryption, aren't you dead in the water (ie: > substancial risk) from the design itself? There are several legitimate reasons for implementing client-side crypto; you might be devising an algorithm that actually tries to protect the user against compromised servers or routers; or you might be trying to prove user's intent (think XSRF defenses) or maintain stream identity and integrity (e.g., for hacky cross-domain communications) without the need to waste time on obtaining single-use crypto tokens from a server. That said, in the first case, you generally should not rely on server-provided data anyway, and you need a local mechanism to gather entropy. Right now, it could be achieved in a number of hackish ways, and in the long run, it might be beneficial to provide standard APIs for this purpose within browsers (there is a trade-off to be made, though: letting applications to sample, deplete, and detect availability of data in the interrupts-driven OS entropy poll, creates a number of interesting security problems). In the latter cases, OTOH, it should be OK to use a seed provided by the server, either inserted into the returned Javascript, or requested via XMLHttpRequest or so. /mz From arshan.dabirsiaghi at aspectsecurity.com Wed May 20 14:40:03 2009 From: arshan.dabirsiaghi at aspectsecurity.com (Arshan Dabirsiaghi) Date: Wed, 20 May 2009 14:40:03 -0400 Subject: [Dailydave] entropicdata.com ? In-Reply-To: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: Secure, flexible, client-side key generation capability is already available in Firefox through the sort-of bizarre tag [1]. I haven't researched the tag much but I'm sure it's a much better source of general entropy out of the box than Math.random(), despite the fact that that's not the intended use. Try it out locally:
In case your reader doesn't see the above HTML, see [2]. It would be trivial to write JavaScript to automatically submit the invisible form to a hidden iframe on your origin and read the key value from various iframe properties. This would make the generation seamless, except for the non-threatening dialog Firefox briefly pops up. If you don't like it, it may be possible to redress it; I haven't tried. Right now it's more of a novelty than anything else - maybe at worst a stop-gap for the FF segment of your users. However, I strongly agree that crypto functionality is needed on the client-side. Its presence in, say, a readily available JavaScript API could encourage na?ve people to do na?ve things, but my counterargument is that they're doing na?ve things now, with badly written APIs, which is almost surely worse. - Arshan [1] https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag [2] http://i8jesus.com/stuff/keygen/keygen.html From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave Aitel Sent: Tuesday, May 19, 2009 7:44 PM To: dailydave at lists.immunitysec.com Subject: [Dailydave] entropicdata.com ? Lots of people are doing things in web services (AJAX, etc) that require real crypto. So they implement RSA/twofish/etc in Javascript and run that in the browser. But this requires a way to generate a key which requires some entropy. There's no "feed of random numbers" that I know of on the web that you can use to seed your crypto, probably because of cross site restrictions. But it seems like either google gears, HTML5, or one of the other new extensions should offer it as a built-in API. Likewise if they allowed you to get data from other sites (which the new Firefox does sometimes?) then you could set up a web service for people to use to get their entropic data from (over SSL of course :>). What else are people using for this? It seems to be a bit of a theme here at SyScan (re: David Thiel's RIA presentation). Is there an API in Silverlight/Flash/etc that lets you get entropy and then give it back to the browser context? -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090520/f08df95c/attachment-0001.htm From kf_lists at digitalmunition.com Wed May 20 15:48:14 2009 From: kf_lists at digitalmunition.com (KF (lists)) Date: Wed, 20 May 2009 15:48:14 -0400 Subject: [Dailydave] Java is fun! In-Reply-To: <4e1ef3e50905200139o1333ccbfp4d5ec6d908f7629a@mail.gmail.com> References: <4e1ef3e50905200139o1333ccbfp4d5ec6d908f7629a@mail.gmail.com> Message-ID: <188828B6-5DC7-4ADA-A708-135FA1613686@digitalmunition.com> Landon was nice enough to leave the .class files non obfuscated for those of you that missed it... http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/HelloWorldApplet.class http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/t.tmp http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/javax/Exec.class http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/javax/Exec$1.class http://landonf.bikemonkey.org/static/moab-tests/CVE-2008-5353/fun/FunLoader.class http://www.varaneckas.com/jad -KF On May 20, 2009, at 4:39 AM, Dave Aitel wrote: > So here are a couple of blog posts about a great bug that has been > used to great effect and is in a CANVAS installation near you! > > http://blog.cr0.org/2009/05/write-once-own-everyone.html > http://landonf.bikemonkey.org/code/macosx/CVE-2008-5353.20090519.html > > Basically, you get to execute Java code as the user if they visit > your web page and have Java turned on. This is default in Fedora, > for example, and Bas handily owned my laptop with it. In CANVAS you > don't execute commands so much as get a JavaNode connectback (which > is somewhat similar to MOSDEF). > > Anyways, it's one of my favorite updates to CANVAS recently. Go > Julian and his wacky ReplaceObject() tricks! :> > > -dave > > _______________________________________________ > 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/20090520/0b425c23/attachment-0001.htm From dave at kof.immunityinc.com Wed May 20 20:29:43 2009 From: dave at kof.immunityinc.com (Dave Aitel) Date: Wed, 20 May 2009 20:29:43 -0400 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. Message-ID: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> A few things stand out from my thoughts here, as I pack up to return from Hong Kong. The first thing is that Microsoft's best hope for Windows is to make it the only platform you can trust with your identity. If you have "end to end trust" then your ISP can say "only machines signed to your identity are allowed on the Internet". They can sell you internet where only IE can access it. How cool is that? See, not cool at all. Consumers hate it and people don't trust Microsoft as a company, which is why the people excited about it are DRM focused or just evil in general. But having the whole stack be "trusted" with a global PKI system is something your bank wants so that it can lower fraud rates. Having every email you send and recieve encrypted and signed (obviously the default will be signed only, for political reasons) will eliminate spam as a matter of due course. There's just so many good things that come with "end to end trust". You could send an email from a trojaned box securely to someone else with a trojaned box. The title bar of your window would say "signed to Microsoft Outlook" and the hypervisor would encrypt the whole transaction from your keyboard presses to the pixel display in a process space no other process or kernel task can access. If this comes to pass, Windows is literally your wallet, and gets cemented in the ecosystem as the only thing that can hold your money and identity. It's a good play and it's still a primary focus for Microsoft - still their best hope for regaining prominance. It might even work. And of course, there was a lot of chatter at SyScan about cloud computing. The smart money is bearish on it. Google and the other cloud providers want to convince businesses that no matter how sensitive their data is, you can store it on a shared infrastructure. This is not even close to true. Shared infrastructures are the next generation of shared hosting providers - they're for students and open source projects. Not businesses and definately not governments. Eventually we'll see the cloud providers move towards offering private clouds with better security guarantees, which is when adoption will start really accellarating. It used to be banks were becoming IT companies, but now it's IT companies that are becoming banks, all asking us to trust them more than their competition. The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does. With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer. Anyways, a fun SyScan. Next stop Miami! -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090520/7e02ebbf/attachment.htm From curtw at siu.edu Thu May 21 09:58:10 2009 From: curtw at siu.edu (Curt Wilson) Date: Thu, 21 May 2009 08:58:10 -0500 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> Message-ID: <4A155DF2.9040400@siu.edu> I'm no expert on hypervisors, but I'm curious - in this scenario, what's to stop a trojan from inserting itself between the hypervisor and keystrokes? If malware such as Torpig, Zeus and the like are any indication of the future threat in this area, then it may be a tall order to ensure "end to end trust" on a trojaned box. Given the routine violation of various protection mechanisms, how to best ensure the protected process space? Dave Aitel wrote: > There's just so many good things that come with "end to end > trust". You could send an email from a trojaned box securely to someone else > with a trojaned box. The title bar of your window would say "signed to > Microsoft Outlook" and the hypervisor would encrypt the whole transaction > from your keyboard presses to the pixel display in a process space no other > process or kernel task can access. From joanna at invisiblethingslab.com Thu May 21 05:44:35 2009 From: joanna at invisiblethingslab.com (Joanna Rutkowska) Date: Thu, 21 May 2009 11:44:35 +0200 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> Message-ID: <4A152283.7070608@invisiblethingslab.com> Dave Aitel wrote: > A few things stand out from my thoughts here, as I pack up to return from > Hong Kong. > > The first thing is that Microsoft's best hope for Windows is to make it the > only platform you can trust with your identity. If you have "end to end > trust" then your ISP can say "only machines signed to your identity are > allowed on the Internet". They can sell you internet where only IE can > access it. How cool is that? See, not cool at all. Consumers hate it and > people don't trust Microsoft as a company, which is why the people excited > about it are DRM focused or just evil in general. > Yes, this is how most people perceive Trusted Computing (AKA Palladium), but in practice this is not true and will not be anytime soon. Two main reasons: 1) The functionality you describe require Remote Attestation (TPM Quote command) to work. There is a small catch however -- how does a remote system know that it is "talking" to a genuine TPM and not software emulated TPM? (more precisely: that the key used for signing the TPM Quote "packet" has been generated on a TPM and not in software?). This is where the EK (Endorsement Key) keys comes into play -- the theory says that the vendor should embed an EK keypair in each TPM (unique to each TPM) they sell. They should also publish certificates for all the EKs for their chips (e.g. on their website). In other words EK is a root of trust for reporting for each TPM and can be used to validate that a certain message has been signed by a genuine TPM indeed (in fact, the various books say, EK should never be used for remote attestation directly, as it betrays the actual unique identity of the platform. Here is where AIK comes into play, but the details are not so important here). The problem is that a couple of TPMs we have looked at (all TPM 1.2) in our lab haven't got any EK embedded. They were just blank. This means they cannot be used, even in the future, to e.g. attest to Warner Bros. or AOL that you're using Windows -- as simply the Warner Bros. or AOL will not be able to determine that they are "talking with" a genuine TPM. Of course one cannot also imagine Warner Bros or AOL to ask users to generate EKs and send the public portion to them, as they would again have no assurance that the users indeed generated their EKs on TPMs and not in software (when you generate an EK on a TPM you don't have access to the corresponding private key, unless you're Chirs Tarnovsky I guess). In other words, a TPM without an EK written at the manufacturing process cannot prove to a remote entity that it is a TPM. Which means we can still run Linux and connect to all those Warner Bros. or AOL services. 2) Even assuming that all TPMs ship with EKs (and vendors publish certificates for them), I still don't see how this could be used to implement the scenario Dave's (and a lot of other people) talking about here: "They can sell you internet where only IE can access it." Whether you use Static Root of Trust (think TPM only, like in BitLocker) or Dynamic Root of Trust (think Intel TXT), you only assure trusted boot of the *core* system components, e.g. the hypervisor or kernel. Now, it's the responsibility of the kernel to load (in a trusted way) all the hundreds of 3rd party kernel drivers (we see an effort here by MS in Vista x64 with driver signing), then all the libs and all the apps. So far so good -- this is doable. But here is where the actual catch is: now the kernel must make sure that when the system is running nobody can compromise all those hundreds of drivers in *runtime* (think overflows), and also that nobody can compromise all those system libs in *runtime*, and that nobody can compromise all those sensitive applications (like IE, or Media Player) in *runtime* (think Dino/Charlie and Nil). A single compromise of any of those elements means that one can get to the address space of one of the sensitive apps (IE or Media Player) and steal all the keys it just obtained from the remote entity (that happily verified the app via Remote Attestation and concluded it is a trusted software). So, a single exploit for one of the drivers, system libs, or the apps, and all your keys are belong to the adversary, who I guess will happily post it on the internet for all the Linux's pleasure. Consequently, for the TC-based DRM to ever work, the following things would have to happen: 1) Vendors should be embedding EK on TPMs they sell (and also issue certs) -- this is all possible, but what about millions of the computers that already have TPM 1.2 and don't have an EK? 2) Microsoft would have to migrate towards a micro-kernel-like architecture, e.g. similar to the used by Xen 3.3/3.4 with driver domains etc. Additionally they should make sure it will not be possible to exploit any of the sensitive apps like e.g. IE or Media Player. Do you think point #2 is possible anytime soon? I seriously doubt it. Oh, and this is actually what I will be talking about at the EuSecWest next week (in addition to evil maids and malicious Chinese PCI backdoors) :) > > The other thing that keeps coming up is memory forensics. You can do a lot > with it today to find trojan .sys's that hackers are using - but it has a > low ceiling I think. Most rootkits "hide processes", or "hide sockets". But > it's an insane thing to do in the kernel. If you're in the kernel, why do > you need a process at all? I couldn't agree more: http://invisiblethings.org/papers/rutkowska_bhfederal2006.ppt (slide #14 and later) Welcome in 2006 :) joanna. -- Joanna Rutkowska Founder/CEO Invisible Things Lab http://invisiblethingslab.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 226 bytes Desc: OpenPGP digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090521/382c8ad9/attachment.pgp From ben at iagu.net Fri May 22 04:25:35 2009 From: ben at iagu.net (Ben Nagy) Date: Fri, 22 May 2009 16:25:35 +0800 Subject: [Dailydave] Cloud fuzzing. In-Reply-To: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> References: <4e1ef3e50905122312l60e7b385t24df66a14bbca364@mail.gmail.com> Message-ID: <6bbf5a3f0905220125q14799bdch9cafb5e8e9b898ac@mail.gmail.com> I just thought I'd drop in a few details here, based on some questions I've been getting. On Wed, May 13, 2009 at 2:12 PM, Dave Aitel wrote: > Today at SyScan Ben Nagy of COSEINC gave a talk on a fuzzing cluster > he's built that does 1.2 million fuzz cases a day against Word 2007. The arithmetically inclined will, of course, note that 20 tests / sec is more like 1.7 mil / day. Currently I'm cruising at more like 25/s - this is with full page heap enabled, which roughly halves the speed. The main reason I wanted to give a lot of metrics is so that someone else will bite and release theirs. :) We use 5 Quad-Xeon servers, and the total cost was around $15k USD. Running 72 clients under ESXi, I figure we broke even over EC2 after about 3 months. Plus, Kostya can't cloudburst me and steal all my 0day when the machines are on an in-house cluster. :P > He's using !exploitable for WinDBG to get an approximation of the > problem. It's a talk full of real metrics. !exploitable is fantastic for grouping crashes, and providing a rough description of the problem. I don't trust its assessment of the result in absolute terms, but this is a hard problem. I just deleted 250k files which all triggered what seems to be a very common and useless bug, and I have about 60k left, spread across ~25 'buckets' (although only about 15 distinct eips, the rest are split up because of different crash states). > 10% cause crashes Quite a few people said that this seems high. It is. I mentioned in the talk that those stats depend very much on the test case generator I am running. The talk was mainly about the harness and general Word info that others can use as a Quick Start manual for distributed Word fuzzing. I didn't talk much about my own case generation, mainly because I don't believe that's the hard part, but partially because not everything about what I'm doing is ready for public release. To get the percentage that high I need to parse the OLE2 file structure, parse the File Information Block, use that to find a specific structure, parse that structure out, and then start manipulating the internal fields. Once I run that, I find some field values that caused crashes and refine the case generator to focus on those fields. So, it's both deep and "adaptive" (which is a term I hate) in the sense that a human writes an iteratively deeper fuzzer. My case generators are not adaptive, intelligent, game changing, new or particularly clever. They are, however, in Ruby. I'm pretty sure we're going to release the harness and the parsers under some kind of OSS license for SyScan Singapore. > A small percentage say they are possibly exploitable, and out of > those, largely false positives. These are all _crashes_, not failures, so false positive is only used here in the sense that !exploitable says "UNKNOWN" or "PROBABLY EXPLOITABLE". For example it sees any read AV on a block data move and figures it will play it safe with "PROBABLY EXPLOITABLE". > The problem of fuzzing is exponential, but if you architect your > fuzzer right, you can scale linearly with your budget. Perhaps your > budget also grows exponentially? :> Yes, soon I plan to have it automatically sell the bugs, and place online orders to Dell with the proceeds. :) > The problems for the future are interesting. Classification of > potential exploitability ?is a problem that involves diffing program > runs, examining programs deeply for structure and behavior, and all > this has to scale up with your 200K cases a day. And this is where I'm going to be spending my time for a while. There is lots of really excellent work out there by lots of people, but adapting it to get fully hands-free operation is not trivial. Answers on a postcard, please. :) Cheers, ben From dave.aitel at gmail.com Fri May 22 07:33:43 2009 From: dave.aitel at gmail.com (Dave Aitel) Date: Fri, 22 May 2009 07:33:43 -0400 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4A155DF2.9040400@siu.edu> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> <4A155DF2.9040400@siu.edu> Message-ID: Most people don't really understand Palladium, since it is quite complex, but it's not a software only solution. You'd need a special Palladium enabled keyboard, mouse, display, and audio IO setup. These would each have crypto chips in them which could encrypt to and from the trusted hypervisor. Look for them in a Microsoft store near you real soon! As Joanna points out, this requires a special kind of key (the EV) to be inserted on your motherboard by the manufacturer, which they are not doing yet probably because the politics of a global PKI system are unbelievably hilarious. Until then, you can software emulate Palladium, but once that becomes ubuquitous, then it's going to be a rapid change (~5 years?) before breaking DRM requires hardware modifications. -dave On Thu, May 21, 2009 at 9:58 AM, Curt Wilson wrote: > > I'm no expert on hypervisors, but I'm curious - in this scenario, what's > to stop a trojan from inserting itself between the hypervisor and > keystrokes? If malware such as Torpig, Zeus and the like are any > indication of the future threat in this area, then it may be a tall > order to ensure "end to end trust" on a trojaned box. Given the routine > violation of various protection mechanisms, how to best ensure the > protected process space? > > Dave Aitel wrote: > > > >> There's just so many good things that come with "end to end >> trust". You could send an email from a trojaned box securely to someone else >> with a trojaned box. The title bar of your window would say "signed to >> Microsoft Outlook" and the hypervisor would encrypt the whole transaction >> from your keyboard presses to the pixel display in a process space no other >> process or kernel task can access. > > > > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From joanna at invisiblethingslab.com Fri May 22 10:07:43 2009 From: joanna at invisiblethingslab.com (Joanna Rutkowska) Date: Fri, 22 May 2009 16:07:43 +0200 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> <4A155DF2.9040400@siu.edu> Message-ID: <4A16B1AF.6030103@invisiblethingslab.com> Dave Aitel wrote: > Most people don't really understand Palladium, since it is quite > complex, but it's not a software only solution. You'd need a special > Palladium enabled keyboard, mouse, display, and audio IO setup. These > would each have crypto chips in them which could encrypt to and from > the trusted hypervisor. Look for them in a Microsoft store near you > real soon! > There is a book about Trusted Computing by David Grawrock, one of the main architects behind TXT and I think also TPM [1] published by Intel press. This book indeed talks about Protected Input/Output (as part of the LaGrande technology, later renamed to TXT). However there is no mention of those Protected Input/Output technologies in any other Intel spec we have been able to get into our hands. It seems like the current technology (e.g. Intel TXT) doesn't have any support for Protected Input/Output. In other words the TXT as we can buy it today (in vPro-compatible hardware) is "only" about trusted boot via DRTM and nothing else. I wrote "only" in quotation marks, as I think providing trusted boot that really works, is still a really big deal. Of course in the next release of processors, Intel or AMD might theoretically add Protected Input/Output. But I'm still skeptical about effectiveness of such technologies in protecting the end-user apps. We cannot offload all the sensitive tasks to the hypervisor, e.g. processing of our banking site one time passwords, etc, because once we start doing that, the hypervisor will grow fat and likelihood of an exploitable bug inside the hypervisor will increase dramatically. And we will get back to the point where we are today with our fat kernelmodes polluted by all sorts of AV, IPS and DLP rootkits^Wmodules, that are easily exploitable by malware. joanna. [1] http://www.intel.com/intelpress/sum_secc.htm -- Joanna Rutkowska Founder/CEO Invisible Things Lab http://invisiblethingslab.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 226 bytes Desc: OpenPGP digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090522/2b9918fc/attachment-0001.pgp From nate at root.org Fri May 22 17:17:26 2009 From: nate at root.org (Nate Lawson) Date: Fri, 22 May 2009 14:17:26 -0700 Subject: [Dailydave] entropicdata.com ? In-Reply-To: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> Message-ID: <4A171666.5010704@root.org> Dave Aitel wrote: > Lots of people are doing things in web services (AJAX, etc) that require > real crypto. So they implement RSA/twofish/etc in Javascript and run > that in the browser. But this requires a way to generate a key which > requires some entropy. There's no "feed of random numbers" that I know > of on the web that you can use to seed your crypto, probably because of > cross site restrictions. But it seems like either google gears, HTML5, > or one of the other new extensions should offer it as a built-in API. > > Likewise if they allowed you to get data from other sites (which the new > Firefox does sometimes?) then you could set up a web service for people > to use to get their entropic data from (over SSL of course :>). > > What else are people using for this? It seems to be a bit of a theme > here at SyScan (re: David Thiel's RIA presentation). Is there an API in > Silverlight/Flash/etc that lets you get entropy and then give it back to > the browser context? Hold on here. You're running Javascript RSA in your browser. Where did that Javascript come from? Right, you have to load it over SSL to be sure the Javascript is unmodified. But if you're already using SSL, any crypto you implement browser-side can only be less reviewed and more likely to explode, in addition to requiring SSL anyway. Loading your random data over HTTP is a bad idea too. DSA reveals your private key to an attacker if even a few bits of the random nonce are predictable: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ Please stop Web 2.0 from reimplementing crypto, badly. Help computer! -- Nate From butlerjr at acm.org Sun May 24 06:13:19 2009 From: butlerjr at acm.org (James Butler) Date: Sun, 24 May 2009 06:13:19 -0400 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> Message-ID: Dave Aitel wrote: _________________ The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does. With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer. ----------------- Dave, I know we spoke about this a few weeks ago, but I did not get a chance to state my disagreement with your opinion. You state that you can do a lot with memory forensics today to find trojan drivers (.sys), and you can. Last time I looked at CANVAS with MOSDEF you were hiding sockets using a TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. First, you are hooking IRPs which are easy to check. Secondly, you are hiding a port by filtering a query to tcpip.sys, but with memory forensics you cannot filter because nothing is queried. Now could MOSDEF be written in a way that more subtly disguised the hook? Certainly and perhaps you already have. Is it possible to create a port for communication without creating a port object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort increases tremendously. Deepdoor still used hooks to intercept packets. The hooks were just hidden deeper than anyone had looked. So yes it is an arms race to "counteract every tiny thing a rootkit writer does", but when doing detection I do not have to detect "every tiny thing" just some things. I will not argue with the fact there is no need to hide processes. Joanna, Greg, etc. have been saying that for years. However, a lot of intruders still use this technique for whatever reason. Let's use memory forensics and eliminate that problem forever. Can memory forensics find traces of CANVAS shellcode? Yes, but it is an extremely expensive operation in regard to time. Does it have false positives? Yes, but instead of looking at perhaps 100 memory sections across 100 processes memory forensics can narrow that down to four or five. Another thing that falls quickly to memory forensics is poor coding practices by the exploit writers. If a handle is left open by mistake or memory is not freed, it is quickly spotted. Peter Silberman has used this to reconstruct the command and control communications of another popular pentesting tool. Does this mean you cannot bypass this detection with proper developers? No. Don't forget though that freed does not necessarily mean gone. Using memory forensics common but stupid techniques malware author's use to prevent reinfecting a box are much easier to spot. For example, with memory forensics you can find all the mutexes a process has open. This might seem like a small thing, but memory forensics is giving us a view into what is happening on the host in ways we did not have before. Is the gradient against memory forensics? Perhaps, but it always is as your attacker evolves. I think now there is more of a gradient for the malware authors than there has been. They have been fighting the war on the disk for a long time. Now it is time they look up to memory as we sharpen our tools for the changing battlefield. Jamie Check here to play with memory forensic tools: http://mandiant.com/software/memoryze.htm to be used with http://www.mandiant.com/software/mav.htm http://www.openrce.org/articles/full_view/32 From alex at sotirov.net Sun May 24 14:39:02 2009 From: alex at sotirov.net (Alexander Sotirov) Date: Sun, 24 May 2009 14:39:02 -0400 Subject: [Dailydave] WOOT'09 Message-ID: <20090524183902.GA4162@MacBook.local> Hi, I want to remind everybody that WOOT'09 is still accepting submissions, but the CFP closes next week: http://www.usenix.org/event/woot09/cfp/ We encourage submissions of work that has been presented at BlackHat or other industry conferences but is well suited to a more formal and complete treatment in a academic peer-reviewed setting. I believe that both the academic and industry communities will benefit from this exchange of ideas. Alex -------------- 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/20090524/ba55050b/attachment.pgp From bania.piotr at gmail.com Mon May 25 12:19:14 2009 From: bania.piotr at gmail.com (Piotr Bania) Date: Mon, 25 May 2009 18:19:14 +0200 Subject: [Dailydave] PAPER: Generic Unpacking of Self-modifying, Aggressive, Packed Binary Programs Message-ID: <23A8384A2B924CA4A0EE682F8C1C6C87@DIED> ABSTRACT Nowadays most of the malware applications are either packed or protected. This techniques are applied especially to evade signature based detectors and also to complicate the job of reverse engineers or security analysts. The time one must spend on unpacking or decrypting malware layers is often very long and in fact remains the most complicated task in the overall process of malware analysis. In this report author proposes MmmBop as a relatively new concept of using dynamic binary instrumentation techniques for unpacking and bypassing detection by self-modifying and highly aggressive packed binary code. MmmBop is able to deal with most of the known and unknown packing algorithms and it is also suitable to successfully bypass most of currently used anti-reversing tricks. [...] Paper can be found at: http://piotrbania.com/all/articles/pbania-dbi-unpacking2009.pdf best regards, pb -- -------------------------------------------------------------------- Piotr Bania - - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://www.piotrbania.com - Key ID: 0xBE43AC33 -------------------------------------------------------------------- - "The more I learn about men, the more I love dogs." From dave.aitel at gmail.com Tue May 26 22:57:40 2009 From: dave.aitel at gmail.com (Dave Aitel) Date: Tue, 26 May 2009 22:57:40 -0400 Subject: [Dailydave] entropicdata.com ? In-Reply-To: <4A171666.5010704@root.org> References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> <4A171666.5010704@root.org> Message-ID: Sure so one perspective is that anything cryptographic has to get done on the server. Which seems perfectly valid, but in some cases people don't want to do it that way. Maybe they want to sign something, without having to upload it to the server, say. Or maybe they just don't want to burden the server with tons of crypto. There's lots of good reasons to do crypto without reinventing SSL. And, of course, the cross domain stuff coming out makes this more likely, I assume. -dave > > Hold on here. You're running Javascript RSA in your browser. Where did > that Javascript come from? Right, you have to load it over SSL to be > sure the Javascript is unmodified. But if you're already using SSL, any > crypto you implement browser-side can only be less reviewed and more > likely to explode, in addition to requiring SSL anyway. > > Loading your random data over HTTP is a bad idea too. DSA reveals your > private key to an attacker if even a few bits of the random nonce are > predictable: > http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ > http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ > > Please stop Web 2.0 from reimplementing crypto, badly. Help computer! > > -- > Nate > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From steve at binarypool.com Tue May 26 04:02:03 2009 From: steve at binarypool.com (Steve Micallef) Date: Tue, 26 May 2009 18:02:03 +1000 Subject: [Dailydave] IDA Plug-in writing tutorial (v1.1) Message-ID: <4A1BA1FB.2000207@binarypool.com> Hi all, For those who might be interested, I've updated the IDA Plug-in Writing Tutorial to cover IDA Pro 5.4. The SDK was mostly frozen as of 4.9, although there have been some subtle changes. All in all there are about 10 new pages including some corrections, new functions and a new sample plug-in. Get it here: http://www.binarypool.com/idapluginwriting/ Feel free to drop me a note with any comments or corrections. Cheers, Steve Micallef From dave at immunityinc.com Wed May 27 11:47:55 2009 From: dave at immunityinc.com (dave) Date: Wed, 27 May 2009 11:47:55 -0400 Subject: [Dailydave] Cliph Message-ID: <4A1D60AB.60703@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those who are not aware, Cliph passed away in a plane accident recently. http://www.isec.pl/ has more information about the funeral. He was, among other things, a great hacker. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkodYKsACgkQtehAhL0gheoMkACeNekDqO1sDPLQiqAG/2c8kglv MPgAn1vG7ySg+fSoyLcEk04cGKqvWooK =qyjL -----END PGP SIGNATURE----- From nate at root.org Wed May 27 12:00:14 2009 From: nate at root.org (Nate Lawson) Date: Wed, 27 May 2009 09:00:14 -0700 Subject: [Dailydave] entropicdata.com ? In-Reply-To: References: <4e1ef3e50905191644x3ef47aa0w74901d7701a0928a@mail.gmail.com> <4A171666.5010704@root.org> Message-ID: <4A1D638E.1020301@root.org> Dave Aitel wrote: > Sure so one perspective is that anything cryptographic has to get done > on the server. Which seems perfectly valid, but in some cases people > don't want to do it that way. > > Maybe they want to sign something, without having to upload it to the > server, say. Or maybe they just don't want to burden the server with > tons of crypto. There's lots of good reasons to do crypto without > reinventing SSL. Could you finish your example? They are signing something, which is verified by ... ? Any scenario I come up with to complete your example has problems. Where does the private key come from to sign it? How did the web browser get this key and code. Where does the recipient of this data get the cert to validate the signature? > And, of course, the cross domain stuff coming out makes this more > likely, I assume. I'm interested in your proposal here. How would Javascript signatures help? -Nate >> Hold on here. You're running Javascript RSA in your browser. Where did >> that Javascript come from? Right, you have to load it over SSL to be >> sure the Javascript is unmodified. But if you're already using SSL, any >> crypto you implement browser-side can only be less reviewed and more >> likely to explode, in addition to requiring SSL anyway. >> >> Loading your random data over HTTP is a bad idea too. DSA reveals your >> private key to an attacker if even a few bits of the random nonce are >> predictable: >> http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ >> http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ >> >> Please stop Web 2.0 from reimplementing crypto, badly. Help computer! >> >> -- >> Nate From dave at immunityinc.com Wed May 27 13:33:04 2009 From: dave at immunityinc.com (dave) Date: Wed, 27 May 2009 13:33:04 -0400 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> Message-ID: <4A1D7950.7020807@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Certainly the CANVAS kernel rootkit is not a covert one. I think it would be somewhat expensive to do basic adversarial testing in the kernel space on this, although I think it would be valuable research for the community. Is memory forensics "testable" against userspace? Memoryze can find hidden sockets and stuff, but I remember a paper from Peter on "finding shellcode" or something. Is that publicly available? Something Bill Arbaugh said is that one major advantage for memory forensics is that a machine has a lot less memory than it does disk space. Searching through disk space (or even storing it if you do enough forensics) is extremely expensive. To your credit you've released a lot of tools in the space people can use for testing the general concepts, which is a valuable thing for determining the overall level of effort curve of the technology itself. Hopefully soon I'll have some real world numbers here for you. :> Do the DD.exe and similar tools go underneath the memory handlers? I assume modern rootkits are memory handlers (or hypervisors). I'm not sure how acquisition really works against that. - -dave > Dave, > > I know we spoke about this a few weeks ago, but I did not get a chance to > state my disagreement with your opinion. You state that you can do a lot > with memory forensics today to find trojan drivers (.sys), and you can. Last > time I looked at CANVAS with MOSDEF you were hiding sockets using a > TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. > First, you are hooking IRPs which are easy to check. Secondly, you are > hiding a port by filtering a query to tcpip.sys, but with memory forensics > you cannot filter because nothing is queried. Now could MOSDEF be written in > a way that more subtly disguised the hook? Certainly and perhaps you already > have. > > Is it possible to create a port for communication without creating a port > object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort > increases tremendously. Deepdoor still used hooks to intercept packets. The > hooks were just hidden deeper than anyone had looked. So yes it is an arms > race to "counteract every tiny thing a rootkit writer does", but when doing > detection I do not have to detect "every tiny thing" just some things. > > I will not argue with the fact there is no need to hide processes. Joanna, > Greg, etc. have been saying that for years. However, a lot of intruders > still use this technique for whatever reason. Let's use memory forensics and > eliminate that problem forever. > > Can memory forensics find traces of CANVAS shellcode? Yes, but it is an > extremely expensive operation in regard to time. Does it have false > positives? Yes, but instead of looking at perhaps 100 memory sections across > 100 processes memory forensics can narrow that down to four or five. Another > thing that falls quickly to memory forensics is poor coding practices by the > exploit writers. If a handle is left open by mistake or memory is not freed, > it is quickly spotted. Peter Silberman has used this to reconstruct the > command and control communications of another popular pentesting tool. Does > this mean you cannot bypass this detection with proper developers? No. Don't > forget though that freed does not necessarily mean gone. > > Using memory forensics common but stupid techniques malware author's use to > prevent reinfecting a box are much easier to spot. For example, with memory > forensics you can find all the mutexes a process has open. This might seem > like a small thing, but memory forensics is giving us a view into what is > happening on the host in ways we did not have before. > > Is the gradient against memory forensics? Perhaps, but it always is as your > attacker evolves. I think now there is more of a gradient for the malware > authors than there has been. They have been fighting the war on the disk for > a long time. Now it is time they look up to memory as we sharpen our tools > for the changing battlefield. > > Jamie > > Check here to play with memory forensic tools: > http://mandiant.com/software/memoryze.htm to be used with > http://www.mandiant.com/software/mav.htm > http://www.openrce.org/articles/full_view/32 > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkodeVAACgkQtehAhL0ghep2pQCdHp3o+dwUrMvn9zDSLJEbsqeJ ey0AnjOkrGMGaT3aMEur8lI78bQKhO+t =lnhV -----END PGP SIGNATURE----- From msuiche at gmail.com Wed May 27 15:39:47 2009 From: msuiche at gmail.com (Matthieu Suiche) Date: Wed, 27 May 2009 21:39:47 +0200 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4A1D7950.7020807@immunityinc.com> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> <4A1D7950.7020807@immunityinc.com> Message-ID: <36615a170905271239w56f38da7i871207feb037a66a@mail.gmail.com> > Do the DD.exe and similar tools go underneath the memory handlers? I > assume modern rootkits are memory handlers (or hypervisors). I'm not > sure how acquisition really works against that. I guess, you mean software-based acquisition. Moreover, Loic Duflot, BSDeamon, folks from Invisible Things and folks from University of Central Florida demonstrated SMM mode is more privileged than Virtualization mode. So I assume modern physical memory acquisition tools take care of this problem. Im not sure how memory handling really works against that. More seriously last time I publicly heard about a rootkit using anti forensics tricks against physical memory acquisition was Rustock.C which used KeRegisterBugCheckCallback() function to clean its memory if a BSOD was invoked. -- Matthieu Suiche From hal999 at att.blackberry.net Wed May 27 15:43:19 2009 From: hal999 at att.blackberry.net (hal999 at att.blackberry.net) Date: Wed, 27 May 2009 19:43:19 +0000 Subject: [Dailydave] Dailydave Digest, Vol 46, Issue 8 In-Reply-To: References: Message-ID: <143835284-1243453449-cardhu_decombobulator_blackberry.rim.net-1306688044-@bxe1096.bisx.prod.on.blackberry> Yeah, you would come now. H Sent via BlackBerry by AT&T -----Original Message----- From: dailydave-request at lists.immunitysec.com Date: Wed, 27 May 2009 13:34:27 To: Subject: Dailydave Digest, Vol 46, Issue 8 Send Dailydave mailing list submissions to dailydave at lists.immunitysec.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.immunitysec.com/mailman/listinfo/dailydave or, via email, send a message with subject or body 'help' to dailydave-request at lists.immunitysec.com You can reach the person managing the list at dailydave-owner at lists.immunitysec.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Dailydave digest..." Today's Topics: 1. Re: entropicdata.com ? (Nate Lawson) 2. Re: Palladium, Memory Forensics, Clouds. (James Butler) 3. WOOT'09 (Alexander Sotirov) 4. PAPER: Generic Unpacking of Self-modifying, Aggressive, Packed Binary Programs (Piotr Bania) 5. Re: entropicdata.com ? (Dave Aitel) 6. IDA Plug-in writing tutorial (v1.1) (Steve Micallef) 7. Cliph (dave) 8. Re: entropicdata.com ? (Nate Lawson) 9. Re: Palladium, Memory Forensics, Clouds. (dave) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 May 2009 14:17:26 -0700 From: Nate Lawson Subject: Re: [Dailydave] entropicdata.com ? To: Dave Aitel Cc: dailydave at lists.immunitysec.com Message-ID: <4A171666.5010704 at root.org> Content-Type: text/plain; charset=ISO-8859-1 Dave Aitel wrote: > Lots of people are doing things in web services (AJAX, etc) that require > real crypto. So they implement RSA/twofish/etc in Javascript and run > that in the browser. But this requires a way to generate a key which > requires some entropy. There's no "feed of random numbers" that I know > of on the web that you can use to seed your crypto, probably because of > cross site restrictions. But it seems like either google gears, HTML5, > or one of the other new extensions should offer it as a built-in API. > > Likewise if they allowed you to get data from other sites (which the new > Firefox does sometimes?) then you could set up a web service for people > to use to get their entropic data from (over SSL of course :>). > > What else are people using for this? It seems to be a bit of a theme > here at SyScan (re: David Thiel's RIA presentation). Is there an API in > Silverlight/Flash/etc that lets you get entropy and then give it back to > the browser context? Hold on here. You're running Javascript RSA in your browser. Where did that Javascript come from? Right, you have to load it over SSL to be sure the Javascript is unmodified. But if you're already using SSL, any crypto you implement browser-side can only be less reviewed and more likely to explode, in addition to requiring SSL anyway. Loading your random data over HTTP is a bad idea too. DSA reveals your private key to an attacker if even a few bits of the random nonce are predictable: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ Please stop Web 2.0 from reimplementing crypto, badly. Help computer! -- Nate ------------------------------ Message: 2 Date: Sun, 24 May 2009 06:13:19 -0400 From: "James Butler" Subject: Re: [Dailydave] Palladium, Memory Forensics, Clouds. To: "'Dave Aitel'" , Message-ID: Content-Type: text/plain; charset="us-ascii" Dave Aitel wrote: _________________ The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does. With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer. ----------------- Dave, I know we spoke about this a few weeks ago, but I did not get a chance to state my disagreement with your opinion. You state that you can do a lot with memory forensics today to find trojan drivers (.sys), and you can. Last time I looked at CANVAS with MOSDEF you were hiding sockets using a TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. First, you are hooking IRPs which are easy to check. Secondly, you are hiding a port by filtering a query to tcpip.sys, but with memory forensics you cannot filter because nothing is queried. Now could MOSDEF be written in a way that more subtly disguised the hook? Certainly and perhaps you already have. Is it possible to create a port for communication without creating a port object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort increases tremendously. Deepdoor still used hooks to intercept packets. The hooks were just hidden deeper than anyone had looked. So yes it is an arms race to "counteract every tiny thing a rootkit writer does", but when doing detection I do not have to detect "every tiny thing" just some things. I will not argue with the fact there is no need to hide processes. Joanna, Greg, etc. have been saying that for years. However, a lot of intruders still use this technique for whatever reason. Let's use memory forensics and eliminate that problem forever. Can memory forensics find traces of CANVAS shellcode? Yes, but it is an extremely expensive operation in regard to time. Does it have false positives? Yes, but instead of looking at perhaps 100 memory sections across 100 processes memory forensics can narrow that down to four or five. Another thing that falls quickly to memory forensics is poor coding practices by the exploit writers. If a handle is left open by mistake or memory is not freed, it is quickly spotted. Peter Silberman has used this to reconstruct the command and control communications of another popular pentesting tool. Does this mean you cannot bypass this detection with proper developers? No. Don't forget though that freed does not necessarily mean gone. Using memory forensics common but stupid techniques malware author's use to prevent reinfecting a box are much easier to spot. For example, with memory forensics you can find all the mutexes a process has open. This might seem like a small thing, but memory forensics is giving us a view into what is happening on the host in ways we did not have before. Is the gradient against memory forensics? Perhaps, but it always is as your attacker evolves. I think now there is more of a gradient for the malware authors than there has been. They have been fighting the war on the disk for a long time. Now it is time they look up to memory as we sharpen our tools for the changing battlefield. Jamie Check here to play with memory forensic tools: http://mandiant.com/software/memoryze.htm to be used with http://www.mandiant.com/software/mav.htm http://www.openrce.org/articles/full_view/32 ------------------------------ Message: 3 Date: Sun, 24 May 2009 14:39:02 -0400 From: Alexander Sotirov Subject: [Dailydave] WOOT'09 To: dailydave at lists.immunitysec.com Message-ID: <20090524183902.GA4162 at MacBook.local> Content-Type: text/plain; charset="us-ascii" Hi, I want to remind everybody that WOOT'09 is still accepting submissions, but the CFP closes next week: http://www.usenix.org/event/woot09/cfp/ We encourage submissions of work that has been presented at BlackHat or other industry conferences but is well suited to a more formal and complete treatment in a academic peer-reviewed setting. I believe that both the academic and industry communities will benefit from this exchange of ideas. Alex -------------- 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/20090524/ba55050b/attachment-0001.pgp ------------------------------ Message: 4 Date: Mon, 25 May 2009 18:19:14 +0200 From: "Piotr Bania" Subject: [Dailydave] PAPER: Generic Unpacking of Self-modifying, Aggressive, Packed Binary Programs To: "dailydave" Message-ID: <23A8384A2B924CA4A0EE682F8C1C6C87 at DIED> Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original ABSTRACT Nowadays most of the malware applications are either packed or protected. This techniques are applied especially to evade signature based detectors and also to complicate the job of reverse engineers or security analysts. The time one must spend on unpacking or decrypting malware layers is often very long and in fact remains the most complicated task in the overall process of malware analysis. In this report author proposes MmmBop as a relatively new concept of using dynamic binary instrumentation techniques for unpacking and bypassing detection by self-modifying and highly aggressive packed binary code. MmmBop is able to deal with most of the known and unknown packing algorithms and it is also suitable to successfully bypass most of currently used anti-reversing tricks. [...] Paper can be found at: http://piotrbania.com/all/articles/pbania-dbi-unpacking2009.pdf best regards, pb -- -------------------------------------------------------------------- Piotr Bania - - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://www.piotrbania.com - Key ID: 0xBE43AC33 -------------------------------------------------------------------- - "The more I learn about men, the more I love dogs." ------------------------------ Message: 5 Date: Tue, 26 May 2009 22:57:40 -0400 From: Dave Aitel Subject: Re: [Dailydave] entropicdata.com ? To: Nate Lawson Cc: dailydave at lists.immunitysec.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Sure so one perspective is that anything cryptographic has to get done on the server. Which seems perfectly valid, but in some cases people don't want to do it that way. Maybe they want to sign something, without having to upload it to the server, say. Or maybe they just don't want to burden the server with tons of crypto. There's lots of good reasons to do crypto without reinventing SSL. And, of course, the cross domain stuff coming out makes this more likely, I assume. -dave > > Hold on here. You're running Javascript RSA in your browser. Where did > that Javascript come from? Right, you have to load it over SSL to be > sure the Javascript is unmodified. But if you're already using SSL, any > crypto you implement browser-side can only be less reviewed and more > likely to explode, in addition to requiring SSL anyway. > > Loading your random data over HTTP is a bad idea too. DSA reveals your > private key to an attacker if even a few bits of the random nonce are > predictable: > http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ > http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ > > Please stop Web 2.0 from reimplementing crypto, badly. Help computer! > > -- > Nate > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > ------------------------------ Message: 6 Date: Tue, 26 May 2009 18:02:03 +1000 From: Steve Micallef Subject: [Dailydave] IDA Plug-in writing tutorial (v1.1) To: "dailydave at lists.immunitysec.com" Message-ID: <4A1BA1FB.2000207 at binarypool.com> Content-Type: text/plain; charset=ISO-8859-1 Hi all, For those who might be interested, I've updated the IDA Plug-in Writing Tutorial to cover IDA Pro 5.4. The SDK was mostly frozen as of 4.9, although there have been some subtle changes. All in all there are about 10 new pages including some corrections, new functions and a new sample plug-in. Get it here: http://www.binarypool.com/idapluginwriting/ Feel free to drop me a note with any comments or corrections. Cheers, Steve Micallef ------------------------------ Message: 7 Date: Wed, 27 May 2009 11:47:55 -0400 From: dave Subject: [Dailydave] Cliph To: dailydave at lists.immunityinc.com Message-ID: <4A1D60AB.60703 at immunityinc.com> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those who are not aware, Cliph passed away in a plane accident recently. http://www.isec.pl/ has more information about the funeral. He was, among other things, a great hacker. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkodYKsACgkQtehAhL0gheoMkACeNekDqO1sDPLQiqAG/2c8kglv MPgAn1vG7ySg+fSoyLcEk04cGKqvWooK =qyjL -----END PGP SIGNATURE----- ------------------------------ Message: 8 Date: Wed, 27 May 2009 09:00:14 -0700 From: Nate Lawson Subject: Re: [Dailydave] entropicdata.com ? To: Dave Aitel Cc: dailydave at lists.immunitysec.com Message-ID: <4A1D638E.1020301 at root.org> Content-Type: text/plain; charset=ISO-8859-1 Dave Aitel wrote: > Sure so one perspective is that anything cryptographic has to get done > on the server. Which seems perfectly valid, but in some cases people > don't want to do it that way. > > Maybe they want to sign something, without having to upload it to the > server, say. Or maybe they just don't want to burden the server with > tons of crypto. There's lots of good reasons to do crypto without > reinventing SSL. Could you finish your example? They are signing something, which is verified by ... ? Any scenario I come up with to complete your example has problems. Where does the private key come from to sign it? How did the web browser get this key and code. Where does the recipient of this data get the cert to validate the signature? > And, of course, the cross domain stuff coming out makes this more > likely, I assume. I'm interested in your proposal here. How would Javascript signatures help? -Nate >> Hold on here. You're running Javascript RSA in your browser. Where did >> that Javascript come from? Right, you have to load it over SSL to be >> sure the Javascript is unmodified. But if you're already using SSL, any >> crypto you implement browser-side can only be less reviewed and more >> likely to explode, in addition to requiring SSL anyway. >> >> Loading your random data over HTTP is a bad idea too. DSA reveals your >> private key to an attacker if even a few bits of the random nonce are >> predictable: >> http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ >> http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ >> >> Please stop Web 2.0 from reimplementing crypto, badly. Help computer! >> >> -- >> Nate ------------------------------ Message: 9 Date: Wed, 27 May 2009 13:33:04 -0400 From: dave Subject: Re: [Dailydave] Palladium, Memory Forensics, Clouds. To: butlerjr at acm.org Cc: dailydave at lists.immunitysec.com Message-ID: <4A1D7950.7020807 at immunityinc.com> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Certainly the CANVAS kernel rootkit is not a covert one. I think it would be somewhat expensive to do basic adversarial testing in the kernel space on this, although I think it would be valuable research for the community. Is memory forensics "testable" against userspace? Memoryze can find hidden sockets and stuff, but I remember a paper from Peter on "finding shellcode" or something. Is that publicly available? Something Bill Arbaugh said is that one major advantage for memory forensics is that a machine has a lot less memory than it does disk space. Searching through disk space (or even storing it if you do enough forensics) is extremely expensive. To your credit you've released a lot of tools in the space people can use for testing the general concepts, which is a valuable thing for determining the overall level of effort curve of the technology itself. Hopefully soon I'll have some real world numbers here for you. :> Do the DD.exe and similar tools go underneath the memory handlers? I assume modern rootkits are memory handlers (or hypervisors). I'm not sure how acquisition really works against that. - -dave > Dave, > > I know we spoke about this a few weeks ago, but I did not get a chance to > state my disagreement with your opinion. You state that you can do a lot > with memory forensics today to find trojan drivers (.sys), and you can. Last > time I looked at CANVAS with MOSDEF you were hiding sockets using a > TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. > First, you are hooking IRPs which are easy to check. Secondly, you are > hiding a port by filtering a query to tcpip.sys, but with memory forensics > you cannot filter because nothing is queried. Now could MOSDEF be written in > a way that more subtly disguised the hook? Certainly and perhaps you already > have. > > Is it possible to create a port for communication without creating a port > object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort > increases tremendously. Deepdoor still used hooks to intercept packets. The > hooks were just hidden deeper than anyone had looked. So yes it is an arms > race to "counteract every tiny thing a rootkit writer does", but when doing > detection I do not have to detect "every tiny thing" just some things. > > I will not argue with the fact there is no need to hide processes. Joanna, > Greg, etc. have been saying that for years. However, a lot of intruders > still use this technique for whatever reason. Let's use memory forensics and > eliminate that problem forever. > > Can memory forensics find traces of CANVAS shellcode? Yes, but it is an > extremely expensive operation in regard to time. Does it have false > positives? Yes, but instead of looking at perhaps 100 memory sections across > 100 processes memory forensics can narrow that down to four or five. Another > thing that falls quickly to memory forensics is poor coding practices by the > exploit writers. If a handle is left open by mistake or memory is not freed, > it is quickly spotted. Peter Silberman has used this to reconstruct the > command and control communications of another popular pentesting tool. Does > this mean you cannot bypass this detection with proper developers? No. Don't > forget though that freed does not necessarily mean gone. > > Using memory forensics common but stupid techniques malware author's use to > prevent reinfecting a box are much easier to spot. For example, with memory > forensics you can find all the mutexes a process has open. This might seem > like a small thing, but memory forensics is giving us a view into what is > happening on the host in ways we did not have before. > > Is the gradient against memory forensics? Perhaps, but it always is as your > attacker evolves. I think now there is more of a gradient for the malware > authors than there has been. They have been fighting the war on the disk for > a long time. Now it is time they look up to memory as we sharpen our tools > for the changing battlefield. > > Jamie > > Check here to play with memory forensic tools: > http://mandiant.com/software/memoryze.htm to be used with > http://www.mandiant.com/software/mav.htm > http://www.openrce.org/articles/full_view/32 > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkodeVAACgkQtehAhL0ghep2pQCdHp3o+dwUrMvn9zDSLJEbsqeJ ey0AnjOkrGMGaT3aMEur8lI78bQKhO+t =lnhV -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave End of Dailydave Digest, Vol 46, Issue 8 **************************************** From dominique.brezinski at gmail.com Wed May 27 20:54:45 2009 From: dominique.brezinski at gmail.com (Dominique Brezinski) Date: Wed, 27 May 2009 17:54:45 -0700 Subject: [Dailydave] Palladium, Memory Forensics, Clouds. In-Reply-To: <4A1D7950.7020807@immunityinc.com> References: <4e1ef3e50905201729y761694cep3804d720cbbc0ab2@mail.gmail.com> <4A1D7950.7020807@immunityinc.com> Message-ID: <597760c90905271754i736abfdfq23d766b0eacbab22@mail.gmail.com> On Wed, May 27, 2009 at 10:33 AM, dave wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Something Bill Arbaugh said is that one major advantage for memory > forensics is that a machine has a lot less memory than it does disk > space. Searching through disk space (or even storing it if you do enough > forensics) is extremely expensive. Been making the same statement for a decade ;) In production environments with high down-time costs and generally huge amounts of disk, some form of memory capture and analysis is really the only viable option for incident response or other forensic activities. The problem of locating the proverbial needle in the haystack is really not an issue, because looking at it one way or another that needle actually looks like a telephone pole in an empty, flat field. The problem and solution are context. Dom From curtwilson618 at gmail.com Thu May 28 12:50:14 2009 From: curtwilson618 at gmail.com (Curt Wilson) Date: Thu, 28 May 2009 11:50:14 -0500 Subject: [Dailydave] New blog - review of Immunity's Heap Exploitation course Message-ID: <6b4a0b620905280950o4fe46b7cu525067e56eeb8124@mail.gmail.com> On my new blog, Perpetual Horizon, I've posted a review of the Immunity Heap Exploitation course I took recently. http://perpetualhorizon.blogspot.com/2009/05/immunitys-heap-overflow-course-review.html May your chunks never be blown but always massaged into favorable alignment. Curt Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090528/ad50f168/attachment.htm From jdemott at crucialsecurity.com Thu May 28 19:01:18 2009 From: jdemott at crucialsecurity.com (Jared DeMott) Date: Thu, 28 May 2009 19:01:18 -0400 Subject: [Dailydave] Whitepaper In-Reply-To: <49CBF0C6.20501@idefense.com> References: <49CBF0C6.20501@idefense.com> Message-ID: <4A1F17BE.2080403@crucialsecurity.com> Hi all, If you plan to take my "Application Security: For Hackers and Developers" at ShakaCon, BlackHat, ToorCon, and others; I finally got off my can and finished the prerequisite white paper. It can be found here: http://www.crucialsecurity.com/index.php?option=com_content&task=view&id=94&Itemid=136 Blessings, Jared