# Nmap 7.93 scan initiated Sat Apr 8 00:43:54 2023 as: nmap -Pn -p- --min-rate 10000 -A -oN scan.txt 10.10.10.79 Nmap scan report for 10.10.10.79 Host is up (0.013s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 1024 964c51423cba2249204d3eec90ccfd0e (DSA) | 2048 46bf1fcc924f1da042b3d216a8583133 (RSA) |_ 256 e62b2519cb7e54cb0ab9ac1698c67da9 (ECDSA) 80/tcp open http Apache httpd 2.2.22 ((Ubuntu)) |_http-title: Site doesn't have a title (text/html). |_http-server-header: Apache/2.2.22 (Ubuntu) 443/tcp open ssl/http Apache httpd 2.2.22 ((Ubuntu)) |_http-title: Site doesn't have a title (text/html). | ssl-cert: Subject: commonName=valentine.htb/organizationName=valentine.htb/stateOrProvinceName=FL/countryName=US | Not valid before: 2018-02-06T00:45:25 |_Not valid after: 2019-02-06T00:45:25 |_ssl-date: 2023-04-08T04:44:27+00:00; 0s from scanner time. |_http-server-header: Apache/2.2.22 (Ubuntu) No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.93%E=4%D=4/8%OT=22%CT=1%CU=39263%PV=Y%DS=2%DC=T%G=Y%TM=6430F12B OS:%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=10C%TI=Z%CI=Z%II=I%TS=8)OPS( OS:O1=M53CST11NW4%O2=M53CST11NW4%O3=M53CNNT11NW4%O4=M53CST11NW4%O5=M53CST11 OS:NW4%O6=M53CST11)WIN(W1=3890%W2=3890%W3=3890%W4=3890%W5=3890%W6=3890)ECN( OS:R=Y%DF=Y%T=40%W=3908%O=M53CNNSNW4%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS OS:%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=3890%S=O%A=S+%F=AS%O=M53CST11NW4%RD=0 OS:%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z OS:%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y OS:%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RI OS:PL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 3306/tcp) HOP RTT ADDRESS 1 13.56 ms 10.10.14.1 2 13.64 ms 10.10.10.79 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Apr 8 00:44:27 2023 -- 1 IP address (1 host up) scanned in 33.73 seconds
nmap output for
TCP/443, the certificate has a
valentine.htb. I tested it as a virtual host, but there doesn't seem to be any noticeable difference when navigating using a hostname.
gobuster dir -u http://10.10.10.79 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt -r -t 100 -o gobuster.txt
/index.php (Status: 200) [Size: 38] /index (Status: 200) [Size: 38] /dev (Status: 200) [Size: 1097] /encode (Status: 200) [Size: 554] /encode.php (Status: 200) [Size: 554] /decode.php (Status: 200) [Size: 552] /decode (Status: 200) [Size: 552] /omg (Status: 200) [Size: 153356]
To do item three and four are pretty interesting, sounds like encoding/decoding might be occurring server-side at this point.
I'm going to hang onto this hash and enumerate some more.
Upon first glance at the directory structure and the server responses, it looks like there are scripts at:
What's really happening here is that the server is redirecting the client based on the directory. So, any file name under
/decoder redirects to
/decoder/decoder.php, and vice-versa for the
I tried some different PHP payloads to see how the server parses the inputs, but it doesn't seem vulnerable to any kind of command injection or file inclusion at the moment. Time to enumerate some more.
TCP/443 looks to be serving the same content as
TCP/80. I re-ran a
nmap scan on the open ports to enumerate some more.
This bit from the output stuck out to me:
443/tcp open https | ssl-heartbleed: | VULNERABLE: | The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption. | 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) of 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/
Looking at the
omg.jpg image during the initial enumeration, it's very clear that I should be focusing on the Heartbleed SSL/TLS vulnerability.
Heartbleed isn't a vulnerability in the web server itself. It's actually happening at the transport layer, where the server and client complete a handshake before sending data at the application layer.
This is a really nice write-up on the vulnerability here:
In short what's happening with this exploit is:
- We tell the server that we've sent
- The server doesn't verify and processes the request
- Since the request is empty, nothing is processed in the memory of the server application
- Thus, when the server replies, the server returns data from memory that it otherwise shouldn't be reading
- Since the web server is the application running the OpenSSL stack, it's possible that sensitive information could be leaked from memory on the server
There are also some Heartbleed exploits on Exploit Database.
This bit is very interesting:
00e0: 31 2F 64 65 63 6F 64 65 2E 70 68 70 0D 0A 43 6F 1/decode.php..Co 00f0: 6E 74 65 6E 74 2D 54 79 70 65 3A 20 61 70 70 6C ntent-Type: appl 0100: 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F ication/x-www-fo 0110: 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0D 0A 43 rm-urlencoded..C 0120: 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 34 ontent-Length: 4 0130: 32 0D 0A 0D 0A 24 74 65 78 74 3D 61 47 56 68 63 2....$text=aGVhc 0140: 6E 52 69 62 47 56 6C 5A 47 4A 6C 62 47 6C 6C 64 nRibGVlZGJlbGlld 0150: 6D 56 30 61 47 56 6F 65 58 42 6C 43 67 3D 3D B6 mV0aGVoeXBlCg==.
That's very clearly a base64-encoded payload being send to the
decode.php script on the server. It seems like we're getting some log data back in the Heartbleed response. Let's try and decode the data.
Cracking the SSH Hash
echo 'heartbleedbelievethehype' > pass.txt john --wordlist=pass.txt ssh-hash
The only problem here is we have a key, but don't have a username. We could try
hype — since the filename on the web server is
hype_key, but outside of that, we'd have to bruteforce with a username list.
I get an error when trying to SSH with the key:
sign_and_send_pubkey.... I imagine it has something to do with the age of the box and outdated SSH ciphers. Time to Google for a workaround.
Looks like we can tack on an option with the SSH command:
And, we're in!
A server vulnerable to the Heartbleed vulnerability leaked a password — which in combination with a SSH private key file — allows an attacker to authenticate to the SSH server running on the target.
At a minimum, Heartbleed is the vulnerability in need of most urgent patching. Beyond that, developers should ensure that sensitive folders are not globally readable, let alone storing SSH keys in web directories anyway.
OS & Kernel
Linux Valentine 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
uid=1000(hype) gid=1000(hype) groups=1000(hype),24(cdrom),30(dip),46(plugdev),124(sambashare) Sorry, user hype may not run sudo on Valentine.
Users and Groups
cdrom:x:24:hype dip:x:30:hype plugdev:x:46:hype hype:x:1000: sambashare:x:124:hype
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:b9:db:34 brd ff:ff:ff:ff:ff:ff inet 10.10.10.79/24 brd 10.10.10.255 scope global eth0 inet6 dead:beef::2932:bdef:12e3:8847/64 scope global temporary dynamic valid_lft 86397sec preferred_lft 14397sec inet6 dead:beef::250:56ff:feb9:db34/64 scope global dynamic valid_lft 86397sec preferred_lft 14397sec inet6 fe80::250:56ff:feb9:db34/64 scope link valid_lft forever preferred_lft forever
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
Processes and Services
root 1022 0.0 0.1 26416 1684 ? Ss 09:30 0:06 /usr/bin/tmux -S /.devs/dev_sess
srw-rw---- 1 root hype 0 Apr 10 09:30 /.devs/dev_sess
Looking at the enumeration of the running processes, the
tmux session running as
/.devs/dev_sess was clearly a clue.
So, I ran the exact same command in my
hype session, since I clearly had
rw privileges to that session file.
Nice! We're done here.