Entries Tagged "banking"

Page 10 of 19

Pepper Spray–Equipped ATMs

South Africa takes its security seriously. Here’s an ATM that automatically squirts pepper spray into the face of “people tampering with the card slots.”

Sounds cool, but these kinds of things are all about false positives:

But the mechanism backfired in one incident last week when pepper spray was inadvertently inhaled by three technicians who required treatment from paramedics.

Patrick Wadula, spokesman for the Absa bank, which is piloting the scheme, told the Mail & Guardian Online: “During a routine maintenance check at an Absa ATM in Fish Hoek, the pepper spray device was accidentally activated.

“At the time there were no customers using the ATM. However, the spray spread into the shopping centre where the ATMs are situated.”

Posted on July 17, 2009 at 1:04 PM •

The ATM Vulnerability You Won't Hear About

The talk has been pulled from the BlackHat conference:

Barnaby Jack, a researcher with Juniper Networks, was to present a demonstration showing how he could jackpot a popular ATM brand by exploiting a vulnerability in its software.

Jack was scheduled to present his talk at the upcoming Black Hat security conference being held in Las Vegas at the end of July.

But on Monday evening, his employer released a statement saying it was canceling the talk due to the vendor’s intervention.

More:

“The vulnerability Barnaby was to discuss has far reaching consequences, not only to the affected ATM vendor, but to other ATM vendors and—ultimately—the public,” wrote Brendan Lewis, director of corporate social media relations for Juniper in a statement posted to the company’s official blog last week. “To publicly disclose the research findings before the affected vendor could properly mitigate the exposure would have potentially placed their customers at risk. That is something we don’t want to see happen.”

More news articles: 1, 2, 3, 4, and 5.

Posted on July 9, 2009 at 12:56 PM • View Comments

Malware Steals ATM Data

One of the risks of using a commercial OS for embedded systems like ATMs: it’s easier to write malware against it:

The report does not detail how the ATMs are infected, but it seems likely that the malware is encoded on a card that can be inserted in an ATM card reader to mount a buffer overflow attack. The machine is compromised by replacing the isadmin.exe file to infect the system.

The malicious isadmin.exe program then uses the Windows API to install the functional attack code by replacing a system file called lsass.exe in the C:WINDOWS directory.

Once the malicious lsass.exe program is installed, it collects users account numbers and PIN codes and waits for a human controller to insert a specially crafted control card to take over the ATM.

After the ATM is put under control of a human attacker, they can perform various functions, including harvesting the purloined data or even ejecting the cash box.

EDITED TO ADD (6/14): Seems like the story I quoted was jumping to conclusions. The actual report says “the malware is installed and activated through a dropper file (a file that an attacker can use to deploy tools onto a compromised system) by the name of isadmin.exe,” which doesn’t really sound like it’s referring to a buffer overflow attack carried out through a card emulator. Also, The Register says “[the] malicious programs can be installed only by people with physical access to the machines, making some level of insider cooperation necessary.”

Posted on June 10, 2009 at 1:51 PM • View Comments

More European Chip and Pin Insecurity

“Optimised to Fail: Card Readers for Online Banking,” by Saar Drimer, Steven J. Murdoch, and Ross Anderson.

Abstract

The Chip Authentication Programme (CAP) has been introduced by banks in Europe to deal with the soaring losses due to online banking fraud. A handheld reader is used together with the customer’s debit card to generate one-time codes for both login and transaction authentication. The CAP protocol is not public, and was rolled out without any public scrutiny. We reverse engineered the UK variant of card readers and smart cards and here provide the first public description of the protocol. We found numerous weaknesses that are due to design errors such as reusing authentication tokens, overloading data semantics, and failing to ensure freshness of responses. The overall strategic error was excessive optimisation. There are also policy implications. The move from signature to PIN for authorising point-of-sale transactions shifted liability from banks to customers; CAP introduces the same problem for online banking. It may also expose customers to physical harm.

EDITED TO ADD (3/12): More info.

Posted on March 5, 2009 at 12:45 PM • View Comments

Horrible Identity Theft Story

This is a story of how smart people can be neutralized through stupid procedures.

