Tommorow at 8:00AM, I will be giving a lecture to the CSE 4273/6273 Computer Crime and Forensics class here at Mississippi State University.  I was asked to speak on the topic of “Linux Filesystems”, and I have chosen to focus on the ext2 and ext3 filesystem data structures.  The class is using the excellent “File System Forensic Analysis” by Brian Carrier as its textbook, so it’s a great opportunity to cover the chapters on ext2/3 (chapters 14 & 15).

It’s a 50-minute class, and pretty strictly so, since the Information and Computer Security class is held immediately afterwards :).  Due to the limited time I have, I’ve scaled back my coverage of these two chapters to what you see in the following slides.  I’m focusing on the basic data structures used by “extx” to point at files and metadata, such as the superblock, group descriptor tables, and inodes.  I’ve included an example of finding a file on a filesystem using only dd piped through xxd and less, and some discussion of what a forensic examiner or someone tasked with data recovery should be on the look-out for.

Unfortunately with this PDF version of the slides, you won’t see the slick Keynote animations I’ve worked into my lecture.  I’m considering expanding the detail and coverage of this, and recording the slideshow as a video with narration for this site:

• Slides - PDF Format (through the “Reduce File Size” Quartz Filter)
  

Enjoy!

Edit: Wow, that filter really killed the screenshots, uploaded the full-res version

I was searching for something completely different on Google’s video search and ran across this video of Tom Liston and Sherri Davidoff demonstrating cold-boot memory attacks at CanSecWest.  As I have covered before, they used my msramdmp tool to make an image of RAM:

Today, Jacob Applebaum is giving a talk at The Last HOPE conference on the tools they have for dumping and retrieving keys from memory after a cold boot.  These are the tools that were demonstrated some months ago, and got everyone interested in the security of whole-disk encryption products.  There was a lot of interest in the memory dumping tool, so since the Princeton tool had not been released, I wrote msramdmp.

The Princeton tools are now available here.

The key-finding code is definitely of interest, and ought to work with msramdmp images as well (although I haven’t tested the code at all, yet).  From what I’m reading of the memory dumping code and docs, if msramdmp is currently suiting your needs, you may not need to change over, especially if you’re taking advantage of the fact that msramdmp will let you dump a few computers before having to pull the images off and reset the partitions.  If, however, you’re wanting to dump more than 4 gigs on a 64-bit machine, dump over a network, or dump an EFI-based machine, the Princeton tools are definitely what you’ll want to start playing with now.

Very cool work, Jacob!  Hope the talk goes well!

It’s a weekend, so I’m all for a fun post.

The sexyhacking.com videos are not safe for work, however they’re probably even less arousing than you’d think.  They are hosted on YouTube, after all.  You might want to have a look, though, since they’re funny (intentionally and unintentionally), and who knows how long they’ll actually be around.

In the second video, described as Episode 1 in a series called “Naughty Script K1dd13″, basic compilation and usage of nmap is covered by a somewhat disinterested teacher.  It must be hot in the classroom, since she’s unbuttoned her shirt about halfway down.  Strangely enough, while nmap is displaying its scan, they censor the IP addresses involved with COPS-style pixelization:

If you’re paying more attention to the terminal than the girl, you’ll notice that they’re not very thorough.  At 3:49, we catch the video editor asleep at the wheel as the traceroute pops up :

…and at 3:50, the censor wakes up :) :

I’m not even sure why they’re attempting to hide the IP address.  It’s stated in the narration that sexyhacking.com will be used as the target, and the IP address revealed above is simply what you’d get doing a DNS lookup of sexyhacking.com…

(so long as Dan Kaminsky isn’t angry at you)

So, to sum it up:  If you’re redacting information out of a video you’re publishing, you not only have to worry about people being able to reverse engineer your pixelation (just black it out!), you’ll also have to make sure you blot it out of every frame :) .

Last night, I received a phishing email wanting my university email account information.  Whenever I’m picking through email headers, or any other kind of network forensics, I find it useful to punch the IP addresses I find into Google.  You can often build a good image of what that particular system or network is used for, by reading abuse reports, exposed log files, logs of Wiki edits, and all sorts of other situations where an IP address might be indexed by a search engine.  

