Intro to Automotive Security - Ariel Zentner

all right everybody we start only 10 minutes late not bad all right first off uh welcome everybody to bides Knoxville 2016 yeah yeah how many people are new this year good this is the uh the biggest year it's our second year so we're expecting hey weas we're doing better uh we're expecting 250 people this year uh so and we have multiple people on list so if it keeps going this good we'll just keep getting larg so but thanks everybody for coming out for this um first off we want to uh thank all the sponsors because without the sponsors helping us pay for this uh we wouldn't be able to do it at all um so uh first off our Platinum

sponsors um is uh Cadre information security um and checkpoint software you'll see them out front um and Cisco Systems which you'll see upstairs our gold sponsors um you'll see them on your bags uh sword and shield they'll be out front over there they've got some cool giveaways for you um tenable network security which is going to be over in the k um Tech Systems which is right here in uh the W where you walk in the venue and opta which is going to be over in the KC as well and then uh also we've got appet uh security and rysc Corp um and they'll be over in the uh the K from there so round of applause for the

[Applause] sponsors and as uh you may or may not have noticed uh by popular demand everybody wanted posters last year we ran out we did a run of posters everybody gets a poster this year uh so it's either orange or blue it's just a luck thing whatever was in your bag that's what you got so hope you guys enjoy that uh We've also got some other giveaways that we'll be doing during the talks um B books uh soldering iron kit some lockpicks there's a lockpick Village again upstairs on the second floor for you to try everything out uh so from the logistics side of things um first and foremost uh how do you get fed

how do you drink things uh we'll go with food first right uh in your bags there are tickets okay do not lose these tickets um a blue ticket there's one of them that is for food uh when you want to be fed uh around lunch um come here uh in scruffy this aisle right here for drinks uh we include alcoholic drinks because we know everybody likes to drink or a lot of people do so everybody gets two tickets uh these two purple tickets that are in your bags don't lose them uh that's how you get alcohol uh the bar is open now they do mamosas and whatever you want so have at it just make it through the day

okay uh if you drink too much there's water on the bar too there is coffee over here in this corner and the bar also uh serves Fountain drinks and those are included so you can have Fountain drinks uh whenever you want uh the other thing Logistics wise you will notice wow this got complicated this year uh you will notice there is a wristband uh this wristband gets you into the Afterparty tonight okay cool all right last but not least uh where are all the tracks we didn't put up signs somebody just told me that so awesome uh main track is here in the in uh scruffy City uh KC will be track number two and next door in Pre

Pub will be our third track uh the third track is only going to be running from 9: to 11:00 and those are remote talks okay uh keynote is at 1 today and uh check uh the bides Knoxville website in sc.org for um the schedule for the day we're going to try to get it on the monitors here um uh so people can see it in the venue as well but that's it uh thanks everybody for coming out hope you guys have a good time um and let us know if you need anything so with that we'll start up the first

[Applause]

presentation hi everyone I'm Ariel from Cisco St stair Center in Cisco uh the stair Center is got a pretty long name it's a security threat analysis and reverse engineering center we're located in Kaa in Israel we have uh we do we perform blackbox testing on embedded devices we have two main teams the hardware team which is uh very much Hardware they do uh silicone reverse engineering delayering of chips using electron microscopes laser glitching and all kinds of heavy stuff and there there's the software team which I'm part of which we do reverse engineering of all the anything which runs code for the past three years or or so we we've been working with the the car

industry uh mainly North American uh vehicle manufacturers uh we've been helping them test their systems look for security vulnerabilities before they get sent out to the field hopefully we'll find the problems before somebody else finds them uh for obvious reasons I won't be mentioning specific names or models of cars but uh it's pretty safe to say that some of you drove into today with cars that we've had a look at in the past so what we'll be talking about today uh first of all we have a look and see from a hacker perspective how we see a car when we look at it we'll learn a bit about the ecosystem connections inside and out we'll uh touch a few uh

common security problems that we see we'll go through a few of our tools and at the end to wrap it all up and put it into context I'll walk you through a project that we did from beginning to end from the stage of receiving the design and analyzing it until the actual development of an exploit for for that car uh it's not going to be very deep or very technical don't worry it's more of a it's more of an overview of the field the first question to ask is what is the car well that depends very much who you're asking right if you ask a traveler he'll probably say it's a vehicle which takes people from one

place to another if you ask a mechanic he'll say it's a internal combustion engine with transmission final drive Wheels steering chassis and all the rest of the mechanical parts of a car you ask a hacker what a car is it's just a pile of computers there's a whole lot of computers connected inside a car nowadays I say a pile because there are a few dozen usually in modern cars all talking to each other uh the big difference to remember between this pile of computers and any other computers that you have in your house or office are these ones are sitting on Wheels and you're possibly inside the car driving at 65 mph so when it's at home something

goes wrong in your computer if somebody takes it over or crashes something it's not the end of the world you might lose some money or lose some data uh when you're driving in a car something goes wrong it could be very bad now all this stuff has been true for the last I don't know 20 30 years since they invented a fuel injection probably I think it was back in the 80s or 70s but what's new nowadays in the modern cars what we call a connected car a connected car is a car with lots and lots of cool attack vectors or supposedly uh connection interfaces to the world right you have a your entertainment system which connects up

to the Internet to download Media and applications and stuff you have a diagnostic system connecting back to the cars uh back end to report errors diagnostic problems and maintenance and whatever you have ARF connections to your key fob you have maybe a mobile phone app to remotely start the car when it's cold you want to start it before you get to the car uh there you have satellite radio digital terrestrial radio soon cars are going to be talking to each other as you can see there are many many connections uh many uh networks going out of this car on a personal note couple of years ago our Leasing Company wanted to upgrade the cars to new cars and the salesperson was

trying to convince me how great this car is it's fully connected straight to their internet and to their computers they can control everything I said no thank you I prefer staying with my old car had all these computers talk to each other inside the car there's a series of buses of network connections between them there the can bus the flexray bus Lin bus different names but ultimately there just ways for the different noes to talk to each other I don't expect you to read all the specific dots but you can you see there are quite a few few points connected from one to another in the car starting from the door handle to the to the pedals to to anything else in

the car airbags whatever it is and uh this trend is increasing right the the cars of Tomorrow are getting more and more advanced we're having seeing more and more interfaces and more and more automatic features of the car which are computer controlled you know like a self assist assisted parking and all those stuff uh one of the main buses in a car is called a can bus it's very common bus these are some of the example example messages You' see running on the CBS like the air conditioning control the radio volume lights the cruise control as you can see some of these messages are quite harmless some of them might be less cuz cruise control can control your

accelerator and your brakes in the car the can buas the control area network is a simple bus it's a single line or differential two-line bus with a few nodes connected uh pretty standard packet uh structure you have an ID and a payload and a CRC and stuff anyone who connects the bus can listen to all the messages and can send messages on the bus there's no Master Slave or any special uh setup there interesting thing to know about the canas is that the idea of the message is also the priority of the message the message with a lower ID message with more zeros takes precedence over other messages so if someone is trying to send a message and at the same

time I send a message with more zeros my message goes through so it's very easy once you're connected to the bus just take over the whole bus and flood it with your messages or no one else can communicate uh some of you might be aware or some not uh you can you have a clear access to the can bus in your car all all modern cars have a connector called OBD2 connector it's under the steering wheel that's what they use in the garage to connect and get diagnostic information and stuff it's very easy to buy a third party tool you can get one from the internet you could sniff the Camas read the messages you can write on the canas

and you can experiment with it if if you want to if you're brave enough to try okay in the past if you wanted to do something bad to someone you would crawl under their car and uh cut the brake lines when they're not looking uh excuse me for the photo it's not really a cutter it's more of a crimping uh tool but was it was a good photo um but crawling under a car is uh first of all it's dirty right you're lying on the floor the brake FL might spill on you and uh second of all it's dangerous as an attacker you have to get very close you're actually touching the car you can get caught uh it will be

much nicer if you can do the same much nicer and cleaner if you can just send a can message on the bus Which does exactly the same thing when we look at this the uh attacks on cars uh their severity we we grade the severity by the distance from the car the the weakest attacks are the ones that you need physical access to the car actually plugging in a USB connector or the can buas or anything else you can do bad stuff but you have to be close you the same distance you could have actually cut the brake lines uh further away are attacks from a few meters if you connect to the blue Bluetooth or Wi-Fi or

something else that where you can actually attack a car or open a car from the outside without physically being inside the car or physically touching it and the best attacks the ones which are done over the internet from far away you can actually attack a Car anywhere in the world from your lost not back hello there's a lose connection somewhere hello okay okay you can say that the for us the the Holy Grail of attacks is uh attacking a car from far away from the internet and uh gaining control over the canas to send arbitrary messages whatever we want let's talk a about about internet connectivity how do the cars connect to the internet well it's

obviously not wired because they're moving around that's unless you're in the amusement park in those cars which have that metal thing to the ceiling and Wi-Fi wouldn't work also cuz you keep moving around you get out of range so the standard uh connectivity is done through Cellular Connections right just like your mobile phone the two uh standard ways are either go through your actual mobile phone you set up a hot spot in in the phone tethering and it connects through your phone to the internet that's very useful for an attacker because uh first of all we can see all the traffic going through our phone it helps us analyze the traffic and second of all it gives us more

