Search for military installed backdoors on laptop

  • My laptop was confiscated by the military institute of my country and they made me to give them all my passwords (I cannot tell you the name of my country). They did not give it back to me for one week (yes, it was out of my sight for a while). I nuked it from orbit but I just realised that it was on sleep state for 2 days and not in shutdown state, so it was connected to my modem via wifi. Does it need to be worried about?


    I need to make sure if they have added something to monitor my activities or steal my data or not? And if they have done that, what should I do to prevent them.

    I have double checked the laptop physically and there is no sign of screw or plastic deformation. Is that still possible that they have compromised its hardware?

    Comments are not for extended discussion; this conversation has been moved to chat.

    "nuked from orbit" means what exactly? (I suppose you didn't actually go to orbit and threw a nuklear weapon onto your laptop, as then you wouldn't ask the question.)

    @PaŭloEbermann Its a reference to a quote from the movie Aliens, and it basically means delete everything you can delete from the laptop and just start from scratch. There is a nice question on that here

  • forest

    forest Correct answer

    2 years ago

    If the device left your sight for any amount of time, replace it. It can no longer be trusted.

    The cost to assure it can still be trusted significantly exceeds the cost of getting a new one

    There is effectively no way to verify that the hardware has not been tampered with without significant expertise and employing non-trivial resources. The only solution is to replace the laptop and all associated components. Without knowing your country or other aspects of the situation you are in, there is no way for me to comment on the likelihood of this, only on the technical feasibility.

    If you do need to verify the integrity of the laptop, there are a few things to check (non-exhaustive):

    • Weight distribution - Verify the precise weight of each component (ICs, PCB, etc). Weight distributions can be analyzed using gyroscopic effects. This requires having uncompromised equipment nearby for comparison. Extremely precise measuring equipment is required. You'll need to be aware of the different tolerances each part has in order to know what is anomalous.

    • Power consumption - Verify the power consumption of each component over time. Backdoors often use power, and their presence can sometimes be detected with a power analysis attack. Do not rely on this however, as integrated circuits can use extremely little power nowadays.

    • PCB X-ray inspection - Use X-rays to view the circuit board internals. This requires expensive equipment for a multi-layer printed circuit board such as a laptop motherboard. It also requires many man hours of intensive inspection of each square micrometer of the device. This is probably the easiest to do, although still takes specialized equipment and skills.

    • IC inspection - Physically remove the various layers on integrated circuits ("decapping") and analyze the internal die. For anything much more complicated than an 8051 microcontroller, this will require significant expertise and is not possible without a high level of domain knowledge and a lab. But this would have to be done for everything from the main chipset to every CPLD on the board. Do you have a full-face respirator and a fume hood for all the acid you'll need to use?

    Sounds excessive? It is, but this is what you would have to do to have a good level of confidence that no malicious hardware modifications have been made. It will be cheaper just to buy a new laptop. Note that this is not intended to be practical advice, and it is not even close to complete even if it was. It's meant only to illustrate this near-impossibility of searching for sophisticated hardware implants.

    I nuked it from orbit but I just realised that it was on sleep state for 2 days and not in shutdown state, so it was connected to my modem via wifi. Does it need to be worried about?

    In theory, compromised hardware or firmware would be made to compromise your wireless access point or other devices listening in. While a suspended state (sleep mode) normally also disables the NIC, you cannot make that assumption if the hardware is compromised. However, while this is theoretically possible, it would require a far more targeted attack, and most military groups will not want to give away their 0days by shooting them at any random nearby wireless devices.

    Unfortunately, it is also theoretically possible that your modem has been compromised. If that is the case though, I think it'd be incredibly unlikely that it was done by your exploited laptop, as they could have just taken over your modem through your internet connection (TR-069 is a bitch), assuming they can control or compromise your ISP. If they have tampered with your hardware, it's much more likely that they have only done so for surveillance purposes, not to spread some silly worm.

    I have double checked the laptop physically and there is no sign of screw or plastic deformation. Is that still possible that they have compromised its hardware?

    Absolutely. There are many ways to open a laptop without that fact being apparent. While many sophisticated chassis intrusion detection mechanisms exist (some that even detect small changes in air pressure that would indicate a person messing with it), there are some "ghetto" techniques which you may be able to use in the future. One technique is to sprinkle nail polish with glitter on the joints of the system, inside and out. Take a high-resolution photo of this (and don't store the photo on the computer!). If the device is opened, the precise layout of the glitter will be disrupted, and it will become exceptionally difficult to put it back in place. You can compare it with the stored photo and look for subtle differences. This is sufficient to detect tampering by most adversaries, if done right.

    The term for this is tamper-evidence, which is any technique that makes it difficult to tamper with a device without that fact being noticeable. More professional options would include bespoke tamper-evident security tape or holographic stickers. There are lots of epoxy potting solutions too (but beware of overheating!). Unfortunately, this can only help you in the future and will obviously be incapable of protecting your system retroactively. But consider how likely it is that they really compromised it.

    Comments are not for extended discussion; this conversation has been moved to chat.

    Replacing the device might be a threat of equivalent force in this case. OPs country could stealthily take control of the computer supply chain and infect a significant supply within its borders.

    @redbow_kimee That's **extremely** unlikely due to how quickly it would become known.

    Surprised you don't mention malicious firmware (for the main motherboard, or for any of the devices). x86 System Management Mode allows nearly-undetectably doing things behind the back of the OS. (There is a performance counter (AMD) or MSR (Intel) that counts System Management Interrupts, though, so you could check for suspiciously-high SMI activity. Is there an equivalent register to Intel's MSR\_SMI\_COUNT on AMD architecture?)

    @PeterCordes Malicious firmware can get around `SMI_COUNT`.

    Ok, that makes it even worse. That leaves you with performance experiments with (regular) interrupts disabled, e.g. in a kernel driver, to try to detect excessive SMIs. Or some other way to try to rule out other causes of some timed intervals being longer than expected, at least statistically.

    @PeterCordes That can be avoided as well, since timers can also be spoofed. The firmware has absolute control over software, so there's nothing that can be done to detect it with a good level of certainty. Plus it could be made to enter SMM only very rarely to avoid tripping any alarms, or even run malicious firmware on the CSME, which is a separate processor and so would not impact the performance of the primary x86 CPU.

    I wasn't sure SMM could convincingly adjust both RDTSC and performance counters in a way that's consistent down to a couple cycles with what out-of-order execution would have done for any given loop that gets interrupted. Loops that don't touch memory, just ALU dependency chains, can be extremely repeatable, but the cost of an interrupt in the middle can depend on how much the loop was benefiting from out-of-order execution overlapping work on multiple iterations. Or if the loop does store to memory, then the cost of an interrupt can include flushing the store buffer.

    @PeterCordes The RDTSC continues counting even in SMM. You're right that there would still be ways to detect it if you really wanted to (assuming it wasn't designed to get around the mechanism you used), but malicious firmware can set SMI to trigger on only rare events, enough that it's very unlikely that you'd ever detect it, short of using an `inc` and `jmp` loop as a counter maxing out on all cores.

    But yeah, only entering SMM very rarely is much more likely, and would probably be nearly impossible to pick out from the background noise of other things that can cause timing spikes, maybe even in an interrupts-disabled loop in kernel mode.

    I *think* there's a way to change the TSC, which OSes used to have to use to try to sync the TSC across cores before the `constant_tsc` feature made HW do that for you across cores in one socket. I know there's TSC manipulation stuff for VT-X to present a scaled/offset TSC to the guest, which isn't available when not using HW virt, but I think there's a way to just set the TSC. And yeah, I was talking about repeatedly timing something that runs for ~200 cycles or so, with `lfence; rdtsc` to start and `rdtscp; lfence` to stop. Or better, `rdpmc` to count core cycles, not ref cycles.

    VT-x doesn't allow manipulating the TSC directly, it just makes it possible to trigger a VMEXIT on instructions that access the TSC (so the hypervisor can modify GPRs before resuming the VM). documents the scaling feature (added after the offset feature), which allows efficient migration of a VM between hardware with different TSC frequencies. Offset and scaling are configured with VMCS fields, and don't require a VM exit. (In fact, this feature only works for rdtsc and rdtscp if it's set so they don't cause a VM exit. It still applies to RDMSR on the `IA32_TIME_STAMP_COUNTER` MSR, and PEBS / PT timestamps, though)

    @PeterCordes Oh interesting. I didn't know that, thanks.

    Make sure you have that photo at a place outside the computer, though.

    Why waste 0days when the password to the Wi-Fi router admin UI was most likely saved in the browser? Or admin:admin or something known to the ISP.

    @forest Regarding controlling the supply chain being extremely unlikely, didn't the NSA do something like this when it intercepted components en-route from suppliers to customers? AFAIK that wasn't revealed until the Snowden leaks

    @JonBentley Yes, but that's a completely different threat model. If they want to get OP, they aren't going to be confiscating his laptop, they'll interdict it as it's being delivered.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM