Ukens angrep: taleanrop over LTE (ReVoLTE)

Fra oversetteren og TL;DR

  1. TL; DR:

    Det ser ut til at VoLTE viste seg å være enda dårligere beskyttet enn de første Wi-Fi-klientene med WEP. En eksklusivt arkitektonisk feilberegning som lar deg XOR trafikken litt og gjenopprette nøkkelen. Et angrep er mulig hvis du er nær den som ringer og han ringer ofte.

  2. Takk for tipset og TL;DR Klukonin

  3. Forskere har laget en app for å finne ut om operatøren din er sårbar, les mer her. Del resultatene i kommentarene, VoLTE er deaktivert i min region på Megafon.

Om forfatteren

Matthew Green.

Jeg er kryptograf og professor ved Johns Hopkins University. Jeg har designet og analysert kryptografiske systemer brukt i trådløse nettverk, betalingssystemer og sikkerhetsplattformer for digitalt innhold. I min forskning ser jeg på ulike måter å bruke kryptografi for å forbedre brukernes personvern.

Det er en stund siden jeg skrev et innleggsformat "ukens angrep", og det gjorde meg opprørt. Ikke fordi det ikke var angrep, men mest fordi det ikke var et angrep på noe mye brukt nok til å få meg ut av forfatterblokka.

Men i dag kom jeg over interessant angrep kalt ReVoLTE for protokoller som jeg er spesielt begeistret for hacking, nemlig mobilnettverk (voice over) LTE-protokoller. Jeg er spent på disse spesielle protokollene – og dette nye angrepet – fordi det er svært sjelden å se faktiske mobilnettverksprotokoller og implementeringer bli hacket. Hovedsakelig fordi disse standardene ble utviklet i røykfylte rom og dokumentert i 12000 XNUMX sider lange dokumenter som ikke alle forskere kan håndtere. Implementering av disse angrepene tvinger dessuten forskere til å bruke komplekse radioprotokoller.

Dermed kan alvorlige kryptografiske sårbarheter spre seg over hele verden, kanskje bare for å bli utnyttet av myndigheter, før noen forsker legger merke til det. Men fra tid til annen er det unntak, og dagens angrep er et av dem.

Forfattere angrepBidragsytere: David Rupprecht, Katharina Kohls, Thorsten Holz og Christina Pöpper fra Ruhr-University Bochum og New York University Abu Dhabi. Dette er et flott angrep for å installere nøkkelen på nytt i taleprotokollen du sannsynligvis allerede bruker (forutsatt at du er fra en eldre generasjon som fortsatt ringer med en mobiltelefon).

Til å begynne med en kort historisk ekskursjon.

Hva er LTE og VoLTE?

Grunnlaget for våre moderne mobiltelefonistandarder ble lagt i Europa på 80-tallet av standarden Globalt system for mobil (Globalt system for mobilkommunikasjon). GSM var den første store digitale mobiltelefonistandarden, som introduserte en rekke revolusjonerende funksjoner, som f.eks. kryptering for å beskytte telefonsamtaler. Tidlig GSM ble først og fremst designet for talekommunikasjon, selv om penger kunne være det overføre andre data.

Etter hvert som dataoverføring ble viktigere i mobilkommunikasjon, ble Long Term Evolution (LTE)-standarder utviklet for å effektivisere denne typen kommunikasjon. LTE er basert på en gruppe eldre standarder som GSM, EDGE и HSPA og er designet for å øke datautvekslingshastigheten. Det er mye merkevarebygging og villedende ved feil betegnelsermen TL;DR er at LTE er et dataoverføringssystem som fungerer som en bro mellom eldre pakkedataprotokoller og fremtidige mobildatateknologier 5G.

