Category: WordPress security

How to Keep Your Dashboard Green

By Logan Kipp

The SiteLock Dashboard is designed to deliver a concise report of your website security status at-a-glance. We’ve incorporated a color-coded light system that is so easy to understand, your eyes won’t need more than two tenths of a second to discern the color of your SiteLock status light. If you’re not familiar with the definitions of the three traffic light settings, I sometimes like to explain these using what I call the beach martini rule. I tend to picture our customers relaxing on the beach, unwinding and sipping a martini because they know SiteLock has their back. At about the  point where it’s a good time to reapply your sunscreen, you also take a quick glance at your site status before sinking back into your lounge chair.

SiteLock Dashboard Green LightGreen – The coast is clear, no action is required at this time. Re-apply your sunscreen and order yourself another martini.

SiteLock Dashboard Yellow LightYellow – Action is required to resolve a non-critical item. When you’re done soaking up the rays for the day, go ahead and take a look at what needs your attention.

SiteLock Dashboard Red LightRed – Action is required on a critical item. Let’s go ahead and set that martini down and take a look at what’s going on.

Potts Traffic Light

While the green light is pretty self-explanatory, the yellow light can mean that either some configuration is required, or that a scan operation is pending. Seeing the red light means that either there is a critical error with one of the scans, or that we’ve found something bad, like malware of a website vulnerability. When you see that red light, much like a traffic light, it means to stop and address the issue.

 

The first traffic light to incorporate the green, yellow, and red color design was deployed in Detroit, MI in 1920.

 

While the green light is pretty self-explanatory, the yellow light can mean that either some configuration is required, or that a scan operation is pending. A red light means that either there is a critical error with one of the scans, or we’ve found something bad, like malware or a website vulnerability. When you see that red light, much like a traffic light, it means you need to stop and address the issue.

Figure 1: Security Alerts pop-up warning.

A critical alert may be warning you that malware or a vulnerability has been discovered on your website. The SMART Scan and Malware Scan sections of your dashboard pertain to malware-related areas of concerns, while the XSS Scan, SQLi Scan, Application Scan, and TrueCode reference vulnerability concerns. Each of the Dashboard product bubbles follow the same uniform green, yellow, and red color scheme.

Figure 2: Product bubbles with statuses.

Yellow Alerts

As I mentioned, there are generally two reasons why a product may be coded yellow.

  • Additional Configuration Required

Some products require configuration before they are fully functional. For example, TrueShield requires DNS changes to be made, and SMART requires FTP or SSH credentials in order to connect to your website. Click the product bubble to be directed on how to complete the setup for the product.

  • Pending Item

Some products or features may require more time to complete their tasks, and will be listed as pending until completion. For example, we send you a letter containing a unique code for address verification, so this item will be listed as pending until you’ve received the letter through traditional mail and input the code into your dashboard.

Red Alerts

Unlike yellow-coded alert items, red-coded items require immediate attention. Again, there are generally two cases for these critical alerts.

  • Malware or Vulnerabilities Found

When a SiteLock scanner locates malware you are immediately alerted. You can click through the product bubble for more details on the discovery. Within the product page, you will find details such as the location of the malware or vulnerability we’ve identified. If you are unable to remediate the issue yourself, call the SiteLock experts at 855.378.6200 for help.

  • Critical Error

Some products like SMART and INFINITY require regular access to your website through SSH or FTP. When we are unable to establish a connection and therefore can not scan your website through these products, you are immediately alerted. Verify the connection details used in the product and ensure that the connection is not being blocked by your web server to resolve this issue.

By addressing any alerts that you encounter in a timely fashion, you’ll be able to keep your Dashboard green and clear of issues. For more information on how to use your SiteLock Dashboard, please feel free to reach out to our 24/7 US-based phone support team at 855.378.6200.

Tags:   account management, alerts, dashboard, malware, SiteLock, vulnerability
Categories:  Website Security, WordPress security
SiteLock Threat Intercept blog

Threat Intercept: Passwords Publicly Exposed by Malware

By Ramuel Gall
This article was co-authored by Product Evangelist Logan Kipp.

THREAT SUMMARY

High Threat
Threat Bar Graphic
Learn More

Category: Shell / Information Disclosure

Trend Identified: 4/20/2017

CVE ID: N/A

Trend Name: Trend Tusayan

