CVE-2019 – 18346 Cross-Site Request Forgery (CSRF) vulnerability in DAViCal CalDAV Server

All three vulnerabilities exist in the web-based management pages that come with DAViCal. We have written three separate advisories to describe the vulnerabilities:

1. CVE-2019-18345 — Reflected Cross-Site Scripting
2. CVE-2019-18346 – (this advisory) Cross-Site Request Forgery 
3. CVE-2019-18347 – Persistent Cross-Site Scripting

About DAViCal

DAViCal is a server for calendar sharing. It is an implementation of the CalDAV protocol which is designed for storing calendaring resources on a remote shared server. It can be used by various e‑mail and calendaring clients to centrally store and share calendars.

It includes a web-based management application. It was in these pages that we discovered this vulnerability.

Affected systems

DAViCal CalDAV Server 1.1.8 and prior

Overview

The application has no protection against CSRF attacks. If an authenticated user visits an attacker-controlled webpage (for example, in another browser tab), the attacker can send arbitrary requests in the name of the user to the application, including requests that result in a state change.

For example, if an attacker includes the following HTML code on his/​her site and an authenticated DAViCal administrator visits, a new administrative account ​“hacker” (password also ​“hacker”) will automatically be created in the background, giving the attacker full access to the calendaring application:

Impact

In a successful CSRF attack, the attacker can change the e‑mail address and password on a victim’s account, which results in a full account takeover. If the compromised user has a privileged (administrator) role within the application, then the attacker is also able to add a new administrator user. 

Solution

Update to version 1.1.9.2

Technical solution details

The most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests. The idea is that you assign a unique token to a user’s session, this token can be regenerated whenever but this usually happens when a new session is created (e.g.when the user logs out and logs back in). This token is then required to be sent along with the rest of the data you want to submit. Prior to performing the action the called route is supposed to perform(let’s say you want to update your user information) the application will check if a CSRF token is present and whether it’s the right one. Once those two checks pass the application will continue executing.

So the first task was to write a library that would generate a CSRF token and attach it to the session. That’s all pretty basic, the only thing I had to take into account is that the current requirement for DAViCal is PHP 5.6.0 and up so I had to keep backwards compatibility in mind. The token is generated by a random number generator (which one is decided by the current PHP version) and then assigned to the user. Once that was done the only thing left is to make sure every information altering request verifies the CSRF token.

The modern way most web frameworks will handle this is by using middleware. Let’s say you map a route to a function in your code,you can then put a CSRF middleware in the middle of that ​‘mapping’. So let’s say you’ve got the following mapping:

‘/​user/​information/​update’> updateUserInformation();

You’d then tell your framework to use a CSRF middleware which would change the flow to:

‘/​user/​information/​update’> checkCSRF(); > updateUserInformation();

DAViCal however is quite an old project (the copyright states 2006 as starting year) and we don’t have the luxury of a framework handling these things for us. The easiest solution is to find every place a POSTrequest is made and manually verifying the token at those places. But I was keen to find out if there was a more central place I could put the CSRF verifying function. As every developer will know, getting to know and understand someone else’s code can be quite a tough one. I found myself using xdebugquite a lot to figure out the flow of the application until something quite obvious became apparent. There is a PHP file in the project called ​‘always.php’ which always runs. This file can be used to launch a function on every page load. This is where I added a function to check the CSRF token on POST requests (which are used in DAViCal to alter information).

The final act was adding the CSRF tokens to all the forms in DAViCal which could be easily found by searching for </form>. Which concluded the fix for the CSRF vulnerability in DAViCal.

Responsible Disclosure timeline

Useful links

• DAViCal 1.1.9.2 Release Notes
• DAViCal on Gitlab
• This issue in the Common Vulnerabilities and Exposures (CVE) database
• This issue in the National Vulnerability Database (NVD)
• This advisory on fulldisclosure
• Debian security advisory