Author Topic: UEFI rootkits  (Read 5147 times)

0 Members and 1 Guest are viewing this topic.

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7673
  • Country: de
  • A qualified hobbyist ;)
UEFI rootkits
« on: July 28, 2022, 06:58:07 pm »
Discovery of new UEFI rootkit exposes an ugly truth: The attacks are invisible to us (https://arstechnica.com/information-technology/2022/07/researchers-unpack-unkillable-uefi-rootkit-that-survives-os-reinstalls/)
 
The following users thanked this post: Ed.Kloonk, bitwelder, MrMobodies

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6686
  • Country: nl
Re: UEFI rootkits
« Reply #1 on: July 28, 2022, 07:21:46 pm »
I want my write protect jumper back.
 
The following users thanked this post: free_electron, Ed.Kloonk, Halcyon

Offline twospoons

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: UEFI rootkits
« Reply #2 on: July 28, 2022, 09:48:34 pm »
I want my write protect jumper back.

Me too. Its such a ridiculously simple solution to bios security. 
 
The following users thanked this post: Ed.Kloonk, MrMobodies

Offline MrMobodies

  • Super Contributor
  • ***
  • Posts: 1901
  • Country: gb
Re: UEFI rootkits
« Reply #3 on: July 29, 2022, 06:16:27 am »
Quote
Researchers have unpacked a major cybersecurity find—a malicious UEFI-based rootkit used in the wild since 2016 to ensure computers remained infected even if an operating system is reinstalled or a hard drive is completely replaced.

Oh dear.

So even if I install an operating system in "non UEFI" mode on a "UEFI" system and someone downloaded and run it, I wonder would it still be able to operate from the firmware despite it not booting from UEFI?.

Quote
While researchers from fellow security firm Qihoo360 reported on an earlier variant of the rootkit in 2017, Kaspersky and most other Western-based security firms didn’t take notice. Kaspersky’s newer research describes in detail how the rootkit—found in firmware images of some Gigabyte or Asus motherboards—is able to hijack the boot process of infected machines. The technical underpinnings attest to the sophistication of the malware.

Does that mean that older "non UEFI" systems are going to be a bit more safer from this kind of vulnerability?

It seems like the same pattern to me where certain features are introduced that are out of the user's control and can end up working against them.
« Last Edit: July 29, 2022, 06:19:33 am by MrMobodies »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6130
  • Country: fi
    • My home page and email address
Re: UEFI rootkits
« Reply #4 on: July 29, 2022, 07:36:54 am »
I want my write protect jumper back.
Me too. Its such a ridiculously simple solution to bios security.
Me three.

Cryptographic signature checking won't fix this, either.  Large companies have shown that they just cannot keep the private keys sufficiently private; they always leak, humans being humans.
 
The following users thanked this post: Ed.Kloonk

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2213
  • Country: 00
Re: UEFI rootkits
« Reply #5 on: July 29, 2022, 07:42:20 am »
Rootkit detection is difficult because a rootkit may be able to subvert the
software that is intended to find it. Detection methods include using an
alternative and trusted operating system, behavioral-based methods, signature
scanning, difference scanning, and memory dump analysis. Removal can be
complicated or practically impossible, especially in cases where the rootkit
resides in the kernel; reinstallation of the operating system may be the only
available solution to the problem.

Operation "Red October" was able to stay under the radar for five years:

https://securelist.com/the-red-october-campaign/57647/

Antivirus software is now so ineffective at detecting new malware threats
most enterprises are probably wasting their money buying it, an analysis
by security firm Imperva has concluded.


http://www.cio.com/article/2390136/antivirus-software/antivirus-software-a-waste-of-money-for-businesses--report-suggests.html

Antivirus tools are a useless box-ticking exercise says Google security chap
Advocates whitelists and other tools that 'genuinely help' security

http://www.theregister.co.uk/2016/11/17/google_hacker_pleads_try_whitelists_not_just_bunk_antivirus_ids/

Several Symantec AV products allow an attacker to run arbitrary code under Linux, MacOS and WIndows. Yes, it's really bad. Affected products are Symantec Endpoint Protection Cloud Client, Symantec Endpoint Protection Small Business Enterprise Client, Norton Family, Norton Antivirus, Norton AntiVirus with Backup, Norton Security, Norton Security with Backup, Norton Internet Security and Norton 360.

DoubleAgent: Taking Full Control Over Your Antivirus

http://www.theregister.co.uk/2017/07/31/ai_defeats_antivirus_software/

https://www.welivesecurity.com/2017/08/30/eset-research-cyberespionage-gazer/
 
The following users thanked this post: Ed.Kloonk

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6136
  • Country: ro
Re: UEFI rootkits
« Reply #6 on: July 29, 2022, 08:22:27 am »
I want my write protect jumper back.

You can not have a write protect jumper.
It almost look like a conspiracy.  :-//


This was supposed to be a metaphor, but with each year:



I don't say it's aliens, but it's aliens.
 
The following users thanked this post: Ed.Kloonk

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #7 on: July 29, 2022, 08:36:13 am »
It should be a surprise?

UEFI was meant insecure
Can boot anything remotely by http..

How other way TAG PROPRIETARY SECURE CHIPS  would be forced? And paid by users

Old BIOS are order of magnitide safer..
Orders...

Paul
 
The following users thanked this post: Ed.Kloonk

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6130
  • Country: fi
    • My home page and email address
Re: UEFI rootkits
« Reply #8 on: July 29, 2022, 10:20:12 am »
Perhaps it is time to throw some love towards coreboot, then?
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #9 on: July 29, 2022, 11:53:31 am »
Perhaps it is time to throw some love towards coreboot, then?

I have few expectations and hopes for the x86 (aka Wintel) platform future

Obviously they paved a way to lock every human out there to boot the hardware and  have working drivers  (aka firmware blobs) that guarantee their milking machine continue working as intended.. ( fast pace obsolescence .. locked formats of audio video.. license managers... etc)

PHORONIX made a simple but realistic post
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1337624-gnome-to-warn-users-if-secure-boot-disabled-preparing-other-firmware-security-help

Only allowed "partners"  playing by these secure rules will actually have a working system.

Outside that? forget it.. it will be a joke of the very same film they repeat..

TPM/IOMU/lcoked signed keys and chips... 

I am already searching a new safe ground to land...
fuck off again

Paul
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6130
  • Country: fi
    • My home page and email address
Re: UEFI rootkits
« Reply #10 on: July 29, 2022, 01:43:30 pm »
Perhaps it is time to throw some love towards coreboot, then?
I have few expectations and hopes for the x86 (aka Wintel) platform future
Well, coreboot can neutralize Intel Management Engine, and LibreBoot in particular has no firmware blobs at all.  See libreboot FAQ and coreboot motherboard list.

But yeah, ARM in particular is in a much better position, wrt. implementations that push their support upstream to mainline Linux, and do not rely on binary blobs.  There are surprisingly many of them.  (In particular, Mali OpenGL ES hardware support provided by open source Lima (Mali 400 and 450) drivers, or possibly by Panfrost (Mali T6xx/T7xx/T8xx and G3x/G5x/G7x) drivers which may or may not be stable enough for general use yet.  Mali 400/450 should work well, though.  If I were to think about how to efficiently separate computation and display rendering with a concise compositor/protocol, I'd definitely start by looking at what OpenGL ES 2.0 provides, as that's what Mali 400/450 supports.)

I'm worried about ARM's future too, though.  The NVidia takeover would have ended ARM open-source support for sure.

Risc-V is a bright spark, although it could be subverted by Intel ME/AMD PSP -type implementation.  @brucehoult would know a lot more about this.
 
The following users thanked this post: bitwelder, DiTBho

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #11 on: July 29, 2022, 03:21:13 pm »
(..)
But yeah, ARM in particular is in a much better position, wrt. implementations that push their support upstream to mainline Linux, and do not rely on binary blobs.  There are surprisingly many of them.

(.)

I am also looking all possible ARM diverted alternatives.. for quite some time

MediaTek is hopeless as they are just consumer  DRM interfaces for now...

And the only possible x86 alternative (A...M....D...)  has gone complete out of balls ..
e.g.  there is no  ballsy leadership for a long time in amd..

They can shift the whole x86 scenario..  with enough balls to compete Wintel

**OR**
https://www.techpowerup.com/297299/us-congress-passes-the-chips-and-science-act

perhaps things will just sink deeper in the same shit... as they are

Paul
« Last Edit: July 29, 2022, 03:24:16 pm by PKTKS »
 

Offline AndyBeez

  • Frequent Contributor
  • **
  • Posts: 853
  • Country: nu
Re: UEFI rootkits
« Reply #12 on: July 29, 2022, 05:05:41 pm »
My reading is the rootkit is on the SPI flash containing the UEFI bootstrapper. So how did it get onto the SPI flash in the first place? Seems more of a state sponsored firmware upgrade in the supply chain, rather than the homework of some random hacksters.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #13 on: July 29, 2022, 05:12:32 pm »
My reading is the rootkit is on the SPI flash containing the UEFI bootstrapper. So how did it get onto the SPI flash in the first place? Seems more of a state sponsored firmware upgrade in the supply chain, rather than the homework of some random hacksters.

They are F**** forcing everyone to their rules...

FORCED  firmware upgrade - simple procedure done by the host ..
download and reflash the firmware... 

at their will  no longer  the user decides...

same deceptive argument SECURITY

matter of fact:  older BIOS are orders mag more secure

Paul
 
The following users thanked this post: MrMobodies

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: UEFI rootkits
« Reply #14 on: July 29, 2022, 07:21:29 pm »
I want my write protect jumper back.

Me too. Its such a ridiculously simple solution to bios security.

They never meant to make it secure. The goal was to make it "reasonably secure" while allowing third-parties to update your system behind your back, while before, you actually had to take a number of manual steps to do this. Which is already a very questionable goal in itself, but it doesn't take a genius to figure out that if it is at all possible to update your system behind your back, then anybody will eventually be able to.
 
The following users thanked this post: MrMobodies

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3772
  • Country: gb
Re: UEFI rootkits
« Reply #15 on: July 29, 2022, 09:07:18 pm »
If I were to think about how to efficiently separate computation and display rendering with a concise compositor/protocol, I'd definitely start by looking at what OpenGL ES 2.0 provides, as that's what Mali 400/450 supports.)

