If I want a secure computer should I go with an older one with no intel ME or a newer one with secure boot and TPM?

[AmpleApricots]

When an intelligence government agency has a vested interest in you, your life is in the hands of people that are willin both to torture and to murder you and people close to you (and might or might not enjoy it) and the laws of the country you're in don't protect you anymore. Good luck with that.

If it's police/federal law enforcement you are worried might be after you, what you're up against can vary wildly from incompetent bumpkins who's whole IT forensics experience consists of checking the windows trashcan on the desktop to high level security specialists, anything is possible. The latter usually work privately because if you're good in the field, you can do better, government jobs aren't well paid and have often crazy hours and backlogs. (This is true for my country, it might not be true for yours) Usually here a robust encryption setup and (even more importantly) not cooperating is the smartest thing to do and your shins will probably remain unbusted for it. There's many tales you can find on the web where people talked themselves from "his shit is encrypted and we have no good proof, probably will have to let him go if he doesn't talk" to "can you believe he gave up his password willingly after we told him we already know everything and will go easy on him if he makes our job easier? He got ten years in the slammer". This happens faster than you think. If they look you up for a month or two while they're investigating you, it's easy to just crack and believe everything that's being told to you, especially since they WILL psychologically abuse and manipulate you in ways that are perfectly legal. As people have said, don't trust windows computers. Effectively, you have no idea what your OS does and with whom it talks and the sheer amount of malware which might or might not be allowed to be used by law enforcement where you are is mind-boggling. Same goes for any locked-down smart device. They're very attractive targets for very many eyes.

When going with linux, the route of a simple encrypted partition that's mounted by a kernel carrying an initramfs with all the important parts is the simplest. It is easy to set up by yourself. IMHO don't trust ready-made solutions by distributions because distro maintainers are the tranny jannies of the linux world and often have no idea what they're doing. The less moving parts there are, the less room there is for an exploitable mistake. It's really important to understand this stuff yourself to be safe and having to put trust into other people because you don't know how anything works IMO means that you can't effectively have a very safe setup. Sorry, just the way it is. Can't become the world's best chef knowing nothing about ovens! You can use features like the aforementioned secureboot/TPM to validate that the kernel/firmware/certain parts of the hardware is/are untampered. How much that will help to know in practice depends to be seen regarding your potential attackers and your setup. Even more interesting with this technology, you can "chain" the encryption of the data to your hardware, meaning making it impossible to just create an image of your hardddrive and just throw it on some cloud to have arrays of GPUs pummel it. (This might be more interesting than you think. An encryption that's unlikely to be broken now might be trivial to break in twenty years because of new discoveries be it technology or bugs in the encryption, and storing a HDD-image for twenty years is not a tall order for a government agency) Of course, if there's something wrong with your hardware, your data's gone.

If you're looking for security from criminals online, most common sense security measures (e.g. different user for your webbrowser task, sandboxing, don't click that naked_cowoker_pics.exe atttachment) are enough. They're usually looking for the low hanging fruits and there's plenty of them. Airgapping generally can't be beat. Good luck hacking that small paper notebook lying in the drawer of your desk. There'll never be a javascript exploit for that one.

 

[Bat Dad]

How is that supposed to be possible unless you have PXE enabled?
Which a home user has no need for.

ESPecter Bootkit Malware Haunts Victims with Persistent Espionage

The rare UEFI bootkit drops a fully featured backdoor on PCs and gains the ultimate persistence by modifying the Windows Boot Manager.

threatpost.com

Malicious bootkits are rare to find in the wild, ESET noted, with “only three real-world cases of UEFI malware [having] been discovered” prior to ESPecter.

The first was LoJax, discovered by ESET in 2018. Believed to have been used by the Russian advanced persistent threat (APT) known as APT28 (aka Fancy Bear or Sofacy), LoJax is a modified version of Absolute Software’s LoJack recovery software for laptops. LoJack hides on a system’s UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop. Unfortunately, a vulnerable 2009 version had several key bugs, chief among them a configuration module that was poorly secured with weak encryption – which the bad guys took advantage of in order to weaponize it.

