These days we tried to find some vulnerability in webmail.ie.cuhk.edu.hk. And we found that it consist of xss vulnerability for us to spoof the same webmail address with injection in URL. It is already an old issue mentioned back to year 2006 in version 2 of Horde, however we come back to the xss injection again in version 4.1.3.
The most updated version of horde IMP is: 4.2.x with one following major security updated had already fix the problem by implementation of filtering HTML entities in URL input:
As the horde server had encountered several url injection problems, we made a list of proof of concepts as follow. Although all of the url are easy be covered by normal user, it’s work very well combined with social network applications:
Injection start here: We can insert our bad script at the original notice message
<a href=”https://webmail1.ie.cuhk.edu.hk/horde/imp/login.php?logout_reason=message&logout_msg=HEHEHEHE
**Search and wipe out the notice message:**
https://webmail.se.cuhk.edu.hk/horde/imp/login.php?logout_reason=message&logout_msg=
</tr><tr >
**Override the submit button at create a hidden form:**
**Add the victim site's URL to the post request: (Since our target is horde version 4.1.x without modification but not single site)
**
**Add invisible form and submit the form when user press "submit":**
**Add invisible iframe and submit the iframe when user press "submit":**
**To minimize the impact of those actions:**
--Submit two post request one after one.
--Construct a fake page which will return to the legitimate page after the user name and password is being captured (window.location=document.referrer or submit the post form to legitimate site again)
--Register a cert from trusted CA and user will post their form to us without warnings.
**It is one of the example of phishing attack:**
**We find some trivial observations in https:**
-- It have warning from https to http.
--When we have two posts request to two sites (bad sites and legitimate sites) in one action,
the bad site request will only succeed if we own a certs from well-known CA or user had already trusted our cert before.
-- It have warning from https to other untrusted https.
-- Another way to fake users to accept our cert is to include an invisible iframe and convince user to trust our certs when they visit the legitimate page. Such that the request will be pass to our site.
To mitigate this vulnerability, horde had already done updates to filtering to HTML entities in URL address. On the other hand it is also the browser responsibility to eliminate some non-reasonable characters like "". As it is already been tagged as UNSAFE in RFC1738 date back to 1994 from T. Berners-Lee. Anyway no one may notice that after 15 years had pass......
Some useful tools:
[http://meyerweb.com/eric/tools/dencoder/](http://meyerweb.com/eric/tools/dencoder/)
[http://javascriptcompressor.com/](http://javascriptcompressor.com/)
Continue:
Phishing to HKU: It don't have https at all, the request will be sent "quietly"
The script override the three functions in post request, all five button will redirect to our pages.
Continue:
Another site I searched from google with: inurl:horde/imp/test.php
(use the same payload for webmail1.ie.cuhk.edu.hk can fake following sites:)
http://webmail.unix66.com/horde/imp/index.php
http://spike.samoa.net.ws/horde/imp/index.php
https://eboks.net/horde/imp/index.php
http://unixlingo.com/horde/imp/index.php //Need some change to eliminate the notice box
http://webmail.nefonline.de/horde/imp/index.php
http://webmail.chaiphirom.com/horde/imp/index.php
http://www.embryo.pu.ru/horde/imp/index.php
http://webmail.dfinternet.net/horde/imp/index.php
http://cst-systemhaus.de/horde/imp/index.php
https://eboks.net/horde/imp/
http://webmail.nefonline.de/horde/imp/
http://stiu.de/horde/imp/
http://spike.samoa.net.ws/horde/imp/
http://www.reina.si/horde/imp/ //permission not set
http://haro.astrossp.unam.mx/horde/imp/index.php //Permission not set
Continue:
Even shorter:
END
Comments