more RADIUS authentication attack scenarios

[3APA3A <3APA3A () SECURITY NNOV RU>]

Hello bugtraq,

  There  is also problem with some vendor-specific RADIUS authentication
  implementation.  For  example  Microsoft  has it's specific attributes
  defined  in  RFC  2548.  These  attributes allow MS-CHAP and MS-CHAPv2
  authentication via RADIUS.

  There  is  design  flow in this authentication scenario which makes it
  vulnerable against M-i-t-M attack.

  As it was said before RADIUS uses some cryptographic schema to encrypt
  User-Password  or CHAP-Password attribute by XORing it with MD5 digest
  obtained from message authenticator and shared secret.

  Microsoft   doesn't   use   same  trick  for  it's  MS-CHAP-Challenge,
  MS-CHAP-Response  and  MS-CHAP2-Response  attribute.  This  fact opens
  possibility  of  both  replay  and  spoof  attack  against MS-CHAP and
  MS-CHAPv2  authentication.  The  only things attacker need to know are
  packet  authenticator  and  MS-CHAP  attributes  of  any  successfully
  authenticated packet (or _any_ valid user account).

  Scenario:

  1.  Attacker  logs  in  to  NAS  with desired account+invalid password
  (user1 + wrong password)
  2. NAS sends authentication packet to RADIUS
  3. Attacker  changes  MS-CHAP attributes (this can be attributes from
  sniffed  packet,  that  is  MS-CHAP-Challenge + Response from previous
  user1  logon  or  attacker can use attributes of known account, may be
  guest).
  4. RADIUS  authenticates  packet  based  on  attributes  provided  by
  attacker and sends Access-Accept to NAS.
  5. NAS logons attacker as user1

  MS-CHAPv2 is also vulnerable in same scenario.

  If  NAS  has weak PRNG and it's possible to guess packet authenticator
  blindly this attack can be turned from M-i-t-M to remote.

  Note:  this  is  not a software bug, this is design flow. This flow is
  not  in  MS-CHAP  (which is vulnerable to M-i-t-M attack itself) or in
  MS-CHAPv2 (which is immune to M-i-t-M). The flow is in the way MS-CHAP
  attributes are used in RADIUS. This way is defined in RFC 2548.

  RADIUS itself is vulnerable to same attack, in some cases it may allow
  privilege escalation: for example user with only PPP access to NAS can
  try  to  login  to NAS via telnet and change Service-Type attribute of
  Access-Request  packet  from  Login  to  Framed to be authenticated by
  RADIUS.  Everything  depends on RADIUS and NAS configuration (the good
  practice   for   RADIUS   server  is  always  send  back  Service-Type
  attribute). If Access-Accept doesn't contain Service-Type attribute or
  NAS doesn't check it - user will be logged via telnet.

  
  P.S. I think RADIUS must be treated as unsecure protocol, like LDAP or
  SNMP, and never intended to be secure because of sensitive information
  sent  in  cleartext. The perfect solution about RADIUS is to use it in
  conjunction with IPSec, if RADIUS traffic cross untrusted network.


  
-- 
http://www.security.nnov.ru
         /\_/\
        { . . }     |\
+--oQQo->{ ^ }<-----+ \
|  ZARAZA  U  3APA3A   }
+-------------o66o--+ /
                    |/
You know my name - look up my number (The Beatles)