Thin client insecurity (and other terrible implementation ideas)

Recently, I started a review of what I thought was going to be a standard web application penetration test (WAPT). I began growing a little suspicious about this app when the client mentioned that I *had* to use IE to interact with the server. I always find amusement in statements like “This website is best viewed using Internet Explorer x or above”.

As soon as I hit the website (before logging in) the server tried to push down a large bundle of files (including an executable). Playing the role of a regular user, I happily signed my system’s security away, by allowing all these files to be downloaded to my test box. As soon as the download was complete I proceeded to authenticate to the website. After authentication, the custom web browser pops up. I’m now thinking ‘Great! This WAPT just turned into a WAPT + reversing gig’.

After toying around with some basic binary analysis/reversing techniques, I learned enough about this custom browser to deduce it was written to standard Win32 and contained nothing potentially dangerous for the end user. Now, moving on to the actual testing of the application”¦

I started off by doing the basics: configuration management testing, authentication testing, etc. Immediately, I was faced with figuring out how to proxy these requests. Once you move away from a standard web browser and all the tools written for it (e.g. Firefox and it’s awesome extensions), I was a bit confused as to the best technique to use to MITM this app. That’s when a fellow Foundstoner pointed me to Fiddler –I can’t believe I haven’t used this proxy before! Fiddler proxied this custom browser flawlessly.

After some initial testing, I can tell you this browser is most likely an attempt at security through obscurity. I have no idea why it was created. It brings nothing to the table in terms of features or security. Here’s just one of many examples why:

Note: Certain fieldnames have been removed to protect the innocent.

Problem #1: Session ID in URL – classic. Read this OWASP page on session management for more information.
Problem #2: Sequential user IDs – also a classic.
Problem #3: This request is gladly accepted by the server. And, although you can’t see it, your password bypasses validation.
Extra credit – Problem #4: (A closer look at Problem #2) Why would this request contain a user ID? Guess what happens when you change the value of this ‘id’ parameter? Privilege escalation!!!

Bottom line:

• There are many significant issues in this application and most others.
• The custom browser seems like an attempt at getting the end user to play by certain rules. Those rules should also be enforced at the server side.
• If you haven’t played with the Fiddler proxy, you’ve got to check it out. I used to think that all proxies were mostly the same – they’re not.
• Make sure all your application developers, designers, architects, managers, etc are all familiar with OWASP and software security fundamentals.