User Controls
I've got a theory why Darth Beaver self destructed & left.
-
2017-06-21 at 4:46 AM UTCWell, screw that – using a proxy between you and the device, or a similar traffic-editing tool, just strip out the response hash to send instead:
GET /index.htm HTTP/1.1
Host: 127.0.0.1:16992
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Digest username=»admin»,
realm=»Digest:048A0000000000000000000000000000»,
nonce=»qTILAAUFAAAjY7rDwLSmxFCq5EJ3pH/n», uri=»/index.htm», response=»»,
qop=auth, nc=00000001, cnonce=»60513ab58858482c»
Notice how response is now empty. And yet Intel's bouncer lets you in, even though you flashed the doorman no password – no valid ID – at all:
HTTP/1.1 200 OK
Date: Thu, 4 May 2017 16:09:17 GMT
Server: AMT
Content-Type: text/html
Transfer-Encoding: chunked
Cache-Control: no cache
Expires: Thu, 26 Oct 1995 00:00:00 GMT
If you poke around inside Intel's firmware, you'll find this gem that lies at the heart of the matter – machine code that decompiles into C that looks pretty much like this:
if(strncmp(computed_response, user_response, response_length))
deny_access();
As you may well know, this standard function compares no more than response_length bytes in the two supplied strings to check if they are identical or not. The two strings compared here are the authentication response sent by person trying to log in (user_response) and the response expected by the service (computed_response). If both strings match, the function returns zero, indicating the password is good and as expected, and the code continues on to grant access. If the strings differ, the function's return value is non-zero, meaning the password is wrong, so access is denied. So far so good.
Unfortunately, response_length is calculated from user_response, so if an empty string is supplied, the length is zero, no bytes are checked, no bytes are therefore different, and – as expected – strncmp() returns zero, indicating success, and access is granted. Thus, an empty response string slips through as valid when it's actually invalid.
Intel should really check the two strings are the same length, since valid responses are always 32-byte MD5 hashes.
Thanks go to Embedi, which reverse engineered the code [PDF] and also reported the flaw to Intel back in March. Tenable also poked around in the service and came to the same conclusion earlier this week.
Intel has published some more info on the vulnerability here, which includes links to a tool to check if your system is at-risk, support contact details, and a list of mitigations to reduce the threat. That tool is apparently Windows-only; there's info here for Linux peeps.
There is also this third-party tool, here, for disabling AMT from Windows.
We're told the programming blunder is present in various, but not all, Intel processor chipsets from today's Kaby Lake family back to silicon sold in 2010: it mainly affects business PCs, professional workstations and small servers, rather than devices aimed at normal folk. However, Chipzilla admitted today that "consumers and small businesses" may end up using processors with the vulnerable tech present.
If you're using a vPro-enabled processor and have provisioned AMT versions 6 to 11.6 on your network, you are definitely at risk of the above vulnerability. This also affects Intel's Standard Manageability (ISM) and Small Business Technology (SBT) products. We recommend you use Intel's utility to double check whether or not you are being silently menaced by this bug.
How bad is this bug? Pretty bad. "The exploit is trivial, a maximum of five lines of Python, and could be doable in a one-line shell command," said SSH inventor Tatu Ylonen.
"It gives full control of affected machines, including the ability to read and modify everything. It can be used to install persistent malware – possibly in the firmware – and read and modify any data. For security servers, it may allow disabling security features, creating fake credentials, or obtaining root keys.
"Disable AMT today. Mobilize whomever you need. Start from the most critical servers: Active Directory, certificate authorities, critical databases, code signing servers, firewalls, security servers, HSMs (if they have it enabled). For data centers, if you can, block ports 16992, 16993, 16994, 16995, 623, 664 in internal firewalls now.
"If you have anything connected to the Internet with AMT on, disable it now. Assume the server has already been compromised."
The last time we looked on Shodan, there were more than 8,000 potentially vulnerable systems on the public internet. There will be thousands upon thousands more on internal corporate networks. -
2017-06-21 at 4:47 AM UTC
Originally posted by -SpectraL https://www.theregister.co.uk/2017/05/05/intel_amt_remote_exploit/
Code dive You can remotely commandeer and control computers that use vulnerable Intel chipsets by sending them empty authentication strings.
You read that right. When you're expected to send a password hash, you send zero bytes. Nothing. Nada. And you'll be rewarded with powerful low-level access to a vulnerable box's hardware from across the network – or across the internet if the management interface faces the public web.
Remember that the next time Intel, a $180bn international semiconductor giant, talks about how important it treats security.
To recap: Intel provides a remote management toolkit called AMT for its business and enterprise-friendly processors; this software is part of Chipzilla's vPro suite and runs at the firmware level, below and out of sight of Windows, Linux, or whatever operating system you're using. The code runs on Intel's Management Engine, a tiny secret computer within your computer that has full control of the hardware and talks directly to the network port, allowing a device to be remotely controlled regardless of whatever OS and applications are running, or not, above it.
Thus, AMT is designed to allow IT admins to remotely log into the guts of computers so they can reboot a knackered machine, repair and tweak the operating system, install a new OS, access a virtual serial console, or gain full-blown remote desktop access via VNC. It is, essentially, god mode.
Normally, AMT is password protected. This week it emerged this authentication can be bypassed, potentially allowing miscreants to take over systems from afar or once inside a corporate network. This critical security bug was designated CVE-2017-5689. While Intel has patched its code, people have to pester their hardware suppliers for the necessary updates before they can be installed.
Today we've learned it is trivial to exploit this flaw, allowing anyone to gain control of vulnerable systems without a password.
AMT is accessed over the network via a bog-standard web interface: the service listens on ports 16992 and 16993. Visiting this with a browser brings up a prompt for a password, and this passphrase is sent using standard HTTP Digest authentication: the username and password are hashed using a nonce from the AMT firmware plus a few other bits of metadata. This scrambled response is checked by the AMT software to be valid, and if so, access is granted to the management interface.
But if you send an empty response, the firmware is fooled into thinking this is correct and lets you through. This means if you use a proxy to change the response to an empty string, or otherwise set up your browser to send empty HTTP Digest authentication responses, you can bypass the password checks.
Essentially, behind the scenes, your browser would normally send something like this to the AMT service, which includes the hashed response string containing the username, password and server nonce:
GET /index.htm HTTP/1.1
Host: 192.168.1.2:16992
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.2:16992/logon.htm
Connection: keep-alive
Authorization: Digest username=»admin»,
realm=»Digest:048A0000000000000000000000000000»,
nonce=»Q0UGAAQEAAAV4M4iGF4+Ni5ZafuMWy9J», uri=»/index.htm»,
response=»d3d4914a43454b159a3fa6f5a91d801d», qop=auth, nc=00000001,
cnonce=»9c5beca4011eea5c»
Literally not SMM related. You fucktard. -
2017-06-21 at 4:50 AM UTC
-
2017-06-21 at 4:52 AM UTC
-
2017-06-21 at 4:59 AM UTC
Originally posted by Captain Falcon These bluffs are always less exciting when you know for a fact that the poster is 100% bullshitting, lol.
:)
True. I just think it would be a little more interesting if he actually proved he could do it.
Like we could at least say, OK, spectral isn't completely full of shit.
Not that he has to prove anything, but it's not even a matter of proof at this point. It's just liek , hey man, can I see your skills? Can you ACTUALLY show Sophie's pi ? That would be cool. He wants you to.
Spectral spends enough time trying to answer technical questions and show he's knowledgeable, so why does he stop when he has a legit chance to really show it?
Probably because, Falco, you're right. -
2017-06-21 at 5:04 AM UTCThat would be a vulgar display of power, for no useful purpose. I'm not like that. I don't have to prove anything to anyone, and I know it.
-
2017-06-21 at 5:06 AM UTC
-
2017-06-21 at 5:15 AM UTC
-
2017-06-21 at 6 PM UTC
-
2017-06-21 at 6:02 PM UTC
-
2017-06-21 at 6:03 PM UTC
-
2017-06-21 at 6:19 PM UTC
-
2017-06-21 at 6:51 PM UTCHere's my theory.
He was investing in Etherium.
Get it? -
2017-06-21 at 8:30 PM UTC
-
2017-06-21 at 8:35 PM UTCzok & the fun bunch sounds like good band name.
-
2017-06-21 at 9:38 PM UTC
-
2017-06-21 at 10:22 PM UTCive never alted, I've always been Bill Krozby
-
2017-06-21 at 10:25 PM UTC
