Online Services

Tag: WordPress Security

  • SQL Injection Vulnerability in WP Statistics

    SQL Injection Vulnerability in WP Statistics

    SQL Injection Vulnerability in WP Statistics

    As part of a vulnerability research project for our Sucuri Firewall, we have been auditing popular open source projects looking for security issues.

    While working on the WordPress plugin WP Statistics, we discovered a SQL Injection vulnerability. This plugin is currently installed on 300,000+ websites.

    Are You at Risk?

    This vulnerability is caused by the lack of sanitization in user provided data. An attacker with at least a subscriber account could leak sensitive data and under the right circumstances/configurations compromise your WordPress installation.

    Continue reading SQL Injection Vulnerability in WP Statistics at Sucuri Blog.

  • WSO Shell: The Hack Is Coming From Inside The House!

    Imagine that one day you discover that a burglar has broken into your home and attempted to make off with your big-screen TV. Fearing for your safety, you immediately contact local law enforcement, and they promptly apprehend the criminal. But to your horror, as they drag the burglar away in handcuffs, they have an additional shocking revelation: the burglar has not only been living in the basement of your home for months, entirely undetected by you, but he’s also converted your basement into an elaborate base for all of his criminal operations.

    You, of course, are both shocked and appalled! How could you not have noticed a nefarious criminal had hijacked your whole residence right under your nose? And how much damage have they already done, unbeknownst to you, all while secretly living under your own roof?

    That’s a lot like what it’s like when an attacker compromises your website and quietly installs a malicious web shell, taking over and executing all kinds of malicious scripts and behavior: your website has been broken into, hackers have made themselves at home on your server, your bandwidth and storage space have been stolen, and you’re none the wiser.

    The Wordfence team has seen thousands of malicious scripts from hackers attempting to compromise the millions of sites that we protect. But there’s one particularly invasive script that, once it makes its way onto your website, acts exactly like the burglar in the above scenario, living in your site’s “basement” and allowing the attacker to wreak havoc almost completely undetected indefinitely: the WSO web shell.

    What Is a Web Shell?

    A web shell is a script that runs on a web server, much like WordPress or any other PHP code. It allows the user to do things as if they were logged in to the server directly. It’s like a server administration tool: it lets the user view or edit files, work with databases, and even run programs. Web shells created by hackers usually have additional malicious features, such as sending spam or automatically defacing a website.

    Web shells are not inherently a type of attack or an exploit. Rather, they’re a tool used to manipulate a site after it’s already been broken into. We talk a lot about the different kinds of exploits and why they put your site at risk, but the truth is that security vulnerabilities and exploits are merely the first step in any successful hack. The goal is to break into your website, and then use a script to take over your site and wreak all sorts of havoc via your server.

    That, in a nutshell, is exactly what the WSO web shell does. It takes over your site for the hacker’s own purposes without you ever realizing it’s there.

    What’s “Special” About WSO?

    WSO is a favorite web shell among hackers because of its particularly powerful set of features.

    • Password protection
    • Server information disclosure
    • File management features like uploading, downloading, or editing files, creating directories, browsing through directories, and searching for text in files
    • Command-line console
    • Database administration
    • PHP code execution
    • Encoding and decoding text input
    • Brute-force attacks against FTP or database servers
    • Installation of a Perl script to act as a more direct backdoor on the server

    Once they’re installed on a website, web shells are notoriously difficult to remove, in large part because hackers often place multiple copies of a web shell all over a site to try to retain access even if some of their malware is removed.

    WSO is designed to be used via a web browser, and it has a pretty simple user-friendly interface, making it very easy for any would-be hacker to learn and put to use.

    It seems to strike a good balance between simplicity and capability, since it’s one of the most popular web shells out there. In fact, despite the simple browser interface, we see a lot of hackers using it simply to execute malicious PHP code on websites. In theory, that’s something that a hacker could accomplish more easily with a very small amount of code:

     

    But hackers seem to like and trust WSO so much that they want it on their compromised websites anyway.

    A whole ecosystem has sprung up in the hacker community around WSO shell, with hackers developing secondary tools that support its execution and use. For example, there’s a tool to build a customized version of the shell with only the features you want.

    We’ve also seen a tool to manage multiple sites infected with it, making it that much easier for even entry-level hackers to take over a large number of websites relatively easily.

    History

    For such a ubiquitous tool, WSO’s origins remains something of an unsolved mystery.

    WSO apparently stands for “web shell by oRb.” It was first seen in hacker communities between 2008 and 2009. The earliest mention we could find was a thread in a Russian hacking forum in January of 2009 by a user named oRb, which the script has since been named after.

    That thread was used to announce a major update to the script, though, so that probably wasn’t the first release of WSO. But Google searches for “WSO Shell” started to pick up soon after.

    oRb continued to post updates and new versions of the script until late 2010, when they released version 2.5. That remains the most popular version, though some hackers have released variations since then (and not always out of altruism toward other hackers – some releases include hidden code to notify the author where they’re installed, thereby causing multiple levels of infiltration and damage).

    The WSO shell is widely used by countless hackers all over the world, with the community of users who prefer it as a web shell growing every day.

    In January of this year, for example, we published research about the ChickenKiev or ‘CK’ botnet which uses WSO as part of its operation.

    Each new iteration is intended to make it easier and easier for hackers to take over websites and do whatever they want after that. The laziness of hackers in this regard can’t be overstated. For example, one of the first lines in the WSO shell sets the password required to use it:

    $auth_pass = "63a9f0ea7bb98050796b649e85481845";

    Specifically, this sets the password to the word ‘root.’ Our WAF has blocked hundreds of attempts to upload WSO to websites we protect – all trying to execute with this simple no-brainer default password.

    How Wordfence Blocks WSO

    We have been monitoring and blocking WSO shell hijacking attempts for some time, and as a direct result, we’ve developed a few powerful ways of making sure every website we protect is safe from this aggressive invasion.

    Wordfence protects your site from exploitation using WSO shell in the following ways:

    • Wordfence will detect and block any attempt to upload WSO shell. The Wordfence WAF scans all requests to your website to look for malicious code using our custom-designed malware signatures, which are continuously updated. The WAF, once installed on your site, will detect any attempt to upload WSO shell – and immediately block it.
    • Wordfence’s malware scanner will detect the presence of WSO shell on your filesystem if an attacker manages to find some other way to install it. You will be instantly alerted if WSO shell is found lurking anywhere on your server.
    • Wordfence also blocks attempts to run WSO shell commands, so that even if a hacker manages to get past the first two defenses, it’s a moot point: WSO shell commands simply won’t work on your site.

    How to Tell If WSO Shell Is Lurking on Your Website

    We have two incredibly easy ways that you can use to determine if WSO shell is secretly lying in wait on your website:

    1. If you have Wordfence installed, simply run a scan. If the results come back clean, you almost certainly don’t have WSO shell on your site.
    2. If you don’t have Wordfence installed, or if you use another content management system like Joomla or Drupal, simply use Gravityscan to scan your website. (Important: make sure you have the Gravityscan Accelerator installed.) Gravityscan will scour your website’s entire filesystem, and your scan results should let you know if you have WSO shell installed anywhere.

    Conclusion

    Because of its low barrier of entry, WSO shell is one of the most popular and most malicious tools used by hackers to infect websites. Having WSO shell installed on your website can a dangerous liability for you and your business.

    Of course, the best defense is a good offense, and using Wordfence or Gravityscan, you can not just block and easily detect its presence and keep your site safe from any would-be attackers – you can also make certain that they never break into your “home” on the web in the first place.

    The post WSO Shell: The Hack Is Coming From Inside The House! appeared first on Wordfence.

  • When Your Plugins Turn Against You

    When Your Plugins Turn Against You

    When Your Plugins Turn Against You

    Every day we face countless cases of sites getting compromised and infected by an attacker. From there, the sites can be used for various operations like spam campaigns, malware spreading or simply to damage your SEO ranking among other events.

    The threat may not always come from outside though. There are occasions where we are indirectly the ones responsible for the infection and may never find out until we get blacklisted by a search engine, or alerted of malicious code from our users.

    Continue reading When Your Plugins Turn Against You at Sucuri Blog.

  • New in Wordfence 6.3.11: Abandoned and Removed Plugin Alerts

    On Thursday of last week, we released Wordfence 6.3.11 which included a really exciting new feature: we are now alerting you if you are running a plugin that either appears to be abandoned or has been removed from the WordPress.org plugin directory. In this post, we explain how each of these new alerts work and why they’re so important to the security of your website.

    Abandoned Plugins

    At Wordfence, we define a potential abandoned plugin as one that has not been updated by its developers in at least 2 years. In May, we analyzed the plugins in the WordPress.org repo and found that almost half of them hadn’t been updated in over 2 years. Over a third of them had a compatibility tag for a WordPress version dating back to 2014 or earlier.

    abandoned plugin alert

    The alert we send tells you how long it’s been since the developer updated the plugin, as well as whether we found reference to any unpatched security issues with it and whether it has been tested with the current version of WordPress.

    Why Should You Care if a Plugin Hasn’t Been Updated Recently?

    If a developer hasn’t updated a plugin in two or more years, there is a really good chance that the plugin author has actually abandoned the plugin altogether. An author that has abandoned a plugin is very unlikely to fix any security vulnerabilities that users have reported. No plugin is immune to becoming a security vulnerability on a website, even simple plugins with small user bases. Simply put, the older a plugin’s code, the higher the risk of security issues.

    Let’s look at ways that vulnerabilities happen or are discovered:

    1. Many Plugins Use Software Components That Were Written by Someone Else

    One of our favorite examples is the TimThumb vulnerability that was discovered in 2011 by someone we know quite well here at Wordfence. TimThumb was an image-sizing utility that was included in lots of themes and plugins. Once the WordPress community discovered the vulnerability, all of the theme and plugin authors who had used it had to scramble to release a fix of their own for each of their plugins.

    In the case of an abandoned plugin, the authors wouldn’t likely be available apply a quick fix. To this day, we continue to see attacks seeking to exploit this very old vulnerability on sites that we protect.

    2. WordPress Plugins Function in a Very Dynamic Environment

    WordPress.org publishes core WordPress updates constantly, and  PHP, Apache, Nginx and updates to other plugins and themes are posted at least as often, too. This continually changing landscape represents a security risk over time.

    A great example is the ‘add_query_arg()’ and ‘remove_query_arg()’ issue that GoDaddy/Sucuri discovered two years ago. The issue here was with a WordPress function that plugin and theme developers use to interact with WordPress core. To fix the issue, each plugin developer needed to update their code and push updates. Any plugin author who was no longer paying attention would likely miss this and leave the vulnerabilities in their code.

    3. Security Researchers and Attackers Are Constantly Finding Vulnerabilities

    As of this writing, the WPVulndb website has publicly reported five WordPress plugin vulnerabilities in the last week alone.

    When a security researcher discovers a vulnerability, they reach out to the developer, disclose the details and give them a fixed amount of time to release a fix. Once the author releases the fix, the researcher generally publishes their findings publicly.

    However, in cases where the author does not respond, such as with an abandoned plugin, the researcher will sometimes release the details anyway, giving attackers the information they need to exploit it. The worst case scenario is when an attacker is the first to discover a vulnerability, leaving literally all of the sites running that plugin vulnerable to attack before developers get the chance to release a fix.

    What Should You Do if One of Your Plugins Appears to be Abandoned?

    The best option in this situation is to remove the plugin and replace it with a plugin whose author is actively maintaining the code. If a suitable replacement doesn’t exist and you are a software developer, or know someone who is, it might be possible to assess the risk and potentially decide to maintain it yourself going forward if vulnerabilities are reported.

    Plugins Removed from WordPress.org

    Plugins listed in the WordPress.org plugin directory need to follow a set of guidelines. The list of requirements is long, so there are a wide variety of reasons why the WordPress.org team may remove a plugin.

    One common security reason is that a security researcher has discovered a vulnerability, contacted the author without getting a response, and then contacted the WordPress plugin team about the author’s unresponsiveness. The WordPress plugin team will do their best to contact the author, but if they also receive no response, they will subsequently remove the plugin from the plugin directory.

    It’s important to stress that not all of the reasons for removing a plugin represent something that should lead you to stop using the plugin, but many of those reasons are worth taking into consideration when deciding whether to keep a plugin on your website.

    What Should You Do if the WordPress.org Directory Removes One of Your Site’s Plugins?

    Your first course of action should be to try to determine why it was removed. If you’re able to verify that the plugin was removed for a non-security reason, then it might be okay to continue to use it. It’s a judgement call on your part based on all the information you’re able to gather. If you can’t figure out why it was removed, or you confirm that it was removed due to a security vulnerability that hasn’t been fixed, we recommend that you remove the plugin from your website immediately and finding a well-maintained replacement for its functionality.

    Conclusion

    As we’ve written about in the past, vulnerable plugins are the most common way that attackers compromise WordPress websites. It is critical that, as a site owner, you only install (and keep) reputable plugins on your website, and that you keep them up-to-date and remove them if they are abandoned. The new alerts that we added last week should make that task much easier going forward.

    The post New in Wordfence 6.3.11: Abandoned and Removed Plugin Alerts appeared first on Wordfence.