Kindergarten-Level Computer Security

If you’ve ever been exploring the Web and manually altered part of the URL in your browser’s address bar—say, to access a different folder on Flickr, or a different friend’s profile on Facebook—you’ve performed the simple technique that hackers recently used to compromise more than 360,000 bank accounts from Citigroup.

This spring, according to the New York Times, hackers with legitimate Citi credit card accounts logged in to the website and noticed that the URLs displayed data unique to each account. By changing a few digits in the URL, the hackers found themselves inside other people’s accounts without ever having to log in as those people. From there, they used custom software to automatically substitute account numbers, enabling them to access many accounts in a short time, the Times reported. (Citigroup declined to comment beyond a statement acknowledging that the hackers obtained names, account numbers, e-mail addresses, and transaction histories.)

Bruce Schneier, chief technologist for the telecommunications company BT, says that preventing the URL from displaying account-specific information is “kindergarten security.” Security researcher L. Jean Camp of Indiana University agrees that the hack was remarkably simple. “Can you believe it?” she says.

Which raises a question: How could a sophisticated financial institution—one that has been hacked before—let something like this happen? Essentially, it built a vault of solid steel and used balsa wood for the door.

Balkanization inside Citigroup may have played a part. Large organizations, Camp says, usually have separate groups for customer service and network security. In a typical company, employees know that certain tasks must always go through certain departments—all personnel changes through Human Resources, for instance. But such a “gatekeeping” role does not always exist for security. This means that a customer service group might design a Web page for credit card holders without necessarily running it past security first. Camp has consulted with at least one major company in which the user interface team said, regarding its design, “If we add security, we’ll break it.” Security is usually called in only in response to a threat or breach, Camp notes.

Chris Novak, managing principal of Verizon’s security branch, which consults with businesses about intrusion prevention, says security oversights often result from an us-or-them approach. In other words, many organizations assume that employees and other insiders can be trusted, so they focus on defending against outside threats. But in designing their systems with these two groups in mind, they often overlook a third group: those who are “not an unknown but not an employee.” That’s essentially what happened in the Citi heist, when the hackers were never faced with the defenses meant for complete outsiders. It’s as if the company assumed that bank robbers don’t have bank accounts.

Novak says that when organizations are shown the vulnerabilities these users-but-not-employees can exploit, their first response is usually, “Well, why would a user do that?” Furthermore, he adds, a lot of large organizations “have a mind-set that they don’t have small problems.” They end up worried about “Mission: Impossible situations,” he says, but the vast majority of attacks are “opportunistic.”

Schneier suggests a more calculating explanation for Citi’s lack of proper defenses. Maybe the bank didn’t spend the money on good security because it figured that it would be cheaper and simpler to reimburse its customers for any fraudulent charges, he says.

Whatever the reason, these basic security weaknesses are more common than you might expect, Novak says. Faults similar to Citigroup’s show up each year in Verizon’s Data Breach Investigation Report, an analysis of hundreds of intrusions. In the 2011 report, for instance, only 18 percent of the cases Verizon investigated resulted from hacks of “high” difficulty—requiring “advanced skills.”