White hat angreb Apple og Paypal: Derfor er kodebiblioteker en reel fare

23. februar 2021 kl. 03:455
White hat angreb Apple og Paypal: Derfor er kodebiblioteker en reel fare
Illustration: Bigstock.
Supply chain-angreb via kodebiblioteker og pakkeværktøjer er en reel fare, viser succesfulde white hat-angreb mod Paypal, Apple og andre.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Kodebiblioteker, der som oftest består af open source software, er næsten magiske i deres egenskaber. Med en simpel kommando som:

  1. pip install pakkenavn

– kan ens software udstyres med nye egenskaber, som regel uden omkostninger.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
5 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
5
8. marts 2021 kl. 10:50

En angrebsvektor kunne være

  1. Upload malware til et obskurt python library
  2. Librariet er tilfældigvis krævet af andre libries som bruges til et bygge miljø.
  3. Bygge miljøet bruger Docker. Når containeren bygges, afvikles det obskure library, som nu kan kompromitere hele bygge miljøet.

Dette giver adgang til

  • Proprietær source kode
  • Eventuelle private bygge certifikater.
  • Måske diverse dokumentationer.
  • Ransomware kryptering af servere
  • Og meget andet

Det behøver heller ikke bare være Docker, man kan også snige den ind i hele distributioner.

4
26. februar 2021 kl. 15:54

Hvis nogen af jer skulle være interesseret i at tale certificering og hvordan vi bygger en sådan op, er I meget velkommen til at skrive eller kontakte mig. Så kan vi kikke på mulighederne sammen.

3
23. februar 2021 kl. 20:23

Det grundlæggende problem er ikke referencer til private pakker og alle mulige små detaljer. Det store problem er at folk hiver kode hjem med meget lidt grund til at have tillid til koden. Hvis man kigger på koden til Linux kernen så er der ret god grund til at have tillid til koden. Der er mange kloge mennesker der reviewer og dårlig kode belønnes ikke.

Men hvis jeg laver min egen distribution, hvorfor skulle nogen så have tillid til min distribution? Hvorfor skulle nogen stole på de binære filer jeg giver dem? Og alle de pakker der udgør Linux ... der er slet ikke samme niveau af reviews som med kernen. Der kræves kun et hul før bad guys er inde.

Læg oveni alle de python, .net, jvm, etc. pakker som udviklere henter bare med et enkelt keystroke. De fleste bruger ikke 2 sekunder på at overveje hvem der har lavet dem, hvad kvaliteten er, hvor mange contributers der er, hvorvidt koden vedligeholdes, etc. Eller for den sags skyld man kan stole på at de binære filer er relateret til den source kode de kan se.

Det samme gælder kommercielle virksomheder. Jeg er ganske sikker på at kernen i Windows har meget høj kvalitet. Og jeg ved at Microsoft dengang de var "king of the hill" investerede fantasilioner i kode-hardening. Jeg ved intet om hvordan det er gået siden. Eller hvad HPE, Nokia, Solarwinds, Peters software-biks, etc. gør der giver grund til tillid.

Vi har brug for et system hvor vi kan have tillid til "gratis" software. Fx. kunne man have et system hvor man kan vinde "reputation" ved at reviewe open source kode, hvor der er parallelle build processer sådan at vi kan verificere at binære filer reflekterer sourcen. Og for closed source har vi brug for et uafhængigt audit system der kan give mig grund til tillid.

Det er tid til at skabe et system vi kan have tillid til. Det vil gøre software (og hardware - husk problemerne med meltdown, spectre etc. i cpu'er) dyrere. Men alternativet er at alt for skræmmende.

2
23. februar 2021 kl. 16:26

Der skelnes mellem private og offentlige repos uploadet til NPM og så private repos, som ikke er uploadet til NPM. Hvis de private repos lå i NPM ville de være scoped og derfor ikke sårbare overfor dette angreb, da det så netop ikke er samme pakkenavn (auth-paypal ville så hedde @paypal/auth-paypal f.eks.). I dette tilfælde er det interne repoer, som ikke findes hos NPM og derfor blot er navngivet som en offentlig pakke. NPM kan så ikke vide at den er privat og vil nok blot slå den offentlige version op. Så svaret på dit spørgsmål er tilsyneladende ja, hvis det er et internt repo ikke uploadet til NPM.

1
23. februar 2021 kl. 15:53

Er det forstået korrekt sådan, at hvis man har et privat repo i npm, så vil en dependency altid defaulte til de offentlige repo's hvis de findes der?