Updates on CyberSecurity, WordPress and what we're cooking in the lab today.

Mossack Fonseca Breach – WordPress Revolution Slider Plugin Possible Cause

This entry was posted in General Security, WordPress Security on April 7, 2016 by Mark Maunder   54 Replies

Update: We have written a follow-up post on how an attacker may have moved laterally on the network from WordPress into the email server.

Mossack Fonseca (MF), the Panamanian law firm at the center of the so called Panama Papers Breach may have been breached via a vulnerable version of Revolution Slider. The data breach has so far brought down the Prime Minister of Iceland and surrounded Russian President Putin and British Prime Minister David Cameron with controversy, among other famous public figures. It is the largest data breach to journalists in history, weighing in at 2.6 terabytes and 11.5 million documents.

Forbes have reported that MF was giving their customers access to data via a web portal running a vulnerable version of Drupal. We performed an analysis on the MF website and have noted the following:

The MF website runs WordPress and is currently running a version of Revolution Slider that is vulnerable to attack and will grant a remote attacker a shell on the web server. 

Viewing this link on the current MF website to a Revolution Slider file reveals the version of revslider they are running is 2.1.7. Versions of Revslider all the way up to 3.0.95 are vulnerable to attack.

Mossack Fonseca running vulnerable Revolution Slider

 

It appears that MF have now put their site behind a firewall which would protect against this vulnerability being exploited. This is a recent change within the last month.

Looking at their IP history on Netcraft shows that their IP was on the same network as their mail servers.

Screen Shot 2016-04-07 at 9.58.56 AM

ViewDNS.info further confirms that this was a recent move to protect their website:

Screen Shot 2016-04-07 at 10.09.51 AM

According to service crawler Shodan, one of the IP’s on their 200.46.144.0 network runs Exchange 2010 mail server which indicates this network block is either their corporate network or at the very least has a range of IT assets belonging to the company. We also show they’re running VPN remote access software.

You can view the IP addresses used for email for MF below which are all on the same network block:

Screen Shot 2016-04-07 at 10.01.52 AM

To summarize so far:

  • We’ve established that they were (and still are) running one of the most common WordPress vulnerabilities, Revolution Slider.
  • Their web server was not behind a firewall.
  • Their web server was on the same network as their mail servers based in Panama.
  • They were serving sensitive customer data from their portal website which includes a client login to access that data.

A theory on what happened in the Mossack Fonseca breach:

A working exploit for the Revolution Slider vulnerability was published on 15 October 2014 on exploit-db which made it widely exploitable by anyone who cared to take the time. A website like mossfon.com which was wide open until a month ago would have been trivially easy to exploit. Attackers frequently create robots to hit URLs like : http://mossfon.com/wp-content/plugins/revslider/release_log.txt

Once they establish that the site is vulnerable from the above URL the robot will simply exploit it and log it into a database and the attacker will review their catch at the end of the day. It’s possible that the attacker discovered they had stumbled across a law firm with assets on the same network as the machine they now had access to. They used the WordPress web server to ‘pivot’ into the corporate assets and begin their data exfiltration.

Technical details of the vulnerability in Revolution Slider

This is a brief technical summary from one of our analysts describing the nature of the vulnerability in Revolution Slider that was exploited.

Revolution Slider (also known as Slider Revolution) version 3.0.95 or older is vulnerable to unauthenticated remote file upload. It has an action called `upload_plugin` which can be called by an unauthenticated user, allowing anyone to upload a zip file containing PHP source code to a temp directory within the revslider plugin.

The code samples below point you to where the specific problem is in revslider. Note that the revslider developer is allowing unprivileged users to make an AJAX (or dynamic browser HTTP) call to a function that should be used by privileged users only and which allows the creation of a file an attacker uploads.

Screen Shot 2016-04-07 at 10.31.37 AM

A demonstration of Revolution Slider being exploited

The following video demonstrates how easy it is to exploit the Revolution Slider vulnerability on a website running the newest version of WordPress and a vulnerable version of Revolution Slider.

Conclusion

As a courtesy we have reached out to Mossack Fonseca to inform them about the Slider Revolution vulnerability on their site and have not yet received a response. They appear to be protected against it being exploited, or perhaps re-exploited in this case but the WordPress plugin on the site still needs updating.

To protect your WordPress installation it is critically important that you update your plugins, themes and core when an update becomes available. You should also monitor updates for security fixes and give those the highest priority. You can find out if a WordPress plugin includes a security update by viewing the changes in the “Changelog”.

