Połaczenia SSH i bezpieczenstwo transmisji

[Marek Guevara Braun]

Cz w rny wrote:
> Dnia Tue, 07 Feb 2006 19:27:57 +0100, Marek Guevara Braun  
> <marek.guevara w atm.com.pl> napisał:
> 
>> Czyli coś takiego jak dane na temat jakości generatorów losowych danej
>> maszyny - parę lat temu Michał Zalewski (lcamtuf) generował ładne
>> rysunki przestrzenne obrazujące jakość generatorów liczb losowych
>> wykorzystywanych przy generacji numerów sekwencyjnych TCP na różnych
>> platformach - niby nikt się już chyba nie bawi w przejmowanie połączeń
>> TCP (nikt ???),
> 
> To nie tak. Całkiem do niedawna znaczna większość systemów (wszystkie  
> swego czasu) generowały kolejne numery sekwencyjne dla różnych transmisji  
> TCP. W ten sposób można było przy pomocy maszyny zombie skanować porty  
> zdalnej maszyny poprzez porównanie zmiay numerów sekwencyjnych TCP. Tak  
> samo można było przewidzieć numer sekwencyjny kolejnych wysyłanych z  
> komputera pakietów, więc można było przechwytywać sesje TCP i w ogóle  
> dobrze się bawić.

IMHO "to nie tak" - idle scan przy użyciu "zombie" [1] wykorzystuje 16-bitowy
ID z nagłówka IP, natomiast numer sekwencyjny TCP (aka ISN dla pierwszego
pakietu) to 32 bitowe pole nagłówka, ale TCP. Na numerze sekwencyjnym
i 32-bitowym numerze potwierdzenia opiera się sesja TCP -  jeśli jesteśmy
w stanie wymyślić, jakich numerów będą używały strony - można próbować podszyć
się pod jednego z rozmówców i coś tam wkleić do transmitowanych danych lub
zakończyć sesję wysyłając RST bez konieczności dostępu do "drutu".
Teoretycznie mamy 2^64 możliwości, ale jak wykazał lcamtuf [2] tak do końca nie
jest - i dla wielu platform wystarczy wiedzieć jakie numery są wybierane
- stąd heurystyka - bo dokładnie jest to takie samo zgadywanie zachowania
(ograniczanie przestrzeni) wykorzystanego algorytmu.

W każdym razie w dobie połączeń SSH wartość jaką przynosi możliwość
wymyślenia numerów sesyjnych jest dużo mniejsza niż za czasów telneta.

> Pierwsze zablokowało tę możliwosć OpenBSD i hardneningi jajek kernela.  
> Teraz każde nowe połączenie TCP dosatje losową liczbę jako numer  
> sekwencyjny TCP.
> 
> Jakość sprzętowego generatora liczb losowych, systemowych funkcji  
> realizujących losowania i specjalnych bibliotek do tego celu to osobny  
> problem. OpenSSL nieźle sobie na tym polu radzi i również ten problem  
> wział pod uwagę, więc raczej nie ma się co specjalnie przejmować.

Dobry generator implementowany w software jest niestety drogi/wolny
- używając systemu do obsługi wielu sesji SSL/TLS OpenSSL możesz wpaść
w pułapkę wydajności - zwykle rozwiązania wybierają "wydajność" ponad
"losowość" (tj. wybierają metody tańsze/szybsze). Sprzętowe generatory
liczb losowych to już inna historia. Nasz Linux obsługuje od niedawna
PadLock/xcrypt VIA, - czy coś jeszcze - wątpie. Nieco lepiej jest w
Open/Free/NetBSD bo tam są jeszcze różne HiFn i inne. Dodatkowo dostępność
tego w Polsce niemal zerowa. W sumie szkoda że nowe AMD czy Intele
nie zaimplementowały tego tak jak VIA.

> Generalnie nie ma co peniać, w 'normlanych' warunkach, choć trzeba być  
> świadomym, że włamanie się jest kwestią nie możliwośći, a środków  
> zainwestowanych ( w najprostrzym przłożeniu $ ).

Czasami te warunki nie są normalne, a czasem ktoś pisze narzędzie i nagle
to co wydawało się tylko wydumaną teorią może wyklikać każdy śmiertelnik
na swoim WinXP.

No ale zawsze jest jeszcze instancja wyższa dla paranoidalnych
secure-maniaków - przychodzą smutni panowie i zabierają całego kompa
wraz z kompletem kopii backup na CD/DVD :-)

> Chyba EOT co?

EOT, EOT.

Pozdrawiam,
Marek

[1] http://www.insecure.org/nmap/idlescan.html

[2] http://lcamtuf.coredump.cx/newtcp/