By supporting non-commercial organizations and open-source applications, we want to increase their security. For this reason, we created our pro bono program last September. The pro bono program offers applicants the chance to be selected for a free high-quality penetration test with a total expense of 10 man-days.
As the first candidate, we selected KeeWeb, which is a KeePass compatible password manager. KeeWeb is both available as a web application and cross-platform native application. It allows users to open and sync their password databases stored locally or in a cloud storage.
Summary of the Penetration Test
We conducted the 10 man-days penetration test between the 16th March and 3rd April 2020. During the test, we identified a total of 6 weaknesses – three classified as High and three classified as Medium.
The identified weaknesses were mostly based on the incorrect use of the OAuth authorization framework and insufficient protection against Cross-Site Scripting (XSS). In the following, we will describe the OAuth weaknesses in detail.
OAuth 2.0 is the de-facto standard for delegated authorization and supported by almost any cloud storage and API provider, including Google, Microsoft, Dropbox, and Amazon Web Services. However, the OAuth framework consists of several rather complex standards and provides various configurations. Flawlessly implementing authorization with OAuth is challenging and can be error-prone from a security perspective. Luckily, there are well-established OAuth best current practices - a collection of security measures that all applications using OAuth should follow.
The highest-ranking weakness that we identified was KeeWeb’s usage of the OAuth implicit grant, which is a violation of the OAuth best current practices. The implicit grant exposes the access tokens, which are used to access the user’s cloud storage, to the browser’s URL bar and its history. This significantly increases the attack surface of the access token. Today, the avoidance of the implicit grant is strongly recommended in general. Further details on its weaknesses can be found in the Drafts “OAuth 2.0 Security Best Current Practice” [3, 2.1.2.] and “OAuth 2.0 for Browser-Based Applications” [2, 4.], as well as the RFC "OAuth 2.0 for Native Apps" [3, 8.2.]. Instead of the implicit grant, the authorization code grant in conjunction with the proof key for code exchange (PKCE) extension should be used.
A second example of the identified weaknesses is another violation of the OAuth best current practices. KeeWeb did not protect against so-called “mix-up” attacks. This class summarizes attacks where the application is confused which OAuth authorization server it should invoke. All applications which support multiple OAuth authorization servers are potentially vulnerable to mix-up attacks and need to protect against this attack class.
On top of the 6 identified weaknesses, we recommended two changes to increase the security of the application further. First, delivering the Content Security Policy to minimize the risk of content injection vulnerabilities. Second, implementing a logout option to allow the user to explicitly revoke access to their cloud storage – an option that is especially important on public or shared computers.
Pro Bono Penetration Test Report
All details of the identified weaknesses and recommendations can be found in the full report here: KeeWeb Penetration Test Report
The weaknesses identified during the penetration test were responsibly disclosed to Mr. Witkowski who is the main contributor to the KeeWeb project on the 16th March.
Mr. Witkowski started to fix the weaknesses immediately and released a first update (v1.14) for KeeWeb on the 18th March. Later, we conducted a short retest of the identified weaknesses and informed the developer that all weaknesses except one were successfully fixed. A second update (v1.14.2) was released on the 4th Mai fixing the last weakness. The latest version also implements both recommendations we included in the report.
We want to thank Mr. Witkowski for participating in our pro bono program and for fixing the identified weaknesses in a fast and responsible manner.
Pro Bono Penetration Test Program
Are you involved with a non-commercial organization or the development of an open-source application and would like to participate in our pro bono program?
Get more information about how to become a pro bono candidate by reading our Pro Bono Penetration Test Program blog post.
If you want to learn more about the security of OAuth, OpenID Connect, or Single Sign-On solutions in general, as well as web security, you can also book one of our in-depth training.
 T. Lodderstedt et al. OAuth 2.0 Security Best Current Practice - Draft 14. Internet Engineering Task Force, 2020. URL: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14.
 D. Waite and A. Parecki. OAuth 2.0 for Browser-Based Apps - Draft 05. Internet Engineering Task Force, 2020. URL: https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05.
 J. Bradley and W. Denniss. OAuth 2.0 for Native Apps. RFC 8252 (Proposed Standard). Internet Engineering Task Force, 2017. URL: https://tools.ietf.org/html/rfc8252.