Kippo – czyli honeypot ssh

Kippo jest narzędziem typu honeypot napisanym w Pythonie emulującym połączenie z usługą SSH. Po udanej próbie logowania do serwera, atakujący otrzymuje wrażenie pełnej interakcji z konsolą atakowanej maszyny. Kippo od tego momentu loguje nawiązanie połączenia SSH oraz pełną interakcję atakującego z systemem (pełny listing wykonanych komend oraz rzeczywiste pobieranie plików atakującego do innej lokalizacji gdy ten wyda komendę wget). Oczywiście z racji, że jest to honeypot to atakujący w pewien sposób musi się dostać do systemu zabezpieczonego hasłem, oraz dodatkowo, dla przykładu metodą rekonesansu, odnaleźć usługę SSH wystawioną na innym porcie niż domyślny 22. Głównym celem wdrożenia Kippo jest spowodowanie by atakujący miał wrażenie poruszania się po realnym systemie, co zespołowi ds. bezpieczeństwa IT może dać pogląd na podstawie wydanych przez niego komend – w jakim celu nastąpiło włamanie, do jakich danych atakujący próbował się dostać oraz jakie wykorzystał techniki. Niewątpliwie jest to również źródło nauki w jaki sposób administrator w niedalekiej przyszłości powinien wzmocnić system. Do głównych zalet Kippo można zaliczyć:

• sfałszowany system plików oparty na Debianie 5.0 wraz z możliwością emulacji dodawania/usuwania plików
• możliwość podkładania zawartości plików w przypadku wykonywania polecenia cat przez atakującego (np. cat /etc/passwd)
• zachowanie do odrębnej lokalizacji plików pobranych przez polecenie wget
• logowanie zachowania użytkownika do formatu kompatybilnego z UML (User-Mode-Linux)

Dokument opisuje proces przygotowania systemu, instalację i konfigurację serwera Kippo, instalację dodatków, a następnie metody ochrony serwera przed wykryciem i atakami. Tzw. drobny hardening systemu Linux przewija się przez cały dokument. Niektóre metody mogą budzić kontrowersje ze względu na wygodę i lenistwo, jednak zaraz potem następuje wytłumaczenie i ewentualny sposób łatania.

Instalacja serwera SSH

W pierwszej kolejności należy mieć na czym postawić usługę Kippo do czego potencjalny włamywacz będzie mógł próbować się dostać. Oczywiście zastosowanie protokołu telnet lub rlogin, które używają czystego-tekstu w transmisji mija się z celem, wobec czego środowiskiem testowym będzie dystrybucja Ubuntu 12.04 z najnowszą wersją serwera SSH zainstalowanym z pomocą systemu zarządzania pakietami apt.

Przygotowanie systemu

Warto też doinstalować inne potrzebne narzędzia jak htop, mc. Na początku proponuję wykonać poniższe polecenie, co spowoduje, że każda komenda w Ubuntu nie będzie musiała być poprzedzana komendą sudo , a proces instalacji pakietów będzie o wiele łatwiejszy i zautomatyzowany.

user1@ubuntu:~$ sudo passwd root	
[sudo] user1 Password: **********
Enter new UNIX password:
Retype new UNIX password:
user1@ubuntu:~$: su -
Enter password: ****  	
root@ubuntu:~#  		
root@ubuntu:~# uname -a 
Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux 

Aktualizacja systemu

Przed przystąpieniem do instalacji Kippo warto zaktualizować pakiety w systemie operacyjnym. Jeżeli wiesz, że chcesz aktywować wszystkie, wystarczy wydać polecenia:

root@ubuntu:~# apt-get update 
root@ubuntu:~# apt-get upgrade 
root@ubuntu:~# apt-get dist-upgrade

Przy pełnej aktualizacji systemu warto oczywiście wyłączyć usługi, które uważa się za zbędne celem uniknięcia ich wyexploitowania. Może to zminimalizować ryzyko kompromitacji systemu. Dla Ubuntu można je podejrzeć za pomocą polecenia:

