Wednesday, February 4, 2015

Application security and PCI-DSS

So, how does PCI-DSS affects our web application security testing or what to make sure the application is compliant with PCI, while doing the security testing.

Here are few requirements which needs to be taken case while testing a web application which handles financial data such as credit card information. As the PCI guidelines itself maintains that the application must be tested on regular basis in "Requirement 11: Regularly test security systems and processes."

But what should really we look for? The requirement 11 is tied back to other requirements Requirement 6.:

11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.

11.3 Implement a methodology for penetration testing that includes the following:

      11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

       11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

Now let's check Requirement 6.1 says:

6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows.

And what to test for:

6.5 Address common coding vulnerabilities in software-development processes as follows:

6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

6.5.2 Buffer overflows

6.5.3 Insecure cryptographic storage

6.5.4 Insecure communications

6.5.5 Improper error handling

6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process

6.5.7 Cross-site scripting (XSS)

6.5.8 Improper access control

6.5.9 Cross-site request forgery (CSRF)

6.5.10 Broken authentication and session management

Basically we need to test the web applucation for OWASP Top 10 vulnerabilities and addtionally we need to scan the servers and infrastructure for possible open ports, patches missing any other misconfigurations.

So basically, focus on Requirement section 6 while doing the testing.

Monday, January 12, 2015

Scanning Android devices with Nessus

There could be some instances where in you need to scan your Android devices with scanners such as Nessus etc to look for insecure/ unnecessary ports, services and misconfigurations.
There are two types of scanning- unauthenticated scan and authenticated scan. Unauthenticated scans are preatty simple, just provide the IP of the target to be scanned, but in case of an authenticated scan which is more comprehensive, you need to have some valid account created on the target device. So, how to run an authenticated scan on Android device? We don't have any IS level account on it.

One way to accomplish this is to create an ssh server on the device. Once the server is installed, it is very basic to run ssh commands remotely such as we do using Putty.

The steps are following:
1. Go ahead and download, install an ssh server. ssh servers such as SSHDroid, SSHelper etc can be installed. They can be installed via Google Play.
One is here:

2. Create an account on the server.

3. Provide the account credentials to Nessus for an authenticated scan.

Hope that helps.

Tuesday, December 9, 2014

Insecure configuration: Debug and Backup enabled in Android apps

It's a very trivial mistake a lot of developers do. They don't pay much attention to this simple looking misconfigurations which can be a big risk to apps. Generally they put much attention on other best practices such as intents, permissions etc, but tend to ignore the debuggable and allowbackup settings. I came across various such mistakes.

The app is debuggable, which means we can attach a debugger to the process and step through every single instruction and even execute arbitrary code in the context of app process.
Similarly, allowbackup is used to determine if to allow the application to participate in the backup and restore infrastructure. This leads to potential data leakage.

If not required, harden the configuration file by setting the values= “False”


Thursday, November 27, 2014

How to download flash content when entire page is loaded as flash

This is a tricky situation as you can't see the page source to look for the tags such as embed etc. All you see is the entire page loads as Flash content and plugins like InspectElement will not work.
I came across the similar scenario.
So, this is how we can sort out this issue. Every browser has flash plugins to display flash contents in the browser itself. So, if we disable the plugin the browser won't be able to display it within and will attempt to download it on harddisk, which can be used for security analysis.
Here how to do in case of Chrome. Just disable the plugin from the browser:

Tuesday, October 14, 2014

Sniffing on localhost/ localloop

Where Wireshark fails, this great tool comes into rescue. Just came across it, wanted to share. It can sniff any interface that has got an IP address, including (localhost/loopback):

Monday, September 8, 2014

Login page behavior

I came across a strange behavior in one web application.
In one tab logged into the web application and in another tab I accessed the login page again. I was thrown out of the first logged in tab too.
Is it desired behavior? I guess the session IDs are shared across tabs and and once logged in one tab can access any page in other tabs.
Let me know if you have any answer.

Tuesday, August 5, 2014

Login page insecure design

Sometimes we come across with the login pages which are not initially served over https, rather it's redirected to https. 
The second scenario is wherein, the login page is served over http but the login section in that page is loaded in a  frame, where the credentials are submitted over https.

Both can be considered as an insecure design as both are susceptible to MITM attacks.
Because the login form was loaded over HTTP, it was open to modification by a malicious party. Every link/URL present on that page (not just the form action) needs to be served over HTTPS. This will prevent Man-in-the- Middle attacks on the login form.
An attacker who exploited this design vulnerability would be able to utilize the information to
escalate their method of attack, possibly leading to impersonation of a legitimate user, the
theft of proprietary data, or execution of actions.

The best defense comes from user's perspective, where a user may directly access the website over https or he may book mark it.

For the second scenario, the whole page needs to be served over https, not just login section. 


The page loaded on http can be modified and inserted with JavaScript or phishing links: