Nagios Log Server 1.4.1 XSS / Authentication Bypass

Type packetstorm
Reporter Francesco Oddo
Modified 2016-08-13T00:00:00


                                            `( , ) (,  
. '.' ) ('. ',  
). , ('. ( ) (  
(_,) .'), ) _ _,  
/ _____/ / _ \ ____ ____ _____  
\____ \==/ /_\ \ _/ ___\/ _ \ / \  
/ \/ | \\ \__( <_> ) Y Y \  
/______ /\___|__ / \___ >____/|__|_| /  
\/ \/.-. \/ \/:wq  
Nagios Log Server Multiple Vulnerabilities  
Affected versions: Nagios Log Server <= 1.4.1  
The Nagios Log Server application is affected by multiple security  
vulnerabilities, including authentication bypass, stored cross-site  
scripting, inconsistent authorization controls and privilege escalation.  
These vulnerabilities can be chained together to obtain unauthenticated  
remote code execution in the context of the root user.  
==Authentication Bypass==  
Authentication for the Nagios Log Server web management interface can be  
bypassed due to an insecure implementation of the function validating  
session cookies within the aSession.phpa file. As shown below, the  
application uses a base64 encoded serialized PHP string along with a  
SHA1 HMAC checksum as the cookie to authenticate and manage user  
sessions. A sample cookie format is shown below:  
s:10:"user_agent";s:72:"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0)  
Gecko/20100101 Firefox/46.0";  
The application relies on the validation against the SHA1 HMAC to  
recognize and destroy invalid session cookies when the checksum value  
does not match. However the encryption key used to generate the HMAC  
checksum is statically set to the SHA1 hash value of the  
$_SERVER['HTTP_HOST'] PHP variable, which is the Host HTTP header value.  
This information can be controlled by the attacker and as such should  
not be considered a secure randomly generated value for the secret  
encryption key.  
Since no further verification is performed for other non-predictable  
fields (e.g. session_id, apikey, email, username etc.) and only a valid  
user agent string matching the correct HTTP header value is required, an  
attacker can forge arbitrary session cookies and bypass authentication.  
The script on the following page generates session cookies which are  
accepted and validated successfully by the application. A auser_ida  
value of 1 can be used to initiate a session in the context of the admin  
[POC - nagiosls_forge_cookie.php]  
// Usage: php nagiosls_forge_cookie.php [TARGET_IP_ADDRESS/DOMAIN NAME]  
$host = $argv[1];  
$host = $argv[1];  
$session =  
s:10:"user_agent";s:72:"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0)  
Gecko/20100101 Firefox/46.0";s:13:"last_activity";  
$encryption_key = sha1($host);  
$hmac_check = hash_hmac('sha1', $session, $encryption_key);  
$cookie = $session . $hmac_check;  
echo urlencode($cookie);  
This vulnerability is present across multiple Nagios products.  
==Stored Cross-Site Scripting==  
The Nagios Log Server application does not validate and HTML encode log  
data sent by configured sources. This issue is aggravated by the fact  
that the application does not maintain a list of authorized log sources,  
but instead accept data from any host connecting to the Nagios Log  
Server port responsible of collecting logs (TCP 5544). An attacker can  
exploit this vulnerability to send malicious JavaScript code and execute  
it in the context of Nagios Log Server user session as shown below.  
# echo '<script>alert("xss")</script>' | nc [TARGET IP] 5544  
The payload gets rendered under '/nagioslogserver/dashboard'.  
==Inconsistent Authorization Controls==  
The Nagios Log Server application provides intended functionality to  
define custom alert commands using different configuration options. By  
default, only administrative users can define alert commands which  
execute scripts on the Log Server filesystem when an alert is triggered.  
However, the application does not properly enforce authorization checks  
and an attacker can access the same functionality in the context of a  
standard user session by providing the correct payload in the aalerta  
POST parameter. This functionality can be abused to obtain remote code  
execution on the target system as the application does not restrict the  
script definition to a single folder and an attacker can specify  
absolute paths to any script or executable file present on the Log  
Server host.  
URL => /nagioslogserver/api/check/create/1  
Method => POST  
Payload =>  
==Privilege Escalation==  
The default Log Server application sudoers configuration allows the  
aapachea user to run the aget_logstash_ports.sha script as root without  
being prompted for a password. However insecure file write permissions  
have been granted to the 'nagios' group for the aget_logstash_ports.sha  
script file. Since the apache user is a member of the 'nagios' group, an  
attacker can overwrite the script contents with arbitrary data.  
Details about the script with insecure permissions are provided below:  
PATH => /usr/local/nagioslogserver/scripts/  
PERMISSIONS => rwxrwxr-x nagios nagios  
| Solution |  
Upgrade to Nagios Log Server 1.4.2  
| Timeline |  
2/06/2016 a Initial disclosure to vendor  
3/06/2016 a Vendor acknowledges receipt of advisory  
22/07/2016 a Vendor releases patched software version  
11/08/2016 a Public disclosure  
| Additional |  
Further information is available in the accompanying PDF.