Plynt Penetration Testing and Code Review Blog

Best Practices for Protecting Banking Sites

Tue, 16 Jun 2009 10:17:04 +0530

by Roshen Chandran

Terence Cornelius, one of our senior security consultants, has written an article on "Best Practices for Protecting Banking Sites" at the Bankers Online website.

Terence provides a 14-point checklist that banks can use to quickly ensure that their public facing websites are safe.

How frequently should an Application be tested?

Wed, 22 Apr 2009 14:19:47 +0530

by Binu Thomas

We are often asked how frequently an application should be tested for security. In this post, I'd like to discuss the criteria for determining the frequency of tests.

First, let's review the benefits of doing periodic penetration tests:

New attacks are invented regularly. Jeremiah Grossman compiles a list of new attacks invented each year. He counted 70 new techniques in 2008, 83 in 2007 and 65 in 2006. That's 15-20 new attack ideas each quarter. A periodic test keeps you current on all the latest attacks too.
New features (and bugs) are added regularly If your application adds new features regularly, then any of those new features could also introduce security holes. In our periodic tests, we've noticed that new holes are added almost every time new features are added. Periodic tests are useful to spot them.
There's more focus on the residual holes This not-so-scientific graph shows the pattern of open vulnerabilities after repeated tests. This is what we've observed after our periodic tests, and suggests that developers fix tougher, residual holes after the easier ones are fixed.

Based on these observations, here're the criteria we recommend for you to determine the ideal frequency for your security tests:

Sensitivity of the data: If your application handles sensitive data like credit cards, you're a more likely target for new attacks, so test the app more frequently.
Criticality of the Application: If your application is business critical, it's better to test it more frequently and reduces your risk.
Frequency of changes: If your application adds new features or undergoes changes regularly, test it more frequently.

Most of the sensitive applications under our care are tested quarterly. The less sensitive ones are tested once in six months. The less sensitive ones with no changes are tested only annually.

Plynt wins "Tomorrow's Technology Today" Award

Tue, 21 Apr 2009 18:36:17 +0530

by Sachin Varghese

The InfoSecurity Products Guide has awarded Plynt this year's "Tomorrow's Technology Today" recognition for application security certification. Thank you to the readers and editors at InfoSecurity Products Guide.

HP WebInspect is the winner in the application security tool category.

The full list is available here.

Lessons Learnt in Managed Risk Services

Mon, 20 Apr 2009 09:57:44 +0530

by Roshen Chandran

This week Jose Varghese and Agnelo D'Souza present the lessons learnt in setting up an enterprise risk management program at the RSA Conference. Jose is the Director of Paladion/Plynt's Managed Security Services and Agnelo D'Souza is the CISO of Kotak Mahindra Bank.

We discuss what worked and what did not in the 18 months when we designed and implemented an integrated security program. If you're at the RSA Conference this week and are interested in hearing the lessons learnt from setting up this award winning program, please drop by at Orange Room 133 (GRC-301) at 8:00am on Thursday, April 23.

URLScan - First Line of Defense

Fri, 27 Mar 2009 13:00:26 +0530

by Siddharth Anbalahan

In this blog we look at how URLscan can be a useful first line of defense against attackers. We discuss the various configuration settings and how URLscan 3.0/3.1 can be used to protect against application layer attacks.

Attached with this blog are two files.
1.) URLScan.txt: Instructions to install and configure URLscan on IIS
2.) A UrlScan.ini file that can be used to protect against popular application attacks like SQL injection and Cross Site Scripting. The ini file can be used for IIS webserver hosting ASP, ASP.NET, PHP (all web applications).

Note:- The right place to fix application vulnerabilities is in the application. Using URLScan to protect against attacks should only be a stop gap measure. Moreover,URLscan does not filter HTTP POST.

So lets get started...

URLscan has been around since 2001 when Microsoft released it to protect attacks against IIS 5.0 webservers. At that time typical attacks included directory traversal, Webdav exploits etc. URLscan would work as a ISAPI filter to monitor URLs, HTTP Request headers to look for directory traversal strings like (%,\, ../ etc).

The typical URLscan filters that are configured on IIS are:

Deny access to various serverside scripts (except asp, .aspx)