root@ubuntu:~# ls /etc/init.d/

Natomiast w przypadku systemów opartych o Red Hat – wystarczy użyć polecenia chkconfig (które również może zostać zainstalowane z repozytorium apt) znaleźć usługi które są wywoływane od poziomu runlevel 3.

root@ubuntu:~# chkconfig --list | grep '3:on'
apache2                   0:off  1:off  2:on   3:on   4:on   5:on   6:off
dns-clean                 0:off  1:on   2:on   3:on   4:on   5:on   6:off
grub-common               0:off  1:off  2:on   3:on   4:on   5:on   6:off
ondemand                  0:off  1:off  2:on   3:on   4:on   5:on   6:off
pppd-dns                  0:off  1:on   2:on   3:on   4:on   5:on   6:off
rc.local                  0:off  1:off  2:on   3:on   4:on   5:on   6:off
rsync                     0:off  1:off  2:on   3:on   4:on   5:on   6:off
sudo                      0:off  1:off  2:on   3:on   4:on   5:on   6:off

Instalacja serwera i klienta SSH

Aby zainstalować serwer SSHd wystarczy wydać polecenia:

root@ubuntu:~# apt-get install openssh-server openssh-client 

Konfiguracja serwera

Oczywiście po wykonaniu wszystkich opcji konfiguracyjnych warto wyłączyć logowanie za pośrednictwem konta root, albo w ogóle ograniczyć dostęp do SSH tylko konkretnym użytkownikom. Dobrą praktyką utrudniającą wykrycie właściwego portu usługi jest oczywiście jego zmiana na wyższy, przykładowo nasłuch SSH na porcie 6969 (zamiast zwykłej zmiany portu można do tego celu użyć authbind).

root@ubuntu:~# vi /etc/ssh/sshd_config  

Wartości do zmiany:

PermitRootLogin no
AllowUsers user1
Protocol 2
Port 6969

Warto również dodać demona SSH do autostartu, w Ubuntu za pośrednictwem:

root@ubuntu:~# update-rc.d ssh defaults

Lub chkconfig:

root@ubuntu:~# chkconfig sshd on

Weryfikacja poprawności konfiguracji

Weryfikację logowania konta root oczywiście następuje przy próbie logowania na to konto, natomiast by sprawdzić właściwą konfigurację portu to oprócz bezpośredniego połączenia się do serwera:

root@ubuntu:~# ssh user1@192.168.37.135 -p 6969
The authenticity of host '[192.168.37.135]:6969 ([192.168.37.135]:6969)' can't be established.
ECDSA key fingerprint is c3:6b:b2:0d:63:34:2b:08:02:bb:29:2d:55:02:04:96.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.37.135]:6969' (ECDSA) to the list of known hosts.
user1@192.168.37.135's password:

… można ją sprawdzić za pośrednictwem polecenia netstat:

root@ubuntu:~# netstat -ant | grep 6969
tcp        0      0 0.0.0.0:6969            0.0.0.0:*               LISTEN
tcp        0      0 192.168.37.135:52108    192.168.37.135:6969     ESTABLISHED
tcp        0      0 192.168.37.135:6969     192.168.37.1:1839       ESTABLISHED
tcp        0      0 192.168.37.135:52109    192.168.37.135:6969     TIME_WAIT
tcp        0      0 192.168.37.135:6969     192.168.37.135:52108    ESTABLISHED
tcp6       0      0 :::6969                 :::*                    LISTEN

Na liście nasłuchujących połączeń widnieje również wartość tcp6, oznacza to, że protokół IPv6 jest włączony. Jeżeli w sieci nie jest stosowany, warto go wyłączyć ze względów bezpieczeństwa. Sprawdzenie czy na pewno protokół v6 jest włączony można sprawdzić poleceniem cat :

root@ubuntu:~# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0

0 oznacza, że protokół jest włączony. W celu wyłączenia należy dodać w /etc/sysctl.conf linijki:

