- From: Chris Drake <christopher@pobox.com>
- Date: Thu, 6 Jul 2006 14:00:42 +1000
- To: "James A. Donald" <jamesd@echeque.com>
- CC: spam filter <spam+w3c@jeff-nelson.com>, public-usable-authentication@w3.org
Hi James,
I'll try and get my list on a Wiki soon. Meanwhile, let me know if my
update didn't address your issues...
JAD> Notably missing from your list is cross site scripting and session
JAD> fixation attacks...
Great point! The "old" definition of XSS was when folks used frames
and such to exploit browser oversights, which I think are problems now
largely plugged? My understanding of the only thing left would be ...
6.18. preventing foreign script in web site context (eg: cookie
theft, bogus injected login screens on live site, etc)
6.19. input data sanitization. eg: - someone typing this in a
"name" input box: <script>alert(document.cookie)</script>
6.20. output data sanitization - eg - not allowing this to be
printed in a form value= field without escaping the quotes
' onclick='alert(document.cookie
2.10. Exploiting outdated technology - eg: old browsers allowing
frames from site A to read content in site B.
4.9. people using outdated older technology (see 2.10)
2.11. undismissable download dialogues (eg: active-X) - see 3.3
eg: 6.20 the above becomes:-
<input type=hidden name=foo value='' onclick='alert(document.cookie'>
from the careless cgi:-
$val=&dblookup("foo"); # i.e. "' onclick="alert(document.cookie'";
print "<input type=text name=foo value='$val'>";
Shoulder surfing is not an issue because we all see dots or "****"
when we type passwords in - however - my own internet banking has
forced us all to use an online keypad (to block keyloggers) thus
making it impossible for me to log in whenever anyone is around me:
this is a surprisingly common occurrence that you probably don't notice
because *currently* your password is "***" protected, but this threat
needs to be in my list because careless people don't understand just
how far "backwards" they can push things when they decide not to do
this anymore... Anyone knowing I use the bank I do (eg: a
co-worker), is now given extra incentive to "social engineer" me into
logging in while in their presence, since it's so easy to see my
username and password on my screen when I do this!
1.4.1 through 1.4.3 listed known *purposes* of typographic attacks
(not the actual attacks - 1.4 is the actual typo attack)
1.5. Not many people think "chrome" will solve anything - the movement
is towards customer secrets right now, given this fact.
I do think a "standard login" might be helpful, but I doubt it's
something we can expect all browser vendors to simultaneously
implement and then all users to upgrade to within any useable
timeframe. That said - I do *not* see any reason why this has to be
limited to the browser - web services can do this just as well.
Kind Regards,
Chris Drake
Thursday, July 6, 2006, 12:48:20 PM, you wrote:
JAD> --
JAD> Chris Drake wrote:
>> 1. Confidence Tricks
>>
>> 1.1. phishing emails
>> 1.1.1. to lure victims to spoof sites
>> 1.1.2. to lure victims into installing malicious code
>> 1.1.3. to lure victims towards O/S vulnerabilities to inject
>> malicious code
>> 1.1.4. to lure victims into revealing information directly via
>> reply or via embedded FORMS within the email
>>
>> 1.2. telephone phishing
>> 1.2.1. to directly extract auth info
>> 1.2.2. to direct victim to spoof site
>>
>> 1.3. person-to-person phishing / situation engineering
>> 1.3.1. to directly extract auth info (ask)
>> 1.3.2. to direct victim to spoof site
JAD> All of these rely both on impersonation, AND on users being trained to
JAD> reveal shared secrets on demand in a wide variety of contexts and
JAD> environments. So we need to both make impersonation difficult, and also
JAD> reduce this unilateral revelation of widely shared secrets, reduce this
JAD> use of widely shared secrets.
>> 1.3.3. shoulder surfing (aka 4.5.2)
>> 1.3.4. physical attack - see 4.7
JAD> These attacks are rare, because people are instinctively on guard
JAD> against them - observe behavior at ATMs. ATM shoulder surfing tends to
JAD> be resisted so forcefully that there is no sharp line between ATM
JAD> shoulder surfing and ATM mugging. It is more a martial arts problem
JAD> than a software engineering problem.
>> 1.4. typographic attacks
>> 1.4.1. spoofing (eg: paypa1.com - using a number 1 for a little L)
>> 1.4.2. direct download of malicious code
>> 1.4.3. browser exploit injection
JAD> The classic instance of browser exploit injection was a bug in the
JAD> Microsoft image viewer that allowed a carefully crafted image to contain
JAD> assembly code that the image viewer would execute with the full
JAD> authority of the user. I don't see that this constitutes a "typographic
JAD> attack"
>> 1.5. online phishing
>> 1.5.1. pop-up/pop-behind windows to spoof sites
>> 1.5.2. floating <DIV> or similar elements (eg: emulating an entire
>> browser UI)
JAD> Untrusted and possibly hostile data should not have sufficient authority
JAD> over the viewer's display to do this - the concept of "secure chrome" is
JAD> largely about preventing this attack.
JAD> Related attacks resulting from excess authority over the viewer display
JAD> are those porn sites that will not let you leave - every time you close
JAD> one popup, two more are spawned.
JAD> A more malevolent attack using the same principle (excess authority over
JAD> the display) is the web page that *insists* you download and execute an
JAD> active X component, and sits in your face, until you do so, refusing to
JAD> be dismissed. Supposedly the function of the Active X component is to
JAD> allow you to view the web page correctly, but in practice, it usually
JAD> uses your modem to auto dial an extremely expensive sex talk line in
JAD> some foreign country, one whose topic is as embarrassing as possible to
JAD> discourage the victim from creating a fuss, and/or takes over your
JAD> computer for a zombie net.
>> 2. Remote Technical Tricks
>>
>> 2.1. spoof techniques
>> 2.1.1. vanilla fake look-alike spoof web sites
>> 2.1.2. CGI proxied look-alike web site (server CGI talks to real
>> site in real time - "man in the middle attack")
>> 2.1.3. popup windows hiding the address bar (3.4.1/3.4.2)
>> 2.1.4. <DIV> simulated browsers (1.5.2)
>>
>> 2.2. iframe exploits (eg: 1.5.1/1.1.3) (spammers buy iframes to
>> launch 1.5 and 1.4 attacks)
>> 2.3. p2p filesharing publication of products modified to
>> remove/limit protection - PGP, IE7, Mozilla, ...
>> 2.4. DNS poisoning (causes correct URL to go to spoof server)
>> 2.5. traffic sniffing (eg: at ISP, telco, WiFi, LAN, phone tap...)
>> 2.6. proxy poisoning (correct URL returns incorrect HTML)
>> 2.7. browser exploits (correct URL returns incorrect HTML)
>> 2.8. targeted proxy attack
>> 2.8.1. directs to vanilla spoof web site (2.1.1)
>> 2.8.2. uses CGI re-writing to proxy legitimate site (eg: convert
>> HTTPS into HTTP to activate traffic sniffing) (2.1.2)
>> 2.8.3 activates 5.7
>> 2.9. Authorized exploitation - see 3.5.
>>
>>
>> 3. Local Technical Tricks
>>
>> 3.2. Software vulnerabilities (aka exploits - eg - 1.1.3)
>> 3.1.1. Known
>> 3.1.2. Unknown
>>
>> 3.2. Browser "toolbars" (grant unrestricted DOM access to SSL data)
>>
>> 3.3. Trojans
>> 3.3.1. Standalone modified/hacked legitimate products (eg: PGP or
>> a MSIE7) with inbuilt protection removed/modified.
>> 3.3.2. Bogus products (eg: the anti-spyware tools manufactured by
>> the Russian spam gangs)
>> 3.3.3. Legitimate products with deliberate secret functionality
>> (eg: warez keygens, sony/CD-Rom music piracy-block addins)
>> 3.3.4. Backdoors (activate remote control and 3.4.1/3.4.2)
>>
>> 3.4. Viruses
>> 3.4.1. General - keyloggers, mouse/screen snapshotters
>> 3.4.2. Targeted - specifically designed for certain victim sites
>> (eg paypal/net banking) or certain victim actions (eg:
>> password entry, detecting typed credit card numbers)
>>
>> 3.5. Authorized exploitation (authority (eg: Microsoft WPA/GA,
>> Police, ISP, MSS, FBI, CIA, MI5, Feds...) engineer a Trojan or
>> Viral exploit to be shipped down the wire to local PC,
>> potentially being legitimately signed/authenticated software.)
>>
>> 3.6. Visual tricks
>> 3.6.1. browser address bar spoofing
>> 3.6.2. address bar hiding
>>
>> 3.7. Hardware attacks
>> 3.7.1. keylogger devices
>> 3.7.2. TEMPEST
>> 3.7.3. malicious hardware modification (token mods, token
>> substitution, auth device substitution/emulation/etc)
>>
>> 3.8. Carnivore, DCS1000, Altivore, NetMap, Echelon, Magic Lantern,
>> RIPA, SORM...
>>
>> 4. Victim Mistakes
>>
>> 4.1. writing down passwords
>> 4.2. telling people passwords
>> 4.2.1. deliberately (eg: friends/family)
>> 4.2.2. under duress (see 4.7)
>> 4.3. picking weak passwords
>> 4.4. using same passwords in more than one place
>> 4.5. inattentiveness when entering passwords
>> 4.5.1. not checking "https" and padlock and URL
>> 4.5.2. not preventing shoulder surfing
>> 4.6. permitting accounts to be "borrowed"
>> 4.7. physical attack (getting mugged)
>> 4.7.1. to steal auth info
>> 4.7.2. to acquire active session
>> 4.7.3. to force victim to take action (eg: xfer money)
>> 4.8. allowing weak lost-password "questions"/procedures
>>
>>
>> 5. Implementation Oversights
>>
>> 5.1. back button
>> 5.2. lost password procedures
>> 5.3. confidence tricks against site (as opposed to user)
>> 5.4. insecure cookies (non-SSL session usage)
>> 5.5. identity theft? site trusts user's lies about identity
>> 5.6. trusting form data
>> 5.7. accepting auth info over NON-SSL (eg: forgetting to check
>> $ENV{HTTPS} is 'on' when performing CGI password checks)
>> 5.8. allowing weak lost-password "questions"/procedures
>> 5.9. replay
>> 5.10. robot exclusion (eg: block mass password guessing)
>> 5.11. geographical exclusion (eg: block logins from Korea)
>> 6.12. user re-identification - eg - "We've never seen you using
>> Mozilla before"
>> 6.13. site-to-user authentication
>> 6.14. allowing users to "remember" auth info in browser (permits
>> local attacks by unauthorised users)
>> 6.15. blocking users from being allowed to "remember" auth info in
>> browser (facilitates spoofing / keyloggers)
>> 6.16. using cookies (may permit local attacks by unauthorised
>> users)
>> 6.17. not using cookies (blocks site from identifying malicious
>> activity or closing co-compromised accounts)
>>
>>
>> 6. Denial of Service attacks
>>
>> 6.1. deliberate failed logins to lock victim out of account
>> 6.2. deliberate failed logins to acquire out-of-channel subsequent
>> access (eg: password resets)
JAD> Notably missing from your list is cross site scripting and session
JAD> fixation attacks - which are flaws in web sites, rather than flaws in
JAD> the internet protocols and architecture. Each particular website has
JAD> all the tools it needs to create web sites that resist session fixation
JAD> and cross site scripting, but they usually do not, and it is in fact
JAD> hard to build a large site that does not contain bugs that allow session
JAD> fixation and/or cross site scripting. The cure lies in in fixing the
JAD> tools with which web sites are programmed - in fixing the languages in
JAD> which web sites are programmed to make this kind of error less likely.
JAD> Also, if a standard login mechanism was built in the browser and/or
JAD> operating system, instead of each website rolling their own, they would
JAD> be less likely to roll their own wrongly. Built in login would take
JAD> care of 99.9% of session fixation attacks, and most cross site scripting
JAD> attacks.
JAD> --digsig
JAD> James A. Donald
JAD> 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
JAD> X4W475db7hpev0naSKV4sqlWhxanEd3CZFzJJoks
JAD> 4i+VSGjfZ0WyxW3/FPQ9odEHjkUXcH4KCmwZmCI9O
Received on Thursday, 6 July 2006 04:01:07 UTC