SANS Digital Forensics and Incident Response Blog

Client-side Web Application Attacks

Over the past few years, attacks against web applications have become more prevalent and sophisticated. There are several methods of attacking web applications, SQL injection being one of the more well-known. In this article, we are going to discuss a different class of attacks and a few examples of how an incident responder or computer forensic investigator might spot them.

All web forms contain fields that are used to grab input from a user and post it to the server for processing. Form fields are commonly used to collect information, from transaction details on e commerce sites to authentication credentials for restricted content. While form fields are used to collect data legitimately from users, they can also be used maliciously.

An example of this is a client side attack commonly known as form field injection. In this type of attack, malware interacting in a web browser adds additional form fields to valid form fields on a web page (search for BHO html injection). The purpose of injected fields is to trick users into revealing sensitive personal information like passwords, ATM PINs, and credit card numbers. This information is captured and transmitted to remote drop sites where it can be used to perpetrate identity theft or fraud. Several classes of malware are capable of performing this kind of attack, including the widely used ZeuS.

HTML injection attacks take form field injection one step further. Instead of inserting a form field into a web page, HTML injection replaces legitimate HTML coming from the server, similar to a "cut and paste" function. The replaced HTML is overwritten by the attacker's HTML and the original, intended content is never rendered by the web browser. This type of attack can be used to alter the logical flow of a web application. For example, legitimate data on a web page, like an account summary, can be replaced by a form asking for a user name and password. After data is entered into the form, the legitimate data will be properly displayed. This may look like an additional level of authentication, tricking a user into entering credentials which are captured like the form field injection attack described above.

Why is this information important to incident response and digital forensic professionals? Both of these attacks are client side attacks. When investigating web application compromises, investigators may not have access to the client side computer. However, since injected fields are part of a web form, they may be transmitted in the POST request along with legitimate fields on the page back to the server. These artifacts may appear as anomalous data in the server logs. For example, a user name field appearing on a POST other than from a legitimate login page should be investigated further.

In summary, being aware of current attacks, how they are preformed, and the resulting artifacts or signatures they may leave behind can be a great benefit to an investigator. By knowing of and looking for these signs, investigators can recognize and respond to incidents faster, resulting in less impact to the organization/agency. It gets back to the old adage of knowing your system, data, flows, etc. Focus on any abnormal deviation from these legitimate patterns as they may be a tip off that an incident has occurred.

Chris Silveira manages the CSIRT and Paul Yacovetta is a forensic engineer at a financial institution.

3 Comments

Posted April 9, 2010 at 11:18 AM | Permalink | Reply

Ram

>> On HTML form field injection this article says "This information is captured and transmitted to remote drop sites where it can be used to perpetrate identity theft or fraud. "
This is perfectly understandable.
>> On HTML injection, "After data is entered into the form, the legitimate data will be properly displayed."
I have a question on this ''" what happens to the data in the form or more appropriately what does the fraudster do to capture the data the user is tricked into entering?
>>Similarly this ''" "since injected fields are part of a web form, they may be transmitted in the POST request along with legitimate fields on the page back to the server"
Why would the data be posted back to the original server? Doesn't the fraudster gain only when the injected data is transmitted to a remote site where they can retrieve it for misuse?
Thanks in advance,
Ram.

Posted April 15, 2010 at 3:47 PM | Permalink | Reply

Chris

Sorry for the delay in response Ram.
>> On HTML injection, "After data is entered into the form, the legitimate data will be properly displayed."
> I have a question on this ''" what happens to the data in the form or more appropriately what does the fraudster do to capture the data the user is tricked into entering?
The malware that injects the illegitimate form fields captures the data and transmits it to a pre-configured drop server. The fraudster picks it up there any number of ways.
>>Similarly this ''" "since injected fields are part of a web form, they may be transmitted in the POST request along with legitimate fields on the page back to the server"
> Why would the data be posted back to the original server? Doesn't the fraudster gain only when the injected data is transmitted to a remote site where they can retrieve it for misuse?
That is an excellent question that we have asked ourselves. The point that we may not have made clearly enough is that the data may be posted back to the web server in addition to being transmitted to the drop server. The browser considers the injected fields to be part of the legitimate form and will send them back in the POST request if the malware doesn't remove them first. In this scenario, the data potentially ends up in two places: the browser sends it to the web server, and the malware sends it to its drop server.
Chris

Posted February 11, 2013 at 5:19 PM | Permalink | Reply

Jeffrey Koontz

are there any basic fixes for this? On the networking side? As a web user are there signs to look for? Would a text based browser be a protection?Doing some research for a network security class and any elaboration would be appreciated. Thanks