Adapting Penetration Testing Methods for Cloud Environments

Penetration testing and security assessments face unique challenges in cloud environments. The traditional network perimeter has largely disappeared, with resources distributed across both on-premises and cloud environments worldwide. Users access these resources via various devices and applications, often requiring only proof of identity such as a password, API key, or access token.

Cloud environments often utilize a variety of tokens, some valid for up to 90 days. Once acquired, these tokens grant access without additional authentication steps. This universal access and extended token validity create specific challenges for incident response. Because of this, when performing security assessments and penetration testing in cloud environments, we recommend focusing primarily on single factor authentication processes and the different methods used to bypass them.

Ways to Exploit Single Factor

An organization’s network boundaries are now defined by the identities that can access cloud resources. A single factor is one piece of data that can be used to access a web service in an authenticated context. In cloud environments, single-factor authentication is frequently targeted. Here’s how adversaries might exploit it:

• Find Single Factor: Current credentials can be searched for, discovered, and used to access accounts (Breaches, dumps, repos, scanning).
• Guess Single Factor: Weak or duplicate passwords can be easily guessed or brute-forced (Common, reuse, default).
• Steal Single Factor: Users can be tricked into providing credentials to an adversary or running malware that steals them (Email, SMS, chat).
• Bypass Single Factor: Account recovery procedures can allow an adversary to bypass the normal authentication process (Email, SMS, security questions).
• Steal Session Credentials: With Cross Site Scripting (XSS), the adversary can run JavaScript in the victim’s browser to send a cookie or session token to a remote server to create an authenticated session from there.
• Forge Session Credentials: With Cross Site Forgery Request (CSRF), the adversary takes advantage of the browser being authenticated to a target site. If the victim is logged in, any request made to the site originating from the victim’s browser will be successful.

To thwart bad actors from targeting single-factor authentication, it’s recommended to:

• Use a long, complex password with two-factor authentication (2FA) enabled
• Verify accurate and up-to-date account recovery info, such as your email and phone
• Review recent activity, including authorized and logged in devices
• Review payments, subscriptions, and third-party access authorizations

Authentication Processes and Their Vulnerabilities

There are various authentication methods that can be used in web applications, and each has its own potential vulnerabilities. Here’s a breakdown:

• Basic Authentication: A username and password are Base64-encoded and included in each request. If they are missing, the server requests them. Since Base64 is easily reversible, an attacker could intercept and decode the credentials.
• Digest Authentication: A hash is created using the username, password, and a nonce (a unique number). This hash is sent to the server, which can validate it without sending the password over the network. If an attacker captures the nonce and other parameters, they might attempt to recreate the hash.
• Windows Integrated Authentication (NTLM): The server requests authentication. The browser responds with encoded and hashed credentials, which are validated by the server with the domain controller. If an attacker can intercept or manipulate the negotiation process, they might be able to spoof or hijack the authentication.
• Form-based Authentication: External to the HTTP protocol, the application prompts the user for credentials, verifies them, and handles authentication. The security depends on how the application handles credentials and sessions. If poorly managed, credentials can be intercepted or sessions hijacked.
• Certificate Authentication: A client holds a certificate with a private key, and the server verifies it against a known public key to authenticate the user. If an attacker can steal or compromise the certificate, they can impersonate the user.
• Password Authentication: This requires a username and password, which can be guessed, cracked, or stolen.
• Public Key Authentication: This involves digital certificates, which can also be compromised if not securely managed.
• Multi-Factor Authentication (MFA): This combines a password with a second factor (e.g., a one-time password or hardware device). It’s more secure but can still be phished or bypassed with advanced techniques.
• One-Time Passwords (OTP): After successfully validating the username and password, the server generates an OTP that can only be used once. The OTP is sent to the user via an out-of-band (OOB) communication method such as SMS, email, or an application. Attackers can trick users into providing the OTP alongside their password. SMS-based OTPs can be intercepted if an attacker controls the user’s phone number or can intercept the communication channel.
• Tamper-Resistant Hardware Devices: These devices—such as Smart Cards and U2F devices—store X.509 certificates and private keys internally and perform cryptographic operations without exposing the private key. Authentication requires both possession of the device and knowledge of a PIN (in the case of Smart Cards). If the device is stolen and the attacker knows the PIN, they can use it.
• MFA with Tamper-Resistant Hardware Devices: Users authenticate with a physical device, such as a Smart Card or U2F key, which holds a private key that never leaves the device. If the user’s browser is compromised, an attacker might be able to hijack a session even after successful authentication. If an attacker steals the hardware device and knows the PIN, they can gain access.
• Hardware Tokens: Hardware tokens generate a code based on an algorithm, a clock, and a unique seed. The user must provide this code along with their username and password to authenticate. Although difficult, if an attacker can copy or clone the token, they can generate the same codes and gain access. An attacker might also phish the code from the user, though the window of opportunity is limited to the token’s validity period.
• OAuth Tokens: OAuth tokens, including JSON Web Tokens (JWT), are digital credentials used to authorize access to resources on behalf of a user or application without needing to share or expose the user’s actual credentials (like a username and password). Bad actors can steal tokens if they were sent via URL, as well as through phishing, XSS, man-in-the-middle attacks, or other methods. A JWT is an encoded string of text containing claims about the bearer of the token.

Ways to Bypass Initial Authentication and Prevent Token Misuse

There are three methods we frequently see used to access web applications either after or without completing the full authentication process:

• Cookies: Passed after authentication for subsequent requests.
• Session JWTs: Tokens issued after authentication to manage user sessions.
• OAuth Tokens: Used to act on behalf of the user.

Token Sidejacking is a threat where attackers intercept tokens (e.g., JWTs) to gain unauthorized access. It is signed with the private key of the identity provider to prove authenticity and integrity. JWTs are great for authorization, but if obtained by an unauthorized user or application, can be used to bypass initial authentication. Here’s how to secure your tokens:

• Use Authorization Headers: Pass tokens via headers, not URLs, to avoid exposure in logs or history.
• Remove or Obscure Tokens in Logs: Ensure tokens aren’t logged, or mask them if necessary.
• Integrate User Context: Tie tokens to a specific user or session to make it harder for an attacker to reuse.
• Set Short Token Lifetimes: Short lifespans reduce the window for misuse. Configure JWTs to expire after a short period, forcing frequent re-authentication or token renewal.
• Use Token Deny-Listing: Implement a deny-list mechanism where tokens can be revoked and prevented from being used even before they expire.
• Encrypt JWTs: Protect sensitive data by encrypting the token.
• Use SessionStorage: Store tokens in sessionStorage instead of localStorage. localStorage persists across sessions, making it a bigger target.
• Clients Should Sign Tokens with Complex Symmetric Keys: Use long, complex keys for signing JWTs to protect against dictionary attacks.

OAuth Token Best Practices

• Avoid Hard-coding Tokens: Don’t embed tokens directly in application code.
• Transmit Securely: Transmit tokens securely over HTTPS and avoid including tokens in URLs (query strings) where they may be logged.
• Rotate and Expire Tokens Regularly: Reduces risk if tokens are compromised.
• Request Minimal Permissions: Limit scope to necessary permissions only.

Ways to Completely Bypass Authentication

Some methods and misconfigurations can allow attackers to bypass authentication mechanisms altogether, including the use of:

• Storage Buckets: Misconfigured cloud storage (e.g., S3 buckets) can be accessed without proper authentication, exposing sensitive data.
• Snapshots and AMIs: Improperly configured permissions on snapshots and Amazon Machine Images (AMIs) can allow unauthorized access to system images and data.
• Graph API: An access token for the Graph API in Azure can provide extensive access, potentially bypassing multi-factor authentication (MFA).
• SNS Topics and SQS Queues: Misconfigured permissions on AWS messaging services can allow unauthorized sending or receiving of messages.

To reduce the risk of allowing attackers to completely bypass authentication, it’s best to follow these recommendations:

• Restrict Root Account Use: The root account in AWS has full access to all resources and should be used sparingly.
• Prohibit Root Access Keys: Avoid using long-term access keys for the root account as they pose a significant security risk.
• Require MFA for Console Access: MFA adds an additional layer of security, making it harder for attackers to gain access with just a password.
• Use Roles for API Access: Roles provide temporary credentials and are more secure than using static access keys.
• Rotate Credentials Regularly: Regular rotation of passwords and access keys limits the potential damage if they are compromised.
• Attach Policies to Groups, Not Users: This makes it easier to manage permissions across multiple users.
• Use AWS Managed Policies: AWS-managed policies are designed with best practices in mind, reducing the risk of misconfiguration.
• Credential Requirements: Enforce strong, complex passwords and enable two-factor authentication (2FA).
• Recovery Info: Ensure account recovery information is updated and accurate to maintain account security.
• Monitoring: Regularly review account activity and settings to detect and respond to potential security issues.

By following these best practices and being aware of potential vulnerabilities, organizations can better secure their network and reduce the risk of unauthorized access to their systems and data within cloud environments.

Contact us for more information on our penetration testing and cloud security services.