Re: Banc of America Article
at Wednesday, January 29, 2003 6:35 PM, Al Rowland <[EMAIL PROTECTED]> was seen to say: > The PIN is on your card, likely encrypted IIRC, the actual answer is a bit simpler - an initial pin is *calculated* from your account number (which *is* stored on the card) and an offset (also on the card) is applied to give the pin you actually type. > Just conjecture, no way to know how this specifically works without > looking at the BoA specific ATM code but I'd be willing to bet the > code errs on the side of customer convenience over absolute security. Possibly. unfortunately (here in the uk at least) "the system" also defaults to believing that only the registered owner could possibly use the card - hence lots of cases over "phantom withdrawls" that the bank refuses to refund. So customer convenience is ok provided it comes free for the bank :)
Re: Banc of America Article
On Wed, Jan 29, 2003 at 01:19:08PM -0500, Charles Sprickman wrote: > > On Wed, 29 Jan 2003, Al Rowland wrote: > > > Or, > > > > IIRC, the ATM system is similar to CC transactions. A best effort is > > made to authorize against your account (Credit Card or Banking) but if > > it fails and the transaction is within a normal range (your daily card > > limit) the CC/ATM completes the transaction. > > So you're telling me that if I go to Kwik-E-Mart, cut the wires, put my > card with a $0 balance in it will happily let me withdraw money? Somehow > that doesn't sound right. How would it know my PIN, or would it assume I > entered it correctly? How would it know my daily card limit? Disclaimer: while I did work for a company that was (or would have been) involved with CC transactions, I have never actually worked with CC auth mechanisms; only discussed them with a housemate who worked on $(MAJOR_CC_VENDOR)'s transaction/auth system. The short answer is: yes. The longer answer is: your PIN is on your card, the rest is recorded in the ATM and syncronized when it has connectivity again. At which point, your bank will be sending you a polite (or, for some amounts, not so polite) request to pay the outstanding balance, the fees incurred for overdraft, and other assorted charges. Most of the financial world operates on a pair of fairly straightforward principles: 1) It costs money to stop fraud. Unless and until the cost of fraud exceeds the cost of stopping the fraud, it is not profitable to attempt to stop the fraud (and, as a correllary, the effort put into stopping fraud is limited to that amount which produces a better-than-even return on investment). All major CC vendors simply budget for some amount of fraud every year; it's a known risk of the business model, and is accounted for. 2) Banks are, as a rule, care fairly little about whether you can withdraw money that you shouldn't be able to. ATM limits are largely about limiting the amount of damage done in the short term. What banks care about a very great deal is trying to make sure that that nothing, anywhere, in the entire system, can cause a transaction that doesn't have an audit trail - and spotting such things is (relatively) easy, because the books suddenly don't balance. Money may be information, but *within the system*, that information is checked, double-checked, cross-checked, and otherwise run through a really insane amount of effort to make sure you can't create money from nothing - and can't move it from one place to another without leaving some record of the movement. Thus, you can get physical cash from an ATM, if the system is out of sync, but as soon as it gets synced up again that will be linked back to your account. The bank only really cares, then, if your account happens to end up negative (and, as above, will take action in more concrete ways, to deal with the situation). Anyone who actually cares about this is strongly advised to not take my word on it, but go do the homework for yourself; most of this information is available to a sufficiently curious searcher. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg08695/pgp0.pgp Description: PGP signature
RE: Banc of America Article
On Wed, 29 Jan 2003, Al Rowland wrote: > Or, > > IIRC, the ATM system is similar to CC transactions. A best effort is > made to authorize against your account (Credit Card or Banking) but if > it fails and the transaction is within a normal range (your daily card > limit) the CC/ATM completes the transaction. So you're telling me that if I go to Kwik-E-Mart, cut the wires, put my card with a $0 balance in it will happily let me withdraw money? Somehow that doesn't sound right. How would it know my PIN, or would it assume I entered it correctly? How would it know my daily card limit? Charles > Best regards, > __ > Al Rowland > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > > Behalf Of Leo Bicknell > > Sent: Tuesday, January 28, 2003 8:03 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Banc of America Article > > > > > > > > FWIW: > > > > http://www.washingtonpost.com/wp-dyn/articles/A57550-2003Jan28.html > > > > "About 13,000 Bank of America cash machines had to be shut > > down. The bank's ATMs sent encrypted information through the > > Internet, and when the data slowed to a crawl, it stymied > > transactions, according to a source, who said customer > > financial information was never in danger of being stolen." > > > > -- > >Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 > > PGP keys at http://www.ufp.org/~bicknell/ > > Read TMBG List - [EMAIL PROTECTED], www.tmbg.org > > >
RE: Banc of America Article
At 12:46 PM 1/29/2003, [EMAIL PROTECTED] wrote: > IIRC, the ATM system is similar to CC transactions. A best effort is > made to authorize against your account (Credit Card or Banking) but if > it fails and the transaction is within a normal range (your daily card > limit) the CC/ATM completes the transaction. Too bad it is not the case, but lets presume that it is. How does it explain branches not being able to process direct withdrawals either? The incident on hand illustrates that the design of our financial networks is broken. If a non sophisticated worm managed to create so many problems, what is going to happen should a real attack be mounted against the networks used by financial services? Perhaps the bank bought VPN service with an SLA from a large network vendor. That SLA was not met due to network congestion. Said vendor will be responsible for reparations to the bank. That doesn't help the customers, of course. Now the bank COULD just use T-1 or faster circuits to all branches, but the network vendors are pushing VPNs (whether formed by IPSec tunnels, Frame Relay, MPLS, etc.) as cheaper alternatives. It would be foolish and irresponsible for the bank management to spend many times the amount of money. Of course even the T-1 circuits can have problems. ATT did melt their telephony backbone on Martin Luther King Day some years back. So should the bank run their own fiber between branches to ensure they're OK in the event of an SS7 meltdown? Where do you draw the line? Which technology do YOU trust? Which can you afford?
RE: Banc of America Article
> IIRC, the ATM system is similar to CC transactions. A best effort is > made to authorize against your account (Credit Card or Banking) but if > it fails and the transaction is within a normal range (your daily card > limit) the CC/ATM completes the transaction. Too bad it is not the case, but lets presume that it is. How does it explain branches not being able to process direct withdrawals either? The incident on hand illustrates that the design of our financial networks is broken. If a non sophisticated worm managed to create so many problems, what is going to happen should a real attack be mounted against the networks used by financial services? Alex
RE: Banc of America Article
AR> Date: Wed, 29 Jan 2003 07:20:35 -0800 AR> From: Al Rowland AR> IIRC, the ATM system is similar to CC transactions. A best AR> effort is made to authorize against your account (Credit Card AR> or Banking) but if it fails and the transaction is within a AR> normal range (your daily card limit) the CC/ATM completes the AR> transaction. Fail-open security on financial networks? Yucky. 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 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: Banc of America Article
Or, IIRC, the ATM system is similar to CC transactions. A best effort is made to authorize against your account (Credit Card or Banking) but if it fails and the transaction is within a normal range (your daily card limit) the CC/ATM completes the transaction. I'd be willing to bet the failure rate Saturday was high enough to cause concern that bank customers (knowingly or innocently) could bypass the normal limits and overdraw or otherwise negatively effect their accounts. So BoA decided to shut down the system until the failure rate returned to 'normal.' Not a bad thing, IMHO. Best regards, __ Al Rowland > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Leo Bicknell > Sent: Tuesday, January 28, 2003 8:03 PM > To: [EMAIL PROTECTED] > Subject: Re: Banc of America Article > > > > FWIW: > > http://www.washingtonpost.com/wp-dyn/articles/A57550-2003Jan28.html > > "About 13,000 Bank of America cash machines had to be shut > down. The bank's ATMs sent encrypted information through the > Internet, and when the data slowed to a crawl, it stymied > transactions, according to a source, who said customer > financial information was never in danger of being stolen." > > -- >Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - [EMAIL PROTECTED], www.tmbg.org >
Re: Banc of America Article
In message <[EMAIL PROTECTED]>, Leo Bicknell writes: > > > >FWIW: > >http://www.washingtonpost.com/wp-dyn/articles/A57550-2003Jan28.html > >"About 13,000 Bank of America cash machines had to be shut down. The >bank's ATMs sent encrypted information through the Internet, and when >the data slowed to a crawl, it stymied transactions, according to a >source, who said customer financial information was never in danger of >being stolen." > OK. I -- and, I suspect, most other folks on this list -- have been predicting for years that the Internet would become *the* data network, good for all taks. Bank of America believed us. They learned that maybe we were a bit overoptimistic in our time frame --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: Banc of America Article
FWIW: http://www.washingtonpost.com/wp-dyn/articles/A57550-2003Jan28.html "About 13,000 Bank of America cash machines had to be shut down. The bank's ATMs sent encrypted information through the Internet, and when the data slowed to a crawl, it stymied transactions, according to a source, who said customer financial information was never in danger of being stolen." -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg08642/pgp0.pgp Description: PGP signature
RE: Banc of America Article
> I'm familiar with some enforced financial institution requirements, no > where did I find transaction data of ATMs on a dedicated network to be > _required_. Is this a common industry practice, or a mandatory standard > I have not discovered? It is a common practice. Since the alarm line is permanently connected to some monitoring company which is supposed to make up its mind about ATM still being there should a nice gentleman with a truck decide to take the entire machine with him, it is very difficult to get that line used for something else. The other line is the data line, which, in my experience, tends to be POTS or ISDN (and sometimes DS0). Maybe I am not being clear on the terminology - dedicated in this case means "non-alarm" line. Wherever the connection terminates is going to depend on implementation. > How does this relate to the No Name standalone ATM which normally have > exposed POTS wires running to the wall? If you look carefully at those wires (without flipping out mini-mart owners) you are most likely to notice that it has either two visible POTS lines or one cable carrying two phone lines. Alex
Re: Banc of America Article
[EMAIL PROTECTED] wrote: > > 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. While the exact mechanism of BofA's exposure is important it is nowhere near as important as the fact that they were, and presumably are still, exposed. My money's on Frame Relay congestion. Some department at BofA, short on engineers and long on budget-oriented management, likely made a decision that saving a lot of money was worth a bit of exposure. I know that decision has been made at other banks. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Banc of America Article
> < 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
RE: Banc of America Article
> I think you're leaving out a very viable possibility in your summary... > > What if BoA took a proactive approach and shut down their SQL environment > (even though none of us known conclusively if they're a SQL or Oracle shop) > to verify that it was in fact clean and not compromised. When you're > talking about access to billions of dollars, it's not worth taking a chance. > They might have actually followed proper security protocol and verified > their systems were clean before re-activating them. Dear Customer, we have proactively shutdown the access to money of anyone deposited with us to verify that we in fact can perform function that we have been contracted by you to perform. Still like it? > Just a thought. Just an answer. > -Dave Alex
Re: Banc of America Article
> While they may have VPN's at many of their branches which offer significant > savings over leased lines everywhere, their web site access to personal > banking information was also offline. It would be worth grepping logs to > see if there was indeed a SQL server from the inside that was infected. Using VPN for branches is very different from using VPN with ATMs. Alex
RE: Banc of America Article
> Actually, I think too many assumptions were made. > > Let's simplify. > > We know UUNet traffic capabilities were reduced significantly. Uunet > has many big customers. Other big carriers had similar affects on their > networks, probably particularly at peering points. > > We know many companies use public or private VPN services from major > carriers such as these, and that both VPN types may use public internet > carriers. > > I think therefore that the only true conclusion we could say is that if > BoA's traffic was not prioritized, it therefore suffered collateral > damage primarily due to traffic not being able to get through between > ATM's and the central processing center. Being someonewhat familiar with the design of ATM networks, I can tell you that it is not correct. Your basic ATM gets two to three connections - one being a data access line, the other being a regular alarm line. The data access line is POTS, DS0 or, ISDN. The alarm line is POTS (the funny part is that certain large banks when buying other banks forget what the other line is used for and put a disconnect order on those creating lots of mess). The transaction data is never supposed to travel on any non-dedicated network. Alex
Re: Banc of America Article
> 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
RE: Banc of America Article
I think you're leaving out a very viable possibility in your summary... What if BoA took a proactive approach and shut down their SQL environment (even though none of us known conclusively if they're a SQL or Oracle shop) to verify that it was in fact clean and not compromised. When you're talking about access to billions of dollars, it's not worth taking a chance. They might have actually followed proper security protocol and verified their systems were clean before re-activating them. Just a thought. -Dave > -Original Message- > From: Alex Rubenstein [SMTP:[EMAIL PROTECTED]] > Sent: Sunday, January 26, 2003 10:59 AM > To: Ray Burkholder > Cc: [EMAIL PROTECTED] > Subject: RE: Banc of America Article > > > > Let me summarize, then ask a question: > > a) BoA uses the public internet for ATM transactions. The public internet > was so dead, that every one of thier ATM machines was dead for many hours, > even many hours longer than the public internet was dead. > > b) BoA uses it's own network for it's on ATM transactions. Somewhere on > the a public to private connection, a firewall wasn't doing it's job, or > there wasn't a firewall. Things were broken for a while, until they were > able to fix all thier SQL servers. > > I guess my point is, if it were a), not every ATM would be dead all the > time, and things would have been fixed in only a little while. Not many > internet 'backbones' (at least ones BoA would have used for this > application) were down as long as BoA's ATM's were. > > On the other hand, I think it's more likely that BoA had unprotected SQL > servers, and they got it. It took a long while for BoA IT people to make > it out of bed saturday morning to fix the problem. > > I still clearly say that I don't know what happened, and I did make > assumptions (as I said in the original mail) -- but I'd still place my > money on b). > > > > On Sun, 26 Jan 2003, Ray Burkholder wrote: > > > Actually, I think too many assumptions were made. > > > > Let's simplify. > > > > We know UUNet traffic capabilities were reduced significantly. Uunet > > has many big customers. Other big carriers had similar affects on their > > networks, probably particularly at peering points. > > > > We know many companies use public or private VPN services from major > > carriers such as these, and that both VPN types may use public internet > > carriers. > > > > I think therefore that the only true conclusion we could say is that if > > BoA's traffic was not prioritized, it therefore suffered collateral > > damage primarily due to traffic not being able to get through between > > ATM's and the central processing center. > > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > > IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Re: Banc of America Article
From: "Alex Rubenstein" > On the other hand, I think it's more likely that BoA had unprotected SQL > servers, and they got it. It took a long while for BoA IT people to make > it out of bed saturday morning to fix the problem. > > I still clearly say that I don't know what happened, and I did make > assumptions (as I said in the original mail) -- but I'd still place my > money on b). > I agree, yet there is inconclusive evidence as to whether the unprotected SQL servers were in their private network or their public network, nor what data was contained on them. Like many networks, they may have just killed out switches and routers that were shared between public and private. Jack Bates BrightNet Oklahoma -Will someone using <5000 for source ports? Makes safeguard filters impossible.
Re: Banc of America Article
Just like the insider TCI theft ring at http://zdnet.com.com/2100-1106-971196.html , the easy way out is to just to skip all that and get access to a leased line from the inside - I'll bet many financial transactions over a private line aren't even encrypted. - Original Message - > Yes, with enough CPU and enough time, it's possible to crack modern > ciphers by brute force. But "enough" is quite a large number.
RE: Banc of America Article
Let me summarize, then ask a question: a) BoA uses the public internet for ATM transactions. The public internet was so dead, that every one of thier ATM machines was dead for many hours, even many hours longer than the public internet was dead. b) BoA uses it's own network for it's on ATM transactions. Somewhere on the a public to private connection, a firewall wasn't doing it's job, or there wasn't a firewall. Things were broken for a while, until they were able to fix all thier SQL servers. I guess my point is, if it were a), not every ATM would be dead all the time, and things would have been fixed in only a little while. Not many internet 'backbones' (at least ones BoA would have used for this application) were down as long as BoA's ATM's were. On the other hand, I think it's more likely that BoA had unprotected SQL servers, and they got it. It took a long while for BoA IT people to make it out of bed saturday morning to fix the problem. I still clearly say that I don't know what happened, and I did make assumptions (as I said in the original mail) -- but I'd still place my money on b). On Sun, 26 Jan 2003, Ray Burkholder wrote: > Actually, I think too many assumptions were made. > > Let's simplify. > > We know UUNet traffic capabilities were reduced significantly. Uunet > has many big customers. Other big carriers had similar affects on their > networks, probably particularly at peering points. > > We know many companies use public or private VPN services from major > carriers such as these, and that both VPN types may use public internet > carriers. > > I think therefore that the only true conclusion we could say is that if > BoA's traffic was not prioritized, it therefore suffered collateral > damage primarily due to traffic not being able to get through between > ATM's and the central processing center. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: Banc of America Article
In message <[EMAIL PROTECTED]>, "E.B. Dreger" writes: > >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. This is practical against, say, DES, with its 56-bit keys. In fact, it's been done; see http://www.virusbtn.com/resources/viruses/indepth/opaserv.xml for an example. But the fact that DES is insecure has been known for years; it doesn't take a worm to underscore that point. Let's look at AES or 3DES instead. Suppose there are 1,000,000,000 infected hosts. Let's further assume that each one can check a single key in .1 nanoseconds. (That's a gross exageration, I might add, for a general-purpose machine -- and we're not talking about 1,000,000,000 NSA code-crackers being infected.) AES uses 128-bit keys; there are therefore 340282366920938463463374607431768211456 possibilities. Call it 3*10^38. Divide that by 10^9 hosts, and 10^10 tries per second per host. That gives us 3*10^19 tries per second. There are ~10^5 seconds/day, and 3*10^2 seconds/year, meaning that it would take 10^12 years for this scenario. 3DES? Well, 3DES may be using 112-bit keys, so we can cut the time by 2^16. Call that 10^5 -- so we'll only have to wait 10^7 years for a single result Yes, with enough CPU and enough time, it's possible to crack modern ciphers by brute force. But "enough" is quite a large number. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: Banc of America Article
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,[EMAIL PROTECTED] 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-
Re: Banc of America Article
While they may have VPN's at many of their branches which offer significant savings over leased lines everywhere, their web site access to personal banking information was also offline. It would be worth grepping logs to see if there was indeed a SQL server from the inside that was infected.
RE: Banc of America Article
Actually, I think too many assumptions were made. Let's simplify. We know UUNet traffic capabilities were reduced significantly. Uunet has many big customers. Other big carriers had similar affects on their networks, probably particularly at peering points. We know many companies use public or private VPN services from major carriers such as these, and that both VPN types may use public internet carriers. I think therefore that the only true conclusion we could say is that if BoA's traffic was not prioritized, it therefore suffered collateral damage primarily due to traffic not being able to get through between ATM's and the central processing center. Ray Burkholder > -Original Message- > From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] > Sent: January 25, 2003 18:45 > To: [EMAIL PROTECTED] > Subject: Banc of America Article > > > > > 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, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > >
Re: Banc of America Article
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 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Banc of America Article
> 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, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: Banc of America Article
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 [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/resume.html
Re: Banc of America Article
On Sat, 25 Jan 2003, 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. Not necessarily. There's this statement from a BoA employee: '"We have been impacted, and for a while customers could not use ATMs and customer services could not access customer information," Gagnon said.' While that's clear as mud, one could also infer that the network that they depend on to interconnect their ATMs and branches was impacted by all the garbage network being carried at the time. They don't disclose how these atm's and branches are connected back to their datacenter(s?), but perhaps someone had the bright idea of tunneling everything over something like the Qwest network, which some here reported as being b0rked for quite some time... Or perhaps they (or the VPN concentration gear) are in a shared datacenter space where other customers bouncing this junk around trashed the network within the datacenter. These days you can never make assumptions about what passes for BCP. Just another possibility... Mind you I'm not rushing out to open an account with them. C > Comments? > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > >
Re: Banc of America Article
> > 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
Re: Banc of America Article
< 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, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > -- Jeffrey Meltzer ICS/VillageWorld 631-218-0700 x100
Re: Banc of America Article
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.
Re: Banc of America Article
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.
Re: Banc of America Article
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