Then there was MosaicRegressor, discovered by Kaspersky in 2019. It was spotted in the wild targeting diplomats and members of non-governmental organizations (NGOs) from Africa, Asia and Europe via email. All of the targets had ties to North Korea. MosaicRegressor is based on a customized version of the leaked source code of HackingTeam’s VectorEDK bootkit, according to an analysis at the time.

The third is a new version of the FinSpy surveillance kit uncovered by Kaspersky last week, which has a module that also compromises the Windows UEFI boot manager.

Even though fully fledged bootkits are few and far between, “in the last few years, we have seen proof-of-concept examples of UEFI bootkits (DreamBoot, EfiGuard), leaked documents (DerStarke, QuarkMatter) and even leaked source code (Hacking Team Vector EDK),” according to ESET researchers.

ESET researchers said that they don’t know how ESPecter is specifically distributed, but for initial compromise, it’s likely that it takes advantage of one of the various UEFI firmware vulnerabilities that allow disabling or bypassing Secure Boot.

Secure Boot is a security standard for PCs using UEFI that ensures that devices boot using only trusted software. For most computers, it’s the main barrier to compromise at the startup layer, and it must be disabled in order to successfully boot with a modified boot manager, ESET researchers noted.

“Though Secure Boot stands in the way of executing untrusted UEFI binaries from the ESP, over the last few years we have been witness to various [ways around it],” according to the analysis. “This shows that securing UEFI firmware is a challenging task and that the way various vendors apply security policies and use UEFI services is not always ideal.”

Other than exploiting a vulnerability, other possible scenarios for getting around Secure Boot include the following, according to the analysis:

• The attacker has physical access to the device (historically known as an “evil maid” attack) and manually disables Secure Boot in the BIOS setup menu. It is common for the firmware configuration menu to still be labeled and referred to as the “BIOS setup menu”, even on UEFI systems, ESET pointed out.
• Secure Boot was already disabled on the compromised machine (e.g., user might dual-boot Windows and other OSes that do not support Secure Boot).
• The first Windows version supporting Secure Boot was Windows 8, so machines running all previous versions are vulnerable to the attack.

Thus, keeping PCs up-to-date and correctly configured can help thwart an ESPecter attack.

 

[byuu]

ESPecter Bootkit Malware Haunts Victims with Persistent Espionage

The rare UEFI bootkit drops a fully featured backdoor on PCs and gains the ultimate persistence by modifying the Windows Boot Manager.

threatpost.com

This makes zero mentions of infecting an unbooted system through the network.
So I don't see how this is relevant.

Researchers aren’t sure yet how it’s distributed, but once ESPecter finds its way onto a PC, it begins its UEFI infection by modifying a legitimate Windows Boot Manager binary.

Sounds like it's infecting the BIOS from a booted Windows system instead like I talked about.

 

[Rusty Crab]

absolutely not true. the us is not gonna pop some spicy zero day on your ass because you post on kiwifarms and torrent dickgirl porn. unless you're selling kilos of drugs a day, forming a terrorist cell, etc, they're just gonna go "oh no we dont know what's going on"

Simply not true. There's no FBI agent sitting there watching you, but the NSA has had PRISM running forever and surely it's only expanded since the snowden days.

With default settings, literally every key you press is sent off to a microsoft server.

What data Windows 10 sends to Microsoft and how to stop it – HackMag

archived 4 Jun 2016 03:39:22 UTC

archive.md

 

[Bat Dad]

This makes zero mentions of infecting an unbooted system through the network.
So I don't see how this is relevant.


Sounds like it's infecting the BIOS from a booted Windows system instead like I talked about.

I'm not an expert, and I'm not pretending to be an expert. IDK why you are focused on "infecting an unbooted system". I don't know the relevance to this topic, but I guess one concern of this nature would be using a supply chain attack.

Why do you think that is an important consideration? If I understood what you are trying to get at, I might have a better answer. The main consideration is that if you are infected at that level, it is hard to get rid of. Wiping your hard drive is not going to get rid of it. The article I shared is regarding UEFI but it if you have compromised UEFI It's not out of the question that you may be able to flash microcode using the same methods.