attack surface because in this way we can attack someone's phone instead of attacking the car and get inside the stream of data the other option which we also see is that the car itself connects the internet directly it has a cellular Mobile uh chip inside it with a SIM card or whatever and it just go straight up to the Internet that's a bit harder to uh to get in the middle of that connection what kind of things we look for well the obvious thing is look for open ports someone's listening on a some kind of service an open port in a car or in any computer is just like a door with a welcome mat for a hacker to come in uh

just like at home you wouldn't expect to see open ports on your computer external facing ports unless you're trying to host some kind of service you definitely would not like to see them in cars but we still do see them sometimes people leave them open for all kinds of reasons now since they're connecting to the internet uh you want the connection to be secure just like any other computer connecting to a secure site they use the standard uh protocols like SSL secure socket layer to encrypt and authenticate the the connection but uh unfortunately SSL has many many configuration parameters and quite often we see that uh some of them are wrong it's fair to say that most of

the most of the configurations that we've seen there was something wrong if it's the wrong uh Cipher Suite or something wrong with the keys or sometimes they have too many certificates people don't don't the car manufactur don't always realize that a car is not a a browser at home your browser has got to connect to thousands and thousands of websites so it needs tons of certificates to connect to all the different places the car should only connect to one preferably one or two uh servers there's no need to have so many having too many certificates in the system can help somebody like us get in with one of the certificates that uh they enable and example of configuration

problems is in this lib curl which we've seen used in the past there are many flags to set one of them is called verify peer which means you're doing server side authentication checking that the server is who you think it is the second one is verify host which says actually check that the server name in the the common name in the certificate is the correct name that you're trying to connect to not another server so some people think that just setting verify host is enough setting it to one or something but if you read the man page it says that when the verifier value is zero the condition succeeds regardless of the name so if people don't read the

fine print in the Man pages it's very easy to make a mistake and let us get in we've done this more than once in the past by impersonating other servers and finding slight differences in certificates they they weren't looking for another thing that you have in cars uh listen to other computers perhaps what we call remote commands uh this is an example of a mobile app you might have seen something similar we haven't looked at this one specifically I just chose an example which is not from our from our area they give you option to stand thank you gives you the options to start and stop the car from afar open the doors unlock and all kinds of other

stuff check the location in the car park how do these commands get from your phone or from your computer to the car there are all kinds of systems one of them is using uh special servers uh for example mqtt Brokers which is one kind of of system that does this kind of messaging mqdt broker is a publish subscribe system you define cues you can publish messages to a queue anyone subscribed to the queue will receive the message it's very flexible very Dynamic you can invent any name of of a queue just type whatever you want ABC if someone registers to ABC he'll get the messages it's so flexible that it has many configuration parameters also and

uh we've seen mistakes in these kind of things too we've had systems where we could connect from the public internet to a live system actually this was a live system connect from the public Internet to the mqt broker and send a message to any car on the system or to all the cars at the same time uh giving them commands sometimes your car goes to sleep you're parking for a long time they don't want to they don't want to be online the whole time so how do they get a message to the car if you want to send a command they use sms's something called SMS shoulder tap it's kind of a wake up package they have all kinds of formats

sometimes they have the server URL inside that tells the car where to connect and get commands sometimes the actual command is inside has some kind of identification uh these things too are another way in for us hackers if there's a mistake in passing the message sometimes we can find availability just by sending a M phone message sometimes they don't check properly that the server is actually one of their servers and we can direct a c to connect to our server all kinds of other funky stuff that can be done through these smss a good solution to all this would be obviously to isolate the network right there's no reason for me for my for a public IP address to be able to

connect to a car right the car should be part of a private Network for for the car manufacturer no reason for it to be connected to the internet if you block it off both for smss and for IP seems like a pretty good solution right when a car connects to the cellular operator use it sends the the SIM cards ICC ID some card of identifier which connects to the APN and that gives it a IP address in a specific range which no one else can access so in order to to access these cars we need to get a computer somehow inside that Network which gets the same range of ips to attack them but where can we find the Linux computer

inside that Network well lucky for us as we said before the cars themselves are computers so in cases like this when we see this kind of setup we Attack One Car locally once we have access in that car we just hop around to the rest of the of the network uh obviously a better solution will be to properly isolate each car from each other and make sure that messages only go to who they're intended to from the car back to the back end and the other way it should be some kind of lay security you know altogether close the ports add firewalls and all the configurations but uh often enough it's not implemented properly even car

systems today okay so we understand that the attack is trying to uh to connect to the car from from AAR how do we start about getting into the car how do we start about about attacking the computer even for our for our testing purposes even not for a real Attack just to learn about the system this is blackbox system well uh first of all for for the ports we do the regular Port scanning Port scanning techniques like you would on a computer uh which is easy enough if it goes through your cell phone like we said before cuz a cell phone is a computer also I can just see all the traffic how do we do it when it

