Having your own website is hard enough. In addition to adding content, trying to grow your audience, maintaining it, now you have to be cautious of malware possibly being spread through your beloved website?
According to Palo Alto Networks’s recent The Modern Malware Review, “90 percent of Unknown Malware [is] Delivered Via Web-Browsing.”
This confirms that most web-based infections fly under the radar for several hours/days before being detected by major antivirus products.
In our previous blog posts, we’ve discussed how web exploits affect end users’ machines and serve malicious payloads.
Let’s take a look behind the curtain on websites and web servers that house and serve malware and how to better protect your own website.
There are millions of websites and the process of getting your own is fairly trivial. Without a doubt the ease of deploying a website and relative low cost to own one is responsible for many of the security issues we face. While you may think of a website as a personal blog, e-commerce site or forum, the bad guys see it as a resource for many purposes:
- Hosting illegal/copyrighted files for free.
- Hosting malware, phishing and fake pharmaceutical pages.
- Sending spam (malware can run on a website just like it does on your desktop computer).
- Gaming Google’s SEO ranking algorithm by stuffing pages with backlinks.
- Performing Denial of Service attacks to knock other websites offline.
Finding the flaw(s)
The dominant web server software is Apache, which runs on Linux. While there is a widely accepted belief that Linux is more secure than Windows, web servers are constantly hacked into by attackers ranging from script kiddies to professional pentesters.
Let’s review some of the most common reasons why websites get hacked:
Stolen user credentials
You access your website by logging into a Control Panel or login page from your favorite blogging software such as WordPress. Occasionally, you may also use an FTP program to upload files. If malware is present on your computer, and it happens to be a keylogger or some other type of password stealer, everything you type, as well your configurations files, can be harvested and sent back to the bad guys. Similarly, logging into your website from a free Wi-Fi hotspot or insecure access point exposes your password.
Weak passwords
Most attackers leave the default “admin” username and choose a password that is easy to guess by performing a technique known as a brute force attack. This consists of trying out hundreds of thousands of passwords until one matches. If you use a typical dictionary or a cute pet name, you might as well give the bad guys the keys to your house.
Software vulnerabilities
Websites run multiple software programs in order to render pages, store customer data, etc. If those are poorly configured or outdated, a multitude of bugs can be exploited by a remote attacker to gain access to the system.
Dangerous configurations
A very important aspect of Linux security is file permissions. However, it is a double-edged sword because, while if set properly, file permissions can make a site very secure, the opposite is true as well. Many people do not understand permissions well or simply disable them altogether in order to install a plugin that complained about restrictions. You can read more about file permissions in this blog post.
A popular attack method that has allowed countless script kiddies to deface websites and spread malware is called Remote File Inclusion (RFI). It consists of tricking the web server into thinking it should open a file as if it actually resides locally by passing specially crafted parameters into the URL. The remote file could be anything, but hackers will use scripts, also known as “shells’” (more on that later), to gain access and perform administrative operations directly on the website.
Owning the box
The ultimate goal of an attacker is to completely own the target system, something known as being root. Unless you possess the administrative credentials, your local user account has very restricted permissions which do not allow you to alter core parts of the website to do as you please. Once again, web servers have enough vulnerabilities to exploit to elevate a user’s privileges to root.
For the most part, attackers will reuse publicly available exploits, perhaps tweak them a little bit to add their signature or a message to their friends. Even exploits that are several years old still work, which shows one of the big issues with website security: lack of security maintenance. There is also some confusion between the hosting provider and its customers regarding the patching process. Some providers will not perform upgrades for you, especially if you install your own Content Management System (WordPress, Joomla!, Drupal). There are many reasons for that:
- The cost: When you only pay a few dollars a month for web site hosting, your provider is not going to waste its time and money troubleshooting your site.
- The responsibility: If performing an update on your site breaks the database or other critical part, this is a pretty big responsibility to assume. Your hosting company is not a web development studio.
The problem is that most website owners wrongly assume everything is taken care of or that a website is for some reason “immune” to security problems.
Prevention goes a long Way
- Only administer your website from a device you trust is free of malware. If you aren’t sure, why not run our Malwarebytes Anti-Malware program?
- Do not administer your site from a free Wi-Fi hotspot (i.e., your local StarBucks). If you must, please use a free or cheap VPN program to encrypt your connection.
- Keep your website up to date just like you would (or should) keep your computer patched up. If you use WordPress, the main dashboard will tell you when updates are available.
- If spending time to secure your site is not your cup of tea, you might want to pay a little more and do “managed hosting,” a turn-key solution where everything is taken care of for you.
- Use strong passwords and change them on a regular basis.
- Back up your site at least once a month.
For the more advanced users out there, let’s roll up our sleeves and dig deeper.
Web malware is quite different from what we see on the Windows platform. For one, there are many more scripts (as opposed to compiled binaries) which can be written in Perl, PHP, Python or simply in bash, the popular Unix shell language. Such scripts are also known as “backdoors or “shells,” since once uploaded onto a website (using for example the Remote File Inclusion we discussed earlier), they allow unfettered remote access.
A popular shell known as C99 lets an attacker browse the entire website’s content directly from its browser:
Figure 1: C99 Shell: A Hacker’s Favorite
In addition, this shell lets you delete and add files, dump the database and even change file permissions.
In almost all cases involving a site hack, you will a find a backdoor of some sort. It may not have a full graphical interface, but as long as it allows hackers remote access, that is more than enough to keep the site under their control. By nature, shells are very small in size and will try to hide in certain directories or, if that is not possible, will be in folders that have more laxed permissions, such as /images, simply because that was the easiest place to inject them.
How to recognize a backdoor
Accessing your files
If you are trying to hunt for malicious files, you will need to access your website internals. You can do so either by FTP, SFTP or SSH. FTP is the old-school way of uploading files using a client like FileZilla or CuteFTP. I recommend using SFTP instead, which supports encryption (as opposed to sending out your login credentials in the clear with FTP). By far the best way to access your web server is using the command line terminal through SSH. Keep in mind that it requires a certain understanding of Linux commands and can seem a little overwhelming. Finally, you can of course browse your files using your web hosting company’s control panel (Cpanel and Plesk to name two).
Figure 2: The Plesk Control Panel
File name patterns/location
Although not a very reliable approach, searching for malicious shells by name can yield some good results. Many hackers will not bother renaming the backdoor they uploaded. So if you see a file called c99.php or r57.php (two very popular backdoors), you are pretty much guaranteed it is bad. Another trick the bad guys use is to rename those files with another extension such as “.txt,” so keep an eye open for those as well (i.e., c99.php.txt, r57.php.txt).
Looking at folders where plugins or images normally reside can be quite revealing if you search for files that have no business being in there.
Figure 3: A Backdoor Hiding Among Images
File modification date
If your site was hacked recently but was fine say, a month ago, then you have something to work with: time stamps. Look for any file added or modified recently and treat is as suspicious.
File permissions/ownership
As we talked about earlier, file permissions and ownership are crucial to keeping a website secure. At the same time, many backdoors that are uploaded will often show with unusual attributes or attributes that are once again “out of place” with other files around them. So if you see a file with “777” permissions, it should instantly raise a red flag. Please refer to this article to learn more about file permissions and ownership.
File contents
A much more powerful method to identify backdoors is to search for patterns and strings within the files themselves. That is where knowledge of Linux commands such as grep comes into play. This, of course, relies on having a list of malicious strings or patterns that is kept up to date. In many ways, you could compare that to antivirus signatures and a malware database.
Figure 4: Yet Another Backdoor Called FilesMan
Log analysis
When all else fails, log analysis can be your best friend. Think of log files as the black box investigators recover to find out more about an accident. Logs contain traces of all events that happened on your website, sorted out by timestamp. There are two types of logs often mentioned: Apache’s access and error logs. Every time someone visits a page on your site, a record is created in your Apache’s access logs. The error logs show entries for commands that resulted in an error, often indicating malicious activity, such as trying to brute force a login page or performing a hack. As you may imagine, log files can get really large, which makes searching them a real pain. There are tools such as OSSEC that make this process a little easier.
If you are using your web host’s control panel, the logs may be located as illustrated below.
Figure 5: Control Panel Showing Apache Logs
Full website compromise
Injecting a backdoor on your site is just the first step in a long chain of events to follow. Once the attacker can control your server, it will want to carry out some sort of action. Note that most (if not all) site compromises are automated, meaning there is no human sitting at a terminal and hacking your particular site. Automated scripts are constantly probing the wire to hack anything that is vulnerable.
As mentioned before, your website can be leveraged to do all sorts of things. Let’s take a look at some of the most common motives and how it is done.
Spam (AKA pharma hack)
It seems spam is here for the long haul. Few people know that pharmaceutical spam also affects websites. While it may not be visible to site owners, pharma spam is definitely found by search engines. All of the sudden, your website is pushing fake drugs and other dubious products. Not only is this going to use up a lot of bandwidth, it will put a website in Google’s blacklist with all the resulting consequences on search rankings.
Figure 6: A Legitimate Website Advertising Various Drugs
The pharma hack is very difficult to eradicate because it is often buried deep within the website’s files and even database. For more information on the subject, I recommend this excellent free resource.
Malware
Using your website to distribute malware is probably the most popular motive behind a site compromise. A legitimate website already has traffic, perhaps even a good SEO ranking, and costs nothing for the hacker. Most notably, who is going to suffer the consequences if it gets blacklisted? You, and the hacker can just find another victim.
While some websites are used to host malware, the majority are simply part of a redirection chain, making it harder for the authorities to find the culprits. As such, the site’s main purpose is to redirect your legitimate visitors onto malicious sites. One way this is done is by hacking a core Apache file called .htaccess. This file serves multiple purposes and can, in fact, be configured to keep the bad guys at bay. At the same time, it is the file of choice for any hacker to plant its malicious redirection code. Most people who own a website will probably never have heard of .htaccess, that is, until the day they get hacked.
Figure 7: Malicious Redirect Code Within The .htaccess File
The picture above shows a typical redirection also known as a conditional redirect. The condition is that the visitor to your site must come from one of the sites (mostly search engines) above. If the condition matches, then the rule is to send the visitor directly to the bad guy’s site. This little trick works really well to keep the redirect under the radar from you, the website’s owner, who most likely will always enter the URL to your site directly, without visiting a search engine to access it.
One other method to redirect traffic is to hack your site’s CMS (Content Management System). If you use WordPress or Joomla!, you know they require PHP, a universal server-side scripting language. The core PHP files can easily be injected with malicious content in the same fashion a Windows file can be infected with a virus and still work normally. In many cases the malicious code is inserted either at the top or the bottom of a page, but this is by no means a standard.
If you browse to your site and view its source code, you might see something like this:
Figure 8: Injected Code Used To Push Malware Found
If you access the infected file directly from your server (via FTP/Control Panel/SSH), you might see this:
Figure 9: A Malicious Obfuscated Script
The reason you see something different is that PHP, being a server-side scripting language, will render the page to the client (whoever browses your site from the outside) without exposing the underlying code.
Regardless, the bad guys love to use encryption or encoding and in particular base 64 encoding. The goal is to obfuscate the code enough to make it harder to really know what it does, especially if you were to do a string or pattern search. Besides, base 64 is also used for legitimate uses, so one cannot completely label it as bad without generating false positives. There’s a cool service offered by Sucuri that lets you deobfuscate base 64 and other encodings; check it out here.
Rogue modules and rootkits
The bad guys want to establish a long and undetected presence on your website. Hacking the .htaccess file or your PHP files is too obvious and can be cleaned up too easily. For this reason, we are seeing more and more advanced malware binaries and even rootkits that are much harder to identify and remove.
Hacking an entire web server might require more work but also pays off in a big way. After all, why would bad guys waste time hacking one website at a time when they can control hundreds or even thousands by compromising a single server box where they are all hosted.
In recent news, we have heard of such compromises affecting Apache with, for example, the Linux Cdorked backdoor. What we are seeing are more sophisticated website compromises with on-the-fly malicious payloads delivered only once to the same victim, with advanced mechanisms built in to defeat crawlers and honeypots in order to evade detection.
Just last week we heard German web hosting company Hetzner was hacked and customer data leaked. The report indicates the attackers had used a never-before-seen rootkit with a backdoor component. This shows how quickly the bad guys are climbing up the chain and one can only imagine the potential of hacking at the source.
So what does Linux malware look like? If you ever get your hands on a sample, you can first analyze it statically. In the example below, we will take the now famous Cdorked backdoor, responsible for those stealthy Apache infections. When the file first surfaced it was practically undetected, only slowly getting more generic signatures from major antivirus vendors once it was made public. Truth be told, harvesting such malware is difficult and requires root-level access as well as cooperation from the hosting providers.
The file command in Linux will show you the binary format (ELF) and that it was compiled for a 64-bit processor.
Figure 10: The File Command Reveals Information On The Binary
If you are interested in checking out its sections, another command (objdump –h filename) will list them all.
Figure 11: Looking At The Binary’s Sections
Of all these sections, the following are the most important:
- .text: It contains executable code.
- .rodata: It contains string constants.
- .data: It contains initialized data.
- .bss: It contains uninitialized static variables.
Another nifty command can show you a strings dump: strings filename | more.
Figure 12: A Binary String Dump
While it is no guarantee, you can sometimes get an idea of what’s in the code. But there is nothing like disassembling the file to really get to its core. This is a more tedious and lengthy process which we will not get into right now. However, know that all of this can be achieved with either native Linux commands and some additional open source programs.
Parting thoughts
As you can see, web server malware has evolved through the years, just like its traditional client-side counterpart. When major hosting providers who supposedly invest a lot of money and technology get hacked, one has to wonder if we can ever really be protected against cyber-criminals. The truth is that for the most part, if you run your own website and perform (or have a company perform) on-going maintenance and prevention, you are most likely safe. In the security field you can never say never, which is why backups are so important when something does happen.
The majority of websites that do get hacked all show failures in one or several areas such as weak passwords, a poorly configured system never updated since it was implemented and a hosting provider that is cheap in all aspects. To some extent, you could compare your website to your car. If you put the cheapest gas in it, never take it to the mechanic for maintenance and always leave it unlocked, you are likely to run into some issues.
Helpful links:
StopBadware: StopBadware.org with its community forum BadwareBusters.org is dedicated to fighting web malware and educating people on the issue. It also operates a large URL ClearingHouse for infected websites. Malwarebytes is one of the StopBadware’s Sponsoring Partners.
Google Webmasters Tools: While a lot of people are angry when Google blacklists their sites, there is usually one or more good reasons why it happened. This is a must-go-to resource if your site is infected and you are on the road to recovery.
Sucuri SiteCheck: This free scanner will inspect your site for malware as well as check if it is already on any blacklist.
RedLeg: There are some good Samaritans out there, people dedicated to helping out others in forums. This is the case with this individual who also provides a ton of useful tips on his site.
