[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libreboot] Blocking Intel ME ?

From: Daniel Tarrero
Subject: Re: [Libreboot] Blocking Intel ME ?
Date: Thu, 21 Jan 2016 11:26:10 +0100

hi dude!

first, i have no in deep knowledge about AMT , and i'm also worry about
AMT's capabilities:

>From wikipedia, Intel's AMT "features" (that nobody seem to use and
everybody should be afraid of ;):

- Encrypted, remote communication channel for network traffic between
the IT console and Intel AMT.
- Ability for a wired PC outside the company's firewall on an open LAN
to establish a secure communication tunnel (via AMT) back to the IT
- Remote power up / power down / power cycle through encrypted WOL.
- Remote boot, via integrated device electronics redirect.
- Console redirection, via serial over LAN (SOL).
- Keyboard, video, mouse (KVM) over network.
- Hardware-based filters for monitoring packet headers in inbound and
outbound network traffic for known threats, and for monitoring known /
unknown threats based on time-based heuristics.
- Isolation circuitry to port-block, rate-limit, or fully isolate a PC
that might be compromised or infected.
- Agent presence checking, via hardware-based, policy-based programmable
- Persistent event log, stored in protected memory (not on the hard
- Access (preboot) the PC's universal unique identifier (UUID).
- Access (preboot) hardware asset information, such as a component's
manufacturer and model, which is updated every time the system goes
through power-on self-test (POST).
- Access (preboot) to third-party data store (TPDS), a protected memory
area that software vendors can use, in which to version
information, .DAT files, and other information.
- Remote configuration options, including certificate-based zero-touch
remote configuration, USB key configuration (light-touch), and manual
- Protected Audio/Video Pathway for playback protection of DRM-protected

... i just miss the lord's right to bed :S

Trying to answer your dubts:

It is possible to block any traffic. To unplugg the wire is the best try
you have :)

It is possible to block all traffic from certain MAC, and also is
possible (and maybe more easy) allow only traffic from specific MAC.
This use to be a common feature in routers nowadays.

BUT! It is also possible to impersonate a MAC (that is, change some
device's MAC to look like other nic's MAC). Read a little about MAC
spoofing and ARP poison to have an idea of this attack behaviour.

- is a good security meassure to filter traffic/routing by MAC
- it is not perfect, can be avoided
- the attack vector you are worried about is sophisticated (bios / cpu /
firmware attacks). I'm afraid that people with this tools already knows
about mac spoofing, arp, and other fancy ways to bypass firewalls.

i think your best bet should be:
- trust your CPU manufacturer (or change it!) and check it's integrity
(take a look at intel's  chipsec project:
- protect you bios (password, jumpers if possible)
- disable AMT in bios, and...
- pray to your gods (all the previous security meassures has also being
broken in some scenarios).

Finally, you can sniff the traffic out of your machine with a linux
machine in the middle. Read about Wireshark and transparent proxies and
maybe some about IDS like Snort too.

Maybe is time to boicot vPRO/AMT hardware :)

??? can be there some hardware way to disable this? jumpers, soldering,
hammering? ^^

good luck and share your findings in the subject! im interested too :)
regards, D

El sáb, 16-01-2016 a las 14:10 +0530, Jay Aurabind escribió:
> Hi,
> I was going through the page at libreboot on Intel Management Engine[1].
> Assume that somebody is indeed planning to attack a user through Intel
> ME, and send some information remotely through its separate ethernet
> interface.
> Is it possible to detect that MAC id of the independent ME unit and
> block it in my router so that even if ME is activated I can block all
> communication to the outside world ? Any possibilities with arp or
> something like that ?
> [1]:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]