OWASP Top 10 Mobile Risks

Update 23 – Het Inzicht – januari 2015

Dit keer in de rubriek ‘De Hack’ gaat Daniël Dragicevic in op de verschillende kwetsbaarheden die in de OWASP Top 10 Mobile Risks zijn opgenomen.

OWASP Top 10 Mobile Risks
Praktijkvoorbeelden, aandachtspunten en aanbevelingen

In Update #22 (september 2014) zijn we in de rubriek ’De Hack’ ingegaan op de verschillende risico’s bij het gebruik van mobiele platformen en applicaties. In dit artikel bespreken we specifiek de OWASP Top 10 voor mobiele applicaties, en benoemen we praktijkvoorbeelden, aandachtspunten en aanbevelingen.

M1: Insufficient server controls
Het eerste risico betreft onvoldoende of onvolledige controle aan de serverzijde van inkomende berichten en/of acties. Wanneer we het hebben over de serverzijde kunt u zich afvragen of dit risico wel thuishoort in een lijst van risico’s voor mobiele applicaties. Mobiele applicaties worden veelal in combinatie met gegevensbronnen op serversystemen gebruikt; denk hierbij aan SOAP-, REST- of XMPP-interfaces. De clienten servercomponent vormen in feite twee onderdelen van hetzelfde informatiesysteem. Deze worden vaak ten onrechte los van elkaar gezien. We raden daarom aan om beide componenten in een beveiligingsonderzoek mee te nemen.

In de praktijk zien we vaak dat inkomende berichten onvoldoende worden gecontroleerd. Dit geeft een aanvaller de mogelijkheid om meer informatie op te vragen dan noodzakelijk. Ook kan een aanvaller acties uitvoeren die niet bij zijn rol passen. Dit soort autorisatiecontroles dienen zowel aan de client- als aan de serverzijde te worden uitgevoerd.

M2: Insecure data storage
Het tweede risico gaat over onveilige opslag van gegevens. We adviseren vaak om zo min mogelijk gegevens op een mobiel apparaat op te slaan. Dat wil zeggen: sla enkel de gegevens op die noodzakelijk zijn voor het functioneren van de applicatie. Om tot deze dataset te komen moet er een threat model van de applicatie worden gemaakt waarbij duidelijk wordt welke gegevens worden gebruikt en waar deze worden opgeslagen.

Voorbeelden van plaatsen waarin we vaak gevoelige data vinden zijn SQLite-databases, logbestanden, XML-bestanden, binaire opslagbestanden en cookie stores. Tijdens onderzoeken zien we vaak onversleutelde SQLite-databases en logbestanden waarin gevoelige informatie is opgenomen. Denk hierbij aan POST-requests met sessie-identifiers, gebruikersnamen en wachtwoorden. Met deze gegevens is het voor een aanvaller mogelijk om zich voor te doen als gebruiker van de applicatie, zonder deze ooit te hebben gestart.

Het is erg belangrijk om u bewust te zijn van de plaatsen waar deze gegevens terecht kunnen komen. Denk hierbij aan backups op desktopsystemen of synchronisatie naar clouddiensten als iCloud, Google Drive of Microsoft SkyDrive. Het feit dat gegevens gesynchroniseerd worden zorgt ervoor dat een aanvaller de mogelijkheid heeft om gegevens te achterhalen zonder dat deze in het bezit is van het mobiele apparaat waarop de applicatie geïnstalleerd is. Het aanvalsoppervlak wordt hiermee aanzienlijk vergroot. Zorg daarom voor sterke encryptie van gegevens die op een mobiel apparaat worden opgeslagen. Denk hierbij ook aan het veilig opslaan van sleutelmateriaal.

M3: Insufficient Transport Layer protection
Dit risico draait om de bescherming van gegevens tijdens transport over een netwerk. In sommige gevallen zien we dat er geen gebruik wordt gemaakt van een versleutelde verbinding. De vertrouwelijkheid van gegevens is dan in beginsel niet gewaarborgd. Vaker zien we dat er gekozen wordt voor een ’gewone’ SSL-verbinding. Dat wil zeggen dat de applicatie vertrouwt op de certificate store van het mobiele OS voor de controle van SSL-certificaten. Wanneer een CA-certificaat in de certificate store van het mobiele besturingssysteem voorkomt, zal de applicatie gesigneerde certificaten vertrouwen en een verbinding opzetten. Wanneer een aanvaller de certificate store van een mobiel besturingssysteem kan manipuleren (d.w.z. een CA-certificaat kan toevoegen), vervalt de beveiligingsmaatregel en kan een aanvaller het netwerkverkeer afluisteren en manipuleren. Ook moet rekening worden gehouden met de mogelijkheid dat onder de vele standaard vertrouwde CA’s, die zich over de wereld verspreid bevinden, ook CA’s kunnen zitten die een vals certificaat uitreiken; bijvoorbeeld als gevolg van compromittering of toepassing van juridische dwangmiddelen. We adviseren daarom altijd om gebruik te maken van certificate pinning. Bij deze techniek controleert de applicatie zelf of het server- of CA-certificaat voldoet aan de verwachting van de applicatie. Op deze manier wordt het slagen van een SSL-verbinding afhankelijk (pinned) van een specifiek server- of CA-certificaat.

