I was playing in Apple bug bounty and I found this URL https://clearmater.apple.com/procurement/index.php/auth/register It is intended for suppliers to register and edit their information.
The response sets the cookie "ci_session" without the security flag. This flag is important because it enforces the browser to send the cookie over SSL. If this flag is not set, we can have a session hijacking attack.
This is the attack scenario:
1- Victim user logins on https://clearmater.apple.com/procurement/index.php
2- Attacker deceives the victim into visiting the URL over HTTP http://clearmater.apple.com/procurement/index.php while sniffing on the victim's netwrok
3- This is what the attacker can see in his sniffer:
The session id was sent in clear text HTTP because the browser was not enforced to send the cookie over HTTPS. Note that the response tried to redirect the user to the HTTPS page. But, it is too late. The attacker already got the authentication session id from the sniffed request.
4- Now, the attacker can just reuse the session id to hijack the session of the user. The screen below shows a request sent using a repeater while using a captured "ci_session" value. The result is a full access on the supplier information.
Apple fixed the issue and added my name to their hall of fame over http://support.apple.com/kb/HT1318. Apple's bug bounty page is available on https://ssl.apple.com/au/support/security/
I started testing for security issues. I thought of examining authentication and session management. I investigated the HTTP requests and responses responsible for authenticating and setting the session cookie.
The response below is returned when a POST request is sent to the URL https://clearmater.apple.com/procurement/index.php/auth/login in order to submit the user name and password
.
The response sets the cookie "ci_session" without the security flag. This flag is important because it enforces the browser to send the cookie over SSL. If this flag is not set, we can have a session hijacking attack.
This is the attack scenario:
1- Victim user logins on https://clearmater.apple.com/procurement/index.php
2- Attacker deceives the victim into visiting the URL over HTTP http://clearmater.apple.com/procurement/index.php while sniffing on the victim's netwrok
3- This is what the attacker can see in his sniffer:
4- Now, the attacker can just reuse the session id to hijack the session of the user. The screen below shows a request sent using a repeater while using a captured "ci_session" value. The result is a full access on the supplier information.
Apple fixed the issue and added my name to their hall of fame over http://support.apple.com/kb/HT1318. Apple's bug bounty page is available on https://ssl.apple.com/au/support/security/
