File Change Detection and Remediation

Today we are going to talk about something a bit less technical than our last post, but also very important for anyone that manages a website: how to detect and address file changes. Why? Well, reviewing your file changes is one of the best ways to detect and prevent your website from infections and hacking. When your website is hacked, the attacker or the malware could either change original files on your website or add new ones. Checking and monitoring any file changes on your server will allow you to take action right away in case anything suspicious happens. We’ll discuss how exactly how we can do that with more details in this post and share with you some tips and tricks for staying on top of changing files.

Fortunately, we don’t have to do this manually. Today there are tools like CodeGuard and many plugins that can help you track file changes automatically for sites built with WordPress, Joomla, Drupal, or anything else.

A little bit about hashing

To explain how file monitoring software works I’d like to first talk about cryptographic hash functions a.k.a. hashing. You might not know what this is, but I can assure that you have used it at least once in your life. 

“A hash function is any function that can be used to map data of arbitrary size to data of fixed size” – Wikipedia

What a hash function does is produce a unique string of letters and numbers that represent the input file. If you’ve heard the terms checksum, digest or signature, the value that the hash function returns is similar. These functions are very common in the security world and they are used to validate integrity and authentication. The most common hashing algorithms are MD5 and SHA, which have many versions like SHA-1, SHA-2 and even SHA-3 which was released in 2015 by NIST. Although MD5 and SHA-1 are not considered safe anymore to be used as cryptographic hash functions, they are still widely used as a checksum to verify data integrity, which is exactly what we need here.

Read More “File Change Detection and Remediation”

Stay on top of your website with new ChangeAlerts

New ChangeAlerts Help You Track File Changes

Last week, we released an update of our ChangeAlerts, a feature many of our customers value more than our secure cloud website backups. ChangeAlerts notify you when something on your website has changed, and are invaluable for detecting if your website has been compromised. URL redirects to scam sites, drive-by-download malware, and Blackhat SEO Spam (“Pharma Hack”) all rely on changes to your files. And with ChangeAlerts, now you will know if you have been victimized.

The ChangeAlert email summary is intended as a quick way to gain insight into what is happening on and to your website. If anything appears unusual, view the detailed information available once you have logged into your website. This is an abbreviated email summary and not exhaustive.

CodeGuard ChangeAlert

Key Sections: Backup Total, Overview, Website Files, Media Files and Other

Backup Total: High-level for all files

Under the Backup Total section of the ChangeAlert, the summation of files added, modified, and deleted is displayed. This provides a quick snapshot of what is going on with your site.

Overview: static and Dynamic File Granular

The Overview section provides more granular information into important static and dynamic files you should keep your eyes on. Static files are those rendered in the browser, while dynamic require a server to generate the output. Depending on your website and configuration, there are likely other file types that are important to you. This list is not exhaustive, but serves as a starting point for the vast majority of our customers. Html, css, javascript, htaccess, php & ruby files are those we place in the abbreviated overview. If any of these change and you or your developer did not change them, contact us immediately as you may have been hacked.

Website Files: Individual file Listing

In this portion, you can view the names of the files that have changed. The old ChangeAlerts resemble just this portion – pure additions, deletions, and modifications, along with the truncated filenames. We will list up to ten of the file changes here, with the rest viewable upon logging into codeguard.com.

Media Files and Other: The rest of your content

Changes to images and video files are much less likely to be problematic, and therefore, are listed last. In this portion, you can view images, videos, and all other file types, which are grouped under “Other”.

ChangeAlerts provide industry-leading visibility into how the content on your website is changing. Stay on top of your site, and gain peace of mind, knowing that if a site is compromised or a malevolent employee defaces the site, you will be the first to know it.

-David

WordPress Brute Force Attacks: Protect Yourself Now

WordPress Brute Force Attacks: Quick Simple Solution

Protect yourself by limiting wp-login.php to your IP address

WordPress Brute Force Attack

If you are a WordPress user, this is all you need to know – the WordPress brute force attacks that occurred last week can be mitigated with one simple technique: restricting which IPs can access your wp-login.php page. That’s it. The reason last week’s WordPress brute force attacks were so effective is that rather than one single computer IP address attempting to guess your password, tens of thousands were used, which means that the attack could occur without sounding some of the traditional alarm bells.

