A fordítótól és TL;DR
TL;DR:
Úgy tűnik, hogy a VoLTE védelme még gyengébb, mint az első Wi-Fi klienseké WEP védelemmel. Kizárólag architekturális hiba, amely lehetővé teszi a forgalom XOR-ozását és a kulcs helyreállítását. A támadás akkor lehetséges, ha a támadó a hívó közelében van, és az illető gyakran hívásokat indít.
Köszönöm a tippet és TL;DR
A kutatók készítettek egy alkalmazást, amely megmondja, hogy sebezhető-e az ön szolgáltatója, bővebben . Kérem, ossza meg a megjegyzésekben az eredményeket, az én régiómban a Megafon VoLTE le van tiltva.
A szerzőről
Matthew Green.
Én kriptográfus vagyok és a Johns Hopkins Egyetem professzora. Kriptográfiai rendszerek tervezésével és elemzésével foglalkozom, amelyeket vezeték nélküli hálózatokban, fizetési rendszerekben és digitális tartalomvédelmi platformokon használnak. Kutatásaim során különböző módszereket vizsgálok a kriptográfia felhasználására a felhasználók adatvédelmének növelése érdekében.
Rég írtam már bejegyzést a , és ez elszomorított. Nem azért, mert nem történt támadás, hanem elsősorban azért, mert nem volt olyan támadás, ami elég széles körben használt rendszert érintett volna ahhoz, hogy kreatív válságomból kihozzon.
De ma ráakadtam egy ReVoLTE néven, amely a sebezhetőségük miatt különösen izgalmas számomra, nevezetesen a mobilhálózatok (hangátviteli) LTE protokolljaival. Én kifejezetten ezeket a protokollokat szeretem – és ezt az új támadást – mert nagyon ritkán láthatunk valódi protokollok és mobilhálózati megvalósítások feltörését. Főként azért, mert ezeket a szabványokat füstös szobákban fejlesztették ki, és 12000 oldalas dokumentumokba foglalták, amelyekkel nem boldogul minden kutató. Továbbá, ezeknek a támadásoknak a megvalósítása a kutatókat bonyolult rádióprotokollok használatára kényszeríti.
Így súlyos kriptográfiai sebezhetőségek terjedhetnek el világszerte, és valószínűleg csak kormányok használják majd őket, mielőtt egy kutató felfigyelne rájuk. De időnként vannak kivételek, és a mai támadás – egyike ezeknek.
Authors : David Rupprecht, Katharina Kohls, Thorsten Holz és Christina Pöpper a Bochumi Ruhr Egyetemről és az Abu-Dzabi New Yorki Egyetemről. Ez egy kiváló támadás a kulcs újrainstallálására a hangprotokollban, amit valószínűleg már használ, (ha feltételezzük, hogy Ön az idősebb generációhoz tartozik, aki még mindig mobiltelefonnal telefonál).
Kezdetnek – rövid történelmi áttekintés.
Mi az LTE és a VoLTE?
A modern mobiltelefonos normák alapjait Európában az 1980-as években fektették le a (Globális Mobil Rendszer). A GSM volt az első jelentős digitális mobiltelefonos szabvány, amely számos forradalmi funkciót vezetett be, például a a telefonhívások védelme érdekében. A korai GSM-t elsősorban hangátvitelre fejlesztették ki, bár pénzért lehetett .
Ahogy a mobilkommunikációban egyre fontosabbá vált az adatátvitel, a Long Term Evolution (LTE) szabványokat dolgozták ki ennek a típusú kommunikációnak a racionalizálására. Az LTE egy sor régebbi szabványra, például GSM-re, és épül, és arra hivatott, hogy növelje az adatátviteli sebességet. Ezen a területen sok brandelés és de a lényeg az, hogy az LTE egy adatátviteli rendszer, amely hidat képez a régi csomagkapcsolt adatátviteli protokollok és a jövő mobiladatátviteli technológiái között. .
Nyilvánvaló, hogy a történelem azt mutatja, hogy amint elegendő (IP) sávszélesség áll rendelkezésre, olyan fogalmak, mint a „hang” és az „adatok” kezdenek elmosódni. Ugyanez vonatkozik a modern mobil protokollokra is. Annak érdekében, hogy ez az átmenet zökkenőmentesebb legyen, az LTE szabványok meghatározzák (VoLTE), amely egy IP szabvány a hanghívások közvetlen továbbítására az LTE rendszer adatátviteli síkján, teljesen megkerülve a mobilhálózat kapcsolt részét. Akárcsak a szokásos , a VoLTE hívások terminálisan a mobilszolgáltató által kezelésbe vehetők és csatlakoztathatók a hagyományos telefonhálózatra. Vagy (ami egyre gyakoribb) ezek közvetlenül egy mobil ügyféltől a másikhoz, sőt különböző szolgáltatók között is.
Akárcsak a hagyományos VoIP, a VoLTE is két népszerű IP-alapú protokollon alapul: a hívások kezdeményezését szolgáló protokoll ( – SIP), és a valós idejű adatátviteli protokoll (, amelynek elnevezése RTTP lenne, de valójában RTP) a hangadatok feldolgozására. A VoLTE néhány extra sávszélesség-optimalizációt is hozzáad, mint például a fejlécek tömörítése.
Nos, mi köze ennek a titkosításhoz?
Az LTE, akárcsak a , rendelkezik egy standard titkosítási protokollkészlettel az adatok levegőben történő továbbításának titkosítására. Ezek elsősorban az adataid védelmét szolgálják, amikor azok a telefonod (amelyet 'felhasználói berendezésnek' vagy UE-nek neveznek) és a mobiltelefon-torony (vagy bárhol, ahol a szolgáltatód eldönti a kapcsolat lezárását) között mozognak. Ez azért van, mert a mobil szolgáltatók ellenséges eszközöknek tekintik a külső lehallgatókat. Nos, természetesen.
(A VoLTE-kapcsolatok közvetlenül különböző szolgáltatók hálózatain belül létesülhetnek, így magának a VoLTE protokollnak vannak további, opcionális titkosítási protokolljait is, amelyek magasabb hálózati szinteken történhetnek. Ezen írás keretein belül ez nem tartozik a témához, csak annyit kell tudni róla, hogy mindent elronthat. Röviden beszélünk róluk később.)
Történelmileg a GSM-ben a titkosításnak : gyenge „Stingray” Kezdjük a titkosítással. Tekintve, hogy a kulcs létrehozása már megtörtént – és erről mindjárt beszélünk – minden adatcsomagot egy folytonos titkosítási módban titkosítanak egy bizonyos „EEA” nevű titkosítóval (amely a gyakorlatban olyan dolgokkal valósítható meg, mint az AES). Lényegében a titkosítási mechanizmus itt
CTR , ahogy az alább látható:
A VoLTE csomagok titkosításának fő algoritmusának forrása: ). Az EEA kód, a „COUNT” egy 32 bites számláló, a „BEARER” pedig egyedi azonosító, amely elválasztja a VoLTE és a hagyományos internetes forgalmat. A „DIRECTION” jelzi, hogy a forgalom melyik irányba halad – az UE-től a toronyhoz vagy fordítva.
Mivel a titkosítási algoritmus (EEA) erős titkosítást, például AES-t használhat, valószínűtlen, hogy közvetlen támadás érje magát a kódot, mint ahogyan az régen . Azonban nyilvánvaló, hogy még erős titkosítás mellett is ez a titkosítási séma kiváló módja lehet, hogy saját magunknak ártson.
Különösen: a LTE szabványban (nem hitelesített) folyamatos titkosítást használnak olyan módban, amely rendkívül sebezhető, ha a számláló – és más bemenetek, mint a „bearer” és a „direction” – valaha újra felhasználásra kerülnek. A mai nyelvben ezt a jelenséget „nonce újrahasználat támadásának” nevezik, de a lehetséges kockázatok nem újak. Ezek régóta ismertek, már a glam metal és akár a disco idejére nyúlnak vissza.
A nonce újrahasználat ellen irányuló támadások a CTR módban már akkor is léteztek, amikor a Poison népszerűvé váltak.
Az igazsághoz hozzátartozik, hogy a LTE szabványok kimondják: „Kérjük, ne használja ezeket a számlálókat újra.” De a LTE szabványok 7000 oldal körüli terjedelműek, és ez valójában olyan, mintha megkérnénk a gyerekeket, hogy ne játszanak fegyverrel. Elkerülhetetlen, hogy meg fogják tenni, és borzalmas dolgok fognak történni. Ebben az esetben a fegyver, ami sült el, az a kulcscsere újrafelhasználásával végrehajtott támadás, ahol két különböző titkos üzenetet XOR-oznak ugyanazokkal a kulcsoffset bájtokkal. Ismert, hogy ez .
Mi az a ReVoLTE?
A ReVoLTE támadás azt mutatja, hogy a gyakorlatban ez a nagyon sebezhető titkosítási konstrukciót valójában hibásan használják a valódi berendezések. Különösen a szerzők valós VoLTE hívásokat elemeznek, amelyeket kereskedelmi berendezések használtak, és megmutatják, hogy ilyen módon egy úgynevezett „kulcscsere támadást” használnak. (Bárki, aki ezt a problémát felfedezte, nagy érdemeket szerzett) (Raza & Lu), akik először jelezték a potenciális sebezhetőséget. De a ReVoLTE kutatások gyakorlati támadássá alakítják át azt.
Engedje meg, hogy röviden bemutassam az támadás lényegét, bár érdemes megnéznie az .
Feltételezhető, hogy amint a LTE beállítja az adatcsomag-küldési kapcsolatot, a hangátvitel LTE fölött csupán annyit jelent, hogy a hangcsomagokat az ezen a kapcsolaton keresztül haladó többi forgalommal együtt kell útvonalazni. Más szavakkal, a VoLTE egy olyan koncepció, amely csak a [OSI modellek – például]. Ez nem teljesen így van.
Valójában az LTE adatkapcsolati szint bevezeti a "bearer" fogalmát. A bearer különböző azonosítókat jelent, amelyek megkülönböztetik a különböző típusú csomagforgalmakat. A normál internetforgalom (az Ön Twittere és Snapchatje) egy bearer-en keresztül halad. A VoIP jelzések a másikon, míg a hangforgalmi csomagok a harmadikon. Nem értem túl jól a rádiósáv és az LTE hálózati útvonalválasztás mechanizmusaiban, de feltételezem, hogy ezt így alakították ki, mert az LTE hálózatok szeretnék biztosítani a QoS (szolgáltatás-minőség) mechanizmusok működését, hogy a különböző csomagáramokat eltérő prioritással kezeljék: azaz az Ön másodrangú TCP kapcsolatai a Facebookon alacsonyabb prioritást élvezhetnek, mint a valós idejű telefonhívásai.
Ez alapvetően nem jelent problémát, de ebből a következő következik. Az LTE titkosítási kulcsokat minden alkalommal külön-külön hoznak létre, amikor új "bearer"-t állítanak be. Elméletileg ez minden alkalommal újra kellene, hogy történjen, amikor új telefonhívást kezdeményez. Ez oda vezet, hogy minden hívás más titkosítási kulcsot használ, ami kizárja annak lehetőségét, hogy ugyanazt a kulcsot két különböző hanghívás csomagjainak titkosítására használják. Valóban, az LTE szabvány valami ilyesmit mond: "különböző kulcsokat kell használni minden alkalommal, amikor új bearert állít be, hogy új telefonhívást kezeljen". De ez nem jelenti azt, hogy ez valóban így történik.
Valójában a valós megvalósítások során két különböző hívás, amelyek közvetlen időbeli közelségben zajlanak, ugyanazt a kulcsot fogják használni - annak ellenére, hogy közöttük új (azonos nevű) bearer-t állítanak be. Az egyetlen gyakorlati változás, ami ezek között a hívások között történik, az az, hogy a titkosítási számláló nullára állítódik. Az irodalomban ezt néha úgy nevezik . Azt lehet állítani, hogy ez lényegében megvalósítási hiba, bár ebben az esetben a kockázatok, úgy tűnik, nagymértékben a szabványból magából adódnak.
A gyakorlatban ez a támadás a kulcstartó áramlásának újrahasználatához vezet, ahol a támadó titkosított csomagokat kaphat $inline$C_1 = M_1 oplus KS$inline$ és $inline$C_2 = M_2 oplus KS$inline$, ami lehetővé teszi a $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$ kiszámítását. Még jobb, ha a támadó tud egyet az $inline$M_1$inline$ vagy $inline$M_2$inline$ közül, akkor azonnal vissza tudja állítani a másikat. Ez erős ösztönzést ad neki arra, hogy megtudjon egyet a két titkosítatlan komponens közül.
Ez eljutat minket a teljes és leghatékonyabb támadási forgatókönyvhöz. Vegyünk egy támadót, aki képes lehallgatni a rádióforgalmat a céltelefon és a mobil torony között, és aki valamilyen ügyes módon „szerencsésen” fel tudott venni két különböző hívást, ahol a második közvetlenül az első után következik. Most képzeljük el, hogy valamilyen módon meg tudja jósolni az egyik hívás titkosítatlan tartalmát. Ilyen körülmények között a szerencse tényleg nem számít. Mivel a telefonok hívások fogadására vannak tervezve, a támadó, aki képes lehallgatni az első hívást, kezdeményezni tudja a második hívást közvetlenül az első befejezése után. Ez a második hívás, ha ugyanazt a titkosítási kulcsot használja, és a számláló nullára állítódik, lehetővé teszi a titkosítatlan adatok visszaállítását. Ráadásul, mivel a támadó lényegében ellenőrzi az adatokat a második hívás során, vissza tudja állítani az első hívás tartalmát – számos specifikusan megvalósított apróságnak köszönhetően,
amelyek a kedvére játszanak. Itt van a támadás általános terve, amelyet a, akik a fejükre állnak.
Itt van a támadási terv általános képe, amelyet :
Támadás áttekintése az . Ez a séma azt feltételezi, hogy két különböző hívás történik ugyanazzal a kulccsal. A támadó egy passzív sniffert (bal felső sarok) és egy másik telefont irányít, amellyel másodszor is hívást kezdeményezhet a céltelefonra.
Tényleg működik ez a támadás?
Ez valóban a ReVoLTE cikk kulcskérdése. Elméletileg az összes fent említett ötlet nagyszerű, de rengeteg kérdést hagy maga után. Ilyenek például:
- Lehetséges-e (akademikus kutatók számára) valóban elfogni a VoLTE kapcsolatot?
- Valóban újra beállítják a kulcsokat a valódi LTE rendszerek?
- Valóban elindíthat egy második hívást elég gyorsan és megbízhatóan ahhoz, hogy a telefon és az adótorony újra felhasználja a kulcsot?
- Még ha a rendszerek újra is állítják a kulcsokat, tényleg meg tudja tudni a második hívás titkosítatlan tartalmát - figyelembe véve, hogy olyan dolgok, mint a kodekek és a dekódolás teljesen megváltoztathatják (bitről bitre) a második hívás tartalmát, még akkor is, ha hozzáférése van a támadó telefonjáról származó 'bitekhöz'?
Ezekre a kérdésekre a ReVoLTE munkája igennel válaszol. A szerzők egy kereskedelmi szoftver-újrakonfigurálható rádiófolyam sniffert használnak, amelyet -nak hívnak, hogy elfogják a VoLTE hívást a lefele irányuló vonalról. (Gondolom, a szoftver elsajátítása és az működésének közelítő megértése hónapokat vett el a szegény posztdoktoroktól - ami tipikus az ilyen akadémiai kutatásoknál).
A kutatók felfedezték, hogy a kulcs újrahasználatának aktiválásához a második hívásnak elég gyorsan kell történnie az első befejezése után, de nem túl gyorsan – körülbelül tizenkét másodpercen belül az általuk tesztelt szolgáltatóknál. Szerencsére nem számít, ha a felhasználó válaszol a hívásra ezen idő alatt – a 'hívás', azaz magának a SIP kapcsolódásnak a folytatása arra készteti a szolgáltatót, hogy újra felhasználja ugyanazt a kulcsot.
Így tehát sok legrosszabb problémája a (4) számú problémával kapcsolatos – a támadó által kezdeményezett hívás nyers, titkosítatlan tartalmának megszerzése. Ez azért történik, mert a tartalmaddal sok minden lejárhat, miközben az áthalad a támadó telefonjától az áldozat telefonjáig a mobilhálózaton. Például ilyen trükköket is alkalmazhatnak, mint a kódolt hangáram átkódolása, ami a hangot változatlanul hagyja, de teljesen megváltoztatja a bináris reprezentációját. Az LTE-hálózatokban a RTP-fejlécek tömörítését is alkalmazzák, ami jelentősen megváltoztathatja a RTP-csomag nagy részét.
Végül a támadó által küldött csomagoknak körülbelül egy vonalba kell rendeződniük azzal a csomagsorozattal, amely a telefonbeszélgetés során távozott. Ez problémás lehet, mivel a hívás közbeni csend módosítása rövidebb üzenetekhez vezet (ún. kényelmes zaj), amelyek nehezen illeszkednek az eredeti híváshoz.
érdemes alaposan elolvasni. Itt számos fent említett problémát tárgyalnak – különösen a szerzők felfedezték, hogy néhány kodek nincs átkódolva, és hogy a célzott hívás körülbelül 89%-os bináris reprezentációja visszaállítható. Ez legalább két tesztelt európai szolgáltatóra vonatkozik.
Ez rendkívül magas sikerességi arány, és őszintén szólva, sokkal magasabb, mint amire számítottam, amikor elkezdtem dolgozni ezen a dokumentumon.
Mit tehetünk a megoldás érdekében?
A kérdésre adott sürgős válasz rendkívül egyszerű: mivel a kihasználás lényege a kulcs újrahasználatába (újratelepítési) támadás, egyszerűen orvosolja ezt a problémát. Győződjön meg arról, hogy minden telefonhívás számára új kulcsot kap, és soha ne engedje a csomagszámlálót visszaállítani a nullára ugyanazzal a kulccsal. A probléma megoldva!
Talán nem is. Ehhez a berendezések széleskörű modernizálására lenne szükség, és őszintén szólva, egyedül ez a megoldás nem túl megbízható. Jó lenne, ha a szabványok találnának egy biztonságosabb módot titkosítási rendszereik megvalósítására, amely alapértelmezés szerint nem sebezhető ilyen kulcsújrahasználati problémák miatt.
Az egyik lehetőség a . Ez túlzottan költséges lehet néhány modern hardver számára, de ez minden bizonnyal olyan irány, amelyen a tervezőknek érdemes lenne elgondolkodniuk a jövőben, különösen figyelembe véve, hogy a 5G szabványok hamarosan világuralomra törnek.
Ez az új kutatás a kérdés egy másik aspektusát is felveti, hogy miért , amelyek közül sok nagyon hasonló konstrukciókat és protokollokat használ. Amikor olyan problémával találkozunk, mint egy és ugyanaz a kulcs újrainstallálása több széles körben elterjedt protokollban, mint például a WPA2, nem tűnik fel, hogy talán eljött az idő, hogy a specifikációinkat és a tesztelési eljárásainkat megbízhatóbbá tegyük? Elég az, hogy a szabványok implementálóit gondos partnerekként kezeljük, akik figyelnek a figyelmeztetéseidre. Kezeljük őket úgy, mint (nem szándékos) ellenfeleket, akik elkerülhetetlenül mindent rosszul fognak megvalósítani.
Vagy, mint opció, megtehetjük azt is, amit egyre inkább megtesznek olyan cégek, mint a Facebook és az Apple: a titkosításnak a hálózati OSI verem egy magasabb szintjén kellene történnie, anélkül, hogy a mobilhálózati hardvergyártókra támaszkodnánk. Akár elő is mozdíthatnánk a végpontok közötti titkosítást a hanghívásoknál, ahogyan azt a WhatsApp teszi a Signal-lal és a FaceTime-mal, abban a reményben, hogy az Egyesült Államok kormánya egyszerűen abbahagyja . Akkor (kivéve néhány metaadatot) sok ezek közül a problémák közül egyszerűen eltűnnének. Ez a megoldás különösen releváns egy olyan világban, ahol .
Vagy egyszerűen megtehetjük, amit már a gyerekeink is tettek: egyszerűen abbahagyjuk azokat az idegesítő telefonhívásokra való válaszadást.
Forrás: habr.com
