Hacking cars in the style of Stuxnet
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 29 | |
| Anzahl der Teile | 29 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/18858 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
Hacktivity 201529 / 29
1
4
6
17
00:00
Hill-DifferentialgleichungHackerMalwareImplementierungMessage-PassingProgrammierumgebungGruppenkeimSoftwareROM <Informatik>DebuggingMikrocontrollerp-BlockAuthentifikationElektronisches ForumEEPROMAnalysisHydrostatikTouchscreenE-MailStichprobeMusterspracheBenutzerfreundlichkeitCodeDatenstrukturFluidImplementierungInformationKryptologieMathematikMathematische LogikSoftwareSprachsyntheseTelekommunikationZeichenketteDeskriptive StatistikFunktion <Mathematik>ProgrammierungHackerHalbleiterspeicherModulare ProgrammierungTypentheorieDigitalisierungMikrocontrollerMAPBildschirmfensterSynchronisierungBenutzeroberflächeSoftwaretestDimensionsanalyseProgrammverifikationAutomatische IndexierungPhysikalischer EffektBeweistheorieBinärcodeBitDebuggingEEPROMForcingFunktionalGatewayGrundraumInhalt <Mathematik>InjektivitätKette <Mathematik>LastLokales MinimumMereologieMultiplikationPhysikalisches SystemPhysikalismusRechenschieberResultanteStichprobenumfangTabelleTreiber <Programm>ZahlenbereichZentrische StreckungE-MailDatenflussQuick-SortSystemaufrufKonfigurationsraumReelle ZahlBroadcastingverfahrenÄhnlichkeitsgeometrieExogene VariableTexteditorInternetworkingFontNichtlinearer OperatorParametersystemHypermediaProzess <Informatik>NormalvektorProgrammfehlerPerfekte GruppeZusammenhängender GraphRPCCoxeter-GruppeMetropolitan area networkInstantiierungElektronische UnterschriftComputersicherheitNummernsystemFormation <Mathematik>Gemeinsamer SpeicherAdditionPunktRouterNetzadressePolarkoordinatenSchnittmengeCAN-BusProtokoll <Datenverarbeitungssystem>Wort <Informatik>Lesen <Datenverarbeitung>ChiffrierungPersönliche IdentifikationsnummerKartesische KoordinatenQuelle <Physik>HilfesystemDisjunktion <Logik>Reverse EngineeringRichtungBimodulDateiformatVerkehrsinformationFlächentheorieKälteerzeugungSoundverarbeitungQuellcodePlastikkartePuffer <Netzplantechnik>SicherungskopieElektronische PublikationBootenEndliche ModelltheorieNP-hartes ProblemSchlüsselverwaltungDifferenteRechenbuchDrahtloses lokales NetzPatch <Software>Neuroinformatikp-BlockCheat <Computerspiel>MalwareHoaxVerdeckungsrechnungLoginDickeIdentifizierbarkeitCybersexFreewarePufferüberlaufSoftwareschwachstelleStandardabweichungSchreiben <Datenverarbeitung>Wurm <Informatik>Message-PassingKeller <Informatik>Interface <Schaltung>GamecontrollerYouTubeMechanismus-Design-TheoriePortscannerSoftwareentwicklerInternet der DingeAlgorithmusOrdnung <Mathematik>PerspektiveSpieltheorieCodierungEntscheidungsmodellProgrammbibliothekHydrostatikVideokonferenzFehlererkennungProgrammiergerätProgrammierumgebungFaserbündelHecke-OperatorVerknüpfungsgliedGrenzschichtablösungAggregatzustandArithmetisches MittelBildschirmmaskeGeradeGruppenoperationInverser LimesRechenwerkSpeicherabzugOvalGüte der AnpassungMatchingComputervirusWasserdampftafelRuhmasseCASE <Informatik>FehlermeldungVorhersagbarkeitDatenfeldVierSummierbarkeitExistenzsatzKovarianzfunktionEigentliche AbbildungEin-AusgabeInformationsspeicherungInstallation <Informatik>DifferenzkernStabilitätstheorie <Logik>GraphfärbungEuler-WinkelDigital Equipment CorporationGSM-Software-Management AGMeterBitrateMotion CapturingSichtenkonzeptAbgeschlossene MengeART-NetzSchreib-Lese-KopfMini-DiscTupelObjekt <Kategorie>Kontextbezogenes SystemMultiplikationsoperatorExploitURLProgram SlicingWald <Graphentheorie>Rechter WinkelOffice-PaketDemoszene <Programmierung>Figurierte ZahlTwitter <Softwareplattform>Lesezeichen <Internet>
Transkript: Englisch(automatisch erzeugt)
00:00
Good afternoon, everyone. And thanks for staying for this last talk. This is the end of the conference, and we really appreciate that you stayed with us and you are interested in our talk, even so that there is another talk in parallel in downstairs in the big hall, which also looks very interesting given by my colleague as well.
00:20
So it seems that the last two talks are, the last two slots were given to the crisis lab. So my name is Levente Buchen. My colleague is Andres Si, and we will give this talk together. So first, I will present some introductory slides, and then when we get to the technical details, Andres will take over.
00:40
And there is a third person who was also involved in this work, who is George Saloy. And we are all from the Budapest University of Technology and Economics. We, too, are from the crisis lab, and George is from the Department of Automobiles and Vehicle Manufacturing. And we will talk about hacking cars. And yesterday, someone asked me whether we
01:00
will bring a car on stage. And I told him that no, unfortunately not. And maybe this is disappointing for you, too. But hopefully, this is the only disappointing thing about this presentation. So why we don't bring a car to the stage? Because we are talking about hacking cars.
01:20
But in fact, as you will see, most of the work we did was mainly on hacking an application on a PC, a diagnostic PC, which had some bad effect on the car itself as well. But actually, the bulk of the work was really hacking the application on the PC. And that's what we mean, in fact, a Stuxnet-style attack.
01:45
But I will explain this later in more detail. So as you know, modern cars are full of embedded controllers, which are basically small computers inside the car, which control different things in the car,
02:02
like the airbag which was mentioned, but also the engine of the car or the ABS, the brake, and so on. And all these electronic control units, ECUs, are connected by internal networks, communication networks, for example, the CAN bus. In addition, the cars have different external interfaces,
02:24
like most of the modern cars might have a Bluetooth stack interface, where you can connect your hands-free set. Some cars have a Wi-Fi hotspot. Some cars have some GPS receiver or a GSM module.
02:40
Or some cars have some so-called wireless tire pressure monitoring systems, which are also present a wireless interface to the car. So if you put all these together, you have computers connected, and there are external interfaces. So there might be attacks. And cyber attacks against these modern cars
03:01
actually are plausible threat. So people started to consider that. And researchers started to work on that as early back in 2010, 2011. And one of the landmark papers, which have been published by a very well-known conference using security in 2011, it was written
03:22
by US-based researchers from well-known universities. And basically, in their paper, they show that cars can be compromised remotely. Very nice paper that goes through systematically over you the attack surface of a modern car. They identified three types of possible surfaces,
03:44
physical access to the car, basically via the OBD interface, short-range wireless access, such as Bluetooth interface or Wi-Fi, and long-range wireless access, for example, a cellular interface.
04:00
So they systematically overviewed these interfaces. And they developed practical attacks, proof-of-concept attacks, against each of these interfaces. So for instance, one of the attacks that they developed was exploiting a vulnerability in the media player of the car. There is a software there which
04:21
parses the media file, which is played. And there was a bug in that buffer overflow vulnerability. So they were able to construct a specially crafted music song file, which they put on a CD. They put the CD in the media player. And when the media player played the CD,
04:41
basically, the bug was exploited in the software. And they took over control over the media player. They also demonstrated exploitable vulnerabilities in the Bluetooth stack of the car that they investigated. Or one of the attacks that they constructed
05:01
was basically exploiting a bug in the GSM module. So they were able to call the car from a remote location, calling the normal telephone number of the car. And they played a specially crafted audio, again, which exploited the bug and loaded additional software
05:22
modules on that GSM module. And it was compromised. And once these modules are compromised, then you are already inside the car. And on the CAN bus, there's basically no more protection, usually. So from one compromised ECU, you can jump to the next one. And essentially, you can take over the whole car.
05:41
That's their work. That's what they have shown. And after that, there were some follow-up work. So one of the very well-known researchers who worked on that was Charlie Miller with his colleague, Chris Wallasek. And basically, their idea was to repeat the research that was done by these US-based researchers I
06:01
just mentioned, because these guys, these academic guys, they did not publish all the details of the attacks that they did for good reasons. But Charlie Miller and his friend had the idea of repeating all the stuff that was done and publish everything. So basically, they come out with a report that contains a very detailed description of what they did
06:23
and all the tools that they used. And in fact, some of you might remember that Charlie Miller gave a talk here at Hacktivity two years ago about this work. So we had already a car hacking presentation two years ago at Hacktivity, which is actually on YouTube.
06:42
So you can watch it. And they continued the work. And a very recent result, you might have heard about that in June or July this year, there was some news that hackers remotely kill the Jeep on the highway. And this was also the work of Charlie Miller and his friend,
07:01
very recent. Basically, they exploited some vulnerability in a Wi-Fi hotspot on this modern Jeep. So they could remotely connect via the internet because the Jeep had a public IP address. They remotely connected and exploited some vulnerability in the hotspot software and remotely took over the control of the car.
07:23
And there are other examples. So if you look at the literature, there is an example of infecting a car via the FM radio broadcast or via the tire or a dimension wireless tire pressure monitoring system or some attacks on relaying communication between the key,
07:41
the wireless key of the car and the car and so on. And all those are remote attacks. So basically, they mean that you compromise the car remotely, not being physically present or close to the car or in the car. And they are, in fact, very intriguing and scary, we agree with that.
08:00
And they can attract, of course, a lot of media attention because it's always a good topic for a news that you took over a Jeep on the highway remotely. But the real risk, in our opinion, is quite unclear. What we mean by this is that it is not so easy to do those kind of remote attacks, in fact.
08:21
So they need, first of all, an exploitable vulnerability in some of the interfaces or in one of the interfaces of the car. And there might be such a vulnerability, but it's not so easy to find such a vulnerability. So finding those vulnerabilities which are really exploitable, this is far from trivial.
08:41
It needs reverse engineering embedded software, which is difficult. There is very little information available about these embedded ECUs because the car manufacturers typically don't share too much. So very limited information from which you can start. And there is a risk of breaking
09:01
relatively expensive equipment. So when you experiment, try to exploit a buffer overflow, you might actually render the device unusable. And you have to throw away and buy a new one. And this can be expensive. So it's not easy. And it may not scale very well
09:20
because a vulnerability in one of the interfaces, in one of the car brands might not be there in another car brand in the same interface or other interfaces. So basically, with just one vulnerability, you can maybe compromise one type of car and not the others.
09:40
So that's what we mean by not scalable. And the question we posed, is there maybe some fluids that are hanging lower, so easier to do than these kind of remote attacks? And that's what we mean by this Stuxnet-style attack. So how Stuxnet work? Basically, most of you should probably know about this.
10:04
And yesterday, we had a wonderful talk on attacking chemical plants. And the speaker there explained, in fact, what we showed a video, in fact, about how Stuxnet works. So you probably know. But the idea, just to repeat the main point, is that Stuxnet was a worm attacking PCs, first of all,
10:26
and then modified the PLC that controlled the uranium centrifuges. But if you look at what Stuxnet is, it's really basically a worm against Windows-based PCs. So the idea was that you first infect a PC and took over the communication between that PC and the PLC.
10:43
And then, once you have that, once you control the communication, then you can modify the PLC, some parameters, or even override some of the programs, and then that has some effect on the control system. And as I said, they exploited weaknesses in Windows,
11:06
and the way they took over the communication was basically just replacing the DLL, which was responsible for the communication between a SCADA software used to manage the PLC and the PLC. So this whole stuff, actually,
11:20
it's kind of a blueprint for similar attacks against similar type of systems. So if you have embedded systems, typically they are managed from PCs. And so basically, that's our idea, to repeat exactly the same kind of logic for cars. So you have some PC, which is a diagnostic PC
11:40
used in garages or repair shops, running some software, which somehow communicates with the car, for instance, via the OBD interface. And then, if we inflect that PC, that PC might change values or override things within the car, and that causes problems to the car.
12:02
So that's the logic of our work. So why is this worrisome? Because PCs in repair shops and garages are probably vulnerable. Probably they are connected to the internet, very likely. They allow also connecting USB devices, and mechanics probably connect all kinds of USB devices
12:21
to those PCs. And they are probably poorly maintained and unministered, because that's not their main job there, the guys there, to maintain their PC. And probably they are also used for other purposes, not just running the diagnostic software. So if you put all this together, it's relatively easy, we believe, to infect them with known or unknown malware.
12:44
And once the malware infected the PC, then the malware can compromise the diagnostic application running on the PC, and then implement stealthy functionality. For example, and this is also what we were aiming for, we can implement a man-in-the-middle attack
13:00
between the diagnostic software and the car. And then we have almost direct access to the car, via the OBD interface. And this only needs standard, standard in quotes, of course, reverse engineering of PC-based software, not very special knowledge about embedded systems.
13:21
And we also believe this scales better than remote attacks, because the same software is usually used to do diagnostic work on multiple types of cars, multiple brands. And every car is taken to the garage at least once a year, or regularly. So any car could be infected in this way.
13:44
So for a proof of concept, we decided to demonstrate that it is indeed easy to do in practice. So in our test environment, we had access to an ODTT, because that's a test car that the Budapest University of Technology and Economics
14:00
is using for teaching vehicle engineers. And we have had access to that car for some time. And so we have chosen a widely used third-party diagnostic software, which basically is compatible with this car, or for all the cars in the Volkswagen Group.
14:21
And we tried to make modifications in this diagnostic application to allow for man-in-the-middle attacks between the application and the car, which allows us eavesdropping or modifying messages on the fly. We make the assumption that the PC is already infected by malware, so we did not write a malware for this work.
14:43
But actually the parallel presentation in the room downstairs is about a malware type of sample that we wrote for bypassing different security protection mechanisms. But this work was not about writing a malware. We assume the malware is there, it infected the PC,
15:02
and the malware can carry out all the modifications on the applications that we do, because we basically do very basic modifications. Okay, so the outline of the rest of the talk will be that we will present you a little bit more detail about the system,
15:20
which we investigated. Some of the protection mechanisms that we discovered that the application developer put in the application, but as you will see, they were not so effective. They did not prevent us to understand and reverse engineer the application and the protocols.
15:43
And then we will go into the details of the techniques, so we will show you how we replaced one of the DLLs of this application. So we do a very similar kind of attack that Stuxnet did. A DLL which is responsible for the communication between the application and the car, or the diagnostic cable.
16:02
So how we did this replacement. Then we explain you how we reverse engineer the protocol, because there is a proprietary protocol between the application and the diagnostic cable. And we had to understand the message formats. There's also a checksum computation. We had to figure out how it works, because when we modify messages,
16:21
we have to recompute the checksums. And there is some encryption scheme involved as well, so messages are encrypted in a certain way, and we had to figure out how this encryption works. And once we did all this, then we can then implement a man-in-the-middle attack,
16:41
and Andres will explain how we did logging and replaying sessions, and how we modify messages on the fly. And then we will mention some of the experiments, the real experiments we did, including this switching of the airbag, and we'll come to the conclusion and some outlook.
17:00
Okay, so let's start with the system model. So we have a diagnostic PC, we have a vehicle, and they are connected with a special so-called diagnostic cable. On the PC, we have a software stack. We have this diagnostic application running. The diagnostic application, in fact, is the component which holds the necessary keys,
17:22
and the protocol implementations for communicating with the cable and the car. And it implements certain diagnostic functions, which basically means that it reads and sets values inside the car in the selected ECU. And the communication,
17:41
so the software uses a number of DLLs, and one of those DLLs is a DLL which is responsible for the communication between the diagnostic software and the cable and the car. And, of course, at the lower level, there are drivers which implement all the low-level communication functions.
18:00
We have this cable, which is, in fact, not a simple connector, but inside the cable, there is a microcontroller, so there is a small PCB with a microcontroller and other components. And this microcontroller basically functions as a gateway. So the application, in fact,
18:21
the application communicates with the cable. And this gateway, the microcontroller in the cable, then translates the messages and sends them or relays them to the OBD interface of the car. So we had to work on this communication between the application and this gateway, in fact,
18:44
to modify and absorb messages. And we have then on the car the OBD. OBD, in fact, stands for Onboard Diagnostic, and most modern cars has this. It's a mandatory interface that car manufacturers put in the car for diagnostic purposes, to do diagnostic work on the car.
19:02
And behind the OBD, then, there is the CAN bus which is connecting the different ECUs, and essentially, while OBD is not equal to CAN, but essentially when you have access to the OBD interface, you have almost direct access to the CAN and you can send messages to the ECUs inside the car.
19:21
So the application developers try to put some protection mechanisms in the application to prevent reverse engineering and hacking the application. So one of those is signing the DLLs that they use. All DLLs loaded by the application are digitally signed, but for some reason,
19:40
they did not really check those signatures. So in fact, this looks like an ineffective protection, or maybe they check, but we did not find where they check it. They might check it somewhere silently or we don't know, but in fact, we could replace one of the DLLs, so they probably don't check. There is some program obfuscation.
20:02
So in the usual stuff, they try to hide the functionality of the program by obfuscating the code with some common methods. However, when the application is started, it de-obfuscates itself in memory. So if you attach to the running application
20:21
with a debugger, you attach a debugger to the already running application, then you can in fact investigate the memory and understand how the application works. Of course, you only see the binary, but that's why we have Andrzej who can read the binary, and he understands how the application works.
20:40
And there is some license verification, so you cannot use any kind of cable. The application checks that the cable is genuinely original, but there are fake copies that you can buy, and actually, that's what we did. So on Amazon, I think it was $15, so we bought this Chinese copy of a genuine cable,
21:03
and it worked. So the Chinese somehow managed also to get the license information and put in the gateway or in the EEPROM of the chip. So we did not have to reverse the license verification mechanism.
21:21
And then we wanted to do this man in the middle, so our goal was to really develop some component which can do eavesropping, can replay messages or inject fake messages. And one natural idea was to somehow modify the DLL which is responsible for the communication between the application and the card.
21:42
So we could, for instance, take the binary because the source code is not available, of course, and somehow patch the binary with all the functions that we need. But in fact, it looked even simpler to introduce another fake DLL, load that fake DLL, and then that fake DLL would load the original one,
22:03
and we use just the functions of the original DLL for communication. But since our fake DLL is loaded before, we get all the calls before, and we can do all sorts of modification before we pass the control to the original DLL. So that's exactly the idea that we implemented.
22:22
And now I take, I give the floor to András who will then give you all the details about the technical part of the attack. Thank you, Levente. Oh, let's see what we've got. Hi, I'm Andrew.
22:40
You may know that usually Windows loader loads an application to the memory and after walks through its import table and gathers the necessary shared libraries, DLLs, et cetera, and loads them to the memory too. So in this case, Windows loader loads our fake DLL
23:02
named as the original DLL. After it loads the DLLs, calls their entry point before passing the control to the original application. So our DLL gets the control and extracts the original DLL to the hard drive,
23:21
and then reloads back it again. So there you can see a chain. When an application calls a read or write function, then we could simply make many in the middle attack and then redirect the call to the original function
23:42
of the original FTD or DLL. And when the call returns, we have the control again and we can return back to the original application. How could we improve our protection? There are some tips. Firstly, you have to check, you have to take care of your third party components
24:03
to not just for your own components. So we have to check FTD, DLL, Windows DLLs maybe, and data files that are placed in your program, that your program loads. So you have to perform digital signature checks
24:22
and CRC checks before loading anything and after loading anything. And you should do this periodically during the program runs and should integrate some or all of these checks to many of your calculations.
24:41
Like when you are sending a request to disable the airbag, there you should place some empty holes in the message that will be replaced after the calculations of the protection of the CRC or digital signature checks. And of course, you should use proper cryptography algorithms,
25:03
not just simple XOR algorithms, as you will see. To reverse engineer this application, we used, of course, our fake FTD DLL. This DLL contains exports name liked in the original FTD DLL. Some of them we redirect some of them,
25:23
but some of them we modified to make, to add further functionality. For example, FT read and FT write, we modified them. And there we can capture or modify the communication when the application calls us. Of course, we used favorite old debugger
25:43
to reverse the diagnostic application, cheat engine for memory scanning, and freeware Ajax, the X editor to viewing captured data and some handy tools for filtering that data. Usually, here you can see a usual message.
26:04
The header consists of three bytes. The first byte means the message direction. Now, this means the message goes to the cable, so send it by the original diagnostic application and goes to the cable. And of course, 4D means the application
26:21
gets the message and the cable answers. After that, you can see size block, size byte. Defines the size of this whole message, including checksum. And after then, the type of the message.
26:41
In this case, it's a request message. And of course, B7, as you can see, is a response. Now, after that, you can see the data block. The force, some of the force byte, force first bytes are kind of target identifiers.
27:03
After that, there is a data length identifier followed by a sync byte. That sync byte comes from the original application cause the developers leave it in the application as a simple C string. So, we named like this because they named like this.
27:25
After then, you can see the actual data block that will the identifier target receive. We discovered these checksums are, to compute these checksums isn't too hard.
27:42
So, you can just simply XOR all of the bytes of the message and you will get the checksum. Here, you can see a simple acknowledgement message. This usually comes from the cable and that means the cable has done successfully
28:01
an operation, for example. Of course, is a type identifier that this is an acknowledgement message. Here is a key message used to initialize the encryption session.
28:20
B6 means this is a key type of message. The key message consists of bytes. These bytes are indexes to a static table that the diagnostic application and the cable both have. And this table, this static table, consists of randomly generated bytes.
28:44
And you also use XORs to perform the encryption. You can see in this example, you get the XOR mask from the table with the help of the key.
29:00
And you just simply XOR it with the original message. And you will get the encrypted result. And of course, then after then, you have to recompute the checksum. Here is the table, as I said. This is a static table.
29:21
And of course, there are the key values. And you can gather, these are indexes and you can get the real XOR max bytes from the table. As the following. Okay. When the application calls our FT write function,
29:43
we of course make a backup of the buffer contained in this function call. And then we can redirect the call to the original DLL. So that's how we make the logging. And of course, when the application calls
30:01
the reads function, that we redirect the reads. And then when the original function returns, we can save the buffer. We can save the answer. And can return to the application. Before any kind of diagnostic operation,
30:20
the cable needs to be initialized or tested. The cable, during this initialization, the cable can examize the capabilities of the car and the cable too. Sorry, the software. Examize the capabilities of the car and the cable.
30:41
Speed limits, license, et cetera. And store in temporary files. It stores in temporary files. Usually these tests are run before any bigger operation blocks. Okay. And you can see here, the software checks the license. And if you want to perform a license check,
31:04
you have to connect the OBD2 connector to the car. But you can bypass this protection with connecting 12 voltage to ODB2 connector. Pin 16, four plus, and pin four, four minus.
31:23
And that will work. Here's an example of a log we made. This log contains the requests and the responses. Here you can see the headers. Yes. And of course, the logging we made of.
31:43
I said the initialization. It's called in the diagnostic software as port test. We perform port test, auto scans when the software and of course the cable scans all of the ECUs in the car and of course the airbag control module
32:02
and ABS brakes, ABS brake. And the last one is failed because may of the application less functionality or the cable less functionality. We didn't know that. And an example for a replaying session.
32:22
These are messages only to write out. So we have a replayer tool and we replay these messages out. Here you can see bonus bytes. These bytes that you have to send out before any kind of operation. This is a kind of cable initializing operation by bytes.
32:47
Or replay tool is a separate process. So it is invisible for the diagnostic application. And if we or if someone want to perform FT write,
33:03
FT write, of course by using FTD IDLL because our replay tool also uses the original FTD IDLL to perform write and read operations. You have to call these functions with the correct parameters before any kind of writing or reading operation.
33:22
And there are some hints that you have to wait after any sent out message. So you have to write delayed. Delayed to the cable and we'll be perfect. Of course the joker byte that you have to send before anything.
33:42
And yes, we could easily replay the airbag speech of the internal messages because there is no need to change anything, encoding or data structure or anything. You just replay what we recorded. So that were a simple process.
34:01
And as I said, this replay tool is a separate application so it is invisible to the diagnostic application. And yes, our fake FTD IDLL can modify, also modify the communication. As you can see here, the application
34:23
sends the messages in byte after byte style. So performs FTD write on each byte of the message. Yes, and here's an example for this. It is sample we want to match and that we want to replace for original message.
34:45
There we can find the match and from the last byte of the match, we can modify the data flow and copy the others. And of course, we calculate the checksum.
35:02
And I give the word back to Valente and thank you. So these were the technical details of how we can log entire sessions, how we can replay messages from a separate application invisibly to the diagnostic application.
35:21
And very importantly, how we can modify messages on the fly, as you saw in the last example. It was our man in the middle tool running in the fake DLL and can change anything in a message which was sent out by the application or received from the cable.
35:41
And with all these tools equipped, then we made some experiments and this is just to show you some of the pictures and some of these things that we did. So here is this ODTT in the garage of the university and this is Andres sitting here and having fun.
36:02
All these experiments were carried out during spring 2015. And so this slide shows you that the diagnostic application itself produces some log files, simple text-based log files. And we just wanted to check whether we also see the same content
36:23
in our own special log files that we make with the man in the middle tool. And so here is the original log, here is some parts of the logs that we made and certain things you see, so these values show up in our logs. So this was just a check of a full scan.
36:43
And the replay of the airbag enable-disable message, as Andres explained, it was just a very easy replay of previously recorded messages. So these messages, in fact, differ only in these two bytes The sync byte is also different, but it is not really check
37:01
or we don't really know what it is, what's the purpose of that sync byte. So this replay worked perfectly. An earlier recorded message with that earlier sync byte could have been, so it was able to replay it back successfully. And all the replays that we were experimenting with
37:23
were successful. So, conclusion. So, as we try to explain, cyber attacks on modern vehicles is a plausible threat, but research has started to focus more on remote attacks
37:44
and we argued that there are easier ways. And that's what we mean by a Stuxnet-style attack where you don't really need to have very special knowledge about cars and internal components of the cars, but you basically hack applications on normal PCs.
38:01
And we believe it has a much higher risk because it's easier to do and maybe more scalable and so on. And the proof of concept that we made is just simply replaying an airbag enable or disable message which doesn't look like very, you know, what's the hack?
38:20
So why is it interesting? But this is just a proof of concept. So as we said, we have a man-in-the-middle tool which means that you can modify anything you want, including maybe firmware update messages. And another interesting thing is that you can also modify responses from the cable. So you can hide from the diagnostic application
38:41
if a value is set in a certain way because when that value is read from the car, then you modify the response from the cable showing a different value. So in this case, we just replayed back an airbag speech-off message. Now the mechanics come with the diagnostic software
39:02
and tries to read this setting out from the car and we can modify that setting that it still shows that it's switched on. So the airbag remains switched off and the diagnostic application gets fake information because of the man-in-the-middle attack that we perform.
39:22
And that can be, of course, serious, right? Because if you can switch off the airbags of thousands of cars and it's not visible to anyone, then anytime when any of those cars have some accident, then it might have some serious consequences, of course. And as I said, you can also do maybe other things, not just switching off the airbag.
39:43
So a very small outlook to the future. VR, this is a new buzzword, an internet of things. These are basically embedded devices connected via the internet. And if you connect these devices via the internet,
40:01
then you, of course, create more risk. So, but the point is that what we showed is valid also for these embedded devices of the future. So basically you manage those devices from PCs. You all know that when you configure your Wi-Fi router, you connect your PC and you configure your router from the PC.
40:21
Or when you, I don't know, later in the future, you configure your refrigerator or whatever, you probably will not have a pretty user interface to configure, but you will use a PC and you will connect to the refrigerator and configure that with the PC. So this whole logic what we are advocating here
40:42
would work. So one could infect the PC and from the PC, all those embedded devices. And what is maybe more scaring, at least to me, and I would like to just bring this up as a kind of a discussion topic. And what if then after some point
41:00
the infection disappears from the PC? The malware actually deletes itself, for instance. Then how you will then detect that all those embedded devices are infected already? And I don't have a good solution for that.
41:21
So I, as I said, just bring it up as a question. What can we really do about this? How we can really secure the internet of things? Then you have still vulnerable PCs which are used to modify or manage those devices. Thank you for your attention.