FreeRADIUS allows hackers to log in without credentials

Pierluigi Paganini May 30, 2017

The security researcher Stefan Winter has discovered a TLS resumption authentication bypass in FreeRADIUS, the world’s most popular RADIUS Server.

The security researcher Stefan Winter from the Luxembourg’s high-speed academic network RESTENA has discovered a FreeRADIUS TLS resumption authentication bypass.

FreeRADIUS is the world’s most popular RADIUS Server, “it is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs. It is also widely used for Enterprise Wi-Fi and IEEE 802.1X network security, particularly in the academic community, including eduroam.

FreeRADIUS

The flaw, tracked as CVE-2017-9148, resides in the TTLS and PEAP implementations that skip inner authentication when handles a resumed TLS connection.

“The implementation of TTLS and PEAP in FreeRADIUS skips inner authentication when it handles a resumed TLS connection. This is a feature but there is a critical catch: the server must never allow resumption of a TLS session until its initial connection gets to the point where inner authentication has been finished successfully. Unfortunately, affected versions of FreeRADIUS fail to reliably prevent resumption of unauthenticated sessions unless the TLS session cache is” reads the description published in the advisory states. “disabled completely and allow an attacker (e.g. a malicious supplicant) to elicit EAP Success without sending any valid credentials.”

Communications interruptions are very frequent, for example when a user on a TLS connection moves from one cell tower to another, and in due to the flaw it isn’t asked for a new login.

The versions affected by the CVE-2017-9148 flaw are:

  • 2.2.x (EOL but still found in some Linux distros): All versions.
  • 3.0.x (stable): All versions before 3.0.14.
  • 3.1.x and 4.0.x (development): All versions before 2017-02-04.

Sysadmins that works with FreeRADIUS installs need to upgrade to the version 3.0.14 that fixed the issue, temporary mitigation could be obtained by disabling the TLS session caching.

The advisory suggested the following mitigation actions

  • (a) Disable TLS session caching. Set enabled = no in the cache subsection of eap module settings (raddb/mods-enabled/eap in the standard v3.0.x-style layout).
  • (b) Upgrade to version 3.0.14.

Giving a look at the timeline of the flaw we can notice that is was also independently reported April 24, 2017, by the researchers Luboš Pavlíček from the University of Economics, Prague.

[adrotate banner=”9″]

Pierluigi Paganini

(Security Affairs – CVE-2017-9148, FreeRADIUS)

[adrotate banner=”13″]



you might also like

leave a comment