Sanitize computer after Homeland Security seizure [closed]

Question

I flew from overseas back to the USA and all my electronic equipment was seized by Homeland Security, including my laptop computer, external hard drives, flash drives, etc.

After more than a month I have finally gotten my stuff back. I have 2 questions:

1. Is it known whether Homeland Security has ever planted spyware, viruses, tracking devices, etc. on seized computers?

2. What should I look for, what steps should I take to sanitize my stuff, what would you do?

EDIT: I can't reformat, burn hard drive, etc. as some have suggested because very important work is on the laptop, i.e. software I've been working on for over a year.

Yes, I had backups of all my data. Unfortunately, the backups were all with me, and they seized all of those too (2 external hard drives, 3 usb flash drives). So merely utilizing backups isn't an option.

Also, someone said people can't help me without breaking laws. I am unaware of any laws which state it is illegal to remove spyware/malware/viruses, or that it is illegal to remove anything the government put on your computer.

EDIT: I guess I could rephrase the question as "how would you go about getting source code you had written (text files) off the computer safely, 'safely' meaning scanning text files to detect anything unusual, and then transmitting or somehow putting them on another computer?"

Answer 1

Given that your laptop was in possession of a government entity with unknown intentions towards you for an extended duration, there's really no way you can restore it to a fully trustworthy state.

If you assume the U.S. DHS to be hostile, then the only secure process to move forward with includes:

1. Assume all data on the laptop, and all other confiscated hardware, to be compromised.
   • Change all passwords for accounts which may have been stored/cached on the devices.
   • Change all passwords for other accounts which use the same password as the accounts which may have been stored/cached on the devices.
   • Void all payment mechanisms which may have been stored/cached on the devices.
   • Communicate appropriate privacy warnings to potentially-affected third parties.
2. Assume the laptop, and all other confiscated hardware, was modified to allow future collection of data, or control of the system, by U.S. DHS or related agencies.
   • Destroy the devices. Do not capture any backup images or copy any files. Just burn/shred/pulverize/crush them as-is.
   • Purchase replacement hardware/software from a trusted source, through a trustworthy supply chain, and re-build from scratch.
   • If trustworthy backups exist (backups which were not also confiscated, and would not be remotely accessible with credentials that may have been stored/cached on confiscated devices), restore data from those sources as needed.

Anything short of this leaves open several extremely undesirable possibilities:

1. U.S. DHS may continue to have access to your online accounts and/or financial resources.
2. One or more of your devices may have persistent malware which allows U.S. DHS, or related agencies, to spy on you or control your systems. And you're back to #1.
3. Files stored on one of your devices may have malware which will install itself upon opening. Then see #2.
4. Hardware or firmware on one of your devices may have been modified to include malware, which may install itself upon connection to another device. See #2 again.
5. Any software projects you were working on, and/or the tools you use to compile them, may have been modified to include malware. Back to #2 again, and also add further impact to your customers if it's not discovered and dealt with before distribution.

You should check out the 10 Immutable Laws of Security. Law #3 certainly applies. Assuming they've exploited that law, you can probably bet Laws #1 & #2 also apply.

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

Also check out the 10 Immutable Laws of Security Administration. Here, Law #4 is most apropos.

Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with

Answer 2

This is a great question.

Basically, once a device has been seized by an adversary with the level of sophistication as a nation-state, especially the United States, that device and all data contained cannot be trusted. The only safe approach is to not trust that device and destroy it.

The Snowden leaks have exposed the various methods in which the American government can compromise computers. This includes installing hardware bugs in the keyboard itself, the GPU, or other components that make the computer fully rooted and compromised even if an O/S is reinstalled. They have also installed radio transmitters to defeat "air-gapped" computers that never connect to the internet by exfiltrating data via hidden radio. Jacob Appelbaum's talk on the subject is very informative: I highly suggest watching this video as he details the various devices the government is known to use. A wikipedia summary is also available.

Now, it is possible the Homeland Security agents didn't plant any of these devices and do not have the same capabilities as the NSA. However, that cannot be ruled out.

While you may be able to retrieve some data from the hard drive by taking it out and putting it into a USB enclosure/using a SATA to USB cable, this has risks. I would use a throw-away, single-use computer for reading the drive..as the drive's firmware or controller may have had malware installed in it that will try to infect any computer it's plugged into.

To counteract this, I would recommend purchasing a forensic hardware duplicator device (known as a write-block duper). Then, plug the SATA drive from your computer into it and clone it to another disk. Then, copy the files from that cloned disk to another computer. That should prevent firmware-based compromise.

However..you can't be guaranteed some type of worm, etc hasn't been planted in the files themselves. By copying to multiple devices, and not using the device you originally used to plug in the hard drive to, you minimize your chances of prolonged compromise; but there's still a chance something is awry with the files. AntiVirus etc won't help against sophisticated attacks like this.

