Product Security

I spend a lot of thinking about how money is changing. To be specific, I’m curious and concerned about the security of our digital money. Along with my team, I’ve found flaws in BitCoin and compromised chip-enabled EMV card readers. But what I’m writing about today isn’t the ways you’ll be attacked in the future but one of the oldest tricks in the card thief’s toolset: a skimmer.

Russian hacker Roman Seleznev has been sentenced to 27 years in prison following his conviction on 38 counts relating to fraud and theft. If that name looks familiar to Seattle resident it’s because he was behind Broadway Grill’s bankruptcy[1] and related ATM and Point of Sale (PoS) hacks worth an estimated $169M in losses across 3,700 financial institutions. Over the course of four years, he perpetrated numerous successful skimmer and malware installations, then trading the stolen information on carding websites to other criminals and organizations who would in turn counterfeit the cards and go on costly spending sprees.

Skimming, responsible for an estimated 97 to 98% of all ATM fraud losses, has been around for some time now. And in case you thought you could wish it away, this persistent threat is actually experiencing a sharp rise. FICO reported a 574% increase in incidents between 2014 and 2015 alone. As skimming equipment becomes cheaper and more available, and adapts to newer technologies, the crime will likely continue to become more common.

These incidents are geographically widespread, affecting ATMs and other EMV terminals throughout the U.S. and elsewhere. Recently, police warnings were issued in Texas, Indiana, Glasgow (Scotland) and Victoria (BC, Canada), just to name a few hotspots.

Two recent incidents further emphasized that we aren’t immune to this scourge in Washington First, a few months ago, one of my company’s credit cards fell prey to skimmer and was used by a fraudster at area Apple and Microsoft Stores (thankfully we were able to reverse the charges). Second, in the last few weeks a security-conscious citizen reported a suspected skimmer installed on an ATM they occasionally used (See photo).

So, what is Skimming?

At its simplest, skimming is placing a device on an ATM or EMV terminal that is hidden from the user’s perspective. The intruding device executes a passive Man in the Middle (MITM) attack to read and store card numbers and other sensitive card information that can be later retrieved, downloaded, and sold illegally – often online. The end result of these compromises netted Seleznev an estimated $2.9 million over four years as just one (albeit extreme) example. In some cases, the devices are paired with some method of PIN extraction: counterfeit PIN pads and pinhole cameras installed in the facade of the machine being two examples.

An ATM Skimmer found in Seattle

By capturing this data, cybercriminals expose a consumer to more than just financial loss. Victims of this crime may find themselves at direct risk of identity theft, impersonation, additional data breaches, and ruined credit history. Anywhere that those debit or credit card numbers are used, they can also be leveraged against the consumer. Oh yeah, criminals can place a skimmer in seconds (seriously, watch the video).

Defenses Against Skimming

Typically, this how a skimmer may be discovered. You visit an ATM, and notice that something ‘feels off’ about the machine. A physical inspection may reveal nothing of note. It’s not until you feel the card reader and notice an unusual protrusion that makes confirms your suspicion. You then notify the bank’s customer service and immediately cancel your card

This is the advice I give to my friends and family about using an ATM:

●      Avoid unfamiliar and standalone ATMs
●      Use familiar ATMs recessed into the building that houses them
●      Look for physical signs of tampering to the card reader, PIN pad, or ATM in general
●      Pay attention to how much force it takes to swipe or insert your card
●      Give the card reader a tug — it should remain solidly fixed in place
●      Always cover the PIN pad while you enter your PIN
●      If you’re unsure, trust your gut. Don’t be afraid to walk away and use another ATM or the teller window.

Mostly, don’t use debit cards unless you must. Apple Pay, Google Wallet are more secure than your debit card.

You may also be wondering: what can organizations do about this? After all, it wasn’t just customers that got hit in the wallet, but Broadway Grill and other businesses and financial institutions.  Recommendations are a little more involved at the organizational level. I’d recommend the following basic steps:

