Open Source and the Digital Forensics Lab

March 18, 2009

A while back I wrote an article for Evidence Technology magazine entitled “Seven Uses of Open-Source Software for the Digital Forensic Lab.” The article was primarily targeted towards law enforcement agencies that were having trouble getting funding for their labs.  In addition to building the case regarding cost savings, I discussed other advantages to running open sourced tools.

At recent conferences I have been increasingly approached by law enforcement as well as corporate investigation teams for advice on dealing with budgetary constraints, so it seems time to resurrect the topic.

Here is a summary of the “Seven”, the original article is here:

  1. Case Management: Although designed for CRM functions, SugarCRM actually makes a great inexpensive case management system.  It has the added advantage of allowing you to maintain a local copy instead of “the cloud”.
  2. Acquisition: The flexibility of “dd” for everything from imaging to memory and file carving makes it the number one contender in this category.  If you must have a MS based solution then you can also try FTK’s Imager lite (not mentioned in the original article).
  3. Analysis: Brian Carrier’s work on The Sleuth Kit with the optional graphical front-end of Autopsy is very worthy of support (tip of the hat to Dan Farmer and Wietse Venema for their original work on “The Coroner’s Toolkit”).  TSK has the added benefit of being scriptable (I use shell or PERL to get the job done).  You can check out TSK here.
  4. Miscellaneous: Stegdetect for dealing with steganography, Ophcrack for system passwords, Foremost or Scalpel for scriptable file carving.
  5. OS support: Linux.  You have access to libraries for NTFS, HFS++, etc. as well as everything you need for MS documents via OpenOffice 3.0. I have had great success with Ubuntu and variations (Mint).
  6. Virtual Platforms: At the time I wrote the article VMWare was offering their player and pre-made virtual systems for download.  If you are running off of a Mac you can use Parallels (not free, but very inexpensive) to run various pre-builds of Linux.  Even more compelling is Live View, which allows you to virtually mount and run a dd image without modifying the underlying image.  You can find Live View here.
  7. Mobile Acquisition and Analysis: Helix is no longer free, but those guys at e-fense  have given so much value to the rest of the world for so long via Helix that I say “Good on them!”.   You can also check out Backtrack 3 – just be aware that you run the risk of altering data if you boot up incorrectly with Backtrack.

What are some other “Can’t miss tools”?  Drop a comment in and tell the rest of us.


Government Denies FOIA Request For .gov Domain List

March 4, 2009

Information Week Article

I was sure that the concept of “security through obscurity” had been thoroughly debunked by now, evidently not.

A recent Freedom of Information Act request for a list of .gov domain names was denied by the GSA.  You should know this about me: I am all for state secrets – I think that, realistically, a government must have secrets.  This is perhaps an argument for another day.

Given the nature of DNS, cached DNS, etc. how long do you think before some of these “hidden” domains show up anyway?

Let’s be clear:  I really don’t think this is a huge deal, but it can be a source of mental fun for the rest of us.  So here is a “wake up it is hump day” mental exercise for you (This WILL be graded, you WILL need to know this for the test!):

What would be a more effective “security through obscurity model” for the government to use, while still listing the required domains?

I will start the ball on this (and therefore open myself up to immediate criticism!):

  • Register the domains as normal, but do not use obviously descriptive names: Instead of “trackingPrivateCitizens.gov” you might use “TPCProject.gov”, you may even consider using a completely sanitized CRC32 version: 13201934.gov  (Free Vidoc Razor T-shirt if you can figure that one out).
  • Keep an internal, classified document that maps out the “sanitized domains” with their true descriptions.

How would you set out to discover these “hidden” domains?

  • We will assume zone transfer is not available (Could be a big assumption).
  • Build a database of known domain names.
  • What next?

Feel free to post any ideas – or chide me for wasting your time and making you read this cruft!


The Top 5 Biggest Infosec Lies

March 2, 2009

I have compiled a list of what I believe are the biggest lies told by and about infosec.  Let me know if you have an addition to the list!

5. There is no evidence that the data has been misused….

This lie is typically told by a company that has just had their digital posteriors handed to them.  The first question that I want to ask upon hearing this one is:

“So… wait… you were completely unable to detect the intruders that were playing around in your own systems for 3 or 4 months, but now all of a sudden you can tell across the entire globe if the information is being misused?”

4. It was a sophisticated attack….

The biggest problem is deciding if this lie is being told by the party that was breached, or the media.  For some reason the media classifies everything as “hacked”, even when it isn’t.  You can add to this that the party that has been breached has two things working against it:

1.  Who wants to admit they were breached by something stupid?  If you are going to be breached you want it to be the most sophisticated, complex attack known to man.

2. The “mouthpiece” for the organization that was breached likely doesn’t understand the technical issues themselves.

3. Of course it is secure – the (Military/Law Enforcement/Government) uses this, so it has to be….

I was asked by a client to sit in a product demonstration not too long ago, and the vendor’s mouthpiece kept harping on the fact that “This is so secure, NASA uses it!”.  They were more than a little crestfallen when I demonstrated for them that they were sending their username/password in Base64 decoded format for the entire world to see – and then the page was moving to SSL encryption (on an expired certificate).

The lesson here?  Just because no one has questioned it, doesn’t make it secure.

2.We have “Insert favorite technology here” so we know we are all set….

