ios beveiliging Door Antoine v.d. Lee

i os b e v e il i gi n g Door Antoine v.d. Lee

A f s t u d e e r p r o j e c t d o m e i n C O M M U N I C AT I O N a n d M U LT I M E D I A D E S I G N - 2 0 1 2

Aut eur

Afstude e r ja a r

Antoine van der Lee

2012

St ud entnummer

Sta g e be dr i jf

500530348

Mirabeau

E -ma i l a dres

B e g e l e i de r s chool

[email protected]

Justus Sturkenboom

Op le i di ngsi nsti tuut

2 e l e ze r

Hogeschool van Amsterdam

Marjolijn Ruyg

M ajo r

B e g e l e i de r M i ra be a u

Communication & Multimedia Design

Simon Heerschap

2012 A f st udeerproj ec t Gemaakt door Antoine van der Lee Versie: 1.0

2

I O S B E V E I LI GIN G

C o lo f o n

Deze scriptie is gelicenseerd onder een Creative Commons Naamsvermelding 3.0 Nederland licentie, http://creativecommons.org/licenses/by/3.0/nl/

V o o rwo o r d Voordat u begint met het lezen van dit document wil ik mijzelf even voorstellen. Ik ben Antoine van der Lee en studeer de opleiding Communication and Multimedia Design aan de hogeschool van Amsterdam. Ik heb ervaring in het ontwikkelen van Windows Phone 7 apps en websites en heb oog voor detail. Bij een project houd ik mij dan ook niet alleen bezig met programmeren, maar ook met design, interactie en testen. In dit document richt ik mij op de beveiliging van iOS. Ik wens u veel plezier met lezen!

Student Communication and Multimedia Design 2008 - 2012

Dit document is geschreven voor de lezer met weinig programmeerkennis. Diverse begrippen zijn cursief in het groen gedrukt en terug te vinden in een begrippenlijst achterin dit verslag. Ook zijn grote stukken code uit dit onderzoek weggelaten of in de bijlage gestopt. Dit is tevens om het verslag leesbaarder te maken.

ment biedt de mogelijkheid om op verschillende links te klikken. Zo verwijzen begrippen naar hun omschrijving, bronnen naar hun bronvermelding en is de inhoudsopgave interactief.

Dit document is bedoeld voor de docenten en studenten van de Hogeschool van Amsterdam, maar ook voor medewerkers van Mirabeau. Het vormt een verslag van mijn bevindingen bij het bouwen van een beveiligd framework voor iOS. Bronnen en bijlages worden gemarkeerd met een footnote en zijn onderop de pagina terug te vinden. Achterin dit verslag staat een overzicht met alle gebruikte bronnen, begrippen en bijlages. De digitale versie van dit docu-

3

Antoine van der Lee

4

I n h o u d s o pgav e Colofon....................................................... 2 Voorwoord.................................................. 3 Inhoudsopgave.......................................... 4 Samenvatting............................................. 6 Onderzoek......................................... 6 Prototype........................................... 6 Conclusie.......................................... 7 Inleiding...................................................... 8 Aanleiding......................................... 8 Probleemstelling................................ 8 Hoofd & deelvragen.......................... 9 Doelstellingen.................................. 10 Oplevering....................................... 10 Mirabeau......................................... 11 De beveiligingsrisico's binnen het ios platform.............................................. 12 Beveiligingslekken uit het verleden...... 13 PayPal ............................................ 13 WhatsApp........................................ 13 Skype.............................................. 14 De mogelijkheden om data uit een applicatie te halen.................................... 15 Jailbreaking..................................... 15 Het injecteren van code.................. 16 De standaard beveiliging van Apple............................................... 16 Het uitvoeren van code in een draaiende applicatie........................ 17 Het monitoren van dataverkeer....... 19 Conclusie............................................. 22 Het beveiligen van de applicatie tegen de vastgestelde beveiligingsrisico's..... 24 Relevante beveiligingsrisico's voor mijn eindproduct................................... 25 Pincodebeveiliging............................... 26 Rabobank bankieren....................... 26 ING Bankieren................................. 27 AEGON Saldo check....................... 27

Het tegengaan van een brute-force aanval.............................................. 28 Het versleutelen van belangrijke data.. 30 Common Crypto.............................. 30 Het aanpassen van functies en variabelen............................................ 33 Het tegengaan van code injecties... 33 Het compliceren van code............... 34 Het detecteren van een jailbreak.... 35 Het controleren van een dataverbinding.............................. 37 Overige beveiligingsmaatregelen......... 38 Het verwijderen van bestanden....... 38 Het verwijderen van database data.38 Het invoeren van een pincode........ 39 Applicatie screenshots.................... 39 Conclusie............................................. 41 Het verifieren van de beveiliging........... 42 Het controleren van de beveiliging door Apple............................................ 43 Bedrijven met een specialisatie op het gebied van beveiliging................... 43 Conclusie............................................. 45 Het toepassen van de gevonden beveiligingoplossingen op het prototype........ 46 Het implementeren van een wachtwoord-beveiliging........................ 47 Het versleutelings-proces.................... 48 Het inbouwen van een dataversleuteling.................................. 50 Het blokkeren van debuggers.............. 51 Het tegengaan van code injecties........ 52 Het compliceren van code................... 53 Het detecteren van een jailbreak......... 54 Het controleren van een dataverbinding..................................... 55 Het verwijderen van bestanden en database data...................................... 55

5

Het managen van de keyboard cache.56 Het managen van de automatisch gemaakte applicatie screenshots......... 56 Conclusie................................................. 58 De samenhang van risico’s binnen de beveiliging van een applicatie.............. 59 Het verifiëren van de beveiliging.......... 59 Een compleet beveiligde applicatie?.... 59 Begrippen, Bronnen en Bijlages............ 60 Begrippen............................................. 61 Bronnen............................................... 63 Websites.......................................... 63 Boeken............................................ 64 Bijlages................................................ 65

Sa m en vatt i n g Dit verslag gaat over de beveiliging van applicaties op het iOS platform. Ik breng verslag van mijn ondervindingen bij het onderzoek naar de beveiligingsrisico’s binnen het platform en breng vervolgens oplossingen voor deze problemen in beeld. Verder maak ik een terugkoppeling naar het uiteindelijke prototype en omschrijf ik op welke manier de beveiliging van een applicatie geverifieerd kan worden.

On d e rzoek

6

Om een applicatie goed te kunnen beveiligen is het belangrijk om een overzicht te creëren van de beveiligingsrisico’s die aanwezig zijn. Door te kijken naar voorgekomen beveiligingslekken uit het verleden kan er geleerd worden van de fouten van anderen. Het zou tenslotte behoorlijk stom zijn om te ondervinden dat een beveiligingslek al eens eerder plaats heeft gevonden. Vervolgens ben ik zelf de hacker gaan spelen en heb ik op verschillende manieren geprobeerd data uit een applicatie te halen. Nadat alle beveiligingsrisico’s op een rijtje waren gezet ben ik op zoek gegaan naar oplossingen zodat deze risico’s uitgesloten kunnen worden. Om dit uiteindelijk te kunnen verifiëren heb ik met verschillende bedrijven contact gezocht en gekeken naar de mogelijkheden. Als laatste onderdeel heb ik een planning gecreëerd waarmee ik in de beschikbare tijd een zo goed mogelijk beveiligd framework kon realiseren.

P rototy pe Voor het prototype is er vastgesteld dat het een aantal veel voorkomende functionaliteiten dient te bevatten. Zo is het mogelijk om in te loggen en wordt er data verstuurd naar een externe server. Hierbij is de data beveiligd en wordt de verbinding gecontroleerd op een mogelijke man-in-the-middle aanval. Verder slaat de applicatie een aantal types van gebruikersdata veilig op binnen de applicatie. Deze types zijn afbeeldingen, teksten en cijfers waarmee de meeste scenario’s voor een toekomstig project zijn ingedekt. Dit alles is zo goed mogelijk beveiligd aan de hand van de resultaten uit mijn onderzoek. Uiteindelijk kan dit prototype in een korte tijd worden omgebouwd om als basis te dienen voor een toekomstig project.

Co n clu si e Om een applicatie voldoende te beveiligen dient er rekening gehouden te worden met meerdere beveiligingsrisico’s. Het implementeren van een bepaalde beveiliging kan zomaar weinig voorstellen als een andere beveiliging wordt overgeslagen.

7

Het verifiëren van applicaties is een dure investering. Voor mij als student was dit onrealistisch en dus niet te bewerkstellen. De kosten voor een professionele verificatie lopen al snel in de duizenden euro’s. Verder lijkt het onmogelijk om een applicatie compleet te beveiligen, maar is het enkel mogelijk om het een hacker zo moeilijk mogelijk te maken. Met genoeg tijd en inspanning zal er altijd een manier te vinden zijn om bij de belangrijke data te komen.

I n lei d i n g A an le i di ng De afgelopen maanden ben ik in een nieuwe wereld beland. Waar ik mij eerst voornamelijk bezig hield met het maken van websites houd ik mij nu dagelijks bezig met het maken van mobiele applicaties. In combinatie met mijn interesse in Apple en iOS heb ik mijn afstudeerproject gericht op het ontwikkelen van een applicatie voor de iPhone. Mijn opdracht doe ik in naam van Mirabeau, het bedrijf waarbij ik sinds afgelopen september al met veel plezier stage loop. In overleg met Mirabeau is er gekozen voor een beveiligd framework voor iOS. Het framework zal als basis gaan dienen voor toekomstige projecten waarbij het hoofdzaak is om belangrijke data te beveiligen.

8

Pro b leemstel l i ng Mobiele telefoons worden steeds slimmer en belangrijker. Uit onderzoek van Telecompaper bleek onlangs nog dat ruim de helft van de Nederlanders (52%) over een smartphone beschikt 1. Met veel verschillende applicaties groeit ook de persoonlijke data op een smartphone en daarmee de vraag naar beveiliging. Het is tenslotte niet de bedoeling dat persoonlijke data simpel te achterhalen is. Een voorbeeld zijn bankier applicaties. Zodra de beveiliging niet op orde is zou het zomaar zo kunnen zijn dat iemand geld kan overmaken met de rekening van een ander. 1 (Telecompaper)

Voor mij ligt hier de uitdaging om te onderzoeken welke risico’s er binnen het iOS platform bestaan. Door vervolgens voor deze risico’s de oplossingen in kaart te brengen ga ik proberen een zo goed mogelijk beveiligd framework te realiseren.

H o o f d & deel vra gen HOOFDVRAAG Hoe kan ik mijn iOS applicatie voldoende beveiligen voor het uitbrengen in de App Store?

9

DEELVRAGEN • Welke beveiligingsrisico’s spelen er op het iOS platform? ◦◦ Welke beveiligingslekken zijn er in het verleden bij andere applicaties geconstateerd? ◦◦ Welke mogelijkheden bestaan er om gegevens uit een applicatie te halen? • Hoe kan ik mijn applicatie tegen deze vastgestelde beveiligingsrisico’s beveiligen? • Hoe verifieer ik dat mijn applicatie voldoende beveiligd is? ◦◦ Worden er door Apple tests uitgevoerd om de beveiliging van een applicatie te controleren? ◦◦ Zijn er andere externe partijen welke gespecialiseerd zijn in de beveiliging van applicaties? • Hoe pas ik deze kennis toe op de realisatie van mijn applicatie? ◦◦ Welke oplossingen hebben invloed op de structuur van de applicatie? ◦◦ Welke oplossingen zijn er binnen de gestelde tijd te realiseren?

10

Do e ls tel l i ngen

O pl eve r i ng