In this case the site owners did not update for some time and it resulted in world leaders being toppled and the largest data breach to journalists in history.

Update: 7 April at 3:52 PST – We should add that one of the firm partners has confirmed that the data was exfiltrated through a hack. There seemed to be some confusion about whether this was an inside job or a hack. Source: BBC News.

Did you enjoy this post? Share it!


Your rating:

54 Comments on "Mossack Fonseca Breach – WordPress Revolution Slider Plugin Possible Cause"

Henry MIller April 7, 2016 at 12:10 pm • Reply

If this is true ....... it would make me so happy. Rev slider brings down presidents!!!

Roy April 7, 2016 at 12:14 pm • Reply

Unbelievable.
Thank you for sharing.

Trevor Nelmes April 7, 2016 at 12:23 pm • Reply

As tech support manager at a major WP theme framework and a popular premium plugin (2 jobs), I get to see the admin screens of a LOT of WordPress sites. 90% are NOT up-to-date regarding updates. The versions of PHP and MySQL I see are positively ancient. I rarely see a sign of any security (all my sites have Wordfence and more).

The trouble is, if I thought by encouraging admins to keep their sites secure, we wouldn't have seen this leak, I would be quite upset. As an old, cynical man, ALL politicians are crooks and deserve this. Roll on yet more leaks. I have no money to hide, so I don't care.

Troubling times. I am pulled in two directions.

Kirsty April 8, 2016 at 2:26 am • Reply

You're nearly spot-on. We run a website monitoring solution across a large number of Magento, Drupal & Wordpress sites. 85% run out of date software.

Ralph April 7, 2016 at 12:39 pm • Reply

SO, it works both ways! Hacking isn't always a bad thing...

Kev Russell April 7, 2016 at 12:50 pm • Reply

Too true Trevor. Governments dictating to businesses around the world screaming for transparency and the leaders of said governments cannot practice what they preach. I have no sympathy for any of those who have found their stashes unearthed. Where I come from that's called karma ! Oh how the mighty fall..

Manik April 7, 2016 at 12:54 pm • Reply

So funny! What one plugin update could do :D ... Good that I use wordfence to alert me, I don't want to be reason to bring down world economy :D :D

Victoria April 7, 2016 at 1:03 pm • Reply

Great marketing!!! Love it! You all saved us when a Slider Revolution breech shut us down. Now ALL our sites and the sites of our customers use Wordfence. I tell everyone I know. To see the number of attacks we avoid daily is ridiculous...it's a no brainer... "use protection". ;D ;D

Jamas April 7, 2016 at 1:13 pm • Reply

This really puts the "Revolution" in that slider. I would imagine that Revolution Slider came bundled with a premium theme they paid for. Unless the theme developer issued updates then it was up to them to pay for a plugin license. Thinking about the money that was floating around this company and they were too cheap to pay $7 license fee.

Thanks for the interesting analysis.

George Iovchev April 7, 2016 at 1:14 pm • Reply

Glad to read this article, very useful information about WP security issues. Will consider using Wordfence on my website.

Mike Schinkel April 7, 2016 at 1:35 pm • Reply

Your title implicates WordPress and a plugin while not shining a light on the bad practice of hosting a website on the same network as an email server amongst other concerns.

Too many people are going to read this with a takeaway of "WordPress=BAD." And that is not fair. What IS bad is self-hosting websites on poorly secured networks and not updating software when security holes are found.

Jacob April 8, 2016 at 1:08 am • Reply

Plugins and theme authors in the WordPress world are mostly mediocre. Well, this is generally true in the software industry.

mark April 8, 2016 at 2:15 am • Reply

I think developers are all human. So the trick is to put processes in place to try and catch our human errors.

Gonzalo April 7, 2016 at 1:36 pm • Reply

Thanks for sharing this info. Fortunately I have all my plugins update and my slider revotion version is 5.1.6.

Trevor Nelmes April 8, 2016 at 1:10 am • Reply

5.1.6? The latest version is 5.2.4. Maybe not quite so up-to-date?

Trevor Nelmes April 8, 2016 at 1:12 am • Reply

In fact, looking at my server, it is just updating to a yet newer version released today.

Tony April 7, 2016 at 1:39 pm • Reply

I am reblogging this post - incredibly important to keep your WordPress website, theme and plugins updated. I use WordFence and VaultPress and recommend these plugins to my students. Thanks for sharing.

ryan April 7, 2016 at 1:48 pm • Reply