M4: Unintended data leakage
Dit risico omvat alle vormen van informatielekken. Vaak komen deze informatielekken voor als gevolg van onbewuste opslag van gegevens, dat wil zeggen: opslag op plaatsen waarmee geen rekening wordt gehouden. Deze opslaglocaties zijn platformspecifiek. Op Apple’s iOS wordt bijvoorbeeld een screenshot van de applicatie gemaakt wanneer deze door een gebruiker naar de achtergrond wordt gedrukt. Zo’n screenshot kan gevoelige informatie bevatten. Ook URLen toetsaanslag-caches zijn locaties waar onbedoeld gevoelige data terechtkomt. In de praktijk zien we dat logbestanden en diagnostische data onnodig veel informatie bevatten. We hebben in de praktijk meerdere keren gezien dat logbestanden met daarin leesbare gebruikersnamen, wachtwoorden, bestandsnamen en andere gevoelige informatie naar ontwikkelaars, advertentieproviders en clouddiensten worden gestuurd. Zorg ervoor dat u exact weet welke informatie wáár wordt opgeslagen en of deze naar het internet wordt gecommuniceerd.

M5: Poor authorization and authentication
Dit risico omvat gebreken in de autorisatie en authenticatie van gebruikers. Gevolg hiervan is dat beperkingen die zijn opgelegd, niet altijd worden gehandhaafd. Gebrekkige autorisatie en authenticatie zijn problemen die we vaker tegenkomen bij onderzoeken naar mobiele applicaties. We zien veelal dat vertrouwd wordt op autorisatiecontroles aan de clientzijde. Ook zien we dat er geen misbruikscenario’s (abuse cases) worden gedefinieerd bij het bouwen van de serversoftware. Wanneer een aanvaller een geldige sessie met de server kan opzetten, heeft hij soms meer functionaliteit tot zijn beschikking dan zichtbaar is in de client. Dit heeft invloed op de vertrouwelijkheid en integriteit van gegevens die op de server worden verwerkt. Ook zien we dat authenticatie een uitdaging is op mobiele platformen. Het is voor gebruikers immers niet handig om lange wachtwoorden te moeten invoeren op een klein toetsenbord. Vaak wordt vertrouwd op vier- of vijfcijferige pincodes voor toegang tot gegevens en applicaties. Deze zijn aanzienlijk gemakkelijker te kraken dan complexe wachtwoorden. We adviseren daarom vaak om te kijken naar het gebruik van meerfactorauthenticatie in de vorm van clientcertificaten of tokens.

M6: Broken cryptography
Het risico van zwakke versleuteling kan verregaande gevolgen hebben. Vaak zien we dat, wanneer er versleuteling wordt gebruikt, ervoor gekozen wordt om meer gegevens op het mobiele apparaat op te slaan. Er wordt verondersteld dat het risico op uitlekken van gegevens is weggenomen. Bij zwakke versleuteling zien we vaak meerdere oorzaken. Ten eerste kan er gebruik worden gemaakt van oude en onveilige versleutelings- of hashingmethoden. Denk hierbij aan 3DES, MD4, MD5 of SHA1. Ook kan het zo zijn dat de gegevens waarop de versleuteling wordt gebaseerd onvoldoende willekeurig zijn. Wat we in de praktijk vooral tegenkomen is een onveilige omgang met sleutelmateriaal. Denk hierbij aan encryptiesleutels die in de applicatiedirectory worden opgeslagen. Wat we ook zien is dat sleutelmateriaal in de broncode van de applicatie wordt opgenomen. Een aanvaller kan in deze gevallen door het dumpen van de applicatiedirectory en reverse engineering van de binary het sleutelmateriaal achterhalen waarmee de gegevens kunnen worden ontsleuteld. We adviseren dan ook om sleutelmateriaal niet buiten de daarvoor bedoelde secure storage op het mobiele apparaat op te slaan.

