Remote access management vulnerability in some Intel hardware

[Simon Clubley]

Basically, for machines built around some Intel chipsets, a remote
attacker can use the machine's remote access capabilities to gain
unauthorised access to your hardware and control it remotely.

As this uses the chipset's built-in remote management capabilites,
it operates underneath the level of the operating system.

See https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/
for details and welcome to an example of the kind of things you are going
to have to watch out for now on x86-64 VMS. :-)

BTW, issues like this are _exactly_ what I was thinking of when I raised
the problem of firmware level security vulnerabilities recently.

Simon.

[j***@yahoo.co.uk]

Post by Simon Clubley
Basically, for machines built around some Intel chipsets, a remote
attacker can use the machine's remote access capabilities to gain
unauthorised access to your hardware and control it remotely.
As this uses the chipset's built-in remote management capabilites,
it operates underneath the level of the operating system.
See https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/
for details and welcome to an example of the kind of things you are going
to have to watch out for now on x86-64 VMS. :-)
BTW, issues like this are _exactly_ what I was thinking of when I raised
the problem of firmware level security vulnerabilities recently.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Also see Charlie Demerjian's article at SemiAccurate from
several years ago, as acknowledged in The Register today.
And before there was AMT there was IPMI. This from 2013:
http://www.itworld.com/article/2708437/security/ipmi--the-most-dangerous-protocol-you-ve-never-heard-of.html


Today's coverage has been remarkably unclear, for anyone
who wants to understand what's really at stake without
being faced with multiple layers of obfuscation.

Some particularly unclear points:
(1) it's not just for servers: there are desktop and laptop
equivalents with e.g. Intel vPro badges. NB these aren't
consumer-class systems, but do end up outside business-class
IT sometimes. Do vPro boxes have a similar vulnerability to
today's discussion. Who knows.

Note also that your classical Proliant/x86 (and equivalent
Dell) server boxes with "Lights Out" management options may
not have the exact vulnerabilities discussed today, but
likely come with equivalent challenges of their own.

(2) it's not just a problem for Window boxes. As Simon notes,
this is (afaik) an issue with the firmware in the CPU's support
chipset, which contains its own non-x86 processor which does
things in its own little world, eg providing VNC-like access
to the main system's keyboard, video, and mouse, even when the
x86 OS isn't working. Also it allows the system's mass storage
to be redirected to something on the LAN. It's supposed to be
protected by various stages of enabling and authentication.
The protection doesn't seem to work as advertised (though
some are wondering if it works as intended by certain three
and four letter agencies).

Some have claimed it's a Windows-specific OS problem but that
isn't how I've read it. Definitive correction welcome.

Why bother hacking the OS, or e.g. finding a mostly-artificial
exploit that leaks data at (say) 24 bits per day, when rather
than going in the hard way you can use the "secret" back way
in and get untraceable total control at speeds the IT
department are used to.

On a related topic, anyone hoping that remoteDMA etc is the
answer to the world's need for low latency high bandwidth
comms might also like to dig a little and maybe learn a lot.

Interesting times.

[Stephen Hoffman]

Post by Simon Clubley
Basically, for machines built around some Intel chipsets, a remote
attacker can use the machine's remote access capabilities to gain
unauthorised access to your hardware and control it remotely.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr


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

nmap -p16992,16993,16994,16995,623,664 {your ip block}/{your cidr}

[Stephen Hoffman]

...

More details on the Intel AMT vulnerability. It's an authentication bypass:

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability

[Simon Clubley]

Post by Stephen Hoffman

...

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability

Thank you Stephen. That was very informative and depressing at the
same time.

I very strongly recommend that everyone reads the above article; it's
even worse than I thought due to how easy it is to bypass the AMT
security layer.

Basically, if the attacker sends a truncated hash (or even an empty
hash) when prompted for the password, then the AMT server will only
compare the full server-side hash up to the length of the attacker
provided hash. Therefore, if the attacker only supplies an empty hash,
then AMT doesn't even check any of it's own hash to see if they match
and just allows access.

