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.