In the video the demonstration shows the ability to traverse the directory tree up to the web root. But isn't that where you'd be stopped? With just basic server permissions setup that user, the www-data or whatever, shouldn't be able to go past the root of the site it's setup for right? Or am I missing something. So yes they can take a site down or whatever, but as far as accessing more data outside of the web root that seems a bit more difficult.

mark April 7, 2016 at 3:23 pm • Reply

Hi Ryan,

Excellent question. Once you hack into a WordPress site using (for example) a vulnerability in a plugin, you have the same access level to the server as the user and group the web server execute as. So in many cases that is user and group www-data and that's the case in the example video.

So if the attacker hacked into MF via revslider, they have access to the box as www-data.

That means the attacker has access to everything the web server has access to. If the only thing the web server has access to is it's own data files and a database containing nothing interest, that's no big deal. Not in this case.

In the case of MF, they made client data accessible via a web interface to their customers. That means a web server had access to client data. So, as per my explanation above, all they had to do was break into the web server as www-data or whatever user the web server ran as and they have client data.

That is one of the reasons we think this attack vector is a likely candidate for how the data was stolen from Mossack Fonseca.

The second reason we think it's a likely candidate is because the wordpress server when the hack occurred was on the same network their mail server and several other corporate services were. This includes an Exchange 2010 server and some VPN gear. Once they gained access to the box hosting WP, it may have given them access to an internal network, or alternatively allowed them to access IP's and ports on the public facing network that are blocked if you're an outsider. I summarized this in the post as 'pivoting' but hopefully this goes into a bit more depth explaining what I was talking about. They could have for example, used an Exchange 2010 vulnerability to gain access to email which would have given them access to things like 'forgot password' functionality to gain further access.

For a list of Exchange vulnerabilities, see here.

So in my opinion their either gained initial access via Drupal or WordPress. Then I think the most likely scenario is they just took the data right off the web server because that client portal sounds like it had full access to client data to do it's job. Or they pivoted via another vector and got it that way.

It is 2.6TB of data and that would have taken a while. But the actual breach happened a year ago - that data was only recently released, and so they may have exfil'd the data over several weeks or months.

Hope that helps.

Mark.

ryan April 8, 2016 at 5:30 am • Reply

I think this really illustrates the importance of separation of concerns with server permissions. Like how some test in a Red-Red-Green way. Server setups when dealing with client information should at minimum be setup in the same way. Lock-Lock-Access. Lock everything down and only open what the user, even server users need. This obviously is more geared toward sites who manage their own VPS or racks. I could be mistaken but I believe that's how Plesk sets up servers. Every webspace runs under it's own system user which can only go to the vhost root and no further.

However, if I'm following you correctly, even if the vhost runs under a user (web), which can only access up to the vhost root. An exploit in a plugin could allow a script to be run as www-data or what is typically a user for Apache/Nginx thus bypassing all of that? Aside from keeping plugins updated, is there a way to lock those system users down?

Thanks for the write-up and response. I've gone down deep in the SSL/TLS rabbit hole and my servers score an A+ from ssllabs but I know that's not everything so I'm always interested in learning more about how a pinhole of a vulnerability becomes a hydrant of opportunity for the bad guys.

Peter April 7, 2016 at 1:48 pm • Reply

Good read. So many sites effected by that plugin.

Further discussion on HN.

https://news.ycombinator.com/item?id=11449750

Daryl April 7, 2016 at 1:56 pm • Reply

Outstanding analysis. Bringing home the important point of updating plugins and having a top notch security product protecting your site. MF saved a lot of money not having an in-house WP admin, but it cost them dearly in the long run. Pay now and respect your system or don't, get hacked and see your world collapse. I actually didn't believe an organization on the level of and having the resources of MF could have actually really be breached, but apparently nobody on staff is WP literate, and they not could predict, nor anticipate a monolith breach of their system through a plugin in their CMS. This is a story to memorialize and remember to protect your CMS and if you use plugins make sure they are updated, if you don't want to update them, for whatever reason, you run the risk of being hacked. BIg thanks to WORDFENCE that I have on my site and for the important alert.

James Ledesma April 7, 2016 at 2:05 pm • Reply

Great article! This just proves that securing and updating your website is so vitally important. You put a lot effort and money into starting an online business and sacrificing your website's security, would be the most idiotic thing and webmaster could ever do. It should always be priority in the maintenance of a site.

Xun Xi April 7, 2016 at 2:34 pm • Reply

It was an inside job.! Stop the speculative forensic audit and attempt to peddle this as a fact and source of the leak

