Thursday, 22 January 2009

A Return to Consulting

I am going back to consulting and contracting.

I will have more details soon, but I am going to be offering:

  • Security consulting

  • Forensic Analysis and Expert witness work

  • Incident handling response and training

  • Audit and testing

  • Data recovery

  • eDiscovery Services and consulting

  • Malware analysis and research

This will allow me to be able to offer my serives at a lower rate as well as being able to offer the level of serives I like to be able to offer.

Tuesday, 20 January 2009

Command: LSOF

Today's command is the UNIX/Linux command "lsof" or "list open files.

In a *NIX system, the "open files" include:

  • disk files,
  • pipes,
  • network sockets,
  • hardware and devices, and
  • all processes running on the system.
*NIX treats all devices and about everything in the system as a file.
By default, that is if you run "lsof" without any additional parameters, the command will display all the files opened by any processes on the system.

You can select a director, volume of single file to see who is using it. For example, the following command will display who is using the "/etc/passwd" file:
  • lsof /etc/passwd

In order to display the process IDs that are utilising the named binary, and only the PID you could use:

  • lsof -t `which named`

In order to display all of the open processesfrom a user called john, you could use:

  • lsof -u john

To display those files that are using the process with PID 541:

  • lsof +p 541

If you wanted to list any open internet protocol sockets or just those related to DNS (on port 53 that is) you could use the following commands respectively:

  • lsof -i
  • lsof -i :53

To drill down and display the processes that are using a UDP connection to or from A DNS Server at the host (using the default port of 53 UDP) we could use:

The command "lsof" is a valuable testing, audit, incident respense and foresinc utility. Make sure that you know the options associated with this command.

An Open File Search
In *NIX, even a solitary open file will (usually) stop a user from unmounting filesystem. Running "lsof" as the superuser (root) in order to display the open files for a mounted volume will allow you to check if the volume can be dismounted. For instance, the following command displays the open files for the volume "/export/home":

# lsof /export/home
bob 1541 user 3u VREG 14,6 4096 6542 /export/home/file.tmp

A response to Dr Gutmann

In his paper, Dr Gatmann has added a refutation to my work without having read it. This is to answer some of his unfounded claims. Much of what he has stated is taken out of context from a SANS Forensic Blog post on the paper.

I know an MFM is not actually an electron microscope, the comment is "A MFM is a variety of what most people simply term an electron microscope." However, as an SEM (a scanning electron microscope) was used in MFM mode, the use of the term electron microscope is valid.

There is a series of posts that will go into detail coming over the following weeks that I am posting on the SANS Forensic site. This will also incorporate the use of Spin-Stand Microscopy.

At NO point did I state that the experiment used "an MFM to perform an error-cancelling read." Rather, the MFM was used to read BOTH track and off-track data.

One area that we demonstrate is that the assertion, "in conventional terms, when a one is written to disk the media records a one, and when a zero is written the media records a zero. However the actual effect is closer to obtaining a 0.95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one." Made by Dr Gutmann is false. This is demonstrably not the case. This is noted in the peer reviewed paper that Dr Guitmann has not as yet read.

True, all the drives I tested are either PRML or ePRML. I was unable to obtain an unused RLL based drive - not a single one. Old used ones yes, new ones, no. In section 3, Dr Gutmann does note PRML drives (contrary to what he states in his rebuttal).

I used MFM based methods and some spin-stand techniques. The point is that it can be demonstrated that data recovery is stochastic and independent. This means that you may be able to recover individual bits and encoded sections, but you do not obtain any data recovery. Recovery of a bit is not the same as data recovery.

I do not believe that recovery of an RLL based drive from the 1990's would be successful. Yes I do say that bits could be recovered, but again, the issue is that this is not data recovery. Assuming that the occasional success equals data recovery is the flaw in Dr Gutmann's paper.

Springer has the copyright for the paper. The link to the paper at Springer is:

Dr Gutmann's work is not science. There is no experimental verification of anything he has purpored in his paper. To be a valid scientific paper, Dr Gutmann would need to quantify the recovery reats for pre and post wipe data recovery. This is not a single encoded message, but actual data. This was never done.

What was presented as science was a hypothesis and no more. More it is a hypothesis that does not hold.