connects straight to the cellular network well uh for example in our office in K we've got this pretty large box called a base station simulator it's actually like a a mobile it's a cellular tower inside your office assuming you don't mind the radiation you can simulate any any operator you just put all the right parameters it's actually not that bad the radiation is sort of pointed at the car and you can uh make it connect to the cellular network through our setup there are also cheaper things like fto cells which are for home use but uh this is a more professional uh solution which has other capabilities now this kind of cellular connectivity is not something

you can do only inside an office inside a lab like a few years ago there was a project called wasp which was a aerial surveillance uh something I can't remember the acronym they had this drone flying around with Wi-Fi and cellular capabilities to connect make people connect to the cellular signal so theoretically you could float on top of cars and make make them connect to you how else do we try and get in we use a fuzzing techniques like uh you would in any other system we've got a tool that we was built in a house called Kitty which is more uh it's more suited for our use for blackbox testing and we test we fuz all kinds of of entrances

into all kinds of interfaces into the car we start with a network fuzzing both server and clients that servers and clients which are on the car we also fuzz the Bluetooth Stacks right we impersonate a phone and go through the whole pairing process and dry find errors in the Bluetooth uh protocols we go on the USB stack right we see there's any errors in the USB passing itself we have to remember that these cars are often a proprietary code it's not the same you know the versions and libraries which have been around our homes for for years and been tested and debugged some of this stuff is quite new code so there's more chances of find finding

bugs in them uh we also try media formats right all the media files and uh stuff like that uh few years ago we took over a car through a Bluetooth connection just by uh giving it a malformed song name in one of the song lists that was enough to get get in okay another thing we look at when we try to connect to the car is we look for the hardware connections to try and see what it's uh what's happening in the connections now obviously this picture is not from a real car CU this is a computer from I don't know 10 years ago at least but uh that's the idea where do you find these

kind of Connections in the car right a car doesn't expose a whole set of of connectors to connect to well the thing is to connect to the back of it if you if you wouldn't mind dismantling your car the the whole panel behind the shiny touchcreen all the buttons you have a computer case and inside you have the motherboard and the motherboard it's got all the chips and the connectors now in a production system there's no reason to have uh connectors for testing and debug but often we find uh test points left on the board one of the things we look for our JTAG connection JTAG is a standard for uh performing on chip instrumentation and testing chips uh

some architectures you get full debugging capabilities in armor mips uh so we look for places like this with a 20 connecting points somewhere on the board try testing them all uh to find it's pretty hard to find which wire to connect where because it's not labeled it's not supposed to be used there are tools like a jtagulator which uh sort of Brute Forces all the connections sending signals to the wires trying to find the right ones if we find the JT connection and we manage to connect to it with the debugger it's game over where full control over the over the chip another thing we often look for and very often find are serial consoles right you have

a Ard connection to like many other embedded devices there's a u connection for development phase to to do stuff uh you almost always see uh something coming out of the of the console during the boot up like boot messages of the kernel and all kinds of information which could be useful in this example here which is a uboot uh system you see the last line here says hit any key to stop autoboot which is something which you would like in your house so we had this connected to the car you press enter on your keyboard and uh next thing you know you're in the uboot menu which is before the kernel Boot and you can

control the whole box and do whatever you want you have full access to the file system system uh sometimes if developers developers are nicer to us they actually leave debug logs running the whole time so while the car is running you see all kinds of messages explaining what's happening which is very helpful for an attacker if they're even friendlier to us they leave a Lo login console on the on the on the serial uh connection so you get this uh you know prompt username login to connect to the car and if we can correct the password then we're in and we have a control over the car and if the even friendly than that they just have a root

shell straight away you just connect the keyboard and you're in full control these things uh exist in our cars uh another connection point which I mentioned before is the canbas right we connected the canbas we have all kinds of tools for sniffing we we listen to the communication we press different buttons in the car see what goes on the bus to learn what commands they use and uh on top of Comm on top of can there are all kinds of other protocols can is a lowlevel layer there are other higher level protocols like UDS which is Universal uh uh diagnostic service that's how you check all those diagnostic messages on your car the different error values and stuff but it

has all kinds of cool commands like reading and writing memory or uh sometimes you can enter programming mode and actually ref flesh the whole CPU through the canvas if these things are left open it's a big problem and the the authentication system they exist some kind of mechanism but they're not very uh secure and they're not always done properly okay so we had a look at the Box tried to attack it f it maybe something crashed but still uh we don't know what it looks like inside this is Black Box we need to get the firware to actually understand what's running inside to see what the vulnerability is and see how to attack it where do we find the phone Weare for

