[eduVPN-deploy] Details Security Issue 2021-08-25

[François Kooman]

Hi all,

On August 25, 2021 we were made aware of a security issue in the eduVPN 
/ Let's Connect! server by Nick Aquina, an eduVPN for Android 
application contributor. All servers we are aware of were updated in the 
last days.

** Vulnerability **

The vulnerability was a classic "input validation" issue. We did not 
verify user input. Due to this problem, the potential for a 
vulnerability was always there, but it became exploitable after an 
update to one of the tools we depend on for generating QR codes. These 
QR codes are used for two-factor enrollment.

The server software was VULNERABLE on Debian 10, Debian 11 and Fedora. 
The server software was NOT vulnerable on Debian 9 and CentOS 7.

The vulnerability was first introduced in vpn-user-portal 2.3.2 released 
on 2020-07-27.

** Scope **

The attack could have been executed by anyone able to login to the VPN 
portal. This typically means all your users.

** Fix **

The vulnerability was fixed in vpn-user-portal 2.3.14 released on 
2021-08-26.

** Description **

The vulnerability became exploitable because of an unfortunate number of 
circumstances:

1. We did not perform adequate input validation on the potentially user 
provided data to generate a QR codes;
2. We use "exec" to run a binary on the system which is risky, 
especially when using user input;
3. The qrencode binary in distributions got updated and introduced a 
"read from file" parameter that did not previously exist;
4. We enabled the QR module _even_ when two factor authentication was 
not enabled.

We did not perform input validation for the QR code generation as it 
seemed not that important at the time and the "Key URI format" [1] was 
quite complicated to validate correctly. Of course, it was a mistake not 
to do that anyway.

The reason we used "exec" to run an executable (2) was that it was much 
faster and we could use a binary already available on all operating 
systems we support [2] and thus remove a few PHP dependencies.

The qrencode tool as mentioned in (3) got the new flag `-r` in version 
4.0.0. Because CentOS 7 [3] and Debian 9 [4] never had/got this version 
I didn't notice the `-r` flag when reviewing the man-page.

Reason (4) was another oversight: we enabled code that was not used 
which is better to avoid. It would have reduced impact substantially.

** Implemented Fixes **

In the current production release we solved (4) by only enabling it when 
two factor authentication is enabled. This reduces the potential attack 
surface. Furthermore, we only allow the TOTP secret to be specified. It 
can be strictly validated as it only uses the Base32 alphabet. This 
solves (1). It is still not the perfect solution. In the next (major) 
release of eduVPN/Let's Connect! we'll avoid exposing a "QR endpoint" 
altogether and directly embed the QR code. Another fix already 
implemented is a strict requirement in the code to always specify a 
validation function when using external input, that will prevent 
"forgetting" to validate input.

** Exploitation **

We did NOT see or hear any indication of exploitation in the field. 
However, you can verify your web server log files and check for 
occurrences of requests to "/qr?qr_text" that look suspicious and e.g. 
point to a file with the "-r" flag. You can check the log files in 
/var/log/apache2 (Debian) or /var/log/httpd (Fedora). If you find 
something, or are not sure, please let us know!

** Recovery **

In case you want to "reset" your server, you can do that, but make sure 
you first install the updates. Note that all users will have to login 
again using the eduVPN/Let's Connect! apps and/or download a new 
configuration file from the portal as ALL data (including local user 
accounts), but no configuration, pertaining to the VPN server will be 
deleted. For single server VPNs:

     $ sudo vpn-maint-reset-system

** Final Thoughts **

It took a few days to get servers updated, which in the end is not so 
bad. We did have to contact some server operators a few times in order 
to get them to update their servers. It is not exactly sure how to 
improve this process. However, it could have been a lot worse...

Let us know if you have any questions!

Regards,
François

[1] https://github.com/google/google-authenticator/wiki/Key-Uri-Format
[2] https://github.com/Bacon/BaconQrCode/issues/70
[3] https://git.centos.org/rpms/qrencode/blob/c7/f/SPECS/qrencode.spec
[4] https://packages.debian.org/stretch/qrencode