disLEXia

Sunday, 12. January 2003

Electronic Discovery

Ernie the Attorney has written on Electronic Discovery and the importance of timeline analysis of email. The "Handbook of Computer Crime Investigation" (ISBN 0-12-163103-6) has a nice chapter on "The other side of civil discovery" explaining how to prepare the data for a discovery request from the view of a forensic consultant. (No, the Author does not warn you not to use MS Office.)

I envision nifty GUI-Based tools which show you a timeline of a communication mesh importing Mailboxes and Mailserver logs. When we look at the rapid development of forensic tools this tools should come in near future. On the other hand the leagal profession seems to have not that many early adaptors. (See this).

BTW: If you do any form of timeline analysis on a computer first try to find out if the clocks of the computers in question are acurate, if not how much they differ from "real time" and how big their "screw" is to calculate back how much they differed some time ago. This might look like a minor issue but I have seen PCs drifting more than 30 minutes per month from "real time".
08:36 | #

Monday, 02. December 2002

Forensic skills bring hackers to justice

Most firms have strategies to prevent their systems being attacked, but they should also develop policies on what to do in the event of a security breach to preserve evidence and prosecute the culprits, according to experts.

The need for successful prosecutions to deter attacks is growing, say many security experts. The increasing threat is shown by the fact that for the first nine months of this year, almost 75,000 security breaches were reported to the security service Cert. This compares with about 52,000 for the whole of 2001 and fewer than 22,000 during 2000.

Laws are widely believed to lag behind advances in technology, but some firms do not report crimes because they lack usable evidence, thus making the job of the police all the more difficult. This is where good policies and digital forensics can help.

Preserving evidence

Security specialist @Stake has said many firms are not adequately prepared to deal with the aftermath of attacks. In many instances, firms believe they must choose between quickly getting systems up and running again or preserving digital evidence of attacks.

But firms can take steps to do both. Phil Huggins, @Stake's managing security architect, said the problem is that businesses are often unaware of what to do in the event of a breach, and this results in evidence being inadvertently deleted.

"Without adequate incident response, the investigation stage cannot take place," he said. "Or systems are put back in such a way that the digital forensic stage won't provide enough information to get to the root of the problem. The correct steps have to be taken so that the evidence is preserved. The more prepared an organisation is for an incident, the faster it can respond."

Companies therefore need to develop better strategies for dealing with attacks, in addition to their business continuity plans. These strategies should include steps to preserve evidence, and should stipulate the data that should be recorded before, during and after each attack to ensure a thorough investigation. [...] [Kill-HUP.com]
21:13 | #

Friday, 29. November 2002

Computer forensics specialists in demand as hacking grows

"There simply are not enough people to do this work," says Scott Pancoast, a Seattle-based certified forensic computer examiner with the Washington state Attorney General's Office. One of just 180 forensics investigators certified worldwide by the International Association of Computer Investigative Specialists, Pancoast is among the 15 to 20 computer forensics examiners who work in this state.

These "digital detectives" collect, preserve and analyze computer evidence according to careful style so that it can be criminally prosecuted.

Not only is demand for computer forensics investigators hot, but several labor forecasts predict a shortfall of nearly 50,000 within the IS security profession, too.

In police parlance, if computer forensics investigators are detectives, then IS security experts are the patrol cops who protect computers and network systems from high-tech safecrackers and vandals. Businesses, government and law-enforcement agencies all are "scrambling" for such workers, says Lake Washington Technical College dean Mike Potter. [LinuxSecurity.com]
11:10 | #

Challenge: How Did These Processes Get Here?

A cracker caused software to run at bootup, but the administrator couldn't figure out how. [Help Net Security]
09:23 | #

Monday, 25. November 2002

Forensic IT Trends Survey 2002

by Fox-IT

What are the trends in forensic IT reseach? Which tools are used? What are the objectives of a forensic IT investigation?

These questions are answered in this small survey. The goal was to find out if other forensic IT investigators worldwide saw the same increase in the number of forensic IT researches and used the same tools.

A total of 102 people took part in this survey about forensic IT investigation.

Download the paper in PDF format here. [Help Net Security]

Interesting findings: Most full-time forensic investigators are found in government. Favorite sources of information is sniffing network traffic and examining PDAs. Reasons for doing an investigation: hacked system, p0rn, fraud investigation, information theft, virus, harassment.

