In one form or another, APIs have been around for years, bringing the benefits of ease of use, efficiency and flexibility to the developer community. The advantage of using APIs for mobile and web apps is that developers can build and deploy functionality and data integrations quickly.
API security posture
But there is a huge downside to this approach. Undermining the power of an API-driven development methodology are shadow, deprecated and non-conforming APIs that, when exposed to the public, introduce the risk of data loss, compromise or automated fraud.
The stateless nature of APIs and their ubiquity makes protecting them increasingly difficult, largely because malicious actors can leverage the same developer benefits – ease of use and flexibility – to easily execute account takeovers, credential stuffing, fake account creation or content scraping. It’s no wonder that Gartner identified API security as a top concern for 50% of businesses.
Thankfully, it’s never too late to get your API footprint in order to better protect your organization’s critical data. Here are a few easy steps you can follow to mitigate API security risks immediately:
1. Start an organization-wide conversation
If your company is having conversations around API security at all, it’s likely that they are happening in a fractured manner. If there’s no larger, cohesive conversation, then various development and operational teams could be taking conflicting approaches to mitigating API security risks.
For this reason, teams should discuss how they can best work together to support API security initiatives. As a basis for these meetings, teams should refer to the NIST Cybersecurity Framework, as it’s a great way to develop a shared understanding of organization-wide cybersecurity risks. The NIST CSF will help the collective team to gain a baseline awareness about the APIs used across the organization to pinpoint the potential gaps in the operational processes that support them, so that companies can work towards improving their API strategy immediately.
2. Ask (& answer) any outstanding questions as a team
To improve an organization’s API security posture, it’s critical that outstanding questions are asked and answered immediately so that gaps in security are reduced and closed. When posing these questions to the group, consider the API assets you have overall, the business environment, governance, risk assessment, risk management strategy, access control, awareness and training, anomalies and events, continuous security monitoring, detection processes, etc. Leave no stone unturned. Here are a few suggested questions to use as a starting point as you work on the next step in this process towards getting your API security house in order:
- How many APIs do we have?
- How were they developed? Which are open-source, custom built or third-party?
- Which APIs are subject to legal or regulatory compliance?
- How do we monitor for vulnerabilities in our APIs?
- How do we protect our APIs from malicious traffic?
- Are there APIs with vulnerabilities?
- What is the business impact if the APIs are compromised or abused?
- Is API security a part of our on-going developer training and security evangelism?
Once any security holes have been identified through a shared understanding, the team then can collectively work together to fill those gaps.
3. Strive for complete and continuous API security and visibility
Visibility is critical to immediate and continuous API security. By going through step one and two, organizations are working towards more secure APIs today – but what about tomorrow and in the years to come as your API footprint expands exponentially?
Consider implementing a visibility and monitoring solution to help you oversee this security program on an ongoing basis, so that your organization can feel confident in having a strong and comprehensive API security posture that grows and adapts as your number of APIs expand and shift. The key components to visibility and monitoring?
Centralized visibility and inventory of all APIs, a detailed view of API traffic patterns, discovery of APIs transmitting sensitive data, continuous API specification conformance assessment, having validated authentication and access control programs in place and running automatic risk analysis based on predefined criteria. Continuous, runtime visibility into how many APIs an organization has, who is accessing them, where they are located and how they are being used, is key to API security.
As organizations continue to expand their use of APIs to drive their business, it’s crucial that companies consider every path malicious actors might take to attack their organization’s critical data.
Credential stuffing attacks are taking up a lot of the oxygen in cybersecurity rooms these days. A steady blitz of large-scale cybersecurity breaches in recent years have flooded the dark web with passwords and other credentials that are used in subsequent attacks such as those on Reddit and State Farm, as well as widespread efforts to exploit the remote work and online get-togethers resulting from the COVID-19 pandemic.
But while enterprises are rightly worried about weathering a hurricane of credential-stuffing attacks, they also need to be concerned about more subtle, but equally dangerous, threats to APIs that can slip in under the radar.
Attacks that exploit APIs, beyond credential stuffing, can start small with targeted probing of unique API logic, and lead to exploits such as the theft of personal information, wholesale data exfiltration or full account takeovers.
Unlike automated flood-the-zone, volume-based credential attacks, other API attacks are conducted almost one-to-one and carried out in elusive ways, targeting the distinct vulnerabilities of each API, making them even harder to detect than attacks happening on a large scale. Yet, they’re capable of causing as much, if not more, damage. And they’re becomingg more and more prevalent with APIs being the foundation of modern applications.
Beyond credential stuffing
Credential stuffing attacks are a key concern for good reason. High profile breaches—such as those of Equifax and LinkedIn, to name two of many—have resulted in billions of compromised credentials floating around on the dark web, feeding an underground industry of malicious activity. For several years now, about 80% of breaches that have resulted from hacking have involved stolen and/or weak passwords, according to Verizon’s annual Data Breach Investigations Report.
Additionally, research by Akamai determined that three-quarters of credential abuse attacks against the financial services industry in 2019 were aimed at APIs. Many of those attacks are conducted on a large scale to overwhelm organizations with millions of automated login attempts.
The majority of threats to APIs move beyond credential stuffing, which is only one of many threats to APIs as defined in the 2019 OWASP API Security Top 10. In many instances they are not automated, are much more subtle and come from authenticated users.
APIs, which are essential to an increasing number of applications, are specialized entities performing particular functions for specific organizations. Someone exploiting a vulnerability in an API used by a bank, retailer or other institution could, with a couple of subtle calls, dump the database, drain an account, cause an outage or do all kinds of other damage to impact revenue and brand reputation.
An attacker doesn’t even have to necessarily sneak in. For instance, they could sign on to Disney+ as a legitimate user and then poke around the API looking for opportunities to exploit. In one example of a front-door approach, a researcher came across an API vulnerability on the Steam developer site that would allow the theft of game license keys. (Luckily for the company, he reported it—and was rewarded with $20,000.)
Most API attacks are very difficult to detect and defend against since they’re carried out in such a clandestine manner. Because APIs are mostly unique, their vulnerabilities don’t conform to any pattern or signature that would allow common security controls to be enforced at scale. And the damage can be considerable, even coming from a single source. For example, an attacker exploiting a weakness in an API could launch a successful DoS attack with a single request.
Rather than the more common DDoS attack, which floods a target with requests from many sources via a botnet, an API DoS can happen when the attacker manipulates the logic of the API, causing the application to overwork itself. If an API is designed to return, say, 10 items per request, an attacker could change that value to 10 million, using up all of an application’s resources and crashing it—with a single request.
Credential stuffing attacks present security challenges of their own. With easy access to evasion tools—and with their own sophistication improving dramatically – it’s not difficult for attackers to disguise their activity behind a mesh of thousands of IP addresses and devices. But credential stuffing nevertheless is an established problem with established solutions.
How enterprises can improve
Enterprises can scale infrastructure to mitigate credential stuffing attacks or buy a solution capable of identifying and stopping the attacks. The trick is to evaluate large volumes of activity and block malicious login attempts without impacting legitimate users, and to do it quickly, identifying successful malicious logins and alerting users in time to protect them from fraud.
Enterprises can improve API security first and foremost by identifying all of their APIs including data exposure, usage, and even those they didn’t know existed. When APIs fly under security operators’ radar, otherwise secure infrastructure has a hole in the fence. Once full visibility is attained, enterprises can more tightly control API access and use, and thus, enable better security.
GrammaTech has released Swap Detector, an open source tool that enables developers and DevOps teams to identify errors due to swapped function arguments, which can also be present in deployed code.
Modern software development involves the use of third-party APIs, libraries, and/or frameworks that are complex, rapidly evolving, and sometimes poorly documented. According to industry estimates, open source components can represent up to 90% of the code in the average application. Meanwhile, API usage errors are a common source of security and reliability vulnerabilities.
“Traditional static-analysis techniques do not take advantage of the vast wealth of information on what represents error-free coding practices available in the open-source domain,” says Alexey Loginov, VP of Research at GrammaTech. “With Swap Detector we applied Big Data analysis techniques, what we call Big Code analysis, to the Fedora RPM open-source repository to baseline correct API usage. This allowed us to develop error-detection capabilities that far exceed the scalability and accuracy of conventional approaches to program analysis.”
Swap Detector consumes input information about a call site, and optionally, function declaration information pertaining to that call site. If it detects a potential swapped-argument error at that call site, it outputs an appropriate warning message and a score for the warning.
The Swap Detector interface integrates with a variety of static analysis tools, such as Clang Static Analyzer, Clang-Tidy, and PyLint. Although initially focused on C/C++ programs, Swap Detector is applicable to programs in other languages; and is especially beneficial for languages that are interpreted and not compiled.
Swap Detector uses multiple error-detection techniques, layered together to increase accuracy. For example, it compares argument names used in call sites with the parameter names used in corresponding declarations. In addition, it uses “Big Code” techniques, applying statistical information about usages of “known good” API-usage patterns collected from a large corpus of code, and flagging usages that are statistically anomalous as potential errors.
To improve the precision of the reported warnings, Swap Detector applies false-positive reduction strategies to the output of both techniques.
ConnectWise has fixed a high-severity vulnerability affecting a ConnectWise Automate API and is urging users who run the solution on their premises to implement the provided hotfixes.
About ConnectWise Automate and the vulnerability
ConnectWise is a provider of business automation solutions for managed services providers (MSPs) and IT solution providers.
ConnectWise Automate is a software suite IT support technicians use to remotely monitor and manage customers’ assets (servers and workstations).
“A remote authenticated user could exploit a vulnerability in a specific Automate API and execute commands and/or modifications within an individual Automate instance,” the company shared in a security bulletin. Effectively, this could allow attackers to do things like run commands on endpoints, create new users, etc.
The vulnerability affects on-premise and cloud instances of ConnectWise Automate versions 2020.5 and earlier.
ConnectWise has applied the hotfixes and hardening measures required to plug the security holes and is urging on-premise partners to do the same based on their Automate instance version.
Those who still use ConnectWise Automate versions 2019.11 or older are urged to implement provided mitigation steps and to update to a supported version.
ConnectWise has been working on the hotfixes since last week and has been releasing them up until Saturday. The first hotfixes were a temporary stopgap, so users are advised to peruse the security advisory and make sure to apply them all.
“To protect our customers, ConnectWise does not publicly disclose or confirm security vulnerabilities until ConnectWise has conducted an analysis of the product and has issued fixes and/or mitigations,” the company noted.
“Alternative tools and processes are used, where appropriate, when targeted or discrete communication with entitled customers is required.”
Earlier this year, BishopFox researchers flagged eight vulnerabilities in ConnectWise Control, the company’s remote control and access solution. Seven of the vulnerabilities were subsequently remediated and the successful remediation confirmed.
Security issues for APIs
The many benefits that APIs bring to the software and application development communities – namely, that they are well documented, publicly available, standard, ubiquitous, efficient, and easy to use – are now being leveraged by bad actors to execute high profile attacks against public-facing applications. For example, we know that developers can use APIs to connect resources like web registration forms to many different backend systems. The resultant flexibility for tasks like backend update also provide support for automated attacks.
The security conundrum for APIs is that whereas most practitioners would recommend design decisions that make resources more hidden and less available, successful deployment of APIs demands willingness to focus on making resources open and available. This helps explain the attention on this aspect of modern computing, and why it is so important for security teams to identify good risk mitigation strategies for API usage.
Security threats to APIs
OWASP risks to APIs
In addition to its focus on risks to general software applications, OWASP has also provided useful guidance for API developers to reduce security risk in their implementations. Given the prominence of the OWASP organization in the software community, it is worth reviewing the 2019 Top 10 API Security Risks (with wording taken from the OWASP website):
1. Broken Object Level Authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface level access control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
2. Broken User Authentication. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user compromises API security overall.
3. Excessive Data Exposure. Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
4. Lack of Resources & Rate Limiting. Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
5. Broken Function Level Authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
6. Mass Assignment. Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to mass assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
7. Security Misconfiguration. Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
8. Injection. Injection flaws, such as SQL, NoSQL, command injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
9. Improper Assets Management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
API security requirements
As exemplified by the OWASP list, the cyber security community is beginning to identify many familiar, canonical issues that emerge in the use of APIs for public-facing applications. Below are five generalized cyber security requirements for APIs that come up in design and development context frequently for both legacy and new Internet applications:
The adage that knowledge-is-power seems appropriate when it comes to API visibility. Application developers and users need to know which APIs are being published, how and when they are updated, who is accessing them, and how are they being accessed. Understanding the scope of one’s API usage is the first step toward securing them.
API access is often loosely-controlled, which can lead to undesired exposure. Ensuring that the correct set of users has appropriate access permissions for each API is a critical security requirement that must be coordinated with enterprise identity and access management (IAM) systems.
In some environments, as much as 90% of the respective application traffic (e.g., account login or registration, shopping cart checkout) is generated by automated bots. Understanding and managing traffic profiles, including differentiating good bots from bad ones, is necessary to prevent automated attacks without blocking legitimate traffic. Effective complementary measures include implementing whitelist, blacklist, and rate-limiting policies, as well as geo-fencing specific to use-cases and corresponding API endpoints.
Vulnerability exploit prevention
APIs simplify attack processes by eliminating the web form or the mobile app, thus allowing a bad actor to more easily exploit a targeted vulnerability. Protecting API endpoints from business logic abuse and other vulnerability exploits is thus a key API security mitigation requirement.
Data loss prevention
Preventing data loss over exposed APIs for appropriately privileged users or otherwise, either due to programming errors or security control gaps, is also a critical security requirement. Many API attacks are designed specifically to gain access to critical data made available from back-end servers and systems.
The API community continues to drive toward more standardized agreement on the optimal approach to security. To this end, industry groups such as OAUTH, for example, have proposed criteria requirements for API security that are quite useful. The most likely progression is that the software security community will continue to refine its understanding and insight into the full range of API security requirements in the coming years. Observers should thus expect to see continued evolution in this area.
API security methods
API abuse in action
By design, APIs are stateless, assuming that the initial request and response are self-contained, holding all the information needed to complete the transaction. Making program calls to an API directly, or as part of a mobile or web application improves user experience and overall performance. This makes it very easy for a bad actor to script and automate their attack as highlighted in two examples below
Account takeover and romance fraud: Zoosk is a well-known dating application. Bad actors decompiled the Zoosk app to uncover account login APIs. Using automation and attack toolkits, they then executed account takeover attacks. In some cases, compromised accounts were used to establish a personal relationship with another Zoosk user and, as the relationship blossomed, the bad actor requested money due to a sudden death or illness in the family. The unsuspecting user gave the money to the bad actor, who was never to be heard from again. Prior to implementing Cequence, romance scams at Zoosk averaged $12,000 with each occurrence. Now, they are virtually eliminated, resulting in increased user confidence and strengthened brand awareness.
Account takeover and financial fraud: Another example of APIs being targeted with an automated attack involves a large financial services customer finding that attackers had targeted its mobile application login API to execute account takeovers. If successful, the bad actors could attempt to commit financial fraud by transferring funds across the Open Funds Transfer (OFX) API. OFX, of course, is the industry standard API for funds transfer within the financial services community, and as such the APIs are publicly-available and well-documented to facilitate use.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
This is third in a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection. Explosion of APIs The API explosion is also driven by several business-oriented factors. First, enterprises are moving away from large monolithic applications that are updated annually at best. Instead, legacy and new applications are being broken into small, independently functional components, often rolled out as container-based … More
Applications are a gateway to valuable data, so it’s no wonder they are one of attackers’ preferred targets.
And since modern applications aren’t a monolithic whole but consist of many separate components “glued together” over networks, attackers have at their disposal many “doors” through which they can attempt access to the data.
Easy targets will remain popular
Some of these doors are more popular than others. According to the latest Application Protection Report by F5 Networks, attackers love to:
“PHP is a widespread and powerful server-side language that’s been used in 80% of sites on the web since 2013. It underpins several of the largest web applications in the world, including WordPress and Facebook,” F5 analysts explained the attraction.
2. Engage in injection attacks and formjacking (the latter especially when targeting the retail sector).
In 2019, formjacking payment cards was resposible for 87% of web breaches and 17% of known breaches in total (up from 71% and 12% in 2018). In 2019, the retail sector was the most significant formjacking target. 81% percent of retail breaches were from formjacking attacks, while nearly all other sectors tended to be breached most often through the access tier.
“The lesson is clear: for any organization that accepts payment card via the web, their shopping cart is a target for cyber-criminals,” the analysts pointed out.
3. Getting access to accounts (and especially email accounts) via phishing, brute forcing, credential stuffing or using stolen credentials.
“Access tier attacks are any that seek to circumvent the legitimate processes of authentication and authorization that we use to control who gets to use an application, and how they can use it. The result of this kind of attack is a malicious actor gaining entry to a system while impersonating a legitimate user. They then use the legitimate user’s authorization to accomplish a malicious goal— usually data exfiltration,” the analysts explained.
Attackers use a number of tactics to keep these attacks unnoticed, but organizations also have a lot of defensive options at their disposal to prevent them.
4. Go after unmonitored, vulnerable, poorly secured or misconfigured APIs.
“In the days of monolithic apps, whatever core business logic generated value needed to be supported by a user interface, storage, and other meta-functions. Now it is sufficient to develop a single specialized service, and use APIs to either outsource other functions to bring an app to market, offer the service to other app owners, or both,” the analysts explained.
Their widespread used makes them a big target, and a combination of factors make them rich targets:
- They are often configured with overly broad permissions
- Lack of visibility and monitoring.
There are solutions to these problems
Attackers go where the data is, and that’s why organizations in each sector/industry should develop risk-based security programs and tailor controls and architecture to reflect the threats they actually face, the analysts advise.
To counter access attacks, organizations should implement multi-factor authentication where fitting and possible, but should also consider:
- Checking passwords against a dictionary of default, stolen, and well-known passwords
- Making sure the system can detect and prevent brute force attacks by, for example, using CAPTHA, slowing down sessions, setting up alarms, etc.
- Creating simple methods for users to report suspected phishing
- Encrypting or eliminating confidential data from the organization’s email caches
- Enabling logging (to be able to discover what the attackers did when they gained access).
Spotting and foiling injection and formjacking attacks can be done with securing servers, patching injection vulnerabilities,employing change control, using web application firewalls (WAFs), through testing and watching of all third-party components on sites with forms accepting critical information, and so on.
But organizations should be aware that the injection landscape is constantly changing, and they have to follow the trends and adapt.
Finally, organizations can mitigate the risk of API attacks by:
- Making (and maintaining) an inventory of their APIs
- Deploying authentication for them and storing credentials securely
- Limiting their permissions
- Monitoring them (by logging connections and reviewing them)
- Encrypting the API connections
- Testing APIs
- Implementing API security tools.
This is the first of a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection.
Purpose of article series
Researching the wide range of API security alternatives can be confusing – even to seasoned experts. This article series is written with the goal of helping all types of readers better understand the pros and cons of the various modern approaches to protecting APIs from cyber security risks. The material is intended to help enterprise security and software development teams develop and maintain a consistent protection philosophy.
The target reader includes software developers who depend on and use APIs every day, as well as technical managers who might have responsibility for API security in their organization. The target reader also includes, however, technical-minded individuals possessing little experience with APIs, but who are nevertheless interested in the security aspects of this important issue. We try to describe the API security concepts in a manner accessible to each type of reader.
Introduction to APIs
The typical user of network and Internet services tends to think of computer interfaces in terms of screens, keyboards, monitors, and the like. These interfaces are the visible means by which systems exchange information with human users, and they have advanced rapidly in recent years. The touch screen from Apple, for example, emerged only a decade ago, and a generation of youngsters barely remembers what the world was like before such useful capability existed.
But there is another type of interface that exists in computing, perhaps more hidden to the everyday user. This other type of interface is how software programs communicate with one another. For many years, this process was poorly specified, with programmers inventing protocols for something called inter-process communication (IPC). An early operating system from Bell Laboratories called Unix, which now serves as the base of both Apple iOS and Android, made IPC designs easier, but they were non-standard.
By 2000, the industry decided that these software-to-software interfaces needed to become more open and standard. Such technical decision became the genesis of what we now refer to as an application programming interface or more commonly – API. Recognize that an API provides a standard interface through which two software programs, also referred to commonly as processes, can communicate, share messages, or managed shared memory.
More specifically, an API is an interface which makes software services available to workloads or applications for bidirectional communication and message sharing. APIs are also commonly used to share memory between different processes. An API is stateless in nature, and will commonly include all the information needed to complete a transaction, unlike a web form that may require multiple transactions for processes like user registration.
Figure 1. General API model
Unix Operating System IPC
Roughly half a century ago, researchers Ken Thomson and Dennis Ritchie of Bell Laboratories initiated a project to build a multitasking operating system for use inside AT&T. Despite such relatively modest original goals, the so-named Unix software and associated design philosophy that they produced have served as the technical base for virtually every successful commercial operating system since. Linux and Android are direct derivatives, whereas iOS and Windows are massively influenced by Unix.
An important design consideration for the Unix operating system involved the need to create an IPC mechanism that would allow for data sharing and message passing between computer programs. Thompson and Ritchie were influenced by many rapidly evolving technical concepts being designed at the time in the computer science community. This included the emergence of producer-consumer models, as well as new methods for distributed computing.
The Unix IPC approach can be viewed as an early attempt to address many of the issues now covered by APIs. Both are concerned with the need to modularize, standardize, and simplify the manner in which data or messages are shared between cooperating processes. The big difference, obviously, is that modern APIs benefit from the massive scale that comes with the Internet. Original Unix efforts were local and operating system-specific.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
From May 2019 and continuing on until the end of the year, there was a dramatic shift by criminals who started targeting APIs, in an effort to bypass security controls. According to data from Akamai, up to 75% of all credential abuse attacks against the financial services industry targeted APIs directly.
According to the report’s findings, from December 2017 through November 2019, 85,422,079,109 credential abuse attacks were observed. Nearly 20 percent, or 16,557,875,875, were against hostnames that were clearly identified as API endpoints. Of these, 473,518,955 attacked organizations in the financial services industry.
A mix of API targeting, and other methodologies
But not all attacks were exclusively API focused. On August 7, 2019, the single largest credential stuffing attack against a financial services firm was recorded, consisting of 55,141,782 malicious login attempts.
This attack was a mix of API targeting, and other methodologies. On August 25, in a separate incident, the criminals targeted APIs directly, in a run that consisted of more than 19 million credential abuse attacks.
“Criminals are getting more creative and hyper-focused on how they go about obtaining access to the things they need to conduct their crimes,” said Steve Ragan, Akamai security researcher and principal author of the State of the Internet / Security report.
“Criminals targeting the financial services industry pay close attention to the defenses used by these organizations, and adjust their attack patterns accordingly.”
Criminals exposing data through different methods
Indicative of this fluid attack dynamic, the report shows that criminals continue to seek to expose data through a number of methods, in order to gain a stronger foothold on the server and ultimately achieve success in their attempts.
SQL Injection (SQLi) accounted for more than 72% of all attacks when looking at all verticals during the 24-month period observed by the report. That rate is halved to 36% when looking at financial services attacks alone. The top attack type against the financial services sector was Local File Inclusion (LFI), with 47% of observed traffic.
XSS was the third-most common type of attack against financial services, with a recorded 50.7 million attacks, or 7.7% of the observed attack traffic.
Criminals still leveraging DDoS attacks
The report also shows that criminals continue to leverage DDoS attacks as a core component of their attack arsenal, particularly as it relates to targeting financial services organizations.
Observations from November 2017 until October 2019, show the financial services industry ranking third in attack volume, with gaming and high tech being the most common targets. However, more than forty percent of the unique DDoS targets were in the financial services industry, which makes this sector the top target when considering unique victims.
“Security teams need to constantly consider policies, procedures, workflows, and business needs – all while fighting off attackers that are often well organized and well-funded,” Ragan concluded. “Our data shows that financial services organizations are constantly improving by adopting fluid security postures, forcing criminals to change their tactics.”
Facebook recently pledged to improve its security following a lawsuit that resulted from a 2018 data breach. The breach, which was left open for more than 20 months, resulted in the theft of 30 million authentication tokens and almost as much personally identifiable information. A “View As” feature that enabled developers to render user pages also let attackers obtain the user’s access token.
The theft of access token represents a major API security risk moving forward, but also highlights how API risks can remain undetected for so long. Of course, Facebook is not unique in this risk. As Microsoft CEO Satya Nadella quipped, “all companies are software companies.”
Digital transformation and cloud migration trends have accelerated an agile development cycle known as continuous integration and continuous deployment/delivery (CI/CD), which enables DevOps to constantly push new updates–like that Facebook app in your pocket.
Yet even as the industry embraces this new software model, much of the security has been commodified by infrastructure providers like Amazon and Microsoft, including container protection, authorization, and data encryption. Likewise, the security functionality of first generation gateways and firewalls, such as DDoS protection and bot mitigation has also been consumed into infrastructure.
However, as this first generation of infrastructure is more or less as good as it gets, it suggests a deeper risk to the underlying application transportation layer, its APIs. The reason that APIs are so powerful as a communication tool is the same reason that they are so vulnerable, APIs have great flexibility in their parameters. As such, they exist in everything from so called “single-page” web applications to mobile apps, and even industrial IoT systems.
Traditionally, API traffic has moved from internal to external callers (“north-south”), which is why the first generation of security has been a tolerable band-aid. However, modern application architectures are now enabling internal application-to-application communication (“east-west”), which represents a critical risk surface because of its ability to move laterally. Furthermore, there is little visibility into this traffic.
API risk is rooted in a lack of visibility, not only into its traffic, but also into its flexible and powerful parameters, known as API specifications—or “specs.” DevOps and SecOps attempt to mitigate this risk by creating and maintaining API catalogs, which are a collection of its specs. But, the reality is that this is a highly manual process in a constantly changing environment. Keeping it up-to-date is easier said than done.
OWASP has introduced its API Security Top 10 to help make sense of this new API risk surface, which is a helpful starting point for a discussion of API risk. We can further simplify API risk into three common categories categories:
1. Unknown or outdated API specifications.
2. Uninspected APIs.
3. Uncontrolled third-party APIs.
Risks related to unknown or outdated API specifications include a complete absence of an API spec, a loosely-defined API spec, or an out-of-spec API call, which typically result from rapid development changes. Bad actors can exploit out-of-spec API calls by accessing customer data through undocumented “shadow” APIs or even simply elevating permissions through a parameter like “administration=yes.”
The risks related to uninspected APIs include launching lateral attacks through compromised servers, encrypted traffic remaining uninspected and API parameters set out of critical range—such as sabotaging an industrial IoT device by setting its temperature high enough to break down. Perhaps the most common of these risks is to miss validating the login session against its parameter. These sorts of mismatches can be the source of severe data breaches, as back-end services are unable to validate the credentials exfiltrating data.
Finally, the risks related to uncontrolled third-party APIs demonstrate that the use of APIs is not limited to incoming calls from enterprise users and partners, but also outgoing calls from business applications to external services. These outgoing calls can be abused to exfiltrate data, such as exposed storage server APIs. Alternatively, public API calls may use compromised credentials to access enterprise services to exfiltrate data. Unlike private data centers, it may not be possible to turn off these public APIs.
No matter how you slice it, the source of these API risks is a lack of visibility, both into their traffic and into their parameters. Next-generation API security solutions offer the promise of automatically discovering and continuously maintaining API catalogs, for further monitoring and alerting. For those that do maintain an up-to-date API catalog, there is benefit not only to security, but also to improving quality assurance and debugging across the DevOps process.
As DevOps moves from development to test environments, and ultimately into production, an API catalog can be used to compare and contrast areas of improvement. In this regard, it is imperative not only for CISOs to gain visibility into their APIs, but also for CIOs. In this way, they will not only secure their APIs, but also accelerate their digital transformation.
A Twitter API that’s intended to help new account holders find people they may already know on Twitter has been abused by known and unknown actors to tie usernames to phone numbers and potentially de-anonymize certain users.
How did it happen?
“On December 24, 2019 we became aware that someone was using a large network of fake accounts to exploit our API and match usernames to phone numbers. We immediately suspended these accounts and are disclosing the details of our investigation to you today because we believe it’s important that you are aware of what happened, and how we fixed it,” Twitter shared on Monday.
“During our investigation, we discovered additional accounts that we believe may have been exploiting this same API endpoint beyond its intended use case. While we identified accounts located in a wide range of countries engaging in these behaviors, we observed a particularly high volume of requests coming from individual IP addresses located within Iran, Israel, and Malaysia. It is possible that some of these IP addresses may have ties to state-sponsored actors.”
Malicious actors (whether state-sponsored or just fraudsters motivated by money) who can match Twitter usernames to phone numbers can not only unmask users that might want to remain anonymous on the microblogging service, but could also use that information to perform SIM swapping attacks and receive the second authentication factor needed for hijacking accounts additionally secured via 2-factor authentication.
The company did not mention it in the advisory, but the trigger for the investigation was a security researcher’s months-long effort of exploiting a flaw in Twitter’s Android app that allowed him to match 17 million phone numbers to Twitter user accounts.
Apparently, the API endpoint did not accept lists of phone numbers in sequential format, but the researcher got around this flimsy protection by generating more than two billion phone numbers, randomizing them, then uploading them to Twitter via the Android app.
This specific bug was present only in the app’s upload feature and has since been fixed.
“The endpoint matches phone numbers to Twitter accounts for those people who have enabled the ‘Let people who have your phone number find you on Twitter’ option and who have a phone number associated with their Twitter account. People who did not have this setting enabled or do not have a phone number associated with their account were not exposed by this vulnerability,” Twitter explained.
After the investigation, the company made “a number of changes to this API endpoint so that it could no longer return specific account names in response to queries.”
OWASP’s API Security Project has released the first edition of its top 10 list of API security risks.
The most common and perilous API security risks
API abuse is an ongoing problem and is expected to escalate in the coming years, as the number of API implementations continues to grow.
The OWASP API Security Project aims to provide software developers and code auditors with information about the risks brought on by insecure APIs.
Earlier this month, they’ve published the official OWASP API Security Top 10 list, which looks like this:
1. Broken Object Level Authorization
2. Broken User Authentication
3. Excessive Data Exposure
4. Lack of Resources & Rate Limiting
5. Broken Function Level Authorization
6. Mass Assignment
7. Security Misconfiguration
9. Improper Assets Management
10. Insufficient Logging & Monitoring
Each of the risks comes with an explanation, example attack scenarios and advice on how to mitigate it it. It also includes links to helpful free resources (education material, guides, cheat sheets, etc.) for developers and DevSecOps practitioners.
The document can be downloaded from GitHub.
“There are issues that look simple, but are critical, like good housekeeping and documenting APIs. There are also complex issues of access control that might require some attention from the design phase,” Erez Yalon, director of security research at Checkmarx and co-lead on the OWASP API Security Project, told Help Net Security.
“To put it simply, follow this list closely – OWASP has done the groundwork for development teams and security professionals to improve their knowledge around security risks to look out for when implementing APIs. Understanding the vulnerabilities outlined within will help teams to mitigate against API security risks and to put systems into place moving forward.”
This first version of the list has been based on publicly available data about API security incidents, security experts’ contributions, and discussion with security practitioners.
“We are planning another version of the OWASP API Security Top 10 in 2020,” he noted.
“This time, in addition to using the knowledge of the AppSec community, we will also use a public call for data that will enable us to fine-tune the list. Additionally, we will be working on a cheat sheet that will be a more practical guide for developers, pen-testers, and auditors.”
As adversaries set their sights on this emerging target, awareness and education around the security pitfalls outlined in the OWASP API Security Top 10 list will be key to the development of secure applications in the future, he concluded.
Developments in integration and APIs have provided businesses with huge benefits. Together, they provide businesses with newfound opportunity to unlock new revenue sources by making data more accessible rather than being stacked disparately at the edge or in on-premise sites.
However, as with any business strategy there are risks, and integration technologies must be used wisely. This rings particularly true when customer data is involved. So, how can organizations reap the rewards of APIs while ensuring consumer data is secure?
Record-breaking year for data breaches
To achieve business success, organizations need to deliver growth from digital transformation and make decisions based on large volumes of sensitive customer data. However, 2019 was the worst year ever for data breaches and, what’s more, today’s consumers are increasingly savvy about their data. More than ever, organizations need to be make sure that the way they handle and process customer data complies with contractual agreements.
That said, while mass data breaches are regularly dominating the headlines, the biggest cause of worry is no longer hackers. Rather, organizations need to look beyond the papers and ensure the data they’re processing is done in accordance with the purposes for which their customers believe it is being used.
Since GDPR was implemented, almost €400 million of fines have been levied. In January 2019, for example, France fined Google €50 million for breaching the transparency and consent requirements in connection with the way they processed personal data for ad personalization. Then, in September, Twitter admitted that it, too, had processed personal data in a manner that may have been in breach of regulations.
In both cases, it seems reasonable to speculate that the over-enthusiastic use of data by developers, exposed through APIs, may be at the root cause of such incidents. So how could this and the subsequent reputational fallout have been avoided?
Unlocking new sources of revenue
According to UK ICO guidelines, there are six lawful bases for processing data to which businesses must effectively manage and deploy their APIs if they are to ensure compliance. This means having complete, end-to-end visibility and security for B2C, B2B and B2B2C transactions, spanning across all data sources whether they be applications, devices, on-premise or in the cloud.
Failing to comply could cause severe reputational damage. For example, in the event of a data breach, individuals may be personally liable for up to £500,000 per incident. In this context, how can organizations trust developers to simply “do the right thing”? Perhaps more importantly: how can organizations ensure they have the necessary systems in place to control the way APIs expose sensitive data?
Luckily, integration and API platforms offer a solution, ensuring that the whole API lifecycle, from requirement to retirement, can be properly managed. This helps to minimize the likelihood that the power APIs provide is abused. From there, policy engines ensure the usage scope of every API can be defined and enforced while reverse invoke technology removes the need to open firewall ports, reducing the chances of hacking.
Integration and API platforms enable users to swiftly onboard partners and exchange documents with API based standards. With partner ecosystems more critical than ever, this proves invaluable as companies look to differentiate their offerings and compete effectively. In essence, coherent integration ensures that organizations can transact and share data with partners while platform technologies ensure they are created and managed effectively.
With access to this information, businesses can ensure the timely and accurate transaction of daily, crucial business documents while streamlining their supply chain, accelerating order-to-cash and increasing customer satisfaction.
Securing data with APIs: Improving efficiencies
APIs provide companies with newfound opportunity to accelerate their business outcomes. However, given the access to large volumes of sensitive information, they need to be leveraged responsibly. Businesses must therefore be open and transparent around the way they interact with consumer data, with the alternative leading to financial and reputational fallout.
Integration and API technologies enable businesses to avoid these risks, streamlining partner onboarding and providing full visibility and control over APIs. This will ultimately allow a company to manage their APIs effectively and efficiently, while ensuring any contractual and regulatory obligations are adhered to.