Recently a friend came to me and told me about a scenario which he had used to deploy his web application. He had built his application using PHP on Apache. There was a front-end server directly accessible to the internet and a back-end server only accessible to the front-end server. The PHP application deployed on the front end server included PHP files kept on the back-end server and showed it on the browser. The included PHP files were hard coded in the code of the PHP application running on the front-end server and this front end application took a GET parameter as input. Now, this scenario kind of caught my interest. I recently read about HTTP parameters pollution and I thought this attack might work in this case. So I began digging and experimenting. And I came up with a demonstration which shows how will this attack work when someone is using a setup similar to the setup described above to bypass a hard coded value in the code. I know this is not recon stuff ,but still its interesting.. 😉
We will see 4 PHP codes here :-
1.) hpp.php – The main application deployed on the front-end server, which remotely includes a PHP code (cms.php) kept on the back-end server.
2.) cms.php – A PHP code kept on the back-end server which receives an input from hpp.php in the “function” parameter and includes a PHP code (set to normaluser.php) meant for a normal user locally.
3.) normaluser.php – A PHP code kept on the back-end server meant for a normal user and included by cms.php .The ping command was set in this case to show that the normal user can only use the ping service.
4.) adminuser.php – A PHP code meant for an admin user. This code can run any OS command directly to show that this code really is for the admin 😉 .
Second Order SQL Injection :-
I always thought that escaping single quotes in a string based user input used for database transactions will prevent SQL injections..but this is not always the case when single quotes are escaped inconsistently (as we will see in this blog).
Say hello to SQL injection of the second order !
Basically second order SQL injections take place when one functionality of a web application takes a user input from a user, escapes (not strips) all SQL metacharacters and inserts that data input into a database. Next, some other functionality of the same application uses that data to craft another SQL query to do a database transaction without escaping that data first (bad idea!). The database transaction done by the second functionality introduces a SQL injection bug in the web application known as second order SQL injection.
I have’nt heard of any Second Order SQL Injection Attacks on real world targets, so decided to make up an example attack myself. Following are the two functionalities with their respective codes (select.php and insert2.php).
The first functionality inserts data into the database. The second functionality uses the data inserted into the fname column to craft a SQL query and get data from the database and show it on the frontend. For making it easy to understand, all the SQL queries run by the web applications are also shown on the frontend.
Hi all, recently one of my friends pointed out an article at http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-of-sites-hacked/ which mentions how underground hackers are selling 0-day Plesk exploit for thousands of dollars. It so happened, that we guys were performing a penetration test for a client who seemed to have a plesk server used as a control panel for managing servers. The server we were targeting was running a plesk 8.6.0 version on windows 2003 OS (got through OS fingerprinting and other banner grabbing). This version seemed to be quite old and the vulnerability existed for versions prior 10.4. Since we were not getting anywhere with the normal penetration tests (as almost everything was patched), we decided to take a look if we can compromise the server in some way using the plesk installation itself. First we created a default installation of Plesk 8.6.0 on a windows 2003 machine to test it in our lab. Next, we started going through the plesk developers and API manuals, which gave us a hint at where we should start poking first.
The API RPC protocol was designed to support interaction between Panel and third-party software remotely. To perform an operation through API RPC, you should send a specifically-structured HTTP message to a particular Panel endpoint (https://site:8443/enterprise/control/agent.php). Panel receives the message, transforms the message to operation instructions, attempts to perform the operations, and returns operation statuses and details.
To process an API RPC operation two HTTP request headers are required – HTTP_AUTH_LOGIN and HTTP_AUTH_PASSWD . It is pretty self explanatory what the two headers are meant for , i.e. HTTP_AUTH_LOGIN has to have a valid username and HTTP_AUTH_PASSWD has to have a valid password to perform an API RPC operation. Now, the vulnerability is triggered when SQL meta-characters are injected within the header HTTP_AUTH_LOGIN , i.e. the API RPC endpoint is vulnerable to a SQL injection which is triggered while processing the HTTP_AUTH_LOGIN header. When we first injected the header, the SQL error returned a JET DB error and we almost jumped out of our chairs cause this vulnerability was so easy to find. Since, we don’t have so many options with JET DB , we reinstalled Plesk with custom installation and created two different systems; one running plesk with MSSQL as backend db and another running MySQL as backend db.
The following snapshot shows the SQL error when we trigger the vulnerability:
In the previous post on metasploit, we did a basic penetration test of a network using the WebUI of Metasploit. In this post we will see how metasploit can help us in identifying systems in a network that do not follow a strong password policy. Basically, we are going to use the scan and bruteforce option of Metasploit WebUI to accomplish this task.
First we complete the project creation process.
Now we click on the scan option of the discovery module and fill in all the project related settings.
“Session Hijacking attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token. Because http communication uses many different TCP connections, the web server needs a method to recognize every user’s connections. The most useful method depends on a token that the Web Server sends to the client browser after a successful client authentication. A session token is normally composed of a string of variable width and it could be used in different ways, like in the URL, in the header of the http requisition as a cookie, in other parts of the header of the http request, or yet in the body of the http requisition.
The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the authenticated parts of a web application.” – (https://www.owasp.org/index.php/Session_hijacking_attack)
The following figure shows a normal web application login page. Using this login page a normal user as well as an admin user can log into the application.
The following figures show the menu screen that is shown to the normal user or the admin user after they log in.
Many a times we have to find weaknesses in networked systems that arise due to a lack of applying critical patches. In cases like these we can use Pen testing tools to quickly find vulnerabilities like these. Metasploit is a Pen testing framework that offers a wide array of penetration testing tasks in an automated way. Metasploit also has an easy to use Web user interface that helps beginner users to extract a large percentage of its potential easily.
Metasploits WebUI login panel looks like the following.
After we login using our credentials we get the following screen, wherein we can create new projects.
Remote File Inclusion
What is RFI:-
RFI stands for remote file inclusion and it is an attack to execute malicious scripts on a server and the script to be executed on the vulnerable server is hosted on a web site on the internet.
Remote File Inclusion attacks allow malicious users to run their own PHP code on a vulnerable website. The attacker is allowed to include his own malicious code in the space provided for PHP programs on a web page. For instance, a piece of vulnerable PHP code would look like this:
include($page . ‘.php’);
This line of PHP code is then used in URLs like the following example:
$page variable is not specifically defined, an attacker can insert the location of a malicious file into the URL and execute it on the target server as in this example:
include() function above instructs the server to retrieve
C99.php from the remote server and run its code. This is possible because PHP allows the user to load both remote and local content with the same functions. The code sample above does not perform any checks on the content of the
$page variable, it blindly passes it to the function. Because the original piece of code appended
.php to the file it would try to fetch the following URL:
As the attackers can not know what the original code might append, they put a question mark at the end of the URLs. This makes the script fetch the intended file, with the appended string as a parameter (which is ignored by the attacker’s script):
This allows the attacker to include any remote file of his choice simply by editing the URL. Attackers commonly include a malicious PHP script called a webshell, also known as a PHP shell. A webshell can display the files and folders on the server and can edit, add or delete files, among other tasks. Scripts that send Spam are also very common. Potentially, the attacker could even use the webshell to gain administrator-level, or root, access on the server.