Banc of America Article

Mailman List Mirror (Read Only)
1

http://biz.yahoo.com/rb/030125/tech_virus_boa_1.html

Let's make the assumption that the outage of ATM's that BoA suffered was
caused by last nights 'SQL Slammer' virus.

The following things can then be assumed:

a) BoA's network has Microsoft SQL Servers on them.

b) BoA has not applied SP3 (available for a week) or the patch for this
particular problem (SQL Slammer) (available for many months).

c) somehow, this attack spawned on the public internet made it's way to
BoA's SQL servers, bypassing firewalls (did they have firewalls?).

Another article states, "Bank of America Corp., one of the nation's
largest banks, said many customers could not withdraw money from its
13,000 ATM machines because of technical problems caused by the attack. A
spokeswoman, Lisa Gagnon, said the bank restored service to nearly all
ATMs by late Saturday afternoon and that customers' money and personal
information had not been at risk."

Does anyone else, based upon the assumptions above, believe this statement
to be patently incorrect (specifically, the part about 'personal
information had not been at risk.') ?

I find these statement made by BoA, based upon assumptions which are
probably correct, to be very scary.

Comments?

-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben --
-- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

2

Which not technically correct, they are not technically incorrect
either.
Initial assesments of the worm do show that it's payload is simply
designed to propagate.

Someone could of course have written another worm / whatever that did
harver or allow the harvesting of data. This would be bad and until they
patched their servers would probably have been possible.
But within the confines of the attack scenario of last night, they are
correct in what they said. It's just PR spin.

What is scarier is that they dont have / use firewalls properly and
traffic can so easily pass from their DMZ/public network to their
private network.

BoA is one place I'll never be willingly taking my business, and I'm
sure now others here won't.

3

Does anyone else, based upon the assumptions above, believe this statement
to be patently incorrect (specifically, the part about 'personal
information had not been at risk.') ?

Actually, the statements are correct. Remember, the worm wasn't programmed
to put the database or the security of the networks at risk. Of course, the
customer's information "could" have been at risk, but in hind sight, it
wasn't.

However, there is another possibility. BofA could have piped a portion of
the public network through equipment that sustains their private network in
a secure manner. However, a MS-SQL system (or a couple hundred) which
contained nothing of value was infected. The load created by the system was
enough to interrupt equipment along the path and effectively shut down their
private network even though it didn't have direct access. Example, I can run
IP through ATM switches. The overloading of the PVC could systematically
destroy the integrity of the ATM network which holds other ATM traffic. This
is still a secure model, although obviously not well engineered as proper
ATM CoS would have limited the IP traffic. Of course, ATM would be one
example. They could be tunneling IP over any number of protocols commonly
used by banks. In essence, only one piece of common equipment has to be shut
down to cause a problem.

Jack Bates
BrightNet Oklahoma

4

Patently incorrect? No. It is possible.

Even if the confidentiality of your data is protected, you are still
vulnerability to attacks on availability and integrity of the data.

For example, you may fully encrypt all your data, use VPNs, etc. But you
can still loose service due to network congestion or routers failing due
to other unprotected traffic on your network.

One of the most common mistakes I see rookie security people make is
thinking "confidentiality" is the only business requirement.

5

< knowing absolutely nothing about how BoA ATM's work >

It could be that BoA's network wasn't flooded / servers infected, but that
the ATM's do not dial BoA directly, and dial somewhere else (ie, maybe some
kind of ATM Dial Provider, nationwide wholesale, etc), and then tunnel back
to BoA to get the data. Could be that the upstream of either the dial
provider, or BoA was just flooded...

6

> Does anyone else, based upon the assumptions above, believe this

statement

> to be patently incorrect (specifically, the part about 'personal
> information had not been at risk.') ?

Which not technically correct, they are not technically incorrect
either.

Hm. One possible attack on BoA's data would be to log incoming udp port
1434 requests to your network, and cross reference the source addresses with
BoA's netblocks. Now you have a list of verified vulnerable BoA MSSQL
servers.

While it's possible that _none_ of the vulnerable servers have _any_
'personal information', I'd venture to guess otherwise.

While I'm on the topic of attacking servers that attacked you first, can I
get some opinions on the ethics of this? I think a targeted attack like the
one I described above would surely be crossing the proverbial line, but what
about an automated nmap scan of attacking hosts, where the data would be
used for aggragate statistics? Thoughts?

Ryan

7

I think a basic point is being overlooked here..

B of A.. A company that handles untold amounts of cash on a daily
basis. Sure, there are valid needs for people to reach both the
internet and the corporate secure net from inside the company. Might
be very hard to get things done, such as doenloading and installing MS
SQL patches otherwise. But since databases in use supposedly contain
highly critical data, how did their servers get infected in the first
place? How did traffic get through to what ought to be designated a
secure port on a secure server? You would also expect that the MOST
critical servers would also be issolated within the secure net as
well, that is, network segmentation. (Just 'cause they're in the same
company doesn't mean the secretary in Ohio needs to access the servers
in San Diego.)

I think that it demonstrates shortcomings in the company's overall
network security policy. Things CAN be easily overlooked and this may
well be a case of something that just didn't get thought about (it
happens) but it deffinitely bears review by those involved, I should
think.

I mean, FDIC aside, if your money and account numbers, SS info, etc,
etc are in that database, wouldn't you want them to make a few
revisions?

And the scary thought for the night: How about the other banks? Credit
card companies? The credit agencies themselves? What vulnerabilities
exist in those agencies?

(Please note, it is not my intent to criticize the company or the
security folk. My hat goes off to any good security admin. These folks
generally do a good job of making sure that us losers can conduct our
menial business with a reasonable surety that there is no one listening
in.)

8

While it's possible that _none_ of the vulnerable servers have _any_
'personal information', I'd venture to guess otherwise.

Agreed. And, even if it is super encrypted, who cares? Enough CPU and time
will take care of that.

-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben --
-- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

9

Date: Sun, 26 Jan 2003 00:22:02 -0500 (Eastern Standard Time)
From: Alex Rubenstein

Agreed. And, even if it is super encrypted, who cares? Enough
CPU and time will take care of that.

Articles about "1000 years to crack using brute force" are a bit
disconcerting if someone has access to 10,000x compromised hosts.
While we're on the subject: root certificates, anybody?

Each worm seems to prove the availability of CPU and time.

Eddy

10

E.B. Dreger wrote:

Date: Sun, 26 Jan 2003 00:22:02 -0500 (Eastern Standard Time)
From: Alex Rubenstein

Agreed. And, even if it is super encrypted, who cares? Enough
CPU and time will take care of that.

Articles about "1000 years to crack using brute force" are a bit
disconcerting if someone has access to 10,000x compromised hosts.
While we're on the subject: root certificates, anybody?

Each worm seems to prove the availability of CPU and time.

Might not even need a worm - just enough money to form a seed.
according to recent paper (TWIRL) the main step towards breaking a 1024 key
(such as used by all the CAs currently) could be done in under a year by a
machine with a cost of $10M (surely not beyond the reach of a large
multinational company or crime organisation). In detail:

http://psifertex.com/download/twirl.pdf
Factoring Large Numbers with the TWIRL Device
(preliminary draft)

Adi Shamir, Eran Tromer

Department of Computer Science and Applied Mathematics Weizzmann Institute
of Science, Rehavot 76100, Israel Ishamir,tromerlftisdon.wei@nmnn.ac.iI

January 23, 2003

Abstract.

The security of the RSA cryptosystem depends on the difficulty of factoring
large integers. The best current factoring algorithm is the Number Field
Sieve (NFS), and its most difficult part is the sieving step. In 1999 a
large distributed computation involving thousands of workstations working
for many months managed to factor a 512-bit RSA key, but 1024-bit keys were
believed to be safe for the next 15-20 years. In this paper we describe a
new hardware implementation of the NFS sieving step (based on standard
0.13pm, I GHz VLSI technology) which is 3-4 orders of magnitude more cost
effective than the best previously published designs (such as the opt
electronic TWINKLE of 1131 and the mesh-based sieving of 151)- Based on a
detailed analysis of all the critical components (but without an actual
implementation), we believe that the NIPS sieving step for 1024-bit RSA keys
can be completed in less than a year by a $10M device, and that the NFS
sieving step for 512-bit RSA keys can be completed in less than ten minutes
by a $10K device. Coupled with recent results about the difficulty of the
NFS matrix step [10], this raises some concerns about the security of these
key sizes-

11

Patently incorrect? No. It is possible.

Even if the confidentiality of your data is protected, you are still
vulnerability to attacks on availability and integrity of the data.

For example, you may fully encrypt all your data, use VPNs, etc. But you
can still loose service due to network congestion or routers failing due
to other unprotected traffic on your network.

That is not as large of a problem as losing part(s)s of the transaction(s).
Obviously, I cannot imagine how stupid should someone be to design their
network in a way where an internet attack can knock off the non-internet
enabled service provided by a bank.

Alex

12

< knowing absolutely nothing about how BoA ATM's work >

It could be that BoA's network wasn't flooded / servers infected, but that
the ATM's do not dial BoA directly, and dial somewhere else (ie, maybe some
kind of ATM Dial Provider, nationwide wholesale, etc), and then tunnel back
to BoA to get the data. Could be that the upstream of either the dial
provider, or BoA was just flooded...

Again, that design makes nearly no sense. The vast majority of the ATMs that
banks own and operate directly are located in the LATAs with bank branches.
Those branches do have good connectivity to the bank processing centers be
that via dedicated links, VPN or carrier pigeons. ATMs do have at a POTS
because that is the way alarm companies monitor them. The sane design is to
aggregate ATMs in zones via large branches and use branch connectivity to
the processing center to provide the link. The other designs are not only
more expensive but also less reliable (as we have seen here).

Alex