On Sun, 28 Jul 2024 09:14:55 +0100, JAB <
noway@nochance.com> wrote:
On 28/07/2024 05:39, Spalls Hurgenson wrote:
Not really a computer game issue, but it /is/ computer related so I'll
post this here anyway. ;-)
"Secure Boot", first released a decade ago, was supposed to hearken a
new age of security for users. It was supposed to create an
unbreakable foundation on which all other security methods would be
built. With SecureBoot, you could be sure that there was no way for a
rootkit to bypass the OS, because OS and BIOS would create an
unbreakable handshake. Thanks to secure hardware keys, so long as
SecureBoot was enabled, nothing could subvert the core OS functions.
But, as with a lot of security, it depends heavily on using strong
cryptographic keys through which the communications between operating
system and hardware could be safely transmitted. Unfortunately, for a
lot of devices, a secure cryptographic key is /not/ what was used.
Instead, a short (4 character) key was used instead. A key so insecure
a 386 probably could break it in seconds. Modern malware, using modern
processors, could subvert it so fast it isn't even worth timing it.
The key itself was provided to hardware manufacturers as a test key.
Despite including the word "AMI Test PK" (public key) and "DO NOT
TRUST", it was embedded into the BIOS of at /least/ 300 device models,
from manufacturers include Acer, Intel, Gigabyte, Aopen, Lenove, HP
and Dell. This means that any security that relies on SecureBoot
(which pretty much includes any Windows machine since 2012) isn't very
secure at all. Everything from HTTPS to Bitlocker is vulnerable now.
How much more vulnerable this makes the average end-user is debatable.
There are a lot of ways to get access to the average computer that
don't require subverting SecureBoot, after all (easiest is just to act
as if you're trustworthy person and tell them to download some malware
;-). But there are institutions which rely on secure hardware - banks,
for instance, or vital infrastructure- and these have just become a
lot more hackable.
If you're interested in seeing if your machine is vulnerable, open a
Powershell command prompt (using administrator access) and enter the
following command (all one line):
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes)
-match "DO NOT TRUST|DO NOT SHIP"
If it returns false, your PC isn't using the vulnerable key. If true,
then you'll want to check for a BIOS update. Assuming there is one;
most manufacturers have washed their hands of the issue, claiming that
since the affected boards are no longer being sold, it's not their
problem.
(depending on your BIOS, there may also be ways to reset the key
yourself. Figuring out how to do that is an exercise left to the
reader ;-)
Again, this isn't a reason for the average user to panic; most
day-to-day hackers aren't going to be using this method to crack into
your PCs. But if you were thinking that you needn't worry about
somebody accessing your files if you lost your laptop, well... you may
not be as protected as you think.
Read more here:
https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/
>
Not good but having worked in software security for a long time it
doesn't really surprise me which is why you'll supposed to have people
who understand things to make sure it's done right. I think a lot of
this comes down to this peculiar trait of software development in that
unlike most software/hardware security doesn't provide direct
functionality to the user but instead acts as a gate keeper to it. To
put it simply, I worked on a system which from a users point of view
would work perfectly. When I looked properly at the encryption function,
not good.
It isn't surprising, no. That's the sad part. Putting all your trust
in a single key -which in many cases is not revokable- is asking for
trouble. Eventually that key /will/ key leaked, and all the security
that depends on it will be broken. We've seen it happen repeatedly in
the past (the most famous being the DVD encryption key*, but there
have been numerous other instances).
This very vulnerability was warned against when SecureBoot was first
introduced.
It should also be a reminder why "backdoor access for governments" to
encryption methods are a /bad/ idea. Aside from the privacy issues,
this backdoor access is enabled by giving the authorities a
non-revokable encryption key that ideally only they have access to.
But inevitably that key would leak, and all of a sudden every bit of
encryption is useless.
>
As for the banks part, I'd hope that banks still use dedicated hardware,
and have a team to basically certify that it is secure, for key security
functions.
You'd hope. But several things work against that.
a) Banks and financial institutions are LARGE, and there
are lots and lots of systems that have access. Many of
these are retail PCs given to the office workers. They're
an obvious backdoor into more sensitive areas. More,
the day-to-day businesses (which is going to be done on
those cheap retail PCs) rely on Internet access, which
leaves them - and ultimately the machines they are
connected to - open to remote attacks.
b) Financial institutions are OLD. They rely on a lot of
old hardware and software. And some of it is /really/
old. I honestly wouldn't be surprised if there is some
old iron from the '70s lurking about in the basements
of some banks. Even when its not ancient, it's such a
mess of different systems, it's almost impossible to
understand how it all works. Securing these is hard
(often impossible), forcing the companies to rely on
upstream devices to act as strong front gates. If that
gate is breached, the company is more dependent on
detection than internal security. All they can hope
to do is find out what happened after the fact.
c) Financial instutions are CONSERVATIVE. They don't like
making changes to their infrastructure. "If it works,
don't mess with it" is a common refrain. Hence the ancient
computers, and a resistance to adding new (more secure)
layers of software on top.
d) Financial institutions are CHEAP. While arguably slightly
more sensitive to security considerations than other
industries, IT is still seen primarily as a cost center.
Paying for the appropriate technological improvements
(and the skilled personell necessary to implement them,
and the training for their other employees) is not an
expense a lot of them want to bother with.
e) Financial institutions are run by STUPID people. Or, at
least, ordinary people who make the same sort of stupid
decisions the rest of us make. Execs are easily swayed by
flashy solutions that sound good but are mostly security
theater. They aren't geniuses making the best choices.
They average (if overly paid) jomokes whose primary interest
is CYA and who are just as easy to bamboozle with quick-
talking and flashy marketing.
f) Security is HARD. It's not a one-step solution. It's a
continuing process. You can't just buy an app and say,
'that's it, we're safe'. You have to constantly be on your
guard, evaluating and upgrading your processes, training
and monitoring your employees. All of which are time
consuming, often difficult for laymen to understand, and
costly (and see reason (d) above why this is an issue.
Also reasons (a), (b), (c), and (e) ;-)
The TL;DR is that while you'd THINK banks/finace are some of our most
secure institutions around, when it comes to tech they too often are
not. If you've ever had any involvement with the industry, you'd be
almost terrified at how backwards it often is. They often rely more on
their reputation for security (and insurance companies and government
bailing them out when they fuck up) as actual proper security
techniques.
And bad as all that is, there are other insitutions which are A LOT
worse. Heck, even the BEST of them -companies which nominally
specialize in the topic- fuck up. See the recent Crowdstrike fiasco.
But there are so many instances out there where there are improperly
secured systems that, if accessed maliciously, could ruin the lives
(or kill outright) thousands of people. Big industrial systems. Major
infrastructure projects. It's horrifying.
Sleep tight. ;-)
* 09F911029D74E35BD84156C5635688C0! Fuck you, MPAA ;-)