rdesktop 1.6.0, POC, exploity a shell kódy

13.5.2008 11:22 | Přečteno: 4040× | GNU/Linux | poslední úprava: 13.5.2008 11:25

Používáte-li rdesktop (program nejenom pro vzdálenou správu Microsoft Windows (Vzdálená plocha)), měli byste se ujistit, že používáte bezpečnou verzi. V pondělí byla uvolněna nová verze 1.6.0 opravující také několik bezpečnostních problémů.

Jedná se hned o tři bezpečnostní problémy. Do CVE databáze byly přidány jako CVE-2008-1801, CVE-2008-1802 a CVE-2008-1803. Na serveru iDefense Labs se lze dočíst, že se jedná o problémy ve třech funkcích: iso_recv_msg() (Integer Underflow), process_redirect_pdu() (BSS Overflow) a channel_process() (Integer Signedness).

Vývojáři rdesktopu byly o problémech informování 12. listopadu 2007, odpověděli 19. listopadu 2007 a 7. května 2008 byla informace o bezpečnostních problémech zveřejněna.

I když exploity zneužívající těchto chyb nejsou k dispozici (zatím?), jsou k dispozici POC (Proof Of Concept), tj. důkazy, že dané chyby zneužít lze. Jde o dva v perlu napsané skripty ukazující možnosti zneužití funkcí iso_recv_msg() a process_redirect_pdu(). Hrozí tedy, že se najde někdo, komu bude za to stát tento POC kód upravit a vloží tam svůj shell kód (shellcode) provádějící nekalou činnost. Samozřejmě může použít již připravené shell kódy. Nejenom na milw0rm serveru lze získat celou řadu shell kódů a to nejenom pro linux/x86.

Co takhle násilné ukončení všech procesů uživatele pod kterým byl rdesktop spuštěn aneb "kill -9 -1" na 11 bajtů ("\x6a\x25\x58\x6a\xff\x5b\x6a\x09\x59\xcd\x80"), přidání uživatele r00t do /etc/passwd na 69 bajtů (heslo by vyžadovalo další bajty, takže r00t bez hesla) nebo smazání všech souborů "rm -rf /" na 45 bajtů. Pokud by vás zajímalo, jak takové shell kódy vytvářet, lze nalézt návody i v češtině.

Naštěstí není tak jednoduché rdesktop zneužít. Uživatel by se musel připojit k falešnému serveru. Útočník by například musel nějakým způsobem přesměrovat komunikaci (ARP spoofing, IP spoofing nebo DNS spoofing).

Pokud máte čas, můžete sledovat zranitelnosti, případně se utěšovat, že zatím žádný exploit nebyl zveřejněn na serverech jako SecurityFocus, SEBUG nebo již zmíněný milw0rm.

       

Komentáře

[petr_p]

Jak je na tom protokol používaný rdesktopem ohledně autentizace a zajištění integrity?

Vždy, když vidím uživatele připojující se na rdesktop server na windows, tak mě jímá hrůza.

[xvasek]

Uživatel se autentizuje přes CHAP, což je celkem dobré, server se (AFAIK) uživateli neautentizuje - což dává dohromady příležitost pro man in the middle attack - sice jen jednou pro jedno přihlášení, ale na druhou stranu to úplně stačí...

[Roger]

V novem TS klientovi (resp. Vistach) nejaka podpora pro overeni serveru je, ne?

[xvasek]

Tak jsem to zkoumal a možnost ověřování serveru tam je, ale nevím jak funguje (proti AD mi to přijde nesmyslné - to by klient musel být členem AD, což je blbost vyžadovat, podrobnější konfigurace - kromě zapnutí - tam není žádná) a implicitně je v klientovi vypnutá. Pak je v helpu, že Windows 2003 SP1 a dřívější neumí poskytnout identitu k ověření, takže je tato funkce "relativně" nová - na to, jak tam měla být dávno.

[pasmen]

Proč by jsi pro ověření proti AD potřebovat být členem domény? Tedy pokud klientem nemyslíš uživatele místo počítače.

[xvasek]

No - pokud něco ověřuji, tak to musí být podle něčeho, ne? AD mi přijde celkem logické, jenom to pro tento účel není úplně vhodné.

[pasmen]

Když se připojuješ přes RDP, je to jako by jsi u toho PC seděl a snažil se do něj přihlásit. Tedy pokud je to PC v AD doméně, ověříš se doménovým jménem a heslem, a/nebo pokud není v doméně, pak lokálním účtem a heslem. A nebo i jinak, můžeš se přihlásit přes čipovku pokud máš, přes otisk prstu atd. atd.

[xvasek]

Potud je to jasné - přihlásit se ještě umím. Ale co když chci taky mít jistotu, že ta obrazovka, do které píšu svoje jméno a heslo, je obrazovka, kterou mi dává server, na který se připojuji, a ne nějaký darebák na cestě?

[pasmen]

Tohle IMO RDP protokol neřeší. Jak říkám, podle mého názoru nebyl tento protokol stavěn na to, aby se přes něj mohl na server připojoval kdekdo, ale byl navržen pro připojování prostřednictvím LAN popř. v rámci VPN. Pokud už trváš na připojení na Windows server přes RDP přes internet, doporučil bych NX server někde uprostřed. Běží nad ssh a navíc jako jednu z funkcí nabízí RDP proxy.

[petr_p]

Že se ještě vměšuji do diskuze – moje otázka ani tak nemířila na Internet jako na vniřní sítě. Přijde mi totiž krajně podezřelé, že běžní uživatelé (v mém okolí spíše lidé živící se výpočetní technikou, tedy lidé poučení) se nad nebezpečností RDP nepozastavují a nepožadují lepší zabezpečení.

[pasmen]

To řekl bych není hlavní funkcí protokolu... Ještě jsem neviděl že by se někdo přes RDP připojoval přímo přes internet a na zbytek použiješ protokoly na nižší vrstvě (IPsec, SSL VPN, ...) V práci to využívá 99% lidí a problém není.

[tezkatlipoka]

tak jsi toho videl malo, kdyz jsem videl lidi z velke softwareove firmy, jak se pripojuji primo na RDP na server, vyvalili se mi oci z dulku. Jinak je RDP skrze VPN samozrejme uplne v pohode, ale opravdu jsem videl naprimo.

[pasmen]

Opravdu myslíš přímo přes internet? Pak jsem toho asi viděl vážně málo. Nicméně to je hloupostí adminů, nikoliv nedostatkem protokolu. Protokol typu RDP musí být především rychlý vzhledem k tomu, že přenáší bitmapy a má být interaktivní. Cokoliv navíc je brzda za kterou tě useři utlučou kamenem do hlavy, v lepším případě.

[StefanV]

moje řeč. U nás se takto přistupuje k většině win serverum a no problemo. Správným návrhem síťové infrastruktůry můžete eliminovat snad jakékoliv podobné bezpečnostní nedostatky.