Account MySQL "root" @ "localhost" non protetto a cui si accede da remoto?

Un po 'di storia: abbiamo appena hackerato il nostro sistema PBX. Il server stesso sembra sicuro (nessun accesso alla console non autorizzato registrato - SSH ecc.), Ma in qualche modo gli hacker sono riusciti a iniettare un nuovo utente amministratore nel software PBX (FreePBX, supportato da MySQL). I registri di Apache implicano che gli hacker sono riusciti ad aggiungere l'utente senza utilizzare l'interfaccia Web (o alcun exploit nell'interfaccia Web).

Ora, da allora ho scoperto che MySQL era in esecuzione senza una password di root (!!) e si associava apertamente all'indirizzo IP esterno (ovviamente, l'ho bloccato ora). Tuttavia, l'unico utente di livello root in MySQL era 'root'@'localhost'e 'root'@'127.0.0.1', entrambi i quali avrebbero dovuto essere accessibili solo localmente.

Quindi, la mia domanda è questa:

Esiste un modo per falsificare una connessione a MySQL in modo da consentire la connessione all'utente 'root' @ 'localhost' da un indirizzo IP remoto, SENZA eseguire altri exploit a livello locale?

Per riferimento, la scatola è Centos 5 (Linux 2.6.10) con Mysql 5.0.95.

mysql security hacking

— TFK
fonte

Sarebbe più adatto a ServerFault - offtopic qui.

— Kapa,

Non ero sicuro - la mia sensazione personale era che, dato che riguarda meno i problemi di configurazione / amministrazione del server e più il tentativo di sfruttare un potenziale bug in MySQL, potrebbe adattarsi meglio qui. Mi scuso se la gente pensa che io sia sul sito / sezione sbagliata per questo.

— TFk,

In realtà, probabilmente appartiene a security.stackexchange.com

Dici "l'unico utente a livello di root era root @ localhost", tuttavia c'erano altri utenti? Non è necessario un utente di livello root per aggiungere un record. Inoltre, dovresti cercare vulnerabilità in FreePBX come questa .

— Marcus Adams,

L'exploit nel tuo link è stato corretto nella mia versione di FreePBX, ma sì, sono d'accordo che le vulnerabilità di FreePBX sono il punto di accesso più probabile, tranne per il fatto che non riesco a trovare nulla nei miei registri di accesso di Apache coerenti con alcuna delle vulnerabilità (senza patch) conosciute . Un buon punto con altri utenti: l'unico altro utente nel db era l'asterisco, che ha una password (non predefinita). Se questo era il punto di ingresso, questo indica nuovamente una vulnerabilità (probabilmente non rilasciata) di FreePBX. La "nessuna password di root" sembrava un buco così grande, rispetto a un nuovo exploit FreePBX non documentato. Quindi, la mia domanda / post.

— TFk,

Risposte:

No.

MySQL non accederà mai a un utente con le specifiche dell'host localhosto 127.0.0.1se non provieni dal sistema locale. Si noti che ciò copre anche la vulnerabilità del bypass di autenticazione, CVE 2012-2122; il confronto password potrebbe essere ingannato, ma il confronto host non lo è.

Avresti bisogno di qualcosa sul sistema per eseguire il proxy per "ingannare" il controllo dell'host di origine. Mi viene in mente qualcosa come phpmyadmin o un bilanciamento del carico come HAProxy in esecuzione davanti alla porta TCP MySQL.

— Shane Madden
fonte

Questo è quello che sospettavo, il che significa che, siccome è una password di root vuota, probabilmente non era l'exploit. Sempre bravo a ricevere opinioni informate - Mille grazie.

— TFk,

Il nome rootè creato per impostazione predefinita ed è molto noto. Il valore letterale root non ha alcun significato nel sistema dei privilegi di MySQL. Quindi non è necessario continuare con il nome utente root.

Dovresti cambiare rootil nome utente in qualcos'altro in modo che il mondo esterno non sia in grado di identificarlo (indovinarlo) facilmente, questo ridurrà i tentativi di hacking.

Ad esempio: se hai un utente come root@ localhostche è abbastanza noto a tutti quindi gli hacker proveranno a collegarlo, dovresti cambiarlo in qualcosa di specifico come admin_db_name@ localhostper una migliore sicurezza.

Monitora una variabile di stato chiamata Aborted_connectsperiodicamente per conoscere la Refusedconnessione al tuo server MySQL, dovrebbe essere 0 dopo il Flush status;comando e non dovrebbe aumentare ulteriormente.

mostra lo stato come "Aborted_connects";

— Mahesh Patil
fonte

Fa "no registrato un accesso non autorizzato" includono fallire login tentativi? In caso contrario, potrebbe essere CVE 2012-2122 .

[...] durante l'esecuzione in determinati ambienti con determinate implementazioni della funzione memcmp, (MySQL) consente agli aggressori remoti di bypassare l'autenticazione autenticandosi ripetutamente con la stessa password errata, il che alla fine fa sì che un confronto token abbia esito positivo a causa di un controllo errato valore di ritorno.

— samuirai
fonte

Il mio "accesso non autorizzato non registrato" era terribilmente ambiguo - intendevo dire che nessun aggressore era riuscito a ottenere l'accesso alla console al server (ad esempio tramite SSH). Inoltre, sembra che le build di Centos non siano interessate (< community.rapid7.com/community/metasploit/blog/2012/06/11/… ), ma sicuramente il tipo di cosa che stavo cercando.

— TFk,