#disable ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Następnie załadować ponownie sysctl komendą:

root@ubuntu:~# sysctl -p

Żeby w pełni wyłączyć ipv6 wraz z podniesieniem systemu można zmodyfikować rekord rozruchowy GRUB:

root@ubuntu:~# vi /etc/default/grub

Zmienić pustą argumentację linijki na następującą:

GRUB_CMDLINE_LINUX="ipv6.disable=1"

Teraz przeładowanie GRUB i restart systemu:

root@ubuntu:~# update-grub2
root@ubuntu:~# shutdown -r now

Ponowne sprawdzenie komendą netstat weryfikuje, że połączenie nie jest nasłuchiwane za pomocą protokołu wersji szóstej.

root@ubuntu:~# netstat -ant | grep 6969
tcp        0      0 0.0.0.0:6969            0.0.0.0:*               LISTEN
tcp        1      0 192.168.37.135:52108    192.168.37.135:6969     CLOSE_WAIT
tcp        0      0 192.168.37.135:6969     192.168.37.1:1839       ESTABLISHED

Warto wspomagać się dodatkowymi narzędziami takimi jak mc i htop. Pierwszy to Midnight Commander czyli okienkowy nawigator plików, a htop to podgląd procesów i ich wydajności w czasie rzeczywistym (pstree++).

root@ubuntu:~# apt-get install -y mc htop 

Instalacja i konfiguracja Kippo

Instalacja zależności Kippo

root@ubuntu:~# apt-get install python-dev openssl python-openssl python-pyasn1 python-twisted -y

Do ściągnięcia Kippo zostanie użyty SVN, wobec czego również należy pakiet Subwersji zainstalować (Kippo może zostać również pobrane za pośrednictwem wget  jako tar.gz):

root@ubuntu:~# apt-get install subversion -y

Tworzenie użytkownika

Kippo nie może zostać uruchomione jako r00t. Należy stworzyć niezależnego użytkownika z katalogiem domowym /home/kippo, domyślną powłoką logowania /bin/bash i nadanie uprawnień sudo:

root@ubuntu:~# useradd -d /home/kippo -s /bin/bash -m kippo -g sudo
root@ubuntu:~# passwd kippo

Instalacja i konfiguracja Kippo

Należy przelogować się na użytkownika kippo i pobrać SVN:

root@ubuntu:~# su kippo 
kippo@ubuntu:/root$ pwd  
/root  
kippo@ubuntu:/root$ cd /home/kippo/  
kippo@ubuntu:~$ svn checkout http://kippo.googlecode.com/svn/trunk/ ./kippo  

Należy przejść do katalogu /kippo/:

kippo@ubuntu:/root$ cd kippo/ && ls
data  dl  doc  fs.pickle  honeyfs  kippo  kippo.cfg.dist  kippo.tac  log  private.key  public.key  start.sh  txtcmds  utils

Opis najbardziej znaczących plików i folderów:

• dl – katalog domyślny do pobranych plików przez atakującego za pośrednictwem wydanej komendy wget (warto zmienić folder na inny na innej maszynie i mapować go za pomocą smbd lub nfs, by atakujący przez przypadek nie zapchał zasobów dyskowych)
• honeyfs – folder zawierający część plików, które zostaną zaprezentowane atakującemu
• kippo.cfg.dist – główny plik konfiguracyjny (do zmiany na kippo.cfg)
• log – folder domyślny dla logów zbieranych na podstawie działań atakującego
• start.sh – skrypt startowy
• utils – folder zawiera wiele ciekawych narzędzi, do których można zaliczyć playlog.py, które pozwala odtworzyć sesję atakującego (podobne do nagrania wideo konsoli). Pozostałe narzędzia są opisane i wykorzystywane poniżej.

Celem właściwego wystartowania serwera Kippo należy zmienić nazwę pliku konfiguracyjnego usuwając rozszerzenie .dist:

kippo@ubuntu:/kippo$ mv kippo.cfg.dist kippo.cfg  
kippo@ubuntu:/kippo$ vi kippo.cfg 

Kippo domyślnie oczekuje na połączenia na porcie 2222. Dodatkowo Kippo wymaga uruchomienia przez użytkownika nieuprzywilejowanego (stąd komenda useradd), a wiadomo, że taki użytkownik nie jest w stanie otworzyć żadnego portu poniżej 1024. Z punktu socjotechnicznego warto ustawić połączenie honeypotu na porcie 22, gdyż jest to pierwsze miejsce do jakiego potencjalny włamywacz będzie zaglądał. Administrator może się logować do shella serwera za pośrednictwem portu 6969, natomiast Kippo pracując na porcie 6666 za pomocą reguły iptables może zostać przekierowane na port 22:

root@ubuntu:~# iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 6666

Zobrazowanie przekierowania portu:

Natomiast w pliku kippo.cfg należy zrobić wpis w ten sposób:

ssh_port = 6666 
hostname = god-ldap 

Pozostałe parametry

Pozostałe parametry w pliku konfiguracyjnym nie są mniej istotne, gdyż też mogą znacząco utrudnić atakującemu weryfikację, że pracuje z honeypotem. Do najciekawszych można zaliczyć klonowanie systemu plików, zmianę nazwy systemu operacyjnego, podłożenie pliku passwd oraz ustalenie alternatywnych haseł dla konta root.

Klonowanie systemu plików

Kippo domyślnie jest uruchamiane z własnym systemem plików, jednak jest on datowany na 2009 rok, więc warto wykonać klon własnego systemu bez udostępniania żadnej wrażliwej informacji. Dokonuje się tego za pomocą skryptu createfs.py z wcześniej wspomnianego katalogu utils:

kippo@ubuntu:/kippo/$ sudo utils/createfs.py > fs.pickle

Zmiana nazwy systemu

Są dwie szkoły w kwestii podłączenia pliku /etc/issue. Można zmienić tę wartość całkowicie na nieznaną lub pozostawić np. starszą wersję dystrybucji. Z psychologicznego punktu widzenia włamywacz powinien wtedy próbować exploitować system zgodnie z pokazaną wersją.

kippo@ubuntu:/kippo/$ sudo echo "Linux Ubuntu 10.10 \n \l" > honeyfs/etc/issue

Urealnienie pliku passwd

Innym ważnym plikiem jest /home/kippo/data/userdb.txt, którego zawartość wygląda jak /etc/passwd bez szyfrowania. Jest to oczywiście wirtualna baza użytkowników. Im bardziej realnie wygląda taki plik (można do niego dodać różne demony usług) – tym większe prawdopodobieństwo, że atakujący na chwilę będzie miał uśpioną czujność.

kippo@ubuntu:~/kippo/data$ cat << EOF >> userdb.txt 
root:0:123456 
user1:0:p4ssw0rd 
EOF

Alternatywnie można edytować plik honeyfs/etc/passwd .

Alternatywne łatwe hasła konta root

Po co? Zgodnie z przysłowiem „Przyjaciół trzymaj blisko, ale wrogów jeszcze bliżej” warto mieć pełną kontrolę nad logiem, kto, kiedy i w jakich okolicznościach próbuje się dostać do systemu. Zostawiając mu sfałszowaną lukę, administrator może szybko zareagować namierzając atakującego lub blokując ruch z danego hosta.

kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add password
kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add passw0rd
kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add admin 
kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add t00r 
kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add 12345 
kippo@ubuntu:~/kippo$ utils/passdb.py data/pass.db add qwerty

Lista dodatkowych znanych komend

Kippo domyślnie całkowicie nie emuluje powłoki, wobec czego można dodać do skryptu całkiem pokaźną listę komend „znanych” i często używanych przez atakującego. Te komendy będą trzymane w folderze txtcmds/. By stworzyć nową komendę należy przekierować rzeczywistą odpowiedź tejże komendy do wirtualnego folderu /bin pod folderem /txtcmds. Jest to typowa odpowiedź statyczna, jednak administratorowi da kolejne cenne minuty wobec skonfundowanego atakującego.

