Exploring the website

The target website “Sense and Sensitivity” is a simple static website with a home page and the login page. Here I tried the common admin:password credentials but that didn’t work.

Sensitive files

Moving around the site, we get to the /assets/ page for the directory listing of publicly accessible assets (images, css, js, and others). Here we see that a webapp.db is also present.

alt Assets directory showing a webapp.db file

It also shows us the service that is running Apache/2.3.29 (Ubuntu) Server and the port 80.

Database

We explore the database by generally following these steps:

Interact with the database
Enumerate tables
Enumerate columns and showing the data

Interacting with the database

This is a flat file database SQLite. GUI applications for exploring SQLite databases exists, but I’d like to stick to the traditional command line interface at least for a quick glance on a small target.

Enumerate tables

alt Showing the users and sessions table

Here we can see that there are two tables in the database — sessions and users.

Enumerate columns

The users table has four columns: userID, username, password, and admin. Then we can show every record in the users table. Users admin and Bob seems to be interesting as they show admin = 1 which indicates that theses could be administrator accounts with administrator privileges.

Meanwhile, the sessions table have the columns: sessionId, userID, and expiry. Since this is empty, we only limit our knowledge gathering to the users database.

Exploitation

We exploit this knowledge of the database exposed to the public assets directory, extract the passwords and try to crack them to see if any one of them is useful. There are encrypted passwords that Crackstation has. successfully cracked. Luckily we also have two of them belonging to admin users. Using this knowledge, try to login with the page.

Post-exploitation

And … we are in!

I tried adding another user with a somewhat similar username as admin,

" admin"

(notice the space), and the form just accepted it. To confirm how this actually is saved in the database, just download the webapp.db again. The records clearly show, on the screenshot below, that there is no input sanitation. This weakness may potentially lead to broken authentication.