Hacker News new | ask | show | jobs
Linux Malware “Drovorub” developed by Russian exposed by NSA and FBI (nsa.gov)
34 points by richardowright 2139 days ago
4 comments

Note that "drovorub" isn't even a Russian word, "drovosek" is. It means "woodcutter".
Seeing a translation of "(security) driver slayer".

https://twitter.com/DAlperovitch/status/1293948157618003969

Why would a natively Russian speaking team misspell this word? Is it possible this software wasn't developed in Russia/by Fancy Bear or that it's some sort of play on words that I don't understand as an English speaker?
The article says it’s a composite of two recovered strings from one of the malicious programs involved. So I wouldn’t read too much into it

Edit: sorry, this article, which we on another thread https://arstechnica.com/information-technology/2020/08/nsa-a...

"pravdosek"
Did you mean "pravdorub"?
<quote> Preventative Mitigations

NOTE: The mitigations that follow are not meant to protect against the initial access vector. The mitigations are designed to prevent Drovorub’s persistence and hiding technique only.

Apply Linux Updates

System administrators should continually check for and run the latest version of vendor-supplied software for computer systems in order to take advantage of software advancements and the latest security detection and mitigation safeguards (National Security Agency, 2018). System administrators should update to Linux Kernel 3.7 or later in order to take full advantage of kernel signing enforcement.

Prevent Untrusted Kernel Modules

System owners are advised to configure systems to load only modules with a valid digital signature making it more difficult for an actor to introduce a malicious kernel module into the system. An adversary could use a malicious kernel module to control the system, hide, or persist across reboots (National Security Agency, 2017).

Activating UEFI Secure Boot is necessary to ensure that only signed kernel modules can be loaded. This requires a UEFI-compliant platform configured in UEFI native mode (not legacy or compatibility modes) in Thorough or Full enforcement mode. Once enabled, Secure Boot creates an integrity chain at boot by verifying signatures of firmware, bootloader(s), and Machine Owner Key (MOK). The kernel, initial filesystem, and kernel modules are then verified by this MOK, which is distributed with Secure Boot-ready Linux distributions. Components with untrusted or absent signatures are denied from execution by Secure Boot policy. Enabling Secure Boot may prevent some products from loading, potentially affecting system functionality, and may require custom configuration (National Security Agency, 2017). </quote>

> kernel module

If you're running a module-enabled kernel then you were already pwned to begin with; nothing to see here. There is absolutely no need for modules except on live cds and the like. Of course, kernel configuration is another huge headache; don't get me wrong.

Can someone explain this? I have DKMS enabled because I use the proprietary nvidia drivers. Also all my drivers are kernel modules. I feel like I'm missing something here, though.
If you use proprietary binary code in kernel, it runs with high privileges and can be used to provide remote root access to your system. Don't worry much about it, your computer most probably already runs proprietary binary code with such high privileges before your OS boots.
While I’ve certainly enjoyed running all compiled-in kernels in the past, I think it’s a bit inflammatory to suggest that there’s no need for modules, when literally every major Linux distro I have ever seen in production (outside of certain embedded devices) has a modular kernel. There’s a good reason for that...
The Cybersecurity Advisory link in the first line of the article is worth a read for a greater insight as to why it might be more than just 'pfft, nothing to see here' regarding kernel modules
Can you please explain the security issue with module-enabled kernels?
¿Do they seriously expect us to believe this neocon cyber BS?