Categories
Security Research

Virus harvesting Czech eID card identities

This research was conducted in cooperation with WardenSec.

This research was presented at QuBit Prague 2020. Video of the talk is available on YouTube.

Popis zranitelnosti v češtině je k dispozici zde.

Introduction

Czech government started issuing new electronical identity cards (further referred to by its Czech name eObčanka) back in July 2018. Those shall provide secure online authentication towards government ICT systems including social security account, online medical prescriptions, land registry, tax returns and more. Assuming eObčanka is well received by public, this Single sign-on (SSO) system could be expected to facilitate further use-cases in the future, possibly also including online voting. Due to the fact that successful theft of those identities might have wide-ranging consequences it is necessary to properly secure them.

eObčanka is implementation of proprietary government PKI system. Authentication key pair is generated and distributed with each eObčanka card and cannot be easily extracted. Usage of private key is protected by PIN known only to the card holder. At first glance this architecture seems to provide adequate security for given use-case.

Nevertheless, we have identified serious design flaw in the authentication workflow which allowed those identities to be stolen at bulk in simple malware campaign. Potential remote attacker could steal those guaranteed citizen identities without victim’s awareness. Our attack assumes that victim’s computer is infected with simple malware. Not citizen nor authentication backend was able to detect such identity theft at the time of our responsible disclosure to National Cyber and Information Security Agency.

Given the information security awareness of an average citizen, we argue that security of the system cannot rely on premise that citizens are not trying to authenticate from devices which are infected with malware or otherwise doctored. Czech eObčanka system was therefore facing serious risk of being targeted by malware campaign. Motivation for such campaign could be twofold – foreign geopolitical power trying to affect potential future online elections or cybercriminals filling in fake tax returns to steal tax refunds.

Throughout this article we would like to introduce you to the eObčanka system, explain how the authentication procedure could be broken and demonstrate proof-of-concept virus covertly stealing guaranteed online identities of fully unaware citizens, demonstrating this attack is not only theoretical, but practical indeed. Lastly, we discuss why it was close to impossible to identify the attack on users side and also why it was not being detected on backend side.

Usual authentication workflow

