Looking at Process, Threads, Modules with Powershell 2.0

I have published "Looking at Processes, Modules, and Threads with Powershell 2.0 Part I".  The paper concerns itself with comparing Processes, Modules, and Threads and offers some discussion for comparing their changes over time. See also:
http://www.rmfdevelopment.com/PowerShell_Scripts/diff_PMT.ps1
http://rmfdevelopment.com/PowerShell_Scripts/diff_PMT_adv.ps1

Read More

Time Issues in Libpcap Traces

Time is an important aspect of Network Security Monitoring. If you don't pay close attention to the time shown in your evidence, and recognize what it means, it's possible you could misinterpret the values you see.

My students and I encountered this issue in TCP/IP Weapons School at Black Hat this week. Let's look at the first ICMP packet in one of our labs.

I'm going to show the output using the Hd tool and then identify and decode the field that depicts time.

In the following output, 2d 0c 65 49 occupies the part of the packet where Libpcap has added a timestamp.

Hd output:

$ hd icmp.sample.pcap 
00000000  d4 c3 b2 a1 02 00 04 00  00 00 00 00 00 00 00 00  |................|
00000010  ea 05 00 00 01 00 00 00  2d 0c 65 49 5f bf 0c 00  |........-.eI_...|
00000020  4a 00 00 00 4a 00 00 00  00 0c 29 82 11 33 00 50  |J...J.....)..3.P|
00000030  56 c0 00 01 08 00 45 00  00 3c 02 77 00 00 80 01  |V.....E..<.w....|
00000040  ea f1 c0 a8 e6 01 c0 a8  e6 05 08 00 43 5c 07 00  |............C\..|
00000050  03 00 61 62 63 64 65 66  67 68 69 6a 6b 6c 6d 6e  |..abcdefghijklmn|
00000060  6f 70 71 72 73 74 75 76  77 61 62 63 64 65 66 67  |opqrstuvwabcdefg|
00000070  68 69                                             |hi|
00000072

Tpo convert 2d 0c 65 49 to a time, we have to swap the bytes, so becomes 0x49650c2d, or 1231359021 in decimal. 1231359021 is a Unix timestamp that we can convert with the -r option found in the FreeBSD version of the date command.

First let me show the date on this system so you can see the timezone of the FreeBSD system, and then I'll convert the seconds into a human readable time.

$ date
Wed Jul 28 00:11:23 EDT 2010

$ date -r 1231359021
Wed Jan  7 15:10:21 EST 2009

So, this ICMP packet has a timestamp of Wed Jan 7 15:10:21 EST 2009. Note that the date command produces a time in EST and not EDT. 15:10:21 EST becomes 16:10:21 EDT. I would have preferred seeing the date output show EDT since that is the time zone on the system in question, but I can understand the output. That seems simple enough, right?

Let's see what Tcpdump says about this packet. First I run the date command to remind us where we are running Tcpdump.

FreeBSD Tcpdump:

$ date
Wed Jul 28 00:11:23 EDT 2010

$ tcpdump -h
tcpdump version 3.9.8
libpcap version 0.9.8

$ tcpdump -n -tttt -r icmp.sample.pcap 
2009-01-07 16:10:21.835423 IP 192.168.230.1 > 192.168.230.5:
 ICMP echo request, id 1792, seq 768, length 40

As we expected, this packet has a timestamp of 16:10:21 (ignore the fractions of a second), and since the time zone is EDT it matches what we expect.

Let's see what a tool like Tshark says.

FreeBSD Tshark:

$ tshark -v
TShark 1.0.7
...edited...
Compiled with GLib 1.2.10, with libpcap 0.9.8, with libz 1.2.3, without POSIX
capabilities, without libpcre, without SMI, without ADNS, without Lua, without
GnuTLS, without Gcrypt, with Heimdal Kerberos.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on FreeBSD 7.2-RELEASE-p7, with libpcap version 0.9.8.

Built using gcc 4.2.1 20070719  [FreeBSD].

$ tshark -n -t ad -r icmp.sample.pcap 
  1 2009-01-07 15:10:21.835423 192.168.230.1 -> 192.168.230.5
 ICMP Echo (ping) request

What? Why does it show 15:10:21? That's the result for EST, not EDT, which is the time zone of the FreeBSD system.

Let's see if a Linux system in EDT behaves the same way.

$ date
Wed Jul 28 00:44:54 EDT 2010

$ tcpdump -V
tcpdump version 4.0.0
libpcap version 1.0.0

$ tcpdump -n -tttt -r icmp.sample.pcap 
2009-01-07 16:10:21.835423 IP 192.168.230.1 > 192.168.230.5:
 ICMP echo request, id 1792, seq 768, length 40

$ tshark -v
TShark 1.2.7
...edited...
Compiled with GLib 2.24.0, with libpcap 1.0.0, with libz 1.2.3.3, with POSIX
capabilities (Linux), with libpcre 7.8, with SMI 0.4.8, with c-ares 1.7.0, with
Lua 5.1, with GnuTLS 2.8.5, with Gcrypt 1.4.4, with MIT Kerberos, with GeoIP.

Running on Linux 2.6.32-23-generic, with libpcap version 1.0.0, GnuTLS 2.8.5,
Gcrypt 1.4.4.

Built using gcc 4.4.3.

$ tshark -n -t ad -r icmp.sample.pcap 
  1 2009-01-07 15:10:21.835423 192.168.230.1  192.168.230.5
  ICMP Echo (ping) request

Again, we see Tcpdump correctly honor the local time zone (EDT) and display the timestamp as 16:10:21, whereas Tshark shows the timestamp as EST or 15:10:21.

I am really disappointed by this Tshark behavior. Incidentally, you get the same results from any tool in the Wireshark suite, such as Wireshark itself, capinfos, etc.

