WEBVTT
00:00:00.099 --> 00:00:15.750
34c3 preroll music
00:00:15.750 --> 00:00:22.450
Herald: Last year he presented how to get
JTAG over USB at the 33C3. Today he will
00:00:22.450 --> 00:00:28.119
tell us how to interrogate the Intel
Management Engine in a similarly ingenious
00:00:28.119 --> 00:00:36.079
and devious way. Please join me in
welcoming Maxim Goryachy to 34C3.
00:00:36.079 --> 00:00:44.130
Applause
00:00:44.590 --> 00:00:54.800
Maxim Goryachy: Hello guys. I'm speaking
about Intel debug capabilities at the CC
00:00:54.800 --> 00:01:02.579
Conference for the second year in a row.
Last time I talked about how new Intel
00:01:02.579 --> 00:01:11.920
CPUs allow debug technology called Intel
Direct Connect Interface or DCI and now
00:01:11.920 --> 00:01:24.670
I'm going to talk how activates DCI for
Intel Management Engine. (Sorry) DCI is a
00:01:24.670 --> 00:01:31.750
private implementation of widely known
industry standards for debugging hardware
00:01:31.750 --> 00:01:40.729
and low level software from Intel. And
addition I will talk about how it can be
00:01:40.729 --> 00:01:51.549
used for research and how to use it in
practice. Unfortunately my colleague Mark
00:01:51.549 --> 00:02:00.939
couldn't come and I will introduce our
research alone. And I think that you some
00:02:00.939 --> 00:02:09.639
hungry and I will be quickly. Out our
Management Engine research team at
00:02:09.639 --> 00:02:15.530
Positive Technologies includes following
researchers: my colleague Dmitry Sklyarov
00:02:15.530 --> 00:02:27.470
and Mark Ermolov and myself. Mark Ermolov
is my colleague. With him, with whom we
00:02:27.470 --> 00:02:32.791
found Intel vulnerability in Intel
Management Engine. He is a system
00:02:32.791 --> 00:02:38.620
programmer and a reverse engineer and
Dmitry Sklyarov a well known reverse
00:02:38.620 --> 00:02:45.830
engineer who did 5 #research of the ME
filesystem. He recovered Huffman codes for
00:02:45.830 --> 00:02:59.200
version 11 of ME and you can find his tool
for unpacking ME image and for parsing ME
00:02:59.200 --> 00:03:09.730
file system on our Github pages. How you
can see our previous talk related to ME
00:03:09.730 --> 00:03:16.980
and our contacts so you can feel free to
communicate with us for any question
00:03:16.980 --> 00:03:25.370
you're interested about our research. How
I have just said I will talk about what is
00:03:25.370 --> 00:03:32.400
Intel ME, how it's implemented and how we
activated JTAG for ME Core vulnerability
00:03:32.400 --> 00:03:40.650
which Mark and I found. Then I disclose in
details how our technique works and show
00:03:40.650 --> 00:03:55.400
proven our achievements. How many people
in this hall know what is ME? Oh cool! But
00:03:55.400 --> 00:04:05.040
in here, a review. As a topic, the
Management Engine is very popular now.
00:04:05.040 --> 00:04:08.940
First it's almost fully undocumented and
very powerful at the same time. For
00:04:08.940 --> 00:04:15.260
example it has full access to your
platforms hardware including CPU complex,
00:04:15.260 --> 00:04:23.460
it has capabilities to intercept all that
you are doing on your PC. For example
00:04:23.460 --> 00:04:34.000
keyboard, he has access to keyboard to
USB and of course PCI buses. It is also a
00:04:34.000 --> 00:04:46.600
root of trust for many Intel security
features like TPM, like DRM and APT. Intel
00:04:46.600 --> 00:04:52.380
has chosen the following design for ME
version 11: independent microcontroller,
00:04:52.380 --> 00:05:03.710
own operating system based on Minix, built
in Java Machine. It gets started before
00:05:03.710 --> 00:05:13.371
main CPU. Its firmware has parts in PCH,
beyond in memory and in SPI flash. Many
00:05:13.371 --> 00:05:19.290
Intel technologies are implemented with
help of Management Engine for example
00:05:19.290 --> 00:05:34.010
Active Management Technology or PVT and we
think that SGX, too. Another question how
00:05:34.010 --> 00:05:51.690
many people in this hall know what is
JTAG? Cool! But some review of JTAG. JTAG
00:05:51.690 --> 00:05:58.300
stands for Joint Test Action Group and you
can find its description in IEEE standards
00:05:58.300 --> 00:06:05.910
which the details available in the
standard itself. As the results of the
00:06:05.910 --> 00:06:16.350
paper available on our blog where the
design is described in close details. Out
00:06:16.350 --> 00:06:23.380
often manufacture extend standard JTAG by
adding their own functions. JTAG in Intel
00:06:23.380 --> 00:06:31.530
processor is described rather poorly and
some information can be found in documents
00:06:31.530 --> 00:06:46.370
and patent. You can see our paper on the
slide and starting with Skylake, Intel
00:06:46.370 --> 00:06:50.579
introduced
Direct Connect Interface technology
00:06:50.579 --> 00:06:55.889
and you can find the description
00:06:55.889 --> 00:07:06.540
of it in the documents and in our works.
The diagrams show two types of connection:
00:07:06.540 --> 00:07:14.670
using a specific device, a so-called Intel
SVT Closed Chassis Adapter or a common
00:07:14.670 --> 00:07:23.080
used USB3 debug cable. I would like to
note that the target system in this case
00:07:23.080 --> 00:07:30.790
doesn't require the use of a hardware
agent. The drawback of this technology is
00:07:30.790 --> 00:07:37.980
that it works out of box. Intel or Silicon
Valley technology closed unintelligible
00:07:37.980 --> 00:07:51.180
provides access to day fix features like
JTAG and RAM control through USB3 ports on
00:07:51.180 --> 00:08:02.160
platforms. It works through USB3 links but
implements a private protocol and makes it
00:08:02.160 --> 00:08:07.960
possible to manipulate the target system
in deep sleep mode. It means that in this
00:08:07.960 --> 00:08:26.270
mode you have independent links between
JTAG adapter and PCH. USB3 host on DCI is
00:08:26.270 --> 00:08:32.839
common USB3 debug cable which works as OTG
device that means that a special device
00:08:32.839 --> 00:08:38.639
appears on the host system and activation
and commands are sent to device through
00:08:38.639 --> 00:08:46.839
the common USB interface. As the device
itself is integrated into PCH and it
00:08:46.839 --> 00:08:58.449
transforms the command into JTAG. If you
have JTAG for ME devices it means you have
00:08:58.449 --> 00:09:04.869
almost full control of ME. Two main
questions: Doesn't who provides of any
00:09:04.869 --> 00:09:09.800
technique for debugging ME on public
platforms? And the second: What does
00:09:09.800 --> 00:09:20.889
software and hardware need for any
debugging? Ok. The answer to the first
00:09:20.889 --> 00:09:28.420
question: Yes they found a special
partition called UTOK which allocated on
00:09:28.420 --> 00:09:40.749
the special, on the SPI flash where
storage ME. This partition has same
00:09:40.749 --> 00:09:47.610
structures FPT and another partition of
ME. Partition builts entry of available
00:09:47.610 --> 00:09:55.600
debug capabilities. One of this records
means types of unlock: Red or orange.
00:09:55.600 --> 00:10:04.899
Please pay attention, it will be important
later. And what is, what means DFx? DFx is
00:10:04.899 --> 00:10:13.059
collective term for next to privation DFT
designed for testability and DFD designed
00:10:13.059 --> 00:10:27.179
for debugging. DFT is set of technique
used for manufacturing defects finding of
00:10:27.179 --> 00:10:38.259
integrated chips and standard DFT it
generally buys it on ordinary boundaries
00:10:38.259 --> 00:10:48.880
can detect comments but Intel extends it's
DFT in its branded silicone view
00:10:48.880 --> 00:10:55.490
technology. DFD joins all internal chip
level logic used to organize Hardware
00:10:55.490 --> 00:11:02.399
level debugging of course sequences
executed by chips. DFx is connected to
00:11:02.399 --> 00:11:13.939
internal world by a special thing called
embedded day fix interface. This bridge
00:11:13.939 --> 00:11:20.199
connects dayfix whith external industry
interface like USB there is a special
00:11:20.199 --> 00:11:26.749
device in interpret from controller hub
called defects aggregator its function is
00:11:26.749 --> 00:11:44.970
to control access to DFx. 2 types : orange
types it means that vendors may use the
00:11:44.970 --> 00:11:54.790
JTAG debugging for ICH for example and
auto partition for orange unlock must be
00:11:54.790 --> 00:12:06.739
signed by vendor scheme. This key stored
in FPF fuses and more interesting is read
00:12:06.739 --> 00:12:17.670
unlock because this unlock provides full
access to besiege. The internal devices
00:12:17.670 --> 00:12:31.889
unlocks JTAG for ME core and provides
unlimited access to ME memory. Intel
00:12:31.889 --> 00:12:37.360
management engine uses two devices for
support Hardware debugging the fixed
00:12:37.360 --> 00:12:44.280
aggregator management's defects
functionality and the CSE zeroing register
00:12:44.280 --> 00:12:55.840
from device called GEN and only
BUP and ROM uses this device.
00:12:55.840 --> 00:13:02.989
It is CSE zeroing register
when we know only
00:13:02.989 --> 00:13:09.399
about 1 bit.
We called it Intel unlock
00:13:09.399 --> 00:13:26.370
request and this register means that you
asked the platform to do read unlock. More
00:13:26.370 --> 00:13:36.339
interesting is DFx aggregator register and
personal to register. Personality register
00:13:36.339 --> 00:13:45.149
specifies type of unlock red or orange and
consent used for allowed right to personal
00:13:45.149 --> 00:13:58.879
to register. It means that consent
register or it means that this bit to
00:13:58.879 --> 00:14:16.850
allow write data in DFx personal to
register and read and lock works in 2
00:14:16.850 --> 00:14:28.981
steps. On the first, the BUP fun is
finding who talked partition. If partition
00:14:28.981 --> 00:14:43.170
found, the BUP checked is checking
partition signatory and platform ID. Also
00:14:43.170 --> 00:15:02.589
BUP checks time because the talk has time
limitation and after that if all is okay,
00:15:02.589 --> 00:15:11.529
BUP parses an entry in who talked
partition called knobs if intel knob
00:15:11.529 --> 00:15:27.029
unlock founded and platform is not already
unlocked BOB set these aren't register and
00:15:27.029 --> 00:15:38.189
do not reset in it. After set in ROM,
check is checking TCS errant register and
00:15:38.189 --> 00:15:53.699
if it's set, it to clean this register and
switch on consent and personality it means
00:15:53.699 --> 00:16:11.850
read and lock after that ROM is cleaning
ME keys and working but if you have active
00:16:11.850 --> 00:16:18.450
but if dci is active immediate doesn't
latch the fix consent register. It means
00:16:18.450 --> 00:16:31.600
that if you want to switch on JTAG you
don't need to reboot ME. if you have the
00:16:31.600 --> 00:16:43.779
second action inhales deply and how active
how to wait read and lock without intel
00:16:43.779 --> 00:16:50.939
keys on blockhead Europe we disclosed bug
in BUP model. This function as you can see
00:16:50.939 --> 00:16:56.920
has a vulnerability when it called other
function reading in BUP CT file it gives
00:16:56.920 --> 00:17:05.169
incorrect size of data to read instead of
local buffer size the buffer DFS file read
00:17:05.169 --> 00:17:14.010
function gets the size of the role file
how we exploited this vulnerability you
00:17:14.010 --> 00:17:22.638
can found in our presentation from
blockhead and using the vulnerability we
00:17:22.638 --> 00:17:34.960
also have activated attack for management
engine and to research ME in internal of
00:17:34.960 --> 00:17:48.309
in ME right activation without intel keys
may be doing after 4 simple steps on the
00:17:48.309 --> 00:17:56.700
first activate manufacture mode for target
it means for DCI and set the size drop in
00:17:56.700 --> 00:18:02.820
a flash descriptor and using the
vulnerability to a lot well with 3 to
00:18:02.820 --> 00:18:19.720
defects personal register and after that
you you will have MEquerem? and you can do
00:18:19.720 --> 00:18:32.789
research in internal semi but
unfortunately you will have one problem
00:18:32.789 --> 00:18:44.059
because you don't have software for
debugging Keeney but it is small problem
00:18:44.059 --> 00:18:52.730
and next let's talk about software part of
technologists tech it's presented by DAL..
00:18:52.730 --> 00:19:00.149
Intel DFX abstraction layer package
it's alleged library exposes all power of
00:19:00.149 --> 00:19:09.610
DFx software model as we found DAL
heslage history supports various platform
00:19:09.610 --> 00:19:23.470
and CPU architecture designed to work with
different debug ports and hardware were we
00:19:23.470 --> 00:19:28.820
know that DAL is a core of all
instruments that Intel uses for testing
00:19:28.820 --> 00:19:38.100
and debugging of its hardware and firmware
components so it's provided with Intel
00:19:38.100 --> 00:19:47.659
systems studio for example and can be
download without an ID and DAL is almost
00:19:47.659 --> 00:20:02.330
writen in C# and has same structure on the
top DAL has console interface
00:20:02.330 --> 00:20:14.020
and GUI interface and library
layer and Driver transport and DFX on
00:20:14.020 --> 00:20:24.350
target we found a patient from Intel in
public description corelation of DFX exci
00:20:24.350 --> 00:20:34.259
internal interfaces you can see our
previous work to details about how
00:20:34.259 --> 00:20:49.250
internal structure of dialogues DAL's
architecture is based on notion there
00:20:49.250 --> 00:20:57.850
are two type of nodes physical and logical
physical nodes represents 3 of hardware
00:20:57.850 --> 00:21:08.540
components organized from probe unit and
including the following levels gdect e to
00:21:08.540 --> 00:21:15.630
c bus and an other logical nodes
represents certain functionalities that
00:21:15.630 --> 00:21:22.149
can be used to perform debugging stuff and
many problems at public version of DAL
00:21:22.149 --> 00:21:28.210
doesn't include configuration for
ME core however that didn't stop us
00:21:28.210 --> 00:21:47.490
and we found the solution how I said DAL
has some configuration and as
00:21:47.490 --> 00:21:52.570
we investigated during reverse engineering
of the DAL library each configuration is
00:21:52.570 --> 00:22:01.201
included in encrypted XML files DAL uses
aes cipher and key derivation function
00:22:01.201 --> 00:22:13.210
pbkdf2 with fixed key and salt the first
of lines of poem it is salt and ATP is
00:22:13.210 --> 00:22:22.960
easy key the simple program on is a simple
program allows the crypto device
00:22:22.960 --> 00:22:26.880
configuration of DAL
applause
00:22:26.880 --> 00:22:34.177
Thank you.
applause continues
00:22:34.177 --> 00:22:42.460
Maybe another poems to decrypt,
for example
00:22:42.460 --> 00:22:50.710
microcode of CPU, I don't know.
How there is no configuration of any
00:22:50.710 --> 00:22:56.929
devices, we found that ME core is an LMT2
devices and the configuration of this
00:22:56.929 --> 00:23:02.250
device can be found in decrypted XML
files, before anybody can write
00:23:02.250 --> 00:23:12.000
configuration for ME. I don't know, for
example on the slide you can see internal
00:23:12.000 --> 00:23:25.669
structure of LP series of PCH. It is U
series of cpu and at the top divided
00:23:25.669 --> 00:23:42.769
on four part and on top connected parts
in the end ME core. and how to do
00:23:42.769 --> 00:23:51.880
custom configuration, four first
steps: on the first decrypt XML files, the
00:23:51.880 --> 00:24:01.790
second adds the following clients to top
SPT XML and use DAL environment for any
00:24:01.790 --> 00:24:40.640
debugging and it will make you computer
personal again. Some demo. One moment.
00:24:40.640 --> 00:24:55.660
Okay. It is version of systems studio
and we decrypt files, with configuration
00:24:55.660 --> 00:25:18.500
of DAL, and to edit to add some lines.
The top is for each series of PCH and the
00:25:18.500 --> 00:25:35.346
bottom for LP series. It is ME core, it is
linked between ME core and unintelligible
00:25:46.594 --> 00:26:01.130
We halt the execution, we load some,
reloading some library, our library, we
00:26:01.130 --> 00:26:31.010
set up reset breaks, it needs for to stop
on the reset vector in ME. How you can see
00:26:31.010 --> 00:26:50.730
GDT table and current instruction and the
register value, LDT value and we are doing
00:26:50.730 --> 00:27:32.470
a reset on ME and step in
instruction in to ME. Then initialize
00:27:32.470 --> 00:28:17.169
of segments and new GDT value, ok and okay
and demo from black hat. it is our stand,
00:28:17.169 --> 00:28:54.220
it is host platform, already halted, init
settings for any core. Oh sorry. It is not
00:28:54.220 --> 00:29:12.080
ME. The reset vector, how you can see in
catcher interface it is
00:29:12.080 --> 00:29:26.120
special device between which manufacture
for for links between host CPU and ME and
00:29:26.120 --> 00:29:39.830
now we read some read only register for
CPU from (???????) and set the value of
00:29:39.830 --> 00:30:01.400
this register from ME. The magic.
applause
00:30:01.400 --> 00:30:07.210
And then my demo
is more interesting than my english
00:30:07.210 --> 00:30:53.779
sorry and I have a live demo if internet
will be good. One moment. It's my machine
00:30:53.779 --> 00:31:31.620
at work and the internet is not good
sorry. maybe maybe later. Okay. And our
00:31:31.620 --> 00:31:38.829
achievement: JTAG activation, we we do
JTAG - well achievement in respect to the
00:31:38.829 --> 00:31:49.230
vulnerability, in addition we activate
JTAG for ME. Also we dumped the ME startup
00:31:49.230 --> 00:32:01.590
code and found the way to extract
platform's key used by the flash file
00:32:01.590 --> 00:32:17.259
system. It means that you can decrypt and
integrate your files into ME and ME
00:32:17.259 --> 00:32:28.929
doesn't detect it. And our links: on our
GitHub page you can find our tools for ME
00:32:28.929 --> 00:32:37.379
reversing researching and our blogs, where
is our article, our reference and thank
00:32:37.379 --> 00:32:40.177
you for your attention. Questions please.
00:32:40.177 --> 00:32:49.569
applause
00:32:49.569 --> 00:32:54.199
Herald: So anyone that has a question for
Maxim please line up by one of the
00:32:54.199 --> 00:32:59.129
microphones. They are 1, 2, 3, 4 on this
side of the room and 5, 6, 7, 8 on that
00:32:59.129 --> 00:33:03.259
side of the room. If you are watching
online we have a signal angel, who is
00:33:03.259 --> 00:33:08.470
monitoring the internet for all of your
interesting questions and they will be
00:33:08.470 --> 00:33:12.369
asked. So already here
at microphone number one.
00:33:12.369 --> 00:33:17.909
Mic 1: Okay so it mentions, you mention
that you dumped the ROM. And previously,
00:33:17.909 --> 00:33:22.160
as there were some rumors with ROM bypass
available, did you compare the dumped
00:33:22.160 --> 00:33:23.550
Maxim: Yeah.
Mic 1: ROM against ROM bypass
00:33:23.550 --> 00:33:25.029
Maxim: Yeah.
Mic 1: and is it the same?
00:33:25.029 --> 00:33:26.039
Maxim: No.
Mic 1: No?
00:33:26.039 --> 00:33:37.839
Maxim: We found there's some difference
but it relates with that ME bypass code
00:33:37.839 --> 00:33:46.889
starts into protected mode but a
real ROM starts into real mode.
00:33:46.889 --> 00:33:51.850
Mic 1: Okay, so otherwise it's
functioning almost the same.
00:33:51.850 --> 00:33:59.380
Maxim: Hmm, we found some difference in
cryptography but I think it is not
00:33:59.380 --> 00:34:02.549
important.
Herald: So, if you if you are leaving
00:34:02.549 --> 00:34:06.350
please be quiet, so the talk is still
going on, we're still having questions and
00:34:06.350 --> 00:34:13.080
answers and please be considerate of the
people asking questions. Thank you. The
00:34:13.080 --> 00:34:20.389
next one, from microphone number five.
Mic 5: Yeah, so you set the personality
00:34:20.389 --> 00:34:27.389
register to read and then you reset the ME
and it will break at the reset. Is that
00:34:27.389 --> 00:34:32.909
register persistence over reboots or you
have to do the exploit and set it every
00:34:32.909 --> 00:34:36.699
time?
Maxim: Yeah, you need to do it every time.
00:34:36.699 --> 00:34:47.130
This only persist between resets.
Herald: Signal angel, is there's a
00:34:47.130 --> 00:34:50.843
question from the internet.
Signal Angel: Yes, they'd like to know
00:34:50.843 --> 00:34:54.380
where to find the internal USB port on the
00:34:54.380 --> 00:34:59.090
main board.
Maxim: Sorry please repetition.
00:34:59.090 --> 00:35:05.540
Sig Ang: The question is where to find the
internal USB port on the main board for
00:35:05.540 --> 00:35:14.320
the JTAG access.
Maxim: How I know all USB ports now has
00:35:14.320 --> 00:35:23.171
access to this functionality. You don't
need to find its ports on your system. If
00:35:23.171 --> 00:35:34.790
you have platform with Skylake you always
has this functionality on your USB ports.
00:35:34.790 --> 00:35:48.770
Oh, of course if this ports link directly
to PCH, if if it is port- link- connected
00:35:48.770 --> 00:36:01.410
where some another controller you probably
don't have to stay on these ports.
00:36:01.410 --> 00:36:09.020
Herald: Microphone, microphone number two.
Mic 2: Does it work, means you can extract
00:36:09.020 --> 00:36:14.890
any key from ME, for example key for SGX
remote as a station?
00:36:14.890 --> 00:36:26.151
Maxim: I didn't know. We are starting this
research how ME relates with SGX and we -
00:36:26.151 --> 00:36:41.723
I don't know how key in ME extract, derive
and loaded and relate with SGX. I don't
00:36:41.723 --> 00:36:45.040
know, sorry.
Herald: Microphone number one.
00:36:45.040 --> 00:36:52.170
Mic 1: Did you receive any any messages,
any recognition about this from Intel?
00:36:52.170 --> 00:36:59.840
Maxim: You mean that - did we share this
information with Intel?
00:36:59.840 --> 00:37:05.600
Mic 1: No, did they react to, did they
react in any way to that?
00:37:05.600 --> 00:37:10.110
Maxim: After our vulnerabilities they said
"okay"
00:37:10.110 --> 00:37:12.538
audience laughs
00:37:12.538 --> 00:37:15.050
Mic 1: Okay, so nothing much
except for patches?
00:37:15.050 --> 00:37:17.010
Maxim: Yeah.
Mic 1: Okay, thank you.
00:37:17.010 --> 00:37:20.336
Herald: Signal angel, is there another
question from the internet?
00:37:20.336 --> 00:37:27.820
Sig Ang: Yeah - how can you disable the
JTAG access? is just disabling the ME
00:37:27.820 --> 00:37:36.909
enough or what do you have to do?
Maxim: Sorry, you mean how Intel disabled
00:37:36.909 --> 00:37:44.810
decide functionality for ME and
Sig Ang: How can you fix it now, how could
00:37:44.810 --> 00:37:48.770
the Intel fix it or how can you secure
your own system?
00:37:48.770 --> 00:37:59.010
Maxim: It is not, it is just feature it is
not bug, sorry. You don't have any chance
00:37:59.010 --> 00:38:06.640
a chance to switch on JTAG for in ME if
you don't have UTAG or you don't have
00:38:06.640 --> 00:38:23.480
vulnerability. And JTAG for ME switch on
only inter BUP mode module - in inter-in
00:38:23.480 --> 00:38:31.130
BUP module. If we have vulnerability in
other module, for example in AMT, we
00:38:31.130 --> 00:38:46.260
mustn't do it. And if you have to try -
it's its feature, it is not bug. You can
00:38:46.260 --> 00:38:54.430
switch off the HECI flash descriptor and
to fix this side problem which we found in
00:38:54.430 --> 00:39:01.110
last year, and it will be ok.
00:39:01.110 --> 00:39:03.650
Herald: Microphone number four
in the back.
00:39:03.650 --> 00:39:07.500
Mic 4: I believe one of your previous
slides mentioned that they incorporated a
00:39:07.500 --> 00:39:12.120
Java Virtual Machine - why in god's earth
did they do that?
00:39:12.120 --> 00:39:30.190
Maxim: How I know; this it is DAL and it
has some relative with jeeks when I know.
00:39:30.190 --> 00:39:36.490
I didn't have details.
Herald: So microphone number five.
00:39:36.490 --> 00:39:44.850
Mic 5: The last slide mentioned the
extraction of platform keys. So a simple
00:39:44.850 --> 00:39:54.420
question - are they enough to sign a
firmware update which you would modify so
00:39:54.420 --> 00:40:04.820
that ME would accept it--
Maxim: No, sorry. Please repeat.
00:40:04.820 --> 00:40:16.370
Mic 5: Okay so let me rephrase
Maxim: I understand. You, okay, the
00:40:16.370 --> 00:40:27.120
firmware sign it by Intel public key. I
don't have private key of Intel and this
00:40:27.120 --> 00:40:36.120
key is not built-in into ME. It is
platform it is only platform key - this
00:40:36.120 --> 00:40:47.290
key for symmetric encryption files and
sign it files on the file system. If you
00:40:47.290 --> 00:40:56.480
have this key, you can only modify any
file system. But unfortunately the
00:40:56.480 --> 00:41:08.760
execution module start in in other places.
Mic 5: Okay, I get it so now is the path
00:41:08.760 --> 00:41:13.580
for castrating system from ME yet,
thank you.
00:41:13.580 --> 00:41:19.200
Herald: Signal angel?
Signal Angel: Can you have only free
00:41:19.200 --> 00:41:23.260
software running on the ME?
00:41:23.260 --> 00:41:26.980
Maxim: Sorry,
please repeat question, slowly.
00:41:26.980 --> 00:41:34.050
Signal Angel: Can you have only free
software running on the ME by modifying
00:41:34.050 --> 00:41:42.030
the flash contents?
Maxim: I don't understand, sorry. You mean
00:41:42.030 --> 00:41:51.330
that how how how we can modify the file
systems or not?
00:41:51.330 --> 00:41:56.280
Signal Angel: Yeah replace the ME firmware
with free code
00:41:56.280 --> 00:42:10.570
Maxim: No no, unfortunately because we we
mustn't to change the the chain between
00:42:10.570 --> 00:42:21.430
ROM and BUP module. And we mustn't to
change kernel of ME and BUP module. I
00:42:21.430 --> 00:42:32.890
don't now how use it functionality for
change in need to open source solution.
00:42:32.890 --> 00:42:41.980
But of course you can to do you can do
special device with detection finality
00:42:41.980 --> 00:42:50.440
which to replace after reboot all ME from
reset vector and executed. But it is some
00:42:50.440 --> 00:43:05.950
quirks, somehow some - impossible, I think
Herald: Microphone number two.
00:43:05.950 --> 00:43:11.940
Mic 2: Are you aware anywhere the MINIX
image has been leaked somewhere where
00:43:11.940 --> 00:43:14.870
perhaps it could be
downloaded and analyzed?
00:43:14.870 --> 00:43:23.120
Maxim: Unfortunately the kernel of ME only
00:43:23.120 --> 00:43:36.430
based on MINIX. And the Intel guys almost
all to rewrite all, almost all kernel. And
00:43:36.430 --> 00:43:44.200
on the reverse engineering. And maybe
indeed you can get information from Intel
00:43:44.200 --> 00:43:52.270
after signs NDA, I don't know.
Herald: Microphone number eight.
00:43:52.270 --> 00:43:58.190
Mic 8: Do you think it do you think it
would ever be possible to add your own
00:43:58.190 --> 00:44:02.330
public keys or are the Intel public keys
for signing the firmware
00:44:02.330 --> 00:44:04.930
stored in a ROM only?
00:44:04.930 --> 00:44:12.420
Maxim: I'm sorry, you mean..
Mic 8: Could you add your own public keys
00:44:12.420 --> 00:44:19.780
for signing firmware with, or is not
possible because the ME checks the public
00:44:19.780 --> 00:44:30.500
key.
Maxim: ME checks only hash of public key
00:44:30.500 --> 00:44:45.190
and we know that ROM has that in ME major
a lot version of any which signs on two
00:44:45.190 --> 00:45:07.710
keys. We saw only one keys front from bus.
And a ROM checked that check SHA from
00:45:07.710 --> 00:45:26.330
public key exist in whitelist. ROM has
hard-coded 8 hashes of keys and some lists
00:45:26.330 --> 00:45:39.540
for some white list of all these hashes.
And if you keys in this list you can run
00:45:39.540 --> 00:45:43.580
your ME firmware
00:45:43.580 --> 00:45:46.560
Mic 8: Okay but that
list of hashes is in ROM?
00:45:46.560 --> 00:45:49.230
Maxim: Yeah yeah.
Mic 8: Okay, thank you.
00:45:49.230 --> 00:45:53.570
Herald: Signal angel.
Signal Angel: What is your general
00:45:53.570 --> 00:46:01.070
impression of this security of ME - how
vulnerable is it to attacks?
00:46:01.070 --> 00:46:12.820
Maxim: Sorry, you mean how vulnerable you
mean have an ability to help us do it?
00:46:12.820 --> 00:46:15.380
Sorry.
Signal Angel: You know, how vulnerable is
00:46:15.380 --> 00:46:20.420
it to other attacks?
Maxim: On other module, yeah?
00:46:20.420 --> 00:46:26.500
Signal Angel: Sorry, on what?
Maxim: In other module.
00:46:26.500 --> 00:46:31.670
Herald: So I think the question is in
general how good is the security of the
00:46:31.670 --> 00:46:35.290
Intel ME?
Maxim: So sorry..
00:46:35.290 --> 00:46:42.570
Herald: In general, how good is the
security of the Intel ME, altogether?
00:46:42.570 --> 00:46:50.210
Maxim: I think it is because is
independent researcher can use it for
00:46:50.210 --> 00:46:57.570
dynamic analysis of any codes - it's it's
cool I I think.
00:46:57.570 --> 00:47:04.710
Herald: Microphone number seven.
Mic 7: Do you have plans to research some
00:47:04.710 --> 00:47:10.000
specific parts of the
Intel ME in the future?
00:47:10.000 --> 00:47:19.467
Maxim: Yeah of course. Intel will publish
00:47:19.467 --> 00:47:28.310
an ME 11 version and I know that they
changed Huffman tables for example. And
00:47:28.310 --> 00:47:38.150
the next the next round of this game will
start it.
00:47:38.150 --> 00:47:42.120
Herald: Is there another
question at microphone 7?
00:47:42.120 --> 00:47:51.730
Mic 7: So if I understood you correctly,
just to make sure, this means that you -
00:47:51.730 --> 00:48:00.270
if you have a CPU of this Skylake
architecture and a USB 3 port, you can
00:48:00.270 --> 00:48:06.560
always get low-level access to the ME.
Maxim: Exactly.
00:48:06.560 --> 00:48:12.440
Mic 7: So, if I were to own such a chip,
I would want that patched. What's the
00:48:12.440 --> 00:48:20.050
usual path? Does the patch come in a
Windows patch or a BIOS update or what is
00:48:20.050 --> 00:48:26.940
it?
Maxim: You have some some ways to use it.
00:48:26.940 --> 00:48:38.500
If you have a SPI programmer, you you can
rewrite flash. You mean how we can exploit
00:48:38.500 --> 00:48:45.280
it?
Mic 7: No, how does, sorry, how will Intel
00:48:45.280 --> 00:48:53.560
distribute a patch for this vulnerability?
Maxim: Oh, unfortunately because downgrade
00:48:53.560 --> 00:49:01.569
always possible. Intel punched only error
in BUP function.
00:49:01.569 --> 00:49:11.010
But researcher or attacker
can always to downgrade version or to
00:49:11.010 --> 00:49:17.390
earlier ME and exploit it without any
problem.
00:49:17.390 --> 00:49:27.480
We are is SPI controller or a SPI
programmer and maybe another way.
00:49:27.480 --> 00:49:32.090
Mic 7: Okay, thank you.
Herald: Microphone number one.
00:49:32.090 --> 00:49:37.330
Mic 1: In the demo with video, we saw the
connection between the two machines with
00:49:37.330 --> 00:49:43.960
this blue box, but I think there's another
one way to connect them with just a USB
00:49:43.960 --> 00:49:51.080
cable. Is there anything you can do with
the blue box that you can't do without it?
00:49:51.080 --> 00:49:59.690
Maxim: Yeah we checked it - we use only
USB3 debug cable. But it is not possible
00:49:59.690 --> 00:50:12.990
for us because we need to to recover the
state of work for loading in ME. I do it
00:50:12.990 --> 00:50:26.160
but I don't like that because I need to
stop execution for my research. It easy
00:50:26.160 --> 00:50:31.190
for me and because
we were using a blue box.
00:50:31.190 --> 00:50:32.580
Mic 1: Thank you.
00:50:32.580 --> 00:50:37.110
Herald: Signal angel.
Signal Angel: Do you plan to publish
00:50:37.110 --> 00:50:44.650
mask ROM dump in the future?
Maxim: Yeah, we will plan to do it, yeah.
00:50:44.650 --> 00:50:51.640
Herald: Signal angel again.
Signal Angel: Just give me a moment.
00:50:51.640 --> 00:51:01.800
Maxim: I didn't know, maybe when I
come back to Moscow.
00:51:01.800 --> 00:51:09.990
Herald: Any other burning questions?
Please come up to one of the numbered
00:51:09.990 --> 00:51:18.567
microphones. Then with that let's give
Maxim of great warm well applause-
00:51:18.567 --> 00:51:22.050
Maxim: Thank you much for your attention.
Herald: Thank you so much Maxim.
00:51:22.050 --> 00:51:25.028
Applause
00:51:25.028 --> 00:51:41.060
34c3 outro
00:51:41.060 --> 00:51:47.000
subtitles created by c3subtitles.de
in the year 2020. Join, and help us!