Nye oplysninger om SolarWinds: Hackere fik fri adgang til intern build-server

Illustration: arkiv

Det var gennem en intern build server at hackere formåede at kompromittere den udbredte SolarWinds-software. Det skriver Crowdstrike selv i en blog.

Her fremgår det også, at hackerne målrettet gik efter netop build serveren, for derefter at kunne deploye malwaren til Crowdstrikes mange kunder.

»The 'Sunspot' had one singular purpose — namely, to watch the build server for build commands that assembled Orion, one of SolarWinds' top products, an IT resources monitoring platform used by more than 33,000 customers across the globe,« skriver Crowdstrike.

Så snart en build command blev eksekveret på serveren ville malwaren erstatte source code-filerne med hvad end den ønskede og på den måde integrere hvad end malwaren ville i selskabets produkter.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Klavs Klavsen

.gad vide hvor mange build servere i verden er blevet angrebet på den måde

Vi har ihvertfald observeret nogen gitlab (en type build server/CI system) servere blive angrebet med success, så man skal passe godt på sine udvikleres laptops (flere store hacks er sket ved at hacke en udviklers computer).. Personligt bruger vi yubikeys til alle GPG og SSH operationer (inkl. git push til gitlab) - da yubikey's kan opsættes til at kræve fysisk berøring ved hver aktion (så en hacket developer laptop - vil kun betyde at når hackeren forsøger at tilgå noget fra den laptop, så blinker yubikey'en bare - og det bliver praktisk umuligt at lave særlig meget (få forsøg kan muligvis lykkedes, hvis udvikleren tror det er hans egen igangværende operation der blinkes om). Og yubikeys er samtidigt noget udvikleren elsker - fordi de så slipper for kodeord.. de indtaster 'pin' for at låse yubikey'en op efter de har tændt computeren for at arbejde - og så behøver de kun at røre yubikey'en - for at logge ind allesteder, se et bestemt kodeord eller andet de nu skal der kræver at man påviser sin identitet.

At kræve "touch" for hver operation giver udfordringer med Ansible og f.ex. re-kryptering af ens passwordstore(.org) - men heldigvis var Yubikey modtagelige for fornuft og deres seneste firmware fik support for "kortvarig 'cache' af touch" fra omkring oktober 2020 af.. så man kan opsætte en timeout hvor en "long touch" af key'en - godkender alt indenfor f.ex. 30 sekunder.

IMHO er det, der vi skal over - for at få ordentlig OG brugervenlig sikkerhed, der fordi det ER brugervenligt, rent faktisk også vil blive brugt.

Og når man først har en yubikey - så er git -S super simpelt, for at tilføje en PGP signering af ens commit - der viser at det ER en selv der har lavet koden (med en rimelig høj grad af sikkerhed - nogen skal inject'e noget lokalt før der køres git add+git commit som brugeren overser) - og disse signaturer kan så bruges til at gøre build step'et sikrere, ved at checke at al kode "git clone" henter til at build'e er verificerbart. Dette skal ligeledes gøres med de docker images man bruger til at build'e - for at sikre at de docker images og de build tools i dem, ikke er "ændret ved".. Det er en noget tung, men sund process :)

Vi bygger f.ex. vores docker billeder fra et fælles Ubuntu base image - som er Open Source og man kan bare clone tools til at builde det fra github, hvis man ikke vil hente fra dockerhub - og bygge det selv, - og så rebuild'e alle andre docker images, på baggrund af det som From image.. For at få en simplere og mere sikker "build verden".

  • 6
  • 0
Log ind eller Opret konto for at kommentere