Sestus Data Corporation announced today the discovery of a vulnerability of the Passmark Sitekey login approach at Bank of America that could permit an attacker to remotely lock out thousands of customers from their online banking accounts.

The vulnerability announced today is similar to a "denial of service" attack in that it permits an attacker to remotely "lock out" customers from their online accounts, potentially overwhelming the bank's customer support lines with calls from frustrated customers. Sestus Data also warned that this vulnerability is not unique to Passmark Sitekey or Bank of America, but is a vulnerability of the underlying challenge question / response approach to authentication used at many banks.

In the case of Passmark Sitekey at Bank of America, Sitekey requires customers to enter their account login ID first, before the website has been authenticated to the customer. This process has been highly criticized by the FFIEC for its potential to permit fraudsters to use counterfeit websites to gather legitimate preliminary login IDs for use in future attacks.

Next, Sitekey attempts to locate a "device ID" on the customer’s computer. In the absence of a device ID, however, Sitekey prompts the customer to supply the answers to personal questions, such as "What is your mother’s maiden name". If the customer answers the questions incorrectly, BofA will lock up the account and require the account owner to call customer service to have their account "reset" or released.

Originally designed as a security feature, Sestus Data Corporation reports it appears this "lock out" process can be exploited by malicious hackers to remotely lock out customers from their accounts en-masse, or used by fraudsters in a hybrid lock out/phishing attack to access the actual account.

Sestus Data described three scenarios for this lock out attack but cautioned that many more scenarios are possible:

Dictionary Based (Automated) Attack Scenario

This attack scenario would involve the use of a dictionary database and a simple scripting program. The attacker would first obtain a database of words used as typical login IDs. Such databases are easily obtainable online.

Next, the attacker would write a simple program to supply the information to a waiting browser. Any high-school computer student could probably write such a program and it would certainly not be beyond the capabilities of an experienced webmaster or programmer.

During the attack, the attacker's program would supply words from the database to BofA’s webpage and test for a response. While it is true that the vast majority of the supplied words would likely be invalid, a small statistical percentage will be valid login IDs. Each time a valid login ID is discovered, since Sitekey would detect no device ID from the attacker's computer, it would prompt for personal information to be supplied in response to challenge questions. The attacker's program would then only need to supply random, nonsensical information. After sufficient invalid answers, BofA will lock the account and the attacker would then move on to the next word.

In this attack scenario, a single attacker could theoretically lock up thousands of BofA accounts, overwhelming the bank's support lines with calls from bewildered customers. Bank of America would likely be unaware of an attack being launched because the attacker would be following the same procedures expected of legitimate website users. Only after the customer support lines started to ring excessively would the bank become aware of the attack. If the bank were to attempt to modify Sitekey to detect multiple invalid IDs being tried from the same IP location, the attacker could simply move behind a legitimate proxy server, such as AOL, and continue their attack.

Casual Attack Scenario

In a less sophisticated version of this attack, a casual malicious attacker could simply go to their public library and begin testing random (or stolen) words against BofA's webpage, and then supply invalid answers for every valid ID discovered.

Hybrid (Lock Out/Phishing) Attack Scenario

In a more insidious version of this attack, an attacker could combine this lock out attack with a traditional phishing attack to actually gain access to the customer’s account.

First, the attacker would lure the customers to a phishing website and prompt them to supply their login ID. Since this is precisely the same "first step" initiated on the legitimate BofA website, the customer would suspect nothing at this point and the phishing website would simply redirect the customer to the legitimate website to "try again".

Later, the fraudster would use these gathered login IDs to lock out the customers from their accounts as described above.

Finally, after the accounts were locked, the fraudster would re-contact the customers by telephone or by email, posing as a BofA customer support representative, and inform the customer that their account has been locked for security reasons. They might even invite the customer to confirm this for themselves while they wait. The fraudster would then request the customer verify certain confidential information "before we will unlock your account".

Since the customer would naturally presume that only BofA should be able to affect their actual account, the customer would likely believe the fraudster and provide the requested confidential information. Once obtained, the fraudster could either re-direct the customer to the legitimate customer support line, or, using the stolen information, contact the bank themselves to have the account unlocked. Once unlocked, the fraudster could use the solicited information to access the account.