3 ms·

The title is a little misleading. This is not a discovery of malware, but rather a theorized capability that malware could use. Link to the paper on which this

by 0x53 5y ago

The title is a little misleading. This is not a discovery of malware, but rather a theorized capability that malware could use. Link to the paper on which this is based: https://arxiv.org/ftp/arxiv/papers/2112/2112.13923.pdf https://arxiv.org/ftp/arxiv/papers/2112/2112.13923.pdf It appears as though the attack is based on the assumption that you have admin level access to the computer.

johnklos 5y ago
It's not a little misleading - it's very misleading. Reading "New Malware Uses", one can't come to any other reasonable conclusion that there exists new malware that, in fact, uses whatever else is in the title. There's nothing even slightly suggesting that this is speculation. "New Malware Could Use" would be worlds different. The bleepingcomputer.com title is not misleading because it has the word "can": "Firmware attack can drop persistent malware in hidden SSD area" https://www.bleepingcomputer.com/news/security/firmware-attack-can-drop-persistent-malware-in-hidden-ssd-area/ https://www.bleepingcomputer.com/news/security/firmware-atta...
- marcan_42 5y ago
  It's not very misleading - it's 100% nonsense. It's not new, it's not malware, and it doesn't and can't bypass any security measures. This is a theoretical mechanism for hiding data in the OP areas on SSDs. It cannot be used to compromise anything, because by definition data in the OP area cannot be accessed by the host, and to infect the host you need to infect data it can access. At most it could allow e.g. RAM-resident malware to hide data in the SSD, but there are much easier ways of doing that. If you've compromised the host to the point where you can issue raw commands to compromise the SSD, you can just throw your encrypted data in a file and fake the OS's free space display to hide it. And besides, malware rarely needs copious amounts of local storage anyway. This is a niche technique among niche techniques that some hypothetical highly advanced malware could opt to use for some very specific thing, and my professional opinion as a security researcher is that no malware ever will actually find this technique useful enough to actually use it. Even the "can drop persistent malware" version is highly misleading, because you need a persistent bootstrap outside the OP area to do anything. You can't just hide your malware in the OP area and expect it to run. That's like hiding a cyanide pill under the couch cushions of your victim and expecting them to find it and swallow it. Basically, just another case of security academia living in their own little world and coming up with fun but useless ideas. Not relevant to actual malware in the wild; move right along. A better use case for this technique would be as a data-hiding trick. E.g. you could put stuff in the OP area that you want $government_agency not to find if they seize and scan your device at a border crossing. But then again, there are a million other ways of doing this that don't involve wacko manufacturer-specific SSD nonsense; steganography has been a thing for ages and, if done right, is nigh undetectable. Just put your raw 44.1kHz FLAC music collection on the disk and store whatever encrypted data you want in the LSBs. That's indistinguishable from flat spectrum dither noise.
  - rosndo 5y ago
    This whole story reeks of a paper mill similar to the Israeli group that keeps dropping slight variations of the same covert channel research every couple of months.
  - wtallis 5y ago
    I agree that the "attack" as described by the article is nonsense. However, it's only missing a few ingredients necessary to be an actual threat model. When you're already postulating the abuse of a vendor-specific feature to (somewhat unreliably) hide data, it's not much of a stretch to also hypothesize an attack against the SSD firmware, gaining control over the drive and its numerous ARM cores. This would make it theoretically possible to make the attack much more durable, by incorporating the rootkit into the operation of the SSD itself and protecting its data from being overwritten. For NVMe SSDs that have DMA capability and aren't trapped behind an IOMMU or are given the opportunity to provide an option ROM for the host to run during boot, this could definitely cause trouble for the system as a whole. I suspect there are still a lot of client SSDs out there that lack an effective secure boot protection for their own firmware. Such an attack requires the resources of a state actor, and could only attack a narrow range of systems (those using a particular model of SSD), and requires a separate successful supply-chain attack or other exploit to initially infect the drive. But once infected, SSDs are a pretty good place to hide malicious code and data, because they have plenty of storage, their own processing resources and copious RAM, access to all your data (unless encrypted on the CPU), and is beyond the scope of what antivirus software monitors. And they can potentially interact with the rest of the system, which is why we really need to see IOMMU support taken more seriously. The ability for your NIC and SSD to talk to each other without getting the CPU involved is really cool—when done for the right reasons.
    - marcan_42 5y ago
      Oh, you're absolutely right that modifying SSD firmware gives you a lot of fun possibilities for hijacking a machine, but that is not new either, it's a threat vector that has been known and investigated for many years now. Here's someone running Linux on an HDD controller in 2013: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1 It's well known that SSD vendor security is usually atrocious; these companies do not have much experience building secure-boot systems, and there are often vendor-specific backdoor commands and such. You absolutely do not need the resources of a state actor to pull that off; a good reason and 5-6 digits' worth of (competent) security researcher time ought to do it. I've spent half of my life breaking systems that try a lot harder to have secure boot than SSDs, as a hobby. Indeed, IOMMU support is critical in the modern hardware ecosystem. Honestly, any system that does not use them by default for all off-chip peripherals in 2021 is just unsuitable for any kind of sensitive use case. That, plus FDE with hashtree authentication, eliminates SSD compromise as an attack vector.