This is critical server infrastructure. :-( Who the hell wrote this
code and how the hell did it survive peer review ?

Simon.

[Bob Gezelter]

Post by Simon Clubley

Post by Stephen Hoffman

...

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability

Thank you Stephen. That was very informative and depressing at the
same time.
I very strongly recommend that everyone reads the above article; it's
even worse than I thought due to how easy it is to bypass the AMT
security layer.
Basically, if the attacker sends a truncated hash (or even an empty
hash) when prompted for the password, then the AMT server will only
compare the full server-side hash up to the length of the attacker
provided hash. Therefore, if the attacker only supplies an empty hash,
then AMT doesn't even check any of it's own hash to see if they match
and just allows access.
This is critical server infrastructure. :-( Who the hell wrote this
code and how the hell did it survive peer review ?
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Simon,

I omitted posting the Intel news to comp.os.vms as it does not affect present OpenVMS platforms (I did post it to RISKS).

It is truly disturbing on many different levels.

- Bob Gezelter, http://www.rlgsc.com

[Stephen Hoffman]

Post by Bob Gezelter

Post by Simon Clubley
This is critical server infrastructure.

I omitted posting the Intel news to comp.os.vms as it does not affect
present OpenVMS platforms (I did post it to RISKS).

More than a few folks are running OpenVMS on x86-64 boxes via
emulation. So... vulnerable. This before the availability of the
port.

Getting access to one box on the network — AMT-exposed server,
down-revision printer, mail server, whatever — can lead to access to
other boxes too, and particularly given that many OpenVMS systems still
use unencrypted and insecure transports.

Then there's SMH, which has functions similar to AMT and has known
flaws in the OpenVMS version of SMH.

Then there are iLO firmware upgrades for ProLiant which don't (yet?)
exist for OpenVMS. I'm getting ssh connection errors whenever I don't
downgrade before connecting to various of the iLO ports I access.

Then there are the down-revision components of OpenVMS itself; pieces
of core layered products are known to be vulnerable. VSI IP will help
here, but some still-commonly-used bits such as telnet, ftp and DECnet
— which I'm unfortunately stuck using in some configurations, too — are
just insecure.

So... don't connect your OpenVMS systems directly to the open 'net — as
I've been stating since at least 2007 — and don't assume that OpenVMS
is secure.

[Kerry Main]

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: May 8, 2017 8:34 AM
Subject: Re: [Info-vax] Remote access management vulnerability in some
Intel hardware

Post by Bob Gezelter

Post by Simon Clubley
This is critical server infrastructure.

I omitted posting the Intel news to comp.os.vms as it does not affect
present OpenVMS platforms (I did post it to RISKS).

More than a few folks are running OpenVMS on x86-64 boxes via
emulation. So... vulnerable. This before the availability of the
port.
Getting access to one box on the network — AMT-exposed server,
down-revision printer, mail server, whatever — can lead to access to
other boxes too, and particularly given that many OpenVMS systems still
use unencrypted and insecure transports.
Then there's SMH, which has functions similar to AMT and has known
flaws in the OpenVMS version of SMH.
Then there are iLO firmware upgrades for ProLiant which don't (yet?)
exist for OpenVMS. I'm getting ssh connection errors whenever I don't
downgrade before connecting to various of the iLO ports I access.
Then there are the down-revision components of OpenVMS itself;
pieces
of core layered products are known to be vulnerable. VSI IP will help
here, but some still-commonly-used bits such as telnet, ftp and DECnet
— which I'm unfortunately stuck using in some configurations, too — are
just insecure.
So... don't connect your OpenVMS systems directly to the open 'net — as
I've been stating since at least 2007 — and don't assume that OpenVMS
is secure.

Agree the flaw is not a good thing, but has somewhat limited impact on OpenVMS systems.

Btw, other than play with trolls stuff, do you really think there are still knowledgeable Customers that connect any OS platform directly to the Internet?

Also, one should always assume there is danger of a platform breach, but that is not unique to OpenVMS. There are no platforms on the planet that can state they are 100% unhackable.

Again, obviously not a good incident, but from what I have read from some of the articles posted, this is an Intel HW platform breach which has recommended fixes and tools supplied to identify systems that may be vulnerable.

Before everyone beats up on Intel, we should remember that the high number of similar critical security issues released each and EVERY month for some commodity OS's.

One could also ask - how does all of this commodity platform OS code pass peer review every month?

And yes, we all know OpenVMS needs work to catch up on some security areas.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Scott Dorsey]

Btw, other than play with trolls stuff, do you really think there are =
still knowledgeable Customers that connect any OS platform directly to =
the Internet?

Well, you have to. SOMETHING has to act as your border machine or firewall.
--scott

[Stephen Hoffman]

Post by Scott Dorsey

Post by Kerry Main
Btw, other than play with trolls stuff, do you really think there are
still knowledgeable Customers that connect any OS platform directly to
the Internet?

Yes, I do. I also know of unskilled folks with exposed systems.

I also know that firewalls are very far from a panacea, and that
attacks that bypass firewalls are commonplace.

Even internal-only use of DECnet and telnet and FTP are hazardous.

I also know we increasingly can't depend on skilled staff even being
available, much less having enough skilled staff and schedule time
available. More with Less, etc.

Then there's that the folks that do know OpenVMS are increasingly
leaving the job market; folks are retiring or dying or moving on to
Linux or Windows Server or other platforms.

But then the cited text also reads like a No True Scotsman discussion.

Post by Scott Dorsey
Well, you have to. SOMETHING has to act as your border machine or firewall.

Ayup.

Then there's the discussion of how to get to ever-larger product
volumes with a complex server software product in a market that
increasingly looks like this:

https://www.nngroup.com/articles/computer-skill-levels/

OpenVMS has to be made far easier and more intuitive and more familiar
to manage, and has to become more automated and more self-managing, and
has to be remotely manageable and more easily provisioned. Because we
are not going back to the Y2K era or to the 1990s; to teams of folks
managing servers. Products that depend on management from the Y2K or
earlier era are just not going to be accepted for wholly new
deployments. Products that are different from what vendors are using —
Linux or Windows Server or such — are also only initially going to be
selected and adopted slowly for wholly new vendors and projects, and by
by smaller projects and vendors too. Nobody is going to swap out a
gazillion-server Linux deployment to train a new team and roll out a
whole new large OpenVMS. Not without a whole lot of work in OpenVMS
to make that feasible. That might happen five or ten years into the
future, but not now. VSI clearly knows all this and will be working
toward this, and though they're focusing on keeping the installed base
happy right now; on establishing a sustainable revenue stream.

[Simon Clubley]

Post by Scott Dorsey

Btw, other than play with trolls stuff, do you really think there are =
still knowledgeable Customers that connect any OS platform directly to =
the Internet?

Well, you have to. SOMETHING has to act as your border machine or firewall.

And if that firewall machine is AMT enabled... :-)

Simon.

[Simon Clubley]

Post by Kerry Main
Before everyone beats up on Intel, we should remember that the high
number of similar critical security issues released each and EVERY
month for some commodity OS's.

It's bad enough when yet another security flaw is discovered in some
web environment, but this is code which runs _underneath_ the operating
system itself.

Intel deserves to be heavily hammered for this.

This is security critical code of the highest order and it should have
been _heavily_ and _formally_ verified.

Post by Kerry Main
One could also ask - how does all of this commodity platform OS code
pass peer review every month?

OTOH, sometimes you ask good questions and that's one of them.

Sooner or later something really bad is likely to happen and the
blowback from it is likely force changes in the software development
process (at least for the software determined to be security
sensitive). Unfortunately, I don't really see much happening until
this event occurs.

Simon.

[David Froble]

Post by Simon Clubley

Post by Kerry Main
Before everyone beats up on Intel, we should remember that the high
number of similar critical security issues released each and EVERY
month for some commodity OS's.

It's bad enough when yet another security flaw is discovered in some
web environment, but this is code which runs _underneath_ the operating
system itself.
Intel deserves to be heavily hammered for this.

Intel doesn't care! They got no competition. Or, very little. Look at how
many expect to run XEONs rather than Opterons. Never forget Intel's attitude
about the 386 FP problem.

Post by Simon Clubley
This is security critical code of the highest order and it should have
been _heavily_ and _formally_ verified.

Post by Kerry Main
One could also ask - how does all of this commodity platform OS code
pass peer review every month?

OTOH, sometimes you ask good questions and that's one of them.
Sooner or later something really bad is likely to happen and the
blowback from it is likely force changes in the software development
process (at least for the software determined to be security
sensitive). Unfortunately, I don't really see much happening until
this event occurs.

You mean, like the latest ransomware stuff?

Didn't affect my VMS systems ....

:-)

[j***@yahoo.co.uk]

Post by Simon Clubley

Post by Stephen Hoffman

...

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability

Thank you Stephen. That was very informative and depressing at the
same time.
I very strongly recommend that everyone reads the above article; it's
even worse than I thought due to how easy it is to bypass the AMT
security layer.
Basically, if the attacker sends a truncated hash (or even an empty
hash) when prompted for the password, then the AMT server will only
compare the full server-side hash up to the length of the attacker
provided hash. Therefore, if the attacker only supplies an empty hash,
then AMT doesn't even check any of it's own hash to see if they match
and just allows access.
This is critical server infrastructure. :-( Who the hell wrote this
code and how the hell did it survive peer review ?
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Interesting how so many "security researchers" have been barking
up their own trees at DEFCON and elsewhere, while folks like
Charlie Demerjian and others have been looking into this for
years, getting nowhere ("we're Intel, you can trust us").

There must be some decent people in the "security" community,
but overall imo the signal to noise ratio isn't that good.

[j***@yahoo.co.uk]

Post by Simon Clubley

Post by Stephen Hoffman

...

https://www.tenable.com/blog/rediscovering-the-intel-amt-vulnerability

Thank you Stephen. That was very informative and depressing at the
same time.
I very strongly recommend that everyone reads the above article; it's
even worse than I thought due to how easy it is to bypass the AMT
security layer.
Basically, if the attacker sends a truncated hash (or even an empty
hash) when prompted for the password, then the AMT server will only
compare the full server-side hash up to the length of the attacker
provided hash. Therefore, if the attacker only supplies an empty hash,
then AMT doesn't even check any of it's own hash to see if they match
and just allows access.
This is critical server infrastructure. :-( Who the hell wrote this
code and how the hell did it survive peer review ?
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world

Correct.

And (I repeat) not just server infrastructure, but business-class
laptops and desktops and such have AMT and vPro etc too, though
the exact details of what applies to them are still unclear. Now,
what kind of organisations use those business-class machines?

Not that anything much in this picture is particularly clear,
apart from the astounding incompetence. Oh well, it's the 21st
century, I suppose people have to expect this stuff in the modern
world of IT. Maybe "peer review" is a bit of a quaint concept.

[Craig A. Berry]

Post by j***@yahoo.co.uk
And (I repeat) not just server infrastructure, but business-class
laptops and desktops and such have AMT and vPro etc too, though
the exact details of what applies to them are still unclear.

Apparently some of these are vulnerable to a local escalation of some
sort even it not running the services that would make them vulnerable to
the remote exploit. And Lenovo is projecting many weeks away for
firmware updates for many of the affected Think-widgets, and a lot of
organizations don't routinely upgrade firmware on end user machines.

As far as OpenVMS relevance, remember you have to have a Windows server
machine to run the only supported monitoring tools for your VMS machine.
If someone can gain administrative access to that Windows machine, how
safe is the VMS machine that you've had to set up as being joined at the
hip to it?

[Paul Sture]

Post by Stephen Hoffman

Post by Simon Clubley
Basically, for machines built around some Intel chipsets, a remote
attacker can use the machine's remote access capabilities to gain
unauthorised access to your hardware and control it remotely.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
https://mjg59.dreamwidth.org/48429.html
nmap -p16992,16993,16994,16995,623,664 {your ip block}/{your cidr}

Thanks for that. Intel only provide a Windows based tool, which might
get problematic from a licensing viewpoint when checking out non-Windows
boxes.

[Snowshoe]

Does any of this affect iLO access to itanium servers? Or x86 only?

[Stephen Hoffman]

Post by Snowshoe
Does any of this affect iLO access to itanium servers?

iLO has security fixes unrelated to the AMT problem.

SMH has security upgrades unrelated to this problem too, and fixes for
those are unavailable for OpenVMS.

Whether there's a web interface vulnerability in iLO similar to this
AMT hole? Donno. Have a look at the security patch notices for what's
been published by HP/HPE.

A local server box with the AMT hole is a great spot to monitor
insecure network traffic to and from your OpenVMS servers, too.

Printers too have firmware security upgrades, and printers — even those
behind firewalls – are often easy to access and breach remotely.

We are not operating in isolated islands of computing, and attackers
are more than willing to try different combinations. The attackers
don't care whether any CVE is tagged with OpenVMS, just that the bug
exists or not and can be exploited or not. The attackers do not care
if the layered product is separately packaged from OpenVMS, just that
it's vulnerable and installed on OpenVMS. The attackers don't care if
the system they're using to access and listen to your telnet and FTP
traffic is a printer, just that it's running down-revision firmware and
they've convinced somebody in your organization to print a document
containing the network monitor and reverse-access gateway into your
network. The attackers don't care if SMH is no longer maintained for
OpenVMS and the "most recent" version is badly vulnerable, just that
SMH is still running on your OpenVMS server. That your SNMP
connections are SNMPv2 and thus open to eavesdropping. Etc.

We are not in the 1990s any more.

[Bob Gezelter]

Post by Stephen Hoffman

Post by Snowshoe
Does any of this affect iLO access to itanium servers?

iLO has security fixes unrelated to the AMT problem.
SMH has security upgrades unrelated to this problem too, and fixes for
those are unavailable for OpenVMS.
Whether there's a web interface vulnerability in iLO similar to this
AMT hole? Donno. Have a look at the security patch notices for what's
been published by HP/HPE.
A local server box with the AMT hole is a great spot to monitor
insecure network traffic to and from your OpenVMS servers, too.
Printers too have firmware security upgrades, and printers — even those
behind firewalls – are often easy to access and breach remotely.
We are not operating in isolated islands of computing, and attackers
are more than willing to try different combinations. The attackers
don't care whether any CVE is tagged with OpenVMS, just that the bug
exists or not and can be exploited or not. The attackers do not care
if the layered product is separately packaged from OpenVMS, just that
it's vulnerable and installed on OpenVMS. The attackers don't care if
the system they're using to access and listen to your telnet and FTP
traffic is a printer, just that it's running down-revision firmware and
they've convinced somebody in your organization to print a document
containing the network monitor and reverse-access gateway into your
network. The attackers don't care if SMH is no longer maintained for
OpenVMS and the "most recent" version is badly vulnerable, just that
SMH is still running on your OpenVMS server. That your SNMP
connections are SNMPv2 and thus open to eavesdropping. Etc.
We are not in the 1990s any more.
--
Pure Personal Opinion | HoffmanLabs LLC

To all,

The original Intel announcement strongly implied "server" chips. However, apparently that was somewhat of a misstatement.

The tool that Intel has now released flags at least some Core-i5 chips (used on "business" laptopss as vulnerable and requiring an update. If anyone has "appliances" connected to one's network that are Intel-based, they are likely to require updates also.

- Bob Gezelter, http://www.rlgsc.com

[Paul Sture]

Post by Bob Gezelter
To all,
The original Intel announcement strongly implied "server" chips.
However, apparently that was somewhat of a misstatement.
The tool that Intel has now released flags at least some Core-i5 chips
(used on "business" laptopss as vulnerable and requiring an update. If
anyone has "appliances" connected to one's network that are
Intel-based, they are likely to require updates also.

The HP/HPE split means that long standing customers have two places to
look...

HP's current list is split into

- Commercial Desktops, Thin Clients, and Retail Point of Sale Desktops
- Desktop Workstations
- Commercial Notebooks, Mobile Workstations, and Mobile Thin Clients
- Consumer Notebooks and Desktops

<http://www8.hp.com/us/en/intelmanageabilityissue.html>

Note that many have a patch availability target date of this next
Saturday.


Here's a high level list from HPE. Note the presence of things like
3PAR and MSA Storage:

<http://h22208.www2.hpe.com/eginfolib/securityalerts/CVE-2017-5689-Intel/CVE-2017-5689.html>

And if you have Dell systems, their page with a model list in a
downloadable PDF appears to be under some strain at the moment:

<http://en.community.dell.com/techcenter/extras/m/white_papers/20443914>

That page referred to by The Register article:
<https://www.theregister.co.uk/2017/05/07/dell_patches_amtvulnerable_systems/>

[Stephen Hoffman]

Post by Bob Gezelter
The original Intel announcement strongly implied "server" chips.

AMT was and is intended for managing business computer systems; both
clients and servers.

AMT is latent on many Intel-based systems with Intel hub chips with
supported networking.

Various vendors including Apple have not provided or provisioned the
management engine firmware and are thus not exposed to this
vulnerability.

HPE servers containing the ProLiant system ROM and the iLO remote
management firmware are also reportedly uneffected by the AMT
vulnerability; those are not loaded with the management engine
firmware. (Do ensure your iLO is running current firmware, as there
are other issues with that.)

It's also been reported by a few folks that a local user can
potentially load AMT firmware into Intel-based hardware configurations,
but details on that aren't clear (yet?). It's probably not a good time
to go do that right now, either.

Post by Bob Gezelter
The tool that Intel has now released flags at least some Core-i5 chips
(used on "business" laptopss as vulnerable and requiring an update. If
anyone has "appliances" connected to one's network that are
Intel-based, they are likely to require updates also.

AMT comprises several parts: various Core or Xeon processors, an Intel
hub, an AMT-compatible network chip, and the management engine firmware.

In addition to the links and the nmap network mapping command mentioned
earlier...

https://nvd.nist.gov/vuln/detail/CVE-2017-5689
https://www.kb.cert.org/vuls/id/491375

It's a certainty that folks are crawling through AMT code now — the
management engine firmware is reportedly based on Minix3 — looking for
other issues, too.

[Stephen Hoffman]

Post by Simon Clubley
Basically, for machines built around some Intel chipsets, a remote
attacker can use the machine's remote access capabilities to gain
unauthorised access to your hardware and control it remotely.

...

https://github.com/mjg59/mei-amt-check
https://puri.sm/posts/reverse-engineering-the-intel-management-engine-romp-module/