That's a great idea!

p.s.
look at IBM POWER10 and POWER11
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11518
  • Country: my
  • reassessing directives...
Re: UEFI rootkits
« Reply #16 on: July 29, 2022, 10:18:05 pm »
My reading is the rootkit is on the SPI flash containing the UEFI bootstrapper. So how did it get onto the SPI flash in the first place? Seems more of a state sponsored firmware upgrade in the supply chain, rather than the homework of some random hacksters.
https://securelist.com/cosmicstrand-uefi-firmware-rootkit/106973/ from the OP's link..
Quote
Affected devices

Although we were unable to discover how the victim machines were infected initially, an analysis of their hardware sheds light on the devices that CosmicStrand can infect. The rootkit is located in the firmware images of Gigabyte or ASUS motherboards, and we noticed that all these images are related to designs using the H81 chipset. This suggests that a common vulnerability may exist that allowed the attackers to inject their rootkit into the firmware’s image.

In these firmware images, modifications have been introduced into the CSMCORE DXE driver, whose entry point has been patched to redirect to code added in the .reloc section. This code, executed during system startup, triggers a long execution chain which results in the download and deployment of a malicious component inside Windows.

Looking at the various firmware images we were able to obtain, we assess that the modifications may have been performed with an automated patcher. If so, it would follow that the attackers had prior access to the victim’s computer in order to extract, modify and overwrite the motherboard’s firmware. This could be achieved through a precursor malware implant already deployed on the computer or physical access (i.e., an evil maid attack scenario). Qihoo’s initial report indicates that a buyer might have received a backdoored motherboard after placing an order at a second-hand reseller. We were unable to confirm this information.
it just happen i'm using Asus H81 MB, so i hope there is a way of knowing if the UEFI is infected or not from an antivirus, so we know when to buy a new motherboard. and hopefully the rootkit wont simply propagate through an app from within Windows/OS.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline AndyBeez

  • Frequent Contributor
  • **
  • Posts: 853
  • Country: nu