This particular bad-guy IP is a great example of an IP address that has really made its mark on Google, so I’ll link the results here:

* Google search results for “196.3.61.4″

Off the eastern coast of Madagascar, there’s an island called Mauritius.  On this island there’s the city of Ebene.  In this city, there’s this building, the “Cyber Tower”.  According to Whois, on the third floor of this building, there’s a computer being used for all sorts of phishing and fraud.  

It would be “just another scammer”, but this one has a great sense of humor.  Check out this diff on an edit made from that IP address on the Wikipedia entry for Advance fee fraud:

Very nice.

I just received these two pictures via email from my major professor, and thought I’d share.  They’re from a series of mock trials that were held for this past fall semester’s computer forensics class.  The students had the opportunity to take the stand and present expert witness testimony regarding the evidence that they had examined as part of a class project.  We had a real courtroom, a real judge, real attorneys, and another university’s students sitting as a jury.  I sat as the accused for a few cases, and also helped guide the defense attorneys through some of the more technical aspects of the forensics.

Thankfully, with the inexperience of the expert witnesses, and coaching my attorney a bit (he had an engineering background, which helped), I was found to be not guilty :) .

Yesterday I did an email interview with SCMagazineUS.com reporter Sue Marquette Poremba, and the article was published later in the day here:

• Home-grown scanner mimics Princeton’s “cold-boot” tool

It’s not a bad article by any stretch of my imagination, but there were some points that I felt were important, and brought up in the interview, that didn’t make it through the writing and editing process. I can definitely understand this, as SC Magazine isn’t my soapbox to stand on (that’s what this site is for). I posted these points as a comment to the article, but they appear to have been deleted or “lost”. While I think that’s strange, I’ll let it be, and just post my points here (these might make more sense if you’ve read the article):

• What I have written is not an “encryption scanner”. It simply dumps the contents of memory, in order to allow someone to data carve it for whatever they’re looking for, which could include images, passwords, text, or even encryption keys. My tool doesn’t “scan” for anything. It’s also kind of strange to call it “home-grown” in the title, and then refer to McGrew Security as a “research firm”. I suppose you could argue that both are true, though :)
• The problem that I mentioned that the Princeton researchers “got around” was the large footprint in memory of other techniques of imaging RAM, such as using Linux Live CDs, not whatever the article is implying was the problem (recovering data from RAM, I think?)
• One reason I wrote the tool was simply because the Princeton tool has not, as of right now, been released. I felt like it was important for security and forensic researchers and practitioners to be able to experiment and base further research off of a tool like this.
• I should have placed more emphasis on this in my response, but I think one of the most positive uses for this could be for forensic examiners/investigators. The ability to capture the contents of RAM with a minimal impact, when seizing evidence, can be very helpful.
• I have a lot of respect for the work that the Princeton researchers have done, and I think they have done an amazing job of raising awareness of an issue that’s been around for a long time.

These are things from the interview that didn’t make the cut, but I felt that people should know. It would have been nice if they would have kept my comment underneath the story, but this’ll just have to do. Everyone that I care about reads this blog anyways, don’t they ;) !

Matthew Geiger was kind enough to point out to me a very silly typo I had made when writing msramdmp. Rather than grabbing 8192 bytes every time I went through the loop in the first section of memory it dumps, it was only going through 8182. Ugh. This means that it was writing 0×00’s for the last 10 bytes of every 8k (but thankfully, only for the smaller first section).

It’s fixed now, so if you downloaded it before, you should go and download it again. Sorry about that :) .

…Firewire.

Kind of like the RAM remanence phenomenon that I wrote msramdmp to utilize, this is also something that I thought people already knew about. Firewire devices have direct access to the main memory of hosts that they are connected to, and you can use this access to dump sections of memory from computers you have temporary physical access to.

Metistorm has written up a nice post and script describing this technique, and is very modest about it. He’s been sitting on the script for 2 years, and also thought this was something everyone else already knew :)

It’s something else to add to your forensic/incident-response bag of tricks :)