XPost: alt.comp.os.windows-11

From Ars Technica:

In 2012, an industry-wide coalition of hardware and software makers
adopted Secure Boot to protect against a long-looming security
threat. The threat was the specter of malware that could infect the
BIOS, the firmware that loaded the operating system each time a
computer booted up. From there, it could remain immune to detection
and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and
fueled in large part by the creation of ICLord Bioskit by a Chinese
researcher in 2007. ICLord was a rootkit, a class of malware that
gains and maintains stealthy root access by subverting key
protections built into the operating system. The proof of concept
demonstrated that such BIOS rootkits weren't only feasible; they were
also powerful. In 2011, the threat became a reality with the
discovery of Mebromi, the first-known BIOS rootkit to be used in the
wild.

...

On Thursday, researchers from security firm Binarly revealed that
Secure Boot is completely compromised on more than 200 device models
sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a
cryptographic key underpinning Secure Boot on those models that was
compromised in 2022. In a public GitHub repository committed in
December of that year, someone working for multiple US-based device manufacturers published what?s known as a platform key, the
cryptographic key that forms the root-of-trust anchor between the
hardware device and the firmware that runs on it. The repository was
located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and
it's not clear when it was taken down.

The repository included the private portion of the platform key in
encrypted form. The encrypted file, however, was protected by a four-
character password, a decision that made it trivial for Binarly, and
anyone else with even a passing curiosity, to crack the passcode and
retrieve the corresponding plain text. The disclosure of the key went
largely unnoticed until January 2023, when Binarly researchers found
it while investigating a supply-chain incident. Now that the leak has
come to light, security experts say it effectively torpedoes the
security assurances offered by Secure Boot.

?It?s a big problem,? said Martin Smolár, a malware analyst
specializing in rootkits who reviewed the Binarly research and spoke
to me about it. ?It?s basically an unlimited Secure Boot bypass for
these devices that use this platform key. So until device
manufacturers or OEMs provide firmware updates, anyone can basically?
execute any malware or untrusted code during system boot. Of course,
privileged access is required, but that?s not a problem in many
cases.?

Binarly researchers said their scans of firmware images uncovered 215
devices that use the compromised key, which can be identified by the certificate serial number
55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. A table appearing at
the end of this article lists each one.

Full article, apparently not behind a paywall: <https://arstechnica.com/security/2024/07/secure-boot-is-completely- compromised-on-200-models-from-5-big-device-makers>

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

Stan,

"Secure Boot is completely broken on 200+ models from 5 big device makers"

Would you call your front door "completely broken" when you find someone
found a key which will also open it ? Or would you just replace the key
(and locks cylinder) with another one ?

IOW, clickbait. The door isn't broken, and not even its lock is.

Granted, replacing that particular, compromised, key will be problematic.

... and there you've got a nice example of how stuffing software on someones motherboard that cannot (isn't /allowed/ to be!) accessed by the owner of it creates its own problems.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

Stan Brown <the_stan_brown@fastmail.fm> wrote:

From Ars Technica:

In 2012, an industry-wide coalition of hardware and software makers
adopted Secure Boot to protect against a long-looming security
threat. The threat was the specter of malware that could infect the
BIOS, the firmware that loaded the operating system each time a
computer booted up. From there, it could remain immune to detection
and removal and could load even before the OS and security apps did.

Microsoft built a backdoor in UEFI that can be used for software
inventorying, tracking, and by malware. While the executable is stored
in the UEFI, it can't do anything until Windows detects its presence,
and then runs it during startup. Microsoft built in a UEFI rootkit.

A "feature" of UEFI (with Microsoft's involvement) is a program can be specified in the UEFI to run on Windows startup. Despite regulating any startup programs, or scanning for malware, there could sit a call to a
program in the UEFI. It could, for example, be used for starting
execution of tracking software (how the computer is used), or for
software inventorying on workstations. I've only seen it used by
companies that wanted to add usage tracking, location, anti-theft, or inventorying to their workstations. However, it could also be used by
malware, and I don't know if any AVs check for a program load specified
in the UEFI. As I recall, some mobos (Lenovo, Gigabyte, ASUS) use this
trick to run services or diagnostics on Windows startup. The AV should
catch malware for whatever the UEFI program load specifies; that is, the
.exe in UEFI usually calls some other program that runs under Windows.

It is a "feature" only with UEFI. When Windows loads, it has a program (C:\Windows\system32\wpbbin.exe) that runs to determine if the UEFI
specified a start program. The UEFI start program is in one of the ACPI
tables in the BIOS. One trick is to rename the loader program in
Windows called the UEFI Bootkit dubbed BlackLotus.

You can Nirsoft's Firmware Tables View to see the ACPI tables in UEFI.
Look for the "Windows Platform Binary Table" (WPBT). Nirsoft will show
the ACPI table, if it is defined, but won't let you delete it. When I
found out about this, Nirsoft didn't show a WPBT table, but then I have
many options disabled in the BIOS. I also don't have the wpbbin.exe
program (that checks the UEFI for an .exe file to load) in my Windows installation.

Although pundits attempt to tout UEFI, Secure Boot, and other later
security measures as protecting users, there are UEFI Bootkits that
bypass all those measures, even Secure Boot, like BlackLotus.

https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/

Those are different beasts than the UEFI program load specified in an
ACPI table that Windows checks if it is defined, and if found will run
the UEFI-specified program. I'm noting the UEFI program load on Windows
launch because refurbs often are company workstations that were leased,
and then disposed of. Companies may employ tracking, location, or
software inventorying that the Windows-loaded UEFI-specified program
will start. You won't find that method listed in, say, SysInternals'
Autoruns. Windows loads, checks the UEFI for the bootkit/rootkit
program, and runs that program under Windows. Since Secure Boot okays
the load of Windows, and since it is a program under Windows that loads
the .exe in the UEFI, Secure Boot won't catch this tactic.

https://eclypsium.com/blog/everyone-gets-a-rootkit/

There are tools to nullify the .exe in the WPBT ACPI table in UEFI by
deleting it from memory before Windows reads the ACPI tables, like:

https://github.com/Jamesits/dropWPBT#from-windows

This removes the WPBT table from system memory, so you have it run as a
startup program (that loads with Windows startup, not until whenever you
log into your Windows account).

For your own computer, you don't want WPBT employed. WPBT started with
Windows 8. Probably the easiest way to disable WPBT is to rename,
delete, or move the wpbbin.exe if it exists on your system. An update
could replace it, so you might want to use Task Scheduler to run a
delete command on every Windows startup. The Github article talks about different methods of disabling WPBT, but they're rather complicated instructions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

On 7/26/2024 12:58 AM, Stan Brown wrote:

From Ars Technica:

In 2012, an industry-wide coalition of hardware and software makers
adopted Secure Boot to protect against a long-looming security
threat. The threat was the specter of malware that could infect the
BIOS, the firmware that loaded the operating system each time a
computer booted up. From there, it could remain immune to detection
and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and
fueled in large part by the creation of ICLord Bioskit by a Chinese researcher in 2007. ICLord was a rootkit, a class of malware that
gains and maintains stealthy root access by subverting key
protections built into the operating system. The proof of concept demonstrated that such BIOS rootkits weren't only feasible; they were
also powerful. In 2011, the threat became a reality with the
discovery of Mebromi, the first-known BIOS rootkit to be used in the
wild.

...

On Thursday, researchers from security firm Binarly revealed that
Secure Boot is completely compromised on more than 200 device models
sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in
December of that year, someone working for multiple US-based device manufacturers published what?s known as a platform key, the
cryptographic key that forms the root-of-trust anchor between the
hardware device and the firmware that runs on it. The repository was
located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and
it's not clear when it was taken down.

The repository included the private portion of the platform key in
encrypted form. The encrypted file, however, was protected by a four- character password, a decision that made it trivial for Binarly, and
anyone else with even a passing curiosity, to crack the passcode and
retrieve the corresponding plain text. The disclosure of the key went
largely unnoticed until January 2023, when Binarly researchers found
it while investigating a supply-chain incident. Now that the leak has
come to light, security experts say it effectively torpedoes the
security assurances offered by Secure Boot.

?It?s a big problem,? said Martin Smolár, a malware analyst
specializing in rootkits who reviewed the Binarly research and spoke
to me about it. ?It?s basically an unlimited Secure Boot bypass for
these devices that use this platform key. So until device
manufacturers or OEMs provide firmware updates, anyone can basically?
execute any malware or untrusted code during system boot. Of course, privileged access is required, but that?s not a problem in many
cases.?

Binarly researchers said their scans of firmware images uncovered 215
devices that use the compromised key, which can be identified by the certificate serial number
55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. A table appearing at
the end of this article lists each one.

Full article, apparently not behind a paywall: <https://arstechnica.com/security/2024/07/secure-boot-is-completely- compromised-on-200-models-from-5-big-device-makers>

Interesting. I've never been clear about how much this matters.
I turned off secure boot after Suse15 messed it up by installing
a bad shim. I still can't say that I really understand that, but I
haven't worried about it. So I guess it's reassuring to know that
it was a safe with no back wall all along. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

On Fri, 7/26/2024 12:58 AM, Stan Brown wrote:

From Ars Technica:

Full article, apparently not behind a paywall:

https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers

It smacks of this being done on purpose.

I bet some part of the key/crypto process costs money.

Money drives stupidity in our society. Even when the amount
of money, is "one penny", that will drive stupidity. And
frequently, that's the sum involved, a penny.

A number of the electronics companies *hate* per-unit
charges. It's an irrational hatred, does not matter how
much the amount affects their bottom line.

That is part of the reason DisplayPort was invented, to get
around a licensing fee per connector on HDMI. A
video card will have three DP++ connectors ("free" license),
and one HDMI connector ("paid" license). There may have
been a fee for Firewire as well, I'd have to go look that up.
USB, I've not heard of one.

It's happened before with MAC addresses for video cards
(purchased from IEEE, and IEEE keeps the record of them
to ensure uniqueness). Some manufacturers were "cloning" or
"recycling" MAC addresses. Which of course, would destroy
Microsoft license tracking via hash (assuming the mobo NIC
MACADDR is a key part of the hash). I've not heard of
shenanigans regarding MAC for some time, so something
must have changed on per-unit costing.

But this kind of stupidity, there must be an underlying theme,
just as there was with MAC cloning.

And MSI losing custody of their ability to ensure an
MSI BIOS is being used to update an MSI BIOS, that's
more likely to be "regular, run-of-the-mill" mistakes.
I don't think they're losing any sleep over it. The customer
takes the risk. The risk is small if you download
from the MSI site, but two motherboard company sites
have been hacked before, so hacking the MSI web site and
staging infected materials, that's not an impossible
development. It means they have to be extra vigilant
about their website.

It means the next time a crypto scheme is invented, the
humans have to be taken out of the loop, and the
controls centralized. Microsoft Pluton is the next
opportunity to remove idiots from the chain of custody.
And that's been "quiet-as-a-mouse". Can't tell if
the AMD instance(s) of Pluton, are showing up in the
TPM dialog in Windows. And if some key for it is in the
BIOS, it'll be no better than what we have now.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

On Fri, 7/26/2024 8:29 AM, Newyana2 wrote:

  Interesting. I've never been clear about how much this matters.
I turned off secure boot after Suse15 messed it up by installing
a bad shim. I still can't say that I really understand that, but I
haven't worried about it. So I guess it's reassuring to know that
it was a safe with no back wall all along. :)

