Archive for September, 2011

Security advisory:

Thursday, September 29th, 2011

Discovered by: Niklas Femerstrand (qnrq)

Overview is an API developed by the legislative assembly of Sweden.

A vulnerability exists in the generation of XML data where data values of the output are affected by parameters in the URL. Hexadecimal values are improperly validated leaving the software vulnerable to parameter and JavaScript injections and XML external entity attacks. A successful XXE attack grants an unauthorized attacker read permissions with privilege escalation possibilities and various services on the web server risk becoming compromised.

Proof of concept
Test parameter injection:

Disclosure timeline
2011-09-27 Notified web section director (Anna Olderius)
2011-09-28 Received response
2011-09-28 Issues resolved
2011-09-29 Public release

FortiGate censorship analysis

Monday, September 12th, 2011

The S23K, also known as the Pirate Bay tour bus, had boarded a Scandlines ferry from Trelleborg. We were a group of pirates and hackers on our way to Chaos Communication Camp 2011 in Finowfurt, Germany. There was free satellite WiFi available on board, and after a while me and my friend jaywalk of Telecomix discovered that one of the project’s home domains,, had been blocked for being a “malicious website”. With approximately an hour left from reaching Germany we found this to be a perfect opportunity to warm up.

The blockade of, filtered as a “Malicious Website” most likely triggered by the occurance of the word “anarchy” in the domain, was quickly evaded by accessing the site using HTTPS. SNI (Server Name Indication) was ignored. We found that was blocked on IP level and so was

We found that blockades on the IP level were forwarded to port 8008 on the FortiGate gateway. Accessing the gateway directly gives a login prompt for disabling filters.

If you’re interested, their 756 page system manual is publicly available for download. If you read between the lines you’ll be able to extract information on how to work around their censorship or even disable it completely. :-)

FortiGate categories

  • Abortion
  • Abused Drugs
  • Adult Materials
  • Advertisements
  • Advocacy Groups
  • Alcohol and Tobacco
  • Arts and Entertainment
  • Brokerage and Trading
  • Business and Economy
  • Computer Security
  • Cult or Occult
  • Cultural Institutions
  • Dynamic Content
  • Education
  • File Sharing and Storage
  • Financial Data and Services
  • Freeware and Software
  • Download
  • Gambling
  • Games
  • Gay or Lesbian or Bisexual Interest
  • Government and Legal Organizations
  • Hacking
  • Health
  • Illegal or Questionable Information
  • Technology
  • Internet Communication
  • Job Search
  • Malicious Web Sites
  • Medicine
  • Militancy and Extremist
  • Military Organizations
  • Miscellaneous
  • News and Media
  • Nudity
  • Pay to Surf
  • Personals and Dating
  • Political Organizations
  • Pornography
  • Racism or Hate
  • Reference Materials
  • Religion
  • Search Engines and Portals
  • Shopping and Auction
  • Social Organizations
  • Society and Lifestyles
  • Special Events
  • Sports
  • Spyware
  • Streaming Media
  • Tasteless
  • Travel
  • Vehicles
  • Violence
  • Weapons
  • Web Hosting
  • Web-based Email

FortiGate classification levels

  • Unclassified
  • Cached Content
  • Multimedia
  • Search
  • Image Search
  • Audio Search
  • Video Search
  • Spam URL
  • Personal Privacy

Erroneous cryptography usage in reCAPTCHA API

Friday, September 2nd, 2011

As a developer you’ll definitely stumble upon a lot of ugly code, and sometimes some snippets are just plain “wtf?”. I found this one by an accident a couple of months ago while browsing through the reCAPTCHA API library developed by Google. First, let’s take a quick look at the PHP manual for a libmcrypt introduced function called mcrypt_encrypt():

string mcrypt_encrypt ( string $cipher , string $key , string $data , string $mode [, string $iv ] )

reCAPTCHA offers a way to only display email addresses to users that solve a CAPTCHA (catchy, huh?) called Mailhide. The Mailhide part of recaptchalib declares a function called _recaptcha_aes_encrypt() and it is declared as below:

function _recaptcha_aes_encrypt($val,$ky) {
        if (! function_exists ("mcrypt_encrypt")) {
                die ("To use reCAPTCHA Mailhide, you need to have the mcrypt php module installed.");
        return mcrypt_encrypt($enc, $ky, $val, $mode, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0");

As you can see, the initialization vector (the last parameter of mcrypt_encrypt()) used is statically defined as a nullbyte string. If you’ve studied cryptography to some extent you probably know that the entire purpose of the initialization vector is to ensure that the same data encrypted with the same key outputs different ciphertext, just like the purpose of a password salt is to generate different hashes for equal password strings in authentication.

By using the \0 IV string Google simply silences a warning which PHP would generate if mcrypt_encrypt() would be called using Rijndael in CBC mode without a specified IV, thus it is possible that the used IV is nothing but a fix of this warning. However, using a static nonrandom IV makes the algorithm susceptible to dictionary attacks. _recaptcha_aes_encrypt() may not be a very important part of the reCAPTCHA API to keep secure, but a very easy solution to this would be to use another block cipher mode which does not require an initialization vector.