Ucieczka z blokowanego internetu #3 sshuttle (Linux/MacOS)

W poprzednich częściach opisałem jak tunelować się przy użyciu ssh i putty. Dzisiaj natrafiłem na fajny programik do tunelowania się przez ssh’a który działa transparentnie  i obsługuje udp.

Program wymaga posiadania uprawnień root’a na komputerze klienckim, za to na serwerze wystarczy nam zwyczajne konto. Przewagą tego rozwiązania nad VPN’ami jest możliwość pełnego tunelowania się przez serwery na których nie możemy instalować oprogramowania. Czytaj dalej Ucieczka z blokowanego internetu #3 sshuttle (Linux/MacOS)

Bender – nowy serwer debiana od zera

Bender

W końcu przyszedł czas na ponowną instalację serwera debiana. Tzn. nie przyszedł bo to linux który może chodzić wiecznie, lecz dla zabawy stwierdziłem, że by się przydała reinstalacja. Ze względu na to że nie lubię jak mi umyka wiedza, opiszę z grubsza instalację i konfigurację serwera.

Nie przedłużając więcej przedstawiam Bender’a.

Dlaczego Bender? Ponieważ chcę wpisać w motd z tekstem

Bite my shiny metal ass

Czytaj dalej Bender – nowy serwer debiana od zera

NSA – Czyli najpotężniejsza organizacja na świecie

O NSA jest dość głośno w szczególności ostatnio kiedy wyszło na jaw, że szpiegują wszystkich jak popadnie bez żadnego nakazu sądowego. Wiele osób nie zdaje sobie sprawy jak potężną organizacją jest NSA.

NSA monitoruje cały ruch sieciowy w Stanach Zjednoczonych, w 90% przypadkach ruch ten jest niezabezpieczony przez jakiekolwiek szyfrowanie. Dzięki temu można odczytać wszystkie informacje jakie są przesyłane do USA. Jeśli myślisz, że Ciebie to nie dotyczy to jesteś w wielkim błędzie. Codziennie przeglądając internet wysyłasz zapytania do serwerów amerykańskich, jako przykład mogę podać znana i występujące chyba wszędzie przyciski Like z Facebook’a, czy Googlowskie Reklamy lub +1 itd. Nawet nie wchodząc na strony na serwerach amerykańskich przesyłamy im informacje o sobie. Nie można zapominać o mailach, które są wysyłany przez najgorszy protokół dostępny w sieci SMTP, który nie ma sam w sobie zaimplementowanego systemu autoryzacji nadawcy wiadomości. Do każdego maila który jest wysyłany do takich adresów jak np. @gmail.com @outlook.com przesyłamy nie bezpośrednio dane ale za pośrednictwem naszego usługodawcy dane czystym tekstem, nawet jak nam się trafi odbiorca w TLD .pl nie mamy gwarancji, że serwer jest poza USA ponieważ możemy sobie go podłączyć pod google apps’y. To są małe przykłady do jakich danych ma dostęp NSA, wystarczy do tego dorzucić dane ze smartphone’ów i już można stwierdzić że NSA wie o tobie prawie wszystko.

Dane które posiada NSA są przerażające, ta organizacja ma praktycznie haki na każdego. Wagę danych które oni posiadają pokazuje sytuacja ze Snowden’em, który to wyniósł dane od nich. Nie wiem czy NSA wie co on wyniósł czy nie, ale można ze spokojem stwierdzić że wkurzył ich ostro, mocniej niż Julian Assange. Zatrzymanie jego jest tak kluczowe dla USA, że grożą oni sankcjami dla Ekwadoru który udzielił mu azylu. Snowden zabezpieczył się przed „zdarzeniami losowymi”, przekazał kilku swoim ludziom zaszyfrowane dane. Niestety w tym sposobie widać pewne luki, można tych ludzi wytropić i albo odebrać im te dane albo je zamazać. W takim wypadku lepiej by było zastosować rozwiązanie Julian’a Assange’a – wrzucić plik na torrent’y. Zniszczenie wszystkich kopii w tym wypadku graniczyłoby z cudem.

Podsumowując aferę z NSA będę próbował trochę naskrobać wpisów nt. zabezpieczenia się przed służbami na tyle ile jest to możliwe.

Ucieczka z blokowanego internetu #2 Putty (*nix/windows)

