A new competition

Via terminal23.net: the Python challenge (this does not have any deadlines, nor does it carry prizes, so you can relax).

Hostile JS Debug

I was looking through a presentation delivered by a McAfee employee during an Indian security conference (Club Hack 2007) and there it was: a reference to a little project of mine dedicated to ease the debugging of obfuscated javascript. Neat. (Or, I could use the the word of the year and say: w00t :-)

2008 Scripting games

Via the terminal23 blog: the Microsoft 2008 Winter Scripting Games. Also with Perl for extra fun :-)

Sunbelt is using Symantec in-house

This is quite old (it has been sitting in my to-do list for a while) but still fun:

What can screenshots reveal about your company? This blog posting from the Sunbelt blog from Friday, November 16, 2007 entitled Some new twists in the Storm worm contains the screenshot which can be seen below with the obfuscated javascript code:

When I looked at the screenshot I saw the peculiar structure towards the top of the page (the first "script" block) and did some searching around. It turns out that this structure is added by ad-blocking code present in some Symantec products as documented on their website. This means that probably whoever made the screenshot at Sunbelt was using Symantec's AV on their system. Interesting to know :-).

VNC - (almost) zero security

I mentioned it previously, but just wanted to be sure that everyone has seen this:

• the "standard" VNC protocol does not offer any encryption of the data (ie. using a packet capture you can reconstruct the screen content and the action of the user). There are unofficial extensions, but they are not widely supported
• During "authentication" only the first 8 characters are considered (which makes it quite easy to brute-force)

What you should do:

• tunnel all VNC traffic through something with a stronger encryption (like SSH or VPN)
• make sure that the VNC server is never bound to Internet facing interfaces (only to VPN interfaces or localhost accessed through a SSH tunnel)
• not use VNC at all :-)

Tangled Web

The World Wide Web has become the main target for much of the computer usage these days. This has several consequences, one of which is that more economic value is placed in it, attracting more attacks. XSS, CSRF, RIF and so on. These are all terms which are used daily by the security research community. What I realized today (yes, I'm slow :)) is that these problems are amplified by every browser plugin out there (Flash, Java, QuickTime, etc).

These plugins are deeply integrated into the browsers in both ways: browsers can instantiate these plugin objects and set their parameters (either via HTML or via scripting) and in turn the plugins can set browser parameters (page location, manipulating the DOM, etc). This means that the vulnerabilities can exists inside of the files destined for these plugins and/or such files can be used to hide the exploitation.

This all hit me when I've read XSS Vulnerabilities in Common Shockwave Flash Files. If the makers of tools can not be trusted to take security into consideration, how can the users of the tools be trusted? And Flash is not the only target by a long shot (remember XSS via PDF? or via links in QuickTime MOV files?) it's just the biggest one. According to a chart on Adobe's site (so it is clearly biased, but the only one I could find), the most widely used browser plugins are the following:

1. Adobe Flash Player
2. Java
3. Windows Media Player
4. QuickTime player
5. Adobe Shockwave player
6. Real player

While there are some elements missing from this list (like the browser integration of the Adobe Acrobat Reader), it is probably the best target list for the following year or so from a web application vulnerability point of view. To protect yourself, you should do the following:

• uninstall the plugins you don't need / use (for example I get pretty well by with Flash only)
• make sure that those plugins are up-to-date. For flash you can visit the About page to make sure that you have the latest version and use the links there to update if it's the case
• use separate browsers for separate purposes (more on this to come)

Faster MD5 collisions

MD5 is looking less and less reliable as the day pass. It seems that now researchers have been able to create an attack that can append a couple thousand bytes to two arbitrarily chosen files which would result in those files having the same MD5 hash, and compute these byte sequences with consumer grade hardware relatively fast (a few days). Via the Symantec blog. However I think that the final statement in the blog post is not correct:

Multiple checksums? Useless if the second algorithm is weaker than the first one (MD5 and CRC32, for example). If the second algorithm is strong, then it is sufficient on its own and the MD5 calculation becomes a waste of time.

This statement would be correct (in my humble opinion) only if the given hashes have the same algorithmic background (for example the MD and SHA family of hashes). However, if you use two hashes which are from two different families (for example one from the SHA-2 family - SHA-224, SHA-256, etc - and WHIRPOOL) odds are that if an attack if found against one, the collisions it generates are not effective against the other and vice-versa. Of course mathematically speaking there will always be collisions, since it isn't possible to create a one-to-one mapping between an larger (possible infinite) set (all possible sequence of bits to be hashed) and a smaller set (the possible hash values), but from a practical point of view we are interested only if we can create these collisions in useful time with chosen starting points.