Binances hændelse på 6,3 mia. USD: hvad skete der, og hvordan mindskes risikoen

Binances foreløbige resultater beskriver kompromittering af medarbejdere i juni og september, efterfulgt af en bredere indtrængning gennem interne AI-værktøjer den 20. oktober. Angriberne fik adgang til to kollegers computere og fandt et token til udrulning af containere. Den 29. oktober brugte de det til at udrulle ondsindet kode, der nåede signeringssystemerne og indledte uautoriserede overførsler.

Angriberne brugte også signeringstjenesten til at oprette en EIP-7702-delegering: tilladelse til, at kode under deres kontrol kunne handle på vegne af en Ethereum-wallet. Tilladelsen fandtes på blockchainen uafhængigt af Binances udbetalingssystemer. At standse udbetalingerne kunne ikke fjerne den. Binance måtte tilbagekalde den særskilt på blockchainen.

Den vigtige forskel er mellem at standse en aktivitet og at fjerne den bemyndigelse, der muliggør den. Udskiftning af en enhed, tilbagekaldelse af adgangsoplysninger til udrulning og annullering af en tilladelse i et andet system håndterer hver sin del af en indtrængning.

En bærbar computer, et udrulningssystem og en følsom tjeneste udfører forskellige opgaver. Risikoen vokser, når adgang til den ene automatisk åbner den næste. Et stjålet token kan lade en angriber udskifte software. Denne software kan derefter handle med tilladelser, som medarbejderen aldrig selv havde direkte.

Fire spørgsmål hjælper med at finde ud af, hvor denne kæde kan brydes:

1. Eksponering af adgangsoplysninger. Hvilken adgang til produktion kan en angriber få fra én medarbejders enhed?
2. Udrulningsrettigheder. Hvem kan ændre den kode, der kører med denne adgang?
3. Autorisation i tjenesten. Hvilke handlinger vil en følsom tjeneste acceptere fra denne kode?
4. Vedvarende adgang. Hvilke nye tilladelser kan bestå, efter at den oprindelige konto er deaktiveret?

Målet er at begrænse, hvordan beføjelser overføres mellem systemer, samt at identificere og tilbagekalde al yderligere adgang, der oprettes under en indtrængning. De følgende afsnit gennemgår fire sikkerhedsforanstaltninger, der understøtter dette mål.

Foranstaltning 1. Reducer de adgangsoplysninger, en bærbar computer kan blotlægge

Adgangsoplysninger er nyttige for en angriber, fordi et andet system accepterer dem som bevis på en bemyndigelse. Færre adgangsoplysninger til produktion på medarbejdernes enheder reducerer, hvad der kan stjæles, når et værktøj, et repository eller en browsersession kompromitteres.

Til rutinearbejde har en medarbejder ofte brug for tilladelse til at anmode om en handling, såsom at genstarte en tjeneste. De adgangsoplysninger, der udfører handlingen, kan blive hos en separat eksekveringsidentitet. At reducere eksponeringen indebærer både at fjerne unødvendige kopier og at administrere de adgangsoplysninger, der er tilbage:

• Erstat rutinemæssig direkte adgang med snævert definerede handlinger, hvor det er praktisk muligt.
• Brug separate identiteter til forskellige ansvarsområder, og begræns deres omfang og levetid.
• Før en fortegnelse over adgangsoplysninger, deres ejere og måden at tilbagekalde dem på.

Dette anvender princippet i OWASPs vejledning om håndtering af hemmeligheder: reducer menneskers håndtering af hemmeligheder, og giv hver identitet kun den nødvendige adgang. En stjålet arbejdsstation blotlægger så færre genanvendelige adgangsoplysninger, og beredskabsteamet ved, hvem der ejer dem, der stadig skal tilbagekaldes.

Foranstaltning 2. Behandl udrulningsrettigheder som produktionsrettigheder

En hemmelighed kan være skjult for en person, men tilgængelig for den kode, personen udruller. Den, der kan ændre koden, kan muligvis læse hemmeligheden, kalde et internt API eller handle som applikationens tjenestekonto. Adgang til udrulning skal derfor vurderes ud fra tilladelserne for den resulterende arbejdsbelastning.

