The Intel dev kit I've been using includes a (also see the ) which allows remote reboots in case the operating system hangs. It has the capability of listening a handful of ports (16992 and 16993, to be specific) on an IP address it shares with the operating system.
(either by snooping DHCP requests or issuing its own; I'm not sure, but either way it uses a shared MAC address in this mode) I have it running on a separate IP address, because I'm worried about one potential use case: how does AMT prevent the host network stack from conflicting with it? In other words, the Intel management software is now listening at least two TCP ports, out-of-band and without the operating system's knowledge. Let's say I initiate a TCP connection to a remote host, and the host stack chooses 16992 or 16993 as the local port to listen on for packets coming back to the box. Won't packets returning from the remote host get 'blackholed' and never reach the OS? Or is there some preventative measure, like an Intel driver in the Linux kernel knowing that TCP should avoid port 16992? (seems unlikely since this is an OS-agnostic feature.) Or maybe the management interface can forward traffic sent to port 16992 that doesn't belong to a known management session back to the host stack? Either way, I'm reluctant to use this for network-intensive loads until I understand how this works.
I searched the and couldn't find anything there either. I suppose this could be tested by initiating around 30,000 TCP connections, and checking if connectivity works even if the port overlaps. But I haven't had a chance to do that yet. (Footnote: I realize this question is similar to, but that questions addresses connectivity in general, not connectivity to the specific TCP ports that overlap with the host stack.).
After configuring AMT to listen on a shared IP address, I ran the test mentioned by in the comments above. (against my own remote host with an SSH server, not actually example.com, of course) Here is the result: Positive test case (using a port not used by AMT): $ nc -p 16991 example.com 22 SSH-2.0-OpenSSH5.9p1 Debian-5ubuntu1.4 ^C $ Negative test case (using a port used by AMT): $ nc -p 16992 example.com 22 $ (After a few minutes, the negative test case timed out and returned to the shell prompt.) So as you can see, the packets coming back to port 16992 were dropped before they reached the host's TCP/IP stack. Recommendation: if reliable networking is important to you, do not enable AMT on the same IP address as your host TCP/IP stack! What should be noted is, that AMT is intended as client OOBM technology not server one. Therefore yes, it may happen that that your computer decide to use AMT ports, but only in case that you specifically configured it to do so.
Most of OSes come with preconfigured ephemeral ports at range 49152 to 65535 as suggested by IANA specification, some Linux distros with 32768 to 61000 and old Windows with 1025–5000. So from my perspective it is save to use shared IP for AMT since its ports are not in ephemeral range (unless you know what you do, and change this particular setting) and should not be used as listening port by any application. There is a controversary thread at Intel forum with the suggestion that one must configure different IP addresses for AMT and host when operating with static IPs. And an explanation: When you configure the vPro machine with static IPs, AMT will use the mac address called manageability mac which comes to play only in static IP mode. Manageability mac address is different from the mac address presented by the host. I confirm that using DHCP with both AMT and Host leads to routing problems. Ping mislead: 64 bytes from 192.168.1.11: icmpseq=18 ttl=64 time=0.559 ms 64 bytes from 192.168.1.11: icmpseq=18 ttl=255 time=0.614 ms (DUP!) 64 bytes from 192.168.1.11: icmpseq=19 ttl=64 time=0.579 ms 64 bytes from 192.168.1.11: icmpseq=19 ttl=255 time=0.630 ms (DUP!) 64 bytes from 192.168.1.11: icmpseq=20 ttl=64 time=0.553 ms 64 bytes from 192.168.1.11: icmpseq=20 ttl=255 time=0.602 ms (DUP!).
One solution might be to set the ports for the Windows TCP stack by using netsh. By default, Windows uses port 49152 65636 (or whatever the upperlimit is) So you're very safe to use AMT. You can set the port range with netsh. For instance, I always use about 1000 ports for perimeter machines. Furthermore, Intel strips off the AMT commands and passes all other traffic on those ports (5 actually!) to the OS (If an OS is present).
So if you would have an application that opened up a port in the AMT range, the traffic will still pass through the OS to the application, because like I said, Intel only strips of the AMT management commands. Its unlikely your application is sending AMT commands. This answer assumes (1) you are using Windows, and (2) you aren't using any software that might try to use AMT-overlapping ports for other reasons. (you may have, for example, a VoIP application that uses random UDP ports) It also makes a claim about how Intel 'strips off' the AMT commands, which was clearly shown to be false in my answer.
Can you provide a reference to support your claim? I wouldn't be surprised if Intel considered this a bug and fixed it one day, but at the time I posted my answer, they clearly had not. – Jan 20 '15 at 17:19.
Intel Unified Amt 8 Management Interface Driver For Mac
Earlier this week Intel announced a that affects its remote management features shipping with Intel Server chipsets for past 7 years, which, if exploited, would allow a remote attacker to take control of vulnerable PCs, laptops, or servers. The vulnerability, labeled CVE-2017-5689, affects Intel remote management technologies, including Active Management Technology (AMT), Intel Standard Manageability (ISM), and Intel Small Business Technology (SBT) software, versions 6 through 11.6. The flaw was originally discovered by Maksim Malyutin, a member of Embedi research team, in mid-February, who then responsibly disclosed it to the Intel security team. My, published earlier this week, was based on the partial information shared by Maksim to The Hacker News, as the reported Intel AMT vulnerability was highly critical and can be exploited remotely, Embedi held technical details until most sysadmins update their systems with a patched firmware. Today, Embedi research team has disclosed complete about the critical vulnerability, revealing that a remote attacker can hijack computers powered by Intel Chipset just by sending an empty authentication string. To understand how, I have compiled this piece explaining:.
What is Intel AMT technology?. Where the Intel AMT Vulnerability resides?. How can an attacker exploit Intel AMT Vulnerability? What is Intel AMT technology? Intel-based chipsets come with an embedded technology, called Intel Active Management Technology (AMT), to enhance the ability of IT administrators, allowing them to remotely manage and repair PCs, workstations, and servers of their organization. Using a web-based control panel, accessible from port 16992 and 16993, which comes pre-installed on the chipset, an administrator can remotely manage a system. The Intel AMT Web Interface works even when the system is turned off, as long as the platform is connected to a line power and a network cable, as it operates independently of the operating system.
Where the Intel AMT Vulnerability resides? To protect Intel AMT Web Interface from unauthorized users, the service makes use of HTTP Digest and Kerberos authentication.
The escalation of privilege vulnerability resides in the way Intel AMT Web Interface handles user authentication over HTTP Digest protocol, which is based on a simple challenge-response paradigm. Before going into the technical details about the exploitation of this vulnerability, first, you need to know how the Digest authentication works. The Digest authentication completes in the following steps:.
Client requests server to initiate login, and in response, the server returns a randomly generated 'nonce' value, the HTTP method, and the requested URI. Next, the user is prompted to enter his username and password. Once entered, the client machine sends an encrypted string (referred as userresponse)—generated by applying a hash function to the entered username and password, server-supplied nonce value, HTTP method, and the requested URI—to the server. The server also calculates a similar encrypted string (referred as computedresponse) using username and password stored in the database and all the other three values. The server compares both the strings using the strncmp function and if they match, it allows the user to log into the Intel AMT Web Interface. The Intel AMT vulnerability resides exactly in the strncmp function that server uses to compare both encrypted strings. Syntax example: strncmp (string1, string2, length) —where, length parameter defines how many characters needs to be compared.
Strncmp is a binary safe string comparison function that returns a negative, zero, or a positive integer depending upon whether string1 is greater or less than string2, and if they are equal, it returns zero. As, it’s obvious, for successful authentication, userresponse variable must be equal to computedresponse variable; hence the strncmp function must return a zero value for any length. But, according to the researcher, the programmers who coded this authentication process for Intel platform mistakenly used the length of the userresponse variable in strncmp function, instead of the computedresponse variable for responselength parameter.
How can an attacker exploit Intel AMT Vulnerability? (The above video demonstration for Intel AMT flaw has been submitted by our beloved readers and independent security researchers, Dhanunjaya.V & Jithin D Kurup, who have previously reported critical flaws in IP cameras, bill boards, banks and payment gateways and many Indian Government sites.) To exploit this logical flaw in Intel AMT Web Interface, all an unauthorized attacker needs to do is send nothing (null) into userresponse to the server.
Since the strncmp function is mistakenly using character length of the userresponse variable to authorize the user, which in this case is null, the string comparison function would be tricked into matching nothing and believe that attacker's response (userresponse) is equals to the computedresponse. As both variables matched, the attacker will be authenticated to log into the Intel AMT Web Interface and do whatever an authorized administrator can do, gaining high-level privileges on the system. Computers Can be Hacked Even If They're Turned OFF An attacker can also use Keyboard Video Mouse (KVM) feature, available inside Intel AMT Web Panel, which runs at a hardware level and allows sysadmins to remotely take control of the whole system, and perform tasks like: 'Attacker can remotely load, execute any program to the target system, read/write any file (using the common file explorer),' the research team wrote in its paper. 'Using IDE-R (IDE Redirection), the attacker can remotely change the boot device to some other virtual image for example.'
'Using SOL (Serial over LAN), the attacker can remotely power on/power off/reboot/reset and do other actions with this feature. Also, it can be used to access BIOS setup for editing,' the team added. In short, a potential attacker can do everything that a sysadmin can do: he can log into a vulnerable machine's hardware, and silently perform malicious activities, like tampering with the system and installing virtually undetectable malware. Install Firmware Update to Patch the Vulnerability NOW! The bug affects Intel manageability firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 for Intel's AMT, ISM, and SBT platforms.
However, versions before 6 or after 11.6 are not impacted. Intel has rated the vulnerability as highly critical and new firmware versions, if any workstation runs AMT, ISM, or SBT, a to check if your system is vulnerable, and a for those organizations that can not immediately install updates. So, the Intel customers are strongly recommended to install a firmware patch without wasting a single second. Also, there's a simple mitigation tool available on, created by Malware researcher, which is based on the Mitigation Guide provided by Intel.
All an affected user has to do is, just download and run DisableAMT.exe, it will disable Intel AMT on Windows operating system (x86 and x64).