Voor deze vragen heb ik een aantal doelstellingen vastgesteld. Naast het feit dat dit zorgt voor een duidelijk overzicht, zorgt dit er ook voor dat mijn onderzoek meetbaar wordt.

Het doel van mijn onderzoek is om een framework voor de iPhone op te leveren welke tegen de gevonden beveiligingsrisico’s beveiligd is. Mirabeau kan dit framework vervolgens in toekomstige applicaties als basis gebruiken om een applicatie op verder te bouwen. Het uiteindelijke prototype zal een aantal vaak voorkomende functionaliteiten bevatten:

De doelstellingen die ik heb opgesteld zijn als volgt: ›› Gedurende een periode van 2 dagen onderzoeken welke beveiligingslekken er in het verleden bij applicaties zijn voorgekomen ›› Gedurende een periode van 12 dagen de mogelijkheden om gegevens uit een applicatie te halen proberen vast te stellen ›› Gedurende een periode van 8 dagen oplossingen voor de geconstateerde beveiligingsrisico’s proberen vast te stellen ›› Gedurende een periode van 1 dag proberen vast te stellen of er door Apple tests uitgevoerd worden om de beveiliging van een applicatie te controleren ›› Gedurende een periode van 1 dag externe partijen welke gespecialiseerd zijn in de beveiliging van applicaties omschrijven ›› Gedurende een periode van 1 dag vaststellen welke oplossingen er binnen de gestelde ontwikkeltijd te realiseren zijn ›› Gedurende een periode van 1 dag vaststellen welke oplossingen er invloed hebben op de structuur van de applicatie

›› ›› ››

De mogelijkheid om in te loggen Het beveiligd versturen van data naar een externe server Het opslaan van gebruikersdata ◦◦ Afbeeldingen ◦◦ Teksten ◦◦ Cijfers

Dit alles dient zo goed mogelijk beveiligd te worden aan de hand van de resultaten uit mijn onderzoek. Uiteindelijk zou het mogelijk moeten zijn om aan de hand van dit framework in een korte tijd de applicatie aan te passen voor een toekomstig project.

M irab e a u Zoals al eerder aangegeven maak ik mijn afstudeerproject in opdracht van Mirabeau. Mirabeau is een mediabureau met vestigingen in Amsterdam, Rotterdam, Eindhoven, Utrecht en Hoorn.

Met een verwachte groei van 200 medewerkers in de komende 3 jaar heeft Mirabeau een ambitieuze toekomst in het vooruitzicht. Het zal de komende jaren dan ook zijn positie in de markt verstevigen en zich gaan ontwikkelen tot een van de grootste mediabureaus in Nederland.

Het bedrijf is opgericht op 2 januari 2001. De oprichters van Mirabeau waren al vroeg betrokken bij verschillende ontwikkelingen in het internet. Het bedrijf is snel gegroeid en werd in zowel 2007,2008 en 2009 door de interactieve branche uitgeroepen tot Bureau van het Jaar.

Doordat de ontwikkeling op het gebied van onlinemarketing dermate snel gaat, heeft Mirabeau er voor gekozen om verschillende partnerships af te sluiten. Mirabeau loopt voorop en heeft partnerships met de toonaangevende software leveranciers. De developers doorlopen trainingsprogramma’s en in samenwerking met de software architecten worden combinaties van pakketten en toepassingen geïmplementeerd. Naast deze specifieke software partners heeft Mirabeau partnerships met bedrijven die specifieke kennis of dienstverlening leveren.

11

Mirabeau streeft naar langdurige relaties met haar opdrachtgevers. In deze relaties worden korte en lange termijnstrategieën uitgewerkt, geanalyseerd en geoptimaliseerd. Een aantal voorbeelden van bedrijven waar Mirabeau mee samenwerkt zijn Funda, Transavia, ING en KLM.

12

I O S B E V E I LI GIN G

D e b e v e i li g i n g s r i s i c o's b i n n en h e t i o s p l at f o r m Inleidi ng Om een applicatie goed te kunnen beveiliging is het belangrijk om te weten welke beveiligingsrisico’s er überhaupt bestaan. Zonder dit gegeven is het onmogelijk om de conclusie te stellen dat de applicatie voldoende beveiligd is. In dit hoofdstuk breng ik allereerst een aantal beveiligingsrisico’s uit het verleden in kaart. Vervolgens creëer ik een overzicht van alle mogelijkheden die er bestaan om data uit een applicatie te hacken.

B e v ei li g i n g s l ek k en u i t h et v e r l ed en Wat is er mooier dan leren van de fouten van een ander? Het is een open deur waar je eigenlijk niet omheen kunt. Het zou tenslotte behoorlijk stom zijn om te ondervinden dat een beveiligingslek al eens eerder heeft plaats gevonden. Het geeft namelijk aan dat het onnodig is geweest en je de applicatie hiertegen had kunnen beveiligen.

Pay Pal PayPal is een van de applicaties waarbij een beveiligingslek naar voren is gekomen 1 . Het probleem deed zich voor bij mensen die de applicatie vanaf hun iPhone gebruikten via een onbeveiligd Wi-Fi netwerk. Het bleek mogelijk om een zogenaamde Man-in-themiddle aanval uit te voeren. Bij een dergelijke aanval wordt de data van een verbinding onderschept en kunnen belangrijke gegevens in de handen van een aanvaller terecht komen.

Afbeelding 1 - Het invoervenster voor het veranderen van een WhatsApp status

Wha ts App Ook bij WhatsApp zijn er een aantal beveiligingslekken naar voren gekomen. Zo was het mogelijk om een account te kapen door een SMS bericht te onderscheppen, konden statussen aangepast worden (Afbeelding 1) en waren chatberichten via een netwerk sniffer te onderscheppen en te bekijken 2. Op het Android platform bleken berichten zelfs onbeveiligd opgeslagen in een database welke met een simpele database tool geopend kan worden.

1  (Zwaag, PayPal iPhone-app krijgt snelle update wegens beveiligingslek)

2  WhatsApp Messenger - Onderzoeksrapport (Blz. 12)

13

In het geval van de PayPal applicatie was het mogelijk om via een Man-in-the-middle aanval de PayPal-transactiegegevens tussen de iPhone en een Wi-Fi netwerk te onderscheppen. Echter werd een update met een oplossing voor het lek binnen 24 uur nadat PayPal op de hoogte was gebracht al verzonden richting Apple.

WhatsApp had deze problemen kunnen voorkomen door de dataverbindingen beter te beveiligen. Door de data te versleutelen zouden deze beveiligingslekken niet zijn opgevallen.

Sk y p e

14

Bij Skype was het door een beveiligingslek mogelijk om het adresboek van een contact te kopiëren 3. Binnen Skype werden de chatberichten in een html-bestand opgeslagen. Het encoderen van de volledige naam van een Skype-gebruiker ging echter niet goed waardoor het mogelijk was om javascriptcode te injecteren. Zodra de contactpersoon het bericht ging lezen werden al zijn contacten doorgestuurd naar de hacker.

3  Skype - Onderzoeksrapport (Blz. 17)

D e m o g e lij k h e d e n o m d ata u i t ee n a p p l i cat i e t e h a l e n Om een applicatie goed te beveiligen is het belangrijk om te weten welke manieren er bestaan om gegevens uit een applicatie te halen. De gevonden beveiligingslekken uit het verleden brengen al een aantal risico’s naar voren: • • • • •

“Man-in-the-middle” aanval SMS Spoofen bij het verifiëren van een account Een server zonder authenticatie Het zonder versleuteling opslaan van gebruikersdata Het verkeerd encoderen van een lokaal HTML bestand waardoor Javascript code geïmplementeerd kan worden

Met behulp van het boek “Hacking and Securing iOS Applications” van Jonathan Zdziarski heb ik zelf geprobeerd bepaalde data te achterhalen. In dit hoofdstuk breng ik verslag van mijn bevindingen.

Om een beeld te krijgen hoe het hacken van een iOS applicatie in zijn werking gaat ben ik gestart met het zogenaamd jailbreaken van een iPhone 1. Jailbreaking staat voor het proces waarbij een aantal systeem beperkingen verwijderd worden. Letterlijk vertaald betekent het “gevangenis uitbraak”. Dit staat voor de beveiligde omgeving van iOS waaruit je als het ware ontsnapt (Zdziarski 38). Jailbreaking maakt het onder andere mogelijk om applicaties buiten de App Store om te installeren. Sommige applicaties worden door de App Store niet toegestaan en zijn dus niet via de App Store te downloaden. 1  Jailbreaking - Onderzoeksrapport (Blz. 19)

Onder deze applicaties vallen onder andere veel applicaties die door hackers worden gebruikt. Ook voor mij was het daarom nodig om mijn iPhone te Jailbreaken.

15

Jailb rea ki ng

H e t injec teren va n co d e Een van de mogelijkheden die een gejailbreakte iPhone biedt is het injecteren van code. Het geeft hackers de mogelijkheid om data te kopiëren, kwaadaardige of schadelijke software te injecteren of een aantal andere manieren van aanvallen uit te voeren (Zdziarski 27). Door de code automatisch op te laten starten bij het opstartproces van de iPhone wordt er een zogenaamde daemon gecreëerd. Een daemon is een programma welke op de achtergrond draait zonder dat de gebruiker het doorheeft (Zdziarski 34). Het geeft de hacker de mogelijkheid om zonder het weet van de gebruiker data te stelen of een verbinding aan te leggen met een thuisnetwerk. Een voorbeeld hiervan is dat een database met alle emailberichten bij het opstarten van de iPhone naar een server van de hacker wordt verstuurd.

16

De st a nda a rd b eve i l i gi ng va n A p p le Binnen iOS zijn er standaard al een aantal beveiligingsmaatregelen geïmplementeerd. Zo is het mogelijk om data binnen de keychain op te slaan, een zogenaamde kluis binnen iOS. De keychain wordt versleuteld

Afbeelding 2 - Het achterhalen van de pincode van een iPhone

zodra de iPhone versleuteld is. Verder zorgt Apple ervoor dat een aantal belangrijke bestanden worden versleuteld. Deze versleuteling zorgt ervoor dat bijvoorbeeld de emailberichten niet zomaar zijn in te lezen. Om deze versleuteling eraf te halen dien je te beschikken over een zogenaamde decryptiesleutel, welke vrij komt zodra de iPhone van zijn versleuteling wordt gehaald. Hierdoor zou het onmogelijk moeten zijn om bij deze data te komen zonder de weet van de pincode. De pincode beveiliging van een iPhone is echter simpel en snel te doorbreken met een zogenaamde brute-force aanval. Bij een brute-force aanval wordt elke mogelijke combinatie geprobeerd, totdat de juiste gevonden is 2. Om een dergelijke aanval uit te voeren dient de iPhone opgestart te worden met een andere opstartschijf waarop de code voor een brute-force aanval geïnstalleerd staat. Op het scherm verschijnen vervolgens alle wachtwoorden die geprobeerd zijn, totdat de juiste gevonden is. 2  (Last Bit Software)

In het boek van Jonathan staat een voorbeeldcode om deze brute-force aanval uit te voeren (Zdziarski 120). Deze code achterhaalt de pincode, vervolgens alle encryptie sleutels en maakt het daarna mogelijk om

H e t ui tvoe r e n va n code i n e e n dra a i e nde a ppl i ca ti e Naast de beveiliging van bestanden is de applicatiestructuur een belangrijk aandachtspunt. Zo is het mogelijk om functies van een applicatie uit te voeren terwijl de applicatie op de iPhone geopend is.

Het

u i t l e z e n va n d e

functies

