Sky Prioritize Yourself

I’ve covered hacking Passbook files in the past, but I’ve decided that it’s now a good time to cover modifying boarding passes. To start things off, you should not replicate what I’m showing in this blog. Modifying your boarding passes could easily get you in trouble with the TSA, and no one has time for that. iOS 7 has made it a lot easier to export Passbook files, so I think it’s time to point out some issues surrounding boarding passes in Passbook.

First off, let’s send ourselves a copy of a boarding pass. It’s as simple as opening Passbook, opening the pass, and hitting the square in the bottom left corner of the pass.


Once you’ve emailed the .pkpass file to yourself, right click on the file and extract (or unzip) the files. The .pkpass file is just a zip file with a different name.


This will result in the following files in the directory.


There will be two more files in there if you have Sky Priority. If you don’t already have Sky Priority, the image files can be found here. These footer images are also used for the TSA Pre Check boarding passes. They just have the Pre Check logo appended to the right of the Sky Priority logo.

So we have the boarding pass file. That’s cool. What can we do with it? Well, if you have an Apple Developer’s account ($99 – more info here), you can modify the boarding pass and email it back to yourself. There is a signature file required by iOS to trust the Passbook pass, that can only be generated with a proper Apple Developer’s certificate, but that’s something you get as an Apple developer. I have heard that this signature file is not required for loading Passbook files into the “Passbook for Android” application, but I have not seen it in practice. So if you’re using the passes from an Android phone, there’s a chance that you won’t have to re-sign the pass.

For this demonstration, we’ll show how you can give yourself Sky Priority on a flight. All that you need to do is add the two Sky Priority images (linked above) to your directory and modify the pass.json file to say that you are in the SKY boarding zone. This can easily be done with a text editor. Here’s what my pass.json file looks like after changing the boarding zone.


Note that I changed the “zone” parameter. If you felt so inclined, you could change your seat number. If you wanted to social engineer your way into first class, this would be a good way to start. Again, I don’t recommend doing any of this. This would not change your boarding pass barcode (also modifiable in pass.json), which is “tamper evident” and is supposed to be signed by a Delta private key. I have not tested this, but if the airport barcode scanners are not checking the signature, you would be able to modify the barcode as well. Again, I have not tested this or seen it in practice, but I have seen documentation that states the security data (signature) is optional. There’s more info on the barcode standard here.

If you are going to re-sign the pass, you will also need to modify the passTypeIdentifier and teamIdentifier fields (in the pass.json) to match your Apple Developer’s account. If these do not match your Apple info, the pass will not validate when you go to sign and/or use it. There’s some more info on signing your first pass here. You’ll also want to delete your manifest.json and signature files, as those were generated by the original pass signer.

Your final directory will look like this:


At this point you will want to run the SignPass utility on the directory. Your output will look like this.


And you will end up with a .pkpass file that you can email to your iOS device.


Now, let’s say you wanted to make it easier to upgrade your priority for all of your flights. It would not be hard to make a script to listen on an email inbox for a .pkpass file, unzip it, modify it, re-sign it, and email the pass back to the sender. On that note, don’t send me your boarding passes. I don’t have this script set up and I don’t want your boarding passes.

This issue is not limited to Delta. Any app that uses Passbook, is vulnerable to pass tampering attacks. This has been a problem for a while. Now that Passbook allows easy exports of .pkpass files, messing with the files is a lot easier.


Things not to overlook in the new PCI DSS 3.0

November 7th is tricky. Some years it rings of election news (at least in the US), while in others it has brought devastating earthquakes to places like Guatemala. Considerably less dramatic, this year it brought us the final version of PCI-DSS: the long-awaited 3.0. For a complete list of all changes in the new DSS, I recommend downloading and reviewing the “PCI DSS 3.0 Summary of Changes” which will take you through everything you need to know. I will limit my post to highlighting some of the most significant, noteworthy, and understated.

Having reviewed all the changes in detail, I am fairly convinced that majority of the pains in adopting the new 3.0 will come from items marked as a “Clarification”, rather than any new or “Evolving” requirements. I anticipate none more than the added clarification on Scoping.

PCI Scope Determination

The updated “Scope of PCI DSS Requirements” section now explicitly talks about the scope being defined not only by the segmented network, but also extending to “all system components included in or connected to the cardholder data environment”. In addition, the new DSS goes on to instruct that the scope is also defined by any system that may “impact the security of (for example, name resolution or web redirection servers) the CDE”. Considering inherent risks of all systems connected to one another, one might interpret this in a way which would include the entire Internet in scope. However, a more sensible approach should revolve around performing a risk-based analysis around those systems connected to the CDE to determine whether the scope is limited to the connected systems or should be extended to the logical network. This is a topic worthy of a whole separate post… or a white-paper… or a book. In the meantime, be sure to fully document your scope and challenge your assumptions to help you identify systems that may impact security of the CDE. Remember that these may include systems that you have previously left off the PCI compliance radar because they were on different logical and physical networks.

Relationship Between PCI DSS and PA-DSS

The clarification offered in the new DSS will mostly impact smaller organizations, and those that felt that they “outsourced” PCI compliance by using an application that had gone through the PA-DSS certification. All systems that process, store, and transmit CHD are in-scope, even if PA-DSS certified. The certification means the application can be implemented in a PCI DSS compliant configuration if installed in accordance with the Implementation Guide provided by the software vendor. This should be validated during the assessment and should not be taken for granted.

Best Practices for Implementing PCI DSS into Business-as-Usual Processes

This section is new in the PCI DSS 3.0 and helps reaffirm the need for a viable security program. While nothing new to security professionals, this section should be reviewed by all organizations, especially those that do not have a well-defined Information Security team. Recommendations offered clearly state that expectation of information security becoming a concern throughout the year, not only during the PCI assessment.


The new “Sampling of Business Facilities/System Components” section covers something all QSA’s already worked with for years. While the new DSS calls it out as something for Assessors, I would recommend everyone read it and make a note of the things you can do to reduce the number of systems that need to get reviewed during the assessment. It’s simple: the more standards are followed during deployment and maintenance, the smaller the sample size. In addition to significantly reducing the amount of work that needs to be performed during the assessment, this has the added benefit of actually improving system management and security.

Understanding the Intent of Each Requirement

PCISSC has published several guidelines to help assessors, merchants, and service providers better understand the intent behind each requirement. These guidelines remained best-kept secrets and were seldom used, in spite of containing essential information for interpreting requirements where they didn’t apply verbatim. In the new DSS, these guidelines have been incorporated into the standard, which will help reduce the number of misunderstandings between assessing and assessed parties. Perhaps even higher value, it will help reduce differences of opinion between assessors, which generally drive merchant and service provider companies crazy with frustration.

Documented and Implemented…

Several changes in the new DSS have to do with re-enforcing the concept that controls must be documented and implemented in accordance with the documentation. While common-sense to most, this may be a good wakeup call to organizations whose policies are several years ahead of the controls that are actually implemented.

Requirement 1.1.3 – Current diagram that shows all cardholder data flows across systems and networks

In my experience as an assessor, I seldom find companies that do this well. Most diagrams are either too high-level (bordering on conceptual) or go to a level of detail that could be used to troubleshoot routing tables. This new requirement now requires diagrams that show where CHD is processed, transmitted, and stored. A side benefit – doing this well will also help critically evaluate the current scope of the CDE and identify opportunities for reducing the scope.

Requirement 2.4 – Maintain an inventory of system components that are in scope for PCI DSS

I don’t know why, but this has been a pain-point of most of the assessments I performed over the past years. System inventories either don’t identify whether the system is in scope for PCI or simply don’t exist. This always created many problems when attempting to select an appropriate sample size and I am happy about this being made into a requirement in the new DSS.

Requirement 3.5.2 and 3.5.3 – Key Storage

Over the years, I have seen many creative solutions for secure storage of data-encryption keys and key-encryption keys. Many met requirements but just as many were too big on creativity and somewhat light on security. Clarifications added in these two requirements help provide better guidance on how keys are to be stored and should be reviewed to ensure that key storage conforms to the new information.

Requirement 5 – Protect all systems against malware and regularly update anti-virus software or programs

No more picking on Windows; now all operating systems are in-scope for anti-virus software. The new and updated requirements still offer some flexibility in which systems get the anti-virus software installed on them, but the process needs to clearly show that anti-malware was a consideration for all platforms.

Requirement 6.6 – For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks

I am not too happy about one of the changes in this requirement . Specifically, you no longer have to run your Web Application Firewall (WAF) in ‘deny’ mode, as ‘detect-only’ is sufficient to meet this requirement. The requirement actually states that the solution will meet the requirement if it is “configured to either block web-based attacks, or generate an alert”. I have some hope that it’s a type-o, because within the same requirement the Guidance section offers: “Web-application firewalls filter and block non-essential traffic at the application layer”. Otherwise, this would be a change that would allow a weaker security configuration than what was required in 2.0.

Requirement 8.5.1 – Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer

This is one of my favorite additions to the PCI DSS, even though I know how much pain this will cause the majority of the service providers. The time-honored practice of using the same password for all customers has been a silent danger for a long time, and I am happy it’s now officially prohibited by the DSS. The small silver-lining here for service providers is that it’s not mandatory until June 30, 2015, so you have a little over a year and a half to propagate this change throughout your organization.

Requirement 9.9 – Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution

Applicable to anyone who uses physical devices for capturing CHD, this new requirement will introduce a number of items that should be considered. First, it requires that the company maintain a full inventory of all devices deployed in the field. Considering the number of retail locations or CHD capture devices deployed in many hospital systems, this alone could provide a challenge for some organizations. The inventory must contain the relevant device information, as well as information about the location of the device. The other two sub-requirements deal with the need to provide periodic training on spotting device tampering, as well as actually performing periodic audits of all devices. While seemingly simple, I anticipate this requirement to create a lot of headaches. At least as with all other new requirements, this one is not required until June 30th, 2015.

Requirement 10.2 5 – Use of and changes to identification and authentication mechanisms…

This requirement enhances mandatory logging settings to include each use of authentication mechanisms and all possible changes to user account permissions and settings. While this is supported by most enterprise-level operating systems, it’s rarely the default configuration and will require changes across a large number of systems. However, custom-written applications may require some additional and enhanced logging triggers to be developed. The same will apply for custom software that does not support logging ‘pausing’ events, as required by 10.2.6.

Requirement 11.2 – Run internal and external network vulnerability scans at least quarterly and after any significant change in the network…

This requirement is certainly not new. However, the council has added a lot of guidance, specifying that a report showing “high” or “critical” vulnerabilities is not acceptable as a quarterly report. This means that in order to meet the quarterly scanning obligations, organizations will need to scan, remediate, rescan, and then save reports. The requirement now specifically talks about combining multiple reports that show a single quarter’s attestation of compliance with this requirement.

Requirement 11.3 – Implement a methodology for penetration testing…

In the past, the requirement on penetration testing loosely stated that the methodology should be documented to reflect application and network level testing. Now, the DSS has added a relatively large description of all the requirements behind an acceptable penetration testing methodology. For companies that do their own penetration testing, they will not be able to simply rely on a pen-testing tool to meet this requirement; they will need to ensure the penetration testing process is a considerable undertaking, not limited to running automated tools on the network. For companies that perform penetration testing for PCI, this means updating or improving their reporting to demonstrate their methodology meets all the requirements stated in 11.3.

Related is the new requirement 11.3.4, which requires that penetration testing include verifying the effectiveness of any network segmentation that is used to safeguard CDEs. Depending on the number of non-CDE networks, this may mean significant changes in scope for penetration testing efforts, particularly for large, global enterprises.

Requirement 12.2 – Implement a risk-assessment process

Love Risk Assessments? So does the PCI council! The standard de-facto risk-assessment requirement has been updated to require repeating them after significant changes, in addition to having to perform them on an annual basis. At least the definition of a significant change has been expanded from adding a new web server to things like relocation or mergers and acquisitions.

Requirement 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

