You are on page 1of 5

How they hack your website

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.
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.
http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT
username, password FROM USERS
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.
For additional resources on this topic, here’s a great overview of XSS (PDF) and just what
can be accomplished with sneaky links.
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.
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 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 Hardening_WordPress"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.