Banking on Java

Way back in 2003, South African bank ABSA were in the news after customers had lost money through hacking. Here's a report from 21 July 2003 and another one with more detail. The story was that some uber-hackers robbed ABSA, were caught, and now Internet banking is safe again.

However, check out the detail on Bugbear B from June 2003; an in-the-wild malware that was noted to steal information from a number of banking domains in several different countries, including South Africa. Was there one uber-hacker attacking ABSA, or multiple tiny hacks by folks who figured out how to make use of Bugbear B?

The South African banking industry responded to the ABSA debacle by boasting new improvements in security, implying that what happened to ABSA would never happen at their bank. These improvements included on-screen mouse-driven number pad to avoid keylogging, and free (but UI-less and thus uncontrollable) MyCIO antivirus and firewall from McAfee.

At this point, the article you are reading is going to jump around seemingly-unrelated topics. Have faith; it will all come together at the end...

Microsoft Java

Sun sued Microsoft over the MS Java VM that was included in Windows and Internet Explorer, as Microsoft's Windows-specific extensions broke the "write once, run anywhere" goal of cross-platform usability. Sun contended that developers attracted to MS Java would be locked into Windows by these extensions.

Recently, I cleaned up an XP SP2 system that included Java malware, and which was running the old MS Java VM. I found instructions on removing MS Java, and the steps looked like those that should be done automatically by an uninstaller - if Microsoft had followed their own advice to developers and provided one for MS Java.

Not only did Microsoft provide no Add/Remove entry for the MS Java VM, but running one of the manual steps to remove it popped up a dialog box with the odd warning that "Internet Explorer will no longer be able to download from the World Wide Web". Now I can understand Java applets not working or pages being unable to display as the site intended, but not being able to do standard downloads? Smells like a smoking gun to me...

Sun Java

By now, most users of Java will be using Sun's Java Runtime Engine (JRE) instead of Microsoft's Java Virtual Machine (VM). We've also become accustomed to the need to fix code defects by updating subsystems such as Java, applying code patches, and so on.

A long-standing bone of contention with Sun has been that when you install a new JRE, the old one remains in place - and we suspected this old and vulnerable code could be used and thus exploited by java malware. We bitched about this all the way from 1.4.xx through 1.5.xx, and yet Sun just carried on installing new JREs while leaving old ones (at 100-150M apiece) in place.

It seemed that unlike Microsoft, Sun just didn't "get" what patching was all about. They seemed to think we downloaded and installed new JREs because we wanted kewl new features, and kept the old ones around for backward compatibility - whereas what we really want to do is smash this "backward compatibility" so that malware could not exploit flaws in the old versions.

Finally, Sun came clean and admitted what we'd always suspected; that a Java applet could specify which version of JRE it would like to be interpreted by, and the current version would obligingly hand off to the applet's JRE of choice.

Java malware

The first known Java virus was written in 1998, and detected as StrangeBrew. Since then, Java has been attacked and exploited in various ways, and both Microsoft and old Sun Java JREs are considered to be hi-risk exploitable surfaces. By now, Java malware abounds, and indeed there was such malware on the system I recently cleaned up. The beat goes on.

Note the dates involved in some of the above links, e.g. Sun JRE 1.4.2.xx was found to be exploitable way back in 2004 (the "Sun" link above) - as well as the versions that are vulnerable, such as 1.4.2_04.

Internet Banking in 2006

After cleaning up the system, I uninstalled MS Java VM, checked that no old Sun JREs were present, and installed Sun JRE 1.5.008 as the only Java engine on the system. After a while I had a call to say that Internet Banking wasn't working anymore.

Indeed, it wasn't working, so I called the bank's tech support, explained the system's history and why the MS Java VM had been removed, and they gave me a link to download a fix. The fix turned out to install the MS Java VM again, which I disallowed.

I called back to ask about an update that would work with current Sun Java, and they said yes, the newest version of the software no longer needs MS Java. I was a bit puzzled to hear it took them this long to switch, given that MS Java was pulled from XP in the days of SP1a, and SP1 is now so old that it's about to lose all further testing and patching, with SP2 as the new baseline.

So we rushed off to the city to collect an installation CD for their newest software, as it is not available as a download. This also did not work, and after another tech call, it turns out that this newest software does not support any Sun Java JRE beyond 1.5.005, so I was advised to fall back to that from the 1.5.008 that I was using.

I noticed that the new banking software installed Sun JRE 1.4.2_03, which is ancient and has been vulnerable to attack since 2004 at least. I uninstalled that old JRE when the banking software had finished installing, and after shutting down and restarting Windows, I tried the new banking software, which again failed to work.

After a bit of technical discussion, it turns out that the new banking software's real JRE threshold is in fact 1.4.2_03, and the only reason it "works" up to 1.5.005 is because it relies on these newer JREs to pass control back to 1.4.2_03.

This is really quite nasty, because users will think they are protected against Java exploits because they installed the latest JRE, while in fact the banking software is undermining this safety by slipstreaming in an old exploitable JRE. It makes a mockery of banking's usual assertion that they do their best to maintain security, but are let down by users who fail to keep their PCs safe and clean. There's something odd in being forced to accept an exploitability risk in order to use security-orientated software.

I haven't named the bank in question (it's not ABSA this time), because they are the only bank I've had reason to check out. For all I know, most or all of our local banks may be just as negligent, so it would be unfair to single out this one just because I found out about them first!