Pentestit.ru lab 12 DB flag (10/16)

Write-up for the Pentestit.ru lab DB flag.

The lab is available under https://lab.pentestit.ru/ address. This series deals with 12th installment of the challenge. It is a CTF laboratory with total of 16 flags to find. In the following series each post will deal with one token. I’ll be be publishing them along with solving these challenges.

Reversing JAR file

In the previous episode we’ve looted a JAR file from the repository. Let’s try to peek inside and see what it’s doing:

Let’s decompile Main.class:

The Java program is a simple client. It is used to list Helpdesk requests in the console. It can be used in 3 modes: list all requests, list given user’s requests or all unclosed requests:

Depending on user’s choice the, JSON payload is created and sent to IP 172.16.0.55 on port 5074 using SSL connection:

Similarly, decompiling Reqvest.class reveals what payload is expected. “Type” field determines mode. 0 should return all requests, while 2 all unclosed. Mode 1 takes another argument named “params1” that filters requests by user:

Accessing service

Let’s test this knowledge in practice. Unfortunately it’s not possible to connect to the service from attackers machine:

Maybe the service is visible from some other subnet. Users maybe?

Ups, connection didn’t work, our client doesn’t like offered ciphers. Let’s see what is available:

Now we can use one from the list and force it’s usage:

This time the connection works:

Let’s make it easier and forward that port to attackers machine

Now, the service is available on attacker’s machine localhost:

SSL connection

From reversed Java code we know that connection uses cllient’s certificate to connect. It is embeded in the jar file and was extracted to a cert.p12 file. OpenSSL uses pem format so let’s convert it:

We also need to unpack server’s CA from Java’s keystore tr_cl:

Now, let’s make a test connection:

The (cat request; cat) construction is needed because OpenSSL terminates after it’s input stream is closed and thus before receiving server’s response. Cat keeps the stream open.

SQL injection

Requests in type “1” require additional argument with a username. Maybe it’s vulnerable to SQL injection? For payload:

Server returns:

There it is! The following payload should return tables and columns available:

The answer:

We’ve found token table! The following table will list the flag:

Summary

A little more work this time. We’ve reversed the client.jar program to find the location of the server and it’s protocol. Then we’ve used SSH port forwarding to gain access to this server through Users subnet. Finally we’ve used OpenSSL to create a SSL connection to discover and exploit a SQL injection vulnerability.