Optus-brud - Aussie telco fortalte, at det bliver nødt til at betale for at erstatte ID'er

Sidste uges cyberintrusion hos det australske teleselskab Optus, som har omkring 10 millioner kunder, har vakt vrede hos landets regering over, hvordan det overtrådte firma skal håndtere stjålne ID-oplysninger.

Darkweb screenshots dukkede hurtigt op efter angrebet, med en undergrund BreachForums bruger, der går under det almindelige navn optusdata tilbyder to trancher af data med påstand om, at de havde to databaser som følger:

  11,200,000 brugerregistreringer med navn, fødselsdato, mobilnummer og ID 4,232,652 registreringer indeholdt en slags ID-dokumentnummer 3,664,598 af ID'erne var fra kørekort 10,000,000 adresseregistre med e-mail, fødselsdato, ID-nummer og mere 3,817,197 havde ID-nummer, 3,238,014, XNUMX. af ID'erne var fra kørekort

Sælger skrev, "Optus, hvis du læser! Prisen for ikke at sælge [sic] data er 1,000,000$US! Vi giver dig 1 uge til at beslutte dig.”

Sædvanlige købere, sagde sælgeren, kunne have databaserne for $300,000 som et job, hvis Optus ikke tog imod sit $1m "eksklusiv adgang" tilbud inden for ugen.

Sælgeren sagde, at de forventede betaling i form af Monero, en populær kryptovaluta, der er sværere at spore end Bitcoin.

Monero transaktioner er blandet sammen som en del af betalingsprotokollen, hvilket gør Monero-økosystemet til en slags kryptomønt-tumbler eller anonymiser i sig selv.

Hvad skete der?

Selve databruddet skyldtes tilsyneladende manglende sikkerhed på det, der i jargonen er kendt som en API-slutpunkt. (API er en forkortelse for applikationsprogrammeringsgrænseflade, en foruddefineret måde for en del af en app, eller samling af apps, til at anmode om en slags service eller hente data fra en anden.)

På nettet har API-endepunkter normalt form af specielle URL'er, der udløser specifik adfærd eller returnerer anmodede data, i stedet for blot at servere en webside.

For eksempel en URL som https://www.example.com/about kan ganske enkelt feed back en statisk webside i HTML-form, såsom:

  
    
       
About this site
       
This site is just an example, as the URL implies.
    
   

Besøg af URL'en med en browser vil derfor resultere i en webside, der ser ud, som du ville forvente:

Men en URL som f.eks https://api.example.com/userdata?id=23de­6731­e9a7 kan returnere en databaserecord, der er specifik for den angivne bruger, som om du havde foretaget et funktionskald i et C-program i stil med:

   /* Typedefs and prototypes */
   typedef struct USERDATA UDAT;
   UDAT* alloc_new_userdata(void);
   int get_userdata(UDAT* buff, const char* uid);

   /* Get a record */
   UDAT* datarec = alloc_new_userdata();
   int err = get_userdata(datarec,"23de6731e9a7");

Hvis det antages, at det anmodede bruger-id eksisterede i databasen, kan kald af den tilsvarende funktion via en HTTP-anmodning til slutpunktet producere et svar i JSON-format som dette:

   {  
      "userid"   : "23de6731e9a7",
      "nickname" : "duck",
      "fullname" : "Paul Ducklin",
      "IDnum"    : "42-4242424242"  
   }

I en API af denne art ville du sandsynligvis forvente, at flere cybersikkerhedsforanstaltninger er på plads, såsom:

• Godkendelse. Hver webanmodning skal muligvis inkludere en HTTP-header, der angiver en tilfældig (ugætterlig) sessionscookie, der er udstedt til en bruger, der for nylig havde bevist sin identitet, for eksempel med et brugernavn, adgangskode og 2FA-kode. Denne form for sessionscookie, som typisk kun er gyldig i en begrænset periode, fungerer som et midlertidigt adgangskort til opslagsanmodninger, der efterfølgende udføres af den forhåndsgodkendte bruger. API-anmodninger fra uautoriserede eller ukendte brugere kan derfor øjeblikkeligt afvises.
• Adgangsbegrænsninger. For databaseopslag, der kan hente personligt identificerbare data (PII), såsom ID-numre, hjemmeadresser eller betalingskortoplysninger, kan serveren, der accepterer API-endepunktsanmodninger, pålægge netværksbeskyttelse for at bortfiltrere anmodninger, der kommer direkte fra internettet. En angriber skal derfor først kompromittere en intern server og vil ikke være i stand til at søge efter data direkte over internettet.
• Svært at gætte database-id'er. Skønt sikkerhed gennem uklarhed (også kendt som "de vil aldrig gætte det") er et dårligt underliggende grundlag for cybersikkerhed, det nytter ikke noget at gøre tingene nemmere, end du skal for skurkene. Hvis dit eget bruger-id er 00000145, og du ved, at en ven, der tilmeldte sig lige efter du fik 00000148, så er det et godt gæt, at gyldige bruger-id-værdier starter ved 00000001 og gå op derfra. Tilfældigt genererede værdier gør det sværere for angribere, der allerede har fundet et smuthul i din adgangskontrol, at køre en løkke, der igen og igen forsøger at hente sandsynlige bruger-id'er.
• Satsbegrænsende. Enhver gentagne sekvens af lignende anmodninger kan bruges som en potentiel IoC, eller indikator for kompromis. Cyberkriminelle, der ønsker at downloade 11,000,000 databaseelementer, bruger generelt ikke en enkelt computer med et enkelt IP-nummer til at udføre hele jobbet, så bulk-downloadangreb er ikke altid umiddelbart indlysende kun fra traditionelle netværksflows. Men de vil ofte generere mønstre og aktivitetshastigheder, der simpelthen ikke matcher, hvad du ville forvente at se i det virkelige liv.

Tilsyneladende var få eller ingen af ​​disse beskyttelser på plads under Optus-angrebet, især inklusive den første ...

…hvilket betyder, at angriberen var i stand til at få adgang til PII uden nogensinde at skulle identificere sig selv overhovedet, endsige for at stjæle en legitim brugers loginkode eller autentificeringscookie for at komme ind.

På en eller anden måde, ser det ud til, at et API-endepunkt med adgang til følsomme data blev åbnet til internettet som helhed, hvor det blev opdaget af en cyberkriminel og misbrugt til at udtrække information, der skulle have stået bag en form for cybersikkerhedsportcullis.

Desuden, hvis angriberens påstand om at have hentet i alt mere end 20,000,000 databaseposter fra to databaser, antager vi [a] at Optus userid koder var let beregnet eller gættet, og [b] at ingen "databaseadgang har ramt usædvanlige niveauer"-advarsler gik af.

Desværre har Optus ikke været særlig klar over, hvordan angrebet udspillede sig, siger blot:

Q. Hvordan skete dette?

A. Optus var offer for et cyberangreb. […]

Q. Er angrebet blevet stoppet?

A. Ja. Efter at have opdaget dette, lukkede Optus øjeblikkeligt angrebet ned.

Med andre ord ser det ud som om at "lukke angrebet" indebar at lukke smuthullet mod yderligere indtrængen (f.eks. ved at blokere adgangen til det uautentificerede API-slutpunkt) i stedet for at opsnappe det indledende angreb tidligt efter kun et begrænset antal poster var blevet stjålet .

Vi formoder, at hvis Optus havde opdaget angrebet, mens det stadig var i gang, ville virksomheden have angivet i sin FAQ, hvor langt skurkene var nået, før deres adgang blev lukket.

Hvad er det næste?

Hvad med kunder, hvis pas- eller kørekortnumre blev afsløret?

Hvor stor en risiko udgør lækage af et ID-dokumentnummer snarere end mere fuldstændige detaljer om selve dokumentet (såsom en højopløsningsscanning eller bekræftet kopi), for ofret for et databrud som dette?

Hvor meget identifikationsværdi skal vi give til ID-numre alene, givet hvor udbredt og hyppigt vi deler dem i disse dage?

Ifølge den australske regering er risikoen betydelig nok til, at ofre for bruddet bliver rådet til at erstatte berørte dokumenter.

Og med muligvis millioner af berørte brugere kan gebyrerne for dokumentfornyelse alene løbe op i hundredvis af millioner af dollars og nødvendiggøre annullering og genudstedelse af en betydelig del af landets kørekort.

Vi anslår, at omkring 16 millioner australiere har licenser og er tilbøjelige til at bruge dem som ID inde i Australien i stedet for at bære deres pas rundt. Så hvis optusdata BreachForum-plakaten fortalte sandheden, og tæt på 4 millioner licensnumre blev stjålet, tæt på 25 % af alle australske licenser skal muligvis udskiftes. Vi ved ikke, hvor nyttigt dette faktisk kan være i tilfælde af australske kørekort, som udstedes af individuelle stater og territorier. I Storbritannien, for eksempel, er dit kørekortnummer helt åbenlyst algoritmisk afledt af dit navn og fødselsdato, med en meget beskeden mængde blandet og kun nogle få tilfældige tegn indsat. En ny licens får derfor et nyt nummer, der minder meget om det tidligere.

De uden licens eller besøgende, der havde købt SIM-kort fra Optus på grundlag af et udenlandsk pas, ville i stedet skulle udskifte deres pas – et australsk pasudskiftning koster tæt på AU$193, et britisk pas er £75 til £85, og en amerikansk fornyelse er $130 til $160.

(Der er også spørgsmålet om ventetider: Australien anbefaler i øjeblikket, at erstatningspas vil tage mindst 6 uger [2022-09-28T13:50Z], og det er uden en pludselig stigning forårsaget af brudrelateret behandling; i Storbritannien, pga. eksisterende efterslæb, fortæller Hans Majestæts regering i øjeblikket ansøgere om at tillade 10 uger til pasfornyelse.)

Hvem bærer omkostningerne?

Selvfølgelig, hvis udskiftning af alle potentielt kompromitterede ID'er anses for nødvendig, er det brændende spørgsmål, "Hvem skal betale?"

Ifølge den australske premierminister, Anthony Albanese, er der ingen tvivl om, hvor pengene til at erstatte pas skal komme fra:

Denne eftermiddag @albomp gav parlamentet en vigtig opdatering om Optus-sikkerhedsbruddet.

Ikke alene kræver vi Optus betaling for erstatningspas til dem, der er berørt af bruddet, men vi er også forpligtet til at styrke vores privatlivslovgivning gennem gennemgangen af ​​Privacy Act. pic.twitter.com/JyoRJxyM3p

— Clare O'Neil MP (@ClareONeilMP) September 28, 2022

Der er intet ord fra den føderale lovgiver om udskiftning af kørekort, det er et spørgsmål, der håndteres af stater og territorier...

...og intet ord om, hvorvidt "erstat alle dokumenter" vil blive en rutinemæssig reaktion, hver gang et brud, der involverer ID-dokumenter, bliver rapporteret, noget der let kunne oversvømme den offentlige service, da licenser og pas normalt forventes at vare 10 år hver.

Hold øje med dette sted – det ser ud til at blive interessant!

---