The commonly accepted trouth that most cybercrime gets unreported seems to be proofen once more:

"On most of the investigations no follow-up action is taken. More than half of the investigations do not lead to a trial or law suit. Just 24 percent of the investigations leads to civil law suit and just 23 percent to a criminal law suit."

Thursday, 21. November 2002

Computer Virus Families: Origins and Differences

Klez.F and Klez.I or Opaserv, Opaserv.D and Opaserv.H are just some examples of malicious code which due to common characteristics and roots are grouped into families by the antivirus industry. "The biggest families like I Love You or the veteran Marker can have as many as 60 variants," explains Luis Corrons, Virus Laboratory Director at Panda Software.

Sometimes a new variant of malicious code originates from another virus which has been modified. On other occasions, the authors of the virus create them using the basic features that define a family of viruses as a type of template. For this reason, some malicious code come in a series, behaving basically in the same way with only minimal differences such as the subject of the e-mail they arrive in or their ability to carry out certain actions, as the examples below illustrate:

Variants "I" and "F" of Klez: both are spread through e-mail and take advantage of the same vulnerability detected in the Internet Explorer navigator (corrected by Microsoft), which makes it possible to execute the attached file automatically when viewed in the Preview Pane. The versions differ in the following ways:

Klez.I is sent in an e-mail message with text and has two attached files. The objective of this malicious code is to stop certain processes and erase files in infected computers.

Klez.F: is sent in an e-mail with no text and includes only one attached file. It modifies some of the system controls (preventing the system from starting up correctly) and overwriting executable files, rendering them useless.

W32/Opaserv and W32/Opaserv.D are able to spread through networks and they attempt to access a web page to update some of their components. In order to infect, both worms create SCRSVR.EXE in the Windows directory, which contains their infection code. In addition W32/Opaserv.D generates the file TMP.INI in the root directory of the hard drive and enters an instruction in WIN.INI to activate the worm.

Opaserv.H is different in that the file that contains it comes in different sizes and is compressed with the PCShrink utility, which encrypts the code that causes the infection. The "J" variant of Opaserv has the ability to create various files in the infected computer. Among them "INSTIT.BAT", copies the worm that contains the infection code. "GUSTAV.SAT" and "INSTITU.VAT" are generated to exchange information with the web page they connect to.

I love you: variants differ, principally in the characteristics of the messages that are sent. The names of the attached files, the web pages they connect to and the file extensions which they affect, are all variable. The appearance within just a few hours of successive variants contributed greatly to their ability to spread.

Corrons also explained how, "Some variants still manage to spread, even though for some time now antivirus solutions have been available to detect and neutralize them." One example is the "I" variant of Klez, which appeared in April and still remains the most damaging malicious code affecting users over the past seven months, according to data collected by Panda ActiveScan. [Help Net Security]
14:04 | #

Wednesday, 20. November 2002

Deleted E-Mails: Tell It To The Judge

[...] f you work for a company that happens to find itself an unfortunate party to litigation proceedings, there's a good chance your seemingly confidential documents, including e-mails, will be poured over by teams of lawyers--and not just your lawyers, but the lawyers for the other parties as well. You need to know what to expect if this happens in order to avoid major embarrassment and heavy expenses.

What can an IT manager expect in a legal dispute? When a legal dispute hits your company, your company's lawyers will immediately seek information via a detailed questionnaire or interview about the hardware and software in use, backup cycles, media used, retention of media, handling of user accounts, ghosting of PCs, and archiving. You could also be asked to produce any documentation detailing the company's corporate policies relating to document retention and archiving. These documents can later be used to verify that the routine you have in place actually matches corporate policy. And it is not uncommon for IT managers to have to take the stand in court regarding their document management procedures.

Lawyers use this information to determine the probable volume and type of electronic files they will be dealing with. It also enables their technology support group to ensure that sufficient server space, software, PCs, and other resources are available for the lawyers to carry out the review in the timeframe set by the court.

Next, you will be asked to provide all electronic data for a specified period, probably going back several years, depending on the nature of the dispute. Data requested can also include information contained on backup media. What happens next depends on the resources available. Often, because companies have limited IT resources, and management isn't familiar with the process for determining what is and what is not relevant in the discovery process, electronic material is sent directly to the lawyers to sort out. Specialist technology groups within the law firms generally set up the systems required to review these files. These IT folk have expertise across a wide range of technologies, enabling them to determine the best way to restore and dissect the information for review. [...] [LinuxSecurity.com]
09:56 | #

Friday, 15. November 2002

Alien Autopsy: Reverse Engineering Win32 Trojans on Linux

[LinuxSecurity.com]
14:08 | #

Dot-Mil Hacker's Download Mistake

When Gary McKinnon -- the British hacker accused of infiltrating U.S. military computers -- downloaded a commercial remote-access program and used it to avoid detection, he may have led investigators right to his door. By Brian McWilliams. [Wired News]
13:51 | #

Unix auditor's practical handbook

[Kill-HUP.com]
12:32 | #

Thursday, 14. November 2002

Maintaining Credible IIS Log Files

This article will offer advice on how to maintain the credibility of IIS log files. [Help Net Security]
20:33 | #

Wednesday, 28. August 2002

Big Brother hiding inside cars' airbags - tells fibs (RISKS-22.21)

Monty Solomon (RISKS-22.21) drew our attention to the use of recorded information in airbag triggers for crash investigation. Notwithstanding the likelihood that extraction of such measurements doesn't constitute a legal measurement(*), such information extracted must be treated with extreme distrust because the operating environment is not trusted and has many potential modes of unpredictable and unforeseen behaviour.

The recording device isn't measuring road speed at all; rather, it relies not only on its own sensors, but also on information provided by other subsystems in the car. Road speed is most easily (cheaply) obtained by measuring the rate of revolutions of the final drive gearing in the transmission. That speed depends on the speed of rotation of the driving wheels and not the road speed.

One example where the indicated speed is nothing like the true road speed is when one or more drive wheels becomes airborne. Depending on the current driver demand and engine torque, a wide-open-throttle condition results in a very rapid acceleration of the airborne drive wheels, producing a "speed" as high as will be permitted by the engine management system.

How much data are stored is another question. If the recording is only of a second or less of the end to a crash, then it's difficult to establish the sanity of individual data points.

The records may be accurate, but how can you be sure that they reflect what happened in reality?

(*) e.g. http://www.nsc.gov.au/PAGES/Nms/nms_metrology.html

Bernd Felsche - Innovative Reckoning, Perth, Western Australia [Bernd Felsche via risks-digest Volume 22, Issue 22]
03:20 | #

Thursday, 22. August 2002

Big Brother hiding inside cars' airbags

On 11 Feb 2002 on Union Road in Trotwood, Ohio, a 1999 Pontiac Trans Am skidded sideways off the road, went airborne for 110 feet, and eventually hit a utility pole. An estimate of the car's speed was upgraded after examining an onboard electronic monitoring device in the airbag control mechanism, which pegged the speed at 124 mph (in a 40-mph zone). [Source:

• Dayton Daily News*, By Cathy Mong, cathy_mong@coxohio.com; PGN-ed] http://www.activedayton.com/ddn/local/0822car.html [Monty Solomon via risks-digest Volume 22, Issue 21]

Sunday, 21. July 2002

Forensic programming course outline

I am currently teaching forensic programming, at roughly the third-year college/university level, at BCIT, and the course will also be run in the fall and again in the spring. Since this is the first course of its kind (as far as I have been able to determine), and since most of the resources (somewhat by necessity) are online, I am beginning to put together the course outline and resources as a set of Web pages. This is not (so far) anything like a full online course: for one thing, I have not (so far) written out complete lecture notes. However, for those interested, the "table of contents" page is available at http://victoria.tc.ca/techrev/fptoc.htm or http://sun.soci.niu.edu/~rslade/fptoc.htm (and also http://cstbtech.bcit.ca/FP/index.html).

This is very much a work in progress, and will be updated and expanded frequently in the coming weeks.

rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade [Rob Slade via risks-digest Volume 22, Issue 16]
22:15 | #

Monday, 15. April 2002

REVIEW: "Handbook of Computer Crime Investigation", Eoghan Casey

BKCMCRIN.RVW 20020315

"Handbook of Computer Crime Investigation", Eoghan Casey, 2002, 0-12-163103-6
%E Eoghan Casey
%C 525 B Street, Suite 1900, San Diego, CA 92101-4495
%D 2002
%G 0-12-163103-6
%I Academic Press/Academic Press Professional/Harcourt Brace
%O U$39.95 800-321-5068 fax: 619-699-6380 dtrujillo@acad.com
%P 448 p.
%T "Handbook of Computer Crime Investigation"

