Affected Versions#

Versions before 20231115.

Source Code Analysis#

First, locate the vulnerable endpoint: 

There is only one method inside the endpoint, toWord, so let’s see what it does: 

Most of the early logic is not essential. The key part is a method that crawls a page, and it is also the only place where the url parameter is used: 

Here it uses getPage to process obj. obj is a URL object created from the url parameter. One confusing thing is that the filename is forced to index.html, so we inspect getWebPage: 

Up to this point it’s mostly file-writing logic, and it only writes index.html. The real issue comes next: the application appears to implement a crawler, so it calls GrabUtility.searchForNewFilesToGrab to further parse content. The conn here is the connection created earlier: 

Inside GrabUtility.searchForNewFilesToGrab, it parses the response and collects URLs from link[href], script[src], and img[src], storing them into the member variable filesToGrab:  

Then it performs the dangerous operation: it iterates over filesToGrab and tries to download each resource. It calls an overloaded GetWebPage method, using the same directory as before, while the filename is derived automatically:  

At this point exploitation becomes straightforward:

• The program only filters by extension. So as long as we avoid the blacklist extensions and combine it with path traversal, we can write arbitrary files.
• The blacklist includes html, htm, php, asp, aspx, and net, but not jsp. So writing a JSP webshell is enough.

One more detail: because it takes the substring after / as the filename, we cannot use / for traversal. But the target is on Windows, so we can use \\ instead.

The exploit flow is:

1. Host a malicious server.
2. In index.html, include a href/img/script URL that points to the JSP payload.

(This also matches the advisory wording about “tricking” the server into downloading dangerous files.)

Reproduction#

The PoC is here: https://github.com/springkill/idocv_poc
Step-by-step notes below:

Craft the page: 

Start a simple Python HTTP server and access it.

Then it got killed (thanks Huorong): 

Disable Huorong (the service seems to cache, so change the port): 

Test: 

And don’t forget to turn Huorong back on afterwards.

Conclusion#

File operations are extremely sensitive—especially downloading files onto a server. Downloaded files should be stored in a fixed directory and must be protected against path traversal. The developer recognized the risk of downloading files, but the mitigation was incomplete, which led to this vulnerability.

Bonus#

I lost count of how many times I tried…