Few things caused merchants and service providers to hit the brakes in the middle of a PCI assessment like the discovery that your PCI-compliant service provider does less for you than you originally anticipated. Statements like “We fully outsource all server-related things to so and so” turned into vendors doing nothing more than providing space, power, and data. In order to help level the playing field, this new requirement requires maintaining a detailed list of all PCI requirements the vendors are covering as part of their service / attestation. This will certainly help everyone get on the same page about how much of the PCI attestation may depend on the PCI AOC provider by a vendor or a service provider.

As reinforced through 12.9, contracts should be updated to include information related to the scope of the PCI attestation included as part of the contract but, like all other new requirements, this is not mandatory until June 30, 2015. During the last North America community meeting, someone asked the council whether this would necessitate all contracts to be re-negotiated immediately in order to meet this requirement. The council replied that that won’t be necessary, as long as contracts get updated as they expire or as part of new contract negotiations.


Once again, this is not a complete recap of all that is new and updated, just those items I feel people need to pay close attention to. The new requirements are probably not significant for a large number of organizations. However, I can definitely see how some companies with smaller and less rigorous information security teams may struggle to meet some of the new and updated requirements.


PA-DSS 3.0 – What to Expect

The PCI Council has just released PA-DSS version 3.0. They have added new requirements, removed one, and changed a few. How this affects your application really depends on how you implemented security.

What’s Been Added

Req. 3.4 Payment application must limit access to required functions/resources and enforce least privilege for built-in accounts:

  • By default, all application/service accounts have access to only those functions/resources specifically needed for purpose of the application/service account.
  • By default, all application/service accounts have minimum level of privilege assigned for each function/resource as needed for the application/service account.

Your application setup needs to make sure that it is using or setting the privileges needed to do the work and not grant excessive permissions. This is intended for built-in accounts as well as service accounts.

Make sure you have documented the permissions needed by any default or service accounts. The auditor will need to verify documentation against what was implemented.

Req. 5.1.5 –Payment application developers to verify integrity of source code during the development process

You need to make sure that any source control tools (i.e. Visual SourceSafe, etc.) is configured so that only the people that do development can make changes to the code. This does not preclude giving other users read access, but you need to minimize who has write access.

Req. 5.1.6 – Payment applications to be developed according to industry best practices for secure coding techniques.

You must develop the application with least privilege to ensure insecure assumptions are not introduced into the application. To prevent an attacker from obtaining sensitive information about an application failure including fail-safe defaults that could then be used to create subsequent attacks. You must also ensure that security is applied to all accesses and inputs into the application to avoid an input channel being left open to compromise.

This includes how the sensitive data and the PAN is handled in memory, the PCI Council it trying to prevent capture of this data by screen scrapping. Try to encrypt this data in memory and keep it there only for a short period of time.

Req. 5.2.10 – Broken authentication and session management

You need to make sure, in your web application, that:

  • Any session cookies are marked as secure.
  • The session is never to be passed on the URL. This would allow them to be logged in the web server.
  • The web application must time out the session after a certain number of minutes. Once timed out, the user must re-authenticate to get access to the application.
  • The session id must change when there is a change in permissions. For example, a session id is set when an anonymous user accesses the login page and after successful authentication, the session id must change to a different value.
  • If a user logs out of the application, you need to delete the session on both the client and the server.

Req. 5.4 – Payment application vendors to incorporate versioning methodology for each payment application.

This is not a change in the way you write your code but a process change and, like so many other requirements, has to be documented both internally and in the Implementation Guide. Many companies already do this but make sure you have a defined method of changing the version numbers.

  • Details of how the elements of the version-numbering scheme are in accordance with requirements specified in the PA-DSS Program Guide.
  • The format of the version-numbering scheme is specified and includes details of number of elements, separators, character set, etc. (e.g., 1.1.1.N, consisting of alphabetic, numeric, and/or alphanumeric characters).
  • A definition of what each element represents in the version-numbering scheme (e.g., type of change, major, minor, or maintenance release, wildcard, etc.)
  • Definition of elements that indicate use of wildcards (if used). For example, a version number of 1.1.x would cover specific versions 1.1.2 and 1.1.3, etc.
  • If an internal version mapping to published versioning scheme is used, the versioning methodology must include mapping of internal versions to the external versions
  • You must have a process in place to review application updates for conformity with the versioning methodology prior to release.

