Digital security specialists like me get some version of this question all the time: “I think my laptop may have been infected with malware. Can you check?”
We dread this sort of query because modern computer exploits are as complex, clever, and hard to reason about as modern computers — particularly if someone has the ability to physically access your device, as is routinely the case with laptops, especially when traveling. So while it’s definitely possible to detect certain types of tampering, it isn’t always trivial. And even in controlled environments, it’s impossible to give a laptop a clean bill of health with full confidence – it’s always possible that it was tampered with in a way you did not think to check.
The issue of tampering is particularly relevant for human rights workers, activists, journalists, and software developers, all of whom hold sensitive data sought by powerful potential attackers. People in these vocations are often keenly aware of the security of their laptops while traveling – after all, laptops store critical secrets like communication with sources, lists of contacts, password databases, and encryption keys used to vouch for source code you write, or to give you access to remote servers.
How safe is it to leave your laptop in your hotel room while you’re attending sessions at a conference? If you come back to find your laptop in a different position than where you thought you left it, can you still trust it? Did someone tamper with it, did a hotel housekeeper simply straighten up the items you left on your desk, or did you misremember where you left it?
These questions typically can’t be answered with total confidence because clever tampering can be so hard to detect. But I hoped I could get a sense of the risks with a carefully controlled experiment. For the last two years, I have carried a “honeypot” laptop with me every time I’ve traveled; this computer was intended to attract (and then detect) tampering. If any hackers, state-sponsored or otherwise, wanted to hack me by physically messing with my computer, I wanted to not only catch them in the act, but also gather technical evidence that I could use to learn how their attack worked and, hopefully, who the attacker was.
While traveling by air, I checked this laptop in my luggage to make it easily accessible to border agents, both domestic and foreign, to tamper with if they chose to. When staying in hotels, I left the laptop sitting on the desk in my room while I was away during the day, to make sure that any malicious housekeepers with permission to enter my room, or anyone else who broke into my room, was free to tamper with it if they chose to. I also put a bunch of hacker stickers all over it, hoping that this would make it a more enticing target.
I never caught anyone tampering with this laptop. But the absence of any evidence of tampering — and my obsessive thoughts about the various ways an attacker could have evaded by detection — serve to underline how fraught the process of computer forensics can be. If someone who makes their living securing computers thinks they could have missed a computer infection, what hope is there for the average computer user?
At the end of my experiment, I thought through all of the things that could have gone wrong. Perhaps someone did tamper with my honeypot laptop, and my methodology for detecting this wasn’t thorough enough to notice. Or maybe potential attackers noticed that the laptop I carried with me and used at the conferences I was attending was different than the one I left in my room, and decided against tampering with it in case it was a trap.
But the most likely reason I didn’t catch any attackers is that no one tried to tamper with my laptop. Hacking a target’s laptop by physically tampering with it while they’re traveling probably happens only rarely because it’s so expensive – it may require travel, physical surveillance, breaking and entering, and the risk of getting caught or breaking the laptop is high. Compare this to cheap forms of hacking like email phishing: You can target thousands of people at once from the comfort of your office, and the risk of getting caught is much lower.
Still, I believe actively checking devices for tampering is worthwhile. You’ll never catch an attacker in the act if you never look for evidence of their attacks. And just looking for evidence, even if you don’t find any, increases costs for attackers: If they want to be sure you won’t notice, they’re going to have to get more creative. I believe it’s useful to explain the technology and the methodology I came up with to detect tampering and share what I learned from the experience. Doing so gives a taste of just how many ways there are to tamper with a laptop.
Photos: Micah Lee
If you don’t use full disk encryption on your laptop, anyone who gains physical access to it, even for just a few minutes, can access all of your data and even implant malware on your computer to spy on you in the future. It doesn’t matter how good your password is because without encryption, the attacker can simply unscrew the case on your laptop, remove your hard disk, and access it from another computer.
Disk encryption does a great job of protecting your data in case you lose your laptop or someone steals it from you. When this person tries accessing your data, they should be completely locked out, so long as the passphrase you use to unlock your laptop is strong enough that they can’t guess it.
But there is a sneaky class of attack, called “evil maid” attacks, that disk encryption alone cannot protect against. Evil maid attacks work like this: An attacker (such as a malicious hotel housekeeper, for example) gains temporary access to your encrypted laptop. Although they can’t decrypt your data, they can spend a few minutes tampering with your laptop and then leave it exactly where they found it. When you come back and type in your credentials, now you have been hacked.
Exactly how an evil maid attack would work against your laptop depends on many factors: the type of computer you use, what operating system you use, which disk encryption software you use, and the configuration of firmware used to boot your computer, firmware which I’ll call “BIOS,” although it can also go by acronyms like EFI and UEFI. Some computers have considerably better technology to prevent evil maid attacks than others – for example, attackers have to do more advanced tampering to hack a Windows laptop encrypted with BitLocker than they do to hack a Mac laptop encrypted with FileVault (as of now, anyway) or a Linux laptop encrypted with LUKS.
An attacker could modify data on your hard disk. “Full disk encryption,” the term used to refer generically to systems like FileVault, really ought to be called “nearly full disk encryption” because, except in a few specific circumstances, there’s always a small part of a computer’s disk that isn’t encrypted.
When you power on your laptop, before your disk has been unlocked, your computer loads a program from this unencrypted part of your disk; it then runs the program, and the program asks you to enter your passphrase. The program converts your passphrase into an encryption key and tries to use it to unlock the disk. If you typed the correct passphrase, the disk unlocks, and the rest of the operating system (which is stored in the encrypted part of the disk) boots up. If you don’t know the right passphrase, there is no way to unlock the disk.
But since the program that asks for your passphrase isn’t encrypted, it’s possible for an attacker that physically has your laptop to replace it with a malicious version that looks exactly the same to the user, but that takes extra steps. For example, after you successfully unlock your disk, it might copy malware onto it that, after the computer finishes booting up, automatically runs in the background, spying on what you’re doing.
Computers that support “secure boot” or “verified boot,” such as Chromebooks and Windows laptops with BitLocker, aren’t vulnerable to this. The BIOS can detect if the unencrypted part of your disk has been tampered with, and if it has, it will refuse to boot. MacBooks and laptops that run Linux could potentially be attacked in this way.
An attacker could replace your BIOS firmware with malicious firmware. When you power on your computer, the very first program that your computer runs is your BIOS firmware. The job of this program is to initialize all of your hardware – your memory, disks, Wi-Fi adapter, video card, USB ports, and everything else – and then ultimately boot an operating system, typically the one stored on your hard disk.
When you format your disk and install a new operating system on your computer, your BIOS firmware doesn’t change. This is because this program isn’t stored on your hard disk at all. Instead, it’s stored in a small chip on your computer’s motherboard called an SPI flash chip.
This is why BIOS malware is so stealthy – you can’t get rid of it by formatting your hard disk, and it can spy on you across operating systems, such as if you boot to a Tails USB stick.
SPI flash chips have eight pins, including one for providing the chip with power, one for reading data, and one for writing data to the chip. This means that it’s possible for an attacker to power off your laptop, open up the case, and attach their own wires to the SPI flash chip pins in order to power it on, and then read and write data to it (the chip itself has no way of telling the difference between this, or just being part of the normal computer). Using this technique, an attacker with physical access to your laptop can replace your BIOS firmware with whatever malware they want.
The Italian spyware firm Hacking Team was caught selling such BIOS malware to its customers (the company’s clients include foreign governments with troubling human rights records). This specific firmware made sure that Windows was always infected with malware. If you’re a target of a Hacking Team customer, even formatting your disk and re-installing Windows would not remove the malware. As soon as you reboot, the malicious BIOS firmware would re-infect the freshly installed Windows with the same malware again.
An attacker could do other things to your hardware. Tampering with unencrypted data on your hard disk, or replacing your BIOS firmware with malware, are the most straightforward types of evil maid attacks, but the list of other potential attacks is only limited by the attacker’s creativity and budget.
Here are a few examples:
When I decided to start this honeypot laptop project, I realized early on that I couldn’t possibly detect every form of tampering. Because tampering with the data on the hard disk or the BIOS firmware are the simplest and cheapest types of evil maid attacks to conduct, and because attackers have limited resources and prefer low-hanging fruit when it’s available, I decided to limit my detection to these two components. But who knows? It’s possible that my honeypot laptop has a malicious component in it that I never checked for.
In February 2016, shortly before I was planning to fly to Spain for the Internet Freedom Festival, I bought a Lenovo IdeaPad S210 Touch for about $700 to use as my honeypot laptop.
Here was the plan. Before each trip, I would:
Then, during the trip, I would:
Once I returned home from a trip, I would:
Along the way, I planned to document everything: I’d take photos of my laptop in my luggage, in hotels, and of the cards that TSA leaves informing me that they searched my luggage; I’d keep a log of the state of my hard disk and BIOS before and after each trip; and I’d keep a journal that includes all technical hurdles I ran into.
This is mostly how it went down, but I did run into a few snags. Bear with me, in the following sections I venture much deeper into the technical weeds than I already have.
Before I proceed, there a few concepts I need to explain.
When I started this project, I decided to dual-boot Windows 10 and Debian, a popular Linux distribution, on my honeypot laptop – that is, I installed both operating systems in different partitions on the same disk, and when I powered on the computer, I got to choose which to boot to. But due to various time-consuming and annoying issues related to Windows updates, I eventually chose to abandon Windows altogether and just run Debian on my honeypot laptop, which made my job of detecting hard disk tampering simpler.
Before each trip, I removed the disk from the honeypot laptop, plugged it into a USB enclosure, and then plugged the USB disk enclosure into a different computer. The first snag I ran into was that when I plugged in the USB disk, my computer automatically tried to mount the partitions. This isn’t good – just by mounting the partitions, I risked modifying the data. So I changed the settings on my computer (which was running Linux) to disable automatically mounting external drives by following these instructions.sha256sum. In order to take a checksum of just the disk header, I used a tool called dd to copy the disk header into a file, and then used sha256sum to take a checksum of that file.
When I returned home from my trip, I repeated the same process to generate a new set of checksums. Finally, I compared the checksums from before my trip with the checksums from after my trip. If the checksums were not the same, then the data on the disk must have changed – this would be evidence of tampering. If I discovered this, I could then start looking into exactly what data had changed to discover how the tampering worked.
For example, in March 2017, before flying to Amsterdam to attend a Tor Project meeting with developers, volunteers, and advocates for the open-source anonymity network, these were the checksums I generated:
4040239f4f0a2090c3ca15216b6e42522c4c3cd291f2c78f3c9e815f25be8295 disk_header ed6e8a3438e55d2aeae4ae691823c4005f7b5df0b62d856bd72d54fa00d886bb /dev/xvdi1 db3d92ed1cfa8621e5673da32100d9117a3835c06a613cf9ac0f2f90de404d17 extended_header cbeb585b6fa39a8425f57fa095ac17353a583bccd93532d65d9274da628a4c72 luks_header
Ten days later, after I had returned from my trip, I generated another set of checksums. They all turned out to be exactly the same, which allowed me to confirm that the data on my hard disk had not changed at all.
When I started this project, I intended to dump BIOS firmware images externally using a BeagleBone Black (explained previously) and a software tool called flashrom, which is used for reading and writing data that’s stored on physical chips on circuit boards, roughly following the instructions outlined here. But I quickly hit a snag, one that I didn’t have the tools or knowledge of electronics to easily resolve.
The SPI flash chip that holds my honeypot laptop’s BIOS firmware has a pin for power and another pin for ground. With the laptop powered off, I connected the power and ground pins to my BBB, and then powered on the BBB.
I had hoped that the BBB would provide power to the SPI flash chip, allowing me to read and write directly to that chip. But instead the BBB immediately powered off. It turns out that, the way this specific laptop was wired, the power for the SPI chip was not isolated from the rest of the system. In order to provide power to that chip, I also needed to provide power to rest of the components of the motherboard, and that takes more watts than my BBB was able to handle. This was annoying because one of the reasons I chose a Lenovo computer as my honeypot laptop is because I have had success doing this exact process on other Lenovo computers in the past, dumping the BIOS firmware by connecting a BBB to the SPI flash chip.
So I decided to change strategies. Instead of dumping the BIOS firmware by connecting wires directly from the SPI flash chip, I would instead use a piece of software called chipsec, running on the honeypot laptop itself, to dump the firmware. However, this strategy has a few downsides compared to directly connecting to the chip:
In order to use chipsec, I set up a USB stick with the operating system Ubuntu (another popular Linux distribution). With the hard disk removed from the honeypot laptop, I plugged in my Ubuntu USB stick, powered on the laptop, and booted to Ubuntu. I put a copy of chipsec on an SD memory card, which I also plugged into the laptop. From there, I was able to run a specific chipsec command to dump the BIOS firmware and save it to the SD card, which I could then inspect on my other computer.VirusTotal report from the first BIOS firmware image that I dumped using chipsec from my honeypot laptop.
Once I successfully managed to dump the BIOS firmware, I came up with this plan:
Of course, it wasn’t this simple. It turns out, every time I booted my honeypot laptop to an Ubuntu live USB stick and dumped the BIOS firmware, that firmware image had a different checksum than the previous one. In order to investigate what was going on, I used a program called UEFITool. This is a graphical program that lets you load BIOS images, view and edit what data is stored inside, and extract data into separate files.
Looking at two BIOS firmware images that had different checksums, I was able to use UEFITool to extract the same components from both, and then generate new checksums for those individual components to see if they matched. I discovered that there was only one small part of the firmware images that differed, and that part did not include any programs. It turns out, each time I powered on the honeypot laptop and opened the boot menu to tell it to boot from my Ubuntu USB stick, it saved information related to booting to a USB stick in that section of the firmware, and this information was slightly different each time, which caused the firmware images to always have different checksums.
So I amended my plan for detecting tampering in the BIOS firmware. To compare firmware images from before and after my trip, I would have to open each image in UEFITool, extract all of the components except for the one that I knew changed, generate checksums for those components, and then compare those checksums to make sure they matched.
Traveling with a honeypot laptop was a lot of work. It required spending a few hours both before and after each trip if I hoped to actually catch an evil maid attacker in the act. So after two years without catching anyone, I have decided to retire the project.
A tool exists today, that didn’t exist when I started the project, that makes it possible to catch evil maid attackers in the act in a different way. Haven is an Android app, designed to run on a spare phone that you leave in your hotel room while you’re away, perhaps sitting on top of your laptop. It uses all of its sensors – microphone, motion detector, light detector, and cameras – to monitor the room for changes, logs everything it notices, and can send Signal notifications to the phone you carry with you when it detects a change. Haven isn’t perfect – there are plenty of false positives – but it gets better all the time and is still likely to catch anyone attempting to tamper with the laptop that’s sitting under the phone Haven is running on.
I was able to do this entire project with 100% free and open source software, thanks to projects like Debian and Ubuntu and tools like dd, sha256sum, flashrom, chipsec, and UEFITool. Other than the honeypot laptop itself, you can buy all of the hardware tools I used, like screwdrivers, a USB enclosure, and a BeagleBone Black, for less than $100.