
Rediscovering the Intel AMT Vulnerability - xorrbit
https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability
======
kbenson
_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 company like Intel, in an
enterprise feature which has a lot of security ramifications, and which has
apparently existed for a long time (years?).

Edit: Also, this is really good evidence for short and hard disclosure
deadlines. What's the chance something as simple as this wasn't known by
someone else? All they had to do was decide to look and they found something
within minutes. It's not like this is obscure or doesn't get your much, it's
about as juicy as they come.

~~~
mdip
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.

~~~
mirimir
So what might the coding error have been? I mean, it seems like null password
matches any password. Parsing null can be hard, but seriously?

~~~
mdip
In the case of Intel's AMT, I'm not sure what could have possibly gone wrong,
but it sounds like this is something that has happened in other applications
that use Digest Authentication.

In the case of Renegade's BBS software, I don't exactly recall the specifics
and since it's been several years, I may not have this exactly right but I'm
fairly certain this is how it happened because I did a _lot_ of work with the
code it was based on[0].

The bug occurred only if the user didn't provide a password. So, effectively,
you could login by not providing a password or by providing the correct
password. In the original Telegard source, the login prompt did _nothing_ if
no password was provided, it simply discarded the provided Enter and waited
for a password. This was handled by a global function that was used for
accepting input. I'm guessing that function was refactored (I ended up doing
this ... it was pretty ugly IIRC) in the Renegade code and it became possible
to send a blank password. The login routine was an interesting beast, as well.
I remember reviewing it in the original code and scratching my head ... it
made _positively no sense_ and so I threw it out and replaced it with a much
simpler implementation. Rumors had swirled around the release of the source
code that this obfuscation was intentional and that there was a back-door
built into the login routine. I'm not sure if that's true or not but the sheer
amount of code to do a string comparison was a little ridiculous[1] --
passwords were not hashed, they were stored in plain text in a record (struct-
like component) dumped to a file and were even viewable in the sysop control
panel's User Editor.

It's entirely possible that they _didn 't_ refactor this bit of logic but
changed something in that mess that caused an empty string to evaluate _true_
along with a matched string. Or it could be that they refactored that like I
did and put an OR where an AND belonged. If they refactored that global
ReadLine method to allow empty returns, they may have felt a need to check for
an empty value at this prompt, though I'm not sure what the motivation for
this would have been. An empty or NIL value wouldn't have caused the
application to crash -- there's no null reference exceptions when you're
dealing in a non-OOP language -- you're not executing methods attached to the
String type because such a thing didn't exist in the language.

The developer should have discovered the problem _way_ before it was ever
released in the wild, but I get why it was missed. He probably checked a bad
value and a good value but never thought to check no value at all. Hell, it
was a mystery why all of these Renegade boards were going down and a bunch of
folks assumed it was a back-door, as was suspected about the original Telegard
code. It was a few weeks before people figured out that it was such a _simple_
screw-up.

[0] The source code wasn't public, it wasn't open source. In fact, it only
existed because an older version of Telegard had its source code leaked, which
the Renegade developers used to create their product (there were a number of
"Telegard Hacks" in those days, including one I wrote and later rewrote from
scratch and served as the _entire reason I decided to become a software
developer_ ).

[1] Sounds suspicious at first glance but there were so many really poorly
performing things about Borland Pascal's core libraries that it was not
uncommon to write several hundred lines of inline assembly to do things like
"write text to the screen quickly". I had done this, myself, on a few
occasions -- the specifics were something around writing to memory reserved
for use by the display capabilities of the 8088/80286/80386 (BIOS reserved
memory IIRC).

[2] NIL was Borland Pascal's "null", and I believe it supported empty strings.
Unlike ISO PASCAL at that time, Borland Pascal had a real string type which
was stored in memory as a character array with a length field at the 0th
index. It didn't use null terminated character arrays like C/C++ which made
working with strings in the language elegant by comparison. Strings, however,
were 8-bit ASCII ... this being the 90s with the target being DOS and all.

~~~
mirimir
OK, it's explained in [https://arstechnica.com/security/2017/05/the-hijacking-
flaw-...](https://arstechnica.com/security/2017/05/the-hijacking-flaw-that-
lurked-in-intel-chips-is-worse-than-anyone-thought/)

The code compares the correct "hash and the hash response received from the
browser, with N set to the length of the response received from the browser".
So if the browser returns "", that's compared with the first zero characters
in the correct hash, which is also "". Funny.

------
bobsam
Intel decided they have the right to put a whole secret computer inside your
computer that only they can access. God knows what it does when no one is
watching.

That's the problem you should discuss, not this particular exploit.

~~~
Animats
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.

~~~
qb45
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's just how this industry works.

This doesn't indicate that there is anything "bad" going on. What _is_ bad is
that Intel, being the cheap bastards they are, combined this remote management
and DRM, virtualization, TPM, CPU initialization and hell knows what else into
one blob running on one MCU with no way to separate and disable the
unneeded/unwanted/buggy/vulnerable garbage from actually useful functionality.
And that such critical part is closed to third party scrutiny.

~~~
throw2016
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.

~~~
duskwuff
> 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...](https://www.arm.com/products/processors/technologies/trustzone/tee-
reference-documentation.php)

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

~~~
qb45
> Don't believe the FSF's FUD

Don't believe anti-FSF FUD. If you think they have an issue with TrustZone
itself, as opposed to devices using it without owner's control, I'd love to
see the links.

------
qb45
TL;DR:

    
    
      memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len)
    

Hey, at least they didn't read past the submitted buffer.

edit:

Note that this is only pseudocode and rumor has it that ME firmware is
actually written mostly in Java. It's not immediately clear to me how to
create equivalent bug in Java, the obvious _string.equals()_ method doesn't
ignore length mismatch.

edit2:

s/passwd/passwd_hash to satisfy pedants below ;)

~~~
lucb1e
> [...] how to create equivalent bug in Java, the obvious string.equals()
> method [...]

Java Card, the Java version made for smart cards, does not have strings, and
thus no String.equals().

Thought I remembered this from a CCC conference about EMV chips or SIM cards
(don't remember which) a few years ago. Googling seems to confirm it:
[https://community.oracle.com/thread/1751610?db=5](https://community.oracle.com/thread/1751610?db=5)

~~~
paulmd
From what I remember in one of the deep teardowns it's possibly Java ME (which
I think is one step above Java Card in terms of features). The file format is
JEFF.

------
DuskStar
So the AMT vuln was related to a lack of security on their web service?
Somehow this does not increase my confidence in the rest of their code - if
they didn't get this right, what else is wrong?

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

~~~
Karunamon
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

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

------
microcolonel
Closed source custom Java ME and ThreadX blob probably maintained by interns,
running all the time with unfettered access to every resource in the system
even when the machine is turned off, integrated into almost every enterprise
computer network in the world.

What could possibly go wrong.

------
xgen
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...](https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/)

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 trust in a company is it worth it enough that they do
not offer a line of chips that do not have this pseudo back door present?

~~~
wmf
Most Intel PCs do not have AMT firmware and thus aren't affected by any AMT
firmware vulnerabilities.

~~~
xgen
Is management engine not on all modern intel chips, but comes disabled
requiring it to be set up in the BIOS?

~~~
wmf
The ME is on all chips but the ME doesn't provide remote management. You're
confusing two different things.

------
walterbell
If AMT provides remote management of devices that are turned off, what program
provides authentication of remote management requests when the OS is powered
off? Has that interface been audited for authentication vulnerabilities?

If there is an OS-independent, network-accessible AMT management service, when
would an admin need to switch from that service to the Windows-hosted web
interface? Why can't all AMT operations be performed without an OS?

~~~
mjg59
There is no Windows-hosted web interface, the web interface is provided by
AMT. LMS is for accessing AMT from the local machine (AMT is listening to the
network hardware, so trying to connect to the web UI locally won't work - the
OS will shortcut the network hardware)

------
MichaelGG
So now that there's more info out, this is only a threat if you have remote
management provisioned? And to provision it, you first need code execution on
the box?

Is the impact of this bug basically nothing to most users? And to provisioned
users, it's just as bad as any bug on a remote management system? That is, the
fact it's built in to the CPU makes no difference?

~~~
bobsam
Many enterprise users are affected by this.

~~~
MichaelGG
Sure but they'd be affected regardless, due to enabling a remote management
system. All I'm asking is if there's any real damage because this is built in
by Intel. If Intel didn't ship this, then OEMs would, just like e.g. Dell
DRAC, right? And that'd have the same attack surface.

~~~
Crespyl
I'm not familiar with DRAC, but if it's something added by an OEM wouldn't it
have to be in the UEFI/BIOS layer or higher?

AMT/ME and its ilk are a physical coprocessor built into the CPU, whether it's
"enabled" or not, not something that can be added or removed after the fact.

------
orblivion
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.

~~~
MichaelGG
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.

------
thyrsus
The article says that a Local Management Service (LMS) must be installed for
the bug to be demonstrated[0], and describes a Windows package that provides
that. Is there a Linux equivalent?

[0] I say "demonstrated" instead of "exploited", since I don't understand the
details sufficiently to rule out exploitation in the absence of LMS.

~~~
anoother
Yes, there is.

I haven't looked into the exploit, but if the attack uses AMT's http(s)
interface, you could also simply access the AMT port(s) from a remote machine.
The service simply allows one to speak to the local ME.

------
cmurf
FTA: "the discovery of a possible zero-day in widely distributed firmware"

Is this CPU firmware? Or microcode? Or is it logic board firmware (UEFI base)?
And if it's CPU firmware, is that replaceable or is it permanently baked into
the CPU?

------
RichardHeart
Will blocking ports 16992 and 16993 at router block this attack (as those are
the AMT ports.)?

------
logicallee
[withdrawn]

~~~
SomeStupidPoint
I'm not sure what you're trying to say -- we can't discuss IME being a second
computing system inside of your computer controlled by someome else?

Because I seem to have just done that.

We can even talk about why the existence of that system is problematic, since
it gives someone else control over "your" computer.

~~~
logicallee
[withdrawn]

~~~
SomeStupidPoint
Are you just trolling?

I've read literally dozens about how Intel ME is a potential vector and it's
problematic to have, particularly when unneeded on consumer devices (a number
of them here on HN). There's whole discussions about it from people like
Libreboot and others who work on fully open systems. Every security
professional I've worked with has been aware that there's a potential hardware
level backdoor you can't wipe out the firmware for without bricking your
machine, and has opinions about it.

I typed "Intel management engine second computer" in to Google, and found
articles calling it a privacy/security threat and potential backdoor ranging
back to 2010/2011 timeframe on the first page of results. (That's not even a
_good_ phrase to search with to find info, I just wanted to prove the point
that you can find pieces with literally the first thing that comes to mind.)

~~~
rayiner
It seems super useful to me. It lets you do OS installs without a
keyboard/screen using VNC. Note that stuff like IPMI is standard in the server
world.

~~~
SomeStupidPoint
Sorry, perhaps I phrased it poorly.

I certainly see the benefit in the server world (eg, managing a data center)
and even in the corporate one (eg, managing a lot of workstations), and didn't
mean to imply that everyone thought it was a negative. (Though, even in that
space, some people do because of the closed source nature where they don't
have full control of the system.)

Rather, I meant that everyone who was serious about security was aware that it
was there and included it in their threat modeling. It's not worse than other
remote management technologies (and may be better, depending on your needs and
trade-offs).

However, for certain systems, there's never a need for the remote management
capabilities, and hence represents a threat for which there's no upside when
included. (I would argue most consumer systems fall under this.)

There are of course, a range of opinions depending on ideological bent, and my
main point was that there _was_ a discussion about it happening.

