Simple solutions for simple attacks

Managing the risk of human error is the first step in protecting customers’ sensitive information

By J. Andrew Valentine

In the ongoing battle between the banks and the bad guys over e-commerce security, let’s take a step back. Forget multi-factor authentication for a moment. Forget security tokens. Forget biometrics. Let’s take a minute to talk about single-factor authentication. Let’s talk about using authentication mechanisms at all. 

During the summer of 2006, a systems administrator in a mid-size bank (that you may or may not have heard of) noticed something peculiar. Routine analysis of site access logs showed that none of the bank’s customers had logged into its online banking system in more than 48 hours. Not a single one. This is a portal that normally services thousands of customers everyday. People login to check their finances, pay bills and plan investments. Except, for two full days that summer, not a single customer had logged in.  

Under this particular business model, the bank maintained two separate publicly facing websites. The first was a purely informational site (think “www.banking.com”) that maintained generally static content. From this informational site, customers could look up branch locations and associated contact information for the bank’s various branches. To access the other website, the one that offered e-commerce and personal banking functionality, users had to click on a hyperlink located in the upper right-hand corner of the site. Clicking on this link would transfer customers to another website (think “www.bankingonline.com”), where they were prompted to enter their account number and password to access their personal accounts.

One bank, two websites. One purely for information, the other purely for e-commerce.

And even though the information portal was showing normal traffic patterns, no one had visited the e-commerce site for more than two days. The systems administrator began to realise there was a potentially huge problem. 

So the systems administrator opened a browser and went to “www.banking.com”, the bank’s informational site. On hovering over the Online banking hyperlink, however, he realised it connected to a foreign website, based in Turkey, instead of “www.bankingonline.com”.

Customers were being routed from the bank’s legitimate informational site to a fraudulent site in Turkey. Once there, they provided account login information, passwords and other personally identifiable information to the bad guys. 

All told, more than several hundred customers clicked on the fraudulent link and provided information over the 48-hour period. 

This is how the bad guys did it. 

The bank in question maintained a web-based content management site to manage its informational web presence. To access that administrative site, internal web developers would use a browser to navigate to “www.banking.com/editcontent.asp” and provide a unique username and password. 

However, investigators noticed the existence of a second, but very similar, looking page also on the web server: “www.banking.com/editcontentDEV.asp”. This was a developmental page built before the site went into production mode. 

The DEV page retained all of the same administrative functionality as the normal “Edit Content” page, but with one important difference: it did not require a user to authenticate with legitimate credentials. One needed only visit the webpage to be granted access to edit any and all content on the informational site. Essentially, all a malicious intruder truly needed was the knowledge that “www.banking.com/editcontentDEV.asp” existed at all! 

The bad guys didn’t have direct access to alter the e-commerce site, but they didn’t need it.

After the intruders found out the “open” administrative page existed for the informational site, they set up the fraudulent phishing site in Turkey, logged into “www.banking.com/editcontentDEV.asp” and simply changed the hyperlink away from “www.bankingonline.com” to the Turkish site.

It was that simple. 

The problem inherent within this scenario is not particularly technical in nature, but rather involves the lack of a fully mature testing and development process. The vulnerability here is administrative. There was no legitimate reason that a development page should have been left on a full production server, but no one knew to look for it, and it wasn’t included in normal and routine auditing policy.  

In the last 18 months, I have seen this very same “hack” take place in more banking, financial and government institutions than most people would care to know. Often times, these web-based content management tools exist without any degree of security authentication at all. Usually, the bad guys are able to walk right in the door and take the information they need without setting up complicated phishing schemes. 

In case after case, intruders are able to access sensitive systems and data because unprotected “development” content exists in the public space. Usually, this is unprotected content that no one in the organisation knows even exists. 

In a security environment, where the majority of businesses and organisations are moving towards strong multi-factor authentication it is staggering how much sensitive content exists in the public space that doesn’t have even single-factor protection. 

The bottom line is that all organisations that deal with sensitive information should routinely inventory all of their publicly facing content. Within any information systems environment, human error is inevitable (to err is human, after all). Properly configured and implemented policy and procedural guidelines, in this case around testing and development, will greatly reduce the risk of human error.

J. Andrew Valentine is a security consultant in Verizon Business Security Solutions’ Incident Response Unit