the car one place to get it is to download from the website if you check in your cars the manufacturers website you'll often see in the customer support page there's a place to download updated firware For Your Entertainment System that's one place to get the code uh it could be encrypted sometimes but it often isn't often it's just signed so we just downloaded and we can uh open up the code and have a look if it doesn't exist on your website you can be sure it exists in the local garage right the the dealership has to update the software all these cars are updatable to fix bugs and to uh revocate certificates and new features and stuff so you just have to

find the right person paying a bit and you get the get your uh your phone Weare uh sometimes if we can't find it anywhere else we can't get it from the Internet or anywhere else we actually lift the physical Flash from the board right a regular pc keeps all the programs and code inside a hard disk in in an embedded system it will be in a flash memory so we pick up the flash memory from the board and we've got these flash reading machines which reads out all the data from The Flash this is especially useful in systems which have encryp encrypted code sometimes the code is downloaded from the internet encrypted but when it's installed they

often decrypted uh during installation so on the flash it's already clear so it's a good place to find the code the problem is that it's quite destructive uh very rarely we manage to put put the flashback and get the car to work again so we need a few a few sets before we start uh trying these kind of things another option that we do sometimes if we if we're lucky sometimes we have the the serial console some kind of access to the system before we get the firware and then we once we're inside we just funnel it out through USB or SSH or any other way that we can okay so now we've got the our phone Weare we have in the

hand we've got to understand what's inside it's just Big Blob of binary data doesn't make much sense it's not a a nice Raptor installation package like you would see on the computer we use tools like binwalk which helps us uh analyze the The Blob and tell us where there are file systems where there are all kinds of zip files and all kinds of other formats we start extracting it bit by bit and uh unpacking them um once we have it unpacked we use uh our favorite disassembler ID Pro that's our main the main tool that we work with to actually reverse engineer all the code and uh understand what's happening inside now part of the

challenges are that there are many different architecture this is not just your x86 home PC or just your AR mobile phone we see all kinds of stuff we see arm mips power PC v850 all kinds of uh some less common architectures um uh first of all so first challenge is actually to identify what architecture you're looking at if you're opene with the wrong architecture it can't read the code so it takes us a while sometimes to uh by reading the chip uh Engravings and stuff to see what we're actually dealing with and sometimes unfortunately Ida doesn't know of that Arch recently we had a I think it was last year we had a a new version

of a V8 v850 chip which is a Renaissance chip I just didn't uh disassemble it properly and we had to write our own Ida processor which took us quite a while to teach Ida but you know we read the instruction manual we taught Ida how to actually understand the code uh needless to say that uh people who know Ida there's also a decompiler tool hex-rays which is very helpful when you doing a x86 R it actually decompiles the code to like human readable CA language but many of these architectur don't have it so we're stuck with the the disassembly another one of the challenges we have is the the memory layouts uh often these uh binaries are

not uh organized in a a known format it's not a Elf or or executable or something which has a header which explains how how it should be opened uh when it's running so Ida doesn't know how to read the code which parts are code which are data how are they aligned so we have quite a challenge sometimes to get this blob of data into uh something that makes sense we have to start shifting parts around we've got all kinds of scripts we try to look for cross reference between different commands looking for Strings finding printer functions all kinds of tricks to get it aligned properly in the memory and to understand what we're looking at

which is code and which is data at the beginning is just a big mess um sometimes when we when we start uh that I forgot to mention these phone words can be gigabytes of size they're monstrous and now there's no way you can disassemble a whole phone Weare read through the whole thing and and and understand the all the works we have to pinpoint our efforts the places the interest us how do we know the interesting Parts uh if there are strings or other kind of debug symbols that point us in the right direction if there aren't symbols we look for other kind of anchors in the inside the code for example if you know that the chip

has a flex can interface for talking to the can and we see the data sheet that it's at a certain address we'll look for that address that number 20900 somewhere in the binary once we find that we'll start constructing our function which is we call I don't know configure can then we'll find the other one which has the control register then we'll call that function right can then we'll start building up backwards from those lowle blocks until we get uh the whole area of code which interest us one thing which is very helpful I mentioned before are strings and debug symbols in the code uh for look at this uh example function here it's some kind

of a sub routine receives a number Compares it to a structure and returns a zero or a one we have no idea what it does but if the developer was nice enough to leave this kind of string inside which says software update version is less advanced than the version It's ex it's obvious what it does our it's very very uh very often we we still see strings in the in the code and the amount of effort with or without strings it's uncomparable you can take us days to understand a piece of code without strings or minutes if you have the strings and even though it's so easy to take them out and they're so important

uh developers often still leave them in production systems too often other things that we sign find which help help us when we're attacking a system are all these leftover debug tools sometimes they leave debuggers inside like a GTB server or qon and Q andx systems and stuff like that all these generic tools sometimes we see proprietary test tools proprietary tools can help us in all kinds of way sometimes they help us understand the flow like if there's a function a script that says flash a secondary CPU and it has all the steps that helps us understand how it works sometimes the tools and are vulnerable we get in through the tools all kinds of useful

