originally reported in https://hackerone.com/reports/238316
The call= parameter on https://www.dokuwiki.org/lib/exe/ajax.php does not properly encode user input, which leads to the reflected file download vulnerability.
Example: https://www.dokuwiki.org/lib/exe/ajax.php?call=%7c%7c%63%61%6c%63%7c%7c
The server responds with: AJAX call '||calc||' unknown!.
This can lead to arbitrary code execution on a victim's machine!
1.) Open Chrome Browser
2.) Visit redacted - contained a link with a download attribute
3.) Right click the Download link and click Save Link As and then save.
4.) installer.bat should then download, which contains the attacker's shellcode, downloaded from https://www.dokuwiki.org/lib/exe/ajax.php?call=%7c%7c%63%61%6c%63%7c%7c
If the user runs this batch file in Windows, it will open your calculator! This could lead to the entire compromise of the victim's computer.
I recommend URL encoding any characters in the server response (if the ajax call is not found) such as & and ; and |
The actual problem here is that the error message reflects the passed parameter uncleaned (because it is a text/plain response). This allows to inject arbitrary code in the response, eg. to create a valid batch file. A user may be tricked into downloading and executing the resulting code (assisted by the download html attribute) since it seems the code comes from a trustworthy server.
Correction: the response is of a text/html mime type and the error message is correctly escaped via htmlspecialchars. However the attack still works since it will keep bash control chars intact.
I would suggest to simply remove the call parameter from the output. If it is really useful for debugging (I doubt that), it could be printed when debugging is enabled.
fixed in 238b8e878ad48f370903465192b57c2072f65d86
Hey there, looks like it this patch doesn't actually fix this issue.
view-source:https://www.dokuwiki.org/lib/exe/ajax.php?call=%7c%7ccalc%7c%7c
You will see ||calc|| in the source which means it's still vulnerable!
An easy patch that I would recommend is to urlencode(); the output if the Ajax Call is unknown!
Issue is here:
https://github.com/splitbrain/dokuwiki/blob/master/lib/exe/ajax.php
29 print "AJAX call '".htmlspecialchars($call)."' unknown!\n";
htmlspecialchars doesn't do anything to | characters so I would recommend changing the code to
29 print "AJAX call '".urlencode($call)."' unknown!\n";
easy fix :)
Thanks,
-Corben Douglas (@sxcurity)
the issue has been fixed but not rolled out to dokuwiki.org, yet.
Oh yep you're right @splitbrain ! I checked a vulnerable version haha! Thanks.
Is there any h1 private program for dokuwiki.
Can I join? @splitbrain
@trichimtrich I'm not sure what you mean, can you contact me at andi[at]splitbrain.org?
He was asking if you had a program on https://hackerone.com. This was originally reported by me to a program running this wiki. @trichimtrich they do not have a program on there.
I've got it. Thank you
No problem.
This issue was assigned CVE-2017-18123
Is there a stable release planned that includes these fixes?
For the coming release, there are still pending issues. Please see https://github.com/splitbrain/dokuwiki/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22%F0%9F%90%B1+Greebo%22
There is no release date planned.
@splitbrain Has this been fixed with Greebo?
https://github.com/splitbrain/dokuwiki/commit/238b8e878ad48f370903465192b57c2072f65d86
@takuy It should be fixed, because there are release_stable_2018-04-22 and release_stable_2018-04-22a tags on the GitHub commit you posted.
@phy25 I see. Thanks! Just saw this issue was still opened; there's a CVE still open for this, so wanted to make sure it was resolved or not.
For me Greebo bahaved the same as the previous vulnerable version. Did anyone else test it?
@r0bag Tested it. The reponse is cleaned. You can test it with the links in the original post above.
DokuWiki.org will respond to https://www.dokuwiki.org/lib/exe/ajax.php?call=%7c%7c%63%61%6c%63%7c%7c with the cleaned AJAX call 'calc' unknown! instead of the dangerous AJAX call '||calc||' unknown!`.
Yep, I can confirm this is fixed.