DDG Tech Notes

H D Morre has announced the release of Metasploit v 3.2 (http://www.metasploit.com/) - and a new license for the popular security testing framework.  According to the main web page:

The Metasploit development team is happy to announce the immediate availability of version 3.2 of the Metasploit Framework. This release is the first version of Metasploit to be provided under a true open source license (BSD) and represents over ten months of work by the development team.

Currently available from the web site are the distributions for the normal cast of OSes (Mac, Linux, etc.) plus a binary windows installer.

I’ve not yet seen any Debian or Ubuntu packages.  I’ll be putting some together myself and make them available here until such time as a maintained package becomes available (sorry, but I do not currently have the time to commit to this long term.)

This time, it is some college students that dared to attempt to present their research findings at Black Hat…

As picked up by ABC News:

A federal court order that prevented three MIT students from telling a hackers conference how they were able to break into Boston’s subway fare collection system has backfired.

Hmmm.  OK - that’s the major news organization’s headline.  But we have to be very careful in how we interpret anything put together by our major news organizations these days.  Really, you should go read their article before reading this post further.

Ok.  Now that you’ve read it…

…Have you really read it?

Looks like the real question here is, did they do their research without breaking any laws?  If so, case precedent would show that the students (specifically, Zack Anderson, “Rusty” Ryan, and the Italian Allessandro Chiesa) should have no direct legal threat from their opposition.  On the face of the text presented in the article alone, this is left somewhat ambiguous.  Consider the statement:

The injunction was meant to block discussion of how the students figured out how to evade the comuter system’s security to change a $1.25 fare card to a $100 fare card.

So which was it.  Did they figure out how to do it?  Or did they do it?  While the distinction may be subtle, it is still huge.  Figuring out how to do something is not a crime in and of itself.  However, if they figured out how to do it by actually doing it we’ve got an entirely different legal landscape.  Even more ambiguous, what if they did figure out how to do it by actually modifying their own card in some way?  Have they committed a crime?  What if they destroyed the card, without using it, after figuring out how?  Are they committing a crime by telling others how it could be done?  What if they tell how to do it, and encourage others to do the same thing and actually use them?

This is a steep, slippery slope.  And unfortunately it is on that any security researcher finds themselves traversing all of the time.  There are never clear-cut answers in our current legal environment where digital signals are continually shoe-horned into legal wording that treats them like physical property.

As an analogy to consider as a thought experiment, imagine an automobile manufacturer.  They may make two different models of cars, one with a top speed of 90 MPH, and one with a top speed of 160 MPH.

So what happens if I use my knowledge of cars to modify my purchased 90 MPH model.  I tweak on it, tune it, apply aftermarket parts until I figure out how to make it go 160 MPH.  Have I deprived the auto manufacturer of their legal claim to the price differential between the 90 and 160 MPH cars?

Like I said - it is a crude analogy.  Just think about it.

Or - if you are looking for a more direct analogy to consider, check out the original presentation materials - while you still can.

Every want to use your Ubuntu distribution to obliterate the data on a disk volume? It may be easier than you think!

First thing - the disclaimer. I’m very conscious about not misrepresenting myself to my blog aggregators regarding what my posts are actually about. On the other hand, after looking at my blog stats, search queries have turned up my site for searches roughly along the lines “Ubuntu Wipe Disk” at a rate that I did not expect. So why this disclaimer?

All of the methods that I am about to present are not really Ubuntu specific. However, as a good blogger, I have an obligation to provide information pertinent to what my readers are looking for.

Also note that any method below that deals with disk partitions can be used equally for swap partitions - arguably one of the most critical partitions to wipe on any system.

And, with the exception of the section below regarding specific disk eradication software, you can perform pretty much any of these steps even with a “Live” Linux CD - which can save you the hassle of physically connecting the hard drive to your Ubuntu machine.

So, here goes…

So, you want to wipe a disk so that no one else can read what you might have written there?

While that sounds like a fairly simple task, there are really some assumptions built into the question that you must consider first:

1. What exactly do you want to wipe? Is it an entire disk, or just a partition on the disk?
2. Who is the “no one” that you want to protect your data from?
3. Are you performing this action in response to your own needs, or the needs of you company or corporation?
4. If you are performing these actions for your company, are there any particular regulatory requirements that you must meet?

With out question framed properly, we can move forward with an actual plan to meet your requirements. Here goes:

What exactly do you want to wipe?

For most methods presented in this article, the what you want to wipe doesn’t really change the method used to wipe it, except for the parameters passed to the specific tools.

Identifying where to perform your wipe.

OK. So you’ve either booted up the target machine with a Live CD, or you’ve attached the drive to your current workstation. How do you know which device it is? Well, here’s a little background. Those of you familiar with Linux device names and identifying attached hard drives will probably want to skip ahead.

Any attached hard drive can be accessed, as if it were a normal file, under the /dev tree. Generally speaking (there are definitely some exceptions to this) IDE type drives follow the naming convention /dev/hdX - where X is a letter a, b, c etc., and other non-IDE type drives (including SCSI, SATA, etc.) are identified as /dev/sdX.

So, for example, the first detected IDE drive (IDE Disk 1 on channel 1 of the first controller) would be at /dev/hda, which the second would be at /dev/hdb.

Likewise, SCSI drives follow a similar patters. The first drive (or LUN, if it is an array) on the first channel of the first detected SCSI controller would be identified as /dev/sda, the second /dev/sdb, etc.

So what do I mean by “first detected”? This is (again, generally speaking) the order in which the kernel module drivers for the devices are loaded.

OK - so that’s how to identify the drive. What about partitions? Those are assigned to a different point under the /dev tree, with a numeric indicator of the partition number (in sequential order.) For example, the first partition of the first IDE drive will be /dev/hda1, and the second /dev/hda2. As you might expect, the partitions of the first SCSI drive would be /dev/sda1, /dev/sda2, etc.

However, things get a little more interesting if you involve the Logical Volume Manager.

I won’t go into the details of how the Logical Volume Manager (LVM) relates to partition numbers. If you are faced with this situation and don’t quite understand which partition means what, I’d actually recommend just wiping the entire disk.

Performing the wipe the quick-n-dirty way.

This method is not entirely secure (meaning a determined person could potentially recover data even after this) but it will protect you against all reasonable, common attempts to scavenge data from the drive.

The core of all of this stems from the fact that deletes on pretty much all file system types don’t actually delete. Generally, they overwrite pointers on the disk that point to were actual data resides. With the pointers gone, the operating system (Linux, Windows, whatever) has no idea of how to read the data.  But, the data is still physically on the disk, and can be retrieved almost trivially with a little knowledge and commonly available tools such as Foremost (ubuntu package: ‘foremost’ - Forensics application to recover data)

So, what we want to do is actually overwrite all of the old data. (Note: if you are going to wipe a disk or a partition using these methods, there is no benefit to deleting stuff prior to the operation. Save yourself some time)

Also, for the methods below, it really makes no difference what operating system created the data in the first place.  If you can get the drive attached to you machine (or access it booting with a Live CD) you can easily erase a Windows, Mac OS X, MS-DOS or whatever drive.

So, here we go.

If all you want to do is overwrite the data, then the simple command line tool ‘dd’ is your friend. dd stands for ‘Direct Dump’ and it does just that - directly dump data to a file. Only in this case, our “file” will be the device link to a disk or partition.

dd has kind of a funny syntax (funny in the UNIX or Linux world, at least) for specifying command line parameters. It is <param>=<value>. To start off, there are only two that we need to worry about. These are ‘if’ (for input file) and ‘of’ (for output file). So, let’s say we want to wipe the first partition of the first SCSI drive in our system. That’s easy! just use:

dd if=/dev/zero of=/dev/sda1

of=/dev/sda1 tells dd to write all data to /dev/sda1, or the first partition of the first SCSI drive.

if=/dev/zero may seem a little strange if you’ve never seen it before. The device /dev/zero is essentially a pseudo-device that dumps out a continual string of zeros. So, dd will continually read from it’s input file (if=) and write that same data to it’s output file (of=) until…

Well, basically, until it gets an error that the disk is full. Which is exactly what we want in this situation, a disk full of zero bit data, or a completely erased disk.

If you want to be a little cooler with your use of dd parameters, you can utilize the bs= and count= parameters.  bs= designates the block size, and count= is the number of bs chunks of data (i.e. the number of blocks) of data that will be written.  If you are not familiar with how to determine the block size and block count of your disk drive, I’d highly recommend just using the method described above.

So that erased my disk!  Great, what else could I have to worry about?

Well, that depends on either 1) how paranoid you are, or 2) what your application is.

