#crimediggers 2016 – Deel 1 – Autowrak

Tweakers en de politie hebben ook dit jaar weer een versie van crimediggers ontwikkeld. Het is de bedoeling dat je online een fictieve zaak oplost van de politie. De politie wil hiermee talent binnenhalen voor de digitale recherche. Iedereen mag meedoen, zelfs ik. De opdrachten zijn echter gericht op mensen die zeer handig zijn met een computer (understatement). Met enkel kennis van Office-applicaties kom je niet zo ver 🙂

Dit is deel 1 van 4 delen:

#crimediggers 2016 – Deel 1 – Autowrak
#crimediggers 2016 – Deel 2 – Wouters kamer
#crimediggers 2016 – Deel 3 – Hotelkamer
#crimediggers 2016 – Deel 4 – Rechtzaak

 

Vooraf iets over de de gebruike software. Ik maak altijd gebruik van wat ik nodig heb en heb dus geen principes in de richting van ‘ik gebruik alleen [insert OS]’. Linux, Windows, Mac, het maakt mij niets uit. Ze hebben allemaal hun voor- en nadelen en tijdens het uitvoeren van deze crimediggers zul je zien dat ik van zowel Windows als Linux gebruik maak. Maak het jezelf ook makkelijk: maak gebruik van de tools die voor jou het beste werken, als je goed zoekt dan is het internet het altijd wel met je eens dus zit daar niet over in 🙂

We gaan de opdracht ‘Numitor’ uitvoeren.

Leuk dat muziekje op de achtergrond. Het is sfeerverhogend maar na 3 minuten toch maar even het tabblad gedempt… Na het invullen van je naam kom je uiteindelijk bij de eerste opdracht uit.

Let op: spoilers ahead!

Autowrak – Sabotage

We moeten op zoek naar de GPS-coördinaten van de locatie waar er gerommeld is met de auto. Het is daarbij handig om een Google mapje in elkaar te zetten zodat je wat eenvoudiger kunt visualiseren wat er is gebeurd, wanneer en waar.

Ga naar Google My Maps en maak een nieuwe map aan. Als eerste zetten we de locatie van het ongeluk in de map. Bij sporen > Noldijk kun je een .kml-bestand downloaden. Die kun je vervolgens importeren in de map. In de map verschijnt een icoontje van een crash in het zuidoosten van Rotterdam.

Wanneer we verder zoeken bij de sporen dan vinden we bij de boordcomputer een zip-bestandje. Daarin is het bestandje /filesystem/var/logs/trip.log te vinden. Trip.log blijkt een .csv-bestandje te zijn met timestamps, GPS-locaties en snelheden. Die gaan we ook in bovenstaande mapje verwerken. De timestamps zijn voor een normaal mens niet eenvoudig te interpreteren als een datum/tijd. Een Python-scriptje helpt ons uit de brand. In dit scriptje worden de unix timestamps omgezet naar een leesbare datum/tijd. We laten de stamps wel staan indien we ze later nodig hebben.

Het verschil tussen de oude en de nieuwe csv:

Deze output.csv kan nu geupload worden naar de Google map met het volgende resultaat:

Dit is allemaal mooi maar we weten nu nog steeds niets over de locatie waar er aan de auto gerommeld is. Als we kijken naar de sporen dan kunnen we wel zien wat het gerommel vermoedelijk inhoudt. Er is een zogenaamde driver box te vinden die in de boordcomputer zat. Er blijkt in het eerder genoemde zip-bestandje ook nog een bestandje te staan genaamd freezeframe.log in /filesystem/var/logs/errors. Daarin zijn ook timestamps te vinden dus die kunnen we naast de eerder genoemde timestamps leggen. Verder lijkt het een log te zijn vanuit CAN-bus, een communicatiesysteem voor hardware in onder meer auto’s. In de kolom ‘Can bus status’ staat ‘overflow’. In de informatietechniek is een overflow meestal niet goed nieuws. Dat nemen we hier ook eerst aan.

