One of the most often overlooked cybersecurity attack vectors, and one of the biggest threats is application-programming interface (API) security. According to the security giant, Akamai, over 80% of all Content Delivery Network (CDN) Internet traffic is API traffic.
APIs enable applications, services and micro services to work together. For example, organizations use APIs to connect applications, data services and mobile applications to deliver services to their customers for banking, gaming, healthcare or any other integrated enterprise applications. Internally, DevOps use APIs to extend monolithic legacy applications to deploy loosely coupled microservices (i.e., containers) to improve the overall efficiency and capabilities of internal or legacy systems (ERP, CRM, SCM, etc.). APIs drive most of today’s digital transformation initiatives and integration strategies. Sadly, most of today’s coders and DevOps personnel are either lazy and/or do not have the knowledge or understanding of how to generate secure code. In my opinion, most of the source code that goes into APIs is garbage and has zero emphases on security (primarily open-source code from GitHub and other repositories). For example, many of the API vulnerabilities are due to common security flaws such as:
- Not understanding the difference between authorization and authentication
- Security misconfigurations and authorization policies
- Lack of sufficient logging and monitoring of data across infrastructure systems.
Over the past couple of weeks, I have been working with a large bank to stop a breach that exploits Zelle’s digital payment system. This attack allowed for the movement of thousands of dollars from unwitting user accounts to email addresses across the globe. When dissecting the cybersecurity “kill-chain,” this attack had several factors:
- The initial breach came from a full takeover of the victim’s email account
- Attackers were able to request user credentials to change PIN, User IDs and passwords via both email and voice verification
- Bad guys took over the account and registered their identities and biometrics on their own devices
- Attackers used Zelle to register email addresses and transfer money $1,000 at a time to themselves and their friends daily. This attack uses a vulnerability between the API used between Zelle and the financial institution.
Sadly, most banks and other institutions that leverage Zelle do not recognize the lack of security of the Zelle service. Bottom line is that Zelle must fix its security flaws—until then I would not recommend sending money using the platform.
Zelle’s service enables users to send money between people easily via email. Sadly, this simplicity and ease of use attracts hackers and scammers. Zelle has enabled the next generation of hackers that exploit users via phone, email and traditional phishing methods to access user account information, including usernames, passwords and PIN information. This fraud is different from conventional bank fraud, and the ease of using a vulnerability in the Zelle API to move untraceable funds makes it difficult for both the consumer and bank to defend against an attack. Again, until Zelle can defend against API attacks in its service, consumers should use alternative services such as Google Pay, Venmo or PayPal.
So as a consumer, how can you protect yourself? First, password hygiene is essential – change your password often and do not use the same password across applications or services – do not use birthdays, anniversaries, or any other identifying patterns. Secondly, enable multi-factor authentication (MFA) on all your accounts and devices. Third, understand your banking policies when it comes to recovering money stolen from your account—many banks will only provide partial recovery of funds taken from your account. Finally, do not allow your financial institution to automatically enroll you in third-party applications like Zelle without your approval. Hackers are having a field day with unsuspecting remote workers left outside of the confines of their companies infrastructure due to Covid-19; the risks could not be higher. The question we should be asking ourselves is not if we will become compromised, but when.