First UEFI rootkit found in the wild

[Solaris17]

This shit is so cool.

https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/

 

[StrayKAT]

This shit is so cool.

https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/

It seems SecureBoot prevents this.

edit: Geez.. political edit? I'm calling out the strangeness of this Sednit group. Oh well.

 

[eidairaman1]

This shit is so cool.

https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/

Someone had something recently, you can ask @R-T-B

 

[Solaris17]

Someone had something recently, you can ask @R-T-B

That conversation is certainly separate and I have no comment on it.

I think security as a whole has started a great shift since around 2015-16 and we are going to see more crazy, more advanced threats. As for UEFI modifications and infections, I am sure this is only the beginning.

Not to fear monger of course just trending after all. Gone are the days of simple virus' todays infections are waged on the silicon level.

 

[eidairaman1]

That conversation is certainly separate and I have no comment on it.

I think security as a whole has started a great shift since around 2015-16 and we are going to see more crazy, more advanced threats. As for UEFI modifications and infections, I am sure this is only the beginning.

Not to fear monger of course just trending after all. Gone are the days of simple virus' todays infections are waged on the silicon level.

Yep that's true it was a virus than the worm and now the rootkit and a Trojan can contain them all at once make you a zombie on a botnet a boot firmware rootkit

Yep that's true it was a virus than the worm and now the rootkit and a Trojan can contain them all at once make you a zombie on a botnet a boot firmware rootkit

I think what's going on need to happen is that they're going to have to have a hash verifier on a non eeprom firmware

 

[hat]

All this could be avoided by adding a simple switch that either allows or blocks writes to the ROM (like floppy discs had).

...Why did they have that, anyway?

 

[Deleted member 6693]

All this could be avoided by adding a simple switch that either allows or blocks writes to the ROM (like floppy discs had).

...Why did they have that, anyway?

To avoid accidental overwrites...I remember our old mainframe - it ran on 5 1/4 floppies - all where write protected (done with removal of a small tape on the side notch)

 

[R-T-B]

That conversation is certainly separate and I have no comment on it.

I think security as a whole has started a great shift since around 2015-16 and we are going to see more crazy, more advanced threats. As for UEFI modifications and infections, I am sure this is only the beginning.

Not to fear monger of course just trending after all. Gone are the days of simple virus' todays infections are waged on the silicon level.

Everything is moving to the UEFI level because UEFI chips are suddenly at minimum, 16MBs. You can fit a fully functional linux kernel in there and believe me malware writers are thrilled.

The two cases are not related but the reason they are able to happen is the same.

It seems SecureBoot prevents this.

As I learned during my support incident, if it can reflash your BIOS, it can also toggle secure boot off in the same action.

 

[StrayKAT]

Everything is moving to the UEFI level because UEFI chips are suddenly at minimum, 16MBs. You can fit a fully functional linux kernel in there and believe me malware writers are thrilled.

The two cases are not related but the reason they are able to happen is the same.



As I learned during my support incident, if it can reflash your BIOS, it can also toggle secure boot off in the same action.

Out of curiosity, once it does that, you couldn't reflash again yourself (assume you knew you were infiltrated)?

 

[R-T-B]

Out of curiosity, once it does that, you couldn't reflash again yourself (assume you knew you were infiltrated)?

The whole thread is documented here on TPU. Basically software flashing was completely unreliable and you couldn't trust the board to tell you a single factual thing about what was going on (it would claim to flash but do nothing). I had to have him send it in to me for a hardware flasher job, which fixed it.

Of course different rootkits have different capabilities. This one appeared tailor built to target my client, and never reached the wild.

 

[Solaris17]

Out of curiosity, once it does that, you couldn't reflash again yourself (assume you knew you were infiltrated)?

Incidentally modifying the default setting in a BIOS to enable/disable secureboot as with any other setting in the bios, also allows you to modify the default setting regarding write permissions, should the system have the ability to control it via BIOS setting.

So in practice you could.

Infect BIOS that has "Allow BIOS overwrite" > Enabled
and
"Secure boot" > On
with a malicious file that changed

"Allow BIOS overwrite" disabled

"Secure Boot" off

Infact alot of BIOS allow you to do a form of this when backing up settings in your "OC Profile" on the boards iv actually tested with this backs up EVERY setting, not just those modified in the OC/clock rate/MIT pages.

Not that @R-T-B s thread has alot to do with subject, he has a whole thread on it already for it to be included here.

Some really neat stuff though. In all of my studies Firmware is my absolute favorite.

 

[AlwaysHope]

Interestingly, got MS update for AMD secure boot today... Link