W poprzedniej części poradnika pokazałem jak omijać blokowany internet przy użyciu programów shellowych. W tej części zamierzam pokazać jak zrobić to samo co wcześniej lecz tym razem przy użyciu po stronie klienta programu putty. Niestety ale nie przeskoczę konfiguracji z shella serwera dlatego przed przystąpieniem do tego poradnika zalecam zapoznanie się z częścią pierwszą ponieważ będę się odnosił do niej.

Dlaczego Putty?

  • Jest na Windowsie. Na systemie operacyjnym Windows nie ma polecenia ssh dlatego najczęściej wykorzystuje się właśnie putty do łączenia się z serwerem ssh.
  • Jest na Linuxie (prawdopodobnie też na innych *nix’ach). Co prawda na linuxie jest ssh, ale niektórzy mogą preferować korzystanie z programu z GUI niż z shell’a.
  • Można w nim robić wszystko co było przedstawione w pierwszej części poradnika
  • Jest otwarto źródłowy, nie wiem jaką ma licencję ale znajduje się w main w repo debiana więc musi być wolnym oprogramowaniem

Instalacja

Windows

Pobieramy program ze strony: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. Mamy do wyboru wersję binarną bez potrzeby instalowania oraz instalkę. Wybieramy wersję która nam najbardziej odpowiada

Linux (na przykładzie Debiana, może się różnić w innych dystrybucjach)

# aptitude install putty

1. Proste tunelowanie

Uruchamiamy putty, w hostname wpisujemy adres swojego serwera. Następnie przechodzimy Connection>SSH>Tunnels.

3

W source port wpisujemy port na którym chcemy otworzyć proxy i wybieramy tryb proxy Dynamic. np.

4

Pamiętamy aby kliknąć Add jeżeli tego nie zrobimy nie ustawimy proxy! Po kliknięciu add w Forwarded prorts powinnien nam się pojawić nowy wpis. np. D8080

5

D – oznacza typ portu dynamiczny

8080 – oznacza który port zostanie użyty w tym przypadku 8080

Teraz aby się nie trudzić z wpisywaniem tego samego za każdym razem przechodzimy do pierwszej karty (Session) i w Saved Session wpisujemy jakąś nazwę dla naszych ustawień i klikamy Save.

6

Teraz klikamy przycisk Open aby połączyć się z serwerem. Teraz może wyskoczyć nam monit o sprawdzenie poprawności klucza. Potwierdzamy klucz jeżeli jest zgodny z tym który jest na serwerze. Logujemy się i jeżeli pojawia nam się shell to udało nam się postawić proxy lokalne.

7

2. Port 22 jest zablokowany

Jeżeli port 22 jest zablokowany w sieci należy ustawić nasłuchiwanie na innym porcie na serwerze, instrukcja jak to zrobić znajduje się w pierwszej części poradnika.

Aby połączyć się z serwerem na innym porcie należy w putty w polu port zmienić port z 22 na 443. np.

443

Nowe ustawienia możemy zapisać w nowym profilu.

3. Wyższa szkoła jazdy czyli wszystko przez proxy

Aby tunelować się przez proxy należy ustawić serwer ssh aby działał na porcie 443, instrukcja jak to zrobić znajduje się w pierwszej części poradnika.

W naszym kliencie putty należy przejść do Connection>Proxy, wybrać opcję proxy http (zapewne takie jest proxy) ustawić host na proxy u nas w sieci (nie to nasze które dopiero chcemy postawić) i jego port. np.

proxyJeżeli nie dostaniemy błędu Forbidden powinno wszystko nam działać.

 

To by było na tyle ze strony używania putty, ominąłem części poradnika które się powtarzały (w końcu nikt nie chce czytać tego samego dwa razy). Powyższe sytuacje sprawdziłem na swojej sieci (choć nie była ona blokowana) więc powinno wszystko działać i śmigać chyba że się walczy z administratorem który musi tylko reagować na występujące sytuację, utrudniając coraz bardziej dostęp do sieci.

Część 3 – shuttle (Linux/MacOS)

Ucieczka z blokowanego internetu (*nix)

