Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Tsunami – nowy skaner sieciowy autorstwa Google
Tsunami – to nowy skaner sieciowy opublikowany przez Google w zeszłym miesiącu. Sebastian Lekies, jeden z pracowników Google, zajmujący się automatyzacją wyszukiwania podatności, opisał go w następujący sposób:
We just open sourced the Tsunami security scanning engine. Tsunami is a false-positive-free scanner focusing on actively exploited, high severity security vulnerabilities. Feel free to reach out to us for questions. (cc @magl22, @paradoxengine) https://t.co/XahkdLhxq2
— Sebastian Lekies (@slekies) June 18, 2020
W skrócie: Tsunami to skaner używany wewnętrznie w Google, którego celem jest:
- Identyfikacja podatności o wysokim poziomie istotności (mniej interesują nas więc takie kwestie, jak np. ujawnienie banera wersji danej usługi),
- Skupienie na podatnościach wykorzystywanych w realnym świecie,
- Całkowite wyeliminowanie false positive’ów (czyli zgłoszeń skanera, które później okazują się fałszywe).
Z dłuższego opisu narzędzia na blogu Google, dowiemy się, że proces skanowania składa się z dwóch kroków:
- Rekonesans – czyli identyfikacja otwartych portów i działających na nich usług. Tsunami nie odkrywa tutaj koła na nowo i pod spodem wykorzystuje
nmap
. - Werfyikacja podatności – na bazie zdobytych wcześniej informacji, Tsunami próbuje zaatakować daną usługę pluginami, które do niej pasują. Weryfikacja podatności odbywa się prawdziwym (choć niegroźnym) exploitem.
W obecnie upublicznionej wersji, Tsunami ma detektory tylko do dwóch klas podatności:
- Upublicznione wrażliwe interfejsy aplikacji – pewne aplikacje, takie jak np. Jupyter czy Jenkins domyślnie wystawiają interfejs użytkownika, który nie wymaga logowania i pozwala na wykonywanie dowolnych poleceń systemu operacyjnego.
- Słabe dane logujące – wykrywane dla takich usług jak SSH, FTP, RDP czy MySQL.
W jednym z miejsc Google twierdziło, że używa Tsunami wewnętrznie, więc na pewno muszą korzystać z dużo większej liczby pluginów niż te, które obecnie zostały ujawnione. Zapytałem o to na Twitterze i Sebastian Lekies potwierdził, że kolejne pluginy są planowane, choć nie podał żadnego terminu.
Yes, we have plans to release more plugins. There are also a few other orgs who are interested in contributing additional plugins. Stay tuned :-)
— Sebastian Lekies (@slekies) July 9, 2020
Tak czy owak, postanowiłem spróbować zmierzyć się z tsunami
i zobaczyć, jakie daje wyniki.
Instalacja Tsunami
W celu uruchomienia Tsunami, przygotowałem maszynę wirtualną z Debianem 10 (Busterem). Pierwszym krokiem jest instalacja zależności:
apt update apt install openjdk-11-jdk nmap ncrack git curl
Tsunami jest napisane w Javie, stąd wymóg openjdk
; nmap
jest używany pod spodem do skanowania portów; ncrack
to z kolei narzędzie używane do wykrywania słabych danych logujących, a git
i curl
potrzebne były do pobrania wszystkich danych i kompilacji.
Kompilacja Tsunami to z kolei wykonanie polecenia w Bashu;
bash -c "$(curl -sfL https://raw.githubusercontent.com/google/tsunami-security-scanner/master/quick_start.sh)"
Poniżej umieszczam Asciicast z procesu instalacji, który u mnie trwał ok. dwie minuty. W tym procesie nie dzieje się wiele interesującego, ale może się przydać osobom, które same chcą zainstalować tsunami i rozwiązać ew. problemy.
Uruchomienie Tsunami
Na samym końcu procesu instalacji, Tsunami wyświetliło informację, w jaki sposób można je uruchomić do przeskanowania localhosta:
cd /root/tsunami && \ java -cp "tsunami-main-0.0.2-SNAPSHOT-cli.jar:/root/tsunami/plugins/*" \ -Dtsunami-config.location=/root/tsunami/tsunami.yaml \ com.google.tsunami.main.cli.TsunamiCli \ --ip-v4-target=127.0.0.1 \ --scan-results-local-output-format=JSON \ --scan-results-local-output-filename=/tmp/tsunami-output.json
Uruchomiłem więc na swoim komputerze Jupyter Notebook (do której detektor ma Tsunami) i włączyłem skaner, by zobaczyć jak sobie poradzi z identyfikacją błędu i jak dokładnie działa. Poniżej asciicast:
Poniżej zaś wklejony wynikowy JSON:
{ "scanStatus": "SUCCEEDED", "scanFindings": [{ "targetInfo": { "networkEndpoints": [{ "type": "IP", "ipAddress": { "addressFamily": "IPV4", "address": "127.0.0.1" } }] }, "networkService": { "networkEndpoint": { "type": "IP_PORT", "ipAddress": { "addressFamily": "IPV4", "address": "127.0.0.1" }, "port": { "portNumber": 8888 } }, "transportProtocol": "TCP", "serviceName": "http", "software": { "name": "Tornado httpd" }, "versionSet": { "versions": [{ "type": "NORMAL", "fullVersionString": "6.0.4" }] } }, "vulnerability": { "mainId": { "publisher": "GOOGLE", "value": "JUPYTER_NOTEBOOK_EXPOSED_UI" }, "severity": "CRITICAL", "title": "Jupyter Notebook Exposed Ui", "description": "Jupyter Notebook is not password or token protected" } }], "scanStartTimestamp": "2020-07-09T11:48:53.923Z", "scanDuration": "79.755s", "fullDetectionReports": { "detectionReports": [{ "targetInfo": { "networkEndpoints": [{ "type": "IP", "ipAddress": { "addressFamily": "IPV4", "address": "127.0.0.1" } }] }, "networkService": { "networkEndpoint": { "type": "IP_PORT", "ipAddress": { "addressFamily": "IPV4", "address": "127.0.0.1" }, "port": { "portNumber": 8888 } }, "transportProtocol": "TCP", "serviceName": "http", "software": { "name": "Tornado httpd" }, "versionSet": { "versions": [{ "type": "NORMAL", "fullVersionString": "6.0.4" }] } }, "detectionTimestamp": "2020-07-09T11:49:16.146Z", "detectionStatus": "VULNERABILITY_VERIFIED", "vulnerability": { "mainId": { "publisher": "GOOGLE", "value": "JUPYTER_NOTEBOOK_EXPOSED_UI" }, "severity": "CRITICAL", "title": "Jupyter Notebook Exposed Ui", "description": "Jupyter Notebook is not password or token protected" } }] } }
Kilka moich spostrzeżeń:
- Tsunami wypisuje bardzo dużo informacji na wyjściu, dzięki czemu dokładnie wiadomo co aktualnie się dzieje. Widać też, że na początku został uruchomiony
nmap
, a późniejncrack
do łamania haseł do SSH. - Skan trwał ok. 1,5 minuty, co jak na hosta mającego dwie otwarte usługi, nie jest genialnym wynikiem.
- W obecnej wersji narzędzia fingerprinting najwyraźniej nie działa zbyt dobrze, bo w końcowym fragmencie wyjścia widać np., że plugin sprawdzający czy na danym porcie jest wystawiany WordPress został… uruchomiony na porcie 22 (SSH).
- Najpewniej Google wewnętrznie korzysta z innego narzędzia, które przetwarza wyniki zwracane przez Tsunami, bo format JSON nie jest najwygodniejszy, jeśli chodzi o czytanie wyników.
Podsumowanie
O ile ideały idące za Tsunami są moim zdaniem słuszne (tylko poważne podatności + 0 false positives), o tyle obecnie wydana wersja ma bardzo skromne możliwości i raczej nie wniesie zbyt wiele do procesu skanowania hostów w naszych sieciach.
Myślę, że jednak warto mieć to narzędzie na oku, bowiem jestem przekonany, że Google ma w zanadrzu dużą liczbę dodatkowych wtyczek, które będą wyszukiwały o wiele większe spektrum podatności w przyszłości. Na razie odkładam Tsunami na półkę i czekam na więcej :)
— Michał Bentkowski, (@SecurityMB) haker w Securitum
OK, skupianie się na poważnych podatnościach spoko, ale ignorowanie medium lvl może prowadzić do vuln chaining i co wtedy? Wlłaśnie dlatego automatyczne skanery zawsze będą niewystarczające.
Ciekawe czasy nastały. Kiedyś takich narzędzi trzeba było szukać po jakiś ciemnych forach gdzie każdy oskarżał się nawzajem o bycie skryptowym dzieckiem i pilnował swoich sekretów jak złotych klejnotów.