Intel AMT vulnerability: Silent Bob is Silent [pdf] | Hacker News Reader

Intel AMT vulnerability: Silent Bob is Silent [pdf]

embedi.com

73 pointsmy12330 comments

Is there even a point in discussing this?

Intel and AMD will continue to not provide options without backdoors, intentional or otherwise.

Everyone will continue to buy their product because the alternatives do not have competitive performance.

Wow. All you have to do is give it an empty response, and it accepts it as valid and lets you in.

How did this get missed in QC? The first thing I try doing while I'm working on my little game is seeing if null or empty inputs allow things that should not happen to happen with each command/function I add into the system. I write the code, see if it compiles, and if it does I immediately test the function in-game with any potentially invalid string/argument I can think to give it. Isn't input testing/validation step #1 in QC for code?

>How did this get missed in QC?

Probably a focus on testing only at the UI level. You would have to have a tool that allowed you to edit or generate your own Auth headers to find it. Or have unit testing that fuzzed, or at least supplied obvious bad stuff like nulls or empty inputs.

Not arguing it's good, but it's not uncommon. I've seen lots of places with webapps where the vast majority of tests are selenium driving form inputs, clicks, etc. That misses things like this, or client side cookie manipulation, etc.

While I'm sure you are right that you would totally never do something like that, it's likewise a truism that virtually all security goofs like this are commited by programmers who think they'd totally never do something like that. To wit: I don't believe you.

What almost certainly happened here is that, as someone else in this thread mentions, someone came by to fix an automated warning about the use of strcmp(a, b) and replaced it with strncmp(a, b, strlen(a)) instead of strncmp(a, b, strlen(b)). Easily 90% of code reviewers wouldn't catch that mistake (especially if it came along with a truckload of other such fixes), and as it's a maintenance change no new tests would have been written for it.

The only way to catch this would have been to already have written and deployed a test that expressly tested an empty string password. That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career. Did you deploy a test and integrate it into CI for every one of them?

It was trickier that that even. It wasn't an empty password. It was an empty digest auth response, something like this is the normal path, inside the browsers code...not your own code.

HA1=MD5(username:realm:password)

HA2=MD5(method:digestURI)

response=MD5(HA1:nonce:HA2)

So you have to hijack the header value the browser sends...not just send an empty password.

"That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career."

No, not a single one. I tend to work on projects with a bit more complexity than that (including designing the required hardware on top of it if something suitable doesn't already exist.)

Well most servers ship with IPMI and a default username/password of admin/admin or something equally guessable. There's some assumption that a competent administrator is managing them.

Not sure what you mean here. A competent admin that set a strong password wouldn't have helped with this.

I guess they would have firewalled access, but there's still a bug/hole.

So if you setup AMT in the BIOS and run Linux you are exploitable? Can somebody confirm that this also affacts AMT < 6.0 i.e. Core2 system like Dell Optiplex 755,780?

Core 2 systems are not exploitable. It's only for Nehalem and later. Yes, you're also vulnerable on Linux.

> So if you setup AMT in the BIOS and run Linux you are exploitable?

Perhaps I misunderstand the question, but AMT is not dependent on the system's OS, by design. AMT runs on Intel Management Engine, a platform on the computer with its own CPU, memory, OS, bus, caches, etc. ... and applications, including AMT. AMT is designed to be used when there is no functioning OS.

Think of it this way: You paid for one computer, but you got two!

AMT runs below the OS on a coprocessor inside the intel chip that has a privilege level greater than hypervisor to your machine and monitors the mobo ethernet independently of the OS. It can re-image and control your machine no matter what OS is running. Yes you're vulnerable running Linux.

Is this vulnerability just an authentication bypass the AMT web server, or the root cause was that AMT itself vulnerable?

I have witnessed more than one (internal, not security critical) bug caused by a junior coder who's noticed a compiler nag about not using the length-checking version of string functions.

Has anyone developed a scanning program yet? To scan your local network for vulnerable machines. It would be very handy to know which systems I need to boot into Bios and disable AMT.

No but you have enough info to make it in the comments

including the nmap/curl commands

http://mjg59.dreamwidth.org/48429.html

Use nmap to check for the open ports.

623, 664, 1699[2-5]

Thanks.

So if I point another computer on the network to the given ports on a browser, I should see this damn interface? Would be a nice way to indicate whether it is on or not, maybe?

I think AMT needs to be provisioned on target computer to be exploitable.

But to find out if it is, I need to go into the BIOS, right? Isn't it easier just to try going to a port?

I keep reading that if you "disable AMT" in the BIOS (on my Lenovo, anyway) it just resets the settings. A complete WTF but that's what I've been reading.

Yea, maybe. going to the port is less conclusive in general case. E.g. you have some firewalls/other networking devices/etc in the middle that would deny access to that port and it would make you think it's disabled but it's actually not.

There is also a local, non root user exploit to provision AMT described in Intel's announcement.

Yes. To be honest, Intel's announcement was a little dry, lacking details.

The problem is even if the interface says it's not activated, can you believe it's not activated? When you have closed source software running on a separate chip you have no control over you can never be 100% sure of what it does. Even if you trust the company completely you can't be sure there's no bugs in it. Especially if it's got a load of code your "not using" in there.

To that end sure, but then this whole discussion is pointless. Right now we have a known serious problem that has a known (by someone out there) way of identifying.

Point your curl at port 16992 of the target machine, you'll get something like:

$ curl -v http://server:16992

> GET / HTTP/1.1

> Host: server:16992

> User-Agent: curl/7.47.0

> Accept: /

< HTTP/1.1 303 See Other

< Location: /logon.htm

< Content-Length: 0

< Server: Intel(R) Active Management Technology 8.1.10

I went to my BIOS and turned AMT "on". I turned off my modem and connected my Lenovo to Ethernet. I sshed into another machine, and ran the curl command back at the Lenovo. I tried ports 16992 and 16993 per the article. And I got no such response.

This shit is never clear, but did I have to actively turn this thing on to be vulnerable to the remote variant of this attack?

Will blocking ports 16992-16993 at router block this attack vector?

Reply on news.ycombinator.com