MSPs large and small are systematically being targeted over and over in the news. It’s almost weekly a new article comes out about a given large provider being targeted. Many of these attacks come from API weaknesses. You can’t control the provider or service, but you can minimize the chance of these attacks impacting you and your customers.
Leaky APIs
Leaky APIs are APIs which allow easy exfiltration of data from a service. These exploits often stem from deprecated APIs or privilege escalations. Many deprecated APIs exist in products for backwards compatibility, but they often come with caveats and holes.
Privilege escalations can happen on APIs due to loose queries which can return data from outside of their scope. Other escalations rely on multiple APIs which accidentally return data outside the scope a user can see normally due to their interactions. A deprecated API may help break another API when glued together with the wrong product.
These types of attacks are often used to harvest credentials or information for attacks later. Stolen passwords can be used on any similar account on multiple platforms to see what is shared. Hackers glean data which makes their later attacks easier either for traditional attacks or for things like phishing attacks.
Weaponizing APIs
With the creation of things like fileless malware and easy, privileged access via RMM tools, weaponizing an API has never been easier. Other products like Webroot have been had similar incidents from adding the feature to run commands remotely. This feature creep combined with API access makes these tools further targets.
Most products rely on various SQL products for databases. Many APIs where the developers are not security conscious will be a thin layer between the user and raw SQL queries. These can be weaponized to poison the data allowing greater access or to exfiltrate useful data. Depending on the product, it may be possible to insert hostile, arbitrary code which gets run by something within the API. Some RMMs even store scripts as blobs in the database.
How Do These Attacks Happen?
These attacks happen because of lax security policies on both sides of the equation. Many vendors do not take into account the ramifications of the access their API can provide. Vendors which integrate their products may ask for more permissions than they should need to function. A lot of permission sets are too permissive in general because its easier for the developer and the user to set up.
Clients of these products often fail to limit users enough. API users floating around provide an easy in to a company if they are compromised. Sometimes, the way multiple APIs talk to one another may be targeted as well. A simple return status from a query in a limited API may provide information that the other API would not normally have given. A simple boolean reply may provide a necessary bit of information for a malicious actor to work off of.
What Can You Do?
Removing unnecessary API users or users which may have API access is one of the easiest steps to protecting yourself, even from APIs outside of your control. Turning obsolete or unnecessary API versions, or even entire APIs off, is another great step. Use it or lose it. Trim off enough of the fat, and the hunter will target easier, more profitable prey.
Shrink your attack surface to shrink what you have to keep safe. Besides just trimming off the obsolete, scope your API users. An API user which only reports from a product doesn’t need write access. Your users need Two-Factor Authentication (2FA) everywhere possible. Do not share credentials between API users and do not recycle user names if you can help it. These basic steps have headed off many attacks before they even have the chance to become a threat with very little imposition on our technicians.
If you run products in house which have an API you use, try blocking traffic based on IP for whatever is using it. This isn’t always possible, but can often be used to limit certain service APIs to specific, known entities which limits the impact of a leaky or broken API. Rate limiting connections is another great step. If your average client hits 5 requests per hour, why not set a limit of 10 requests per hour so that brute force attempts take significantly longer? Alerting on these thresholds is another great step, especially if you control something in the stack which can see this.
Researching Products
No product is going to be perfect, but you can shop around to minimize damage. How does your current product handle exploitation? Are they quick to report it or do they take their time? A vendor which reacts fast, may still get hit, but at least you’ll know before your clients do and be able to protect yourself.
A vendor which tells you about an exploit quickly is also a vendor which works on fixing it quickly. Look at the vendor’s response history and how long it takes them to clear out serious CVEs to know how big a threat they are to your business. If they can’t keep up with serious vulnerabilities which are reported, what else are the missing that’s not reported yet?
Always be on the lookout to how a vendor impacts you and your clients. A vendor which never has real access is easier to trust than one which can make system level changes. Look out for how they handle older APIs too. A vendor which leaves deprecated features in too long runs the risk of being exploited down the line.
Ask your vendor what they do about older versions and whether or not they rate limit requests and accounts. See what the scope of their API access is. The irony is that those proudest of their APIs open access will usually be the first to tell you about it. Weigh this with your other options and the impact on your client before signing.
Our Strategy
We minimize unnecessary API interaction and work to maintain best practices to prevent exploits. When an API becomes obsolete, it is removed from our system where possible. API access is also further limited for fixed entities to prevent more wholesale access from being available off premise. Users need 2FA to get into basically anything. These patterns heavily minimize the attack surface with very little maintenance. Our large community contributes to helping make sure every potential exploit is known as soon as possible.
Our Security Focus
We focus on a holistic approach to security, and try to stay ahead of exploits and reduce the risk of any given component. Your security is only as strong as its weakest link, so you must be vigilant. Prevent unauthorized API access by preventing any access unless necessary. We want to know about an exploit as soon as it is public, if not before and be able to react to it.
Cutting off your finger is better than losing your arm, but not having to lose either is best. Prioritization of exploits is extremely important to surviving in the modern security landscape. We’re well past the days of “perfect security” even being a pipe dream, let alone realistic. We work to hedge our bets and make our platform the least ideal for hackers without sacrificing functionality. An ounce of prevention, even if it’s bitter, is a lot better than a pound of cure.
Going Forward
Stay ahead of hackers by locking down every aspect of your security. APIs are one of the most often overlooked, easily exploited part of many products. Almost every major software product is going to have an API of some kind too. Know what you’re dealing with and limit the damage where you can. MSPs have become low hanging fruit to many hackers, elevate your security and elevate yourself from being next.
by Sage Driskell
