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:

1. 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.
2. 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:

1. 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.
2. 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ń:

1. 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óźniej ncrack do łamania haseł do SSH.
2. Skan trwał ok. 1,5 minuty, co jak na hosta mającego dwie otwarte usługi, nie jest genialnym wynikiem.
3. 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).
4. 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