Intel AMT strikes again. I imagine this problem will only increase in the future, now that more malware creators know they can try to use this CPU backdoor (okay, this "totally-not-intended-for-bad-things and super-useful remote connection enterprise feature").
Exploiting vPro / AMT / any remote access mechanism from any chip maker is hardly a new idea.
AMT and AMD's equivalent (don't remember the name) has been a holy grail for security researchers and malware authors alike for many years. People have been begging Intel for a very long time to make business-tier chips without remote access capabilities.
For personal computing, at least we have enthusiast chips. For example, my i7 K model lacks the technology.
EDIT: AMD's remote tech is called Platform Security Processor (PSP). Thank you, jacquesm!
It isn't present AFAIK, because Intel cuts corners on enthusiast chips they do not expect to be used in a networked environment in order to save money, and still charge you more than the non-enthusiast counterparts.
I couldn't truly say whether Intel bins all of their processors with the same prefab or not, I'm not sure how to find this out either.
My working theory however is that since my chip lacks vPRO / AMT and I have not been able to find any indication it exists on the chip even in a dormant state, there may be more than one prefab used for binning.
However they could be using the same prefab for all.
ME is there (ability to execute below ring -1). Go ahead and check it right now, look at lspci/device manager for Management Engine Communications device. Its present on cheapest desktop H81 motherboards, and on highend (at the time) Z87 ones, no matter the cpu.
I have done that before, and I've just done it again, and I don't get anything. The only thing present on my system related to ME afaik is the MEI linux driver, which is pretty useless without a ME to talk to.
According to ARK [0], vPRO is absent. I have done various other system queries and nothing has turned up.
Anything else you want me to query? And where do you get this information that ME is present in all chips? Having a motherboard that supports ME is irrelevant, if the chip has no ME.
> People have been begging Intel for a very long time to make business-tier chips without remote access capabilities.
Yes. But somehow, any time anyone brings up wanting a device without one, people start poo-pooing the idea. "Just don't use it." "That's paranoid." "Just another CVE, yawn."
In a ton of discussions over the years, I have yet to hear a single plausible, benign reason for why the ME's 30 minute timer must be impossible to disable by the owner of the chip.
Maybe because everyone, who had any clue, knew since the begging what was ME intended for. The only news here is that "wrong" guys used this backdoor (again, nothing unexpected).
> When contacted by Microsoft, Intel said the PLATINUM group wasn't using any vulnerability in the Intel AMT SOL interface, but this was another classic case of bad guys using a technology developed for legitimate purposes to do bad things.
Worst excuse ever. "Look guys, at least it's not a backdoor we left on purpose!!!"
2) Disconnect from the network. This, of course, won't stop local attacks on the AMT or ME.
This is why I've been complaining about the ME forever. Forcing a privileged black-box that can't be disabled in to every CPU is... not suspicious all.
Even worse are some implementations. I have a Supermicro all-in-one MB that I used in building a home storage server. It has two gig-ethernet ports. About two months ago, I was rearranging around the machine, and when I plugged it back in, apparently I switched the ethernet port plugged in to the switch to the "primary" interface.
And one of the monitors goes off a few minutes later - there's a new network device on my private network. Turns out a web interface to the ME comes up automatically when using the primary NIC - it got a DHCP lease and was happily waiting to be managed - with the default creds ADMIN/ADMIN.
I thought that we had that one figured out, but apparently not. Yes, I should have read the manual for the motherboard, but that's beyond absurd. And, I guess, a good reminder to trust nothing.
>How can the consumer stop someone from exploiting this hack?
[Remove Intel ME](https://github.com/corna/me_cleaner) to the largest extent possible. I don't know of equivalent tools for AMD, though, which also has similar systems in place.
We're a long way until free hardware design are a thing, for a more immediate solution, try this:
If it's processing power you need, I guess the ASUS KGPE-D16 with Libreboot would to the trick.
As a laptop - X200, X200T, T400, T400s, T500, etc.
You can find a list of vendors here: https://libreboot.org/suppliers.html
An ARM CPU is just a core. SoCs probably do have this, pretty often. I know the Raspberry Pi's got a separate processor core running closed-source Broadcom software, and which has access to the system's memory.
Aaaand I think this is the first public disclosure of malware using the Intel Management Engine / AMT's network connection (that uses SMBus, i talked about it here https://news.ycombinator.com/item?id=14309557 and gave links to appropriate datasheets). Welp.
AMT/ME being used by malware created by well-resourced adversaries is no surprise, and is why Intel needed to give an irreversible and verifiable way of completely disabling it.
AMT is disabled by default on most consumer PCs or at least it's not expose itself. Though AMT work on top of ME and ME is opposite: it's always active and required for system to operate.
If ME firmware not found CPU will shut down every 30 minutes or something. There also way to neutralize some part of ME firmware while keeping system operational, but it's hard to tell how effective this is actually.
I posted it below already, but anyway as far as I personally understand to provision AMT you need it actually enabled in BIOS / EFI and it's in fact usually disabled by default.
Privileged users usually have BIOS access. BIOS's are often designed to be configurable/flashable with vendor-specific tools that your run on top of your OS.
AMT exploits are a side channel attack. AMT has it's own processor, loads from it's own ROM separate from the BIOS and has it's own network stack but has full access to the system at a hardware level. AMT System Management Mode hooks in to the CPU at ring level -2, below the OS and is remotely exploitable.
If it isn't verifiable, how can you check if the article's statement is true for your particular machine?
And moreover, the article continues with Microsoft can't say if these state-sponsored hackers found a secret way to enable this feature on infected hosts
There's a second bug that allows a non-privileged local user to provision it.
"An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs"
Also a privileged local user can provision it -- which is also pretty horrific, and that's not even a bug, it's how it's designed! Also "provision manageability features" is such an awkwardly euphemistic phrase here tbh, it's like reading leaked classified documents talking about "implanting" systems.
Isn't it supposed to be enabled in BIOS in order to provision it? On most laptops and desktop motherboards such features simply disable by default like VT-d (IOMMU).
The only way to be sure it's off is by severing the link between the LM-suffixed Intel Ethernet chip and the PCH. There are two links, the 'normal' one (often MII type, sometimes PCI(e)), and the OOB-one, via SMBus or a comparable I2C style bus between the PCH and the Ethernet chip.
Another way that hasn't been verified since in theory the ARC controller could access other PCI devices anyway, is to install a new ethernet card in a free expansion slot and use that instead. AMT is supposedly only supported with a specific CPU, firmware, PCH and PHY combination. Breaking that chain by swapping one of those components with an unsupported one should work. If you simply don't use any of the AMT-enabled interfaces, it shouldn't be able to communicate at all. Best plug in a chopped off ethernet jack to make sure nobody plugs in a cable by mistake.
I believe there was a 802.11 variant as well, but that might have been before AMT and around the Centrino era. Best disconnect that as well...
Is it a free proxy? Some asshole may have been using the proxy to scrape or ddos the website perhaps? Or perhaps someone did various other nefarious things such as spam comments or harass people.
It's funny that the image of the CPU in the article is a P4-era socket 478 model, which AFAIK comes from a time when Intel ME didn't exist in its current form yet... somewhat like showing a late 80s vehicle in an article about hacking self-driving cars.
"Intel AMT SOL technology" - a most ironic acronym for this situation...
I suspect that one can partially mitigate this risk by removing the network card from a laptop motherboard and using a USB network device that requires a software driver.
Another round of crappy journalism. It's not obscure, it's not a CPU feature but a platform feature, and there are plenty of out-of-band communication channels out there, this isn't the only one. On top of that, this was already published two DEF CONs ago.
You can exfil data and even do practival bi-directional communication over: SOL, IPMI, ASF, MT's ARC CPU via injected firmware and then via TCP/IP. Any of them will work. Add vendor-specific firmware addons on top of that (i.e. Broadcom tends to have exploitable firmware in their NIC controllers)
Most of them are in a vulnerable state by default because the technology was supposed to be 'easy' and 'user friendly', but 'users' don't even know what they are, and most deployments are done by the WinTel horde that doesn't actually know anything outside the Microsoft framework. (and thus leave the defaults as-is)
That's not quite the right question: this is just standard use of a remote management feature which is disabled by default. If you enable any remote management service, which are extremely common on server class hardware and many enterprise desktop devices regardless of vendor, you have to take responsibility for securing the management features you enable.
The only real news would be if this was enabled by default or if the design didn't allow it to be secured.
It also seems to rely on "unexpected functionality by buggy code". There were flaws in basic luxury functionality like JPEG parsing that allows anyone to overwrite certain pieces of memory regardless of it's signature or write protect bits. It was then used as a jumping pad to enter the ARC CPU and have total system control from there. Basically, unless you desolder the flash, it's a rootkit you can't get out.
It's surprising that everyone is up in arms about AMT and ME while not complaining in the slightest about SGX. SGX allows third parties to run code on your processor that is outside of your control. We're losing our computers to corporate interests. You are buying a device they can remotely manage, exert control with a higher privilege than yours, hide secrets inside your machine, and make all the decisions for you. To be even more dramatic, you are purchasing your own enslavement.
SGX, if they allow arbitrary code to be signed, is amazing. It enables remote trust. You could execute jobs "in the cloud" without anyone being able to see your data. You could write a known-correct coin tumbler or trading platform.
If it does only get locked to a few code authors, that would be a tremendous shame.
If Intel is the one source of ultimate trust, why not just run your secure whatever on Intel's servers? Seems a lot less complex than jumping through all these SGX hoops.
companies that make the bios were* the other sources of "ultimate trust". why not let them...
*then came uefi.
hoop-jumping never a problem with the i.t. market. more complexity is fine so long as managed by someone else. only the sales pitch needs to be simple.
why is it unfathomable that users could only trust themselves and other users? continual push toward more complexity helps keep users from ever believing this is achievable.
Can you explain how, exactly? Spyware would need to call out to system APIs to do anything useful, and that's not something that can be done inside an enclave.
Sure, it'd let you be a bit sloppier with randomware, not needing public key crypto to make it all work. Not really a huge deal.
Yes I can. In past there was many cases when normal software and even distributed drivers contained different kind of malware. After some point someone find it and it's become detectable, there was scandal and way to remove it. Also there was very serious risk that if some company put backdoor into their software it's will be found and company will be sued at least.
If something like SGX become publicly available then a lot of proprietary software and content manufacturers going to use it for DRM purposes. So efficiently it's will be everywhere.
Now imagine that every company can put sleeping backdoor in their software that can't be found by reverse engineering. Then they can activate it on demand for purposes of industrial espionage. Or they can simply ship own version of backdoor to ever customer and then pretend it's was some "bug" when someone detected it's activity.
I think you might not understand SGX's capability. It's just a compute kernel. So if they're taking data from your system, that's still very visible. And if they are sending data, that's also visible. So, sure, it's handy to hide logic. So the WannaCry thing, you'd be able to see it does DNS queries, but not how it determined a certain outcome based on the inputs. But you can't hide, for instance, a keylogger.
I perfectly understand what you pointing to, but problem of black box running in every piece of software is massive. Anyone could use it to implement remote backdoor in software and then pretend it's just a DRM that talking with licensing server.
Yeah it's could be detected when it's start to be active, but it's doesn't have to. It's could be idle on PC for years undetected just waiting for remote command, trigger or special payload just for you.
PS: Also fact that secure enclave itself can't access system API mean nothing because half of software already have interpreters in it as well as frameworks for every possible activity bad or good.
It's not a black box. SGX code is unencrypted even at runtime, and as long as its running that code has to remain present and unencrypted. You can detect it at any time, not just when it starts up.
A bit too late response, but anyway. There is already apps that use SGX to safely work with DRM or private keys. If there is a way keep keys secret what would stop anyone from implementing interpreters that will keep code secret?
The reason is that SGX doesn't do remotely the same thing that AMT and ME do. Code that uses SGX doesn't gain privileges it didn't have (in fact, it loses privileges even compared to normal usermode code). It can be scheduled/killed by the OS the same as any other user code, and the feature can be disabled wholesale via firmware (the processor will not shutdown after 30 minutes like it does when ME is prevented from running). The code running in the enclave is also not encrypted; only data it generates at runtime is, so you can inspect it and decide whether you want to run it just fine. Kernels can't even use it directly, so I'm not sure how SGX helps anybody "make all the decisions for you".
In fact, SGX is probably the only way to get some semblance of a defense against compromised ME and SMM code. There's even a number of open source projects that use it (e.g. [0]). To be even more dramatic, not every acronym Intel comes up with is Pure Evil.
SGX is the ultimate DRM. Once SGX programs talk directly to monitors that support some HDCP like protocol, it will be the end of ad/tracker blockers. Web pages will run in SGX land.
The ultimate DRM is a system that runs unencrypted code with unencrypted inputs/outputs (i.e. trivially simulated) with an attestation mechanism for providing some evidence that the output is in fact from that algorithm? The most DRM-ish thing I can think of doing with that is making sure that e.g. your browser runs whatever script the server sends, except you can feed it fake data (it can't communicate with the outside world except through code you control) and you can view and modify the code and run it in parallel outside SGX. Hardly ultimate.
> Intel ME runs even when the main processor is powered off, and while this feature looks pretty shady, Intel built ME to provide remote administration capabilities to companies that manage large networks of thousands of computers.
So they exposed millions of consumer and business computers in order to satisfy a niche enterprise usecase? Why is this not something that has to be manually turned on?
Intel ME has always sounded like a glaring security risk. Another operating system running in the background that can run it's own network stack? This is 100% being exploited by intel agencies.
Extensions like AMT do need to be manually enabled, but ME itself is always running a big old pile of encrypted code that we'll never get to look at, and yes there's a better than even chance there are exploits in that code only nation states could find (hopefully anyway).
83 comments
[ 817 ms ] story [ 1796 ms ] threadAMT and AMD's equivalent (don't remember the name) has been a holy grail for security researchers and malware authors alike for many years. People have been begging Intel for a very long time to make business-tier chips without remote access capabilities.
For personal computing, at least we have enthusiast chips. For example, my i7 K model lacks the technology.
EDIT: AMD's remote tech is called Platform Security Processor (PSP). Thank you, jacquesm!
It's not really new that Intel and AMD do binning to get more yield.
My working theory however is that since my chip lacks vPRO / AMT and I have not been able to find any indication it exists on the chip even in a dormant state, there may be more than one prefab used for binning.
However they could be using the same prefab for all.
Thus, "AFAIK".
According to ARK [0], vPRO is absent. I have done various other system queries and nothing has turned up.
Anything else you want me to query? And where do you get this information that ME is present in all chips? Having a motherboard that supports ME is irrelevant, if the chip has no ME.
[0] https://ark.intel.com/products/88195/Intel-Core-i7-6700K-Pro...
sudo intelmetool -s
Im pretty sure Intel BootGuard is ME based
Same questions apply to you. This is something I would like to be proved wrong on, as I don't want a false since of security.
PSP: Platform Security Processor
Yes. But somehow, any time anyone brings up wanting a device without one, people start poo-pooing the idea. "Just don't use it." "That's paranoid." "Just another CVE, yawn."
In a ton of discussions over the years, I have yet to hear a single plausible, benign reason for why the ME's 30 minute timer must be impossible to disable by the owner of the chip.
> When contacted by Microsoft, Intel said the PLATINUM group wasn't using any vulnerability in the Intel AMT SOL interface, but this was another classic case of bad guys using a technology developed for legitimate purposes to do bad things.
Worst excuse ever. "Look guys, at least it's not a backdoor we left on purpose!!!"
m(
Does anyone know about similar AMD vulnerabilities?
The cynic in me thinks that some execs got FISA orders.
How can the consumer stop someone from exploiting this hack?
2) Disconnect from the network. This, of course, won't stop local attacks on the AMT or ME.
This is why I've been complaining about the ME forever. Forcing a privileged black-box that can't be disabled in to every CPU is... not suspicious all.
Even worse are some implementations. I have a Supermicro all-in-one MB that I used in building a home storage server. It has two gig-ethernet ports. About two months ago, I was rearranging around the machine, and when I plugged it back in, apparently I switched the ethernet port plugged in to the switch to the "primary" interface.
And one of the monitors goes off a few minutes later - there's a new network device on my private network. Turns out a web interface to the ME comes up automatically when using the primary NIC - it got a DHCP lease and was happily waiting to be managed - with the default creds ADMIN/ADMIN.
I thought that we had that one figured out, but apparently not. Yes, I should have read the manual for the motherboard, but that's beyond absurd. And, I guess, a good reminder to trust nothing.
[Remove Intel ME](https://github.com/corna/me_cleaner) to the largest extent possible. I don't know of equivalent tools for AMD, though, which also has similar systems in place.
IBMs POWER processors are comparable to high-end Xeons and the specifications are entirely open.
I'd love to see a new "Talos" effort in light of recent events: https://www.crowdsupply.com/raptor-computing-systems/talos-s...
If it's processing power you need, I guess the ASUS KGPE-D16 with Libreboot would to the trick. As a laptop - X200, X200T, T400, T400s, T500, etc. You can find a list of vendors here: https://libreboot.org/suppliers.html
The former, probably not.
The latter probably have something similar --- and they're even less publicly documented than Intel ME/AMT or AMD's equivalent.
AMT/ME being used by malware created by well-resourced adversaries is no surprise, and is why Intel needed to give an irreversible and verifiable way of completely disabling it.
The article said it comes disabled by default. Isn't this a verifiable way, or is the article incorrect?
If ME firmware not found CPU will shut down every 30 minutes or something. There also way to neutralize some part of ME firmware while keeping system operational, but it's hard to tell how effective this is actually.
Am I missing something?
And moreover, the article continues with Microsoft can't say if these state-sponsored hackers found a secret way to enable this feature on infected hosts
"An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs"
https://security-center.intel.com/advisory.aspx?intelid=INTE...
Another way that hasn't been verified since in theory the ARC controller could access other PCI devices anyway, is to install a new ethernet card in a free expansion slot and use that instead. AMT is supposedly only supported with a specific CPU, firmware, PCH and PHY combination. Breaking that chain by swapping one of those components with an unsupported one should work. If you simply don't use any of the AMT-enabled interfaces, it shouldn't be able to communicate at all. Best plug in a chopped off ethernet jack to make sure nobody plugs in a cable by mistake.
I believe there was a 802.11 variant as well, but that might have been before AMT and around the Centrino era. Best disconnect that as well...
"Intel AMT SOL technology" - a most ironic acronym for this situation...
You can exfil data and even do practival bi-directional communication over: SOL, IPMI, ASF, MT's ARC CPU via injected firmware and then via TCP/IP. Any of them will work. Add vendor-specific firmware addons on top of that (i.e. Broadcom tends to have exploitable firmware in their NIC controllers)
Most of them are in a vulnerable state by default because the technology was supposed to be 'easy' and 'user friendly', but 'users' don't even know what they are, and most deployments are done by the WinTel horde that doesn't actually know anything outside the Microsoft framework. (and thus leave the defaults as-is)
I probably posted something similar on https://news.ycombinator.com/item?id=11913379
Is it bad? Yes. Is it new? No. Is it ever reported on correctly? Also no.
Read about AMD PSP / ARM TrustZone.
That's not quite the right question: this is just standard use of a remote management feature which is disabled by default. If you enable any remote management service, which are extremely common on server class hardware and many enterprise desktop devices regardless of vendor, you have to take responsibility for securing the management features you enable.
The only real news would be if this was enabled by default or if the design didn't allow it to be secured.
If it does only get locked to a few code authors, that would be a tremendous shame.
*then came uefi.
hoop-jumping never a problem with the i.t. market. more complexity is fine so long as managed by someone else. only the sales pitch needs to be simple.
why is it unfathomable that users could only trust themselves and other users? continual push toward more complexity helps keep users from ever believing this is achievable.
Sure, it'd let you be a bit sloppier with randomware, not needing public key crypto to make it all work. Not really a huge deal.
If something like SGX become publicly available then a lot of proprietary software and content manufacturers going to use it for DRM purposes. So efficiently it's will be everywhere.
Now imagine that every company can put sleeping backdoor in their software that can't be found by reverse engineering. Then they can activate it on demand for purposes of industrial espionage. Or they can simply ship own version of backdoor to ever customer and then pretend it's was some "bug" when someone detected it's activity.
Yeah it's could be detected when it's start to be active, but it's doesn't have to. It's could be idle on PC for years undetected just waiting for remote command, trigger or special payload just for you.
PS: Also fact that secure enclave itself can't access system API mean nothing because half of software already have interpreters in it as well as frameworks for every possible activity bad or good.
In fact, SGX is probably the only way to get some semblance of a defense against compromised ME and SMM code. There's even a number of open source projects that use it (e.g. [0]). To be even more dramatic, not every acronym Intel comes up with is Pure Evil.
[0]: https://github.com/ayeks/TresorSGX
So they exposed millions of consumer and business computers in order to satisfy a niche enterprise usecase? Why is this not something that has to be manually turned on?
Intel ME has always sounded like a glaring security risk. Another operating system running in the background that can run it's own network stack? This is 100% being exploited by intel agencies.