Czasami zdarza się że korzystamy z internetu który przez administratora sieci jest ograniczony. Jest wiele powodów dlaczego dla których taka sytuacja występuje, (ochrona przed piractwem, zmniejszenie obciążenia sieci, zwiększenie wydajności pracy itp.) lecz czasami się zdarza iż potrzebujemy skorzystać z zablokowanych usług np. zablokowany smtp do wysyłania poczty w hotspotcie na lotnisku. W takim wypadku trzeba przekierować ruch przez jakiś swój serwer.

W poniższym artykule będę korzystał z przypadku kiedy mamy własny serwer (jesteśmy jego administratorami z uprawnieniami root’a).

1. Proste tunelowanie

W tym przypadku bierzemy pod uwagę sytuację w której nie jest blokowany standardowy port ssh (22/tcp), wtedy wystarczy proste postawienie proxy socks przez klienta ssh.

$ ssh [email protected] -D 8080

Opcja -D 8080 otwiera na loopbacku port 8080 na którym będzie stało nasze proxy socks. Numer portu może być dowolny, jednak normalny użytkownik nie może otworzyć portu poniżej 1024 to może tylko root jednak nie ma to większego sensu.

Jeżeli chcemy możemy sprawdzić czy port jest otwarty poleceniem nmap.

$ nmap localhost
Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-20 10:27 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000070s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
111/tcp  open  rpcbind
631/tcp  open  ipp
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

Ok mamy już postawione proxy i możemy korzystać przez niego z nieograniczonego internetu.

2. Port 22 jest zablokowany

Może przydarzyć się sytuacja iż port 22 jest zablokowany. W tym wypadku możemy postawić serwer ssh na innym porcie. Lecz musimy się dostać do swojego serwera w inny sposób (w końcu w sieci której jesteśmy port do secure sh jest zablokowany). Najprawdopodobniej otwarte porty będą w przedziale do 1024, są to porty których przeznaczenie jest znane. Możemy wypisać je poleceniem:

$ grep '\([^0-9][0-9]\{1,3\}\|10[0-1][0-9]\|102[0-4]\)\/tcp' /etc/services

Z pewniejszych portów można wyłonić:

ftp		21/tcp
smtp		25/tcp		mail
domain		53/tcp				# Domain Name Server
http		80/tcp		www		# WorldWideWeb HTTP
pop3		110/tcp		pop-3		# POP version 3
ntp		123/tcp
https		443/tcp				# http protocol over TLS/SSL
urd		465/tcp		ssmtp smtps  # URL Rendesvous Directory for SSM
submission	587/tcp				# Submission [RFC4409]
imaps		993/tcp				# IMAP over SSL
pop3s		995/tcp				# POP-3 over SSL

Portami które nie będą się rzucały na pierwszy rzut oka że jest coś nie tak będą wszystkie SSL’e, w końcu nie da się SSL swobodnie podsłuchiwać bez MitM’a ale to da się w przypadku ssh łatwo zauważyć. Wytypowane przeze mnie porty są IMO najczęściej wykorzystywane w necie, można użyć też innych portów które się uważa że mogą być otwarte. Teraz pozostaje nam zmienić konfigurację serwera ssh. W debianie plik konfiguracji znajduje się w:

/etc/ssh/sshd_config

Otwieramy go oczywiście jako root swoim ulubionym edytorem czyli vim’em np.

# vim /etc/ssh/sshd_config

Następnie znajdujemy wpis odpowiedzialny za nasłuchiwanie na portach. Najczęściej będzie to

# What ports, IPs and protocols we listen for
Port 22

Teraz poniżej tego wpisu dopisujemy dodatkowe porty na których chcemy aby nam nasłuchiwał serwer ssh. np.

# What ports, IPs and protocols we listen for
Port 22
Port 993
Port 443

Teraz pozostaje nam zrestartować serwer ssh (aktualne połączenia z serwerem ssh nie zostaną przerwane), np w debianie:

# service ssh restart

Teraz mamy otwarte dodatkowe porty dla serwera ssh. Teraz na swoim komputerze klienckim uruchamiamy ssh z dodatkowym parametrem -p i numerem portu np.

$ ssh [email protected] -p 995 -D 8080

Opcja -D zostaje ponieważ ona odpowiada nam za otwarcie dynamicznego proxy na porcie 8080 (lokalnie). Jeśli port nie jest blokowany to połączymy się bez problemu.

3. Wyższa szkoła jazdy czyli wszystko przez proxy.

