Computer Security
[EN] no-pyccku

Related information

  RADIUS protocol and implementation weakness

  Re: More problems with RADIUS (protocol and implementations)

  More problems with RADIUS (protocol and implementations)

  An Analysis of the RADIUS Authentication Protocol

From:3APA3A <3APA3A_(at)>
Subject:more RADIUS authentication attack scenarios

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).


 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
 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.

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

About | Terms of use | Privacy Policy
© SecurityVulns, 3APA3A, Vladimir Dubrovin
Nizhny Novgorod