LaCasaDePapel

nmapAuto

nmap
recon

nmap

recon

nikto
gobuster

nikto

http

https

gobuster

no finds on the http server
images/1329-1.png

vsftp 2.3.4 exploit

doing a little googling, vsftpd 2.3.4 is infamous

images/1352-1.png

open backdoor on port 6200 with :)

typing steve:) to trigger the backdoor
images/1353-2.png

and nmap again:
images/1353-3.png

port is open, lets connect

rlwrap nc to port 6200

we can use netcat to connect to our victim on port 6200

rlwrap is a script that allows our shell to arrow up to past commands which is incredibly convenient in this scenario

phpinfo()

we see we're logged in as user dali
images/1355-2.png

scandir

we can list the various folders of our victim by using the scan directory php command or scandir
images/1356-1.png

interesting files

1. nairobi's ssh key
images/1357-1.png

ls $tokyo

if we ‘ls’

images/1376-1.png

we see file_get_contents('/home/nairobi/ca.key') images/1376-2.png

and also the cert is in x509 format images/1376-3.png

using vi to clean up nairobi's key

1st to get rid of the ‘\n’s
images/1358-1.png

:%s/\\n/g
1. %s/ to initiate remove
2. \\n is to remove ‘\n’ character
3. /g is to finish

Next we need to remove the leading spaces, do that manually

nairobi's public key

we can get nairobi's public key with a simple openssl command

images/1362-1.png

openssl pkey -in <private key> -pubout
images/1362-2.png

/etc/passwd

initial foothold

dl cert

first we export the certificate to our directory, I also renamed it ca.crt

images/1361-1.png

compare public keys of nairobi's key and webserver's key

we can compare the webserver's key with nairobi's key that we extracted earlier

images/1363-1.png

and we generate our certificate's public key with the following (cert says its x509 on the form)

openssl x509 -in ca.crt -pubkey -noout
images/1363-2.png

we have the private key to the certificate authority used to trust this webserver

(they are the same) what does this mean? -we have the private key to the certificate authority used to trust this webserver -→ so we can generate a client key->>>

generate client key

we have the private key to the certificate authority used to trust this webserver
so we can generate a client key

openssl genrsa -out client.key 4096
images/1364-1.png

now we have to create a certificate signing request:

openssl req -new -key client.key -out client.csr
images/1364-3.png

now we have our certificate signing request, but now we have to sign it

openssl x509 -req -in client.csr -CA ca.crt -CAkey nairobi_ca_key -set_serial 9001 -extensions client -days 9002 -outform PEM -out client.cer
images/1364-4.png

now we have a signed certificate, but unfortunately firefox cannot import it, it has to be in PKCS12

certificate sign request data

Here are my settings, feel free to input whatever you want, it makes no difference
country:US
State:OH
Locality:SC
ON:xiong
OU name:mao
CN:maoxiong
email:xiong@miaomao.now
pass:miao

convert to PKCS12

openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12
password=miao
images/1366-1.png

p12 key is a combination of client.cer and client.key
images/1366-2.png

info

to view our certificate info:

openssl pkcs12 -info -in client.p12
images/1367-1.png

add key to firefox certificate store

search for certification in firefox's settings
images/1368-1.png

add ca.crt to firefox

make sure the trust settings are set to identify websites
images/1370-1.png

refresh page

we see this animation move around a bit and...

we're in the private area
images/1369-3.png

https://10.10.10.131/file/U0VBU09OLTEvMDEuYXZp

Local file Inclusion Vuln

LFI: we see the path variable can load other directories on our victim as well:

https://10.10.10.131/?path=..
images/1371-1.png

we've successfully navigated to another directory on the box, proving it has a local file inclusion vulnerability

.ssh

ssh into professor acct

using the rsa_id private key we downloaded, we can use trial and error to see which user owns this key and log into them via ssh

after trying each user found earlier images/1378-1.png

we have our foothold!
images/1378-3.png

user.txt

privesc

pspy
memcache.ini
using professor's directory ownership to our advantage

pspy

lets monitor the processes on the box and see what we can find out

1. first set up our httpserver in the same directory as our pspy script images/1379-1.png

2. download it to our victim images/1379-3.png

3. run it and check for interesting processes
./pspy64 -f
-f -> file system events
images/1379-4.png

memcache.ini

we see memcache.ini is being called every few minutes

images/1380-1.png

checking the file we see its owned by root and that we can only read the file
images/1380-3.png

using professor's directory ownership to our advantage

Although we do not have permission to make changes to memcache.ini since root wrote it, professor DOES however, own his own /home/professor directory

images/1381-1.png

meaning we can simply move/rename memcache.ini within our directory, allowing us to write our own memcache.ini that will be called in the schdeuled process we observed from pspy
images/1381-4.png