For the really paranoid, always remember remnance!

So what the heck is remnance?  Basically, you can think of this as leftovers in the process of writing data to magnetic media.  At a very high level, writing to magnetic media is basically applying a magnetic field to a region of the media to change the “pole” or “charge” of that region.  For simplicity sake, think of the two poles of a magnet north (N) and south (S).  No imagine that all N regions represent a 0 (zero) and all S regions represent a 1.  You’ve got a simple formula for representing your binary data on your magnetic media.

Since this is a process of changing the magnetic orientation of a region of media, things can change over time.  Fluctuations in the space between the write head and the media due to heat variations, humidity, etc, as well as changes in the media itself over time can effect the way the media responds to this reorientation process.

Or, as another analogy, imagine that you are standing in front of a wall with a bunch of balloons filled with either red or green paint.  Assuming you can always throw the balloon at the exact spot on the wall, tiny differences in the wind at the time it is thrown or whatever will result in slightly different patterns splattered on the wall.  While the center of the region will always obviously be either red or green after each throw, there will be remnants of previous throws around the rim of where they hit.  And, if you threw a green balloon last time, and a red balloon this time, the outer area of the “splatter” will show more green than red.

This is basically what happens with your magnetic media.  Tiny tell-tale signs are left on the periphery of the regions that can give clues to data that was written there previously.  Processes - such as Magnetic Force Microscopy - can then be run on the media itself to lift this information from the disk and deduce - if not outright read - what was previously there.  In other words, simply overwriting your magnetic media with all zeros as above doesn’t completely remove all traces of the data on the disk!

