Disabling Intel ME remote management Via Metasploit

[ravenise]

Once a user has access to intel ME internals, they should be able to modify Intel ME's settings and disable remote access / back door features using Metasploit modules; This could be turned into an automated patch that permanently closes all known vectors of attack built into AMT;

https://rapid7.com/db/search?utf8=%E2%9C%93&q=amt&t=a

[matt123b]

One of the issues with the IME is that it has its own little operating system that's running in there whenever the PC has power supplied to it. It's an always-on hardware/firmware hypervisor, and Windows and Linux have drivers that can be used to interface with the IME from the OS level. With me_cleaner all of the required firmware for the IME to work is stripped out, except for the FPT and BUP, so a partition map and one module for hardware init and some power management. The IME also has a kernel module and others that are responsible for processing updates and managing other modules. These other modules, like AMT, aren't responsible for processing updates to the IME firmware.

If there was a dangerous program running on a Linux machine for example, I could uninstall it. But there's still an entire OS under that, and if I don't trust that OS, how do I know that this can't be used to reinstall the bad program? This basically means that I can never connect the machine to the outside web, which totally defeats the purpose of removing the malicious program anyways. The IME is similar here because you're just shutting down/removing some of the lesser software while the core OS components remain.

Don't get me wrong here, this would be better than nothing at all, but still not as through as me_cleaner. Using an external flasher to gut the firmware will always be a better option because there's no chance of the IME reinstalling its own modules without a kernel and other essential parts used to install them. Really for all intents and purposes, me_cleaner is disabling the IME.

[ravenise]

Thank you for your prompt response my brother. That's great and I have no problem with that, I agree that me_cleaner is the best option. Thing is me_cleaner exists, the suggestion I am offering doesn't so far as I am aware. If AMT and all the remote features were disabled VIA an exploit then ostensibly there would be no way for an attacker to re-activate those remote mechanisms unless the firmware was re-flashed. However, it would appear firmware updates can be disabled as well, as evident by the settings in my descriptor.

"local firmware update enabled "false" "bios reflash capable" false "ME flash protection override enabled" false

(I have two different setting layouts in my descriptor, "Boulder Creek -EL_ICH10" and "McCreary -EL_ICH10D." I'm not sure which is active or if both are active at the same time.)

So using the method I suggest, the only possible mechanism for exploitation would be if an exploit was previously embedded inside a compromised Intel ME (or firmware hub), that is capable of changing the settings back, and or establishing a connection through the O/S somehow. If the computer board is fresh, never connected to the internet, and you did this immediately, bingo, no chance for an exploit living inside there.

The biggest issue with me_cleaner is it requires people flash their firmware with external devices and the risk of bricking their hardware. I so far I haven't been able to get a handle on what version of Intel ME is on my 10 year old board. Possibly because I re-flashed it with an Intel firmware update some years ago; Nothing from Intel would detect it. MeInfoWin.exe says "PMXUtil: Error during PMX Call: sseiddrvedll32e.dll!IDRVInstallDriver[}: Couldn't Open Service Manager err(5). In dos I managed to dump the descriptor, which doesn't seem to provide a version number, looks like it may have been stripped. "Flash Image" -> "ME Region" says "major version 0", "minor version 0," "hotfix version 0," "build version 0." fpt.exe stated, "reading region information from flash descriptor" --- Flash Image Information, Signature: INVALID! No more information to be displayed." But at least I can see the configuration of ME.

How many people can or are willing to flash their boards? I would only do this if I knew it was 100% safe. That is a lot of messing around. Using an actual open source exploit from a trustworthy source to disable the most dangerous components of ME, its authentication mechanisms and remote access and reflashability, I believe is one of the best options. The descriptor can be dumped later to detect any modifications and changes.

Take a look at my descriptor, tell me what you think is going on in here. The only tool that worked for me was Intel ME System Tools v5 r1; MX25L80005.zip

[skochinsky]

@ravenise This dump contains only the legacy BIOS (AMIBIOS8) and has no descriptor. If this is full content of your flash, it seems your board is using flash in descriptor-less mode (it was possible until ICH10), in which the ME firmware is not present in the flash so the ME is only running the Boot ROM code. So you don't need to clean it because it's already absent :)

[ravenise]

@skochinsky Does that mean ICH10 does use "descriptor mode" or do you mean everything before ICH10 uses descriptor-less mode. What is descriptor-less mode? I am using an Asus P5Q Pro; It has a ICH10R chipset; The board also has a component called "Express Gate" which is a linux kernel / distro that allows one to access the net right at post; includes skype, a browser, and other features. I'd love to clean that thing out.

[ravenise]

