Skip to main content
You have been assigned a penetration test on a critical Linux server in the client’s environment. The primary objective is to gain root-level access to this system to demonstrate maximum impact from the engagement.
Image

​
Initial Access

The client has provided you with credentials for an “Assumed Breach” scenario.

​
Enumeration

As always, starting things off with an nmap scan.
Make sure to add the following line to /etc/hosts:

10.1.172.242 walnut.local
I also ran a UDP scan:
A lot more open ports than I expected! We have:
  • 22 (SSH)
  • LDAP (389)
  • SMB (139/445)
  • NFS
  • UDP port 207
  • UDP Port 1025
What is most odd to me about these ports is how this box is claiming to be a linux box, despite there being common windows services open in SMB and LDAP. Regardless, we will continue enumerating to first see what access we have. To do this, I will spray our given creds against SSH, LDAP, and SMB using nxcspray:
We don’t authenticate to SSH or LDAP, but we do authenticate as a guest to SMB! Image Let’s take a closer look at what shares might be open:
Image Unfortunately, while there is an ‘automation’ custom share, it doesn’t appear as if we have any READ or WRITE access to it. Moving down the list of ports we can enumerate, let’s check out NFS next. We can enumerate NFS using rpcinfo and showmount to confirm nfs_acl is installed. but we see that there aren’t actually any mounted file system:
Image

​
Enumerating LDAP

Going back to LDAP, I noticed something odd. This server is running OpenLDAP 2.2.X - 2.3.X. Some quick googling reveals that the server may be vulnerable to Kerberos KBIND Buffer Overflow, an RCE up to 2.3.x in OpenLDAP. But before we explore that further, we should do some basic enumeration first. Trying our given creds, we find that we don’t actually authenticate.
We can provide creds differently though! If we provide the ou of Peopleand use -x authentication (simple authentication) alongside the “secure prompt” with -W, we can query information about LDAP on walnut!
We can narrow down our search a little bit, instead of searching at the root of the LDAP server, we can look at objects, in this case we can look at the users objects specifically:
We see that there are 3 users:
  • automation
  • larryburns
  • briangeoff
This could come in handy later if we need to do password spraying. Alongside the users object, we can also query all the OUs and Groups on the server:
Outside of the already discovered users and groups, we find that each group has a cn: miners value. That suggests miners could be a shared group name or a classification represented in the directory.

​
Initial Foothold: Creds via LDAP Enumeration

We can keep enumerating down this path by dumping attributes for all three users we found:
Hooray! We found some creds in the description field of the automation user!

​
Lateral Movement: Authentication as Automation

We authenticate and can read the automation and print share, and write to the automation share! Image I will export all of the files from the share using nxc:
Image We can obtain the user flag here in the automation folder, which looks like it is a mirror of a home directory in linux: Image From here we can also grab automation’s SSH key and use it to get a stable shell on the machine Image Image

​
Lateral Movement: Script as localjob3

First thing’s first, we find this script running in automations’ home directory:
Looking at the script we are seeing that it is taking su -, so switching user and the .hidden file contains md5 hashes, which the script apperas to be from usernames. Looking at the other users on the box and md5hashing each of them, the only backup file contains a string, which could be a password, do localjob3! Image We can su to localjob3 and authenticate! Image

​
Privilege Escalation: NFS

Looking at our pemrissions, we have sudo -l on systemctl!
Let’s check out what this service is all about. This is an interesting sudo permission to have because restarting a service only matters when we control some aspect of that service and what the service starts.
We see the important lines are underneath the [Service] section, where the executable is actually being started. Unfortunately, we don’t have direct control over any of these files and they aren’t overwritable, so we must pivot to a more standard approach with NFS, which is looking toward NFS squashing. To perform and NFS squash, we need write permissions on /etc/exports … which we don’t have, only read. Image But what is that ”+” at the end of the permissions? This signifies that there is some kind of access control list (ACL) controlling the file permissions. To look at these additionally set permissions we can run getfacl: Image Looking at the output, we see that through the ACL our user localjob3 actually does have write permissions on the file! With this, we can follow a standard no_root_squash exploit! Image On our kali machine, we can run the following sequence of commands to mount our file system to walnut’s, then create an SUID copy of /bin/bash which we will use on the shared folder in Walnut.
Going back to our walnut terminal, we can now go to the mapped /srv directory, run bash -p to activate the SUID bit and drop into a root shell where we can claim root.txt ! Image This box was quite a fun one! I have never seen ACL’s on linux before, but thankfully that ”+” gave it away. Happy hacking!