How They Hack Your Website

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.

As we saw above, access to the database raises a number of interesting

possibilities. The database structure can be mapped by a skilled hacker

through ill-conceived visibility of error messages — this is called

database footprinting — and then this knowledge of table names and so

forth can be used to gain access to additional data. Revealing error

messages are manna - they can carry invaluable table name and

structural details.

The following illustrative string is from Imperva.

http://www.mydomain.com/products/products.asp?productid=123 UNION

SELECT username, password FROM USERS

There are vast swathes of information on SQL Injection available, here

are a couple of good sources:

GovernmentSecurity.org

SecurityDocs.com

Cross Site Scripting (XSS)

XSS or Cross Site Scripting is the other major vulnerability which

dominates the web hacking landscape, and is an exceptionally tricky

customer which seems particularly difficult to stop. Microsoft,

MySpace, Google… all the big cahunas have had problems with XSS

vulnerabilities. This is somewhat more complicated than SQL Injection,

and we'll just have a quick look to get a feel for it.

XSS is about malicious (usually) JavaScript routines embedded in

hyperlinks, which are used to hijack sessions, hijack ads in

applications and steal personal information.

Picture the scene: you're there flicking through some nameless bulletin

board because, yes, you really are that lazy at work. Some friendly

girl with broken English implores you to get in touch. 'Me nice gurl',

she says. You've always wondered where those links actually go, so you

say what the hell. You hover over the link, it looks like this in the

information bar:

[%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…]

Hmmm…what the hell, let's give it a bash, you say. The one thing I

really need right now is to see an ad for cheap Cialis. Maybe the

linked page satisfies this craving, maybe not. Nothing dramatic happens

when you click the link, at any rate, and the long day wears on.

When a link in an IM, email, forum or message board is hexed like the

one above, it could contain just about anything. Like this example,

from SandSprite, which helps steal a session cookie, which can

potentially be used to hijack a session in a web application, or even

to access user account details.

Stealing cookies is just the tip of the iceberg though — XSS attacks

through links and through embedded code on a page or even a bb post can

do a whole lot more, with a little imagination.

XSS is mostly of concern to consumers and to developers of web

applications. It's the family of security nightmares which keeps people

like MySpace Tom and Mark Zuckerberg awake at night. So they're not all

bad then, I suppose…

For additional resources on this topic, here's a great overview of XSS

(PDF) and just what can be accomplished with sneaky links. And here's

an in-depth XSS video.

Authorization Bypass

Authorization Bypass is a frighteningly simple process which can be

employed against poorly designed applications or content management

frameworks. You know how it is… you run a small university and you want

to give the undergraduate students something to do. So they build a

content management framework for the Mickey Bags research department.

Trouble is that this local portal is connected to other more important

campus databases. Next thing you know, there goes the farm

Authorization bypass, to gain access to the Admin backend, can be as

simple as this:

Find weak target login page.

View source. Copy to notepad.

Delete the authorization javascript, amend a link or two.

Save to desktop.

Open on desktop. Enter anything into login fields, press enter.

Hey Presto.

Here's a great video of a White Hat going through the authorization-

bypass process on YouTube. This was done against a small university's

website. It's a two-minute process. Note that he gets into the User 1

account, which is not the Admin account in this case. Is Admin User 1

on your User table?

Google Hacking

This is by far the easiest hack of all. It really is extraordinary what

you can find in Google's index. And here's Newsflash #1: you can find a

wealth of actual usernames and passwords using search strings.

Copy and paste these into Google:

inurl:passlist.txt

inurl:passwd.txt

…and this one is just priceless…

“login: *” “password= *” filetype:xls

Such strings return very random results, and are of little use for

targeted attacks. Google hacking will primarily be used for finding

sites with vulnerabilities. If a hacker knows that, say, SQL Server

2000 has certain exploits, and he knows a unique string pushed out by

that version in results, you can hone in on vulnerable websites.

For specific targets Google can return some exceptionally useful

information: full server configurations, database details (so a good

hacker knows what kind of injections might work), and so forth. You can

find any amount of SQL database dumps as well (fooling around with a

Google hack while preparing this article, I stumbled across a dump for

a top-tier CMS developer's website). And a vast amount more besides.

johnny.ihackstuff.com is the man to go to for Google hacks. One

interesting one I toyed with invited me to the Joomla! install page for

dozens of sites… people who had uploaded Joomla!, decided against

installing it, and subsequently had either left the domain to rot, or

else set a redirect on the page to, say, their Flickr account (in one

case). Allowing anybody to walk in and run through the installer. Other

query strings target unprotected email/IM archives, and all sorts of

very sensitive information. What fun we can have!

Password Cracking

Hashed strings can often be deciphered through 'brute forcing'. Bad

news, eh? Yes, and particularly if your encrypted passwords/usernames

are floating around in an unprotected file somewhere, and some Google

hacker comes across it.

You might think that just because your password now looks something

like XWE42GH64223JHTF6533H in one of those files, it means that it

can't be cracked? Wrong. Tools are freely available which will decipher

a certain proportion of hashed and similarly encoded passwords.

A Few Defensive Measures

If you utilize a web content management system, subscribe to the

development blog. Update to new versions soon as possible.

Update all 3rd party modules as a matter of course — any modules

incorporating web forms or enabling member file uploads are a potential

threat. Module vulnerabilities can offer access to your full database.

Harden your Web CMS or publishing platform. For example, if you use

WordPress, use this guide as a reference.

If you have an admin login page for your custom built CMS, why not call

it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?

Enter some confusing data into your login fields like the sample

Injection strings shown above, and any else which you think might

confuse the server. If you get an unusual error message disclosing

server-generated code then this may betray vulnerability.

Do a few Google hacks on your name and your website. Just in case…

When in doubt, pull the yellow cable out! It won't do you any good, but

hey, it rhymes.

UPDATE

I had posted a link here to a hacking bulletin board containing

specific sql injections strings etc. The link pointed to a page which

listed numerous hacks targetting various CMS platforms, but containing

a disproportionate number of hacks for one platform in particular. In

retrospect, and following a specific complaint, I have pulled down this

link. Apologies to the complainant and to anyone else who found this

link to be inappropriate.