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