OWASPs vejledning om CI/CD-sikkerhed behandler ændringer i repositories, pipelinekonfiguration og eksekveringsværter som dele af det samme sikkerhedsproblem. Beskyttelsen skal omfatte koden før udrulningen og dens tilladelser efter udrulningen:

• Kræv gennemgang af produktionskode, og beskyt den repository-gren, som automatiseringen kører.
• Kontroller ændringer i opgavedefinitioner, afhængigheder og input ved start såvel som i hovedscriptet.
• Giv arbejdsbelastninger kun de adgangsoplysninger og den netværksadgang, deres funktion kræver.

To sæt foranstaltninger skal arbejde sammen. Tilladelser til repositories og udrulning bestemmer, hvem der kan ændre koden. Separate politikker for identiteter, værter og netværk begrænser, hvad koden kan gøre, når den kører. Central opbevaring af hemmeligheder reducerer eksponeringen, mens disse politikker begrænser det program, der bruger hemmeligheden.

Foranstaltning 3. Autoriser handlingen, ikke kun den, der kalder

En signeringstjeneste kan holde sin private nøgle skjult og stadig acceptere en skadelig signeringsanmodning. Den samme forskel gælder for en database eller et cloud-API: autentificering af en arbejdsbelastning identificerer den, der kalder, mens autorisation afgør, hvad vedkommende må gøre.

OWASP anbefaler at kontrollere autorisation ved hver anmodning og afvise adgang, medmindre den udtrykkeligt er tilladt. I den modtagende tjeneste betyder det, at både handlingen og dens mål skal kontrolleres: tilladte betalingsmodtagere og beløb, databaseoperationer eller infrastrukturændringer.

Resultatet bør være en tjeneste, der vurderer den ønskede handling, selv når den, der kalder, allerede er betroet. Automatiseringen styrer, hvordan arbejde anmodes om. Den modtagende tjeneste styrer, hvilke handlinger den accepterer.

Foranstaltning 4. Tilbagekald adgang, der oprettes under indtrængningen

En angriber kan bruge en legitim identitet til at tilføje yderligere adgangsoplysninger eller tildele flere tilladelser. MITRE ATT&CK dokumenterer kontomanipulation som en måde at bevare eller udvide adgang på, herunder ved at tilføje cloud-adgangsoplysninger og SSH-nøgler. Deaktivering af den oprindelige session fjerner ikke nødvendigvis disse ændringer.

Binances delegering på blockchainen illustrerer, hvorfor beredskabsteamet skal undersøge tilladelserne i selve det berørte system. Inddæmningen skal omfatte både det første fodfæste og de beføjelser, der oprettes gennem det:

• Begræns, hvilke automatiseringsidentiteter der kan oprette yderligere adgangsoplysninger eller tildele tilladelser.
• Medtag nyoprettede konti, sessioner og delegeringer i beredskabsplanen.
• Bekræft tilbagekaldelsen i det system, der håndhæver tilladelsen, i stedet for at betragte en stoppet opgave som bevis på inddæmning.

Disse trin giver beredskabsteamet et defineret sæt identiteter og tilladelser at undersøge og tilbagekalde. De gør også inddæmningen testbar: teamet kan kontrollere, om hver kendt vej til den berørte tjeneste faktisk er lukket.

Disse foranstaltninger virker på forskellige lag: medarbejderens enhed, udrulningssystemet, den modtagende tjeneste og beredskabsprocessen. Hvert lag skal have en ansvarlig og en måde at kontrollere, at dets begrænsninger holder, når et andet lag kompromitteres.

Platforme til automatiseringsstyring håndterer den del af problemet, der ligger mellem en medarbejders anmodning og eksekvering i produktion. I Semaphore UI kan et team forberede en defineret opgave, styre, hvem der må køre eller ændre den, og udføre den med en separat identitet. Autorisation inde i måltjenesten og tilbagekaldelse af tilladelser oprettet andre steder er stadig disse systemers og beredskabsteamets ansvar.