My first response to this usually is: “Tell me/Show me the specific policy/procedure that your favorite technology is in place to support.  What about the policy and procedure that governs support of the technology?”  The largest portion of the time an organization is completely unable to do this simple exercise.

Infosec technology that does not support policy and procedure is pretty much meaningless – at best you have wasted money, at worst you have created yet another attack vector through a mis-managed, poorly understood device.

1.  We are compliant with (HIPAA, GLB, Sarbannes-Oxley, PCI, etc.) so we know we are secure….

Ummm… so was Heartland….  Do we really need to go down this road?


The Fifth Amendment and Sebastien Boucher: Beyond Knee-Jerk Response

February 27, 2009

In December of 2006, Sebastien Boucher was crossing the US border when he was stopped and his laptop was reviewed by ICE officials.   The laptop was in his backseat and, according to documents, the drive containing the child pornography was accessible without requiring a password.

Mr. Boucher was Mirandized, but waived his rights and continued to talk to the agent.  During this conversation Mr. Boucher told the agent that he sometimes accidentally downloaded child pornography but would then delete the files when he realized what they were.  The agent requested that Mr. Boucher show him where he stored the files that he downloaded and Mr. Boucher directed him to a drive “Z”.

The agent continued to search the laptop and found several more instances of child pornography.  Mr. Boucher was subsequently arrested and the laptop seized (it was shutdown).

Nine days later a forensic bit image was made of the drive and the drive “Z” was found to be encrypted by PGP, and the content unaccessible without the encryption key which, curiously enough, Mr. Boucher has refused to turn over.

In November 2007 Judge Jerome J. Niedermeier granted Sebastien Boucher’s motion to quash the subpoena directing him to turn over his encryption key for the drive, citing his fifth amendment rights.

An appeal was filed and U.S. District Judge William Sessions in Vermont ruled this week that Mr. Boucher does not have a fifth amendment right to keep the files encrypted.

What motivates me most to write about this case is the knee-jerk response that will surely follow by those that only read news releases and not the actual filings in the case.  Both judges have raised some fascinating issues regarding the fifth amendment and this specific case, and both the granting of the motion to quash and the subsequent reversal hinged on specific facts in this case, and NOT a blanket decision as some blogs will have you believe.

Judge Niedermeier weighed issues regarding compulsion to testify (subpoena) and the various components that make up a valid fifth amendment argument. In pondering these points the judge notes:

Both parties agree that the contents of the laptop do not enjoy Fifth Amendment
protection as the contents were voluntarily prepared and are not testimonial. See id. at 409-10 (holding previously created work documents not privileged under the Fifth Amendment). Also, the government concedes that it cannot compel Boucher to disclose the password to the grand jury because the disclosure would be testimonial. The question remains whether entry of the password, giving the government access to drive Z, would be testimonial and therefore privileged.

The state evidently agreed to “not use the production of the password against Boucher.”  In so doing the state felt it would remove the testimonial aspect of entering the password.  Judge Niedermeier rejected this outright, citing United States v. Hubbell, 530 U.S. 27 (2000).

In rejecting further arguments, Judge Niedermeier pointed out that the password was something in Boucher’s mind, and further stated:

This information is unlike a document, to which the foregone conclusion doctrine usually applies, and unlike any physical evidence the government could already know of. It is pure testimonial production rather than physical evidence having testimonial aspects. Compelling Boucher to produce the password compels him to display the contents of his mind to incriminate himself.

In his reversal, Judge Sessions notes that neither side questions the fact that “the contents of the laptop were voluntarily prepared or compiled and are not testimonial, and therefore do not enjoy Fifth Amendment protection.”, but notes that the root of the issue is the production of the password that in effect causes the accused to “‘disclose the contents of his own mind’”.

He also mentions the “compelling” aspect of the subpoena and notes that there are two scenarios under which the act of production in response to a subpoena may communicate incriminating facts:

(1) ‘if the existence and location of the subpoenaed papers are unknown to the government’; or (2) where production would ‘implicitly authenticate’ the documents.” Id. (quoting United States v. Fox, 721 F.2d 32, 36 (2d Cir.1983)).

Drawing from this the judge concludes that because Boucher already let the Government see the drive and the contents (unencrypted) and because the Government does not require Boucher’s production of the unencrypted drive to link him to the files on his computer, then the production is not considered incriminating and so the fifth amendment protection is not valid.

I have to say that without reading the opinions I would assume that because Mr. Boucher was Mirandized, willingly volunteered information regarding the existence and contents of the drive (prior to shutdown and encryption) and willingly allowed a Government agent to browse his drive I would have assumed that he had rung a bell that could not be unrung.

[  Copies of the opinions will be uploaded soon]


Adobe Releases Fix for Flash

February 26, 2009

OVERVIEW:
Adobe released a fix for its Flash Player yesterday that mitigates 5 different attack vectors.  Some of the flaws could allow a malicious attacker to take over a compromised system merely by enticing a user to a page with a compromised .swf (Flash) file.

AFFECTED SOFTWARE:
Flash player 10.0.12.36 and earlier for:

Windows, Mac OSX, Linux

USEFUL LINKS:

Adobe Security Bulletin:
http://www.adobe.com/support/security/bulletins/apsb09-01.html

Patch for v. 10
http://www.adobe.com/go/getflashplayer

Patch for v. 9
http://www.adobe.com/go/kb406791

NOTES:

Make sure to patch each browser that you have installed.  You can do this by visiting the patch link each time for each browser.