een tekstbestand met deze gegevens via het netwerk naar de computer te kopiëren. In dit bestand staat verschillende data, waaronder de sleutels om de versleuteling van bestanden af te halen. Verder is het mogelijk om met dit bestand de versleuteling van de keychain elementen te verwijderen. Zo is het mogelijk om accountgegevens en wachtwoorden te achterhalen van verschillende services en applicaties. Het geeft aan dat de standaard encryptie van Apple onvoldoende beveiliging bied en deze data simpel te achterhalen is.

17

Afbeelding 3 - De gevonden accountgegevens

De eerste stap in dit proces is het uitlezen van de functies. Dit is nodig om te weten welke functies er bestaan en welke er dus zijn uit te voeren. Standaard zijn de applicaties van de iPhone versleuteld en is het niet mogelijk om de functies uit te lezen. Door de versleuteling van de applicatie te verwijderen is het mogelijk om deze functienamen zichtbaar te maken. Dit proces wordt ook wel reversed enginering genoemd 3.

3 (Amini)

Afbeelding 4 - Een class dump geeft een overzicht van functies en variabelen

Uiteindelijke verschijnen alle functies en variabelen van de applicatie (Afbeelding 4).

Er kon namelijk een functie worden aangeroepen waarmee het inlogscherm verdween.

In dit voorbeeld is de applicatie PhotoVault gebruikt. Deze applicatie beweert dat het afbeeldingen op de iPhone of iPad kan beveiligen. Dit gebeurt door middel van een pinbeveiliging bij het opstarten van de applicatie.

Deze applicatie geeft aan hoe simpel het is om bepaalde beveiligingen te doorbreken.

Het

Het

wijzigen of creëren

va n f u n c t i e s u i t vo e r e n va n d e

functies

18

Na het indexeren van alle functies is de volgende stap het uitvoeren van functies terwijl de applicatie geopend is. Met behulp van Jonathan’s boek bleek het mogelijk om de beveiliging van de applicatie Photovault op verschillende manieren te omzeilen 4. 4  Het omzeilen van een beveiliging met behulp van cycript - Onderzoeksrapport Bijlage 4

Het is ook mogelijk om bestaande functies te wijzigen. Hierdoor is het mogelijk om code te manipuleren en daarmee een beveiliging te omzeilen. Stel dat er bijvoorbeeld een functie bestaat die terugkeert of de pincode juist is, dan kan deze functie zodanig aangepast worden zodat de pincode altijd juist wordt bevonden. Met Cycript is het daarnaast ook mogelijk om zelf functies aan te maken. Zo is het bijvoorbeeld mogelijk om een pop-up te laten verschijnen (Afbeelding 5).

Het

wijzigen en uitlezen

va n va r i a b e l e n Naast het uitvoeren, wijzigen en creëren van functies is het tevens mogelijk om variabe-

H e t m oni tor e n va n da tave r ke e r Mobiele applicaties maken vaak gebruik van verschillende services waarbij er een verbinding wordt gemaakt met een externe server. Bij deze verbinding wordt er data via het internet verstuurd, waarna de server vaak een antwoord terugstuurt. Deze data kan belangrijke informatie bevatten en is daardoor erg interessant voor een hacker (Zdziarski 209). Een voorbeeld is een inlogsysteem waarbij het account en het wachtwoord naar een server verstuurd worden. Deze server geeft vervolgens een antwoord of het inloggen gelukt is. Een hacker zou in dit voorbeeld deze accountgegevens kunnen onderscheppen. Het is daarom belangrijk om data met een versleuteling naar een server te versturen.

om functies aan te maken en bijvoorbeeld een pop-up te laten verschijnen

len te wijzigen of uit te lezen. Zo bleek het bij de PhotoVault applicatie mogelijk om de pincode te wijzigen en vervolgens met deze pincode in te loggen 5.

5  Het wijzigen en uitlezen van variabelen - Onderzoeksrapport (Blz. 30)

A PN H i j a c k i n g APN staat voor Access Point Name en bevat alle gegevens voor een iPhone of iPad om data te versturen en te ontvangen via een netwerk (Zdziarski 209). Een hacker kan deze gegevens aanpassen zodat een verbinding eerst langs een tussenstation komt voordat het naar de buitenwereld gaat. Het

19

Afbeelding 5 - Door middel van Cycript is het mogelijk

Er zijn verschillende manieren om data te onderscheppen. Hieronder volgt een overzicht met de methodes welke voor een hacker interessant zijn.

aanpassen kan handmatig of met de tool Apple Configuration Utility. Op deze manier is het mogelijk om alle data die langs komt te monitoren en spreekt men van APN Hijacking.

P ay l o a d

delivery

De Payload Delivery methode lijkt veel op de APN Hijacking methode. Het verschil is dat de configuratie van een iPhone of iPad bij deze methode via een installatiebestand wordt aangepast (Zdziarski 212). Een voorbeeld is dat het bestand via een email verstuurd wordt met een nepbericht waarbij het lijkt alsof het bestand van Apple afkomstig is. Hierbij is de hacker dus wel afhankelijk van de gebruiker welke het bestand moet installeren (Afbeelding 6). Afbeelding 6 - Een email welke van Apple afkomstig lijkt te zijn

Een andere manier is het opzetten van een proxyserver. Een proxyserver is een computer die zich tussen het apparaat van de gebruiker en het internet bevindt 6. Bij deze methode wordt er gebruik gemaakt van de Wi-Fi verbinding van de iPhone. Door deze verbinding via de computer te laten verlopen kan de data gemonitord worden.

Om dit in te stellen dienen de Wi-Fi instellingen van de iPhone aangepast te worden. Dit kan handmatig of via een code injectie gedaan worden. Ook is het mogelijk om het net zoals de Payload Delivery methode met een installatiebestand in te stellen.

20

Proxyserver

6 (Java)

Afbeelding 7 - De onderschepte accountgegevens

21

Vervolgens kan het dataverkeer gemonitord worden met tools als SSLStrip en Paros Proxy. Deze tools creëren een overzicht van het dataverkeer tussen de proxyserver en het apparaat. Zo bleek dat de accountgegevens van mijn eigen Content Management Systeem simpel te traceren waren met SSLStrip (Afbeelding 7).

C o n c lu s i e Na een ware ontdekkingsreis als beginnende hacker sta ik vooral versteld van het feit hoe makkelijk het is om de pincode van een iPhone te achterhalen. Ik heb verschillende methodes zelf kunnen toepassen en kan daaruit de conclusie trekken dat een aantal beveiligingsimplementaties van Apple vervallen op het moment dat de pincode is ingevoerd. De versleuteling van verschillende bestanden vervalt, waaronder die van verschillende databases. Zo ook de keychain elementen waarin wachtwoorden en andere gebruikersgegevens worden opgeslagen. Als ontwikkelaar loop je een behoorlijk beveiligingsrisico als je puur op de beveiliging van iOS vertrouwd. Ook is het mij duidelijk geworden dat hackers de applicatie niet alleen van buitenaf, maar ook van binnenin kunnen bekijken. De structuur van een applicatie wordt daardoor een stuk belangrijker. Functies en variabelen zijn simpel aan te passen en geven een hacker de mogelijkheid om een applicatie flink aan te passen.

22

Naast het feit dat data binnen de applicatie veilig opgeslagen dient te worden is het ook belangrijk om uitgaande data te versleutelen. Met verschillende tools is het mogelijk om de data te onderscheppen en uit te lezen.

Al met al dient elke methode waarbij belangrijke data gebruikt wordt goed uitgedacht te worden. Hierbij lijkt het onmogelijk om de data volledig onbereikbaar te maken, maar is het vooral de kunst om het de hacker zo moeilijk mogelijk te maken.

23

24

I O S B E V E I LI GIN G

H e t b ev e i l i g en va n d e a p p li cat i e t eg en d e vast g es t el d e b ev e i li g i n g s r i s i c o's Inleidi ng Nadat ik de beveiligingsrisico’s heb vastgesteld is het zaak om voor elk risico een oplossing te vinden. In dit hoofdstuk beschrijf ik de oplossingen voor de gevonden beveiligingsrisico’s welke betrekking hebben op mijn eindproduct

Om het geheel zo overzichtelijk mogelijk te houden heb ik alle beveiligingsrisico’s die voor mijn applicatie relevant zijn nog even op een rijtje gezet:

Tevens zal ik nog een aantal overige beveiligingsmaatregelen omschrijven welke niet direct aan een beveiligingsrisico te koppelen zijn.

››

Verder heb ik twee beveiligingslekken die in het verleden zijn voorgekomen bij andere applicaties buiten mijn onderzoek gehouden. Zo bleek het bij Skype mogelijk te zijn om code te injecteren via een HTML bestand. Aangezien ik in mijn applicatie geen verbinding met de database via een HTML bestand zal laten lopen heb ik dit risico weggelaten. Een ander lek vond plaats op serverniveau waarbij het mogelijk was om WhatsApp statussen aan te passen. Dit valt buiten mijn onderzoek waardoor ik ook dit risico heb weggelaten.

››

››

››

Een viercijferige pincode is binnen een aantal minuten te achterhalen. Er zijn verschillende methodes om bestanden van de iPhone te kopiëren. Door de pincode in te voeren wordt de standaard Apple versleuteling verheven en heeft een hacker vrij doorgang. Ook de gegevens in de keychain elementen van Apple zijn te achterhalen. Er kan dus niet simpelweg op de beveiliging van iOS vertrouwd worden. Functies en variabelen kunnen uitgelezen en aangepast worden. De applicatiestructuur is dus erg belangrijk. Het moet niet mogelijk zijn om bijvoorbeeld een inlogscherm te omzeilen door simpelweg een functie aan te passen. Dataverkeer vanuit de applicatie naar een externe server kan door middel van een aantal tools makkelijk onderschept worden. Het inlezen van deze data is voor een hacker daardoor een fluitje van een cent.

25

R el e va n t e b ev e i li g i n g s r i s i c o ' s v o o r m ij n e i n d p r o d u c t

P i n c o d e b ev ei l i g i n g Uit het vorige hoofdstuk bleek dat een viercijferige pincode binnen enkele minuten te achterhalen is. Door een zogenaamde brute-force aanval worden alle pincodes geprobeerd, totdat de juiste gevonden is. Met deze juiste pincode is vervolgens alle data te bereiken. Om vast te stellen wat de juiste oplossing voor dit probleem is ben ik de applicaties van de Rabobank, de ING en Aegon gaan bekijken. Bij deze bankierapplicaties is beveiliging een belangrijk onderdeel. Uiteindelijk heb ik uit al deze verschillende applicaties de pluspunten gefilterd en deze gecombineerd om tot een zo goed mogelijke beveiliging te komen.

Rab o ba nk ba nki er e n Om gebruik te maken van de Rabobank applicatie dient een gebruiker allereerst zijn telefoon te registreren met behulp van een Random Reader. Een Random Reader is een authenticatiemiddel welke aan de hand van de pincode van de gebruiker en een gegeven code een inlogcode genereert. Met deze inlogcode kan de gebruiker zijn rekeningnummer valideren.

26

Vervolgens wordt er aan de gebruiker gevraagd om een pincode van vijf cijfers te kiezen. Dit in tegenstelling tot de viercijferige pincode van de iPhone. Het inloggen werkt niet zonder een internetverbinding, wat aangeeft dat de authenticatie op serverniveau plaatsvind. Ook is de juiste pincode daardoor niet in het geheugen van de telefoon te vinden. Dit blijkt ook uit het uitlezen van de keychain, waarbij er geen gegevens van de Rabobank applicatie te vinden zijn.

Afbeelding 8 - Het inlogscherm van de Rabobank App

Het

vo o r d e e l va n e e n

vijfcijferige pincode

vindt de authenticatie op serverniveau plaats en is de pincode niet in het geheugen terug te vinden.