things that we find there uh sometimes we also find these hidden back doors that the engineers left inside all kinds of menus press these buttons do this or if you have a a certain file name on the on the user B like if it's a media file it plays if it's a bin file installs the firmware but if it's a certain directory with a special name and Sh at the end will run a shell script directly gets us straight in uh for some reason people think that the these kind of secrets are can't be seen but uh obviously are not experienced enough in reverse engineering because it's a one of the first things you see okay so let's say uh our attacker

managed to uh attack a process in the in the car and got in and took over a process which was say interfacing the web and now he's controlling the process what kind of damage can you do in the car that depends if everything runs as root as often happens in embedded systems because it's much easier to configure then you have full control over the over the whole processor but when when not everything runs as root when they do have a separate proper separation for users where do we look to get the privilege escalation one good place to look in boot boot up scripts when the Box boots all the ETC init script and stuff like

that they run as rote so we look for errors in those scripts as I said before a lot of the code in the cars is not not standard code they have all the proprietary scripts that they added and they're not always careful enough for example this script which we found once uh there was a user called browser who was in charge of browsing the internet he had a low uh privilege and they had a command to do CH own minus r on his home directory for every booop uh we don't know why they had this code there for every boot up we think it was a mistake it was probably something that you would do one time when preparing the file

system but it was there so we asked ourselves if it besides being wasteful if there's any damage that can be done through the script and the answer is yes cuz ch are follows soft links Sim links out of the out of the directory so if you can get a file pointing from your home directory out to a system file somewhere it will change the ownership to be the lower the ownership of the browser user which exactly what we did we took over the browser process we created a soft link to another directory outside and the next reboot we had the control of other files on the system and we started from there other places we look for privilege

escalation are all kinds of IPC demons there are lots of processes usually running in these system systems and they communicate between themselves with interprocess communication it's either some kind of proprietary system when they have some sockets they send messages to each other or standard systems like debas um if you can send a message from a low privilege process to a high privilege process and make it uh perform the the the command then you're actually uh adding your uh you're jumping your uh privilege but if you find an error in the passing then it's even better because you can take control over the process this example here it's from Charlie Miller's uh report and from uh

back in August it says dbus can require authentication on the Jeep head unit the authentication is open to Anonymous action is shown below and you see someone tellen anything from outside open port on debas can send messages to all the processors on this system now uh I mean you probably had to believe these things actually existing cars today it's so easy to take a control of a car but you can just ask the guy who was in the jeep that got pushed off the road these things do exist uh another place we look for is uh firmware updates right just similar to Startup scripts firmware updates run as roote because you have to mount stuff

and install stuff and all kinds of heavy things so fir update is a good uh good place to get to get a foothold as an attacker into the system phone the firware itself as we said usually comes from USB or some other source could be encrypted could be signed uh even if it's signed there's some kind of manifest like a table of content explaining what we what what we have inside the bundle usually there's like a list of files and and the hashes and then there'll be a signature file full of all the signatures and cryptographic signatures of all the files but uh sometimes in the part the in this example here the signature file

itself is listed inside the Manifest file it's not it's not a fixed name the name is here so obviously the Manifest file itself can't be signed which means we can play with the Manifest file and all kinds of bugs and stuff in passing manifest files are often used by US uh to get inside another thing which uh we see too often is US of the system system function command the system function command takes a string or passes it to a shell it's a perfect place to get a Shell Code insertion into the box like in these kind of functions which install stuff from the from the USB it takes a name straight from the Manifest file

runs a shell command on it if you put a semicolon and some other command you're inside the Box other more complicated stuff that we do sometimes are talk to attacks time of check time of use time of check time of use is when something is done in a nonatomic manner like a reading of far from the USB they read it one time check the signature if it's okay they read it again and install now if you can get in between those two reads and SW swap the file to something else you can trick the box into installing something which is not signed which is exactly what we do we have a setup using an IMX 5 board which has a

USB stack on it and it gets an image file which is actually the file system on the USB and we uh we actually switch the images between the two reads in cases like this sometimes you have to have uh precise timing sometimes it's easier it depends on the system uh obviously secure boot if the if the bootloader would actually check the the signature of the whole image every time that it boots up to make sure no one's touched it that's a good help in making your system safer this does exist sometimes but not enough and actually recently some one of our team members found a bug in the secure boot mechanism and uh took over the Box even