Op dit moment kunnen we stellen dat er voor de locatie waar de auto gesaboteerd is, er een paar omstandigheden moeten zijn:

  • De auto moet langere tijd stil hebben gestaan, enkel stoppen bij het verkeerslicht is onvoldoende tijd om in te breken
  • De eigenaar van de auto kon niet aanwezig zijn tijdens de sabotage
  • De boordcomputer heeft vermoedelijk gemerkt dat er iets vreemds aan de hand was, dat kan terug te vinden zijn in het log
  • De snelheid van de auto was op het moment van saboteren 0 km/h

Als we de drie timestamps van het error-log naast het reguliere log leggen dan zien we het volgende: de eerste timestamp in het error-log komt overeen met een moment waarop de auto bijna een uur stil stond. De tweede en derde timestamp komen overeen met het moment dat de auto verongelukte.

Op basis daarvan kunnen we stellen dat de eerste timestamp het vermoedelijke moment is dat er aan de auto is gerommeld. Maar laten we alle voorwaarden op een rij zetten:

  • De auto moet langere tijd stil hebben gestaan, enkel stoppen bij het verkeerslicht is onvoldoende tijd om in te breken
    Ja, dat is het geval, de auto stond in ieder geval stil van 20:01 t/m 20:58 op 30 maart.
  • De eigenaar van de auto kon niet aanwezig zijn tijdens de sabotage
    Dat is in dit geval zeer aannemelijk. De auto stond stil bij een Chinees restaurant wat is terug te zien op Google Maps. Dat de eigenaar daar ook gegeten heeft wordt aannemelijker gemaakt door het gelukskoekje wat in de auto te vinden was. Verder heeft hij het eten ook in het restaurant genuttigd en niet afgehaald. Niemand gaat een uur wachten bij het afhalen van eten…
  • De boordcomputer heeft vermoedelijk gemerkt dat er iets mis ging, dat kan terug te vinden zijn in het log
    In het log komt er inderdaad een foutmelding naar voren dat er iets gebeurd is. Hiervan kun je wel zeggen dat het natuurlijk niet per se zo hoeft te zijn dat er een foutmelding in het log terechtkomt als er een module in de boordcomputer geprikt wordt. Maar in dit geval lijkt daar wel sprake van te zijn.
  • De snelheid van de auto was op het moment van saboteren 0 km/h
    Dat klopt, in de beide logs is te zien dat de auto stil stond.

Uit het reguliere log kunnen we dan afleiden dat er gerommeld is met de auto op locatie 51.8975, 4.46663

Was dat importeren van de csv in die Google Map nou nodig? Tja, in het echt zul je ook een algemeen beeld moeten krijgen van wat zich afgespeeld heeft zodat je voor jezelf kunt bepalen welke vragen je moet stellen en wat je moet uitsluiten. Goede oefening toch? 🙂

Autowrak – Hackers Handle

In deze opdracht moeten we uitzoeken wie de driver box heeft gemaakt, ontwikkeld of aangepast. Die persoon wordt in dit verband bedoeld met hacker. Dit is niet noodzakelijkerwijs degene die de driver box heeft geplugd in de boordcomputer.

We beginnen bij de sporen met het downloaden van het .tar.gz-bestand bij de driver box. Daarin bevindt zich een bestand genaamd data.dd. Als we die openen in een hex-editor dan krijgen we wellicht wat informatie over de inhoud. Gezien de grootte van het bestand denk ik dat dit een image van de driver box opslag is. Met de editor HxD kun je een bestand openen als hard disk image zodat de editor dit direct opdeelt in sectoren van 512 bytes. Dit is dan het resultaat:

Dat is een GRUB-bootsector. De GRUB is te lezen en 0x55,0xAA als laatste 2 bytes wijzen op een bootsector. Dit is dus een (gedeelte) van een hard disk image. Hard disk kun je ruim opvatten, dat kan ook een SD of een USB-stick zijn. Hoe dan ook, we moeten deze image mounten om de inhoud te lezen Ăłf je kunt de image als basis voor een virtual machine gebruiken. Dat levert wat risico’s op omdat je geen idee hebt wat er gebeurt als je de image opstart. Veiliger is dan ook om gewoon de image te mounten in een bestaande Linux virtual machine. Dat gaan we doen.

