Stocker

1. Get a new OpenVPN Connection and try again for port 80 through a web browser.

2. Checked web browser with IP.

   1. Nothing there

3. I ran a whatweb on the IP:

   1. 
4. I ran a quick nmap scan with no flags:

   1. 
5. Since port 22 and 80 were open I ran a version scan on them:

   1. 
6. Since port 80 is open it appears that something is open there so I'm going back to the web browser. When I do, I notice it redirects to http://stocker.htb/

   1. The page does not load.

   2. Turned on the proxy to check with burpsuite

   3. Nothing is coming through, no code.

   4. TODO: Need to retry web server at another time to see if I can come up with something.

7. Decided to run gobuster to see if that comes up with anything.

   1. I'm assuming the web server is not up and running:

      1. 
8. Checked exploit-db for both nginx and openssh for any vulnerabilities pertaining to those versions.

   1. Nothing popped up

9. Checked msfconsole for exploits but nothing there either.

10. Will try further nmap scans to see if I can find anymore information:

    1. 
    2. I discovered some ssh-hostkeys

       1. RSA - 3072 3d12971d86bc161683608f4f06e6d54e

       2. ECDSA - 256 7c4d1a7868ce1200df491037f9ad174f

       3. ED25519 - 256 dd978050a5bacd7d55e827ed28fdaa3b

       4. TODO: May need to dig further into this.

11. I tried a couple of typical usernames and passwords to access ssh.

    1. No luck

12. I instead decided to give a brute force attempt at ssh.

    1. I used the brute-ssh script from nmap to see if I could come up with something.

       1. I gave up on this after 5 min. TODO: Should try again but the attack may take a long time.

13. I moved to a hydra check.

    1. Gave up on this. But can come back to it later.

14. I want to run a bigger nmap scan on the target to see if any other ports are open.

    1. 

    1. 
15. URGENT:

    1. After completing the Tier 1 Machine Responder (Check the walk-through for more information). I think the IP and domain name needs to be added to /etc/hosts file so that the url can resolve. Use the command below:

echo "[IP] stocker.htb" | sudo tee -a /etc/hosts

1. The above worked. I was able to add "stocker.htb to the hosts list and now I can see the website. Thank god.

2. I have access to the website. None of the link go anywhere and only go to specific parts of the first page.

   1. I ran gobuster again on it and came up with the following. All of them return with a 403 error code. Forbidden

1. Decided to open burp suite and see if I can access the other pages with it.

   1. I didn't discover anything in the header request or responses

2. In the source code, I found a link to onepagelove.com/stride which is the website that the template came from. I went ahead and downloaded the free template to take a look at the file format.

   1. Didn't find anything obvious.

3. I searched msfconsole for anything obvious relating to the template.

   1. Found nothing

4. I ran nmap again since I can see the http page. I found some new stuff:

   1. 
   2. It looks like we have an http-generator of Eleventy v2.0.0

      1. I have no idea what that is. I looked it up but got more confused.

   3. Nothing obvious pops up for it when I search for exploits or vulnerabilities.

5. I decided to run a OS nmap scan see below:

   1. Nothing new or interesting pops up.

6. I went back through and checked for any exploits on nginx. I didn't find anything for that version.

7. I went up on the discussion board finally for the machine and saw someone had mentioned using the vhost option for gobuster so I decided to give that a try.

   1. 
   2. So now I have a subdomain to check out.

   3. At first it didn't work. So I added it to the etc/hosts lists similar to adding stocker.htb. This time I changed it to dev.stocker.htb.

   4. This worked and now I'm at a login page for the website.

1. I started with reading through the page source and the only thing I found was some JS for checking the username and password.