mark April 7, 2016 at 3:42 pm • Reply

One of the partners have confirmed it was a hack. Source: BBC http://www.bbc.com/news/world-latin-america-35975503

Rafa April 7, 2016 at 2:42 pm • Reply

I think that the word is: unbelievable!

Thanks for sharing.

James April 7, 2016 at 7:56 pm • Reply

For a company as big as Mossack Fonseca, you would expect them to have their data seriously locked down. Surely they didn't have all of these records connected and exposed in this manner but if hackers knew how valuable their data was then they would become targets.

Ervin April 7, 2016 at 11:31 pm • Reply

Giving direct access to sensitive client data to an open web application without proper authentication and validation is a very bad idea. Client data should be served on a need-to-know basis and only release what is requested. A proper implementation would be a protected API interface which only releases data to the request and only pieces of data the requesting person has been granted access to. Per request api keys and authorization tokens, validation.
And as it has been written: It is a very bad practice to place the website on the same network with other vital company assets. They could have put the Wordpress site and the Client interface on a cloud service, and retrieve data from the company assets via API requests.
So what they tried to obfuscate via legalese, they've lost to a seemingly `very` transparent network infrastructure.

Theo April 8, 2016 at 12:11 am • Reply

Thank you for the great analysis. Storing huge amounts of client data and not thinking about basic security, bad practice.

Ejvind Jacobsen April 8, 2016 at 12:47 am • Reply

Thanks for a thorough article. It is becoming more and more obvious that even socalled professional hosting providers don't know what they are talking about, or they are negligent to their clients needs.
It may be because it is too difficult to explain what might happen if you don't protect yourself from security breaches, since it could be resulting in any number of things. But this example really shows how little it takes to wreak havoc. So if nothing else, this case provides a perfect example of how bad it can get.

Ivan Ivanov April 8, 2016 at 1:04 am • Reply

Why all wordpress plugins are not updating automatically? In any way every plugin should be always updated. Why we need to manually update everything. Everone suppose that these updates are for good and for improvements.

Paul April 8, 2016 at 3:28 am • Reply

Nice article and a few interesting comments.

I'm curious to know in what way you believe a firewall would protect against this vulnerability being exploited.

Stefan M April 8, 2016 at 4:00 am • Reply

Am I correct in assuming the vulnerability is specific to the Wordpress plugin versions?

From what I've read (here and elsewhere), it appears that it relates to upload functionality in the WP plugin rather than the core JavaScript slider code itself.

Having rushed to check our sites- I recognised the name- it turned out that the version I remembered using wasn't for our WP installation, but part of a theme on our (non-WP) ecommerce site.

