Live data from Hacker News

Rediscovering the Intel AMT Vulnerability

tenable.com

71–80 of 94 posts

Re: Rediscovering the Intel AMT Vulnerability

#71

So does this cut down the attack to people on your network? Would a simple NAT protect me here? Also it's bizarre that they're disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don't read hacker news and who aren't exactly going to update their BIOS as an everyday thing.

This feature is only active if you set it up and configure it for your company/management system. Random Lenovo customers aren't at risk. The only people at risk are companies that set AMT up, and then they should be looking for security issues with all the vendors they use.

Re: Rediscovering the Intel AMT Vulnerability

#72

So does this cut down the attack to people on your network? Would a simple NAT protect me here? Also it's bizarre that they're disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don't read hacker news and who aren't exactly going to update their BIOS as an everyday thing.

If you're not a business customer you won't have AMT provisioned, so this hack won't work remotely. Apparently a local attacker could provision AMT and then perform the attack, but that's substantially less bad.

Re: Rediscovering the Intel AMT Vulnerability

#73
post #30
post #26

Earlier quoted context omitted.

Have you seen their reddit AMA regarding this?

Not the person you were replying to but I would really want to read this, do you have a link? edit I think i may have found it, is it this https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...

There still seems to be much confusion about the relationship between PSP and DASH (AMD's version of AMT).

Re: Rediscovering the Intel AMT Vulnerability

#74
post #52
post #24

Earlier quoted context omitted.

Having a "management engine" with direct access to the network and to memory is questionable in itself. Its code being secret indicates there's probably something bad going in. If it only does what Intel says it does, it doesn't need to be secret.

Unfortunately, a "management engine" with some degree of control over the CPU is necessary for, well, management. As in remote management, which is something that big corps with thousands of machines want, and the more control it gives the better. The code itself is as secret as the code of any proprietary Windows-based remote administration tool they could supply as a poor man's substitute if the ME didn't exist. It…

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium.

The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence.

All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel providing a signed confession. Both improbable and unrealistic. In many ways the detail, scale and scope of revelations in the past 5-10 years make skepticism and hard questions essential. The benefit of doubt has long moved the other way. This alternative is a kind of forced naiveté and denial.

Re: Rediscovering the Intel AMT Vulnerability

#75

Earlier quoted context omitted.

It does very little. As usual with AMT, there's a lot of noise, but these vulnerabilities to date have only been exploitable with activated AMT. With activation you can patch, etc. And as I always point out in these stories, if Intel AMT freaks you out, Google "absolute software embedded bios".

Black Hat Briefings 2009 - researchers show that the implementation of the Computrace/LoJack agent embedded in the BIOS has vulnerabilities and that this "available control of the anti-theft agent allows a highly dangerous form of BIOS-enhanced rootkit that can bypass all chipset or installation restrictions and reutilize many existing features offered in this kind of software." Black Hat 2014 - Kaspersky demonstrate…

Ah, the laptop anti-theft arms race.

Re: Rediscovering the Intel AMT Vulnerability

#76
post #23

Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header). Authentication still worked. We had discovered a complete bypass of the authentication scheme. What. the. fuck. This is not the kind of bug you should ship in anything if you have the barest bit of testing in place, much less a large…

Wow. Just Wow.

After reading about this over several days I would have never guessed it was such a gaping hole. This reminds me of a software bug I encountered in the 90s with a version of the Renegade BBS software (a Telegard hack). In one minor revision, you could login to any account by just not bothering to enter a password. Though the "sysop" (admin) account often had a custom name, for convenience, you could login by your user number and the sysop user number was always zero. A good friend of mine had his entire system wiped out by a malicious user with this little problem.

It doesn't sound like this is a matter of leaving the password field blank, but rather sending a request with a tool like cURL and setting the header to an empty/NULL response, but it's about as close to just as bad as you can get. Sheesh.

Re: Rediscovering the Intel AMT Vulnerability

#77
post #40

AMD have something similar to this, and there was some mentioning of this in an ama on reddit here: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea... What are the reasons for having this, I mean good business reasons? I get that designing cpus is expensive and they reuse as much they can, and that businesses would want the benefits or remote management. However when weighed up against the damage to trus…

> What are the reasons for having this, I mean good business reasons?

