Piotr Konieczny

konsultant ds. bezpieczeństwa, podróżnik,
hobbystycznie fuksiarz i gadżeciarz
szkot, prawie spadochroniarz...
nienawidzi zielonego.


« wszystkie wpisy |

Piątek, 28 kwietnia 2006 :: 17:01:15
IT

Oni nie odkryli Ameryki (a szkoda) -- o błędach w SSH (i PWr)

Wszystko zaczęło się kilka dni temu, kiedy do prasy wysłane zostały "sensacyjne wiadomości z PWr" o nie mniej sensacyjnym tytule: "Słabe punkty protokołów SSL/TSL i SSH".

Specjaliści z Politechniki Wrocławskiej pracujący pod kierunkiem prof. Mirosława Kutyłowskiego odkryli słabe punkty protokołów SSL/TSL i SSH, najpopularniejszych protokołów zapewniających bezpieczną komunikację w Internecie [...]
Źródło: http://www.pwr.wroc.pl/118071.xml
Dodatek: http://kleptografia.im.pwr.wroc.pl/

I teraz teza tego postu: Oni nie odkryli Ameryki!. Dlatego tytuł "Słabe punkty protokołów SSL/TSL i SSH" zmieniamy na "Trojanowanie dowolnego programu klienta" z wykorzystaniem techniki A.Younga i M.Yunga, przeobrażając jednocześnie specjalistów-hackerów w zwykłych (?) script kiddsów...

No dobra, przesadziłem z tymi script kiddsami :-) ale grupa prof. Kutylowskiego ,,przesadziła'' (a raczej niedosadziła) z dokumentacją swoich rewelacji (zwłaszcza, jeśli chodzi o noty prasowe), więc jesteśmy kwita.

Otóż, wątpliwym w moim odczuciu jest stwierdzanie, iż "protokoły SSL i SSH mają błędy" (tzn. o ich błędach słyszeliśmy i pewnie usłyszymy jeszcze nie raz, ale nie w tym konkretnym przypadku), a już zupełnym nonsensem jest określenie wszystkich programów korzystających z w/w protokołów jako "zagrożone atakiem".

Mili Państwo Internauci, zapamiętajcie: ZAWSZE jesteście zagrożeni, w nie mniejszym stopniu niż użytkownicy Internet Explorera, Outlooka Expresa, Mozilli Firefox, przeglądarki Opera i inych programów, które implementują z SSL/TSL, a które wymieniła grupa pod kierownictwem prof. Kutyłowskiego w swoim raporcie.

To co odkryli panowie z PWr prowadząc swoje badania? Połączenie znanych od dawna technik:

1) przejęcie kontroli nad jedną ze stron -- oj, przecież nieautoryzowany dostęp do jednej ze stron daje nam większe możliwości, niż tylko podsłuchiwanie zaszyfrowanej transmisji, w dodatku wymagające takiej gimnastyki jak:
2) podmiana klucza (chociaż można łatwiej podchromolić dane, ręka do góry, kto wie jak :-)
3) można się również (bardzo na siłę) dopatrywać ataku MITM.

Krótko mówiąc, trojan (reprezentuje czarną stronę mocy -- podsłuchującego) wymyśla sobie klucz, a następnie podstawia go jako klucz sesji, którym protokół szyfruje transmisję pomiędzy zatrojanowanym klientem a np. bankiem. Znając klucz, trojan rozszyfruje przesyłane za pomocą bezpiecznego protokołu dane.

Rozwiązanie uniemożliwiające tak łatwe wstrzyknięcie klucza? Proszę bardzo: generacja klucza w oparciu nie tylko o "losowość", ale także o fragment przesyłanych danych (ale uwaga, dane muszą pochodzić od OBU stron!). AFAIR takie rozwiązania stają się coraz powszechniejsze przy projektowaniu nowych, hmm, nazwijmy to standardów komunikacji.