●      Add anti-skimmer protections, such as those recommended by the ATM Security Association
●      Designate and post a clear contact responsible for security issues
●      Ensure strict compliance with data encryption and storage requirements
●      Monitor access and to the device
●      Regularly inspect the device for tampering

Countering the rise of skimming and related criminal techniques for stealing sensitive card-encoded data is vital, and not as difficult as it may first seem. Combined with increased awareness and vigilance, the techniques above can help you regain your financial peace of mind.

Several enterprises are increasingly investing time and money in building application security tasks into their existing SDLCs. Some of them have also reached the conclusion that proactive approaches , like threat modeling, have more ROI than reactive approaches. As a result, some enterprises with nascent appsec programs have turned to threat modeling as a panacea for their security problems. However, threat modeling may not be the solution to their immediate problems. Now I recognize that this may be a controversial statement.

Recently, I have been involved in several situations where organizations with their heart in the right place have made threat modeling mandatory as part of the development process, with limited success. My point is that threat modeling as part of a mature SDLC is a desired end state though not necessarily the initial step. Let’s examine this argument.

Firstly, threat modeling depends on several elements of a SDLC to be fairly mature. Most importantly it depends on requirement and specification gathering process to be rigorous. Also, an enterprise must have well defined standards and policies in place to act as input into the threat modeling process. Without these elements of the SDLC in place, the threat modeling process will be isolated and have a reduced impact.

Secondly, a threat model is a security plan only and is useless without any committed follow-up action as part of development and testing. Most enterprises do not allocate sufficient time and resources to implement the findings of the threat model. A large portion of organizations don’t even have a security assessment team in place. These teams are consumers of the threat modeling process that actual carry out the most crucial task of reducing risk by implementing countermeasures.

Thirdly, it is practically feasible to create threat models only for new projects or those undergoing incremental changes. As a result, legacy applications do not benefit from threat modeling. This leaves a huge gap in the enterprises’ risk profile.

Finally, most nascent application security programs need quick and demonstrable ROI. The threat modeling process ROI can take several months or even years to be quantifiable because it is an incremental process that is dependant on several other SDLC processes to be effective. There are other areas where investment can bring in more immediate ROI. These areas include security assessment team, security training for developers and definition of countermeasures for common vulnerabilities.

For organizations with nascent application security processes, I recommend that they us the following framework to evaluate if they are ready to adopt threat modeling:

• Does a security baseline exist?
• Is the SDLC process fairly well defined and followed during development?
• Has the organization agreed upon countermeasures for common vulnerabilities?
• Are developers trained to avoid common vulnerabilities?
• Do developers do a self review of code for security vulnerabilities?
• Does a security assessment team exist?

If the answer to more than two of the questions above is no then the organization is probably not ready for adopting threat modeling.

If you’re not already thinking right now that your DevOps teams should be run like a DevSecOps team, you may already be in a world of hurt. Time to wake up! As the adoption of APIs continues to grow, so do the risks to organizations that don’t actively test the security of their solutions.

Modern Agile development frameworks have changed the way engineering teams produce products. Under these frameworks, products receive small, frequent updates daily or weekly rather than major quarterly or annual product releases. These frameworks also rely on continuous integration (CI) systems to facilitate each build. While the product’s efficacy and flexibility are improved by these small releases, each new build introduces the potential for security vulnerabilities.

At the time of this writing there are more than 18,000 public APIs available. Continued growth and adoption of APIs is expected over the next decade as APIs power the backends of many of the most critical services.

Unfortunately the security tools used to test APIs are manual, slow to deploy, occur late in the development process, and rely on experienced penetration testers. Indeed, taking just one quick look at the current landscape of security testing tools, several gaps clearly emerge:

API Specific Testing

Many existing solutions are generalist security tools – not designed to perform security testing on modern APIs. These web-scanner style tools work by pointing to a single service, API, or endpoint. The tool then crawls that service and captures the traffic that is sent between the API and the client. By analyzing this data, the tool returns a pass or fails result, and while vulnerabilities need to be individually and manually located and verified by the penetration tester before it can be sent to a developer.

