search

Enumeration

hashtag
www-data

www-data@agile:/etc/nginx/sites-available$ cat superpass.nginx
cat superpass.nginx
server {
    listen 80;
    listen 127.0.0.1:80;
    server_name superpass.htb;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_send_timeout 300;

    location /static {
        alias /app/app/superpass/static;
        expires 365d;
    }

    location /console {
        rewrite ^/console$ /console0xdf last;
    }

    location / {
        #include uwsgi_params;

        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Protocol $scheme;
    }
}

The directory shows here is /app. Inside /app.

So we have two superpass folders. One in /app/app and the other one in /app/app-testing.

After connecting to the mysql.

This is the table where registered users are kept.

0xdf and corum are default.

I tried cracking the hashed_passwords but failed.

We see agile as well. With user corum's password. But I took all the username=passwords in different files to run a brute-force. We know the SSH port is open.

We get a hit!

hashtag
ssh - corum

circle-check

I like how ippsec did it. He first ran ps -ef --forest to see all running processes(ps) and detailed tree view (-ef --forest). Which then shows the following.

Two python applications on different ports (5000,5555) and different users (www-data,runner) running. And then he went into / to find files with strings 5555 which exposes the /etc/nginx site configuration files, exposing two different files, one is exposed to the internet and the other one is only accessible internally.

They way ippsec did the box its much cleaner imo.

Once in, I digged deeper into the /app-testing directory. I found this interesting file , but we cannot read it.

Its been used by test_site_interactively.py.

circle-check

Selenium is used to test web applications directly on browsers like chrome through Python code. And inside this file we see that, its using the contents of creds.txt which are the usernames and passwords, against the application to see if its working.

There is a line here saying --remote-debugging-port=41829. Its a hard-coded port.

And it is open.

This site is also alive.

We cannot access it from outside. It redirects us back to the default site.

We have to access it from localhost. We can tunnel our localhost to SSH. So we can access port 5555 from our localhost.

So I registered a new user here. But it doesn;t reflect on the mysql database.

Previously we saw the line --remote-debugging-port=41829. I found an articlearrow-up-right that explains the attack path. We can abuse that by creating a tunnel between our host and the linux host.

Once thats done we can connect it to our chrome debugger by going to chrome://inspect/#devices > configure > add localhost:41829 > done. We should see a new remote device.

When inspecting it and going to vault we find some new credentials.

I can use that to ssh in as edwards:d07867c6267dcb5df0af

hashtag
ssh - edwards

Opening these files gives us two credentials.

Trying them both to get root failed.

But we do know that cred.txt is used by the /app/app-testing/tests/functional/test_site_interactively.py file.

PreviousFootholdNextPrivEsc

Last updated