This box makes use of a local DNS services. Enumeration reveals subdomains, which host additional websites. One of these contains a login panel, which suffers from a SQL injection vulnerability, allowing us to bypass the authorization process. The now accessible webpage presents another form to the user, which is susceptible to command injection. By injecting a reverse shell, we get an initial foothold into the system.
Moving forward, we can abuse a cronjob, which executes a PHP file as root. Since the already compromised account owns this file, we can replace it with a PHP reverse shell, which leads to a total compromise of the system.
nmap -sC -sV 10.10.10.13 -oN nmap.txtStarting Nmap 7.95 ( https://nmap.org ) at 2025-02-10 16:21 CETNmap scan report for 10.10.10.13Host is up (0.062s latency).Not shown: 997 closed tcp ports (reset)PORT STATE SERVICE VERSION22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.1 (Ubuntu Linux; protocol 2.0)| ssh-hostkey:| 2048 18:b9:73:82:6f:26:c7:78:8f:1b:39:88:d8:02:ce:e8 (RSA)| 256 1a:e6:06:a6:05:0b:bb:41:92:b0:28:bf:7f:e5:96:3b (ECDSA)|_ 256 1a:0e:e7:ba:00:cc:02:01:04:cd:a3:a9:3f:5e:22:20 (ED25519)53/tcp open domain ISC BIND 9.10.3-P4 (Ubuntu Linux)| dns-nsid:|_ bind.version: 9.10.3-P4-Ubuntu80/tcp open http Apache httpd 2.4.18 ((Ubuntu))|_http-title: Apache2 Ubuntu Default Page: It works|_http-server-header: Apache/2.4.18 (Ubuntu)Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelService detection performed. Please report any incorrect results at https://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 18.81 seconds
When we visit the webpage, we can see the default Apache installation page. After trying to brute force some subdirectories for this website with Gobuster, we can conclude, that this web service is not accessible for us, at least not this way.
We also discovered a DNS service on this machine, so let’s interact with it. We can request the domain entry of this machine, by querying it via Nslookup over this service.
nslookup 10.10.10.13 10.10.10.1313.10.10.10.in-addr.arpa name = ns1.cronos.htb.
The response contains the subdomain of the nameserver, and therefore the domain of the entire machine as cronons.htb. Let’s add this domain to our local DNS resolver /etc/hosts. However, there may be other subdomains, which we do not yet know about. We can run Gobuster in the DNS mode against cronos.htb, using the same DNS service as before.
gobuster dns -r cronos.htb -d cronos.htb -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt===============================================================Gobuster v3.6by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)===============================================================[+] Domain: cronos.htb[+] Threads: 10[+] Resolver: cronos.htb[+] Timeout: 1s[+] Wordlist: /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt===============================================================Starting gobuster in DNS enumeration mode===============================================================Found: www.cronos.htbFound: ns1.cronos.htbFound: admin.cronos.htbProgress: 18971 / 114442 (16.58%)^C
We also discover the subdomains www and admin, both of which can be added to /etc/hosts. If we revisit the web server again by referring to the domain cronos.htb, we are instead greeted with a basic, but different web page. Since we can not do much with this page, and Gobuster yields no additional results, let’s visit admin.cronos.htb. Here, we can see a login panel, which requires a username and a password. Another Gobuster execution does yet again not reveal subdirectories.
User Flag
Since we have no additional information besides this login page, I suspect that this is our only way into the application. Entering test credentials comes back with a generic error message, meaning we can not even enumerate user accounts. Therefore, it is most likely, that this panel is vulnerable to SQL injections. This process is mostly trial and error. After trying several variations of the basic queries for authentication bypasses, such as ' OR 1=1-- for both fields, we can successfully inject the form by setting the username to ' OR 1=1-- -. The password field can be disregarded.
Analysis in Retrospect
After compromising the machine, we can see the query for ourselves, which we inject:
SELECT id FROM users WHERE username = 'username_input' and password = 'password_input'
If we inject ' OR 1=1-- for the username, it would lead to the following query:
SELECT id FROM users WHERE username = '' OR 1=1--' and password = ''
At first glance, this looks correct, as the OR would ensure a positive response and everything after would be commented out. Apparently, this is not the case. Instead, this query leads to a syntax error due to the original '. Changing the injection to ' OR 1=1-- - or ' OR 1=1 # circumvents this by enfocing the comment.
Once we gain authorization, we are being forwarded to /welcome.php. Here, we can use an http form to execute either ping or traceroute against a target of our choice. Entering a locally accessible IP (such as the one of the attacking machine, remember that the box has no internet connection), print the according output of the respective Linux utility.
Since we can set any value for the IP, It’s very likely that this field is vulnerable to common injection. Let’s test this, my appending the IP with a semicolon and any generic command.
As we can see from the output, we just achieved command execution. By injection a reverse shell into this field, we can get a callback to a Netcat listener. We use the following value for the IP field:
We have a shell as www-data. We can retrieve the user flag from /home/noulis.
4283bd75ccfd980e2f6a7322def94658
Root Flag
The first enumeration stages for elevating our privileges do not yield any results. We can find the admin password in the webroot’s config.php, however this is neither the same password for anything else on the system, nor can we leverage our access to MySQL for privilege escalation. Lastly, ps aux does not reveal any running processes we can hijack.
However, the crontab file reveals a cronjob running every minute as the root user. As we can see, it invokes PHP to execute the artisan file, which is part of another web page.
www-data@cronos:/etc$ cat crontabcat crontab# /etc/crontab: system-wide crontab# Unlike any other crontab you don't have to run the `crontab'# command to install the new version when you edit this file# and files in /etc/cron.d. These files also have username fields,# that none of the other crontabs do.SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin# m h dom mon dow user command17 * * * * root cd / && run-parts --report /etc/cron.hourly25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )* * * * * root php /var/www/laravel/artisan schedule:run >> /dev/null 2>&1#
If we take a look at this file, we can see that our service account has write access to this file. This allows us full control over what is being executes by root.
To exploit this, we download a php-reverse-shell onto our attacking machine, which we transfer to the target by spawning a python http server. We only need to delete the actual artisan file and rename the PHP shell script accordingly.
After spawning another Netcat listener, we get a connection after a few seconds. We now have a shell as root and can claim the respective flag.
