Android-apper og SSL: Hvor er hengelåsen?

Da vi oppfordret til sikkerhetsbevisste IT-ledere, ble vi klar over SSL-kryptering (Secure Socket Layer), og hvor viktig den var. Jeg vil satse Gi ikke noen privat eller økonomisk informasjon med mindre du ser en lukket hengelås og HTTPS høres kjent ut?

Eksakte detaljer var ikke viktige for de fleste; vi bare visste at når begge var til stede i nettleseren, var det trygt for digital trafikk å krysse det utilgivende internett. Da mobiltelefoner ble smarte, minnet de samme lederne pliktoppfyllende oss om at mobile nettlesere også bruker SSL - for eksempel Chromes mobile nettleser.

Så vi er fremdeles trygge å krysse internett ved hjelp av enten mobilnettet eller en Wi-Fi-forbindelse, så lenge en lukket hengelås og HTTPS er synlige.

Hva med apper?

Som tar vare på nettlesere, men hva med dataprogrammer - mange reklamerer med SSL, for eksempel Skype:

Når du logger på kontoen din på nettstedet vårt, blir all informasjonen sendt over SSL. SSL krypterer all informasjonen før den forlater datamaskinen din, og kan bare dekrypteres av serveren vår.

Av en eller annen grunn viser ikke dataprogrammer som bruker SSL om SSL er aktivert - ingen tegn til hengelås eller HTTPS. Jeg har vært over hele Skype-appen, og det er ingen omtale av SSL noe sted. Hvis jeg savnet det, gi meg beskjed.

Ikke noe problem, jeg skal teste om Skype krypterer trafikken deres ved å bruke en pakkesniffer. Og det ser ut til å se ut i henhold til følgende gibberish.

Når det gjelder Skype mobilapplikasjon, har vi en annen historie. I likhet med dataprogrammet gir ikke appen noen indikasjon SSL er aktivert og fungerer riktig. For å gjøre vondt verre, er det ingen enkel måte å teste om appen krypterer trafikk eller ikke.

Jeg spurte andre TechRepublic skribent og Android-utvikler, William Francis, om applikasjoner kunne endres for å informere brukeren om tilstanden til SSL-tilkoblingen:

Ikke akkurat, da du kan ha flere SSL-tilkoblinger samtidig. Å overvåke all innkommende trafikk vil kreve kanalisering av all trafikk gjennom en proxy, eller et lavere nivå (kjerne) privilegert program. Android-appen / tillatelsessystemet kjører forstyrrelser, noe som hindrer at apper spionerer etter nettverkstrafikk som blir sendt til andre installerte applikasjoner.

Jeg fikk et nesten identisk svar fra Kurt Huwig, skaperen av SSL Verify, en Android-app som bekrefter populære SSL-sertifikater:

Det er en måte. Man kan skrive en HTTP-proxy som bekrefter SSL-tilkoblinger. Vis deretter et ikon på oppgavelinjen når SSL er aktiv. Fortsatt er det vanligvis flere apper som kjører i bakgrunnen på Android, noe som gjør det vanskelig å knytte trafikk til riktig applikasjon.

Det ser ut til at antakelse ikke er en god idé

Ifølge et tysk forskerteam fra Leibniz University of Hannover og Philipps University of Marburg, ledet av Dr. Bernd Freisleben (øverste bilde) og Dr. Matthew Smith, bruker ikke en betydelig andel Android-applikasjoner SSL riktig. Innledningen til teamets forskningsartikkel, "Why Eve and Mallory Love Android: An Analysis of Android SSL (In) Security" nevner:

Vår analyse avdekket 1 074 (8, 0%) av appene som ble undersøkt, inneholder SSL / TLS-kode som potensielt er sårbar for angrep fra Man in the Middle (MitM). Ulike former for misbruk av SSL / TLS ble oppdaget under en ytterligere manuell revisjon av 100 utvalgte apper som gjorde det mulig for oss å starte MitM-angrep mot 41 apper, og samle et stort utvalg av sensitive data.

Professor Freisleben ville at jeg skulle påpeke at selv om forskerne bare testet gratisapper, bør man ikke anta at kjøpte apper er fri for SSL-problemer.