kippo@ubuntu:~/kippo$ df -h > txtcmds/bin/df
kippo@ubuntu:~/kippo$ sudo iptables -L > txtcmds/bin/iptables
kippo@ubuntu:~/kippo$ ps aux > txtcmds/bin/ps

W ten sposób polecenie iptables nie zwróci niczego, gdyż domyślnie sudo będzie oczekiwało na hasło użytkownika.

Uruchomienie Kippo

Skrypt startowy nazywa się start.sh i można go wywołać komendą:

kippo@ubuntu:/kippo$ ./start.sh 

Przegląd zawartości loga

Logi znajdują się w pliku /home/kippo/log/kippo.log, warto do niego zajrzeć:

kippo@ubuntu:~/kippo/data$ cat /home/kippo/log/kippo.log 
2014-04-11 04:21:53-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] unauthorized login: 
2014-04-11 04:21:53-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root trying auth keyboard-interactive
2014-04-11 04:21:57-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] login attempt [root/abcdef] failed
2014-04-11 04:21:57-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root failed auth keyboard-interactive
2014-04-11 04:21:57-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] unauthorized login:
2014-04-11 04:21:57-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root trying auth keyboard-interactive
2014-04-11 04:21:58-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] login attempt [root/qwerty] failed
2014-04-11 04:21:58-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root failed auth keyboard-interactive
2014-04-11 04:21:58-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] unauthorized login:
2014-04-11 04:21:58-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root trying auth keyboard-interactive
2014-04-11 04:21:59-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] login attempt [root/12345] failed
2014-04-11 04:21:59-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root failed auth keyboard-interactive
2014-04-11 04:21:59-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] unauthorized login:
2014-04-11 04:21:59-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root trying auth keyboard-interactive
2014-04-11 04:25:18-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] login attempt [root/123456] succeeded
2014-04-11 04:25:18-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] root authenticated with keyboard-interactive
2014-04-11 04:25:18-0700 [SSHService ssh-userauth on HoneyPotTransport,0,192.168.37.1] starting service ssh-connection
2014-04-11 04:25:18-0700 [SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] got channel session request
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] channel open
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] pty request: xterm (50, 189, 0, 0)
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] Terminal size: 50 189
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] getting shell
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] Opening TTY log: log/tty/20140411-042518-1689.log
2014-04-11 04:25:18-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] /etc/motd resolved into /etc/motd
2014-04-11 04:25:20-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] CMD: ls
2014-04-11 04:25:20-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] Command found: ls
2014-04-11 04:25:21-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] CMD: ls -lsa
2014-04-11 04:25:21-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] Command found: ls -lsa
2014-04-11 04:25:25-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] CMD: exit
2014-04-11 04:25:25-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] Command found: exit
2014-04-11 04:25:25-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] sending close 0
2014-04-11 04:25:25-0700 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,0,192.168.37.1] remote close
2014-04-11 04:25:25-0700 [HoneyPotTransport,0,192.168.37.1] connection lost

Log w znakomity sposób przedstawia dwie główne funkcjonalności Kippo. Pierwsza to rejestrowanie prób logowania na serwer, a do drugiej zaliczamy raportowanie wszystkich czynności jakie użytkownik wykonał na serwerze.

Log pseudo-wideo z popcornem i colą

W przypadku gdy log jest obszerny, a taki z pewnością będzie, istnieje znacznie wygodniejsza metoda sprawdzania podatności, opiera się ona na skrypcie pythona dostępnego z katalogu utils o nazwie playlog.py. Za jego pośrednictwem można odzwierciedlić dokładne czasowe zachowanie się włamywacza. Istnieje wrażenie jakby oglądało się film z konsoli. Wskazany log jednakże pobiera się z innego miejsca i nie jest to kippo.log

kippo@kipp0:~/kippo$ ls -lsa log/tty/
total 72
 4 drwxr-xr-x 3 kippo sudo  4096 Jun 13 13:22 .
 4 drwxr-xr-x 4 kippo sudo  4096 Jun 13 12:55 ..
36 -rw------- 1 kippo sudo 36686 Jun 13 12:57 20140613-125558-9854.log
24 -rw------- 1 kippo sudo 22770 Jun 13 13:22 20140613-132213-3919.log

Każde nawiązanie połączenia do fałszywego terminala powoduje wygenerowanie pliku z timestamp od pierwszej próby logowania. Odczytać taki plik w czasie rzeczywistym można za pośrednictwem polecenia:

kippo@kipp0:~/kippo$ utils/playlog.py log/tty/20140613-132213-3919.log

Jest to zdecydowanie efektywniejsza metoda analizy całościowej, nie licząc poszukiwań konkretnego sposobu ataku.

Ciekawe statystyki

Na blogu infosanity można przeczytać o zebraniu przez autora ciekawych statystyk, który przez dwa tygodnie wystawiał na światło dzienne do ataku serwer Kippo. Narzucające się wnioski są kluczowe, gdyż wynika z nich, że atakujący w większości przypadków nadal próbują zyskać dostęp do systemu przez najsłabsze ogniwo jakim jest człowiek, który z lenistwa bądź niewiedzy ustawia hasło '123456′ lub ustawia login 'admin’ bo łatwo mu zapamiętać.

Najczęściej typowane hasła:

1. a (651)
2. 123456 (495)
3. password (331)
4. 12345 (302)
5. 123 (224)
6. 1234 (169)
7. 1 (139)
8. 12 (123)
9. root (105)
10. test (46)

Najczęściej typowane loginy:

1. root (8510)
2. admin (144)
3. test (127)
4. oracle (96)
5. nagios (49)
6. mysql (47)
7. guest (43)
8. info (42)
9. user (41)
10. postgres (40)

Liczba połączeń z unikalnego adresu IP:

1. 202.99.89.69 (5212)
2. 200.61.189.164 (1752)
3. 78.37.83.203 (1043)
4. 218.108.235.86 (848)
5. 195.14.50.8 (628)
6. 218.80.200.138 (271)
7. 58.222.200.226 (238)
8. 58.18.172.206 (158)
9. 119.188.7.174 (128)
10. 119.42.148.10 (113)

Kippo-graph

Kippo-graph jest skryptem wizualizującym statystyki zebrane przez kippo.log jak również zbierającym playlogi z kippo/log/tty/. Wymaga zainstalowanego serwera WWW, PHP oraz MySQL, gdyż korzysta z biblioteki Libchart i dowolnej, stworzonej bazy danych. W pierwszej kolejności należy zainstalować serwer MySQL (ewentualnie można także instalować panel phpMyAdmin w zależności od newralgiczności systemu (im wyższa – tym mniej polecane jest otwieranie kolejnej potencjalnej podatności). Parametr -y domyślnie odpowiada 'yes’ na pytanie czy kontynuować instalację.

root@ubuntu:~# apt-get install -y mysql-server mysql-client apache2

Następnie należy stworzyć bazę danych 'kippo’ z pełnymi uprawnieniami

root@ubuntu:~# mysql -h localhost -u root -p
mysql> create database kippo;
mysql> GRANT ALL ON kippo.* TO 'kippo'@'localhost' IDENTIFIED BY 'passw0rd';
exit

Tabele nie trzeba tworzyć z palca, wystarczy skorzystać z gotowego skryptu sql mysql.sql:

root@ubuntu:~# cd /home/kippo/kippo/doc/sql
mysql> mysql -u kippo -p
mysql> use kippo;
mysql> source mysql.sql;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.01 sec)
mysql> show tables;
+-----------------+
| Tables_in_kippo |
+-----------------+
| auth            |
| clients         |
| downloads       |
| input           |
| sensors         |
| sessions        |
| ttylog          |
+-----------------+
7 rows in set (0.00 sec)
exit