M7: Client Side Injection
Dan is er het risico van injectie van gemanipuleerde data in de mobiele applicatie. Hierbij wordt vaak gedacht aan JavaScript- of SQL-injectie op het moment dat de applicatie uitgevoerd wordt. Echter, bij mobiele applicaties kan het verder gaan dan dat. Ook gegevens die vanaf het bestandssysteem van het mobiele apparaat worden gelezen kunnen worden gemanipuleerd. Zo hebben we een mobiele applicatie onderzocht die gebruikmaakte van certificate pinning. Hierbij werd een CA-certificaat vanuit de bestandsmap van de applicatie geladen en vergeleken met het CA-certificaat dat door de server werd overlegd. We hebben het CA-certificaat op het bestandssysteem vervangen door een CA-certificaat dat door ons was uitgegeven: zo konden we certificate pinning omzeilen. Dit is een eenvoudige manier waarop door middel van injectie van gemanipuleerde data een beveiligingsmaatregel is omzeild. We adviseren om alle in- en outputs in kaart te brengen en overal strikte validatie toe te passen.

M8: Security decisions via untrusted inputs
Wanneer een applicatie beveiligingsmaatregelen laat afhangen van invoer die door de gebruiker of door een aanvaller kan worden gemanipuleerd, spreken we van een beveiligingsbesluit dat is genomen op basis van niet-vertrouwde invoer. Een voorbeeld hiervan is het toekennen van beheerdersrechten wanneer een “admin=True” parameter in een URL wordt meegestuurd. Deze parameter kan door een aanvaller worden gezet. In het geval van mobiele applicaties zien we dat beveiligingsbesluiten worden genomen op basis van gegevens (bijv. cookies) die onversleuteld op het bestandssysteem van het mobiele apparaat staan. Door deze te manipuleren kan een aanvaller onterecht toegang krijgen tot functionaliteit en gegevens die niet toegankelijk zouden moeten zijn. Zorg er daarom voor dat deze informatie versleuteld wordt opgeslagen om de kans te verkleinen dat deze worden gemanipuleerd. Ook kan gekozen worden voor een opzet waarbij de autorisatiegegevens van de server worden opgehaald bij het starten van de applicatie; zorg hierbij wel voor een veilige (pinned) verbinding.

M9: Improper session handling
Onveilig sessiebeheer is een risico dat we in de praktijk vaak tegenkomen. We zien dat sessie-identifiers vaak niet, of pas na lange tijd verlopen en worden geïnvalideerd. Gecombineerd met het onveilig opslaan van gegevens is het voor een aanvaller gemakkelijk om toegang te krijgen tot een gebruikerssessie. Zorg ervoor dat sessies binnen acceptabele tijd verlopen. Daarnaast moeten sessie-identifiers willekeurig worden gegenereerd en versleuteld worden opgeslagen.

M10: Lack of binary protections
Dit risico spitst zich toe op de mogelijkheid tot reverse engineering van mobiele applicaties. Door een binary te analyseren en te vertalen naar leesbare broncode en begrijpelijke applicatielogica is het voor aanvallers mogelijk om aanvalsmogelijkheden te ontdekken. Denk hierbij aan het omzeilen of uitschakelen van ingebouwde beveiligingsmaatregelen, het aanpassen van applicatielogica en het stelen van gegevens. In een recent onderzoek hebben we op basis van reverse engineering achterhaald hoe de gegevens op het mobiele apparaat werden versleuteld. De versleuteling werd uitgevoerd op basis een aantal factoren. Een vijfcijferige pincode die bij het starten van de applicatie werd gevraagd was in dit geval de enige onbekende factor. Op basis van deze informatie konden we in korte tijd de pincode van de gebruiker achterhalen en de gegevens ontsleutelen.

Zoals u heeft kunnen lezen is er een groot aantal zaken waar rekening mee gehouden moet worden bij de ontwikkeling van mobiele applicaties. Zorg ervoor dat zowel voorafgaand aan, als tijdens het ontwikkelproces, gebruik wordt gemaakt van threat modeling. Dit geeft een goed beeld van het aanvalsoppervlak, de trust boundaries en gegevensstromen in de applicatie. Op basis van deze informatie is het mogelijk om in alle fasen van het ontwikkelproces misbruikscenario’s (abuse cases) te definiëren. Deze kunnen in een pentest worden gebruikt en zorgen uiteindelijk voor een mobiele applicatie waarin de vertrouwelijkheid, integriteit en toegankelijkheid van gegevens kan worden gewaarborgd.

 

@Secura 2017
Disclaimer  /  Privacy policy  /  Sitemap / Inloggen
Webdesign Studio HB / webdevelopment Medusa