A Problem Like API Security: How Attackers Hack Authentication

There is a sight gag that has been used in a number of movies and TV comedies that involves an apartment building lobby. It shows how people who don’t live there, but who want to get in anyway, such as Girl Guides looking to sell cookies to the tenants – simply run their fingers down every call button on the tenant directory, like a pianist performing a glissando, knowing that at least one of the dozens of apartments being buzzed will let them in simply out of reflex or laziness.

This is a fitting example of broken authentication in the analogue world: an automated system designed to keep non-residents out and to allow them in only by granting individual manual permission that is easily overrun and exploited, without any need for sophisticated tools.

Broken authentication is a term that is used in the world of infosec to describe similar types of outcomes. Organizations of all types that have internet-facing media such as websites and APIs use some form of authentication to prevent the wrong people from “buzzing themselves in,” but these too, are woefully not up to the task.

Attacks that exploit APIs

One of the most common points of weakness is the API attack, in which bad actors force their way in through a variety of techniques, all of which essentially abuse the construction of the APIs own interface, after which they can deposit malware, steal data, or perform other types of crime and sabotage.

One of these techniques is credential stuffing, which involves using stolen usernames and passwords – obtained through data breaches, for example – to fool the API into recognizing a valid ID. This, by the way, is one of many reasons why everyone should change their passwords regularly.

A related technique involves brute force attacks which, instead of using bona fide names and passwords, throws a whole lot of guessed combinations, such as jlee@company.com in tandem with a huge list of well-known passwords such as sunshine123, or made-up passwords using common word combinations. Although there are billions of variations of names and passwords to use, there are also millions of computers out there, pumping out these billions of variations consistently and quickly. Therefore, it’s called a brute force attack. It just throws combinations at the front door, buzzing each one until the API or website lets one in. It also illustrates the reason passwords should never contain such easily guessed words but should always be made up of randomly generated strings of letters and numbers, with the help of a password manager.

And just like street-smart Girl Guides, “attackers will also throttle their credential stuffing attacks to avoid detection and therefore avoid triggering rate limits on API endpoints that an organization might set. Services with normally massive traffic flow may not recognize a credential stuffing attack at all, because they can’t distinguish the activities of a single attacker within the mass of traffic.”

A brute force attack on an organization is made easier when predictable address taxonomies are used, such as “employee’s first-name initial plus surname at company domain dot com,” as in jlee at company dot com. This cuts down by a huge amount the variables that need to be guessed by threat actors’ machinery. In fact, this taxonomy is usually given away directly on a company’s website.

Since most people still choose easy-to-remember passwords consisting of words and numbers (password123 still being one of the most popular), there are also a great many predictable passwords that can be applied to each name as the brute forcing continues. To a human, the activity of brute forcing may seem like an impossible workload, but to a computer, it’s what they like to do.

APIS are increasingly vulnerable

The numbers, though, show a shocking story. As quoted by SC Magazine on a recently released report on API security, “95% of respondents acknowledging they had an API security incident in the last 12 months, but 34% of them also have no API security strategy in place” shows just how vulnerable organizations have become, especially when such lax password hygiene standards come in contact with APIs. The report’s key messages that the media picked up on included the following four points:

• Ninety-five percent of surveyed organizations have experienced an API security incident in the past 12 months.
• Despite the increase in attacks and incidents, organizations running production APIs remain unprepared for API attacks.
• Lack of expertise reinforces the high need for education on API security.
• Developers must better understand how bad actors propagate attacks, to harden their APIs.

The report itself delivers more alarming numbers as well:

• API attacks rose 681% in the past 12 months, compared to a 321% increase in overall API traffic.
• Two-thirds of respondents (62%) admitted they have delayed application rollouts because of API security concerns.
• Eighty-three percent of respondents are not very confident that their API inventory is complete.

Together, these facts paint a less-than secure picture. Threat actors remain relentless in their quest to penetrate their targets. Brute force and credential stuffing attacks may not be the most sophisticated of hacking techniques, but they remain effective thanks to a surfeit of usable data in the form of stolen password databases, paired with persistent reluctance on the part of individuals and companies to maintain and improve password strength.

Furthermore, an increased dependence on APIs to facilitate communication between a company and its business partners, without proportionate hardening of those APIs leaves yet another gaping security hole, one that is likely to be found and exploited by bad actors who actively focus on scanning for such vulnerabilities.

Why Should We Care?

The reason people should care about the vulnerability of APIs and other areas of a company’s digital infrastructure is that every breach and attack have far-reaching and complex consequences. They are seldom just a one-time activity. It’s on par to those Girl Guides getting into the building, and then leaving the door wide open when they leave. Privileged data gets exposed to the entire internet. Malware and other technologies get implanted, leading to further attacks and destruction. Beyond the data, companies face litigation, damage control, loss of market share and market valuation, repair of compromised systems and delays in system improvements – the list goes on, and as it does so the company’s lights flicker and dim menacingly.

About the Author: Steve Prentice is a specialist in organizational psychology, focusing on the interaction of people, technology and change. He works as a speaker, author, broadcaster and writer, with clients in IT, cybersecurity, government, healthcare, and law, dealing with cybersecurity, AI, blockchain and the future of work.  

Steve is the author of three business books and is a ghostwriter for experts worldwide. He is a visiting lecturer at the at Ontario Tech University, and delivers keynotes, media interviews, white papers, and podcasts on these topics. 

He holds degrees in journalism and psychology, and is pursuing a PhD in Psychology, focusing on brain/technology interaction. 

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.