So, I'll avoid writing anything about NSA collusion or related speculation and talk specifically about what you've asked -- business reasons. The main reason is that customers are already purchasing technology like this through third-party expansion cards and this kind of technology makes those (expensive) adapters less necessary for those customers if its built into the CPU. At a past company I worked at, every HP Proliant server we purchased was purchased with a PCI Express adapter that was a full computer on a card. It came with a special cable that passed the 15-pin VGA output through the card and allowed complete control of the server (and we purchased the "Lights Out" edition which included battery power so that the server could be powered on remotely).

It allows one to do things you can't do through software remote management, like install the operating system, modify the BIOS settings, see POST messages at boot. It sounds like AMT offers a lot of this functionality without the need for that (I think $700) board, which would be appealing to a lot of enterprises, almost all of whom consider folks screaming about possible vulnerabilities in AMT as tin-foil-hat wearing security geeks, or have otherwise convinced themselves that "it'll never happen to me (or Intel, etc)". I, personally, tried in vein to point out the security threats that these third-party boards posed to the organization, being that the software could not be audited, was often used for years past the support date of the hardware (where security patching via firmware updates was no longer provided) and allowed complete and total access to the system in ways that even the worst OS vulnerability wouldn't (that was the point, after all), but was basically told that the benefits outweighed the risks[0].

The argument for using a management board, however, was a little easier to make than the argument for using AMT. Our security standards required that any device with a management interface be segregated to a high-security management network that, while not air-gapped, was protected via additional VPN and two-factor authentication and no access to the internet from within. It's unhelpful if the laptop of the administrator with the appropriate token is infected with something, but at least this allowed for one extra set of firewalls between those interfaces and the internet. Now...whether or not these boards were actually on said management network is anyone's guess and in the case of AMT-style software, there'd be no way to do something similar. These PCI-e boards were complete computers with their own isolated[0] network adapters.

[0] I'm not positive about this one and in all likelihood a sufficiently bad vulnerability might make that separation irrelevant, but AFAIK, the network adapters on these boards were not accessible to the OS and were used by the management interface, only. If that wasn't the case, that would have made a great argument for their elimination since the management network would then be accessible via corporate (which is what the server was plugged into) without the VPN connection.

Re: Rediscovering the Intel AMT Vulnerability

#78
post #23

Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header). Authentication still worked. We had discovered a complete bypass of the authentication scheme. What. the. fuck. This is not the kind of bug you should ship in anything if you have the barest bit of testing in place, much less a large…

Well... I agree with you in principle, but in practice I find developers often to forget that code fails the way it is supposed to fail, when it is supposed to fail. In the authentication case, everyone remembers to check that when you're supposed to be logged in, you can access what you should be able to access. But it's really common to not think to test that when you're not logged in you shouldn't be able to access what you should be able to access (when logged in), or that when logged in as user X you shouldn't be able to access user Y's stuff.

Re: Rediscovering the Intel AMT Vulnerability

#79
post #3

Earlier quoted context omitted.

To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.

That's more of an argument about inauditable, non-disableable, hostile (the CPU shuts itself off if you blank out the appropriate data structures) code running below ring 0

Don't forget in the majority of cases unupdatable too! (No vendor is going to issue fixes for old boards)

Re: Rediscovering the Intel AMT Vulnerability

#80
post #52

Earlier quoted context omitted.

Unfortunately, a "management engine" with some degree of control over the CPU is necessary for, well, management. As in remote management, which is something that big corps with thousands of machines want, and the more control it gives the better. The code itself is as secret as the code of any proprietary Windows-based remote administration tool they could supply as a poor man's substitute if the ME didn't exist. It…

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel pr…

> The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence.

Don't believe the FSF's FUD. TrustZone is really not comparable at all to Intel's Management Engine or AMD's Secure Processor:

* TrustZone is an operating mode of the CPU, not a separate processor. Fundamentally, it's not all that different from supervisor mode; it's just more privileged. (If you really wanted, you could probably write an OS that ran parts of the kernel in TrustZone.)

* You don't have to have anything running under TrustZone. Indeed, most processors which support TrustZone (e.g, most Android phones) aren't using it at all.

* The TrustZone specification is publicly available [1]. You can read about it all you want. (If you're brave enough and have the right development tools, you can even write code to run in it.)

* ARM's reference implementation of a TrustZone OS is also publicly available [2]. If you're curious how it works, you can see for yourself. (This doesn't include the application code which may be present in specific implementations, of course.)

[1]: https://www.arm.com/products/processors/technologies/trustzo...

[2]: https://github.com/ARM-software/arm-trusted-firmware

Post reply on HN