Last week a reporter asked me to comment on a story he was writing that detailed this hack. I couldn't post this to Memestreams until after that article was published.

I plug in the register URL and start inserting my information. The second screen is where your Priority Code gets entered. Being the curious person I am I took a peek at the source code. Much to my chagrin I find this:

Well huh. These look like MD5 hashes. So what we need to do is crack the MD5 passwords with what we know about our keyspace: All upper case, most likely keyboard ASCII characters and numbers only. We can probably rule out non-printable ASCII so now we're just looking at A-Z0-9. Just an educated guess.

We begin the crack. Less than 10 seconds and I've already cracked a code that looks interesting. Lets see what we get: A Platinum Pass for $0.00? Special line access to the Keynote! Alright!

My thoughts are this is an excellent example of security issues with Web 2.0 applications. Specifically, the leaking of an application's programing logic to the attacker.

In the case, IDG tried to make their website more responsive by performing some of their validation on the client. They did this by pushing some JavaScript to the client's web browser. Even if IDG still performed that validation on the server, they have leaked how the priority code is verified and used by their website. This is the leaking of control logic All an attacker needs to do is look at the JavaScript code and see how the priority code is verified against a list of valid codes. Even though those codes are encrypted, the JavaScript again aids the attacker. It provides step by step instructions showing how the priority code is encrypted as well as the algorithm used allowing the attacker to easily brute force the valid codes. By accessing the JavaScript code, the attacker could also see that IDG made some mistakes before they encrypted the code, making the discounts even easily to brute force (IDG first capitalized the code and the removed a number of special characters and symbols, etc). This drastically reduced the number of combinations an attacker needs to try to brute force all the priority codes)

Once the attacker knows all the priority codes, it is obvious which ones gave the attacker a free pass worth thousands of dollars.

The moral of the story: JavaScript code is visible to an attacker. It is impossible to completely obfuscate or hide it. More and more Web 2.0 technologies like Ajax means more and more programs are placing application logic in JavaScript, making it even easy to attackers to find flaws in web applications. In this case, by trying to enrich the user's experience, the programmers exposed all of there discount offers in JavaScript, allowing an attacker to discovery them and perform fraud for thousands of dollars.

Web developer's need to make sure they don't leak vital information about how their applications work. In today's Web 2.0 world of rich web interfaces like Ajax and Adobe's Flex, this is a very easy mistake to make.

This is a great example of information leakage in "Web 2.0" applications. Acidus comments:

Last week a reporter asked me to comment on a story he was writing that detailed this hack. I couldn't post this to Memestreams until after that article was published.

I plug in the register URL and start inserting my information. The second screen is where your Priority Code gets entered. Being the curious person I am I took a peek at the source code. Much to my chagrin I find this:

Well huh. These look like MD5 hashes. So what we need to do is crack the MD5 passwords with what we know about our keyspace: All upper case, most likely keyboard ASCII characters and numbers only. We can probably rule out non-printable ASCII so now we're just looking at A-Z0-9. Just an educated guess.

We begin the crack. Less than 10 seconds and I've already cracked a code that looks interesting. Lets see what we get: A Platinum Pass for $0.00? Special line access to the Keynote! Alright!

My thoughts are this is an excellent example of security issues with Web 2.0 applications. Specifically, the leaking of an application's programing logic to the attacker.

In the case, IDG tried to make their website more responsive by performing some of their validation on the client. They did this by pushing some JavaScript to the client's web browser. Even if IDG still performed that validation on the server, they have leaked how the priority code is verified and used by their website. This is the leaking of control logic All an attacker needs to do is look at the JavaScript code and see how the priority code is verified against a list of valid codes. Even though those codes are encrypted, the JavaScript again aids the attacker. It provides step by step instructions showing how the priority code is encrypted as well as the algorithm used allowing the attacker to easily brute force the valid codes. By accessing the JavaScript code, the attacker could also see that IDG made some mistakes before they encrypted the code, making the discounts even easily to brute force (IDG first capitalized the code and the removed a number of special characters and symbols, etc). This drastically reduced the number of combinations an attacker needs to try to brute force all the priority codes)

Once the attacker knows all the priority codes, it is obvious which ones gave the attacker a free pass worth thousands of dollars.

The moral of the story: JavaScript code is visible to an attacker. It is impossible to completely obfuscate or hide it. More and more Web 2.0 technologies like Ajax means more and more programs are placing application logic in JavaScript, making it even easy to attackers to find flaws in web applications. In this case, by trying to enrich the user's experience, the programmers exposed all of there discount offers in JavaScript, allowing an attacker to discovery them and perform fraud for thousands of dollars.

Web developer's need to make sure they don't leak vital information about how their applications work. In today's Web 2.0 world of rich web interfaces like Ajax and Adobe's Flex, this is a very easy mistake to make.