Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Password Reset Address Spoof Vulnerability in DokuWiki #1709

Closed
ambulong opened this issue Oct 3, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@ambulong
Copy link

commented Oct 3, 2016

Hi,
This is the another vulnerability i found in DokuWiki.
DokuWiki use $_SERVER[HTTP_HOST] to be a part of the password reset address. This can lead to phishing attacks because of the modification of the site's links. (A remote unauthenticated attacker can chenge the host in reset password address.)
The vulnerability can be triggered only if the Host header is not part of the web server routing process (e.g. if several domains are served by the same web server).

Vulnerable file /inc/init.php, and the getBaseURL() method use $_SERVER[HTTP_HOST] to be a part of the URL.

Solution:
Use the variable $_SERVER[SERVER_NAME] instead of the variable $_SERVER[HTTP_HOST] given that the server name is correctly defined or use an application specific constant.

Hongkun Zeng
hongkun.zeng@dbappsecurity.com.cn

@Klap-in Klap-in added the Bug label Oct 4, 2016

@ambulong

This comment has been minimized.

Copy link
Author

commented Oct 5, 2016

Solution update:
Using the variable $_SERVER[SERVER_NAME] instead of the variable $_SERVER[HTTP_HOST] is not a good solution in some situation. (http://stackoverflow.com/questions/2297403/http-host-vs-server-name/2297421)
The safest, albeit mildly inconvenient solution, is requiring administrators to provide a whitelist of trusted domains during the initial site setup process.

@splitbrain

This comment has been minimized.

Copy link
Owner

commented Oct 5, 2016

Sorry I fail to see the vulnerability here. The password reset URL will contain the host the link was requested with, yes. But how is this a problem. Can you give a concrete attack scenario?

@ambulong

This comment has been minimized.

Copy link
Author

commented Oct 5, 2016

The attacker can change the Host in HTTP Request Header, just like that:

POST /doku.php?id=start&do=resendpwd HTTP/1.1
Host: attacker.com
Content-Length: 71
Cache-Control: max-age=0
Origin: http://localhost:8010
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Referer: http://localhost:8010/doku.php?id=start&do=resendpwd
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8
Cookie: PHPSESSID=ci84qso6grc***; kf_usersid=I83c***; backhttp[2]=http%3A%2F%2Flocalhost%3A8010%2Findex.php%3Fm%3Dadmin%26a%3Dindex%26c%3Dindex%26allow%3Dduc*** backhttp[1]=http%3A%2F%2Flocalhost%3A8010%2Findex.php%3Fm%3Dadmin%26allow%3DduoV609n1xc***%26c%3Dchakanhtml; backhttp[0]=http%3A%2F%2Flocalhost%3A8010%2Findex.php%3Findex%3D-MtmI; DOKU_PREFS=ext_enabled%231%23ext_disabled%231%23ext_updatable%231%23list%23thumbs%23link%231%23align%231%23size%232; DokuWiki=8ohc***
Connection: close

sectok=3c***&do=resendpwd&save=1&login=admin

And then, the user will receive a email from correct email address, but with incorrect reset password link.

ref:
Practical HTTP Host header attacks
http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html

@splitbrain

This comment has been minimized.

Copy link
Owner

commented Oct 5, 2016

Hmm... that would require the target host to listen on attacker.com (eg. having a server alias for it or having no name based virtual hosts). But I see what you mean.

@ambulong

This comment has been minimized.

Copy link
Author

commented Oct 5, 2016

Yes. It is exactly as you said. And it will be a security issue in that situation.

@ambulong

This comment has been minimized.

Copy link
Author

commented Oct 12, 2016

CVE-2016-7965

@michitux

This comment has been minimized.

Copy link
Collaborator

commented Oct 12, 2016

Some ideas how to fix this:

  • Maybe introduce a new configuration variable, as, as far as I can see, we won't have any choice but to force the user to specify all hosts that might be used in URLs. While in most cases it should be okay if all emails contain the same host even though the wiki is available via different domains, there might always be cases where this is not sufficient.
  • Automatically save the current host during the initial setup. This is probably the easiest and most obvious solution for new installations.
  • For existing installations, the whole thing is more tricky. One idea is that we could write the first seen host after the update in some cache file and use that one as default for the configuration value. This should immediately prevent almost all attacks as it is very unlikely that the first access after the upgrade is from an attacker. In order to not to surprise the admin by the set host value, we should additionally display a warning for admins that goes away once they have properly set the configuration variable.

At some point I thought doing a DNS lookup for the host and checking if the IP of the server is returned might be a way to verify hosts automatically (and cache the result to avoid a lookup on every request), but then I noticed that this can be easily exploitable (I'm mentioning it here so nobody else will implement this). The attacker could setup his domain with a very short TTL and change the IP directly after the verification.

@michitux michitux added the Security label Oct 12, 2016

@mprins

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

why not use basedir and baseurl config properties to circumvent this?

@splitbrain

This comment has been minimized.

Copy link
Owner

commented Oct 14, 2016

Autodetecting the host is an important feature for setting up wiki farms and it is a major convenience factor for our users (on installation, on moving the wiki between servers and accessing it from different network locations), so I'm leaning towards a WONTFIX here.

@mprins suggestion sounds like a good compromise. When baseurl is set, it should always be used regardless of the current host header. I believe that is already the case, but we should verify this. Admins can then set this to gain a little extra security against phishing. We can also adjust the documentation to point out this feature.

@splitbrain splitbrain removed the Bug label Oct 14, 2016

@splitbrain

This comment has been minimized.

Copy link
Owner

commented Nov 22, 2016

I confirmed that setting the baseurl will fixate the used server name also for sent out emails and adjusted the documentation at https://www.dokuwiki.org/config:baseurl

I also added another link at https://www.dokuwiki.org/security#dokuwiki_configuration_settings

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.