That's why the computer can no longer be trusted. You can take steps like the hardware duplicator to help minimize the possibility of issues however.

Also this story might be of note: http://www.wired.com/2010/11/hacker-border-search/ .. famous hacker gets his computer inspected at border by DHS, and his conclusion was one I believe that's very valid:

“I can’t trust any of these devices now,” says Marlinspike, who prefers not to divulge his legal name. “They could have modified the hardware or installed new keyboard firmware.”

Answer 3

Depending on your level of paranoia about this and the amount of your code, at the extreme you can move to a LOW-TECH method to circumvent anything that has been done.
Buy a cheap printer. Connect it to your laptop. Print out your source code as reams and reams of text. Print out any graphics, layouts etc. Print out any needed user settings. Destroy the laptop and printer.

Of course you now have to re-input all of your source code, re-create your graphics and so on, but you don't have to actually re-invent any of the IP and there is NO electronic connection for anyone to track.

Answer 4

1) So there's no way of knowing they haven't. I feel like that's a bit above their paygrade (and would they have the time to?). It depends on your paranoia level. If your thoughts flow like a tranquil stream after the first spring day, then copy the data to a new machine and move on with life. If you wonder if the dogs howling in your thoughts are messengers for the prince of darkness, burn everything in a thermite-fueled bonfire.

2) For me personally, I would destroy the equipment, weep on its grave, and move on. With backups that aren't physically on me. However, most of the data I keep on my machines either lives in the cloud, or is replaceable.

If this work is truly priceless, an audit is in order. First off, take the drive out of the laptop and plug it into an isolated environment -- new computer with no network. A handy-dandy Linux Live CD is great for this. Mount the drive in question, and look through the files -- do you see anything odd? Is anything missing? Any strange windows files? Using Clam AV is also a good choice. Are there any new files you don't recognize? Delete them.

I'd also do the copy over in small pieces while in the Linux Live CD. Unless they're sophisticated enough to put Windows and Linux malware on there, you'd prevent any surveillance programs from autoplaying and finding a new home. I cannot stress this enough -- know what you are copying. Check your project -- Any new additions you don't remember?

After that, use a clean Windows environment and be on the watch for any suspicious activity. Build a good security policy, and next time encrypt your drives! Oh, and toss everything once you've recovered the data. Firmware attacks are real.

Answer 5

As others have pointed out, for the source code you need do more than just copy it out safely - you need to be able to detect tampering. And for that you need to do a substantial code review.

If the code is highly complex, or you don't know enough about it to adequately do so, you do have another option: crowdsource your review. Just publish the code as open source, and invite people to find the implant. I imagine some people would relish the challenge.

Answer 6

1. Get another (trusted) computer.
2. Get two USB/serial adapters, and a null modem cable (to connect them). It's unlikely that your trusted computer is remotely exploitable over a serial connection. Connect one adapter to each computer.
3. On the trusted computer, run cat /dev/ttyS0 > hd.img. (Your serial adapter might not be /dev/ttyS0; you might want to check this somehow)
4. Connect the two computers.
5. On the untrusted computer, run cat /dev/sda > /dev/ttyS0 (or whichever hard drive you want to image, and whatever the serial adapter is called on that computer)
   (If that computer isn't running Linux already, then use a Live CD or a throwaway Live USB)
6. When this finishes, ctrl-C the trusted computer's cat process (since it will keep waiting for more data).

(If you have more drives you want to image, attach them to the untrustworthy computer and repeat the procedure)

You now should have a hard-drive image, and you obtained it without making your trusted computer vulnerable. As the contents of the image are untrustworthy, do not boot it in a virtual machine.

You could open it with a hex editor and try to search for the data you want, but it will take you forever to piece together the files.

Instead, write a program (in a memory-safe language such as Java or Python) to parse the filesystem's data structures and extract the files you want. Make sure to review each extracted file in a hex editor before using it for anything else, in case it's been tampered with. (Don't even use cat. xxd is fine as long as it's not set to display ASCII characters)

Destroy the untrustworthy computer and devices (including any Live USBs you used on that computer); you don't know they haven't added any tracking devices. They have (probably) done that in the past, so this concern is not unjustified.

Answer 7

I've never faced this scenario; however from what I know the reverse cleanup procedure works. Boot external media and carefully copy your work files out one by one, auditing them as you go. Then reformat.

Be glad that up-to-date systems do not have attacks via text or image files (at least known ones). If mysterious processes do appear, submit your work files for malware analysis. If you got any, the DHS will regret having targeted you and wasted their most sophisticated malware on a low-priority target.

Answer 8

For future reference, both for yourself and others, I would recommend performing a full SHA256 hashing of all files on the computer, and of the firmware, before and after such a trip. Be sure to leave the SHA1 hash list at home.

I would also recommend that for trips out of country that you take an older laptop that you've erased and given a fresh install of your OS of choice prior to the trip. Take only the files you need. Smaller files should be cloud hosted or remotely accessed. Larger files should be encrypted individually and given innocuous names and nonstandard file extensions that don't reveal their purpose.

Prior to returning, you should remove any files that you don't want the Customs agents accessing.

At the very least, these steps will narrow down your focus for determining what files might have been added/modified/deleted.

Answer 9

As stated in other answers, there could be spyware in the BIOS or otherwise hidden in modified hardware. (For example, in theory, one can imagine a complex attack where a processor is replaced by a chip that emulates the original processor but also does additional things for spying purposes.)

To be absolutely sure that you had removed any such spyware would require expertise in the electronics, and even then, the time to do so might be worth more than the value of the hardware.

However, recovering data (not executable code), especially plain text, from it is possible, provided that you never run code that came - directly or indirectly - from the compromised machine (including any files directly written by hardware from the compromised laptop). That means:

1. You can't use the laptop itself to copy the data.
2. You can't recover compiled code (assuming that you aren't going to disassemble and read it all thoroughly).
3. Any source code that you recover must be manually inspected. If it's your own code, checking for added spyware should be feasible, but time-consuming.
4. The above two points apply to any document types that can include macros or scripts (e.g. Microsoft Word and Excel documents).
5. You could recover document types that support macros by using trusted software to check for and remove the macros.

