Finding

Due to the processing logic on the support page, I found a flaw which would allow an attacker to have the login form render over plain HTTP. The submission of the login form also happens over plain HTTP. This would allow an attacker to be able to socially engineer a user to visit the link of their choosing, which would then make the support page with the login form render over plain HTTP. The attacker can then sniff the user's login credentials.

Below is a screenshot showing the page loaded over plan HTTP with the login form being presented to the user:

Below is a screenshot of the login submission from the page over plain HTTP (using BurpSuite as a proxy to log the POST request from the browser), illustrating the plain text username and password avaiable to anyone who could sniff this request:

This issue is compounded by the fact that even if you navigate to the HTTPS version of the URL, you are still redirected to the plain HTTP version (which would only help make a phishing attempt even more realistic).

The root cause of the issue is 2 fold:

1. All non-sensitive actions on the site are redirected to plain HTTP.
2. The type query parameter opens the login form regards of value and the only check against this in terms of not redirect from HTTPS is for the word 'login'.

Resolution

Issue has been resolved.

Vendor Notification

• 5 April 2018 - Formal submission to the Product Security Incidence Response Team
• 6 April 2018 - Received response from vendor stating that the information would be passed onto the relevant team.
• 27 April 2018 - Sent email asking for update.
• 5 May 2018 - Sent another email asking for an update.
• 8 May 2018 - Sent final email asking for an update. Informed the vendor intentions of publishing finding.
• 11 May 2018 - No response received from vendor, published findings.