In this article, we will discuss user privacy issues that our team has recently discovered in two independent e-signature solutions, which have been fixed by now. In the past we also discovered vulnerabilities related to e-signature,Ā for example,Ā a high risk vulnerability in the central e-government services portal allowedĀ user impersonation.
With document signing, Lithuanian e-signature users have the choice between a few alternatives for storing public/private keys and certificates. We will use standalone government ID cards as an example. The approach described in this article should however be valid for other types of smart cards and USB tokens, except for the mobile signature option. It is worth mentioning that upon insertion of an e-signature media,Ā only the qualified digital certificate, and not the private key, is accessible without the PIN code. This certificate contains theĀ NAME, theĀ SURNAME, and theĀ PERSON CODEĀ of the owner of the certificate. Also, in case of regular use of a smartcard/token, chances are it willĀ remain in the card reader of the computer. Why bother disconnecting it, one may ask?
Before exploring the first example, letās recall whatĀ Cross-Origin Resource Sharing (CORS)Ā is. CORS is a mechanism that enables web browsers to perform cross-domain requests using the XMLHttpRequest API in a controlled manner. These cross-origin requests have an āOriginā header, which identifies the domain starting the request.
One typical security issue with CORS: a web browser sends an āOriginā header, and the web server should reply with the āAccess-Control-Allow-Originā header. That same header should contain only whitelisted trusted domains. InĀ reality, often the āAccess-Control-Allow-Originā header contains a wildcard ā*ā, meaning that any domain on the web can communicate with the web server ignoring CORS, without limitations. ToĀ prevent such a misconfiguration, we recommend using a whitelisting mechanism. This vulnerability falls under the category of āSecurity Misconfigurationā ofĀ OWASP Top 10.
GoSignCoreĀ software (version 3.1.3, dated 2020-06-18) is a standalone e-signing application used to sign documents on Windows-based systems provided by theĀ State Enterprise Centre of Registers of Lithuania. The default installation runs a web service on the TCP port 8000 tied to the local host and is the main channel for qualified digital certificate retrieval and data signing. Because of an insecure configuration of CORS, a malicious website can interact with the GoSign web service and retrieve usersā personal information.
Letās take the following code as aĀ proof of concept:
<script>
var createCORSRequest = function(method, url) {
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr) {
// Most browsers.
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined") {
// IE8 & IE9
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
// CORS not supported.
xhr = null;
}
return xhr;
};
var url = 'https://localhost:8000/certs';
var method = 'GET';
var xhr = createCORSRequest(method, url);
xhr.onload = function() {
document.write("<pre>"+JSON.stringify(JSON.parse(xhr.response), null, 2)+"</pre>");
};
xhr.send();
</script>
It is probable that the example code is hosted somewhere on the web or embedded in a legitimate web page using, for instance, aĀ stored cross-site scripting vulnerability, or fully compromising the target website. For it to work, the user of the vulnerable e-signing software has to access this website containing the malicious code. See below the output of the script:
As you might guess, the outputĀ contains the personal dataĀ of the certificate owner, where SERIALNUMBER is the personal code of a Lithuanian citizen. We use this output as an example only since, during an actual attack, the victim wouldĀ not get any warning nor see any output. Besides, the perpetrator would collect and store the data visible on the screenshot.
Dokobit e-signing solutionĀ enables smart-card interactionsĀ and uses a customĀ browser extension āĀ a third-party software module that extends the functionality of a web browser, letting users customize their browsing experience- to interact with the smartcard reader software. Because theyĀ interact directly with untrusted web content, extensions are at risk of attack from malicious website operators and active network attackers.
With the Dokobit Firefox browser extension, letās look at theĀ manifest.jsonĀ configuration file from the extension package to see the problem:
Here we can observe one of the typical browser extension related vulnerabilities, which enables the affected extension toĀ run from any context. Here, theĀ content_scriptsĀ parameter specifies that the browser extension gets injected in all web pages as defined by the match patternĀ *://*/*, meaning that malicious websites can interact with it. Since the extension is used to enhance the functionality of document e-signing, the best is toĀ limitĀ it to only the āDokobitā website context.
Like in the previous example, the following code can beĀ hosted on the web:
<html>
<head></head>
<body>
<script>
function start() {
aa = new IsignChromeSigning()
aa.getCertificate({"lang":"en","certificatePurpose":"signsss","isInitial":false,"policyI
ds":[],"bulkSigning":false}).then((val)=>document.write("<pre>"+JSON.stringify(val,null,2)+"</pre>")).catch((val) => document.write(val));;
}
setTimeout(function(){ start(); }, 3000);
</script>
</body>
The code also uses an extra trick toĀ silently gather personal data. Here, an incorrect value passed to theĀ certificate purposeĀ parameter triggers an exception which returns an error containing the personal data of a user. Without this trick, a certificate selection pop-up is displayed for the user to click on ā making any attack impossible since such behavior raisesĀ suspicion. The malicious website could ultimatelyĀ gather personal informationĀ about the user as shown in the screenshot:
During a genuine attack, the victim would not get any warning, nor see any output, plus the attacker could store this data.
We have briefly shown how trivial vulnerabilities canĀ affect the privacy of end-users. Everyone knows the worth of personal data for data mining companies, hackers preparing phishing attacks, and other exploitation vectors not discussed within this article. E-signature software requires aĀ higher level of security by default, but reality shows that even the most widely used solutions are not faultless. In a nutshell, a secure software development life cycle is eitherĀ not established or insufficientĀ in terms of quality assurance of sensitive pieces of e-signature software.
Critical Security was established in 2007 by a group of cyber security enthusiasts. Since its establishment, the company has been providing high-quality security assessments and penetration tests to various organizations, helping them identify and mitigate potential security threats.