Afgelopen juli wisten twee hackers het stuur van een Jeep Cherokee over te nemen met behulp van een autohack-app die ze slechts negentig euro kostte. Ook slaagden hackers erin om de deuren van een bepaald type Range Rover te openen, en om door middel van een ‘keyless ignition system’ de motor te starten en er vervolgens ‘mee aan de haal te gaan’ in minder dan dertig seconden. Meer dan 65.000 auto’s werden door Range Rover teruggeroepen om het softwareprobleem te verhelpen.
Dit zijn niet de enige twee voorbeelden. Voertuigen, net zoals vele andere internet of things-toepassingen, zijn nooit ontworpen om op grote schaal verbonden te worden, wat ze inherent onveilig maakt omdat nooit nagedacht is over veiligheid anders dan toepassingen als airbags. Voertuigen zijn in feite computers op wielen geworden en vorig jaar zijn er maar liefst 89 miljoen nieuwe voertuigen op de markt gekomen.
Toen CANBus-netwerken – die maximaal honderd processors kunnen ondersteunen – werden ontwikkeld, was de enige externe interface de diagnostische poort, welke gebruikt werd door de dealer voor onderhoud- en storingswerkzaamheden. Vandaag de dag hebben auto’s sim-kaarten, mogelijkheden tot synchronisatie met smartphones, een reeks aan interfaces en zelfs een ingebouwde WiFi-hotspot-functionaliteit. Los hiervan is de levensduur van een auto zo lang dat als hackers de systemen nu niet kunnen hacken, ze dit in de toekomst wél kunnen. Ook als een auto in 2015 goed beveiligd is, maken technologische innovaties het voertuig binnen afzienbare tijd steeds kwetsbaarder. Dit zien we ook bij computersystemen, waarbij continu patching wordt toegepast gedurende de levensduur van een systeem om beveiligingsproblemen op te lossen. Met voertuigen is het risico van andere aard aangezien er levensbedreigende situaties kunnen ontstaan. En dit is iets om ons zorgen over te maken.
Beginpunt
Het infotainment-systeem is waarschijnlijk het beginpunt voor een hacker, en wel om twee redenen. Ten eerste omdat het in veel voertuigen direct is aangesloten op het interne netwerk dat met alle systemen communiceert. Ten tweede is er veel informatie beschikbaar over deze operationele systemen, firmware-updates en de back-uproutes. Deze informatie moet door fabrikanten beschikbaar worden gesteld om onafhankelijke garages de mogelijkheid te geven om aan hun auto’s te werken. Dit wordt ook vaak wettelijk vastgelegd.
Met doorzettingsvermogen en de juiste tools kan het infotainment-systeem worden overgenomen en bijvoorbeeld het volume van de radio worden aangepast, de bestemming van het navigatiesysteem worden gewijzigd of de ruitenwissers worden bediend. Dit zijn nog relatief onschuldige voorbeelden, maar een hacker kan ook de elektronische systemen van een auto verstoren, waardoor het rijgedrag van de auto kan worden beïnvloed.
Maar een hacker kan meer. Zo is het mogelijk de brandstoftoevoer te onderbreken, de stuurcorrectie te beïnvloeden door met één wiel te remmen, de deuren te vergrendelen of ontgrendelen, de transmissie los te koppelen en de remmen te blokkeren. Hoe kan een hacker dit doen? Het netwerk van de auto communiceert met de systemen van een auto door middel van instructiepakketjes met ID’s. Aan de hand van deze ID’s weet het ontvangende systeem wat het moet doen. Het systeem reageert altijd op het pakketje met het laagste ID. Wanneer een hacker data stuurt met pakketjes die op nul staan, dan kan hij een DDoS-achtige aanval veroorzaken, die we de ‘Arbitration Hijack’ noemen.
Vaststellen beveiligingsrisico’s
Om je auto te beveiligen, moet u een drietal zaken in overweging nemen. Allereerst zijn dit de mogelijke interfaces welke kunnen worden aangevallen; de interne en externe interfaces, zoals SD, TPMS, dvd, OBD-II, Bluetooth, afstandbediening, et cetera. Maar ook de apparatuur die gebruikt wordt door autodealers voor service en de systemen die met de auto communiceren via de ether moeten worden bekeken. Middels code reviews en penetratietesten kunnen vervolgens beveiligingsrisico’s in webservices, mobiele applicaties en de diverse interfaces worden vastgesteld. Ook heb je een centraal platform nodig dat snel CANBus-data kan analyseren en uitzonderingsituaties herkent die vervolgens op basis hiervan een indicatie kan afgeven voor opkomende bedreigingen. En ten slotte is er een gateway nodig in het voertuig om CANBus-netwerken veiliger te maken en om mogelijke uitzonderingen op het platform te identificeren en doorgeven voor analyse.
Maar denk ook aan de externe partijen die aan je voertuig werken: hoe weet je zeker wat een monteur van een chiptuningbedrijf doet in het hart van je voertuig wanneer hij de ECU optimaliseert voor meer vermogen? Gebruikt deze garage een niet-geïnfecteerd en veilig platform om verbinding te maken met jouw voertuig?
Wie is het meest geschikt om connected cars te beveiligen? Je hebt een onafhankelijke persoon nodig die uitgebreide ervaring heeft in een wat volwassenere markt, zoals de financiële markt. Momenteel werken autofabrikanten vooral alleen; ze bespreken niet wat ze aan het doen zijn, zeker niet met andere fabrikanten. Dit kan ook anders, want bij het aanpakken van beveiligingissues heb je zoveel mogelijk gedeelde intelligentie nodig.
Het hacken van een voertuig is niet zonder meer eenvoudig, er is veel onderzoek nodig en er moet veelvuldig worden getest omdat de systemen ingewikkeld zijn. Daarom is het zeer belangrijk om voertuigen regelmatig te testen om zoveel mogelijk kwetsbaarheden weg te nemen.
Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 7, september 2015.
Over de auteur
Andy Rowland is head of Customer Innovation, Energy, Resources and Automotive bij BT Global Services. BT is al meer dan twintig jaar betrokken bij ethical hacking en heeft meer dan zestig ethical hacking-consultants wereldwijd, die worden ondersteund door tweeduizend beveiligingsexperts.
Andy Rowland stipt in zijn artikel een aantal aspecten in de beveilig van ‘connected cars’ aan. Hij laat echter een fundamenteel basisaspect onderbelicht: fouten in de programmatuur. Hackers maken veelal gebruik van fouten in het dynamische gedrag van software. Hoewel er veel aandacht wordt besteed aan security in het ontwerp van software interfaces, gaat het vaak mis bij de implementatie. Met handmatige code reviews en tests spoor je slechts een deel van de fouten op. Een fout in het dynamische gedrag – zoals een ‘out-of-bound memory access’ – ontdek je niet door met veel ogen naar de code te staren. Maar dit is nu juist het soort fouten dat door hackers wordt misbruikt. Een van de bekendste voorbeelden is ‘Heartbleed’ bug in de OpenSSL library, eerder dit jaar.
De Barr Group die de software in de Toyota Camry analyseerde na het terugroepen van zo’n 8 miljoen auto’s, vond legio fouten in het dynamische gedrag: memory leaks, data races, illegal memory accesses, etc. Met zo’n 8 miljoen regels software in alleen al de web browser in Android, is het infotainmentsysteem van de auto de eerste plek waar hackers zich op richten, zoals Rowland ook aangeeft. De complexiteit en omvang van dit soort software is namelijk zo groot dat dit vol potentiele lekken zit.
De enige manier om echt secure software te maken is om dit bij de bron aan te pakken: het programmeerproces zelf. Een eerste reactie is dan vaak om over te stappen op modelgedreven ontwerp en het automatisch genereren van code. Dat heeft helaas geen zin als er sprake is van een grote, bestaande software stack. Je kan die niet zomaar weggooien om in een nieuwe taal helemaal opnieuw te beginnen. Krachtige analysetools zijn de enige oplossing om kritische fouten in bestaande software effectief en tijdig op te sporen. Hiervoor is een whitebox-aanpak nodig waarbij de analysetool in de programmacode zelf kan kijken. Vooruitziende organisaties die soort tools toepassen zullen op de lange termijn het verschil gaan maken.