Con-Identity: Identification and authentication failure

The Con-Identity origin story

0 mins read

To access any application, including accessing Facebook or a platform like the AWS console, you require a username and password for your account with that provider.

When applications that are hosted in the cloud are directly available to access from the internet with weak authentication mechanisms (or none at all), attackers can compromise this lack of authentication and take over cloud-hosted applications for misuse. The lack of appropriate identification or authentication in place results in the birth of Con-Identity — the identification and authentication failure villain.

wordpress-sync/series-aws-security-con-identity-small

Common causes

Identification and authentication failures occur when a user’s identity, authentication, or session management is not implemented appropriately, leaving the cloud-hosted application unprotected against this attack. Attackers can exploit these unprotected cloud-hosted applications to get access to usernames, passwords, and session tokens and assume identities temporarily or permanently. The attacker becomes a con artist able to assume the identity of the user it has gained credentials for. Using this assumed identity, the attacker can take advantage of the access and allow actions for the user.

This villain also has its origins in the AppSec world and holds true for applications hosted on-premise. It has made its appearance on the OWASP Top 10 Application Security since 2017, then known as Broken Authentication and then amended to Identification and Authentication failure in 2021.

Identification and authentication failures occur because of two main reasons:

Insufficient credential management– When weak username, passwords, and hashing techniques are used, attackers can use various password cracking techniques to gain access to credentials.
Insufficient session management– For an application hosted in AWS, a session is a secure connection between the client (you) and the remote managed node (application) that is issued by the application and is unique to your identity on the application. The lack of appropriate management of these sessions can lead to an application compromise.

The attacker can exploit Identification and Authentication Failures through various different attacks, the top 3 that are most commonly known

Brute force access – The attacker tries several different common passwords using automated scripts until the correct ones are found. User Credentials found in a Data breach could also be another place to find credentials that can be used to access protected services via brute force.
Credential stuffing– The attacker uses an automated tool to try a list of username and passwords stolen from known repository sites like haveibeenpwned.com or from another domain that the user is reusing their credentials in to gain access.
Session hijacking– The attacker takes over a legitimate user’s session ID by doing things like sniffing network traffic. A session ID is usually allocated to a user when they login into a system, so they don't need to re-login again.

Problems caused by identification and authentication failures

Con-Identity poses a significant risk. If the attacker gains access to an user account with full administrator privileges in AWS, they can exploit these privileges to gain access to highly sensitive data, commit identity theft, money laundering, and fraud.

3 places in AWS where Con-Identity hides

Compute services with no authentication

Compute services like AWS EC2 can be used to host vulnerable applications with security group or firewall rules open to the internet with no authentication. When these security group or firewall rules for these internet-facing web servers have no appropriate authentication in place, it gives rise to our not-so-good friend Con-Identity.

AWS IAM user or root user with weak credentials

In AWS, an IAM User is an entity that represents a person or an application that uses assigned roles and permissions to perform allowed actions in AWS. An AWS root user is the first identity you start with in a brand new AWS Account, and it has complete access to all your AWS services and resources. If you choose to use the root user instead of an IAM user to do everyday tasks in AWS, or have weak username and passwords or no MFA (multifactor authentication) in place for both AWS Root user(s) & AWS IAM User(s), these can give rise to Con-Identity.

See more:

AWS API Gateway using identity with weak credentials

An API acts as a front door for applications and allows another application or a user to interact with it. In AWS, there is an API gateway. This AWS API Gateway is a fully managed service by AWS that “makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale.” If the identity is used in API Gateway to interact with other services and the user is missing authentication or is using weak credentials, this may result in identification and authentication vulnerabilities, and once again, Con-Identity appears.

3 ways to stop Con-Identity

Enforcing login on all applications

A simple but effective way to address identification and authentication failure is by enforcing login i.e., having a strong authentication like username and password and ideally MFA (multi-factor authentication) as requirements to access all of your applications hosted in AWS.

Use a standards-based Authentication/authorization framework

Another way to have strong authentication in place for applications is by using industry standards-based frameworks like SAML, OAuth and OpenID Connect which can securely allow authorized users to access multiple applications and domains using a single set of credentials.

See more:

Pentest applications

While enforcing logins and/or using industry standards-based authorization frameworks works well to protect against Con-Identity, pentesting the applications in your organizations is also an effective tool as it ensures that you don’t have security gaps in your implementation (always a good idea!).