Efterlod udviklerlogins i app-kode: Android-apps er pragteksemplarer på dårlig passwordskik

Illustration: Android Logo
Selv de nøgler, der var gemt bag udmærket kryptering, kunne graves frem med simple brute attacks.

Der er adskillige udviklere, der dovent efterlader deres krypteringsnøgler til applikationerne i selve koden til applikationerne. I nogle tilfælde er det endda standard for udviklingsværktøjet at hardcode nøglerne ind i programmet, skriver The Register.

Læs også: Banker skeler til karakteren i sikkerhedsscannere af hensyn til image

Den besynderlige tilgang til app- og passwordsikkerhed blev kortlagt i en analyse af 1,8 millioner gratis Android-apps af sikkerhedsvirksomheden CERT/CC og fremlagt på BSides-sikkerhedskonferencen.

Læs også: NemID nøgleapp på vej til smartphones og tablets

Og analysen viste flere skræmmende, gennemgående sikkerhedsfejl. Helt konkret flød det med PGP-nøgler, VPN-koder og admin-passwords i koden til de mange apps. Overordnet set fandt CERT næsten 20.000 apps, der havde usikre nøgler bygget ind.

Herunder Samsungs egen ‘Smart Home’-app.

»Jeg er overbevist om, at de apps, der koster penge, har præcis samme svagheder, men siden jeg allerede har downloadet 1,8 millioner gratis apps, er det for mig ikke en mulighed at teste alle de betalte også, end ikke hvis de kun kostede 99 cent,« siger Will Dormann, der er sikkerhedsforsker hos CERT/CC, på BSides.

Dovenskab og dårlig kultur

I nogle af tilfældene er der slet og ret tale om dovenskab fra udviklernes side, når de inkluderer essentielle nøgler i koden, frit tilgængelige. Det var eksempelvis tilfældet for en udvikler, der kodede både sine Android- og iOS-udviklerlogins ind i sin app.

Læs også: Nu vil Google blokere deres apps på uægte Android-versioner

Men værre er det ifølge The Register, at nogle app-værktøjer, der lader udviklere bygge deres egne apps, hardcoder nøglerne og koderne ind i applikationerne. Som standard.

Dette inkluderer værktøjet appinventor, der dog har ændret praksis efter at de blev bekendt med analysen.

Læs også: Android-telefoner bliver ikke patched i bund

Selv hvis nøglerne opbevares i en krypteret container, er de forholdsvis nemme at få fingre i. I hvert fald hvis containerne kun beskyttes af en simpel kode. Når CERT/CC fandt noget, der kunne ligne en sådan container, kørte de de to mest almindelige paswordcrackers, Jack the Ripper og Hashcat, på containerne. Sådan lykkedes det i flere tilfælde CCERT/CC at tiltvinge sig adgang til nøglerne med brute attacks - selvom de i princippet var sikret.

Læs også: Medie: Israelsk virksomhed hævder at kunne omgå låsen på nyeste iOS og Android

Dermed kunne CERT/CC som en sidegevinst af analysen udlede, at passwordcrackers er blevet stadigt bedre til at knække vores koder. Og at de koder, der anvendes til at sikre nøglerne i applikationerne, var himmelråbende lette at gætte.

Læs også: Amerikanerne flygter fra Facebook: Hver tiende har slettet deres profil - siger de

»Det handler, stadigvæk, om at bruge lange og komplicerede passwords. Undgå eksempelvis QWERTY,« siger Will Dorman til TheRegister.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
Christian Jørgensen

Jeg er helt enig i at det er dårlig skik at skrive sine kodeord ind i en app - men 20.000 apps ud af 1,8 mill. giver 1,1%, så næsten 99% af de testede apps har ikke denne svaghed.

Jeg kunne også godt tænke mig at vide, om dette kun gælder Android apps - der nævnes en Android og iOS udvikler i artiklen, så mon ikke det samme gælder for Apples platform? Hvis det er tilfældet, er artiklens overskrift unuanceret og blot et angreb på Android platformen...

Version2, kom gerne med lidt mere seriøse artikler!

Jesper S. Møller

Som appudvikler i op iOS eller Android kan din kode i altid blive splittet ad og undersøgt, som artiklen demonstrerer. Derfor duer det ikke gemme passwords i appens programfil, heller ikke hvis du vælger det bedsteste password i hele verden - hvad artiklen måske får sarte sjæle til at tro.
Problemet er jo generelt at man ønsker at tilgå et general purpose API med en brugsspecifik nøgle, i stedet for at have et App-tilrettet API.

Det nemmeste er derfor om app'ens støtte-APIer kan være helt åbne (så kræves der slet ingen passwords eller nøgler).

Alternativt kan du forudsætte at der er et system af en slags, som brugeren skal være identificeret overfor (f.eks. en Google-konto). Så kan du tjekke OAuth fra serversiden for at sikre at det i det mindste er den rigtige bruger, du snakker med.

Hvis du ikke kan åbne dine server-APIer for alle, og ikke vil kræve autentificering af dine brugere (men blot vil være sikker på at brugeren kalder op fra din app på en beskyttet enhed), har både iOS og Android API'er, der kan hjælpe, med tilhørende services:

  • På iOS hedder det DeviceCheck API'et
  • På Android er det Androids Device Attestation API

De kan lidt forskelligt, men understøtter begge muligheden for at tjekke at det der en rigtig app i den anden ende.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017