Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought' (arstechnica.com)

An anonymous reader quotes Ars Technica: A remote hijacking flaw that lurked in Intel chips for seven years was more severe than many people imagined, because it allowed hackers to remotely gain administrative control over huge fleets of computers without entering a password. This is according to technical analyses published Friday... AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all...

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote. "We had discovered a complete bypass of the authentication scheme." A separate technical analysis from Embedi, the security firm Intel credited with first disclosing the vulnerability, arrived at the same conclusion... Making matters worse, unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware... The packets bypass the OS completely.
The article adds that Intel officials "said they expect PC makers to release a patch next week." And in the meantime? "Intel is urging customers to download and run this discovery tool to diagnose potentially vulnerable computers."

Saturday Ars Technica found more than 8,500 systems with an AMT interface exposed to the internet using the Shodan search engine -- over 2,000 in the United States -- adding that "many others may be accessible via organizational networks."

Comments

I don't think you know what that word means.

[fahrbot-bot]

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.

He and I have different definitions for the word "worked".

Re:I don't think you know what that word means.

[tlhIngan]

When there is no authentication, one can't claim that it worked in any sense.

Actually, there's a difference in this case.

First, if you're using a normal browser, you cannot actually facilitate this bug. It's impossible. So entering a blank password at the authentication prompt - it won't work.

The reason it works is because you need to modify the HTTP headers (which is probably why it hid for so long). Remember in HTTP authentication, what gets sent is a hashed value of the username, password, nonce, and realm. It's well known how it's done, so it's not terribly secure to begin with (unless you do it over SSL), but that's HTTP authentication.

The bug is that you need to send a HTTP authentication header with nothing. A normal browser won't do this because it will always send a hash, so you needed a proxy that strips off the hash from the header and passes everything else through.

Of course, the bug is in the way it compares the hashes - as in, comparing the entered hash with its length to a strcmp() style function - the blank header forces the compare two strings of zero length returning authenticated status.

Yes, it's a serious bug, no, it's not as stupid as entering a blank password. One does wonder if other web applications are just as vulnerable, though - since I'm sure this bug is present in many other things as well (after all, a blank authentication header doesn't happen in the normal case - a browser will return something).

Re:I don't think you know what that word means.

[smallfries]

You know that Intel processors without AMT still have the capability but it is disabled in software...

Predictable outcome

[Anonymous Coward]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.

Re:Predictable outcome

[Dogtanian]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.

Coincidentally, around six weeks back, I bookmarked this article, originally written in 2016. Notably, it says that:-

Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.

Pedantry; it doesn't appear to be on every Intel chip, only those with vPro enabled(?) Still a horrible idea.

Re: Predictable outcome

[sexconker]

"Let's see a suit and a recall of millions of laptops. I'd love to see Intel out of business"
Apple laptops aren't effected, even if they run Windows in a VM. The chips that Intel ships to Apple don't have AMT enabled.
Of course if there is a massive revolt against the OEMs who implemented this because Corporate IT lazy-asses requested it, that means more MacBooks sold, which of course will continue to run on AMT-Free Intel chips.
Win-Win... but not for Windows.

The chips that Intel ships to Apple don't have AMT enabled.

I'm destroying some mods on this thread by posting, but I need to correct your very wrong post.

It's still physically present. No one except Intel knows what is actually baked into it and what's actually turned on at any given point. That's the fucking problem. That's why we're in this mess to begin with.

Re:Predictable outcome

[sexconker]

It's still physically in every chip from the last decade or so. Intel just disabled features based on the SKU. Whether AMT is disabled or "disabled" is unknown.

Ars story highest voted comment

[Anonymous Coward]

(What? I get that security is hard and that sometimes there are unforeseen vulnerabilities. But... you can enter any text as the password, and it accepts it? Did no one at Intel test a wrong password at any point? This isn't a bug, this is outright negligence.)

 

The article is a bit confusing regarding this, but no, you can't send an empty password. That's because when a browser does digest authentication it doesn't actually send the password, or even a password hash, to the web server.
 

The browser sends instead a response MD5 hash computed on a string composed of various items, including a variable nonce sent by the server, in addition to the password, for example:
 

response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI))
https://en.wikipedia.org/wiki/Digest_ac ... entication
 

This means a normal browser would never send an empty response, even when you enter an empty password. It would always send a 32 hex digit MD5 hash looking like this:
 

response="6629fae49393a05397450978507c4ef1"
 

The server would then compute the same hash, and compare them. If they are equal, it allows login, if they are different it denies login.
 

The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:
 

strncmp(string1, string2, N)
http://www.cplusplus.com/reference/cstring/strncmp/
 

And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:
 

strncmp(computed_hash, response, strlen(response))
 

So when it compared a real hash generated by a browser it would do something like:
 

strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d", 32)
 

This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn't match, and it would reject the empty password or invalid password.
 

So anyone testing this from a browser would find it works perfectly.
 

The problem is what happens if you don't use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this:
 

strncmp("6629fae49393a05397450978507c4ef1","",0)
 

This means the function will compare the first 0 characters between the two strings. So it is equivalent to:
 

strncmp("","",0)
 

Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal.
 

What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings.
 

Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don't need to supply a length parameter, like this:
 

strcmp(string1, string2)
http://www.cplusplus.com/reference/cstring/strcmp/

Responsibility for such flaws

[NuclearCat]

When companies will bear responsibility for flaws in such features, as AMT encrypted and obfuscated from 3rd party analysis and management, and enabled by default, and for such screw ups they will pay hefty fines, they will think twice, before making features work such way.

We've known for years that AMT was a risk

[Anonymous Coward]

see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed

Moneyquote:

"The ME and its extension, AMT, are serious security issues on modern Intel hardware and one of the main obstacles preventing most Intel based systems from being liberated by users."

But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?

Re: Dear Intel

[mikael]

This is what all backdoors look like. "Ooops, we accidently encrypt and decrypt the password and write it out at the end of the file". "Whoops, we missed out a break statement in the selection of the encryption algorithm, it always defaults to the legacy easily broken encryption method". "Oh, shooot, we forget to add the menu option to the router to filter out multicasts, anyone can send a SSDP multicast to that address and get a list of hosts returned."

Like Microsoft's Windows OS firewall doesn't allow blocking of Microsoft telemetry servers. Wonder why? What could be so harmful in blocking a data stream of a few hundred bytes/second?

Re: Predictable outcome (only in windows?)

[Anonymous Coward]

No, Intel AMT runs completely independently of the operating system. It doesn't matter whether the operating system is Windows, Linux, BSD, or anything else.

In fact, it's even worse. Intel AMT can still be running while the computer is off (but still plugged in). See

https://fsf.org/blogs/community/active-management-technology

Let me say it again: your computer can be pwned while it's off! You don't need to have anything running at all, because Intel AMT keeps running in the background as long as the machine is plugged in.

Re:It's time to hold engineers liable

[sjames]

The employers aren't currently held responsible either.

The problem is that the developers have no power over management to make them do the right thing. Unless and until they do, it isn't reasonable to hold them responsible. They can't make their employer do QA tests, they can't make the employer push the schedule back, and they can't prevent the premature release of a product.

Lack of negative testing - extremely common

[raymorris]

This much more common mistake than one might think. A *lot* of applications will accept an empty password. It's one of the more common of the 90,000 or so vulnerabilities that we test for.

Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative - what does it do with incorrect input? If a program retrieves a web page, what if it's empty? What does a searching or sorting program do when asked to aort or search an empty list, or a list of just one item? That stuff doesn't get tested much.