A storm in a teacup 09.11.2018
In recent days, the disclosure of a “flaw” in the e-voting system used by the canton of Geneva has featured widely on Swiss social networks. The information was initially disclosed by the Swiss Television SRF (source for German speakers). Since then, there has been a wave of political reactions/repercussions stating that " the security is not at the desired level ". In my opinion, the majority of these statements are populist (let's protect honest citizens from the big bad Internet) by people who have only glossed over the subject. What is this “flaw” from a technical point of view? A guest column from Kevin Chollet.
The flaw from a user's point of view
- Login to the e-voting portal using the URL such as www.evoting-ch.ch
- Redirection to a URL such as https://hacked-evoting.ch
- The site displayed copies the style of the legitimate website so as not to arouse suspicion. It is the main channel of exploitation, namely a man-in-the-middle attack.
The flaw itself is step 2, the redirection from www.evoting-ch.ch to https://hacked-evoting.ch. This exploits a cache-poisoning type attack. To understand this type of attack, it is necessary to specify the context of the request (a request is generated when the user accesses a website).
What is the life of a web request?
Overall, a web request is as follows:
This is the ultra simplified version of a request. However the DNS step is a little more complicated than that. Unfortunately it is necessary to understand the operation a little more precisely in order to understand the attack.
In a nutshell, the DNS "translation" is carried out according to a principle of delegation: the DNS server "resolver" (mainly the DNS server of the operator) will make a request to the "authority" of the .ch in order to find out which server takes care of evoting-ch.ch and then sends a request to the latter server to find out how to resolve www.evoting-ch.ch.
The DNS poisoning attack
The DNS poisoning (DNS cache poisoning) attack, in general, targets the resolver DNS server (at the level of the red dot in the previous graphic). This server uses a cache mechanism (in order to avoid reducing the number of underlying requests). The attack consists of compromising this cache so that the requests are directed to a malicious server.
How to protect yourself?
The majority of reactions following the disclosure of the flaw have criticized the person responsible for the e-voting system. There are mechanisms to avoid this type of attack that can be implemented by the service provider (DNSSEC) but that's not all: this is the best way to take away responsibility from the end user!
DNSSEC
DNSSEC is a mechanism to ensure that the DNS resolution is carried out legitimately. A previous article explains the concept and its implementation in certain contexts.
It should be noted that the use of DNSSEC is limited at present: according to figures from nic.ch 2.8% of.ch sites implement DNSSEC
HTTPS by default
This flaw redirects from the URL http://www.evoting-ch.ch to https://hacked-evoting.ch but in the case where access is explicitly via https: //www.evoting-ch.ch, the redirection will not be carried out (a certificate error will be displayed).
HSTS and HSTS Preload
HSTS is a mechanism which forces browsers to connect using HTTPS by default. Once the initial connection has been established, HSTS indicates through the use of a header that websites should be accessed using HTTPS by default, preventing the risk of DNS cache poisoning. However, the initial connection itself remains a problem. For this reason, HSTS has been enhanced with HSTS Preload, a list which is consulted dynamically by browsers and forces them to connect to a specific domain using HTTPS by default.
Make users take responsibility
The way this attack works is very similar to phishing. Today, users need to pay close attention: a visual check of the URL is time-consuming but necessary to guard against this type of problem.
In addition, as illustrated in the second graphic, this attack concerns elements of the user environment: the end user is responsible for using an uncompromised computer terminal. The present case makes it possible to blame the flaw on the service provider, but in the case where the access terminal is infected or the user uses a compromised browser, the only response can be to take care of the real problem, i.e. the terminal. The user chooses, mostly unknowingly, the DNS servers he trusts to direct his web browsing (either explicitly or via the choice of his operator). If the DNS server in question is unreliable, it is necessary to query the choice rather the remote service at which access takes place.
This article was first published on blog.cholletk.me.
