software security

With WannaCry and now Petya we’re beginning to see how and why the new strain of ransomware worms are evolving and growing far more effective than previous versions.

I think there are 3 main factors: Propagation, Payload, and Payment.*

Propagation: You ideally want to be able to spread using as many different types of techniques as you can.
Payload: Once you’ve infected the system you want to have a payload that encrypts properly, doesn’t have any easy bypass to decryption, and clearly indicates to the victim what they should do next.
Payment: You need to be able to take in money efficiently and then actually decrypt the systems of those who pay. This piece is crucial, otherwise people will quickly learn they can’t get their files back even if they do pay and be inclined to just start over.

WannaCry vs. Petya
WannaCry used SMB as its main spreading mechanism, and its payment infrastructure lacked the ability to scale. It also had a kill switch, which was famously triggered and halted further propagation.

Petya on the other hand appears to be much more effective at spreading since it’s using both EternalBlue and credential sharing
/ PSEXEC to infect more systems. This means it can harvest working credentials and spread even if the new targets aren’t vulnerable to an exploit.

[NOTE: This is early analysis so some details could turn out to be different as we learn more.]

What remains to be seen is how effective the payload and payment infrastructures are on this one. It’s one thing to encrypt files, but it’s something else entirely to decrypt them.

The other important unknown at this point is if Petya is standalone or a component of a more elaborate attack. Is what we’re seeing now intended to be a compelling distraction?

There’s been some reports indicating these exploits were utilized by a sophisticated threat actor against the same targets prior to WannaCry. So it’s possible that WannaCry was poorly designed on purpose. Either way, we’re advising clients to investigate if there is any evidence of a more strategic use of these tools in the weeks leading up to Petya hitting.

*Note: I’m sure there are many more thorough ways to analyze the efficacy of worms. These are just three that came to mind while reading about Petya and thinking about it compared to WannaCry.

Two-factor Authentication (2FA) today is something like having a firewall in the year 2000: if you say you have it, it basically stops any further questioning.

Unfortunately, when you have a powerful and mismanaged API, 2FA is about as effective as having a stateful firewall protecting a broken web application.

It’s time we accept as an industry that API keys and secrets are essentially usernames and passwords, except they’re designed to be used in an automated way to perform your company’s most sensitive functions, often instrumented by developers who don’t prioritize security.

Other than that, they’re fine.

The API Backdoor

The next time you’re chatting with someone about 2FA access to some big-name SaaS or product, ask them if they have an API.

They’ll probably respond, “Of course.”

Now ask them what you can do with that API.

“Oh, it’s a great API. You can do pretty much everything.”

“Great. How many people have access?”

“It’s super popular. We give access to all our developers, and any account can ask for and receive a key.”

“Cool. So how many of those keys are out there, and how do you control them?”

“…”

Exactly.

API keys often have full access to the platform, and guess what the access method is: a string of characters for your key, and a string of characters for your secret.

Sound familiar? How is this different from a username and password?

“Oh, but this is different because it’s all code-ey and stuff. Lots of programming and hard things.”

No.

That’s not a defense. Good APIs also share something else: great documentation.

It’s easy to do things like adding users, adjusting permissions, or pulling data using this interface because it’s meant to be easy. In fact, the easier it is to do something powerful, the better.

And this is all happening on 2FA-enabled accounts, despite that supposed higher level of security.

Summary

Everyone understands that 2FA is better than just a username and password.
Everyone is also trying to add an API to their new services.
API keys are just usernames and passwords used in code.
Few people realize this, and think it’s safe because “programming is hard” or because “APIs are magic.”
APIs are not magic. They’re an entry point into your application, and there are far too many keys and secrets floating around Slack, Github, and many other places on services that are 2FA-enabled.
This presents a false sense of security.

2FA is great. Enable it where you can. But it’s not the end of the conversation. Be sure to look at your API as well. Know what you can do with it, know who has keys, know how often they expire, and have a plan for monitoring and response.

For all intents and purposes, you should treat API access like legacy username and password access. After all, API keys and secrets are credentials.

Credentials can be stolen, and credentials can be used to do bad things.

This post is adapted from Daniel Miessler’s original blog post, which you can find at https://danielmiessler.com/blog/apis-2fas-achilles-heel/.

Service: software security

WannaCry vs. Petya: Keys to Ransomware Effectiveness

APIs are 2FA Backdoors