137

Are there viruses that have managed to hide themselves somewhere other than on the hard drive? Like CPU cache or on the motherboard?

Is it even possible? Say I get a virus, so I get rid of the HDD and install a new one. Could the virus still be on my PC?

Jon
  • 3
  • 2
Ivan Bilan
  • 1,251
  • 2
  • 9
  • 10
  • 30
    Floppy disks -- I remember having to deal with viruses on floppies on my Amiga, and that didn't even have a hard drive. Same applies to any other removable media like USB sticks that can auto-run code when inserted into the computer. Even read-only media like CD-ROMs might have been shipped with viruses on them. – Simba Apr 21 '16 at 11:33
  • 9
    A bit more abstract, but I had a virus inside a virtual Windows machine once, with access to my real harddisk. Not directly what you're asking for, hence a comment. – phresnel Apr 21 '16 at 11:41
  • 2
    I had years ago a virus on my mainboard (at least I'm assuming so, since I couldn't explain it with anything else). it was like 2008 and my computer behaved strange. alot randomly files where wirtten all over my folders. And 1 or 2 reboots later something prevented to boot from that HDD. I also was not able to reinstall windows on that HDD. So I bought a new HDD unplugged the old one and installed windows. Installed drivers (didn't even connect internet so far) rebooted..... Same files where written on the factory new HDD. 1 more reboot and I couldn't use it anymore aswell. I bought a new PC. – Zaibis Apr 21 '16 at 15:34
  • 2
    Someone should write a virus for a [Mercury delay line](https://en.wikipedia.org/wiki/Delay_line_memory#Mercury_delay_lines) – Sam Apr 21 '16 at 15:35
  • 2
    Somewhat related: http://security.stackexchange.com/q/111156/91904 – Marc.2377 Apr 21 '16 at 18:59
  • 1
    Though not answering this question, it's better also to know that a virus doesn't have to be stored (except for the running instance in the memory) if it spreads quickly enough. In this case, if everyone on the internet shutdown their computer, the virus is gone, but they don't. – user23013 Apr 23 '16 at 13:15
  • 1
    If you want to be scared or impressed depending on your position check out hardware manufacturers reference documentation. For example Dell offers a document called "Statement of Volatility" for all servere. It contains mjltiple pages with inventory of (writeable, flash) firmware storage in a enterprise server. Sample: http://downloads.dell.com/manuals/common/poweredge-r720_white%20papers1_en-us.pdf – eckes Apr 23 '16 at 15:48
  • @Zaibis : What you are describing can also be caused by a simple failure of the onboard drive controller. Replacing the mobo should have been sufficient, assuming that the failure wasn't being induced by something else (like a marginal P/S, or another component able to inject transients into the power bus or data bus). – Eric Towers Apr 24 '16 at 20:59
  • There are viruses who hide on firmware of hardware. Think about it. The driver inside your GPU is infected (or any other part of your computer). Then you're basically boned. Even when you whipe your full pc the malwsre stays there and probably the only way to retrieve is to flash the hardware piece or replace it. Given that you ever have the chance of locating it. This is the really nasty stuff – BlueWizard Apr 25 '16 at 05:17
  • @Zaibis: Had that behaviour once, too. As Eric describes, it was probably a mobo controller failure. To me, it was even worse than a virus, because it can hide itself for way longer than your typical virus and it was completely "cross-platform" :P – phresnel Apr 25 '16 at 15:32
  • @JonasDralle What should a "driver inside your GPU" be?! How would that code be executed and re-infect the PC? – JimmyB Apr 26 '16 at 09:56

10 Answers10

203

Plenty of places:

Modern hardware has a wide range of persistent data stores, usually used for firmware. It's far too expensive to ship a complex device like a GPU or network card and put the firmware on a mask ROM where it can't be updated, then have a fault cause mass recalls. As such you need two things: a writeable location for that firmware, and a way to put the new firmware in place. This means the operating system software must be able to write to where the firmware is stored in the hardware (usually EEPROMs).

A good example of this is the state of modern BIOS/UEFI update utilities. You can take a UEFI image and an executable running on your OS (e.g. Windows), click a button, and your UEFI updates. Simple! If you reverse engineer how these work (which I have done a few times) it's mostly a case of a kernel-mode driver being loaded which takes page data from the given UEFI image and talks directly to the UEFI chip using the out instruction, sending the correct commands to unlock the flash and start the update process.

There are some protections, of course. Most BIOS / UEFI images won't load unless they're signed by the vendor. Of course, an advanced enough attacker might just steal the signing key from the vendor, but that's going into conspiracy theories and godlike threat actors, which just aren't realistic to fight in almost any scenario. Management engines like IME are meant to have certain protections which prevent their memory sections from being accessed even by ring0 code, but research has shown that there are many mistakes out there, and lots of weaknesses.

So, everything is screwed, right? Well, yes and no. It's possible to put rootkits in hardware, but it's also incredibly difficult. Each individual computer has such a variance in hardware and firmware versions that it's impossible to build a generic rootkit for most things. You can't just get a generic Asus BIOS and flash it to any board; you'll kill it. You'd need to create a rootkit for each separate board type, sometimes down to the correct revision range. It's also an area of security that involves a huge amount of cross-domain knowledge, way down deep to the hardware and low-level operational aspects of modern computing platforms, alongside strong security and cryptographic knowledge, so not many people are capable.

Are you likely to be targeted? No.

Are you likely to get infected with a BIOS/UEFI/SMM/GPU/NIC-resident rootkit? No.

The complexities and variances involved are just too great for the average user to ever realistically have to worry about it. Even from an economic perspective, these things take an inordinate amount of skill and effort and money to build, so burning them on consumer malware is idiotic. These kinds of threats are so targeted that they only ever really belong in the nation-state threat model.

forest
  • 64,616
  • 20
  • 206
  • 257
Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 36
    Don't forget the most simple case: a flash drive. If an USB stick caused the infection, it will happily infect the new HDD again. – Bergi Apr 21 '16 at 11:56
  • 24
    @Bergi I took the question to exclude traditional mass storage media entirely, but yes, that is true. You can also include smartphones in that category. – Polynomial Apr 21 '16 at 12:03
  • 7
    It realy depends on what "you" represents.Low-level user like you and me ? Of course, no. High-level journalist reporting on controversial subjects? The answer is a bit more sophiscated. Beeing careful never hurt somebody ... – Mxsky Apr 21 '16 at 14:24
  • 1
    It's more than just the content of the flash drive though. Wasn't there a PoC for infecting usb firmware? – Nate Diamond Apr 21 '16 at 15:54
  • 1
    @Nate Yes, it is known as badusb, but for virtually all the reasons described above for other hardware types, badusb is equally unlikely to be a threat to the average user. – Alden Be Apr 21 '16 at 18:35
  • 3
    Note that malware like the one that infected the Iranian nuclear power stations was also later discovered to infect German powerplants and laptops of ordinary people. That's the thing with malware designed to infect secure installations: by definition it has to try as hard as it possibly can. Such malware, since it was designed to target specific hardware (in this case equipment manufactured by Siemens), is unlikely to do damage to your PC. But just because you weren't deliberately targeted does not mean that your PC won't be potentially infected. – slebetman Apr 22 '16 at 03:43
  • While I tend to agree that these threat vectors are unlikely, aren't we basically reviving a variation of the old "security through obscurity" argument? – Viktor Toth Apr 22 '16 at 15:05
  • 3
    @ViktorToth Yes, but that's somewhat irrelevant when we're talking about risk modeling. It's not as much obscurity as it is limiting the applicability of malware to a very small ecosystem, making it not worth the effort to an attacker unless it's intended to be targeted. Attack economics is an important part of the threat model. – Polynomial Apr 22 '16 at 15:09
  • 1
    @slebetman The difference here is that Stuxnet's *payload* was designed to interface with a specific PLC device attached to the system. In this case we're talking about generic persistence vectors, not payloads, which is an important distinction. While you might get infected with a piece of malware with such functionality (which would still be unlikely) the chances of it actually being able to "hide" in the intended way are infinitesimal. Similarly, the German powerplant that was infected simply had Stuxnet on a computer that was in the powerplant, and it did not trigger its intended payload. – Polynomial Apr 22 '16 at 15:15
  • @Polynomial: Correct. That's what I said. Just because you're not targeted does not mean you will not be infected. Remember - payload and infection are two different things. I don't know about you but I'm not comfortable with viruses on my PC regardless weather the payload is deployed. It's hard enough to live with bugs in regular programs. Potential bugs in viruses that may end doing random stuff to my files I can live without. – slebetman Apr 22 '16 at 16:31
  • @slebetman True, but I'd rather have malware on my system that I can detect and appropriately triage than malware on my system that ruins my hardware. – Polynomial Apr 22 '16 at 16:39
  • It is also possible that malware only hides itself in the memory (RAM). Especially on servers - which are rarely restarted - this becomes popular. – rugk Apr 22 '16 at 18:26
  • @rugk This is almost impossible to do without ever touching the disk, though. While attempts have been made, issues like paging and having to drop libraries to inject into the processes into temporary directories, ultimately means that memory-resident malware is often not entirely memory-resident. – Polynomial Apr 22 '16 at 18:30
  • 1
    If you are really paranoid, your hard drive can have a malware on it's firmware. I read a while ago about running Linux out of the hardware chip itself. The hard drive had an ARM processor, 32MB or memory and enough to run a shell there. You can read it on http://spritesmods.com/?art=hddhack – Ismael Miguel Apr 23 '16 at 15:41
  • Just a minor correction. Malware cannot store itself in SMM, it can merely hide itself there at runtime because SMM is not persistent. As soon as the computer shuts down, everything executing in a system management context (ring -2) is lost. Also, you are confusing SMM with the ME. SMM is completely different from the Management Engine, which is ring -3. The ME has its own firmware (stored in the BIOS), which actually is persistent, whereas SMM is just a higher privileged mode available for execution on the CPU. – forest Apr 24 '16 at 03:45
  • Actually, there's a third problem with this answer I have to point out. You mentioned the Jellyfish PoC (the GPU-resident malware). It is also not persistent across reboots. It, like SMM, is just designed to be able to hide from traditional IDS. While in theory the GPU's firmware could be overwritten to create a true persistent hiding place for malware, that's not what you linked to. And the Quest to the Core paper, talking about microcode and such, are also not relevant to the question. Microcode must be re-applied at every boot. It is lost when the system shuts down. – forest Apr 24 '16 at 03:52
  • Overall, every one of those places you mentioned, other than the BIOS/UEFI, are temporary hiding spots that malware can use to evade IDS and maintain higher privileges. None of them are used to persist across reboots or reinstalls. Also I think you mixed up IME with SMI (the Phrack paper you mentioned didn't talk about the IME at all, only SMIs, which are used to launch into SMM context). I think this whole answer misunderstands the question and lists places malware can hide from an IDS in, not places malware can be stored in. And don't most systems use MLC NAND instead of EEPROM now days? – forest Apr 24 '16 at 03:55
  • @forest If you infect these areas you can implement malware with specific capabilities. For example, infecting a NIC's firmware gives you DMA access to the entire system memory, and a covert exfiltration channel that can't be seen by the OS. GPU malware can again DMA, so it has full control over the system, although it can't directly communicate out (well, actually, it can, if you hook up an internet-connected TV via HDMI, due to HEC). GPUs also have firmware. Point being that these places store code, and modifying that code allows for a persistent stealthy rootkit. – Polynomial Apr 24 '16 at 21:53
  • That's true, but in order to get into those places, you need the privileges required to get DMA abilities in the first place, so it's not privesc either. There's really no point in moving to the GPU's once you already have ring 0, other than to hide from the rest of the system and covertly mess with things over DMA. It won't let you survive a reboot. Unless I misunderstood OP's question, he's not asking about a stealthy rootkit, but one which is stored in places other than the hard drive, like the BIOS, etc (not just one which hides from an IDS). – forest Apr 24 '16 at 23:47
  • Aren't there dedicated chips responsible for reading if the software to be installed and checking if it is signed ? – Pop Flamingo Apr 25 '16 at 11:08
  • @TrevörAnneDenise Not really; there are features in some hardware platforms to try to enforce code integrity and authenticity (e.g. ARM TrustZone and UEFI SecureBoot) but in practice these have been shown to be deficient due to mistakes in implementation or poor vendor support. – Polynomial Apr 26 '16 at 13:05
  • 1
    @TrevörAnneDenise The problem is that these systems have (largely) been jury-rigged into existing architectures to solve problems which arose decades after the system was originally designed. As such, the features tend to have convoluted requirements and limitations, weakening their capabilities and increasing the implementation costs. Also, code signing is a difficult matter on general purpose machines - who should be allowed to sign code? If you limit it, it stifles your freedom of OS choice. If you open it up to anyone, what's to stop malware being signed? It's a difficult UX choice. – Polynomial Apr 26 '16 at 13:11
  • That's understandable ! – Pop Flamingo Apr 26 '16 at 13:12
42

The short answer to your question is yes.

Here are some places where a virus could hide:

  • On the firmware of your keyboard, mouse, webcam, speakers, etc. Basically anything you connect to your computer that has a writable firmware.
  • On your hard drive firmware. Sort of on your hard drive, but still survives a reformatting. The NSA are likely suspects for that one.
  • In your BIOS or UEFI.
  • In ye olden days, boot sectors of floppy disks. This was standard among early viruses, since at the time floppy disks were often used as primary storage. Same goes for USB sticks now.

A virus could potentially target anything where there is writable data that gets treated as executable code. On a computer, that is basically anywhere. For it to survive a restart, though, it would have to be some kind of persistent storage. So the CPU cache might not be the best place to hide.

Most viruses don't do this, though, and just live on the HDD. This is because virus writers are (rationally) lazy. Why go for the complicated options when there is plenty of low hanging fruit?

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215
  • 16
    Ah yes, I forgot the hard disk firmware from my answer. Travis Goodspeed did an interesting talk on this a while back, producing an anti-forensics disk. The idea was that normal OS read/write and ATA command patterns are pretty unique, but write-blockers, forensics software, and cloners (e.g. `dd`) send totally different patterns making it easy to spot when a disk is being forensically analysed. The disk then wipes itself with a repeated pattern of the lyrics to Rick Astley's Never Gonna Give You Up. – Polynomial Apr 21 '16 at 13:28
  • 3
    @Polynomial Does that count as a Rickroll? – JAB Apr 21 '16 at 17:53
  • 1
    anything with firmware, indeed. including printers – prusswan Apr 23 '16 at 12:43
  • Keyboards have writable firmware? I knew some expensive mice did, but I didn't know of any keyboards which did. I'm a bit sad to even find that out, considering I'm one of those people who still prefers using a PS/2 keyboard and mouse... On demand interrupts > some silly driver polling 5000 times a second, imo. – forest Apr 24 '16 at 04:02
  • @forest It is not standard, but I think there are. I could be wrong on this one, though. – Anders Apr 24 '16 at 10:06
  • 2
    @forest - there was a proven attack on Mac keyboard firmware a while back, think it got written up on Hackaday. No reason to think they're unique though. These days everything has a micro in it because it's just cheaper than building functionality in hardware, and very capable (and hence usefully infectable) micros are so cheap now. – John U Apr 25 '16 at 10:36
  • 1
    http://www.zdnet.com/article/criminals-push-malware-by-losing-usb-sticks-in-parking-lots/ and http://www.instructables.com/id/USB-Mouse-Flash-Drive-Hack/ – TecBrat Apr 26 '16 at 18:02
  • @Polynomial Wasn't that writeup in PoC||GTFO and specifically for iPod hard drives? I recall it made modifications to the iPod firmware that interfaced with the drive, not with the drive firmware itself (though naturally you could do the same thing in the drive firmware). – forest Nov 22 '18 at 09:02
  • @forest Yes, a better cite would be [hddhack over at spritesmods](https://spritesmods.com/?art=hddhack). – Polynomial Nov 26 '18 at 17:58
13

One of most common but unchecked places is... a peripherial with "embedded driver disk", like lots of 3G/4G USB sticks. They have — technically — a hub inside, and a Generic Storage + the device itself on it. Upgrading its firmware usually upgrades a disk image mounted to the generic storage part. It's read-only from PC in regular use, but it's easily remapped as a CD-ROM with autoplay. The one I've experienced myself in 2006-2008 was a 4G stick for a local cell provider. It contained CD-ROM like storage out-of-the-box from local sale point, autoplay and torjan included =) Next firmware patch — and a storage is remapped back to HDD and no virus on board.

JDługosz
  • 1,138
  • 2
  • 7
  • 12
Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • 3
    I would have thought "autorun" would be permanently disabled by now – Xen2050 Apr 22 '16 at 07:45
  • 3
    @Xen2050 Fasten your seatbelt : when I was upgrading from Windows 7 to 10, in win7 autorun was disabled. In win10 **it was enabled again by installer** at the same time it has migrated all the settings I had – Alexey Vesnin Apr 22 '16 at 14:23
11

The main problem for any kind of storage is that the system must be willing to execute the malware. During the boot of the operating system this means it has to be somewhere as an executable, DLL, driver or similar on the hard disk. It does not need to be fully there, i.e. it can be a small loadable stuff and the rest might reside somewhere else (even in the network).

But malware can also be loaded before the OS executes. The loading of the OS is controlled by the BIOS or UEFI so if the malware is already contained in this stage it is outside the control of the OS. For one example see Hacking Team's malware uses a UEFI rootkit to survive operating system reinstalls.

Apart from that you have firmware on the network card, the graphic card, the hard disk etc and these often can be replaced. Thus some malware might hide there too and change the behavior of the system, see How the NSA’s Firmware Hacking Works and Why It’s So Unsettling.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
6

There were a few things that came to mind when I read the question that extend beyond the scope of the example given. There are other places that a virus can be stored besides on a hard drive or even on a computer. A couple of those places would be bacteria (specifically E. coli) and your DNA.

According to some research performed cerca 2010 that proved that E. coli could not only store data (or a virus) but also offer bioencryption.

More recently, scientists have discovered that they can store up to 700TB of data in 1 gram of your DNA. The advantage would be that it's a long term storage if properly stored.

So, as the tech industry moves closer to integrating technology and our biology, they may have to look further than just our hard drive, BIOS, memory, GPU, etc.

Josh
  • 169
  • 2
  • Here are a couple more links that may be of interest. http://www.extremetech.com/extreme/212496-dna-can-now-reliably-store-data-for-2000-years-or-more http://io9.gizmodo.com/5699767/bioencryption-can-store-almost-a-million-gigabytes-of-data-inside-bacteria – Josh Apr 21 '16 at 22:25
  • Oh snap, didn't think of that. – Joseph Apr 21 '16 at 22:25
  • 3
    Interesting, but for now it's not really a viable place to store a computer virus that would re-infect a new OS (thankfully, would hate to have to physically clean a motherboard as well as install a "clean OS") – Xen2050 Apr 22 '16 at 07:41
  • 1
    And if you store the computer virus in an *actual* virus, we all become carriers for it! – fluffy Apr 23 '16 at 01:42
5

In addition to an excellent Polynomial's answer, there are some more options:

  • another device on the network, obviously (e.g. another computer infecting samba shares, router adding exploit to its web page, ...)
  • USB device (e.g. flash disk) secretly changing to a keyboard and typing/downloading the malware to the host computer
Edheldil
  • 885
  • 5
  • 9
2

Not sure whether any other part of computer was used by virus,but long back came across BADBIOS

What does bad bios do?

Radio (SDR) program code, even with all wireless hardware removed.


It is said to infect the firmware on USB sticks.

It is said to use TTF (font) files, apparently in large numbers, as a vector when spreading.

Apart from the above its not only virus which attacks a machine there were many types of rootkits available like PCI rootkit

In Summary the virus can be resided at bios or at any source but it requires some point of execution which lacks at hardware.

Edit after question :

As per question ,yes there were chances of virus which could transfer to ur new hdd,for instance consider rootkits like jellyfish ,but notably this cases were rare for normal end users

BlueBerry - Vignesh4303
  • 5,107
  • 13
  • 34
  • 63
  • 1
    "It is said to spread itself to new victim computers using the speakers on an infected device to talk to the microphone on an uninfected one." , wait what? Through soundwaves? – Ivan Bilan Apr 21 '16 at 09:22
  • @ivan_bilan one thing should be noted over here,this were the possiblities which was derived theoretically and proven methods describe how it can be done,but this kind of rootkits,virus,spywares were very uncommon and rare among endusers,so no need to worry about that http://blog.erratasec.com/2013/10/badbios-features-explained.html#.VxicW7NZNE4 have a look over here there is in much detailed answer – BlueBerry - Vignesh4303 Apr 21 '16 at 09:24
  • 3
    The sophos article you linked to suggests that badBIOS may be a hoax, as it has only ever affected Dragos Ruiu, the guy who reported it, No one has replicated his findings. – browly Apr 21 '16 at 15:32
  • @ivan_bilan http://www.jocm.us/uploadfile/2013/1125/20131125103803901.pdf – JAB Apr 21 '16 at 17:54
  • That's an awful lot of "It is said" requiring a myriad of highly advanced features converging on a single person only. Has any of this ever been verified? I'm very sceptical and am leaning towards believing this was simply a weird hoax or imaginary episode. Reading other threads suggests this is old hat and I'm not alone in this interpretation of it all. – underscore_d Apr 24 '16 at 15:55
2

The answer is YES, they can hide in many other places, not only into your HDD, but also into other storage devices you have connected to your PC.

  • In early days, I use to have lot of issue with CD/DVD "Autorun" option in my Microsoft Windows. Virus were so capable to automatically create "Autorun.inf" into burning media and use to run and infect automatically into fresh PC when I insert affected ROM into reader.

  • Virus use to infect USB flash drive automatically, and spread by themselves if the flash drive is inserted into uninfected system.

These are two major areas, where your primary focus have to be.

If you have managed to remove Virus from your HDD, don't forget to check Windows Registry at these locations: (believe me I have disabled many Virus files being executed, by removing unknown entries from below locations);

Run "regedit" to open Windows Registry Editor, and navigate to check below two locations for suspicious registry entries !!

HKEY_CURRENT_USER : Software : Microsoft : Windows : CurrentVersion : Run

HKEY_LOCAL_MACHINE : SOFTWARE : Microsoft : Windows : CurrentVersion : Run

Kiran
  • 21
  • 2
  • 1
    I think that if the hard drive was removed, then the OS (and any registry entries) would be gone with it. – schroeder Apr 21 '16 at 18:53
2

In case you are using a custom CPU working as an harvard architecture based design, a virus can inject the ROM that the instruction codes are stored in but it is a very very hard process to change a ROM value that way . Still it is an injection

B. Koksal
  • 21
  • 2
-4

On a piece of paper, which is then typed in at the keyboard (or OCRed?).

The most obvious is the EICAR test virus signature:

"X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR"
"-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"

If you join the two strings together and save it as an executable file (a ".com" file on MSDOS or 32-bit Windows platforms) then any self-respecting anti-virus program is supposed to treat it in the same manner as if it were a virus. Note that this is specifically enter-able with characters that can be generated from a plain vanilla "keyboard".

schroeder
  • 123,438
  • 55
  • 284
  • 319
Stephen Lyons
  • 1
  • 1
    What is obvious about EICAR as an example? All malware is code that needs to be compiled or interpreted. I am completely confused as to why EICAR is an example. Is it just because it's short enough for the average person to type? – schroeder Apr 22 '16 at 17:40
  • 2
    I am also not sure if being printed out counts as "hiding" as per the question. – schroeder Apr 22 '16 at 17:41
  • That is not a virus. It is just a test string for AV programs. There's no way for that file to reproduce, be executed, or do anything that virus or malware do. – Neil Smithline Apr 28 '16 at 16:18