This book is hard to read. Not because of excessive technical rigour or depth: quite the opposite. The work lacks focus and direction, and appears to be a compilation of components without an assembly diagram. It's the type of material that might result from the "war stories" told around a security seminar, after the core curriculum had been taken away.

Chapter one is entitled "Introduction," but, other than a statement that the book is supposed to be a resource for forensic examiners who may have to deal with computerized systems, there is almost no declaration of what the volume is about. The remaining material in the chapter, while it does have an obvious relation to the act of obtaining evidence from computers, does not have any clear structure. The points asserted are good advice, but appear to be relatively random thoughts. The text is neither readable nor lucid: in places it seems more like a parody of obfuscated academic papers. Chapter two is somewhat more understandable, offering an outline on how to prepare documentation for discovery. Unfortunately, while it does deal with some technical issues (original media is better than a bit-wise copy, which is better than a copy of a file), the material concentrates on lawyerly debates about what might be needed, and, after a great deal of verbiage, boils down to the recommendation to produce all possible documentation, but not too much. (Where the material does get technical it frequently goes too far, starting to deal with specific pieces of software, rather than concepts.)

Part one looks at tools in forensic computing. Unfortunately, to a greater or lesser extent, the four chapters each deal only with a single tool or vendor; EnCase, Cisco's NetFlow logs, Network Flight Recorder, and NTI.

Part two is entitled technology: it looks at operating systems, networks, and other system types. Chapter seven provides some details of the FAT (File Allocation Table) and NTFS (NT File System) structures, as well as print spool files. A miscellaneous collection of information about UNIX files is given in chapter eight. A similarly unstructured compilation is listed in chapter nine, which reviews network data. Wireless network analysis, in chapter ten, concentrates on cellular telephone systems, and really only throws out generic information about such setups. Chapter eleven's overview of embedded systems varies between a similar generality and unhelpful photographs of breadboarded circuits.

Part three provides three case studies. While interesting (parts of the third are especially amusing), they really don't provide much in the way of assistance to anyone having to perform investigations.

The authors and contributors seem to be much more involved in the law, and law enforcement, than in the technology of computer forensics. The book has no framework or structure within which to place the many details. Therefore, the material simply blends into a haze of trivia, rather than providing the promised handbook. For those seriously working in the field there are many helpful points of information, but organizing them is left as an exercise to the reader.

copyright Robert M. Slade, 2002 BKCMCRIN.RVW 20020315 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade [Rob Slade via risks-digest Volume 22, Issue 04]
15:35 | #

Tuesday, 26. March 2002

REVIEW: "Computer Forensics", Warren G. Kruse II/Jay G. Heiser

BKCMPFRN.RVW 20020221

"Computer Forensics", Warren G. Kruse II/Jay G. Heiser, 2001,
0-201-70719-5, U$39.99/C$59.95
%A Warren G. Kruse II wkruse@monmouth.com
%A Jay G. Heiser
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2002
%G 0-201-70719-5
%I Addison-Wesley Publishing Co.
%O U$39.99/C$59.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com
%P 392 p.
%T "Computer Forensics: Incident Response Essentials"

I'm still disappointed that authors seem to think computer forensics is limited to data recovery, but this work at least has utility value going for it.

Chapter one is a rough outline of data recovery, with an emphasis on documentation and the chain of evidence. Basic information about IP addressing, for the purpose of tracing intruders, is given in chapter two: it is useful and does not drown the reader in inconsequential details. (There is an oddly vitriolic dismissal of the story of the origin of the term for Packet INternet Groper.) A valuable discussion of e-mail headers, and a very terse outline of intrusion detection systems (IDS) are also included. Hard drive basics and concepts are given in chapter three. The material is generally good, but some points on imaging and connecting are passed over rather quickly. Chapter four has a reasonable high-level overview of encryption abstractions, but it is difficult to see the immediate relevance of the material to forensics. "Data Hiding," chapter five, contains some meandering topics that range from password cracking to NTFS (NT File System) streams to steganography. A few tools for dealing with these problems are listed. The description of hostile code, in chapter six, matches that of weeds in gardening: anything you don't want. It is, therefore, unsurprising to find that the content, while basically sound, is not particularly structured or helpful.

