On February 6, I had written a blog post regarding a possible security breach at BlogVault. Since then we have been conducting a thorough investigation into the issue. We have concluded the investigations. This post outlines its results.
No Data Breached
In our previous communication with you, we had mentioned that there had been a data breach. After detailed investigations, we found that the issue was a vulnerability in the BlogVault plugin, and none of the data on our servers were exposed.
We have ensured to cover every aspect of our system in our investigations, which involved inspecting the logs for our system as well as that of affected and unaffected sites. We also reviewed the attack payload with great detail.
BlogVault Plugin Vulnerability Fixed in Version 1.45
On Feb 4, we learned that we were using ‘unserialize’ PHP function on unverified data in BlogVault plugin versions 1.40 to version 1.44. We fixed it on the same day (Feb 4) with plugin version 1.45.
However, we had assumed the worst, and communicated with our customers the same day about the security issue. Following this, we also made a public announcement about it via a blog post.
Since then, we have thoroughly investigated the issue and analyzed our entire system. We have found that the the above mentioned vulnerability was the only entry point that allowed malware to be injected into sites on which the BlogVault plugin was reachable.
The BlogVault plugin has been secure ever since the updates on version 1.45.
However, we have continued to strengthen the security of our plugin and as of the date on which this post is published, the latest version of the BlogVault plugin is 1.46. If your BlogVault plugin is older than 1.46, we request you to update to the latest version available in the WordPress repository (https://wordpress.org/plugins/blogvault-real-time-backup/ ).
Your data and backups are safe
As mentioned in our previous communication, your backups and data were safe and continue to be safe. They were never at risk. This includes:
Your backups
Your passwords
Your payment details
Please find below the details of the measures we have taken during the investigation to bolster the security of our service:
Preventive Security Measures Implemented
As a reflection of our commitment to security best practices, we have taken a list of preventive security measures during the investigation to ensure that this incident doesn’t repeat itself.
Updates made with versions 1.45, and 1.46 of the BlogVault plugin were a part of the measures to strengthen the security of the plugin.
We have actively scanned all sites to identify websites affected by this issue and to get them cleaned and secure.
We have also pushed an automatic update to the BlogVault plugin on most sites.
Moreover, we have taken and continue to take measures to ensure that neither the BlogVault plugin nor the servers can be exploited.
Your Trust Continues to Be Important to Us
During this period, many of you who have reached out to us via our chat channels, email or even Twitter. We realize that you have not received the level of service on which we pride ourselves, and for this we apologize.
At BlogVault we are committed to being transparent and accountable to you. I know that we had received some questions about details regarding the issue. We were unable to respond to them because we had prioritized the security of the affected sites of our customers. We also wanted to ensure that we would refrain from adding to any speculations and only communicate facts.
We recently discovered a security breach at BlogVault which led to some data being exposed. Here are some details about the issue. We are currently in the middle of an extensive investigation and we will share updates with more detail as and when we learn more about the issue.
We have reached out to all our customers informing them about the situation. We have also set up a ‘Security Updates’ page to be communicative throughout the process. The page also has some FAQs and contact details. Please follow this link for more details: https://blogvault.net/help/info
We understand that it can be frustrating for you; as it is for us, to not have all the information. We aim to be comprehensive in our response to the issue. Once we have safeguarded our customers’ data, and our investigation is complete we will be able to share more details.
Lastly, we have reached out all BlogVault customers and we are deeply moved by the patience and understanding displayed by many of them. We are working round the clock and have prioritized safeguarding your data.
Watching dominoes fall is always fun. And why wouldn’t it be? It’s a harmless, yet mesmerizing display of organized chaos. But if it did represent something harmful, there would be much reason to worry. Cross-site scripting attacks, at their worst, are the dominoes of common website vulnerabilities.
Once dominoes start falling, there’s no stopping them.
Cross-site scripting, generally known as XSS, is a type of Injection attack. It works a little differently from most other attacks, because it in addition to exploiting WordPress websites and their servers, the attack also utilizes web browsers.
How it works in general
Cross-Site Scripting starts out the way most injection attacks (such as SQL Injection) do: by accepting user inputs. An attacker injects malicious scripts into good WordPress sites through a part of the website that accepts users’ inputs (like a comment field). So if an attacker could use, say malicious JavaScript code within “<script>… </script>” tags in the comment section, the code would run on the browser. This would allow the attacker access to any information they can glean from the visitor’s browser, from cookies to saved or entered login credentials.
How to prevent Cross-Site Scripting
There are a few sure ways to prevent XSS attacks on your WordPress site. Some of them include making sure that your:
Web browser makes use of the same origin policy- Web browsers usually have a set of rules, by which one web page is allowed to access script on another only if they had the same origin. If a browser doesn’t check the origin of the script of web pages, it results in a vulnerability that can be used by attackers to inject malicious scripts. This means that users’ browsers would execute the code. All of this is moot though, if one of your website’s visitors uses a browser that doesn’t have this policy… in which case stricter security measures on your site would help.
Website can tell the difference between markup tags and actual content on a page– Websites are vulnerable to XSS attacks when they can’t make out the difference between markup code and content that has to load on its pages. This means that if there were a piece of text, like an equation having the ‘<’ sign, and executable code (containing the <script> tag, the browser would mess them both up. This could be because the developers forgot to implement rules that dictated that “<” signs in text on the web page would be represented as “<”. When this happens, the website is vulnerable.
Website has input validation and sanitization- None of this would happen if the standards of accepting users’ inputs was very high.
Categories of XSS attacks
Cross-Site Scripting is a very complex attack especially because of how it can be categorized. It can be put in buckets, based on the following criteria:
Whether the malicious script (from users’ inputs) is stored-
If the malicious script is stored on the website or browser’s database, the attack is categorised as a Stored (or Persistent) XSS attack.
If it’s reflected to other visitors instead, it’s called a Reflected XSS (or Non-persistent) attack.
Which side accepts unvalidated user-inputs (this categorization overlaps the Stored and Reflected categorisation)-
Server-side XSS attacks
Client-side XSS attacks
Stored (or persistent) XSS Attack
Stored XSS usually occurs when user inputs are taken and stored on a database. In this case, the user is affected because unsafe data is run on the browser. Any attacker could input malicious code on a vulnerable website just once, and it would get stored (persistently) on the server. When any other user accesses the website, they would get affected. The malicious code infects the user’s browser, and retrieves sensitive data, (such as usernames and passwords) for any site the user might use the browser to visit. Here is what a Stored (or Persistent) XSS attack looks like:
Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.
One of the most well-known, real-world examples of this attack, is that of the MySpace worm of 2005. The worm was scripted in JavaScript to be self-propagating. So instead of just affecting people who visited the point of origin of the worm, it affected visitors of the original victims, thus propagating exponentially. Here’s how it loosely worked:
Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours.
This attack is precisely why we compared XSS attacks to dominoes falling.
Reflected (or non-persistent) XSS attack
Reflected XSS attacks are a different thing altogether. They are the most well-known sort of XSS, and can pose a serious threat, if not prepared for. Here’s a general example, to explain how this attack could work:
Reflected XSS is the more well-known sort of XSS attack.
This attack could be used to do anything from launching a DDoS attack (as seen in the above example), to scanning the websites/ profiles/ browsers of every visitor to your website, for vulnerabilities that could later be exploited.
Cross-Site Scripting could use information from any website/web service you use.
The Cross-site Scripting attack is one that has existed for a long time. Unfortunately, until the MySpace worm was created, not many in the realm of internet security took it very seriously. However, according to a report by WhiteHat Security in 2015, even 10 years after the MySpace worm, 47% of all websites are still vulnerable to this kind of attack. This attack relies on user inputs not being validated or sanitised before being processed. So the best way to protect your WordPress website, is to make sure that it doesn’t take your subscribers’ inputs lightly. This obviously means you should make sure that the plugins and themes on your site accepting user inputs validate them first. But even otherwise, choosing an extra security feature can never cause harm. If you’d like to try out a website scanner that is 100% accurate, requires no technical assistance, and also helps you remove hacks, visit MalCare.
Removing malware from your website, and getting rid of hacks is a painstaking process. When you’re a website owner whose site has been hacked, your online reputation takes a hit. It’s only more distressing when you keep getting hacked. The reason behind this, most of the time, is a ‘backdoor’.
Having a backdoor could be explained with some ease, by comparing it to something we could call a “spare-key situation”.
Suppose you had a spare key to your house, but you dropped it somewhere on your street. Someone creepy has found it, and unfortunately for you, this person also knows exactly where you live. Of course you don’t know about it, but you notice changes at home.
Whether all the furniture in your house is gone, or whether the sofa is always a little warmer in the morning depends entirely on what this person with the spare key is doing in your house. This means unless you change your locks or employ other security measures, this stranger has full access to your home, and will keep coming back.
Hackers also do something similar when they hack WordPress sites.
When a hacker exploits a vulnerability and hacks a site, they want to be able to enter it again in the future. They also want to do so, without needing to put in the effort again. This becomes difficult though, if the site owner closes the vulnerability by updating the exploitable theme/plugin. That is why hackers leave behind code called backdoors on the site. This way, even if the vulnerability is fixed, the backdoor remains. Backdoors are inconspicuous, because the longer they stay hidden, the longer the attacker has a way to get back in.
Backdoors can give hackers complete control through Arbitrary Code Execution. One of the most common backdoors is ‘Filesman’. Since it’s feature-rich, it allows hackers to perform a variety of functions. However, there are others too, which might be just three-four words of code, but prove to be equally dangerous.
A lot of the time, backdoors are disguised as WordPress files, and are hidden by the hacker in a place only they know. You, as an admin, could find the file only if you combed through all the WordPress files. This is especially difficult because backdoors can go in so many different places.
Here are a few places backdoors are usually hidden on your WordPress site:
In core WordPress folders: Adding a new file to, or modifying an existing file in a core WordPress folder (e.g. wp-includes or wp-admin or wp-content) can easily go unnoticed. Especially in the wp-includes folder, since it contains every file ever included to the site. This is why we noticed a lot of backdoors here.
In new, innocent-looking folders: Hackers could add hackfiles to new files that look completely innocuous, like ./images/
Plugins and Themes: Not many people bother to check these folders after the plugins/themes have been installed. This makes these folders a perfect target. Moreover, a lot of plugins have their own vulnerabilities. Another way hackers install backdoors, is by adding a new plugin to the site that looks normal, but is actually malware.
Just to give you a general idea, this is how you identify a backdoor (that looks like a plugin file):
These vulnerabilities are sneaky. They can be passed off by a number of malware scanners as legitimate files, because of the way they’re named. This is why it’s so difficult to identify backdoors.
Backdoors are especially infuriating because sometimes hackers choose to leave more than one of them, in many locations. So even if one was discovered, there would be another way in.
Accurate, efficient scanning and hack removal requires time, and technical assistance (which is expensive usually). If you’d like to test the only one-click, automated hack-cleaner that misses nothing, and sounds no false alarms, we suggest that you try MalCare, for free.
Having your website hacked could be compared to having an annoying roommate sometimes. Everything’s a mess, no matter how many times you keep putting things back. Your shampoo, food and other resources are always running out. Thanks to them, shows you’ve never even heard of turn up in your ‘Continue Watching’ list on Netflix… And to top it, none of your friends want to come over any more.
But that’s where the similarities end.
You can always talk things out with a roommate, or probably move out… But hacks have devastating consequences. And there’s no way you can just end the problem by walking out. Your website’s reputation is at stake, and the internet never forgets.
There are a number of reasons hackers attack your WordPress website even when they know nothing about you, or what your site stands for. In fact, most of the time, hackers use crawler bots, like the ones search-engines use, to check the web for sites that exhibit vulnerabilities.
Once they identify weak websites, hackers attack for one of the following reasons:
They want to gain critical information from the website. (This could be any sensitive information, like login credentials)
Modifying your site allows them to serve your visitors malicious content (like viruses, or malicious code that could track your visitor’s cookies)
Defacing a website helps hackers send some sort of message across. These kinds of attacks make up for only a small number of hacks
Your website could be another notch in the hacker’s belt: damaging your website could help them climb ranks in the hacker community
Exploiting your site’s resources could prove to get them some kind of monetary benefit. Stealing your visitors identities and selling them on the web is something a lot of hackers do. Hackers could also try to gain control of your server, in which case they could do anything.
Once an attacker gains control of your server, the amount of power they wield depends only on what they want to do. They could do anything from sending out spam mail, to even deleting your website. In fact, some malware is designed to lock you out of your website until you give in to the hacker’s demands. Malware designed for this purpose, is called ransomware, (for obvious reasons). The data stolen from websites could also be held for ransom. Hackers could declare to release it in case their terms of payment isn’t met. But those are headline-worthy scenarios… What hackers stand to gain by remaining undetected, is a lot more. Undetected hacks mean that hackers could keep siphoning off information, and using it for their own purposes.
In fact, the Netflix scenario we mentioned earlier actually happened earlier this year. Netflix users’ login credentials were stolen after the site got hacked, and then sold on the web. Identity theft is a huge business, and hacks like these thrive on the premise that the website owner isn’t in the know. So even if you’re only a WordPress site owner who has subscribers, you have reason to worry.
It’s been a while since WordPress core has had any vulnerabilities, but plugins and themes are a different story altogether. Developers creating these plugins and themes usually don’t anticipate the exploitation of vulnerabilities… or they build first, and then fix later. But with hackers becoming more and more competent, hacks keep getting more complex, and difficult to identify.
Most vulnerabilities open doorways to other exploits and attacks, each with their own scope of damage. The cumulative damage could be disastrous for you, as a WordPress website owner. Moreover, your site could keep getting hacked because of exploits like Backdoors. They maintain a foothold to your website’s server, and your website.
Having your very own website used to be something reserved for developers once upon a time. All that changed with WordPress, and for the better.
But it’s never over.
Whether you run a small blog with a loyal following or a big ecommerce window, your website is an integral part of your life. It represents your passions and reflects your abilities.
Maintaining a WordPress site involves a lot of time, and work.
Being hacked takes away from you the power to share your best with your readers or customers. In some cases, the damage to your site maybe too deep for you to get your site back up with all the data.
And the worst part is that it looks like a senseless act, especially when your website has no information worth stealing.
This is why we’ve compiled a list that we hope you, a site owner, gain some insight into:
Why hackers hack your site, how hacks cause so much damage, and some common attacks along with real-world examples of those attacks.
While some hacks are aimed at gaining information from your site, most attacks are to accessing your hosting and database servers. If accessed, files on your website’s server could provide to anything from yielding sensitive information, to unlimited access.
Where vulnerabilities are found and how to protect your website
Most vulnerabilities are found in plugins and themes. Keeping them up to date, or deleting ones that you don’t use, is one way you can protect your website, and server.
There are other ways you can keep your website safe though. We’ll talk about them in another post.
The types of hacks
One thing you need to know, is that by knowing the kinds of attacks out there, and parts of your site design you have to pay more attention to, you understand how to stay more secure. However, hacks happen in a number of ways and can be difficult to categorize and understand.
That’s what this two-part series is aimed at helping with. We’ve tried to present a lot of information, in a format that is easy to understand. Hopefully it helps even those of us who aren’t very fluent in code.
In this part, we’re going to talk about:
Arbitrary/Remote Code Execution (one of the most powerful ways to take control of a site)
File Inclusion-
Remote File Inclusion
Local File Inclusion
Injection attacks-
SQL Injection attacks
Cross-Site scripting (XSS) attacks
Backdoors (remember this: it’s how websites keep getting reinfected)
Now that we’ve got all of that out of the way, let’s get down to business.
In an ideal scenario, only trusted code associated with your WordPress site can be run on your site/server. The Arbitrary Code Execution (or Remote Code Execution) exploit though, allows hackers to run unauthorized code on your server. Arbitrary Code Execution is dangerous because it allows attackers to take complete control over the website, or the server it’s hosted on, or both.
How the attack works
Attackers first need to get executable code to your website. Vulnerabilities on your website, like the ones that allow File Inclusion (more on this below) lets them do this. They then run it on your server remotely.
A real-world example of an attack exploiting the Arbitrary / Remote Code Execution vulnerability
WP Super Cache and W3 Total Cache are both plugins designed to cache dynamic WordPress pages in order to reduce the sites’ load times for visitors. Plugins like these sometimes use special tags to differentiate static content from dynamic content. Dynamic content is executed on the server.
The problem with this was that WP Super Cache, and W3 Total Cache had vulnerabilities that could be exploited when websites using them, also used comment fields. You see, these vulnerabilities allowed website’s visitors to post comments with (dynamic) PHP code inside special tags.
Since these special tags were executable, attackers used them to run arbitrary commands, knowing that the plugins would execute them. As a result, the comments would return whatever information the attacker requested.
Note: The next few sections will use the terms ‘remote’ and ‘local’. The best way to explain these terms, would be with reference to the hosting server.
You see, a hosting server is a lot like your computer.
Anything on the computer/ hosting server is local (like a local file, folder, or drive).
Anything from outside the computer/ hosting server (like an external hard disk), would be remote.
Most of the time, attackers need to ‘include’ a hack file to your website’s hosting server before they run it. If the vulnerability on your site allows for the file to be included from a ‘remote’ location, it’s called Remote File Inclusion.
How the attack works
Remote File Inclusion is a type of vulnerability that allows an attacker to request your website to include a remote file, which usually consists of executable code. (PHP files are an example). Once your website processes the request and includes the file to your server, the attacker executes the code remotely. (This is why we explained Arbitrary Code Execution first).
Once the attacker does this, depending on what the included file was created to do, it can cause data-theft, or other serious damage to your site.
A Real-World Example of an attack exploiting the Remote File Inclusion vulnerability
Attackers exploited a vulnerability on the TimThumb plugin to first perform Remote File Inclusion, and then Arbitrary Code Execution. And even when the vulnerability was patched in version 2.0, this plugin was so widely used,that it caused millions of sites to be hacked. Even today, we see hacks because of it.
TimThumb let users import images from image-hosting websites (like flickr.com and imgur.com) and edit them on the fly, especially to make thumbnails. The plugin had a list of trusted websites, and only URLs that came from websites were accepted. This process of allowing access based on a list is called ‘whitelisting’.
The problem with TimThumb though, was that it didn’t check the actual source of the file; only checked for URLs that looked like they came from a trusted website.
Here’s a brief explanation of what the plugin did:
How TimThumb’s vulnerability was exploited and used for Arbitrary Code Execution
Once the plugin accepted URLs that linked to an executable PHP hackfile, the file got included remotely to the website’s server. Attackers could then run it, and cause massive damage.
*Disclaimer: None of the URLs or file names in the example are real; they’re only used to illustrate the example.
b. Local File Inclusion attacks
The Local File Inclusion vulnerability is somewhat similar to Remote File Inclusion, except that it includes ‘local’ files. Attackers could also use this kind of file inclusion as a prelude to executing Arbitrary Code.
How the attack works
This vulnerability allows attackers to access files on the hosting server, that aren’t typically available to the regular visitor. Such files can be used to get admin access, steal confidential data etc.
Let’s say your site allows users to access website files through URL parameters. This is one bad way to have coded your site:
<?php include($_GET[‘file’]); ?>
The logic used to write this command is bad the user can enter any filename into the URL parameter. If your WordPress site has a file with this name, it’ll get executed.
Since our bad code is including files without validation, an attacker can use it to access sensitive files (like passwd file):
Ultimate Member is a WordPress plugin that makes it possible for visitors to your site to sign up and to create user profiles for them. The plugin exhibited a vulnerability in July this year, when it incorporated user-supplied input in the ‘page’ parameter without proper validation. This allowed for anyone who had access to the membership form to retrieve some sensitive information from local WordPress PHP files.
3. Injection attacks
All websites require user inputs, whether it’s for logging in, or even just to go to the next page through a click. When a website allows visitors to enter inputs, hackers can introduce code to attack the website, or its server. Exploits that follow this method, are known as Injection attacks.
There are many different kinds of Injection attacks, but a couple of the most rampant ones include SQL injection (which allows access to your website’s database through MySQL commands or queries), and Cross-Site Scripting.
This Injection attack exploits text fields that allow users’ entries. The reason this attack is so dangerous, is because SQL commands could be used to add, modify or delete data on your WordPress’ database.
How the attack works
Every one of us has seen the WordPress login page– you enter your username and password to access the dashboard.
Suppose your username is ‘admin’ you enter it in the login form.
This input is then looked up in the database to check if such a user exists. The thing is, instead of a valid username, you could also input some SQL code.
Now if, for some reason the website directly used the dangerous SQL while looking up the user, the site could be exploited. Fortunately, core WordPress takes extreme care to make sure that user inputs are sanitized before being used while accessing the database. Various themes and plugins, however, sometimes don’t validate input, thus leading to an exploit.
Image credit: https://xkcd.com/327/
Again, the modifications that could be made to your database are innumerable, and the results depend on what is modified. Here are a couple of a generic examples of how an attacker could carry out SQL injection, and why it would be dangerous:
Here’s another example of SQL injection (this time in code)… Suppose we input ‘admin’ in the following code:
The following code would be executed:
So just imagine what would happen if you entered:
(cue: violin screech from Psycho)
This goes to show you need to have a lot of checkpoints to make sure your plugins are safe. You can never be sure enough.
*Disclaimer: Again, code in the example above isn’t something you could execute. It’s just there for illustrative purposes.
A couple of real-world examples of attacks exploiting the SQL injection vulnerability:
1. Booking Calendar is a WordPress plugin that was used for making online reservations based on availability. Unfortunately, just a couple of days ago, an SQL injection vulnerability was discovered on this plugin. The vulnerability allowed an attacker to view data from websites’ servers’ databases. Fortunately, the vulnerability was revealed to the developers of the plugin before anyone else, and they fixed it in an update.
Note: If you’ve got this plugin installed in a theme, or it’s on your website as a standalone plugin, we ask that you update it immediately.
2. Yoast SEO is one of the most popular SEO plugins for WordPress with over a million installs.
Versions before 1.7.3.3 had a SQL vulnernability issue. This issue existed in spite of the plugin actually taking measures to protect against SQL Injection. This was because the authors of the plugin made use of a WordPress function called ‘esc_sql()’, which opened a doorway for the vulnerability. So the plugin wasn’t foolproof.
Cross-site scripting usually affects web applications, when user inputs are directly included as part of web pages.
How the attack works
Web browsers usually have a set of rules to make sure they’re safe from attacks like Cross-Site Scripting. Those that don’t have such rules in place though, have vulnerabilities that allow hackers to inject malicious Javascript.
This means if you’re an admin of a WordPress site, attackers could use XSS to get access to your cookies, or login information, or even just change the content on your site, without you even knowing it. Your sites’ visitors seeing that page via a vulnerable browser would get affected too.
A real-world example of an attack exploiting the Cross-Site Scripting vulnerability
Jetpack, again one of the most popular WordPress plugins available, offers WordPress.org users the ease-of-use that WordPress.com users enjoy.
Jetpack version 3.0 had a vulnerability that allowed attackers to send WordPress admins a link, that would execute malicious JavaScript.
More recently though, the Jetpack plugin had another XSS vulnerability, that was patched in version 4.0.3.
See, the plugin analyzed HTML code looking for things like video links that it could embed in the page automatically.
Unfortunately, the plugin didn’t check if video links were also surrounded by malicious HTML tags. The vulnerability allowed an attacker to include executable, malicious JavaScript in the comment section. This script ran in the browsers of those visiting the site, as well as the site owners.
If you’ve detected hacks on your website, and have painstakingly gotten them removed, you’d understandably be perplexed when the site is hacked again. The thing is, hackers often leave a bit of malicious code hidden in another part of your website that allows them to re-enter and reinfect your site again and again. This is obviously why it’s called a ‘backdoor’.
How the attack works
Backdoors are sneaky little vulnerabilities. Most of the time hackers use other vulnerabilities to try and launch one kind of attack. Once they get access to the website, they immediately put in an infected file in an inconspicuous folder completely different from where the original attack started. The file never links to any URL, whether on your website or off, or calls attention to itself. In fact, one of the only ways to find it is if the admin of the website combs through the site’s file system. This makes it extremely hard to detect, even by malware scanners. However, since the hacker knows exactly where the file is, he or she can access, and execute it to override any admin functions.
One specific, yet highly popular backdoor, is the ‘Filesman’. Filesman is feature-rich, so it can do a variety of things, including giving complete access to everything on your site.
With a vulnerability like the Backdoor, it’s important to keep deleting plugins and themes that you’re not using.
It’s easy to ignore the notification on your WordPress admin dashboard that says you have a bunch of plugins to update, but your WordPress site’s security relies heavily on it.
As you can see, finding hacks and getting rid of them can be a ridiculously tedious affair. Most efficient hack-scanning and cleaning systems available require technical assistance. And if you take time-zones into consideration, removal could take about 12 hours or so.
This is why the team behind BlogVault built an automated, one-click hack-detecting and cleaning system, that requires no technical assistance. Click here to check out the free trial!
We hope this list of vulnerabilities and exploits helped you. Let us know what you thought of it in the comments!
Fans of Dennis Cooper, the experimental artist and writer, have expressed concern over Google’s removal of the artist’s Blogger account and blog of 14 years. What’s worse, his Gmail account, the medium through which most of his correspondence was conducted was also rendered inaccessible.
The writer’s blog, was a choice destination for followers of transgressive, avant garde writing and experimental art, some of which included ‘Frisk’ and ‘Luster’ (books that later spawned movies in 1995 and 2002), as well as the critically acclaimed book, ‘Closer’. The American artist’s work often depicted graphic violence and savage sexuality.
Back to black: Dennis Cooper might have to sue Google to get his life’s work back. (Image from here)
His blog was updated six times a week, with literature, film and music he enjoyed, some of which followed in the same vein. It’s understandable, therefore, that readers would be offended by it. However, the blog contained a warning, stating that it contained mature and violent content. So the question is, whether this was an attempt at censorship.
In a talk with the Guardian, Pati Hertling, an art lawyer, explained that the First amendment rights to free speech, (which any American citizen is entitled to), do not apply to the world of private corporations like Google or Facebook. This is because the amendment only protects you against public censorship. “Because it’s Google, they’re a private corporation, it’s a private realm, they can do whatever they want”, she said.
Dominant technology companies, such as Google and Facebook, have a vested economic interest in controlling content management. In fact, according to a report by Gizmodo, a former news journalist who curated news for Facebook said that the members of the ‘news curating’ team suppressed content that held ‘conservative views’. The problem is that when tech giants like these create ‘walled gardens’ for content, they wield power over what the general public is exposed to. And since these arenas are great to look at, and have great publicity, the trade-off for creators, is between ease-of-use & productiveness; and creativity & freedom. When the reins are handed over to these firms with a click to ‘Agree to terms and conditions’, things don’t look too good for an artist.
Being in complete control of the content you put up is an important thing to consider, when you’re an artist whose livelihood depends on freedom of expression. This is one of the reasons open source projects, that allow you to host your own site have become so popular. No matter which open platform you choose to host on, you’re in control of your content, and there are much lesser chances of forced censorship. WordPress.org currently powers about 26% of the world’s websites, and it continues to attract creators and inspire a community of contributors. One of the reasons behind this is the platform’s mission to democratize and socialize the publishing world.
When Cooper contacted Google over various channels, the response he received said that the blog was in “violation of the terms of service agreement.” Cooper has no confirmation of whether the blog and his email account have simply been disabled, or whether they have been deleted altogether.
The deactivation of Cooper’s account have serious consequences– his contacts collected for over a decade, as well as recent offers to various platforms for his performance art work were all on his email account, and are now gone. Moreover, all of his work, (including his last gif novel,, which he had been working on for seven months), was hosted only on his blog. He had no backups, and no data stored anywhere else.
“As long as you back everything up. I don’t see really the danger,” agrees Dennis Cooper. “But if you’re at the mercy of Google or some place like Google, obviously I’m a living example of not to be blind like that and think that everything is hunky dory.” Open source platforms are a great way to have complete control over your content, but having your resources backed up is an essential safety measure.
WordPress has a number of backup solutions, all of which could help you get back online. These safeguard your work, in case your website gets taken down by a hack, or is offline because of a human error, or because of your web host. Choosing one according to your needs, and your technical expertise, acts as a sort of insurance policy. Solutions like BlogVault offer WordPress backup services that ensure your data’s safety. It also gets your website back online automatically in case your website has been taken down, so you can have peace of mind.
Do you use Sitepress’s Multilingual CMS plugin? If yes, this post could be very useful to you. A vulnerability was found recently in this plugin that can compromise your entire site. The vulnerability exposes your site to an SQL injection attack that’ll allow hackers to access your database. The issue has been fixed in version 3.1.6. Unfortunately this plugin doesn’t allow automatic updates from the WordPress dashboard and thus requires a manual upgrade. This leaves a lot of sites open for attack as many people may easily miss the update to the change log. So if you haven’t upgraded the plugin yet, do it now!
The blogVault team scanned its customer sites for the vulnerable plugin and found over 99 sites that are susceptible to an SQL injection attack. We have notified all of them to upgrade their plugin immediately. This is, of course, restricted to our customers. Our service is unlike any other backup plugin that is available today. Sign up for blogVault to avail the benefits of the best backup service for your site.
The Sucuri team recently published a critical vulnerability in one of the popular slider plugins – WordPress Slider Revolution Premium Plugin. The bug has been fixed by the developers in version 4.2 of the plugin. The popular slider plugin is hosted on CodeCanyon as a standalone offering and also bundled along with a lot of theme packages.
The vulnerability is very severe in nature and can allow attackers to gain complete access to your site by compromising your database credentials. The issue belongs to a category known as Local File Inclusion (LFI) attack. It allows the attacker to download any file from the server, including wp-config.php. An example of this exploit is as follows –
Considering the severity of the issue, all users using this plugin must upgrade to version 4.2 immediately. The team at blogVault scanned our customer sites for the vulnerable plugin and found at least 356 sites that needed the upgrade. A notification has been sent to all these customers warning them about the vulnerable plugin and its associated severity. Needless to say, this proactive notification is restricted to our esteemed customer only. Our service extends beyond regular backups, unlike any other backup plugin. Sign up for blogVault to avail the benefits of the best backup service for your site.
Data security is one of the top concerns in the world today. With a rise in the number of systems being automated and information stored electronically, the vulnerabilities are also ever increasing. We at BlogVault understand the value of website security and the implications of data loss. Therefore, we’ve taken every possible measure to ensure that it is 100% safe and secure. We maintain multiple copies of your WordPress backup on our local servers. Besides that, we also store your encrypted backup data on Amazon S3 servers. Lastly, we also provide you with an option to upload any particular version of the WordPress backups the BlogVault plugin maintains, to your Dropbox. We ensure that the integrity of your data is not compromised at any point.
BlogVault Data Center
We store two copies of your website backup in our data center located in Germany. The data center houses highly robust and secure servers.
Co-located data and backup
BlogVault ensures the highest protection for your data because your website backup is stored independently from the actual data. This is a classic case of separating the church from the state so that each can fulfil its own purpose. By maintain your backup in servers that are different from where your actual data resides, we ensure that your backup is always at your disposal in the face of any site failures.
Cloud Storage
Apart from the two copies of your website backup our data center, we also create as many as seven copies of your data on Amazon S3 servers. This means we have nine encrypted copies of every backup.
You have the choice of downloading any version of your backup in the last 30 days, at any point of time. What if there is a gold version that you want to copy to your own storage, such as Dropbox? We allow that too by providing an Upload to Dropbox option for every backup version in our history.
Using your own Amazon S3 account
Many developers today may have their own Amazon S3 account. However, there are many potential threats while interfacing with S3 servers directly from your website. Some of the obvious hindrances that you might encounter while using S3 servers are:
Ideal for hard-core programmers – Amazon provides APIs for you to embed in your code so that data is automatically backed up from your website. Unless you are a geek who likes to get down and dirty with such specifics, this could be a challenge for a regular developer.
Key management – Every Amazon S3 account is uniquely identified by a key. This key needs to be a part of any website that interfaces with S3 servers directly. A developer working on five sites will be using one S3 account and hence, the same key for all the websites. This puts your data at great risk. If one of these websites is hacked and the evil doer gets hold of your S3 key, all five sites are compromised. You can not only end up losing all your data but also your S3 account itself.
Account management – Managing an S3 account requires a bit of effort in itself. You need to have an in-depth understanding of how S3 account stores your information (buckets, objects), access control, and versioning.
We at BlogVault alleviate all the above S3 server related problems by maintaining our own S3 account to store your backup. Unlike regular developers, we don’t have to embed the S3 key into your website. Instead, our S3 key is stored within the database, thus ensuring its security. You also don’t need to undergo any hassle for storing or managing your data in your S3 account as it is handled by us. Hence your data is totally independent of your website, and completely protected.
Using your Dropbox account
You might be wondering, why not use a Dropbox account for backup? After all, it works as an excellent interface to Amazon S3 servers. You still have to embed the Dropbox key in your website. And the cost is much higher than an S3 account itself. But if you still want to save your backup to Dropbox, we have an Upload to Dropbox option just for you.
In summary, you can be at peace once you sign up with us. We safeguard your data using the best in class technology. We perform WordPress backups, secure your data, and keep your website data ready in case of any emergency you might face.
About Blogvault
Blogvault was started by Akshat
Choudhary in 2007. Based out of
Bangalore, India, we are a complete
backup service with over 10,000
customers from across the world.
Sign In
Sign Up
