Abstract
--------

"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
that:

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:

    ?batch_name=invalid%27%20UNION%20ALL%20SELECT%20NULL,%20username%20AS%20batch_name,%20NULL,%20password%20AS%20batch_status,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL%20FROM%20operators%3B%23

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:
https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/include/common/notificationsBatchDetails.php#L110

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:

    config-maint-disconnect-user.php?username=nonexistentuser

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

Results:
    User-Name='nonexistentuser',
    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:
https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/library/exten-maint-radclient.php#L78

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:

https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/acct-active.php#L82
https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/acct-all.php#L75
https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/acct-custom-query.php#L123

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

https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/daloradius-users/bill-invoice-report.php#L124

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:
https://github.com/lirantal/daloradius/blob/ed4fea937c2b9b32b952e946bd417669a42eeb43/mng-edit.php#L486

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.

Solutions/Workarounds
---------------------

You can work around the first issue by simply not having the requisite
libraries installed, or disabling the script if you're not using
batches.

The author is working on patches in this pull request:
https://github.com/lirantal/daloradius/pull/15

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)

References
----------

1) https://github.com/lirantal/daloradius
2) https://cxsecurity.com/issue/WLB-2013030130