The inherent vulnerabilities harming financial services companies

Dan Woods, VP of the Shape Security Intelligence Centre at F5, explores inherent vulnerabilities in the financial services industry, explains why they happen, how to protect against them, and why traditional countermeasures alone don't work.

Financial services organizations are among the most targeted in the world by the most sophisticated and well-resourced attackers.

It is increasingly important that the entire organization works together to identify and protect against attacks that exploit inherent vulnerabilities, which cannot be patched in a traditional sense because they result from valid and often critical business requirements.

Credential Validation Attacks, A.K.A Credential Stuffing

Credential stuffing entails bad actors obtaining hundreds of thousands, millions, or billions of username password pairs from the dark web or from a poorly secured organization. They then use automation to try these against the login applications of other organizations that were not part of the original compromise.

Bad actors sometimes launch attacks through a fintech, such as a loyalty point or financial aggregator, or a bill payment service. To use these free services, subscribers must first ‘link’ their accounts at their bank, retailer, hotel, airline, telecommunications provider, etc., by giving the fintech their username and password for each account. The fintech then attempts to programmatically log into each account. If the subscriber provides the correct username and password, the linking continues. After an account is linked, the fintech uses automation to repeatedly log into the account and scrape the contents–sometimes thousands of times per day.

Canary Accounts

With canary accounts, the cybercriminal tries usernames and passwords from stolen or purchased credentials, which exhibit a 0.1 to 3.0% login success rate. They then use the same infrastructure to log into one or more canary accounts several times, which exhibit a 100% login success rate. This results in an increased net login success rate for all transactions from the same infrastructure.

Account enumeration attacks

Another attacker technique is to launch an attack against an application that will confirm whether the username corresponds to a valid account. If not, then the attacker knows using the password would result in a failed login. Applications frequently targeted with account enumeration attacks are Forgot Username, ID, or Password, and Create Account.

Other ‘create account’ automations

At Shape, we frequently see automation against the ‘create account’ application for reasons other than account enumeration. This is especially true for financial services organizations that are exploited for money laundering and for the creation and maintenance of synthetic identities.

How to protect your organization

Protecting your organization from attacks against inherent vulnerabilities results only from a strict adherence to a perpetual three-step process:

Step 1: Gain visibility

Identifying the applications likely to experience automation requires informed and objective answers to questions for each application. Why might someone launch automation against the application? Why might someone perceive a monetary or intelligence gathering benefit from doing so? Or is there a long term, more strategic incentive? Finding answers to these questions requires fluency in the applications and workflows, and comprehensive understanding of the automation seen in the wild against other financial organizations.

Step 2: Take action on automation

Allow-list the good automation and mitigate the bad automation. Key things to consider:

  • Avoid allow-listing transactions using an attribute that can be easily spoofed, such as a user agent string. Ideally, allow-list transactions using a shared secret somewhere in the HTTP header.
  • Don’t mitigate bad automation by dropping the session, which gives the actor feedback that the automation is being mitigated and incentivizes retools. Rather delay the actor’s realization that the automation is being mitigated. Shape accomplishes this by offering additional mitigation options, such as: redirect or forward the transaction, inject or change something in the transaction and pass it to origin, or respond with a fully formed HTML page.

Step 3: Conduct ongoing retrospective analysis

Organizations must conduct ongoing retrospective analysis on transactions hitting the targeted application to quickly identify retools or other unwanted automation, with human-supported artificial intelligence and machine learning systems operating on aggregate transactions.

You must also have a means for quickly updating your real-time defenses without impacting legitimate customers.

WHY TRADITIONAL COUNTERMEASURES DON’T WORK

Traditional countermeasures include layer 5–7 defenses, such as web application firewalls (WAF), requiring a second factor of authentication (2FA) for the targeted application, or bot detection and prevention tools such as a CAPTCHA:

  • Web Application Firewalls (WAF). Traditional WAFs look primarily at the Application Layer to defend against the OWASP Top Ten. But the Application Layer provides insufficient signal to reliably detect sophisticated automation. This requires additional signals, such as those obtained by collecting behavioral biometrics and interrogating the browser/device environment.
  • Second Factor Authentication (2FA). 2FA plays an important role, but widespread use is expensive and creates friction for customers. And while it makes account takeover (ATO) more difficult, it doesn’t always prevent Credential Stuffing.

With most 2FA implementations, a customer submits a username
and password and if those are correct, they are asked to enter the second factor
authentication. If the details entered are incorrect, the customer receives an error message and is not asked to enter the second factor of authentication. The difference in the response tells the attacker if the credentials are correct. The attacker has not taken over the account but can sell the known good credentials to another attacker who specializes in defeating 2FA (e.g., via port-outs, SIM swaps, SS7 compromises, iOS/Android malware, or social engineering).

  • CAPTCHA causes undesirable friction for customers leading to session and revenue abandonment. Much like 2FA, and they don’t stop bots. Dozens of companies use optical character recognition (OCR), machine learning, and even human click farms to solve CAPTCHAs for a nominal fee.

What next?

Shape has found that after successfully mitigating unwanted automation against web and mobile applications, and after doing battle with actors as they retool over weeks and even months, many actors continue their activity manually using human click farms. That’s why we offer multiple, continually evolving products to protect our customers from these threats.