This article describes three vulnerabilities discovered by the BSSI audit team during this test. They affect the EPS TSE Server 8 (version 21.0.11) administrative interface.
The EPS TSE Server 8 Web-based administrative interface is used to manage and configure tax printers connected to the EPS TSE Server 8:
First vulnerability – Recovering administrative credentials without authentication (CVE-2020-28929)
The first vulnerability allows an unauthenticated attacker to download an archive of server logs. In this archive, it is notably possible to retrieve the identifiers (username and hashed password) of the administrative accounts.
The tests, conducted by the auditor, followed two steps:
- Black box: The first step allowed to assess the application, without any prior information, as an attacker would do.
- Grey box: The second step consisted in auditing the application security using an account provided by the client’s technical team, as a malicious employee would do.
First, an automatic navigation via fuzzing of folders and files (using tools such as Dirb, Patator or WFuzz) was conducted in black box. The fuzz allowed to discover the existence of the file “http://<IP>/maintenance/troubleshoot.php”, but the web interface returned only a blank page.
Then a manual navigation, in grey box, of the application allowed to test the functionalities present in the administrative interface. The analysis of the requests allowed to notice that the log export feature used the URL “http://<IP>/maintenance/troubleshoot.php?download=1”.
A GET request to this URL allows the download an archive containing many log files:
The analysis of these log files made it possible to find all the identifiers of the interface as well as the fingerprint of their password:
Here the couple “admin / $6$seh$Hg0i6hGTSqOJRESk1E/RJnLVvUDh/Q7l0N9zHsH5xODtQZkR/ETDIHc1Up57Yj7q3JoFwIUrijyQOtqW/z54C1” could be found. The use of the python crypt library makes it possible to retrieve the fingerprint of the password of the admin account:
In order to test the authentication mechanisms, the auditor tried to retrieve the archive containing the log files without being authenticated. Since the log exporting feature did not check the presence of an authentication token, the log files could be recovered without being authenticated.
An attacker can therefore recover the “account / password hash” pairs from the device, then break them offline in order to gain administrative access to the device.
Tests conducted by the auditors revealed a parameter vulnerable to Cross-Site Scripting (XSS) injections. It was identified in the user management tab of the administration interface (https://<IP>/settings/users.php).
Note: Interception of requests using a proxy (Burp for example) is required to create a user with malicious code as display name.
Once the user is created, an administrator is forced to execute the malicious payload when he clicks on the “update” or “delete” button:
Since the device’s session cookies are generated without the “Secure” and “Http-only” security attributes, it is possible to retrieve another administrator’s session token by this method.
The device has only one type of account (administrator) and the exploitation of this vulnerability requires an admin account. This vulnerability can therefore only be used by chaining with the third vulnerability (CSRF) or by a malicious employee who would like to trap another administrator before performing malicious actions on the device.
Third vulnerability: Cross-Site Request Forgery (CSRF) vulnerability across the entire administration interface (CVE-2020-28931)
The third vulnerability allows an unauthenticated attacker to force an authenticated user (i.e., an administrator) to execute POST requests without his knowledge. This vulnerability notably allows an attacker who does not have a valid account to obtain one by forcing an administrator to create a new high-privilege account.
Indeed, the tests carried out by the auditors made it possible to notice the absence of anti-Cross-Site Request Forgery protection.
The attack consists in causing a victim to send requests (for example, GET or POST) to a vulnerable site (V), without his knowledge and on his behalf (see figures 1 and 2). The requests are sent when the victim visits a malicious or compromised site (M), or clicks on a link. The attack always targets one or more sites in particular that are vulnerable. The CSRF is always done blindly, because the attacker causes one or more requests to be sent without getting a response.
Upon discovery of the vulnerabilities, the BSSI auditing team contacted and reported the vulnerabilities to the corresponding SEH team (responsible for the product). A patch was made available on October 15th, 2020 (corresponding to version 21.0.18). This patch effectively fixes the 3 vulnerabilities although it is not indicated in the changelog.
07/29/2020 – Discovery of the vulnerability
08/24/2020 – First contact with the Security team of EPSON
10/06/2020 – Contact with the Security team of EPSON
10/15/2020 – The vulnerabilities are pretended to be fixed using the patch 21.0.18
10/26/2020 – Correction verification request
11/13/2020 – Contact with the Security team of EPSON
11/30/2020 – Vulnerability disclosure (notification to EPSON + 90 days)