Hardware Hacking Village - Another Car Hacking Approach
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.
Lafois, Benjamin N. N.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 335 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: 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/48878 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 27324 / 335
8
9
12
14
32
38
41
58
60
61
72
75
83
87
92
96
108
115
128
132
143
152
158
159
191
193
218
230
268
271
273
276
278
295
310
320
321
335
00:00
FacebookComputerMultiplikationsoperatorSystemprogrammierungCodeGeradeThreadDifferenteNotepad-ComputerZahlenbereichPlastikkarteAggregatzustandComputersicherheitAutonomic ComputingInformationGamecontrollerInformation RetrievalBitRechenwerkFunktionalTouchscreenInfotainmentOrdnung <Mathematik>DatensatzMAPProzess <Informatik>MultiplikationInternetworkingKomplex <Algebra>HardwareSoftwareSoftwaretestÜberlastkontrolleHilfesystemPunktVorlesung/Konferenz
03:08
MultiplikationsoperatorDifferenteEinfache GenauigkeitMobiles InternetSystemprogrammierungDrahtloses lokales NetzTelekommunikationVorlesung/Konferenz
03:48
SystemprogrammierungProzess <Informatik>SoftwareMultiplikationsoperatorMultiplikationGeradeRechenwerkInfotainmentInternetworkingInformationURLTouchscreenMAPCASE <Informatik>TelekommunikationEinfache GenauigkeitBitDifferenteFunktionalQuaderKonfiguration <Informatik>BetriebssystemProgrammfehlerSystemplattformBus <Informatik>BildschirmfensterHardwareKommunikationsprotokollCodierungMereologieARM <Computerarchitektur>Einfach zusammenhängender RaumSystem-on-ChipHyperbelverfahrenSchreib-Lese-KopfUmwandlungsenthalpieEinbettung <Mathematik>Vorlesung/Konferenz
07:36
BetriebssystemOrtsoperatorInformationPersönliche IdentifikationsnummerFlash-SpeicherKomplex <Algebra>Prozess <Informatik>ComputerarchitekturSoftwareentwicklerMikrokernelOpen SourceSoftwareKette <Mathematik>Vorlesung/Konferenz
08:52
MultiplikationsoperatorSystemstartDateiverwaltungTreiber <Programm>SoftwareentwicklerOrdnung <Mathematik>Einfacher RingKernel <Informatik>Elektronische PublikationBildgebendes VerfahrenPartitionsfunktionLastUmwandlungsenthalpieDifferenteMinkowski-MetrikHackerBenutzeroberflächeBitEinfache GenauigkeitOpen SourceMikrokernelPlotterUltraviolett-PhotoelektronenspektroskopieSampler <Musikinstrument>GeradeVorlesung/Konferenz
11:30
AdditionBildgebendes VerfahrenSystemstartBildschirmfensterComputersicherheitHardwareCASE <Informatik>MAPDateiverwaltungElektronische UnterschriftMinkowski-MetrikKernel <Informatik>BitPunktProgrammierungLastDifferenteFlash-SpeicherVersionsverwaltungComputerspielSystemprogrammierungPartitionsfunktionFirmwareProzess <Informatik>Vorlesung/Konferenz
13:52
SpielkonsoleHardwareEPROMService PackZeichenketteEinfach zusammenhängender RaumMAPFlash-SpeicherMinkowski-MetrikVektorraumPunktFirmwareKartesische KoordinatenDifferenteInterface <Schaltung>Offene MengeSoftwareFlächeninhaltSoftwaretestInteraktives FernsehenFreier LadungsträgerRechter WinkelAnalysisE-MailMereologieGraphfärbungComputervirusVorlesung/Konferenz
16:14
Ordnung <Mathematik>BitWiederherstellung <Informatik>EmulatorCAN-BusEigentliche AbbildungKommunikationsprotokollStandardabweichungPunktInterface <Schaltung>Nichtlinearer OperatorDifferenteMultiplikationsoperatorMixed RealityBus <Informatik>Vorlesung/Konferenz
17:44
CAN-BusRastertunnelmikroskopSystemplattformHardwareHalbleiterspeicherBitLesezeichen <Internet>InformationBus <Informatik>Vorlesung/Konferenz
19:00
ComputerarchitekturInformationProgrammierumgebungCASE <Informatik>StandardabweichungCAN-BusVorlesung/Konferenz
19:36
InternetworkingSimulationKonfigurationsraumEinfach zusammenhängender RaumTreiber <Programm>Ordnung <Mathematik>Nichtlinearer OperatorCAN-BusTelekommunikationProgrammierumgebungGefrierenEmulatorKartesische KoordinatenGemeinsamer SpeicherVorlesung/Konferenz
20:28
Direkte numerische SimulationLesezeichen <Internet>TabellePunktNetzadresseKartesische KoordinatenStandardabweichungVerdeckungsrechnungBitVorlesung/Konferenz
21:18
Automatische HandlungsplanungSoftwareEinfach zusammenhängender RaumFlächeninhaltUmwandlungsenthalpieInternetworkingCoxeter-GruppeOrdnung <Mathematik>ModallogikNichtlinearer OperatorSoftwareschwachstelleComputerspielVorlesung/Konferenz
22:34
Einfach zusammenhängender RaumWinkelProzess <Informatik>InformationsspeicherungApp <Programm>LimesmengeKartesische KoordinatenFirmwareFirewallSoftwareTelnetSoftwaretestBitTelekommunikationSoftware Development KitBus <Informatik>SoftwareschwachstelleEin-AusgabeInternetworkingElektronische UnterschriftPasswortHumanoider RoboterBenutzerbeteiligungHyperbelverfahrenInhalt <Mathematik>Vorlesung/Konferenz
24:04
PackprogrammAppletDigitales ZertifikatBildschirmsymbolAssemblerSoftwareBitNichtlinearer OperatorMessage-PassingByte-CodeLeistung <Physik>MultiplikationsoperatorLaufzeitfehlerLesezeichen <Internet>Elektronische PublikationURLLastGamecontrollerChiffrierungCodeVirtuelle MaschineDifferenteDateiverwaltungElektronische UnterschriftSystemprogrammierungSpieltheorieNormaler OperatorImplementierungWurm <Informatik>ServerOnline-KatalogKartesische KoordinatenMAPApp <Programm>VirtualisierungPublic-Key-KryptosystemQuellcodeInhalt <Mathematik>IntegralMalwareClientDatenflussBildverstehenGeradeZahlenbereichFreewareGrundsätze ordnungsmäßiger DatenverarbeitungNormalvektorVersionsverwaltungLaufzeitsystemVerschlingungNabel <Mathematik>Mathematische LogikStandardabweichungProzess <Informatik>Vorzeichen <Mathematik>PolygonzugSkriptspracheInformationsspeicherungVerzeichnisdienstComputerVerkehrsinformationProgrammierungWellenpaketAnalysisProgrammbibliothekGüte der AnpassungOpen SourceSchreiben <Datenverarbeitung>SoftwaretestFront-End <Software>Lesen <Datenverarbeitung>Vorlesung/Konferenz
32:39
Nabel <Mathematik>TelnetSystemstartGeometrische FrustrationService providerDämon <Informatik>SkriptspracheLeistung <Physik>BildschirmfensterMultiplikationsoperatorSpielkonsoleFaktor <Algebra>Persönliche IdentifikationsnummerInhalt <Mathematik>Mathematische LogikKontrollstrukturProgrammverifikationDatenfeldObjekt <Kategorie>MehrplatzsystemWhiteboardFunktion <Mathematik>DickeCompilerPasswortHardwareZahlenbereichKonfiguration <Informatik>QuaderBitDienst <Informatik>VersionsverwaltungAdressraumMereologieHumanoider RoboterCodeKernel <Informatik>SystemprogrammierungSoftwareAuthentifikationBus <Informatik>SoftwarearchitekturRPCKonditionszahlBootenMinkowski-MetrikPartitionsfunktionProfil <Aerodynamik>ExploitPhasenumwandlungGrenzschichtablösungBildschirmmaskeBenutzeroberflächeBildgebendes VerfahrenMalwareDatenverwaltungATMEinfach zusammenhängender RaumBenutzerbeteiligungTreiber <Programm>Interaktives FernsehenSoftwareentwicklerWarteschlangeDifferenteWurzel <Mathematik>LoginBefehlsprozessorTUNIS <Programm>Rhombus <Mathematik>QuellcodeVorhersagbarkeitE-MailDistributionenraumEreignishorizontSchlüsselverwaltungLogikanalysatorGatewayExogene VariableComputersicherheitSprachsyntheseFlash-SpeicherAbschattungWorkstation <Musikinstrument>Elektronische PublikationSpezifisches VolumenHalbleiterspeicherKommunikationsprotokollKartesische KoordinatenPhysikalismusCAN-BusARM <Computerarchitektur>Deskriptive StatistikLesen <Datenverarbeitung>StandardabweichungLesezeichen <Internet>Eigentliche AbbildungProdukt <Mathematik>Schreiben <Datenverarbeitung>ProgrammierungVorlesung/Konferenz
41:14
VersionsverwaltungBitComputerGüte der AnpassungHardwareSystemprogrammierungNebenbedingungArithmetische FolgeAdressraumWeb SiteATMSystemaufrufLoginHackerAuthentifikationSpielkonsoleService providerNichtlinearer OperatorZahlenbereichQuellcodeProgrammierungMehrplatzsystemFirmwareInformationSoftwareBetriebssystemComputersicherheitUmwandlungsenthalpieSoftwareschwachstelleTreiber <Programm>SystemstartÜbersetzer <Informatik>Vorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
00:00
So, we are Ben and Vladan from IBM X4 Thread and we are involved in a lot of stuff, but we like to hack hardware, software, and especially if something has a wheels and it's moving, it is interesting target for us. So, we spend a lot of time actually working with vehicle security testing, and today we are here to share a little
00:22
bit of stuff that we encounter through the years with you. So, what we are going to cover today is about hacking car infotainment system and how far we can actually go with it. So, where are the dangers and what is the approach that we have discovered which is different than everybody else is using. So, why it is
00:45
important? So, unfortunately cars are becoming a lot more, cars are becoming a lot more complex than they were before. So, this screen we can see different number of lines of code that are used to develop specific systems and we see that Facebook is something about 6.7 million lines of code, Boeing
01:06
787 is a 7 million and we have Ford F150 at 150 million lines of code including all systems in the car. So, current modern car can have more than 200 kilos of just electronic and wires in it. So, you will find like 100
01:26
different smart computing units, I'm not saying computer because they are of different level, but smart computer units which control specific functions from your entertainment system, from your convenience systems until the suspension, motor ignition and everything else. So, cars become a really
01:44
complex multi-computer systems which are all connected and they becoming more and more connected and exposed even to the internet. So, we all like our entertainment system because it gives us constant access to everything. So, we have, we can watch movies while we stand fortunately, we can gain information
02:04
from the internet, we can retrieve data from systems about road, state situation on road, if there are congestion, non-congestion, we can do a lot of stuff. So, it needs to be complex in order to support all of this. What is
02:20
infotainment system? It is a not so simple thing that we can think, what we see in our car is just a small screen which is presented to us and we interact with this screen by touching it, moving it, abusing it to different ways, spilling our coffee on it, but it is just what is exposed so we can actually see. What is behind it is usually much, much more complex than it. So, it can
02:43
contain different features, radio, Bluetooth, control cameras inside, outside recording, in autonomous car, it can have even more stuff. So, if you have lane assist, it can, it is used to do this lane assist. So, cameras will be
03:01
picking up the data, send it to your infotainment system and it will do processing and help you stay out of the lines. So, to keep you straight on. So, there is a lot of stuff that is integrated, that is connected. We see a lot of radio communication, so your, for example, your tire pressure monitoring system, it is all wireless, you can have Bluetooth, you
03:25
can have Wi-Fi, you can have a lot of different technology and car is becoming actually like mobile phone on the wheels. So, that's unfortunate because we know how bad we are surviving our mobiles. They take all of the time, we are looking at them all the time and we can hit stuff while we
03:43
are walking. Imagine that happening while you are driving, not the best situation for sure. So, as I mentioned, what we see is just a single head unit usually which is displaying all information, but behind it we have a plethora of different systems which are used to collect this information and
04:02
to process and in the end to present it to us. So, in specific case that we are mostly discussing today, we saw that it is multi-system which has multiple different boxes which are dedicated to different things. Some functionality can overlap between different boxes because, for example, in
04:24
a one-car manufacturer you can have one level which is basic or you can buy another option which is advanced functionalities or third one which are superb functionalities and all offer something that might be better than the previous box and all them together are connected and communicate within each
04:42
other. So, they collect information about your car, about the way you are driving, about your location and even maybe some of your personal information which we are going to show a little bit later. Problem with this is we have a lot of software, as I mentioned, 150 millions line of codes. Do you think it is bug free? No. And problem is that updating car is much more difficult than
05:07
updating your mobile or Windows operating system or Linux or whatever operating system you are using. So, this is a part of the problem. So, manufacturers make it very difficult for you to change your car computer
05:21
software embedded. It's a little bit easier to update your infotainment system but it might be even not done because customers are not used to it. You need to go on the line to log in with some specific credentials that should be provided to you by your vendor. I hope they are not providing it free for all so you can just download, update on the Internet. We saw even that
05:42
happens. So, it can be really dangerous and long-standing process which might not be done in time. So, you might be exposed. In worst case, manufacturer need to recall the cars so they can update them and change the software in case of serious problems. So, as I mentioned, in head unit,
06:05
we have some basic functionalities and we have another box which is hidden behind the dashboard which provides additional features. It might be connectivity, it might be better FM receiver with more functions. It can be GPS receiver
06:22
for navigation. And all these boxes are connected to each other with their own bus. So, they are using their own bus to connect to each other to exchange information because in the end, you always see the basic device screen. So, there is only one device which has screen. Other device when connected
06:42
to it will communicate and take over the screen from the base device, from navigation unit, from head unit, sorry. So, it uses some inter-equipment communication protocol which can be vendor specific. There are few that are open and known but mostly they are using some proprietary communication protocols. When we open these boxes, we can find different hardware inside it.
07:07
So, in this case, what we commonly see is a Texas instrument chip. It's big SOC which is optimized to run fun and nice operating system called QNX which some of you might know was running on BlackBerry devices some time
07:23
ago. Now, they are upgrading it and maintaining it and they are selling it as the main car navigation platform. So, it is new Neutrino platform which run on ARM, ARM V7 in this case. And this chip is very powerful and can do a lot of stuff for you. It can do a lot of DSP processing. So, it can do video
07:45
processing. It can process network information. It can interface with other stuff. So, it is really powerful device with complex architecture and it is implemented in such systems. So, what we found on these devices is stuff like a non-flash. We have identified a lot of positions where we can connect
08:07
and see what the information are there. So, on these pins, there can be something interesting, something we don't know until we verify. So, as I mentioned, the main operating system which you can find on most of these
08:21
cars are Android and QNX. QNX is becoming really dominant in this place because it is micro kernel based. Unfortunately, it's proprietary. So, it is very difficult to obtain anything open source. If somebody has any information about any open source tool chain for QNX, let me know. I'm interested.
08:41
Otherwise, licenses for QNX for developers are somewhere like 10K dollars per the license. So, it is really expensive. What we also see that these devices are on top of the QNX. They are running some user interface.
09:01
It's based on SWF, Flash User Interface, and it utilizes known technologies which are a little bit modified and customized for specific purposes like Lua scripting, D-Bus, Java, XLAT. So, all of these are standard, but they are usually just enough modified so it's difficult to use
09:21
pre-existing tools to do anything with this. So, also during this, we have discovered that one of these devices has more than one single partition. So, these partitions are all custom QNX file systems, and they are optimized in order so when you're updating, you overwrite
09:41
only a single partition. So, as I mentioned, QNX is similar to Linux, but it is a little bit different because it implements a little bit different approach to the kernel. So, it is microkernel, which is monolithic in contrary to Linux, which is modular. So, everything should be already
10:04
in the kernel itself, but some of the drivers which are needed are loaded from user space. So, it is a little bit different than the Linux kernel where everything is running in ring 0. So, every driver run in kernel space unless you're using some hacks and you fuse or something that enables you
10:23
to use user space drivers. So, problem with this, everything is proprietary. As I already mentioned, proprietary file systems which are mount as read-only on device. There is not much documentation. We spent few months researching about QNX, but as I said, expensive licenses,
10:43
close source, proprietary, there is not much to find open. So, we were spending a lot of time reading development manuals, trying to find something that exists. So, few people done something, but they are limited. So, we built on other existing tools.
11:06
Problem is that it is impossible to cross-compile for QNX anything unless you have QNX development tools which are costing 10K as I mentioned. So, what we started, we started to analyze the boot process first. So, boot process start with IPL which is like your Linux loader.
11:25
So, it will load first and then load everything else. It will load this image file system that is actually Z image in Linux. So, it is kernel and then it will start loading user space programs and finally it will load partitions from flash memory.
11:44
So, it has fully running system in the end. So, what we see while reading this documentation that I mentioned, we have discovered one interesting recommendation by the vendor and that is actually what we find really interesting and that is to eliminate everything that can slow down
12:04
the booting process. So, all security features like checksums, signatures, CRC, whatever you have, they strongly advise you to disable it so device boots quickly. You don't want to be sitting in your car for 20 minutes
12:20
waiting it to come up to check image before it loads it to check if it is consistent. So, it is just optimized for quick boot because we are impatient. We like to be driving from point A to point B not waiting for our car to boot. We have Windows for that. Also, what we saw that there is no secure boot,
12:40
file systems were not encrypted. So, there was a lot of security features which are missing and which made our life a little bit easier than it would be otherwise. So, also one interesting thing, devices that we tested were customized for different car manufacturers.
13:00
So, we have checked not a single vendor but we have checked every car that we can find and that people will allow us to play with. And you would be surprised that not many people will allow you to play with their car. I don't know why. But we saw that they all use OEM devices which are kind of similar to each other and they are just a little bit customized
13:21
and optimized for each specific cars. In some specific cases, we saw that car vendor asked for additional security features to be included in such devices. So, it is possible that the same device which run in one car is vulnerable and the same device with same level of hardware version
13:43
runs differently in other car because car manufacturer asked for additional security features to be on. So, when we dumped the firmware from these devices and we have done analysis, we found references actually that the same firmware is actually baseline for different car manufacturers.
14:00
So, we found strings that are relevant for anything that you can imagine. So, I believe they are selling to everybody. So, problem in this area is that you're not sure even if it is the same hardware, if it is the same level of software and feature packs that are implemented on this hardware. So, our idea is to see what we can do first
14:22
without actually dismantling the car. So, we reviewed all access vectors. So, radio signals. Available interface for USB, CD, available applications on the devices. So, they are having some kind of market
14:41
where you can download and install your own applications. Some of them you need to pay. Some of them are free of charge and can be just downloaded. After we were done with this part, then we started dismantling the devices. So, we pulled them out of the dashboard. We had wires everywhere. So, we start analyzing devices.
15:01
We saw there are flash chips. There are EPROMs. There are consoles. There are soldier points, test points where we can maybe do something with it. But unfortunately, car is not the best laboratory that you can work. This is poor Ben. No, Ben was not hurt during this work.
15:22
So, he's safe. He's here. He's just very cold in this picture, I know. So, we were working in the UK in the winter. It was not the best possible way. It was around zero and we are sitting on car park with everything open because car is small and there is two of us and we are not so small. We need a room, especially me, yes.
15:43
Thanks for pointing that out. It was not obvious. So, we removed just the plastic covers of the dashboard so we can actually access the wires and the connections behind the devices and we started analyzing how these devices interacts with the car.
16:03
So, our idea was we don't like to work outside on cold in a very, very low space. So, our idea was can we move the car inside? Guys maintaining our labs say no. We will not allow you to drive car in.
16:21
Elevators might be a little bit smaller than you need. So, then we get another idea and that is let us try to emulate the car outside of the car. So, we need to replicate enough so devices are operational but without actually needing to have the car. In very, very old times, I would go to the junkyard
16:41
and I will try to salvage ECU with everything but today we do not need to do that because modern car are not operating on the same principles. Even modern car do not have lately proper OBD interface. This is emulated. So, even in the car, you have emulation OBD and behind that, it runs whatever you want.
17:02
So, there are different protocols and standards that are used. But in order to make devices operational at this point, we needed to check status of the holy grail, CAN bus. So, how device interacting with the car? We started by discovering where CAN bus is connected
17:22
to device and started sniffing in order to find out what device needs from the car so we can set it up in our lab. But we discovered that we might not need to do anything because device is not communicated on the CAN bus. So, device is just listening but at that point in time,
17:42
we could not find any single packet injected by device on the CAN bus. So, what we saw, we started first, device was removed, we started sniffing the CAN bus, collecting what information we can see, then we connected everything, start running, comparing and we see exactly the same stuff.
18:01
So, device is not interfering with CAN bus at all. Anyway, we just captured this traffic so we can replay it back in the lab. So, if we missed something, it will still work so we don't have a problem with that. So, this is a little bit of hardware that I like to use. It is all small hardware and it is pretty cheap.
18:21
I like Blue Pill, it is very cheap STM platform. It is less than $2 on your favorite trainee's supplier and it is cheaper than Arduino, it can be programmed Arduino but it's much more powerful. And what I like it, it has USB and I was very happy when I discovered it has CAN bus on it.
18:42
When I start developing a sniffer that I needed, I had one sniffer, it is on the right corner but I needed to have two of them, one to sniff, one to inject. So, I needed to create another tool and I like to have my own tools anyway. I discovered one very disappointing thing and that this platform cannot work on USB and CAN at the same time because of some memory overlaps
19:02
in the architecture of device and you can use only USB or CAN. But luckily, I had a CAN shield from Arduino which worked really well in this case. So, we have collected all information from CAN bus and started creating our environment in the lab where we had standard power supply units,
19:22
we have everything else. What we didn't have are actually cameras, antennas and speakers but that was not important because devices were fully operational even without that. So, we were very lucky because now we can work in much hotter and better environments.
19:40
Our hands are not freezing, we are not hurting ourselves. Our CAN bus simulation is working, device is happy, not complaining and everything is just fine so we can focus onto the operation. So, as I mentioned, devices are using wireless connectivity but not on themselves. So, they need to connect to your phone.
20:03
You as a driver need to set up connectivity on your phone and share, so it is like a hotspot or Bluetooth depending on devices, some of them require WiFi, some of them require Bluetooth but it will use that as a communication channel in order to establish connectivity to the internet
20:23
and to go to download everything it needs, applications, configurations to enable you access to up market so you can buy applications that you like to install. So, what we see is the device is now having standard IP address which enabled us to play with it
20:42
without actually connecting to wires. So, we have set up a rough access point which is controlled by us based on host APD, DNS mask, IP tables and our favorite burp tool and we connected to these devices to our access point
21:00
and just intercept the traffic to see what device is doing. We have discovered that devices are, devices that are using Bluetooth were a little bit more pickier than WiFi devices. So, they needed to establish first, before they establish pan connectivity,
21:20
so, private area network, it needs to be set up as hands-free device. So, it needs first to connect your target device that you're sharing with your car as a hands-free device and then it can use it as a network standpoint. So, that made our life a little bit complicated but not too much because it was easy for us to create a small Python tool based on PyBluesy
21:42
which we use to emulate phone in both profiles. So, that enabled us to actually establish connection and to sniff the traffic that goes from device to the internet and back. So, we implemented only necessary devices, only necessary features in order to have this device
22:01
connect and operate. Now, Ben, I'm tired. So, now, Vladan has introduced the device, how they work and their specificities. I'm going to detail you what kind of attacks we have conducting on the device. But first of all, because we have described
22:21
our talks, sorry, as a new approach, why our previous attacks don't work anymore. You remember a couple of years ago, here at DEFCON and Black Hat, some researcher have introduced vulnerabilities present on Jeep cars. So, these vulnerabilities were exploiting connectivity.
22:40
They were connecting to the device using telnet. The password were well known and present on the internet. They were also using D-Bus over TCP to connect to the device. And last but not least, they were abusing the firmware upgrade process by passing the content signature check-in. So, now for our test,
23:01
we still have the IP connectivity to the device. So, they have not configured any software firewall to prevent us to access the device. But D-Bus over TCP is closed, telnet is closed and the firmware upgrade process has been hardened. So, we couldn't reuse any of the previous vulnerability described on the web and here.
23:22
So, the angle we choose was the third party applications. So, on the device we have been testing, we realized that the vendor has provided an app store and when they designed the solution, the goal was for them to open the devices to third party vendors and they could create their own application and they could sell it on the store,
23:41
like for example, the Android app store or the app store for iOS. In the reality, there is only a limited set of application which are on it and they have never, I think, released the software development kit for third party applications, which is good, you will realize why a bit later. So, the first thing we did is we intercepted
24:02
the communication between the software app store and its back end. So, it was using HTTPS, which is good. Problem is, the encryption is broken. When we try to intercept and replace the certificate by a self-signed certificate, the device did not show any warning and it was continuing operating as normal.
24:21
So, first problem. The second problem is the device is communicated with its back end using XML messages, a bit like SOAP and we could easily intercept the content and modify the content on the fly. So, for example, when the device requests the software catalog, the server will reply with a full catalog,
24:40
including the links to the URLs for the install package and just with a status, which is buy, install or install. So, if the status is buy, the device, when you will click on it, will offer you to buy and pay for it. But if the status is just replay by install, the device will install it without having to pay for it. So, the logic control is done at the client side,
25:01
which is very bad and it might reminds you the first mobile apps you have been testing couple of years ago. So, good stuff for us. We could get access to paid apps for free, but our goal is to go deeper. So, here is an illustration. You see we have just replaced, sorry, the base that's used by install and we were able to install the application on the device.
25:26
Now, we did some analysis on what was an install package for a third-party application. So, in the previous screenshots, you've seen that we have the URL for the install package. So, we downloaded couple of them. You don't need any authentication,
25:41
so just a wget with the URL and you could access the third-party application package. So, we downloaded all of them and we started analyzing them. So, what's an installation package? Basically, it's a zip archive with inside a jar file, so a Java archive and one signature file, which is a signed message digest using RSA signature.
26:04
So, we have tried to spend a little bit of time, but we were not able to break the signature encryption, which is good. Once we open the jar file, we realized that the source code is not obfuscated, which means with any of your favorite Java decompiler, you can access the source code, which is good.
26:20
However, the jar file by itself is signed with some private keys. So, here we are facing a system with two different levels of code signature. So, does this mean game over? So, what we first try, our first attempt was to play with the process of zip extraction.
26:42
You will understand why. The very first step that the app store is doing when you install an application is storing the zip file in a temporary area and extract it because to check the checksum of the file, its signature, it first need to extract it. So, this is the piece of code
27:01
in charge of unzipping the install package. And if you are good hackers, and I believe you all are, you will immediately notice that if you have used a zip entry name, you might be able, because it's concatenated, to do arbitrary file writing. So, what happens if you had a file to the archive with a zip entry, something like dot dot slash
27:22
dot dot slash something? So, we wanted to validate this. Obviously, this is not going to work with zip, unzip, unzip. You will get the message removing, trailing slash, or whatever. But what happens with this dirty Java code? So, we created a crafted zip archive using any Python lib.
27:41
And you remember, we don't yet have control on the device, so if we want to see if this was successful, we need to write somewhere, we can check the file is created. So, so far, the only thing we can do is plug a USB stick and check if we are able to extract a file to a USB stick. On QNX, if you read a little bit of documentation, you will find that the location of the USB stick
28:01
is slash FS USB zero and then your USB device. So, we created this crafted zip file with a directory traversal, writing an empty file on the USB stick. And you know what? It worked. So, this means that we have an arbitrary file writing without creating any warning on the device once you install a crafted installation package.
28:23
So, good start. But now, to take control on the device, what we need to do is to be able to copy a file to a place where it can be executed from. So, it, it, it brings you two problems. As we said, most of the file system of the device are read only because if the device loses power, it need to restart without having to do
28:41
content integrity, file system checking, and whatever. So, most of the file system are read only under normal operation, excepting some of them. And the place where third party apps are stored is a read write file system because you can install the applications, you can remove them, you can upgrade them. So, the file system has to be mounted as read write. So, we need to write at this place
29:01
and we need to find this location. The second thing is, so, this Java archive, those are, Vladan mentioned, xlets. So, this is one of the G2ME implementation. The problem is, we cannot build any application or rebuild the application if we don't have the vendor SDK or API or libraries.
29:21
So, this is also one of the problem we have been facing and we will explain how we solved it. So, it is possible to recompile the Java source code, but impossible to recompile it. This is what we just said. But how about backdooring, patching? If you all have done some testing training, you have been doing disassembling, x86 modification,
29:45
changing instruction, repacking, and whatever. And what about doing the same with Java? Because basically, Java, what is that? Is Java source code compiled? So, it is Java bytecode, it is known as this, and this is portable code to be executed by the Java runtime environment. But basically, the bytecode is just assembly,
30:02
but for a different kind of machine, and the machine is just Java runtime. So, if you use the Java bytecode and you modify it with kind of a disassembler, which exists, you can patch the Java code without needing the SDK nor API. This is what we did. But remember what we said, the Java archive itself is sign,
30:20
which means that if we modify the bytecode, the Java runtime environment should refuse to execute it. So, because we didn't want to lose too much time, our first attempt was just to change a PNG icon from the Java package. And when we installed the application, it refused to start, which means that the GVM, the Java virtual machine, refused our modified application, which is good.
30:42
So, here again, game over. No, we tried something desperate. We said, okay, the signature is not good, but what happens if we just remove the signature? So, guess what? It worked. So, if there is a signature and the signature is not good, reject the program.
31:00
But if there is no signature, no problem, just start it. And it worked. So, now we are able to write on the file system and we are able to execute malicious code that we have created. So, the next step are pretty straightforward. We just have to create a malicious payload. So, it is basically Java source code.
31:21
So, you just use the standard Java SDK. You just have to pay attention to the Java minor and major version. So, basically, your code has to be executable by the target. So, what you do, you analyze the source code you extracted and you are compiling with the same target version and it should work. And then you have to hijack the normal execution flow
31:41
to redirect it to your malicious payload. So, here, we've been using massively the USB connector of the car because we didn't want to recompile at every time our program. So, what we did is we just did a payload, executed the script shell, which is in the USB stick. So, if we want to modify it, it's easy.
32:00
You just plug the USB stick on your computer, modify the script shell and re-execute the application without having to reinstall or doing nothing. So, haltering the Java byte code, I told you modifying the assembly. So, it's pretty easy. You just have to basically add the invoke static, sorry, method, which is calling your payload.
32:22
For various reasons, I'm not going into how the GVM works. You also have to add the instruction to map your assembly code to some virtual line numbers of the source code. This is the way it works. So, it's not just one line but free instruction for it to get it to work. But the fundamental instruction here is the invoke static,
32:41
which brings you to your malicious code. So, now, every time the patched application is started from the user interface, it executes the script.sh located on our USB key. I'm not going through the details because we have performed maybe hundreds or several hundreds attempts
33:01
because we have no idea on the device. We are doing blind attack. We don't have the response. So, we were having iterative approach. We were writing commands in the script and collecting the output every time. Editing the script and starting over multiple times. In the end, our goal is still to get connectivity to the device with an interactive shell.
33:21
So, remember the target device is using QNX and QNX provides something which is called QCon. And QCon is a debugging daemon for QNX used during the development phases. It allows you to do some profiling but more interesting for us to do remote code execution. Problem, the QCon daemon was not part of the build
33:41
because when you do production build, you remove any useless stuff that you won't need in production because you need to save space and time and whatever. So, QCon was not part of the build but Telnet was for some reason. So, we couldn't use Telnet as is because Telnet requires authentication and we don't have the root password.
34:01
But QCon does not. What we were able to do because we still don't have QNX license and our managers were not willing to buy us the license, we found QCon on the web. We were just downloading a Raspberry Pi image for QNX which was using the same distribution and fortunately the Raspberry Pi
34:21
is using the same CPU instruction which is ARM v7. So, we desperately copy the QCon from the device and we executed and it worked. So, we had a QCon daemon working and we could interact with the device. So, obviously the first thing we tried is getting the root password. So, we got the shadow file and we managed to crack the password.
34:44
So, now maintaining access and post exploitation. Because we don't want to repeat all of those step every time we want to get access to the device, we needed to find a way to get persistent access. So, basically that means starting automatically either QCon or Telnet or both.
35:01
We cracked the root password because it's using Descript. The password length is limited to eight characters. So, this could be cracked with a reasonably powerful system within few hours. This is optional because you can use QCon but it's nice because Telnet is much better for interactive shell than QCon because QCon doesn't have for example
35:21
the background and whatever. So, we have to find a script on the device which reside on the read write partition and which is executed at every boot time. So, it makes a lot of conditions but we still find one. When you're doing that, you need to be very careful because if you mess with a startup script,
35:41
there is no reset to factory option because you will prevent the device to boot properly. So, you can't even go to upgrade mode and reinstall it and there is no reset to factory that will restore the content of your flash. So, if you mess, you crash the device. So, you have to be very careful during this step unless you will get a break.
36:02
So, during the post exploitation step, we were having some fun. First of all, we realized that all the personal data are stored in SQLite which is very common. This is the same for Android and many other system. So, what was funny, if you are in a rental car and there has been several drivers before you
36:21
pairing their phone with the system, you will get all their phone's names, Mac address, Bluetooth Mac address, phone books and if it's Android phones, you will also get the content of SMS inbox which is fun. The second thing is there is a lot of logins. So, you know where was the car and when
36:40
with the GPS location, time and date and some events which is also interesting and it has been used in France for a criminal investigation where they could demonstrate that the killer was at the right place because the car had recorded this in the logs. For example, you can do some tuning, customizing the color, get a different GUI
37:01
because it's just flash and HTML5 HTML so you can customize it very easily and it's fun. And you can also play with the services. You remember when Vlad introduced the software architecture, it's using D-Bus, so a common bus with a lot of services plugged on it. So for example, the FM tuner, so from the common line,
37:21
you can change the station, you can change the volume from the common line, you can use the text to speech service which is used by the navigation to make the car speech to you and it's very fun. It's especially very fun if you re-enable D-Bus TCP and remote access to the car. So if it's a rental car and somebody else is connecting the car after you
37:40
and you get access back to the device, you can talk to the guy through the car which is very fun and that might be very scary for the guy. Most of the systems, so all those services, D-Bus services are written in a new way. It's a modified version because everything is non-standard but if you modified the decompiler,
38:02
Lua decompiler to bypass some checksum, some magic numbers, verifications, you are able to reverse it and obtain the source code. So it was very interesting for the, for the next step. Now the only grain, the CAN-Bus because all of this, we did it in the objective of getting access to the CAN-Bus and to the car critical systems.
38:23
CAN-Bus is allowing access, we've told you, to the engine ECU, something less critical, air conditionings, windows, whatever. And here, we were facing a big frustration. The system we have tested did not have a full access to the CAN-Bus. It was actually going through a gateway
38:41
and this gateway was responding to a proprietary protocol. So it was only giving access to, for example, the fuel consumption, the speed of the car, accelerometer so that, for example, if the car is driving in the tuner and there is no GPS signal, the GPS navigation system still knows which speed the car is going on.
39:01
But it was a lot of frustration for us because we were not able to jump on the CAN-Bus. It was even more frustrating because the reason why it was not possible was not for, it was not a security countermeasure. It was not because, it was just because the device had a whole poor device design. So they had to put this gateway
39:21
because the device itself didn't have the CAN transceiver on the board. So it was a lot of frustration for us. Now because we are at the hardware hacking village and we have many, we've mainly talked about software, we're gonna talk a little bit about hardware. So the box was dismantled. We have been used standard tools such as clamps,
39:44
power supply, logic analyzer, oscilloscope and all the tools you can get to your favorite Chinese provider still. And we have been able to identify the pins you see, but we had no idea what was their purpose. So using the logic analyzer,
40:03
we could quickly identify the console. So it's a serial console at 115, 200 Bo. Unfortunately, once you boot, you have authentication required. You know, if you do this on a standard Linux, you can boot in single user mode
40:20
just by altering the kernel command. But with QNX, with the IPL, you cannot do that. The IPL, so initial program loader, which was on the device, did not offer this option. Authentication was required, so here we had to have the root password cracked, otherwise we were not able to get into the device.
40:43
So this is what I just said. We had a problem, we needed this root password. So what other option doing the physical hardware attack? There was a FM, so the FM is a small memory chip using SPI. Because when the device is booting, it doesn't have the drivers to talk,
41:02
to communicate with the big flash NAND, it needs an intermediate step. And this is what the IPL is doing. The IPL is loading the driver to communicate with the large NAND chip. And we found out that in this small eight kilobytes FM, there is obviously some persistent information,
41:22
such the MAC address of the device, Bluetooth, WiFi, the serial number, maybe the build version. But there is mainly the QNX IPL, which is the driver for the next step. And our idea is, if we modify the IPL, if we recompile it, offering the support to boot in single user mode
41:41
by changing the initial program from login to just KSH, then we can get access to the device without needing authentication using the serial console. So here, the work is still in progress, but we found the QNX IPL source code because it is provided by Texas Instruments on their website. So you just have to modify it, recompile it,
42:02
and rewrite it in the FM chip. This is not a problem because if you remember, there is no secure boot because everything has been disabled. So you just have to recompile, write it in the device, and then you're good to go. Work is still in progress, maybe in a future talk, we might be able to demonstrate it.
42:20
So just to summarize, because some of you might be a little bit frustrated, our idea is if you are a good software and a good system hacker, don't be afraid of embedded and hardware hacking because here, hardware is just basically a computer, a normal computer with some specificities because the operating system is a bit different, you have a bit of constraint, but it's basically a computer which you can hack
42:42
using the old techniques you've been learning for 10 years. So thank you for attending our call, talk, sorry, and if you have any question, you're welcome. Are there any questions?
43:10
So question was, are these disclosed to manufacturer? As far as we know, yes, they should be. So it disclosed to the manufacturer, but if you remember the problem of OEM,
43:22
the manufacturer don't necessarily have the capability to patch the firmware themselves, so they might have to go to their OEM provider, ask them to fix the problem, get a build, get it, and push it to the cars in operation, which might be a problem because you might have maybe one or two millions of car with vulnerable systems.
43:46
Okay, if anybody has any questions later, we will be around. So thank you everybody and see you around. Bye.