Accesso OpenSSH a un account di sistema

Question

Accesso OpenSSH a un account di sistema

#1 da (2 voti)

1

Durante un normale test di penna per un cliente mi sono imbattuto in una scatola con OpenSSH 7.2p1 in esecuzione.

Attraverso una ricerca su Google ho scoperto questa vulnerabilità con la precedente versione di OpenSSH

Sono andato a indagare ulteriormente. Sono stato in grado di comprendere alcuni dettagli della vulnerabilità e l'exploit stesso. Tuttavia, ho bisogno di aiuto per capire altre cose.

Ho una conoscenza di base di come funziona esattamente SSH. Questo è una risorsa che è molto in sincronia con capendo che ho.

Ora esaminando ulteriormente il problema, da quello che capisco è che sul server X11Forwarding yes è richiesto nel file di configurazione sshd. Poiché ho accesso SSH alla scatola, ho verificato che questa condizione era soddisfatta.

Quindi la mia comprensione al riguardo è che è necessario che un account con la shell impostata su /bin/false o un account utente con comandi forzati sia in grado di dimostrare lo sfruttamento stesso.

Inoltre, in aggiunta, l'utente sopra deve essere già autenticato. (Questa comprensione è corretta?)

Quindi sono entrato nel box e ho cercato di vedere se c'è un utente di questo tipo che soddisfi le condizioni di cui sopra.

Ho fatto un cat /etc/passwd | grep /bin/false e ha estratto un elenco di utenti con la shell impostata su / bin / false. Uno di questi utenti era l'utente denominato mongodb , che aveva la directory home impostata su /home/mongodb e inoltre era protetta da una password come indicato da x nel file passwd .

Ho letto dell'installazione di mongodb e sono venuto a sapere che viene installato con il proprio utente.

Ora qualcosa che ho bisogno di aiuto con la comprensione:

A che cosa serve questo utente di mongodb ? Ho guardato in modo approfondito / home e non sono riuscito a trovare una directory home per questo utente nonostante fosse menzionato nel file passwd.
Come e quando viene autenticato questo utente?
C'è un modo in cui quando questo utente si autentica con il sistema, può essere sfruttato per sfruttare il bug di injection xauth di comando autenticato da OpenSSH?

Per favore perdonami la mia scarsa comprensione degli utenti Linux o SSH e fammi sapere se ci sono risorse che potrebbero aiutarmi a capire meglio queste basi.

linux authentication mongodb exploit openssh

posta qre0ct 22.09.2016 - 13:46

fonte

1 risposta

Leggi altre domande sui tag linux authentication mongodb exploit openssh

Quanto è ben protetto se i dati di fatturazione e fattura dei clienti sono? Confronta gli approcci per abbinare una chiave privata e un certificato

score 2 · Accepted Answer

I sistemi Unix di solito hanno molti account utente per scopi di sistema, usati per un particolare servizio di sistema, ad es. per eseguire un demone particolare. I processi che forniscono quel servizio vengono eseguiti come quell'utente, i file di dati manipolati dal servizio sono di proprietà dell'utente e i file di configurazione sono leggibili da quell'utente (ma normalmente non è scrivibile: root, ovvero l'amministratore di sistema, possiede i file di configurazione ). Questo account mongodb è un caso tipico di una bog: sarebbe proprietario dei file di database MongoDB.

Le home directory non sono davvero utili per la maggior parte degli utenti di sistema. Per gli utenti umani determinano dove le applicazioni cercano i file di configurazione, ma non è una preoccupazione per gli utenti del sistema che eseguono solo un programma specifico che non legge i file di configurazione per utente. La directory home è anche il punto in cui il server SSH cerca le chiavi autorizzate dell'utente, cioè le credenziali aggiuntive che concedono l'accesso all'account, ma la maggior parte degli utenti di sistema non dovrebbe essere loggato e quindi non avrà le chiavi SSH. A volte la home directory è una directory di sistema (ad esempio in /var ), a volte è / , a volte è una directory inesistente, non importa.

Gli utenti del sistema possono avere o meno una shell valida come propria shell di login. Avere una shell valida come /bin/sh consente cose come su mongodb ma in molti casi questo non è necessario e la shell di login è impostata su un programma che non fa nulla , come /bin/false , /bin/true o /usr/sbin/nologin . Questo serve come ulteriore livello di difesa se qualche altra parte della configurazione è fallita e consente all'utente di accedere.

Molti modi per accedere a un account utente eseguono la shell di login dell'utente, incluso SSH (ma anche su , cron, ecc.). Normalmente, con la shell impostata su /bin/false , anche se si è riusciti ad accedere tramite SSH, non sarebbe possibile eseguire nulla. Il bug che hai trovato, CVE-2016-3115 , è dovuto a OpenSSH che esegue l'iniezione di cookie X11 (chiamando xauth ) prima di eseguire la shell di login dell'utente.

Ma per sfruttare questo bug, devi prima passare il primo livello di difesa e accedere all'account mongodb . Ciò non dovrebbe essere possibile: l'account non ha chiavi pubbliche autorizzate poiché la sua home directory non esiste e non dovrebbe avere una password. Avere x nella colonna password di /etc/passwd non indica che l'account ha una password; probabilmente è il caso di tutti i conti. Significa che l'hash della password, se ce n'è uno, è in /etc/shadow .