Radiator used for authentication in water monitoring

Water monitoring is important in all regions of the world. In order to have a clear overall picture of such vital resource, it is necessary to have real-time data about river levels and flows, storage elevations and volumes, and water salinity.

Water monitoring organizations use remote sensor networks to monitor data such as reservoir levels, stream flows, and pipeline valve positions. Those sensors, often equipped with mobile data transceivers, are critical components of the water management system, and therefore need to be authenticated.

For one of our major customers in this field, we have provided a RADIUS authentication solution, using Radiator AAA server to authenticate around 2000 active devices currently in active service.

After the authentication is done, the sensors send their telemetry data to specialized data repositories for processing, analysis, and display, in order for customer organizations to know the real-time status of their water system.

Would you like to know more about using Radiator in device authentication?

If you are interested in using Radiator in device authentication - for example in telemetry or sensor networks, please do not hesitate to contact our sales team at sales@radiatorsoftware.com.

Radiator, being the most flexible AAA server in the market, may be just the solution for your authentication use case.

Radiator is not affected by log4j vulnerability

On the 10th of December 2021 a vulnerability (CVE-2021-44228) in a popular Java-based logging utility log4j was published. Since then we have received some customer queries about Radiator’s vulnerability.

Radiator does not utilise Java or log4j as a component of our software and is therefore not vulnerable to the log4j vulnerability.

While following closely the situation, research and responses around the vulnerability, we have identified that RADIUS protocol and infrastructure can be used to deliver the exploit to more vulnerable services such as Java-based backend services, AAA information sources and centralised logging systems. We have documented this delivery method principle into a separate blog post found here:

https://blog.radiatorsoftware.com/2021/12/radius-servers-and-log4j-vulnerability.html

We will continue monitoring the issue closely and announce if issues affecting Radiator or Radiator services are found.

RADIUS servers and log4j vulnerability

On the 10th of December 2021 a vulnerability (CVE-2021-44228) in a popular Java-based logging utility log4j was published. While Radiator and some other RADIUS servers are not themselves vulnerable, log4j may be used in Java based user interfaces, log processors and many other supporting services and software. The systems and networks using RADIUS authentication can then be used to deliver the exploit to some other vulnerable services even if the exploit does not affect the RADIUS server systems directly.

Figure 1: RADIUS infrastructure as a delivery method for log4j exploits

The attacker can always try to exploit accessible network devices directly. Many network devices nowadays use Java based user interfaces and logging systems, which include log4j as a component and are therefore vulnerable to a direct attack. The attack can however reach deeper into backend services via RADIUS authentication without the need for the attacker to reach the actual backend services directly.

If the attacker is able to get the network device to add a suitable exploit payload to the RADIUS request, that payload can then be delivered through the RADIUS server to backend services and even outside one organisation. The payload does not affect the RADIUS servers themselves (unless they use Java and log4j) but RADIUS and RADIUS federations may be used as a delivery mechanism for exploits to reach more interesting targets.

Mitigating the risk by filtering and sanitising RADIUS attributes in RADIUS servers is likely to break more than it protects. It is more productive to focus on updating or possibly replacing log4j using systems than trying to prevent the delivery of the exploit.