Stare luki w TCP odkryte na nowo
Prezentacja Paula Watsona na konferencji CanSecWest, zatytułowana „Slipping In The Window: TCP Reset Attacks” poruszyła światem specjalistów od bezpieczeństwa sieci. Udowodnił on, że luki w implementacji TCP znane od wielu lat da się wykorzystać łatwiej, niż przypuszczano.
Od wielu lat wiadomo, że istnieje teoretyczna możliwość spreparowania pakietów TCP w taki sposób, by przez odbierający je host traktowane były jak pochodzące z innego źródła. Wielokrotnie rozważano możliwość wykorzystania tego mechanizmu do zmodyfikowania sesji TCP pomiędzy dwiema maszynami przez atakującego z zewnątrz. Uznawano to jednak za niewykonalne w praktyce ze względu na używane w protokole TCP tak zwane numery sekwencyjne, identyfikujące kolejność pakietów a także pozwalające na zweryfikowanie spójności danego połączenia. Numery te są tworzone w oparciu o ustalony na początku losowy numer inicjujący (ISN) oraz ilość wysłanych danych. Numer sekwencyjny ma 32 bity, w związku z czym teoretycznie możliwość odgadnięcia numeru, który zostałby zaakceptowany przez serwer wynosi 1/2^32.
W rzeczywistości, host zaakceptuje przychodzący pakiet jeżeli jego numer sekwencyjny mieści się w tzw. oknie, którego wielkość jest zależna od konkretnej implementacji.
CERT/CC w swoim zaleceniu CA-2001-09 z 2001 roku wskazywał na możliwość odgadnięcia numeru ISN w niektórych implementacjach, gdzie występowała zbyt słaba losowość tego numeru.
Tymczasem z badań statystycznych Paula Watsona wynika, że wygenerowanie numerów sekwencyjnych, które zostaną zaakceptowane może zająć czas liczony w sekundach nawet jeśli ISN nie jest znany. Jakie mogą być konsekwencje? W przypadku danych, przychodzące pakiety będą przechowywane i składane we właściwej kolejności. Dlatego podmiana danych w sesji TCP nadal pozostaje trudna do wykonania. Jednak zgodnie z RFC 793, po odebraniu pakietu RST z akceptowalnym numerem sekwencyjnym połączenie zrywane jest od razu. W związku z tym stosunkowo łatwe może być samo zakłócanie łączności i ataki typu (D)DoS.
Najbardziej podatne są wszelkie sesje TCP trwające dłuższy czas, w szczególności między dwoma maszynami o łatwych do poznania lub przewidzenia adresach i numerach portów źródłowych i docelowych. Niestety, do takich połączeń należą sesje BGP. W związku z tym każdy, kto posługuje się tym protokołem i nie zapewnił ochrony BGP na przykład przez zestawienie tuneli IPSec, narażony jest potencjalnie na poważne konsekwencje.
NISCC Vulnerability Advisory 236929 –
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
US-CERT Technical Cyber Security Alert TA04-111A — Vulnerabilities in TCP – http://www.us-cert.gov/cas/techalerts/TA04-111A.html
Źródło informacji: CERT Polska