msgbartop
Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
msgbarbottom
Loading site search ...

Weak Passwords and Tainted WordPress Widgets

   01 Mar 12   Filed in Website exploits

A few days ago I investigated a hack where the following script was injected into web pages:

<sc ript src="hxxp://www .copytech .lu/js/java.js"></script>

The script was at the very top of the HTML code and in the middle of the page. It was a WordPress site so I suggested to check the index.php and theme files for the malicious code.

The topmost script was indeed in the theme’s index.php file. But theme files didn’t contain the script that I found in the middle of web pages’ HTML code.

Sidebar Widgets

When I compared the code of the theme and the HTML of web pages, it became clear that the script was a part of a sidebar widget (stored in a database). I asked the webmaster to check code of theme widgets in WordPress admin interface (Appearance -> Widgets) — the malicious script was found at the bottom of one widget.

This sort of WordPress widget injection is quite uncommon, so I needed to figure out how the attackers managed to inject the malicious code into WordPress database.

Initially, I had two hypotheses:

  • The attackers logged into WordPress admin interface and modified the widget code (but where did they get the credentials?)
  • They used a backdoor script (web shell) to get the database password (from wp-config.php) and then used SQL commands to inject the code directly to a database (standard feature of many web shells)

I asked the webmaster to change passwords of all WordPress users to prevent attacks via the first scenario and requested to provide site’s access logs so that I could try to find suspicious requests [to backdoors].

Log Analysis

The logs analysis revealed a few interesting things:

1. I found a few unsuccessful attempts to exploit known vulnerabilities in WordPress plugins (e.g. timthumb.php/cropper.php, 1-flash-gallery) but there were no successful requests to anything that looked like a backdoor. — So, it looks like the backdoor scenario was incorrect.

2. Multiple POST requests to /wp-login.php from various IPs from all around the world. Many of them were consecutive. Some IPs requested this URL hundreds of times in a short period. — This looks like a distributed brute-force attack — someone tried to guess WordPress login/password.

3. And finally, I found a session that seems to be the answer:

Someone from Brazil (IP 201.0.108.40), logged into WordPress (on the first attempt)

201.0.108.40 - - [16/Feb/2012:14:51:11 -0700] "GET <removed>.com/wp-login.php HTTP/1.1" 200 2256 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
...
201.0.108.40 - - [16/Feb/2012:14:51:16 -0700] "POST <removed>.com/wp-login.php HTTP/1.1" 302 - "http://<removed>.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
...
201.0.108.40 - - [16/Feb/2012:14:51:16 -0700] "GET <removed>.com/wp-admin/index.php HTTP/1.1" 200 44602 "http://<removed>.com/wp-login.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

then used a theme editor to modify the index.php file in the current theme

201.0.108.40 - - [16/Feb/2012:14:51:37 -0700] "GET <removed>.com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme HTTP/1.1" 200 34802 "http://<removed>.com/wp-admin/theme-editor.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
201.0.108.40 - - [16/Feb/2012:14:51:48 -0700] "POST <removed>.com/wp-admin/theme-editor.php HTTP/1.1" 302 - "http://<removed>.com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
201.0.108.40 - - [16/Feb/2012:14:51:49 -0700] "GET <removed>.com/wp-admin/theme-editor.php?file=/home/<removed>/html/wp-content/themes/<current-theme>/index.php&theme=Current+Theme&a=te&scrollto=0 HTTP/1.1" 200 35009 "http://<removed>.com/wp-admin/theme-editor.php?file=/themes/current-theme/index.php&theme=Current+Theme&dir=theme" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

and then modified some widget in that theme

201.0.108.40 - - [16/Feb/2012:14:52:16 -0700] "GET <removed>.com/wp-admin/widgets.php HTTP/1.1" 200 88903 "http://<removed>.com/wp-admin/theme-editor.php?file=/home/<removed>/html/wp-content/themes/current-theme/index.php&theme=News+Magazine+Theme+640&a=te&scrollto=0" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
...
201.0.108.40 - - [16/Feb/2012:14:52:33 -0700] "POST <removed>.com/wp-admin/admin-ajax.php HTTP/1.1" 200 1692 "http://<removed>.com/wp-admin/widgets.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

