This writeup details the technical exploitation of a misconfigured user account that possessed membership in the disk group. This membership allows a non-privileged user to bypass the Linux Discretionary Access Control (DAC) model by interacting directly with the filesystem at the binary level.

1. Enumeration & Group Analysis

The exploitation began with an audit of the current process's security context.

$ id uid=1001(User1) gid=1002(User1) groups=1002(User1),6(disk)

Technical Context: In Linux, the disk group (GID 6) typically owns the device nodes in /dev/. Membership in this group grants raw read/write access to block devices. While the operating system enforces permissions (like 600 on /etc/shadow) at the filesystem level, these permissions are metadata stored within the filesystem structure. If a user can read the raw blocks of the partition, they can parse the filesystem manually, effectively ignoring the OS's permission checks.

2. Storage Stack Mapping

Before attempting to read sensitive files, the target block device must be identified.

$ lsblk
NAME                        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                           8:0    0   20G  0 disk 
├─sda1                        8:1    0    1M  0 part 
├─sda2                        8:2    0  1.8G  0 part /boot
└─sda3                        8:3    0 18.2G  0 part 
  └─ubuntu--vg-ubuntu--lv   252:0    0   10G  0 lvm  /

Stack Analysis:

  • Physical Layer: /dev/sda is the raw disk.
  • Partition Layer: /dev/sda3 is a partition initialized as an LVM Physical Volume (PV).
  • Logical Layer: ubuntu--vg-ubuntu--lv is the Logical Volume (LV) formatted with an ext4 filesystem and mounted at /.

Attempts to run debugfs on /dev/sda3 failed with a "Bad magic number" error because /dev/sda3 contains LVM metadata, not the actual ext4 header. The target for the exploit must be the mapped device: /dev/mapper/ubuntu--vg-ubuntu--lv.

3. Filesystem Debugging & DAC Bypass

The debugfs utility is an interactive file system debugger. Since the user user1 has read access to the block device via the disk group, they can use debugfs to open the filesystem and invoke the cat internal command.

Execution:

debugfs -R "cat /etc/shadow" /dev/mapper/ubuntu--vg-ubuntu--lv

Internal Mechanism:

  1. Direct I/O: debugfs opens the block device file descriptor.
  2. Superblock Parsing: It reads the superblock to identify the Inode Table and Block Group Descriptors.
  3. Inode Resolution: It traverses the directory structure (starting at Inode 2 for /) until it locates the Inode for /etc/shadow.
  4. Data Extraction: It reads the data blocks pointed to by the Inode and streams them to stdout.

Because debugfs performs its own internal parsing of the ext4 structures, the kernel's Virtual File System (VFS) layer—and consequently the standard permission checks—are never engaged.

4. Credential Extraction (Shadow Analysis)

The output revealed the system's password hashes. Notably:

| **User** | **Hash Type** | **Hash Prefix** |
| **root** | yescrypt | `$y$j9T$...` |
| **user_adm** | SHA-512 (Unix) | `$6$eiS0g...` |
| User1 | yescrypt | `$y$j9T$...` |

Security Impact: The exposure of the root and user_adm hashes allows for offline password cracking. Furthermore, an attacker with disk group access could technically use debugfs in write mode (-w) to overwrite /etc/shadow, effectively changing any user's password or injecting a known hash to gain instant root access.

Remediation

  • Remove Administrative Groups: No standard user should be a member of the disk, mem, or kmem groups.
  • Audit LVM Permissions: Ensure that logical volume device nodes in /dev/mapper/ maintain strict permissions (typically brw-rw---- root disk).
  • Kernel Hardening: Implement Linux Security Modules (LSMs) like SELinux or AppArmor to restrict even high-privileged groups from accessing raw disk devices.