Selvfølgelig forteller historien oss at når det er nok (IP) båndbredde tilgjengelig, vil konsepter som "stemme" og "data" begynne å bli uskarpe. Det samme gjelder moderne cellulære protokoller. For å gjøre denne overgangen jevnere, definerer LTE-standarder Voice-over-LTE (VoLTE), som er en IP-standard for å føre taleanrop direkte over dataplanet til et LTE-system, og omgå oppringt del av mobilnettverket helt. Som med standard VoIP-samtaler,VoLTE-samtaler kan avsluttes av mobiloperatøren og kobles til det vanlige telefonnettet. Eller (som det blir stadig mer vanlig) de kan rutes direkte fra en mobilklient til en annen, og til og med mellom forskjellige leverandører.

Som standard VoIP er VoLTE basert på to populære IP-baserte protokoller: Session Initiation Protocol (Sesjonsinitieringsprotokoll – SIP) for samtaleoppsett og sanntids transportprotokoll (Sanntids transportprotokoll, som skal kalles RTTP, men egentlig kalles RTP) for behandling av taledata. VoLTE legger også til noen ekstra båndbreddeoptimaliseringer, for eksempel topptekstkomprimering.

Ok, hva har dette med kryptering å gjøre?

LTE, liksom GSM, har et standardsett med kryptografiske protokoller for kryptering av pakker når de sendes over luften. De er hovedsakelig utformet for å beskytte dataene dine når de beveger seg mellom telefonen (kalt brukerutstyret eller UE) og mobiltårnet (eller hvor enn leverandøren din bestemmer seg for å avslutte forbindelsen). Dette er fordi mobilleverandører ser på eksterne avlyttingsenheter som fiender. Selvfølgelig.