Vector: Application Vulnerability, Multiple

The threat rating was determined using the following metrics:

Complexity:

LOW: The vectors used to infect websites appear to be well-documented vulnerabilities in older versions of website platforms.

Confidentiality Impact:

HIGH: This infection provides complete control of the target website, including credential disclosure and database contents.

Integrity Impact:

HIGH: This infection provides the adversary administrator-level access to impacted website applications, making total data loss a possibility.

The SiteLock team has discovered a dangerous malware trend that not only provides website administrator level access to the bad actors involved, but exposes sensitive website credentials publicly over the internet.

The mechanism behind the trend involves the injection of the IndoXploit Shell, or IDX Shell, a common shell kit that is often used to deface and compromise websites. This particular trend makes extended use of the shell by grabbing the contents of configuration files for content management systems (CMS) including WordPress, Joomla and Magento, and saving them to .txt files in a folder it creates named /idx_config. While these text files may seem innocuous, they contain sensitive credentials that a hacker could use to access CMS-connected databases on target hosting accounts.


A Shell is a tool that can be used by an adversary to run commands in a hosting environment. Many hackers opt to upload a shell as the primary method for controlling a target environment.

Who is impacted?

We have identified that this trend currently impacts WordPress, Joomla and Magento websites by taking advantage of various vulnerabilities present in older versions of the platforms.

What does it look like?

A website that has been infected will have a world-browsable folder called “idx_config,” which contains text versions of the configuration file of every CMS installation the shell is able to find.

IDX Shell

IDX Shell

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

Here’s what you need to do

As this trend both provides administrator-level control over the target website environment as well as publicly discloses credentials, action must be taken to counter both threats.

  • Run a malware scan to locate the presence of any shell files. (see: SiteLock Malware Scanners)
  • Search for any instances of the idx_config folder and delete any sensitive information within. We’ve most commonly observed this folder directly in the webroot, but may be present in other folders as well.
  • Update your CMS platform to the latest version, including any themes, plugins, or extensions used.
  • Change all database passwords.
  • Update any relevant connection strings within the CMS platform.
  • Change your CMS passwords.
  • Review all administrator-level accounts in your CMS platform for any users that do not belong.
  • If you are using the software cPanel to manage your hosting account, change your cPanel password.

We advise reaching out to your hosting provider as they may have a backup of your website stored on file. Additionally, if you have any questions or concerns about how to protect your website, please contact us at 877.563.2832 or email support@sitelock.com.

Please check this article regularly for updates as more information becomes available.

Tags:   cpanel, idx shell, Joomla!, magento, malware, password, shell, threat intercept, trend, vulnerability, WordPress
Categories:  Website Security, WordPress, WordPress security
website security scientist

Ask a Security Pro: Encryption Explained

By Logan Kipp

Over the last year I’ve led a multitude of security workshops aimed to educate entry-level WordPress users about website security. Some of the questions I regularly field in these workshops are related to the mechanics of SSL certificates, and their role in protecting website data from prying eyes. As you may know, the installation of an SSL certificate on a web server allows the server to accept traffic on the hypertext transfer protocol (secure), or simply ‘HTTPS,’ the primary form of encrypted data transfer between websites and visitors. I’d like to share the answers to some of the most frequently asked questions I’ve had on the subject.

SSL is the Armored Truck

The first thing I’d like to clarify on the subject of HTTPS and SSL certificates specifically is that the use of SSL certificates and HTTPS do not in any way, shape, or form protect the data on your website itself. HTTPS encrypts data in transit only. Neither does it protect data resting on visitors’ computers. You should consider HTTPS the armored truck of websites, not the bank vault. It acts as the protection against adversaries while data travels from point ‘A’ to point ‘B’.

Did you know that most HTTPS connections are actually using TLS (Transport Layer Security) ciphers, not Secure Sockets Layer (SSL) ciphers? SSL ciphers have been phased-out in favor of newer TLS technology. Vendors continue to use the term SSL likely due to consumer familiarity with the term.

 

While SSL certificates form a very important part of your overall security posture as a WordPress website owner, the security of your website itself should instead be entrusted in security processes and mechanisms, such as a secure development life cycle (SDLC), the implementation of network and web application firewalls (WAF), and regular malware and vulnerability scans.

SSL Certificate

