We're just reporting what we know at this point and what we think is likely. What we know is that their web server had access to _client data_ (the client portal). Two websites had vulnerabilities - both the WP site and the Drupal site. And it is _client data_ that was exfiltrated.
So in my opinion it's highly likely that the client data was taken via either a Drupal or WP attack vector. Even if this beach didn't happen, the client data eventually would have been stolen via one of these vectors. There are thousands of bot scripts that are exploiting revslider every day and so it's inevitable the site would have been hacked repeatedly and someone would have noticed a 2.6TB database that the web server had permission to access.
To illustrate: I've seen scripts running in real-time coming into a honeypot that run 'show databases;' and then dump everything to a .sql file in a public web directory and hit that URL to download. An attacker might have gotten a partial dump and then gone OMG and gone back for seconds... and thirds, and fourths...
I think the use of "reporting" is a stretch.. you're speculating and twisting information in your favor.
You're right, data was exfiltrated... Do we know if the portal was on the same server as the website? You seem to be making that connection, but that hasn't been illustrated.
So if you're opinion is that it was either a Drupal or WordPress attack vector, why not highlight that in your article or subsequent email? Based on your email, you imply it was WordPress but fail to make this point...
OK "truthfinder007" whose account was created 2 hours ago and has karma of 2. I think I've had about enough of what's going on here. Tell your boss I say hi and that he owes me a beer at the next wordcamp. ;-)
At best, this article is amateur hour for WordFence. It's focused on the topmost layers of the OSI model in an ecosystem requiring attention at all layers, from the wire -> up. Don't sell your product as anything more than consumer grade snake oil.
At the top, whether WordPress is secure or not has zero impact on a properly designed network. If a company is dumb enough to use WordPress on internal hosts, they have bigger problems. Add to this, that a properly designed network should have mitigated the chance that a web server be compromised and at least segregate the network and provide access control to sensitive data.
In short, the network was doomed regardless if WordFence was in place or not and it's damned irresponsible for WordFence to suggest they could protect clients from the kind of attack which played out here.
WordFence are a typical WordPress development company, in that they're web developers first, security / network experts when they need to make a sale.... It's consumer grade crap, which is why this article needs to be treated as such.
I should also mention that just because a web server has an outside IP in the same subnet as the mail server pool, doesn't mean it's on the same physical network. It could be on it's own completely separate physical network or segmented via vlans with full access controls in place. If you understood network security you would know how NAT works.
These guys got hacked because they failed on every level of network best practice or even the fundamentals. Taking advantage of this to sell a product which is equally as naive, is as I said, irresponsible if not negligent.
Forgot to mention, the RevSlider exploit used on your demo video will not give full access to the system as you stated. It'll give only access which the web server is currently executing as; www-data has no access beyond the webroot.
So your engaging in FUD as well.
I'm not sure why you've decided that they had no firewall in place before. You're not offering any data to support this other than the clear change in hosting which recently took place. This shows a reaction which is perfectly normal, it shows nothing in terms of firewalls.
All I am seeing is speculation after speculation in your article, with absolutely zero forensic evidence of your claim. You're not even addressing the fact that their Exchange server running an older OWA was running an improperly configured SSL certificate which left SSLv3 enabled, leaving it wide open to DROWN.
I'm also seeing many thanks in your comments, and seeing folks mention buying into your product. What I don't see though is you setting these people straight that WordFence is only a tiny part of a much larger solution and that WordFence would have done absolutely nothing to prevent this breach. I'm also not seeing my comment either, but that's okay.
I respect the work these researchers are doing. But to be blunt: if I had that kind of sensitive data, there is no way I'd even consider having a WordPress on the same network. I'm not a security expert, but I like to think I avoid the most obvious pitfalls. And WordPress strikes me as a security pit the size of a continent and there are many reasonable alternatives.
To be fair, you're pretty much gonna hit trouble if you're using third party plugins and themes for any script. That's because they're made by just about everyone and anyone and often not vetted for security or code quality purposes.
WordPress on its own can be kept moderately secure, as can any other major script in this market. But if you're installing themes and plugins without knowing exactly what they're doing, then you're gonna have security problems regardless of the script. Doesn't matter if its WordPress, Drupal, Joomla, Magento or anything else, third party plugins and themes are usually the weakest part of the site.
Eh, it wasn't WordPress per se, but a plugin. This plugin's vulnerability was also posted YEARS ago. So I wouldn't blame WP (in this case).
As a dev, I've come across plenty of out of date CMS/ modules/ plugins that had huge security holes in them. It's part of the 'build and forget' mentality that seems to be widespread these days.
As much as I'll be the first to say "update your damned plugins" to every Wordpress dev, there's more to it than that.
Revslider is a "premium" plugin, which means you buy the plugin, and then, optionally, ongoing support, which includes updates.
You can logon to Wordpress and there's a big "click here to update all your plugins" button. And you press it, and it will say "you are fully updated now!" or something to that effect.
To update revslider, you're supposed to use your support agreement to logon to the distributor's website, and go download and install an update separately. I've seen dozens of revslider deployments and I've never yet had a developer believe there was anything more to it than pressing the "automatic update" button, which basically lies to you in the case of premium plugins.
I'm perfectly happy blaming Wordpress - because it needs a mechanism of saying "nope, this plugin requires a support agreement. It is however, vulnerable".
No one other than person or people that released that data knows what happened for sure but, one hole in your security that will allow shell access is just as bad as another.
Some are worse than others but, all need to be fixed.
It also illustrates the complexity of security. The smallest decisions (a wordpress plugin), hosting your own wordpress web servers, using wordpress, can have on your security.
Whether you have an open door, an open window or an inside man to unlock it from the inside, they all leave you exposed.
That's only speculation. All Wordfence found is that their site had a vulnerable plugin and they are magically linking that to the compromise. No real forensics there.
I don't think a plugin could have caused this but we never know...
Nonetheless, it highlights very fragile nature of third party plugins. May be Wordpress ought to run some kind of certification program to analyze and certify plugins.
This article is speculative and does the security community a huge disservice. There is nothing interesting about this research, outside of spreading FUD via marketing scamy techniques like using link bait taking advantage of something that has global attention.
Allow me to explain why and how I’ve come to this conclusion:
1 - It all starts with the email they sent out:
“We performed an analysis of MF's network and it seems that the breach may have been caused by an outdated WordPress plugin: Revolution Slider. It turns out that not updating your WordPress plugins may result in the fall of world leaders and the largest data breach to journalists in history.”
I get it, they need people to click...
2 - In the Forbes article they reference, it reads:
“its portal used by customers to access sensitive data was most likely run on a three-year-old version of Drupal, 7.23. That platform has at least 25 known vulnerabilities at the time of writing, two of which could have been used by a hacker to upload their own code to the server and start hoovering up data.”
but of those 25 potential vulnerabilities, the key one according to WordFence was:
“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.”
3 - In the same Forbes article they reference it states:
“In a letter, dated April 1 and posted on Wikileaks’Twitter profile, the firm told customers it was investigating an email server hack.”
So naturally, WordFence needed to connect the dots for the readers:
“Their web server was on the same network as their mail servers based in Panama.”
and here:
“Looking at their IP history on Netcraft shows that their IP was on the same network as their mail servers.”
Got it, they’re on the same network… but nowhere to they describe the process for traversing the network and any potential roadblocks they’d find… but then later after connecting the dots to the mail server, they revert to the data in the portal.. explained later...
4 - They create this video showing how to use a script to exploit the RevSlider vuln. They then type a number of commands to show you how exhaustive the control us:
Commands like:
- ls -la (listing what’s in a folder)
- pwd (showing what directory they are in)
and to really show their control they navigate to /var/www/html (in other words to the same exact directory they’re supposed to have access to under the user they have control of). They then proceed to make statements how “they have full control of the server”. They have control of the web directory which is what they would have access too. To have full access to the server they’d need to show some form of privilege escalation that gives actual control of the server…
The argument the author makes to this point on his blog states:
“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.”
So what's the point of the email reference above, if it was on the web server as they theorize?
Additionally, this only makes sense if the portal was on the same web server. There is no proof that the “portal” is on the same server as the web server. I understand why they didn't, using their own tool they didn't have the information: http://toolbar.netcraft.com/site_report?url=portal.mossfon.c...
If the vector was Drupal, it’d be more realistic that they leveraged a SQLi vulnerability to siphon the data if that was the vector at all… On that same note, if the user was the same web user, how is that known? Because they don’t update their website doesn’t mean they don’t apply basic sysadmin steps.. again, it’s speculative on both side, but that’s the issue when you don’t know enough…
Additionally, this is a lot of data we’re talking about.. It'd be very curious if they managed to store that amoutn of data on a web server and not some form of database server…
5 - In the same video they show how they can see the network cards are attached by using ifconfig… but again show no examples of how that information was used to tunnel into the rest of the environment and how they would have gone about doing something like that…. from their own admission, they show how the mail servers were on the same network, but that itself doesn’t make them susceptible.. there are a number of things that have to happen to be successful… The web server could be on it’s own DMZ, there could be a number of firewalls isolating parts of the network, there could be a number of things….
Additionally, they speculate it was WordPress … the platform for their main website, when in reality Drupal was the CMS used for the client portal.. wouldn’t it be more realistic to think it’d be Drupal where the real data resides?
6 - There are also statements to how attackers work.. using automated scripts to scan websites for potential vulnerabilities like Revsliders… while it’s true… the logic is flawed… these crawlers pull thousands of websites at any given time… a site like “mossfon.com” is not a high value target, unless it’s being targeted.. these scripts are automated, so are most of their attacks which will automatically upload their scripts and payloads… if the lists are scanned they’re looking for valuable targets, unfortunately mossfon.com isn’t one, unless you know what it is… this logic defies reason and understanding of how attacks happen…
In any event, those are my thoughts... unfortunate...
Seeing Wordfence using this to promote their product does not create much confidence.