SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   OS (UNIX)  >   OpenBSD Kernel Vendors:   OpenBSD
OpenBSD login_radius() Authentication Error Lets Remote Users Login to the System
SecurityTracker Alert ID:  1011377
SecurityTracker URL:  http://securitytracker.com/id/1011377
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Updated:  Sep 21 2004
Original Entry Date:  Sep 21 2004
Impact:   User access via network
Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 3.5 and prior versions
Description:   An authentication vulnerability was reported in OpenBSD's login_radius(8) RADIUS authentication implementation. A remote user can bypass authentication in certain cases.

Eilko Bos reported that a remote user with the ability to spoof responses from a RADIUS server to the target OpenBSD server can successfully authenticate to the target server without authentication credentials.

A remote user can can request authentication and then spoof the RADIUS server's response with a valid ACCEPT packet obtained from an arbitrary RADIUS server. The target OpenBSD server will reportedly authenticate the spoofed packet, even though the shared secret is not correct and the password is not correct.

Only systems that are configured in '/etc/login.conf' to perform RADIUS authentication (which is not the default configuration) are affected.

Impact:   A remote user can authenticate to the system without having authentication credentials.
Solution:   The vendor has issued a fix in OpenBSD-current, OpenBSD 3.6, and the 3.4 and 3.5 -stable branches. Patches are also available for OpenBSD 3.4 and 3.5 at:

ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.4/common/031_radius.patch
ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.5/common/020_radius.patch

Vendor URL:  www.openbsd.org/ (Links to External Site)
Cause:   Authentication error

Message History:   None.


 Source Message Contents

Subject:  [VulnWatch] OpenBSD radius authentication vulnerability


Title: OpenBSD radius authentication vulnerability

Summary:        Authentication can be bypassed when radius-authentication is
                used on OpenBSD.

Impact:         Unauthorized access to the system

Software:       OpenBSD 3.2 and OpenBSD 3.5 confirmed vulnerable.

Workarounds:
        1) Place the Radius server on an isolated lan so that only the system
           (radius-client) can reach it.
        2) Don't use radius login.

Solutions:
        - Apply the patch released by OpenBSD.

        OpenBSD 3.6 will ship with this fixed.


Description:    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 authen-
        tication 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.


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

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

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

Author:         Eilko Bos, Le Reseau B.V.

-- 
Le Reseau B.V.
Bieslookstraat 31
9731HH  Groningen, Netherlands
Telefoon: +31 505497014	Fax: +31 505492310	Internet: http://www.reseau.nl

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC