iOS apps ramt af sikkerhedshul

Illustration: Virrage Images/Bigstock
Hackere kan udnytte sikkerhedshul i flere udbredte apps som Facebook Messenger, Gmail og Google+ til at identificere iPhone-ejere.

En iPhone-bruger, der gerne vil være anonym, kan identificeres af hackere gennem et sikkerhedshul i flere af de kendte besked-apps til iOS. Det gælder blandt andet Facebook Messenger, Gmail og Google+, men der kan sagtens være tale om flere. Det skriver Andrei Neculaesei, der er udvikler for den danske startup Airtame og er den, der har opdaget hullet.

Sikkerhedshullet består i den måde, som Apple’s mobilstyresystem håndterer links til at foretage opkald på telefonen. Normalt hvis man klikker på et link til at ringe et telefonnummer op i Safari-browseren, vil der komme en popup besked frem, der spørger, om man vil ringe det pågældende nummer op.

Læs også: Sådan holder spionprogrammer sig skjult på din iPhone

Som Apple også selv beskriver i sin dokumentation til mobiludviklere, så gælder dette dog ikke, hvis man klikker på linket i en apps' egen browser. I denne situation vil telefonen foretage opkaldet uden videre og dermed åbne op for en hel række af muligheder for misbrug.

Andrei Neculaesei optog en gif af sikkerhedshullet i Facebook Messenger (klik for at se animationen):

Illustration: Andrei Neculaesei

Ondsindede kan således forholdsvis let programmere en hjemmeside, der får intetanende iPhone-brugere til at falde i sikkerhedsfælden. Ringer man op eksempelvis op til et telefonnummer med ekstra høje afgifter, vil man måske ikke kunne nå at forhindre opkaldet. Og da det også er muligt at lave links til videoopkald med Facetime, vil det være muligt for hackeren at få sit offer til at ringe op, hvorefter han kan nå at tage et screenshot af vedkommende og muligvis lokalisere ham.

Problemet er så udbredt, fordi de fleste apps bruger deres egen browser til at håndtere links. Det gælder blandt andet Facebook Messenger, Gmail og Google+ ifølge Andrei Neculaesei. Han skriver også, at fejlen ligger hos app-udviklerne, da de ikke har programmeret deres apps til at vise en popup-advarsel ved opkald.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Milos Game

Umiddelbart vil jeg sige (mis)brug af feature, da denne feature er beskrevet i dokumentationen, der oven i købet siger at udvikleren selv kan tilføje en popup besked:

The tel URL scheme is used to launch the Phone app on iOS devices and initiate dialing of the specified phone number. When a user taps a telephone link in a webpage, iOS displays an alert asking if the user really wants to dial the phone number and initiates dialing if the user accepts. When a user opens a URL with the tel scheme in a native app, iOS does not display an alert and initiates dialing without further prompting the user. However, a native app can be configured to display its own alert.

Denne alert burde var slået til som default, og udviklerne ville få muligheden for at slå den fra.

Sune Riedel

Sikkerhedshul er et meget stort ord at bruge, som Milos også nævner, men lad os bare kalde det det.

Det er en designbeslutning, som gør at en app kan gøre noget (uden nødvendigvis at have onde intentioner), som koster brugeren penge (via telefonregningen). Det kræver dog den udløsende faktor, at brugeren er for langsom til at lægge på, når opkaldet startes (jeg formoder, at der skal etableres forbindelse inden man bliver bonget for et overtakseret opkald - ellers kan teleselskabet vel maksimalt tage betaling for et opkaldsforsøg - hvis de stadig gør det).

Det bringer mig videre til det egentlige problem:
Når jeg ringer op til et givent nummer - er det mit ansvar som kunde på forhånd at vide, at det er et overtakseret nummer, jeg ringer til, eller burde jeg skulle bekræfte dette, når jeg foretager opkaldet ("du er ved at ringe op til et nummer, der koster 10 kr. i minuttet at ringe til - bekræft venligst ved at trykke 1 - ellers læg på")?

Michael Dyhr Iversen

... ios gjorde som android og bare åbnede telefon, med nummere indtastet, så kunne man selv vælge om man vil trykke ok.

Ellers vil jeg give de andre 2 ret, det er da muligt at bruge det til at overtaksere folk, men folk skal selv trykke på linket, og trykker man på noget der kommer fra en fremmed??? (retorisk spørgsmål)

