Exercise 7

This is the report for the seventh and final series of exercises for my penetration testing course, taught by Tero Karvinen
http://terokarvinen.com/2018/penetration-testing-course-autumn-2018
The seventh assignment consists of three parts, as follows:

H7

a) Tee troijalainen Unicornilla ohjeen mukaan. (Vinkki: katso Tatun raporttia)

b) Asenna oma, itsellesi uusi harjoitusmaali. Voit hakea maalikoneen Vulnhubista. Murtaudu koneelle, katso walktroughsta vinkki, jos jäät jumiin.

c) Google Project Zero. Löydätkö tekniikoita, joita voi hyödyntää pentestissä? (Ei tarvitse toistaa haastavia assembler-temppuja)

These exercises are done on my home computer, the hardware consists of the following:
i7-5820K processor
ASUS X99M-WS Motherboard
16Gb DDR4 Kingston RAM
Samsung 840 EVO 250Gb ssd

The operating system used is the Kali Linux version 2018.3.

a)

Since I already tried using Unicorn, I was excluded from this assignment.
The unicorn test can be found in my previous assignment H6

b)

The practice target I decided to use from Vulnhub was the first one that was on their list, Node:1. The description stated that it was a medium level boot2root kind of challenge.
https://www.vulnhub.com/entry/node-1,252/

The setup of the target machine was pretty straight forward, download the .ovs file and import it to VirtualBox. Only note is that the virtual machines network settings were a bit off, so I changed the network adapter to “bridged” mode. Aftet that the machine start up without a hitch.

 

 

 

 

 

 

 

 

 

 

 

 

I started by performing a basic nmap scan using db_nmap.

 

 

 

 

 

 

 

 

 

 

 

 

 

Since the only port open other than SSH (22/TCP) was 3000 with a node.js service I decided to investigate that. I tried using uniscan on the target, but it didn’t give any additional useful information.

I browsed the the target address and found a new lead.

 

 

 

 

 

 

 

 

 

 

 

Since I had no other leads, I started to incpect the page source for clues.

 

 

 

 

 

 

 

 

 

 

 

The inspector didn’t reveal anything so I looked at the debugger, if that might have something intresting in it. I was glad to find /users/api that contained very useful information.

 

 

 

 

 

 

 

 

 

 

 

I wasn’t sure what encoding the password was, so I just googled the hash. The answer was SHA256 and was easily decodable.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

After the password was decoded, I tried to login to the site using the admin username and password compination I now had.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The only thing I could do was download a myplace.backup file. I also tried login in using the other credentials from the users list but the site gave a message that “at the moment only administrators can login”.

I tried reading the myplace.backup file but it was encoded. First I didn’t have a clue what encoding was in question but when I saw the file ending, I knew it had to be base64.

 

 

 

 

 

 

 

 

 

 

 

 

 

In an earlier course class, Tero showed us how to decode base64. I used that command:

cat myplace.beckup | base64 -d

The result was not exactly what I was looking for.

 

 

 

 

 

 

 

So I decided to try and decode the myplace.backup to a file. It was revealed that the file was infact a .zip file that was password protected.

 

 

 

 

 

 

 

 

 

 

 

 

Since I didn’t have a password for the file (the ones from the /api/users did not work), the only thing I could think of was password enumeration. Previously I had used hydra for this but when I googled it, the first search result was for program called fcrackzip. I had never heard of it, but it was intended for a case like this one. A quick glance on the instructions and the progman was able to crack the password. It was actualy ridiculously fast on performing the enumeration, only took like one second to find the match. I used the rockyou.txt file, since it’s contains a large amount of passwords. The file can be found in Kali Linux by default.

 

 

 

 

 

 

 

 

 

The backup had a the same file structure as /var/www would normally have, as far as I have seen. I started browsing the files, from the base directory upwards. The app.html didn’t have anything interesting in it.

 

 

 

 

 

 

 

 

 

 

 

The next one turned out very useful, since it had credentials for the user “mark” in it (and also a troll face 😀 ).

 

 

 

 

 

 

 

 

 

 

 

Since there was only two ports open on the machine, port 3000/tcp I had already checked out and the port 27017 from the app.js file runs on localhost, SSH is the only left to try. I decided on trying the newly found credentials to login via SSH. Luckily this guess was correct.

 

 

 

 

 

 

 

 

 

 

 

 

 

From this point, I had no clue on how to proceed. I could not find anything by browsing the file system that would seem to be of any use. Mark didn’t have sudo privileges. I spend about two hours on thinking and searching for more clues but all came out empty.

I decided on looking at an walkthrough of the machine to find clues on how to proceed. The fisrt one I looked at, mentioned that the machine had a privilege escalation flaw, this was possibly unintended weakness but I decided on trying it out. Now I know that the target machine is running Ubuntu 16.04 operating system, so I decided on googling it. The first search result seemed like something that could work, since I already had access to the system.

 

 

 

 

 

 

 

 

 

 

 

I downloaded the file, compiled it and tried to copy it to the target computer using mark’s account.

 

 

 

 

 

 

Since scp didn’t work (would have been too easy it seems). Maybe mark could download files from internet. A friend on mine who does pentesting, once said that python http server had helped him in many occasions, so this was something I could try out. Setting the temporary server up is quite easy, just set it up on the folder you want to use as it’s base.

 

 

 

 

 

 

 

Ok, lets admit. The downloading of the file could have been simpler. Had to try a few options before I could get it right.

 

 

 

 

 

 

 

 

 

 

 

 

 

The only thing left was to make the file executable and try it out.

 

 

 

 

 

 

 

 

 

 

 

 

It worked like a charm and I was able to get root access.

I looked through walkthroughs and this was the easy way of doing this. To be honest, I’m not sure I could have solved this without the privilege escalation exploit. The “right” way of solving this machine, is for the moment a bit out of my reach concerning my knowledge on pentesting.

c)

I haven’t read Project zero before, our teacher mentioned it before in class before this assignment. To be honest, I didn’t expect the material to be so deeply technical. This is generally not a bad thing, but I had a little bit of trouble on finding an article that wasn’t too challenging to read and interpret, it also had to be something I had genuine interest in.

The one that I found interesting was an arcticle about exploiting windows 10 in a local network using WPAD/PAC and JScript.

Before I continue I have to state that I’m not a javascript wizard and never have been, I actually don’t used it that much any more.

What I find fascinating about this exploit is that WPAD (Web Proxy Auto Discovery Protocol) and PAC (Proxy Auto-Config) are ancient in our modern terms of view. Javascript has also a reputation in being used in website exploits.

There are two things that I found interesting in this. Firstly, man-in-the-middle attacks. I have newer done one using DCHP and have tiny interest in trying one out some day. In this case the PAC file which the host can use to determine proper proxy setting, this file is contains a javascript function that is executed to optain that information. The PAC is paired with the WPAD that the computer uses to query the network for a server from which the PAC can be downloaded. This query can also happen via DHCP. So the attacker could impersonate a DHCP server to provide a modified PAC file to be executed by the would be victim computer. By doing this, the attacker can direct the browser trafic to his/hers selected proxy and intercept it.

The second thing is that this technique is quite old and as the article demostrates, it still works. The threat is not uknown and measures have been taken to prevent this but sill.

References:

https://googleprojectzero.blogspot.com/2017/12/apacolypse-now-exploiting-windows-10-in_18.html

http://terokarvinen.com/2018/penetration-testing-course-autumn-2018

https://medium.com/egghunter/node-1-vulnhub-walkthrough-5635aa56cc74