gruez 5y ago
>It appears as though the attack is based on the assumption that you have admin level access to the computer. Ah yes, the famous "it rather involved being on the other side of this airtight hatchway" that raymond chen talks about. https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98115 https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98...
- 13of40 5y ago
  Yeah, and I'm not really seeing the advantage of doing this versus just encrypting the data and storing it in normal filesystem space. Maybe that whoever has to write an anti-evasion for it now has to be able to look in this unallocated space on the SSD, and there's no easy API to use?
  - marcan_42 5y ago
    The malware has to exist outside the OP area to be able to infect the host, otherwise it would never run. Antimalware can just look for that bit. All this really does is let you increase the amount of storage malware can potentially use; it doesn't hide the core, which has to live in the normal area.
  - deleted 5y ago
    [deleted]
dang 5y ago
Ok, we've changed the title above (to one suggested by a user who emailed—thanks!)

by 0x53 5y ago

johnklos 5y ago

It's not a little misleading - it's very misleading. Reading "New Malware Uses", one can't come to any other reasonable conclusion that there exists new malware that, in fact, uses whatever else is in the title. There's nothing even slightly suggesting that this is speculation. "New Malware Could Use" would be worlds different. The bleepingcomputer.com title is not misleading because it has the word "can": "Firmware attack can drop persistent malware in hidden SSD area" https://www.bleepingcomputer.com/news/security/firmware-attack-can-drop-persistent-malware-in-hidden-ssd-area/ https://www.bleepingcomputer.com/news/security/firmware-atta...

marcan_42 5y ago
It's not very misleading - it's 100% nonsense. It's not new, it's not malware, and it doesn't and can't bypass any security measures. This is a theoretical mechanism for hiding data in the OP areas on SSDs. It cannot be used to compromise anything, because by definition data in the OP area cannot be accessed by the host, and to infect the host you need to infect data it can access. At most it could allow e.g. RAM-resident malware to hide data in the SSD, but there are much easier ways of doing that. If you've compromised the host to the point where you can issue raw commands to compromise the SSD, you can just throw your encrypted data in a file and fake the OS's free space display to hide it. And besides, malware rarely needs copious amounts of local storage anyway. This is a niche technique among niche techniques that some hypothetical highly advanced malware could opt to use for some very specific thing, and my professional opinion as a security researcher is that no malware ever will actually find this technique useful enough to actually use it. Even the "can drop persistent malware" version is highly misleading, because you need a persistent bootstrap outside the OP area to do anything. You can't just hide your malware in the OP area and expect it to run. That's like hiding a cyanide pill under the couch cushions of your victim and expecting them to find it and swallow it. Basically, just another case of security academia living in their own little world and coming up with fun but useless ideas. Not relevant to actual malware in the wild; move right along. A better use case for this technique would be as a data-hiding trick. E.g. you could put stuff in the OP area that you want $government_agency not to find if they seize and scan your device at a border crossing. But then again, there are a million other ways of doing this that don't involve wacko manufacturer-specific SSD nonsense; steganography has been a thing for ages and, if done right, is nigh undetectable. Just put your raw 44.1kHz FLAC music collection on the disk and store whatever encrypted data you want in the LSBs. That's indistinguishable from flat spectrum dither noise.
- rosndo 5y ago
  This whole story reeks of a paper mill similar to the Israeli group that keeps dropping slight variations of the same covert channel research every couple of months.
- wtallis 5y ago
  I agree that the "attack" as described by the article is nonsense. However, it's only missing a few ingredients necessary to be an actual threat model. When you're already postulating the abuse of a vendor-specific feature to (somewhat unreliably) hide data, it's not much of a stretch to also hypothesize an attack against the SSD firmware, gaining control over the drive and its numerous ARM cores. This would make it theoretically possible to make the attack much more durable, by incorporating the rootkit into the operation of the SSD itself and protecting its data from being overwritten. For NVMe SSDs that have DMA capability and aren't trapped behind an IOMMU or are given the opportunity to provide an option ROM for the host to run during boot, this could definitely cause trouble for the system as a whole. I suspect there are still a lot of client SSDs out there that lack an effective secure boot protection for their own firmware. Such an attack requires the resources of a state actor, and could only attack a narrow range of systems (those using a particular model of SSD), and requires a separate successful supply-chain attack or other exploit to initially infect the drive. But once infected, SSDs are a pretty good place to hide malicious code and data, because they have plenty of storage, their own processing resources and copious RAM, access to all your data (unless encrypted on the CPU), and is beyond the scope of what antivirus software monitors. And they can potentially interact with the rest of the system, which is why we really need to see IOMMU support taken more seriously. The ability for your NIC and SSD to talk to each other without getting the CPU involved is really cool—when done for the right reasons.
  - marcan_42 5y ago
    Oh, you're absolutely right that modifying SSD firmware gives you a lot of fun possibilities for hijacking a machine, but that is not new either, it's a threat vector that has been known and investigated for many years now. Here's someone running Linux on an HDD controller in 2013: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1 It's well known that SSD vendor security is usually atrocious; these companies do not have much experience building secure-boot systems, and there are often vendor-specific backdoor commands and such. You absolutely do not need the resources of a state actor to pull that off; a good reason and 5-6 digits' worth of (competent) security researcher time ought to do it. I've spent half of my life breaking systems that try a lot harder to have secure boot than SSDs, as a hobby. Indeed, IOMMU support is critical in the modern hardware ecosystem. Honestly, any system that does not use them by default for all off-chip peripherals in 2021 is just unsuitable for any kind of sensitive use case. That, plus FDE with hashtree authentication, eliminates SSD compromise as an attack vector.

gruez 5y ago

>It appears as though the attack is based on the assumption that you have admin level access to the computer. Ah yes, the famous "it rather involved being on the other side of this airtight hatchway" that raymond chen talks about. https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98115 https://devblogs.microsoft.com/oldnewthing/20180227-00/?p=98...

13of40 5y ago
Yeah, and I'm not really seeing the advantage of doing this versus just encrypting the data and storing it in normal filesystem space. Maybe that whoever has to write an anti-evasion for it now has to be able to look in this unallocated space on the SSD, and there's no easy API to use?
- marcan_42 5y ago
  The malware has to exist outside the OP area to be able to infect the host, otherwise it would never run. Antimalware can just look for that bit. All this really does is let you increase the amount of storage malware can potentially use; it doesn't hide the core, which has to live in the normal area.
- deleted 5y ago
  [deleted]

dang 5y ago

Ok, we've changed the title above (to one suggested by a user who emailed—thanks!)