But why risk relying on security plugins that may fail you when you can fix things yourself? And why install new software when the fix will take 2 minutes? Lastly, why rely on subpar solutions that can still cause your server to crash, due to the strain of rendering the wp-login page? How about you implement a solution that almost effortlessly rejects the unwanted advances in the most resource-effective way.

This is all that you need to do to protect yourself from a WordPress brute force attack:

  1. Identify your IP address (http://www.myipaddress.com/)
  2. Log into your server via FTP/SFTP or your hosting control panel’s file manager. HostGator’s file manager is below.
    HostGator File Manager
  3. Navigate to your .htaccess file (If it doesn’t exist, create it with a text editor)
    HostGator .htaccess
  4. Add this to the beginning (replacing the xxx.xxx.xxx.xxx with your ip):
    <files wp-login.php>
    order deny,allow
    deny from all
    allow from xxx.xxx.xxx.xxx
    </files>

Verify that your wp-login page cannot be accessed from a computer other than the one you are using. To do this, try using your phone or a friend’s computer. We are not claiming that this will protect you from all of the nefarious characters on the internet. This will, however, protect you completely from a WordPress brute force attack. Thanks to James Dunn from wpmu.org for providing much of the guidance.

Background Information

Last Thursday, April 11th 2013, hundreds of thousands (at least) of website owners across the globe became victims of a sophisticated attempt to gain access to the portions of their webservers controlled by the WordPress Content Management System (CMS). WordPress is installed as a subordinate on the Linux operating system, usually below software used by shared hosting providers to provide control panels. The leading software used is cPanel and Plesk, produced by cPanel, Inc, and Parallels, Inc, respectively. Custom made hosting software is also used by hosting providers. Notable users of each type:

  • cPanel: HostGator, Namecheap, WebHostingBuzz, BlueHost, A Small Orange
  • Plesk: Hostmysite.com, Media Temple
  • Custom-made software (GoDaddy, DreamHost, Endurance International vDeck properties: FatCow, iPage, etc). 

Vulnerabilities exist at each level of software installed: server (Linux), hosting provider (cPanel), and CMS (WordPress). I want to mention each level before focusing on the CMS and WordPress brute force attacks. To address only the CMS does a disservice, since a false sense of security can be created by closing every single window in the house if the front door is left open.

Server/Operating System/Hypervisor Vulnerabilities

Protection at this level is absolutely the responsibility of the hosting provider. WordPress users have no ability to control this, and only through picking a hosting provider focused on security can vulnerabilities at the hardware, operating system, and hypervisor be addressed. This equipment and software serves to create the base layer for hosting provider software to run.

Web Hosting Control Panels: cPanel, Plesk, vDeck, Custom

Locking down the control panel may be the responsibility of the hosting provider, or if you are running a VPS or dedicated server, it’s on you. Vulnerabilities do exist at this level, and have been exploited. Thousands of sites were hacked after a Parallels Plesk exploit was utilized – http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-of-sites-hacked. It is common knowledge that no system is impervious, and that as software increases in usage, the benefit to hacking it increases to miscreants. Software exploits, while possibly indicative of poorly written code, are more often a sign that the software has become popular enough to be a target.

Content Management Systems: WordPress, Joomla, Drupal, etc

All content management systems have vulnerabilities. WordPress brute force attacks, however, just come knocking at the front door, again and again. By simply guessing at a website owner’s username and password, the only restricting factor is the speed the website owner’s computer can respond “Yes” or “No” and the speed at which the attacker can make requests.

CBS MoneyWatch Blacklisted by Google

On Wednesday, April 20th, CBS MoneyWatch, a ZDNet sister site, was blacklisted by Google for malware hosting.  Larry Dignan, Editor in Chief of ZDNet and SmartPlanet, as well as Editorial Director of TechRepublic, reported that the engineering team at ZDNet was furiously trying to figure out the root cause of the issue, to no avail.  Ultimately, the team concluded there was no malware on their site and the blacklisting was due to a false positive.  This is an interesting conclusion – was there a false positive, or was Google correct and now that the issue has been remediated, is ZDNet trying to prevent a media disaster?