En del av papiret interesserte meg spesielt. Det var der forskerne ga detaljer om hvordan utviklere feil inkorporerte SSL i applikasjonene sine:

  • Tillit til alle sertifikater : TrustManager-grensesnittet kan implementeres for å stole på alle sertifikater, uavhengig av hvem som har signert dem eller til og med for hvilket emne de ble utstedt.
  • Tillatelse av alle vertsnavn : Det er mulig å avstå fra sjekker om sertifikatet ble utstedt for denne adressen eller ikke. Når du for eksempel får tilgang til serveren eksempel.com, godtas et sertifikat utstedt for noen andre domain.com.
  • Stol på mange sertifikatmyndigheter (CA) : Dette er ikke nødvendigvis en feil, men Android 4.0 stoler på 134 CA-rotsertifikater som standard.
  • Mixed-Mode / No SSL : App-utviklere står fritt til å blande sikre og usikre tilkoblinger i den samme appen, eller ikke bruke SSL i det hele tatt. Dette er ikke direkte et SSL-problem. Men det er relevant å nevne at det ikke er noen utvendige tegn, og ingen mulighet for en felles app for å sjekke om en sikker tilkobling brukes eller ikke.

Jeg har nå tre kilder som sier at det er nesten umulig for en bruker å avgjøre om en Android-applikasjon bruker SSL, og bruker SSL riktig. Hvis det er sant, hva er forskningsteamets hemmelighet?

Hvordan vet de det da?

Forskerteamet opprettet en Androguard-utvidelse kalt MalloDroid, et verktøy som letter statistisk kodeanalyse av Android-applikasjoner. Detaljer som er spesifikke for MalloDroid er:

  • Analyser nettverkets API-anrop, og trekk ut gyldige HTTP (S) URL-er fra de dekompilerte appene.
  • Sjekk gyldigheten av SSL-sertifikatene til alle ekstraherte HTTPS-verter.
  • Identifiser apper som inneholder API-anrop som skiller seg fra Androids standard SSL-bruk, for eksempel inneholder tillitsadministratorer som ikke er standard, SSL-socketfabrikker eller vertsnavnverifiserere med tillatte bekreftelsesstrategier.

Professor Freisleben forklarer hva som skjer etter at MalloDroid har flagget apper med sannsynlige SSL-problemer:

Vi gjennomførte en manuell studie av 100 kirsebærplukkede apper for å finne ut hva slags informasjon som faktisk sendes via potensielt ødelagte SSL-kommunikasjonskanaler ved å installere disse appene på en ekte telefon, og utføre et aktivt MitM-angrep mot appene.

Jeg er glad for at de sjekker apper; Jeg har ikke tid til å sjekke hver mobilapp manuelt. På mine digitale reiser fant jeg en annen gruppe mennesker som er interessert i å sikre at trafikken fra mobile enheter er sikker.

ZAP av Zscaler

Zscaler, et selskap som var interessert i online sikkerhet, trengte en måte å teste mobilapplikasjoner på. Så de opprettet ZAP. Zscaler Application Profiler (ZAP) er:

A nettbasert verktøy designet for å effektivisere fangst og analyse av HTTP (S) -trafikk fra mobile applikasjoner. ZAP er i stand til å analysere trafikk fra både iOS og Android-applikasjoner.

Jeg er kjent med Zscaler. For tre år siden var Michael Sutton, visepresident for sikkerhetsforskning i Zscaler, min ekspertkilde da jeg skrev om multifunksjonsskrivere som fungerte som spionverktøy. Jeg ringte Michael og ba ham om å forklare ZAP:

ZAP bruker dynamisk analyse (ingen kode blir inspisert). Vi setter opp en proxy-server som lar deg sende trafikk gjennom systemet vårt og vi analyserer hva som overføres.

Michael forklarte videre:

Vår viktigste bekymring er brukernes personvern og å sørge for at personlig identifiserbar informasjon blir kryptert. For det formål har vi brukeren satt opp en falsk konto i appen for testing. Når trafikk fra søknad blir analysert, sjekker vi om noen av de falske brukerdataene blir sendt i det fjerne.

ZAP sjekker følgende:

  • Autentisering : Brukernavn / passord sendes i klartekst eller ved hjelp av svake kodingsmetoder.
  • Enhetsmetadatelekkasje : Data som kan identifisere en individuell enhet, for eksempel UDID (Unique Device Identifier).
  • Personlig identifiserbar informasjonslekkasje : Data som kan identifisere en individuell bruker, for eksempel en e-postadresse, telefonnummer eller postadresse.
  • Eksponert innhold : Kommunikasjon med tredjeparter som reklame- eller analysesider.

Så med ZAP har vi en måte å sjekke mobilapplikasjoner på. Det høres ut som om forskerteamet snart skal ha MalloDroid-nettstedet sitt i gang. Sammen skal verktøyene gi en god ide om hva som er galt med en mobilapplikasjon.

Men hva da?

Hva er alternativene våre?

Forskningsoppgaven fortsatte med å liste opp hva som kan gjøres for å eliminere feil SSL-implementering:

  • Håndhevet sertifisjekontroll : Tving utviklere til å bruke standard bibliotekimplementeringer levert av Android APIs.
  • HTTPS Everywhere : En løsning for å forbedre en god del av sårbarhetene som ble oppdaget i eksempelsettet vårt, er en Android-versjon av HTTPS-Everywhere, integrert i kommunikasjons-API-ene.
  • Forbedrede tillatelser og retningslinjer : I stedet for en generell tillatelse for Internett-tilgang, kan en mer finkornet policy-modell gi rom for mer kontroll.
  • Visuell sikkerhetsfeedback : Rimelig tilbakemelding til brukeren om sikkerhetsstatusen til det aktuelle programmet er utvilsomt et verdifullt tiltak.
  • MalloDroid installasjonsbeskyttelse : MalloDroid kan integreres i appinstallatører eller appmarkeder for å utføre statisk kodeanalyse.

Problemet med hvert av forslagene ovenfor, de er ikke noe vi kan gjøre. Forskerteamet antydet imidlertid noe om:

I å introdusere retningslinjer som GSM_ONLY, NO_OPEN_ WIFI eller TRUSTED_NETWORKS kan bidra til å beskytte apper mot noen MitM-angrep. Til tross for at mobilnettverk som GSM / 3G / 4G ikke gir absolutt sikkerhet, krever de fortsatt betydelig mer innsats for å utføre et aktivt MitM-angrep.

Det er interessant; mobilnettverk er sikrere enn Wi-Fi-tilkoblinger. Jeg trengte bekreftelse, så jeg sjekket med Dr. Denis Foo Kune. Han er min ekspert på mobilteknologi. Du husker kanskje artikkelen min, "Finne eiere av mobiltelefoner på ikke-GPS-måten", der jeg forklarte hvordan Denis kunne spore mennesker uten å bruke telefonens GPS. Denis hadde dette å si:

Sårbarheten kan utnyttes av hvem som helst på banen mellom enheten og serveren. Å ha enheten på mobilnettet gjør det litt vanskeligere. En angriper må enten ha kontroll over en node mellom tjenesteleverandøren og internett-serveren, eller bruke et off-path-angrep for å avlede trafikk til en node under sin kontroll. Zhiyun Qian hadde et par papirer om det.

Jeg vil si at bruk av mobilnettet i stedet for Wi-Fi-nettverket er litt bedre (forutsatt at du stoler på mobiltelefoneleverandøren din mer enn folk på Wi-Fi-nettverket), men det bør ikke betraktes som en endelig løsning.

Siste tanker

At mobilapplikasjoner har problemer med SSL er forvirrende. Professor Freisleben hadde en interessant kommentar angående dette:

Vi fikk forskjellige reaksjoner fra utviklere vi kontaktet; noen var ikke klar over problemene, noen slo av SSL-valideringskontroller under utviklingen (og glemte tilsynelatende å slå dem på etterpå), og noen hevdet at kundene ville at de skulle unngå å bruke SSL-sertifikater.

Nok en gang koker det ned til Buyer Beware . Sjekk mobilapper ved installasjon, hver gang applikasjonen oppdateres, og vurder å bruke mobiltelefonforbindelser hvis det er den minste bekymring for sikkerhet eller personvern.

© Copyright 2020 | mobilegn.com