Hacking x2

Now that I've established a little information on hacking and hackers, I'll update with some information that shows the procedures of hacking, and the dangers of being hacked. Once again, I will use publicly available material as references.

Injections

Not the kind that that was developed to rip off your insurance company, but the type that alters database and scripting code to allow admittance to otherwise locked sites. This is one of the more simple hacks, and requires surprisingly little skill. It does require that the target system lack necessary security and sanitation code. However, because many admins and webhosts are rather lazy, these hacks have remained useful for quite some time.

SQL Injection

A SQL (pronounced "sequel") Injection relies on the very basic database programming msSQL or mySQL to implement. Note that SQL is not the only language used for databases, but is quite common. It uses plain English (or country of choice) commands, such as "Select fieldlist from table ... etc etc"

These commands are entered from exposed fields on the internet. If you have ever seen a page that asks for your user name and password, for example, you are possibly looking at a SQL form. When you enter your user name and password, the database compares it to a field of user names, and then the password associated with the typed user name. If they match, you are allowed access. If not, you are given an error message.

Think of it as an excel spreadsheet. Each row corresponds to a certain type of data. So row one might be your user name, row two your password, and row three your email. When you type your user name, it finds that unique user name, and then checks to see if the password you entered is the same. If it returns true, you are allowed access.

Because SQL cannot interpret by itself if a benign user name and password was entered, or if another, malicious SQL command was given, it simply carries out the orders as it was designed to.

So an attacker will first begin by establishing these things:

1. Is this a SQL Database? If yes, skip to 2. If no, Skip to end
2. What is the field name for "username"
3. What is the field name for "password"
4. What is the field name for "email"

To establish if the target uses a SQL database, the attacker will feed it a short SQL snippet. Remember that a SQL database will understand any SQL commands, even if it can't run them or they produce an error. What is typed into the login field is not important, after all, passwords are used as the universal key, user names are merely a reference point. In the password field, a command such as x' or '1'='1 will be typed.

In any SQL database, when a comparison is called between two fields, if they match a value of true will be returned. Because "or" automatically interrupts the search, 1=1 is tacked onto the end of the resulting search. The password is most definately not "x" but before the database returns false, it reads the "or" statement and the subsequent "1=1." This statement, is of course, true. Because the database is looking for a true answer, not a false, it pushes the "true" value.

Now, you might think it silly to have the database "look" for a true answer instead of being stoic and neutral. However, you must think about a query in conventional terms. Say you are going to the grocery store to buy a gallon of milk. When you ask a sales clerk where the milk is, you do not say "where is the milk not?" He would have to take you to every part of the store the milk is not at before you could determine where the milk is. Instead, you ask "where is the milk?" Now he will take you to the precise location the milk is kept. Keep in mind that there is not a single jug with "milk" stenciled into it, but all forms of milk. He cannot tell you where the 2% milk is unless you ask him specifically.

The initial discovery of the milk would result in a return of "true." You can, of course, refine your search if possible, but the point remains.

Now, using this analogy, imagine you went into Sears and said "Where is the milk or drills?" The clerk would tell you that there is no milk, but he will not then tell you to go away. The "or" statement will inspire him to take you to the drills. There was no milk, but the query for drills returned true.

So, if the attacker initiates an injection such as x' or '1'='1, the database must respond. To do this, the attacker can use the "mail me my password" feature. Though there are other ways to do this, it must be a method that will return some sort of value. Remember that the attacker will be unable to see the actually SQL code.

Let us say that the return was "We have sent you an email with your password in it." This will tell the attacker that they have found a SQL database, and what's more, it is not "sanitized." That is, there is nothing checking the code before it is executed to ensure that an attack is not occurring. Keep in mind that this is executing code in the database, so someone was just sent an email with steps to recover their password. Just as no systems can keep hackers out, no hackers can crack undetected. There is always a log, some trace to tell they were or are working.

Okay, so the attacker knows this is a SQL database with little or no security. Now they need to build an image of what the database looks like in their mind. Though it is better to use a pen and paper or open a text document. Each field has a unique name. The password list, for example, may be password, passwrd, pword, secret, etc. Each field that must be exploited by the attack must be named. There is no easy way to do this, but almost all databases use the same basic words to denote the field. This is again attributed to the laziness of the designers or admins.

To begin this, the attacker will change the code slightly. Now it will look more like x' AND password IS NULL; --

AND is substituted for OR, because we don't want it to return true. This is especially true when working with the email field. The attacker doesn't want 10 change of password emails going out to all 10,000 people in the database. If an error such as "missing syntax" is returned, its the wrong field name. However, if the attacker gets a response such as "no match found" then they know it is the correct field name. The three most important fields for the attacker to acquire are "logon/user name, password, and email. Other fields can be found this way, but they really serve no purpose. Once the attacker has access to all the resources by hacking into the system, they can acquire the same information in a fraction of the time.

Now that the attacker has figured out the correct field names, they are ready to move on to gaining full access. To do this, they must either guess a password, or use a much easier method of overriding an existing user and changing their password with a SQL injection.

Note that the attacker may have access to one SQL database, but it may not be the database that stores login credentials. To verify this, first the table name must be acquired. The code for this is x' AND 1=(SELECT COUNT(*) FROM tabname); --. Note that the attacker must guess the table's name, however, as usual the names are generally obvious. Members, users, etc. The command x' AND tabname.email IS NULL; -- wil l verify that this is in fact the table that is being actively used for login credentials.

After all this is settled, the attacker will need a valid login. Remember that this information is readily available. Many sites set the user name to match the account name. On a forum, for example, the name you login with is the name that is displayed when you post in threads. Also some variation will be used for the real name of the webmaster or contact listed on the website.

Using that user name and the command:
x';
UPDATE listname
SET email = 'victim's@email.com'
WHERE email = 'youremail@email.com

The attacker injects the command to change the table, deleting the original email and substituting it with theirs.

Now the attacker simply initiates the "reset my password" function, and it sends the password reset link to their email.

They now have full administrator privileges to the system, or the credentials of another user which they can cause havoc with. At their victim's expense, of course.

A written source for this can be found here

Here are some video's of the attacks in action:







So...

Consider this a warning! Don't be lazy. Nobody can guess a password field named "Iowatachata" ... okay, so you aren't likely to tell your boss that you changed all the SQL fields to random sesame street characters. You can, however, sanitize the input so that only characters which are allowed for passwords can be entered into the database. The characters =, ;, and ' should never be valid characters for passwords or user names. Ensure that they will be rejected.

There are many more steps to securing a SQL database. However, as with all security operations, the methods of securing a system is far harder than the methods used to break the security.