Introduction

It happened. Someone told me a website was invulnerable.
Coincidentally, since it also happened to belong to a highschool, I took it as a challenge, obtained permission to find flaws in it and have found some pretty serious ones later on. The flaws have since been patched.

Blind, Boolean-Based SQL Injection

SQL Injection (SQLi) is a vulnerability which allows an attacker to inject malicious code into SQL statements.

When using such a vulnerability, an attacker may be able to create, update and delete database information.
It is one of the most common web hacking techniques.

Finding SQL Injection

In the reconnaissance phase, which is a preparation phase when a potential attacker seeks to gather information about the target, I noticed an ID in the URL.

I started probing for SQL injection, and was greeted by a blank page.

Lets break it down..:

• The URL contained a GET parameter called ‘bid’.
• Since the URL contained the parameter, it is logical to presume that the website would run a SQL query according to it. For example with GET parameter value set to ‘1’ the query would become something like this:

SELECT * FROM table WHERE something = ‘1’;

• If there is nothing preventing a user from entering malicious input, an attacker could enter something like an apostrophe (‘), which should return an SQL error, because the query would then look like this:

SELECT * FROM table WHERE something = ‘1”;

I started out with adding “OR 1=2” to the URL just to find out that the request would get blocked. Bummer.

However, just a few weeks ago I was teaching myself boolean-based SQL injection, so I decided to give it a try..

After a couple of queries have failed, I decided to would try one last time before giving up and my query quickly became “and ascii(substring((SELECT concat(username,0x3a,password) FROM user LIMIT 0,1),1,1))>96”

It executed. The page loaded normally.

However, when I used “and ascii(substring((SELECT concat(username,0x3a,password) FROM user LIMIT 0,1),1,1))<1” I was greeted by a blank page.

Lets break it down once again..:

• ASCII() returns a number code that represents a specific character. (65 – A, 97 – a, etc.)
• SUBSTRING() returns a specified number of characters from a particular position of a given string.
• CONCAT() joins two fields together.
• 0x3a – :
• user – MySQL table. (guessed)
• LIMIT 0,1 returns the first row.

In theory, by using this payload and changing the charcode and substring start positions an attacker could extract all of the usernames and the corresponding password hashes from the database. Not good.

When I found this, I was excited and decided to search for more flaws.

I found another one almost instantly. It was CSRF.

CSRF?

Cross-Site Request Forgery (CSRF) is an attack that forces a user to execute unwanted actions when they’re logged in to a web application.

As I saw that the website had a page that allowed users to change their passwords my first thought was that it might be vulnerable to CSRF – turns out I was correct.

CSRF Demo

I quickly realized that it’s possible to chain these two vulnerabilities (SQLi & CSRF) together. Here’s how:

1. The attacker must obtain the usernames and appropriate password hashes from the database. (This could have been accomplished by using SQL Injection or other methods)
2. The attacker must successfully crack the password hash to see the plain text version of the password.
3. The attacker must know the appropriate POST parameters that are used to change the password.
4. The user that an attacker is targeting must be logged in to the website.
5. Attacker creates a script that sends a POST request to the page, uploads that script somewhere on his server and sends a link to an unsuspecting user.
6. User clicks on the link just to see his password get changed.

Then i dug deeper and stumbled upon CodoLogic‘s FreiChat..

FreiChat & XSS

FreiChat instantly caught my attention:

What is a hardcoded password?

Hardcoding passwords is the process of embedding plain text passwords into the source code.

It would appear that FreiChat had done just that which is never good, so, thinking there might be another flaw, I visited CodoLogic’s website, downloaded the recent version (11.0) of the software in question and sure enough, I found a reflected XSS..

What is Reflected XSS?

Reflected Cross-Site Scripting (XSS) is a vulnerability where a malicious script is part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload.

I reported my findings to CodoLogic, they have confirmed the flaw exists and clarified it will be fixed in their upcoming releases.

It is important to note that the flaw only affected FreiChat 11.0 – newer versions of the software (the current is 11.1 at the time of writing) remain unaffected.

CodoLogic’s team have reacted to my report within minutes which in my experience is unusual, so kudos to them!

That’s it for the first part of the article, in the upcoming blog posts I’ll cover these vulnerabilities even more explaining how they work and how they can be mitigated.