Deanonymization Of Lithuanian E-Signature Users

In 2020, remote work and digital access to public services have become the new normal. Lithuanian citizens have multiple options for accessing different public services and signing documents online.

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.

Typical Usage Scenarios

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?

Example 1 ā€“ GoSign misconfiguration

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.

EXAMPLE 2 ā€“ DOKOBIT MISCONFIGURATION

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.

Conclusion

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.

About Us

Ā© 2024 Critical Security