though it had a secure boot inside okay so past this stage let's say our attacker is inside he's got root privilege on the on the main processor he's controlling all the processes can he send in the C messages on the car can he do bad stuff well that depends if the application CPU is connected to the canas then yes once you're inside and your route you can just send using the driver straight on the canas a better design would be something like this which separates it to two separate processors this is something we often see the One processor in charge of the entertainment connects the internet and showing all the movies and stuff and that's like the the less secure

processor and there's a totally separate processor who in charge of of talking to the canas and all the other critical systems on the car uh this way if you take over one if you compromise One processor the other one still stays safe but uh you still have to uh send information from One processor to the other because the main processor wants to read I don't know your current speed or get your location or stuff like that so you have you define a set of messages going between the processors a fixed set of messages like enam you know message 1 2 3 4 5 only safe messages that's all that goes across in The Wire between the

two this is a kind of a a safe setup but need to remember is that if you have uh two processors with some kind of remote procedure calling between them that adds another attack surface for us to get in between to to attack the processor which is performing the IPC often these are proprietary systems proprietary code writing the RPC between the two processors and this example here there was a project when we had a arm CPU a dual core arm one side the application CPU was running uh was running Linux for the media the other side was running uh some kind of a real-time system with t engine or something and they defined a shared memory to get messages from side

to side and in order to use the shared memory they wrote a kernel model which you give it some kind of que some kind of Q node you put it in the queue the other side will read the message send the C message Etc but a bug that we found inside the implementation of this uh driver uh actually allowed us to gain kernel privileges on the main CPU that was from a regular user so it gave us quite a boost that mistake they had in the RPC okay now I've got the reach the maybe more interesting part um now we take you through our project uh from beginning to end to see what it looks

like this project that we received this was a design that we saw there was infotainment unit I didn't mention it earlier but we mainly look at the infotainment units because they are the ones that have most connectivity to the internet and to the other stuff it had the application CPU inside it was sitting on the canvas and uh the infotainment unit would connect straight to the internet to the car vend servers in order to download Media and all kinds of uh applications and stuff now all the communication was done securely and properly with SSL uh anything which had used as passwords or important information was done secure besides the media files themselves which came from

all kinds of other CDN and stuff they were pass in the clear because no need to encrypt uh music file but we noticed that besides uh the music files being downloaded there was also terms and conditions page you know just a text Page those annoying ones that pop up at the beginning when you install an application says you know do you agree to all the stuff and you scroll scroll scroll and you say yes and whatever it says this is some kind of Radio application uh so that was another one of the pages that was uh downloaded via HTTP and not https okay so we look at the system to observe it from all sides see what we

can find first thing we notice from the design is that the application CPU has full access to the canvas okay I mentioned before which is uh not too not too secure design uh the second thing was that the firmware was available on the web so as we said before we downloaded the firmware and started reverse engineering it another thing which was very helpful we had the shell console via art with a a login shell uh we didn't have the credentials but we had the the shell itself and uh the thing which I mentioned before is that there was a web page which was downloaded of H HTTP that one page that we identified in the whole

system uh looking at first engineering the code and looking at all the components we noticed that the webkit library was an old version now this often happens in embedded systems that the software components aren't updated as frequently as we would like them to be it's much harder to send out an update to a car somewhere have to wait for the next uh I don't know time goes for servers and it could be expensive so that don't don't update don't update the systems as frequently as you would in your home computer and uh one of the things we look for our known vulnerabilities we look in the CV databases to see if there's anything uh anything which we

can attack this Library so uh we saw this and another thing we saw was that there was some uh tools still installed in the system there was qon which this is a q andx system which is similar to Linux but not exactly it's a bit more complicated cuz not all the standard tools work uh but they do have a qon debugger installed and they had FTP and some other useful useful utilities already inside the system which saved us compiling them and putting them inside so with all this we started planning our attack first thing we did was as soon as we got the the firware uh firware image we took out the Shadow the password and Shadow

files and started cracking the password the root password using John the Ripper one of the tools that cracks password it takes quite a while in this case I think it took about two weeks of of working the computer was working but we had enough to do in the meantime so we don't care we just let the computer work in the background and we were continue with our reverse engineering uh in that web kit version that we identified we saw that there was a there was a JavaScript used after free vulnerability it's a kind of vulnerability which you can if you allocate a certain kind of structure then afterward you deallocate it then you allocate another structure in the

same slot you can get control and using that uh that vulnerability you can actually access you can get read write control anywhere in the memory space this is really cool it's a really cool uh bug to uh to cool vulnerability to attack but it's quite complicated to get this to work because it's Heat memory and the memory regions some of them were non executable and unwritable it wasn't easy to know exactly what addresses to to to write and how to uh how to do this correctly but lucky for us we had the qon inside the debugger and we had a full debugging Suite actually QX give you a a client tool also which is got