One concern is that your firmware may be compromised somehow. That does not reside on your hard disk and a threat of that nature is going to be hard to detect with anti-malware software. The point is that the earlier in the boot process you can exploit, the harder to remove and detect it will be.

This specific quote is what I thought would be particularly telling, if you are aware of what LoJack is (was?)

The first was LoJax, discovered by ESET in 2018. Believed to have been used by the Russian advanced persistent threat (APT) known as APT28 (aka Fancy Bear or Sofacy), LoJax is a modified version of Absolute Software’s LoJack recovery software for laptops. LoJack hides on a system’s UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop. Unfortunately, a vulnerable 2009 version had several key bugs, chief among them a configuration module that was poorly secured with weak encryption – which the bad guys took advantage of in order to weaponize it.

LoJack for laptops was the same idea as LoJack for cars. It was integrated into the bios and was able to use networking without being fully booted into windows. It would contact the servers and hopefully you could locate the stolen laptop. Fancy Bear leveraged LoJacks (low level) networking abilities to fully compromise the system.

 

[byuu]

One concern is that your firmware may be compromised somehow.

Secure Boot is part of the firmware. So if that's fucked, Secure Boot is fucked.

A supply chain attack, that it could protect against would be something like getting an already infected counterfeit Windows install disc.

Fancy Bear leveraged LoJacks (low level) networking abilities to fully compromise the system.

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

The hackers changed the firmware from an hacked Windows system to exploit the UEFI module. It completely bypasses Secure Boot.

 

[Bat Dad]

The hackers changed the firmware from an hacked Windows system to exploit the UEFI module. It completely bypasses Secure Boot.

I don't think that's what this white paper says: My bad, I misunderstood what you were saying here. I thought you meant Fancy Bear had physical access to change the module. The concern is detecting and remediating a low level exploit. Or my concern, and my main point here.

The whitepaper does point out that in this specific instance secure boot would not have helped. But it also points out why a trusted execution env is important.

In May 2018, an Arbor Networks blog post described several trojanized samples of Absolute Software’s LoJack small agent, rpcnetp.exe. These malicious samples communicated with a malicious C&C server instead of the legitimate Absolute Software server, because their hardcoded configuration settings had been altered. Some of the domains found in LoJax samples have been seen before: they were used in late 2017 as C&C domains for the notorious Sednit first-stage backdoor, SedUploader. Because of this campaign’s malicious usage of the LoJack small agent, we call this malware LoJax.

From the link in the above quote:

• Proof of concept in using Lojack as a backdoor or intrusion vector date back to 2014. Its continued use suggest attackers could have used it in long-running operations.
• Initially, the Lojack agents containing rogue C2 had low Anti-Virus (AV) detection which increased the probability of infection and subsequent successful C2 communication.
• The distribution mechanism for the malicious Lojack samples remains unknown. However, Fancy Bear commonly uses phishing to deliver malware payloads as seen with Sedupload in late 2017.

The issue that I mentioned earlier regarding flashing microcode sems to be supported by the whitepaper as well:

Patching SPI flash memory with malware​

On systems that were targeted by the LoJax campaign, we found various tools that are able to access and patch UEFI/BIOS settings. All used a kernel driver, RwDrv.sys, to access the UEFI/BIOS settings. This kernel driver is bundled with RWEverything, a free utility available on the web that can be used to read information on almost all of a computer’s low-level settings, including PCI Express, Memory, PCI Option ROMs, etc. As this kernel driver belongs to legitimate software, it is signed with a valid code-signing certificate.

Secure Boot is part of the firmware. So if that's fucked, Secure Boot is fucked.

There is more than one microcontroller with firmware residing on it in a computer. There are many. For instance broadcom WiFi/BT firmware was recently exploited and that's not a threat you can easily detect with antivirus.

If you have an effective trusted environment for your cryptography, it's going to make all these threats much harder to pull off. And again nothing is fully secure, you just can't have that attitude when security is paramount. You can only harden things to the point where it is hopefully not worth the resources. When it comes to nation states as threats and as targets, nothing should be fully trusted. You should always operate with the assumption that you may be vulnerable.

---

