PERSISTENT COOKIES CAN PROVE TROUBLESOME FOR AWS

For both attackers and penetration testers, phishing has been a go-to move for about two decades and it continues to work quite well today. It’s a reliable way to harvest users’ credentials for all sorts of apps and services, including cloud platforms, and a researcher has discovered that some cookies used for authentication on Amazon Web Services remain valid even after the victim has changed the password and logged out of the account. That means that an attacker who is able to phish a victim’s username and password will have persistent access to the victim’s AWS account, even with multi-factor authentication enabled.

In many phishing scenarios, the use of MFA is a solid defense, but there are lots of different MFA factors and some established methods for obtaining MFA codes that allow attackers to circumvent some of those protections. One way to do that is to force victims through a reverse proxy on the way to the phishing page the attacker has set up. That enables the attacker to intercept the victim’s traffic and record both the credentials and any MFA code she would enter when prompted. Spencer Gietzen, lead cloud pen tester at Rhino Security Labs, discovered on a recent customer engagement that this method not only worked against AWS accounts with MFA enabled, but also collected the victim’s AWS authentication cookie. In his research, Gietzen used Modlishka, a reverse-proxy framework released earlier this year.

“Because Modlishka is just proxying the AWS web page to our target user, it will be able to phish them, regardless of whether or not they have MFA enabled. Once the user is prompted for their MFA code and enters it, Modlishka will interject. It will create a valid login session with the AWS web console, store the details, then send the target user off to the actual AWS website and away from our phishing page. The user’s credentials and cookies will be stored in the cookie jar,” Gietzen said in a post on the phishing technique.

While using this technique, Gietzen found that it also collected the authentication cookies that AWS issues to users, as well. Cookies typically will expire once a user logs out of the associated service or changes the password. But Gietzen discovered that wasn’t the case with the AWS cookies. Instead, he found that they lasted for about 12 hours, even if the victim changed the password on the phished account and logged out.

The technique Gietzen developed is specific to the AWS Identity and Access Management system, which allows the use of several different form factors of MFA, including mobile apps and hardware devices. The technique would not work against a hardware-based U2F token, but those tokens aren’t usable for everything on AWS, such as work done through a command-line interface.

“In this testing, we ‘phished’ our own user account and then logged into the web console with the stolen cookies. Acting as if we were a user who was just phished, we changed the password of our user and then logged out in hopes that it would invalidate the session that the attacker stole. We found that after doing this, the session was still valid. This showed us that even after a target user changes their IAM user’s password and logs out, the phished cookies could still create a multi-factor authenticated session to the AWS web console,” he wrote.

“We investigated the limitations of the cookies further by removing the MFA device used on that phished user’s account. We then replaced it with a brand new MFA device, changed the password for the user, then logged out of the web console. Even after all of that, we were still able to use the cookies we originally stole to create a multi-factor authenticated session to the AWS web console.”

When Gietzen reported what he’d found to Amazon, the company said that the behavior is intended and is designed to allow long sessions for workloads that take extended periods of time, even after the user has logged out.

“Though this does make sense from a usability standpoint, it is still a concern for security. Because AWS says that the cookies are working as intended, this behavior will likely not change,” he wrote.

Gietzen said there are some effective defenses against this technique, with the most effective being the use of a hardware U2F key, which is highly resistant to phishing.

“For AWS users in particular, going with a hardware-based MFA device (like a Yubikey) is the way to go. It would prevent this attack because of some additional security features that are used by those devices and modern web browsers (URL verification mainly). Another option would be to remove IAM users completely from your AWS environment, and to only rely on IAM roles/temporary credentials, rather than long-lived usernames and passwords,” he said via email.