Defending against Spying with Browser Helper Objects

Beomsoo Park, Sungjin Hong, Jaewook Oh, Heejo Lee

Korea UniversityTel: +82-2-3290-3208Fax: +82-2-953-0771heejo@korea.ac.kr

Technical Report KU-CCS-05-001

Abstract

A Browser Helper Object (BHO) is a small program that runs automatically every time MicrosoftInternet Explorer (IE) is started, providing the possibility of extending and modifying the browser. How-ever, new security threats are appearing in the form of malicious BHOs acting as spywares or adwares,which include browser hijacking to unsavory sites, adding unwanted shortcuts to one’s favorite folder,and stealing private information from web surfers through keystroke logging. Infection by maliciousBHOs can be incurred as a result of normal web surfing, without the need to be tricked into downloadingand running a strange file. Moreover, these nuisances are not easy to remove from the registry settingsand altered files. In order to defend against malicious BHOs, we propose a secure automatic sign-in(SAS) architecture, which enables automatic logon to a web site through the detection of a logon form.A password is initially registered for a web site with a virtual keyboard which replaces keystrokes withmouse clicks. Then, starting from the next visit, the logon procedure is under the protection of SASbefore accessing the web site, which prevents sensitive information from being eavesdropped on via theweb browser. This study can be one step towards the establishment of a proactive defense against spyingprograms, in contrast to the existing reactive anti-spyware tools which are only able to detect and removeknown malicious programs at the risk of re-infection.

Key words: Browser helper object (BHO), Internet Explorer, spywares, keylogger.

1 Introduction

Microsoft Internet Explorer (IE) is the most widely used web browser, with a reported global market share of93.9% in May 2004 according to OneStat.com. This web browser supports an extensible framework basedon the concept of the Browser Helper Object (BHO) [1], which is a small program that runs automaticallyevery time IE is started. In this framework, a BHO, which is designed with the intention of providingassistance when browsing the Internet, can intercept all events which arise, before they are handled byIE itself. Unfortunately, this feature opens the door to the development of malicious BHOs referred to asadwares or spywares [6], which manipulate the browser events or quietly gather private information.

However, this does not mean that all BHOs are bad. For example, the Google Toolbar includes a BHO aspart of its installation, which is evidently not malicious. An example of a bad BHO is Surfbar [5], which isinstalled without the user’s permission by exploiting a vulnerability in IE. The Surfbar BHO, also known as

1

Junkbar and Pornbar, changes the start page to http://www.surferbar.com, then installs hundredsof porn site shortcuts.

BHOs are usually distributed in the form of an “Active X” control, whose installation requires admin-istrator privilege on the system. This may mislead people to believe that BHOs are not dangerous butsufficiently tractable. However, due to the fact that many users work with the administrator privilege andimprudently agree to install Active X controls, malicious BHOs can be quietly installed without their real-izing it. Since IE loads all registered BHOs without any user intervention, it is difficult to recognize whichBHOs are loaded and whether bad BHOs are currently running on a system.

Most malicious BHOs act as adwares which changes the start page of IE or insert ads on web pages [2],however, some BHOs are designed to gather private information by spying on the web browser by loggingall input to the browser. In other words, a malicious BHO can capture a password, which is only displayedin the form of asterisks in the browser window, and credit card numbers copied by cut-and-paste mouseoperations. Thus, BHO based spywares are more powerful than conventional “keystroke” loggers. Althoughthe potential danger of BHOs is well known, there have been few studies of the possible countermeasuresthat can be used to defend against such attacks. One trivial way of accomplishing this is to disable BHOs onthe browser. However, disabling BHOs implies that the user cannot make use of BHOs in any way, whichis likely to cause some inconvenience. Therefore, another way of defending against malicious BHOs isneeded, while allowing good BHOs to perform their useful functions.

We propose a secure automatic sign-in (SAS) architecture as a viable countermeasure mechanism againstmalicious BHOs. The SAS architecture provides automatic login without typing a password for each loginto a web site. Also, the password for a particular web site can be registered safely on the first login attemptby using a virtual keyboard. Therefore, spying BHOs which attempt to intercept confidential informationwill fail, while normal procedures are handled securely by an anti-spying BHO handler.

2 Related Works

Malicious BHOs are listed on the Sysinfo web site [2] where most BHOs are known as adwares or spywares.A handful of tools have been developed for listing and disabling BHOs, including BHO Demon [3]. How-ever, it is difficult for normal users to use these tools properly, since they do not have enough knowledge todecide which BHOs are malicious and which are not.

A keylogger is a keystroke recorder, which logs all input entered from the keyboard, based on software orhardware. A hardware keylogger is usually an external attachment which is installed between the keyboardand its port, and stores every keystroke in an internal memory for later retrieval. Many commercial productsare available in the form of small, inexpensive devices, such as KeyGhost. A software keylogger, on theother hand, is a small, hidden program which records keystrokes to a local or remote log file. There aremany ways in which keyloggers can operate and hide themselves, including through Windows hooks [8]and registry logging [10].

One way of preventing keylogging is to avoid entering sensitive information using a keyboard. An on-screen virtual keyboard can act as an alternative, which replaces keystrokes with mouse clicks [9]. However,a malicious BHO can capture any text entered into a web browser, even which is copied using mouse clicks.BHOs can monitor any information carried in a web browser, no matter where the information comes from.Furthermore, logging on a web browser is undetectable by previous keylogger detection mechanisms and,therefore, improved anti-keylogging solutions are needed to defend against malicious BHOs.

There are various commercial products that are available for managing passwords and filling out formsautomatically, including Softex’s OmniPass, EST Soft’s AlPass and Siber Systems’ RoboForm. These prod-ucts make it easier for the user to manage multiple passwords and provide for automatic sign-in without userintervention. However, they do not guarantee the security of the sign-in procedures, so that it is possible for

2

keyloggers to steal the sign-in information typed using the keyboard. Also, malicious BHOs can interceptthe sign-in information, which is only displayed in the form of asterisks in the browser window. Thus, thesesolutions are incapable of defending the user against malicious BHOs.

The Platform for Privacy Preferences (P3P), developed by the World Wide Web Consortium (W3C), isemerging as an industry standard for privacy protection. P3P-enabled web sites convert their privacy policiesinto a standard format based on extensible markup language (XML), and P3P-enabled browsers can read thissnapshot automatically and compare it with the user’s privacy preferences. While P3P still has limitationson tiny mobile devices and complex web services, it enhances user controls over privacy policies. However,the P3P program will also be delivered in the form of a BHO and the platform itself cannot be a solution forprotecting web browsers from malicious BHOs.

3 Attacks with BHOs

3.1 BHO Interfaces

A user can extend or restrict the functions of IE using BHOs [1]. As a COM in-process server object, aBHO can be implemented by using COM interfaces such as IObjectWithSite and IDispatch. The two maininterfaces of BHOs can be described as follows.

� IObjectWithSite : This is an interface which is essential for BHOs to be loaded by IE. When IEloads a BHO, IE passes the pointer of an IWebBrowers2 interface by calling the SetSite method ofan IObjectWithSite interface. The IWebBrowser2 interface is necessary in order to allow the BHO toreceive the events incurred by IE.

� IDispatch: When an event occurs in IE, IE calls the Invoke method of an IDispatch interface. Thus,the IDispatch interface needs to be implemented in order to handle the events occurring in IE. Amongthe methods included in the IDispatch interface, re-defining the Invoke method enables it to recognizeall of the events occurring in IE.

Because a BHO is a COM server object, it should be registered as a COM object in the registry. As well,it also needs to be registered in the list of BHOs, in order for it to be loaded automatically when starting IE.A BHO is registered with the CLSID 1 type in the key, as shown in Fig. 1. When an IE browser starts, allregistered BHOs are loaded into the same location of the memory context of IE. Thus, the number of BHOinstances is equal to the number of IE instances.

A BHO can detect all browsing events such as forward, backward, refresh and so on through IDispatchinterfaces. Also, a BHO can detect all keyboard and mouse events such as keystrokes and mouse movements,since it is located in the same memory context as IE. This implies that any BHO can gather information aboutweb sites visited, and credit card numbers, IDs and passwords entered during web surfing. In addition, sincea BHO is also a local process running on a computer, it can access the local resources and other processesin the computer.

3.2 Malicious BHOs

There are many ways to use the salient features of BHOs with bad intentions. The main security problemscan be classified into the following three categories.

1A CLSID is a globally unique identifier that identifies a COM class object.

3

Figure 1: BHOs in registry with the CLSID type.

� Browser hijacking: BHOs are commonly used for browser hijacking [5]. A BHO can intercept allof the events in order to take control of the browser and, in this way, it is able to perform any functionrelated to the browser. For instance, a malicious BHO can change the start page to an unsavory site,invoke pop-up windows, and add new shortcuts to favorite folders without the user’s permission.

� Capturing sign-in information: A BHO can access the contents of the web pages being browsed,and store them in a file or transmit to another place. It can even capture the passwords which aredisplayed in the form of asterisks in the browser window and any other sensitive information enteredby cut-and-paste. A new malicious BHO recently appeared whose purpose is to capture passwordsahead of SSL [4].

� Logging keystrokes: Since a BHO can intercept the events incurred by key input, all keystrokescan be recorded while web surfing. The effects of keylogging BHOs are equivalent to the maliciousfunctions and threats posed by traditional keyloggers [8].

Besides the above security issues, BHOs are occasionally used for the purpose of diminishing the sys-tem’s stability or performance; e.g., Divago Surfairy causes the computer to be unable to print, FavoriteMancauses the system to lock up for a certain period of time, while others may cause the system to slow down.

4 Secure Automatic Sign-in (SAS) Architecture

4.1 Principles of the SAS Architecture

Among the possible attacks using BHOs, the disclosure of sign-in information is the single most importantthreat, since this information enables an attacker to gain the user’s full privileges. This attack can be accom-plished in two different ways. One is to retrieve the contents of a web-page sign-in form. The other is torecord all of the user’s keystrokes. These two methods can also be combined and used simultaneously by asingle BHO program.

Conventional anti-keylogging technologies are not effective in defending against such attacks usingmalicious BHOs. Some anti-keyloggers use a driver level protection which tries to prevent a keylogger

4

from intercepting keystroke events. Others detect keylogging processes by monitoring enlarged files aftergenerating keystroke events [10]. While there are many detection and protection mechanisms for defendingagainst keyloggers, malicious BHOs constitute another type of threat which is insufficiently handled byanti-keylogging techniques.

Thus, we propose the secure automatic sign-in (SAS) architecture which has two fundamental principles.SAS provides protection against the stealing of the contents of a web page, as well as against keystrokelogging. The design goals of SAS can be described as follows.

� Securing sign-in information on web pages: When information is entered on a web page througha browser, it remains there until the page is submitted. Also, when the page is submitted to the webserver, some events are triggered by the IE browser. At this time, a BHO can detect these events andobtain the contents of the web page. The only sure way of preventing sign-in information from beingstolen is to avoid using legitimate sign-in information on the web page directly.

� Preventing keystroke logging: Many different protective mechanisms have been proposed to combatkeystroke logging. One obvious way is the use of an alternative input method instead of a keyboard.The virtual on-screen keyboard [9] comes under this category. In order to guarantee protection againstmalicious BHOs, two conditions have to be met: 1) do not use the keyboard and 2) do not request themodification of current web pages.

The avoidance technique proposed herein for the purpose of securing the sign-in information works intwo phases, as follows. First, the sign-in form with valid user inputs is replaced by a modified form withfalse information, and then the modified page is submitted. Next, before the packet corresponding to theHTTP submit command is sent to the web server, the HTTP request message is intercepted and the fakeinformation is replaced by the valid user information.

4.2 System design of SAS

Figure 2: Components of SAS.

SAS consists of 3 components, viz. sasBHO, sasTray, and KeyBank, as shown in Fig. 2. sasBHO is aBHO program which is loaded when IE starts. sasTRAY is a small program used as a tray application andKeyBank is used to store the authentication information used for revisiting registered sites.

5

1. Try to detect a sign-in form on the web page.2. Confirm that sasTRAY is running.3. Check whether the user has the proper authority to access KeyBank.4. Search for the ID and password of the current site.5. If they do not exist, allow the user to enter the ID and password via a virtual keyboard.6. Submit the web page with a bogus ID and password.7. Hook HttpSendRequest() to modify the HTTP request message.8. Replace the bogus ID and password with the ID and password found in Step 4 or entered in Step 5.9. Retransmit the modified HTTP request message.

Figure 3: The procedure of sasBHO used for automatic sign-in.

� sasBHO: A guardian BHO, called sasBHO, detects the existence of a sign-in form in a web page.Also, this BHO program is responsible for displaying a virtual keyboard, which is used to obtainthe master ID and password, and for executing the automatic sign-in procedure using the IDs andpasswords registered in KeyBank.

� sasTRAY: An application program, sasTRAY, runs separately from IE or the BHOs and resides inthe system tray of Microsoft Windows. Furthermore, sasTRAY is responsible for maintaining theinformation required for master authentication, even after IE and sasBHO have terminated.

� KeyBank: The access-controllable storage used for maintaining sign-in information is called Key-Bank, which stores per-user IDs and passwords for registered sites. The IDs and passwords are storedafter being encrypted using the master password as an encryption key. Then, sasBHO can accessKeyBank after being authenticated properly.

4.3 sasBHO

� FORM �� INPUT type=“text” name=“id” � � BR �� INPUT type=“password” name=“pw” � � BR �� INPUT type=“submit” �� /FORM �

Figure 4: Part of the HTML code used for the most common form of sign-in.

When the user visits a web page, sasBHO tries to detect a sign-in form on the web page. The sequenceof events associated with the automatic sign-in is described in Fig. 3 While there is no standard form forweb-site logons, logon forms usually have three inputs: the ID, password, and submit. Fig. 4 shows the mostcommon form of sign-in used in web sites. The “name” properties of the input tags are not unique amongweb sites, however, the “type” properties have the regular form, i.e., the “password” type for password-inputtags, and the “text” type for ID-input tags.

From this fact, we can design an algorithm which finds a sign-in form in a web page. We propose asign-in form detection algorithm which runs recursively, so as to find any sign-in form, even in the innerframes of the web page. The detection algorithm, shown in Fig. 5, tries to find an input tag whose type is

6

Figure 5: Sign-in form detection algorithm. � is an input as the document of a web page. The outputs �����and ��� are the locations of the INPUT tags which hold the ID and password.

“text”, and then find an input tag whose type is “password”. If no tag corresponding to a sign-in form isfound, it tries again by searching the frames recursively, including both multi-frames and inner-frames. Thisheuristic algorithm enables us to detect the existence of a logon form in most web sites.

Fig. 6 shows the Windows API for the function HttpSendRequest() 2, which is used for sending thespecified request to the HTTP server. In order to replace the bogus ID and password with the real ID andpassword, the HTTP request message can be manipulated by hooking the function HttpSendRequest(), asdescribed in steps 7 9 in Fig. 3. There are three fields which need to be modified in the Windows API forHttpSendRequest(): lpszHeaders, lpOptional, and dwOptionalLength. To accomplish this, it is necessaryto find the bogus ID and password in the lpOptional field, and change them to the real ID and password.Then, the length, dwOptionalLength, of the lpOptional field and the content length of the entity body inlpszHeaders need to be adjusted.

2There are two versions of this function in Windows: HttpSendRequestA() is used with ANSI builds and HttpSendRequestW()is used with Unicode builds. Based on our experiments, hooking HttpSendRequestA() works for most web sites.

7

BOOL WINAPI HttpSendRequest(HINTERNET hRequest,LPCTSTR lpszHeaders,DWORD dwHeadersLength,LPVOID lpOptional,DWORD dwOptionalLength

);

Figure 6: Windows API for the function HttpSendRequest().

4.4 sasTRAY

In order to access KeyBank, sasBHO needs to be authorized by the master authentication process. sasTRAYis used for the purpose of retaining the information required for master authentication after IE and BHOshave terminated. The master authority can be authenticated by interprocess communication (IPC) betweensasBHO and sasTRAY by using the Windows messages, WM GETTEXT and WM SETTEXT. If one pro-cess passes a WM GETTEXT message with a buffer as a parameter, Windows transmits the buffer througha memory-mapped file to the other process, which responds by sending a WM SETTEXT message. Whileauthenticating the master authority, the WM GETTEXT message is sent to sasTRAY to check whether thecurrent user is already authenticated or not. If master authority is not authenticated yet, a dialog box appearsasking the user to input the master ID and password.

4.5 KeyBank

User authentication information can be stored in KeyBank. This information, including the master ID andpassword as well as the sign-in information for each site, is stored in the repository. One user’s KeyBankcan be distinguished from those of other users by means of his or her own master ID. The information forone logon consists of three fields:

URL#ID#PASSWORD

After being encrypted with the master password as an encryption key, the information is stored on therepository. The AES algorithm can be a good candidate of the encryption. The # sign can safely be used asa separator, because this symbol is generally not used for IDs, passwords, or URLs.

5 Evaluation

5.1 Validation of the SAS architecture

We implemented the SAS architecture on Windows systems, running a version of IE superior than 4.0.Master authentication, which is shown in Fig. 7, is requested when visiting a web site with a sign-in formwithout master authority. After entering the master key, the appropriate ID and password stored in KeyBankare used for automatic sign-in to the web site. If the password is not found, SAS requests site registrationvia the virtual keyboard, as shown in Fig. 8. Because entering an ID and password into the sign-in formon the web browser may cause the sign-in information to be disclosed to a BHO, a fake ID and password,e.g. IDKIN, is entered into the sign-in form, as shown in Fig 9. However, the correct sign-in informationis delivered to the web server by replacing the fake ID and password in the HTTP request message with thecorrect one, as shown in Fig. 10.

8

In the present implementation, it was confirmed that the SAS architecture works properly in conjunctionwith web surfing activities when used with the latest versions of the IE web browser.

Figure 7: Master authentication. Figure 8: Site registration.

Figure 9: Sign-in form with fake information. Figure 10: Successful sign-in.

5.2 Bypassing malicious BHOs

In order to analyze malicious BHOs quantitatively, we examined the list of BHOs archived on the Sysinfoweb site [2]. Among the 1017 BHOs listed on this site, 512 are malicious, 404 are legitimate, and 82BHOs are open to debate, with the remainder being duplicated items. The properties of malicious BHOscan be classified into four categories: advertising, privacy violation, security issues and stability problems.Advertising BHOs are made primarily for commercial purposes. Privacy violation implies that a BHO sendssome information from a local computer to a particular destination without the user’s consent. Securityissues are those cases where a BHO receives an arbitrary code from a remote server and executes the codeon the local computer. This may include covert actions similar to those performed by Trojan horses orcomputer viruses. A stability problem is incurred when a BHO causes a computer to fail to perform itsnormal functions properly. Keylogging or spying BHOs fall into the area of privacy violation, where theyare more than 30% of malicious BHOs.

9

Figure 11: Quantitative analysis of legitimateBHOs and malicious BHOs.

Figure 12: Types of malicious BHOs.

The SAS architecture can be used to bypass or avoid spying BHOs, even unknown BHOs. Contrarily,anti-spyware programs can remove or disable only known malicious BHOs. In order to evaluate the ef-fectiveness of SAS, we created a malicious BHO which records all input to the browser and, in this way,obtains the sign-in information used for visiting web pages. After applying SAS , this malicious BHO couldno longer capture any sensitive information. This mechanism can be extended to protect any form of sensi-tive information entered on a web browser. To accomplish this, the detection algorithm can be adapted so asto use another form on the web page.

5.3 Performance of the sign-in form detection algorithm

Sign-in forms can be classified into three categories: normal, abnormal, and no login form. Normal loginforms are detectable by the sign-in detection algorithm. In this case, the sign-in form can be located in oneof three frames: the main frame of a web page, one of the multi-frames of a web page, or the inner-frameinside either the main frame or the multi-frames. Abnormal login forms cannot be detected in a systematicway. They can be divided into two categories. The first case involves web pages written in a programminglanguage which runs on the server side such as ASP, JSP, PHP and CGI. The second case involves singleexecution files such as FLASH animations. No login form means that a site may not have any authenticationprocedure.

In order to evaluate the performance of the sign-in form detection algorithm of SAS, we examined thetop 100 sites according to the ranking on http://www.alexa.com. Among these 100 sites, 65 havenormal login forms, 27 have no login form, 2 sites were not available due to server or network failure, and6 sites have abnormal login forms. Among these 6 sites, 4 were not detected due to the implementation ofserver side programs. And the remaining two sites were undetected due to the use of a FLASH animation.

SAS detects 91.5% of logon forms in the popular web sites. Furthermore, it is possible to further increasethe effective range of SAS by adapting it to abnormal sites on a case by case basis.

5.4 Safety of the virtual keyboard

A malicious person could trace the virtual keyboard in order to get hold of the sensitive information enteredwhile registering an ID and password for a web site. However, the chances is rare since it is invoked onlywhen registering a new site and no longer used after the registration. Furthermore, we can keep the security

10

Figure 13: Types of logon forms

level high by various means.When IE starts, SAS creates an instance of the virtual keyboard class. If the user visits a web site

that they have never visited, SAS displays the virtual keyboard in order to ask the user to input an IDand password. Then, SAS uses this information by referencing the instance of the virtual keyboard classwhenever needed and these data are only available on the local level. Moreover, they load into memorydynamically so it is difficult to sniff them. There are no major problems involved in transferring and usingdata. However, an attacker might peep into the virtual keyboard through a resource ID of the key of thevirtual keyboard. Because the resource ID of the virtual keyboard is fixed, one solution to this problemwould be to generate the IDs of the keys at random, at the moment when the virtual keyboard is displayed.

5.5 Robbery of KeyBank

The KeyBank is a potential target of attacks due to its central importance, in that it is used to store all of theID’s and passwords. A strong symmetric encryption mechanism, e.g., AES, can protect the information byencrypting it with the master key. And the cryptanalysis of the proven cryptosystem is not feasible within areasonable length of time.

While there is no systematic means of protection from user related deficiencies, such as the choice of aweak password as a master key, there is one additional method of enhancing the security level of KeyBank.Instead of storing the sign-in information on the hard disk drive, we can store it on a removable drive, inorder to further reduce the chances the encrypted passwords being stolen.

6 Conclusion

BHOs were designed with the intention of supporting the browser, IE, however, the threats posed by thevarious forms of malicious BHOs are growing fast, ranging from hijacking browsers to gathering privateinformation. In order to defend against malicious BHOs, we propose the SAS architecture, which preventsmalicious BHOs from spying on a web page. SAS does not leave any sensitive sign-in information on a webpage, but hides such information so as to make it inaccessible to a web browser or a malicious BHO. Also,by using a virtual keyboard, no keystroke event can be stolen by a keylogging BHO, even when registeringan ID and password for a new web site. We showed that the proposed mechanism with the sign-in detection

11

algorithm works effectively for most sites. We plan to extend the coverage of SAS and build a generalframework for screening private data on a web browser from malicious codes.

References

[1] D. Esposito, Browser Helper Objects: The Browser the Way You Want It, Microsoft, 1999.http://msdn.microsoft.com/library/en-us/dnwebgen/html/bho.asp

[2] Sysinfo, List of BHOs. http://sysinfo.org/bholist.php

[3] Definitive Solutions, BHO Demon. http://www.definitivesolutions.com/bhodemon.htm

[4] Slashdot, New IE malware captures passwords ahead of SSL, Jun. 29, 2004. http://it.slashdot.org

[5] Mary Landesman, Browser Hijacking, http://antivirus.about.com/cs/allabout/a/browjack.htm

[6] Websense, Inc., Emerging Threats: Spyware, Oct. 2004.http://www.websense.com/products/resources/wp/EmergingThreats Spyware.pdf

[7] Serge Krasavin, Keyloggers – content monitoring devices, 2001.http://skrasavi.ds.uiuc.edu/Info/Keyloggers.pdf

[8] K. Subramanyam, C. E. Frank, D. H. Galli, Keyloggers: The Overlooked Threat to Computer Security,Proc. MCURCSM, Oct. 2003. http://www.denison.edu/mathsci/mcurcsm2003/

[9] MiloSoft, Free virtual on-screen keyboard. http://march-of-faces.org/resources/vkt.html

[10] Rattle, Reverse engineering by accident, Dec. 2002. http://neworder.box.sk

12