Jump to content
Forum upgrade is live! Read more... ×
Sign in to follow this  
Master_Scythe

PSA: Remote security exploit in all 2008+ Intel platforms

Recommended Posts

https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/

 

 

....."The problem is quite simple, the ME controls the network ports and has DMA access to the system. It can arbitrarily read and write to any memory or storage on the system, can bypass disk encryption once it is unlocked (and possibly if it has not, SemiAccurate hasn’t been able to 100% verify this capability yet), read and write to the screen, and do all of this completely unlogged. Due to the network access abilities, it can also send whatever it finds out to wherever it wants, encrypted or not."....

 

Fuck me......

 

...."If you have provisioned AMT or ISM on your systems, you should disable it in the Intel MEBx. If you haven’t provisioned these, or have and want to mitigate the local vulnerability too, there are more steps to take. If you have a box with AMT, ISM, or SBT, you need to disable or uninstall Local Manageability Service (LMS) on your boxes. Intel helpfully points out that doing this will mean your box can’t be managed using those services when you disable them. If this makes you think about whether or not to disable those things, trust us, don’t think about it, disable them NOW.".....

Edited by Master_Scythe

Share this post


Link to post
Share on other sites

More info https://en.wikipedia.org/wiki/Intel_Active_Management_Technology

 

This seems like a bit of a worry, supposedly even powered down or crashed machines can still be remotely managed.

Have to wonder though if the low-level control only applies to resident ethernet port connections - I imagine it probably would for cases of "OS not active".

Also wonder, with "OS active" is there any point in using a network card or USB dongle to try and lessen vulnerability.

Share this post


Link to post
Share on other sites

More info https://en.wikipedia.org/wiki/Intel_Active_Management_Technology

 

This seems like a bit of a worry, supposedly even powered down or crashed machines can still be remotely managed.

Have to wonder though if the low-level control only applies to resident ethernet port connections - I imagine it probably would for cases of "OS not active".

Also wonder, with "OS active" is there any point in using a network card or USB dongle to try and lessen vulnerability.

 

Really I only worry about the 'Remote' side of it.

If someone has access to my machine, local exploits are the last of my worries.

 

I wonder if there's just a way to disable DMA for your network card. That should solve it, from reading the semiacurate news article (thats a bad business name in hind sight, lol)

Tool to test for vulerability

 

https://downloadcenter.intel.com/download/26755

Edited by Master_Scythe

Share this post


Link to post
Share on other sites

...supposedly even powered down or crashed machines...

 

>.> Yyeah. I think I'm going to go ahead and call "BALLS!" on that bit. "Non-operational" does not carry an implicit "except for remote operation" - it means "this is fucked".

Share this post


Link to post
Share on other sites

Not necessarily - it's a bit like ADB for Android. PCs have had active hardware when powered down for years to allow for stuff like WOL, USB charging, etc and in fact the whole ATX specification reliese on standby power.

Entirely probably the vulnerabity would be more in the SOE corporate/govt area as it's the management facilities built into firmware and motherboards that are vulnerable and more likely to be enabled and configured in those environments.

 

I'm doing a run of that utility now, I think I might be OK - log from the run below. Seems you need to run from elevated command prompt, I had problems running from Windows or a plain cmd prompt.

I used command SCSDISCOVERY systemdiscovery /noregistry

 

 

2017-05-03 16:28:51:(INFO) : ACU Configurator , Category: HandleOutPut: Starting log 2017-05-03 16:28:51



2017-05-03 16:28:51:(INFO) : SCSDiscovery, Category: -SystemDiscovery-: Core-i7: Discovering the System information...

2017-05-03 16:30:36:(ERROR) : ACU Configurator , Category: Error message: Failed to connect to the Intel(R) Management Engine Interface PTHI client.
 (0xc000001c)

2017-05-03 16:31:06:(ERROR) : Core-i7, Category: AMT Interface error: Failed while calling  Soap call  GetCoreVersion. Intel(R) AMT connection error 
 0xc000521c: A TCP error occurred. Make sure that the destination settings are correct and that a network connection exists to the target. , error in
 discover 0xc000521c

2017-05-03 16:31:31:(ERROR) : Core-i7, Category: AMT Interface error: Failed while calling  Soap call  GetCoreVersion. Intel(R) AMT connection error
  0xc000521c: A TCP error occurred. Make sure that the destination settings are correct and that a network connection exists to the target. , error 
in discover 0xc000521c

2017-05-03 16:31:34:(WARN) : SCSDiscovery.exe, Category: System Discovery: System Discovery finished with warnings: System Discovery failed to get data from 
some of the interfaces on this system.  (0xc00027ff). Failed to get data from the MEI interface.   (0xc000283d). Failed to connect to the 
Intel(R) Management Engine Interface PTHI client.  (0xc000001c). This system does not have Intel(R) AMT (or it is disabled in the Intel MEBX, or the
 correct drivers are not installed or enabled, or the current user does not have permissions to the drivers).  (0xc0000063). Failed to read the
 registry value (Primary DNS suffix).  (0xc0001f52). Failed to get data from the Intel(R) AMT WSMAN Discovery interface.   (0xc0002841).
 Initial connection to the Intel(R) AMT device failed.   (0xc00007d2). A TCP error occurred. Make sure that the destination settings are correct and 
that a network connection exists to the target.  (0xc000521c). Failed to get data from the GetDNSLookupName interface.   (0xc0002842).
 Failed to retrieve the host onboard IPv4 IP (please check the LAN settings).   (0xc0002836).

2017-05-03 16:31:34:(INFO) : SCSDiscovery, Category: Exit: ***********Exit with code 32 - Intel(R) AMT operation completed with warnings:
 Details: Success. System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system.  (0xc00027ff).
 Failed to get data from the MEI interface.   (0xc000283d). Failed to connect to the Intel(R) Management Engine Interface PTHI client.  (0xc000001c). 
This system does not have Intel(R) AMT (or it is disabled in the Intel MEBX, or the correct drivers are not installed or enabled, or the current user
 does not have permissions to the drivers).  (0xc0000063). Failed to read the registry value (Primary DNS suffix).  (0xc0001f52). Failed to get data
 from the Intel(R) AMT WSMAN Discovery interface.   (0xc0002841). Initial connection to the Intel(R) AMT device failed.   (0xc00007d2).
 A TCP error occurred. Make sure that the destination settings are correct and that a network connection exists to the target.  (0xc000521c).
 Failed to get data from the GetDNSLookupName interface.   (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings).
   (0xc0002836).

 

 

Edited by Rybags

Share this post


Link to post
Share on other sites

 

...supposedly even powered down or crashed machines...

 

>.> Yyeah. I think I'm going to go ahead and call "BALLS!" on that bit. "Non-operational" does not carry an implicit "except for remote operation" - it means "this is fucked".

 

 

I think they meant powered down non-bootable servers.

your ME interface (or idrac, or LightsOut) is still a small OS running on a card. If you can run a script from that, you're in luck.

 

Just think of that webcam firmware botnet thing that just went around whos name i'm forgetting (mirakai?)

Share this post


Link to post
Share on other sites

the following was posted by Mathew Garret (link: https://mjg59.dreamwidth.org/48429.html)

 

 

----

INTEL'S REMOTE AMT VULNERABILITY

 

Intel just announced a vulnerability in their Active Management Technology stack. Here's what we know so far.

 

Background

Intel chipsets for some years have included a Management Engine, a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT is another piece of software running on the ME, albeit one that takes advantage of a wide range of ME features.

 

Active Management Technology

AMT is intended to provide IT departments with a means to manage client systems. When AMT is enabled, any packets sent to the machine's wired network port on port 16992 or 16993 will be redirected to the ME and passed on to AMT - the OS never sees these packets. AMT provides a web UI that allows you to do things like reboot a machine, provide remote install media or even (if the OS is configured appropriately) get a remote console. Access to AMT requires a password - the implication of this vulnerability is that that password can be bypassed.

 

Remote management

AMT has two types of remote console: emulated serial and full graphical. The emulated serial console requires only that the operating system run a console on that serial port, while the graphical environment requires drivers on the OS side requires that the OS set a compatible video mode but is also otherwise OS-independent[2]. However, an attacker who enables emulated serial support may be able to use that to configure grub to enable serial console. Remote graphical console seems to be problematic under Linux but some people claim to have it working, so an attacker would be able to interact with your graphical console as if you were physically present. Yes, this is terrifying.

 

Remote media

AMT supports providing an ISO remotely. In older versions of AMT (before 11.0) this was in the form of an emulated IDE controller. In 11.0 and later, this takes the form of an emulated USB device. The nice thing about the latter is that any image provided that way will probably be automounted if there's a logged in user, which probably means it's possible to use a malformed filesystem to get arbitrary code execution in the kernel. Fun!

The other part of the remote media is that systems will happily boot off it. An attacker can reboot a system into their own OS and examine drive contents at their leisure. This doesn't let them bypass disk encryption in a straightforward way[1], so you should probably enable that.

 

How bad is this

That depends. Unless you've explicitly enabled AMT at any point, you're probably fine. The drivers that allow local users to provision the system would require administrative rights to install, so as long as you don't have them installed then the only local users who can do anything are the ones who are admins anyway. If you do have it enabled, though…

 

How do I know if I have it enabled?

Yeah this is way more annoying than it should be. First of all, does your system even support AMT? AMT requires a few things:

1) A supported CPU
2) A supported chipset
3) Supported network hardware
4) The ME firmware to contain the AMT firmware

Merely having a "vPRO" CPU and chipset isn't sufficient - your system vendor also needs to have licensed the AMT code. Under Linux, if lspci doesn't show a communication controller with "MEI" or "HECI" in the description, AMT isn't running and you're safe. If it does show an MEI controller, that still doesn't mean you're vulnerable - AMT may still not be provisioned. If you reboot you should see a brief firmware splash mentioning the ME. Hitting ctrl+p at this point should get you into a menu which should let you disable AMT.

 

How about over Wifi?

Turning on AMT doesn't automatically turn it on for wifi. AMT will also only connect itself to networks it's been explicitly told about. Where things get more confusing is that once the OS is running, responsibility for wifi is switched from the ME to the OS and it forwards packets to AMT. I haven't been able to find good documentation on whether having AMT enabled for wifi results in the OS forwarding packets to AMT on all wifi networks or only ones that are explicitly configured.

 

What do we not know?

We have zero information about the vulnerability, other than that it allows unauthenticated access to AMT. One big thing that's not clear at the moment is whether this affects all AMT setups, setups that are in Small Business Mode, or setups that are in Enterprise Mode. If the latter, the impact on individual end-users will be basically zero - Enterprise Mode involves a bunch of effort to configure and nobody's doing that for their home systems. If it affects all systems, or just systems in Small Business Mode, things are likely to be worse.

 

What should I do?

Make sure AMT is disabled. If it's your own computer, you should then have nothing else to worry about. If you're a Windows admin with untrusted users, you should also disable or uninstall LSM by following these instructions.

 

Does this mean every Intel system built since 2008 can be taken over by hackers?

No. Most Intel systems don't ship with AMT. Most Intel systems with AMT don't have it turned on.

 

Does this allow persistent compromise of the system?

Not in any novel way. An attacker could disable Secure Boot and install a backdoored bootloader, just as they could with physical access.

 

But isn't the ME a giant backdoor with arbitrary access to RAM?

Yes, but there's no indication that this vulnerability allows execution of arbitrary code on the ME - it looks like it's just (ha ha) an authentication bypass for AMT.

 

Is this a big deal anyway?

Yes. Fixing this requires a system firmware update in order to provide new ME firmware (including an updated copy of the AMT code). Many of the affected machines are no longer receiving firmware updates from their manufacturers, and so will probably never get a fix. Anyone who ever enables AMT on one of these devices will be vulnerable. That's ignoring the fact that firmware updates are rarely flagged as security critical (they don't generally come via Windows update), so even when updates are made available, users probably won't know about them or install them.

 

Avoiding this kind of thing in future

Users ought to have full control over what's running on their systems, including the ME. If a vendor is no longer providing updates then it should at least be possible for a sufficiently desperate user to pay someone else to do a firmware build with the appropriate fixes. Leaving firmware updates at the whims of hardware manufacturers who will only support systems for a fraction of their useful lifespan is inevitably going to end badly.

 

How certain are you about any of this?

Not hugely - the quality of public documentation on AMT isn't wonderful, and while I've spent some time playing with it (and related technologies) I'm not an expert. If anything above seems inaccurate, let me know and I'll fix it.

[1] Eh well. They could reboot into their own OS, modify your initramfs (because that's not signed even if you're using UEFI Secure Boot) such that it writes a copy of your disk passphrase to /boot before unlocking it, wait for you to type in your passphrase, reboot again and gain access. Sealing the encryption key to the TPM would avoid this.

[2] Updated after this comment - I thought I'd fixed this before publishing but left that claim in by accident.

Edited by @~thehung

Share this post


Link to post
Share on other sites

I wonder if there's just a way to disable DMA for your network card. That should solve it, from reading the semiacurate news article (thats a bad business name in hind sight, lol)

The article says "has DMA access to the system" without really explaining what that means.

 

Presumably, it means the management engine can tell the 8237 to initiate arbitrary DMA transfers, which obviously opens a can of worms.

 

You can't "disable DMA for your network card" because it won't work without it. In fact, you can't really use PCI or PCIe without DMA.

Share this post


Link to post
Share on other sites

The article says "has DMA access to the system" without really explaining what that means.

from the following lines:

 

- it can arbitrarily read and write to any memory or storage on the system

- bypass disk encryption once it is unlocked

- read and write to the screen

- do all of this completely unlogged

- send whatever it finds out to wherever it wants, encrypted or not.

 

i took that for an explanation. what is misleading/incorrect/missing?

Share this post


Link to post
Share on other sites

My Dell workstation (1st gen Bloomfield Xeon) has the option to set TPM off.

I would guess that on machines where such options aren't in the menu there's probably no vulnerabiltiy.

 

DMA access without needing any privelage escalation... you can do prettymuch anything.

Share this post


Link to post
Share on other sites

 

The article says "has DMA access to the system" without really explaining what that means.

from the following lines:

 

- it can arbitrarily read and write to any memory or storage on the system

- bypass disk encryption once it is unlocked

- read and write to the screen

- do all of this completely unlogged

- send whatever it finds out to wherever it wants, encrypted or not.

 

i took that for an explanation. what is misleading/incorrect/missing?

 

I just meant it would've just helped to talk briefly about what DMA is.

Share this post


Link to post
Share on other sites

I'd have thought being an Amiga guy you'd have that well covered.

Direct Memory Access, prettymuch the act of an IO chip or coprocessor other than the CPU reading or writing to Ram, mostly or totally independent of CPU control.

In the old days it was usually just limited to video generation. As time went by, you had the likes of sound generation, RS232 FIFOs, graphics blitter, and floppy + HDD IO.

 

These days practically every IO operation can be automated with DMA to the extent that the CPU just has to send a start command then wait for an interrupt of periodically check a flag. Although with stuff like memory controller and PCIe being largely moved to the CPU, it's a physical coexistence but logically an independent subsystem.

Share this post


Link to post
Share on other sites

I'd have thought being an Amiga guy you'd have that well covered.

I do, I meant because of like questions like MS's about disabling DMA for the network card.

Share this post


Link to post
Share on other sites

I'm not sure that would make a difference. If the low level system management accepts commands embedded in incoming packets it probably doesn't matter if they're DMA'd or buffered then copied by the CPU.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×