well...

 url: http://ringzer0team.com/challenges/171
flag: FLAG-0Kg64o8M9gPQfH45583Mc0jc3u


this challenge wants us to perform a 'data truncation' attack on the underlying
dbms system.

«what's 'data truncation'?»

ah-ha! bobby, that's a really interesting question indeed! here, take this url
http://planet.mysql.com/entry/?id=14365 and rtfm, bobby.

for those of you whose name isn't 'bobby' (not even 'robert', just 'bobby'), a
column (or data) truncation vulnerability is an implementation flaw where the
users' input isn't being properly sanitized during an UPDATE or INSERT clause,
and pairing that with a sized column value (eg: varchar(20)) with mysql's
relaxed comparison rules when outside of a binary context comparison grants us
an interesting scenario, one where we're able to insert a 'comparison' similar
value into a field.

what do i mean by 'comparison similar'? let's take this challenge's scenario
for example:

    . upon registering the engine will check for an existing row with the same
      username to avoid duplicates:

        SELECT id FROM users WHERE user = '$username'

    . if the previous query returns 0 rows, it will then proceed and insert the
      new user:

        INSERT INTO users (user, pass) VALUES ('$user', '$pass')

what's the deal here? see, let's assume 'user' is a field whose type is
varchar with default limits (20), this means we can register as, say,
'123456789-123456789-' and everything will be fine and dandy but what happens
should we try and submit '123456789-123456789-12345' as our username? we'll get
truncated back to '123456789-123456789-'. nothing out of the ordinary.

now, onto the 'what if's: what if we register as 'admin               x'?
those are 15 blanks followed by one char and preceded by a 5 char string. that
is 21 chars worth of stuff, so following the rule above we should just get
truncated back to 'admin               '. true, and that is mysql working as
intended, nothing out of the ordinary here either.

thing is, the first SELECT will return false, since there's no "21 chars" user
in the table, and INSERT will insert our row truncated to 20. the problem lies
in mysql's loose comparison for the login's SELECT - when in non-binary mode
comparison, 'admin               ' and 'admin' are the same to the dbms, all
trailing whitespace is stripped. thing is, 'admin               ' has a (to us)
known password, while 'admin' doesn't; but since mysql treats both usernames as
equal, we can now login as 'admin' with our password, because:

    SELECT * FROM users WHERE user = 'admin' AND pass = 'kek'

will return our row.

    > Welcome back admin FLAG-0Kg64o8M9gPQfH45583Mc0jc3u

weirdly enough, i ended up buying a hint for this one because the truncation
(first thing i tried) didn't seem to work (bad timing i guess), so i also tried
updating the table, inserting rows and whatnot; in the end i've come full-circle
and went back to truncation.