Dailies
- Caoine
- Echoica
- Jina Bolton
- Lifehacker
- Overclockers Australia
- RiskAnalys.is
- Rory.Blog
- Schneier on Security
- Security Catalyst Community
- Security Ripcord
- Securosis.com
- Slashdot
- Whirlpool
Photos
Categories
- Books
- Computers
- Family
- Forensics
- General
- GTD
- Movies
- Music
- Profession
- Security
- University and Studies
- Web Development
Monthly archives
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- December 2006
- June 2006
- May 2006
- April 2006
- March 2006
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- February 2005
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
- January 2004
- December 2003
- November 2003
- October 2003
- September 2003
- August 2003
- July 2003
- June 2003
- May 2003
- April 2003
- March 2003
- February 2003
- January 2003
- December 2002
- November 2002
- October 2002
Search
When Security Tools Go Bad
Noticed on milworm today PoC buffer overflows for both OllyDBG and ImpREC. This reminded me of a post I wrote last year about some vulnerabilities that were discovered in EnCase and the Sleuth Kit. These sorts of issues do get me thinking about how much, and how effectively, we verify the validity of the security tools we use.
At a forensic acquisition training course I attended recently, one of the items discussed was assuring and validating that the tools you use do not compromise the information you are acquiring. This is particularly important for chain of custody and tamper-proofing. You don’t want to use a particular piece of software, which claims to access a storage media without making any changes to it, only to discover that it has made minute changes. Or that a hardware device designed to prevent data being written to a hard-drive actually makes small changes to the drive itself.
This same principle applies to tools used for malware reverse engineering or software validation. You don’t want to find that the tools you’re using to try and determine if software is malicious, are exploitable by DLLs able to run foreign executables. If you aren’t careful with your testing environments, you may un-expectantly expose it to malware (in the bad way, not in the way that is controlled). This isn’t much of a problem if you run your reverse engineering tools in a virtualised environment, but if you don’t then you might find that you’ll have to spend some time rolling back or re-installing everything.
Being pragmatic of course, I don’t think anyone would expect you to be able to find the sorts of vulnerabilities as was found in this PoC. But sure, you’ll have to show some degree of rigour in validating your tools. Most of the time it will be sufficient to check for any current or previous vulnerabilities on security sites such as securityfocus, sans, securitytracker or milworm. Perhaps rigour around also means that you maintain an up-to-date tools list, including your licensing and version information. Perhaps you utilise Secunia’s software to ensure that all software is current.
I’m unsure how other people perform this process, or even if it’s necessary. Perhaps it’s only necessary in the forensic space. I’m not entirely sure. I’ve posted the question on the Security Catalyst Community so hopefully I’ll find out what other people think.
Posted by Christian
Posted in: Computers, Forensics, Security
No Comments »
9 July 2008
Forensic Acquisition Training
I was fortunate enough to attend a two-day crash course on forensic image acquisition last week. The trainer was Phillip Russo from CIA Solutions, whilst a local Perth boy he spends a huge amount of his time running training elsewhere around the world. The course covered the basics of forensic acquisition, traditional investigation skills and computer crime, integrity tools (hashing), checklists, chain of custody, to shutdown or not shutdown, dead versus live forensics, media types, write blockers (software versus hardware), imaging and image types, and a summary of tools.
One of the highlights for me personally was having an opportunity to discuss more of the court room and legal aspects of presenting evidence, as Phillip had a history of presenting in court in a number of different contexts. I think it was through his experience that he had methods of dissecting fairly difficult concepts, so much so that I imagine even the mums and dads out there could understand. A good example is the concept of file slack. Whilst I may have a fairly good understanding of what file slack is, trying to explain this to people who don’t have any history or experience with computer forensics, even savvy IT people, can be a fairly daunting task. Combine this with trying to explain how hard drives, partitions and file systems work and you certainly have a fairly large task in front of you.
Another highlight was the opportunity, not only to get hands on with hardware write blockers and AccessData’s FTK Imager, but also to combine this with real life scenarios and the process of documentation. Due to studying computer forensics at University I was fairly comfortable with the technical process of data acquisition, but combining this with the realistic process of documenting the acquisition, including chain of custody forms, was quite interesting and surprisingly difficult to do effectively.
The question was raised, whether or not if all the forms were transitioned into digital form, whether that would still be admissible in court. Whilst the concept could not be completely discounted, the fact that such records are not ‘tangible’ seemed to be quite an important factor for court room presentation. Judges and juries seem to have a better grasp of concepts when they can see the evidence in front of them. This certainly made sense to me, and obviously relates quite closely with the KISS principle. I think this also makes sense for this type of environment, probably more so than applying it to web application development for example, as you are already bombarding people with foreign and complex concepts, let alone trying to explain to them the principles of digital signatures of your ‘running sheet’, as opposed to your hand written notes.
Overall a worthwhile 2 days, and whilst it whetted my appetite for further training in forensic analysis, I’ll just have to leave that for another day.
Posted by Christian
Posted in: Computers, Forensics, Profession, Security
1 Comment »
6 May 2008
Don’s Windows Incident Response Script
Just had a quick play with Don’s Windows Incident Response Script and am very happy that someone else has put in the time and effort for something as useful as this, and then provided it for all. Some of the useful information it captures includes:
- User Account Information - Account name, Full name, SID, LocalAccount
- System Information - Hostname, manufacturer, OS Type, version, SP etc
- PreFetch File Information (this is AWESOME) - the metadata of about the last 128 programs that were executed
- Installed Software
- Windows Setup Log
- USBSTOR Registry Key
- Windows Firewall Exception List
- Log On and Off Events (if auditing is turned on of course)
- Event Logs
- Temp Internet Information
- Running Processes
- Active Network Connections (ahh netstat)
- Anti-malware logs (dependant on your AV vendor)
So yeah, go check it out.
Posted by Christian
Posted in: Computers, Forensics, Security
No Comments »
19 April 2008