this graphical user interface so we we checked all the memory regions we found a place which was writable and we chose exactly where to write our uh our Shell Code attack and we use this actually to write a Shell Code Inside the Box so this is what the attack looked like uh see in the system we have the application CPU inside is our attack Vector that's that JavaScript engine inside webcat and uh there's the car vendor website and there's our server instead now the car want wants to connect to uh to their server but see seeing that it's HTTP and not https we were able to intercept the communication in the middle and direct it to our server

instead once we got to our server uh we downloaded our page with the terms and conditions and had a little if frame with our JavaScript inside our JavaScript ran the code inside and uh from that it jumped out and it wrote a Shell Code and took over the whole application CPU now the first thing we did once we were in the application CPU is we we used the the FTP client which was there downloading more scripts and more tools of our own and we set us up like a persistent uh system which would connect to our server all the time pulling the server asking for commands we we had the command and control center like a nice uh web GUI I think we called

it yes we can and you can just uh go to that website and uh type in your commands and those C commands will go straight down the internet into your canvas of the car now the nice thing is that all the cars that this manufacturer all the tens of thousands of cars or whatever they were all connected to the same terms and conditions page so if we manage to take control of the original server of the terms and conditions and inject that JavaScript over there would have control over all the cars driving around the world at the same time so we went back to the client with our findings got a bit of a fright after

this uh don't worry this was quite a while back it's been fixed since then and they uh they gave back the security architect to redesign and uh lucky enough they said it's not enough just to patch the that web kit version we want a proper design we're going to assume that the application CPU will always be compromised which is a good assumption because there are many processors running many websites and stuff someone's going to attack one of the processes on the way so what they did is they introduced the secondary vehicle CPU as we mentioned before this was a a v850 chip it was a totally new design they had the application CPU and the secondary CPU

they were connected over a spy bass so we got the system again and we said you know this time we're stumped we can't uh can't get the C messages what can we do so we looked at it again what we noticed were the follows we noticed that the communication goes over spy we noticed that only predefined C messages can be sent we even reverse engineered the 50 and so there was a switch case with a fixed uh number of messages that it would accept and that was it nothing else uh we saw all the phone whereare was signed we can't just change the phunware and uh you know override that function with something else can't can't

patch it uh but two interesting points that we did find uh one that the the new vehicle CPU firware is written over the Spy by the application CPU right the those uh all the phunware came in through the USB the application CPU would read the phunware inside pass it some of it would install in its own CPU and the other part will send over the Spy to the vehicle CPU to install uh in the vehicle cpu's uh memory and the most interesting point was that the signature was verified in the application CPU and not in the vehicle CPU right so the application CPU would check the ver the signature once at the beginning say it's

safe and then install it in the vehicle CPU what does this enable us uh if we take what happens if we take control over the application CPU like before right we can just ignore the signature checks for the vehicle CPU and stand across and the vehicle CPU wouldn't check it again which is exactly what we did setup is similar as before the they try to connect to their server and reach our servers this time we start off by downloading our uh JavaScript uh payload and taking over the application CPU just as before but here was another stage what we did was we took the vehicle CPU firmware the original firmware we uh understood we after reverse engineering

we understood where to patch the firware and we actually patched the function which did the switch case to enable it to receive any can message and seeing that no one checked the signature no one actually noticed that the binary has changed so at this stage using FTP we actually downloaded a whole firmware image for the second CPU it took a couple of minutes but it was worth the wait and then uh imitating the SPI commands we actually I think it was also using one of their tools they had a tool which uh which did the flashing itself or some kind of script so it was quite easy to understand the protocol over the SPI to send uh send the the firware

across we didn't have to sniff the hardware we just looked at the software and uh using the same using their own tools we actually reflashed the vehicle CPU from the application CPU and from here the continues exactly the same as before again we sent the C messages uh this attack was actually shown as a demo to the some of the managers in that car company uh they were quite impressed at the time and I think it gave a big boost to the to their efforts in improving the security of their systems okay so let's just uh wrap it up and conclude what we saw the first thing is that uh today's cars contain computers you have to remember it's a system full

of computers another thing to notice is that tomorrow's cars are going to contain more computers now with all the automatic parking all these soon going have cars driving themselves even if in the past only some of the system were computerized now everything is going to be computerized steering and all uh of course we should remember that hecking cars is a dangerous Hobby and uh uh one of the important takeaways are the security issues that we find in the cars are very similar to other embedded systems there's nothing new you the regular port and SSL and shell command and stuff it's it's just the same kind of system but uh the thing which is uh more problematic in the cars

is that they're lagging behind the home PC scene by quite a bit security I mean only recently cars started getting connected a lot of the code is still proprietary it's not open source it's not checked enough so there are quite a few errors to be found quite a few vulnerabilities to be found in the cast today and which can be taken advantage uh by attackers that's it thank you very [Music] much