Deny access to static sensitive files (.config, .log) etc.

[DenyExtensions]

.exe
.bat
.cmd
.com
.htw ; Maps to webhits.dll, part of Index Server
.ida ; Maps to idq.dll, part of Index Server
.idq ; Maps to idq.dll, part of Index Server
.htr ; Maps to ism.dll, a legacy administrative tool
.idc ; Maps to httpodbc.dll, a legacy database access tool
.shtm ; Maps to ssinc.dll, for Server Side Includes
.shtml ; Maps to ssinc.dll, for Server Side Includes
.stm ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services

; Deny various static files
.ini ; Configuration files
.log ; Log files
.pol ; Policy files
.dat ; Configuration files
.config ; Configuration files

For the above to be applied, set
UseAllowExtensions=0

[AllowVerbs] specifies the HTTP methods that are allowed. This effectively disables TRACE HTTP method and all Webdav methods

[AllowVerbs]
GET
HEAD
POST

For the above to be applied, set
UseAllowverbs=1

IIS6.0 is secure by default and the above settings come pre-configured with IIS 6.0

As IIS webservers have become secure, the focus of attacks has turned towards the applications hosted on them. Attackers are no longer restricted to specific versions of webservers.

SQL injection is one such popular attack on applications. It is simple to conduct and requires no or limited knowledge of the underlying webserver or operating system of the target system.

Clearly the best way to protect against a SQL injection attack is using parameterized sql queries and filtering inputs.

Attackers flood websites with SQL injection attacks. Even if applications are secure against SQL injection attack, such automated SQL injection attacks are invalid requests for the application. We need a way to prevent these attacks from reaching the application.

Fortunately, Microsoft has come up with URLScan 3.0/3.1, which allows web server administrators to extend the functionality of URLscan.

URLscan 3.0/3.1 now look for QueryStrings within the URL. The way we can extend the URLscan functionaility is using the [Rulelist] option. A [Rulelist] allows configuration of custom filters.

A Sample [Rulelist] configuration with custom filters to protect against SQL injection is given in the blog-

and is listed below

RuleList=SQL Injection
[SQL Injection]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Strings
ScanUrl=0 //Option to SCAN URL
ScanAllRaw=0
ScanQueryString=1
ScanHeaders= // OPTION to SCAN HTTP HEADERS, example: Cookie

[SQL Injection Strings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
create // this will filter urls with ?action=create
cursor
declare
delete // this will filter urls with ?action=delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update // this will filter urls with ?action=update

Rulelists can be used to check querystrings, HTTP Headers: Cookie, and the URL itself.

New Massachusetts Data Protection Standards, which states are next?

Thu, 05 Mar 2009 20:05:37 +0530

by Paresh Amin, CISSP

Do you conduct online credit card transactions with a Massachusetts resident? Do you collect social security or financial account numbers on a Massachusetts resident? If you answered yes to either of these questions then this law affects you. It does not matter where your company is located; once you touch Massachusetts Residents information this new law effects you.

In October 2008, the Commonwealth of Massachusetts introduced sweeping new regulations to protect the "personal information" of its residents. Unlike the data breach notifications laws enacted by most states (including Massachusetts), these regulations were not confined to situations where data is already compromised. Instead, the regulations impose a comprehensive new regime designed to prevent data breaches.

The regulations apply to any entities that handle Massachusetts residents' Social Security, credit card or financial account numbers, meaning virtually all Massachusetts businesses and many businesses outside of the Commonwealth are affected.

As of May 1, 2009 any company which stores personal information must have the needed security parameters in place. The Massachusetts Office of Consumer Affairs & Business Regulation ("OCABR") issued "Standards for Protection of Personal Information for Residents of the Commonwealth" (Regulation 201 Mass. CodeRegs 17.00). This new regulation represents one of the most far-reaching information security and related compliance requirements in the country.

Massachusetts now has the broadest data security regulations in the country. These regulations - which cover businesses inside and outside of Massachusetts - require the development and implementation of a comprehensive and detailed information security program.

Satisfying the new regulatory requirements will not simply be a question of allocating resources. It demands a dedicated and well-planned program/project-based effort.

The new law talks about many specific requirements including secure access to this type of sensitive PPI data regardless of where the data sits in system, servers and/or applications.

Here's the link to the new MA regulation (pdf).

NY has also recently put out their version of this law (Data Protection specify related to application Security), the questions that begs to be answered is how many states are next to put in place these extra data protection requirements. The bottom line is data protection continues to become a "front and center" initiatives for many states and this trend is only going to gain momentum. Business should start thinking about their own data protection controls around network, systems and application and quickly establish a baseline. Many of the steps needed to support these extra data protection requirements echo core PCI, HIPPA and other regulation requirements. This can be bad for many businesses still looking to establish compliancy to these already existing regulatory. This now just adds yet more support to get this done as quickly as possible.

OWASP Australia - Code Review Techniques

Thu, 26 Feb 2009 07:43:38 +0530

by Jaideep Jha

Siddharth and I are presenting on "Advanced Code Review Techniques" at the OWASP Australia Conference in a few hours. We share some efficient techniques to find common flaws in .Net and J2EE applications. The scripts we discuss are also available for download on our code review page.

In the next few weeks, we will analyze some of these techniques in this blog too.

State of New York takes a major step in Application Security

Tue, 20 Jan 2009 10:15:18 +0530

by Paresh Amin

The State of New York has elevated Application Security in a pioneering move. The State of New York's procurement contracts will now include language that takes application security into account. Specifically, programmers wishing to do business with New York will be required to based on newly implemented contract language to read the recently released list of the 25 most dangerous programming errors (More on this below). This effort is fully supported and sponsored by New York State Office of Cyber Security and Critical Infrastructure Coordination (CSCIS). CSCIC is responsible for leading and coordinating New York State's efforts regarding cyber security readiness, geographic information systems (GIS) and critical infrastructure preparedness. CSCIC works collaboratively with the public and private sectors to foster communication and coordination. CSCIC also coordinates closely with the NYS Office of Homeland Security (OHS).

This makes perfect sense. New York is the third largest state in population. The state serves its large populace through multiple state wide agencies through the use of internet facing web applications to get them easy access to the various state supported programs.

Web-based applications can pose significant information security risk for organizations and since the majority of them require the collection of private, personal and sensitive information (PPSI), such as Social Security numbers. Making the security of their application a key priority makes sense. Additionally, other NY state-wide agency applications support the transfer and disbursement of funds which again support the need for enhance application security and proper application-level testing. If that wasn't enough reasons most of the states agencies must also comply with multiple federal and state information security mandates, including the Federal Information Security Management Act (FISMA), the New York State Information Security Breach and Notification Act and New York State Cyber Security Policy.

In addition, CSCIS has developed a cyber academy with the state's colleges and universities to educate and train the next generation of programmers about the basics of application development security. This represents another key element in managing and more importantly avoiding application vulnerabilities/erros right at the beginning of the software development cycle.

As mentioned above the reference to the 25 most dangerous programming errors was an output generated by more than 30 U.S. and international cyber security organizations that have joined and come up with this list. The CWE/SANS Top 25 List was compiled with help from organizations and individuals including Apple, CERT, Microsoft, Oracle, Red Hat, to name a few. It is managed by The SANS Institute and Mitre, and funded by U.S. Department of Homeland Security's National Cyber Security Division and the U.S. National Security Agency, both of which also contributed to the development of the list. The hope is that by making these programming errors public, software code, and by extension the nation's cyber infrastructure, will be more secure.

CWE stands for Common Weakness Enumeration, a government-sponsored software assurance initiative. The Top 25 List consists of three categories of programming errors: Insecure Interaction Between Components (nine errors), Risky Resource Management (nine errors), and Porous Defenses (seven errors). Examples of errors in the respective categories include: CWE-20: Improper Input Validation; CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer; and CWE-285: Improper Access Control.

The hope is that the errors list will serve four major purposes:

To make software more secure for buyers by requiring that vendors certify their software is free of these top 25 errors
To incorporate awareness of these errors into software testing tools
To provide information necessary for educators to teach more secure programming techniques and
To provide a guide for employers to determine the abilities of programmers to write code free of these errors

Many of the errors on the list led to the majority of security breaches in 2008. That should not be a surprise, believe it or not most of the errors on the list are not well understood by programmers; secure coding practices are not widely taught by computer science programs; most developers are still only be requested to code of feature and functionality requirements not security requirements. Furthermore application vulnerabilities and errors are frequently not tested by organizations developing software for sale.

Hopefully the attempt made by these groups and by active participants like State of New York in leveraging this body of knowledge is further replicated across all industries and verticals for the purpose of improving the application security in order t o safeguard customer and corporate data.

New site - IT Governance Asia

Tue, 09 Dec 2008 15:27:57 +0530

by Vinod Vasudevan

Our publishers, IT Governance Publishing, has launched a new site today IT Governance Asia, targeted at the Asian markets.

Almost the entire catalog of books from IT Governance is available for electronic download at the site - including the book we wrote on Application Security in the ISO 27001 Environment. The site also features pocket guides and best practices reports from the IT Governance stable.

All the best for the new initiative!

Why App Penetration Tests take more than 2-3 days

Mon, 17 Nov 2008 12:02:51 +0530

by Roshen Chandran

Our application security tests usually take between 10-30 days. The effort depends on the size and complexity of each application. Though some small applications can be tested in 5 days, most apps take 10 days or longer.

At times, clients ask us why we can't just do it in 2-3 days with the help of a scanner.

Running a scanner is only a small part of the penetration test. A scanner is useful for finding SQL Injection and Cross Site Scripting vulnerabilities.

And those are not the most important attacks on your application.

The attacks you are most worried about are those that affect your business directly. In an online banking app, can an adversary siphon off funds? In an insurance application, can an adversary modify the terms of a user's policy? In a healthcare application, can an adversary change the prescription for a patient?

Scanners, naturally, do not understand the business context. They run generic test cases for popular attacks. They do a decent job of that, but they don't exercise your business logic.

The penetration tester dons the hat of the adversary. He studies the application and thinks through what the adversary wants to achieve. He constructs security test cases to beat the business logic - to siphon off funds, to modify the terms of a policy, to change the prescription. This requires understanding the application, constructing a threat profile, designing a test plan and then executing the test cases.

For most applications, that will take between 10-30 person days, with many of the efficiency improvements we have brought to our testing processes. A 3-day test would be a lot less thorough.

Download Link for Webinar

Mon, 17 Nov 2008 10:37:47 +0530

by Sangita Pakala

The Webex recording of the Emergency Threat Update is available for download now. (4.7 MB)

Please note you will need the Webex Playback client (3.3 MB) to view the webinar.

Emergency Threat Update: Windows Worm Breakout

Mon, 10 Nov 2008 17:09:11 +0530

by Sangita Pakala

Jose Varghese, who leads the Managed Risk Services practice at Paladion/Plynt, just completed an Emergency Threat Update Webinar to customers on the recent Windows Worm Breakout. He explains how to detect the worm, eradicate it and prevent it in the first place.

The slide deck is available here:

Emergency Threat Update Nov 10, 2008

I shall post the link to the recorded webinar as soon as I get a copy.

100% Compliant - Does not equal 100% Secure

Mon, 10 Nov 2008 08:38:36 +0530

by Paresh Amin

Don't be confused. Just because you have checked off all the boxes or answered "yes" to an online assessment questionnaire for PCI or SOX, it doesn't mean that you can hang your hat up.

You can be compliant to a regulation but still lack mature controls, policies and processes to protect your data. Compliance and security support each other. But it's risk management that helps define when and how each is fulfilled. Many companies over-emphasize compliance, without making sure the compliant environment is actually secure. For example, both Hannaford Brothers and TJX were PCI DSS compliant, but were not secure.

The good practice to meet your regulatory requirements along with a risk management program. Doing risk assessment and mitigation is also not a one-time deal. It's got to become standard practice, done multiple times a year. Also, consider technology and services that integrate risk management with compliance processes. Work towards maturing security policies. Enable them to be implemented, instead of having everyone wrapped up in preparation for the next compliance assessment.

It's tempting to argue that compliance is the only thing that gets priority when budgets are tightly controlled. But the role of good management is to meet compliance requirements and also strengthen security on the ground. Again, what may be compliant may not be secure - don't fall into that trap.

Webinar Alert: Value of Database Penetration Testing

Thu, 06 Nov 2008 16:37:29 +0530

by Sachin Varghese

An interesting listen. One of Plynt's industry peers and soon to be partner Ntirety hosted a live webinar on the "Value of Database Penetration & Vulnerability Testing" and invited Paresh Amin our US VP of Enterprise Business and Strategy to speak on this topic. As a security practitioner and a certified CISSP he was excited at the opportunity to share his experience with Ntirety's clients and prospects. As Paresh states, "There are many options open to an organization when looking for approaches to securing your databases and it can get confusing very quickly".

In today's highly sensitive information security world everyone (including the DBAs) have responsibilities in protecting their corporate and customer data from both internal and external threats.

If you are interested in learning about Database Security, please check out the webinar.

Here is the description of the webinar:

Title: The Value of Database Penetration & Vulnerability Testing

In this webinar, Paresh Amin discusses:

Why backend database testing is just as vital as front end testing
How to avoid backend database malfunctions that cause system deadlock, data corruption, poor performance, and data loss
An overview of backend database testing (functional vs. structural)
An overview of high profile database attacks in the past few years

By viewing this recorded webinar you walk away with an understanding of the overall benefits of a database vulnerability assessment and penetration test. You also learn some essential ideas to structure your own approach to database security testing.

Penetration Testing Content Management Systems

Fri, 03 Oct 2008 18:38:06 +0530

by Siddharth Anbalahan

Today, I want to discuss how we do penetration tests of Content Management Systems (CMS) like Wordpress or more specialized CMS used for managing intranets and knowledge bases. Our approach to testing is quite familiar to our regular readers. Let's review the basics of the approach:

Create a Threat Profile for the CMS
Create the Test Plan
Perform the Tests
Prepare the Report

A "Threat" is the goal of an adversary, it's what the bad guys want to achieve. A "Threat Profile" is the list of all threats to an application. [For more about Threat Profiles, please read "Why We Love Threat Profiles"].

The Threat Profile is central to our testing methodology. For a Content Management System, the threat profile would include threats like:

An adversary...

... publishes content on a site he is not authorized to
... deletes published content from a site
... modifies templates without authorization
... adds editors and publishers without authorization
... modifies the scheduled publishing date for an article
... views the list of documents scheduled for publication
... steals the passwords of other users

Notice these are the things an adversary might be interested in. Logically, that's where we should start from.

It takes about half-a-day to two days to create the threat profile - that depends on the complexity of the CMS. We study the CMS, prepare a draft threat profile and then get your feedback. Our generic Threat Profile Repository helps accelerate this step. This repository is a collection of common threats we see many applications.

Once the Threat Profile is ready, we create the Test Plan for the CMS - the specific tests to perform for checking each threat. This is the intensely technical part of our test, when we visualize in the mind's eye the various possibilities for attack.

The Test Plan connects each threat in the Threat Profile to specific pages on the CMS. For example, consider the threat, "The adversary publishes content on a site he is not authorized to". The "Publish Content" page and the "Schedule for Future Date" page are the relevant pages for the threat. An adversary might try to exploit flaws in these pages to publish content without permissions.

Once we identify the right pages, then we identify all the attacks to try on those pages to realize that specific threat. For example, on the "Publish Content" page, we might decide to try a Variable Manipulation attack and a SQL Injection attack to publish content by escalating privileges. The Test Plan is thus prepared for all the Threats to the application. To assist our engineers, we have a master reference checklist of all attacks - they pick attacks for the Test Plan from that checklist.

Once the Test Plan is prepared, it's reviewed and approved by a senior. The actual testing begins only after that. The tests are a combination of manual and automated checks. The penetration tester adheres to the original Test Plan. The test plan is updated when he gets new ideas during the test.

When an attack succeeds, we capture the screenshots of the attack. Our final report explains the attack step-by-step using these screen shots.

Any large application penetration test involves hundreds of test cases, so it's important that we focus on the right set of test cases. We should, for instance, focus on whether a the terms of a plan can be modified than on generating error messages by tampering unimportant variables. The Threat Profile to Test Plan approach helps us focus our testing on the threats specific to CMS.