Blackhat Day 4 – DTrace and PINK

This morning I attended a session on DTrace which is a sort of tracing capability created by Sun for Solaris 10 that can be ported to other OS's.  Some engineers from SAIC have figured out how to make this useful for reverse engineering, vuln discovery and even things like exploit prevention (HIPS) . . . the talk started off really slow and then the presenters misjudged the time they had to present and unfortunately rushed the really juicy stuff (the demos that really solidified their points and make people get it) near the end.  One of the coolest things though was when they built a vulnerable binary (it had a heap overrun vuln with an improperly sized malloc() call) and then used Ruby DTRace to watch the process for heap overflows by tracing the heap mallocs and then the writes . . . what really impressed me though was when they then exported this information via a network listener to a running instance of IDA in a Windows VM . . . the data they sent to IDA gave IDA the information it needed to comment the vulnerable / buggy cal statement in the disassembly (they had the vulnerable binary open in IDA and ready to go) . . . it was freaking awesome to see the buffer overrun be detected by Ruby DTrace and information about the vuln pumped to the IDA listener and have IDA instantly locate the bad code and comment it!

This afternoon I attended a session presented by Immunity in which they talked a bit about a pentest job they worked in the past.  The gist of the presentation is that they went after the email gateway, specifically targetting the AV package they had installed on the mail server (i.e. exploiting a vuln in the AV software installed on the email gateway).  They mentioned that a LOT of the AV packages they looked at were compiled with Borland and don't make use of /GS and even opt-out of DEP and disable SafeSEH so that they really don't have or make use of any modern / available mitigations provided by Windows.  This made me think of one of our products that allows you to run up to like 8 or so AV products on your mail server to scan incoming email attachments . . . talk about attack surface!

Anwyays - they crafted an exploit for an AV package that allowed them to own the server and then read email of people they were interested in to gather intel and eventually expand influence internally.  They hopped inbound via the DNS RPC vuln by targeting a PDC to own a domain and from their it was pretty easy to own whatever member machines they wanted to own.  This particular customer was using an 'air gap' network . . . moving data back and forth between machines on USB drives and it was just a matter of waiting until the drive was plugged into the machine so that they could get at the data.  I guess during this engagement they decided that they wanted a really stealthy C&C channel since this wasn't a quick one day thing but something that took a lot of time to setup.  So they created a botnet (sort of - more like a stealthy backdoor - but I guess it could be used in a botnet easily enough) which they call PINK and which will be available soon to CANVAS subscribers.  PINK has the following properties:

  1. It's installed on the client as a shell extension - I thought this required admin rights but they claim that it works as a standard user - I need to check on this. 🙂

  2. Once the user does something like a right-click the DLL loads into explorer and since it's a shell extension it persists reboots.  This DLL is what does the outbound communication (so 3rd party firewall products may alert you that Explorer.exe is trying to do outbound stuff, and you can configure the Vista firewall to block outbound connections from explorer.exe if you so desire).  They could of course probably modify the firewall rules to allow the connection if the user is an admin . . . or they could just use the DLL loaded in explorer to inject a DLL into another process that IS allowed to talk outbound via HTTP (like IE).  This is why outbound filtering is hard if not impossible to do effectively.

  3. The DLL uses the IE proxy settings and it communicates outbound via HTTP GETs.  The communication only occurs when it detects that the user is at the computer and/or surfing the Internet to make the packets look legit in a network trace (i.e. no 4am C&C calls that would be suspicious).

  4. The C&C is performed via blog web sites.  The bad guys (in this case Immunity) setup a blog and they design the backdoor / bot to query for some key words on the blog site (so the blog can be deleted and a new one can be setup and as long as there is a blog post with the keywords indexed by the blog server - the malware would find it when it performs a search on the blog site for blog entries with the keyword).  They used keywords that were topical or related to current events that would seem like things one migth search a blog site for.

  5. Once the bot malware located the keywords in a blog post there was a blob of base 64 encoded data following the keywords.  The decoded data was actually a signed / encrypted command of some kind.  The signing / encryption is important to prevent replay attacks etc.

Something very similar to this was presented at the Seattle Toorcon beta last year and I remember being blown away by the researchers who found evidence that this is actually already being used on various blog sites by real bad guys.  Outside of that conference and now this one - I've never seen anyone else talk about this technique let alone real world malware / bad guys using it.  It is indeed fairly clever . . . and once you start thinking of a blog as a blind drop for your bot / backdoor commands it gets really interesting.   You could actually post your commands in a *legitimate* blog as a comment to that blog post!  so the bad guys don't even need to create a new blog - they can repurpose an existing one and use it for C&C with their bot hosts . . .  I as a former IR guy was more interested in the malware being used on the client . . . Sinan mentioned that it removed itself from the loaded module list so that it was 'invisible' but clearly there is still evidence in the registry as all one would have to do would be to examine shell extensions - which Autoruns can do for you rather quickly . . .


Comments (0)

Skip to main content