You would connect the hard disc to a new machine, to copy from it, and discard it afterwards.

There is still the risk of buffer overrun attacks in documents, targeting a particular application that you might use to view the document. A possible defence against these (apart from checking for known vulnerabilities) would be to use less common applications (and not ones that were installed on your laptop, since they're the ones they'd expect you to use) to view the documents, or converting them to another format (using software from a trusted source to do so), and possibly back.

The hard disc(s) from the compromised laptop could have modified firmware, but that can't directly cause code to run on the machine you use to copy from them (it could alter data as it is read or written). Though in theory, it could have a buffer overrun exploit targeting a disc driver.

Ideally, all copying and conversion (and macro removal) would be done on a machine that you would reinstall (or discard) afterwards. (A Raspberry Pi or similar is quick to set up and can be expendable).

Answer 10

You want to copy your sourcecode from the compromised machine without the risk of infecting your new computer?

Easy:

1. Get access to an open WiFi Network
2. Copy your Sourcecode-Files to a free storage cloud service (or paste-bin)
3. download the source-files with your home computer
4. Carefully inspect all your sources for tampering (which is rather unlikely, because they usually would think you have backup-copies somewhere and wouldn't bother, but depends on the complexity of your software)

In this way you don't have any direct connection from the (possibly) compromised machine to your home computer. The only files you transfer are raw text files and inspected by hand. So the only attack-vector left is underhanded code in your sourcecode files. The only way to be bullet proof against that would be to rewrite every method in a new Project. Look at the old sourcecode and write each method anew with some minor fixes and cleaning up.

Answer 11

Others have covered the dangers & issues here perfectly so I'm not going to try to reproduce that. I just wanted to add a suggestion for after the inevitable code review. I realise that the question is about santizing the computer, but I'd suggest you need to take steps regarding your code too.

So let's assume that you've treated all the hardware as though it's a total write off and hostile, and you need to get the code back from it. There's already been suggestions of how to get the code off and on to another machine using a throw away printer and let's say you've done that (I'd have phycisally removed the wireless adaptor from the compromised machine before booting it as an extra precaution too).

So you've typed in your code again and reviewed it for modifications already and you're happy with it. The extra step I'd take now is to also assume the code has been examined and needs reviewing at a functional level and, if necessary, changing.

This might be the way you hash and store passwords, perhaps a licencing mechanism if it has one, or perhaps your code communicates over the internet with users in a particular way. I'm just thinking if I was carrying the code which ran something which would be of interest to a nation state actor, I'd look at modifying it so that if they've gleaned anything from it's inner workings, the next time they see it in use it will behave differently to how they'd expect it to behave.

tl;dr

I'd suggest giving some thought to the functonality of the code you were carrying; would a potentially hostile actor gain any benefit from having an understanding of how it works? If so consider how you'd mitigate the fact that someone has that knowledge.

This is assuming of course, that the code you were carrying would potentially be of interest to them.

Final note; this step would be necessary in my mind even if I'd restored the code from a known safe backup, as it's the way the code works which has been exposed.

Your situation doesn't sound like much fun regardless - good luck in getting it all sorted out.