- AT&T Data Breach - Crowdstrike Update Crash - CPU Predictive Processing Bypass - Intel CPU 100% Failure Rate Bug - Secure Boot Bypass Man, this month has NOT been a good month for computers and security.
It's annoying that all these sites report "the vulnerability affects 200+ motherboards from the big OEMs" but nobody has a compiled list of exactly which motherboards are affected and which are not. You can test your motherboard. You can't test the one in the store.
Yet plenty of security people genuinely believe that being able to see the source code makes you more vulnerable. It's one of the reasons companies like GlobalProtect are able to sell their proprietary VPN solution. :(
having code validated by public is always better, implementing it in a way that even if breached risk and exposure will be reduced thats the other thing, from my experience its best to use both when You deploy something really critical
Don’t worry guys, if someone guesses our 4 character password we will just change it to a new 5 character long password. And just in case this change is needed under short timeframe we will all agree in advance that the fifth character is a “1” and we will reuse the first four characters to make it easy to remember.
@@thewalrusdragon9579 A.I and lay offs + stupid CeOs. They always get the wrong man innthe place with no expertises wtf, this way he will fuck the company and the industry
No, firmware has been a dumpster fire for decades. This is largely due to the ecosystem behind it. See the UEFI Forum whitepaper from August 2023 on embargo / disclosure periods for security issues. They demand a *year* because they are so slow and complex.
Anyone else here old enough to remember flashing bios by physically removing the bios chip, UV erasing it and then re programming it, now THATS security.
The promise: "We can add new features and fix bugs in hardware you already own." The reality: "We can sell unfinished products with the carrot on a stick of potentially being finished.. some day."
The flash parts that can be erased and rewritten in-system and from within the system are due to updatability. The physical extra parts make it hard for people to upgrade when there are already bugs in the firmware, which happens often. And yes, it is not as "firm" as the name suggests - especially with UEFI bringing a whole other OS on its own. Bryan Cantrill calls firmware the "software that is hard to get to". Anyway, secondly, part of the flash is used for storage, where user settings, EFI variables and such are stored, like volatile data from other platform components, like the CSME, possibly EC, ethernet adapter, etc..
You can (usually) enroll your own secure boot keys *IF* your board's UEFI supports it... In which case it's up to you to sign the bootloader and/or kernel. I 100% agree that these companies should not hold the keys and determine what it is "secure" to boot from on OUR hardware.
The powershell command doesn't work as given. Where it has '.:' between the right bracket and 'ASCII', it should say '::'. Also, 'True' is the response you should get if you are compromised ('False' means you are not, while an error message saying GetSecureBootUEFI is undefined means you don't have SecureBoot activated).
Not sure why game cheaters would, because cheats don't run on the firmware and in some cases there are even peripherals they can plug in that cheat for them. I think they can still run an executable even if secure boot is there, they just cant flash the firmware no? not too familiar with secure boot or TPM I think they trash.
@@vaikjsf34ait would be a very difficult thing to do, but you could inject your own bootloader into the boot process, that then injects a custom kernel patch into the kernel. From there, it'd be trivial to hide anything you want from the anticheat
Easy fix - Just ban all devices with said vulnerability the same way RUST banned all a4tech hardware due to the powerful macro software that some people used to make anti recoil macros. Sure, you will piss a lot of people off, but hey, all in the name of security
Well, it is there to authenticate the bootloader binary. And they wrote it. Arguably you want to check their private key at least before you would self-sign it, and had they not leaked their keys in a git-repo it would have been perfectly good way to verify the binary is written by the author it was supposed to be written by. How I see it is that when you use your own key, you have no way of actually knowing what you sign, as it is proprietary code. You can however sign a state you trust, to ensure that state hasn’t changed.
It is perfectly reasonable and actually a good idea for a company to ship products with their trusted root key and use it to verify signed software upgrades. BUT they must protect the private key by using real hardware security modules which make leaking the private root key impossible but they are expensive and painful to use so many companies don't bother.
You know you can resign or add another signature to the binary correct? If you remove the companies PK from secure boot you're not just blindly signing completely unknown code and there are open source bootloaders right?
I never understood the value proposition of "secure boot" except as making Open Source bootloaders hard or impossible to use and disallowing tweaking/analyzing manufacturers firmware aka. "locking the system down like a Playstation", and maybe make money on the side with "signing services". Anyway, I found a writeup of the state of this approach from 2020 in "Communications of the ACM": "Securing the Boot Process: The hardware root of trust."
Secure boot is super important, especially on mobile devices. On many Android phones (where it is called Verified Boot) it is often disabled when rooting the device. This means anyone with access to the phone can run any code they want, such as a bruteforcer for a PIN (assuming no hardware limiting) With it on, only updates/code signed by the registered private key can be used. This ensures that if someone steals your phone, your data & phone are fully inaccessible.
_except as making Open Source bootloaders hard or impossible to use and disallowing tweaking/analyzing manufacturers firmware aka. "locking the system down like a Playstation", and maybe make money on the side with "signing services"._ That's exactly the only value proposition. It was a way for Microsoft to keep it's technically illegal monopoly and they sold it as a "security feature".
@@probablypablitocelebrites various services show this doesnt reslly help though doesnt it. Samsung even have a bunch of knox tech and theyre one of the most vunerable.
@@probablypablito This is not perfectly accurate. Though they achieve basically the same goal as you mentioned, AVB and Secure Boot are two completely distinct thing: most Android devices don't support UEFI which is needed for Secure Boot. Also, all SB/AVB "guarantees" is that you don't execute a bootloader that hasn't been signed by whatever keys are enrolled on the device. Once you've executed that bootloader, arbitrary code can be executed by other means. It's not much about bruteforcing: with physical access, one could extract your eMMC and try bruteforcing from there (as I don't think the master key is stored in a "secure device", correct me if I'm wrong though). You *should* be expecting RCE exploits on your phone anyways if someone has physical access to it: the safety of your full disk encryption should not rely on the ability of the attacker to execute arbitrary code on your device. However, SB/AVB prevents installing and executing a rogue bootloader that would, for example, keylog the decryption password when user unlocks the device.
The PowerShell script isn't even going to work, it incorrectly uses ".:" (which isn't valid PowerShell code), when it should be "::", the static accessor operator.
@@RokeJulianLockhart.s13ouq Yeah, being primarily designed with less tech-savvy, non-developer sysadmins in mind (hence the verbose verb-noun naming conventions of cmdlets), a lot of PowerShell scripts tend to be written quite poorly. And in this case, the script is essentially just a .NET API call, which could just as well be written in C#. But this is just straight up invalid syntax. The author of the article didn't even bother copy-pasting the script into the shell and executing it before publishing the article.
It's a bit funny to think of the computer, I started up with 40 years ago. The OS was in a ROM or EPROM and you had to replace the chip to change the OS. When rebooting NOTHING had changed, but now everything have to be updated all the time, but why do anything else than the OS need to have kernel access? Companies should not have the keys, it's just a matter of time, before something is exposed.
To be fair, literally everything is a Microsoft conspiracy to stop Linux to certain groups. I've started calling it "Windows Derangement Syndrome", since the symptoms are so similar.
Thanks for bringing awareness on the subject Ed, it led me to double check my secure boot settings. People are questioning the effectiveness of secure boot after this issue but what they're failing to realize is that this is a "~200 devices affected" kind of thing rather than "all devices from 200 manufacturers affected", there's a huge difference. Thankfully my device is not compromised at this time.
"rather than 'all devices from 200 manufacturers affected', there's a huge difference." - True, but on the other hand, we don't know how many devices currently have unknown/undisclosed vulnerabilities. The ONLY reason we know about this vulnerability is because someone posted the key on Github.
A secure boot ensures the part of the bootloader that prompts you for your encryption key to unlock the encrypted boot drive hasn't been replaced with code that steals your password.
@@itsTyrion Yep. Secure boot is designed to protect all the parts of the operating system that aren't protected by the OS authentication systems. I.e., it protects everything you can get to without a password. In theory.
@@darrennew8211Secure Boot doesn't encrypt anything. TPM does. Secure Boot itself only lets verified code run at boot. This prevents evil maid attacks such as modifying the bootloader to put a keylogger on it and steal the encryption key.
@@Maxjoker98 This would be a plausibly deniable leak. Just try to remember, your government made an agreement with at least 14 other governments that they were allowed to spy on you as long as they "promise" to share the information they gather. I think we can *fingers crossed* be sure, that they aren't using that agreement for their own gain or sharing the information with US citizens inside the country with direct lineage to foreign intelligence so they can have an advantage in love, economics and war.
@@Maxjoker98 Honestly yeah the NSA is far more likely to show up and tell them they need their keys and here is their court orders for it. They don't really have a lot of need to be sneaky when they have government backing.
*That's a stupid question: “how does this keep happening???” The answer is triaial: manufacturers can be grossly negligent in threatening customers and never have to take responsibility.* If it were otherwise, Dell, for example, would now be sued, e.g. with 10$ for each affected device. *I bet manufacturers would never define a standard router password 'admin/admin' again and they would take very simple measures to ensure that test keys would never be in productive systems again.* 🙂
I'm not even surprised, not because of what's been happening recently. But because I already knew secure boot really just means "Microsoft-approved boot OS" Was never about security, but having more control of the user's machine. Keeping out possible competition
Secure boot is secure as long as you: 1. enroll your own keys, and 2. aren't being threatened by a state actor. This problem is caused by irresponsible manufacturers who don't know how to do proper secret management, not by broken secure boot implementations
Is there any evidence of this actually being bad or is it just more conspiracy and fearmongering by people who would force me to use Linux at gunpoint?
The fact that a way to bypass secure boot has been found, and one or two viruses are designed to be able to do so does *not* mean that you're better off letting all other malware easily insert code at boot by disabling secure boot. Having it enabled doesn't affect you detrimentally in any way. Unless you use a custom unsigned Linux kernel, keep secure boot on. It's like disabling Windows Defender because some malware found a way to bypass it.
That's a really bad fallacy in cybersec, just because there's ways to bypass some security measure doesn't mean that you shouldn't use it. Defence in depth is one of the most fundamental security principles.
i don't completely understand secure boot and what its associated with (if its just a windows thing or a motherboard thing) but if i get mint linux will i neeed to worry
It is perfectly reasonable and actually a good idea for a company to ship products with their trusted root key and use it to verify signed software updates. BUT they must protect the private key by using real hardware security modules which make leaking the private root key impossible but they are expensive and painful to use so many companies don't bother.
"You have a secret key that lives inside your OEM" is perhaps the most confusing way to state this, but what it means is, the manufacturer is the one with the private key, and the key on your motherboard is a _public_ key that verifies the signature against the certificate chain.
That's why you should never buy any computer with a firmware and design, code and deploy the boot, kernel and OS yourself, deciding by yourself how to interpret and possibly execute every single software you get access to. Same for your car: you don't design the fuel you put in it, you don't decide of the design of the airbag: nothing but ownership issues ! Build you car yourself from raw mineral : THAT is ownership and security ! 🤣
Imagine if your manufacturer had the key to your car (or, more accurately, a key that opens all the same models of that car) and someone just carelessly leaves it somewhere in public. And I have to argue, you only truly own your device when you've manufactured all the chips with your own billion dollar fab of course
@@emjizone There is a big huge jump from _having the only and only keys of your own vehicle,_ to "building it yourself from raw minerals". Your analogy is just plain bad and wrong.
I thought most folks would use their own certificate authority for secure boot. Why would I trust a public CA if I don't have to? The main use case for public CAs is certificate distribution, e.g. for TLS over the public internet. Moreover, anyone who is self-signing their UKI would have to replace the CAs on the board - which I thought was basically everyone except maybe Windows users.
I designed offline signing procedures for financial institutions. Damn if the devices are on the list, we might need to renew many of them (I'll physically destroy and blend them all) and get them re-audited by third parties >.> I'm also curious that Chromebooks' keys are safe. Those are securebooted linux.
Wow, Gigabyte is winning this one with the largest number and variety of compromised devices! Intel/AMD/ARM Server boards, full Rackmount Servers, Mini-PCs... At this point I'm downright impressed by Gigabyte's consistency in upholding their poor reputation.
The problem rooted in the wish to do away with READ ONLY chip and TOTALLY replace it FLASHABLE chip. The wish were granted but it has the consequences!
If they have access and admin rights to the machine to mess with secure boot... the house is on fire already. This just adds to the pwnage, but isn't the root cause of it.
Sure the OEM(s) used secure boot certificate technology during manufacturing but they did so in a way that effectively undermines the whole reason to be implementing secure boot in the first place. OEM managers were probably non technical and saw secure boot as no different as any item on a checklist. "We have it? Okay good". Secure boot needs to be managed directly by sometime who has a technical understanding of securely distributing security certificates and the importance of doing so SECURELY.
So does this mean they want us to purchase a newer device and throw out our old device? Imagine have 14th intel and these motherboard... We know its a bomb, but cant defuse it
This is why we need a non-flashable bios. It would solve the problem. However it does make a new problem. You can't update the microcode to fix issues things like the CPU.
The problem with 2FA from what I've heard, is that many sites that use it require you to have a less secure 2FA option enabled, and it's a this OR that approach instead of this AND that. Meaning the more-secure option is not making the account more secure when an attacker only needs to attack the less secure 2FA, for example SIM swapping or something.
@@throwaway6478No, “the adversary doesn’t know the keys” is *not* “security by obscurity” . “Security by obscurity” is when the security is based on adversaries not knowing how the system works, and is *specifically in contrast to* security based on adversaries not knowing the secret keys.
this isn't security by obscurity this is security by password authentication with a stupidly low amount of bits of entropy so it was easy to crack security by obscurity is when you use a reversible, simple cypher such as the alphabet +2 where A=C B=D and so on, or you hide passwords by checking the "show hidden files" box to unchecked or you take the first half and append it to the second half so ABCD becomes CDAB, THAT'S obscurity
A basic rule in cryptography is to always verify and never trust. This is why you should always be allowed to generate your own keys and only you should have a private key. Centralized 3rd parties are alwats going to be a major vulnerability.
the only reason i clicked on your video from the youtube suggestions is to tell you what i've been telling all these suspense and cliffhanger titlers which is this. if i don't know what the vid is about, there's a 96% chance i'm not going to waste my time clicking on it. i really wish artists like you would quit wasting youtube storage space.
DAMNIT! I ALWAYS do this. I come up with an idea as a prototype/proof of concept. Once I prove my hypothesis I pretty much shelve it. The last thing I worked on two years ago was an SSO dongle very similar to this YubiKey thing. I went super paranoid and used biometric - fingerprint - in order to access it. That way it had 2FA built in - something you are, and something you have. Your fingerprint is something you are - it's unique to you and nobody else can take it from you. The device is something you have, and it can physically be taken from you. Edit: Forgot to mention it was built around a Pico Pi for the prototype. Those are like $4 boards with a custom M0 Cortex chip called an RP2040 which is the microcontroller in the Raspberry Pi ecosystem. It can run MicroPython which makes writing the application code dirt simple and pretty safe as well. Writing native C can introduce memory bugs that could be exploited.
There is now a project developing an open source U2F dongle (part of what the yubikey does)... tricky part is getting a dongle that works U2F and SSH and GPG... and now they want us to use discoverable device resident crednetials called Passkeys which used to be called Password-less FIDO2 discoverable credentials. I dislike device resident creds for so many reasons including these dongles have VERY limited key storage space, and also U2F uses the same math and has same security as Passkeys but lets the host store a wrapped key (only the correct U2F dongle can decrypt the secret portion with its master key) which means they can be used for an unlimited number of logins on unlimited website (literally unlimited), but also an attacker with your key has to first find by trial and error which account that key opens and where... discoverable credentials are less good because the attacker now has the key and a list of what it opens... bypass the PIN (If one was set anyhow) and you're in.
Automation prevents human mistakes, but automation eventually breaks and when it does it reproduces the same mistake on every unit. This is an expected kind of issue. It will come back again some day..
People saying secure boot doesnt make anything more secure and that its a proprietary stack that the user has no control over don't know what or how secure boot actually works. The user can reset, remove or distrust whatever keys they want and create their own to replace the Microsoft and oem keys to have full control over which signed binaries are allowed at boot
I agree, they should've spread these out more as this many issues/attacks all at once is too much for cybersecurity professionals to handle. That's why I didn't go into cybersec, from what I've heard you will go from having nothing to do to everything burning down in the blink of an eye. I don't know why they do that when it would be more efficient to spread problems out.
just checked on my laptop to see if I have one of those do not trust pk's ( i don't know anything about coding or IT so i'm just following the steps people show in the video), turns out it is indeed one of these which have this vulnerability, wtf do I do now? pray that no one hacks into my PC? I will probably buy a new one but how do I know that's not compromised as well?
Hey man, love your work. Important question, I stumbled on this video, the day before I got a gigabyte B450M delivered. I opened the box containing all the components for my PC build to find all the components were factory sealed, except the motherboard. Of course, after watching this video, I'm paranoid. So I enquired with the supplier and the Gigabyte local representatives as well and I'm shocked to learn that the boxes are not necessary "factory sealed". This just seems absolutely bonkers, the supply chain from the manufacturer to consumer have just accepted that it's ok for this low level (again, lover the channel 😉) and vulnerable component to not be sealed. I think you should dive into this with an investigation, and call it out.
root private keys must only be generated in Hardware Security Modules where the key CANNOT be exported in plaintext. Even Azure didn't adhere to this rule and had a SAML signing key leaked in a memory dump.
Secure boot was never meant for security, the only reason it exists is to make it more difficult for people to install Linux on budget Windows laptops which incentivizes them to buy a new laptop after a year or two when Windows automatically upgrades requiring double the RAM that was soldered onto your laptops motherboard.
Embedded dev working on Secure Boot(SB) here: Correctly integrating secure boot is absolutely non trivial (esp. on non x86 devices). But my biggest concern is about people who are told to „enable secure boot on that device“, but who don’t understand how it works. For testing, test signatures are added to the db, but forgotten to be removed when shipping. In CI/CD pipelines the signing is done, but it is not carefully checked who can run the pipeline. Then there are signed recovery shells (used to recover broken devices), but with root access (making SB basically pointless). As said, it’s not so much about the technology, but about people using but not understanding it.
With every processor and component out there backdoored there's no longer a practical reason for computer security. You want security? Write something on a piece of paper. You can't hack paper.
What? Secure Boot is a nice security feature. The only time when that type of feature is not OK is when the manufacturer does not allow 3rd party software and uses signing to prevent it. Like mobile phones do. Secure Boot even lets you enroll your own keys!
This is so incredibly easy to avoid... just have a unique key for every device. "But that would be sooo many keys for the vendor to keep in storage!" Not at all. You could have 100 million private keys and that would be (assuming 1028 bit) 1028 * 100 million = 100 Gb = ~12GB if stored efficiently. Oh no, one of the keys were leaked! Yea, that sucks for ONE device, but you give that customer a refund and move on. "But that database could be leaked!" Then multisignature all the keys with another key kept separately. My lord why are ALL of these recent security catastrophies so fundamentally simple to avoid. A 14 yr old with a multisig Bitcoin address has more security than what they did here... We are WAY past due for a huge purge of any company that is laying off / outsourcing engineers which results in this mess. I'm so tired of this.
About the course content on your website. Are the tutorials applicable to users running Linux or are they specific to Windows? Would someone with a Linux PC be able to follow along with the practice material while watching the video lessons?
wow haha I really wish I had a yubikey to secure myself online with 2FA: yubi.co/lowlevellearning-2024
frfr
!
ur looking kinda insecure, no cap, get a yubyub
ur looking kinda insecure, no cap. get a yubyub
i c u, i aplod u klapklap
- AT&T Data Breach
- Crowdstrike Update Crash
- CPU Predictive Processing Bypass
- Intel CPU 100% Failure Rate Bug
- Secure Boot Bypass
Man, this month has NOT been a good month for computers and security.
Try "year"
"Year" is more accurate, add SSH vulnerability to the mix
xz backdoor
gay furries
The GamersNexus Disappointment Tour shirt this year is going to be amazing
Here we go again I guess
DVD Jon, where are you today?
See you next week
That probably shouldn't have made me laugh
These massive breaches, failures, and outages are going to turn this into a weekly news channel 😔
You forgot the "ahh shit"
It's annoying that all these sites report "the vulnerability affects 200+ motherboards from the big OEMs" but nobody has a compiled list of exactly which motherboards are affected and which are not.
You can test your motherboard. You can't test the one in the store.
you can buy it first then test the mobo and curse when you find its affected then refund it as long as you didnt bend pins :P
The mentioned article has a list of 215 devices at the end.
@@vaikjsf34a Only for a Newegg RMA center employee to drag a flathead screwdriver over the pins and blame you for it.
@@pwnmeisterage just RMA it :)
200+ models that have been tested. Sounds like a list we need of which aren't vulnerable.
"proprietary" and "security" really shouldn't be in the same sentence anymore...
Yet plenty of security people genuinely believe that being able to see the source code makes you more vulnerable. It's one of the reasons companies like GlobalProtect are able to sell their proprietary VPN solution. :(
Sometime ago, I would have totally agreed. Open source never guarantees security, it's all up to you to to implement it properly.
Oh, so you prefer when nobody knows who own the keys you use ?
having code validated by public is always better, implementing it in a way that even if breached risk and exposure will be reduced thats the other thing, from my experience its best to use both when You deploy something really critical
ascension spotted
Don’t worry guys, if someone guesses our 4 character password we will just change it to a new 5 character long password. And just in case this change is needed under short timeframe we will all agree in advance that the fifth character is a “1” and we will reuse the first four characters to make it easy to remember.
The real tragedy here is that many such people exist :')
Think it’s a coincidence that tech layoffs are at a high and at the same time stuff like this is happening every other day now?
Throw in a little increased rate of adoption of AI in software development and I'm not opposed to accepting that explanation.
@@thewalrusdragon9579 A.I and lay offs + stupid CeOs. They always get the wrong man innthe place with no expertises wtf, this way he will fuck the company and the industry
No, firmware has been a dumpster fire for decades.
This is largely due to the ecosystem behind it.
See the UEFI Forum whitepaper from August 2023 on embargo / disclosure periods for security issues. They demand a *year* because they are so slow and complex.
100000% what I’ve been saying. You just confirmed I’m not crazy for thinking this!
@@CyReVoltyou meant to write "yes". Yes it is a coincidence.
Disabled secure boot because my Linux Distro wasn't working with it.
You don't fear secure boot issues if you disable it 😊
Tbh, I think you can add the signature or hash of your custom kernel.
Same lol
@@tablettablete186 You can, but i don't think its worth 15 minutes out of my day because that 15 minutes will always become 5 hours
@@tablettablete186 Yeah its super easy, at least on arch to enroll your own keys and automatically sign your kernels and stuff.
@@tablettablete186signature: "1234"
"Don't trust it. Do not ship!"
Did it get shipped? Hell ya! ☠️
As a dev, am I surprised? Hell no!
I'm not a software dev but could this be what happens if you write a comment instead of opening a ticket/issue?
@@zokalyx wat
@@zokalyxthis is why you are not a software dev
@@fullfungo can u explain?
Anyone else here old enough to remember flashing bios by physically removing the bios chip, UV erasing it and then re programming it, now THATS security.
Yeah, we had one of those UV EEPROM burners at work in the 90's. I loved the sound made when burning all of those gates again.
You got 7 thumbs up in 4 hours so there's your answer. Dinosaurs remember. Nobody else does.
When exactly did it become possible to write to "firm"ware without that kind of physical setup, anyway? And why?
The promise: "We can add new features and fix bugs in hardware you already own."
The reality: "We can sell unfinished products with the carrot on a stick of potentially being finished.. some day."
The flash parts that can be erased and rewritten in-system and from within the system are due to updatability. The physical extra parts make it hard for people to upgrade when there are already bugs in the firmware, which happens often. And yes, it is not as "firm" as the name suggests - especially with UEFI bringing a whole other OS on its own. Bryan Cantrill calls firmware the "software that is hard to get to". Anyway, secondly, part of the flash is used for storage, where user settings, EFI variables and such are stored, like volatile data from other platform components, like the CSME, possibly EC, ethernet adapter, etc..
private keys should be made by people who want to protect their devices against maid attacks, not by companies.
this is just absurd
You can (usually) enroll your own secure boot keys *IF* your board's UEFI supports it... In which case it's up to you to sign the bootloader and/or kernel. I 100% agree that these companies should not hold the keys and determine what it is "secure" to boot from on OUR hardware.
Maid and catgirl attacks.
@@SterileNeutrino need
@@SterileNeutrino I'm gonna start calling it an Evil Catgirl attack now.
@@SterileNeutrino when you put it that way
The powershell command doesn't work as given. Where it has '.:' between the right bracket and 'ASCII', it should say '::'. Also, 'True' is the response you should get if you are compromised ('False' means you are not, while an error message saying GetSecureBootUEFI is undefined means you don't have SecureBoot activated).
Expectations: Viruses gonna bypass secure boot.
Reality: Game cheaters gonna bypass secure boot that anticheats require these days.
Rogue nation states have obtained +12.5% melee damage buff for more than the allotted thirty seconds
Not sure why game cheaters would, because cheats don't run on the firmware and in some cases there are even peripherals they can plug in that cheat for them. I think they can still run an executable even if secure boot is there, they just cant flash the firmware no? not too familiar with secure boot or TPM I think they trash.
@@vaikjsf34ait would be a very difficult thing to do, but you could inject your own bootloader into the boot process, that then injects a custom kernel patch into the kernel.
From there, it'd be trivial to hide anything you want from the anticheat
Easy fix - Just ban all devices with said vulnerability the same way RUST banned all a4tech hardware due to the powerful macro software that some people used to make anti recoil macros. Sure, you will piss a lot of people off, but hey, all in the name of security
@@vaikjsf34a Because kernel-level anti cheats like Vanguard which is required to play Valorant require secure boot to be enabled.
Good, secure boot is only good when you use your own keys, not ones made by people you don't even know
Well, it is there to authenticate the bootloader binary. And they wrote it. Arguably you want to check their private key at least before you would self-sign it, and had they not leaked their keys in a git-repo it would have been perfectly good way to verify the binary is written by the author it was supposed to be written by.
How I see it is that when you use your own key, you have no way of actually knowing what you sign, as it is proprietary code. You can however sign a state you trust, to ensure that state hasn’t changed.
It is perfectly reasonable and actually a good idea for a company to ship products with their trusted root key and use it to verify signed software upgrades. BUT they must protect the private key by using real hardware security modules which make leaking the private root key impossible but they are expensive and painful to use so many companies don't bother.
You know you can resign or add another signature to the binary correct? If you remove the companies PK from secure boot you're not just blindly signing completely unknown code and there are open source bootloaders right?
0:08 - That was your mistake
"I'm not even supposed to be here today!"
@@NatetheAceOfficial It's sad how Smith decided to end Clerks III. I guess he finally wanted to put that franchise to bed.
I never understood the value proposition of "secure boot" except as making Open Source bootloaders hard or impossible to use and disallowing tweaking/analyzing manufacturers firmware aka. "locking the system down like a Playstation", and maybe make money on the side with "signing services".
Anyway, I found a writeup of the state of this approach from 2020 in "Communications of the ACM": "Securing the Boot Process: The hardware root of trust."
Secure boot is super important, especially on mobile devices. On many Android phones (where it is called Verified Boot) it is often disabled when rooting the device. This means anyone with access to the phone can run any code they want, such as a bruteforcer for a PIN (assuming no hardware limiting)
With it on, only updates/code signed by the registered private key can be used. This ensures that if someone steals your phone, your data & phone are fully inaccessible.
_except as making Open Source bootloaders hard or impossible to use and disallowing tweaking/analyzing manufacturers firmware aka. "locking the system down like a Playstation", and maybe make money on the side with "signing services"._
That's exactly the only value proposition. It was a way for Microsoft to keep it's technically illegal monopoly and they sold it as a "security feature".
@@probablypablitocelebrites various services show this doesnt reslly help though doesnt it. Samsung even have a bunch of knox tech and theyre one of the most vunerable.
@@probablypablito This is not perfectly accurate. Though they achieve basically the same goal as you mentioned, AVB and Secure Boot are two completely distinct thing: most Android devices don't support UEFI which is needed for Secure Boot. Also, all SB/AVB "guarantees" is that you don't execute a bootloader that hasn't been signed by whatever keys are enrolled on the device. Once you've executed that bootloader, arbitrary code can be executed by other means.
It's not much about bruteforcing: with physical access, one could extract your eMMC and try bruteforcing from there (as I don't think the master key is stored in a "secure device", correct me if I'm wrong though). You *should* be expecting RCE exploits on your phone anyways if someone has physical access to it: the safety of your full disk encryption should not rely on the ability of the attacker to execute arbitrary code on your device. However, SB/AVB prevents installing and executing a rogue bootloader that would, for example, keylog the decryption password when user unlocks the device.
It really doesn't make open source bootloaders impossible at all, just load your own keys into the BIOS.
“Secure” in modern computing just means “safe for now”.
No, it means "vendor remains in control of _your_ computer".
@@benhetland576 Those two things aren’t mutually exclusive. Study formal logic.
@@NinjaRunningWild Fair enough, but notice also that safe isn't the same as secure, and neither implies the other.
Buffalo
@@benhetland576 until they inevitably slip up, so every hacker in the world can use the vendors' backdoors
Why does every motherboard manufacturer use the same private key? That sounds incredibly stupid
Probably part of the "UEFI Feature" standard...
The PowerShell script isn't even going to work, it incorrectly uses ".:" (which isn't valid PowerShell code), when it should be "::", the static accessor operator.
Broken PowerShell scripts are par for the course. Somehow, scripted OOP breaks peoples' minds.
@@RokeJulianLockhart.s13ouq Yeah, being primarily designed with less tech-savvy, non-developer sysadmins in mind (hence the verbose verb-noun naming conventions of cmdlets), a lot of PowerShell scripts tend to be written quite poorly. And in this case, the script is essentially just a .NET API call, which could just as well be written in C#.
But this is just straight up invalid syntax. The author of the article didn't even bother copy-pasting the script into the shell and executing it before publishing the article.
Is this correct?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
@@MZZenylit's easier to pop a PowerShell and run a bit of code that's essentially C# than to actually make a C# project, so there's that aspect
@@stefanalecu9532 Indeed, I do that regularly. Although in my experience, the code quality of C# code tends to be greater than that of PowerShell.
password must have been "asdf"
How do you know my password?😢
@@susugar3338 because you said it
How do you know my area's power station's controller's password? 😢
I vote "test"
@@jalil2985Yeah, given the content of the "Issuer" field, that seems pretty likely.
It's a bit funny to think of the computer, I started up with 40 years ago. The OS was in a ROM or EPROM and you had to replace the chip to change the OS. When rebooting NOTHING had changed, but now everything have to be updated all the time, but why do anything else than the OS need to have kernel access?
Companies should not have the keys, it's just a matter of time, before something is exposed.
I'm old enough to remember when Secure Boot was a Microsoft conspiracy to stop Linux.
To be fair, literally everything is a Microsoft conspiracy to stop Linux to certain groups.
I've started calling it "Windows Derangement Syndrome", since the symptoms are so similar.
@@eadweard. so, you're older than a few years?...
@@NJ-wb1cz I am.
@@eadweard. wow
@@NJ-wb1cz Bar burpates.
Thanks for bringing awareness on the subject Ed, it led me to double check my secure boot settings.
People are questioning the effectiveness of secure boot after this issue but what they're failing to realize is that this is a "~200 devices affected" kind of thing rather than "all devices from 200 manufacturers affected", there's a huge difference.
Thankfully my device is not compromised at this time.
"rather than 'all devices from 200 manufacturers affected', there's a huge difference." - True, but on the other hand, we don't know how many devices currently have unknown/undisclosed vulnerabilities. The ONLY reason we know about this vulnerability is because someone posted the key on Github.
wtf is a secure boot. i use arch btw
lmao
A secure boot ensures the part of the bootloader that prompts you for your encryption key to unlock the encrypted boot drive hasn't been replaced with code that steals your password.
@@darrennew8211 nope
@@itsTyrion Yep. Secure boot is designed to protect all the parts of the operating system that aren't protected by the OS authentication systems. I.e., it protects everything you can get to without a password. In theory.
@@darrennew8211Secure Boot doesn't encrypt anything. TPM does. Secure Boot itself only lets verified code run at boot. This prevents evil maid attacks such as modifying the bootloader to put a keylogger on it and steal the encryption key.
NSA really needs to learn not to leaks their secret keys.
@@Maxjoker98 now we know why they are the ones who hold the keys and not us :)
@@Maxjoker98 This would be a plausibly deniable leak. Just try to remember, your government made an agreement with at least 14 other governments that they were allowed to spy on you as long as they "promise" to share the information they gather. I think we can *fingers crossed* be sure, that they aren't using that agreement for their own gain or sharing the information with US citizens inside the country with direct lineage to foreign intelligence so they can have an advantage in love, economics and war.
@@Maxjoker98They might have one of Microsofts private keys. Or who knows, maybe they don't even need them...
@@Maxjoker98 Honestly yeah the NSA is far more likely to show up and tell them they need their keys and here is their court orders for it. They don't really have a lot of need to be sneaky when they have government backing.
*That's a stupid question: “how does this keep happening???” The answer is triaial: manufacturers can be grossly negligent in threatening customers and never have to take responsibility.* If it were otherwise, Dell, for example, would now be sued, e.g. with 10$ for each affected device. *I bet manufacturers would never define a standard router password 'admin/admin' again and they would take very simple measures to ensure that test keys would never be in productive systems again.* 🙂
If you dont control it, you dont own it. Its really as simple as that.
Wonder how many mobos will not receive a firmware update as they are considered "deprecated"
I'm not even surprised, not because of what's been happening recently. But because I already knew secure boot really just means "Microsoft-approved boot OS"
Was never about security, but having more control of the user's machine. Keeping out possible competition
that secure boot isn't actually secure is the least surprising revelation tbh
@@XerrolAvengerII Well it is, until it isnt'.
It just seems like branding right now... pepsi is really just flavored carbonated water... secure boot is really mostly secure until it isn't.
Secure boot is secure as long as you: 1. enroll your own keys, and 2. aren't being threatened by a state actor.
This problem is caused by irresponsible manufacturers who don't know how to do proper secret management, not by broken secure boot implementations
Secure boot is NOT a good thing because it is centrally managed by extremely untrustworthy corporations.
I mean, same goes for HTTPS, you need a central list of trusted CAs.
Better than not having it, plus, you can turn it off.
you can roll your own keys
@@junzhengca I agree, but I trust ICANN more than I do Dell.
Is there any evidence of this actually being bad or is it just more conspiracy and fearmongering by people who would force me to use Linux at gunpoint?
@@junzhengca no you absolutely do not.
i've had secure boot disabled for years, especially since the one hack that had something to do with it. just seems useless at this point
Secure boot is useful, you just need to disable vendor keys and enroll your own.
Secure boot protects important data, it's very useful.
The fact that a way to bypass secure boot has been found, and one or two viruses are designed to be able to do so does *not* mean that you're better off letting all other malware easily insert code at boot by disabling secure boot. Having it enabled doesn't affect you detrimentally in any way. Unless you use a custom unsigned Linux kernel, keep secure boot on. It's like disabling Windows Defender because some malware found a way to bypass it.
That's a really bad fallacy in cybersec, just because there's ways to bypass some security measure doesn't mean that you shouldn't use it.
Defence in depth is one of the most fundamental security principles.
@@firewalldaprotogen more like insecure boot, amiright?... Right?...
Yeah it wasn't that funny
00:33 "slow learning channel" :D
Remember: this doesnt affect you if you dont use secure boot in the first place
i don't completely understand secure boot and what its associated with (if its just a windows thing or a motherboard thing) but if i get mint linux will i neeed to worry
It is perfectly reasonable and actually a good idea for a company to ship products with their trusted root key and use it to verify signed software updates. BUT they must protect the private key by using real hardware security modules which make leaking the private root key impossible but they are expensive and painful to use so many companies don't bother.
4:32 "OEM manufacturer" = original equipment manufacturer manufacturer
This message brought to you by the Department of Redundancy Department.
Or you just take control of your secure boot and put your own platform key in there. (Yes you can do that)
How many years since defected products to stop preventing secure boot???......... 🤔
That took way longer than I expected, when they introduced that feature back in the days.
Thanks for coming in on your day off 👍
"You have a secret key that lives inside your OEM" is perhaps the most confusing way to state this, but what it means is, the manufacturer is the one with the private key, and the key on your motherboard is a _public_ key that verifies the signature against the certificate chain.
OEM management:
Hey we gotta make sure we offer secure boot just like our competitors.
*Proceeds to distribute certificates insecurely*
PR Changeset
"abcd" -> "abcde"
_Increased password entropy for encrypting the private key_
Not your keys, not your hardware
That's why you should never buy any computer with a firmware and design, code and deploy the boot, kernel and OS yourself, deciding by yourself how to interpret and possibly execute every single software you get access to.
Same for your car: you don't design the fuel you put in it, you don't decide of the design of the airbag: nothing but ownership issues !
Build you car yourself from raw mineral : THAT is ownership and security ! 🤣
Imagine if your manufacturer had the key to your car (or, more accurately, a key that opens all the same models of that car) and someone just carelessly leaves it somewhere in public.
And I have to argue, you only truly own your device when you've manufactured all the chips with your own billion dollar fab of course
@@emjizone There is a big huge jump from _having the only and only keys of your own vehicle,_ to "building it yourself from raw minerals". Your analogy is just plain bad and wrong.
@@emjizoneCringe take
"My video rate is going up because guees the world is on fire." should be the tagline of all of UA-cam at this point 😂😂😢
I thought most folks would use their own certificate authority for secure boot. Why would I trust a public CA if I don't have to? The main use case for public CAs is certificate distribution, e.g. for TLS over the public internet. Moreover, anyone who is self-signing their UKI would have to replace the CAs on the board - which I thought was basically everyone except maybe Windows users.
0:27 good, very good, the architecture is open and free still !
1:16 he said the thing! :D
I designed offline signing procedures for financial institutions. Damn if the devices are on the list, we might need to renew many of them (I'll physically destroy and blend them all) and get them re-audited by third parties >.> I'm also curious that Chromebooks' keys are safe. Those are securebooted linux.
Wow, Gigabyte is winning this one with the largest number and variety of compromised devices!
Intel/AMD/ARM Server boards, full Rackmount Servers, Mini-PCs... At this point I'm downright impressed by Gigabyte's consistency in upholding their poor reputation.
The problem rooted in the wish to do away with READ ONLY chip and TOTALLY replace it FLASHABLE chip.
The wish were granted but it has the consequences!
This feels like it's just one thing after another this year.
Honestly nobody in those corporations gives a shit as long as the money keeps on rolling in.
If they have access and admin rights to the machine to mess with secure boot... the house is on fire already. This just adds to the pwnage, but isn't the root cause of it.
The year of CyberPunk 😅🤣
UEFI never fails to fail
is UEFI now synonymous with RBMK ? 🤔☢️
UEFI was also the password
Sure the OEM(s) used secure boot certificate technology during manufacturing but they did so in a way that effectively undermines the whole reason to be implementing secure boot in the first place.
OEM managers were probably non technical and saw secure boot as no different as any item on a checklist. "We have it? Okay good".
Secure boot needs to be managed directly by sometime who has a technical understanding of securely distributing security certificates and the importance of doing so SECURELY.
So does this mean they want us to purchase a newer device and throw out our old device?
Imagine have 14th intel and these motherboard... We know its a bomb, but cant defuse it
This is why we need a non-flashable bios. It would solve the problem. However it does make a new problem. You can't update the microcode to fix issues things like the CPU.
Anti-tech movement making moves.
“if you’re a freak and use power shell” took me out
The problem with 2FA from what I've heard, is that many sites that use it require you to have a less secure 2FA option enabled, and it's a this OR that approach instead of this AND that. Meaning the more-secure option is not making the account more secure when an attacker only needs to attack the less secure 2FA, for example SIM swapping or something.
Security by obscurity AGAIN?
That is most cyber security. as long as someone doesn't have the key/password your safe enough but, if the secret gets leaked Pandoras box is opened.
Most encryption works by the keys not being known by everyone - that is, obscurity.
@@throwaway6478No, “the adversary doesn’t know the keys” is *not* “security by obscurity” . “Security by obscurity” is when the security is based on adversaries not knowing how the system works, and is *specifically in contrast to* security based on adversaries not knowing the secret keys.
this isn't security by obscurity this is security by password authentication with a stupidly low amount of bits of entropy so it was easy to crack
security by obscurity is when you use a reversible, simple cypher such as the alphabet +2 where A=C B=D and so on, or you hide passwords by checking the "show hidden files" box to unchecked or you take the first half and append it to the second half so ABCD becomes CDAB, THAT'S obscurity
Once you conflate "obscurity" with "secret" you realize that all security rests on a foundation of secrets, or obscurity.
A basic rule in cryptography is to always verify and never trust. This is why you should always be allowed to generate your own keys and only you should have a private key. Centralized 3rd parties are alwats going to be a major vulnerability.
the only reason i clicked on your video from the youtube suggestions is to tell you what i've been telling all these suspense and cliffhanger titlers which is this. if i don't know what the vid is about, there's a 96% chance i'm not going to waste my time clicking on it. i really wish artists like you would quit wasting youtube storage space.
DAMNIT! I ALWAYS do this. I come up with an idea as a prototype/proof of concept. Once I prove my hypothesis I pretty much shelve it. The last thing I worked on two years ago was an SSO dongle very similar to this YubiKey thing. I went super paranoid and used biometric - fingerprint - in order to access it. That way it had 2FA built in - something you are, and something you have. Your fingerprint is something you are - it's unique to you and nobody else can take it from you. The device is something you have, and it can physically be taken from you. Edit: Forgot to mention it was built around a Pico Pi for the prototype. Those are like $4 boards with a custom M0 Cortex chip called an RP2040 which is the microcontroller in the Raspberry Pi ecosystem. It can run MicroPython which makes writing the application code dirt simple and pretty safe as well. Writing native C can introduce memory bugs that could be exploited.
There is now a project developing an open source U2F dongle (part of what the yubikey does)... tricky part is getting a dongle that works U2F and SSH and GPG... and now they want us to use discoverable device resident crednetials called Passkeys which used to be called Password-less FIDO2 discoverable credentials. I dislike device resident creds for so many reasons including these dongles have VERY limited key storage space, and also U2F uses the same math and has same security as Passkeys but lets the host store a wrapped key (only the correct U2F dongle can decrypt the secret portion with its master key) which means they can be used for an unlimited number of logins on unlimited website (literally unlimited), but also an attacker with your key has to first find by trial and error which account that key opens and where... discoverable credentials are less good because the attacker now has the key and a list of what it opens... bypass the PIN (If one was set anyhow) and you're in.
Automation prevents human mistakes, but automation eventually breaks and when it does it reproduces the same mistake on every unit. This is an expected kind of issue. It will come back again some day..
No MSI. Whew. Dodged that one.
People saying secure boot doesnt make anything more secure and that its a proprietary stack that the user has no control over don't know what or how secure boot actually works. The user can reset, remove or distrust whatever keys they want and create their own to replace the Microsoft and oem keys to have full control over which signed binaries are allowed at boot
Can we please stop with crazy big exploits? Same with "historical moments".
I agree, they should've spread these out more as this many issues/attacks all at once is too much for cybersecurity professionals to handle. That's why I didn't go into cybersec, from what I've heard you will go from having nothing to do to everything burning down in the blink of an eye. I don't know why they do that when it would be more efficient to spread problems out.
Currently the french high-speed train network has been sabotaged by simply stealing cables. That's big exploit.
@@SterileNeutrino Oh God, I don't know if I laugh or I get scared lol
Yes, please, I'm already sick and tired of amount of historical moments that are happening right now
The PowerShell command has a typo in it. It should be double colon (::) rather than dot colon (.:) before the ASCII.GetString.
just checked on my laptop to see if I have one of those do not trust pk's ( i don't know anything about coding or IT so i'm just following the steps people show in the video), turns out it is indeed one of these which have this vulnerability, wtf do I do now? pray that no one hacks into my PC? I will probably buy a new one but how do I know that's not compromised as well?
Disabled secure boot to install arch a while back and forgot to turn it on again, totally forgot about it's existence till now
none of those cammands work and im not sure why
Hey man, love your work. Important question, I stumbled on this video, the day before I got a gigabyte B450M delivered. I opened the box containing all the components for my PC build to find all the components were factory sealed, except the motherboard. Of course, after watching this video, I'm paranoid. So I enquired with the supplier and the Gigabyte local representatives as well and I'm shocked to learn that the boxes are not necessary "factory sealed". This just seems absolutely bonkers, the supply chain from the manufacturer to consumer have just accepted that it's ok for this low level (again, lover the channel 😉) and vulnerable component to not be sealed. I think you should dive into this with an investigation, and call it out.
Looks like you have more juicy content to come in this year 😁
god fucking dammit that is at least 400 computers I'm responsible for that I'll have to check
root private keys must only be generated in Hardware Security Modules where the key CANNOT be exported in plaintext. Even Azure didn't adhere to this rule and had a SAML signing key leaked in a memory dump.
Hey Low Level Learning! I thought I recognized u from my Discord 🙂 Great video - I've always found "Secure" boot a bit sus, lol. Lore ur channel!
Secure boot was never meant for security, the only reason it exists is to make it more difficult for people to install Linux on budget Windows laptops which incentivizes them to buy a new laptop after a year or two when Windows automatically upgrades requiring double the RAM that was soldered onto your laptops motherboard.
quote: "What secure boot is supposed to be..."
That sounds scary already :)
I really wish you'd brought up Microsoft, Intel, etc. and their malfeasance subverting what was a good idea 30 years ago.
Embedded dev working on Secure Boot(SB) here: Correctly integrating secure boot is absolutely non trivial (esp. on non x86 devices). But my biggest concern is about people who are told to „enable secure boot on that device“, but who don’t understand how it works. For testing, test signatures are added to the db, but forgotten to be removed when shipping. In CI/CD pipelines the signing is done, but it is not carefully checked who can run the pipeline. Then there are signed recovery shells (used to recover broken devices), but with root access (making SB basically pointless). As said, it’s not so much about the technology, but about people using but not understanding it.
And then all the clueless weniees blame Microsoft, just like with CrowdStrike.
seems there is a lot of bad crap going on with tech at the moment.
Faulty CPU's, Data Breaches, Crowdstrikle fiasco, And now Secure Boot
Four character password: 1234 ...that's something an idiot would put on their luggage. "Honey! I'm ordering new luggage!"
7:45 Public keys don’t decrypt anything, they do the opposite. I guess it was just a naive slip.
With every processor and component out there backdoored there's no longer a practical reason for computer security. You want security? Write something on a piece of paper. You can't hack paper.
It happen when ever sales go down and new hardware have to be sold 😂
Ah Secure Boot getting what it deserves.
What? Secure Boot is a nice security feature. The only time when that type of feature is not OK is when the manufacturer does not allow 3rd party software and uses signing to prevent it. Like mobile phones do. Secure Boot even lets you enroll your own keys!
"What if we blame C again?" - Rustaceans, probably.
from one article "For reasons that aren’t clear, the test keys made their way into devices from a nearly inexhaustive roster of makers"
LAZINESS.
This is so incredibly easy to avoid... just have a unique key for every device. "But that would be sooo many keys for the vendor to keep in storage!" Not at all. You could have 100 million private keys and that would be (assuming 1028 bit) 1028 * 100 million = 100 Gb = ~12GB if stored efficiently. Oh no, one of the keys were leaked! Yea, that sucks for ONE device, but you give that customer a refund and move on. "But that database could be leaked!" Then multisignature all the keys with another key kept separately. My lord why are ALL of these recent security catastrophies so fundamentally simple to avoid. A 14 yr old with a multisig Bitcoin address has more security than what they did here...
We are WAY past due for a huge purge of any company that is laying off / outsourcing engineers which results in this mess. I'm so tired of this.
Wouldn't it be the height of irony, if he makes his next video on the Youbico hack...?
I’m fairly certain, and this is my opinion, there is a covert governmental campaign to minimize Microsoft/Windows market share into the future.
It’s crazy that the channel blew up so big that he had to change his name to Ed
A day in the life:
Wakes up 😊
Gets lower level learning notification: 😊
Sees title 😮
Watches vid :/😢
You can bet state actors aren't happy that someone is shining a light on a bypass that has existed for years.
Oh i was scared for a second. I turn that shit off.
About the course content on your website. Are the tutorials applicable to users running Linux or are they specific to Windows? Would someone with a Linux PC be able to follow along with the practice material while watching the video lessons?
Yubikey is amazing. I am planning to hand some out for Christmas this year.