Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:2179
HistoryNov 14, 2001 - 12:00 a.m.

more RADIUS authentication attack scenarios

2001-11-1400:00:00
vulners.com
49

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)