Why you should develop a mobile app ?

  Why you should develop a mobile app for your business? Mobile apps are now integral part of almost every business, irrespective of their size and industry. Several small industries too have profited from developing mobile apps. While most small businesses have their own Website, it is...

5 tricks to be a successful app developer

Demand of Mobile Application Development is increasing day by day as there are different platform on which a Mobile App Development Company can Develop Applications as per Business Demand, If you’re just starting out, here are a few tips to be a successful app developer firstly...

Native Mobile Application Development

What is Native Mobile App Development? Screens are small, apps are big, and life as we know it is on its head again. In a world that's increasingly social and open-minded, mobile apps play an important role, & changed the focus from what's on the internet...

Exploring Plesk’s Unspecified SQL Injection Vulnerability

Proof of concept of Plesk Vulnerability CVE-2012-1557

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 vulnerability

From http://download1.parallels.com/Plesk/PP11/11.0/Doc/en-US/online/plesk-api-rpc/
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:


Antivirus Evasion with Metasploit Pro

Introduction AV Evasion has always been a topic of interest among security researchers as well as malware writers. Though less talked about, AV Evasion for a Penetration Tester too has paramount importance. For instance if you were to conduct a penetration test, you would want to...

Pentesting Networks for weak passwords using Metasploit

Basic Test Using Metasploit Penetration Testing Tool

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


“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.