Régóta ismert volt a német titkosszolgálatok vágya, hogy a Skype-beszélgetéseket is le tudják hallgatni, a Chaos Computer Club (CCC) tagjai jóvoltából pedig 2011. október 8-án megismerhettük egy kémszoftverük, a Quellen-TKÜ anatómiáját, amely nem magának a Skype-nak valamilyen hibáját használja ki (tehát, az továbbra is jónak tűnik), hanem az audio stream-et vélhetőleg közvetlenül a mikrofon-bemenetről menti le. A Sophos elemzése is megerősíti, hogy a kémszoftver az alábbi funkcionalitással rendelkezik:- A trójai le tudja hallgatni többek közt a Skype, MSN Messenger és Yahoo Messenger adatforgalmát (üzenetküldéseket, beszélgetéseket is).
- A trójai naplózni tudja a billentyűleütéseket a Firefox, Opera, Internet Explorer és SeaMonkey böngészőknél.
- A trójai képes bizonyos időközönként automatikusan pillanatfelvételt készíteni a képernyőről (JPEG formátumban).
- A trójai a megszerzett adatokat ki tudja küldeni külső szerverekre, illetve maga a trójai lehetőséget ad a távoli vezérlésre.
Mivel a Skype igencsak népszerű C2C kommunikációnál, sőt, nagyon sok helyen (pl. webes boltoknál) az ügyfélkapcsolati, B2C kommunikációt is ezzel valósítják meg, elképzelhető, hogy a G2C esetében, a közigazgatás és az állampolgár közötti kapcsolattartásra is használhatnák az ottani IT-rendszerek, a kormányzati felhasználásnál azonban a nemzetbiztonsági szempontok is előtérbe kerülnek. A Skype erőssége, a kriptográfia alkalmazása más megoldásoknál is megjelenik, igaz, a mikrofon-bemenet figyelése ellen ez nem nyújt védelmet. Éppen ezért valószínűleg nem az a megoldás, ha hirtelen mindenki lecseréli a Skype-ot pl. a távol-keletiek kedvenc IM alkalmazására, az ooVoo nevű csodaszoftverre. Az sem biztos, hogy jó, ha az RC4 és AES algoritmusok révén rejtjelezett, hagyományos node-okon és supernode-okon alapuló peer-to-peer architektúrájú Skype nem teljesen szabványos VoIP protokollja helyett valami teljesen mást választunk. Mindettől függetlenül érdemes körbenézni, megvizsgálni más lehetőségeknél az előnyöket, illetve az esetleges hibákból fakadó veszélyeket elemezni. Például bizonyos esetekben hasznos lehet egy kliens-szerveres, kétoldali, kriptográfia-alapú hitelesítéseket érvényre juttató SSL-csatornába ágyazott streaming megoldás pl. az RTMP (Real Time Messaging Protocol) protokollon alapulva. Nézzük is meg, hogy mi a helyzet itt a kriptográfiai rétegben!
A Macromedia (most Adobe) által kifejlesztett RTMP protokollt az Adobe Media Server, illetve a Wowza Media Server is támogatja, a stream-et pedig Adobe Flash Player segítségével akár böngészőbe ágyazott formában tudják a felhasználók megnézni. Az alapszintű működés utólag lett kiegészítve a biztonsági funkciókkal, amely megvalósítja a csatorna rejtjelezését, illetve a node-ok hitelesítését is. Az RTMPE (Encrypted Real Time Messaging Protocol), illetve az RTMPS (Real Time Messaging Protocol over SSL) hivatott megválaszolni a biztonsági kérdéseket. Az SSL-es RTMPS változat a 443-as porton, míg az RTMP és RTMPE a 1935-ös porton kommunikál, alapvetően a protokoll nem nyílt, mégis visszafejtették és az RTMPE esetében ki is derült ismét, hogy a "Security by Obscurity" csak egy ideig tud működni.
Az RTMPE protokollelemzését 2009. május 23-án tették közzé. Az abban leírt kommunikációt az rtmpdump.exe, illetve a Wireshark segítségével lementett adatforgalmon végig tudjuk követni.
- rtmpdump használata (a "sample.mp4" stream érkezik a szerverről, ezt a "test_dump.flv" állományba menti, az stdout pedig a "test_invoke.txt" állományba kerül kiírásra):
rtmpdump.exe -r "rtmpe://<IP-cím>/vod/sample.mp4" -V -o test_dump.flv > test_invoke.txt 2>&1
A rejtjelezéshez szimmetrikus, titkos kulcsra van szükség, abban pedig előbb meg kell egyeznie a kliensnek és a szervernek. Erre a Diffie-Hellman protokollt használja az RTMPE, amire utal a "DH public key" kifejezés is. A "HandShake: Initial client digest:" kiolvasható a forgalomból. A "HandShake: Secret key:", az "RC4 Out Key:", az "RC4 In Key:" nem olvasható ki a forgalomból, de kiszámolható az elkapott és egyéb ismert paraméterek alapján.
A Diffie-Hellman első lépésénél mindkét fél létrehoz egy-egy nyilvános és titkos adatot. A két fél kizárólag a nyilvános adatokat küldi át a nem megbízható csatornán. Végrehajtják a szükséges műveleteket (hatványozás és modulo osztás), aminek eredményeképpen mindkét oldalon előáll ugyanaz a titkos adat (szimmetrikus rejtjelező kulcs). Az RTMPE üzeneteken ez nyomonkövethető.
A kliens létrehozza a Diffie-Hellman adatokat, és a nyilvános felét belerakja az átküldendő "clientsig" változóba. Ugyanezt a lépést végrehajtja a szerver oldal is, azaz ott is előáll a "DHPublicKeyS" és "serversig[ ]" érték.clientsig[ ] = DHPublicKeyC A kliens a "GenuineFPConst" (értéke: "Genuine Adobe Flash Player 001") kulccsal rejtjelezi a kliens által létrehozott "msg" üzenetet, majd annak SHA-256 lenyomatát belerakja az átküldendő "clientsig" változóba. Ugyanezt a lépést végrehajtja a szerver oldal is, azaz ott is előáll az "msg" és "serversig[ ]" érték.clientsig[ ] = HMACsha256(msg, GenuineFPConst) Megtörténik az első üzenetváltás a kliens és a szerver között.
A kliens a "GenuineFMSConst" (értéke: "Genuine Adobe Flash Media Server 001") kulccsal rejtjelezi a szerver által küldött "msg" üzenetet, majd annak SHA-256 lenyomatát összeveti a szerver által létrehozott és elküldött lenyomattal.Compare(serversig[ ], HMACsha256(msg, GenuineFMSConst)) Egyezés esetén a szimmetrikus kulcsú "aláírás" ellenőrzése sikeres, és a kliens kiveszi a szerver által létrehozott Diffie-Hellman adatok nyilvános felét.DHPublicKeyS = serversig[ ] A kliens létrehozza a további rejtjelezéshez egyeztetett, 256 bites szimmetrikus kulcsot ("DHSharedSecret") a kliens által létrehozott titkos adat ("DHPrivateKeyC") és a szerver által létrehozott nyilvános adat ("DHPublicKeyS") alapján (hatványozás, modulo osztás révén). Ugyanezt a lépést végrehajtja a szerver oldal is, azaz ott is előáll a "DHSharedSecret" érték.DHSharedSecret = DH(DHPrivateKeyC, DHPublicKeyS) A tényleges rejtjelezéshez az egyeztetett, 256 bites szimmetrikus kulcsból két különböző értéket származtatnak az RC4 (ARCFOUR) algoritmus számára:- egy 256 bites szimmetrikus kulcsot a szerver által létrehozott nyilvános adat alapján - ezzel ("KeyIn") fejti meg a kliens a bejövő adatot
KeyIn = ARC4Key(HMACsha256(DHPublicKeyS, DHSharedSecret)[ ]) - egy 256 bites szimmetrikus kulcsot a kliens által létrehozott nyilvános adat alapján - ezzel ("KeyOut") rejtjelezi a kliens a kimenő adatot
KeyOut = ARC4Key(HMACsha256(DHPublicKeyC, DHSharedSecret)[ ])
Megtörténik a második üzenetváltás a kliens és a szerver között.
A második üzenetváltásnál - a protokollelemzés szerint - más szimmetrikus kulcsokat ("GenuineFMSConstCrud" és "GenuineFPConstCrud") használ a kliens és a szerver a "HMACsha256" rejtjelezéshez. Ezek az új adatok azonban nem befolyásolják a szimmetrikus kódoláshoz használandó "KeyIn" és "KeyOut" RC4 kulcsok értékét (ugyanis a "GenuineFMSConstCrud" csak a "GenuineFMSConst" és "RandomCrud" összefűzése, illetve a "GenuineFPConstCrud" is csak a "GenuineFPConst" és "RandomCrud" összefűzése, maga a "RandomCrud" pedig csak egy konstans byte-tömb).
Az elemzés nyilvánosságra kerülésével a protokoll hibáira is fény derült. A "man-in-the-middle" (MITM) támadás nem is a hálózati forgalomban elkapható adatok miatt kivitelezhető, hanem azért, mert nincs semmilyen bizalmas adat (pl. jelszó, PIN kód), amivel a kezdeti HMAC-alapú rejtjelezést végrehajtanák, az RTMPE esetében ugyanis ezek ("GenuineFPConst", "GenuineFMSConst") konstans string-ek! Más esetekben (pl. RSA SecurID) a HMAC-rejtjelezést úgy hajtják végre, hogy a szimmetrikus kulcsot ("seed") előtte más módon már egyeztették és azt titokban tartják (az nem egy nyilvános, konstans string)!
Az RTMPE-vel szemben az RTMPS az SSL-réteg szabványos alkalmazása révén oldja meg a rejtjelezést. Ehhez teljesen hagyományos SSL-szerver tanúsítványt kell kibocsátani a pl. Wowza Media Server számára, majd újraindítást követően már lehet is nézni RTMPS-csatornán a stream-et. Az SSL-réteg funkciói elérhetők, így akár valóban csak a szerver által elfogadható kliens tanúsítvánnyal hitelesített felhasználók férkőzhetnek a stream közelébe.
A kliens-szerveres megoldással szemben talán nagyobb bizalommal élnek a piacon (pl. érzékeny adatokat kezelő közigazgatási, banki szférában) annak ellenére, hogy amíg a kriptográfiai funkciók használata megfelelő pl. a Skype esetében, addig a peer-to-peer modell is elégséges védelmet nyújt az adatfolyamnak. Igaz, 0-day sebezhetőség bármikor jöhet, és az peer-to-peer esetben nagyobb fejfájást okozhat...
Kapcsolódó anyagok:
|
