[UNIX] OpenBSD Radius Authentication Vulnerability

From: SecuriTeam (support_at_securiteam.com)
Date: 09/22/04

  • Next message: SecuriTeam: "[UNIX] glFTPd Local Stack Buffer Overflow" 
    To: list@securiteam.com
Date: 22 Sep 2004 11:28:30 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      OpenBSD Radius Authentication Vulnerability
    ------------------------------------------------------------------------

    SUMMARY

    When using radius authentication on OpenBSD it is possible to login on the
    OpenBSD when traffic from the radius-server can be spoofed. Since radius
    uses UDP, this is not hard to do. Radius authentication is not enabled by
    default on OpenBSD.

    When connecting to an OpenBSD machine that does radius authentication when
    configured in /etc/login.conf (see man(5) login.conf and man(8)
    login_radius), the OpenBSD machine will ask for userid and password. This
    userid and password is sent to the radius server. The radius-server will
    respond with either an 'REJECT' or 'ACCEPT'. More information on the
    protocol can be found in RfC 2865.

    DETAILS

    Vulnerable Systems:
     * OpenBSD version 3.2
     * OpenBSD version 3.5

    Immune Systems:
     * OpenBSD version 3.6

    Background:
    From this RfC, Chapter 7.1:
     ================================
    The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS
    Server for a user named nemo logging in on port 3 with password
    "arctangent".

    The Request Authenticator is a 16 octet random number generated by the
    NAS.

    The User-Password is 16 octets of password padded at end with nulls, XORed
    with MD5(shared secret|Request Authenticator).

          01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
          98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
          93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
          01 10 05 06 00 00 00 03

           1 Code = Access-Request (1)
           1 ID = 0
           2 Length = 56
          16 Request Authenticator

          Attributes:
           6 User-Name = "nemo"
          18 User-Password
           6 NAS-IP-Address = 192.168.1.16
           6 NAS-Port = 3

    The RADIUS server authenticates nemo, and sends an Access-Accept UDP
    packet to the NAS telling it to telnet nemo to host 192.168.1.3.

    The Response Authenticator is a 16-octet MD5 checksum of the code (2), id
    (0), Length (38), the Request Authenticator from above, the attributes in
    this reply, and the shared secret.

          02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
          9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
          0e 06 c0 a8 01 03

           1 Code = Access-Accept (2)
           1 ID = 0 (same as in Access-Request)
           2 Length = 38
          16 Response Authenticator

          Attributes:
           6 Service-Type (6) = Login (1)
           6 Login-Service (15) = Telnet (0)
           6 Login-IP-Host (14) = 192.168.1.3

    Technical details:
    Since the Response Authenticator in the reply uses ther Request
    Authenticator from the request, the client must be able to verify the
    'origin', it should have a corresponding request pending.

    This is where it fails. Eilko Bos used the following setup:
            [--- LAN
    ----------------------------------------------------------]
                     | | |
                     | | OpenBSD | Radius-
                   [ ] client [ ] server [ ] Server
                10.10.1.3 10.10.1.2 10.10.1.1

    Step 1-3 is preparation phase.
    1) Setup an environment where radius login is used and that you control.

    2) Login via radius, sniff the packets and save the 'ACCEPT' packet.

    3) Transform the 'ACCEPT'-packet data so it can be used by e.g. socat or
    hping.

    4) From the client, login to the OpenBSD server. The OpenBSD server will
    send a REQUEST to the radius-server, and awaits an answer. You can either
    use arp-spoofing to let the OpenBSD server think another machine you have
    control of is the radius-server (assuming local network) or you must use a
    perfect timing, spoofing a packet w/ the correct source- and dest.
    portnumbers

    5) You can either use arp-spoofing to let the OpenBSD server think
    another machine you have control of is the radius-server (assuming local
    network) or you must use a perfect timing, spoofing a packet w/ the
    correct source- and dest. portnumbers. Send the ACCEPT packet. This can
    be done w/ e.g. socat or hping. OpenBSD will use the ACCEPT-packet and
    grant login.

    In the above scenario's, you don't need to know the shared secret (as you
    would have to when setting up another radius-server) nor the password of
    the account you use for logging in.

    Sample messages from not-vulnerable systems:
    With FreeBSD 5.2.1, the following message is logged:
    Aug 31 11:40:39 server login: rad_send_request: No valid RADIUS responses
    received

    With Fedora Core2/pam_radius_auth.so
    (http://www.freeradius.org/pam_radius_auth/) the following message is
    logged:
    10.10.1.1 fails verification: The shared secret is probably incorrect.

    Disclosure Timeline:
    10-09-2004 Informed the OpenBSD crew at 21:19 CEST
    11-09-2004 Received patch at 02:30 CEST

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:E.Bos@reseau.nl> Eilko Bos,
    Le Reseau B.V.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[UNIX] glFTPd Local Stack Buffer Overflow"

    Relevant Pages