Mossack Fonseca Breach – WordPress Revolution Slider Plugin Possible Cause

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!

Comments

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

  • Unbelievable.
    Thank you for sharing.

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

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

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

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

  • 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

  • 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

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

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

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

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

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

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

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

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

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

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

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

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

  • Good read. So many sites effected by that plugin.

    Further discussion on HN.

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

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

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

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

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

  • I think that the word is: unbelievable!

    Thanks for sharing.

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

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

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

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

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

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

  • 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).

  • Great analysis!

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

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

    • Hi Alex,

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

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

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

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

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

      • Thanks, Mark. Understood.

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

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

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

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

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

  • 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

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

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

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

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

  • 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!

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