Dailydave mailing list archives
Re: Dailydave Digest, Vol 46, Issue 8
From: hal999 () att blackberry net
Date: Wed, 27 May 2009 19:43:19 +0000
Yeah, you would come now. H
Sent via BlackBerry by AT&T
-----Original Message-----
From: dailydave-request () lists immunitysec com
Date: Wed, 27 May 2009 13:34:27
To: <dailydave () lists immunitysec com>
Subject: Dailydave Digest, Vol 46, Issue 8
Send Dailydave mailing list submissions to
dailydave () lists immunitysec com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-request () lists immunitysec com
You can reach the person managing the list at
dailydave-owner () lists immunitysec com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Re: entropicdata.com ? (Nate Lawson)
2. Re: Palladium, Memory Forensics, Clouds. (James Butler)
3. WOOT'09 (Alexander Sotirov)
4. PAPER: Generic Unpacking of Self-modifying, Aggressive,
Packed Binary Programs (Piotr Bania)
5. Re: entropicdata.com ? (Dave Aitel)
6. IDA Plug-in writing tutorial (v1.1) (Steve Micallef)
7. Cliph (dave)
8. Re: entropicdata.com ? (Nate Lawson)
9. Re: Palladium, Memory Forensics, Clouds. (dave)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 May 2009 14:17:26 -0700
From: Nate Lawson <nate () root org>
Subject: Re: [Dailydave] entropicdata.com ?
To: Dave Aitel <dave () kof immunityinc com>
Cc: dailydave () lists immunitysec com
Message-ID: <4A171666.5010704 () root org>
Content-Type: text/plain; charset=ISO-8859-1
Dave Aitel wrote:
Lots of people are doing things in web services (AJAX, etc) that require real crypto. So they implement RSA/twofish/etc in Javascript and run that in the browser. But this requires a way to generate a key which requires some entropy. There's no "feed of random numbers" that I know of on the web that you can use to seed your crypto, probably because of cross site restrictions. But it seems like either google gears, HTML5, or one of the other new extensions should offer it as a built-in API. Likewise if they allowed you to get data from other sites (which the new Firefox does sometimes?) then you could set up a web service for people to use to get their entropic data from (over SSL of course :>). What else are people using for this? It seems to be a bit of a theme here at SyScan (re: David Thiel's RIA presentation). Is there an API in Silverlight/Flash/etc that lets you get entropy and then give it back to the browser context?
Hold on here. You're running Javascript RSA in your browser. Where did that Javascript come from? Right, you have to load it over SSL to be sure the Javascript is unmodified. But if you're already using SSL, any crypto you implement browser-side can only be less reviewed and more likely to explode, in addition to requiring SSL anyway. Loading your random data over HTTP is a bad idea too. DSA reveals your private key to an attacker if even a few bits of the random nonce are predictable: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ Please stop Web 2.0 from reimplementing crypto, badly. Help computer! -- Nate ------------------------------ Message: 2 Date: Sun, 24 May 2009 06:13:19 -0400 From: "James Butler" <butlerjr () acm org> Subject: Re: [Dailydave] Palladium, Memory Forensics, Clouds. To: "'Dave Aitel'" <dave () kof immunityinc com>, <dailydave () lists immunitysec com> Message-ID: <A2FD08C71C2A4A29B6CE51B97AEC4C14@PIMPHAND> Content-Type: text/plain; charset="us-ascii" Dave Aitel wrote: _________________ The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does. With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer. ----------------- Dave, I know we spoke about this a few weeks ago, but I did not get a chance to state my disagreement with your opinion. You state that you can do a lot with memory forensics today to find trojan drivers (.sys), and you can. Last time I looked at CANVAS with MOSDEF you were hiding sockets using a TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. First, you are hooking IRPs which are easy to check. Secondly, you are hiding a port by filtering a query to tcpip.sys, but with memory forensics you cannot filter because nothing is queried. Now could MOSDEF be written in a way that more subtly disguised the hook? Certainly and perhaps you already have. Is it possible to create a port for communication without creating a port object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort increases tremendously. Deepdoor still used hooks to intercept packets. The hooks were just hidden deeper than anyone had looked. So yes it is an arms race to "counteract every tiny thing a rootkit writer does", but when doing detection I do not have to detect "every tiny thing" just some things. I will not argue with the fact there is no need to hide processes. Joanna, Greg, etc. have been saying that for years. However, a lot of intruders still use this technique for whatever reason. Let's use memory forensics and eliminate that problem forever. Can memory forensics find traces of CANVAS shellcode? Yes, but it is an extremely expensive operation in regard to time. Does it have false positives? Yes, but instead of looking at perhaps 100 memory sections across 100 processes memory forensics can narrow that down to four or five. Another thing that falls quickly to memory forensics is poor coding practices by the exploit writers. If a handle is left open by mistake or memory is not freed, it is quickly spotted. Peter Silberman has used this to reconstruct the command and control communications of another popular pentesting tool. Does this mean you cannot bypass this detection with proper developers? No. Don't forget though that freed does not necessarily mean gone. Using memory forensics common but stupid techniques malware author's use to prevent reinfecting a box are much easier to spot. For example, with memory forensics you can find all the mutexes a process has open. This might seem like a small thing, but memory forensics is giving us a view into what is happening on the host in ways we did not have before. Is the gradient against memory forensics? Perhaps, but it always is as your attacker evolves. I think now there is more of a gradient for the malware authors than there has been. They have been fighting the war on the disk for a long time. Now it is time they look up to memory as we sharpen our tools for the changing battlefield. Jamie Check here to play with memory forensic tools: http://mandiant.com/software/memoryze.htm to be used with http://www.mandiant.com/software/mav.htm http://www.openrce.org/articles/full_view/32 ------------------------------ Message: 3 Date: Sun, 24 May 2009 14:39:02 -0400 From: Alexander Sotirov <alex () sotirov net> Subject: [Dailydave] WOOT'09 To: dailydave () lists immunitysec com Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi, I want to remind everybody that WOOT'09 is still accepting submissions, but the CFP closes next week: http://www.usenix.org/event/woot09/cfp/ We encourage submissions of work that has been presented at BlackHat or other industry conferences but is well suited to a more formal and complete treatment in a academic peer-reviewed setting. I believe that both the academic and industry communities will benefit from this exchange of ideas. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090524/ba55050b/attachment-0001.pgp ------------------------------ Message: 4 Date: Mon, 25 May 2009 18:19:14 +0200 From: "Piotr Bania" <bania.piotr () gmail com> Subject: [Dailydave] PAPER: Generic Unpacking of Self-modifying, Aggressive, Packed Binary Programs To: "dailydave" <dailydave () lists immunitysec com> Message-ID: <23A8384A2B924CA4A0EE682F8C1C6C87@DIED> Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original ABSTRACT Nowadays most of the malware applications are either packed or protected. This techniques are applied especially to evade signature based detectors and also to complicate the job of reverse engineers or security analysts. The time one must spend on unpacking or decrypting malware layers is often very long and in fact remains the most complicated task in the overall process of malware analysis. In this report author proposes MmmBop as a relatively new concept of using dynamic binary instrumentation techniques for unpacking and bypassing detection by self-modifying and highly aggressive packed binary code. MmmBop is able to deal with most of the known and unknown packing algorithms and it is also suitable to successfully bypass most of currently used anti-reversing tricks. [...] Paper can be found at: http://piotrbania.com/all/articles/pbania-dbi-unpacking2009.pdf best regards, pb -- -------------------------------------------------------------------- Piotr Bania - <bania.piotr () gmail com> - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://www.piotrbania.com - Key ID: 0xBE43AC33 -------------------------------------------------------------------- - "The more I learn about men, the more I love dogs." ------------------------------ Message: 5 Date: Tue, 26 May 2009 22:57:40 -0400 From: Dave Aitel <dave.aitel () gmail com> Subject: Re: [Dailydave] entropicdata.com ? To: Nate Lawson <nate () root org> Cc: dailydave () lists immunitysec com Message-ID: <b581b3220905261957u2c16927br588cc6202c1a45e2 () mail gmail com> Content-Type: text/plain; charset=ISO-8859-1 Sure so one perspective is that anything cryptographic has to get done on the server. Which seems perfectly valid, but in some cases people don't want to do it that way. Maybe they want to sign something, without having to upload it to the server, say. Or maybe they just don't want to burden the server with tons of crypto. There's lots of good reasons to do crypto without reinventing SSL. And, of course, the cross ___domain stuff coming out makes this more likely, I assume. -dave
Hold on here. You're running Javascript RSA in your browser. Where did that Javascript come from? Right, you have to load it over SSL to be sure the Javascript is unmodified. But if you're already using SSL, any crypto you implement browser-side can only be less reviewed and more likely to explode, in addition to requiring SSL anyway. Loading your random data over HTTP is a bad idea too. DSA reveals your private key to an attacker if even a few bits of the random nonce are predictable: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ Please stop Web 2.0 from reimplementing crypto, badly. Help computer! -- Nate _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
------------------------------
Message: 6
Date: Tue, 26 May 2009 18:02:03 +1000
From: Steve Micallef <steve () binarypool com>
Subject: [Dailydave] IDA Plug-in writing tutorial (v1.1)
To: "dailydave () lists immunitysec com"
<dailydave () lists immunitysec com>
Message-ID: <4A1BA1FB.2000207 () binarypool com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
For those who might be interested, I've updated the IDA Plug-in
Writing Tutorial to cover IDA Pro 5.4. The SDK was mostly frozen as
of 4.9, although there have been some subtle changes.
All in all there are about 10 new pages including some corrections,
new functions and a new sample plug-in. Get it here:
http://www.binarypool.com/idapluginwriting/
Feel free to drop me a note with any comments or corrections.
Cheers,
Steve Micallef
------------------------------
Message: 7
Date: Wed, 27 May 2009 11:47:55 -0400
From: dave <dave () immunityinc com>
Subject: [Dailydave] Cliph
To: dailydave () lists immunityinc com
Message-ID: <4A1D60AB.60703 () immunityinc com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For those who are not aware, Cliph passed away in a plane accident recently.
http://www.isec.pl/ has more information about the funeral. He was,
among other things, a great hacker.
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkodYKsACgkQtehAhL0gheoMkACeNekDqO1sDPLQiqAG/2c8kglv
MPgAn1vG7ySg+fSoyLcEk04cGKqvWooK
=qyjL
-----END PGP SIGNATURE-----
------------------------------
Message: 8
Date: Wed, 27 May 2009 09:00:14 -0700
From: Nate Lawson <nate () root org>
Subject: Re: [Dailydave] entropicdata.com ?
To: Dave Aitel <dave.aitel () gmail com>
Cc: dailydave () lists immunitysec com
Message-ID: <4A1D638E.1020301 () root org>
Content-Type: text/plain; charset=ISO-8859-1
Dave Aitel wrote:
Sure so one perspective is that anything cryptographic has to get done on the server. Which seems perfectly valid, but in some cases people don't want to do it that way. Maybe they want to sign something, without having to upload it to the server, say. Or maybe they just don't want to burden the server with tons of crypto. There's lots of good reasons to do crypto without reinventing SSL.
Could you finish your example? They are signing something, which is verified by ... ? Any scenario I come up with to complete your example has problems. Where does the private key come from to sign it? How did the web browser get this key and code. Where does the recipient of this data get the cert to validate the signature?
And, of course, the cross ___domain stuff coming out makes this more likely, I assume.
I'm interested in your proposal here. How would Javascript signatures help? -Nate
Hold on here. You're running Javascript RSA in your browser. Where did that Javascript come from? Right, you have to load it over SSL to be sure the Javascript is unmodified. But if you're already using SSL, any crypto you implement browser-side can only be less reviewed and more likely to explode, in addition to requiring SSL anyway. Loading your random data over HTTP is a bad idea too. DSA reveals your private key to an attacker if even a few bits of the random nonce are predictable: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ http://rdist.root.org/2009/05/20/amazon-web-services-signature-vulnerability/ Please stop Web 2.0 from reimplementing crypto, badly. Help computer! -- Nate
------------------------------ Message: 9 Date: Wed, 27 May 2009 13:33:04 -0400 From: dave <dave () immunityinc com> Subject: Re: [Dailydave] Palladium, Memory Forensics, Clouds. To: butlerjr () acm org Cc: dailydave () lists immunitysec com Message-ID: <4A1D7950.7020807 () immunityinc com> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Certainly the CANVAS kernel rootkit is not a covert one. I think it would be somewhat expensive to do basic adversarial testing in the kernel space on this, although I think it would be valuable research for the community. Is memory forensics "testable" against userspace? Memoryze can find hidden sockets and stuff, but I remember a paper from Peter on "finding shellcode" or something. Is that publicly available? Something Bill Arbaugh said is that one major advantage for memory forensics is that a machine has a lot less memory than it does disk space. Searching through disk space (or even storing it if you do enough forensics) is extremely expensive. To your credit you've released a lot of tools in the space people can use for testing the general concepts, which is a valuable thing for determining the overall level of effort curve of the technology itself. Hopefully soon I'll have some real world numbers here for you. :> Do the DD.exe and similar tools go underneath the memory handlers? I assume modern rootkits are memory handlers (or hypervisors). I'm not sure how acquisition really works against that. - -dave
Dave, I know we spoke about this a few weeks ago, but I did not get a chance to state my disagreement with your opinion. You state that you can do a lot with memory forensics today to find trojan drivers (.sys), and you can. Last time I looked at CANVAS with MOSDEF you were hiding sockets using a TCPIP.sys IRP hook. This shows up like a red flag with memory forensics. First, you are hooking IRPs which are easy to check. Secondly, you are hiding a port by filtering a query to tcpip.sys, but with memory forensics you cannot filter because nothing is queried. Now could MOSDEF be written in a way that more subtly disguised the hook? Certainly and perhaps you already have. Is it possible to create a port for communication without creating a port object? Yes, Joanna demonstrated this with Deepdoor, but the level of effort increases tremendously. Deepdoor still used hooks to intercept packets. The hooks were just hidden deeper than anyone had looked. So yes it is an arms race to "counteract every tiny thing a rootkit writer does", but when doing detection I do not have to detect "every tiny thing" just some things. I will not argue with the fact there is no need to hide processes. Joanna, Greg, etc. have been saying that for years. However, a lot of intruders still use this technique for whatever reason. Let's use memory forensics and eliminate that problem forever. Can memory forensics find traces of CANVAS shellcode? Yes, but it is an extremely expensive operation in regard to time. Does it have false positives? Yes, but instead of looking at perhaps 100 memory sections across 100 processes memory forensics can narrow that down to four or five. Another thing that falls quickly to memory forensics is poor coding practices by the exploit writers. If a handle is left open by mistake or memory is not freed, it is quickly spotted. Peter Silberman has used this to reconstruct the command and control communications of another popular pentesting tool. Does this mean you cannot bypass this detection with proper developers? No. Don't forget though that freed does not necessarily mean gone. Using memory forensics common but stupid techniques malware author's use to prevent reinfecting a box are much easier to spot. For example, with memory forensics you can find all the mutexes a process has open. This might seem like a small thing, but memory forensics is giving us a view into what is happening on the host in ways we did not have before. Is the gradient against memory forensics? Perhaps, but it always is as your attacker evolves. I think now there is more of a gradient for the malware authors than there has been. They have been fighting the war on the disk for a long time. Now it is time they look up to memory as we sharpen our tools for the changing battlefield. Jamie Check here to play with memory forensic tools: http://mandiant.com/software/memoryze.htm to be used with http://www.mandiant.com/software/mav.htm http://www.openrce.org/articles/full_view/32 _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkodeVAACgkQtehAhL0ghep2pQCdHp3o+dwUrMvn9zDSLJEbsqeJ ey0AnjOkrGMGaT3aMEur8lI78bQKhO+t =lnhV -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave End of Dailydave Digest, Vol 46, Issue 8 **************************************** _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Re: Dailydave Digest, Vol 46, Issue 8 hal999 (May 27)