Sune Riedel

... ios gjorde som android og bare åbnede telefon, med nummere indtastet, så kunne man selv vælge om man vil trykke ok.


Det kommer jo an på om udvikleren på Android har valgt at bruge Intent.ACTION_DIAL, der gør som du beskriver, eller om han/hun har brugt Intent.ACTION_CALL, der gør præcis som beskrevet på iPhone. Sidstnævnte kræver at app'en har sat en CALL_PHONE permission, som brugeren skal godkende ved installation.

Peter Stricker

Sidstnævnte kræver at app'en har sat en CALL_PHONE permission, som brugeren skal godkende ved installation.


Og det gør brugeren! Der er et utal af permissions, og hver gang en app skal opdateres skal man godkende permissions såfremt der er behov for nye.

Og selv hvis udvikleren har de bedste intentioner om, at beskytte brugerens privatliv, så er det ikke muligt at bede om Intent.ACTION_CALL og så alligevel tillade installation af app'en, hvis brugeren ikke giver denne rettighed.

Lige præcis i denne situation kunne det jo være rart nok, hvis man som bruger kunne sige nej til CALL, men ja til DIAL (som apk'en ikke har bedt om).

PHK omtalte denne Tjernobyl-problematik allerede for tre år siden:
http://www.version2.dk/blog/trusted-computing-31318

Lars Tørnes Hansen's svar er især interessant:
http://www.version2.dk/blog/trusted-computing-31318#comment-178844

Jakob Damkjær

Clicktroling af version2 bruger, da denne "historie" kun eksistere i andedammen i Danmark.

og ikke rigtigt kan siges at være noget der kommer i nærheden af et "sikkerhedshul" specielt da hvis en app skulle "misbruge" denne dokumenterede feature ville ha en levetid på et par dage og derefter ville miste deres app dev licens og appen ville blive blacklistet på alle iOS dimser. Specielt når samme feature eksistere på android... så hvorfor kun nævne iPhone...

Well den åbentlyse årsag er at trafikken på version2 er lidt lav og de trænger til at lave "iPhone!!!!!" referance linkbaiting.

Var Airtame løbet tør for penge til at købe rigtige reklamer for deres produkt ? så de læste en manual...og opdagede noget der var en rimelig tynd kop the.

Sørgeligt at version2 og airtame ikke er i stand til at lave mindre gennemskuelig "social engeniering" clickbaiting.

Mon tro der kommer en artikel i aviser uden en techjournalist om et par dage bare fordi der var iPhone i titlen og der er minimalt faktisk "ny iPhone leaks" baseret på andet end fri fantasi...

Men imponerende "kvalitets filter" version2.dk har for tiden... virkelig verdensklasse...

Sune Riedel

og ikke rigtigt kan siges at være noget der kommer i nærheden af et "sikkerhedshul" specielt da hvis en app skulle "misbruge" denne dokumenterede feature ville ha en levetid på et par dage og derefter ville miste deres app dev licens og appen ville blive blacklistet på alle iOS dimser. Specielt når samme feature eksistere på android... så hvorfor kun nævne iPhone...


Hvad mener du med "hvis en app skulle misbruge" - det bliver jo dokumenteret i den animerede gif, at misbruget kan finde sted idag i eksisterende apps som f.eks. Facebook Messenger, Gmail eller Google+, hvis en bruger lokkes til at trykke på et "ondsindet" link, som de modtager - og det er mig bekendt apps, der allerede findes og ikke er blacklistet nogen steder.

Men bevares - om du vil kalde det misbrug, social engineering eller sikkerhedshul er mig ligemeget.

Resultatet er det samme: En bruger, der er lidt for hurtig til at trykke på et ondsindet link i én af de sårbare apps, og er lidt for langsom til at afbryde det efterfølgende opkald, får en dummebøde fra sit teleselskab for et opkald til et overtakseret nummer.

Sune Riedel

Og ja, det findes også på Android, men kun hvis brugeren har installeret en app, hvor han/hun på installationstidspunket explicit har givet tilladelse til at app'en foretager opkald. Så på den måde kan man sige, at Android tilbyder en mere fleksibel form for "sikkerhed" (via de her permissions som nævnt tidligere), men denne fleksibilitet antager også at brugeren på installationstidspunktet rent faktisk forstår de forskellige permissions og forholder sig til dem.

Log ind eller Opret konto for at kommentere