A Day in the Life of...

Here's Simon Singh's take on the issue. He believes that it's a matter of trust and the fact that a lot of scientific findings go against conventional common sense, while Specter believes that people fear what they don't understand. Both dynamics are at work most likely.

Labels: fear versus reason pseudoscience science

I've been building a live DVD honeypot distro for the last month or so on a VMware virtual machine. It initially had a 20GB virtual hard drive that I thought would have enough space, but Ubuntu builds up cruft at a pretty rapid pace and before I knew it I was out of disk space. No problem thought I. I'll just resize the virtual disk file using vmware-vdiskmanager. That was the easy part. The not so easy part was resizing the ext4 filesystem on the newly resized virtual drive. I had backed up my build directory and moved it off the system as a gnuzipped tar archive. I didn't use the system for much of anything else, so I proceeded to remove the ext4 journal and resize the filesystem using resize2fs (a recent version) via a live DVD. Everything was still there, removed and recreated the resized partitions, and fsck -n /dev/sda1 checked out okay. I could still see the data in /media/drive when I checked, so I rebooted the system. When the live DVD finished rebooting, I checked the media directory and nothing was there. Checked the virtual drive; fsck -n /dev/sda1 stated that no superblock could be found. Then, as the sinking feeling took hold, I realized that I had overlooked backing up one other crucial file, my gnupg secring.gpg file I had recently created. If I had decrypted a certain email and stored the plain text away, it would have been no big deal. Or, if I had backed up the vmware virtual machine and played with a copy, it would have been trivial to recover, but I'd taken none of those, in hindsight, prudent measures.

Well, what to do. The easy way out would be to swallow my pride, rebuild the virtual machine, create a new secret key, and email the new public key to my correspondent and ask him to reencrypt the original message and resend it. The harder, but more educating, way out of the problem would be to recover the file. The data was likely still on the drive, the pointers to that data were likely gone or corrupted at best. I had nothing to lose by trying and I needed to hone my data recovery/ digital forensics skills. So, using dd and ssh via a script I wrote about six years ago, I created a bit by bit image of the virtual hard drive on another system. I loaded the image file into autopsy and the results weren't good. Autopsy would only be able to perform keyword searches on the image. The data layer really couldn't be seen or analyzed. I tried a few keyword searches, but it was futile. I called it a night at that point and went to bed.

The next morning, I decided the best approach would be to go with scalpel or some other data carver. Data carvers search for files using the file's header and footer information. Once the file is recovered, you just rename it to what you called it previously and you are good to go. Searching for "secring.gpg magic bytes, header, scalpel.conf" on Google led me nowhere. So, I generated two new public and private keys on my laptop and an Ubuntu virtual machine and compared their headers and footers. Each file had a slightly different header and footer.



I could tell you what I tried, but I'll give you the results. I created four new gpg entries in scalpel.conf, and two of them worked perfectly.

secring.gpg:

gpg with header "\x95\x03\xbe" and footer "\xb0\x02\x00\x00" --> 1 files

pubring.gpg:

gpg with header "\x99\x01\x0d" and footer "\xb0\x02\x00\x03" --> 3 files

As you can see above, I could have used a longer header sequence by appending \x04\x4c or \x04\x4c\xa2 to each header sequence. The longer the sequence, the fewer results one gets. This cuts down on false positives, but it may result in no files being recovered at all. One just has to do some experimental runs with scalpel to tune the scalpel.conf configuration file. In this case, I only wanted gpg files, so I commented out every entry except the newly created gpg entries. After making a copy of the image, I split the image into 10GB files with split, i.e.

split -b 10GB livecd

which results in three 9.3GB files called xaa, xab, xac, and a 2.1GB file called xad. Running scalpel on the 30GB file resulted in an estimated 28 hour second pass scan. Narrowing the search to just gpg files and scanning 9.3GB files resulted in a complete file carving (2 passes) within 20 minutes per 9.3GB file. The gpg files were recovered from the xaa subfile.

I rebuilt the corrupted virtual machine once I had the recovered files. I created a .gnupg directory within the user's home directory and copied the pubring.gpg and secring.gpg files into that directory. Using apt-get, you can install thunderbird and the enigmail xpi plugin seamlessly:

apt-get install thunderbird enigmail gnupg (if gnupg isn't installed).

You can test gnupg like so:

gpg --list-keys (for querying keys stored in the public keyring), and
gpg --list-secret-keys (for keys stored in the secret keyring).

Then you start thunderbird and give it your name, email address, and password. It's smart enough to set up your gmail server settings for you. You just give enigmail your secret key passphrase and you can decrypt any messages encrypted using your keys.

I could have searched for the pubring.gpg using my email address since it is embedded in the public key using grep:

grep -r "jmoore@gmail.com" /scalpelresults/

will search all of the carved files for that text expression. To eliminate carved emails, pipe the output to grep with the v option like so:

grep -r "jmoore@gmail.com" /scalpelresults/ | grep -v "To: John Moore" | grep -v "From:
John Moore" | grep -v "Return-Path"

but fortunately, just browsing for the 4 files listed in the audit.txt file worked, since scalpel placed them in their own subdirectories.

Labels: digital forensics data recovery gnupg scalpel headers footers

I would write about the Stuxnet worm which seems to be the first publicly known piece of military grade attackware, but Bruce Schneier and others have written extensively about it. Langner's blog and Geekheim.de have the most pieces of evidence for who did what to whom where. The Symantec Security Response blog has some very good technical breakdowns of the reverse engineering of specific parts of the worm. Air gapping the networks would not help because the worm was designed to defeat that barrier by using USB sticks which is a method originally used by floppy disk based worms in the days before PCs were connected to the Internet. Since our own DOD isn't smart enough to protect its own networks from USB worms, the likely American suspects are the CIA or NSA, probably the latter. But, the nation who had the best motive for doing this very cost effective attack was Israel. The Natanz ultracentrifuges were the likely target of this operation.

Update (10/01/2010): F-secure has a nice Stuxnet Questions and Answers post along with a video demonstration of what Stuxnet is capable of. Two pieces of internal evidence from the reverse engineering:

1. The path statement in the compiled code, \myrtus\src\objfre_w2k_x86\i386\guava.pdb, has the words myrtus and guava. Guavas are plants of the myrtle family. They are a type of pomegranate which serves as the Jewish symbols of righteousness and fruitfulness. Is Stuxnet a weapon of righteousness targeting the servants (machines) of the enemies of Israel? In this case, is the enemy, Iran? Are we dealing with a former biologist who is now a programmer, or with someone exposed to taxonomic nomenclature who could make an inside joke?

2. The registry key created called 19790509, which is the date, May 9, 1979, which was the date Habib Elghanian was executed in Iran as a spy on what appear to be completely false charges. His death led to the mass exodus of 100,000 Jews from Iran.

Here's The Register's analysis. Symantec has released the Steuxnet Whitepaper.

Labels: military grade specific targeted attackware

Here's a nice Symantec blog post about an attacker interacting with a high interaction honeypot.

Labels: IT Securty honeypot

The reason why aliens don't visit Earth often.

Labels: Monty comic strip aliens gardening

Yves Smith of Naked Capitalism was on the Keiser Report. Here's the excerpted interview.

Labels: Yves Smith Max Keiser Econned economics

I've been having to run VMware Workstation 6.5.4 on Linux kernel 2.6.30 because the modules will not compile on any higher kernel. VMware was offering a 30% discount on upgrades, so I thought I'd upgrade and see if the module compile problems had been fixed. Well, they hadn't. The errors occur in iommu:

CC [M] /tmp/vmware-root/modules/vmmon-only/linux/iommu.o
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: In function ‘IOMMU_SetupMMU’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:156: error: implicit declaration of function ‘iommu_map_range’
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: In function ‘IOMMUUnregisterDeviceInt’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:216: warning: ignoring return value of ‘device_attach’, declared with attribute warn_unused_result
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c: In function ‘IOMMU_VMCleanup’:
/tmp/vmware-root/modules/vmmon-only/linux/iommu.c:403: error: implicit declaration of function ‘iommu_unmap_range’
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/iommu.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.35-4.slh.11-aptosid-amd64'
make: *** [vmmon.ko] Error 2

I could have saved myself $70 since I got module compile issues, i.e. fatal make errors, for free with either 6.5.4 or 7.x. Fortunately, there is an easy fix documented at www.rrfx.net.

If you don't wish to visit the link, the fix by Robert Reid is documented below:

cd /tmp
tar xvf /usr/lib/vmware/modules/source/vmmon.tar -C /tmp
perl -pi -e 's,_range,,' vmmon-only/linux/iommu.c
tar cvf /usr/lib/vmware/modules/source/vmmon.tar vmmon-only

To get VMware Workstation 6.5.4 to work on kernel 2.6.32 or above on Ubuntu 10.04 LTS, you'll need to do two things, get the installer to bypass a hang condition and patch vnetUserListener.c and pgtbl.h by adding two include statements, #include "compat_sched.h" and #include "<"linux/sched.h">", to each file:

1. chmod u+x VMware-Workstation-6.5.*.bundle
./VMware-Workstation-6.5.*.bundle --ignore-errors

in a separate terminal run:

while true; do sudo killall -9 vmware-modconfig-console; sleep 1; done

Original documentation is here.

2. Patch vmci and vmnet documented here and here:

tar xvf /usr/lib/vmware/modules/source/vmnet.tar -C /tmp
tar xvf /usr/lib/vmware/modules/source/vmci.tar -C /tmp

cd /tmp

perl -pi -e 's,("vnetInt.h"),\1\n#include "compat_sched.h",' vmnet-only/vnetUserListener.c
perl -pi -e 's,("compat_sched.h"),\1\n#include "<"linux/sched.h">"",' vmnet-only/vnetUserListener.c
perl -pi -e 's,("compat_page.h"),\1\n#include "compat_sched.h",' vmci-only/include/pgtbl.h
perl -pi -e 's,("compat_sched.h"),\1\n#include "<"linux/sched.h">"",' vmci-only/include/pgtbl.h

tar cvf /usr/lib/vmware/modules/source/vmnet.tar /tmp/vmnet-only
tar cvf /usr/lib/vmware/modules/source/vmci.tar /tmp/vmci-only

note: "<" and ">" should just be < and >, but blogspot.com's servers make things like header files disappear in source code.

Now run vmware-modconfig --console --install-all to finish the VMware Workstation installation.

Labels: vmmon compilation failure VMware kernel 2.6.35

Economist Steve Keen says that the major economies are entering a debt deflationary spiral. The way out of it would be to increase workers' wages which would allow them to pay off their debts and create inflation. But, economic policy makers don't understand this, and therefore, it will be the last thing they do.



The entire show is called Global Debt Collapse

Dean Baker points out that economists are always quick to blame workers for the economy being depressed rather than the bad judgments of the economic policy makers themselves.

Before examining the argument here more closely, it is worth noting that arguments about rising structural unemployment come around during every recession. When the economy fails to produce jobs fast enough to bring down the unemployment rate economists quickly turn to blaming the workers. The problem is not that economists came up with bad policies; the problem is that workers don't have the right skills or live in the right place. This happened after each of the last four recessions.

Labels: bad American economic policies

The economy is not like the weather, not a natural phenomenon. People may complain about the weather, but there is little one can do about the weather other than enjoy it when it is nice, or seek shelter from it when it is less than nice. The economy is derived from people's individual and collective actions and commerce. Therefore, people control the economy either directly or indirectly. When an investment banker states that financial crises happen every 5-10 years, he's lying. Policymakers are supposed to regulate markets to prevent such man made disasters, and that is their function by law. When politicians say that there is nothing they can do to fix the economy, they are lying. All our politicians have done thus far is throw money at the problem of insolvent banks. They have not fixed the underlying problem which is that the banks are broke. They know that the government has the means and ability to put people back to work, help them stay fed, and keep them in their homes, but there is no political will to do so just like there was no political will to fix Wall Street. There is no political will to reign in defense spending, healthcare costs, drug costs, insurance costs, an unfair tax code full of loop holes, or lax trade policies that allow jobs to go overseas resulting in lost income, revenue, and taxes for American workers, businesses, and governments. There is no will to fix the economics profession as well which supplies the majority of advisors and policymakers to government and business. So Americans will still be receiving bad at best, and deceitful at worst, advice from a profession that is supposed to be able to predict economic trends and advise economic solutions to problems. Instead, many economists and politicians act and sound like TV weathermen. The few economists and other professionals who do recommend solutions are pretty much either marginalized, derided, ignored, or their ideas watered down to be effectively useless. This situation can not go on. Either the Middle Class collapses and we all join the ranks of the Poor, and the country collapses in a state of chaos, or we pull together and fix the nation, and lift all boats, not just the boats of the well connected and the wealthy.

If you think the GOP will come to the rescue this November, better think again. The GOP helped cause this mess. The GOP ran Congress from 1994-2006. They had control of the Executive Branch from 2000-2008, and the Judicial Branch from 2000 onwards. Most Federal Reserve governors are Republicans. Many administration officials are leftovers from the Bush Administration. The Democrats are not blameless, either, but they weren't a major contributor to the mess we are in. Unfortunately, the Democrats seem to be a party divided, and the Obama Administration is itself divided. The Democratic Party's solutions have been weak or ineffective at best. Jon Stewart sums the current situation up this way:"What the Democrats do, doesn't matter!"
When Treasury fights for Wall Street which means the regulators are effectively lobbying for those they are supposed to regulate, government is divided and at odds with itself, and likely compromised, if not corrupted.

Labels: observations and opinion