Does anyone know why Tshark and the like don't really honor the local time zone, and instead use Standard Time instead of recognizing Daylight Savings Time?

Read More

Review of Digital Forensics for Network, Internet, and Cloud Computing Posted

Amazon.com just published by two star review of Digital Forensics for Network, Internet, and Cloud Computing by Terrence V. Lillard and company. From the review:

Digital Forensics for Network, Internet, and Cloud Computing (DFFNIACC) is one of the worst books I've read in the last few years. You may wonder why I bothered reading a two star book. Blame a flight from the east coast to Las Vegas and not much else to read during those five hours! DFFNIACC is a jumbled collection of incoherent thoughts, loosely bound by the idea of "forensics" but clearly not subjected to any real planning or oversight. This book is very similar to the Syngress book "Botnets" which I gave 2 stars in 2008, and as you might expect features one of the same authors. Save your money and skip DFFNIACC; only the chapter on NetFlow and another offering a general overview of NetWitness are worth reading.

Read More

Review of Virtualization and Forensics Posted

Amazon.com just published my three star review of Virtualization and Forensics by Dianne Barrett and Gregory Kipper. From the review:

"Virtualization and Forensics" (VAF) offers "a digital forensic investigator's guide to virtual environments" as its subtitle. Eric Cole's introduction says "How do we analyze the [virtual] systems forensically since standard methods no longer work? Let me introduce a key piece of research and literature, VAF." I disagree with Eric's claim: I did not find VAF to be a compelling resource for forensic investigators of virtual environments. If an author writes a book on virtual forensics, I would expert more advice on how to accomplish the task, and less description of virtual environments. Unfortunately, VAF spends most of its time talking about virtual systems and not enough time helping investigators analyze them.

Read More

Review of Digital Triage Forensics Posted

Amazon.com just published my two star review of Digital Triage Forensics: Processing the Digital Crime Scene by Stephen Pearson and Richard Watson. From the review:

I have to preface this review by saying my criticism of this book should not be taken as criticism of the brave men and women who put their lives on the line fighting for our freedom in Southwest Asia (SWA). I'm reviewing the book "Digital Triage Forensics" (DTF), not the people who wrote it or the people who rely on the concepts therein.

DTF is a misleading, disappointing book. The subtitle is "processing the digital crime scene." The back cover says "the expert's model for investigating cyber crimes," and it claims "now corporations, law enforcement, and consultants can benefit from the unique perspectives of the experts who pioneered DTF." That sounds promising, right? It turns out that DTF is essentially a handbook for Weapon Intelligence Teams (WITs) who deploy to Iraq and Afghanistan to collect battlefield intelligence before and after Improvised Explosive Devices (IEDs) detonate! I cannot fathom why Syngress published this book, when the intended audience probably numbers in the dozens. Unless you need to learn the basics of how to collect cell phones and hard drive images to provide "actionable intelligence" to warfighters, you can avoid reading DTF.

Read More

Dell Needs a PSIRT

It's clear to me that Dell needs a Product Security Incident Response Team, or PSIRT. Their response to the malware shipping with R410 replacement motherboards is not what I would like to see from a company of their size and stature.

Take a look at this Dell Community thread to see what I mean. It's almost comical.

These are a few problems I see:

1. They are informing the public of this malware problem using phone calls, not a posting on a Web site. A customer thinks he's being scammed and posts a question to a support forum. Someone named "DELL-Matt M" replies:
   
   "The service phone call you received was in fact legitimate... We have assembled a customer list and are directly contacting customers like you through a call campaign. On the call, you should be provided a phone number to call if you have additional questions. Hopefully you received this on your call. If not, let me know and we’ll get it to you as soon as possible so you have all of the follow-up information needed."
   
   Another customer rightfully asks: "So why is there no information in the recall links or other readily obvious place on the site?"


2. The next information about the problem is another post to the same thread from "DELL-Matt M".
   
   "We will continue to update this forum as new information becomes available or questions arise."
   
   This story is making the news and Dell will update customers in a forum thread?!?


3. One customer then questions whether 'DELL-Matt M" works for Dell!
   
   "Will you please post your employee number? In a phone call to Dell this morning I was told that no Dell employee wrote this...."


4. "DELL-Matt M" replies:
   
   "Yes Art, I am a Dell employee and the information I posted is accurate. If you need specific information, please contact US_EEC_escalations@dell.com.
   
   Thanks, Matt"
   
   Still no link to an official Dell story.


5. Try searching for "Dell PSIRT" or "Dell security". You get nothing about the security of Dell products.

Dell needs to step up its game. It's shipping products to customers with malware, and it's "handling" the issue through a support forum.

I think my post Every Software Vendor Must Read and Heed referencing Matt Olney's recommendations is a good place to start, Dell!

Read More

Review of The Watchman Posted

Amazon.com just posted my three star review of The Watchman by Jonathan Littman. From the review:

The Watchman by Jonathan Littman is a tough book to review. The author states that he started writing a book about Kevin Poulsen (The Watchman), then delayed that project to write a book about Kevin Mitnick (The Fugitive Game, or TFG). After finishing TFG, the author returned to the Poulsen book. Unfortunately, it seems that the approach that the author took in TFG (recounting direct telephone conversations with Kevin Mitnick) didn't translate well for The Watchman. Whereas TFG covers the part of the time Mitnick was on the run and speaking with the author, The Watchman tries to tell the overall story of Kevin Poulsen's life. The end result is not likely to reflect reality as well as a story where the author was a first-hand participant. It seems several of the main characters in The Watchman, most notable Poulsen himself, disagree with their portrayal in the book. Nevertheless, The Watchman is worth reading since it is the only book on Kevin Poulsen; just beware its likely weaknesses.

Read More