Re: Fringe: e-banking not yet secure

[macwheel99 () wowway com]

Here is link to "Analyzing Web sites for user-visible security design flaws" 
by 3 authors: The professor & 2 graduate students.
http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf

The financial institutions that they studied
http://www.eecs.umich.edu/laura/webusability/websites.html

This paper is to be presented at the Symposium on Usable Privacy and 
Security (SOUPS) meeting at Carnegie Mellon University July 25.  
http://cups.cs.cmu.edu/soups/2008/

According to this other article, the study was done in 2006. Presumably (we 
would hope) some of the financial institutions have since upgraded their 
sites. http://www.eurekalert.org/pub_releases/2008-07/uom-sfi072208.php 

Relevant links here. http://news.yahoo.com/s/cmp/209600041

I originally saw the link on e-com sec & thought it also belonged on Data 
Loss, and Linked-In's Security before Implementation (I have not yet posted 
it there). http://packetfocus.com/proactive/index.php

Al Macintyre
Jack of all trades, master of some


security curmudgeon wrote
> ISN posted the article as well, cross-posting my reply.
>
> : Security flaws plague majority of e-banking sites 
> : http://www.finextra.com/fullstory.asp?id=18764
> : 
> : Over 75% of banking Web sites contain fundamental design flaws 
> that : could put customers at risk from cyber thieves, according to 
> a study (of : 214 bank web sites)conducted by researchers at the 
> University of : Michigan.
>
> Unfortunately, all I can find are articles mentioning the study. It 
> still isn't available on Atul Prakash's home page [1]. Since all we 
> have to go on right now are sound bytes and brief summaries, it is 
> very easy to tear large holes in the results. I encourage Prakash 
> and his team to make the original research more readily available.
>
> : The flaws are not bugs that can be easily fixed with a patch, but 
> are : systemic, stemming from the flow and layout of the sites.
>
> The flaws are often very easy to fix, and do not require much 
> work from the bank.
>
> : 47% placed secure login boxes on insecure pages.
>
> While a bad practice, this doesn't translate to "attackers can get 
> access to customer information" necessarily. "He says this allows 
> hackers to re-route data entered in the boxes or create a spoof page 
> to harvest information." First, to re-route data entered in the 
> boxes relies on something more than a mixed HTTP/S page. Exploiting 
> cross-frame scripting in some browsers would be a good idea, but 
> that can be blocked regardless of the page being served over SSL. 
> Second, bad guys can spoof pages regardless of the presence of SSL,
>  yet Prakash suggests otherwise.
>
> "Prakash says in a wireless situation, it's possible to conduct this 
> man-in-the-middle attack without changing the bank URL for the user, 
> so even a vigilant customer could fall victim."
>
> Certainly a risk, but the amount of customers accessing their bank 
> over unsecured wireless are probably very minimal and changes the 
> requirements of exploitation considerably.
>
> : 55% put contact information and security advice on insecure pages.
>
> Again, having a static /contact.html on the legitimate domain, not 
> served over SSL is not a vulnerability, and does not lead to 
> customers being at risk from "hackers getting access to customer 
> information". The summary and introduction to the article is poorly 
> worded and misleading.
>
> : Some banks use social security numbers or e-mail addresses as user 
> IDs.
>
> This is definitely a bad practice and commonly seen, but this is 
> half of the information needed to authenticate. Brute forcing a list 
> of login IDs is time consuming, brute forcing valid passwords for 
> them on top of that is very time consuming. There are certainly 
> controls that can be put in place to make harvesting attacks more 
> costly, regardless of the login name scheme.
>
> : 28% don't state a policy on passwords, or allow weak passwords.
>
> Yes, they should state their policy, but how many of the 28% don't 
> state the policy yet enforce a relatively strong one? This number is 
> a poor metric.
>
> I have a hard time believing that Prakash and his team got 
> permission to test 214 bank web sites. If they did, it was still 
> done without authentication based on the results in the article. The 
> few results they do have are not near the risk implied by the 
> summary wording or have caveats on exploitation. None of them are 
> real eye-openers as each one would likely result in the compromise 
> of a handful of accounts. While certainly bad, that is insignificant 
> compared to an SQL injection or privilege escalation attack that 
> allowed cross-user information disclosure 
> (or manipulation).
>
> All said and done, this research is quite limp so far.
>
> - jericho

_______________________________________________
Dataloss Mailing List (dataloss () attrition org)
http://attrition.org/dataloss

Tenable Network Security offers data leakage and compliance monitoring
solutions for large and small networks. Scan your network and monitor your
traffic to find the data needing protection before it leaks out!
http://www.tenablesecurity.com/products/compliance.shtml