Condivisioni SMB / CIFS sulle vulnerabilità di HP-UX

2

Quindi, ho eseguito una scansione Nessus non autenticata contro un'infrastruttura critica come parte di un pen-test, ma sto recuperando alcune cose strane e non riesco a ricreare il problema per dimostrarlo al cliente.

La macchina che sto testando è una macchina HP-UX ma Nessus sta segnalando che è possibile accedere a una "condivisione" di condivisione specifica utilizzando una sessione NULL (Nessus plug-inID 42411 ) e che i contenuti della condivisione sono di lettura / scrittura (continua ad elencare il contenuto corretto della condivisione (confermato con l'admin )). Questo sta sfruttando il servizio su TCP 445.

Ora generalmente, se sto provando a stabilire una sessione NULL da un computer basato su Windows a un computer basato su Windows che è vulnerabile eseguirò il seguente comando

C:\> net use \hostname\IPC$ "" /USER:"" 

Quindi posso semplicemente sfogliare le condivisioni semplicemente aprendo un dialogo di esecuzione e andando \ hostname \ e vedo una bella lista. Non così in questo caso. Non riesco a vedere il contenuto della condivisione o nemmeno a aprirlo.

Quindi, ovviamente questa è una macchina HP-UX, il che significa che questo risultato è già un po 'spento, ma in ogni caso, sta ancora vedendo cose che non dovrebbe essere e non so come crea questo. I CVE associati ( 1999-0520 e 1999-0519 ) non sembra contenere alcuna informazione utile sullo sfruttamento di questo. Le sessioni NULL sono un problema di Windows o è un client Samba? Come posso riprodurre questo problema su un computer di test Linux o sul mio computer di test di Windows per dimostrare la vulnerabilità al client?

L'altra vulnerabilità identificata da Nessus è "Samba Symlink Traversal Arbitrary File access" ( Plugin ID 44406 ). Mostra che è in grado di leggere il contenuto di / etc / passwd e che i contenuti sono di nuovo confermati come corretti, tuttavia non sono completamente sicuro su come riprodurlo di nuovo. In base al advisor Samba il problema si verifica quando un client è autorizzato a scrivere in una directory (presumibilmente la suddetta condivisione "di backup") e creare collegamenti simbolici alle risorse locali. Sembra che questo codice dimostrerà il problema.

È corretto che la correzione dell'autenticazione della sessione NULL risolverà il problema di Symlink (almeno per gli autori di attacchi non autenticati)?

    
posta NULLZ 17.02.2015 - 15:16
fonte

1 risposta

1

Assicurati di utilizzare l'account corretto per accedere alla condivisione NULL. Potrebbe essere nobody o smbnull . (Controlla tuo smb.conf file .)

C:\> net use \hostname\backup "" /USER:nobody

C:\> net use \hostname\backup "" /USER:smbnull

Prova anche la condivisione backup anziché IPC$ con il tuo utente vuoto:

C:\> net use \hostname\backup "" /USER:""

Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers?).

Sì, lo aggiusterà per gli attaccanti non autenticati. Per correggerlo per tutti gli utenti, devi impostare wide links su no .

    
risposta data 03.03.2015 - 18:02
fonte

Leggi altre domande sui tag