Why Friends Don’t Let Friends Run Windows: Mystery Banking DLL

So I signed into the credit union’s online banking site, did the multi-factor authentication dance, and was confronted with this dialog box…

HVFCU Mystery DLL Download
HVFCU Mystery DLL Download

No, as a matter of fact, I did not choose to open ibank.dll, thank you very much for asking.

Well, what would you do?

Got this response from the credit union’s email help desk:

Upon speaking to out Information Technology department, I have been advised that this is a known problem for FireFox, Mac, and Linux users.

Hmmm, well now, Internet Explorer is conspicuous by its absence on that list, isn’t it?

A bit more prodding produced this response:

HVFCU uses a third party vendor to provide the Internet Banking software used on our servers.  On November 22 we installed the equivalent of their year end release (which is mandatory due to regulatory changes contained in the release).  Subsequent to that upgrade we discovered that errors had been introduced for Mac and/or Linux users of Safari and FireFox (and also for a small subset of Windows Internet Explorer users).  These same errors do not occur on Safari nor FireFox running on Windows.  We reported these problems to our vendor within 24 hours of the installation.

My guess is that the “small subset of Windows Internet Explorer users” corresponds to the few who actually armored-up their IE security settings enough that it doesn’t automatically download and execute anything offered to it from any website.

The rest, well, those PCs are most likely part of a zombie botnet.

He assured me:

The “ibank.dll” program cannot run on a Mac nor a PC.  It is solely a server side application which generates HTML pages.

Just guessing here, but if the “misconfiguration” had extended to actually serving the file, well, it probably would have run just fine (or, at least, attempted to run) on any Windows PC. They are, after all, using DLLs on the server, so it’s not like they’re a Unix-based shop.

And it’s pretty obvious that their vendor’s testing extended only far enough to verify that the code worked with security settings dialed to “Root me!” Maybe they didn’t actually do any testing at all; this was, after all, just an end-of-year update. What could possibly go wrong?

If you’re wondering why your Windows-based PC has been behaving oddly, maybe you’ve gotten a drive-by download from a trustworthy site with all the appropriate icons on their home page.

Makes you really trust the banking system, doesn’t it?

Or maybe it’s just another reason to stop using Windows…

11 thoughts on “Why Friends Don’t Let Friends Run Windows: Mystery Banking DLL

  1. “The “ibank.dll” program cannot run on a Mac nor a PC. It is solely a server side application which generates HTML pages.”
    This is correct. It’s a harmless MIME type configuration error. Much like you might have seen when a web address ending in e.g. .php attempts to download a file instead of rendering the HTML. If you save and open the ibank.dll file in a text editor I bet you will see HTML.

    “Just guessing here, but if the “misconfiguration” had extended to actually serving the file, well, it probably would have run just fine (or, at least, attempted to run) on any Windows PC. They are, after all, using DLLs on the server, so it’s not like they’re a Unix-based shop.”
    You’re guessing wrong :) DLLs are not executable files. They contain library code that doesn’t have a main function, so it can’t be directly executed.

    There are certainly security flaws in Windows and IE, but this was not one. Windows and IE have both improved dramatically in the past few years and should be given due credit for that. BTW, I have no conflict of interest – I run Chrome on OSX.

    1. Well, let’s put it this way: the Credit Union gave me the opportunity to download an executable file without prearrangement. The only information I get is that they think it’s a good idea. Everything else comes after I decide more research is indicated…

      In this particular situation, they screwed up and didn’t actually have a file to download. That’s not the expected outcome; the misconfiguration could have been much worse.

      Or it could be a compromised system; there’s no reason to believe the Credit Union’s servers are more trustworthy than any others. The “misconfiguration” could well be an attack they just haven’t noticed yet.

      DLLs are not executable files

      DLLs contain routines that will be called by another program at some point, so they meet a simple definition of “executable” code.

      That DLLs do not, in general, run directly is irrelevant… as witness the number of malware attacks spread through DLL downloads.

      Windows and IE have both improved dramatically in the past few years

      From a fairly low base; it’s still far too simple to bring a Windows box to its knees.

      Part of the problem is the huge installed base of utterly vulnerable Windows boxes; the botnets are just stuffed with low-hanging fruit. Vista and WIn 7 are much better, but they don’t have much representation yet.

    1. Hadn’t noticed the captcha recycling, but now that you mention it, there’s exactly one background image with a few variable-position horizontal and vertical black lines. I think a dab of ImageMagick could take care of that…

      However, it does seem they’re not doing client-side SQL injection inspection, detection, and rejection these days… must’a been one of those upgrades!

  2. It’s a difficult problem for banks: hire their own coders and then try to produce comparatively secure code, or trust a software provider for purchase of that code. Who knows what the software provider actually is doing in that code (if they, indeed, wrote it, or if they subcontracted it out.)
    The problem isn’t even solved by just banking in person, these days, since they’re also running someone else’s software internally. Bah. The office of the comptroller of currency (as I understand it) is supposed to not let banks run untested software that moves money around, but that doesn’t do much to protect people against applications that aren’t critical (and aren’t tested) but have access to account information that would give nogoodniks access to accounts.
    That doesn’t even address dns cache poisoning or other nasty client/network-side shenanigans entirely outside the banks’ control or knowledge.
    It’s going to be an interesting ten years…

    1. or if they subcontracted it out

      Which is, of course, something that’s only recently begun to worry institutions: did they pay to have a subcontractor install a back door in their enterprise-critical code?

      I know which way I’d bet… not always, but often enough to make a difference.

      Worst part: they’ll never know until it’s much too late.

      1. From a strictly capitalist viewpoint, if you stand to make more installing a backdoor than you’ll lose by bad publicity surrounding it, the right decision is to go ahead and put on the black hat, particularly when the company you’re screwing isn’t going to want any publicity since it’ll hurt them too.

  3. That doesn’t even address dns cache poisoning or other nasty client/network-side shenanigans entirely outside the banks’ control or knowledge.
    It’s going to be an interesting ten years…

    1. The part that’s really amusing is that banks & credit card companies still send out emails with clickable links… and then wonder why so many of their customers have compromised machines.

Comments are closed.