# Just came across this Intel AMT vulnerability check.

## Budoka

https://github.com/mjg59/mei-amt-check

----------

## khayyam

Budoka ...

it might be worth mentioning what IME/AMT is and what the vunerability is.

best ... khay

----------

## Zucca

I will even go and suggest to write a short article on wiki about the software and its usage.

----------

## szatox

AMT vulnerability seems to be more about panic than it's worth.

If you have a physical access to some hardware, you can basically do anything with it.

If you have access to a management interface, it's pretty much the same as if you had physical access to the hardware. You can do anything.

Solution: do not expose management interfaces to the internet.

Those topics keep popping up now and then, yet people tend to forget about stuff we really can't inspect, like bios and firmware included with hardware.

Say, during early boot bios calls firmware from expansion cards. (PXE, sounds familiar? Manufacturer logo displayed before loading OS even starts?)

Since those things run before OS starts, and essentially don't need the OS, they can do anything they want. Note: the malicious code doesn't even have to be a part the bios itself. It can be firmware from any device attached to system bus.

----------

## 1clue

This is just speculation, but I'm guessing that most people who have hardware with a remote management interface:

Know about it.

Have read the extremely prominent warnings about the security implications of letting anyone at that interface.

Chose their hardware with remote management in mind.

Have some sort of plan to prevent that remote management interface from being connected to the outside world.

The mere existence of this sort of interface is an insane security risk, for exactly the same reasons why the administrators of the hardware want that interface to be present on the hardware:  You can do ANYTHING to the box without being there, except physically connecting and disconnecting wires.

The security implications of this are apparent to anyone using the interface, precisely because it allows you to do what you do every time you use the interface. I don't know how to say it more clearly.

It's like a sharp knife. Sharp knives are valuable because you can cut things with them, and they're also dangerous because you can cut things with them.

----------

## Hu

While I would hope that all systems that ship this interface make it very clear what it can do and how dangerous it can be when abused, I think there is a general sense (whether or not justified) that the relevant features were shipped on hardware not so clearly marked.  This led to extensive concern over whether a system might be in a dangerous configuration without the explicit intention of its operator.  The inconvenience of checking that when the system is not running Windows only exacerbated the problem.

As for the advice about not connecting it to the outside world, while that is excellent advice (that is sadly ignored by far too many "IT professionals"), that is unfortunately insufficient.  If any system on the internal network has access to it and becomes infected by any of a long list of relay-capable malware, the AMT system will be indirectly accessible to the outside world by way of the relay.  To be truly safe, it needs to be not only isolated from the Internet, but also isolated from any systems that might reasonably be expected to catch a relay-capable malware infection.  Achieving that is considerably more inconvenient, and may well be skipped even by people who know better than to give it a public IP address.

----------

## khayyam

 *1clue wrote:*   

> This is just speculation, but I'm guessing that most people who have hardware with a remote management interface:
> 
> 1. Know about it.

 

1clue ... that's the thing, nobody but Intel know about it, it's a blackbox (and I'm speaking of IME as well as AMT). All we know is the information provided by them.

 *1clue wrote:*   

> 2. Have read the extremely prominent warnings about the security implications of letting anyone at that interface.

 

Well, no, you have a situation in which sending a null string at authentication bypasses authentication, that is either intentional, and so a backdoor, or gross incompetence (which would void any credibility for the provider of the mechanism). Coupled with this Intel put a great deal of effort into key signing for the firmware (making it resilient to tampering/replacement ... see the links in the coreboot wiki linked above) but didn't check for a null string!!!! ... that is not something I'm prepared to attribute to a simple "error", more likely it provides them plausible deniability.

 *1clue wrote:*   

> 3. Chose their hardware with remote management in mind.

 

Fine, but they should know what they are getting ... and that is the objection to closed source firmwares.

 *1clue wrote:*   

> 4. Have some sort of plan to prevent that remote management interface from being connected to the outside world.

 

AMT is also on various laptops (see the above linked coreboot wiki), so this isn't something which can be "managed" in the way you suggest.

 *1clue wrote:*   

> It's like a sharp knife. Sharp knives are valuable because you can cut things with them, and they're also dangerous because you can cut things with them.

 

That analogy doesn't function in this instance because with a sharp knife you know what you are dealing with (and should you not you can experiment with the implement to test it's qualities, etc).

best ... khay

----------

## 1clue

@khayyam,

I'll admit to not having actually read the link until now. There are so many posts regarding IPMI/IME/AMT/whatever and every time people are amazed that such a security hole could exist.

I've checked my hardware, and none of it is vulnerable. As well (as I mentioned earlier) my out-of-band-manageable equipment has the OOB-enabled interface connected to a dead-end network.  Meaning there's nothing except the management NICs of servers (which the server OS leaves unconfigured) and a host to configure them from, and the host has no Internet connectivity. I've verified that the other NICs don't have the fingerprints of the OOB-enabled NICs, meaning the OOB services are not exposed to the other NICs in a way that I know to check.

While it's conceivable that some attack could come from a different NIC on these systems, I can't see how that differs from any other network intrusion. Setting up the management interfaces on their own network prevents even this bug from being exploitable, barring some other unknown agent.

A no-password backdoor is bad news, no way it's anything but bad. Clearly putting this sort of management on a laptop was an insanely bad idea, security hole or not. And that signed firmware thing has to be a PITA no matter what.

----------