This section describes standard eObčanka authentication workflow against ePortal of Czech Social Security Administration (it is important to note that this detail is not relevant – security flaw lies in SSO functionality – once SSO identity is stolen, attacker can login to all government systems available under this SSO). Authentication workflow is also severely simplified and we only describe details necessary to understand our attack. The following steps are taken in order to login (see also figure 1 with detailed login diagram):

  1. Citizen navigates to the ePortal of Czech Social Security Administration website: https://eportal.cssz.cz and selects authentication using National Identity Authority (NIA)
  2. Citizen is redirected to SSO portal of NIA (frontend) https://eop.eidentita.cz and selects authentication using eObčanka
  3. NIA frontend initiates the authentication session by generating transaction identifier (mwId) in the uniqueidentifier format and asks user’s browser to open the following URL: czeeopauth://mwid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, where Xs represent given uniqueidentifier.
  4. Triggering URL from step 3 leads to independent application eObčanka Identifikace being opened on user’s computer with mwId being its second parameter (argv[1] for those familiar with C development).
  5. Program eObčanka Identifikace securely authenticates citizen against NIA backend (https://mweop.eidentita.cz). During this process, citizen needs to enter PIN code by which private authentication key is protected inside eObčanka. Upon successful completion, citizen’s identity is bound to given transaction ID (mwId).
  6. All infrastructure components – NIA backend, NIA frontend and ePortal of Czech Social Security Administration – are communicating together. Therefore, ePortal now knows the citizen’s identity which is proven by ownership of eObčanka and knowledge of PIN. Citizen is therefore successfully logged in (this part is significantly simplified).
Figure 1: Schema of standard login procedure

Theory behind our attack

Chain is unfortunately only as strong as it weakest link. In case of the login procedure described in the previous section it is step 4 in which browser initiates desktop application eObčanka Identifikace from the browser and passes mwId as application parameter. Computer of average citizen might be infected with malware, which might change the authentication workflow to the following:

  1. Citizen navigates to the ePortal of Czech Social Security Administration website: https://eportal.cssz.cz and selects authentication using National Identity Authority (NIA)
  2. Citizen is redirected to SSO portal of NIA (frontend) https://eop.eidentita.cz and selects authentication using eObčanka
  3. NIA frontend initiates the authentication session by generating transaction identifier (mwId) in the uniqueidentifier format and asks user’s browser to open the following URL: czeeopauth://mwid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, where Xs represent given uniqueidentifier.
  4. Triggering URL from step 3 leads to independent application eObčanka Identifikace being opened on user’s computer with mwId being its first parameter (argv[1] for those familiar with C development). At this point, however, malware intercepts this call.
  5. Malware which intercepted this call immediately connects to the attacker’s backend (command & control server).
  6. Attacker’s backend requests its own login transaction identifier (mwId) in the following format: czeeopauth://mwid=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY. Note that this mwId is unrelated to the original mwId requested by user.
  7. Malware swaps the transaction id of the user czeeopauth://mwid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX for the transaction id of the attacker czeeopauth://mwid=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY in the program memory of eObčanka Identifikace.
  8. Program eObčanka Identifikace securely authenticates user against NIA backend (https://mweop.eidentita.cz), but this time using transaction ID of the attacker. Upon successful completion of this process, citizens identity is bound to attackers transaction ID YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY instead of user’s transaction ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX!
  9. At this point, attacker successfully completed identity theft and fully controls user’s government guaranteed identity. As NIA is SSO portal, attacker is able to login to all systems connected to it (including ePortal of Czech Social Security Administration) and act in the name of the user.
  10. Legitimate user’s login attempt times out with inconclusive error. User has no chance to find out his identity was just stolen.
Figure 2: Schema of theoretical attack against standard login procedure

Practical implementation

Attack might seem complex to implement, but it is in fact surprisingly trivial to implement and carry out. Program eObčanka Identifikace does not rely on system openssl library and it is instead installed with its own openssl version.

Figure 3: Bash script initiating eObčanka Identifikace with its own openssl library

Let us assume that some citizens use compromised computers with malware (virus) which infected this openssl library. Library can be easily modified so that upon its initialization it executes steps 5-7 of the theoretical attack described in the previous section.

Openssl must be initialized when program starts and prior any communication between eObčanka Identifikace application and NIA backend can be done. We can therefore modify openssl initialization call to trigger our virus as follows.

Figure 4: Malware planted in openssl library SSL_new() function

Actual attack is then carried out within spoof_MWID() function as follows.

Figure 5: spoof_MWID() function which swaps transaction IDs

Malicious function simply calculates position of argv array (arguments with which program was started) on the program stack (this value is constant across different program executions) and replaces argument holding legitimate mwId with attacker’s mwId.

We have successfully tested proof-of-concept of this attack on Linux version of eObčanka Identifikace. There is no indication that similar attack would not be possible on other OS versions including Windows and Mac. Following shows video of working proof-of-concept attack.

YouTube

By loading the video, you agree to YouTube’s privacy policy.
Learn more

Load video

Video demonstrating working PoC

What is the potential impact?

In case of successful identity theft, eObčanka Identifikace program and NIA frontend leaves user no chance to recognize that anything malicious happened. The only difference between successful login attempt and the one that has been stolen is the login attempt timeout with generic error message. It is fair to assume that no user would find that suspicious, instead they would try to login again.

In theory NIA backend shall be able to partially detect and prevent this attack, but to our surprise it did not detect it even in the most obvious forms. Even the most naive implementation of this attack – with login attempts starting from browser at IP address 1 and certain geolocation and completing from eObčanka Identifikace program at IP address 2 and totally different geolocation succeeded.

We believe this security flaw constitutes significant security risk for the whole system of eObčanka. We do not believe that someone would be motivated to misuse it in order to steal single identity. There is, however, significant risk that someone might be motivated to mount malware campaign against Czech users trying to steal those identities en mass. Motivation to orchestrate such attack would only grow with eObčanka growing adoption rates. Ideal motivation for such attack might be attempts of foreign geopolitical force to influence future online elections at Czech Republic or simple motivation of cybercriminals to steal tax returns submitted online using eObčanka.

Responsible disclosure

We have initially identified this issue in the first half of 2019. We have reported it to responsible people, but we were not properly informed on the countermeasures . Therefore, we presented the issue at QuBIT conference in Prague 2020 and released this article to public scrutiny.

Responsible disclosure timeline:

  • 19th&20th January 2019: Hackathon eObčanka in Paralelní Polis
  • 14th August 2019: Issue reported to NÚKIB (National Cyber and Information Security Agency of Czech Republic)
  • August – November 2019: No progress despite several reminders and status inquiries. NÚKIB stopped communicating with us.
  • Spring 2020: We noticed first visible countermeasure. mwId is now displayed in eObčanka Identifikace as well as on the web, so user can at least manually compare them.
  • 27th August 2020: Shared presentation slides from our upcoming talk at QuBIT conference with NÚKIB. We received no response nor comment.
  • September 2020: Public disclosure at QuBIT conference in Prague 2020. It is more than 1 year since we initially reported the issue. We are not aware of any other countermeasures taken.
Figure 6: The only countermeasure that was (to the best of our knowledge) implemented