A zatem, jeśli ktoś ma dostęp do naszego komputera (bo modyfikuje nam klienta SSH, takiego PuTTy np.), to w pierwszej kolejności to my mamy problem z bezpieczeństwem własnej maszyny, a dopiero konsekwencją tego może być "podatność protokołów SSL/TSL/SSH" na atak. Innymi słowy, atakujący może nam zrobić psikusa wybierając dowolną (inną) aplikację, a nie tylko tą, która implementuje SSL/SSH.

Oczywiście dostęp do naszego komputera może być pośredni -- tzn. my jesteśmy dumbass, naiwnie łapiąc się na próbę podrzucenia trojana: Hej stary, przesyłam Ci fajniejsze PuTTy, możesz je użyć na USB sticku, bo zapisuje wszystko w plikach, a nie w rejestrze! Sprawdź!

Gorzej, jeśli wyobrazimy sobie sytuację, że trojana dostajemy już od producenta oprogramowania. Hipotetycznie, takie cudo mogłoby zostać zaimplementowane w Internet Explorerze -- sic! kto by pomyślał, nie? :-).

Czyżbym słyszał głosy, że jednynym słuszym i etycznie poprawnym oprogramowaniem jest Open Source? A kto z Was dokładnie (naprawdę DOKŁADNIE!) sprawdza źródła, a potem SAM z nich kompiluje programy? Acha... tak myślałem...

Krótko mówiąc, doceniam prace zespołu z PWr i niewątpliwie należą im się brawa (choćby za to, że mieli chęci, i z tych chęci wyszły ciekawe rzeczy), ale opisana przez nich metoda, mimo że interesująca, jest -- przyznacie -- ździebko naciągana, a artykuły takie jak ten, niestety, jeszcze mocniej wypaczają ją w oczach bardziej doświadczonych użytkowników, niepotrzebnie siejąc przy okazji panikę wśród zwykłych klikaczy.

Pamiętajcie, najciemniej jest pod latarnią...
(Przykład: odkryłem kolejną metodę blokowania każdego systemu: pokrętło kontrastu na monitorze... do zera. Ekran ciemny, monitor włączony. Nikt z pracujących ze mną osób nie ma pojęcia co jest nie tak... :D)

• Następny post: Bedzie padac, meteoryty nisko lataja...
• Poprzedni post: Grozny bug w Firefox -- tym razem naprawde :-)

 

Chcesz być informowany o kolejnych wpisach na ten temat?
Kanał RSS: kliknij tutaj. Subskrybcja poprzez e-mail: kliknij tutaj.

 

« reszta wpisów | • trackback | ‡ torturuj posta!

Komentarze:

1. Carstein Piątek, 28 kwietnia 2006, 17:26:24
 

Tak się właśnie zastanawialiśmy, czy by nie napisać czegoś podobnego, bo całe zamieszanie zaczynało być lekko śmieszne.

Bardzo dobry wpis.

 
2. Puck Piątek, 28 kwietnia 2006, 17:35:14
 

No, to teraz mogę zakopać tamtego linka. ;)

BTW pokrętła - jakiś rok temu księgowej w firmie mojego ojca "zepsuł się laptop". Poprosilem (dwa miesiące temu), żeby przyniósł go do domu, skoro i tak nikt z niego nie korzysta. Diagnoza, nie wiem kto ją wystawił, ale chyba informatyk w firmie, była taka, że matryca padła.
Faktycznie, po właczeniu nie było nic widać... do czasu podkręcenia kontrastu. ;-)

 
3. Piotr Konieczny Piątek, 28 kwietnia 2006, 17:37:18
 

Carstein: Dziękuję.

Pewnie jak większość, przemilczałbym sprawę, cokolwiek wesołą, bo w rzeczy samej, nie przepadam za podkładaniem kłód pod nogi rodzimym badaczom, ale artykuły w stylu: http://miasta.gazeta.pl/wroclaw/1,35751,3312194.html po prostu rozpalają mnie do czerwoności...

(A wystarczyło stworzyć enigmatyczny, techniczny raport, podesłać na zagraniczne vuln-listy, przedyskutować sprawę jeszcze raz i potem wystosować wyważone oświadczenie medialne)

 
4. Carstein Piątek, 28 kwietnia 2006, 17:48:46
 

Generalnie u nas w zespole było tak: pierwsze newsy (hacking.pl, infojama) nas rozbawiły (cyt. "Nie wiem, co oni palą, ale musi byc dobre..."). Niestety w miarę upływu czasu było tylko gorzej. Artykuł na GW już nas po prostu wku....rzył :)

Nosiliśmy się z zamiarem napisania czegoś prostującego, ale dziękuje, że nas wyręczyłeś :)

 
5. Carstein Piątek, 28 kwietnia 2006, 17:51:00
 

Zapomniałem napisać:

Po cholerę oni to wogle do ABW wysyłali? Z tego co czytałem, to wysłali to również do MS, i jeszcze kilku innych firm. Czemu nikt nie wysłał nic do OpenSSL? ;)

piko, mogę ci odpowiedzieć, czemu to nie poszło na żadne zagraniczne vuln-listy - tam by to kompletnie olali, ponieważ się na tym znają. :)

 
6. iss Piątek, 28 kwietnia 2006, 17:56:54
 

Kiedyś (jak jeszcze miałem monitor z dwoma klasycznymi pokrętłami) taki kawał zrobiła mi siostrzenica (pewnie nieświadomie nawet). Trochę czasu i nerwów zeszło zanim się zorientowałem, że wystarczy pokręcić żeby "naprawić".

 
7. GiM Piątek, 28 kwietnia 2006, 18:00:24
 

cze piko, tak zerknąłem na linki i wiesz co, nie wiedziałem, że ludzie tracą czas na pisanie takich pierdół [takie moje 0.02$]

 
8. Patrys Piątek, 28 kwietnia 2006, 22:08:35
 

Jeśli komuś podrzucę zmodyfikowanego klienta SSH, to mogę równie dobrze przez niego uploadować sobie dowolną binarkę na serwer (w tym implementującą "E.T. phone home", co pozwala automatycznie przejąć konto nawet za firewallem).

 
9. dzz Sobota, 29 kwietnia 2006, 00:19:24
 

Jak rozumiem, wszyscy czytaliście publikację dotyczącą znalezionych luk? I wiecie, jak wygląda scenariusz ataku? Co wysyła taka podmieniona binarka (tu: biblioteka SSL) i jak to wykryć? I jakie to niesie konsekwencje? No? Kto czytał? Jakoś nikogo nie widzę.

Po kim jak po kim, ale po tobie, PK, nie spodziewałem się takich komentarzy bez wystarczającej informacji.

 
10. Carstein Sobota, 29 kwietnia 2006, 00:31:55
 

Ponieważ nie jestem naukowcem-teoretykiem, ale pratykiem patrzę na problem w ten sposób - jeśli ktoś jest w stenie podmienić ci bibliotekę SSL, to masz dużo poważniejsze problemy, niż ten konkretny.

Taka sama sytuacja miała miejsce kilka lat temu, gdzie kilku czechów podało do wiadomości, że złamało PGP, po czym się okazało, że do przeprowadzenia ataku trzeba mieć dostęp do klucza prywatnego - czyli znowu, ciekawy problem teoretyczny - praktycznie natomiast, bez znaczenia.

A durni dziennikarze problemu nie rozumieją i tworzą sensację.

 
11. dzz Sobota, 29 kwietnia 2006, 00:58:07
 

Zamiast sobie strzępić klawiaturę odeślę cię do archiwum pl.comp.security: <slrne4va4g.rnp.dozzie@hans.zsh.bash.org.pl>.
To jest jak najbardziej realne zagrożenie.

 
12. Cukier Sobota, 29 kwietnia 2006, 11:03:40
 

"Kochana uczelnia", szkoda gadac. Szkoda ze "badacze" z IM nie zajzeli na zajecia na EKA, na ktorych uczylismy sie o zmiennych LD_PRELOAD itp. Jako test poszla biblioteka unicorn MIchala Zalewskiego :)