The shim can't work now.

As of July 2024 patch tuesday, the "thing" the shim relies on, has
been revoked. A new shim would be required, but only if you were
Secure Booting. If you installed with Secure Boot off, then the
shim can't make any difference (as it is not part of booting then).
The current shim (on a new release) should be signed with 2023.

To verify that the Secure Boot DB update was successful, open an Admin PowerShell

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’ ===> TRUE

The reason mine returns true, is I did the change manually.
The automation was unable to complete it (because... Secure Boot is off).

I don't use Secure Boot, so this is irrelevant at the moment.
But at least it has been patched up to please Microsoft, and
if their code actually checks this value, they might be
pleased. But the automation does not check, and hammers
away at it. Think of installing that manually, as a digestive mint.

I installed a fresh copy of WIndows, in secure boot mode, and it did
its little hammer dance, then I threw the install away and
went back to my (non-secure) daily driver image. That's how I got CA 2023.

"They tried so hard, to make the machine pretty."

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

On 7/26/2024 7:30 PM, Paul wrote:

I don't use Secure Boot, so this is irrelevant at the moment.

I don't use it either. As noted, I had to disable it
because Suse broke it and I couldn't boot anything.
But I don't really care.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.comp.os.windows-11

Paul wrote:

To verify that the Secure Boot DB update was successful, open an Admin PowerShell
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

Without the fancy quotes ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)