Slashdot Mirror
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."
"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."
(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)) ... entication
https://en.wikipedia.org/wiki/Digest_ac
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/
"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".
The best phrasing would be that authentication "succeeded" despite the wrong password. You still get the idea.
The Daddy casts sleep on the Baby. The Baby resists!
see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed
Moneyquote:
But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?
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.
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.
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).