Here’s the part of the story where some poor guy’s account get’s completely f-ed. This thief had been bounced to the out-sourced to security so often that he must have made a check list of any possible questions they would ask him. Through whatever means, he managed to get the answers to these questions. Now when he called, he could give us the information we were asking for, but by this point we knew his voice so well that we still tried to get him to security. It worked like this: We put him on hold and dial the extension for security. We get a security rep and start to explain the situation; we tell them he was able to give the right information, but that we know is the same guy that’s been calling for weeks and we are certain he is not the account holder. They begrudgingly take the call. Minutes later another one of us gets a call from a security rep saying they are giving us a customer who has been cleared by them. And here the thief was back in our department. For those of us who had come to know him, the fight waged on night after night.

Posted on October 30, 2008 at 12:10 PM • View Comments

News from the Rock Phish Gang

Definitely interesting:

Based in Europe, the Rock Phish group is a criminal collective that has been targeting banks and other financial institutions since 2004. According to RSA, they are responsible for half of the worldwide phishing attacks and have siphoned tens of millions of dollars from individuals’ bank accounts. The group got its name from a now discontinued quirk in which the phishers used directory paths that contained the word “rock.”

The first sign the group was expanding operations came in April, when it introduced a trojan known alternately as Zeus or WSNPOEM, which steals sensitive financial information in transit from a victim’s machine to a bank. Shortly afterward, the gang added more crimeware, including a custom-made botnet client that was spread, among other means, using the Neosploit infection kit.

[…]

Soon, additional signs appeared pointing to a partnership between Rock Phishers and Asprox. Most notably, the command and control server for the custom Rock Phish crimeware had exactly the same directory structure of many of the Asprox servers, leading RSA researchers to believe Rock Phish and Asprox attacks were using at least one common server. (Researchers from Damballa were able to confirm this finding after observing malware samples from each of the respective botnets establish HTTP proxy server connections to a common set of destination IPs.)

Posted on September 10, 2008 at 7:47 AM • View Comments

A British Bank Bans a Man's Password

Weird story.

Mr Jetley said he first realised his security password had been changed when a call centre staff member told him his code word did not match with the one on the computer.

“I thought it was actually quite a funny response,” he said.

“But what really incensed me was when I was told I could not change it back to ‘Lloyds is pants’ because they said it was not appropriate.

[…]

“The rules seemed to change, and they told me it had to be one word, so I tried ‘censorship’, but they didn’t like that, and then said it had to be no more than six letters long.”

Lloyd’s claims that they fired the employee responsible for this, but what I want to know is how the employee got a copy of the man’s password in the first place. Why isn’t it stored only in encrypted form on the bank’s computers?

How secure can the bank’s computer systems be if employees are allowed to look at and change customer passwords at whim?

Posted on August 29, 2008 at 10:44 AM • View Comments

Indictments Against Largest ID Theft Ring Ever

It was really big news yesterday, but I don’t think it’s that much of a big deal. These crimes are still easy to commit and it’s still too hard to catch the criminals. Catching one gang, even a large one, isn’t going to make us any safer.

If we want to mitigate identity theft, we have to make it harder for people to get credit, make transactions, and generally do financial business remotely:

The crime involves two very separate issues. The first is the privacy of personal data. Personal privacy is important for many reasons, one of which is impersonation and fraud. As more information about us is collected, correlated, and sold, it becomes easier for criminals to get their hands on the data they need to commit fraud. This is what’s been in the news recently: ChoicePoint, LexisNexis, Bank of America, and so on. But data privacy is more than just fraud. Whether it is the books we take out of the library, the websites we visit, or the contents of our text messages, most of us have personal data on third-party computers that we don’t want made public. The posting of Paris Hilton’s phone book on the Internet is a celebrity example of this.

The second issue is the ease with which a criminal can use personal data to commit fraud. It doesn’t take much personal information to apply for a credit card in someone else’s name. It doesn’t take much to submit fraudulent bank transactions in someone else’s name. It’s surprisingly easy to get an identification card in someone else’s name. Our current culture, where identity is verified simply and sloppily, makes it easier for a criminal to impersonate his victim.

Proposed fixes tend to concentrate on the first issue—making personal data harder to steal—whereas the real problem is the second. If we’re ever going to manage the risks and effects of electronic impersonation, we must concentrate on preventing and detecting fraudulent transactions.

I am, however, impressed that we managed to pull together the police forces from several countries to prosecute this case.

Posted on August 7, 2008 at 12:45 PM • View Comments

1 … 8 9 10 11 12 … 19

Sidebar photo of Bruce Schneier by Joe MacInnis.