Elke Linux-distro is te gebruiken. Zorgt dat data.dd toegankelijk is. Het simpelste is om de image binnen te halen met wget.

Eerst controleren we welke partities de image bevat:

Er zijn twee partities. De eerste is maar 4 MB groot. Die slaan we over. De tweede is interessanter. Die gaan we mounten.

We hebben nu toegang tot de bestanden op de driver box. Let op dat je hier dus geen commando’s als uptime, df, cat /proc/cpuinfo en dergelijke kunt uitvoeren. Je moet alle informatie uit de bestanden halen. Het eerste waar ik naar kijk zijn de logbestanden, de inhoud van /root en /home en vervolgens naar andere opvallende directories.

Een simpele opdracht voor het zoeken naar logbestanden:

Hier lijken geen logbestanden te zijn. Wel zie ik hier LuCI staan, een webinterface voor OpenWRT/LEDE. En dat zijn open source custom firmwares voor routers. Verder lijkt dit een dood spoor.

Vervolgens kijken we in /root en /home. Dat levert het volgende op:

Uiteindelijk blijkt er in /home/fuzzer een bestand genaamd driver_fuzzer te staan. Met file komen we erachter wat de inhoud van het bestand is:

Een ELF, een uitvoerbaar bestand voor Linux dus. Natuurlijk moet je dat bestand niet zomaar uitvoeren maar ja, je wil stiekem toch graag weten wat het is. Ik wil dat graag weten dus ik ga het bestand toch uitvoeren maar wel onder gecontroleerde omstandigheden of een sandbox zo je wilt. Nu weet je dat in dit geval de politie in zo’n opdracht als dit je niet gaat opzadelen met ransomware of andere malware. Maar in de praktijk is dat anders. En we doen alsof het de praktijk is. Daarom zorg je dat je dit bestand uitvoert in een virtuele machine die geen netwerkverbinding heeft en geen gedeelde mappen heeft met de host. Maak een snapshot van de huidige staat van de virtuele machine zodat je later snel weer terug kunt naar de ‘schone’ situatie mocht dat nodig zijn. Vervolgens voeren we het bestand uit:

Er is wat geklaag over missende hardware en dat is logisch. Maar de banner bovenin is interessanter. Eronder staat morsecode. In dit geval staat er FKABITCOINBEAS. Het zou de hacker handle kunnen zijn waar we naar op zoek zijn maar FKA betekent Formerly Known As. De maker van de fuzzer heette blijkbaar ooit Bitcoinbeas. Meestal volgt een FKA op een echte naam. Denk aan ‘The Artist Formerly Known as Prince‘. Nu staat hier dus (…) formerly known as Bitcoinbeas. Kortom we moeten uitvinden wat er boven staat in dat halfslachtige 1337-speak. Als je je ogen een beetje dichtknijpt dan kom je een heel eind. Ik dacht vrij snel aan Tha BeaSt of Tha BeaZt ondanks dat de horizontale streep in de S en Z gespiegeld zijn. We moeten iets meer zekerheid hebben. We veranderen alle hoofdletters in de banner door pipes ‘|’:

Nu is duidelijker te lezen dat de eerste letters ‘Tha Bea..’ zijn. Die Z moet het haast wel zijn gezien de scherpe hoeken. Alleen die laatste letter, daar kan ik niet met 100% zekerheid een t van maken. Maar andere letters op die plaats kan ik niet verzinnen. Dit moet wel een t zijn. Verder komt het aantal letters overeen met het invulvak op Crimediggers. Die gratis hint hebben we in de praktijk niet natuurlijk 🙂

Ik had graag meer zekerheid gehad maar in het uitvoerbare bestand kon ik Tha BeaZt niet terugvinden. Ook bij de andere sporen kon ik het niet terugvinden.

Dat maakt dat ik voor nu denk dat de handle van de hacker Tha BeaZt is. Dat bleek te kloppen in ieder geval.