ZION SECURITY :: Unsecure implementation of eID authentication in Drupal

Unsecure implementation of eID authentication in Drupal

Friday, February 26, 2010 by Administrator

A few weeks ago I saw a tweet by Dries Buytaert, the creator of Drupal, that a Belgian web agency created a module for Drupal to allow authentication with the Belgian electronic identity card (eID). I am a supporter of Drupal and the eID card since years.

ZION SECURITY wrote a whitepaper about implementing a secure authentication framework for the eID, see http://www.zionsecurity.com/news/whitepaper-10-tips-voor-een-veilige-eid-implementatie.aspx.

Because it is Drupal, the module is open-source so we took a look at the implementation and to my big surprise, the implementation fails terribly at securing the authentication process.

Testing this in our lab was impossible because the quality of the module is unsatisfying and I don't want to waste time fixing somebody else mistakes. However, it was for me required to blog about the unsecurity of this module before somebody uses it for a production environment. Contacting this web agency resulted in nothing constructive so this is also an eye-opener for them!

What is the problem? There are different problems.

1. They use the serialnumber of the certificate, which is the Rijksregisternummer (SSN) of a Belgian citizen. The usage of this SSN is prohibited by the Belgian Privacy Commission but they use it as a primary key in the Drupal user database (fail!)

2. To authenticate the user, they use a proxy server that will validate the eID certificate and retrieve the values like firstname, lastname and serialnumber. These parameters are then sent to the Drupal site using HTTP in clear text! No protection of the SSN is provided in any way, for example: http//drupalsite/eid/response?firstname=Erwin+Andr%C3%A9&lastname=Geirnaert&serialnr=CENSORED &token=0f2e01a6bedb2dee2df2bde2c05f68c8

3. The token that you notice in the URL above is generated by the Drupal site! This token is visible for the user and can be copied and re-used, in my Drupal site this was /eid.php?token=0f2e01a6bedb2dee2df2bde2c05f68c8&login=CENSORED

4. To make things worse, if we combine the previous information we can logon to any web site that uses this module when we know the SSN number. We don't need the eID, the PIN code or the certificate, only the SSN. How do you get the SSN? The SSN is a string of 11 numbers, where the first 6 are the birthdate of the user and the last 5 are random. So if I know somebody his birthday (LinkedIn, Plaxo, Facebook anyone?) I can brute-force his SSN in 9999 requests to gain access to the Drupal site. These attempts are not detected, blocked or logged!

5. All connections to the Drupal web site are not using HTTPS so it is possible to sniff the user his cookie! Now that is possible to use SSL with client certificates thanks to the Belgian government, unbelievable!

Typing this makes me somewhat angry. Initiatives like OWASP, SANS Secure Coding, ... are useless when people don't want to write secure code and forget about the impact of security bugs and even refuse help from people like us!

13 comment(s) for “Unsecure implementation of eID authentication in Drupal”

Geert Says:
Tuesday, March 02, 2010Hi, you write "and the last 5 are random"...Even that is not exactly true: the two last are the reminder of a DIV 96 (just like belgian bank account numbers)
Johan Says:
Tuesday, March 02, 2010Actually it's 97, because that is the greatest prime number with 2 digits.
Fang Says:
Tuesday, March 02, 2010Well it's not even bad coding practice, it's pure non sense or naive/simple mind implementation...
Jan Says:
Tuesday, March 02, 2010I also had questions about the storage of the rijksregisternummer of the user, so I already submitted a bug report for this.

And since the last 2 digits of the RRN contain a checksum, only 1000 attempts are required to brute-force it.
Rémi Says:
Wednesday, March 03, 2010While these issues are all valid, you don't seem to have reported any bug regarding them to the drupal BTS.

I know that driving traffic to one's blog is crucial, but bug reporting would help the developpers enhance the system, or at least show potential users the security implications of using this module.

Right now, the only bug report that I could find is about the potential illegitimate use of the nationnal number (from Jan I presume). Which is a start, but clearly doesn't represent the real security risk that using this module represents.
Erwin Says:
Wednesday, March 03, 2010Hi Rémi,

I contacted Dries @ Drupal and Drupal Security. The problem is that it cannot be solved with fixing 1 bug, the design is flawed.
Rémi Says:
Wednesday, March 03, 2010Hi, the problem is that right now there is no trace of these problems on the drupal website. So an unsuspecting user (like me) can't have any idea of what happens.
Amedee Van Gasse Says:
Wednesday, March 03, 2010@Remi: a very valid criticism, but why haven't YOU stepped up and reported a bug? Put your money where your mouth is! Meanwhile I have promoted Jan's feature request to a bug report.

@Erwin: there are thousands of contributed Drupal modules, and Dries Buytaert is a very busy man. It's useless to contact him about a tiny little module. That's like contacting Linus Torvalds for a bug in a linux kernel module for hardware that only two people in the world use.
You should contact the author, coworks.be
Amedee Van Gasse Says:
Wednesday, March 03, 2010According to a comment on the datanews article, the agency that developed the module was never contacted. Or they are blatantly lying. I think that this can only be resolved by a full disclosure of the email conversation between Zion Security and Coworks.
Wim Leers Says:
Wednesday, March 03, 2010I didn't read the article in depth. But I definitely believe that the Drupal module is a poor implementation and has severe security issues.

However, what also must be said, is that the requirements to implement proper secure eID authentication are also absolutely ridiculous. They require too much fiddling, don't work in *all* browsers, require you to set up a separate authentication server, IIRC even require you to install an application/plugin/something vague on your pc (and it only works properly in Windows IIRC) and whatnot.

From what I've seen, eID is a joke.
Erwin Says:
Wednesday, March 03, 2010@Amedee, we were contacted by Coworks with the same question. I mailed them our e-mail and their response. I also proposed to help them with securing the module and that we are always available for questions and support! I don't think that it is required to publish these e-mails but there was contact before I created this blog entry.

Also, I got several replies from Dries concerning this issue, he was very helpful and he understood the impact of the problem.
Pieter Verhaeghe Says:
Wednesday, March 03, 2010It is indeed not very simple to have a good and secure eID implementation in a web application. This eID module for Drupal is not the only online eID authentication implementation that has security flaws!
As I commented yesterday on the DataNews website ( http://datanews.rnews.be/nl/90-7-28733/article.html ), the guidelines for eID authentication are not always very clear. For the moment, two methods that are mainly used to do online authentication with the eID are client-side SSL authentication and authentication with a Java applet ( http://code.google.com/p/eid-applet ). The problem is that a malicious applet can have a large impact on all existing web applications with eID authentication. The reason for this is the PIN caching or Single Sign-On feature on the eID chip for authentication. After a successful authentication, the private key on the chip remains active as long as no logout command is sent to the chip and the card remains inserted in the card reader. A malicious applet can abuse this feature by imitating a normal authentication applet towards the user. After the normal authentication, the applet knows that the private key is still active on the chip and now it can setup new connections to other eID web applications and log in on those applications without user's consent (because the PIN code is not asked for these additional authentications). Moreover, all current web applications that use eID authentication (either HTTPS or applet authentication) cannot distantiate between a malicious applet or a real user that logs in.

Because the government doesn't regulate the authentication protocol at the moment, each developer is free to use his own authentication mechanism. Moreover, as more and more eID applications will use different authentication techniques, users don't know which mechanisms they can trust and which aren't save (anymore). In the end, users won't trust the eID at all, as some of you here apparently already do ;)
Erwin Says:
Monday, March 08, 2010To follow up on this discussion, I've talked with LSEC about the remarks and comments and we will try to start an initiative to tackle the problems discussed.