It all took less than two minutes. So that visitor definitely knew the WordPress admin password (only administrators can edit themes) and was only interested in modifying the index.php and some widget — the places where the malicious code was found later. And these were the only two minutes that the IP 201.0.108.40 worked with the site (at least during the two weeks that I had access logs for).

By the way, the webmaster told me that a few WordPress users, including the user with an administrative role, used “123456” as their passwords — no wonder the attackers managed to figure out the passwords.

That’s probably the first time I come across a massive attack that tries to guess WordPress admin credentials and then use them to modify current themes.

Most probable scenario

Hackers use brute force attacks to guess logins/passwords of WordPress blogs (I saw signs of similar attacks in access logs of some other sites too).

Once they find a working combination, they log into the compromised blogs and use a theme editor to inject a malicious code into theme files (usually index.php) and then use a widget editor to inject the same malicious code into “text” widgets (that allow raw HTML code).

Other sites involved in the attack

Then I checked a few other affected sites (the “copytech .lu” scripts) and they all were WordPress blogs with scripts injected at the very top of the HTML code and in the widget sections (if blogs used widgets). Moreover, I found a few other malicious scripts injected by this attack. e.g.

<sc ript src="hxxp://halldor .is/_inf/G3.js"></script>

Here are some typical messages that you can find on Safe Browsing diagnostic pages of the affected sites:

Malicious software is hosted on 3 domain(s), including halo8.com/, fafonseca.com.br/, copytech.lu/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including copytech.lu/, clasingsky.com/.

and

Malicious software is hosted on 1 domain(s), including infcom.it/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including halldor.is/, gesotim.org/.

The malicious scripts are usually intermediaries that simply load other malicious scripts from different sites. For example:

  • hxxp://gesotim .org/_inf/index.php?action=iframe
  • hxxp://www.clasingsky .com/img/_inf/index.php?action=iframe

It’s easy to notice that all those malicious scripts are loaded from compromised legitimate websites. Hackers use this trick more and more. They place their malicious files in subdirectories of hacked web sites. So it’s always a good idea to regularly scan your servers for unwanted files.

Webmasters

The only principle of website security that knows literally every webmaster and site owner is to use passwords that other people don’t know and can’t easily guess. However, this attack shows that many bloggers still don’t bother using strong passwords.

I’d like to use this chance to remind some password management best practices:

  1. Use strong passwords (not “123456”, not “qwerty”, not some common word or names) — attackers use automated tools to try hundreds (if not thousands) new combinations every day. Here are a couple of approaches to choosing strong passwords:
  2. Regularly change passwords
  3. Don’t use the same passwords for different services and on different sites.
  4. Use password managers like KeePass or LastPass so that you don’t have to memorize every password (you still need to remember a master password and it should be strong).
  5. Don’t use easy to guess user names. It’s another layer of your security, so “admin” and “administrator” are the worst possible user names for site administrators.
    For WordPress users: Your WordPress administrator’s user name should NOT be admin – it’s too easy to guess. If you still have the “admin” user, create a new administrator user with a different login and then remove the “admin” user.

That’s the bare minimum that every webmaster should know about passwords.

##
Your comments are welcome!

Similar posts:

How to choose a strong password – simple tips for better security

Reader's Comments (4)

  1. |

    Would just like to add that there are many fine plugins which restrict bots and human hackers from guessing at passwords as well.

    User Locker is my favorite, though quite a few others work just as well (your mileage may vary).

    Enjoy!
    Jim Walker, The Hack Repair Guy

  2. |

    Very interesting read. Just to clarify; am I right in thinking just users with administrator access are vulnerable to this sort of attack, not editors or users with a lower level of access?

    • |

      As far as I understand, only administrators can change widgets. And only admins can use Theme and Plugin editors to change source code of theme and plugin files.

  3. |

    User Locker is useless, i installed it on my company blog and this still got hacked :(