Shamlessly grep’d from the http://www.hackerfactor.com/blog/ There be good stuff here…
I’m not an electrician. While I am pretty confident that I can change a light bulb or plug something into an outlet, adding a new electrical outlet or installing a new light into the ceiling of my office is beyond my skill set.
Much of the software on the Internet is like the ceiling light in my office. Regular users know how to push the install button, configure colors, edit blog entries, start new forum topics, and even add in plugins. However, your typical user cannot develop a new plugin or know how to do much more than use the software as it was intended. (They are users, after all.)
The problem is, default installations are usually not secure installations. Even if there are no known vulnerabilities, new ones are discovered every day. Software that is secure today may not be secure tomorrow.
In my previous blog entry I wrote about a really simple way to lower your threat profile. By hiding the software version, you deter automated systems that scan for vulnerable systems. However, hiding your version doesn’t stop blind attacks.
The Blind Attacker
When attacking a system, most people follow Sun Tzu’s The Art of War: Know your enemy. This means conducting reconnaissance before attacking. With a blind attacker, they forgo reconnaissance. A blind attacker will try an exploit and then check to see if it worked — without first looking to see what they are attacking.
On the Internet, most attacks are performed by automated software; they are not manual. Automated blind attacks are the most common type of attacks. At any given moment, hundreds of thousands of computers are infected with malware and slinging attacks blindly across the Internet. Usually you won’t notice because the attack wasn’t appropriate for your system, but every now and then a blind attack succeeds. (It’s the spaghetti test method: If you throw enough noodles against the wall, something might stick.)
Methods like hiding your software version won’t stop a blind attacker. So we need to do something more.
Patch!
It might sound obvious, but you need to periodically patch and update your software. Unlike your PC, your blog, wiki, and online forum software probably does not have an auto-update feature. Patching and upgrading your web software is like changing the oil in your car. If you don’t do it periodically, then it isn’t a question of “if” it will fail; it will fail. The only question is “when”.
Most popular web software packages have lists of updates and changes. WordPress has their security and release information in blog format, as does Serendipity. Docuwiki keeps a list of changes, and MediaWiki uses a low-volume mailing list to actively keep users advised of changes.
How often to patch is up to you. If you change your car’s oil every three months, then that sounds like a good minimum effort. If you run a high-volume site, then monthly or weekly is probably good. And if you run a massive site, like Amazon or Wikipedia, or consider your site to be mission critical (or run a high target site, like a security geek who blogs about security tips), then daily checks with scheduled updates is definitely the way to go.
Finally, if you choose not to patch, then you should have a good reason beyond “it isn’t convenient”, “it’s too much work”, or “I don’t know how”. And frankly, there are not many good reasons. (If your wrote your own code, if you have undergone a government Orange Book (TCSEC) audit and have received an A1 rating, if your system is not on the Internet, or if you have enough security layers that a direct attack is improbable, then you can delay patching. Otherwise, you must remain vigilant.)
Moving Footholds
While patching will stop attacks that are known, it won’t stop an 0-day exploit. A zero-day (or oh-day) vulnerability is one in which there is no patch currently available. (The count refers to the number of days after the vendor starts working on a patch. No patch means day zero.) Patching also won’t help you during the time between when a patch exists and when you apply it.
Blind attackers succeed because they know about a vulnerability and how vulnerable systems are configured. To stop blind attackers, you just need to change the system enough that it looks different from the expected configuration. The attacker looks for a foothold, and fails to make contact.
Common footholds come from CGI scripts that process user input. If your PHP or ASP web page has a form on it, or allows users to select dynamic content (not a static HTML page), then that is a potential foothold. To make the system look different, we just need to remove the target.
As with other forms of Security by Obscurity (SbO), this doesn’t remove the vulnerability. However, this approach is great for stopping blind attackers.
Don’t Ask, Don’t Tell
One common type of attack is to go after login pages. If you can guess the login, then you can gain access to the system. Blogs, wikis, and other web software usually have login links on the page. This allows the administrator to get into the system and modify content.
The typical SbO approach is to hide the login link. This way, humans won’t stumble across it. Frankly, unless you expect lots of other people (“lots” meaning “all of your customers”) to login, there is no reason for this to be public. Copy the login URL to your web browser’s bookmarks, and then remove the login link from your page.
For example, the City of Albert Lea, Minnesota uses WordPress 2.8.4 (found in the the source of their HTML content). At the bottom of their web site is a Log in link. There is no reason for the general public to see this link. Having it present is an attractive nuisance.
If the bare minimum you can do is to remove the hyperlink, then the intermediate solution is to move the link. If your link is http://www.cityofalbertlea.org/wp-login.php, then rename “wp-login.php” to something else (e.g., supersecret-login.php). Now attackers don’t see the link (because you took it off your page) and if they take a wild guess then they will guess wrong. For WordPress users, you can find a great writeup of files to rename at the blog Peter’s Useful Crap.
For the really advanced users who don’t have any/many remote users with login access, you’ll need to do a little programming. Keep a list of network addresses that are permitted to connect to the login page. Modify the login script to make sure that the user is coming from a permitted network address. This introduces two-part authentication: something you know (your password, the URL to the login page), and something you have (your network address). Even if some malware infects your computer and sends your password to Russia, the Russians won’t be able to login to your site from a remote location.
With this advanced tip, you begin to lock down your site. Even if an attacker knows the URL to the login page, they cannot login because they will be coming from the wrong network address. Of course, you won’t be able to login from a coffee shop, but I view this as a good thing — coffee shops are usually not secure network connections. (Which is more important: your company’s reputation and web site’s security, or your mocha latte frappachino grande?)
Remove Default Samples
Most software packages include sample scripts and templates that are used to illustrate various features or configuration options. Remove these examples. If you’re going to use the features, then use them in your customized templates or personalized pages. You don’t need the example files on a live (Internet accessible) server. The only thing these examples do: they provide potential footholds for blind attackers.
For example, http://psort.mirror.edu.cn/ currently has the default installation page for the Apache web server. This includes all of the manuals for Apache and some of the default CGI scripts. This server has not been configured, so if you happen to know an exploit for an unconfigured Apache server, then this is a good target. However, if the owner did configure the main web page, they might still forget to remove the default documentation and scripts. It only takes one exploit of a default file to take over a system.
For a couple of years, security guru Johnny Long maintained Google Hacking Database (GHDB). Using Google, he searched for standard files and default configurations that are vulnerable to everything from information leakage to cruel exploits. Although the GHDB is no longer maintained, it still serves as an excellent example for why you should not keep default sample scripts and templates sitting around on a publicly accessible server. (GHDB contained much more than exploits from default scripts, but we’ll get to system hardening in a bit.)
Next Up?
When I follow up with simple system hardening next Tuesday, I will dive into some lockdown options. Some of this information will also be covered at my up-coming “Fort Collins Internet Pros” presentation on the 16th — “Htaccess configurations and turning your htaccess file into an application firewall.”
