|
Recently, I spent five hours in a rental car driving to from San DiegoLas Vegas. Yes, I could have flown and been there in less then an hour, but then I would have missed all the joys of the road. To be honest, I totally forgot how long it takes to drive there and somehow had convinced myself I could do it in two hours.
So, two hours into my pleasure cruise, it dawned on me that I was nowhere near Vegas. Instead, I was sitting in bumper to bumper traffic watching a construction crew working at “government pace,” resurfacing the freeway. Now I could have driven in my own car, but in a moment of brilliance I thought, “Why put the miles on my car when I can just rent one?”
So there I was, protecting my very comfortable car at home from an additional 760 miles (round trip) on the odometer, while I sat in an extremely uncomfortable SUV that smelled like a Tijuana jail cell. For those who have made the trip, you can also relate to the fact there are no tolerable radio stations to be found in the desert. At one point, I found myself listening to an AM station with two guys arguing about what space aliens actually look like. By the time I arrived in Vegas, I had already contacted Southwest Airlines and booked a one way ticket home. The rental car would not be seeing San Diego again for some time.
Why should you care about the misery that is my life? It might seem clear that this trip has nothing to do with networking and even less to do with web application security. Well, first let me state that this trip was long and miserable -- so be glad you only had to read about it. Second, this trip has everything to do with web application security. You see, when you develop a web application, you have every good intention of writing secure code. You plan out the design, you document the security concerns and you test the final application. It takes you six months, working 6 a.m. to midnight, but in the end your boss is impressed, you get a raise and everyone is happy.
That’s your first trip to Vegas. Time passes and you move up in the ranks and are no longer required to work such long, hard hours. Life becomes good. Then one day your competitor announces they are now offering some great new services through their online application. A wave of panic runs through your office, and upper management sends out word that they are no longer happy with the original application. You offer to update the application, and since it didn’t take you that long last time, you are pretty sure you can have it updated within just a few weeks -- like management has requested. And there it is, the beginning of your two-hour drive to Vegas.
Three weeks later, and two hours into your drive, you realize that you are screwed. There is no way you are making the deadline, you are no longer the hero and now it’s just figuring out how to save your own hide. Next thing you know, you are cutting corners, writing notes to yourself to remember to secure that code later, and partially documenting as you go along. You are not alone.
The fact of the matter is that most online applications that have been compromised are not exploited through the original code. Most often, it’s the software that is added later that causes the problem. This can be for a number of reasons from the scenario listed above to just a misunderstanding of how the original code was designed to work. Ultimately, the additional code fails to maintain the original level of security and problems arise. A few examples of exploits I have discovered in online applications can help to demonstrate where the breakdowns happen.
The First Example
About a month ago, I was testing an application of a financial institution. In this case, the company had hired two other organizations to write software to work together with its application to do online billing. You should always be concerned when you are attempting to coordinate software that ultimately is working between three separate organizations. It is not that it can’t be done, it just means that there needs to be far more communication and documentation, which often breaks down with larger groups.
In this case, there was a definite breakdown in how the security would work. The design was simple enough. A customer would log into one web site using his user name and password. Then, to transfer the funds, he would be handed off to a separate web site. The handoff would pass over the authenticated user’s credentials, which in turn would allow the financial institution to process the transaction.
During testing, I found that when the handoff occurred, there was a tracking number that was associated with the user. I thought this was how they were able to prove who the user was. I also assumed there was some kind of algorithm at work between the two organizations that worked on a timestamp of other such matrix that would allow for authentication between the two hosts.
Upon testing, though, I found that there was nothing of the sort. In fact, the tracking number had no bearing on the handoff at all. Instead, the financial institution was put into a position where it was forced to trust that the fields being submitted to its web server were accurate. In other words, I could create my own web page, browse to the page and submit any checking account number I pleased; and the data would simply be accepted as fact and processed by the financial institution’s web page.
The exploit? A malicious individual could transfer funds out of any checking account in the United States. Obviously, this was a major vulnerability. Once brought to the attention of the financial institution, there was quick action to get the issue resolved.
This type of vulnerability is not unique and I have seen many similar mistakes made when two organizations attempt to pass data between each other via web pages. A quick and simple solution to this type of vulnerability is to use an encrypted hash. Basically agree on a key between the two organizations, or if you have the capabilities, use a public private key system. Then, encrypt the data you wish to pass between the two organizations into a hash.
To the user, it just looks like garbled text; but to the receiving server, it can be unencrypted and used for the transaction. Of course, this is just one of dozens of possible secure solutions, but in a situation like this, you must be able to prove the data being handed to the server is truly verified and allowed to be sent.
The Second Example
Another situation I have seen time and again is where a page is added to perform a simple task and security is overlooked. I was testing a site, and while you were logged-in, the site used an encrypted session to track you online. This was very secure and I was having little success. Then, I went to a page that had been added to notify people about a new option for bill pay. The user was required to click a button on the page to validate that they had read it.
Once the user read it, it would not display again. The problem with this page was that the site did not use the encrypted hash that was used everywhere else. Instead, the user’s name and actual password for the fields were used. There was no reason I could see for doing this, other than the designers had thrown it together quickly and didn’t really give it much thought for security.
After a couple tests, I found that you could submit the name and any password you liked over and over and it would never lock the account. If you got the password correct, the page displayed. If the password was incorrect you were sent to an error page. Like most online applications, if I attempted to login with numerous passwords at the login prompt, the account would lock up after a few failed attempts. This page now gave me the ability to run brute force attacks against any account I wanted. In this case, the site used only numeric passwords, so it took only minutes to break accounts.
Of course not all online applications have security issues that are this blatant and easy to exploit, but I have found the majority of the applications I have tested have had at least one or more security issues that would have led to the compromise of confidential information. In most of the cases I tested, the vulnerabilities were due to additions that had been made to the original code.
So remember, next time you’re stepping up to make changes to an existing application, at a minimum double your estimated time. For you see, much like my two-hour drive to Vegas, your mind may have a funny way of shifting reality and taking you for a much longer adventure then you remembered.
About the Author
Jim Stickley is the CTO of TraceSecurity, Inc. (www.traceSecurity.com), a provider of enterprise-class vulnerability management solutions and security assessments. He can be reached at jstickley@tracesecurity.com.
Go Back
|
