Managing vulnerabilities in operating systems and software can be challenging and even contentious. Opinions are divided among industry peers – some argue that security updates would be unnecessary if developers were held accountable for security vulnerabilities [1]. In contrast, others assert that updating systems as soon as possible (where applicable) was a critical best practice for users [2]. Most clients in my consulting job adopt some form of vulnerability management paradigm (quarterly vulnerability assessments and addressing discovered vulnerabilities to automated vulnerability management programs where identified vulnerabilities are addressed as soon as possible). I noticed some peculiarities while providing consultancy services to a discerning customer's automated vulnerability management program. The automated vulnerability management product will not be discussed here as it is neither the main focal point nor a debate on whether the product is trustworthy. Instead, it was serendipitous and stemmed from just a simple drive to appropriately mitigate identified vulnerabilities in all systems. Together with the client's management support, we worked together to address the vulnerability in question while ensuring it was fully mitigated.

It all started when a new low-risk vulnerability was identified – the Adobe Acrobat Reader software installed on the client's assets (a Windows enterprise environment with a heavy majority of Windows 10 Version 22H2 clients) were identified to have JavaScript enabled. Typically, there is no business need for JavaScript to be enabled in Adobe Reader, especially if users only need to view documents and occasionally fill in simple form fields. As such, the vulnerability management tool advised that JavaScript be disabled and even provided steps to do so. In this case, the recommended action was to set the registry key HKLM\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockDown\bDisableJavaScript to the REG_DWORD value of 1. The change management team approved the configuration change, and the system administrator was tasked to implement the hardening configuration.

While reviewing the configuration change status, I also came across Adobe's own advisory on how to adjust the usage of JavaScript within their products [3]. Adobe's suggested configuration did not require administrative privileges or Windows registry modifications. I then had a random thought – what if the proposed configuration change by the vulnerability management tool did not work as intended, and JavaScript was still being enabled despite the registry key change?

An experiment was in order, and I was fortunate that the system administrator was game enough to allow me to test things out. We searched for a simple JavaScript PDF file [4], verified its functionality, and executed it on two clients – one configured according to the recommendations of the vulnerability management tool. In contrast, the other client was configured according to the documentation by Adobe. Of course, the clients were rebooted after the configuration.

Surprisingly, the client configured according to the documentation by Adobe did not allow JavaScript execution, while the client with the registry key modification allowed JavaScript to execute. This introduced a small challenge – clients that had the registry key modified were shown to have the vulnerability mitigated (the hardening process took place over a period of time) by the vulnerability management tool. Meanwhile, the particular client with custom configuration within Adobe Acrobat Reader was shown as vulnerable to JavaScript execution when it was configured to disable JavaScript execution. Management was notified immediately, and the stakeholders decided to roll back the previous configuration and implement the configuration suggested by Adobe. The vulnerability highlighted in the vulnerability management tool was added to the list of exceptions, with an explanation detailing the actual configuration and the client noting that the vulnerability had been resolved.

The adage of "Trust, but verify" appears to hold true. A quick literature review online regarding the registry key configuration yielded multiple positive feedback (JavaScript was disabled). If the client had just implemented the change without verification, the vulnerability management tool would have shown that the vulnerability was resolved. However, the environment would still have been vulnerable to PDF JavaScript execution – a risk that the client's management was unwilling to accept. As such, verifying resolved vulnerabilities must be performed even if a vulnerability management program is in place. From a consulting perspective, professional skepticism (even though this is usually articulated in accountancy audits) can add value to a client's cybersecurity posture and sometimes even yield unexpected findings in cybersecurity assessments.

References:
1. https://doi.ieeecomputersociety.org/10.1109/TSE.2022.3176674 
2. https://doi.org/10.1145/3587826
3. https://helpx.adobe.com/acrobat/using/javascripts-pdfs-security-risk.html
4. https://acrobatusers.com/assets/collections/tutorials/legacy/tech_corners/javascript_corner/tips/2006/popup_windows_part2/AlertBoxExamples.pdf

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter