bugtraq - Re[5]: RSA SecurID SID800 Token vulnerable by design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 11 Sep 2006 20:16:35 +0400
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: "Brian Eaton" <eaton.lists@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re[5]: RSA SecurID SID800 Token vulnerable by design

Dear Brian Eaton,

--Monday, September 11, 2006, 7:35:08 PM, you wrote to 3APA3A@...urity.nnov.ru:

>> It means, if authentication schema is NTLM-compatible (it must be for
>> compatibility   with   pre-Windows   2000   hosts  and  some  network
>> applications,  like  Outlook  Express),  attacker can use compromised
>> account to access network resources without having access to 2-factor
>> authentication  device. How long he can retain this access depends on
>> how  often account's NT key is changed (usually with password change,
>> but  actually  depends on implementation of authentication system and
>> may be never).

BE> Is this RSA whitepaper an example of what you are talking about?

BE> http://tinyurl.com/pb5n7

BE> The whitepaper refers to Kerberos tickets, but the mechanism sounds
BE> like it could work with NTLM as well.

BE> I think the situation you are pointing out is where an authentication
BE> process requires an initial two-factor authentication, but then issues
BE> some kind of session key that takes a very long time to expire. That
BE> would seem to defeat the purpose of the two-factor auth.

In  case  of  Kerberos  authentication there is also "session key" (TGT)
which  is  issued  by  default  for  10  hours. But Kerberos controls IP
address of the client, it reduces the impact of ticket stealing. In case
of  NTLM,  this  control  is  impossible,  because  domain controller is
contacted by server, not by client.

Regarding NTLM support it's not absolutely clear, but according to this:

-=-=-=-=-=- quote

 In this scenario, the first time end users are asked to RSA SecurID authenticate to
Microsoft Windows, users are asked for their Windows password.  The RSA ACE/Sever 
software captures and stores it.  From then on, RSA Authentication Manager software 
provides the Windows password to the Windows login process for the end user who does 
not need to enter it. 

-=-=-=-=-=-

NT  key  is  probably  generated  and used by SecurID. And probably it's
worst  possible  case:  NT  key  is derived from windows password and is
never changed. Of cause, it needs to be checked. If NTLM works (e.g. you
can connect to file server behind NAT or through mapped port) - it is.

-- 
~/ZARAZA
http://www.security.nnov.ru/