
First Sednit UEFI Rootkit Unveiled [video] - jonathankoren
https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_unveiled
======
ddevault
UEFI is perhaps the single most egregious pile of garbage ever concieved by
humans. I don't think it's possible to overstate how awful it truly is.

Here's how BIOS works: basically, the computer loads the first 512 bytes of
disk into memory and jumps to it. The OS takes over from there and does
whatever it needs to, like bootstrapping stage 2 and loading the kernel from
the filesystem. The spec[0] is 46 pages long and you are granted the rights to
reproduce, distribute, and implement it free of charge.

Want to know how UEFI works? The spec[1] is a 2,899 page PDF which you have to
pay to use in any way, including writing an implementation.

[0]
[https://web.archive.org/web/20110715081320/http://www.phoeni...](https://web.archive.org/web/20110715081320/http://www.phoenix.com/resources/specs-
bbs101.pdf)

[1] [https://uefi.org/specifications](https://uefi.org/specifications)

Every copy of this specification should be found and burned. The ashes should
be buried deep in a dark place and the earth above salted. Anyone who thinks
this is the first rootkit made for it is completely insane. This thing was
probably explicitly designed with rootkits in mind.

~~~
peter_d_sherman
Agreed completely.

But remember Hanlon's Razor: "Never attribute to malice that which is
adequately explained by stupidity"
([https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)).

UEFI smells like it was designed by a committee, so the value it adds (if any)
seems far outweighed by the added complexity (and corresponding security
challenges) it creates... to paraphrase Douglas Adams: (and replacing the word
"Universe" with "BIOS":)

“There is a theory which states that if ever anyone discovers exactly what the
BIOS is for and why it is here, it will instantly disappear and be replaced by
something even more bizarre and inexplicable... There is another theory which
states that this has already happened...” <g>

~~~
duckMuppet
Don't forget the corollary to Hanlon's razor, Grey's law which i think is far
more applicable here: 'Any sufficiently advanced incompetence is
indistinguishable from malice'.

I'm not sure why others who respond think if something is old it isn't
applicable, I suppose I'm on the X/millennial border so I don't get it though.

------
CaliforniaKarl
Hmmm, looking at the post from u/voltagex_, I'd suggest changing the URL to
[https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_u...](https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_unveiled),
and changing the title to "First Sednit UEFI Rootkit Unveiled".

The original URL ([https://threatpost.com/uefi-rootkit-
sednit/140420/](https://threatpost.com/uefi-rootkit-sednit/140420/)) looks
like a short writeup, but I'm not sure if it adds any new content. And given
the tendency to link back directly to source, it's probably worth a change.

~~~
dang
Ok, we changed the URL from [https://threatpost.com/uefi-rootkit-
sednit/140420/](https://threatpost.com/uefi-rootkit-sednit/140420/).

Looks like this work was discussed a few months ago:
[https://news.ycombinator.com/item?id=18090651](https://news.ycombinator.com/item?id=18090651)

------
voltagex_
Writeup: [https://www.welivesecurity.com/wp-
content/uploads/2018/09/ES...](https://www.welivesecurity.com/wp-
content/uploads/2018/09/ESET-LoJax.pdf)

Video:
[https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_u...](https://media.ccc.de/v/35c3-9561-first_sednit_uefi_rootkit_unveiled)

------
atswimtwobirds
Will this rootkit run on Linux?

~~~
bcl
The UEFI payload would work on Linux systems, yes. But the delivery system
described would not.

~~~
atswimtwobirds
>> It abuses platforms that do not implement the BIOS Write Lock mechanism
incorrectly

I agree that post-boot the BIOS should be read-only.

> The UEFI payload would work on Linux systems, yes. But the delivery system
> described would not.

There was a case of rm -rf / erasing UEFI variables on linux system, rendering
the system unbootable. Mapping the BIOS into the file-system doesn't strike me
as too clever, but then again what do I know.

------
mises
New article, but it's old news:
[https://www.welivesecurity.com/2018/09/27/lojax-first-
uefi-r...](https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-
found-wild-courtesy-sednit-group/)

------
lelandgaunt
> The purpose of the legitimate LoJack software is to help victims of a stolen
> laptop be able to access their PC without tipping off the bad guys who stole
> it.

Promise?

------
aortega
Isn't this computrace repurposed? this research is about 10 years old.
[https://www.blackhat.com/presentations/bh-
usa-09/ORTEGA/BHUS...](https://www.blackhat.com/presentations/bh-
usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf)

------
cjhanks
I hope it's not too off topic. But on Linux systems with NVIDIA drivers - is
it even possible/reasonable to re-enable secure boot?

~~~
mjg59
Yes, you can add a key with mokutik and sign your locally built drivers.

~~~
bubblethink
But does it buy you any real security at that point ? If the private key is
stored on the file system, a local root exploit can just as easily use the key
to sign whatever it wants. I don't even see the benefit or the threat model of
secureboot on regular linux disros.

~~~
Xylakant
Don’t store the private key on the local filesystem then. Use a USB stick or
build and sign the modules on a separate machine. Depending on your threat
model, a strong passphrase on the signing key might already go a long way.

~~~
bubblethink
I'm no so sure about that. Unless you are using an android/chromeos like
system, secureboot alone itself is quite ineffective to begin with because
your filesystem is writable. And keeping the private key elsewhere, while
possible in theory, would just add too much friction. For instance, apt
install nvidia-xxx won't work.

~~~
Xylakant
Sure, security adds friction. Whether the added friction is worth the added
security in your case depends on the amount of friction and the amount of
security it buys you. The trade off is likely different for you than it is for
a larger org. For example, you (or the admins responsible for your org) could
maintain an apt repo with signed nvidia drivers for your org. This would
reduce the friction by centralizing the signing process.

I keep my signing key on my machine, but gpg-encrypted bound to a yubikey. Is
that frictionless? No, certainly not. Does it provide perfect security? No,
certainly not. A dedicated attacker can root my box and wait until I need to
sign a module. Does it protect me from loading random kernel modules if I get
hit by an automated attack? Most likely. Good enough for what I currently
expect as threats.

------
CaliforniaKarl
Ah, interesting video! Now I've got something to watch/listen to while I'm on
the bus today.

------
gammateam
Its interesting that nobody does a SHOW HN on their rootkits on Hackernews

Instead third party stuff like this comes very occassionally

The name is a misnomer

~~~
hug
Only because you're completely unaware of the history of the word "hacker"; It
certainly doesn't just mean someone who breaks into other computers.

Reading the old Jargon File entry for the word might clue you in:
[http://www.catb.org/jargon/html/H/hacker.html](http://www.catb.org/jargon/html/H/hacker.html)

~~~
gammateam
Nah, that doesnt actually explain whats going on now

A) Either people dont post that kind of stuff here, which is still ironic
anytime this century

B) People do post and it doesn't get upvoted

C) People do post and it gets moderated away

~~~
rbanffy
I don't think it's ironic at all. It's just that most of us may be a different
kind of hacker.

~~~
gammateam
Right......

I get that it was an all encompassing term, but it hasnt been colloquially
this entire century

But to be fair, the Pedantic News wouldnt be a misnomer

