SweetCAPTCHA Returns Hijacking Another Plugin

Yesterday we observed a strange short return of the SweetCaptcha plugin to WordPress.org repository.

In June we reported that SweetCaptcha injected third-party ad code to their scripts which lead to malvertising problems on the sites that used this CAPTCHA service. After that incident, the SweetCaptcha WordPress plugin had been removed from the official plugin repository.

To our surprise, we noticed SweetCaptcha in the WordPress repository on July 22 2015. To even greater surprise, the plugin page URL was https://wordpress.org/plugins/jumpple/.

SweetCaptcha revived on wordpress.org/plugins/jumpple/

tldr;

If you don’t have time for this almost detective story, please scroll down to the summary section where you will find the gist of the incident, otherwise, please bear with me.

What’s Going On?

Why does this plugin have a new URL? Probably its authors wanted to return it into the official repository but couldn’t update the once deleted plugin so had to create the same plugin with a new identifier (slug). This was our first thought.

However, a bit of research revealed that a real Jumpple plugin existed on that URL for many years. Google cache shows that on July 22th 2015 08:29:37 GMT that plugin repository page still had information about the original Jumpple Security 1.0.1 plugin which hadn’t been updated for more than 2 years by that moment (actually since July 11, 2012 as you can see on the same cache page).

Jumpple plugin page in Google cache

Don’t be fooled by the SweetCaptcha background image on the above screenshot. Google doesn’t cache images, it uses cached URLs which at that moment already contained the SweetCaptcha background image

background-image: url("//ps.w.org/jumpple/assets/banner-772x250.jpg");

The original Jumpple background can be found here: https://plugins.trac.wordpress.org/browser/jumpple/assets/banner-772×250.jpg?rev=571398

SweetCaptcha and Jumpple. What’s Common?

OK. Our next thought was, “Maybe Jumpple and SweetCaptcha belonged to the same people and they decided to reuse the Jumpple plugin slug (id) to upload the SweetCaptcha plugin?”

To prove this hypothesis, we opened the “www .jumpple .com” site, associated with the original Jumpple Security plugin, and found this strange site about vaporizers, full of spammy SEO links and unintelligible text — definitely not something one expected to see on a site of a security monitoring plugin.

Pure spam on jumpple com

What Happened to Jumpple?

Now the situation looks more intriguing. Let’s figure out what happened to the jumpple site. Was it hacked, hijacked, or … ?

The Wayback Machine shows that this site existed until July 2013 and then stopped responding until December of 2014 when it began returning 404 error pages.

Last snapshot of the original jumpple com back from 2013

DomainTools reports that this domain changed 3 registrars, 9 IPs and 6 name servers. So it looks like the domain name had expired or changed hands and now owned by completely different people, not the plugin developers.

But wait, the DomainsTools service also has this nice feature called Screenshot History. Let’s check the screenshots for jumpple.com. The one from January 2013 looks very interesting;

Look who’s been monitored by Jumpple! 😉

Did you know that back in 2013 eBay, Facebook and Twitter, and other world’s most respected brands trusted Jumpple and were monitored by this service? Neither did I. Well, I can easily imagine that Jumpple monitored twitter.com but probably Twitter didn’t know about it! 😉

OK, let’s forget about the deceiving marketing tricks for now. What’s really interesting is that we can see the SweetCaptcha logo in the same row as Facebook, Twitter and other Internet giants. Why did they include a logo of quite a small and by many orders less popular service there? The only plausible answer I have is Jumpple and SweetCaptcha were somehow affiliated (or may be run by the same people).

Now we can suggest that the choice of the “jumpple” account in the WordPress repository was not random. Most likely it either belongs to SweetCaptcha or to people who know SweetCaptcha very well.

SVN Revision Log

Now let’s see how they managed to replace one plugin with a completely unrelated plugin in the official WordPress.org repository. Since all developers who submit plugins to WordPress.org have to use the public SVN repository, we have a great tool that can show us the full timeline of the jumpple plugin hijacking.

Jumpple SVN revision log

In the revision log, we can see that after 3 years of inactivity, this plugin was updated 4 weeks ago, and then two updates on July 22, 2015 (yesterday).

The first update (June 22, 2015) just changed the supported WordPress version to 4.2.2 in the readme.txt file. That’s it. The commit description is pretty self-explanatory “readme.txt changed – checking if the commit is working“. So it looks like they decided to revive the plugin and tested if they still can update it after such a long time.