@skochinsky So this is the same BIOS I am accessing during post? Are you saying Intel ME on my ICH10R poses no risk at all, and I can stick my ram back into DIM 0 now?

[ravenise]

A very strange thing occurred the other day while I was logged into windows. After disabling a few entries in the registry governing hardware "redirect" (aka remote control and access to the hardware of my PC) Registry entries grew from ~461000, to ~540000. A massive hidden layer of my registry was uncovered that I had never seen or knew about before; I should have made a backup of this, because I can no longer access it anymore; After trying to disable some very persistent redirect registry keys, which re-enabled upon boot, 1/5'th of my registry vanished again. All the entries I had previously searched for and changed, are no longer visible in my registry. For example.

Windows 7 64 SP1

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

I had changed these from 1, to 0. Some of them were persistent on reboot; they would switch back to 1 again. It wasn't long before I was no longer able to find them anymore; I had not deleted them.

It is as though some remote admin was redirecting a huge chunk of my registry / O/S and hardware. (or THEY were a huge chunk of my o/s and hardware) I was shocked to see these hidden registry keys unlocked; In the process of disabling the redirect settings, twice as many or more more redirect keys became available to me on the next boot (upon searching). You can find these keys by searching for "DeviceRedirect" and or "allowredirect". Many of them were not accessible in group policy (updated with Microsoft security compliance manager)

These six objects also disappeared.

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{007A0536-350C-47ED-9868-DF5C42F80CEA}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{2228C782-A61F-4964-BF35-039C64C5762A}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{971B4056-B53A-4932-85C0-1C67D70BFD18}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{AF3CE3F0-520B-435A-A45C-312C2374AB79}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{DA63EBEF-85CB-4B8A-AC11-43F92721699F}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions] "AllowRedirect"=dword:00000000

[HKEY_USERS\S-1-5-21-2240875929-447784991-1091042645-1000\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects{E615A4B9-1522-4ED3-82A0-03A4B4BD5848}Machine\Software\Policies\Microsoft\Windows\DeviceRedirect\Restrictions]

I uncovered all of this while finding possible shady group policy entries for Chrome browser. One of the steps I took that may have uncovered my hidden registry entries was followed here: https://www.bleepingcomputer.com/virus-removal/remove-chrome-extension-installed-by-your-administrator

I ran RD /S /Q "%WinDir%\System32\GroupPolicyUsers" RD /S /Q "%WinDir%\System32\GroupPolicy" gpupdate /force

A chrome extension (GhostVPN) had access to system settings and had injected a group policy to allow access to system Proxy settings;

Registry Group Policy Objects \SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects{FC974C88-F4E9-4026-B8E4-839875341946}Machine\Software\Policies\Google\Chrome\ExtensionInstallWhitelist\1 = nhippelchacimnkamngddemhkifekini

[ravenise]

@skochinsky Will anything have changed if I try dumping after having removed the ram from slot 0?

[ravenise]

I'm curious how my hackers managed to disable my computer from connecting to the internet from linux, including live distros; for a while anyway. Windows worked just fine. Though they were also changing the mac address on the router and the passwords at one point as well.

[skochinsky]

Since your flash is missing the ME firmware, presence or absence of RAM in slot 0 has no effect on ME: no code will run except the most basic hardware init in the boot ROM.

Your PC issues have nothing to do with ME, please use superuser.com or similar to fix them.

[ravenise]

@skochinsky So did my ME up and ran away all on its own? Is it not always enabled by default; Or was this due to the after-market bios? I thought ME required hardware flashing. There is so much confusing information out there, so please elaborate. I would appreciate that very very much. When running software like hwinfo64 it claims AMT is running and enabled. (gonna jump into windows and double check this stuff quickly just to be sure, will update asap) I thought the ME has its own dedicated flash chip that runs along side the bios; Are all ME's present directly on the CMOS/BIOS/EUFI only and not on a dedicated flash rom? Do "Vpro" enabled boards have a dedicated flash? What do you know of components that contain kernels like the on-board "express gate"? Is it possible for the the Intel Firmware-hub to be compromized and used for nefarious purposes as well? The amount of security intel implemented into them was staggering to me, why? Obviously they got something that could go wrong in there too. It even had its own jumper pins to disable flashing at the hardware level. My board has a 82802 firmware hub; looks like it was originally designed back in 2000. 82802 FirmwareHub.pdf

[ravenise]

Ok so correction, as it is depicted in this image, it says iAMT, and ME supported. That is all.

[ravenise]

I tried importing the me software dump and the original bios i had recently flashed into IFIT; it was after market; kets bios I had added some xeon micro codes; The one I dumped loaded into Flash Image Tool with no problem; the original pre-flashed bios gave me an error.

[ravenise]