Een voordeel van een langere pincode is dat er meerdere mogelijkheden zijn. Met vier cijfers zijn er 10 000 mogelijkheden en met vijf cijfers zijn dat er 100 000. Het aantal mogelijkheden vertienvoudigd en zorgt ervoor dat een Brute-force aanval meerdere mogelijkheden langs moet gaan. Een brute-force aanval is hierdoor niet uitgesloten, maar het kost een hacker waarschijnlijk wel een stuk meer tijd om de pincode te achterhalen. Echter zal het account bij meerdere keren verkeerd inloggen waarschijnlijk geblokkeerd worden.

ING B anki eren

Net als de Rabobank applicatie maakt ING gebruik van een vijfcijferige inlogcode. Ook 1  (Zwaag, ING Bankieren: vernieuwende app voor mobiel bankieren op iPhone, iPad en Android) 2 (ING)

Afbeelding 9 - Het koppelen van een rekeningnummer ing de ING app

AE G O N Sa l do che ck De AEGON saldo check applicatie verschilt qua inloggen met de applicatie van ING en de Rabobank. Het maakt namelijk gebruik van een gebruikersnaam en wachtwoord in plaats van een rekeningnummer met pincode. Een groot voordeel van een wachtwoord is dat er veel meer mogelijkheden zijn. De

27

De applicatie van de ING vraagt bij de eerste keer opstarten om een aantal gegevens van de gebruiker 1. Als deze gegevens kloppen wordt er om een bevestigingscode gevraagd. Deze code is op te halen via Mijn ING, waarbij er eenmalig een TAN-code nodig is. Een TAN-code bestaat uit zes cijfers en wordt vanuit ING gratis per sms verzonden 2. Vervolgens dient de gebruiker een pincode van vijf cijfers op te geven. In het vervolg is enkel deze pincode nodig om in te loggen.

lengte is variabel en in tegenstelling tot cijfers zijn er bij letters 26 mogelijkheden. Daarnaast kunnen er ook hoofdletters en cijfers gebruikt worden. Dit zorgt voor een totaal van 62 mogelijkheden per ingevoerde karakter. Het spreekt voor zich dat het bij een brute-force aanval meer tijd kost om een dergelijk wachtwoord te achterhalen. Bovendien is de lengte van het wachtwoord niet bekend, waardoor het aantal mogelijkheden verder toeneemt.

H e t te g e ng a a n va n e e n br ute - force a a nva l Om een inlogsysteem veilig te maken dient er rekening gehouden te worden met een brute-force aanval. Het is een methode die door hackers gebruikt wordt om wachtwoorden te achterhalen door simpelweg elke mogelijkheid uit te proberen. Na contact te hebben gezocht met meerdere beveiligingsbedrijven bleek dat er met een geavanceerd systeem meer dan 300 miljoen pogingen per seconde geprobeerd kunnen worden. Een inlogsysteem zonder authenticatie op server niveau zal daarom snel te doorbreken zijn. Om het systeem daarnaast veilig genoeg te maken is het verstandig om voor een wachtwoord te kiezen met veel verschillende mogelijkheden, maar het is ook belangrijk om te kijken naar het gedrag van de mens bij het gebruik van een wachtwoord. Uit een onderzoek van Daniel Amitay blijkt dat veel iPhone gebruikers een simpel patroon gebruiken bij hun pincode 3. Daniel registreerde 204.508 pincodes en concludeerde dat er 8884 keer de pincode 1234 gebruikt werd en 5246 keer de pincode 0000. In totaal bleek dat 15% van de pincodes uit een simpel patroon bestonden.

28

Afbeelding 10 - Het inlogscherm van de AEGON app

3 (Amitay)

Uit deze resultaten kunnen een aantal conclusies getrokken worden. Veel gebruikers kiezen hetzelfde wachtwoord voor verschillende toepassingen. Ook wordt er vaak een simpel te onthouden wachtwoord gekozen. Een pincode van vier cijfers is daarom geen goede keus, aangezien de kans vrij groot is dat de gebruiker dezelfde gebruikt als voor hun iPhone vergrendeling. Er zijn verschillende manieren om te voorkomen dat de gebruiker een simpel patroon of een makkelijk te raden wachtwoord kiest. Een van de mogelijkheden is om de gebruiker een wachtwoord toe te sturen. Hiermee houd je de sterkte van het wachtwoord in eigen hand en ontneem je de gebruiker de mogelijkheid om een bekend patroon te kiezen. Dit kan tegelijkertijd voor ergernis zorgen bij de gebruiker. Hij dient tenslotte een nieuw patroon uit zijn hoofd te leren. Een andere optie is het vastzetten van een patroon. Door de gebruiker te forceren om 4  (PC Tools)

naast cijfers ook letters te gebruiken dwing je de gebruiker om een lastiger wachtwoord te kiezen. Echter houd de gebruiker wel de mogelijkheid om een voor hem bekend wachtwoord te nemen. Hierbij is het wel belangrijk om te zorgen dat er genoeg combinaties overblijven. De beste oplossing lijkt een combinatie van deze twee mogelijkheden. Door een combinatie van twee letters met vijf cijfers te gebruiken ontstaat er een wachtwoord met 67.600.000 mogelijkheden. Door de twee letters vast te zetten en de gebruiker de mogelijkheid te geven de vijf cijfers zelf in te vullen worden de twee mogelijkheden gecombineerd. Het resultaat is uiteindelijk een wachtwoord welke met een brute-force aanval lastig te achterhalen is. Het geeft de gebruiker voldoende tijd om zijn account bij diefstal van zijn iPhone te deactiveren. Deze maatregelen in combinatie met authenticatie op serverniveau moeten een brute-force aanval door een hacker zo goed als uitsluiten.

29

Uit een ander onderzoek van PC Tools blijkt dat 45% van de bevolking uit de Benelux op alle websites die het bezoekt hetzelfde wachtwoord gebruikt 4. Dit gegeven zou er voor gezorgd kunnen hebben dat ING en Rabobank voor een pincode van vijf cijfers gekozen hebben. De pincode van een iPhone bleek namelijk simpel te achterhalen en uitgaande van dit onderzoek is de kans dat de pincode van de iPhone hetzelfde is als de pincode van andere applicaties tenslotte 45%.

H e t v e rs leu t el en va n b ela n g r ij k e data Binnen een applicatie zijn er verschillende data welke versleutelt dient te worden. Zo zijn er bestanden als een database of afbeeldingen, maar dienen ook wachtwoorden na het invoeren direct versleuteld te worden.

Co mmon Cr ypto Jonathan behandeld in zijn boek een handige tool bij het versleutelen van data genaamd Common Crypto (Zdziarski 244). Deze tool bied een aantal verschillende manieren van versleutelen en is standaard beschikbaar binnen het framework van de iPhone.

30

De soorten versleutelingen verschillen in sterkte en zijn niet allemaal even geschikt voor elke applicatie. Een standaard encryptie maakt gebruik van één sleutel genaamd de master sleutel. Er ontstaat echter een probleem, want waar slaan we deze encryptie sleutel in op? De keychain bleek namelijk simpel te achterhalen en ook variabelen zijn uit te lezen. Een oplossing voor dit probleem is het gebruiken van een zogenaamde master sleutel encryptie . Data wordt versleuteld met behulp van de master sleutel, maar de master sleutel wordt los daarvan nog versleuteld met een wachtwoord.

Om de versleuteling van een bestand te verwijderen is dus allereerst het wachtwoord nodig. Met het wachtwoord kan de master sleutel achterhaald worden om hier vervolgens de versleuteling van de data mee te verwijderen. Deze methode heeft als voordeel dat de master sleutel nooit aangepast hoeft te worden. Stel dat de gebruiker zijn wachtwoord aanpast, dient enkel de master sleutel opnieuw versleuteld te worden. In het geval dat het wachtwoord direct gebruikt zou worden om alle data te versleutelen zou alle data opnieuw versleuteld moeten worden met het nieuwe wachtwoord. Daarnaast is het mogelijk om de master sleutel aan de hand van een geheime vraag te versleutelen. Deze sleutel kan dan gebruikt worden in het geval dat de gebruiker zijn wachtwoord vergeet.

Afbeelding 11 - Het versleutelproces met een openbare en geheime sleutel

In het voorbeeld is de linker persoon Alice en de rechter persoon Bob. Het boek omschrijft de versleuteling als volgt: “Veronderstel dat Alice wil communiceren met Bob. Zoals is weergegeven in afbeelding 8.6 gebruiken Bob en Alice in plaats van één geheime sleutel (zoals bij de symmetrische sleutelsystemen), twee sleutels. Bob (de ontvanger van de berichten van Alice) heeft twee sleutels; een openbare sleutel die iedereen (inclusief Trudy de indringer) kent en een geheime sleutel die alleen Bob kent.” 1  (Kurose and Ross)

In het geval van een iPhone applicatie is Alice de gebruiker en Bob de applicatie. Binnen de applicatie is er dus naast het wachtwoord van Alice nog een andere sleutel bekend. Alle data wordt eerst met de openbare sleutel versleutelt en vervolgens nog eens met de geheime sleutel. Bij deze methode dient een hacker naast de openbare sleutel ook de geheime sleutel te achterhalen.

31

Het boek Computer netwerken van James F. Kurose en Keith W. Ross omschrijft deze manier van versleutelen aan de hand van een afbeelding (Afbeelding 11) 1.

Bij deze manier van versleutelen wordt er gebruik gemaakt van “iets wat je hebt” (de data en de master sleutel) en “iets wat je weet” (het wachtwoord). Dit wordt ook wel een Key Derivation Function genoemd. Key Derivation Functions hebben een aantal voordelen: ›› De tijd van het ophalen van een sleutel kan beïnvloed worden. Dit kan gebruikt worden om een brute-force aanval te vertragen. ›› Naast het wachtwoord kunnen er meerdere waardes gebruikt worden voor een versleuteling ◦◦ Bijv. het toestel identificatienummer, coördinaten of een bepaalde tijd. ›› Het biedt de mogelijkheid om de lengte van de sleutel te bepalen. Om naast deze methode gebruik te maken van een externe server kan er nog een extra sleutel gebruikt worden. Deze sleutel wordt bewaard op een server en pas vrijgegeven zodra de gebruiker is ingelogd.

32

Om de versleuteling van de master sleutel te verwijderen dient de hacker naast het wachtwoord ook de andere waardes te achterhalen. De tijd die hier voor nodig is zal al snel oplopen tot een maand, waardoor de gebruiker genoeg tijd heeft om zijn account af te sluiten.

H et aa n pass en va n f u n ct i es e n va r i a b el en Hackers hebben de mogelijkheid om op een draaiende applicatie in te haken door middel van een debugger. Hiermee kunnen ze functies en variabelen aanpassen. Ook zijn variabelen uit te lezen. Om dit tegen te gaan dient het geheugen beveiligd te worden. Jonathan geeft in zijn boek een aantal preventieve handelingen die het de hacker al een stuk moeilijker maakt (Zdziarski 264): • • • •

Sla nooit belangrijke data in het geheugen op voordat een gebruiker is ingelogd. Bewaar belangrijke data niet in instance variabelen welke simpel zijn uit te lezen. Bewaar geen verwijzing naar belangrijke sleutels in instance variabelen. Bewaar belangrijke data alleen in het geheugen op het moment dat je ze gebruikt.

H et t egenga a n va n co d e inj ec ti es

33

Een van de eerste methodes die hackers uitproberen is het aanpassen en toevoegen van functies (Zdziarski 295). Deze manier van hacken is tegen te gaan door functies te controleren voor ze worden uitgevoerd. Geïnjecteerde code beland in zogenaamde address space, oftewel, een ruimte binnen het geheugen. Binnen de address space kan er gekeken worden waar functies vandaan komen.

Als een functie niet vanuit de applicatie of het framework van Apple komt kan het opstarten onderbroken worden. Het komt dan namelijk van een onbekende bron zoals bijvoorbeeld een code injectie (Afbeelding 12). De functies worden gevalideerd en op het moment dat de geïnjecteerde code langs komt wordt het proces gestopt.

Afbeelding 12 - Het valideren van functies

Inline

functies

Het uitvoeren van code injecties is hiermee nog niet onmogelijk. De hacker dient echter de code in bestaande functies te injecteren wat het proces vooral moeilijker maakt. Dit wordt bijvoorbeeld met een tool als Cycript gedaan. Om dit tegen te gaan kan er in elke functie een authenticatiecheck geplaatst worden. Echter is het mogelijk om met een debugger simpele checks uit te schakelen 1. Hiervoor dient de naam van de check bekend te zijn, welke te achterhalen is met de tool Otool (Afbeelding 13).

Afbeelding 13 - Het overzicht van Otool laat zien dat de functie is_session_valid wordt aangeroepen

34

Door deze functie inline te maken is hij niet meer te vinden via een tool als Otool (Zdziarski 306). Met het inline maken van een functie wordt er geen functie meer aangeroepen, maar wordt de daadwerkelijke code van de functie gekopieerd op de locatie waar het wordt aangeroepen 2. Hierdoor is het niet meer mogelijk om simpelweg de functie voor het authentiseren aan te passen, maar dient de code op elke plek waar het wordt aangeroepen omzeilt te worden.

1  Het uitschakelen van checks met behulp van een debugger - Onderzoeksrapport Bijlage 6 2  Het verschil tussen een normale en een inline functie - Onderzoeksrapport Bijlage 7

H e t com pl i ce r e n van code Door de code van een applicatie te compliceren wordt de code een stuk minder leesbaar voor een hacker. Er zijn verschillende manieren om dit te doen.

O p t i m a l i s at i e

flags

Een van de mogelijkheden is het toevoegen van optimalisatie flags (Zdziarski 313-317). Deze flags beïnvloeden het compileren van code en zorgen ervoor dat de code geoptimaliseerd wordt. Daarnaast zorgt het ervoor dat de code complexer en daardoor bij een symbol table dump vaak minder leesbaar wordt. Echter kan het er in sommige gevallen ook voor zorgen dat de code leesbaarder wordt doordat er veel wordt weggelaten. Een symbol table dump genereerd een overzicht van methodes en variabelen in assembly taal waarbij onder andere het geheugenadres is uit te lezen. Het gebruiken van optimalisatie flags komt vooral tot zijn recht als het beveiligen van variabelen belangrijker is dan het beveiligen van functies. Alle toewijzingen van variabelen worden namelijk onzichtbaar, terwijl functies nog steeds leesbaar zijn.

S t r i pp i n g Door de code van een applicatie te strippen verdwijnen ook de functies bij een symbol table dump (Zdziarski 317-323). Stel dat er een functie als “check_op_debuggers” wordt gebruikt, een hacker maakt een symbol table dump, ziet deze functienaam en zorgt ervoor dat deze functie wordt uitgeschakeld. Het wordt een stuk moeilijker als deze functienamen niet uit te lezen zijn met een symbol table dump 3. In combinatie met het eerder genoemde inline maken van een functie zou er voor zorgen dat een hacker aanzienlijk meer tijd nodig heeft om een applicatie te hacken.

Funroll-loops Een laatste methode is het toevoegen van zogenaamde funroll-loops (Zdziarski 323-326). Een funroll-loop zorgt ervoor dat een loop in een symbol table dump herhaalt wordt. Als er binnen deze loop bijvoorbeeld een securitycheck wordt gedaan dan dient een hacker niet één keer, maar meerdere keren deze check te omzeilen 4. Net als de eerder genoemde methodes wordt het injecteren van code hiermee niet uitgesloten, maar vooral bemoeilijkt.

H e t de te cte r e n va n e e n ja i l br e a k Alle eerder genoemde methodes zijn enkel mogelijk op een gejailbreakte iPhone. Een jailbreak zorgt ervoor dat bepaalde beveiligingen worden verwijderd en verschillende tools geïnstalleerd kunnen worden. Door te detecteren of een toestel gejailbreakt is kunnen veel methodes uitgesloten worden. Op het moment dat er een jailbreak gedetecteerd is kan er op een passende manier gereageerd worden door bijvoorbeeld de applicatie af te sluiten of data te verwijderen. Er zijn verschillende manieren om een jailbreak te detecteren 5: ›› Het testen van bepaalde functies die met een jailbreak niet meer werken. ›› Het zoeken naar jailbreak gerelateerde applicaties ›› Het controleren van de bestandsgrote van het bestand ”/etc/fstab” ›› Het controleren op omgeleide folders Het blijft echter wel mogelijk om deze check te omzeilen. In combinatie met eerder genoemde methodes zal het wel behoorlijk lastig worden om de functie te vinden en vervolgens uit te schakelen. Bovendien heeft een applicatie geen waarde meer in het geval dat de data bij het vinden van een jailbreak verwijderd zou worden.

4  Het verschil na het implementeren van een funrollloop - Onderzoeksrapport Bijlage 9

35

3  Het verschil na het strippen van code - Onderzoeksrapport Bijlage 8 5  Het detecteren van een jailbreak - Onderzoeksrapport Bijlage 10

Belangrijke data valt dan niet meer te achterhalen, tenzij de hacker een back-up van de applicatie zou hebben gemaakt. Echter kan de data door de gebruiker ook niet meer achterhaald worden, tenzij het extern staat opgeslagen.

36

Daarnaast sluit je met deze check een behoorlijk aantal gebruikers uit. Alle gebruikers met een gejailbreakte iPhone kunnen de applicaties tenslotte niet meer gebruiken. Het maakt de applicatie dus een stuk veiliger, maar heeft ook zo zijn nadelen.

H et c o n t ro l er en va n e en datav e r b i n d i n g Uit onderzoek bleek dat met een zogenaamde Man-in-the-middle aanval een dataverbinding kan worden afgeluisterd. Zo is het bijvoorbeeld mogelijk om belangrijke data zoals gebruikersgegevens te onderscheppen of certificaten te kopiëren. Door een certificaat te kopiëren kan een hacker zich voordoen als een gebruiker en daarmee belangrijke data ontvangen van een server. Het is dus belangrijk om een dataverbinding te controleren voordat er data verstuurd wordt. Apple heeft een standaard beveiliging in iOS gebouwd waarmee een dataverbinding wordt gevalideerd, namelijk SSL. Daardoor is het niet mogelijk om bijvoorbeeld naar een website te navigeren zodra een verbinding als onveilig wordt gezien (Afbeelding 14).

In combinatie met de eerder genoemde maatregelen waarmee de applicatie wordt beveiligd is het daardoor voor een hacker erg lastig om een dataverbinding af te luisteren. Echter blijft het niet onmogelijk doordat de mogelijkheid bestaat dat ook deze checks omzeilt worden. Daarom is het belangrijk om naast deze preventieve maatregelen de data altijd versleuteld te versturen.

Afbeelding 14 - De verbinding mislukt omdat de verbinding als onveilig wordt gezien

37

SSL staat voor Secure Sockets Layer en zorgt voor het versleutelen en verifiëren van gegevens tussen een applicatie en een server (Kurose and Ross 726). Zonder deze beveiliging is een dataverbinding met verschillende tools simpel af te luisteren. Echter blijkt dat de standaard check binnen iOS simpel te omzeilen is 1. Dit gebeurt door middel van een code injectie. Het is daarom belangrijk om in de applicatie zelf ook de dataverbinding te controleren. Jonathan geeft hiervoor een voorbeeldcode in zijn boek (Zdziarski 298).

De code controleert de verbinding en checkt tevens of er code geïnjecteerd is waarmee de SSL beveiliging omzeilt kan worden.

1  Het omzeilen van de standaard SSL beveiliging Onderzoeksrapport Bijlage 11

Ov e r i g e b e v e i l i g i n g s m aat r e g e len Buiten de geconstateerde beveiligingsrisico’s zijn er nog een aantal maatregelen welke de applicatie beveiligen.

H e t verwi j deren va n b e st anden In het geval dat een applicatie een bestand verwijderd is het voor een hacker vaak nog mogelijk om dit bestand te achterhalen. Om dit tegen te gaan dient een bestand eerst geleegd te worden voordat het daadwerkelijk verwijderd wordt. Jonathan geeft hiervoor een voorbeeldcode in zijn boek (Zdziarski 273). Hiermee verliest het bestand zijn waarde en heeft een hacker er weinig meer aan.

Key boa r d ca che Om het automatisch corrigeren van teksten goed te laten werken wordt alle keyboard input opgeslagen. Hierdoor bouwt iOS een bibliotheek aan woorden op en kan het in het vervolg woorden voor de gebruiker aangeven of corrigeren (Zdziarski 283). Er zijn echter een aantal uitzonderingen: ››

››

38

H e t verwi j deren va n d at aba se da ta Net als bij het verwijderen van bestanden blijft ook database data opgeslagen ondanks dat het verwijderd lijkt te zijn. Om dit te voorkomen is een speciale manier van verwijderen nodig. Door in plaats van een verwijder query een update query te gebruiken en de data te vervangen met de zeroblob functie verdwijnt de data uit het geheugen (Zdziarski 282). De zeroblob functie veranderd elk karakter in een 0 waardoor het geen ruimte meer in het geheugen in beslag neemt.

››

››

Data uit tekstvelden die gemarkeerd zijn als een input voor wachtwoorden worden niet opgeslagen. Teksten met alleen getallen worden niet opgeslagen. Dit is vooral om te voorkomen dat rekeningnummers en dergelijke kunnen worden achterhaald. Data uit tekstvelden waarbij autocorrect is uitgeschakeld worden niet opgeslagen. Kleine woorden worden niet altijd opgeslagen.

Het is dus vrij simpel om dit tegen te gaan. Door het automatisch corrigeren in een tekstveld uit te zetten zal er geen input worden opgeslagen. Ook kan dit probleem worden opgelost door het tekstveld als wachtwoordveld in te stellen. Als laatste is het ook nog mogelijk om het kopiëren en plakken van teksten uit te zetten.

Hoe goed je een applicatie ook beveiligt, je vertrouwd uiteindelijk op de gebruiker die de pincode weet. Daarmee komt er nog een beveiligingsprobleem om de hoek kijken. Het zou zomaar zo kunnen zijn dat er iemand over zijn schouder meekijkt. Doordat iOS overal hetzelfde toetsenbord gebruikt voor het invoeren van getallen kan deze persoon de pincode simpel aflezen. Jonathan komt met een oplossing voor dit probleem (Zdziarski 285). Door een ander toetsenbord te gebruiken dan het origineel is het mogelijk om de getallen in willekeurige volgorde terug te laten keren (Afbeelding 15). Hierdoor is het voor iemand die meekijkt een stuk lastiger om te zien welke pincode er wordt ingevoerd. Het kan echter ook voor irritatie bij de gebruiker zorgen doordat een vast patroon wordt doorbroken. Dit is echter iets om uit te zoeken met een gebruikerstest.

Afbeelding 15 - Het invoerscherm met de cijfers in willekeurige volgorde

Appl i ca ti e s cr e e ns hots Op het moment dat een applicatie naar de achtergrond verdwijnt wordt er een screenshots van het huidige scherm gemaakt. Dit wordt gedaan om een soepele overgang te creëren op het moment dat de applicatie weer wordt geopend. Zo zou het zomaar zo kunnen zijn dat een gebruiker zijn rekening heeft bekeken en vervolgens een andere applicatie opent. De applicatie wordt hierbij niet afgesloten, maar in het geheugen bewaard. In de afbeelding zou in dit geval zijn rekening te zien zijn. Doordat deze screenshots niet worden verwijderd is het mogelijk om deze afbeeldingen te achterhalen.

39

H et in voeren va n e e n p inc ode

Afbeelding 16 - De code om ervoor te zorgen dat de automatisch opgeslagen afbeeldingen geen belangrijke data bevatten

40

Om dit tegen te gaan dient het scherm geleegd te worden voordat de afbeelding gemaakt wordt (Zdziarski 285). Jonathan geeft hiervoor een voorbeeldcode (Afbeelding 16).

C o n c lu s i e Voor elk gevonden risico is er een oplossing, maar het lijkt onmogelijk om een hacker volledig tegen te houden. Met genoeg tijd en kennis zal er in elke applicatie wel een gaatje gevonden worden om data te achterhalen. Het is alleen zaak het zo moeilijk mogelijk te maken waardoor het voor hacker een stuk minder interessant wordt.

41

Bepaalde beveiligingen zijn afhankelijk van andere. Een functie om een dataverbinding te controleren kan simpel omzeilt worden als functies en variabelen zonder problemen zijn uit te lezen. Het is dus zaak om alle beveiligingsrisico’s uit te sluiten.

I O S B E V E I LI GIN G 42

H e t v e r i f i er en va n d e b e v e i li g i n g Inleidi ng Om er zeker van te zijn dat een applicatie voldoende beveiligd is dient de beveiliging van mijn applicatie gecontroleerd te worden. In dit hoofdstuk breng in de manieren om de beveiliging van een applicatie te verifiëren in kaart.

Voordat een applicatie in de App Store gepubliceerd wordt dient deze gesigneerd te worden. Geregistreerde developers kunnen hun eigen applicatie signeren en naar de App Store versturen. Alleen gesigneerde applicaties worden door de App Store geaccepteerd. Dit zorgt ervoor dat een applicatie waarmee geknoeid is niet zomaar uitgebracht kan worden 1. Nadat een applicatie bij Apple is binnengekomen wordt deze getest op verschillende punten aan de hand van Apple’s richtlijnen 2. Hierbij wordt er bijvoorbeeld gecontroleerd of een applicatie niet crasht, maar wordt er ook gecontroleerd op verdachte functionaliteiten. Dit is om te voorkomen dat er een applicatie in de App Store terecht komt met slechte bedoelingen. Er wordt echter niet gecontroleerd of een applicatie goed beveiligd is tegen de verschillende hack methodes. Een applicatie is dus niet per definitie veilig op het moment dat deze succesvol aan de App Store is toegevoegd.

B e dr i jve n m e t e e n s pe ci a l i sa ti e op he t g e bi e d va n beve i l i g i ng Er zijn verschillende bedrijven die zich bezig houden met het testen van de beveiliging van applicaties. Dit gebeurt niet alleen bij mobiele applicaties, maar ook bij bijvoorbeeld websites. Een dergelijke test wordt ook wel penetration testing genoemd. Delen van deze test kunnen geautomatiseerd worden, maar er zijn ook onderdelen die handmatig moeten worden gedaan. Het belangrijkste doel van een penetration test is het bepalen van de kwetsbaarheden in een beveiliging 3.

43

H et co ntrol eren va n d e b evei l i gi ng door Ap p le

1  (Apple, Deploying iPhone and iPage) 2  (Apple, App Store Review Guidelines)

3 (Marqit)

DELL

››

Dell is een van de bedrijven die zich hiermee bezig houd en test een applicatie op drie verschillende manieren:

›› ›› ››

››

Mobile Application Security Best Practices Review ◦◦ Controleert het design en test de beveiliging via de user-interface. ›› Mobile Application Technical Assessment ◦◦ Betreft een handmatige test waarbij er gericht getest wordt om de beveiliging te doorbreken. ›› Webservice or API Testing ◦◦ Controleert verschillende dataverbindingen en gebruikte API’s. Dell bied verder voor 12 maanden service met als uitgangspunt een zo goed mogelijk beveiligde applicatie te realiseren 4.

Viaforensics Een andere bedrijf welke zich bezig houd met de beveiliging van applicaties is viaForensics 5. Bij dit bedrijf wordt een applicatie op de volgende punten getest: ››

44

››

Het managen van browsegeschiedenis en opgeslagen data Het testen op een Man-in-the-middle aanval

4 (Dell) 5 (viaForensics)

›› ››

et permanent verwijderen van beH standen De beveiliging van een inlogscherm De beveiliging van dataverbindingen De beveiliging tegen debuggers en andere tools die een applicatie kunnen manipuleren terwijl de applicatie geopend is De beveiliging bij onverwachtse on derbrekingen De beveiliging van data in een backup

Als alle tests succesvol worden doorstaan krijgt de applicatie een certificaat om aan te geven dat de beveiliging van de applicatie op orde is.

Verizon Verizon is een internationaal bedrijf wat zich bezig houd met meerdere services. Een van deze services is mobiele beveiliging. In een email is mij verteld op welke onderdelen er onder andere getest wordt: ›› ›› ››

Het testen op een brute-force aanval De beveiliging van dataverbindingen De beveiliging tegen debuggers

Daarnaast wordt er een code review uitgevoerd om beveiligingsrisico’s naar boven te krijgen. Per dag wordt er €950 tot €1200 in rekening gebracht. De kortste test die ze uitvoeren duurt drie dagen en de langste soms wel eens 30. Een dergelijke test kan dus flink in de kosten lopen.

Secure

a pp s

Het Nederlandse bedrijf Secure Apps bied een security scan aan inclusief met een code review 6. “Deze code review creëert een goed beeld van de sterke en zwakke punten van de veiligheid van uw app”, aldus Secure Apps. Vervolgens wordt er aan de hand van deze resultaten een security scan gedaan. De resultaten uit deze scan worden vervolgens uitgebreid gepresenteerd en in een rapport aangeleverd.

C oncl us i e Om er zeker van te zijn dat een applicatie goed beveiligd is kan er niet op Apple vertrouwd worden. De checks die vanuit Apple gedaan worden zijn niet gericht op de beveiliging van applicaties. Een andere mogelijkheid is het inhuren van een extern bedrijf die zich richt op de beveiliging van mobiele applicaties. De kosten om een dergelijk bedrijf in te huren lopen echter al snel in de duizenden euro’s. Voor mij als student is het daarom onrealistisch om de beveiliging te laten verifiëren.

Een enkele code review kost bij Secure Apps €2000 en een complete security scan inclusief code review kost €4000. Om er zeker van te zijn dat een applicatie goed beveiligd is kan er niet op Apple vertrouwd worden. De checks die vanuit Apple gedaan worden zijn niet gericht op de beveiliging van applicaties.

45

Een andere mogelijkheid is het inhuren van een extern bedrijf die zich richt op de beveiliging van mobiele applicaties. De kosten om een dergelijk bedrijf in te huren lopen echter al snel in de duizenden euro’s. Voor mij als student is het daarom onrealistisch om de beveiliging te laten verifiëren.

6  (Secure Apps)

H e t t o epass en va n d e g evo n d en b ev e i li g i n g o p l o s s i n g en o p h et p rototy p e Inleidi ng

46

I O S B E V E I LI GIN G

Nadat de beveiligingsrisico’s zijn vastgesteld en de oplossingen in kaart zijn gebracht is het zaak om deze bevindingen toe te passen op het eindproduct. Om het overzichtelijk te houden zet ik eerst alle nodige beveiligingsimplementaties nog even op een rij: › › › › › › › › › › ›

Het implementeren van een wachtwoordbeveiliging Het inbouwen van een dataversleuteling Het blokkeren van debuggers Het tegengaan van code injecties Het compliceren van code Het detecteren van een jailbreak Het controleren van een dataverbinding Het verwijderen van bestanden Het verwijderen van database data Het managen van de keyboard cache Het managen van de automatisch gemaakte applicatie screenshots

In het komende hoofdstuk zal ik per onderdeel de terugkoppeling maken naar het gecreëerde prototype.

H et im pl ementeren van ee n wach t woordb eve ili gi ng Een van de belangrijkste beveiligingsimplementaties is de wachtwoordbeveiliging. Het vormt de ingang voor gebruikers om bij de beveiligde data te komen. Zodra dit onderdeel niet goed beveiligd is, wordt het voor een hacker een stuk makkelijker om bij zijn einddoel te komen.

Het

design

Het design van het inlogscherm is niet meer dan twee invulvelden en een inlogbutton. In mijn eerste ontwerp hielp ik de gebruiker door het patroon van het wachtwoord in het design terug te laten komen (Afbeelding 17). Echter geeft dit de hacker ook een duidelijk aanwijzing en een flinke voorsprong bij het achterhalen van het wachtwoord. Verder heb ik er voor gekozen om de gebruikersnaam niet te onthouden, in tegenstelling tot de onderzochte bankieren applicaties. De gebruikersnaam wordt namelijk meegenomen in het versleutelingsproces en door deze geheim te houden dient de hacker nog een onderdeel te achterhalen. Het uiteindelijke design is dan ook niet meer dan twee invulvelden met een placeholder (Afbeelding 18).

47

Uit mijn onderzoek bleek dat een wachtwoordbeveiliging zonder authenticatie op serverniveau niet veilig genoeg was. Bij het inloggen wordt er daarom gecommuniceerd met een server welke een sleutel terugkeert op het moment dat er juist is ingelogd.

Voor het type wachtwoord is er gekozen voor een combinatie van cijfers en letters. Hierbij worden de eerste twee letters voor de gebruiker gekozen en kan de gebruiker de laatste 5 cijfers zelf kiezen. Hierdoor wordt er voorkomen dat de gebruiker een simpel te herkennen patroon kiest of dezelfde pincode als voor het ontsleutelen van de iPhone.

Afbeelding 17 - Het oude design

Afbeelding 18 - Het nieuwe design

48

H e t versl eutel i ngs p ro ce s Zodra de gebruiker inlogt wordt er een versleutelingsproces opgestart. Hierbij wordt er een zogenaamde hoofdsleutel gecreëerd door middel van een aantal iteraties. Uiteindelijk wordt alle data met deze hoofdsleutel versleuteld en ontsleuteld.

3.

Tijdens het bouwen van deze implementatie kwam ik er door een extern bedrijf achter dat mijn wachtwoordsysteem niet veilig genoeg was en er authenticatie op serverniveau nodig was. Hierdoor moest er een versleuteld pakket naar de server gestuurd worden welke vervolgens op de server weer ontsleuteld kon worden. Mijn eerste versleuteling was dan ook niet veilig genoeg 1.

5.

In het overzicht is te zien dat er een aantal stappen worden doorlopen. 1. Bij de eerste stap worden de gebruikersnaam en wachtwoord samen met een salt omgezet naar een rode sleutel. Deze rode sleutel wordt bij het registreren opgeslagen in de keychain, waardoor het bij het inloggen mogelijk is om te kijken of de gebruikersgegevens kloppen door deze sleutels te vergelijken. 2. Om te voorkomen dat de sleutel uit de keychain in een volgende stap kan worden geïnjecteerd, worden de ge1  Bijlage 1 - Mijn eerste encryptie

4.

bruikersnaam en wachtwoord bij deze stap nogmaals gebruikt. In combinatie met een salt vormt dit uiteindelijk de groene sleutel. Als laatste extra versleuteling wordt de groene sleutel versleuteld met een salt om de gele sleutel te creëren. Met de gele sleutel wordt de hoofdsleutel versleuteld. Dit vormt een blauwe sleutel welke bij het registeren wordt opgeslagen in de keychain. Bij het inloggen wordt de gele sleutel gecreëerd. Met deze sleutel is het mogelijk om de blauwe sleutel te ontsleutelen en de hoofdsleutel te achterhalen.