Wraz z kolejnymi wydaniami Kippo zostały dodane aktualizacje łatające pewne zbędne funkcjonalności lub oczywiste luki i również należy je zastosować:

root@ubuntu:~# cd /home/kippo/kippo/doc/sql
mysql> mysql -u kippo -p
mysql> use kippo;
mysql> source update2.sql;
mysql> source update3.sql;
mysql> source update4.sql;
mysql> source update5.sql;
mysql> source update6.sql;
mysql> source update7.sql;
exit

W następnym kroku do pliku kippo.cfg należy podać parametry do połączenia z bazą danych:

[database_mysql]
host = localhost
database = kippo
username = kippo
password = passw0rd

Należy ściągnąć i zainstalować kippo-graph i skopiować jego zawartość do folderu wystawianego na serwer Apache:

root@ubuntu:~# wget http://bruteforce.gr/wp-content/uploads/kippo-graph-0.9.3.tar
root@ubuntu:~# mv kippo-graph-0.9.3.tar /var/www
root@ubuntu:~# cd /var/www
root@ubuntu:~# tar xvf kippo-graph-0.9.3.tar --no-same-permissions
root@ubuntu:~# cd kippo-graph
root@ubuntu:~# chmod 777 generated-graphs
root@ubuntu:~# vi config.php

Podobnie jak w przypadku samego Kippo, należy Kippo-graph połączyć z bazą danych wpisując wartości do pliku config.php:

define('DB_HOST', 'localhost');
define('DB_USER', 'kippo');
define('DB_PASS', 'passw0rd');
define('DB_NAME', 'kippo');
define('DB_PORT', '3306');

Przykładowe ekrany Kippo-graph

Film how-to!

Zapraszam do obejrzenia filmu obejmującego instalację i konfigurację kippo oraz kippo-graph zgodnie z powyższą publikacją:

Rozpoznawanie Kippo

Komenda „./”

Największą wadą opisanego honeypota jest fakt, że symuluje on system, a nie jest pełnym emulatorem i kopią danego środowiska, wobec tego atakujący powinien mieć nawyk w pierwszej kolejności wydania polecenia, które od razu nasunie mu myśl „coś jest nie tak”. Przykładem, który może przeoczyć administrator jest komenda ./, gdzie zachowanie normalnego systemu wygląda tak:

root@ubuntu:~# ./
-bash: ./: Is a directory

A wirtualna powłoka odpowie tak:

root@god:~# ./
./: command not found

Komenda „w” oraz „uptime” – statyczna wartość

Innym przykładem jest statyczna komenda w oraz uptime . Atakujący wiedząc czym jest Kippo, wie, że ma on w sobie w pliku /commands/base.py hardkodowe wartości pokazujące zawsze 14 days, 3:53. Oczywiście wystarczy zmienić te wartości na coś innego (byle identycznego) i wtedy te wartości nie rzucają się w oczy:

root@ubuntu:/home/kippo/kippo# uptime
 12:31:41 up  1:52,  2 users,  load average: 0.05, 0.04, 0.05
root@ubuntu:/home/kippo/kippo# w
 12:31:42 up  1:52,  2 users,  load average: 0.05, 0.04, 0.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1                      10:40    1:50m  0.43s  0.01s ssh user1@192.168.37.135 -p 6969
root     pts/0    192.168.37.1     12:24    6.00s  0.12s  0.00s w

Zmylenie „wget”

Z racji, że Kippo zezwala atakującemu na pobieranie plików oraz sam je pobiera do specyficznego folderu za pomocą komendy wget. Analiza emulatora wget.py pokazuje, że wget dodaje wartość „http://” do każdego zapytania, ale jest ona jedynie przekazywana do funkcji connectTCP z biblioteki twisted:

commands/wget.py:103
self.connection = reactor.connectTCP(
            host, port, factory, bindAddress=out_addr)

Wystarczy więc wydać polecenie:

root@god:~# wget microsoft.com:80

By po chwili otrzymać jedną z dwóch odpowiedzi:

“HTTP request sent, awaiting response… Connection was closed cleanly.”
lub
“HTTP request sent, awaiting response… User timeout caused connection failure.”

Gdzie system rzeczywisty odpowiedziałby tak:

root@ubuntu:/home/kippo/kippo# wget microsoft.com:80
--2014-04-13 12:34:21--  http://microsoft.com/
Resolving microsoft.com (microsoft.com)... 64.4.11.37, 65.55.58.201
Connecting to microsoft.com (microsoft.com)|64.4.11.37|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.microsoft.com/ [following]
--2014-04-13 12:34:21--  http://www.microsoft.com/
Resolving www.microsoft.com (www.microsoft.com)... 65.55.57.27
Connecting to www.microsoft.com (www.microsoft.com)|65.55.57.27|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /pl-pl/default.aspx [following]
--2014-04-13 12:34:22--  http://www.microsoft.com/pl-pl/default.aspx
Reusing existing connection to www.microsoft.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 91113 (89K) [text/html]
Saving to: `index.html'

100%[===================================================================================================================================================>] 91,113      83.1K/s   in 1.1s

2014-04-13 12:34:23 (83.1 KB/s) - `index.html' saved [91113/91113]

Oprócz tego RequestTimeout [408] z reguły wynosi 20 sekund, a jednak emulator wget zwraca tę odpowiedź dużo szybciej.

Timeout logowania

Niedawno został także zgłoszony bug pokazujący, że gdy przy próbie logowania do systemu zostanie wpisana pusta nazwa użytkownika i prompt o hasło to system nie zrywa takiego połączenia, gdzie powinien je zamknąć po upływie około 10 sekund (domyślnie).

Wykrywalność przez MetaSploit Framework

Niestety zgodnie z informacją Toda Beardsley’a Kippo nie podąża za właściwą wymianą sekwencji klucza klienta z serwerem SSH. Przy normalnej próbie połączenia serwer zwraca protokół i wersję, następnie klient odpowiada swoimi wartościami i żąda wymiany kluczy na które żądanie serwer odpowiada. Są one wymieniane używając algorytmu DH i szyfrowane połączenie staje się zestawione. W przypadku Kippo – serwer (emulator) przesyła przedwcześnie pakiet Key Exchange Init tym samym zaburzając sekwencję. Może to zostać sprawdzone np. za pośrednictwem aplikacji Wireshark. Gotowy moduł Metasploita nazywa się ssh_version.rb i znajduje się w msf3/modules/auxiliary/scanner/ssh/ (smutek.).

Zalety używania Kippo

Kippo przede wszystkim daje chwilę czasu reakcji na próbę włamania i rekonesans z kim mamy do czynienia. Wprawny włamywacz prawdopodobnie bardzo szybko wykryje honeypot, lub wręcz go ominie, jednak takie rozwiązanie odstrasza script-kiddies oraz młodych, niedoświadczonych black-hat hakerów. Niesamowitą wartością dodaną jest analiza logów z linkami wget, gdzie dla administratora może być to prawdziwa podniecająca skarbnica wiedzy do skryptów. Sam log również może uczyć w jaki sposób mogą odbywać się ataki do jego serwera. Administrator może się czynnie uczyć reagować na zagrożenie. Oprócz wymienionych argumentów, skrypt playlog.py daje niesamowitą frajdę i emocje z oglądania.

Bibliografia

• http://code.google.com/p/kippo/
• http://en.wikipedia.org/wiki/Kippo
• http://bruteforce.gr/kippo-graph
• https://www.alertlogic.com/attacking-kippo/
• http://calebcoffie.com/category/isf/stuff-found-on-my-honeypot/
• http://code.google.com/p/kippo/source/browse/trunk/utils/playlog.py?r=194
• http://prezi.com/wwuskkot4nhs/detecting-medium-interaction-honeypots/
• http://www.behindthefirewalls.com/2014/02/ssh-honeynet-kippo-kali-and-raspberry-pi.html

–Tomasz Turba