Edit:
I think this part of the paper you linked covers most of your concerns:

Secure Boot is designed to protect against malicious components coming from outside of the SPI flash memory. To protect against tampering with the SPI flash memory, the system’s root of trust must be moved to hardware. Such technologies exist and Intel Boot Guard is a good example of this. It has been available starting with the Haswell family of Intel processors introduced in 2013. Had this technology been available and properly configured on the victim’s system, the machine would have refused to boot after the compromise.

Updating system firmware should not be something trivial for a malicious actor to achieve. There are different protections provided by the platform to prevent unauthorized writes to system SPI flash memory. The tool described above is able to update the system’s firmware only if the SPI flash memory protections are vulnerable or misconfigured. Thus, you should make sure that you are using the latest UEFI/BIOS available for your motherboard. Also, as the exploited vulnerability affects only older chipsets, make sure that critical systems have modern chipsets with the Platform Controller Hub (introduced with Intel Series 5 chipsets in 200.

Unfortunately for the ambitious end user, updating a system’s firmware is not a trivial task. Thus, firmware security is mostly in the hands of UEFI/BIOS vendors. The security mechanisms provided by the platform need to be configured properly by the system firmware in order to actually protect it. Firmware must be built from the ground up with security in mind. Fortunately, more and more security researchers are looking at firmware security, thus contributing to improving this area and raising awareness among UEFI/BIOS vendors.

Remediation of a UEFI firmware-based compromise is a hard problem. There are no easy ways to automatically remove such a threat from a system. In the case we described above: in order to remove the rootkit, the SPI flash memory needs to be reflashed with a clean firmware image specific to the motherboard. This is a delicate operation that must be performed manually. It is definitely not a procedure that most computer owners are familiar with. The only alternative to reflashing the UEFI/BIOS is to replace the motherboard of the compromised system outright.

 

[byuu]

Patching SPI flash memory with malware​

On systems that were targeted by the LoJax campaign, we found various tools that are able to access and patch UEFI/BIOS settings. All used a kernel driver, RwDrv.sys, to access the UEFI/BIOS settings. This kernel driver is bundled with RWEverything, a free utility available on the web that can be used to read information on almost all of a computer’s low-level settings, including PCI Express, Memory, PCI Option ROMs, etc. As this kernel driver belongs to legitimate software, it is signed with a valid code-signing certificate.

This only confirms that the firmware was changed from a compromised Windows using a kernel driver that came from a random downloaded utility.

There is more than one microcontroller with firmware residing on it in a computer. There are many. For instance broadcom WiFi/BT firmware was recently exploited and that's not a threat you can easily detect with antivirus.

And to attack any of these you either need physical access or full access to the booted system.

And those threats are as "easily" detectable by an antivirus than anything else because all an antivirus can do is check against a database of known malware. It makes no difference if it's code that injects crap into the kernel or into the firmware.

 

[Bat Dad]

Is the point you are making is that nothing is categorically secure? Because I agree. That's one of the first things I posted ITT. I'm not debating that secure boot or TPM or any other specific tech is good, or even effective. Just that there is a theoretical threat that would benefit from having a less secure boot process. I don't use secure boot myself, and other than turning it off, I've never (knowingly) had any interaction with it.

And to attack any of these you either need physical access or full access to the booted system

If an attacker has root on an already running system, is there no point in trying to secure the boot process? What happens if you remove the threat on the running machine, but the attacker has successfully gained persistence by residing in the insecure boot process?

Depending on the amount of memory they are able to access, they could write malware that lives in some SPI memory chip. One that injects a process during each boot to acquire root privileges. They could make random changes in the payload each time you boot to avoid detection by antivirus software once the AV service has started. I'm not saying that exists, but theoretically I think it could.

If the TPM is intact, then only approved parties should be able to sign software that would pass secure boot checks during start up. That is the idea, in my understanding. Supposedly, if anything is fishy it just won't completely boot.

I remember when secure boot was announced and people were not too happy about it. IDK if those worries have been justified, but I barely notice it TBH. I don't particularly trust it, though. I think it likely that the more complexity that is added, the easier it is to attack. Not the other way around. At the time, people were (rightly) concerned that it would just be another DRM for these assholes to control customers access to shit we bought and paid for. That doesn't seem to have been a real big concern, outside those Windows RT turds. Maybe because the announcement was so unpopular that they allowed the functionality to be disabled. Or maybe they intended that all along, who knows.

Sounds like it's infecting the BIOS from a booted Windows system instead like I talked about.

An interesting sidenote, a couple of years ago the Linux Mint servers were hacked, and the hackers uploaded an infected ISO image & checksum to the servers. Then the Linux Mint website distributed it, only for a day or something.

 

[byuu]

Is the point you are making is that nothing is categorically secure? Because I agree. That's one of the first things I posted ITT. I'm not debating that secure boot or TPM or any other specific tech is good, or even effective. Just that there is a theoretical threat that would benefit from having a less secure boot process. I don't use secure boot myself, and other than turning it off, I've never (knowingly) had any interaction with it.

No, not really. My point is there no use for Secure Boot for a home user since I can't think of single realistic scenario where Secure Boot would save you from getting your system compromised.
And you shouldn't conflate TPM and Secure Boot. They are different things and you can have one without the other.

Depending on the amount of memory they are able to access, they could write malware that lives in some SPI memory chip. One that injects a process during each boot to acquire root privileges. They could make random changes in the payload each time you boot to avoid detection by antivirus software once the AV service has started. I'm not saying that exists, but theoretically I think it could.

Which would mean the whole BIOS is compromised. Secure Boot does not protect against that.
That's what TPM and the like would be for.

 

[Bat Dad]

No, not really. My point is there no use for Secure Boot for a home user since I can't think of single realistic scenario where Secure Boot would save you from getting your system compromised.

Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.

The OEM can use instructions from the firmware manufacturer to create Secure boot keys and to store them in the PC firmware. When you add UEFI drivers, you'll also need to make sure these are signed and included in the Secure Boot database.

For information on how the secure boot process works included Trusted Boot and Measured Boot, see Secure the Windows 10 boot process.

That's what TPM and the like would be for.

Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A TPM chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper-resistant, and malicious software is unable to tamper with the security functions of the TPM. Some of the key advantages of using TPM technology are that you can:

• Generate, store, and limit the use of cryptographic keys.
• Use TPM technology for platform device authentication by using the TPM’s unique RSA key, which is burned into itself.
• Help ensure platform integrity by taking and storing security measurements.

The most common TPM functions are used for system integrity measurements and for key creation and use. During the boot process of a system, the boot code that is loaded (including firmware and the operating system components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for how a system started and to make sure that a TPM-based key was used only when the correct software was used to boot the system.

TPM-based keys can be configured in a variety of ways. One option is to make a TPM-based key unavailable outside the TPM. This is good to mitigate phishing attacks because it prevents the key from being copied and used without the TPM. TPM-based keys can also be configured to require an authorization value to use them. If too many incorrect authorization guesses occur, the TPM will activate its dictionary attack logic and prevent further authorization value guesses.

 

[byuu]

For information on how the secure boot process works included Trusted Boot and Measured Boot, see Secure the Windows 10 boot process.

This combines a lot of different technologies.

Secure Boot does not require a Trusted Platform Module (TPM).

Secure Boot Overview

 

[Bat Dad]

My point is there no use for Secure Boot for a home user...

Well, then your point is wasted. I said at the beginning of the thread that it's unlikely for random joe to be a target of sophisticated attacks.

...since I can't think of single realistic scenario where Secure Boot would save you from getting your system compromised.

It's not meant to keep your system from being compromised. It's meant to prevent an already compromised system from booting.

Secure Boot does not require a Trusted Platform Module (TPM).

Again, not sure what you are responding to. I never said it was a requirement.

Implementation of UEFI Secure Boot is part of Microsoft’s Trusted Boot Architecture. A growing trend in the evolution of malware exploits is targeting the boot path as a preferred attack vector. This class of attack has been difficult to guard against, since antimalware products can be disabled by malicious software that prevents them from loading entirely. With Windows 8.1’s Trusted Boot architecture and its establishment of a root of trust with Secure Boot, the customer is protected from malicious code executing in the boot path by ensuring that only signed, certified “known good” code and boot loaders can execute before the operating system itself loads.

 

[byuu]

Well, then your point is wasted. I said at the beginning of the thread that it's unlikely for random joe to be a target of sophisticated attacks.

Even against a sophisticated attacker (without physical access) it doesn't offer any real benefit.

It's not meant to keep your system from being compromised. It's meant to prevent an already compromised system from booting.

And that's the problem. You're already fucked before Secure Boot can even do anything.

Even if you use the whole Windows 11(TM) chain of technologies you need for Secure Boot to actually protect anything.
So your UEFI bios gets verified, which then verifies the boot loader (this is the only thing Secure Boot does), then the boot loader verifies the kernel, then the kernel verifies the drivers and kernel modules (and in this long chain you only need to find one weak link to break it all), you're still left with untrusted userspace which includes things that Windows will autostart after boot.
So the malware can infect anything that the user will grant privileges (like monitoring for any new setup files you download), have access to all your private data (and scan it for passwords or encrypt it all for ransomware), can infect any application you use* (and for example replace your browser with a compromised one that sends all your entered logins and credit card numbers back to the attacker). Even after reboot.

So now you also have make sure all userspace software is trusted and only allow software to run that comes verified right from the Microsoft Store.
Then the whole trusted computing might actually improve security and not just introduce new attack vectors through the increased complexity of it all, as long as Microsoft, who are infamous for fucking up security, or pc OEMs, who are even less competent at it, don't fuck anything up.


* or just change all the shortcuts you launch it from if they reside in a protected area

 

[Likely]

No, not really. My point is there no use for Secure Boot for a home user since I can't think of single realistic scenario where Secure Boot would save you from getting your system compromised.

Secure boot helps establishes a chain of trust from boot to desktop. It's responsibilities might be over once the kernel's signature is verified and jumped into, but that chain of trust means that the kernel can now be trusted to be intact.

An actual once-common attack, that secure boot (and the resulting chain of trust) has almost completely wiped out against desktop users, was viruses installing kernel-mode drivers/rootkits that allowed them to persist across boots.

Actually, this goes beyond attacks, because it also means that for a company to deploy a kernel mode driver, they have to go through the Microsoft driver verification and quality process. This in turn helps Microsoft ensure that drivers in the wild meet a minimum quality bar, which reduces problems/bugchecks, and thus increases user satisfaction/reduces support calls.

 

[byuu]

Secure boot helps establishes a chain of trust from boot to desktop. It's responsibilities might be over once the kernel's signature is verified and jumped into, but that chain of trust means that the kernel can now be trusted to be intact.

An actual once-common attack, that secure boot (and the resulting chain of trust) has almost completely wiped out against desktop users, was viruses installing kernel-mode drivers/rootkits that allowed them to persist across boots.

A thing that Secure Boot doesn't protect against at all but kernel driver signing does instead?

 

[DaddyDickDown]

The chink spyware is already in your firmware bro. Just get over being spied on.

 

[Likely]

A thing that Secure Boot doesn't protect against at all but kernel driver signing does instead?

Yes, and kernel driver signing cannot be trusted without full boot chain of trust.

If someone compromises the bootloader, they have compromised the kernel.
If they have compromised the kernel, they have compromised driver verification.

You cannot have kernel driver signature verification integrity without some sort of full boot chain of trust, the first part of which is verified by Secure Boot. That is how Secure Boot provides benefit to, and helps protect, desktop users.

 

[Rusty Crab]

As others have stated, all this stuff about bootloaders can be circumvented with rubber hose cryptography.
You should really just prevent it from getting to that stage at all.
Just using linux distros with a trustwothy VPN gets you 90% of the way there.
If you have to worry about secureboot, you're probably already targeted and it's probably too late.

 

[Scumhook]

I think what everyone else is really trying to say, is to install Nortons and you'll be fine.

If you want to be double bagged, install Nortons, then run another Windows inside VirtualBox and put Nortons on that as well.

Bonus, with the second methodology, you will see a significant performance increase, as well as an enhanced feeling of safety and calm.