ps: Piko, twoje haslo do jakiejs maszyny unixowej chyba tez gdzies mam, To z czasow kiedy nagminnie podmienialo sie putty na wlasne, "lekko" zmodyfikowane w kafejkach w Kielcach ;)

 
13. Cukier Sobota, 29 kwietnia 2006, 11:05:11
 

A co do blokowania system operacyjnego to polecam "ScreenShot" pulpitu, umiescic go na tapecie i ukryc/skasowac wszystkie ikony ;)
Dziala swietnie...

 
14. Czara Sobota, 29 kwietnia 2006, 12:18:22
 

hehe motyw z screenshotem pulpitu czesto stosowalo sie w liceum :)

 
15. Piotr Konieczny Sobota, 29 kwietnia 2006, 13:02:42
 

Dozzie: Z calym szacunkiem do Ciebie, jako osoby, ktora przyczynila sie do odkrycia -- tak, zachecony komunikatami prasowymi, czytalem wiele razy, to co umiesciliscie na stronie. Dodatkowo, odswiezylem sobie strony podane w referencjach. Atak rozumiem, jego "niewykrywalnosc" takze. Brawo!

Nie zmienia to jednak faktu, ze wszystko jest dla mnie naciagane, a przyklad (z ktorym ubiegl mnie Carstein, i ja podalbym, gdybym mial dostep do sieci 24h/dobe) jest wrecz idealny jako analogia.

Zreszta, sama niewykrywalnosc mozna rozumiec na kilka sposobow (vide: szyfrowany kanal komunikacyjny via DNS)

Jak widzisz, cukier ma jakiestam moje haslo -- i jego metode w gruncie rzeczy tez mozna nazwac niewykrywalna.

I odzywajac sie tutaj poruszyles kolejna kwestie, o ktorej juz nie chcialem wspominac -- Twoj udzial w projekcie. Kurde, dozzie, co Wy zaliczenie z tego macie, ze tak bronisz tej sensacyjnosci? ;-)

@cukier: Pamietam, kiedy cyfer i wil3 bawili sie kloggerami, zostawiajac sobie &quot;dowcipne&quot; komentarze jako loginy i hasla ;-)

 
16. dzz Niedziela, 30 kwietnia 2006, 21:45:08
 

Jego metodę można nazwać jedynie niezauważalną. Hasło musi zostać gdzieś zapisane albo wysłane, wystarczy monitorować zapisy i dane wychodzące. W przypadku ataku na SSL, TLS i SSH (a teraz i na IKE) użytkownik nie ma szans na wykrycie, bo żadne dodatkowe dane nigdzie się nie pojawiają (nie ma pliku, do którego hasło jest zapisane, nie jest wysyłany żaden e-mail z kluczem, zupełnie nic nie ma). To jest atak innej klasy niż zwykłe przechwycenie danych przed zaszyfrowaniem.

I nie, nie mamy zaliczenia z tego. Co więcej, w pracach przy ataku na SSH i SSL/TLS nie brałem udziału, a o luce w IKE jeszcze nic się nie pojawiło.

@Cukier: o czym ty mówisz? Po czym wnioskujesz, że w IM nikt nic nie wie o formacie ELF?

 
17. kaminskp Sobota, 19 stycznia 2008, 18:54:54
 

Jestem zainteresowany protokółem SSL.
Muszę stworzyć pracę magisterską. Strony intranetowe ze skryptami i bazą MySQL. Ma to wykorzystywać ten protokół ale nie wiem jak z nieg skorzystać. Może macie gdzieś coś na ten temat. kaminskp@tlen.pl

 

Dodaj komentarz:

Wyślij pustą wiadomość, aby śledzić komentarze przez bota.
Komentarze są własnością osób komentujących.
Właściciel bloga nie ponosi za nie odpowiedzialności.
Komentarze nie na temat będą usuwane.

Ofiara

Jeśli powyższy wpis przydał Ci się w jakiś sposób,

autorowi :-)

Czytelnicy:

« wszystkie wpisy