In dit proces wordt er geen gebruik gemaakt van een externe server. In mijn uiteindelijke implementatie wordt er een extra sleutel gebruikt welke afkomstig is van een externe server 2. Dit zijn een flink aantal extra stappen. Het originele proces is verder uitgebreid en vormt uiteindelijk de paarse sleutel. Deze wordt samen met de groene public sleutel opgestuurd naar de server. Voor de communicatie tussen de iPhone en de server wordt er gebruik gemaakt van een openbare en een geheime sleutel. Deze methode van versleutelen is in mijn onderzoek naar voren gekomen 3. Het pakketje wordt bij deze methode met een geheime sleutel versleuteld. De server heeft 2  Bijlage 2 - Mijn uiteindelijke encryptie 3  Common Crypto - Onderzoeksrapport (Blz. 42)

deze geheime sleutel in zijn database staan en kan deze door middel van de openbare sleutel achterhalen. Vervolgens is het mogelijk om het pakketje te ontsleutelen, de data te controleren en een versleuteld pakket terug te sturen. Dit is te zien in het middelste gedeelte van bijlage 2. Het pakketje wordt vervolgens op de iPhone ontsleuteld en gecontroleerd. Uiteindelijk wordt de lichtgroene sleutel gecreëerd waarmee de hoofdsleutel versleuteld en ontsleuteld kan worden.

Zodra het pakketje op de iPhone binnenkomt wordt er gekeken hoe oud het pakketje is en of het inloggen gelukt is. Zodra het inloggen om welke reden dan ook mislukt is wordt er een pop-up getoond met een bericht naar de gebruiker.

49

Bij het controleren van het pakketje wordt er naar een aantal dingen gekeken. Op de server wordt gekeken hoe oud het pakketje is en of de inloggegevens kloppen. Als het

pakketje ouder dan 5 minuten is wordt het inlogproces afgebroken en dient de gebruiker opnieuw in te loggen. Dit is om te voorkomen dat een hacker een pakketje probeert te hergebruiken. Vervolgens wordt er gekeken of de gebruikersgegevens overeenkomen. Zodra dit niet klopt wordt er een response terug gestuurd naar de iPhone met het aantal inlogpogingen die nog over zijn.

Afbeelding 19 - Zodra het inloggen mislukt is wordt dit door middel van een pop-up aan de gebruiker getoond

Het

b e v e i l i g e n va n d e

d ata v e r b i n d i n g Naast het versleutelen van de pakketjes die worden rondgestuurd is het ook belangrijk om de dataverbinding te controleren op een man-in-the-middle aanval. Zodra de controle faalt wordt de applicatie afgesloten. Deze controle wordt op meerdere plekken binnen de applicatie aangeroepen.

Zodra de data in de database wordt toegevoegd wordt het eerst versleuteld. Zodra de data wordt uitgelezen wordt het direct ontsleuteld. Hierdoor vindt het versleutelingsproces op één plek binnen de applicatie plaats en heeft de data geen waarde voor een hacker omdat het versleuteld in een database staat opgeslagen.

Inlogsessies

H e t inbouwen van e en d at aversl eutel i ng

50

Om te voorkomen dat de data zonder in te loggen te bereiken is en van waarde kan zijn is het nodig om de data te versleutelen. Dit wordt gedaan door middel van de hoofdsleutel welke bij het inloggen achterhaalt wordt. Binnen het iOS platform kan er gebruik gemaakt worden van een Core Data database. Een Core Data database is eigenlijk een gewone SQL database met een schilletje eromheen. Hierdoor is het mogelijk om door middel van het ontwikkelprogramma de database aan te passen. Ook is het mogelijk om gebruik te maken van zogenaamde transformables. Dit zijn functies die worden aangeroepen bij het injecteren en uitlezen van de waardes uit de database. Deze functionaliteit was een uitkomst voor het versleutelen van de data.

Om te voorkomen dat een gebruiker constant opnieuw moet inloggen om de hoofdsleutel te achterhalen wordt er gebruik gemaakt van een inlogsessie. Bij het inloggen wordt er vanuit de server een sessiesleutel teruggestuurd. Hiermee wordt de hoofdsleutel versleuteld en in het geheugen van de applicatie opgeslagen. Op het moment dat er data versleuteld of ontsleuteld dient te worden wordt er een pakketje met de openbare sleutel naar de server verzonden. De server controleert vervolgens of de sessie geldig is en stuurt een versleuteld pakketje terug met daarin de sessie sleutel. Hiermee is vervolgens de hoofdsleutel weer te ontsleutelen. Verder wordt er op de server gecontroleerd hoe oud de sessie is. Zodra deze ouder dan een uur is wordt er een response naar de iPhone teruggestuurd waardoor de applicatie wordt uitgelogd.

Verschillende

d atat y p e s

Voor mijn applicatie had ik de doelstelling om teksten, afbeeldingen en cijfers versleuteld op te slaan. Deze verschillende datatypes worden rechtstreeks versleuteld in de database opgeslagen. Afbeeldingen worden dus niet lokaal versleuteld opgeslagen, maar omgezet naar bytes welke vervolgens versleuteld worden toegevoegd aan de database.

H et b lokkeren va n d eb u g gers

Allereerst wordt de functie ptrace uitgevoerd. Zodra er een debugger wordt gebruikt zorgt het aanroepen van deze functie ervoor dat de applicatie wordt afgesloten. Als extra check wordt de functie check_debuggers aangeroepen. Dit is om te voorkomen dat een hacker door middel van een debugger de ptrace functie overslaat. Dit is mogelijk doordat de hacker voor het opstarten van de applicatie al breakpoints kan instellen. Breakpoints zijn punten waar de applicatie dient te stoppen en waar vervolgens commando’s uitgevoerd kunnen worden.

51

Om te voorkomen dat de applicatie aangepast kan worden op het moment dat deze draait, is het nodig om te controleren of er debuggers worden gebruikt. Deze check (Af-

beelding 20) wordt op elke pagina en voor belangrijke functies aangeroepen. Een voorbeeld van een belangrijke functie is het versleutelen van data.

Afbeelding 20 - Het controleren of er een debugger wordt gebruikt

Zodra de functie check_debuggers een 1 terugstuurt is er sprake van een debugger en dient de applicatie afgesloten te worden. Om dit te testen heb ik geprobeerd een debugger te gebruiken bij mijn applicatie. De functie werkte waardoor er een foutmelding verscheen (Afbeelding 21).

Afbeelding 21 - Een debugger is gedetecteerd en de applicatie wordt afgesloten

H e t te g e ng a a n va n code i nje cti e s Om te voorkomen dat een hacker code kan injecteren en daarmee belangrijke data kan onderscheppen dient er gecontroleerd te worden op code injecties. Uit het onderzoek bleek dat dit mogelijk was door alle functies te controleren op hun herkomst 4. Daarnaast dienen functies inline gemaakt te worden waardoor ze bij een zogenaamde symbol table dump niet naar voren komen. Jonathan gaf in zijn boek de code om te controleren op code injecties (Zdziarski 295). Om te controleren of deze code ook daadwerkelijk werkt ben ik zelf code gaan injecteren. De functie werkte naar behoren en de code injectie injection3.dylib werd gedetecteerd (Afbeelding 22). Daarnaast zijn alle functies inline gemaakt (Afbeelding 23).

Afbeelding 22 - Het detecteren van een code injectie

52

Afbeelding 23 - Inline functies

4  Het tegengaan van code injecties - Onderzoeksrapport (Blz. 44)

H et co mpl i c eren va n co d e Om het uitlezen van functies en variabelen te bemoeilijken is het nodig om de code te compliceren. Uit het onderzoek bleek dat dit mogelijk was door optimalisatie flags, stripping en funroll-loops 5. Deze flags zijn simpel toe te voegen in de settings van het ontwikkelprogramma (Afbeelding 24).

Afbeelding 25 - De instellingen voor het strippen van de code

Voor het strippen zitten er binnen xcode een aantal standaard ingebouwde instellingen (Afbeelding 25). Hierin is vooral de Strip Linked Product instelling belangrijk welke ervoor zorgt dat de functies onherkenbaar worden bij een class dump.

Afbeelding 24 - De instellingen voor de optimalisatie flags

53



5  Het compliceren van code - Onderzoeksrapport (Blz. 45)

H e t detec teren van ee n ja i l brea k Veel van de methodes om data te hacken zijn enkel mogelijk op een gejailbreakte iPhone. Door binnen de applicatie te controleren of de iPhone gejailbreakt is wordt het voor een hacker een stuk moeilijker om data te achterhalen. Echter wordt er hierdoor ook een groot aantal gebruikers uitgesloten. Het is daarom de vraag of een toekomstige klant hierop wilt controleren. Om deze reden heb ik ervoor gekozen om een zogenaamde macro flag toe te voegen (Afbeelding 26).

54

Vervolgens is het mogelijk om in de code te controleren of deze flag op 1 staat en er dus op een jailbreak gecontroleerd moet worden (Afbeelding 27). Deze controle wordt bij het opstarten van de applicatie gedaan waardoor de applicatie bij een eventueel gedetecteerde jailbreak zo snel mogelijk kan worden afgesloten (Afbeelding 28). De functie fork zal bij een gejailbreakte iPhone een waarde van onder de nul opleveren waardoor de iPhone vervolgens afgesloten zal worden.

Afbeelding 26 - De jailbreak macro flag

Afbeelding 27 - Het controleren van de jailbreak flag

Afbeelding 28 - Het controleren op een jailbreak

H et co ntrol eren va n e e n d ataverbi ndi ng Om een man-in-the-middle aanval uit te sluiten is het nodig om de dataverbinding te controleren. Door gebruik te maken van de standaard beveiliging binnen iOS is het mogelijk om er achter te komen of de dataverbinding afgeluisterd wordt. De connectie zal namelijk falen waardoor er vervolgens een functie zal worden uitgevoerd die het falen moet afhandelen (Afbeelding 29). Door hier de applicatie af te sluiten zal het voor een hacker een stuk moeilijker worden om de verbinding af te luisteren. In combinatie met de overige beveiligingsimplementaties zal het tevens erg lastig worden om deze controle over te slaan.

H e t ve r w i jde r e n va n be s ta nde n e n da ta ba s e da ta In de huidige prototype worden bestanden als bytes in de database opgeslagen. Er worden geen bestanden op het bestandssysteem opgeslagen. Hierdoor is de beveiligingsimplementatie voor het verwijderen van bestanden vervallen. Daarnaast wordt er gebruik gemaakt van een Core Data database waarbij het verwijderen van data door de Core Data service wordt afgehandeld. Hierdoor is het niet mogelijk om de data te vervangen met de zeroblob functie zoals omschreven in het onderzoeksrapport 6.

55

Afbeelding 29 - Zodra de connectie faalt wordt de applicatie afgesloten

6  Het verwijderen van database data - Onderzoeksrapport (Blz. 48)

H e t ma na gen va n de key b oa rd c a c he Om het automatisch corrigeren van teksten goed te laten werken wordt alle keyboard input binnen het iOS platform opgeslagen. Hierdoor bouwt iOS een bibliotheek aan woorden op en kan het in het vervolg woorden voor de gebruiker aangeven of corrigeren (Zdziarski 283). Er bleken echter een aantal uitzonderingen te zijn: ››

››

››

››

