https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/
At HackDefense, we were evaluating various calendaring
solutions, and
during installation and configuration of DAViCal we discovered
three
(severe) vulnerabilities. We reported these vulnerabilities to
the
vendor. Unfortunately, the DAViCal project itself was not able to
fix
these vulnerabilities. As DAViCal is an open source project we
decided
to contribute patches for these vulnerabilities ourselves. DAViCal
has
accepted our patches in the 1.1.9.1 release. If you use DAViCal as
a
calendaring server, we recommend upgrading to version 1.1.9.1
immediately
to remediate the issues we’ve discovered.
All three vulnerabilities exist in the web-based management
pages that
come with DAViCal. We have written three separate advisories to
describe
the vulnerabilities:
CVE-2019-18345 – (this advisory) Reflected Cross-Site
Scripting
CVE-2019-18346 – Cross-Site Request Forgery
CVE-2019-18347 – Persistent Cross-Site Scripting
CVE Reference: CVE-2019-18345
CVSS score: 9.3
CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
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
========
A reflected cross-site scripting (XSS) vulnerability was found
in
multiple pages of the DAViCal CalDAV Server. This is possible
because
the application echoes user supplied input without encoding.
POC URL:
http://davical.host/admin.php?action=edit&t="><script>alert()</script>&id=1
Impact
======
If a user visits an attacker-supplied link, the attacker can
view all
data the attacked user can view, as well as perform all actions in
the
name of the user. If the user is administrator, the attacker can
for
example change the password of the user to take over the account
and
gain full access to the application.
Solution
========
Update to version 1.1.9.1
Technical solution details
==========================
XSS vulnerabilities are a problem with dynamically generated
websites
that use user input. If user input is not correctly sanitized you
could
very well end up with a user pushing some javascript to your
frontend.
XSS isn’t a vulnerability that’s hard to grasp or circumvent but
it’s
awfully easy to make a mistake like that. One thing you’ll hear
over and
over again is never to trust user input. Always sanitize it when
it
comes in and it’s best to still not trust it then. Characters like
<, >
and " should never be rawly echoed to the frontend. The use cases
for
echoing user input back to the frontend are endless. From a
simple
"Greetings, $username" to editing personal user information with
the
form having all the fields already filled in. So when someone has
a
quote in their name, you shouldn’t echo the raw quote but
".
These days web frameworks handle a lot of sanitation for us.
Laravel for
example uses simple brackets to echo variables to the user all
these
variables are escaped first: {{ $username }}. Twig does
something
similar by using a pipe like syntax: {{ $username | escape}}.
These days when developing your application you need to make
sure you
sanitize everything you output to the user. But since DAViCal is
an
established project it’s not doable to sift through the code to
look for
functions that output text to the frontend. Another problem was
that
DAViCal dynamically adds GET parameters to echoed urls. This is why
I
chose to sanitize both incoming variables and their names. In
the
DAViCal always.php I added a function that loops through the $_GET
and
$_POST array recursively (as arrays can contain arrays and so
forth) and
run the names and variables through htmlspecialchars() except for
the
password field which of course should be able to have special
characters
in them.
The reason you don’t do it this way in new applications is
because now
if for some reason someone has another way of interacting with
your
application (by API calls for example) you’d have to sanitize your
input
on both sides. Moreover, APIs that pass JSON objects around for
example,
don’t need to have script tags encoded as it means nothing to them
and
JSON objects are encoded in a different way. In this case
however,
DAViCal doesn’t have other entry points which you can use to insert
data
in the database. So sanitizing all input once will suffice!
Responsible Disclosure timeline
===============================
04-Jan-2019 Reported to the DAViCal CalDAV Server project (no
response)
21-Jan-2019 Reported to the DAViCal CalDAV Server project again
22-Jan-2019 Report acknowledged
28-May-2019 Asked for an update regarding these vulnerabilities
29-May-2019 The DAViCal project responded that they did not
have
resources to implement a fix for these vulnerabilities
31-May-2019 Partnered up with Niels van Gijzen to contribute a
patch
24-Oct-2019 CVE-2019-18345, CVE-2019-18346 and CVE-2019-18347
were
assigned to these vulnerabilities
25-Oct-2019 Released a patch that fixes these vulnerabilities
29-Nov-2019 DAViCal verified the patch
03-Dec-2019 DAViCal released version 1.1.9.1 including our
patch
Useful links
============
DAViCal 1.1.9.1 Release Notes
https://wiki.davical.org/index.php/Release_Notes/1.1.9.1
DAViCal 1.1.9.1 on Gitlab
https://gitlab.com/davical-project/davical
This advisory
https://hackdefense.com/publications/cve-2019-18345-davical-caldav-server-vulnerability/
