A fordítótól és TL;DR
-
TL; DR:
Úgy tűnik, hogy a VoLTE még rosszabbul védett, mint az első WEP-pel rendelkező Wi-Fi kliensek. Kizárólag építészeti tévedés, amely lehetővé teszi a forgalom egy kis XOR-át és a kulcs visszaállítását. Támadás akkor lehetséges, ha a hívó közelében tartózkodik, és gyakran hív.
-
Köszönöm a tippet és TL;DR
-
A kutatók egy alkalmazást készítettek annak megállapítására, hogy a szolgáltató sebezhető-e. További információ . Oszd meg az eredményeket a megjegyzésekben, a VoLTE le van tiltva az én régiómban a Megafonon.
A szerzőről
Matthew Green.
Titkosító és professzor vagyok a Johns Hopkins Egyetemen. Vezeték nélküli hálózatokban, fizetési rendszerekben és digitális tartalombiztonsági platformokon használt kriptográfiai rendszereket terveztem és elemeztem. Kutatásom során a kriptográfia használatának különböző módjait vizsgálom a felhasználói adatvédelem javítása érdekében.
Már egy ideje írtam egy posztformátumot , és ez felzaklatott. Nem azért, mert nem voltak támadások, hanem leginkább azért, mert nem támadtak valami olyan széles körben használt dolgot, hogy kikerüljek az írói blokkból.
De ma ráakadtam ReVoLTE-nek hívják azokat a protokollokat, amelyeket különösen izgatnak a feltörések, nevezetesen a mobilhálózati (voice over) LTE protokollok miatt. Izgatottak ezek a konkrét protokollok – és ez az új támadás –, mert nagyon ritkán látni, hogy tényleges mobilhálózati protokollokat és megvalósításokat feltörnek. Főleg azért, mert ezeket a szabványokat füsttel teli helyiségekben dolgozták ki, és 12000 XNUMX oldalas dokumentumokban dokumentálták, amelyeket nem minden kutató tud kezelni. Ráadásul ezeknek a támadásoknak a végrehajtása összetett rádióprotokollok használatára kényszeríti a kutatókat.
Így súlyos kriptográfiai sérülékenységek terjedhetnek el az egész világon, talán csak a kormányok kihasználhatják őket, mielőtt bármely kutató észrevenné. De időről időre vannak kivételek, és a mai támadás is ezek közé tartozik.
Szerzők Közreműködők: David Rupprecht, Katharina Kohls, Thorsten Holz és Christina Pöpper, a Ruhr-University Bochum és a New York University Abu Dhabi munkatársai. Ez egy nagyszerű támadás a valószínűleg már használt hangprotokoll kulcsának újratelepítésére (feltételezve, hogy Ön egy régebbi generációhoz tartozik, amely még mindig mobiltelefonról kezdeményez telefonhívásokat).
Kezdésnek egy rövid történelmi kirándulás.
Mi az LTE és a VoLTE?
A modern mobiltelefon-szabványaink alapjait még a 80-as években Európában fektették le a szabvány (Global System for Mobile Communications). A GSM volt az első jelentős digitális mobiltelefon-szabvány, amely számos forradalmi funkciót vezetett be, mint pl. telefonhívások védelmére. A korai GSM-et elsősorban hangkommunikációra tervezték, bár a pénz lehet .
Ahogy az adatátvitel egyre fontosabbá vált a cellás kommunikációban, a Long Term Evolution (LTE) szabványokat fejlesztették ki az ilyen típusú kommunikáció egyszerűsítésére. Az LTE régebbi szabványok csoportján alapul, mint például a GSM, и és az adatcsere sebességének növelésére szolgál. Nagyon sok márkajelzés és de a TL;DR az, hogy az LTE egy adatátviteli rendszer, amely hídként szolgál a régebbi csomagkapcsolt adatátviteli protokollok és a jövőbeli cellás adattechnológiák között. .
Természetesen a történelem azt mondja, hogy amint elegendő (IP) sávszélesség áll rendelkezésre, az olyan fogalmak, mint a „hang” és az „adat”, elkezdenek összemosódni. Ugyanez vonatkozik a modern cellás protokollokra is. Az átmenet simábbá tétele érdekében az LTE szabványok határozzák meg (VoLTE), amely egy IP-szabvány a hanghívások közvetlenül az LTE rendszer adatsíkján történő továbbítására, teljesen megkerülve a mobilhálózat betárcsázós részét. Mint a standardnál ,A VoLTE-hívásokat a mobilszolgáltató bonthatja és csatlakoztathatja a normál telefonhálózathoz. Vagy (mint az egyre gyakoribb) ők közvetlenül az egyik mobil kliensről a másikra, sőt különböző szolgáltatók között is.
A szabványos VoIP-hez hasonlóan a VoLTE is két népszerű IP-alapú protokollon alapul: Session Initiation Protocol ( – SIP) a hívás beállításához és a valós idejű szállítási protokollhoz (, amelyet RTTP-nek kellene nevezni, de valójában RTP-nek hívják) a hangadatok feldolgozásához. A VoLTE néhány további sávszélesség-optimalizálást is hozzáad, például a fejléctömörítést.
Oké, mi köze ennek a titkosításhoz?
LTE, pl , szabványos kriptográfiai protokollkészlettel rendelkezik a csomagok titkosításához, miközben azokat az éteren keresztül továbbítják. Főleg arra tervezték őket, hogy megvédjék az Ön adatait, amikor azok a telefon (úgynevezett felhasználói berendezés vagy UE) és a mobiltorony (vagy ahol a szolgáltató a kapcsolat megszakítása mellett dönt) között utaznak. Ennek az az oka, hogy a mobilszolgáltatók ellenségnek tekintik a külső lehallgató eszközöket. Hát persze.
(Azonban az a tény, hogy a VoLTE kapcsolatok közvetlenül létrejöhetnek a kliensek között a különböző szolgáltatói hálózatokon, azt jelenti, hogy magának a VoLTE protokollnak van néhány további és opcionális titkosítási protokollja, amelyek magasabb hálózati rétegekben is előfordulhatnak. Ez nem releváns a jelen cikk szempontjából, kivéve, hogy mindent tönkretehetnek (a továbbiakban róluk lesz szó röviden).
Történelmileg a titkosítás a GSM-ben volt : rossz , protokollok, amelyekben csak a telefon volt hitelesítve a toronyhoz (ami azt jelenti, hogy a támadó kiadhatja magát a toronynak, generálva ) stb. Az LTE számos nyilvánvaló hibát kijavított, miközben megőrizte ugyanazt a struktúrát.
Kezdjük magával a titkosítással. Feltéve, hogy a kulcs létrehozása már megtörtént - és erről egy perc múlva beszélünk -, akkor minden adatcsomagot folyamtitkosítással titkosítanak az úgynevezett "EEA" használatával (ami a gyakorlatban olyan dolgokkal valósítható meg, mint például az AES ). Lényegében itt a titkosítási mechanizmus az az alábbi:
A VoLTE-csomagok fő titkosítási algoritmusa (forrás: ). Az EEA egy titkosítás, a „COUNT” egy 32 bites számláló, a „BEARER” pedig egy egyedi munkamenet-azonosító, amely elválasztja a VoLTE-kapcsolatokat a normál internetes forgalomtól. Az „IRÁNY” azt jelzi, hogy a forgalom milyen irányban folyik – az UE-tól a toronyig vagy fordítva.
Mivel maga a titkosítási algoritmus (EEA) megvalósítható erős titkosítással, mint például az AES, nem valószínű, hogy ilyen közvetlen támadás érné magát a titkosítást. . Nyilvánvaló azonban, hogy ez a titkosítási séma még erős titkosítás mellett is nagyszerű módja annak, hogy lábon lődd magad.
Konkrétan: az LTE szabvány (nem hitelesített) adatfolyam titkosítót használ, amelynek módja rendkívül sérülékeny lesz, ha a számlálót – és más bemeneteket, mint például a „hordozó” és a „irány” – újra felhasználják. A modern szóhasználatban ennek a fogalomnak a kifejezése „nonce reuse attack”, de a lehetséges kockázatok itt nem valami modernek. Híresek és ősiek, a glam metal, sőt a disco idejére nyúlnak vissza.
CTR módban az egyszeri újrafelhasználás elleni támadások akkor is léteztek, amikor a Poison ismertté vált
Az igazságosság kedvéért az LTE szabványok azt mondják: „Kérjük, ne használja újra ezeket a mérőórákat.” De az LTE szabványok körülbelül 7000 oldalasak, és mindenesetre olyan, mintha könyörögnének a gyerekeknek, hogy ne játsszanak fegyverrel. Elkerülhetetlenül megtörténik, és szörnyű dolgok fognak történni. Az elsütő fegyver ebben az esetben egy kulcsfolyam újrafelhasználási támadás, amelyben két különböző bizalmas üzenet X VAGY ugyanazt a kulcsfolyam bájtja. Köztudott, hogy ez .
Mi az a ReVoLTE?
A ReVoLTE támadás azt mutatja, hogy a gyakorlatban ezt a nagyon sérülékeny titkosítási tervet a valós hardverek visszaélnek. Pontosabban, a szerzők elemzik a valódi VoLTE-hívásokat, amelyeket kereskedelmi berendezésekkel indítottak, és megmutatják, hogy használhatják az úgynevezett "kulcs-újratelepítési támadást". (A probléma megtalálásáért nagy elismerés illeti (Raza & Lu), akik elsőként mutattak rá a lehetséges sebezhetőségre. De a ReVoLTE kutatás gyakorlati támadássá változtatja).
Hadd mutassam meg röviden a támadás lényegét, bár érdemes megnézni és .
Feltételezhető, hogy amint az LTE csomagkapcsolt adatátviteli kapcsolatot létesít, az LTE-n keresztüli beszédfeladat csupán a hangcsomagok ezen a kapcsolaton keresztül történő továbbítása lesz, a többi forgalommal együtt. Más szóval, a VoLTE egy olyan fogalom lesz, amely csak a vége felé létezik [OSI modellek – kb.]. Ez nem teljesen igaz.
Valójában az LTE kapcsolati réteg bevezeti a „hordozó” fogalmát. A hordozók külön munkamenet-azonosítók, amelyek elválasztják a különböző típusú csomagforgalmat. A rendszeres internetes forgalom (a Twitter és a Snapchat) egy hordozón megy keresztül. A VoIP SIP jelzése egy másikon megy keresztül, és a hangforgalmi csomagok feldolgozása egy harmadikon keresztül történik. Nem vagyok nagyon járatos az LTE rádiós és hálózati útválasztási mechanizmusokban, de úgy gondolom, hogy ez így van megcsinálva, mert az LTE hálózatok a QoS (szolgáltatásminőség) mechanizmusokat akarják kényszeríteni, hogy a különböző csomagfolyamokat különböző prioritási szinteken dolgozzák fel: pl. a tiéd másodrendű Előfordulhat, hogy a Facebook TCP-kapcsolatai alacsonyabb prioritásúak, mint a valós idejű hanghívások.
Ez általában nem probléma, de a következmények a következők. Az LTE-titkosítás kulcsai minden alkalommal külön jönnek létre, amikor új „hordozót” telepítenek. Alapvetően ennek meg kell ismétlődnie minden alkalommal, amikor új telefonhívást kezdeményez. Ez azt eredményezi, hogy minden híváshoz más-más titkosítási kulcsot kell használni, és kiküszöböli annak lehetőségét, hogy ugyanazt a kulcsot két különböző hanghívási csomag titkosításához használják fel. Valójában az LTE szabvány valami ilyesmit mond: "Minden alkalommal más kulcsot kell használnia, amikor új hordozót telepít egy új telefonhívás kezelésére". De ez nem jelenti azt, hogy ez valóban megtörténik.
Valójában a valós megvalósításokban két különböző, időbeli közelségben előforduló hívás ugyanazt a kulcsot fogja használni - annak ellenére, hogy új, azonos nevű hordozók vannak beállítva közöttük. Az egyetlen gyakorlati változás ezek között a hívások között az, hogy a titkosítási számláló nullázódik. A szakirodalomban ezt néha úgy hívják . Lehet vitatkozni, hogy ez alapvetően megvalósítási hiba, bár ebben az esetben a kockázatok nagyrészt magából a szabványból fakadnak.
A gyakorlatban ez a támadás kulcsfolyam újrafelhasználását eredményezi, ahol a támadó megszerezheti a $inline$C_1 = M_1 oplus KS$inline$ és $inline$C_2 = M_2 oplus KS$inline$ titkosított csomagokat, lehetővé téve a $inline$ kiszámítását. C_1 oplus C_2 = M_1 oplus M_2$inline$. Még jobb, ha a támadó ismeri az $inline$M_1$inline$ vagy $inline$M_2$inline$ egyikét, akkor azonnal visszaállíthatja a másikat. Ez erős ösztönzést ad neki találja meg a két titkosítatlan összetevő egyikét.
Ezzel elérkeztünk 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 akinek valahogy olyan szerencséje van, hogy két különböző hívást rögzít, és a második közvetlenül az első után következik be. Most képzelje el, hogy valahogy kitalálhatja az egyik hívás titkosítatlan tartalmát. Ilyenekkel serénység támadónk teljesen visszafejtheti az első hívást egy egyszerű XOR használatával a két csomag között.
Persze a szerencsének ehhez semmi köze. Mivel a telefonokat hívások fogadására tervezték, a támadó, aki meghallja az első hívást, pontosan abban a pillanatban tud második hívást kezdeményezni, amikor az első befejeződik. Ez a második hívás, ha ugyanazt a titkosítási kulcsot újra használjuk a számláló nullára állításával, lehetővé teszi a titkosítatlan adatok helyreállítását. Sőt, mivel támadónk a második hívás során ténylegesen irányítja az adatokat, vissza tudja állítani az első hívás tartalmát – sok speciálisan megvalósított megoldásnak köszönhetően. kis dolgok, az ő oldalán játszik.
Íme egy kép az általános támadási tervről :
Támadás áttekintése innen . Ez a séma azt feltételezi, hogy két különböző hívás történik ugyanazzal a gombbal. A támadó irányítja a passzív szippantót (balra fent), valamint egy második telefont, amellyel második hívást kezdeményezhet az áldozat telefonjára.
Tehát tényleg működik a támadás?
Egyrészt valóban ez a fő kérdése a ReVoLTE-ről szóló cikkhez. A fenti ötletek mindegyike nagyszerű elméletileg, de sok kérdést hagy maga után. Mint például:
- Lehetséges (akadémiai kutatók számára) ténylegesen elfogni egy VoLTE-kapcsolatot?
- Valódi LTE rendszerek valóban újrakulcsolják?
- Tud-e valóban gyorsan és elég megbízhatóan kezdeményezni egy második hívást ahhoz, hogy a telefon és a torony újra felhasználja a kulcsot?
- Még ha a rendszerek újrakulcsolják is, valóban ismerheti a második hívás titkosítatlan tartalmát – tekintettel arra, hogy az olyan dolgok, mint a kodekek és az átkódolás teljesen megváltoztathatják a második hívás (bitről bitre) tartalmát, még akkor is, ha hozzáfér a "bitekhez" "a támadó telefonjáról jön?
A ReVoLTE munkája ezekre a kérdésekre igenlő választ ad. A szerzők egy kereskedelmi szoftverrel újrakonfigurálható rádiós stream szippantót használnak a VoLTE hívás lefelé irányuló oldalról történő lehallgatásához. (Úgy gondolom, hogy a szoftverrel való bánásmód és a működésének hozzávetőleges megismerése hónapokat vett el a szegény végzős hallgatók életéből – ez jellemző az ilyen jellegű tudományos kutatásokra).
A kutatók azt találták, hogy ahhoz, hogy a kulcs újrafelhasználása működjön, a második hívásnak elég gyorsan meg kellett történnie az első befejezése után, de nem túl gyorsan – körülbelül tíz másodpercig a kísérletezett kezelők számára. Szerencsére nem mindegy, hogy a felhasználó ezen időn belül fogadja-e a hívást – a „csengetés” pl. Maga a SIP-kapcsolat arra kényszeríti a kezelőt, hogy újra használja ugyanazt a kulcsot.
Így a legrosszabb problémák közül sok a (4) probléma körül forog – egy támadó által kezdeményezett hívás titkosítatlan tartalmának bitjeinek fogadása. Ennek az az oka, hogy sok minden megtörténhet a tartalommal, amikor a támadó telefonjáról az áldozat telefonjára jut el a mobilhálózaton keresztül. Például olyan piszkos trükkök, mint egy kódolt audio folyam újrakódolása, amely ugyanazt a hangot hagyja, de teljesen megváltoztatja a bináris megjelenítését. Az LTE hálózatok RTP fejléctömörítést is használnak, ami jelentősen megváltoztathatja az RTP-csomagok nagy részét.
Végül a támadó által küldött csomagoknak nagyjából egy vonalban kell lenniük az első telefonhívás során küldött csomagokkal. Ez problémás lehet, mert a csend módosítása telefonhívás közben rövidebb üzeneteket (más néven komfortzajt) eredményez, ami nem biztos, hogy jól illeszkedik az eredeti híváshoz.
Érdemes részletesen elolvasni. A fenti problémák közül sok foglalkozik – különösen a szerzők azt találták, hogy egyes kodekek nincsenek újrakódolva, és a célhívás bináris reprezentációjának körülbelül 89%-a visszaállítható. Ez legalább két tesztelt európai szolgáltatóra igaz.
Ez meglepően magas sikerarány, és őszintén szólva sokkal magasabb, mint amire számítottam, amikor elkezdtem dolgozni ezen a dokumentumon.
Szóval mit tehetünk a javítás érdekében?
Az azonnali válasz erre a kérdésre nagyon egyszerű: mivel a sérülékenység lényege egy kulcs újrafelhasználási (újratelepítési) támadása, egyszerűen javítsa ki a problémát. Győződjön meg arról, hogy minden telefonhíváshoz új kulcsot kap, és soha ne engedje, hogy a csomagszámláló nullára állítsa vissza a számlálót ugyanazzal a gombbal. Probléma megoldódott!
Vagy talán nem. Ehhez sok berendezés frissítésére lesz szükség, és őszintén szólva egy ilyen javítás önmagában nem túl megbízható. Jó lenne, ha a szabványok biztonságosabb módot találnának titkosítási módjuk megvalósítására, amely alapértelmezés szerint nem katasztrofálisan sebezhető az ilyen kulcs-újrahasználati problémákkal szemben.
Az egyik lehetséges lehetőség a használata . Lehet, hogy ez túl drága néhány jelenlegi hardver számára, de minden bizonnyal ez az a terület, amelyre a tervezőknek gondolniuk kell a jövőben, különösen, mivel az 5G szabványok hamarosan átveszik a világot.
Ez az új tanulmány azt az általános kérdést is felveti, hogy miért , amelyek közül sok nagyon hasonló kialakítást és protokollt használ. Amikor azzal a problémával szembesül, hogy ugyanazt a kulcsot több, széles körben használt protokollon, például a WPA2-n keresztül kell újratelepíteni, nem gondolja, hogy ideje lenne robusztusabbá tenni a specifikációkat és a tesztelési eljárásokat? Ne kezelje a szabványok végrehajtóit átgondolt partnerként, akik figyelmesek az Ön figyelmeztetéseire. Bánj velük úgy, mint (akaratlan) ellenfelekkel, akiknek elkerülhetetlenül rossz lesz a helyzete.
Vagy megtehetjük azt, amit az olyan cégek, mint a Facebook és az Apple egyre gyakrabban tesznek: a hanghívások titkosítását az OSI hálózati verem magasabb szintjén valósíthatjuk meg anélkül, hogy a mobileszközök gyártóira támaszkodnánk. Akár a hanghívások végpontok közötti titkosítását is szorgalmazhatnánk, mint ahogy a WhatsApp a Signal és a FaceTime esetében teszi, feltéve, hogy az Egyesült Államok kormánya egyszerűen leáll. . Akkor (néhány metaadat kivételével) sok ilyen probléma egyszerűen eltűnne. Ez a megoldás különösen fontos egy olyan világban, ahol .
Vagy egyszerűen megtehetjük azt, amit a gyerekeink már megtettek: ne válaszoljunk ezekre a bosszantó hanghívásokra.
Forrás: will.com