You're a spy who has infiltrated BigCorp. Your mission is to steal its latest lab tech, but you don't have the security clearance to get into the laboratory. Unfortunately, you're stuck in the marketing department most of the time, but whenever you get a chance to slip away, you scope out the joint.
You play it cool, but you analyze every detail: Where are the security cameras? How many security guards are there? When do they change shifts? How often do people enter and exit the room?
You try to pick up all of the minutiae and you constantly wrack your brain: "How can I possibly make it into the lab?"
After about a month, you finally have your Eureka moment. The door to the lab is monitored by a single guard, and you noticed that there’s no scanner. The guard simply checks the ID cards and only lets the scientists in. Unfortunately, your marketing ID isn't gonna cut it.
However, you notice a glaring weakness. On Fridays, the security guard puts in a double shift. You figure that by the end of it, she has to be way too tired to notice the subtle difference between your marketing ID and a scientist ID. It'll be risky, but your spy bosses are putting pressure on you to steal the tech already. You figure you should go for it. What's the worst that could happen? If you get refused, all you have to do is calmly walk out and never come back.
Success. You're in.
Beating authorization mechanisms
The core of this story is really about how an attacker can beat an identity and access management system (IAM). In this case, the spy is targeting weaknesses in the authorization process. They noticed that the guard, the person responsible for checking authorization, would be extremely tired by the end of her shift and presumed that she would be unable to do her job effectively. The spy was right.
What is authorization?
Authorization is concerned with what an entity is or isn't allowed to do. If a user is authorized to access a resource, then they are allowed to access it. Unauthorized parties aren't allowed to access the resource.
It's important not to confuse authorization with authentication. Despite having similar sounding names, they are actually separate processes. Authentication is the process of verifying someone's identity, while authorization is concerned with determining whether they can or can’t access something.
In a typical identification and access management (IAM) system, a user will be challenged to identify who they are, and then authenticate themselves to prove that they are actually who they claim to be. Usernames are often used for identification, while passwords, biometrics and security tokens often play the role of authentication. These factors are used to verify that they are the true owner of the identity.
If a user successfully authenticates themselves, the system is satisfied that they are the legitimate entity that they claim to be. Once the system knows who the user is, it can determine authorization—whether or not the user can access or modify the resource that they have requested.
The system will then look up the user in the access control policy to check whether or not they are authorized to access the resource. If the access control policy shows that they are authorized, the user will be granted access. If they aren't authorized, they will be denied.
Now, just because someone isn't authorized to access a resource doesn't mean that it's impossible for them to access it. Instead, it means that the system shouldn't let them access it. But as we know, many systems have weaknesses, and a wily attacker may be able to figure out ways to exploit them. A few common authorization errors that can be exploited include:
- Missing authorization — When a system doesn't check user authorization.
- Placement of a user in an incorrect group — When a user is placed in an incorrect group that allows them to access resources that should be restricted.
- Insufficient granularity of access control — When the control policy is too broad, granting users access to sensitive resources that should be restricted.
- Authorization bypass through user-controlled key — When an attacker can look up user records via a key value that they are able to manipulate.
- Direct request — When lack of security controls allow an attacker to access a resource through alternate navigation paths.
In our example above, the spy noticed that the guard would probably be too tired to check the authorization properly, and the spy took advantage of that. Of course, BigCorp's system had a bunch of weaknesses that could have easily been addressed if it took its security more seriously. BigCorp could have banned double shifts, installed a card reader, clearly color-coded the ID cards and done many other things.
Unfortunately, BigCorp skimped on its security, and now it’s gonna have to pay the price. Management will have a fun time telling their investors that a competitor has just stolen their top-secret tech.
If BigCorp had at least one cybersecurity pro with a CISSP online masterclass under their belt, it could've spotted and avoided these weaknesses a mile away. Multi-factor authentication, biometrics, and even smart cards should have been the guardians BigCorp never used. Now, here we are, discussing authorization after the fact.
Now, let's bring this back home and consider your company's authorization processes. Think about both the physical and digital mechanisms—are there any weaknesses? Could a cunning, well-resourced spy figure out how to exploit the system? How could your company bolster its authorization mechanisms?
