In this Issue:
>>WIPING OUT SENSITIVE DATA
Deleting files doesn't mean they're erased. Here's how to get rid of deleted files—for good.
Most computer users don't realize that deleting a file does not get rid of the file contents. Conventional file deletion merely drops entries for the file in the File Allocation Table (in a FAT filesystem), Master File Table (in NTFS), or similar index to allocated clusters. Clusters are marked as unallocated so they may be reused for the storage of data associated with new files in the future. To protect against unwanted disclosure of sensitive data, files must be wiped or erased rather than simply being deleted.
When a file is wiped, its contents are overwritten so that normal disk I/O and software calls are not sufficient to recover the file's data. Overwritten data is considered erased even when forensic data recovery techniques are able to detect residual recoverable data physically present on the storage device. When data recovery is a simple matter of executing software instructions to parse data structures starting with known file headers, the difference between a deleted file and an active one is little more than a limitation of perception caused by inadequate built-in data recovery features.
As programmers, it's our job to ensure that delete really means that data is gone, at least with respect to software that can control the data storage device through the normal I/O interface. Very sensitive information is supposed to be overwritten numerous times with random bit sequences, and a variety of techniques and algorithms have been defined and standardized for accomplishing thorough destruction of data. Two open source programs that are useful for permanently wiping data storage devices or highly sensitive files are Darik's Boot and Nuke (DBAN) and Eraser. They can be downloaded from SourceForge at the following URLs:
DBAN:
http://sourceforge.net/projects/dban/
Eraser:
http://sourceforge.net/projects/eraser/
In most cases, simply overwriting file contents with nonrandom data, such as streams of ones or zeros, is more than enough additional protection against software-based data recovery or forensic tools. The following .NET class illustrates a simple, quick and effective way to ensure that delete really means that a file can't be recovered using software alone. The class wipes a file by writing zeros in place of each byte of allocated space prior to calling the regular file-deletion API:
using System;
using System.IO;
namespace filewipeclass {
class main {
[STAThread]
static void Main(string[] args) {
FileWipe fw = new FileWipe();
fw.Wipe(args[0]); }}
class FileWipe {
// File.Delete method only drops FAT/MFT entry
// FileWipe destroys file data first.
public void Wipe(string sPath) {
FileInfo fi = new FileInfo(sPath);
try {
if(fi.Exists) {
FileStream fs = fi.OpenWrite();
for(int a = 0;a < fi.Length;a++) {
fs.WriteByte(0);
}
fs.Close();
}
fi.Delete();
}
catch(Exception e) {System.Console.WriteLine(e);}
}}}
There's no good reason to leave deleted data sitting on a data storage device just waiting to be recovered. Adding a predelete step to the file-erasing process is easy in any language, and only by wiping files that users believe they're deleting can we fulfill our obligation to users to provide them with software that does not offer a false sense of security.
Even data that may not seem sensitive to us often turns out to be very sensitive to our users. For instance, temporary files that are never seen by a normal user are often examined by forensic investigators who consider the mere existence of a file, deleted or not, to be conclusive proof that a particular person caused our software to perform some task at a particular time. Such circumstantial evidence of possible activity on a computer in the past can have significant security or legal implications for the computing public.
As a rule, if you care about producing secure software products that are safe to use, everything must be wiped rather than just deleted.
—Jason Coombs
This article originally appeared in the Dr. Dobb's Windows Security, April 21, 2005
>>TALES OF THE CYBERTERRORISTS
Wanna buy a continent? A new book tells you how. Also,
@Stake's SmartRisk lets you get down to binary.
We don't cover much outright fiction in New and Noteworthy (even if some of those press releases do get a little fervent from time to time). But I'm making an exception for Stealing the Network: How to Own a Continent (Syngress, 2004). It's a work of fiction, true, but with a "ripped from tomorrow's headlines twist: The authors-real-life crackers, terrorism experts and security consultants—have spun a fictional story of how bad guys (and gals) could take down a continent's infrastructure, but the technology and techniques are purportedly the real thing. With Kevin Mitnick as a technical reviewer, I'm inclined to believe them. The idea is to inform while entertaining—if the book succeeds, you'll put it down and rush to your digital ramparts, knowing how the bad guys plan to breach them.
In another interesting twist, the nine authors set up a Yahoo mailing list to facilitate its creation, and excerpts from the discussions are included as a "The Making Of ... appendix.
Stealing the Network: How to Own a Continent will set you back $49.95, which has got to be the cheapest deal for a continent since Ug and Moog picked up North America for two hand axes and a saber-tooth skin.
Speaking of Security
There's a lot to be said for tradition. When it comes to
application security, however, I'm fed up with the tried-
and-true method of waiting for crackers to break in and wreck
the place; for some reason, clients seem to get all soggy and
hard to light when their accounting department's PCs
transmogrify into an army of zombies and their website gets
a porn-o-mat makeover.
Fighting bad voodoo with good voodoo, @stake's SmartRisk Analyzer performs a static analysis on your C, C++ and Java applications that goes way deeper than your source code—it works on the binaries (even into the libraries you link against), referencing your source where possible. (How? Beats me.) The software maps the flow of control and data in your application, and uses that model to run risk analyses for many different vulnerabilities, such as the classic buffer overflow depicted in the screen shot. (Repeat after me: "strcpy ... Bad! strncpy ... Good! Redoing in a modern language ... Very, very good!)
The software provides a full set of reports to help developers and managers get a handle on what's going on under the hood, and, of course, it's extensible with new rules as needed. SmartRisk Analyzer runs on Windows; pricing starts at $40,000, supporting a development group of 20 people.
For more information contact @stake; 196 Broadway; Cambridge, MA 02139; Tel: (617) 621-3500; Fax: (617) 621-1738; www.atstake.com
This article originally appeared in New and Noteworthy, Software Development, Sept. 2004