Most likely the plugin was not automatically updated because the July cached pages still said “Compatible up to: 3.4.2”, not “4.2.2”. Maybe 2+ years of inactivity flagged the update for a manual review, since normal updates usually take just a few minutes.

From the WordPress Plugin developer FAQ:

I made some changes to my SVN repository. How long will it take for the WordPress.org Plugin Directory to reflect those changes?

The WordPress.org Plugin Directory updates every few minutes. However, it may take longer for your changes to appear depending on the size of the update queue.

I can only guess, but the update was finally approved a few days ago (after all, the change was almost cosmetic and absolutely benign) and whoever-it-was decided to go on and replace the jumpple plugin with the SweetCAPTCHA plugin. You can see it in this large update (July 22, 2015)

They moved jumpple files from trunk/ to tags/1.0.2/. Then copied https://plugins.trac.wordpress.org/browser/sweetcaptcha-revolutionary-free-captcha-service/trunk/ to trunk/ (made the last saved SweetCaptcha code the current version of Jumpple) and removed the jumpple banners from assets/, and then 3 minutes later, uploaded the SweetCaptcha banner to finalize the hijacking.

Apparently, this time the “new versions” appeared on the plugin page almost immediately, since we noticed it there just a couple of hours after the SVN repository update. Now that plugin is in “active development” the updates for the plugin page get approved much faster.

By the way, did you notice the description of the large update? It says:

just testing if the sweetcaptcha is free of ads or not

Isn’t it sweet? Uploading the same version of the plugin to the public repository won’t help determine whether the plugin is free from ads. You don’t have to do it to install the plugin and test it. Moreover, in the case of SweetCaptcha, the ads are loaded directly from the sweetcaptcha.com site (https://www.sweetcaptcha.com/api/v2/apps/csrf/(client_id)?ver=3.1.0) and it depends on that remote script whether the ads are being injected or not, not on the plugin code. And in case you want to know the answer — yes, that script still includes the ad code from “clktag.com/adServe/banners?tid=SWTMPOP&tagid=2″, so site using SweetCaptcha are still at risk of malvertising (or just unwanted ads).

Summary

This is the high level overview of the incident as I see it.

1. On June 9, 2015, after SweetCaptcha was accused of injecting malicious ads into websites that used its CAPTCHA, their plugin had been removed from WordPress.org plugin repository.
2. SweetCaptcha had to offer their plugin as a direct download on their own site which has many down sides comparing to having their plugin in WordPress,org repository (issues with reputation, automatic update notifications, discoverability, etc)
3. They tried to find their way back to the WordPress.org and recalled the almost forgotten Jumpple account of their once affiliated (?) and now defunct service.
4. On June 22, 2015, they made a minor update to the Jumpple Security plugin to test if they could revive it.
5. Due to a long inactivity of the Jumpple plugin development, the update approval took about a month.
6. On July 22, 2015, once the minor update was approved, they replaced the code and assets of the Jumpple plugin with the code and assets of the SweetCaptcha plugin.
7. Since the plugin was no longer “stale” (lost the 2+ years of inactivity warning), this new update was pushed directly to the https://wordpress.org/plugins/jumpple/ plugin page almost immediately.
8. During a few hours that page served the same SweetCaptcha plugin that had been removed from the repository a little more than a month ago.
9. On July 23, 2015, we noticed that the jumpple plugin page was removed from WordPress.org too. I don’t know what exactly happened but hope that although the plugin page was quickly updated after uploading the “new version” of the plugin, it was queued for a more detailed review and when reviewers noticed the hijacking of one plugin by another, they simply removed that plugin from their repository.

If you see any flaws in this scenario or have some additional details, please leave your comment below.

This incident, once again, reminds us about the risks of installing third party software (no matter whether it’s your website, browser, computer or smartphone). You should seriously consider installing software only from trusted official repositories (WordPress plugin directory, Google Play, Apple AppStore, etc) that screen submissions for security issues. Even when you use the official repositories, you should still decide whether you can trust particular developers now and years from now. It’s quite a common scenario when criminals try to hijack or buy developer accounts of legitimate applications, or pay their developers to add some malicious code into their software, so some benign plugin or application may turn bad after an update — the only thing that protects you is the author reputation and the security screening and approval process in the repository.