Re: UEFI rootkits
« Reply #17 on: July 30, 2022, 09:01:19 am »
I would be interested to know where those mobos where manufactured. One supply chain 'overlap' for both Asus and Gigabyte is Taiwan; a territory that China has long wanted to annex. But as Qihoo suggests, there may be a bad actor in the retail chain.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #18 on: July 30, 2022, 09:24:16 am »
Will not assume such restric scope

I have a half dozen Biostar mobos which very much alike use the same layout chipset and firmware manufacturer...

I doubt of such restrictions

Paul
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11518
  • Country: my
  • reassessing directives...
Re: UEFI rootkits
« Reply #19 on: July 30, 2022, 10:09:32 am »
I would be interested to know where those mobos where manufactured. One supply chain 'overlap' for both Asus and Gigabyte is Taiwan; a territory that China has long wanted to annex. But as Qihoo suggests, there may be a bad actor in the retail chain.
i got my mobo in 2015, if the rootkit came from factory, i'm not sure its effectiveness on newer windows10/11. i did upgrade the firmware some years ago, if the rootkit is embedded in the image file, there must be a way of detecting it... but then, its not my normal joe skill. i'll keep my faith on my avast antivirus... most importantly the rootkit will call home to its C2 server to get its payload, i think we can detect if our PC will try to call that server right? as long as it doesnt touch my personal files, i think i wont worry too much...
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline AndyBeez

  • Frequent Contributor
  • **
  • Posts: 853
  • Country: nu
Re: UEFI rootkits
« Reply #20 on: July 30, 2022, 11:22:46 am »
I would be interested to know where those mobos where manufactured. One supply chain 'overlap' for both Asus and Gigabyte is Taiwan; a territory that China has long wanted to annex. But as Qihoo suggests, there may be a bad actor in the retail chain.
i got my mobo in 2015, if the rootkit came from factory, i'm not sure its effectiveness on newer windows10/11. i did upgrade the firmware some years ago, if the rootkit is embedded in the image file, there must be a way of detecting it... but then, its not my normal joe skill. i'll keep my faith on my avast antivirus... most importantly the rootkit will call home to its C2 server to get its payload, i think we can detect if our PC will try to call that server right? as long as it doesnt touch my personal files, i think i wont worry too much...
Having a payload server is always the weakest link; the URI can be blocked or even confiscated by ICANN. It also points a finger at the threat sponsor. This rootkit was deployed as an under the radar attack that assumed no one had the skillset to notice; given the over reliance on anti virus software. And then someone did.

I have no idea what the flash hardware is on those mobos -could not decipher a target from H81 mobo images? SPI Soic chip would be nice, as this can be 'clamped' - as per vehicle ECU hacks. So is this a threat? Only if that C2 server is hot.

Any of you PC geeks know of a BIOS probe toolkit that can hex dump the flash without opening the case?
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11518
  • Country: my
  • reassessing directives...
Re: UEFI rootkits
« Reply #21 on: July 30, 2022, 12:30:44 pm »
So is this a threat? Only if that C2 server is hot.
Any of you PC geeks know of a BIOS probe toolkit that can hex dump the flash without opening the case?
and only if they have access to your PC or you click the firmware update from manufacturer through uefi bios utility. i think dumping flash from mobo is not necessary as they can just temper the original bios update image file with their rootkit code. but as the article stated, this is not a normal joe cracker can do it, a slight error in the code can render the mobo unbootable/crash.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline gamalot

  • Super Contributor
  • ***
  • Posts: 1296
  • Country: au
  • Correct my English
    • Youtube
Re: UEFI rootkits
« Reply #22 on: July 30, 2022, 12:39:05 pm »
I want my write protect jumper back.

I'm not very familiar with those Flash chips used to store BIOS code, I guess hardware write protection and QPI operation maybe not compatible.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6130
  • Country: fi
    • My home page and email address
Re: UEFI rootkits
« Reply #23 on: July 30, 2022, 01:39:26 pm »
I want my write protect jumper back.
I'm not very familiar with those Flash chips used to store BIOS code, I guess hardware write protection and QPI operation maybe not compatible.
The ones with a parallel interface, e.g. Kioxia TC58B series, still have a separate write protect pin.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: UEFI rootkits
« Reply #24 on: July 31, 2022, 11:32:59 am »

only if they have access to your PC or you click the firmware update from manufacturer through uefi bios utility.


AFAIK recently hosts  (read  M MM MM SSS) can do that transparently from the OS unattended and without any sort of required permission..  At their will...   (although we all know there is always a nice button and cute thing somewhere telling you they respect ... etc_etall )

Paul
 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf