Testing WhatPulse Web Application Security

Background

I have been using WhatPulse for over 17 years. WhatPulse, first released in 2003, is a client capable of tracking computer usage data for personal analytics purposes. For example, it can generate a heatmap of the most frequently typed letters, most frequently clicked screen location, or how far your mouse cursor has traveled over time.

Discovery

Last month, I had to visit the website to update my WhatPulse client. When I scrolled past the Change Password section, I noticed there was no field to verify my old password. This fit the criteria for an Unverified Password Change (CWE-620). Identification and Authentication Failures are an incredibly common web application vulnerability as classified by the OWASP Top 10. A finding like this deserves additional investigation.

Side note on CWE: Common Weakness Enumeration (CWE) is a dictionary of weak development practices which introduce flaws, faults or bugs that may lead the way to more specific vulnerabilities. For example: concurrency issues, memory buffer errors, random number generation, and weak authentication processes.

From this perspective, the primary threat is local. Someone with shared physical access being able to change a logged-in user’s password. However, a weakness in password verification could be exploited by a remote user through cross-site requests.

Because I identified this weakness passively by observing my own account and did not have permission to conduct further testing, I reached out to the developer to responsibly disclose my observations. I requested permission to continue testing to see if I could identify additional vulnerabilities.?

With approval formally obtained, I proceeded to dig deeper. This post is a summary report of my findings. For a more in-depth technical report, check out the Technodivergent Blog.

Important reminder: the testing performed in this blog post was conducted responsibly with explicit permission from the WhatPulse developer. It is against cybersecurity professional ethics to test a system without authorization, so don’t do it unless you have permission and understand the scope you’re allowed to test.

Summary

Testing

While performing routine account management tasks, a security researcher observed an Unverified Password Change (CWE-620) weakness. After responsible disclosure of a potentially exploitable vulnerability, permission for additional testing & validation was obtained.

Further testing confirmed a Cross-Site Request Forgery (CSRF) vulnerability. CSRF is when a malicious site or email causes the target’s browser to perform an unauthorized request on behalf of said user (provided the user is already authenticated). Attackers can leverage this attack via email or social media phishing campaigns to fraudulently change account details, thereby obtaining access to the target account.

Mitigation Recommendations

The following recommendations were made to mitigate Cross-Site Request Forgery:

• Force reauthentication, confirmation of old password, or require verification link to perform sensitive tasks
• Ensure proper server-side validation of anti-CSRF tokens
• Validate request is from whatpulse.org via origin/headers

Vulnerability Resolution

The developer chose to mitigate this vulnerability by sending a verification link to the email associated with the account, introducing an additional layer of security to prevent unauthorized changes from occurring.