API attack prevention, a real-life example

I posted a previous article about the ways to protect Web Services and protect REST APIs and got contacted to help with an inquiry around how an API Gateway could help mitigate a recent attack that occurred. You will read below a real-life example of API attack prevention.

API attack prevention situation

The situation got described to me like this:

“The company provides an app for trading (stock papers) and is  receiving data thru an API. The hacker obtained user and passwords probably using phishing and reverse engineering to capture/rebuild specific payload structures to falsify operations.”

This sounds scary, doesn’t it? It is not that unusual. Companies like Kaspersky and others have already raised that more sophisticated cyber attacks are on the increase.

The diagnostics

So how can enterprises develop an API attack prevention strategy for such kind of scenario?
In the first place, it needs proper monitoring to get detected which seemed to be the case here. It’s also interesting that in this scenario it was not a general issue of the implementation or mistake, it was caused by a higher level of effort to gain access to credentials. This can be seen quite often if the value of the data or action is high. Intellectual property, any kind of financial transaction (stock papers, payments, etc.) are interesting here.

Some people might say, ah you need to encrypt the traffic to stop this kind of attack. The point is that this has to be implemented the right way on the client side too. If the attacker got access to login information, it’s likely that he would be able to gain access to additional things like Certs and Keys in order to be able to decrypt the payload.

The counter-measures for API attack prevention

1. First counter-measures against this API attack: out-of-band notification
The receiving system could, for example, implement a notification system which would push notifications to the user. While the user gets onboard for the first time, he could provide a mobile phone number where those notifications would be sent to.

If someone would take over your account, you would recognize it by getting those SMS push notifications without having to perform any action. This allows at least the user to quickly change the password or react on the account take over. Push notifications etc. can be provided by MBaaS Platforms and this can for sure be integrated within the policies of an API Management solution to get triggered.

You have to be a little bit careful with the onboarding process and make sure that it’s hard to change a mobile number too.

Those SMS can also be used to send messages when new devices get identified by different IP, Host Header, etc. accessing the service. This is for example what Facebook or Google do when you log in from different parts of the world. This doesn’t prevent the attack entirely but provides a way to react quicker.

2. Second counter-measures against this API attack: two-factor authentication
Another way could be to integrate with an OTP (One-Time-Password) system like Google Authenticator or other systems. Most providers like Apple, Google, Microsoft or AWS provide this two-factor authentication for their accounts. 

The second factor, a second password, for example, is provided by the OTP app and is changed frequently (for example every 120 seconds). You can only access the service and execute actions if you have both username, password, and the OTP.

There also exists an alternate method that consists in having two-factor authentication leveraging SMS push notification containing an OTP. The SMS contains a time-boxed password you have to present for login or other actions that you want to perform and needs to be entered before any action get executed. This method is currently widely used here in Germany for interacting with your bank or insurance company to protect your account with an additional layer of security.