Drupal 7: attacco nei log

Question

Drupal 7: attacco nei log

#1 da (5 voti)

6

Nei miei registri di Drupal 7 vedo voci come:

http://example.com/?q=file/ajax/name/%23value/form-tkSDwR6W66a8vR_AIDxAzwMVklkjTkNMjf8SEqfTX8Q

Ci sono diverse voci come questa, con solo l'ultima stringa modificata.

È di un utente non autenticato.

Ho provato ad accedere anche all'URL e ottengo il seguente:

[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","themename":{"topoptiontext":"Page selection"},"ajaxPageState":{"theme":"themename","theme_token":"xxxxxx"}},"merge":true},{"command":"insert","method":"replaceWith","selector":null,"data":"\u003Cdiv class=\u0022messages error\u0022\u003E\n\u003Ch2 class=\u0022element-invisible\u0022\u003EError message\u003C\/h2\u003E\nAn unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (128 MB) that this server supports.\u003C\/div\u003E\n","settings":null}]

Nella precedente voce del registro ho rimosso il nome del mio tema e sostituito il toke con xxxx Immagino che l'aggressore non sia riuscito a entrare.

Il mio sito è aggiornato all'ultima versione 7.58

Dovrei preoccuparmi di ciò? C'è qualcosa che dovrei fare per impedirlo?

Grazie mille

drupal

posta MMT 18.04.2018 - 21:49

fonte

1 risposta

Leggi altre domande sui tag drupal

Come il Meterpreter carica i moduli? Protezione di un processo da utenti locali

score 5 · Accepted Answer

Questo sembra parte di un tentativo di sfruttare CVE-2018-7600 alias SA-CORE-2018-002 , la vulnerabilità che è stata corretta in Drupal 7.58 (e 8.3.9, 8.4.6 e 8.5.1). Questo era ampiamente exploited nel momento in cui questa domanda era chiese.

Se avevi già un Drupal completamente rattoppato allora non eri vulnerabile a questo attacco. Tuttavia, Drupal 7.58 è noto per essere vulnerabile a un attacco simile, quindi è necessario assicurarsi di aggiornare alla versione più recente, se non lo si è già fatto.

Generalmente chiunque usi Drupal dovrebbe assicurarsi di mantenere sia core Drupal che eventuali moduli e temi che usano (questo è vero per tutto il software). Drupal pubblica i suoi annunci sulla sicurezza, insieme a informazioni su come ricevere una notifica quando diventano disponibili, al link .

Se hai siti Drupal che sono ancora non patchati, vedi link .

Se sei interessato, puoi aggiungere $conf['sanitize_input_logging'] = TRUE; al tuo file settings.php (su un sito completamente rattoppato) per abilitare la registrazione aggiuntiva dei tentativi rilevati per sfruttare questo problema. Inizierai quindi a visualizzare i messaggi relativi a "Chiavi potenzialmente pericolose rimosse ..." nel registro di controllo quando viene rilevato un tentativo di exploit.

L'attacco originale (per Drupal 7) è diviso in due parti. La prima parte invia una richiesta elaborata a una pagina con un modulo, solitamente il modulo di reimpostazione della password, per memorizzare un valore speciale in una cache; il secondo richiede l'URL / file / ajax ... in modo da indurre l'API del modulo di Drupal a interpretare erroneamente il valore memorizzato nella cache e ad eseguire il codice contenuto al suo interno. La prima richiesta è quella che verrà disinfettata dalla correzione in Drupal 7.58. Il secondo è ciò che vedi nel registro qui. (La correzione aggiuntiva in Drupal 7.59 aggiunge ulteriore sanitizzazione per entrambi). Il valore casuale è la chiave della cache, nota in Drupal parlance come ID della build della forma.

Immagino che un exploit di CVE-2018-7602 possa sembrare simile, anche se l' annuncio sembra indica che questo non è utilizzabile da un utente non autenticato, e in ogni caso i dettagli non erano pubblici al momento.