Data uit tekstvelden die gemarkeerd zijn als een input voor wachtwoorden worden niet opgeslagen. Teksten met alleen getallen worden niet opgeslagen. Dit is vooral om te voorkomen dat rekeningnummers en dergelijke kunnen worden achterhaald. Data uit tekstvelden waarbij autocorrect is uitgeschakeld worden niet opgeslagen. Kleine woorden worden niet altijd opgeslagen.

56

Deze implementatie bestond dus enkel uit een paar instellingen. Dit heb ik dan ook bij elk tekstveld toegepast (Afbeelding 30).

Afbeelding 30 - De instellingen voor het managen van de keyboard cache

H e t m a na g e n va n de a utom a ti sch g e m a a k te a ppl i ca t ie s cr e e ns hots Op het moment dat een applicatie naar de achtergrond verdwijnt wordt er een screenshots van het huidige scherm gemaakt. Dit wordt gedaan om een soepele overgang te creëren op het moment dat de applicatie weer wordt geopend. Zo zou het zomaar zo kunnen zijn dat een gebruiker zijn rekening heeft bekeken en vervolgens een andere applicatie opent. De applicatie wordt hierbij niet afgesloten, maar in het geheugen bewaard. In de afbeelding zou in dit geval zijn rekening te zien zijn. Doordat deze screenshots niet worden verwijderd is het mogelijk om deze afbeeldingen te achterhalen.

Jonathan geeft hiervoor een oplossing in zijn boek (Afbeelding 31). Echter heb ik voor een andere implementatie gekozen waarbij er een afbeelding wordt getoond van de applicatie in plaats van een leeg scherm (Afbeelding 32). De code die ik hiervoor gebruikt ziet er iets anders uit en zorgt er als het ware voor dat de afbeelding boven alle schermen zichtbaar wordt voordat de afbeelding gemaakt wordt (Afbeelding 33).

Afbeelding 32 - De automatisch gemaakte afbeelding

Afbeelding 31 - De code om ervoor te zorgen dat de automatisch opgeslagen afbeeldingen geen belangrijke data bevatten

57

Afbeelding 33 - De code die ervoor zorgt dat de afbeelding naar voren komt

I O S B E V E I LI GIN G 58

C o n c lu s i e Inleidi ng Na een uitgebreid onderzoek en het bouwen van een beveiligd framework kan ik een aantal conclusies trekken. Allereerst kan ik vertellen dat ik zelf verstelt sta van de mogelijkheden die het iOS platform biedt op het gebied van hacken. Hierbij is mij het meest bijgebleven hoe makkelijk het was om de pincode van een iPhone te achterhalen. Het heeft er voor gezorgd dat mijn collega’s hun iPhone niet meer onbewaakt op hun bureau laten liggen.

Uit mijn onderzoek is gebleken dat de beveiliging van een applicatie pas grondig is op het moment dat alle risico’s zijn meegenomen in de ontwikkeling van de app. Een inlogsysteem kan door een hacker vrij simpel omzeilt worden als de gebruikersgegevens onbeveiligd in het geheugen staan opgeslagen en een inlogsysteem heeft weinig waarde als de data ook zonder het inloggen te bereiken is via bijvoorbeeld een USB verbinding. Een ander goed voorbeeld is het beveiligen van een dataverbinding tegen een man-inthe-middle aanval. De controle op een dergelijke aanval is door middel van een code injectie of een debugger voor een hacker vrij simpel uit te schakelen. Deze controle heeft dus weinig waarde als de applicatie niet tegen code injecties en debuggers beveiligd wordt.

H et veri fi ëren va n d e b evei l i gi ng Voor mij als student is het onrealistisch om de beveiliging te laten verifiëren door een gespecialiseerd bedrijf. De kosten lopen al snel in de duizenden euro’s. Apple lijkt met zijn controles verder weinig aandacht te besteden aan de beveiliging van applicaties. Het legt de verantwoordelijkheid bij de ontwikkelaar en geeft daarmee een grote verantwoor-

delijkheid uit handen. Voor mijn afstudeerproject heb ik de beveiliging voor een groot deel zelf kunnen verifiëren. Door mijn kennis die ik heb opgedaan tijdens het onderzoek kon ik op verschillende manieren bewijzen leveren van de ingebouwde implementaties en kan ik de conclusie trekken dat de applicatie tegen de gevonden beveiligingsrisico’s beveiligd is.

E e n com pl e e t beve i l i g de a ppl i ca ti e ? Mijn doel met dit afstudeerproject was een beveiligd framework creëren waarmee een toekomstig project snel omgezet kan worden tot een beveiligde applicatie. Deze applicatie dient voldoende beveiligd te zijn om uitgebracht te worden in de App Store. Een belangrijke conclusie is dat het onmogelijk is om een applicatie volledig te beveiligen, maar je het een hacker alleen zo moeilijk mogelijk kan maken. Met de resultaten uit mijn onderzoek en de implementaties in het uiteindelijke prototype heb ik een framework gecreëerd waarbij de gevonden beveiligingsrisico’s zo goed mogelijk zijn aangepakt. De applicatie zal echter in de toekomst bij nieuwe versies van het iOS platform waarschijnlijk moeten worden bijgewerkt om de beveiliging ook in de toekomst te kunnen bewerkstellen. 59

D e samenha ng va n risico ’s bi nnen de b eve ili gi ng va n een ap p lica ti e

I O S B E V E I LI GIN G 60

B eg r i p p e n, B r o n n en en B ij lag es Inleidi ng Diverse begrippen uit mijn onderzoek worden hier kort en bondig uitgelegd. Alle cursief groen gedrukte begrippen uit mijn onderzoek zijn hier terug te vinden. Onder elk begrip staat aangegeven waar het voor het eerst is aangeroepen en alle begrippen zijn op alfabet gesorteerd. Mocht u dit document digitaal bekijken dan is het voor u mogelijk om op de pagina nummers te klikken. Daarnaast heb ik in mijn verslag gerefereerd naar verschillende bronnen en bijlages. Ook deze zijn in dit hoofdstuk te vinden.

Begrippen Api

Debugger

Ook wel Application Programming Interface, staat voor een verzameling van afspraken (functies) over hoe een onderdeel van het ene programma kan communiceren met het andere.

Een tool voor de terminal om fouten in een applicatie mee op te sporen.

↑

Encryptie

pagina 44

↑

pagina 33

Het versleutelen van data.

Brute-force Een manier van hacken om door elke mogelijkheid te proberen een wachtwoord te achterhalen. pagina 16

i OS Het besturingssysteem van Apple voor de iPhone en iPad. ↑

Class

pagina 17

pagina 3

dump

Creëert een overzicht van functies uit een bepaalde class.

Jailbreaken

↑

Het proces waarbij bepaalde systeem beperkingen van een iPhone verwijderd worden waardoor er onder andere buiten de officiële App Store om applicaties geïnstalleerd kunnen worden.

pagina 18

Cycript Een tool voor de terminal om functies in een applicatie uit te voeren terwijl deze geopend is.

↑

↑

Keychain

pagina 19

Daemon Een programma welke op de achtergrond draait zonder dat de gebruiker het doorheeft. ↑

pagina 16

pagina 15

Een beveiligde database op het iOS platform. Hierin staat belangrijke data zoals bijvoorbeeld wachtwoorden. ↑

pagina 16

61

↑

↑

Man-in-the-middle

Symbol

Bij een Man-in-the-middle aanval (MITM) worden gegevens tussen een router en de telefoon onderschept door een aanvaller.

Een overzicht van methodes en variabelen in assembly taal waarbij onder andere het geheugenadres is uit te lezen.

↑

↑

pagina 6

Netwerk

sniffer

Een tool om dataverbindingen binnen een netwerk te monitoren. ↑

pagina 13

Een tool voor de terminal om functies en andere informatie van een applicatie uit te lezen. ↑

pagina 34

S a lt Een salt, of zout in het Nederlands, zorgt voor een extra vertroebeling bij een encryptie proces. ↑

pagina 48

62

Spoofen Een techniek waarbij de afzender van een bericht vervangen wordt door een andere afzender dan degene die het bericht daadwerkelijk verstuurde. ↑

pagina 15

pagina 34

Terminal De terminal wordt gebruikt voor het uitvoeren van verschillende commando’s, zowel op een Mac als op een iPhone. ↑

Otool

ta b l e d u m p

pagina 61

Xcode Xcode is de naam van het ontwikkelprogramma voor het bouwen van iOS applicaties. ↑

pagina 53

B ro n n en ››

Amini, Pedram. Reverse Engineering iPhone AppStore Binaries. 2009. 9 Maart 2012 http://dvlabs.tippingpoint.com/blog/2009/03/06/reverse-engineering-iphone-appstorebinaries

››

Amitay, Daniel. Most Common iPhone Passcodes. 13 Juni 2011. 20 Maart 2012 http://www.amitay.us/blog/files/most_common_iphone_passcodes.php

››

Apple. App Store Review Guidelines. 2012. 28 Maart 2012 https://developer.apple.com/appstore/resources/approval/guidelines.html ◦◦ —. “Deploying iPhone and iPad.” Oktober 2011. Apple. 28 Maart 2012 http://images.apple.com/iphone/business/docs/iOS_Security.pdf

››

ell. Mobile Application Security Assessment. n.d. 28 Maart 2012 D http://www.secureworks.com/consulting/mobility_security/Mobile_Application_Security_ Assessment/

››

ING. TAN-code via mobiel. n.d. 19 Maart 2012 http://www.ing.nl/particulier/internetbankieren/internetbankieren/mijn-ing/tan-code-viamobiel/

››

Java. Wat is een proxyserver? Hoe ontvang ik informatie over de proxyserver? n.d. 14 Maart 2012 http://www.java.com/nl/download/help/proxy_server.xml

››

Last Bit Software. Brute Force Attack. n.d. 7 Maart 2012 http://lastbit.com/rm_bruteforce.asp

››

Marqit. Penetration testing. n.d. 28 Maart 2012 http://www.marqit.nl/wat-is-penetration-testing.aspx

››

PC Tools. Three Out Of Four Web Users Still Not Security Savvy. 2 September 2009. 20 Maart 2012 http://www.pctools.com/news/view/id/265/

››

Secure Apps. Security Scan: voorkom vervelende verrassingen. n.d. 29 Maart 2012 http://secureapps.nl/#

63

We b sites

››

Telecompaper. Ruim helft Nederlanders heeft smartphone. 14 Maart 2012. 29 Maart 2012 http://www.telecompaper.com/nieuws/ruim-helft-nederlanders-heeft-smartphonetelecompaper

››

viaForensics. Mobile Application Security - Appsecure. n.d. 28 Maart 2012 https://viaforensics.com/services/security/mobile-application-appsecure/

››

Zwaag, Gonny van der. ING Bankieren: vernieuwde app voor mobile bankieren op iPhone, iPad en Android. 8 November 2011. 19 Maart 2012 http://www.iphoneclub.nl/151051/ing-bankieren-vernieuwde-app-voor-mobiel-bankierenop-iphone-ipad-en-android/ ◦◦ —. PayPal iPhone-app krijgt snelle update wegens beveiligingslek. 04 November 2010. 27 Februari 2012 http://www.iphoneclub.nl/94495/paypal-iphone-app-krijgt-snelle-update-wegensbeveiligingslek/

64

Bo e ken ››

Kurose, James F. and Keith W. Ross. Computernetwerken. 3e editie. Benelux: Pearson Education Benelux, 2005.

››

Zdziarski, Jonathan. Hacking and Securing iOS Applications. Sebastopol: O’Reilly Media, 2012.

65

Bijlage 1 - Het versleutelingsproces zonder authenticatie op serverniveau

B ij l ag e s

Bijlage 2 - Het versleutelingsproces met authenticatie op serverniveau

66

67