Se un hacker ha cambiato blog_charset in UTF-7, questo rende WordPress vulnerabile a ulteriori attacchi?


19

Ho avuto un cliente che è stato violato di recente e ho notato che c'erano strani personaggi sul suo sito, come  e Æ. Si scopre che gli hacker hanno cambiato blog_charset in UTF-7 nella wp_optionstabella nel database. L'ho ripristinato su UTF-8, ma mi chiedevo se durante il periodo in cui era impostato su UTF-7, ciò avrebbe potuto creare delle vulnerabilità di sicurezza?

Ho fatto qualche ricerca e ho scoperto che c'era una vulnerabilità di WordPress UTF-7 che è stata risolta nella versione 2.0.6 . Stiamo eseguendo la versione più recente di WordPress, quindi non avrebbero potuto usare quell'exploit, ma ci sono altri exploit correlati a UTF-7? Davvero, c'è qualche ragione per cui gli hacker cambiano blog_charset se non per essere un dolore? Ho cercato di determinare come sono entrati e mi chiedo se questo sia collegato in qualche modo.

Risposte:


23

<e >sono codificati come +ADw-e +AD4-in UTF-7 . Ora immagina quanto segue:

  1. Qualcuno invia +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-come testo di commento. Passerà tutti i servizi igienici senza fuggire.

  2. Il database prevede e tratta tutti i dati in arrivo come UTF-8. Poiché tutti i UTF-7 flussi sono validi UTF-8 anche questo non sarà mai come risultato un errore di SQL, e mysql_real_escapeo htmlspecialcharsnon toccarlo.

  3. WordPress invia un'intestazione text/html;charset=utf-7.

  4. WordPress visualizza il commento, in attesa di dati di escape. Ma poiché questo è trattato come UTF-7 dal browser, JavaScript verrà eseguito.

Quindi sì, è un problema di sicurezza.

UTF-7 non è supportato da tutti i browser, la maggior parte renderà il testo come Windows-1252 (o qualunque sia la codifica predefinita sul loro sistema operativo) o come UTF-8. Il problema principale è: la fuga non funzionerà più.


Il semplice cambio del valore di codifica non è una soluzione. Un visitatore regolare può mai cambiare, in modo da avere a trovare la porta aperta.


Grazie! Incrociano le dita sul fatto che correggere quella voce del database ha chiuso la falla di sicurezza.
Jennette,

Non preoccuparti, ho già intrapreso diverse azioni per chiudere le falle di sicurezza. Non riuscivo proprio a capire come stessero ancora entrando. Niente sembra essere stato violato negli ultimi giorni, quindi speriamo che cambiare la codifica in UTF-8 sia stato l'ultimo passo per chiudere tutti i buchi.
Jennette,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.