I am reading via libreboot quote

"Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space."

So it appears Ket may have actually done this himself with his bios back in 2010?

[skochinsky]

On ICH10 (NB: not the Intel 10 series!), the ME firmware is optional, so it's up to OEM whether to provide it or not; it seems on your board the OEM is not using the ME from the beginning (probably to save on flash chip cost).

[skochinsky]

P.S. from the ICH10 datasheet:

5.23.1.1 Non-Descriptor Mode Non-descriptor mode is similar to the flash functionality of ICH7. In this mode, SPI Flash can only be used for BIOS. Direct read and writes are not supported. BIOS has read/write access only through register accesses. Through those register accesses BIOS can read and write to the entire flash without security checking. There is also no support for the integrated Gigabit Ethernet, Intel Management Engine, chipset soft straps, as well multiple SPI Flash components.

The value at the start of flash (offset 0) determines mode:

FLVALSIG - Flash Valid Signature Register Memory Address: FDBAR + 000h Flash Valid Signature. This field identifies the Flash Descriptor sector as valid. If the contents at this location contain 0FF0A55Ah, then the Flash Descriptor is considered valid and it will operate in Descriptor Mode, else it will operate in Non-Descriptor Mode.

[ravenise]

Wow how lucky I turned out to be. I'm using an Asus P5Q Pro; with a little mod you can use a quad cord Xeon; They are faster than the core2 quad core extreme editions; some of which are still selling for $270 on ebay; The Xeon 5460 was only $18 usd, and mod was only $3. Highly recommend you cover your mofsets with a proper heatsink, here is a good source if you think about using this setup otherwise you could fry your motherboard a lot sooner than you were hoping.

[ravenise]

I am curious as to why my Qualcomm/Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (L1e) is enabled during post, on occasion; typically after a BSOD; or after running certain linux distros. When the computer reboots, the lancard remains active; the light on my switch turns on; The only way to stop this is to turn off the computer, unplug it from the wall and remove the battery. otherwise it eventually stops after a few reboots. The lan card then otherwise only does this when kernels drivers are loaded up by the O/S; I thought this may have been a feature of Intel ME. Do you know anything about this? There is a feature on this Atheros developed by Asus called "AI net 2 " which if enabled also boots the Lan card up on post. Enables or disables checking of the Atheros LAN cable during the Power-On Self-Test.

+E4427_P5Q_Pro.pdf

[ValoWaking]

ICH7 is not safety to use and u asking abot ICH10, amazing, ARM ARC in your nothbridge have hisone flash, that containe OS, ICH7 is AMT ready chipset, and it can passtrow all from your ARM in nothbridge to your virtual MAC (that have ASF, or DASH).

u can open any datasheet like 945GC+ICH7 or G41+ICH7 and read scheme

At first u need to ask Intel, NSA or maybe FBI how work all this sh*t

and at first i think u need to read what is PHY NIC, at second - put out your backdoored P5Q in window ))

[CodeAsm]

I am curious as to why my Qualcomm/Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (L1e) is enabled during post, on occasion; typically after a BSOD; or after running certain linux distros. When the computer reboots, the lancard remains active; the light on my switch turns on; The only way to stop this is to turn off the computer, unplug it from the wall and remove the battery. otherwise it eventually stops after a few reboots. The lan card then otherwise only does this when kernels drivers are loaded up by the O/S; I thought this may have been a feature of Intel ME. Do you know anything about this? There is a feature on this Atheros developed by Asus called "AI net 2 " which if enabled also boots the Lan card up on post. Enables or disables checking of the Atheros LAN cable during the Power-On Self-Test.

+E4427_P5Q_Pro.pdf

Dont know if your particular cards are the case, but most Wireless and wired network cards get their firmware from the driver, so when you run windows, or linux, from coldboot, either no firmware may be running or a very basic one (the one that allows the bios to netboot maybe or load another firmware from EFI modules?)

anyway, even if I get the first part wrong, the drivers may load a newer firmware into the card and when your windows BSOD, or sleeps, linux sleeps or reboots, the firmware may still be running, the OS (or malicuous actor) may have setup the card to wake up from lan, or send periodic packets? im not familiar with the exact default options, but the card may basicly still be active.

If your not a politician or famous person tho, dont asume youd be a direct target and it may just be a firmware doing its "basic" things, like reading packets and seeing if its for him (to wake up). try wireshark and analyse any packets going in and out, match the mac adress. (and yeah, some networkcards may even have another network device, aka MAC on the same port.) If Intel ME isnt running, as previous replies seem to indicate, Intel ME isnt your problem, the networkcard running some firmware while the CPU is halted or BSOD, should not be a problem. you could analyse your network port for what is actually being send, but i asume nothing special.