From ergosum at neurosecurity.com Mon Sep 1 18:05:13 2008 From: ergosum at neurosecurity.com (ergosum) Date: Tue, 2 Sep 2008 00:05:13 +0200 Subject: [Dailydave] The lack of hard questions In-Reply-To: References: <44283.1219874152@turing-police.cc.vt.edu> Message-ID: <200809020005.13629.ergosum@neurosecurity.com> On Thursday 28 August 2008 00:43:43 Charles Miller wrote: > But the problem is, if there are only a handful of people who can make > a reliable exploit for a particular vulnerability (or not) and none of > them work for MS, how can MS accurately determine whether an exploit > for a particular vulnerability will be somewhat reliable or totally > reliable (or not possible at all)? Doesn't anyone remember gobbles :) > Charles, no ofense, but the MS Security team has several members who can make reliable exploits, probably much better than many "security experts". So, don't take for granted that MS is full of crap because that shows your lack of knowledge about them. > On Aug 27, 2008, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: > > On Wed, 27 Aug 2008 09:05:42 EDT, Pusscat said: > >> My assumption would be that if it can be made reliable by anyone, > >> then it's > >> reliable. It probably shouldn't be a quantum value, collapsed by our > >> inability ;) > > > > Yes, it only has to be weaponized once. > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -- http://www.neurosecurity.com "We must be the change we wish to see in the world" Mahatma Gandhi From dan at geer.org Mon Sep 1 22:23:29 2008 From: dan at geer.org (dan at geer.org) Date: Mon, 01 Sep 2008 22:23:29 -0400 Subject: [Dailydave] The lack of hard questions In-Reply-To: Your message of "Wed, 27 Aug 2008 14:05:57 PDT." Message-ID: <20080902022329.7DA0F34191@absinthe.tinho.net> Mike Reavey writes: -+----------------- | Hey folks - we're here, watching this thread. Send us your | questions, either directly to msrcteam at microsoft.com or to the | list. We'll answer them here:blogs.technet.com/ecostrat in a | future post. One question I've always wanted to know is based on partial knowledge on my part. As I recall the story -- and this is subject to correction -- back when one CD's worth of Windows source was posted on the Internet new exploits began appearing in perhaps a fortnight. That was interesting inasmuch as it proved that amateurs could do it via source analysis and, which is more, this is about the time when MSFT began providing source to a number of governments as part of the monopoly defense -- including countries had (have) competent national laboratories, e.g., Russia. So my questions: what sort of vulns do you get back from foreign governments and, assuming that they don't share except with you, how often are what those governments discover previously unknown, how often are the vulns that are discovered discovered independently, and do you ever see exploits of vulns that have only been identified by governments (and do those exploits correlate with the nature of who is doing the discovering)? A white paper on your efforts to avoid being a vector of cyber warfare would serve, should one be handy. In respect, --dan From cmiller at securityevaluators.com Mon Sep 1 19:05:49 2008 From: cmiller at securityevaluators.com (Charles Miller) Date: Mon, 1 Sep 2008 18:05:49 -0500 Subject: [Dailydave] The lack of hard questions In-Reply-To: <200809020005.13629.ergosum@neurosecurity.com> References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> Message-ID: First off, I'm not a MS hater. I'm sure MS has security guys better than many security experts, no doubt better than myself. That is not the point. The point is, it only takes one or two of the best exploit developers to make a reliable exploit and it is very hard to predict what these guys can do. (and I stand by my statement that MS doesn't employ the BEST exploit developers - why would they?) It seems to me to be inherently unpredictable to predict how reliable a particular vulnerability is. For example, I'm sure MS was unaware that you could defeat ASLR and reliably exploit IE bugs until Alex and Mark told them. Charlie On Sep 1, 2008, at 5:05 PM, ergosum wrote: > On Thursday 28 August 2008 00:43:43 Charles Miller wrote: >> But the problem is, if there are only a handful of people who can >> make >> a reliable exploit for a particular vulnerability (or not) and none >> of >> them work for MS, how can MS accurately determine whether an exploit >> for a particular vulnerability will be somewhat reliable or totally >> reliable (or not possible at all)? Doesn't anyone remember >> gobbles :) >> > > Charles, no ofense, but the MS Security team has several members who > can make > reliable exploits, probably much better than many "security > experts". So, > don't take for granted that MS is full of crap because that shows > your lack > of knowledge about them. > From msuiche at gmail.com Tue Sep 2 03:05:39 2008 From: msuiche at gmail.com (Matthieu Suiche) Date: Tue, 2 Sep 2008 09:05:39 +0200 Subject: [Dailydave] The lack of hard questions In-Reply-To: <200809020005.13629.ergosum@neurosecurity.com> References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> Message-ID: <36615a170809020005g476bfbf8n989c530c44d86c18@mail.gmail.com> Ergosum is right. For instance, as you can see here, http://blogs.msdn.com/michael_howard/archive/2008/08/18/matt-miller-joins-the-security-science-team.aspx , MSFT recently hired Matt Miller/skape. And I'm sure they also have several unknow engineers who are very talented regarding security field. On Tue, Sep 2, 2008 at 12:05 AM, ergosum wrote: > On Thursday 28 August 2008 00:43:43 Charles Miller wrote: >> But the problem is, if there are only a handful of people who can make >> a reliable exploit for a particular vulnerability (or not) and none of >> them work for MS, how can MS accurately determine whether an exploit >> for a particular vulnerability will be somewhat reliable or totally >> reliable (or not possible at all)? Doesn't anyone remember gobbles :) >> > > Charles, no ofense, but the MS Security team has several members who can make > reliable exploits, probably much better than many "security experts". So, > don't take for granted that MS is full of crap because that shows your lack > of knowledge about them. > > > >> On Aug 27, 2008, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: >> > On Wed, 27 Aug 2008 09:05:42 EDT, Pusscat said: >> >> My assumption would be that if it can be made reliable by anyone, >> >> then it's >> >> reliable. It probably shouldn't be a quantum value, collapsed by our >> >> inability ;) >> > >> > Yes, it only has to be weaponized once. >> >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave > > > > -- > http://www.neurosecurity.com > > "We must be the change we wish to see in the world" > Mahatma Gandhi > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- Matthieu Suiche From cmiller at securityevaluators.com Tue Sep 2 11:46:49 2008 From: cmiller at securityevaluators.com (Charles Miller) Date: Tue, 2 Sep 2008 10:46:49 -0500 Subject: [Dailydave] The lack of hard questions In-Reply-To: <36615a170809020005g476bfbf8n989c530c44d86c18@mail.gmail.com> References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> <36615a170809020005g476bfbf8n989c530c44d86c18@mail.gmail.com> Message-ID: <49E7C3E5-31A9-4EF4-BB1F-3DBDA0D635A4@securityevaluators.com> I don't want to argue this to death, but I think everyone is missing my point. Okay, MS has lots of smart people and Matt Miller kicks ass. We all agree on this. However, I'm sure Matt is still occasionally surprised by something some other researcher does or is amazed when some guy no one has ever heard of from Argentina manages to exploit some bug no one thought was possible. All I'm saying is it is very hard to determine how reliably exploitable a particular vulnerability is. Although, maybe I'm the only one who finds it difficult... Also, I know the MS party at Blackhat was good, but this has gotta be the first time in history someone on a security list has been given so much grief about mentioning that MS might not have the absolute best security folks in the world :) Charlie On Sep 2, 2008, at 2:05 AM, Matthieu Suiche wrote: > Ergosum is right. For instance, as you can see here, > http://blogs.msdn.com/michael_howard/archive/2008/08/18/matt-miller-joins-the-security-science-team.aspx > , MSFT recently hired Matt Miller/skape. And I'm sure they also have > several unknow engineers who are very talented regarding security > field. From matt at use.net Tue Sep 2 16:41:23 2008 From: matt at use.net (Matt) Date: Tue, 2 Sep 2008 13:41:23 -0700 (PDT) Subject: [Dailydave] The lack of hard questions In-Reply-To: References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> Message-ID: On Mon, 1 Sep 2008, Charles Miller wrote: > First off, I'm not a MS hater. I'm sure MS has security guys better Hey Charles, It's interesting that you have to note this in the first place. I am noticing that people are pulling out the "anti-Microsoft" label a lot when they want to deflate the legitimacy of what someone is saying. It's getting really irritating. I don't know if this was a concerted effort planned by Microsoft to induce sympathy, or what. Last year, Luis and I actually had one of our students put in the comments that we were anti-Microsoft. The entire code for bugreport, that we use as a reference implementation, is written in C# for fuck's sake! Just because people aren't wearing out their knees (and jaws) continually worshipping at the shrine of Microsoft doesn't mean they're "against" everything that everyone working for Microsoft has accomplished. Quite the contrary, for me, anyways. It's when I see something good that's so close to being great and falling short for no reason, it's just that much more disappointing. Really looking forward to spherical Surface and holographic displays being purchasable soon, and a fully managed OS :) -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt From psy.echo at gmail.com Tue Sep 2 22:04:12 2008 From: psy.echo at gmail.com (Rishi Narang) Date: Wed, 3 Sep 2008 07:34:12 +0530 Subject: [Dailydave] Google Chrome Browser Flaw Message-ID: <243104685.20080903073412@gmail.com> Hi, Here is a flaw in just released Google Chrome Browser (Beta). This not a really a "Jail-Break" remote execution type of serious vulnerability (till now, it doesn't seem one) but surely crashes the application (all tabs) and needs a browser restart. But, as a whole the browser surely is very neat and fast! Google with its own simplicity and creativity, has taken integrated features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch their bugs too, as the old Carpet Bombing Attack and other speculations going in wild! --------------------------------------------------- Software: Google Chrome Browser 0.2.149.27 Tested: Windows XP Professional SP3 Result: Google Chrome Crashes with All Tabs Problem: An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a 'special' character, the chrome crashes with a Google Chrome message window "Whoa! Google Chrome has crashed. Restart now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), followed by "POP EBP" instruction when pointed out by the EIP register at 0x01002FF4. Proof of Concept: http://evilfingers.com/advisory/google_chrome_poc.php Credit: Rishi Narang www.greyhat.in www.evilfingers.com --------------------------------------------------- -- Thanks & Regards, Rishi Narang | Security Researcher Founder, GREYHAT Insight Key: 0x8D67A3A3 (www.greyhat.in/key.asc) www.greyhat.in ... eschew obfuscation, espouse elucidation. From isaac.dawson at gmail.com Wed Sep 3 08:46:01 2008 From: isaac.dawson at gmail.com (Isaac Dawson) Date: Wed, 3 Sep 2008 21:46:01 +0900 Subject: [Dailydave] Google Chrome Browser Flaw In-Reply-To: <243104685.20080903073412@gmail.com> References: <243104685.20080903073412@gmail.com> Message-ID: <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> Just remember, According the EULA you 'clicked', google now owns any vulnerability you find! http://tapthehive.com/discuss/This_Post_Not_Made_In_Chrome_Google_s_EULA_Sucks -isaac On Wed, Sep 3, 2008 at 11:04 AM, Rishi Narang wrote: > Hi, > > Here is a flaw in just released Google Chrome Browser (Beta). This not a really a "Jail-Break" remote execution type of serious vulnerability (till now, it doesn't seem one) but surely crashes the application (all tabs) and needs a browser restart. But, as a whole the browser surely is very neat and fast! > > Google with its own simplicity and creativity, has taken integrated features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch their bugs too, as the old Carpet Bombing Attack and other speculations going in wild! > > --------------------------------------------------- > Software: > Google Chrome Browser 0.2.149.27 > > Tested: > Windows XP Professional SP3 > > Result: > Google Chrome Crashes with All Tabs > > Problem: > An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a 'special' character, the chrome crashes with a Google Chrome message window "Whoa! Google Chrome has crashed. Restart now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), followed by "POP EBP" instruction when pointed out by the EIP register at 0x01002FF4. > > Proof of Concept: > http://evilfingers.com/advisory/google_chrome_poc.php > > Credit: > Rishi Narang > www.greyhat.in > www.evilfingers.com > --------------------------------------------------- > > -- > Thanks & Regards, > Rishi Narang | Security Researcher > Founder, GREYHAT Insight > Key: 0x8D67A3A3 (www.greyhat.in/key.asc) > www.greyhat.in > > ... eschew obfuscation, espouse elucidation. > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From trygve at pogostick.net Tue Sep 2 06:13:20 2008 From: trygve at pogostick.net (Trygve Aasheim) Date: Tue, 02 Sep 2008 12:13:20 +0200 Subject: [Dailydave] The lack of hard questions In-Reply-To: <200809020005.13629.ergosum@neurosecurity.com> References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> Message-ID: <48BD11C0.2050906@pogostick.net> Why sometimes "Security Experts" and not the vendor should say if it is a vulnerability or a bug, and if its reliable (read entire timeline): http://www.coresecurity.com/content/open-bsd-advisorie The vendor might have other interests, and most major vendors run all their communication through their marketing department (which usually ARE full of crap)...and that doesn't help. Even if they're packed with people who can make "reliable exploits"... And many times the "Security Team" is overbooked (by the marketing department to do presentations on seminars or create security whitepaper strategies)... Microsoft might be different of course...but maybe not in the future, since they've now proved that security doesn't really sell: http://pwnie-awards.org/2008/nominees.html#fail ergosum wrote: > > Charles, no ofense, but the MS Security team has several members who can make > reliable exploits, probably much better than many "security experts". So, > don't take for granted that MS is full of crap because that shows your lack > of knowledge about them. > > > >> On Aug 27, 2008, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: >>> On Wed, 27 Aug 2008 09:05:42 EDT, Pusscat said: >>>> My assumption would be that if it can be made reliable by anyone, >>>> then it's >>>> reliable. It probably shouldn't be a quantum value, collapsed by our >>>> inability ;) >>> Yes, it only has to be weaponized once. >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave > > > From pusscat at metasploit.com Wed Sep 3 10:44:27 2008 From: pusscat at metasploit.com (Pusscat) Date: Wed, 3 Sep 2008 10:44:27 -0400 Subject: [Dailydave] The lack of hard questions In-Reply-To: References: <44283.1219874152@turing-police.cc.vt.edu> <200809020005.13629.ergosum@neurosecurity.com> Message-ID: <01f601c90dd3$934c6e10$b9e54a30$@com> Bringing this back around to the main question, apart from the idea that it's difficult to say with certainty that an vuln is not exploitable, Microsoft is really asking how likely are we to see a reliable exploit in the wild. I think this is a much easier question to answer, because there are other important limiting factors in the decision to even work on an exploit, such as: - Deployment width of the vulnerable service - Likelihood of exposure - Effort / gain ratio of exploit dev - Something /else/ better being released in the same patch package (is there something else tastier and easier? Might as well attack that if the two vulns are in the same patch set) So often one can look at a bug and say, this is difficult, it might not be reliable, not everyone will have this turned on, and hey look, they killbitted an active X control that's easy in the same KB number. Screw it. I'll write the AX exploit instead and get better ROI. This is why I don't think that in most cases these estimations will be far off, especially considering the crowd that'll be looking the possibilities over. The real questions only occur when they release a kernel bug just after a holiday that effects everyone, and no one is sure if it's possible to gain execution, but it sure looks delicious ;) ~ Lurene -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Matt Sent: Tuesday, September 02, 2008 4:41 PM To: Charles Miller Cc: dailydave at lists.immunitysec.com Subject: Re: [Dailydave] The lack of hard questions On Mon, 1 Sep 2008, Charles Miller wrote: > First off, I'm not a MS hater. I'm sure MS has security guys better Hey Charles, It's interesting that you have to note this in the first place. I am noticing that people are pulling out the "anti-Microsoft" label a lot when they want to deflate the legitimacy of what someone is saying. It's getting really irritating. I don't know if this was a concerted effort planned by Microsoft to induce sympathy, or what. Last year, Luis and I actually had one of our students put in the comments that we were anti-Microsoft. The entire code for bugreport, that we use as a reference implementation, is written in C# for fuck's sake! Just because people aren't wearing out their knees (and jaws) continually worshipping at the shrine of Microsoft doesn't mean they're "against" everything that everyone working for Microsoft has accomplished. Quite the contrary, for me, anyways. It's when I see something good that's so close to being great and falling short for no reason, it's just that much more disappointing. Really looking forward to spherical Surface and holographic displays being purchasable soon, and a fully managed OS :) -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From sub at room641a.net Wed Sep 3 12:17:22 2008 From: sub at room641a.net (sub) Date: Wed, 3 Sep 2008 09:17:22 -0700 Subject: [Dailydave] Google Chrome Browser Flaw In-Reply-To: <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> References: <243104685.20080903073412@gmail.com> <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> Message-ID: <8805f1180809030917t5e0cb122p60fcf4d221e7600f@mail.gmail.com> For those of you not wanting to subject yourself to Google's EULA, which applies to the binary release only, you can compile "Chromium" from source which is licensed under a "BSD-style" license and does not have any additional license agreements that I am aware of. http://dev.chromium.org/Home On Wed, Sep 3, 2008 at 5:46 AM, Isaac Dawson wrote: > Just remember, > According the EULA you 'clicked', google now owns any vulnerability you find! > http://tapthehive.com/discuss/This_Post_Not_Made_In_Chrome_Google_s_EULA_Sucks > -isaac > > On Wed, Sep 3, 2008 at 11:04 AM, Rishi Narang wrote: >> Hi, >> >> Here is a flaw in just released Google Chrome Browser (Beta). This not a really a "Jail-Break" remote execution type of serious vulnerability (till now, it doesn't seem one) but surely crashes the application (all tabs) and needs a browser restart. But, as a whole the browser surely is very neat and fast! >> >> Google with its own simplicity and creativity, has taken integrated features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch their bugs too, as the old Carpet Bombing Attack and other speculations going in wild! >> >> --------------------------------------------------- >> Software: >> Google Chrome Browser 0.2.149.27 >> >> Tested: >> Windows XP Professional SP3 >> >> Result: >> Google Chrome Crashes with All Tabs >> >> Problem: >> An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a 'special' character, the chrome crashes with a Google Chrome message window "Whoa! Google Chrome has crashed. Restart now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), followed by "POP EBP" instruction when pointed out by the EIP register at 0x01002FF4. >> >> Proof of Concept: >> http://evilfingers.com/advisory/google_chrome_poc.php >> >> Credit: >> Rishi Narang >> www.greyhat.in >> www.evilfingers.com >> --------------------------------------------------- >> >> -- >> Thanks & Regards, >> Rishi Narang | Security Researcher >> Founder, GREYHAT Insight >> Key: 0x8D67A3A3 (www.greyhat.in/key.asc) >> www.greyhat.in >> >> ... eschew obfuscation, espouse elucidation. >> >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From rhyskidd at gmail.com Wed Sep 3 11:16:24 2008 From: rhyskidd at gmail.com (Rhys Kidd) Date: Wed, 3 Sep 2008 23:16:24 +0800 Subject: [Dailydave] Google Chrome Browser Flaw In-Reply-To: <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> References: <243104685.20080903073412@gmail.com> <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> Message-ID: <68dd869f0809030816n44da66b4k7acef88e22067b7@mail.gmail.com> Ah, no. Google doesn't "own" the intellectual property in relation to the alleged vulnerability on the mere basis that Rishi's previous email was sent from a GMail account, and thus you assume from a Chrome browser - correct me if this isn't your proposition. Acceptance of Google's Chrome EULA means you assign a *license* to Google to "*reproduce, adapt, modify, translate, publish, publicly perform, blah blah blah*" your content. Licensing != transfer of ownership in common law jurisdictions. Yes, I agree the EULA seems a bit over the top, but after a few more re-reads appears to be a non-technically aware lawyer's attempt to cover their bases on doing things like gzip/deflate HTTP encoding.. "*11.3 You understand that Google, in performing the required technical steps to provide the Services to our users, may ... make such changes to your Content as are necessary to conform and adapt that Content to the technical requirements of connecting networks, devices, services or media*" Rhys 2008/9/3 Isaac Dawson > Just remember, > According the EULA you 'clicked', google now owns any vulnerability you > find! > > http://tapthehive.com/discuss/This_Post_Not_Made_In_Chrome_Google_s_EULA_Sucks > -isaac > > On Wed, Sep 3, 2008 at 11:04 AM, Rishi Narang wrote: > > Hi, > > > > Here is a flaw in just released Google Chrome Browser (Beta). This not a > really a "Jail-Break" remote execution type of serious vulnerability (till > now, it doesn't seem one) but surely crashes the application (all tabs) and > needs a browser restart. But, as a whole the browser surely is very neat and > fast! > > > > Google with its own simplicity and creativity, has taken integrated > features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch > their bugs too, as the old Carpet Bombing Attack and other speculations > going in wild! > > > > --------------------------------------------------- > > Software: > > Google Chrome Browser 0.2.149.27 > > > > Tested: > > Windows XP Professional SP3 > > > > Result: > > Google Chrome Crashes with All Tabs > > > > Problem: > > An issue exists in how chrome behaves with undefined-handlers in > chrome.dll version 0.2.149.27. A crash can result without user > interaction. When a user is made to visit a malicious link, which has an > undefined handler followed by a 'special' character, the chrome crashes with > a Google Chrome message window "Whoa! Google Chrome has crashed. Restart > now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), > followed by "POP EBP" instruction when pointed out by the EIP register at > 0x01002FF4. > > > > Proof of Concept: > > http://evilfingers.com/advisory/google_chrome_poc.php > > > > Credit: > > Rishi Narang > > www.greyhat.in > > www.evilfingers.com > > --------------------------------------------------- > > > > -- > > Thanks & Regards, > > Rishi Narang | Security Researcher > > Founder, GREYHAT Insight > > Key: 0x8D67A3A3 (www.greyhat.in/key.asc) > > www.greyhat.in > > > > ... eschew obfuscation, espouse elucidation. > > > > _______________________________________________ > > 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/20080903/1e18cf02/attachment.htm From msuiche at gmail.com Wed Sep 3 13:01:01 2008 From: msuiche at gmail.com (Matthieu Suiche) Date: Wed, 3 Sep 2008 19:01:01 +0200 Subject: [Dailydave] Google Chrome Browser Flaw In-Reply-To: <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> References: <243104685.20080903073412@gmail.com> <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> Message-ID: <36615a170809031001p21860047t7db6ba139f72cd1a@mail.gmail.com> This is not a vulnerability. This is only a bug located inside chrome.dll because of Microsoft Visual Studio C-Run-Time Libraries. (As you can see Google is able to make a faster browser than IE8 by using Microsoft products :-)) The breakpoint is executed by _invalid_parameter() (from _invalid_parameter_noinfo()) function (Defined in crt/src/invarg.c) _invalid_parameter() function is called when an invalid argument is passed into a CRT function. If you try to read "toto:%" it won't successfuly identify the target, then it will try to find a correct target as a each well know different protocol (ftp, https, ...) through memcpy_s() (see http://msdn.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx) function each time. The problem looks to come from \\autocomplete\\autocomplete.cc file. This give us interesting interesting information like, Google is using Visual Studio >= 8.0 and should respect Microsoft security guidelines while developping Google Chrome. Let's see if these "new" guidelines will help to provide a safer browser... On Wed, Sep 3, 2008 at 2:46 PM, Isaac Dawson wrote: > Just remember, > According the EULA you 'clicked', google now owns any vulnerability you find! > http://tapthehive.com/discuss/This_Post_Not_Made_In_Chrome_Google_s_EULA_Sucks > -isaac > > On Wed, Sep 3, 2008 at 11:04 AM, Rishi Narang wrote: >> Hi, >> >> Here is a flaw in just released Google Chrome Browser (Beta). This not a really a "Jail-Break" remote execution type of serious vulnerability (till now, it doesn't seem one) but surely crashes the application (all tabs) and needs a browser restart. But, as a whole the browser surely is very neat and fast! >> >> Google with its own simplicity and creativity, has taken integrated features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch their bugs too, as the old Carpet Bombing Attack and other speculations going in wild! >> >> --------------------------------------------------- >> Software: >> Google Chrome Browser 0.2.149.27 >> >> Tested: >> Windows XP Professional SP3 >> >> Result: >> Google Chrome Crashes with All Tabs >> >> Problem: >> An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a 'special' character, the chrome crashes with a Google Chrome message window "Whoa! Google Chrome has crashed. Restart now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), followed by "POP EBP" instruction when pointed out by the EIP register at 0x01002FF4. >> >> Proof of Concept: >> http://evilfingers.com/advisory/google_chrome_poc.php >> >> Credit: >> Rishi Narang >> www.greyhat.in >> www.evilfingers.com >> --------------------------------------------------- >> >> -- >> Thanks & Regards, >> Rishi Narang | Security Researcher >> Founder, GREYHAT Insight >> Key: 0x8D67A3A3 (www.greyhat.in/key.asc) >> www.greyhat.in >> >> ... eschew obfuscation, espouse elucidation. >> >> _______________________________________________ >> 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 > -- Matthieu Suiche From psy.echo at gmail.com Wed Sep 3 15:39:17 2008 From: psy.echo at gmail.com (Rishi Narang) Date: Thu, 4 Sep 2008 01:09:17 +0530 Subject: [Dailydave] Google Chrome Browser Flaw In-Reply-To: <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> References: <243104685.20080903073412@gmail.com> <5ff6321e0809030546o53c7323s74b9c76152fe5ee1@mail.gmail.com> Message-ID: <616417460.20080904010917@gmail.com> Hi, "Time" can definitely plays a major role. There was a collision that occurred due to the fact that I took time to find the real break point in the code, search for a template and to publish at EvilFingers site before sending it to Google and other bugtraqs. Even though I had the vulnerability 4 hrs well before the real publication of the bug and had the exploit along with the some crash details like "int 3" Kernel Exception/Trap @ 0x01002FF3, different attack cases, exceptions of http/ftp and further debug logs; there was this bug published (though without the details of possible cases, exceptions and mouse hover techniques) couple of hours before I released it out at EvilFingers. So, I would like to convey due credit to Mr. JanDeMooij as well for his posting the bug on http://code.google.com/p/chromium/issues/detail?id=122, and thanks to Mr. Brennan for contacting me about the same. -- Thanks & Regards, Rishi Narang | Security Researcher Founder, GREYHAT Insight Key: 0x8D67A3A3 (www.greyhat.in/key.asc) www.greyhat.in ... eschew obfuscation, espouse elucidation. Wednesday, September 3, 2008, 6:16:01 PM, you wrote: > On Wed, Sep 3, 2008 at 11:04 AM, Rishi Narang wrote: >> Hi, >> Here is a flaw in just released Google Chrome Browser (Beta). This not a really a "Jail-Break" remote execution type of serious vulnerability (till now, it doesn't seem one) but surely crashes the application (all tabs) and needs a browser restart. But, as a whole the browser surely is very neat and fast! >> Google with its own simplicity and creativity, has taken integrated features of top browsers - Firefox, IE, Safari etc. Hope, it didn't catch their bugs too, as the old Carpet Bombing Attack and other speculations going in wild! >> --------------------------------------------------- >> Software: >> Google Chrome Browser 0.2.149.27 >> Tested: >> Windows XP Professional SP3 >> Result: >> Google Chrome Crashes with All Tabs >> Problem: >> An issue exists in how chrome behaves with undefined-handlers in chrome.dll version 0.2.149.27. A crash can result without user interaction. When a user is made to visit a malicious link, which has an undefined handler followed by a 'special' character, the chrome crashes with a Google Chrome message window "Whoa! Google Chrome has crashed. Restart now?". It crashes on "int 3" at 0x01002FF3 as an exception/trap (kernel), followed by "POP EBP" instruction when pointed out by the EIP register at 0x01002FF4. >> Proof of Concept: >> http://evilfingers.com/advisory/google_chrome_poc.php >> Credit: >> Rishi Narang >> www.greyhat.in >> www.evilfingers.com >> --------------------------------------------------- From bas.alberts at immunityinc.com Wed Sep 3 16:32:54 2008 From: bas.alberts at immunityinc.com (Bas Alberts) Date: Wed, 03 Sep 2008 16:32:54 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released Message-ID: <48BEF476.6040103@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Immunity is releasing the DR Linux 2.6 IA32 rootkit under the GPLv2. It is supported by CANVAS (and is thus commercially supported for your penetration-testing needs) but is suitable for standalone use. Currently the rootkit can: o Hide processes o Hide network sockets o Hide files o Get a remote MOSDEF Node (via hidden userland-backdoor) The major benefit of the DR rootkit is that all this happens transparently to the end user. The children of a hidden process are also automatically hidden. The sockets a hidden process creates are also hidden. But if you are a hidden process, you can see hidden resources. This makes the DR rootkit nicely manageable. DR loads via insmod - we've tested the rootkit on a number of Linux distributions including CentOS and Ubuntu. The CANVAS support and backdoor logic were written by Daniel Palacio during his Immunity summer internship. He provided both the kernel hooks and the userland backdoor to the project. The rootkit engine (DR.c) was written by Bas Alberts and consists of a debug register based hooking engine that does not modify the IDT or syscall table at all. It was written as a reference implementation for people wanting to experiment with such a rootkit technology, and was designed to be able to integrate easily into existing syscall hook based rootkits. It has known limitations and considerations which you can read about in the attached README. You can find the source to the DR rootkit at: URL: http://www.immunityinc.com/downloads/linux_rootkit_source.tbz2 MD5SUM: 1256523fa8a87949c5e588c981108ee8 Any questions or ideas for this project can be sent to DD or your friendly neighborhood CANVAS support address! (support at immunityinc.com) Thanks, Team Immunity Debug Register Rootkit 0.1 - reference implementation ===================================================== About ===== DR features a reference implementation of a IA32 debug register based rootkit hooking engine. It does not modify IDT or syscall_table at all but still provides transparent syscall hooking on IA32 Linux 2.6. Features ======== SystemCall hooking without modifying IDT, or syscall_table, at all. Not even for a milisecond(tm). Using hardware execute and read breakpoints. Details ======= DR places a hardware breakpoint on the syscall handler, and the resulting trap places a memory watch on the syscall_table entry for the __NR_syscall of the intercepted syscall. It does this for both INT 0x80 and sysenter based system calls. When the memory watch for the syscall_table entry kicks in, the trap handler then redirects execution for that syscall to a syscall hook. Example Flow ============ Execute global breakpoint on syscall handler in dr0, syscall is called, breakpoint kicks in. Modified do_debug handler places global read watch on syscall_table[__NR_syscall]. When syscall is called, memory access breakpoint kicks in. Modified do_debug handler places function pointer to hooked syscall in task regs eip. Execution is redirected to hooked syscall. Repeat. [ 864.447800] ******* LOADING IA32 DR HOOKING ENGINE ******* [ 864.447868] *** loader: handler for INT 128: C0104210 [ 864.447923] *** loader: syscall_table: C02FC540 [ 864.447934] *** loader: syscall_call call *table(,eax,4): C010424B [ 864.447952] *** loader: handler for INT 1: C02F4360 [ 864.448085] *** loader: INT 1 handler patched to use __my_do_debug [ 864.448165] *** loader: initialized hook_table [ 864.448199] *** loader: systenter_entry call *table(,eax,4): C01041CB [ 871.592214] *** dr0/dr1 trap: setting read watch on syscall_NR of 220 at C02FC8B0 [ 871.598191] *** got dr2 trap (syscall_table watch) [ 871.598723] *** hooked __NR_220 to E0AC7350 Using the memory watch approach, one does not have to modify IDT or syscall_table ever. This is an original approach, but considering we _are_ the debugger .. one could dream up a million other viable and fruitful solutions to non-memory modifying DR rootkits. Limitations =========== This is a reference implementation. A lot more can be done to actually be hidden. Production code will include kmalloc based non-LKM code handling. Full Global Detect debug register access detection support, and additional memory watching for the debug ENTRY call offset patch. Additional testing is required to check for scheduler issues and other racy problems. This reference implementation is intended as a case study into the general rootkit approach now that the cat is out of the bag. The provided example hooks serve as a basic example rootkit known to suffer the following limitations: Detection ========= In it's current form there is no prevention of someone else accessing the debug registers. This could be easily added with GD access flag control, however this is left as an exercise to the reader. Furthermore this module behaves like a normal LKM in that is has symbols and is resident in memory like a normal LKM. This can be bypassed by porting the module init to a kmalloc based loading logic. To be added in v0.2. - - Detection via module based symbols - - Detection via granted access to hardware debug registers - - Detection via timing logic - - Detection via open("/proc/hiddenpid/stat"); success Adding/Changing hooks ===================== All hooks are defined in hooktable.h. A good example template is the hook_example_exit function. Once a hook is added to the global hook table, it will be automagically used by the hooking engine. 10 asmlinkage static void hook_example_exit(int status); ... 149 asmlinkage /* required: args passed on stack to syscall */ 150 static void hook_example_exit(int status) 151 { 152 /* standard hook prologue */ 153 asmlinkage int (*orig_exit)(int status); 154 void **sys_p = (void **)sys_table_global; 155 orig_exit = (int (*)())sys_p[__NR_exit]; ... 167 else 168 return orig_exit(status); 169 } You then initialize this function in the global hook_table as such: 121 hook_table[__NR_exit] = (void *)hook_example_exit; The hooking engine was designed to be very friendly and open to modification/extension. It was designed to provide a more current hooking engine for existing sycall_table based rootkit logic. All rootkit specific logic lives in hooktable.h. Todo ==== - - move to kmalloc based init loader, -EINVAL return - - improve hooks to do proper '/proc' and getdents handling - - move /proc handling to inode based checks - - instruction emulation for outside debug register access GD stylee Credits ======= The debug register based hooking engine was written by Bas Alberts, all additional hooks contained in hooktable.h, besides the example hook_exit were written by Daniel Palacio. References ========== 1) The IA32 Software Developers Manual Vol. 3B, Chapter 18 2) Mistifying the debugger, Phrack 65-8, halfdead License ======= GPLv2 Contact ======= bas.alberts at immunityinc.com / support at immunityinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvvR2LpdA2Ju9tfcRAvVmAJ41wqdf6AFpI1RDEjkf+gA3v9Zd5gCgg3C5 cV6vD5lSvq1hjX64ElgjVSE= =82MQ -----END PGP SIGNATURE----- From darkangel at antifork.org Thu Sep 4 07:39:51 2008 From: darkangel at antifork.org (Pierre Falda) Date: Thu, 4 Sep 2008 13:39:51 +0200 Subject: [Dailydave] DR Linux 2.6 rootkit released Message-ID: Hi people, if someone else is still interested in these things and wants to see an 'old' code, in 2006 i have published an article and a 2.4.x/2.6.x (tested until .19) linux rootkit which loads itself through kmem and fully implements these techniques. It's a full working rootkit with a debug registers engine and with anti detection checks via GD and CPU emulation to protect itself too. It has all modern rootkits hiding features, anti detection extra features like kmem/mem/kcore/procfs on the fly patching and most add-ons like TTY and applications sniffing. It works watching SCT and supports syscall invocations through int 80 and sysenter and so on. You can find the source code here: http://packetstormsecurity.org/UNIX/penetration/rootkits/mood-nt_2.3.tgz or here http://darkangel.antifork.org/codes.htm The article about the hardware engine (in Italian) is here http://darkangel.antifork.org/publications/Abuso%20dell%27Hardware%20nell%27Attacco%20al%20Kernel%20di%20Linux.pdf and if you want the printed version in a scientific publication you can go here: http://www.atsystem.org/en/conventions/nss06/convention+proceedings Have a nice day! Pierre Falda 'darkangel' http://darkangel.antifork.org Antifork Research Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080904/4cba4613/attachment.htm From bas.alberts at immunityinc.com Thu Sep 4 09:29:27 2008 From: bas.alberts at immunityinc.com (Bas Alberts) Date: Thu, 04 Sep 2008 09:29:27 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: References: <48BEF476.6040103@immunityinc.com> Message-ID: <48BFE2B7.50306@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hrmm .. didn't read moodNT .. mostly it's just a straight translation of the IA software developers manual. MoodNT would have been referenced otherwise. Read DR.c for the gritty details. It was written to be a porting platform for existing syscall hooks. Very simple stuff. In any event, I only wrote the debug register bit (DR.c) .. I think the actual hooks and 'rootkit' functionality could be improved (read my comments in source). Feel free to do so. For me the goal was just to give a simple and clean hooking mechanism based on dr logic, that people could plug into existing 'oldschool' rootkits. Cheers, Bas ninjaboy wrote: > 2008/9/3 Bas Alberts : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> All, >> >> Immunity is releasing the DR Linux 2.6 IA32 rootkit under the GPLv2. It >> is supported by CANVAS (and is thus commercially supported for your >> penetration-testing needs) but is suitable for standalone use. >> >> Currently the rootkit can: >> >> o Hide processes >> o Hide network sockets >> o Hide files >> o Get a remote MOSDEF Node (via hidden userland-backdoor) >> > > good fork of mood-nt. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv+K3LpdA2Ju9tfcRAhemAJ9WAydPGDcSfCUsza/pcTDQQ8MflACgglU2 zop+jBkdmjCjzzUfggUzyHk= =BObD -----END PGP SIGNATURE----- From bas.alberts at immunityinc.com Thu Sep 4 12:59:21 2008 From: bas.alberts at immunityinc.com (Bas Alberts) Date: Thu, 04 Sep 2008 12:59:21 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: References: Message-ID: <48C013E9.4090400@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just as a sidenote, I was unaware of Pierre's research paper until today (not much up on the Italians :)). But his paper most definitely is a goto reference for this general hooking approach. Even if it is in Italian, it's pretty readable and well researched. Combined with the Intel SDM the work presented becomes pretty straightforward. I've added it to the references in the DR README, and feel that it serves as an excellent reference for the general approach as far as Linux debug register based kernel hooking specifics go. To answer some questions I've been getting off-list: - - Yes, SMP support will be added - - Yes, X86_64 support will be added - - Yes, Proper GD support will be added The initial implementation was written on the spot and in the span of a week. Because the engine is used in the CANVAS rootkit it will receive continuous support and updates. Feel free to submit feature requests. Regards, Bas Alberts Senior Security Researcher Immunity, Inc. Pierre Falda wrote: > Hi people, > if someone else is still interested in these things and wants to see an > 'old' code, in 2006 i have published an article and a 2.4.x/2.6.x (tested > until .19) linux rootkit > which loads itself through kmem and fully implements these techniques. It's > a full working rootkit with a debug registers engine and with > anti detection checks via GD and CPU emulation to protect itself too. It has > all modern rootkits hiding features, anti detection extra features > like kmem/mem/kcore/procfs on the fly patching and most add-ons like TTY and > applications sniffing. It works watching SCT and supports > syscall invocations through int 80 and sysenter and so on. > > You can find the source code here: > > http://packetstormsecurity.org/UNIX/penetration/rootkits/mood-nt_2.3.tgz > > or here > > http://darkangel.antifork.org/codes.htm > > The article about the hardware engine (in Italian) is here > > http://darkangel.antifork.org/publications/Abuso%20dell%27Hardware%20nell%27Attacco%20al%20Kernel%20di%20Linux.pdf > > and if you want the printed version in a scientific publication you can go > here: > > http://www.atsystem.org/en/conventions/nss06/convention+proceedings > > Have a nice day! > > > Pierre Falda 'darkangel' > http://darkangel.antifork.org > Antifork Research Inc. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwBPpLpdA2Ju9tfcRAnR6AJ9UHQPhTG5U8hIqQIiZCzf5cUbIMACeK73N FJ3eafqT3KebzG4ADuJF6aw= =LA18 -----END PGP SIGNATURE----- From bas.alberts at immunityinc.com Thu Sep 4 15:58:37 2008 From: bas.alberts at immunityinc.com (Bas Alberts) Date: Thu, 04 Sep 2008 15:58:37 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released Message-ID: <48C03DED.3050601@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For people wishing to track this project. You can get the latest version at http://www.immunityinc.com/resources-freesoftware.shtml. I just added SMP support to the hooking engine. You can request other features and file bug reports directly to support at immunityinc.com. I'll stop spamming the list with DR stuff now, so just check the website for updates if you're interested. Cheers, Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwD3tLpdA2Ju9tfcRAhmIAJ9c7H/nFuQZqPe1cv4fl3HhVAHEhACgtc7l JBtGbdJIXD9ccAboKwNvZm8= =yuE/ -----END PGP SIGNATURE----- From mhtajik at gmail.com Thu Sep 4 17:15:33 2008 From: mhtajik at gmail.com (Mohammad Hosein) Date: Fri, 5 Sep 2008 01:45:33 +0430 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: <48C03DED.3050601@immunityinc.com> References: <48C03DED.3050601@immunityinc.com> Message-ID: <26f61db50809041415u589b1b23n787c737021bf2504@mail.gmail.com> i'm probably 2-3 days far from examining this myself , but if anyone out there have ideas on how this whole debug register hooks and stuff would react on "hardened" kind of kernels ( like the one gentoo offers ) let us know the details On Fri, Sep 5, 2008 at 12:28 AM, Bas Alberts wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > For people wishing to track this project. You can get the latest version > at http://www.immunityinc.com/resources-freesoftware.shtml. I just added > SMP support to the hooking engine. You can request other features and > file bug reports directly to support at immunityinc.com. > > I'll stop spamming the list with DR stuff now, so just check the website > for updates if you're interested. > > Cheers, > Bas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIwD3tLpdA2Ju9tfcRAhmIAJ9c7H/nFuQZqPe1cv4fl3HhVAHEhACgtc7l > JBtGbdJIXD9ccAboKwNvZm8= > =yuE/ > -----END PGP SIGNATURE----- > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080905/b94dbb35/attachment-0001.htm From joanna at invisiblethings.org Thu Sep 4 17:44:27 2008 From: joanna at invisiblethings.org (Joanna Rutkowska) Date: Thu, 04 Sep 2008 23:44:27 +0200 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: <48BEF476.6040103@immunityinc.com> References: <48BEF476.6040103@immunityinc.com> Message-ID: <48C056BB.3010000@invisiblethings.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [resending from my DD-known address] Bas Alberts wrote: > > The rootkit engine (DR.c) was written by Bas Alberts and consists of a > debug register based hooking engine that does not modify the IDT or > syscall table at all. Sorry for being lazy and not looking into your source code, but one of the 2 most important question one should ask is: what do you hook to handle #DB in your code? Choices are: 1) IDT 2) Linux IDT handler (or some other Linux *code* modification) 3) some function pointer that is used by Linux kernel during #DB handling (registering for #DB delivery as some callback would be a variation of this) 4) something that is neither a code nor a function pointer (?!) You said it was not #1. No #2 is not interesting at all (trivially detectable by code hashing). So I assume you do #3, right? > Detection > ========= > > In it's current form there is no prevention of someone else accessing > the debug registers. This could be easily added with GD access flag > control, however this is left as an exercise to the reader. > Ho ho :) GD flag allows you to detect that others want to use the debug registers. But this is only the beginning of the story -- the real question is what you do next? You have two options: 1) "emulate" reads/writes to DRx (but don't touch the physical register) 2) stop using given DRx and give it back to the system One might be tempted to go with #1 as it sounds easy, but this is trivially detectable by a simple program that sets e.g. a read access breakpoint somewhere in its code and then tries if that breakpoint actually *works*. So, option #2 is a better choice. But then the problem is: how do you know when the OS stops using the DRx so that you can claim it back? Not an easy problem as Rafal found out when he was coding his First Xen Hypervisor Rootkit (he also coded The Second XHR), incidentally also called the DR rootkit :) You can find Rafal's presentation here: http://invisiblethingslab.com/bh08/part2.pdf and also a working code (with full GD support with DRx give-back): http://invisiblethingslab.com/bh08/code/part1/xen-subvert-0.8.2.tgz There is also a paper Rafal wrote about this for all the people that like to read something before going sleep: http://invisiblethingslab.com/bh08/papers/part1-subverting_xen.pdf (You can also read about a different Xen Hypervsior Rootkit implementation there). > References > ========== > > 1) The IA32 Software Developers Manual Vol. 3B, Chapter 18 > 2) Mistifying the debugger, Phrack 65-8, halfdead For sure I wasn't the first one using DRx for rootkit/backdoor coding, but I think my 2006 Black Hat presentation predates this Phrack article: http://invisiblethings.org/papers/joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt (slide #41) :) joanna. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjAVrkACgkQORdkotfEW84xEACdGFI9rr7CiBWYY88CFMADWcnu eDsAn1641FvBefIr9OKyoInziGHEM+0T =ghzM -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Thu Sep 4 20:14:25 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Sep 2008 20:14:25 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: Your message of "Fri, 05 Sep 2008 01:45:33 +0430." <26f61db50809041415u589b1b23n787c737021bf2504@mail.gmail.com> References: <48C03DED.3050601@immunityinc.com> <26f61db50809041415u589b1b23n787c737021bf2504@mail.gmail.com> Message-ID: <4429.1220573665@turing-police.cc.vt.edu> On Fri, 05 Sep 2008 01:45:33 +0430, Mohammad Hosein said: > i'm probably 2-3 days far from examining this myself , but if anyone out > there have ideas on how this whole debug register hooks and stuff would > react on "hardened" kind of kernels ( like the one gentoo offers ) let us You'd probably need to examine each "hardened" kernel to see if their particular mix of hardening features includes anything to stop this particular rootkit. If the particular kernel doesn't address it, the rootkit won't care. There's too many different "hardened" kernels out there, with varying degrees of hardening and sanity of security posture, across the entire spectrum of "not really hardened" to "misguided cargo-cult hardening" to "truly bulletproof" that making a generic judgment is pointless. And note that even the "truly bulletproof" ones will probably yield when faced with a sufficiently high caliber artillery shell... ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080904/b142b61d/attachment.pgp From bania.piotr at gmail.com Fri Sep 5 01:24:12 2008 From: bania.piotr at gmail.com (Piotr Bania) Date: Fri, 5 Sep 2008 07:24:12 +0200 Subject: [Dailydave] DR Linux 2.6 rootkit released References: <48BEF476.6040103@immunityinc.com> <48C056BB.3010000@invisiblethings.org> Message-ID: <002001c90f17$a4889a10$9cd61953@DIED> > For sure I wasn't the first one using DRx for rootkit/backdoor coding, but > I > think my 2006 Black Hat presentation predates this Phrack article: > > http://invisiblethings.org/papers/joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt > > (slide #41) > > :) For sure you were not even close. PM.Wanderer or Orgasmotron virus used this *debug registers* technique back in 1997 already. - PM.Wanderer : http://old.antivir.ru/english/lib/wanderer.htm - Orgasmotron (Vecna.Tron): http://www.viruslist.com/en/viruses/encyclopedia?virusid=19117 - 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 jon at oberheide.org Fri Sep 5 02:11:03 2008 From: jon at oberheide.org (Jon Oberheide) Date: Fri, 05 Sep 2008 02:11:03 -0400 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: <4429.1220573665@turing-police.cc.vt.edu> References: <48C03DED.3050601@immunityinc.com> <26f61db50809041415u589b1b23n787c737021bf2504@mail.gmail.com> <4429.1220573665@turing-police.cc.vt.edu> Message-ID: <1220595063.22994.26.camel@localhost> On Thu, 2008-09-04 at 20:14 -0400, Valdis.Kletnieks at vt.edu wrote: > On Fri, 05 Sep 2008 01:45:33 +0430, Mohammad Hosein said: > > > i'm probably 2-3 days far from examining this myself , but if anyone out > > there have ideas on how this whole debug register hooks and stuff would > > react on "hardened" kind of kernels ( like the one gentoo offers ) let us > > You'd probably need to examine each "hardened" kernel to see if their particular > mix of hardening features includes anything to stop this particular rootkit. > If the particular kernel doesn't address it, the rootkit won't care. There's > too many different "hardened" kernels out there, with varying degrees of > hardening and sanity of security posture, across the entire spectrum of > "not really hardened" to "misguided cargo-cult hardening" to "truly bulletproof" > that making a generic judgment is pointless. In general, "hardened" kernels are simply designed to "harden" the system against initial exploitation rather than play the tricky game of prevention/detection during/after loading of the rootkit. If there's wide open avenues for loading via /dev/kmem (CONFIG_DEVKMEM=y), /dev/mem (CONFIG_NONPROMISC_DEVMEM=n), or, in the case of DR, insmod (CONFIG_MODULES=y), then your hardened kernel can only do so much. Of course, that's not to say that kernel protection mechanisms don't attempt to detect debug register usage [1], but as Joanna points out [2], it ain't so simple. Regards, Jon Oberheide [1] http://uninformed.org/index.cgi?v=6&a=1&p=18 [2] http://lists.immunitysec.com/pipermail/dailydave/2008-September/005329.html -- 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/20080905/a093b07d/attachment.pgp From smaillist at gmail.com Fri Sep 5 12:10:13 2008 From: smaillist at gmail.com (Sowhat) Date: Sat, 6 Sep 2008 00:10:13 +0800 Subject: [Dailydave] XCon 2008 Call for Paper In-Reply-To: References: Message-ID: (Notes: XCon is held by XFOCUS guys (Casper and others), they wrote the CFP and I am just helping to post it to FD/DD. If you have any questions regarding the schedule, the conferences, the hotel, etc, please shoot against Casper ;) Though I am happy to forward it. Welcome to XCon! Welcome to China!) ---------------------------------------------------------------------------------------------------------------------------------- XCon 2008 Call for Paper Nov. 18th ? 19th, 2008, Beijing, PRC (http://xcon.xfocus.net) XCon is wholeheartedly expecting papers from those who are passionate about information security technique and their participation and sharing of the conference. Attenders Anyone who loves information security, including information security experts and fans, network administrators, network security consultants, CIO, hacker technique fans, etc. Location : Beijing Jintai Hotel http://www.bjjintaihotel.com/ Topics include (but not limited to): --- Security in new fields - Vista - Web 2.0 - 3G/4G network - Mobile Handset - Banks & financial institutes - GRPS & CDMA - Routing device - Visualization technique --- Application security - Web application vulnerability research - Application reverse engineering and related automated tools - Database security & attacks - Protocol security & exploitation - Advanced Trojans, worms and backdoor technique - Encryption & decryption technique --- Intrusion detection/forensics analysis - File system analysis & recovery - Real-time data structure recovery - Reverse engineering (malicious code analysis technique, vulnerability research) - Traffic analysis - Intrusion detection and anti-detection technique --- Wireless & VoIP security - 802.11x, CDPD, Bluetooth, WAP/TDMA, GSM, SMS - PDA & mobile protocol analysis - Palm, Pocket Pc - Wireless gateway - VoIP security & vulnerability analysis - WLANs hardening & vulnerability analysis ---P2P technique - Instant messenger (MSN, Skype, ICQ, etc.) - P2P application (BT, Emule, Thunder, online multi-media, etc.) Paper Submission The submitted paper will include the following information : 1) Brief introduction to the topic. Please clarify if the topic has been previously publicized, and if so, the distribution scope. 2) Speaker's self introduction and work experience. 3) Speaker's contact information: full name, alias, nationality, network nickname, e-mail, tel, fax, current working place and company, IM (MSN, ICQ, YM, AIM or others). 4) Presentation details: - duration - if any new tool/vulnerability/exploit will be released 5) The paper must include both PPT (for presentation) and WORD (for detailed description) in MS Office or OpenOffice format. All the papers will be submitted to cfp at xfocus.org for preliminary selection. The deadline for submission is Oct. 10th, 2008, and deadline for confirmation is Oct. 20th, 2008. No matter if the paper is accepted, we will officially inform you by the provided contact method within 5 working days. Some important dates * Deadline for submission ? Oct. 10th, 2008 * Deadline for confirmation ? Oct. 20th, 2008 Speakers' privilege If your paper is accepted by XCon, you will be invited to give an individual lecture in XCon. The speakers will be provided with : - Round-trip plane ticket (Economy class, and one person only. Foreign speakers up to 1,200 USD) - Two days' food and accommodation - Invitation to celebration party - Tour to some well-known scenic spots and historical sites in Beijing, taste of Chinese flavored food - Luck draw Important : - Speakers must provide corresponding invoice or credential. - XCon reserves the right of final explanation. For more information about the conference, please contact xcon at xfocus.org or professional XCon2008 organizer. MSN: xfocusxcon at hotmail.com; tel : 086-010-62029792 Application In order to attend the conference, please register at XCon website (http://xcon.xfocus.net) or directly contact the organizer mentioned above. We will offer different discounts according to the time of application. Attenders' food and accommodation will be covered by themselves, and XCon will provide restaurant reservation and other service. Other information : All the information about XCon will be released on XCon and Xfocus website. Please visit http://xcon.xfocus.org/ for more information about speakers, agenda and previous XCon documents. Thank you for your support on XCon ! -- Sowhat http://secway.org "Life is like a bug, Do you know how to exploit it ?" -- Sowhat http://secway.org "Life is like a bug, Do you know how to exploit it ?" From curtw at siu.edu Fri Sep 5 12:27:45 2008 From: curtw at siu.edu (Curt Wilson) Date: Fri, 05 Sep 2008 11:27:45 -0500 Subject: [Dailydave] DR Linux 2.6 rootkit released In-Reply-To: <4429.1220573665@turing-police.cc.vt.edu> References: <48C03DED.3050601@immunityinc.com> <26f61db50809041415u589b1b23n787c737021bf2504@mail.gmail.com> <4429.1220573665@turing-police.cc.vt.edu> Message-ID: <48C15E01.8010202@siu.edu> Valdis.Kletnieks at vt.edu wrote: > On Fri, 05 Sep 2008 01:45:33 +0430, Mohammad Hosein said: > >> i'm probably 2-3 days far from examining this myself , but if anyone out >> there have ideas on how this whole debug register hooks and stuff would >> react on "hardened" kind of kernels ( like the one gentoo offers ) let us > > You'd probably need to examine each "hardened" kernel to see if their particular > mix of hardening features includes anything to stop this particular rootkit. > If the particular kernel doesn't address it, the rootkit won't care. There's > too many different "hardened" kernels out there, with varying degrees of > hardening and sanity of security posture, across the entire spectrum of > "not really hardened" to "misguided cargo-cult hardening" to "truly bulletproof" > that making a generic judgment is pointless. > > And note that even the "truly bulletproof" ones will probably yield when > faced with a sufficiently high caliber artillery shell... ;) What about SElinux? I don't currently have the time & resources to test this. From dave at immunityinc.com Fri Sep 5 13:43:44 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 05 Sep 2008 13:43:44 -0400 Subject: [Dailydave] IKE Message-ID: <48C16FD0.9010201@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So yesterday at the CANVAS user's group meeting people were starting to talk about the massive hurricane headed in our direction. Mostly in Miami people ignore hurricanes. So when they do start to talk about evacuating that means things are probably going to be bad. Last time "bad" was no power for several weeks, which meant no sewage for tall buildings and no gas for cars (those pumps are electric). Driving in Miami is dangerous at the best of times, but when the traffic lights are all stuck blinking yellow it becomes suicidal. Other than hurricanes, we did get a chance to talk rootkits at the CANVAS user's meeting. I don't necessarily see Immunity's role as "build the world's most cutting edge rootkit". But having a rootkit that penetration testers can use with a double-click is just as cool as having an exploit that breaks into the host with a double-click. Kostya also made me take the NOP Certification, which I'm happy to say I did, in fact, pass, much to Kostya's evidenced surprise. :> In honor of such excitement, there's a "special" here on the news page: http://www.immunityinc.com/news-latest.shtml - -dave P.S. If you're going to post about the rootkit on ZDnet/etc, please note it was Daniel Palacio and Bas Alberts who worked on that project, and not me. Realistically though, I hope lots of people download it and extend it. There's no I in hacking! :> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwW/PtehAhL0gheoRAlK7AJ0eEEEr712ML3OBUiNq3KShQ6ZH5gCggK3k R+NOr/iFlaWix3edHC9Vi+g= =SiVu -----END PGP SIGNATURE----- From thomas at coseinc.com Mon Sep 8 02:50:39 2008 From: thomas at coseinc.com (Thomas Lim) Date: Mon, 08 Sep 2008 14:50:39 +0800 Subject: [Dailydave] recruitment of researchers Message-ID: <48C4CB3F.90303@coseinc.com> dear dailydave readers COSEINC is looking to hire the following: Mobile Phone Platform Researchers: * Good knowledge of the Windows Mobile, Symabian and/or Blackberry internals * Experienced in developing and reverse engineering embedded applications for mobile devices * Good understanding of Wireless Data Link Layer, including WLAN, Wi-Fi and WiMAX * Good understanding of mobile network protocols, including GSM, 2.5G and 3G Virtualization Researchers: * Good knowledge of kernel internals for windows and linux * Experienced in developing and reverse engineering of low level drivers * Good knowledge and understanding of Intel VT and AMD-V virtualization artcitecture * Good understanding of current virtual machines technologies for those of you who are interested, please visit www.coseinc.com for more information or send your detailed resume to hr at coseinc.com. -- Thank you Thomas Lim COSEINC Private Limited From hennings at gwu.edu Wed Sep 10 09:16:07 2008 From: hennings at gwu.edu (Amy Butler) Date: Wed, 10 Sep 2008 09:16:07 -0400 Subject: [Dailydave] Job posting - Sr. Security Engineer Message-ID: <48C7C897.6010800@gwu.edu> Hi Dave, Hope you don't mind me posting a job for your readers: Sr. Security Engineer - George Washington University George Washington University is seeking a highly qualified individual to fill an immediate opening within the Information Security Office. The candidate's primary job function would be to perform penetration tests and application security assessments. As such, candidates must be: 1. Self-motivated and able to work with little oversight. 2. Able to perform detailed and thorough assessments on technology infrastructure prior to deployment. 3. Able to convey both orally and in written form the results of analysis, as well as remediation strategies. Basic Technical Requirements include: 1. Extensive experience performing vulnerability assessments and application testing. This includes both remote and local assessments against Windows and UNIX hosts and their applications. 2. Knowledge of scripting languages and networking protocols. 3. Competence in analyzing Java and Javascript is a plus. The salary range for this position is $90,000 to $115,000. In addition to health care and other benefits, GWU offers its employees 96% free tuition for Undergraduate, Masters, and PhD programs. Candidates can apply online at: https://www.gwu.jobs/ Click on Technical Positions and submit your application through the Sr. Computer Forensic Information Security Systems Engineer post. Amy Butler Assistant Director, Security Systems Operations The George Washington University From arunkoshy at gmail.com Thu Sep 11 04:29:13 2008 From: arunkoshy at gmail.com (Arun Koshy) Date: Thu, 11 Sep 2008 18:29:13 +1000 Subject: [Dailydave] tooltalk : OSR DMK Message-ID: <1d0ba3070809110129y97e40ah55a0abc878739a72@mail.gmail.com> check : http://www.osr.com/toolkits_dmk.shtml Would like to know if anyone's had production / experimental dealings with the above ? Details about your experience with the kit would be appreciated. From dave at immunityinc.com Fri Sep 12 08:09:37 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 12 Sep 2008 08:09:37 -0400 Subject: [Dailydave] Hilarious posts Message-ID: <48CA5C01.3030806@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In this industry, it's always important to remember to bring the funny! This month's funny is brought by a patch that takes out something Kostya noted in the protected storage: i.e. it used a set key in French Windows. Obviously the French government got very upset about that (even though it was originally their fault for demanding broken crypto in the first place) and MS rushed off to change it in record time! Original post: http://expertmiami.blogspot.com/2008/06/francaises-francais-time-to-bend-over.html News0ft's post about it (castigating people for always finding THE BIG BUG!): http://news0ft.blogspot.com/2008/09/on-frl-le-big-onetm.html - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIylwAtehAhL0gheoRAhenAJ96OjDLulE7ABgngmOClCo6IXpDogCfVTEA b5LuAyip9QCBhHkFe4RvBvE= =CTy4 -----END PGP SIGNATURE----- From kyle.c.quest at gmail.com Fri Sep 12 08:45:32 2008 From: kyle.c.quest at gmail.com (Kyle C. Quest) Date: Fri, 12 Sep 2008 08:45:32 -0400 Subject: [Dailydave] tooltalk : OSR DMK In-Reply-To: <1d0ba3070809110129y97e40ah55a0abc878739a72@mail.gmail.com> References: <1d0ba3070809110129y97e40ah55a0abc878739a72@mail.gmail.com> Message-ID: When it comes file system and file system filter drivers on Windows OSR is the best. The DMK is worth every penny... It makes life so much easier allowing you to focus on what you need to do instead of battling with the windows kernel internals. It's especially great if you need to support a wide range of platforms. A number of security companies use them in their products (to do content control, encryption, etc). I only wish that DMK had a way to hold buffers without having to return the output buffer, but that can be worked around. > http://www.osr.com/toolkits_dmk.shtml > > Would like to know if anyone's had production / experimental dealings > with the above ? Details about your experience with the kit would be > appreciated. From dave at immunityinc.com Mon Sep 15 08:30:38 2008 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 15 Sep 2008 08:30:38 -0400 Subject: [Dailydave] Annoyances Message-ID: <48CE556E.9030507@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You know what would be annoying? If every fifteen seconds a random VM was suspended just long enough to get a memory snapshot and then that snapshot was analyzed for CANVAS-style shellcode in every process. It's not hard to do now that the API's are all opening up. Even a simple "This thread is running from the heap and is not Java" would work. At that point the shellcode will have to jump into unused space in a DLL and then we all get to play statistical matching games to say "This function does not look like Visual Studio compiled it, unlike the rest of the DLL". Anyways, there's a lot of cool stuff you can do from the hypervisor. Probably the stuff VMWare and Microsoft and Xen don't want to talk about involved breaking DRM, writing invisible email-sniffing programs that hook Exchange's new email function, or other fun stuff. Just being able to get a clean copy of memory is cool, since you don't get one with a little daemon installed on the server (since memory changes as you copy it). - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIzlVutehAhL0gheoRAi2uAJ4hdQFi5cH/35vh5zgZNhs9ARvmkgCdE8rI 6ZDejFziVmOQQpThAI4LUBI= =WdZI -----END PGP SIGNATURE----- From nicolas at immunitysec.com Mon Sep 15 11:01:25 2008 From: nicolas at immunitysec.com (Nicolas Waisman) Date: Mon, 15 Sep 2008 12:01:25 -0300 Subject: [Dailydave] Immunity Debugger 1.7 Released Message-ID: <48CE78C5.2040705@immunitysec.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Immunity is proud to announce: Immunity Debugger v1.7 It's been a rough couple of months and the release got delayed by other projects, but the new version is now among us! New in this release: New methods had been added for setting variables on the disassembled functions. Scripts for auditing drivers and ActiveX are now available and good amount of bugs have been fixed. We would like to express our appreciation for the enormous amount of contributions, feedback and requests we receive daily from the Immunity Debugger community at http://forum.immunityinc.com. Thanks for using Immunity Debugger! We hope you enjoy this month's release, Check out the Changelog below for more detailed information. You can upgrade your current Immunity Debugger by going to Help/Update or directly downloading the new installer from http://www.immunityinc.com/products-immdbg.shtml Sincerely Team Immunity http://www.immunityinc.com 1.70 Build 0 New Features: - - Debugger o Added support for variable decoding when second pass analysis enabled - - Immunity Debugger API o Added getVariable/setVariable methods o Added driverlib.py for analyzing drivers - - PyCommands o activex.py for auditing ActiveX controls - - Bug Fixes o Fixed Python pathing issue when JIT debugging/spawning from right-click o Fixed Module.getName() method to return only the module name o Fixed length check error in imm.Assemble() -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIznjFnx8KWzmcRsERAj5DAKCyLIRpNefIWxBATN0akyQxXsNzfQCfefBi rjevUwYBSYuza3HVtOkHOe4= =GvYv -----END PGP SIGNATURE----- From avri.schneider at gmail.com Mon Sep 15 14:09:44 2008 From: avri.schneider at gmail.com (Avraham Schneider) Date: Mon, 15 Sep 2008 21:09:44 +0300 Subject: [Dailydave] Either get in.... In-Reply-To: <489B7D85.6040200@immunityinc.com> References: <489B7D85.6040200@immunityinc.com> Message-ID: http://www.youtube.com/watch?v=Fz0E8Lh7twg I don't have access to either ImmunityTarget.exe or ImmunityService.exe... Regards, Avri On Fri, Aug 8, 2008 at 1:56 AM, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It's thunderstorming here in Vegas. Already several people have been > arrested at the Riviera trying to break into the computer room. Very > exciting stuff! But tomorrow the public opening of the NOP > certification starts, so I wanted to make sure everyone knew how to > use VisualSploit, if that's their tool of choice (which I recommend, > of course :>). You'll be able to bring your own tools but VisualSploit > is just so durn pretty! > > http://www.immunityinc.com/niprint-defcon16.html > > > - -dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIm32DtehAhL0gheoRAgRjAJ9lKCQjosLwP2ikxKqzDLIZhSM6JwCfeUaf > sVTYXdZ/2VuSDijI8niFPb8= > =CXOO > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080915/9533efff/attachment.htm From alexm at immunityinc.com Mon Sep 15 18:00:04 2008 From: alexm at immunityinc.com (alexm) Date: Mon, 15 Sep 2008 18:00:04 -0400 Subject: [Dailydave] Either get in... Message-ID: <48CEDAE4.1020200@immunityinc.com> Avri, That's by design, one of the ideas behind the NOP is not to allow people to practice on the specific target before taking the exam. We feel that one of the problems plaguing the certification industry is that for some certifications candidates are provided answer rubrics (though for all possible answers, not just their specific version of the exam) prior to sitting their exam. In order to address this with the NOP, we decided to limit the type of practice people can do before the exam. You're free to download and exploit any program for Windows 2000 you want and that's great prep work; you just can't use our target :) If you'd like to sit the exam Justin Seitz (justin@) and myself will be at ICE (https://www.sans.org/ns2008/whitewolf.php) this year from October 1st through the 3rd. We're hoping to make time for folks who'd like to take the exam as we're also participating in the event. More information about the NOP (including some statistics) can be found here: http://www.immunityinc.com/services-cnop.shtml Cheers, -AlexM /Avraham Schneider Wrote.../ http://www.youtube.com/watch?v=Fz0E8Lh7twg I don't have access to either ImmunityTarget.exe or ImmunityService.exe... Regards, Avri -- Alex McGeorge Senior Security Researcher Immunity, Inc From luiz.eduardo at gmail.com Tue Sep 16 14:11:57 2008 From: luiz.eduardo at gmail.com (luiz.eduardo at gmail.com) Date: Tue, 16 Sep 2008 11:11:57 -0700 Subject: [Dailydave] Either get in... In-Reply-To: <48CEDAE4.1020200@immunityinc.com> References: <48CEDAE4.1020200@immunityinc.com> Message-ID: (sorry for the xpostings) The call for papers for YSTS (you sh0t the sheriff) 2.0 is now open! The 2nd edition will be held in Sao Paulo, Brazil, on November 17th and 18th, 2008 INTRODUCTION YSTS is a very unique event dedicated to the top-notch Information Security Society in Brazil, having local and speakers from abroad. YSTS mixes the highest quality presentations, covering diverse topics in information security, from all technical haxor to management C level good stuff. The goal is make the attendees get the "real big picture" of the current state of information security world, mixing professionals from different Infosec segments of the market. For the attendees, this is almost an invite-only event. So, submitting a talk is certainly a good hack to try to be there, specially if you're local. Due to the success of last year's edition, we'll keep the same format: - Kicked-back and cozy environment - YSTS 2.0 will be held at an almost secret location - Once again, this secret location will, most likely, be a club or a bar - and yes, we have food and drinks CONFERENCE TOPICS The focus for YSTS 2.0 will include the following: * Operating Systems * Career and Management topics * Mobile Devices/Embedded Systems * Information Security Audit and Control * Web and anything 2.0 * Information Security Policies * Networking/Telecommunication/Radio Frequencies * Incident Response & other applicable (and useful) Infosec Policies * Information Warfare * Malware/ BotNets * User awareness/ Social Networking Threats * Secure Programming * Hacker Spaces/ hacker community * Fuzzing * Physical Security * Virtualization * Cryptography / Obfuscation * Infrastructure and Critical Systems * Caipirinha Hacks * and everything else security related you might think would be good for the conference We like shorter talks, 30 minutes is plenty for you to deliver the message, but, if you feel like you need more time, please be specific in the paper submission WHAT WOULD YOU GET BEING A SPEAKER? * Round-trip economy class air-ticket for one person * Airport transportation arrangements * 4 nights of accommodation * Breakfast, lunch and dinner during conference * After-conference parties * Auditing products in traditional Brazilian barbecue restaurants WHY WOULD YOU WANT TO BE A SPEAKER AND GO TO BRAZIL? * Sao Paulo is a melting-pot of different cultures, with plenty of stuff to do * We really take care of our speakers (you don't have to trust us, I am sure you know at least one of our previous speakers, check with them) * We highly recommend that if you're coming from abroad, you stick around for a few more days * and yeah, beautiful people too CFP SUBMISSION Each paper submission must include the following information: * Name, title, address, email and phone/contact number * Short biography and qualification * Speaking experience * Summary or abstract for your presentation * Technical requirements (others than LCD Projector) * Other publications or conferences where this material has been or will be published/submitted. We do accept submissions in English, Portuguese or Spanish. IMPORTANT DATES Final CFP Submission - October 5th, 2008 Final Notification of Acceptance - October 15th, 2008 Final Material Submission for accepted presentations - November 5th, 2008 Please send your talk submission to cfp/at/ysts.org CONTACT INFORMATION General Inquiries: b0ard/at/ysts.org Sponsorship Inquiries: sponsors/at/ysts.org We hope to see you there! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080916/1275b77b/attachment.htm From dave at immunityinc.com Wed Sep 17 13:44:28 2008 From: dave at immunityinc.com (Dave Aitel) Date: Wed, 17 Sep 2008 13:44:28 -0400 Subject: [Dailydave] ndr.py and sarah palin Message-ID: <48D141FC.3000906@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://wikileaks.org/wiki/Sarah_Palin_Yahoo_inbox_2008 http://blogs.abcnews.com/politicalpunch/2008/09/how-transparent.html I have to admit that if a government official uses yahoo.com email addresses to avoid subpoenas, and then their yahoo.com password gets out, that's just funny. Especially when the email subjects are things like "CONFIDENTIAL ETHICS INVESTIGATION". Password recovery for the win! I spent a bit of this morning in some of Cody's ndr.py code fixing a few minor bugs. It's funny how no one noticed his web page on the NDR encoding's wasn't quite right. The Finding 0day's class today is doing activeX stuff which is supported under the newest Immunity Debugger. If you haven't gotten it, now's the time! :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0UH7tehAhL0gheoRAp3PAJ4wPv1DeMJT07pRS66oqsaqA+3/mgCcCxjM pJp8zcyaBAQRCqRGEd4ITQE= =UVoz -----END PGP SIGNATURE----- From dave.korn at artimi.com Wed Sep 17 14:30:43 2008 From: dave.korn at artimi.com (Dave Korn) Date: Wed, 17 Sep 2008 19:30:43 +0100 Subject: [Dailydave] ndr.py and sarah palin In-Reply-To: <48D141FC.3000906@immunityinc.com> References: <48D141FC.3000906@immunityinc.com> Message-ID: <014901c918f3$7eb54be0$9601a8c0@CAM.ARTIMI.COM> Dave Aitel wrote on 17 September 2008 18:44: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://wikileaks.org/wiki/Sarah_Palin_Yahoo_inbox_2008 >From that page: "Nb. The 'ctunnel.com' reference in the browser screen shots is to a proxy service used to prevent the activists from being traced." That intrigued me, so I browsed to ctunnel.com. Not being the default-script-running type, I got a blank page, except for the html title "Ctunnel.com will protect your anonymity on the internet, helping you evade url and ip filters!". So I looked at the source, and it's full of stuff like ....