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 --
On Sat, Jan 25, 2003 at 05:45:16PM -0500, Alex Rubenstein wrote:
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.') ?
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.
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
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 --
AR> Date: Sun, 26 Jan 2003 00:22:02 -0500 (Eastern Standard Time) AR> From: Alex Rubenstein AR> Agreed. And, even if it is super encrypted, who cares? Enough AR> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
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-
From: "Alex Rubenstein"
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
On Sat, 25 Jan 2003, Alex Rubenstein wrote:
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.') ?
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.
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
< 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... On Sat, Jan 25, 2003 at 05:45:16PM -0500, Alex Rubenstein wrote:
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 --
-- Jeffrey Meltzer ICS/VillageWorld 631-218-0700 x100
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.) --- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/resume.html
< 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
participants (10)
-
Alex Rubenstein -
alex＠yuriev.com -
Avleen Vig -
Dave Howe -
E.B. Dreger -
Jack Bates -
Jeffrey Meltzer -
Ryan Fox -
Sean Donelan -
Wayne E. Bouchard