(Men det faktum at VoLTE-forbindelser kan oppstå direkte mellom klienter på ulike leverandørnettverk betyr at selve VoLTE-protokollen har noen ekstra og valgfrie krypteringsprotokoller som kan forekomme på høyere nettverkslag. Dette er ikke relevant for den aktuelle artikkelen, bortsett fra faktum at de kan ødelegge alt (vi skal snakke om dem kort neste gang).

Historisk sett har kryptering i GSM vært mange svake punkter: dårlig chiffer, protokoller der bare telefonen ble autentisert til tårnet (som betyr at en angriper kan etterligne tårnet, og genererer "Rokke") og så videre. LTE korrigerte mange av de åpenbare feilene mens de beholdt mye av den samme strukturen.

La oss starte med selve kryptering. Forutsatt at nøkkeloppretting allerede har skjedd - og vi snakker om det om et minutt - så krypteres hver pakke med data ved hjelp av strømkryptering ved å bruke noe som kalles "EEA" (som i praksis kan implementeres ved å bruke ting som AES ). I hovedsak er krypteringsmekanismen her CTRsom Nedenfor:

Ukens angrep: taleanrop over LTE (ReVoLTE)
Hovedkrypteringsalgoritmen for VoLTE-pakker (kilde: ReVoLTE). EEA er et chiffer, "COUNT" er en 32-bits teller, "BEARER" er en unik sesjonsidentifikator som skiller VoLTE-tilkoblinger fra vanlig Internett-trafikk. "RETNING" indikerer i hvilken retning trafikken flyter - fra UE til tårnet eller omvendt.

Siden selve krypteringsalgoritmen (EEA) kan implementeres ved hjelp av en sterk chiffer som AES, er det usannsynlig at det vil være noe direkte angrep på selve chifferen som dette skjedde i GSM-tiden. Det er imidlertid klart at selv med en sterk chiffer, er dette krypteringsskjemaet en fin måte å skyte deg selv i foten på.

Spesielt: LTE-standarden bruker et (uautentisert) strømchiffer med en modus som vil være ekstremt sårbar hvis telleren – og andre innganger som «bærer» og «retning» – noen gang blir gjenbrukt. I moderne språkbruk er begrepet "ikke gjenbruksangrep", men de potensielle risikoene her er ikke noe moderne. De er kjente og eldgamle, og dateres tilbake til dagene med glam metal og til og med disco.

Ukens angrep: taleanrop over LTE (ReVoLTE)
Angrep på ikke-gjenbruk i CTR-modus eksisterte selv da Poison ble kjent

For å være rettferdig sier LTE-standardene: "Vennligst ikke gjenbruk disse målerne." Men LTE-standarder er omtrent 7000 sider lange, og i alle fall er det som å tigge barn om ikke å leke med en pistol. De vil uunngåelig, og forferdelige ting vil skje. Avfyringspistolen i dette tilfellet er et keystream-gjenbruksangrep, der to forskjellige konfidensielle meldinger XOR de samme keystream-bytene. Det er kjent at dette har en svært ødeleggende effekt på konfidensialiteten til kommunikasjon.

Hva er ReVoLTE?

ReVoLTE-angrepet viser at denne svært sårbare krypteringsdesignen i praksis misbrukes av maskinvare fra den virkelige verden. Spesifikt analyserer forfatterne ekte VoLTE-anrop gjort ved hjelp av kommersielt utstyr og viser at de kan bruke noe som kalles et "nøkkelreinstallasjonsangrep." (Mye ære for å finne dette problemet går til Reise og Lu (Raza & Lu), som var de første som påpekte den potensielle sårbarheten. Men ReVoLTE-forskning gjør det til et praktisk angrep).

La meg vise deg kort essensen av angrepet, selv om du bør se og kildedokument.

Man kan anta at når LTE etablerer en pakkedataforbindelse, blir oppgaven med voice over LTE bare et spørsmål om å dirigere talepakker over den forbindelsen sammen med resten av trafikken din. Med andre ord vil VoLTE være et konsept som bare eksisterer over 2. nivå [OSI-modeller – ca.]. Dette er ikke helt sant.

Faktisk introduserer LTE-lenkelaget konseptet "bærer". Bærere er separate sesjonsidentifikatorer som skiller forskjellige typer pakketrafikk. Vanlig internettrafikk (din Twitter og Snapchat) går gjennom én bærer. SIP-signalering for VoIP går gjennom en annen, og taletrafikkpakker behandles gjennom en tredje. Jeg er ikke veldig kunnskapsrik om LTE-radio og nettverksrutingsmekanismer, men jeg tror det er gjort på denne måten fordi LTE-nettverk ønsker å håndheve QoS-mekanismer (kvalitet på tjenesten) slik at forskjellige pakkestrømmer behandles på forskjellige prioritetsnivåer: dvs. din annenrangs TCP-tilkoblinger til Facebook kan ha lavere prioritet enn dine sanntidstaleanrop.

Dette er generelt ikke et problem, men konsekvensene er som følger. Nøkler for LTE-kryptering opprettes separat hver gang en ny "bærer" installeres. I utgangspunktet bør dette skje igjen hver gang du foretar en ny telefonsamtale. Dette vil resultere i at en annen krypteringsnøkkel brukes for hver samtale, og eliminerer muligheten for å gjenbruke den samme nøkkelen for å kryptere to forskjellige sett med taleanropspakker. Faktisk sier LTE-standarden noe sånt som "du bør bruke en annen nøkkel hver gang du installerer en ny bærer for å håndtere en ny telefonsamtale." Men dette betyr ikke at dette faktisk skjer.

Faktisk, i virkelige implementeringer, vil to forskjellige samtaler som forekommer i umiddelbar nærhet bruke den samme nøkkelen - til tross for at nye bærere med samme navn er konfigurert mellom dem. Den eneste praktiske endringen som skjer mellom disse samtalene er at krypteringstelleren tilbakestilles til null. I litteraturen kalles dette noen ganger reinstallasjon av nøkkelangrep. Man kan hevde at dette i hovedsak er en implementeringsfeil, selv om risikoen i dette tilfellet i stor grad ser ut til å stamme fra selve standarden.

I praksis resulterer dette angrepet i gjenbruk av nøkkelstrøm, der angriperen kan skaffe de krypterte pakkene $inline$C_1 = M_1 oplus KS$inline$ og $inline$C_2 = M_2 oplus KS$inline$, som tillater beregning av $inline$ C_1 tillegg C_2 = M_1 tillegg M_2$inline$. Enda bedre, hvis angriperen kjenner en av $inline$M_1$inline$ eller $inline$M_2$inline$, så kan han umiddelbart gjenopprette den andre. Dette gir ham et sterkt insentiv finn ut en av de to ukrypterte komponentene.

Dette bringer oss til det komplette og mest effektive angrepsscenarioet. Tenk på en angriper som kan avskjære radiotrafikk mellom en måltelefon og et mobiltårn, og som på en eller annen måte er heldig nok til å ta opp to forskjellige samtaler, hvor den andre skjer umiddelbart etter den første. Tenk deg nå at han på en eller annen måte kunne gjette det ukrypterte innholdet i en av samtalene. Med slik tilfeldighet angriperen vår kan fullstendig dekryptere den første samtalen ved å bruke en enkel XOR mellom de to settene med pakker.

Flaks har selvfølgelig ingenting med det å gjøre. Siden telefoner er laget for å motta anrop, vil en angriper som kan overhøre det første anropet kunne starte en andre anrop akkurat i det øyeblikket den første avsluttes. Dette andre anropet, hvis den samme krypteringsnøkkelen brukes igjen med telleren tilbakestilt til null, vil tillate at de ukrypterte dataene kan gjenopprettes. Dessuten, siden angriperen vår faktisk kontrollerer dataene under den andre samtalen, kan han gjenopprette innholdet i den første samtalen - takket være mange spesifikt implementerte små ting, spiller på hans side.

Her er et bilde av den generelle angrepsplanen hentet fra originaldokument:

Ukens angrep: taleanrop over LTE (ReVoLTE)
Angrepsoversikt fra ReVoLTE-dokument. Denne ordningen forutsetter at to forskjellige anrop utføres med samme tast. Angriperen kontrollerer den passive snifferen (øverst til venstre), samt en andre telefon, som han kan ringe til offerets telefon med.

Så virker angrepet virkelig?

På den ene siden er dette egentlig hovedspørsmålet for artikkelen om ReVoLTE. Alle de ovennevnte ideene er gode i teorien, men de etterlater seg mange spørsmål. Som for eksempel:

  1. Er det mulig (for akademiske forskere) å faktisk avskjære en VoLTE-forbindelse?
  2. Omnøkler virkelige LTE-systemer?
  3. Kan du faktisk starte en ny samtale raskt og pålitelig nok til at telefonen og tårnet kan gjenbruke nøkkelen?
  4. Selv om systemer omnøkler, kan du faktisk vite det ukrypterte innholdet i den andre samtalen - gitt at ting som kodeker og transkoding kan fullstendig endre (bit-for-bit) innholdet i den andre samtalen, selv om du har tilgang til "bitene "kommer du fra angrepstelefonen din?

ReVoLTEs arbeid svarer bekreftende på noen av disse spørsmålene. Forfatterne bruker en kommersiell programvare-rekonfigurerbar radiostrømsniffer kalt Airscope for å avlytte et VoLTE-anrop fra nedlinksiden. (Jeg tror bare det å sette seg inn i programvaren og få en grov ide om hvordan den fungerer tok måneder av livet til de stakkars avgangsstudentene - noe som er typisk for denne typen akademisk forskning).

Forskerne fant ut at for at gjenbruk av nøkkel skulle fungere, måtte den andre samtalen skje raskt nok etter at den første var over, men ikke for raskt - omtrent ti sekunder for operatørene de eksperimenterte med. Heldigvis spiller det ingen rolle om brukeren svarer på anropet innen denne tiden – «ringen» dvs. Selve SIP-tilkoblingen tvinger operatøren til å gjenbruke den samme nøkkelen.

Derfor dreier mange av de elendigste problemene seg rundt problem (4) – å motta biter av det ukrypterte innholdet i en samtale initiert av en angriper. Dette er fordi mye kan skje med innholdet ditt når det går fra angriperens telefon til offerets telefon over mobilnettverket. For eksempel slike skitne triks som å omkode en kodet lydstrøm, som etterlater lyden den samme, men fullstendig endrer sin binære representasjon. LTE-nettverk bruker også RTP-header-komprimering, som kan endre mye av RTP-pakken betydelig.

Til slutt bør pakkene sendt av angriperen være omtrent på linje med pakkene som ble sendt under den første telefonsamtalen. Dette kan være problematisk fordi endring av stillheten under en telefonsamtale resulterer i kortere meldinger (aka komfortstøy) som kanskje ikke passer godt med den opprinnelige samtalen.

Seksjon "angrep fra den virkelige verden" Det er verdt å lese i detalj. Den tar for seg mange av de ovennevnte problemene - spesielt oppdaget forfatterne at noen kodeker ikke er omkodet, og at omtrent 89 % av målanropets binære representasjon kan gjenopprettes. Dette gjelder for minst to europeiske operatører som ble testet.

Dette er en overraskende høy suksessrate, og ærlig talt mye høyere enn jeg forventet da jeg begynte å jobbe med dette dokumentet.

Så hva kan vi gjøre for å fikse det?

Det umiddelbare svaret på dette spørsmålet er veldig enkelt: siden essensen av sårbarheten er et nøkkelangrep for gjenbruk (reinstallasjon), bare fikse problemet. Sørg for at en ny nøkkel er hentet for hver telefonsamtale, og la aldri pakketelleren tilbakestille telleren til null med samme tast. Problem løst!

Eller kanskje ikke. Dette vil kreve oppgradering av mye utstyr, og ærlig talt er en slik løsning i seg selv ikke super pålitelig. Det ville vært fint om standarder kunne finne en sikrere måte å implementere krypteringsmodusene sine på, som ikke som standard er katastrofalt sårbare for slike problemer med gjenbruk av nøkkel.

Et mulig alternativ er å bruke krypteringsmoduser der misbruk av nonce ikke fører til katastrofale konsekvenser. Dette kan være for dyrt for noe nåværende maskinvare, men det er absolutt et område designere bør tenke på i fremtiden, spesielt ettersom 5G-standarder er i ferd med å ta over verden.

Denne nye studien reiser også det generelle spørsmålet om hvorfor de samme jævla angrepene dukker stadig opp i den ene standarden etter den andre, hvorav mange bruker svært like design og protokoller. Når du står overfor problemet med å installere den samme nøkkelen på nytt på tvers av flere mye brukte protokoller som WPA2, tror du ikke det kan være på tide å gjøre spesifikasjonene og testprosedyrene mer robuste? Slutt å behandle standardimplementere som gjennomtenkte partnere som er oppmerksomme på advarslene dine. Behandle dem som (utilsiktede) motstandere som uunngåelig kommer til å ta feil.

Eller alternativt kan vi gjøre det selskaper som Facebook og Apple i økende grad gjør: få taleanropskryptering til å skje på et høyere nivå av OSI-nettverksstabelen, uten å stole på produsenter av mobilutstyr. Vi kan til og med presse på for ende-til-ende-kryptering av taleanrop, slik WhatsApp gjør med Signal og FaceTime, forutsatt at den amerikanske regjeringen bare stopper snurre oss opp. Da (med unntak av noen metadata) ville mange av disse problemene ganske enkelt forsvinne. Denne løsningen er spesielt relevant i en verden der selv myndigheter er ikke sikre på om de stoler på utstyrsleverandørene sine.

Eller vi kan ganske enkelt gjøre det barna våre allerede har gjort: slutte å svare på de irriterende taleanropene.

Kilde: www.habr.com

Legg til en kommentar