OpenSSH – enumeracja użytkowników – CVE-2018-15473

Wprowadzanie

Podczas testów bezpieczeństwa infrastruktury często stajemy przed zadaniem przetestowania bezpieczeństwa serwera SSH. Jednym z podstawowych testów jest sprawdzenie odporności na ataki brute-force. W atakach tego typu znajomość poprawnych nazw użytkowników w znacznym stopniu zwiększa prawdopodobieństwo sukcesu – zamiast sprawdzać wszystkie możliwe kombinacje potencjalnych nazw użytkowników i haseł, sprawdzamy poprawność haseł tylko dla istniejących użytkowników. Jednym ze sposób na uzyskanie listy poprawnych nazw użytkowników jest enumeracja, która w dużym uproszczeniu sprowadza się do wykorzystania błędu serwera uwierzytelniającego w celu weryfikacji czy dana nazwa użytkownika jest poprawna. Jeżeli serwer uwierzytelniający pozwala na enumerację nazw użytkowników, atak brute-force możemy rozbić na dwa etapy:

1. Listę potencjalnych nazw użytkowników filtrujemy odpytując serwer o poprawność danej nazwy
2. Listę istniejących nazw użytkowników używamy do przeprowadzenia właściwego ataku brute-force

Z uwagi na popularność serwera OpenSSH postanowiłem przeanalizować kod serwera pod kątem podatności na enumerację nazw użytkowników. Analizie poddana została najnowsza (na dzień 2018.07.18) wersja OpenSSH 7.7p1.

Szczegóły techniczne

Plik auth2-pubkey.c zawiera kod implementujący uwierzytelnienie za pomocą klucza:

static int
userauth_pubkey(struct ssh *ssh)
{
    Authctxt *authctxt = ssh->authctxt;
    struct passwd *pw = authctxt->pw;
    struct sshbuf *b;
    struct sshkey *key = NULL;
    char *pkalg, *userstyle = NULL, *key_s = NULL, *ca_s = NULL;
    u_char *pkblob, *sig, have_sig;
    size_t blen, slen;
    int r, pktype;
    int authenticated = 0;
    struct sshauthopt *authopts = NULL;

    if (!authctxt->valid) {
        debug2("%s: disabled because of invalid user", __func__);
        return 0;
    }
    if ((r = sshpkt_get_u8(ssh, &have_sig)) != 0 ||
        (r = sshpkt_get_cstring(ssh, &pkalg, NULL)) != 0 ||
        (r = sshpkt_get_string(ssh, &pkblob, &blen)) != 0)
        fatal("%s: parse request failed: %s", __func__, ssh_err(r));
    pktype = sshkey_type_from_name(pkalg);

W przypadku, gdy próba uwierzytelnienia odbywa się dla nieistniejącego użytkownika warunek sprawdzany w linii 101 jest spełniony w rezultacie serwer kończy proces uwierzytelnienia (linia 103). W przeciwnym przypadku, gdy nazwa użytkownika jest prawidłowa, proces uwierzytelnienia jest kontynuowany.

Linie 105-107 zawierają kod odpowiedzialny za parsowanie pakietu SSH. Jeżeli nastąpi błąd parsowania następuje awaryjne zakończenie procesu (wywołanie funkcji „fatal” w linii 108). Na tym etapie analizy możemy założyć, że „łagodne” (linia 103) i awaryjne (linia 108) zakończenie procesu uwierzytelnienia powinno być, z perspektywy klienta SSH, jednoznacznie rozróżnialne.

W celu opracowania sposobu na awaryjne zakończenie procesu przeanalizujmy funkcję „sshpkt_get_string” (packet.c):

int
sshpkt_get_string(struct ssh *ssh, u_char **valp, size_t *lenp)
{
  return sshbuf_get_string(ssh->state->incoming_packet, valp, lenp);
}

W linii 2521 wywoływana jest funkcja „sshbuf_get_string” (sshbuf-getput-basic.c):

int
sshbuf_get_string(struct sshbuf *buf, u_char **valp, size_t *lenp)
{
    const u_char *val;
    size_t len;
    int r;

    if (valp != NULL)
        *valp = NULL;
    if (lenp != NULL)
        *lenp = 0;
    if ((r = sshbuf_get_string_direct(buf, &val, &len)) < 0)
        return r;

W linii 107 wywoływana jest funkcja „sshbuf_get_string_direct” (sshbuf-getput-basic.c):

int
sshbuf_get_string_direct(struct sshbuf *buf, const u_char **valp, size_t *lenp)
{
   size_t len;
   const u_char *p;
   int r;

   if (valp != NULL)
       *valp = NULL;
   if (lenp != NULL)
       *lenp = 0;
   if ((r = sshbuf_peek_string_direct(buf, &p, &len)) < 0)
       return r;
   if (valp != NULL)

W linii 134 wywoływana jest funkcja „sshbuf_peek_string_direct” (sshbuf-getput-basic.c):

int
sshbuf_peek_string_direct(const struct sshbuf *buf, const u_char **valp,
   size_t *lenp)
{
   u_int32_t len;
   const u_char *p = sshbuf_ptr(buf);

   if (valp != NULL)
       *valp = NULL;
   if (lenp != NULL)
       *lenp = 0;
   if (sshbuf_len(buf) < 4) {
       SSHBUF_DBG(("SSH_ERR_MESSAGE_INCOMPLETE"));
       return SSH_ERR_MESSAGE_INCOMPLETE;
   }
   len = PEEK_U32(p);
   if (len > SSHBUF_SIZE_MAX - 4) {
       SSHBUF_DBG(("SSH_ERR_STRING_TOO_LARGE"));
       return SSH_ERR_STRING_TOO_LARGE;
   }
   if (sshbuf_len(buf) - 4 < len) {
       SSHBUF_DBG(("SSH_ERR_MESSAGE_INCOMPLETE"));
       return SSH_ERR_MESSAGE_INCOMPLETE;
   }

Funkcja wykonuje walidację wartości typu „string”, sprawdzana jest między innymi długość danych (linia 165) – długość nie może być większa niż SSHBUF_SIZE_MAX – 4 .

Stała SSHBUF_SIZE_MAX  zdefiniowana jest w pliku sshbuf.h:

#define SSHBUF_SIZE_MAX 0x8000000 /* Hard maximum size */

W tym momencie uzyskaliśmy sposób na zmuszenie funkcji „sshpkt_get_string” do zwrócenia błędu – wysłanie wartości typu „string” o długości większej niż 0x8000000 – 4 .

Wróćmy do analizy funkcji „userauth_pubkey” (auth2-pubkey.c):

static int
userauth_pubkey(struct ssh *ssh)
{
   Authctxt *authctxt = ssh->authctxt;
   struct passwd *pw = authctxt->pw;
   struct sshbuf *b;
   struct sshkey *key = NULL;
   char *pkalg, *userstyle = NULL, *key_s = NULL, *ca_s = NULL;
   u_char *pkblob, *sig, have_sig;
   size_t blen, slen;
   int r, pktype;
   int authenticated = 0;
   struct sshauthopt *authopts = NULL;

   if (!authctxt->valid) {
       debug2("%s: disabled because of invalid user", __func__);
       return 0;
   }
   if ((r = sshpkt_get_u8(ssh, &have_sig)) != 0 ||
       (r = sshpkt_get_cstring(ssh, &pkalg, NULL)) != 0 ||
       (r = sshpkt_get_string(ssh, &pkblob, &blen)) != 0)
       fatal("%s: parse request failed: %s", __func__, ssh_err(r));
   pktype = sshkey_type_from_name(pkalg);

W linii 107 następuje próba odczytania wartości typu „string”. Wysłanie wartości o długości większej niż 0x8000000 – 4  powinno spowodować, że funkcja „sshpkt_get_string” zwróci błąd, a w rezultacie nastąpi awaryjne zakończenie procesu (linia 108). Warto wspomnieć, że wysłane dane nie muszą mieć długości większej niż 0x8000000 – 4 , tylko zadeklarowany rozmiar (przesyłany w osobnym polu) musi przekraczać dozwoloną wartość.

W celu wysłania spreparowanego pakietu SSH, który zawiera „string” z odpowiednią długością zmodyfikuję bibliotekę paramiko. Paramiko to implementacja protokołu SSHv2 napisana w Pythonie (https://github.com/paramiko/paramiko). Zachęcam do modyfikacji biblioteki we własnym zakresie.

Na bazie zmodyfikowanej biblioteki paramiko napiszmy prosty skrypt do sprawdzenia poprawności nazwy użytkownika:

import paramiko
import sys

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(hostname=sys.argv[1], port=int(sys.argv[2]), username=sys.argv[3], key_filename='./conf/id_rsa', password='', look_for_keys=False)
ssh.close()

Uruchomienie skryptu dla nazwy istniejącego użytkownika (user) kończy się błędem „No existing session”

python2 test.py debian 22 user
[...]
paramiko.ssh_exception.SSHException: No existing session

Natomiast uruchomienie skryptu dla nazwy nieistniejącego użytkownika (asdf) kończy się błędem „Authentication failed.”

python2 test.py debian 22 asdf
[...]
paramiko.ssh_exception.AuthenticationException: Authentication failed.

Różnica w odpowiedzi serwera pozwala jednoznacznie stwierdzić czy użytkownik o danej nazwie istnieje w testowanym systemie.

Na zakończenie warto wspomnieć, że przedstawiony błąd enumeracji oprócz oczywistego wykorzystania w pierwszej fazie ataku brute-force, może zostać również wykorzystany do detekcji oprogramowania zainstalowanego na testowanym serwerze np. wykrycie użytkownika „postgres” sugeruje, że wykorzystywana jest baza PostgreSQL. Idąc dalej istnienie lub brak określonych nazw może sugerować użycie danego systemu operacyjnego.

Podsumowanie

Błąd został zgłoszony do zespołu odpowiedzialnego za rozwój OpenSSH. Z uwagi na fakt, że wersja OpenSSH, która zawiera poprawkę nie została jeszcze opublikowana, natomiast w sieci można znaleźć działający exploit, rekomendujemy wdrożyć następujące kroki w celu ochrony przed atakami typu brute-force:

• jeśli to możliwe należy wdrożyć mechanizm uwierzytelnienia oparty na kluczach
• upewnić się, że konta zabezpieczone są silnymi hasłami
• rozważyć wdrożenie mechanizmów utrudniających przeprowadzenie ataków typu brute-force np. fail2ban

Timeline

16.07.2018 – zgłoszenie błędu do zespołu OpenSSH
18.07.2018 – potwierdzenie błędu przez zespół OpenSSH
31.07.2018 – publikacja poprawki na githubie
15.08.2018 – na bazie publicznie dostępnej poprawki opublikowane zostały, przez niezależnego badacza, szczegóły techniczne błędu  (http://seclists.org/oss-sec/2018/q3/124)
17.08.2018 – przypisany został nr CVE-2018-15473
22.08.2018 – nasza publikacja

Dariusz Tytko, realizuje testy bezpieczeństwa w Securitum