Older point-and-shoot tools also require users to manually configure the tool for each API endpoint before they can be tested. This laborious configuration step wastes time and leads to mistakes in testing; plus, these tools can only perform one test at a time. They also do not support modern authentication schemes used by most APIs and applications. This gap in support leads to poor code coverage and vulnerabilities.

Limited Integration

Security tools should work with the tools developers already use to create and manage their products. Current security tools lack basic integrations, such as the ability to capture, analyze, and store log files, integrate with CI build systems, or send fault findings to common bug tracking software solutions. Intended to be used by security experts and pen testers, they also require manual efforts to test for, verify, and log vulnerabilities, which is very costly.

End of Development

Because of the difficulty developer teams face in integrating existing security tools into their workflows, testing of products is often performed by security professionals late in the development process. Bugs are much more expensive to fix the later they are found. The time and cost to manually test products (see above) frequently encourages testing to occur only once per major development cycle rather than for every new build of the product. This results in intermediate builds of products being put into production without proper testing.

Preventing Releases

Existing security tools do not have the ability to stop builds with known vulnerabilities from being released to a production environment. Additionally, the time it takes to find and fix all vulnerabilities when they are discovered late can cause significant ship date delays.

Instead, a more efficient and streamlined approach to security would be to take what we call a DevSecOps approach, and automate API security testing around the engineering team’s current workflow to more closely and effectively navigate the complexity throughout the entire development lifecycle.

In this DevSecOps scenario the process is wrapped around these 7 key fundamentals:

1. API Specific Security Testing

Your team should be testing against vulnerability lists that highlight new and emerging vulnerabilities, such as the OWASP Top 10. These typically surface during complex interactions between multiple APIs and services.

2. Automated Test Case Generation

Your engineering teams already have their automation or unit tests to ensure that your products behave as expected. These unit tests are designed to provide good code coverage and pass through the product’s authentication schemes. Thus, you should be configuring automation testing frameworks that enable the conversion of your current unit tests into security tests. Leveraging already created unit tests moves security testing to “the left” or earlier in the development lifecycle. Bugs fixes here are cheaper and easier.

3. Don’t Break Developer Workflow

Continuous integration is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. You should run your security checks as a step within your current developer build pipeline. When faults are discovered, vulnerable builds should be automatically prevented from being put into production. Here, all interactions should occur from within the tooling your developers are already familiar with. You then don’t have to invest time and resources altering your team’s workflows or teaching your engineers to use new security tools. Security is baked into every build automatically.

4. Fuzzing

This is when your team “mutates” valid messages which can uncover additional security vulnerabilities that are not covered when doing your automated OWASP testing. This step is critical to discovering those company destroying 0-days.

5. Testing Profiles

Speed and shipping deadlines are critical for your teams that push builds multiple times a day. Use tools that allow users to balance security testing coverage with ship deadline requirements. Each testing profile should be configurable, allowing your teams to include or exclude certain checks or modes of testing.

6. Fault Results

Findings should include the information required for your developer to fix the issue quickly. All fault findings should be viewable from within the CI or bug tracking system the engineering team uses.

7. False Positives

Finally, one common shortfall of existing automated security testing solutions is management of false positives. It takes considerable time for your team to manually sort and determine which faults are valid bugs and which can be safely ignored. One option is to customize how faults are managed so that false positives do not slow development. When a failure is determined to be a false positive or a team decides not to fix an issue, it can be added to a list of automatically ignored failures. Future builds will still test for the fault, but will not report it in ticket management systems or block builds from deploying.

Conclusion

To better compete and head off major security concerns it is paramount that organizations deploy automated, scalable processes for security testing of their APIs. Key to that success is ensuring security is properly tuned along the entire development lifecycle. This requires new thinking and much closer testing that ultimately turns DevOps teams into DevSecOps teams.

---

Author Note: A version of this article was also published by App Developer Magazine