Attacks/Breaches
1/10/2013
12:22 PM
Connect Directly
RSS
E-Mail
50%
50%

Bank Attacker Iran Ties Questioned By Security Pros

U.S. government officials continue to blame Iran for launching attacks against U.S. banks, but some information security experts see only circumstantial evidence.

If Iran is masterminding the online attacks against U.S. banks, where's the hard evidence?

Numerous current and former U.S. officials have accused the Iranian government of sponsoring the distributed denial-of-service (DDoS) attacks, which began in September and recently restarted. For four months, the attacks have disrupted the websites of many of the United States' leading financial institutions, including Bank of America, Citigroup, JPMorgan Chase and Wells Fargo.

Shortly after the first wave of attacks began, U.S. officials began blaming Iran, and have continued to do so. "There is no doubt within the U.S. government that Iran is behind these attacks," James A. Lewis, who's a former official at the State and Commerce Departments, told the The New York Times.

Officials have also noted that the attacks are so sophisticated and unstoppable that only a nation state could have launched them. Others have said that the attackers have pursued disruption, rather than personal enrichment, which further suggests nation state involvement. But to date, government officials have produced no evidence that links Iran to the attacks.

[ Hackers have infiltrated U.S. networks, say government officials. Read DOD: Hackers Breached U.S. Critical Infrastructure Control Systems. ]

Many information security experts, however, see no irrefutable signs of Iranian involvement. "You can tell that it was planned and executed pretty well," said Carl Herberger, VP of security solutions at Radware, which has been investigating the attacks on behalf of its customers.

But Herberger noted that project management skills aren't evidence of Iranian backing. "The best way I can probably say this is we've seen no irrefutable evidence that it's a single nation state or single actor that's participating in the attacks," he said. "There's nothing we've seen that can't be perpetrated by a small amount of knowledgeable individuals, whether they be associated with a nation state or otherwise."

What is clear is that the attacks aren't the work of amateurs. "The attacks have a couple of attributes attached to them which lead people to believe they're a little more professional," he said. "Some of the attacks are very well organized, choreographed and obfuscated. They have nice cloaking mechanisms, including the ability to masquerade the origin of the command-and-control infrastructure. ... There's clearly a management effort, and there are some beautifully designed tools able to perpetrate this attack."

But while the attack tools are effective, they aren't necessarily the product of an advanced cyber-weapons laboratory. "The tool being used isn't particularly impressive, based on what our 'threat hunter' tells me. But then, if it works, it works -- so why invest more resources into it?" said Sean Sullivan, security advisor at F-Secure Labs, via email. "The simple nature of the tool, though, causes me to read the analysis [suggesting state sponsorship] with a heavy grain of salt."

What of the fact that the bank attackers have managed to compromise servers at data centers, thus unleashing high-volume DDoS attacks that have reached sustained packet floods of 70 Gbps?

"The numbers are impressive, and there does appear to be good coordination, but that doesn't necessarily mean 'state-sponsored,' at least in the sense that a state agency is responsible," said Sullivan. "It could very well be useful idiots which receive funding somehow, or else are acting on their own, but with the passive approval of a nation state."

"A 70-gpbs attack against banks is trivially easy for any individual," said Robert David Graham, head of Errata Security, in a blog post. "What's new with this attack is that it doesn't come from a botnet of thousands of machines, but from a few data centers. This is an easy attack. Data centers have 10 gbps+ connections to the Internet and hundreds of vulnerable servers. Just run nmap or Nessus or any hacking tool targeting the data center, and you'll compromise several servers to run your attacks from."

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5619
Published: 2014-09-29
The Sleuth Kit (TSK) 4.0.1 does not properly handle "." (dotfile) file system entries in FAT file systems and other file systems for which . is not a reserved name, which allows local users to hide activities it more difficult to conduct forensics activities, as demonstrated by Flame.

CVE-2012-5621
Published: 2014-09-29
lib/engine/components/opal/opal-call.cpp in ekiga before 4.0.0 allows remote attackers to cause a denial of service (crash) via an OPAL connection with a party name that contains invalid UTF-8 strings.

CVE-2012-6107
Published: 2014-09-29
Apache Axis2/C does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2012-6110
Published: 2014-09-29
bcron-exec in bcron before 0.10 does not close file descriptors associated with temporary files when running a cron job, which allows local users to modify job files and send spam messages by accessing an open file descriptor.

CVE-2013-1874
Published: 2014-09-29
Untrusted search path vulnerability in csi in Chicken before 4.8.2 allows local users to execute arbitrary code via a Trojan horse .csirc in the current working directory.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.