I had a client who got hacked recently and I noticed that there were weird characters appearing on her site, like à and Ã. It turns out that the hackers changed the blog_charset to UTF-7 in the wp_options table in the database. I set it back to UTF-8, but I was wondering if during the time it was set to UTF-7, could that create any security vulnerabilities?
I did some searching and discovered there used to be a WordPress UTF-7 vulnerability that was fixed in version 2.0.6. We’re running the most recent version of WordPress, so they couldn’t have used that exploit, but are there any other exploits related to UTF-7? Really, is there any reason the hackers would change the blog_charset other than to be a pain? I’ve been trying to determine how they got in and I’m wondering if this is connected somehow.
<and>are encoded as+ADw-and+AD4-in UTF-7. Now imagine the following:Someone sends
+ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-as comment text. It will pass all sanitation unescaped.The database expects and treats all incoming data as UTF-8. Since all UTF-7 streams are valid UTF-8 too, this will never result in a SQL error, and
mysql_real_escapeorhtmlspecialcharswill not touch it.WordPress sends a header
text/html;charset=utf-7.WordPress displays the comment, expecting escaped data. But since this is treated as UTF-7 by the browser the JavaScript will be executed.
So, yes, it is a security problem.
UTF-7 is not supported by all browsers, most will render the text as Windows-1252 (or whatever is the default encoding on their OS) or as UTF-8.
The main problem is: escaping will not work anymore.
Just changing the encoding value back is not a solution. A regular visitor can never change it, so you have to find the open door.
Also, it might be needed (re-converting all the encodings of your tables):
https://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8