That version appears to be almost all client-side with no reference to "upload" in the JavaScript. Thus, I'm *assuming* it's probably safe...? (Not strictly a WP issue, but I guess it's nice to keep it clear).

Ramiro April 8, 2016 at 5:06 am • Reply

Great analysis!

Hoofy April 8, 2016 at 5:22 am • Reply

Thanks for an interesting read. Almost as interesting are the people surprised by the lack of security. This shouldn't be surprising as the vast majority of companies, from the biggest multi-nationals down to small enterprises, do not invest anywhere near enough in security. Until they do stuff like this will continue on a very regular basis.

Alex April 8, 2016 at 7:47 am • Reply

Are those who install the most recent version of Revolution Slider still vulnerable to attack?

Bruce Jackson April 8, 2016 at 11:06 am • Reply

Hi Alex,

This security issue was closed in 2014! Recent versions are NOT vulnerable to this attack.

Thomas April 8, 2016 at 11:10 am • Reply

Ok, lets stop pointing fingers here. The issue isn't Revolution Slider or WordPress, it's the site owners.

Quote from article: "Versions of Revslider all the way up to 3.0.95 are vulnerable to attack"

According to Revolution Slider's website, version 4.0.6 was released on November 14th 2013. Someone isn't updating anything, ever. They're just asking to be compromised.

Brian April 8, 2016 at 11:20 am • Reply

Great article. It makes me wonder at point the hackers fully realized what they got their hands on. If it was just a random fishing expedition, I imagine it would take some pretty deep investigation before realizing this needs to be released to a consortium of investigative journalists. Maybe they knew what they were hunting after all. A premeditated attempt at MF and sniffed out the easiest vulnerability.

Alan April 8, 2016 at 11:54 am • Reply

Unbelievably, their WordPress server still allows directory browsing. It shows all sorts of pdf files that may or may not be public anyway, but remarkably, they have stored a zip file [removed by moderator for security reasons] of what appears to be a dump of a previous website - perhaps what WordPress replaced:

[link to mossfon.com also removed by mod for security reasons. Yes, dir browsing still works for the uploads dir]

The sql file contains the user names, email addresses and md5-encrypted passwords of 17 logins. All but four of those md5 passwords are easily discoverable in seconds: they are things like [also removed by moderator for security reasons]. I hope they're not using the same logins on their new site...

mark April 8, 2016 at 12:56 pm • Reply

Hi Alan.

Sorry I had to edit the guts out of your comment, but some of it is 0day and I wanted to protect the mossfon folks. Whether or not we agree with their business model, I want to make sure that we don't provide an opportunity for a further breach.

We're aware of the additional data and the dump but chose to keep that private.

Mark.

Alan April 9, 2016 at 2:24 am • Reply

Thanks, Mark. Understood.

Chris Haas April 8, 2016 at 12:31 pm • Reply

Just a quick note, after reading this post I scanned all of my sites looking for a file called release_log.txt and found one that maxed out at version 2.2. However, with a little more digging I found that starting in either version 3 or version 4 they started writing changelog information to a different file, release_log.html, but kept the original text file. Version 5 does not have the text file anymore. So presence of the text-based changelog file alone does not guarantee that you are running the old version of the plugin. In my case I found I was running 4.6.5 and although I wasn't vulnerable I still bought the upgrade to 5.2 just to be safe.

mark April 8, 2016 at 12:52 pm • Reply

Hi Chris,

Interesting. I just checked with our analyst and as some commenters have noted, you can (could?) browse the servers directories. We saw the revslider files were dated 2013. Since we published this they've removed revslider and looks like they've disabled directory browsing for at least some parts of the server.

Regards,

Mark.

Klaus April 8, 2016 at 2:12 pm • Reply

http://www.mossfon.com/wp-login.php

Eric Nelson April 9, 2016 at 9:02 pm • Reply

So their login page into their Wordpress site isn't even protected or done over an https connection. Remember login credentials are sent as cleartext over http. Wow, for a company that handled trillions of dollars in assets you would think they could have hired even one information security analyst.

Eric_Nelson April 10, 2016 at 6:30 pm • Reply

So their login page into their Wordpress site isn't even protected or done over an https connection and thus login credentials are sent as cleartext over http. Wow, for a company that handled trillions of dollars in assets you would think they could have hired even one information security analyst.

webtart April 9, 2016 at 5:04 am • Reply

Why not run a script like this?
#!/bin/bash
blog[1]=mossfon.com
blog[2]=wordfence.com
blog[2]=web-tart.co.uk
for a in 1 2 3;
do
echo “Giving ${blog[$a]} an Upgrade”
cd ${blog[$a]}
wp core update
wp db optimize
wp plugin update-all
wp theme update-all
cd ..
done
exit 0

Saddam Hossain April 10, 2016 at 8:20 am • Reply

Great learning from this article. What I don't understand is, why they didn't take initiative to secure it more after that hack? Thanks for the informative article.

Farcas Gelu Danut April 10, 2016 at 11:21 pm • Reply

I can not believe how much neglect can exist in a company that uses such sensitive information!

Francis Kim April 10, 2016 at 11:50 pm • Reply

Thanks for the detailed post, I'll be passing it on to my fellow WordPress devs.

knightrideruk April 12, 2016 at 1:34 am • Reply

What very few commentators are not mentioning is who is going to be the biggest loser not I fear Mossack Fonseca but WordPress itself. Even if it can be proved it was not WordPress itself but a plugin will make little difference. WordPress needs some sort of automatic update for all updates classed as a security risk (similar to windows 10) at least then if the site WP admins forgot, didn't know or were plain uninterested the system would not of been left compromised. Maybe WordFence or similar plugin should be made mandatory on all new WordPress downloads.

Karl April 13, 2016 at 1:12 am • Reply

This is a classic case of neglecting WordPress technical maintenance, updates and security.

It's not on everyones priority list and should be. There is no excuse for not having a sound plan in place to lockdown a site and update on a frequent basis.

Unfortunately it's a task that tends to be put off for another day, as there is always something more "important" to do, there isn't. It should either be done in house or outsourced, as long as it's done!

Winoto April 14, 2016 at 11:32 pm • Reply

Nice info for web developer like me to gain security & protect web asset.

Get the latest WordPress security updates and news

Sign up for WordPress security alerts, Wordfence product updates and security news via email.