May 05, 2006

Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan

Journalist Roger Grimes did some research on trojans and came up with this:

Even more disturbing is that most banks and regulatory officials donít understand the new threat, and when presented with it, hesitate to offer anything but the same old advice.

Every bank and regulatory official contacted for this article said they have already recommended banks implement a two-factor or multifactor log-on authentication screen. In general, they expressed frustration at the amount of effort it has taken to get banks to follow that advice. And all complained about the trouble these schemes are causing legitimate customers.

When told how SSL-evading Trojans can bypass any authentication mechanism, most offered up additional ineffective authentication as a solution. When convinced by additional discussion that the problem could be solved only by fixing transactional authorization, most shrugged their shoulders and said they would remain under pressure to continue implementing authentication-only solutions.

They were also hesitant to broach the subject with senior management. It had taken so long to get banks to agree to two-factor authentication, they said, it would be almost impossible to change recommendations midstream. That puts the banking industry on a collision course with escalating attacks.

On the nail. (Sorry, Dave!)

Microsoft has apparently expressed a preference of smart cards over two-factor tokens:

More interesting is Microsoft's long-term view of two-factor authentication. In contrast to companies such as E*Trade, AOL, and VeriSign which have either announced support for or are already supporting one-time password + security token combinations for their customers, Microsoft sees things moving in a different direction, according to a spokesperson.

Most customers told Microsoft they do not view one-time passwords as strategic and are looking long term to smart cards as their preferred strong authentication mechanism.

In any soap opera, there appear advert breaks where the housewife is offered the choice of bland brand A versus bland brand B. "Most housewifes we surveyed chose Brand X soap powder." Maybe Microsoft's heart is in the right place, though:

Last week, Microsoft pledged to bring about 100 legal actions against phishers in Europe, the Middle East and Africa (EMEA) over the next few months.

That's smart. Given their risk exposure, they'd better have something good to bring to the negotiating table, especially given their extensive experience in prosecuting evil software copiers and less extensive success in stopping spam. To take a leaf out of Chandler's book, with fraud you are either fighting them or your are supporting them. (hmmm, spoke too soon.)

Adam finds an article on how Adam Laurie and Steve Boggan "hacked" the airline ticket tracking systems to extract the full identity of a flyer. Skipping the details on the hack itself (did buying the ticket establish their credentials?) the piece is more relevant for its revelations of just how much data is being put together for erstwhile tracking purposes.

We logged on to the BA website, bought a ticket in Broer's name and then, using the frequent flyer number on his boarding pass stub, without typing in a password, were given full access to all his personal details - including his passport number, the date it expired, his nationality (he is Dutch, living in the UK) and his date of birth. The system even allowed us to change the information.

Using this information and surfing publicly available databases, we were able - within 15 minutes - to find out where Broer lived, who lived there with him, where he worked, which universities he had attended and even how much his house was worth when he bought it two years ago.

The article talks about how the Europeans handed over the data to the Americans in apparent breach of their own privacy rules. Things like what means you ordered, what sort of hotel room. Today you're a terrorist for ordering the ethnic meal, and tomorrow you run the same risk if you swap hotels and your hotel chain doesn't approve. Think that's extreme? Look how the information creep has started:

"They want to extend the advance passenger information system [APIS] to include data on where passengers are going and where they are staying because of concerns over plagues," he says. "For example, if bird flu breaks out, they want to know where all the foreign travellers are.

That's nothing more than an excuse by the system operators to extract more information. Of course, your hotel will be then required to provide up to date information as to where you moved next.

A data point - perhaps the first transaction trojan. FTR:

Transaction-based SSL-evading Trojans are the most dangerous and sophisticated. They wait until the user has successfully authenticated at the bankís Web site, eliminating the need to bypass or capture authentication information. The Trojan then manipulates the underlying transaction, so that what the user thinks is happening is different from whatís actually transpiring on the siteís servers.

The Win32.Grams E-gold Trojan, spawned in November 2004, is a prime example of transaction-based type. When the user successfully authenticates, the Trojan opens a hidden browser window, reads the userís account balance, and creates another hidden window that initiates a secret transfer. The userís account balance, minus a small amount (to bypass any automatic warnings), is then sent to a predefined payee.