2. After some research I found the login page uses NoSQL. I need to look into attempting a NoSQL Injection.

   1. I should try the following login information. See SQL Injection notes for more information on this. {"email":' or 1=1--","password":"a"}

      1. Didn't work

   2. I'm going to browse payloadallthethings for a nosql injection option. Browse the authentification bypass to see if something will work.

      1. https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/NoSQL%20Injection#authentication-bypass

   3. OK. I don't think I would have figured this out on my own but figured I should write it down for future reference.

      1. I should have started with SQL Injection Testing to see if that worked.

      2. Next I should test for NoSQL Injection.

      3. When that doesn't work I should check for JSON capability. I need to look into how to do this in the future.

         1. To do this though, when I capture the login attempt from burpsuite, I can change the "Content-Type" Header to "application/json".

         2. 
      4. Multiple ways to check for SQL and NoSQL Injection but should start with authentification bypass tricks from payloadallthethings first.

      5. Once I have changed the content-type header to application/json, I next grab the following payload from payloadlallthethings from the link above:

{"username": {"$ne": null}, "password": {"$ne": null}}

• Forward the request and bam. you're signed in.

• I now have access to a webpage where I can add items to a cart and purchase them.

• If I click on an item and add it to the basket it does.

• I can then hit the "Submit Purchase" button to buy it.

• This also gives me a pdf document reciept.

• This gives me a couple of things:

• Their may be a user called Angoose

• I have an email address of [e-mail]

• This also gives me the URL path of http://dev.stocker.htb/api/po/[ORDER ID]

• I ran exiftool on the pdf to see if I could get any other info.

exiftool [Path to PDF file]

• It looks like Chromium uses the Skia/PDF m108 to create the pdfs. I did a quick google search but didn't find anything to note here as far as exploits.

• The page source didn't have anything but I submitted another order and captured the submit with Burpsuite to see what happens.

• I had to look a hint on how to add some language in here to exploit the search. The source page shows that it gathers information from the server on the front end.

• We can use HackTricks to put together some server side XSS:

<iframe src=/home></iframe>

• I will use an iframe to display the source information. From this I can add a quick look up to the /etc/passwd file for users and passwords.

• I will now take the orderId given and check out the browser page the was given for the PDF reciepts.

http://dev.stocker.htb/api/po/[ORDER ID]

• Looks like we have access into the system so let's see what else we can dig up.

• Let's adjust the size of the iframe to see more.

<iframe src=/etc/passwd height=650px width=600px></iframe>

• I now have a few usernames:

  • mongodb

  • angoose

  • _laurel

• I started exploring the system painstakingly but when blindly reaching around, I wasn't getting anywhere quickly. I looked up a hint and they told me to go look in the index.js file.

• I used the following payload below to go to the file from the usual input method above.

<iframe src=/var/www/dev/index.js height=1000px width=1000px></iframe>

• In the index.js file there are some credentials. I first tried them on SSH with mongodb but that didn't work so I tried it with the rest of them.

ssh angoose@[Target IP]
IHeardPassphrasesArePrettySecure

• And that worked.

• The user flag can be found with the following below:

cat /home/angoose/user.txt

USER FLAG: 973aa973087ab3ff12d0b9969a701872

• Next is the root flag. It was kind of interesting because when I ran the ls command on angoose directory I found that linpeas was already on there. Before I run it though, let's see what privleges I could possibly abuse to get root privileges.

sudo -l
IHeardPassphrasesArePrettySecure

• It looks like I can run any javascript file in the /usr/local/scripts/ directory. Let's go check that out.

• It looks like I only have read access to the .package-lock.json file which looks like it just lists dependencies.

• When I try to run the files though, it does not let me run them as sudo.

sudo node creds.js

• The key here is that you have to specify the path to node:

sudo /usr/bin/node /usr/local/scripts

• Without specifying the path it won't work. Here is where it get's really weird. Back on the angoose directory, we find a cleanup.js file. If we cat the file, we find it is a javascript file that reads the root.txt file in the root directory.

const fs = require('fs');
fs.readFile('/root/root.txt', 'utf8', (err, data) => {
 if (err) throw err;
 console.log(data);
});

• So, how do we run this file if it is not in the /usr/local/scripts directory? And we can't create a new file in that directory due to permission issues.

• This is where it get's interesting and I would not have figured it out on my own but is a good trick to keep in mind.

sudo /usr/bin/node /usr/local/scripts/../../../home/angoose/cleanup.js

root.txt: ea3b7425be2a6fb9134731e9bf8c3042