The Recurity Lablog

When people announce that they have found a vulnerability in something that should be really secure, it should always trigger interest with reservations. Yesterday, a contracting consultant currently working for us announced that he identified a bug in the reference implementation of the Twofish crypto cipher. While this would not have been the first time in our halls that an issue in a cryptographic reference implementation was identified, it astonished me.

At first sight, the code he showed did indeed look like a variable initialization was missing:

DWORD RS_MDS_Encode(DWORD k0,DWORD k1)
	{
	int i,j;
	DWORD r;

	for (i=r=0;i<2;i++)
		{
		r ^= (i) ? k0 : k1;			/* merge in 32 more key bits */
		for (j=0;j<4;j++)			/* shift one byte at a time */
			RS_rem(r);				
		}
	return r;
	}

The initialization of the variable r wasn't really obvious and I missed it too. Frankly, my annoyance was significant since we are currently helping a customer to design a security protocol with Twofish being one of the cornerstones, due to the cipher's strength and conservative design. And we went to great lengths to get it right, getting a cryptographer on board for the project and verifying everything over and over again. The prospect of looking at a broken reference implementation wasn't really what I wanted to hear.

After reviewing the code today, it quickly became obvious that there was no bug in the function; it initializes r when entering the loop. But, while looking at the reference implementation, I noticed the following comment at the beginning of the file:

Notes:
		*	Pedagogical version (non-optimized)
		*	Tab size is set to 4 characters in this file

While browsing the source code, I immediately stumbled over a few lines such as:

/* works for big and little endian! */
d[i/8] |= b << (4*((i^1)&7));		

outBuffer[n/8] = (outBuffer[n/8] & ~ bit) | 
                 (ctBit ^ ((((BYTE *) x)[0] & 0x80) >> (n&7)));

And I have to say: with all due respect, this is everything but pedagogical code. What is the point of presenting the pedagogical reference implementation of a cryptographic algorithm in a language such as C, where out of bounds array access isn't really noticed and one can write code such as the examples shown above? To teach students that really important code must look like this? If this is not optimized for actual use, why not present the code in a readable form, computing everything one step at a time and preferably in a programming language that doesn't look like a someone rolled an armadillo over his keyboard?

Schneier and Ferguson correctly state in their book "Practical Cryptography" that complexity kills most security systems and that the only known way of handling complexity is to modularize the problem into chunks that the human mind can handle. This advice should be adjusted to read: chunks that an average human mind can handle. I know that many people are proud of their brilliance, rightfully or not, but that's not the point.

Cryptography is fragile and delicate enough by nature. But it is also a very important building block of many security systems. Therefore, many programmers must implement cryptography in their respective programming languages and some of them may not be able to correctly understand either the C gibberish in the reference implementation or the LaTeX special math character party in the official Twofish paper. May be it's just my world view as a consultant, but we always try to explain demanding content as simple as possible while still being correct, which is in fact the real challenge.

A common answer is: If people don't understand it completely, they should not implement crypto. This seems simple enough, but the number of people in the world who do not fall under this rule is too small compared to the amount of software that needs protection. We need security mechanisms most programmers (and auditors) can handle; otherwise we will keep producing insecure software. Not even the most brilliant person can write all his programs himself without the need to trust another, potentially unknown programmer. And the other programmer will, be definition, be less brilliant.

Schneier and Ferguson keep repeating the following important sentence in their book: "We have enough high performance insecure systems, we don't need another one." They are totally right. But with all due respect, please consider this rule yourself next time.

Normally, hackers and vulnerability researchers are accused of irresponsible disclosure, namely the publication of vulnerability information before a fix is available from the vendor of the affected product. The discussions of the dos and don'ts when performing full disclosure and what constitutes responsible or irresponsible behaviour are as old as the idea of public disclosure of vulnerability details itself.

On the 16th of November, Lance James of Secure Science Corporation posted on the SecurityFocus Binary Analysis mailing list and 5 other mailing lists an extensive analysis of a piece of Trojan horse Malware for Windows. The purpose of the Malware was to collect HTTP Post data when certain keywords, such as "bank", "login" or "mail" were matched in the target URL and drop the collected data at some (probably hacked) web server.

The report, written by an anonymous author at Secure Science Corporation and Michael Ligh, explains how the Trojan works and how it encodes and compresses the data collected before dropping it onto the collection sever. Section 11, detailing the encoding and compression, also contains some example material gathered during lab tests and containing only exemplary login data used by Michael Ligh for the testing of the program.

What surprised me was section 12, which detailed that the drop site was changed by an update to the Trojan on October 18 and listed the un-obfuscated IP address of the new drop server. When I saw the authors reporting updates on the drop site at the time of them writing the report and concluding that the site is still very active, we checked it out. Result: It is still alive!!!

Not only did the authors of the report point everyone and their dogs to a live and kicking drop site for stolen banking, email and other accounts but they also detailed how to decode, decompress and interpret the data into a readable and easy to use format. To verify that this is actually the case, we implemented a decoder solely based on the information in the report and tested it with the daily TAR ball of the drop point site from November 17. The TAR ball contains logs from 1196 infected computers, all in all 371 MB of illegally obtained confidential personal data. Our decoder successfully converted the data into readable text format. According to the PHP scripts running on the drop site, it currently maintained 7410 infected machines.

We will assumed in dubio pro reo that Secure Science Corporation tried to contact the hoster or upstream provider of the drop site and simply failed to have the site taken offline due to the contacted party being unreachable or unresponsive. We asked Secure Science Corporation about that and requested taking down the paper and replacing it with a version not disclosing the IP address of the drop site. The only answer was: "many attempts have been made", no comment regarding the paper.

So at the end of the day, we made our own efforts and informed some contacts about the drop site. It is now offline, replaced by a fresh and probably equally insecure Apache installation. May be this happened due to our requests, may be not.

An entertaining side note: A Google search for "FBI computer crime" produces the email address of the FBI National Computer Crime Squad (NCCS) as nccs@fbi.gov. Unfortunately, the address bounces with a "user unknown" SMTP error. Apparently, computer crime has been eradicated in the USA.

The morale of the story: Is the act of publishing illegally obtained information that can only be used to commit a crime itself a criminal act? I don't know. Is it responsible to do so? Certainly not. Irresponsible disclosure is obviously not limited to hackers.

A German proverb is: "Reden ist Silber, Schweigen ist Gold.", which could be translated as "Speaking is silver, silence is golden." It suggests that in most cases, keeping your mouth shut is a lot smarter than blubbering out whatever crosses your mind. Therefore, golden silence is a comparison (in the linguistic sense, as in augmentation) to speaking.

Now, if not speaking were the augmentation of speaking, what would be the antonym of such golden silence? What could be the worst case of mindless babble? The answer smiled at me today from an exhibition advertisement (as in advertising exhibitionism) printed on transparent film. Reading it from both sides was a revealing experience:

... .

Disclaimer: The current temparatures in Berlin do not allow for any straight thinking. Therefore, we have to revert to humor to prevent our brains to from simply stopping operation altogether. Consider this post as the our mental screen saver.