Minimizing remnance via software

It is very important to note that, while software based methods can significantly reduce the possibility of data recovery using magnetic remnance, it can never completely eliminate it.  Again, this is one of those things where you have to consider what your requirements are.  Do we just want to make sure that no one can reasonable pull our tax return from our hard drive after we sell it on EBay?  If so, the software solution below is probably very reasonable.  Are you trying to eradicate data from the hard drive that has the super-secret pictures of the alien autopsy performed at Area 51?  Well, then, software won’t cut it (and you’re hopefully not looking for advice from my blog anyhow!)

The general idea behind a software based approach to addressing remnance is to not simple overwrite the data once, but to repeatedly ‘flip’ the bit.  That is, write all zeros to the disk, followed by all ones, followed again by all zeros.  By using this method, you can scramble the data available from remnance, and make it much harder for anyone to pull anything useful from the drive.  The more times you consecutively ‘flip’ the bit, the better off you are.

Unfortunately, there is no really easy way to stream a series of bits of ones the way that /dev/zero streams bits of zeros.  For that, you’ll need some other piece of software.

xFlip

One options is xFlip (more details and downloads are available on the xFlip page) written by yours truly.  With xFlip, you can choose any combination of:

• Overwrite the data with random bits
• Overwrite the data with all zeros
• Overwrite the data with all ones
• ‘Flip’ all bits to their opposite (technically, XOR each byte with 255)

And you can repeat any combination of these steps an arbitrary number of times.  Currently, I’ve not yet created a Ubuntu package for this - either it’s source or a binary form.  However, if you are reasonable comfortable with gcc or your favorite ANSI C compiler, the source code is pretty small and basic.  If there is enough demand, I’ll gladly put the time into packaging this for Hardy, for whatever platforms I can get my hands on.

xFlip has its limitations too, however.  For example, any sectors that have been marked as “bad” by the disk will not be touched, and could potentially leak data that was originally written to them.

Wipe

The Ubuntu package wipe (sudo apt-get install wipe, or via synaptic package manager) is primarily focused on removing individual files.  However, it will happily work with full disk devices or partitions by addressing them with the same /dev tree locations described in the ‘dd’ method above.  You’ll probably have to manually install it when using a Live CD, however.

Secure Deletion Toolkit

The Secure deletion toolkit (Ubuntu package secure-delete) is another tool primarily targeting specific files.  Again, you’ll not likely find it on most Live CD distributions.

Actually, it is a collection of tools, including:

• srm - Effectively wiping all of the data from a file, instead of just removing the pointers
• sfill - fills (scrambles) all of the free space on a drive.  This will obfuscate any data left laying around from files previously deleted on your disk.
• smem - wipes data from memory in a secure way.  This may seem silly, until you consider the proliferation of solid state memory devices
• sswap - Wiping swap space.

It may seem odd, but if this is your toolkit of choice, sswap can actually be used to successfully eradicate the data (with the limitation describe above) from a hard disk or partition.  It’s kind of a hack, but here is the idea:

First, identify your target drive as describe in the ‘dd’ method above.  Then, after mounting the drive on your Ubuntu system, or operating off of a live CD, first initialize the disk or partition as swap space (however, see notes below.)  For, say, the first IDE drive, you would use the command:

mkswap /dev/hda

Similarly, the first partition on the second SCSI disk would be:

mkswap /dev/sda1

In fact, the mkswap command may not be necessary.  This is not my preferred method or software, so I haven’t tried it without the mkswap command.

Then, simply:

sswap {device}

and replace {device} with the /dev path to you hard drive or partition, and you’re good to go.

Further Methods

