Web applications are now the next big victim after games for hackers .
A recent research shows that 70% of vulnerabilities exist at the top layer of the web application.
The attackers use several techniques to hack web applications . I have been constantly monitoring different types of web attacks involving different methods but there ar some common steps which all hackers follow in order to perform their attack on applications. I am presenting a 5 phase method which covers from gaining information to maintaining the attack on the application . You can also read one of the most popular articles of this blog - How to hack a website/web server - a 3 step guide.
Phase 1: Silent reconnaissance
The attacker gathers as much information as possible identifying potentially vulnerable areas of the application. This is done discretely using tools such as Web debugging proxies to monitor the traffic between the browser and the Web server. The attacker traverses the site, much like a normal user, while collecting valuable information about how the application works. This activity goes undetected, because as far as the server is concerned, it represents the traffic of a legitimate user.
At this point, the attacker will stop interacting with the target server directly. The attacker will spend significant time reviewing the data collected by the debugging proxy and extracting useful facts about the environment. This may include the type of hardware and software in the network architecture, programming languages, libraries, source code and comments. This information will be leveraged during the later phases of the attack.
Phase 2: Attack vector establishment
This phase begins once the attacker has gained an understanding of the application design and the breadth of its attack surface. Until now, the interaction with the server has been fairly benign and undetectable, but in the next phase, things get a little louder. For this reason, the attacker will often start using an anonymous proxy to interact with the server.
The attacker may also employ other protective measures such as browser privacy controls, firewalls, antivirus and virtual machines. Once the attacker is confident that his traffic can no longer be traced, the real work can start.
With notes in hand, and a debugging proxy up and running, the attacker starts to seek out dynamic pages, especially those which accept form or query input. The attacker will then determine what the various input parameters are, and attempt to derive boundary cases for them. Boundary case values are sent to the application to provoke an unintended response from the server
The attacker repeats this activity on all dynamic pages that he is aware of. When finished, he has a list of all the parameters that are correctly validated by the server, and more important, the parameters that are vulnerable -- they produce calculation errors, fatal errors, or are blindly injected into the response without encoding or cleansing.
The attacker tailors the boundary cases so they do not match any known attack signatures, so this activity is almost always imperceptible to server administrators. The attacker still has to remain anonymous, because many applications keep track of errors and record the addresses of the clients responsible for generating them. Because of this, administrators could discover the activity later by inspecting logs with a security tool. However, this is typically long after the attacker has moved on to the next phase.
If the attacker was able to obtain a large number of potentially vulnerable inputs, the next step is to start testing each one to see if an attack vector is possible. For example, if the attacker received an SQL error when submitting a value of "my'username" in a login form, then there is probably an SQL injection vulnerability. The attacker will start supplying more structured SQL syntax into the input in an effort to shape the resulting error.
Phase 3: Implementation
This phase begins once the attacker has identified the vulnerabilities and their associated attack vectors. This is where the real damage starts. The scope of damage depends on the types of vulnerabilities that are exploited. For example:
• The attacker starts to mine the database for sensitive information, delete existing information, or insert new fraudulent information.
• The attacker seeds the application with malicious code by way of XSS vulnerabilities and reflected parameters.
• The attacker designs complex phishing scams that use the vulnerabilities to give the scam credibility.
The possibilities are only constrained by the potential vectors, and how they can be chained together to deliver more powerful payloads. Most of the damage has been done at this point.
Phase 4: Automation
Attacks such as input parameter abuse are often single request vectors. This means the damage happens within a single HTTP request. Sometimes, however, the execution of an attack vector provides incremental benefits each time it is performed. Generally, if the attack vector generates revenue for the attacker, the next step is to automate the attack. This enables the attacker to repeat the attack vector over and over again, multiplying the overall monetary gain.
Because the attacker must still cover his tracks in order to execute the automated attack, he will generally code the attack into a remotely controlled bot. This tactic poses serious challenges for the administrator, because even if the attack is identified, an IP-based block will no longer be sufficient. To accomplish this, attackers will often use a prefabricated "command and control" kit that allows them to quickly raise and command a bot army.
Phase 5: Maintenance
Finally the attack is complete. The hacker has extracted as much data as his experience and skill allows. He will go off and work on other projects until his automated bots start to fail. This will signal that some fundamental vulnerability in the attack vector has been patched or modified. If the attacker cares enough, he may repeat the entire process over again, focusing on the parts of the application that are essential for the bots proper functioning. He will find a work around for the new patch, create an entirely new attack vector, or move to a different target altogether.
These phases clearly encompass all the techniques involved in penentrating a web application. The difficulty of the attack can vary according to the sofistication of the application.
No comments:
Post a Comment