"If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle." - Sun Tzu, The Art of War.
Take the immortal words of Sun Tzu, know yourself. Or here, know your code. Do you know how your code will react to an attack? Do you know if your application or data is secure, or if there are huge security holes? If your application were under attack, would you even know it?
And what about know the enemy? Do you know how a hacker will attack your application? Do you know what early warning signs to look for, to detect when your applications are being hacked? Have you ever looked at your application as a hacker would, and thought about how you would attack it? As a professional hacker, in this article, I will guide you through the process hackers take to exploit applications and systems.
I'm often asked, "What should I worry about in my code that hackers could exploit?" This is easy enough to answer for risks we know about today, but it doesn't address the real problem. I can tell you about the most popular attack vectors for today's applications, but that will only help you today. To truly help you become more secure, I need to teach you what to look for. I want to enable you to do the analysis. This follows the old proverb, "Give a man a fish and he will be able to eat today; teach a man to fish and he will never go hungry." This is true for security and your applications — well, not the whole fishing part, but the teaching part. You get the idea.
Our Mark
Okay, enough proverbs — let's get down to it. For the purpose of this article, we focus on Web applications. Take any application you can find on the Web. It could be written in ASP.Net, PHP, JSP, ASP, etc. This article is to help free your mind (couldn't resist the reference) to look at your applications as a hacker would, no matter how the applications were written or what language they were written in.
Take any application on the Internet. Perhaps its amazon.com, that allows users to login, make purchases, and search for items to buy. Maybe we are looking at ebay.com, which also allows users to login, search, and list items and descriptions to be shown to potential bidders. Or consider a site like http://forums.station.sony.com/swg, a forums site for online gaming that allows users to post text and potentially pictures.
Enter the Hacker
There are many reasons people are attracted to hacking. The three reasons that seem to always bubble to the top of the list are personal gain, revenge, or power. Some hackers hack to get services or products for free or to steal money. Others hack to get back at the hosting provider or at the employer who spurned them. Most hackers, however, just love the power: the feeling of ultimate control once you manipulate the system, bend the rules of the matrix if you will, allowing you to assert control over a system that seemed otherwise impervious to attack.
As a professional hacker, I can say that there is nothing random about the way a hack is crafted. The beginning of every hack starts with information. For the rest of this section, I would like you to think like a hacker. Picture an application in your head, or visit one on the Web, and look at that application with the full intention of hacking it.
LEGAL DISCLAIMER: Please do not go hacking sites because "Duane told me to do it." I said, just look at the site, don't hack the site.
What's the first thing you do? This is the question that stumps most beginning hackers. People say "Sure, it's easy to hack," but saying it's easy and actually knowing the steps in the dance are two very different things. Let's look at them.
To hack an application, you must know all there is to know about that application.
The first thing most hackers do is use a combination of automated tools, such as retina or nikto. They also enumerate your site manually, to understand as much as possible about your application.
Hackers look for:
* Places data can be submitted to the server, including search fields, data entry, registration pages, and forum posts.
* Format of the URL. Your standard URL format sometimes gives away hints about the underpinnings of what data is being sent back to the server. As a result, it can give the hacker an easy way to manipulate the data stream.
For example, if you had a URL, http://my.website.com/TestPage.asp?User=jsmith, I could try to change jsmith to something else.
* Hidden fields in the pages, such as viewstate, input fields containing important information about security or pricing, etc. These fields, although they say they are hidden, really are accessed easily by the hacker. A program called Achilles allows a hacker to manipulate all data sent from the server to the client and all data sent back. Achilles allows all hidden fields to be seen, and their values to be changed.
* Client-side validation. Sometimes, client-side validation gives the hacker insights into the method you're using to ensure your fields are safe from hackers: what checks you are doing, and in what order.
Armed with this information, the hacker can plan an attack suited for your site and application
Anytime your application allows a user to submit data, you should worry. I know what you are thinking. "Duane, we validate all information the user types in our application to make sure it's not malicious. We don't need to worry about this... do we?" It's great that you check all input fields that users can type data into for malicious code. But what about fields they can't type into?
Most people only worry about data that is submitted to the server in a textbox. There are many places data is submitted back to the server, such as via a drop down list. It's easy for a hacker to change the values in the list on the client side, and submit to the server. You need to validate on the server side each and every field that has data the user could have manipulated on the client.
What do you do, once you find out someone has attempted to inject SQL code or other bad things into your input fields? The tendency in our industry is to be helpful. We try to clean up the input, so it's safe enough to put in the database or execute. However, this is a fundamentally flawed mentality.
If someone enters "SELECT * FROM tblCreditCard" as his username for the login of a site, you probably don't want to try to clean that up and then submit it to the database. If any fields are not what you expected, then don't allow the page to execute.
Each and every time your application gets input that was unexpected, it should be logged somewhere! I know what you are thinking: "I have tons of logs already that I don't get a chance to read. Why, oh why, would I want another?" Logs are the only way you can tell what's going on with your application. It's like buying stuff and not keeping the receipt. If, next month, you get a bill from a vendor charging you double what you were told the cost would be, you wouldn't have any proof because you didn't keep a log of the original charge.
Understand the Entire Attack Surface
Keep in mind that most hackers aren't trying just one way of getting into your site. They try hundreds or thousands. The ones who hack by hand (not using automated tools) systematically test each link in the security chain to see which is the weakest. In hacking sites, I've noticed that I usually get access through the systems or sites people didn't know were there or didn't care about. ("We don't really care what happens to that server. We're really concerned with our credit card processing server that sits next to it.") As a hacker, I just need one entry point, one way into your network — and from there, I will set up my base of operations and start moving inside your defenses.
For example, let's say we have a Web server with twenty different Web sites hosted on it; we're an ISP. Now does it seem weird, if we look at our logs and see a random IP address hitting one of those sites? The answer is usually No. We expect people to use the Web site, and we don't block access by IP address. Would it be odd for all the sites on that box to be hit by one IP address? Usually, the answer to this question is Yes. That would be weird, because the audience of each site is different; it would be highly unlikely for one person to hit them all. Could this be a hacker testing the electric fence, surveying the terrain to see where the weakest entry point is? Could be — yet most people don't think of looking for this type of anomaly.
One last point. Trying to track a hacker on the Internet is like trying to track the wild Yeti in Nepal (I'm not sure there are any tamed Yeti...). But in any case, if the Yeti left no tracks, was silent, and hid where you weren't looking or in a place you didn't know existed... would you find him? If hackers can poke and prod your application and potentially get access to sections of your code or data that you weren't expecting them to, will you know they are there?
Neo: "What? Are you trying to tell me that I can dodge bullets?"
Morpheus: "No Neo, I'm trying to tell you that when you're ready, you won't have to."
I could tell you about all the latest exploits and exactly what to look for today to fix your specific application and make sure it's secure. We would talk about buffer-overflows, SQL injection, Cross-Site Script hacking, the list goes on and on. We would be essentially attempting to dodge the bullets; trying to worry about each and every little incoming attack.
Once you are ready, once you start thinking about your applications and the environment in a holistic manner, and once you control your applications to react the way you want them to or log the activity when they don't, then you will be able to protect against attacks that haven't even been dreamt up yet. I'm not saying your application will be 100% secure, just that your application will always be under your control. You will always be aware of what's going on and what your threats are. That is the true nature of security. It's all about control. You want to be in control. Logs, coupled with a strong understanding of how you may be attacked, is a huge step in the right direction.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment