NOTE: The issue highlighted in this post is for educational purposes only.
Last weekend some electronic gadgets were ordered from the Fry’s electronic store at (https://shop3.frys.com//wf?a=SIGN_IN,w=CHECKOUT=1). An account was created and after interacting with the web application for 10 minutes, a number of security issues were identified in the Fry's online portal due to insecure design and coding practices. The idea behind this post is to educate application developers on how to design secure components. It is just something I came across and decided to share.
In this post, the insecure design of "Password Change Component" has been presented. The user should take the highlighted issue in consideration while accessing the online web portal.
Insecure Design - Password Change Component
It has been noticed that the "Password Change Component" used by Fry's online portal is designed insecurely. A secure design practice involves that application component should ask for the “old password” from the user before the new password is supplied and verified accordingly. This is required by the application to perform additional password verification to determine whether the HTTP request is issued by the legitimate user or not. If the “old password” is required and validated, it enhances the design and robustness of the system. Further, the component does not even enforce complex password requirements. For examples:- (1) the last used password can be reset again as new password, (2) minimum password length enforced is 6 characters. Many other variables in the password complexity requirements are not met either.
The issue does not end here. The flaw highlighted above is a basic design fallacy. Let's see how multiple vulnerabilities can be chained together.
Cross-site Request Forgery - Password Change Component
The password change component (mod_exist_password.php) is vulnerable to Cross-site Request Forgery (CSRF) attack. Let's look into a number of design checks:
- The application does not implement origin verification checks either via unique tokens or "Origin" header. As a result, HTTP POST requests are accepted by application without any token verification and validation.
- The password change component does not explicitly enforce the verification of “old password”.
- The application does not even perform a basic "HTTP Referer" verification check on the server side.
It means the attacker can easily author a CSRF exploit to change the password on the fly which ultimately results in the account hijacking.
Let's validate this.
The HTTP POST request is taken from the CSRF exploit drafted as a Proof-of-Concept (PoC). It can be deciphered that the HTTP POST request does not carry any token as a part of request header or the body header. In addition, the ‘Referer” header is also removed from the HTTP request. General, “Referer” validation on the server side is treated as a defense against CSRF attack. In this case, no "Referer" validation is performed either.
POST /wf HTTP/1.1
Host: shop3.frys.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 169
Cookie: ID_KOT=987123654; J1_USER_ID=[Removed]; BTgroup=B; FSERVERID=s107
Connection: close
Upgrade-Insecure-Requests: 1
r=misc,c=new_password=[Truncated]&r=misc,c=new_password_again=[Truncated]&a=MODIFY_PASSWORD,w=ACCTMAINT=&button.x=21&button.y=9
HTTP/1.1 200 OK
Date: [Truncated]
Server: Apache
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Cache-Control: max-age=0
Expires: [Truncated]
Vary: Accept-Encoding
Connection: close
Content-Type: text/html;charset=ISO-8859-1
Via: 1.1 sjc1-10
Content-Length: 13877
|
By simply sending the HTTP POST request to the server via a CSRF exploit when the user is logged-in the session, the attacker can change the end-user password.
Disclosure:
Frys was contacted via Twitter and via LinkedIn as no direct security contact information was available. No response was received so the details have been released.
