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)
This archive was generated by hypermail 2b30 : Wed Nov 14 2001 - 14:24:07 PST