The only other options for data destruction above and beyond this are all physical based methods.  Obviously physical methods can not be accomplished from your workstation, but I include them for completeness:

• Passing the physical disk through a very strong magnetic field.  This is referred to as degaussing.
• Incineration.  But, you better make it really really hot.
• Shredding.  Even more important than with paper, though (due to the small ‘region’ size on high density hard drives) the size of the chunks coming out of a disk shredder are extremely important.

You’ll find a multitude of commercial services offering any of the above.  If you work for an organization that is serious about data destruction, but wants to keep it in-house for policy, compliance, or other reasons, commercial degaussers are probably the best bet.

So there ya have it!

In truth, if you are just the average person, the ‘dd’ method described above will likely be plenty for protecting the normal user data from any reasonable attempt to extract it.  It doesn’t take much more to go the next step and use a tool like xFlip, wipe, or sswap to eradicate the data in a way that would protect you from all but the most determined and money-rich government, investigative agency of contracted digital forensics firm.

The fingerprint reader on my IBM X41 Laptop (now running Ubuntu 8.04 LTS Desktop Edition) has been staring at me from between my palms for years now. Time to finally get that sucka working…
First off, I’m not generally a big fan of “package managed” distributions - at least not on my own, personal experimental laptop. However, the extremely light weight (about 3 lbs or 1.5 kg, according to Lenovo), coupled with it’s durable titanium frame made it a perfect candidate for my travel computer. I chose Ubuntu as my distro of choice in this capacity.

So, starting down the road of info gathering, lsusb showed me this:

ross@peloton:~$ lsusb
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
Bus 003 Device 002: ID 0a5c:201e Broadcom Corp.
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 004: ID 1199:0120 Sierra Wireless, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
ross@peloton:~$ 

Cool. It’s a USB device.

As I’m intentionally trying to stick to the packaging system in use on this system. Trying to track down dependencies in my compiled-from-source software is one thing. Trying to track down how my compiled-from-source software broke some pre-compiled package installed in a way I didn’t realize is quite another.

So, I skipped the RTFG step (that’s ‘G’ for Google) and went straight to Synaptic Package Manager, and threw in a quick search for ‘fingerprint’. I ended up installing the following packages. Hopefully, by the end of this article, I’ll trim this list down:

libpam-thinkfinger
libthinkfinger0
libthinkginger-doc just in case
thinkfinger-tools
nmap

OK. So nmap has nothing to do with the fingerprint reader. But, it happened to turn up in my search results, and I know I’ll need it later, so I picked it to!

The details of the packages lead me to check out the binary tf-tool:

ross@peloton:/proc$ which tf-tool
/usr/sbin/tf-tool
ross@peloton:/proc$ tf-tool --help

ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>

Usage: tf-tool [--acquire | --verify] [--verbose] [bir_file]
  where --verbose and bir_file are optional.

  --verbose defaults to unspecified
    bir_file defaults to ~/.thinkfinger.bir.

ross@peloton:/proc$ 

Not so helpful in my opinion. However, ‘man tf-tool’ was helpful, check it out. Let’s give it a test run:

ross@peloton:/proc$ sudo tf-tool --acquire

ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>

Initializing... done.
Please swipe your finger (successful swipes 3/3, failed swipes: 1)... done.
Storing data (/home/ross/.thinkfinger.bir)... done.
ross@peloton:/proc$

Note that I ran it under sudo (my standard user account is not yet able to access the USB device) but it keyed off of my real UID, and stored the output in my home directory (/home/ross instead of /root). Cool.

And then see if we can match it:

ross@peloton:/proc$ sudo tf-tool --verify

ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>

Initializing... done.
Please swipe your finger (successful swipes 1/1, failed swipes: 0)... done.
Result: Fingerprint does match.
ross@peloton:/proc$

And what happens if I swipe a different finger?

ross@peloton:/proc$ sudo tf-tool --verify

ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>

Initializing... done.
Please swipe your finger (successful swipes 1/1, failed swipes: 0)... done.
Result: Fingerprint does *not* match.
ross@peloton:/proc$

So far, all looks promising.

The man page for lib_thinkfinger indicates that you need a specific device at a specific path in the dev tree, provided by the module ‘uinput.’ Looks like Ubuntu already took care of all of that for me:

ross@peloton:~$ lsmod | grep uinput
uinput                 10240  1
ross@peloton:~$ ls -al /dev/input/uinput
crw-rw----+ 1 root root 10, 223 2008-05-13 20:50 /dev/input/uinput
ross@peloton:~$

