Technolution

Page takes a “pin” and sees if it matches what’s expected via hash functions, if so, we can add our name to Hall of Fame.

Page does checking in javascript, so let’s take advantage.  Copy top of page, and wrap in a brute force function, to check through all values.  Put new code in new, local, .html file and brute force the PIN.

Brute force function:

function brute() {
var str;
for(var i = 1000000; i < 10000000; i++) {
str=i.toString();
//alert(‘converted’+str.length);
verifypin(str);
}
alert(‘Reached the end ;c’);
}

Put brute() on an onLoad for a new page, and load that page.  About 3/4 of the way through, we get our answer and we have brute forced the PIN by barely writing any new code.  YAY!

In today’s post, we’re going to be looking at the Damo Security Challenges, specifically Challenge VI.  This page can be found here.  Let’s head over to the page and get started.

Once at the page, we can see the familiar layout of a Member’s List, Member’s Only page, Hall of Fame, Login and Register.  If we register and login, we are again presented with a message saying we can add a user to the Hall of Fame if we are an admin.  Another thing to note, is if we log in, on the login page, there is a button for “remember me”.

If we have remember me turned on, we can look at the cookies that are saved on our side.  There are two cookie values saved, one for username and one for password.  We can also see the values for these cookies end in %3D, which is an equals sign.  This gives us reason to believe it’s padding from base64 encoding.  Thus, we can use a small php snippet to verify.  Running <?php $str=’VALUE_OF_USERNAME_FROM_COOKIE’; echo base64_decode($str); ?> returns our username.  Doing the same with the password returns our password.  Thus, we can assume these are used on the server.

The first attack is to try and replace our username cookie with the value which would be expected if we were logged in as admin, so use a php snippet to get ‘admin’ base64_encoded <?php $str=’admin’; echo base64_encode($str);?> and put that into the username cookie and try to submit our name to the hall of fame.  This doesn’t work, and we’re told we have to be admin.

The next attack is a little trickier and involves SQL Injection.  First, let’s think about what happens when a name is submitted to the Hall of Fame.  Since a username and password are supplied as well, we can assume the php script checks if there is at least one matching user for the username and password, and if the username is admin.  If so, the submitted name is added to the Hall of Fame.  So, if we can do SQL Injection and return at least one match, we should get added to the hall of fame.  So, let’s think about the SQLi we want.  The injection can be in the password and return true, thus the basic sqli works: ourpassword’ or ‘1’=’1  However, to get this into the sqli, we have to base64 encode it and submit it as our cookie value for the password.  So again, php <?php $str = ‘something\’ or \’1\’=\’1′; echo base64_encode($str); ?>.  Now we submit the previously calculated value for ‘admin’ as our username and this SQLi value as our password via cookies when we try to add a name to the hall of fame.  If done correctly, our name gets added. 🙂  YAY!

So What?

SQL Injection, it’s not just for query strings.  Injection vulns come from any place where users can provide input, regardless of if it is in a query string, a post body, a cookie value, an AJAX request, if it comes from the user’s computer, it can result in injection.  Also, base64 isn’t encryption, it’s encoding, so anyone can do it and thus it doesn’t provide any safety in this context.  If you want to put a cookie on a user’s computer, encrypt it with encryption with a private key such that the user cannot create a correctly encrypted string.

In today’s post, we’re going to be looking at the 3rd Web Security Challenge by Damo.  This page can be found here.  So head on over to the page, and lets get started.

Once there, we can get an idea of what this website does.  It has a front page, a member’s list, a member’s only page, hall of fame, login and register pages.  We can register and make an account, and if we do, we get a message saying we can post a name to the hall of fame if we’re an admin.  Thus, one way to post to the HOF is by getting access to an admin account.  If we look at the members list, we can see 5 accounts belonging to various admins (with names such as Stallone, Li, etc).  We can also note this is a php site, and assume there is a DB for holding all the information.  Thus, let’s try SQL Injection.

Trying to do injection on the login page doesn’t provide much feed back.  However, if we go to the member list page and click on one of the members, we’re taken to a page that lists their info (http://damo.clanteam.com/sch3/member-info.php?id=1).  From here, if we try to inject a single quote into the id param, we get an SQL error and notice we can inject SQL.  A hint is also displayed on the page showing a union with 5 fields, one of which is sqlite_version(), thus we can assume the DB is running SQLite.

So, let’s try adding a union onto the query, but do a union that pulls from the sqlite_master table so that we can start getting some table names and reading through the DB.  If we hit the point http://damo.clanteam.com/sch3/member-info.php?id=9’%20UNION%20ALL%20SELECT%201,2,3,sql,name%20FROM%20sqlite_master%20WHERE%20type=’table’–%20–‘ we see there is a hall_of_fame table.  Trying to insert into the table directly doesn’t work (went there, tried that), so let’s try to find other tables. So let’s add onto the query an ORDER BY statement and order based on name.  Doing so returns info on the accounts table, mainly the SQL used to create it: CREATE TABLE [accounts] ( [id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, [username] TEXT NOT NULL, [password] TEXT NOT NULL )

Now that we know the accounts table holds username/passwords, we can pick one of the admins from it and get their username/password!  http://damo.clanteam.com/sch3/member-info.php?id=9’%20UNION%20ALL%20SELECT%20username,password,1,2,1%20FROM%20accounts;–%20–‘ gets us:

First Name: stallone
Last Name: PASSWORD_HASH

Now we can take the password hash, throw it in a file and run it through John the Ripper and in less than a second are presented with the password for the stallone account.  Now we can simply login with the username and password and add our name to the hall of fame!

So What?

SQL Injection is bad, mmmkay.  Use parameterized queries, or whatever the language you’re using calls it.  Don’t directly concatenate user input into an SQL query via String concatenation.

Feature, information leak, same thing.  At least sometimes?  It turns out this is the fact with the iPhone 5 and strong passcodes.

Many people are familiar with passcodes used to protect phones now-a-days.  These passcodes are used to unlock the phone for use after a period of disuse (such a minute, 5 minutes, or even instantly as soon as the screen is turned off).  The iPhone 5 supports two types of passcodes, “simple” and otherwise.  Simple passcodes are limited to numbers only, and always have a length of 4.  Non-simple passcodes can use letters and numbers and can be up to 10 characters long.  Since simple passcodes only involve numbers, the input screen shows a number pad for input.  However, with complex passcodes, the situation is different.

With complex passcodes, if we have both letters and numbers in our passcode, the input screen shows the standard on screen QWERTY keyboard.  However, if a complex passcode only contains numbers (greatly reducing the complexity and attack space), the QWERTY keyboard is not shown, and only a number pad is shown.  This usability (?) choice (?) directly reveals that numeric-only complex passcodes are numeric-only to potential attackers without them having to know anything about the password and greatly reduces the security of numeric-only passcodes.  However, who wants to enter numbers on a QWERTY keyboard on a touch screen?

Choices.