Not all security vulnerabilities are created equally

Does this sound familiar to you? It’s a typical Monday morning. You get up, drive to the office, grab a cup of coffee and, while you’re at it, hack into a portal. Or is this anything but normal to you? If that’s the case, let’s go back a little bit further.

Security plays a critical role in the world today. If you didn’t already know this, you should by now. Security checks should be part of any project, especially those in the field of software development. Initial measures include training the developers, taking steps to raise awareness for security and establishing a SecDevOps process. To wrap it up, a battery of pentests should be carried out prior to release. I was asked by a group of colleagues to pentest a portal to check that it is secure. This involved a portal for a major customer who uses Keycloak for identity and access management (IAM) in the backend. The pentest should run for about a week.

As luck would have it, the test revealed only a small number of security vulnerabilities. There was one that really stood out, however. Security vulnerabilities are classified into the Common Weakness Enumeration (CWE) categories. In this particular case, the vulnerability fell into the category ‘CWE-208 Observable Timing Discrepancy’. In addition, the vulnerability also met the criteria of ‘CWE-640: Weak Password Recovery Mechanism for Forgotten Password’. This means that it is possible to draw conclusions about internal processes based on the response time. In this particular case, the vulnerability related to the password recovery process. In principle, a corresponding function should be configured in such a way that no information is sent regarding whether or not the user account whose password is to be reset exists. This could look something like this: each time an account ID is entered, you receive a message that an e-mail has been sent for password recovery, regardless of whether the account exists. This was also the method adopted for the portal. However, I soon noticed that this process would take slightly longer in some cases. Knowing this, I was able to quickly show that final confirmation that an e-mail has been sent takes roughly ten times as long if a user account exists. This might get by a script kiddie, but an experienced hacker sees that it’s possible to quickly get their hands on existing user names or e-mail addresses. After discussing the vulnerability with the portal’s developers, it soon became clear that this problem was related to Keycloak and not the portal’s code.

How could a hacker now exploit this vulnerability?

To answer this question, consider the following points:

1. Keycloak is in use at many companies

Keycloak is primarily used by businesses. Generally speaking, companies have their own Keycloak instances which are only used for their employees and/or customers.

2. A company’s employees can be easily identified

In this day and age, social media networks such as LinkedIn, Xing and Facebook can be used to quickly identify employees who work for a specific company. In addition, it is also easy to find personal information about employees or customers of a company, since people generally share and divulge this data voluntarily. This could include information like hobbies, political views, family members, friends and acquaintances or other specific activities.

3. Identifying a company’s customers

It’s a little more difficult, but not impossible, to identity a company’s customers. If customers do not voluntarily disclose information that reveals their ties to a company, a security breach like the one described above could result in this information getting out. It’s easy to find large databases and lists of e-mail addresses on the Internet. These often come from earlier hacks or other leaks. These lists can be used to carry out a simple enumeration attack on a password recovery function and identify which of the e-mail addresses have access to the corresponding Keycloak instance based on the time discrepancy.

Hacking is primarily about acquiring information. It’s not for nothing that the number one rule is: ‘enumeration, enumeration, enumeration’. In other words, gathering as much information as possible. The data can then be used for dictionary attacks (trying out passwords from databases using common passwords) or for spear phishing attacks (phishing with a personal context, which makes the attack seem more authentic).

Known vulnerabilities in software products are usually compiled in a global list of the Common Vulnerabilities and Exposures (CVE) database. For a pentester, it is a great honour to find a previously unknown vulnerability and receive an official CVE number for it. However, there is a process that must first be completed before a vulnerability is entered in the database. This includes reporting the vulnerability, receiving feedback from the developer and other steps. There are two ways to report a vulnerability: one way is to report them to a CVE numbering authority, or CNA for short. They are responsible for generating CVE numbers for products from their company. If the product developer is not a CNA, the Mitre Corporation, an NPO and IT security research institution, is informed, after which it assigns a CVE number. Red Hat is both the developer of Keycloak and a CNA, meaning that only Red Hat can issue a CVE for this vulnerability.

Since this is a serious vulnerability that could also be assigned to two CWE categories, I reported the bug to Red Hat. Although the website promises a response within a few working days, I did not receive one for four weeks. I then reported the bug again, saying that I would publish the security vulnerability soon if Red Hat failed to respond again. This time they got back to me two days later to inform me that they were looking into the matter. One week after that, I received a reply. Despite the arguments I presented and my being able to assign the bug to at least two CWE categories, Red Hat did not classify it as a security risk. This came as somewhat of a surprise since there are already similar CVEs for other products such as Novel iChain 2.2 dated back to 2003. While I can understand why they responded like they did because no one wants to receive a CVE for their software, Red Hat is a CNA, and ‘authority’ is part of the acronym. As a CNA you should serve as a role model.

Nevertheless, I decided to go ahead and write as well as publish an advisory, which is a white paper describing a vulnerability that has been identified which is used as a medium for publication. The advisory can be downloaded at the end of the article.

Whatever difference in opinion we may have had, Red Hat has promised to correct the issue, so hopefully this bug will be fixed in the future. That is all that really matters in the end. Now on to the next cup of coffee and the next security vulnerability.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.

Link to advisory

Would you like to learn more about exciting topics from the adesso world? Then take a look at our previously published blog posts.