A list of software (and some hardware) tools are described in chapter seven. Chapter eight explains a number of points about the Windows operating system that might affect data recovery and forensics. (The material discussed is not, unfortunately, exhaustive, although it is very useful as far as it goes.) The introduction to UNIX, in chapter nine, is more structured and detailed, although it examines fewer specific tools. Chapter ten's general overview of an attack on a UNIX system is fairly standard, although there is a useful table of commonly compromised system utilities. A wide variety of tools and commands for collecting information from and about UNIX systems is given briefly in chapter eleven.

Chapter twelve is a short introduction to general concepts in the (US) law enforcement system. The last chapter is a rather abrupt finish to the book. There are seven appendices, the most useful of which is a handy point form overview of incident response activities.

Computer forensics books are starting to come out of the woodwork, and most offer such sage advice as "gather evidence" and "don't mess up the chain of custody." This book does tend to follow the same style and tone, but also has very valuable tips for practical work. It won't help you much in analysis, but it will help you become better at collecting data that will stand up in court.

copyright Robert M. Slade, 2002 BKCMPFRN.RVW 20020221
rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

[Rob Slade via risks-digest Volume 22, Issue 02]
15:45 | #

Wednesday, 21. November 2001

FBI targets suspects' PCs with spy virus

The FBI is working on software that could insert a computer virus into a suspect's computer capable of reading encrypted data. The software, known as "Magic Lantern," installs "keylogging" software that can capture keystrokes typed on a computer. The virus can be sent via e-mail. Once on the targeted PC, it waits for a suspect to launch the Pretty Good Privacy encryption program and then logs the passphrase used to start the program, essentially giving agents access to the keys needed to decrypt files. The Magic Lantern software is part of the FBI's "Enhanced Carnivore Project Plan," which operates under the umbrella project name of Cyber Knight. Electronic Privacy Information Center attorney David Sobel says privacy issues arise when keylogging results in "overly broad" searches, since it would be possible to observe every keystroke typed by the suspect, even if a court order specified only encryption keys. The FBI has already used a less-sophisticated version of the software to build the high-profile racketeering case against Nicodemo Scarfo, but had to manually turn the system on and off in order to comply with the court order. [MSNBC/Wall Street Journal 21 Nov 2001; NewsScan Daily, 21 November 2001] http://interactive.wsj.com/articles/SB10062942834030720.htm (sub req'd)

[Insertion by e-mail probably works well for Microsoft software, which is prone to that kind of attack. Various reports suggest that Magic Lantern can also plant itself by penetrating systems. Penetrability of supposedly secure systems has long been noted here, with further risks resulting from a weak system that is directly networked to supposedly more secure systems (especially if done with single-sign-on authentication). This may not be a case where one good (LAN-)turn deserves another. PGN] ["NewsScan" via risks-digest Volume 21, Issue 77]
00:00 | #

Friday, 17. August 2001

Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60)

The DMCA has also had effects on my forensic analysis products. Because the current copyright law makes anything that is put into tangible form copyright unless made otherwise by the author (or by law), things like criminal records are copyright.

This means that if the criminal tries to protect their material - for example by hiding it using steganography, encrypting it, or by putting it on a computer with a password to prevent unauthorized access - then that work is protected by the DMCA (after all, the password on Windows systems is effective protection unless you try to circumvent it).

Because the primary purpose of most of my forensic analysis tools is to reveal things that are protected from revelation, and because the DMCA makes it illegal to distribute such a device, I have been forced (based on the recent arrests and other threats against authors of such things) to withdraw my forensic products from the market.

I should note that companies like Access Data who sell products that are explicitly designed for undoing encryption, etc. are almost certainly in violation of the DMCA. While the FBI might not arrest them now because they sell to the FBI (and other in law enforcement - as did I), this does not mean that the FBI cannot arrest them at any time and charge them with a felony. Indeed, sale to law enforcement is not legal, even though law enforcement can, on its own, build and use such tools.

The effects on research and education are even more interesting. For example, I am having a discussion with my university now about canceling courses on forensics and cryptanalysis because in these courses we teach people how to get around protection of this sort and may provide the capabilities to do so in so teaching. The DMCA has, I believe, made this illegal - and if you are teaching such a course next semester, you might think about the issues as well. On the research side, I don't work on research I cannot publish, so I am canceling the aspects of my research that go into these areas.

Fred Cohen		Fred Cohen & Associates.........tel/fax:925-454-0171
fc@all.net		The University of New Haven.....http://www.unhca.com/
http://all.net/		Sandia National Laboratories....tel:925-294-2087