Webinjects – The Basics
It’s not uncommon for malware to use a technique known as formgrabbing; this is done by hooking browser functions responsible for encrypting and sending data to a webpage. By intercepting data before it is encrypted with SSL the malware can read the HTTP header and steal usernames and passwords from post data being sent to a target website.
The purpose of webinjects
Sometimes formgrabbing isn’t enough: Most banks have security methods to combat man in the middle attacks. I’m just going to explain just one of the many security methods.
As well as the standard username and password, the user has a security pin number. During login the user is asked for their username, password, and 3 digits from their security pin: The digits required will be chosen at random (Eg. one time they might be asked for the 1st, 3rd, and 9th digit, another time they might be asked for the 2nd, 5th and 8th digit). The digits required change every login, the full security pin is never sent to the bank website, and there is no way to know which digit is which. In order to login to the bank account, the malware would need to be able to get the full security pin,which it can’t get (or can it?).
Webinjects work in a similar way to a formgrabber, but instead they intercepting data being sent from the website to the browser; The data interception is done after the data is decrypted (SSL) but before the browser displays it, giving the malware the ability to modify webpages on the fly.
Webinjects In Action
In order to see exactly how modifying the webpage can retrieve the security pin from the earlier example, I’ve decided to try my hand at writing webinjects and infecting myself with Zeus (I’ve spent hours reversing banking malware but never got a chance to play with it).
In order to try and save my self from being prosecuted by overzealous anti virus firms (cough Kaspersky cough), I’m going to be targeting a made up bank.
|How the page should look|
|The data which is sent to the server via POST|
Above is an example of our fictional bank site working properly, but in order to get the security pin the page has to be modified using webinjects. The webinjects will add an extra field asking for the full security pin, but the site says “You will never be asked to enter your full security pin”, so the malware is going to remove that and replace it with a more convincing message.
|Figure 1: The page once our Zeus webinjects are running|
|Figure 2: The data which is sent to the server via POST (with webinjects active)|
|Figure 3: Our webinjects and how they modify the page source|
|Figure 4: The log that gets sent to the Zeus C&C|
As you may have noticed in figure 1 and 3 the full_secure_pin field was added by our injects and in figure 4 it is picked up by the formgrabber then sent to the C&C, however in figure 2 it has not sent to the bank website; This is because the formgrabber has the ability to remove post fields once it has logged them, so the field that was added by the webinjects is removed before the post data is sent to the bank, making the inject undetectable on the banks end.
In order for an end user to know if they’re infected with a banking Trojan which uses webinjects, the user needs to be looking out for them. If you notice fields, popups, requests or images that weren’t there before: it’s a good idea to check the page on another computer and get a friend to check it on theirs, if the page doesn’t mach it’s likely malware is modifying the page.