Could I possible be ready to use this for authentication? Oh - wait, the pam configuration. Going back on my past pam experience, I take a stab at it by adding a line for the pam_thinkfinger module (already installed in /lib/security by the package) to the file /etc/pam.d/common-auth. This makes my final file (along with the Ubuntu installed default comments) as:

ross@peloton:/lib/security$ sudo cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
auth	sufficient	pam_thinkfinger.so
auth	requisite	pam_unix.so nullok_secure
auth	optional	pam_smbpass.so migrate

Now for the test run. Let’s try something simple like an ’su’ to my own user:

ross@peloton:/lib/security$ su - ross
Password or swipe finger:
ross@peloton:~$ 

“Password or swipe finger:” Wow. Very good sign. And it worked!

But wait - the manpage for lib_thinkfinger clearly said that I needed to copy my fingerprint data file into /etc/pam_thingfinger - but I didn’t. Turns out it’ll also look for the file .thinkfinger.bir in the user’s home directory. This just happens to be the file that tf-tool created by default with the –acquire we did above.

Of course, this is only the print for a single finger. I’ve yet to test out if I can authenticate by storing multiple files in /etc/pam_thinkfinger. But for now all is good.

And the final confirmation is when I saw the “…or swipe finger” text displayed at the password prompt of gdm when I logged into my gnome desktop. Ahh how sweet to simply swipe my finger. Who needs stinkin passwords!

As you can see, setting this up was super simple and straightforward. Let me know what does and does not work for you in these steps.

It is important to note, however, that all of this works only within the context of the operating system.  The above still does not enable fingerprints to be used in the BIOS controlled hard disk access password, or administrator password for accessing the system BIOS config.  Hopefully, I’ll get time to work out how to use the stored fingerprint data in those areas.  Until then …

…happy finger swiping

Rochester Institute of Technology sent out an email indicating that there internet traffic was hijacked. Good thing they reassured everyone that everything was OK…..
Here’s the text of the email that was sent out:

To: RIT Community
Subject: Internet disruption

At approximately 5:45 a.m. today, RIT lost its connection to theInternet for about 90 minutes. During that time, all in-boundInternet traffic was being diverted to an overseas location. We areinvestigating whether this was a malicious act. We have discoveredthis Internet disruption also occurred at four other colleges anduniversities.

Any e-mail sent to you during this time period may have been lost. Wedo not believe any Institute information was compromised.

As a precaution, we are only going to allow access to the Oracleapplications from on-campus locations until we have furtherinformation about this incident. If you have further questions on thismatter, please contact the ITS HelpDesk at 585-555-5555 or via e-mailat helpdesk@rit.edu.
———- End Message

All I can say is I challenge you to read this closely - then draw your own conclusions about the liklihood that the statement “We do not believe any Institute information was compromised.“

Rochester Institute of Technology is at www.rit.edu

Yet another tape lost with consumer information… But this time from Iron Mountain?
Taken from The SANS Institute newsletter:

3. Security Screw-Up of the Month
Data Lost on 650,000 Credit Card Holders. Personal information on about 650,000 customers of J.C. Penney and up to 100 or more other retailers could be compromised after a computer tape went missing. GE Money, which handles credit card operations for J.C. Penney and many other retailers, said that the missing information includes Social Security numbers for about 150,000 people. The information was on a backup computer tape that was discovered missing last October. It was being stored at a warehouse run by Iron Mountain Inc., a data storage company, and was never checked out, but can’t be found either, said Richard C. Jones, a spokesman for GE Money, part of General Electric Capital Corp. Jones said there was “no indication of theft or anything of that sort,” and no evidence of fraudulent activity on the accounts involved.
More information:
http://ap.google.com/article/ALeqM5iZchJDcVnuQDNPJsok2PSPr5vwRQD8U808VO0
http://www.news.com/Credit-issuer-says-data-lost-for-650%2C000-customers/2100-1029_3-6226913.html?tag=cd.top

So you think you’ve done the right thing, contracted with the reputable service provider, and you still find yourself with the same headlines as the jokers that transported their backup tapes in backpacks in the back seat of the sys admin’s car.

Umm - ever hear of encryption?

To subscribe to the newsletter that I got this excerpt from, see https://www.sans.org/newsletters/ouch

imbee.com smacked by government agencies for its inappropriate handling of private information for minors.
Industrious Kids, Inc - the operators of imbee.com - were cited for inappropriate handling of the private information of minors as outlined in Child Online Privacy Protection Act (COPPA). According to the official Federal Trade Comission Report:

…imbee enabled more than 10,500 children to create imbee accounts by submitting their first and last names, dates of birth, personal e-mail addresses, parents’ e-mail addresses, gender, user-names and passwords prior to the site’s providing notice to parents or obtaining their consent