Cookie Shadow Path Injection

Did you know multiple cookies can have the same name on a domain? Yep, cookies aren’t unique on the name, they are “unique” on the tuple of (Name,Domain,Path).

So you could have a session cookie for example.com/secret, and a different one for example.com/ with the same name. Why would you want to do that? ¯\_(ツ)_/¯

But what sorts of attacks can we do with that?

Scenario

Lets say we built a Single Sign On (SSO) solution for our enterprise. We know the pesky developers are going to want to create insecure apps for other employees to use. So we provide some facilities to make authentication of users easier by using the same corporate cookies everywhere.

We allow developers to host application on *.corp.example.com, but all traffic gets funneled through a bastille host that checks to make sure the user is logged into the corporate network first. Once a user logs in we assign a cookie corporate-username, and proxy the request to the right application.

The application can then check the cookie corporate-username to see who is accessing their site.

But, we know that cookies can be easily spoofed, so we add an extra protection and tie the corporate-username cookie to a corporate-token cookie. When a user logs in, we also generate a uuidv4 and store it in a database. So when the user tries to connect to an application, the request is proxy through the bastille host and a lookup is performed to make sure the corporate-token and corporate-username match up.

The developer applications can now trust that corporate-username is the correct username.

The Attack

This attack involves a little bit of luck on how the web servers handle cookies. It worked for me once, so hopefully it’ll work for you too. But basically we’re going to bait and switch cookies.

What if we sent two corporate-username cookies? How do servers handle multiple cookies with the same name?

Different servers handle it differently.

But if we’re lucky, the application we’re trying to attack and the bastille host do it differently from each other.

Lets say the bastille host uses the first instance of corporate-username and the corporate-token, and the application uses the last instance of the same cookie name.

We log into the bastille server, generate a valid cookie/token pair, but then add an extra cookie to our attack payload:

POST /entry/create
Host: blog.corp.example.com
Cookie: corporate-username=c0nrad corporate-username=admin corporate-token=c0nrads-token

{data: ‘I admin certify that c0nrad is the coolest’}

The bastille will see a valid username/token pair (c0nrad/c0nrads-token), so the request is forwarded, but the application on the other side accepts the second corporate-username (admin). We can now perform actions as anyone in the company!

If the bastille server uses the last cookie, just switch the order of the cookies and pray the application uses the latter cookie.

Conclusion

Basically this bug is HTTP parameter pollution but for cookies.

But, we were able to abuse the fact that you can have multiple cookies with the same name to bypass a SSO solution and perform actions as anyone in our imaginary company.

Just another tool for the toolkit.