Many SSL-evading Trojans are ďone-offs,Ē meaning that they are encrypted or packaged so that each Trojan is unique -- defeating signature-style detection by anti-virus software.

Ultimately, SSL-evading Trojans can be defeated only when users stop running untrusted code -- or better still, when banks deploy back-end defensive mechanisms that move beyond mere authentication protection.

Sorry about the "blame the user" trick at the end. When will they ever learn?

Posted by iang at May 5, 2006 05:55 PM | TrackBack
Comments

re:
E-commerce in crisis: When SSL isn't safe
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.h
tml?s=feature

the PC end-point vulnerability has been long recognized ... that is part of the early motivation for the EU FINREAD terminal standard.
http://www.garlic.com/~lynn/subpubkey.html#finread

FINREAD moved authentication out of vulnerable PCs into a trusted authentication environment as well as providing mechanism for supporting transaction-based authentication (each transaction/operation is explicitly authentication) as opposed to just simple session authentication (with possibly encryption wrapper for security).

The recent discussion is that if you have a separate trusted authentication environment for authentication (based on digital signature authentication) then there are some additional benefit to relying parties to also have the trusted authentication environment also digitally signing the operation (so the relying party has some proof that a trusted authentication environment was in use as opposed to some compromised/counterfeit authentication environment).
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures

with respect about to earlier comment about having a token that requires a digital signing hardware token to have correct (human) PIN entry .... would allow a relying party to be able to associate a specific digital signature with some human operation (PIN entry), if the relying party had some way of knowing that the hardware token being used, in facted, required PIN entry.

Issues addressed by the EU finread terminal standard was to eliminate PC virus/trojan from logging the PIN value and then replaying the PIN values to the hardware token (w/o the users knowledge). The EU finread terminal standard provided from a countermeasure to the PC virus/trojan replaying PIN entries. However, the EU finread terminal standard didn't actually require the terminal to also digitally sign the transaction (providing an indication to the relying party that an finread terminal was actually being used ... as opposed to some counterfeit environment). For financial transactions, the terminal also displayed the value of the transaction being sent to the token for signing (as countermeasure to virus/trojan displaying values different than what are in the actual transaction)

There is an issue with the relying party knowing the operational characteristics of the hardware token being used for a digital signature (w/o which the relying party has no mechanism to know whether PIN-entry was even required ... or even if a hardware token is being used). The relying party having knowledge of the hardware token operational characteristics allows for some evaluation of whether it was actual simple one-factor authentication ("something you have") ... or if possibly additional authentication factors were involved (multi-factor authentication).

There is also an issue with the relying party having knowledge of the operational characteristics of any kind of terminal (or other digital signing environment) that also digitally signs the operation. This provides the relying party with basis for doing further trust evaluation (like whether there was possibility that virus/trojan entered the PIN).

Finally with respect to comment about associating PIN-entry with indication of any "human intent" (read, understood, approves, aggress, and/or authorizes)
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures

The relying party having knowledge of the hardware token may have some basis for assuming that the digital signature implies that (the correct) PIN was entered. Having the 2nd digital signature from the terminal provides some basis for assuming that the PIN entry actually involved human interaction. That ties the token's digital signature to some human interaction. However, there is still no tie between the human interaction and read, understood, approves, aggrees, and/or authorizes.

However, if the relying party has knowledge of the terminal environment (that also digitally signs the operation), then there may be some basis for assuming that the terminal had displayed a message requesting the person to enter their PIN if they agreed with the operation (and critical pieces of the transaction is also displayed), and that the PIN was entered after the message was displayed. There is now some basis for the relying party to assume that the human interaction (PIN entry) was in response asking if the person agreed.

Early in the AADS chip strawman
http://www.garlic.com/~lynn/index.html#aads

and X9.59 work,
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

we realized that transactions needed to be directly signed, that it should be possible for the digital signing (terminal) environment to also sign the transactions, and that the relying party needed to have access to both the token operational characteristics as well as any terminal environment operation characteristics (in order to correctly interpret and evaluate any meaning attached to the digital signatures ... as well as dynamic adaptive risk assesement).

this was one of the issues over the years involving the "yes card" technology ... the token is authenticated separately from the transaction operations ... opening various kinds
of mitm-attacks
http://www.garlic.com/~lynn/subpubkey.html#mitm
or various kinds of other end-point vulnerabilities. some recent postings on "yes card" technology
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views
http://www.garlic.com/~lynn/aadsm22.htm##41 FraudWatch Chip&PIN

and is the issue in the SSL-evading trojans:
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

again, another example where the end-point is authenticated separately from the actual operations ... creating additional cracks and vulnerabilities that may be exploited (MITM-attacks and/or interception and modification).

of course, in the AADS model ... the relying party could obtain online access to all of this information for correctly interpreting digital signatures ... in a digital certificateless paradigm
http://www.garlic.com/~lynn/subpubkey.html#certless

we also talked to some of the people behind the X.509V3 digital certificate work and pointed out that such useful integrity information might be significantly more interesting to a relying party than anything that might be found a CPS statement.

Posted by: Lynn Wheeler at May 5, 2006 03:52 PM

another on the subject:

Trusted Web Sites Not Always Trustworthy, Says Noted Computer Security Researcher
http://biz.yahoo.com/prnews/060505/sff027.html?.v=48

with respect to today's news articles on chip&pin fraud
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17

a post in the original thread
http://www.garlic.com/~lynn/aadms22.htm#40 FraudWatch - Chip&Pin

about chip&pin not being useable on the Internet because of vulnerabilities ... possibly similar skimming related vulnerabilities (for replay attacks).

Note that some of the vulnerabilities mentioned in this thread are similar to those faced when deploying corporate vpn for access by traveling and at-home employees.

some of this first showed up when employees would attach dial-up modems to their PCs and work and dial the internet. these PCs (when also connected to the internal corporate intra-net) allowed attackers to bridge attacks thru the dial-up connection, bypassing the corporate firewalls.

later with off-site VPN connections, the remote employee PCs required an internet connection in order to tunnel the VPN connection into the corporate network. Lots of personal PC VPN software added all sorts of countermeasures attempting to keep attackers from using the PC to bridge into the corporate network (bypassing corporate firewalls).

a lot of these corporate VPN-related countermeasures (attempting to prevent attackers from using employee's PC internet connection to bridge into the corporate network) ... have been specifically directed at virus/trojan related vulnerabilities.

Posted by: Lynn Wheeler at May 6, 2006 10:48 AM

Perhaps its time for people to start avoiding hotel chains.

Recently I decided to spend the weekend in an upscale resort community in the U.S. When I had reduced the number of candidates to only a few I called to find out price and availability. While I had the local reservation person (often the hotel clerk on duty) on the phone I inquired if I could pay for the deposit by money order and the room bill in cash, as I had grown wary of being tracked in commercial data bases. To my surprise most agreed. One hotel clerk expressed the same concerns. He even promised to place a 72-hour hold on room (I was making the reservation well in advance of occupancy) in order for my money order to arrive by post. Now if only the money order could be digital and available for immediate deposit by the hotel that would be a big advantage...

One innovative payment service in the U.S. is 'My ICIS' http://www.myicis.com/ They allow clients to create and maintain pseudonymous accounts from which they can issue electronic money orders. These MOs can be printed on an ordinary ink jet, trimmed to appropriate size of a standard check and deposited into a consumer or commercial account along with other checks and cash. Self-printed checks can occasionally raise some eyebrows at the teller but are perfectly legal. Its not recommended that they be deposited via an ATM. Banks often send ATM deposits to an automated processing center which can reject checks that do not have the bank routing information printed in magnetic ink (even if they are legal under Federal Clearinghouse rules). My ICIS accounts can be funded via e-gold.

Virtual credit cards, depending upon how they are funded may also be a privacy advocate's friend in these and similar situations.

For those who missed the subtle news, the 'defeat' of John Gilmore's suit against the FAA, Homeland Security and Southwest airlines, that insisted passengers present a government-issued ID before being allowed through airport security checkpoints and to board, was in some ways a victory. The judge ruled that passengers could not be required to show ID if they submitted to a more through inspection (what is commonly called being a 'Selectee').

Posted by: Steve at May 10, 2006 11:56 AM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.