jperezduerto.info
UnderPass
Linux· Easy
Summary
I identified SNMP running openly on the internet with the default 'public' community string, which disclosed the hostname UnDerPass.htb and advertised the installed daloRADIUS application. The daloRADIUS operator web panel accepted its factory-default credentials unchanged, granting administrative control over the RADIUS server.
The user management screen exposed every RADIUS account's password stored as an unsalted MD5 hash; one hash was cracked offline in seconds, yielding the SSH password for the same account name on the host. Once inside as svcMosh, a passwordless sudo rule for mosh-server let me spawn a root-owned Mosh session and obtain an interactive root shell — full system compromise in four chained steps.
Command conventions
The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"
export PASSWORD3="<a-password-you-choose>"
export PASSWORD4="<a-password-you-choose>"Attack path — how the box was taken
1ReconnaissanceSNMP enumeration with default community string (T1602.001)
Discovered SNMP open with default community string, leaking host identity and installed application
A UDP scan found SNMP listening on port 161, accepting SNMPv1 and SNMPv3. Querying with the industry-default read-only community string 'public' returned the system description MIB, which named the host 'UnDerPass.htb' and explicitly stated it was 'the only daloradius server' — handing my the hostname and the name of the web application with no credentials required.
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public) ... Host: UnDerPass.htb is the only daloradius server
Exact commands 2
Confirm SNMP is open on UDP 161 and read the service banner.
nmap -sU -p 161 -sV --open $TARGETWalk the system MIB group with the 'public' community string; returns sysDescr, sysName, and sysContact strings that identify the host and application.
snmpwalk -v1 -c public $TARGET 1.3.6.1.2.1.1FixDisable SNMP or restrict it to management networks with a non-default community stringMedium
WeaknessSNMP was exposed on the public interface with the factory-default 'public' community string, allowing any host on the internet to read system description data — including the hostname and the name of the installed application — with no authentication.
FixIf SNMP monitoring is not required, stop and disable the snmpd service ('systemctl disable --now snmpd'). If it is required, upgrade to SNMPv3 with SHA authentication and AES encryption, replace the 'public' community string with a long random value, and restrict allowed source addresses to your monitoring server using an SNMP view ACL and a host-based firewall rule (e.g., 'ufw allow from <monitor-ip> proto udp to any port 161'). Block UDP 161 at the perimeter firewall for all other sources.
2EnumerationKnown-application default-path discovery
Located the daloRADIUS operator login panel at its default installation path
Using the hostname obtained from SNMP, I added UnDerPass.htb to local DNS resolution and navigated to the known default daloRADIUS operator path. The login page returned HTTP 200, confirming the application was installed and directly accessible from the internet with no network-level restriction.
Curl -s -o /dev/null -w '%{http_code}' .../operators/login.php -> 200
Exact commands 2
Register the SNMP-discovered hostname for virtual-host resolution.
echo "$TARGET underpass.htb" | sudo tee -a /etc/hostscurl -s -o /dev/null -w '%{http_code}' http://$TARGET/daloradius/app/operators/login.php3ExploitationDefault credential exploitation (T1078.001)
Authenticated to daloRADIUS using unchanged factory-default credentials
The server responded with a 302 redirect to the dashboard, granting my full administrative access to the RADIUS management interface, including the ability to read all user account records.
HTTP/1.1 302 Found ... Location: index.php ... <title>Dashboard :: daloRADIUS</title>
Exact commands 1
Authenticate with the daloRADIUS default credentials; -L follows the redirect to the dashboard. Saves the session cookie for subsequent requests.
curl -sik -c cookies.txt -X POST http://$TARGET/daloradius/app/operators/login.php --data 'username=administrator&password=$PASSWORD2' -LFixChange daloRADIUS default operator credentials and restrict admin panel network accessCritical
Weakness
FixImmediately change the administrator password to a strong, unique value of 20 or more characters. Restrict access to the /daloradius/app/operators/ path by IP allowlist at the web server level (Apache: 'Require ip <trusted-range>') or via firewall, so the panel is not reachable from untrusted networks. Consider placing it behind a VPN or bastion host. Enable HTTP authentication as a defence-in-depth layer on top of the application login.
4Credential AccessCredential harvesting from web application and offline MD5 hash cracking (T1110.002)
Extracted and cracked the svcMosh RADIUS account's unsalted MD5 password hash
The daloRADIUS user list page displayed every RADIUS account alongside its stored password hash in plain view. The svcMosh account showed the value [REDACTED: recovered credential] — an unsalted MD5 digest. Running the hash against the rockyou wordlist with Hashcat recovered the plaintext password '[REDACTED: recovered credential]' in seconds, a speed made possible because unsalted MD5 can be precomputed at billions of guesses per second.
SvcMosh Edit User Accounting | [REDACTED: recovered credential] | (n/a); cracked to '[REDACTED: recovered credential]'
Exact commands 2
Authenticated GET to dump the RADIUS user list, including plaintext-displayed password hashes.
curl -sb cookies.txt "http://$TARGET/daloradius/app/operators/mng-users-list.php"-m 0 selects raw MD5 mode. Replace rockyou.txt path with your local wordlist location.
echo '$PASSWORD3' > hash.txt && hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt --forceFixReplace unsalted MD5 password storage with a strong adaptive hashing algorithmHigh
WeaknessdaloRADIUS stored RADIUS user passwords as unsalted MD5 hashes, which are trivially cracked against a standard wordlist. Anyone who gains read access to the user table — for example, through the compromised admin panel — instantly recovers plaintext passwords that may then be reused to access other systems.
FixConfigure FreeRADIUS and daloRADIUS to store passwords using bcrypt or Argon2id. If the RADIUS protocol requires cleartext or reversible storage for certain authentication methods (e.g., CHAP or MS-CHAPv2), document that constraint, keep the RADIUS database isolated from other systems, and enforce strong unique passwords for every RADIUS account enforced by a password policy. Force a password reset for all existing accounts after changing the storage algorithm. Ensure RADIUS account passwords are never shared with operating-system or SSH accounts.
5FootholdCredential reuse over SSH (T1078)
Gained an interactive SSH shell as svcMosh using the cracked password
The password recovered from the daloRADIUS hash — '[REDACTED: recovered credential]' — was reused directly as the SSH password for the identically-named system account. SSH authentication succeeded immediately, placing my in a shell as uid 1002 (svcMosh) and enabling capture of the user flag from the account's home directory.
Uid=1002(svcMosh) gid=1002(svcMosh) groups=1002(svcMosh)
Exact commands 1
Logs in with the cracked credentials and prints uid and the user flag (actual value replaced with <user.txt>).
sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null svcMosh@$TARGET 'id; cat /home/svcMosh/user.txt'6Privilege EscalationSudo abuse via GTFOBins mosh-server (T1548.003)
Escalated to root by abusing a passwordless sudo rule for mosh-server
Checking svcMosh's sudo permissions revealed a NOPASSWD entry for /usr/bin/mosh-server with no command restrictions. Running mosh-server under sudo started a Mosh session owned by root on a local port and printed a one-time session key. My set that key in the environment and connected with mosh-client, which negotiated with the root-owned server process and delivered an interactive root PTY — complete system compromise without any password prompt.
Sudo -l entry: (ALL) NOPASSWD: /usr/bin/mosh-server; MOSH_KEY [REDACTED: recovered credential] used to connect on port 60002
Exact commands 4
List allowed sudo commands for svcMosh; expect a NOPASSWD entry for /usr/bin/mosh-server.
sudo -lStart a root-owned Mosh server on port 60002; note the MOSH KEY printed to stdout.
sudo /usr/bin/mosh-server new -p 60002 -c 256 -s -l LANG=en_US.UTF-8Set the session key printed by mosh-server and connect; delivers an interactive shell running as root. Alternatively: script -qfec 'mosh-client 127.0.0.1 60002' /dev/null
export MOSH_KEY='$PASSWORD4' && mosh-client 127.0.0.1 60002Run inside the root Mosh session to confirm privilege and capture the root flag (value replaced with <root.txt>).
id && cat /root/root.txtFixRemove the passwordless sudo rule granting unrestricted mosh-server executionCritical
WeaknessThe svcMosh service account could run /usr/bin/mosh-server as root without a password prompt and without restriction on arguments. Because mosh-server spawns an interactive shell that inherits the invoking process's privileges, this is functionally equivalent to granting an unconditional root shell to anyone who can authenticate as svcMosh.
FixRemove the mosh-server entry from /etc/sudoers and any file under /etc/sudoers.d/ ('visudo' or 'rm /etc/sudoers.d/<file>'). Audit all sudo rules on every host with 'sudo -l' for each service account and apply the principle of least privilege: no service account should hold NOPASSWD access to any binary listed on GTFOBins or capable of spawning a shell. If Mosh remote access is needed for administrators, grant it only to named human accounts requiring MFA, never to service accounts.
Attack patterns used
The transferable techniques behind this compromise.
Password / Credential ReuseCredential Access · Lateral MovementT1078
What it is
A password recovered from one place — a config file, a database, a cracked hash, a service account — is tried against other accounts and services (SSH, SMB, WinRM, sudo, the database, the next host). Reuse turns a single leaked secret into broad access.
Why it works
Humans and deployments reuse passwords across accounts and tiers, and lateral movement thrives on it. Remediate with unique credentials per account/service, a password manager/vault, and MFA on remote-access services.
Read more
Sudo Misconfiguration (GTFOBins)Linux · Privilege EscalationT1548.003
What it is
When a low-privileged user is allowed (via sudo -l) to run a specific binary as root, many binaries can be coerced into spawning a root shell or reading root-owned files. GTFOBins catalogs the escape for each binary — e.g. sudo perl -e 'exec "/bin/sh"', sudo vim -c ':!sh', sudo find . -exec /bin/sh \;.
Why it works
Admins grant narrow sudo rights assuming the binary is 'safe', but interpreters, editors, and many utilities have shell-out features. Remediate by avoiding sudo rules on interpreter-class binaries, using NOEXEC, and least-privilege review. Always run sudo -l first on a foothold.
Read more
Exposed services
| 22/tcp | ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0) |
| 80/tcp | http Apache httpd 2.4.52 ((Ubuntu)) |
| 161/udp | snmp SNMPv1 server; net-snmp SNMPv3 server (public) |