When it comes to the subject of encryption, I think most of us correctly visualize the rather abstract concept of jumbled words or characters so the original message is no longer legible, and thus protected from adversaries. However, few that I’ve encountered outside the security community have a firm understanding of what exactly the mechanics are behind that process. Encryption holds very ancient roots in human society, most obviously in military communications, where it’s designed to conceal the true message from enemies attempting to intercept to learn about troop movements and strategies. However, avoiding a verbose lesson in cryptographic history, for this article we’re going to focus on the concept of encryption and how it works in reference to modern websites utilizing SSL certificates for HTTPS.

Modern-day websites using HTTPS typically rely on a system called public key cryptography, also known as asymmetric cryptography, to protect data in transit. In public key cryptography the website owner generates a set of unique keys, one public key and one private key. The public key is as its name denotes, the non-private half of the relationship used by the public to facilitate private communication that can be nearly impossible to decode without possession of the associated private key. The integrity of this system depends entirely on both the secrecy of the private key and its strength against breaches. Much like if the keys to your house are stolen, if the private key is stolen, you are compromised and the only solution is to change the locks. This process is called re-keying in terms of SSL certificates.

Public Key Encryption

Web servers will typically support a variety of different encryption ciphers. When you visit a website using an SSL certificate to provide HTTPS, a discussion occurs between your browser and the website server to communicate what ciphers you both support. The browser and website server will then agree upon the strongest common cipher to use. This process is called negotiation. Once your browser and the website server have agreed upon a cipher to use, the web server provides your browser a public key to use for the initial encryption of the data your browser wishes to send. Once this asymmetric key relationship has been established, a second symmetric key relationship is formed using the same cipher already agreed upon and the initial public key so that both parties can encrypt and decrypt messages from each other.

SSL Asymmetric Key Relationship

The reason that both asymmetric and symmetric keys are used in these communications is due to the initial stages where an agreed upon cipher has to be transmitted over plain text, and the following communications are what need to be protected. As a result, the website server hands your browser the method for keeping the main symmetric keys safe by providing its public key in the beginning of the conversation, essentially providing two layers of protection for the data that follows.

Not all ciphers are created equally. The strength of a cipher is determined by the difficulty involved in reversing encrypted data back to plain text without possession of its associated private key. This is measured in the time and computational resources required to complete the process. Some ciphers would take hundreds of thousands of years to reverse by the current modern computational power available, where as other older ciphers may now only take but a few minutes to break. Cipher generations evolve relative to the average computational power available to the public because while we want our data to be secure, we also demand that websites load quickly. The strongest ciphers generally create messages that take a long time to decrypt, so a balance must be struck between speed and security. As computers become faster, we are able to use stronger ciphers without sacrificing speed.  On the other side of the coin, we must increase security because computers are able to break encryption with more ease. This is why you may hear about ciphers becoming outdated or obsolete. Modern encryption has become an arms race between brilliant mathematicians and their computers, and hackers and theirs.

Have a question for our security professionals or a topic that you would like us to write about? Message @SiteLock and use the #AskSecPro tag!

Tags:   #AskSecPro, Encryption, HTTPS, SSL
Categories:  Ask a Security Pro, Website Security, WordPress security

Malware and WordPress Auto Login

By Michael Veenstra

Malware comes in a great deal of unique shapes and sizes.  Most people know someone who has had the misfortune of an infected computer at some point. Ransomware, trojans, and viruses that affect consumers’ physical devices are generally built with compiled code, which means you can’t easily “take a look under the hood” to get a solid idea of how it works.

The types of malware we work with at SiteLock behave a little differently, however. The web-ready files we encounter most frequently are written in Interpreted Languages like PHP and JavaScript. This means that the files involved contain plain, human-readable code, allowing anyone who understands the language to see what the files do.

Tags:   malware, PHP Code, WordPress
Categories:  Website Security, WordPress security
SiteLock Threat Intercept blog

Trending: Fake WordPress SEO Plugin Provides Backdoor Access

By Jessica Ortega

We recently discussed a particularly sneaky piece of malware that’s been disguising itself as fake plugin and targeting Joomla! users. While this phenomenon is not unique to the Joomla! content management system, SiteLock has discovered a recent trending fake plugin for WordPress, one of the world’s largest open source applications.

The fake plugin the SiteLock Research team found is called WP-Base-SEO. It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools. Malicious content was found in /wp-content/plugins/wp-base-seo/wp-seo-main.php.  At first glance, the file appears to be legitimate, including a reference to the WordPress plugin database and documentation on how the plugin works.

WordPress fake SEO Plugin header

Fake plugin header

Tags:   fake plugin, Joomla!, SiteLock, WordPress
Categories:  SiteLock News, WordPress security
website security scientist

Ask a Security Professional: Feature-Based Malware Detection

By Logan Kipp

Last year we published an #AskSecPro series where we explained how signature-based malware analysis works, as well as how traditional signatures are created. An area we don’t often talk about in public channels, but has played a pivotal role in SiteLock becoming a global leader in website security solutions, is our research and development efforts in new security technologies. In addition to our more traditional approaches to malware detection, SiteLock continues to explore new frontiers in technological improvement to push the field of security research forward. For some time SiteLock has been developing machine learning mechanisms as part of its process for discovering new malware iterations on an automatic basis. Our research in the field has shown that machine learning promises to be an important part of early malware detection and preliminary identification. One of the most significant breakthroughs we’ve had in machine learning as it pertains to malware detection and signatures, has been in feature-based signature analysis.

Tags:   #AskSecPro, analysis, behavioral analysis, feature-based, machine learning, malware, research, signatures, unsupervised learning
Categories:  Ask a Security Pro, Website Security, WordPress, WordPress security
website security scientist

Ask a Security Professional: WordPress Database Security Part Two — Best Practices

By Logan Kipp

In Part One of our #AskSecPro series on WordPress Database Security, we learned about the anatomy of WordPress. Now that we have a firm understanding of the role the WordPress MySQL database plays in a WordPress installation, we can take a look at the various ways an adversary can exploit the mechanisms involved. We’ll also explore some of the ways to defend your database against compromise.

Tags:   #AskSecPro, best practices, database, mysql
Categories:  Ask a Security Pro, Website Security, WordPress, WordPress security
website security scientist

Ask a Security Professional: What is #Cloudbleed?

By Logan Kipp

Over the last few days you may have heard the term #Cloudbleed thrown around the water cooler. Some of the questions our customers are asking us include,  “What is Cloudbleed?” and “Am I protected from Cloudbleed?” As your resident Security Professional, I’ll be glad to help you to understand what the Cloudbleed buzz is all about and how it may impact you.

— First, I want to be very clear that the Cloudbleed bug does NOT impact SiteLock TrueShield™ WAF/CDN. More below.

Tags:   buffer overflow, CDN, cloudbleed, disclosure, leaked, memory leak
Categories:  Ask a Security Pro, Website Security, WordPress, WordPress security

Rogue Pharmacy Defacements via REST API Exploit

By Logan Kipp
SiteLock Research shield

This article was co-authored by Security Researcher Wyatt Morgan from SiteLock Research.

 

This month we’ve seen WordPress websites bombarded with defacements and remote code execution attempts by abusing a vulnerability in the WordPress REST API. As could be expected, compromises motivated by financial gain have now made their debut through the same vector. This most recent flavor of defacements focuses on driving traffic to a rogue pharmacy website, where the visitor is encouraged to purchase — you guessed it, “authentic” erectile dysfunction medication.

Tags:   exploit, pharmahack, REST API, rogue pharmacy, trend, Trend Yuma
Categories:  Website Security, WordPress, WordPress security

Remote Code Execution Attempts via REST API Vulnerability

By Logan Kipp
SiteLock Research shield

This article was co-authored by Security Researcher Wyatt Morgan from SiteLock Research.

 

In the continuing saga of the WordPress REST API vulnerability in WordPress 4.7 and 4.7.1, SiteLock has identified that at least one hacker has launched a campaign specifically attempting remote code execution (RCE) on WordPress websites. The attacks aim to take advantage of WordPress websites using plugins that enable PHP to run inside of posts. If successful, the attack injects a line of code that ultimately downloads a series of malicious files from a Pastebin repository. These malicious files are used to install  backdoors and automatically steal information from  websites. When unsuccessful at remote code execution, the attack overwrites existing posts and leaves behind PHP shortcode.

Tags:   api, backdoor, exploit, rce, remote code execution, rest, Trend Sedona, WordPress
Categories:  Website Security, WordCamp, WordPress security