19

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.

Improve this question

2 Answers 2

Reset to default
22

< and > are encoded as +ADw- and +AD4- in UTF-7. Now imagine the following:

  1. Someone sends +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4- as comment text. It will pass all sanitation unescaped.

  2. 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_escape or htmlspecialchars will not touch it.

  3. WordPress sends a header text/html;charset=utf-7.

  4. 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.

Improve this answer
2
  • Thanks! I'll cross my fingers that fixing that database entry has closed the security hole.
    – Jennette
    Dec 24, 2012 at 3:22
  • Don't worry, I'd already taken several actions to close security holes. I just couldn't figure out how they were still getting in. Nothing seems to have been hacked in the last few days, so hopefully changing the encoding back to UTF-8 was the final step in closing all the holes.
    – Jennette
    Dec 26, 2012 at 15:17
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.