Full disclosure and the banking industry
[Posted February 26, 2003 by corbet]
Back in 1992, an English police officer named John Munden returned from a
vacation to find that a series of ATM withdrawals had cleaned out his bank
account. His complaints to the bank were not received well; they responded
that their systems were secure and only Mr. Munden could have made those
withdrawals. When he persisted, the bank (the Halifax Building Society)
had him prosecuted (and convicted) for fraud. It took four years, and
a great deal of effort by a researcher named Ross Anderson, to shine a
light on Halifax's poor security, and to get Mr. Munden freed on appeal.
Even so, the attitude of the banking industry has changed little;
complaints of "phantom withdrawals" are given little credence, and account
holders often end up footing the bill. (Some countries, including the
U.S., give consumers more protection than others, such as Britain, in this
area).
Given that peoples' money - and freedom - are being staked on the security
of the ATM system, it would be nice to know that this system is truly
secure. But banks, unsurprisingly, are unenthusiastic about opening up
their systems to external review. Mr. Anderson and colleagues have
continued their research into the phantom withdrawal problem, and have
served as expert witnesses in associated court cases. Recently they turned
up something interesting.
The personal ID numbers (PINs) used to verify the person using an ATM card
are kept in a carefully-guarded database. It is not generally possible to
extract a specific PIN directly. Instead, the ATM system operates through
a set of hardware security modules that can give "yes or no" answers for a
given account number and PIN. Thus, it is claimed, even a corrupt insider
would be reduced to guessing to obtain a specific PIN number. The search
space is not that large (10,000 numbers), but it still requires an average
of 5,000 guesses to obtain a single PIN.
Mike Bond and Piotr Zielinski, working with Mr. Anderson, found a
vulnerability in this system; their writeup is available (for now) on the
web in PDF format (also
available here while
Cryptome, which apparently has been broken into, gets back on its feet). By
manipulating a simple "decimalization table" used in the generation of the
PIN from the account number, an attacker can quickly determine which digits
are present in the PIN. Using that information and some additional tricks,
the researchers were able to extract PIN numbers using an average of
15 guesses. An attacker, they conclude, would be able to extract about
7,000 PINs over the course of a half-hour lunch break.
Citibank has responded to this discovery by seeking a gag order to suppress the
disclosure of the vulnerability information. The information, says
Citibank, is confidential and should not be released publicly. This action
immediately had the obvious effect: once word got out, the paper describing
the vulnerability was copied far and wide across the net, beyond any
feasible recall. Even in the modern world, once information gets out, it
is out.
Citibank could certainly argue that it does not want to provide useful
information to those who would attack its systems. On the other hand, the
rising tide of phantom withdrawal cases suggests that some of this
information is in the hands of the Bad Guys already. Could it be that the
banks are really trying to avoid (1) admitting that phantom
withdrawals are a real problem, and (2) undertaking the expensive task
of fixing their systems?
Evidence in the software field consistently suggests that vendors do not
rush out to fix their security problems in the absence of considerable
external pressure to do so. This is especially true if the costs of the
problems can be pushed onto somebody else. The banking industry
needs disclosure of its problems if we are to have any confidence in
its security at all. As with vulnerabilities in the software industry,
banking vulnerabilities should be handled with some care. But the
information has to get out, or the problems will not be fixed in any sort
of timely way. Consider, for example, the uproar the resulted when Matt
Blaze exposed
a vulnerability in master-keyed door locks which, apparently, had been
known to locksmiths (but not fixed) for decades.
The lessons we have learned in the software world are applicable in a much
wider context. Continued defense of our ways of working, including
disclosure of security problems and open review of security-related
systems, is important for our security and freedom.
This is true with regard to our computing systems, and far beyond.
(
Log in to post comments)