Może się wydarzyć sytuacja iż tak wkurzyliśmy administratora że zablokował cały ruch wychodzący do sieci, a dostęp do internetu mamy przez czyjeś proxy, niestety nie jest to proxy typu socks lecz http. Nawet i na to znajdzie się rozwiązanie. Na początek musimy zainstalować pakiet corkscrew. Następnie edytujemy plik własnej konfiguracji SSH.

$ ~/.ssh/config

W pliku wpisujemy

ProxyCommand /usr/bin/corkscrew PROXY_HOST PROXY_PORT %h %p

Gdzie PROXY_HOST adres IP serwera proxy a PROXY_PORT to port serwera proxy. Teraz łączymy się ze swoim serwerem tak jak w punkcie poprzednim tylko z użyciem portu 443. Można spróbować użyć innych portów ale najprawdopodobniej http+ssl (443/tcp) będzie otwarty. Teraz pozostaje nam korzystać z naszego proxy zamiast tego wymuszonego.

Walka z wiatrakami

Co dalej? Tego nie mogę przewidzieć. Administrator może w łatwy sposób po kolei blokować serwer kiedy wykryje że na nich jest postawione ssh lub inny serwis do obejścia ograniczeń sieci. Próba wymuszenia na administratorze lub jego szefie odblokowania którejś z usług może się skończyć dwojako. Nawet jak uda wam się przekonać kogoś do odblokowania ssh’a to może on nałożyć cap’a na niego w wielkości np 20 kb/s. Przy dzisiejszym internecie na nic nam to się zda. W przypadku kiedy nie uda nam się namówić kogoś na odblokowanie ssh’a może się to skończyć różnymi konsekwencjami np. można być oskarżonym w pracy o próbę wyniesienia poufnych danych firmowych i zostać zwolnionym, dlatego przed przystąpieniem do robienia czegokolwiek związanego z obejściem zabezpieczeń lepiej jest się zorientować jakie to może nieść za sobą konsekwencje.

Jak znajdę jeszcze trochę czasu to zrobię mały dodatek dla obsługi ssh’a przez putty ponieważ na windowsie nie ma natywnego ssh’a.

Część 2 – Putty (*nix/windows)

Część 3 – shuttle (Linux/MacOS)

PMA – Część 1 Uzyskiwanie dostępu do sieci bezprzewodowych

Podane poniżej informacje służą tylko i wyłącznie do przeprowadzania
zaplanowanych audytów ze zgodą właściciela lub administratora sieci
którą audytujesz!

Czas na pierwszą część Poradnika Małego Audytora – Łamanie kluczy sieci bezprzewodowych.

1. Wstęp

Sieci bezprzewodowe mogą być Otwarte (bez żadnego szyfrowania), WEP, WPA1/2-Personal, WPA1/2-Enterprise. Dodatkowo sieć może posiadać filtrację adresów mac i brak rozgłaszania SSID.

Czytaj dalej PMA – Część 1 Uzyskiwanie dostępu do sieci bezprzewodowych

Poradnik małego audytora

Podane poniżej informacje służą tylko i wyłącznie do przeprowadzania
zaplanowanych audytów ze zgodą właściciela lub administratora sieci
którą audytujesz!

Niezapisana wiedza z czasem umyka, no może nie wszystkim ale mi tak. Zauważyłem to ostatnio z audytem który zacząłem przeprowadzać. Nie pamiętałem jak użyć john’a no i zapomniałem o fajnych narzędziach typu IGHASHGPU. No i w międzyczasie wyszły nowe lepsze narzędzia. Doszedłem do wniosku iż muszę swoją wiedzę zapisać w jakiejś formie. Napisanie tego na blogu jest dość dobrym rozwiązaniem, ja się dzielę wiedzą a odwiedzający mój blog mogą mnie w czymś poprawić, coś podpowiedzieć.

W tej serii wpisów zamierzam poruszyć następujące tematy:

  1. Sieci bezprzewodowe – uzyskiwanie dostępu do zabezpieczonej sieci wifi
  2. Podglądanie otwartych portów na serwerze
  3. Podsłuchiwanie ruchu sieciowego
  4. ARP Spoofing
  5. TOR
  6. Odzyskiwanie haseł w Windows i *nix

Dla napisania wpisów będę używał debiana. Wiem że jest coś takiego jak backtrack ale to jest dystrybucja służąca tylko do jednego, a debian może służyć również do normalnego używania a nie tylko audytu.