daloRADIUS 0.9-9 SQL Injection / Code Execution

Type packetstorm
Reporter Liran Tal
Modified 2016-10-24T00:00:00


"daloRADIUS is an advanced RADIUS web management application aimed at  
managing hotspots and general-purpose ISP deployments. It features  
user management, graphical reporting, accounting, a billing engine and  
integrates with GoogleMaps for geo-locating."[1]  
While auditing this software for a business we found multiple  
potential security issues and despite the fact that this is a web  
application written in the early 2000s, there are unfortunately a lot  
of people running it in production.  
Numerous SQL Injection vulnerabilities have been found and  
disclosed[2] and are as-yet unresolved, however most of these appear  
to require authentication to the system in the form of "operator"  
access, limiting their usefulness to malicious attackers. Let's fix  
Vulnerability #1 - Anonymous SQL Injection to disclose operator passwords  
Assuming the daloRADIUS installation has php-dompdf (and maybe  
php-mail and php-mail_mime) installed (it looks like many do, to  
facilitate invoicing), there exists an SQL injection vulnerability in  
include/common/notificationsBatchDetails.php which does not require  
any credentials on the server whatsoever.  
The argument batch_name is not sanitized, and so with a carefully  
constructed batch_name such as:  
The usernames and passwords (stored in cleartext) of all operators  
will all be printed handily to a table in a PDF that's downloaded  
straight to your browser.  
It's worth noting that the damage of this vulnerability would have  
been dramatically decreased (reducing it's severity to that of the  
other SQL injection attacks which require operator access) if this  
script either checked it was running inside of the main scripts, or  
checked if it was logged in itself.  
The problem is found here:  
Introduced in commit 5b5da4bb3adf681fd9dd3a52c3b983358558fd0d  
Vulnerability #2: Arbitrary Shell Command Execution  
If a user has access to log in to the main daloRADIUS application (ie,  
"Operator" access) they can execute arbitrary commands on the server  
using the "Disconnect User" feature:  
Ensure you set the NAS IP/port to anything (doesn't have to be valid,  
just non-empty), the username need not exist and it really doesn't  
matter as nothing is checked and exploiting this will cause the system  
to not actually disconnect the client.  
In the "Additional attributes" box put anything like so, to break out  
of the quotes:  
"; id; echo "  
Command is then: echo ""; id; echo "" | radclient...  
uid=33(www-data) gid=33(www-data) groups=33(www-data)  
radclient: Nothing to send.  
Shortcut: config-maint-disconnect-user.php?username=nonexistentuser&submit=a&nasaddr=a&nasport=a&nassecret=a&customattributes=%22%3b%20id%3b%20echo%20%22  
Problem occurs in this function:  
Introduced in commit 05e6c72cdd14a1485d5cc21e8ca75306238f8f6d  
Indeed, I didn't realise this early on, but due to incorrect use of  
escapeshellarg() it looks like previous versions are also vulnerable  
in the other fields, including in the "test authentication" function  
as well (you just have to work around the escaping of single quotes,  
backticks, pipes etc).  
Bonus Security Issues  
In addition to previously documented SQL injection issues just about  
anywhere "orderBy" is found, and copious amounts of issues in the  
contrib/ directory, we also found the following that were not  
extensively researched:  
.. etc. Pretty much just grep -rn '$orderBy' for a complete list, but  
most of these require operator access already so the attack surface is  
pretty limited.  
This one only requires user-access if the daloradius-users portal is installed:  
As mentioned above, operator and user passwords are stored in  
cleartext with no option to hash them whatsoever. RADIUS passwords can  
be hashed if the authentication method supports it (ie, PAP), albeit  
with some dodgy logic and weak hashing mechanisms. For example, if you  
use crypt() for password hashing, it always uses the characters 'SA'  
for the salt, in four places such as:  
Without thinking too hard about it, this is probably not a big deal  
because crypt() is so close to useless these days, with or without a  
salt - it's probably not the only issue though.  
You can work around the first issue by simply not having the requisite  
libraries installed, or disabling the script if you're not using  
The author is working on patches in this pull request:  
Disclosure Timeline  
The author of the software has made a fix publicly available in a pull  
request, and the exploits are pretty obvious if you look at the  
changes so I'm publicizing this now in the hopes that the folks  
running this software can disable it, firewall it, or whatever. The  
fix is still in-progress, and at the time of writing breaks the "user  
disconnect" function, and so no release has been rolled yet.  
To the author's credit, the amount of support for such an ancient  
piece of software was more than I was expecting.  
Discovery: 2016-09-04  
Vendor Contacted: 2016-09-05  
Vendor Responded: 2016-09-05  
Fix publicized: 2016-10-19  
Authors and Acknowledgments  
James Fraser <fwaggle@fwaggle.org>  
Avinash Duduskar <strykar@hotmail.com>  
Liran Tal (vendor)  
1) https://github.com/lirantal/daloradius  
2) https://cxsecurity.com/issue/WLB-2013030130