Req. 5.5 – Risk assessment techniques (for example, application threat modeling) are used to identify potential application security design flaws and vulnerabilities during the software-development process. Risk assessment processes include the following:

  • Coverage of all functions of the payment application, including but not limited to, security-impacting features and features that cross trust-boundaries.
  • Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
  • Identification of all areas within the payment application that interact with PAN and/or SAD or the cardholder data environment (CDE), as well as any process-oriented outcomes that could lead to the exposure of cardholder data.
  • A list of potential threats and vulnerabilities resulting from cardholder data flow analyses and assign risk ratings (for example, high, medium, or low priority) to each.
  • Implementation of appropriate corrections and countermeasures during the development process.
  • Documentation of risk assessment results for management review and approval.

What the PCI Council wants is to make sure that risks in your application are assessed appropriately and that the process covers all aspects of your application including any third party tools (DLLs, etc.).

You will need to document the threat modeling you have done against your application. If you have never done one or are unsure how to do it, Microsoft has a good process and provides a free tool. The out this page for more information:

Req. 5.6 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation includes:

  • Signature by an authorized party to formally approve release of the application or application update
  • Confirmation that secure development processes were followed by the vendor.

Make sure to record the approval of the release of the software and patches. This is to confirm that your secure development processes were followed.

Req. 7.3 – Include release notes for all application updates, including details and impact of the update, and how the version number was changed to reflect the application update.

Make sure you are publishing your release notes and that they include the customer impact.

Req. 10.2.2 – If vendors or integrators/resellers can access customers’ payment applications remotely, a unique authentication credential (such as a password/phrase) must be used for each customer environment.

This one is simple enough; your support people cannot use the same password to access different customers. Avoid the use of repeatable formulas to generate passwords that are easily guessed. These credentials become known over time and can be used by unauthorized individuals to compromise the vendor’s customers.

Req. 13.1.1 – Provides relevant information specific to the application for customers, resellers, and integrators to use.

The Implementation Guide must state the name and version for the software it is intended for. It must also include the application dependencies (i.e. SLQ Server, PCCharge, etc.)

Req. 14.1 – Provide information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually

These training materials are for your personnel involved in the development and support of your application. The materials must be about PA-DSS and information security.

Req. 14.2 – Assign roles and responsibilities to vendor personnel including the following:

  • Overall accountability for meeting all the requirements in PA-DSS
  • Keeping up-to-date within any changes in the PCI SSC PA-DSS Program Guide
  • Ensuring secure coding practices are followed
  • Ensuring integrators/resellers receive training and supporting materials
  • Ensuring all vendor personnel with PA-DSS responsibilities, including developers, receive training

You must assign one or more people to be responsible for meeting the requirement in PA-DSS. This person must keep up to date on the changes in PA-DSS as well as make sure the requirements are met.

Ensure that each person or persons’ responsibilities are documented.

What’s Been Removed

Req. 2.4 – If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.

All of the PA vendors I worked with did not do disk encryption but use file, table/column encryption. It makes sense to remove this requirement. In addition, disk encryption is only effective at preventing data loss due to physical theft, which is not a significant concern in the majority of datacenters.

What’s Been Significantly Changed

Req. 3.3.2 – Use a strong, one-way cryptographic algorithm, based on approved standards to render all payment application passwords unreadable during storage. Each password must have a unique input variable that is concatenated with the password before the cryptographic algorithm is applied.

It appears that encrypting the password is no longer acceptable. In your application, you must use a strong, one-way cryptographic algorithm (hash) as well as a salt value. Review your application storage to make sure that you are using a hashing algorithm with a salt. They do note that the salt does not have to be unpredictable or a secret.

Req. 4.2.5 – Use of, and changes to the application’s identification and authentication mechanisms (including but not limited to creation of new accounts, elevation of privileges, etc.), and all changes, additions, deletions to application accounts with root or administrative privileges.

Any changes to accounts in the application must be audited.

Discover why security operations teams choose NetSPI.