Forestil dig en driftsingeniør på vagt, der skal genstarte en API-tjeneste. En vedligeholder forbereder en playbook og en Task Template, der fastlægger målværterne og fremgangsmåden for genstarten. Ingeniøren starter opgaven og læser resultatet uden at åbne en SSH-session til produktion. De to veje nedenfor udfører den samme genstart, men placerer adgangsoplysningerne til eksekvering hos forskellige parter.

Opbygningen af genstartsforløbet kræver fire sammenhængende trin: opret en begrænset eksekveringsidentitet, definer, hvad brugerne må køre eller ændre, vælg eksekveringsmiljøet, og gør resultatet synligt. Når de trin er på plads, kan den samme tilgang udvides til udrulninger.

En stjålet operatørsession kan stadig anmode om de handlinger, kontoen har tilladelse til at køre. Selv en tilladt genstart kan forstyrre en tjeneste, hvis den gentages mange gange. Test det konfigurerede forløb med en realistisk operatørkonto i et stagingmiljø, og undersøg både dens muligheder og teamets reaktion på misbrug:

• Tilladelser til opgaver og input. Afprøv de faktiske roller og startmuligheder, herunder alternative grene, inventarer og argumenter.
• Adgang ud over den tilsigtede handling. Kontroller adgang til andre skabeloner, adgangsoplysninger og produktionssystemer, herunder hvad runnerens proces kan nå.
• Opdagelse og driftsmæssig påvirkning. Bekræft, hvem der modtager resultater, hvem der undersøger uventet aktivitet, og om gentagne kørsler kan forårsage uacceptabel forstyrrelse.
• Tilbagekaldelse. Test tilbagekaldelse af sessioner og tokens, og identificer tilladelser, som eksekveringsidentiteten kan oprette andre steder.

Dokumenter den adgang, testkontoen beholder, og luk enhver vej, der går ud over handlingens formål. Teamet bør afslutte øvelsen med viden om både, hvad en stjålet session kan gøre, og hvordan misbruget kan opdages og inddæmmes.

Adgangskontrol arbejder sammen med endpointbeskyttelse og et team, der ved, hvordan det skal reagere. Gør det forberedte forløb så bekvemt, at folk kan bruge det uden at vende tilbage til delte nøgler og udokumenterede genveje. Understøt det med nogle få daglige vaner:

• Kør ukendte installationsprogrammer og opgaver fra jobsamtaler i midlertidige, isolerede miljøer uden virksomhedsadgangsoplysninger, monterede værtsmapper eller adgang til interne netværk.
• Gør det let at indberette mistænkelig aktivitet tidligt og uden bebrejdelser. Giv folk en tydelig kontaktperson og en vej til hændelseshåndtering.
• Gennemgå adgang, når ansvarsområder ændres, oprethold en kontrolleret procedure for nødadgang, og øv tilbagekaldelse før en hændelse.

Disse vaner forbinder forebyggelse, opdagelse og genopretning med det daglige arbejde. De hjælper med at holde adgangsmodellen korrekt, når ansvaret ændrer sig, og giver teamet en velkendt reaktion, når der opstår en mistænkelig hændelse.

Den centrale lære er at begrænse, hvor mange beføjelser én kompromitteret identitet kan samle. Færre adgangsoplysninger på bærbare computere, gennemgået automatisering, begrænsede eksekveringsværter og autorisation inde i produktionstjenester reducerer alle de veje, en angriber kan følge.

Semaphore gør flere af disse foranstaltninger til en del af et gentageligt forløb: forberedte opgaver, separate tilladelser til kørsel og redigering, centralt leverede adgangsoplysninger og synlige eksekveringsregistreringer. Operatører får de handlinger, deres arbejde kræver, mens vedligeholdere beholder kontrollen over koden og adgangsoplysningerne bag dem.

Start med én hyppigt brugt produktionshandling: forbered dens opgaveskabelon, tildel de nødvendige operatørtilladelser, og test den resulterende adgang, før den direkte forbindelse, den erstatter, udfases. Et nyttigt mål for fremskridt er, hvor lidt en angriber kan gøre med den næste konto, der kompromitteres.