ijaci vol4 no1-maninbrowser

International Journal of Ambient Computing and Intelligence, 4(1), 29-39, January-March 2012 29

Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.

Keywords: Hacking,InternetBanking,Man-in-the-Browser,Man-in-the-Middle,Security

1. INTRODUCTION

In network security terminology, “the Middle” is defined very broadly. In this sense it refers to the domain of action of Man in the Middle (MitM) attacks, in which an unauthorized party inserts themselves surreptitiously at some point along the flow of communication between two or more parties. This is so as to gain the ability to monitor the information that is exchanged, and perhaps also to modify that information, generally without being discovered so doing (Tanenbaum & Wetherall, 2011). In theory, the attack can be performed at almost any point along the communication channel between the victims. The Man in the Middle may attack through a server they control at any point along the data channel, or anywhere along the wire

that it is possible to arrange for a physical tap. In practice it is impractical to choose a server or wire somewhere in the immediate vicinity of a targeted party, and it would be ineffective to attack from somewhere at random in the web where traffic is subject to fluctuating routing tables. Therefore, this approach would usually be commenced with a phishing attack to trick the user into bridging the gap, which will be discussed. If either terminating machine is us-ing a wireless connection, the Man could also interpose himself between that machine and its associated wireless router, by picking up their outgoing signal and then posing as the user’s machine to the router. This would also work if they have control over a LAN device on the same bus as the user.

The “Middle” described already encom-passes all points from the moment a signal leaves a machine at one end of a transaction right through until just before it reaches its

Man in the Browser AttacksTimothyDougan,UniversityofUlster,UK

KevinCurran,UniversityofUlster,UK

ABSTRACTMan-in-the-BrowserattacksareasophisticatednewhackingtechniqueassociatedwithInternetcrime,es-peciallythatwhichtargetscustomersofInternetbanking.Thesecuritycommunityhasbeenawareofthemassuchfortimebuttheyhavegrowninabilityandsuccessduringthattime.TheseattacksareaspecialisedversionofMan-in-the-Middleattack,andoperatebystealingauthenticationdataandalteringlegitimateusertransactionstobenefittheattackers.ThispaperexamineswhatMan-in-the-Browserattacksarecapableofandhowspecificversionsoftheattackareexecuted,withreferencetotheircontrolstructure,datainteractiontechniques,andmethodsforcircumventingsecurity.Finallytheauthorsdiscusstheeffectivenessofcounter-Man-in-the-Middlestrategies,andspeculateuponwhattheseattackstellusabouttheInternetenvironment.

DOI: 10.4018/jaci.2012010103

30 International Journal of Ambient Computing and Intelligence, 4(1), 29-39, January-March 2012


destination. However, the Man could also breach the integrity of the signal before it even leaves the user’s PC, if he subjects the user to a Man in the Browser (MitB) attack. This is a more recent form of attack in which the user’s browser is corrupted in order to act as the tap in the information stream, an attack which “occurs at the system level, between the user and the browser, [rather than via] the protocol layer” (Litan & Allan, 2006). This, structur-ally speaking, is “a man-in-the-middle attack between the user and the security mechanisms of the browser” (Gühring, 2006).

Therefore, in network security terms, “the Middle” is every point along the course an information transaction between the initial input and final output device (i.e., anything that is not a keyboard or a monitor etc). In this sense, the MitB attack is a special case of the MitM attack in which the intrusion occurs at the very nearest end of the middle to the user.

2. MitB IN TERMS OF MitM

Let us begin by exploring the places in which MitB differs from MitM. Firstly, MitM inter-cepts data using an inserted or compromised piece of hardware that is external to the targeted system. MitB on the other hand gains access through the software configuration on that sys-tem, generally by way of a Trojan that targets the web browsers on that computer.

Secondly, MitM either has to deal with messages that have already been protected by whatever security is associated with the con-nection (and read/alter them mid-flight in both directions of communication), or has to present a plausible reason for the user to create their connection with the attacker’s own server. MitB does not need to bother with the extra work this entails. In the outward-bound direction, it is the author of all compromised messages sent. In the inward-bound direction, it does still have to deal with a fully formed message, but it does not need to be concerned with modifying the message itself so as to conceal its actions. This is because MitB directly controls the

browser, and therefore needs only to modify the browser display to be as the user expects. Together this means that it works outside of any client-side and server-side encryption and validation, and therefore does not have to be concerned with increased latency arising from hashing overheads or to provide dummy keys for public key encryption.

This implies another advantage of MitB over MitM, in that MitM is only guaranteed to be able to handle public key encryption (and this only up to a point as discussed in the section “Trust”), whereas MitB is “immune” to all forms of encryption, including symmetric key, by being external to it. Finally, MitM is only truly effective a directed or location-based attack, whereas MitB can be spammed to as many computers as its Trojan is able to infect. If the access point of MitM were somewhere at random in the Internet, it is unlikely for it to be able to extract valuable data or make modifica-tions undetectably. This is because packets can be routed independently, so any data gleaned will probably be fragmentary, and replies to any fraudulent modified messages would not be guaranteed to pass through the same compromised point as the outgoing message, making concealment of modifications almost impossible. To maintain constant contact, the MitM attacker must either be physically close enough to the victim to capture their outgoing data before it has the opportunity to bifurcate, or trick the victim into navigating to the attacker’s own server that will act as a stable mid-point.

This compels the attacker to either directly target or in some other way reach out to indi-viduals or groups, and means that this attack does not scale very well. On the other hand, the only such limitations on MitB are around the level of security that is installed on the systems it attacks or is practiced by the people who use them, and it scales very well. Where MitM is limited to a chosen few targets at a time (most effectively spread by mass spam emails with links to compromised sites), individual MitB Trojans are known to have compromised be-tween hundreds and hundreds of thousands of users’ security concurrently (Finjan, 2009;



Stone-Gross et al., 2009; RSA Fraud Action Research Labs, 2008; Murchu, 2009).

Although their underlying technical structures are very different, this is not to say that MitB has little in common with MitM. Besides being based on the same principle of the addition of concealed third parties into the flow of transactions, both also have the same capabilities once inside the security provisions of a transaction and both are carried out for similar ends. However, it is fair to say that MitB exceeds MitM in many ways.

3. MitB CAPABILITIES

Leaving MitM behind for now, and leaving how MitB technically accomplishes what it does until later, let us now consider MitB’s general capabilities (some of which may or may not be included in a given version of the attack, and which between versions will vary in method of implementation). These can be broadly classi-fied under five categories. MitB can:

3.1. Steal Data

MitB’s control over the browser gives it the ability to collect information both passively by keylogging, and actively by phishing. Any data entered into the compromised browser is potentially available to the attacker, with the ability for them to select preferred data to steal as described below. In addition, and to get around the way in which many security conscious websites limit the amount of sensitive data they request from the user, MitB can prompt for extra data by using its ability to modify the structure of pages displayed in the browser.

3.2. Modify Html

This is referred to as html injection and it allows the attacker to alter the html of a page before it is sent to the browser for interpretation. Typically, this would be used in two ways – firstly, to add extra data entry fields that prompt the user to enter private information in excess of what is normally requested by a page, and secondly to

modify server responses. Data field addition allows for much more powerful data collection, especially if there are data entry fields that are usually obfuscated by a secure site with the intention of defeating keyloggers. Rather than try to defeat a virtual keyboard or a jumbled and/or partial character-by-character password entry system (i.e., “enter the 3rd, 1st and 5th letter of your password”), this instead allows MitB to alter the login procedure so that the password is entered in the clear, from whence it can be lifted directly as per the previous ability discussed. Modifying server responses allows MitB to cover its tracks by making the server response appear to agree with the users original intentions, which MitB may need to do, as it will sometimes modify data sent by the client to the server.

3.3. Modify Outgoing Data

Just as MitB can modify the html that is shown to the user, its level of access also allows it to tamper with outgoing form data the user is submitting to a server. This allows for various fraudulent actions (usually in the context of internet banking) with the added advantage of the request originating with, and being largely composed by, the legitimate user of a web ser-vice. This makes the fraud very much harder to detect and therefore very much more likely not only to initially succeed, but also to remain undiscovered for long enough for the attacker to take advantage of it.

3.4. Choose Targets

All of the foregoing is useful only if the MitB Trojan is able to identify what data it should tamper with or steal. Each version of MitB makes a list of items of interest available to its browser monitoring services. The members of this list will typically be used to select two dif-ferent types of data – either individual fields of interest by their proximity to certain keywords, or entire pages of interest by their residing in a chosen domain. The domain-targeted attacks are chosen for their value, and this targeting allows the fraud to be tailored to the specifications of



each chosen domain. For instance, is clearly not of use to perform html injection attacks as discussed above without knowing what to inject and where to do so. Attackers cannot expect inserting a “Please enter password/email/D.O.B.” field at random into every page to be very successful. Therefore the Trojan must keep a catalogue of particular domains to pay extra attention to, which must include instruc-tions as to where and how within those domains it should carry out its more sophisticated thefts and manipulations.

This level of specificity, combined with instructions to limit non-explicit data theft to data fields that are labelled “Password”, “User Name”, “Email” etc acts to limit the amount of non-valuable data that is stolen. Such a provision is useful because, as implied above, individual implementations of MitB attacks can be actively stealing data from many thousands of users concurrently. This becomes an issue when you consider that all stolen data must be communicated back to the owner of the attack over a finite amount of available bandwidth.

3.5. Communicate with HQ

There is no point in stealing data without hav-ing some way to retrieve it, so therefore it is a basic requirement of a data-stealing MitB at-tack is that there be a means whereby to extract stolen data. With this requirement of the ability to communicate externally a given, there are many other uses such a connection can be put to. Designating a command server and giving that server control over individual infected machines is a particularly valuable second-ary use of this ability as it allows for remote modification of the Trojan’s parameters and for the software version of the infection to be updated. This in turn enables MitB domain and field targeting to be improved, and provides a procedure by which new features and techniques can be added as they are devised. Furthermore, it may be useful to provide access to a server that carries modified security scripts to replace those that protect data in a secure site, tailored corporate image files if a phishing page is be-

ing built from scratch, or precise instructions as to how the subsequent steps of the attack are to be carried out. This could be in order to facilitate more elaborate phishing attacks for Trojan implementations that do not have sufficient control over the browser to suppress “mixed content” warnings (that alert the user to the presence in a page of files coming from somewhere not covered by the certificate of the business site they are visiting), or simply to reduce overheads. It is more efficient to do this than to provide a Trojan with a library of instructions, scripts and images suitable to every eventuality.

4. HOW MitB IS PERFORMED

We move now into the specifics of how these attacks are carried out. It is important to note at this point that a MitB attack is only one com-ponent in the arsenal of modern Trojans. These Trojans combine different techniques to gain access to and control over systems, maintain themselves and remain undetected. To discuss how a MitB attack is carried out, we will examine the MitB component of some well-known and widespread Trojans, with reference to the five categories described above. The Trojans we will use as examples are all botnets, which suits the remote-control style allowed by MitB. They are:

1. URLzone (a.k.a. Bebloh) – a sophisticated Trojan from the Ukraine focused on Ger-man banking (Finjan, 2009)

2. Torpig (a.k.a. Sinowal) – a flexible botnet that steals data mainly in the USA and Europe (Stone-Gross et al., 2009)

3. Zeus (a.k.a. Zbot, Kneber) – a very wide-spread Botnet that has also been very well covered by the media (Falliere & Chien, 2009)

I will discuss each one with regard to the five aspects explained, and then briefly highlight notable features at the end.



4.1. URLzone

Stealing Data

URLzone is focused more on directly stealing money from victims, rather than stealing their data to sell or to use to commit fraud later on. Such data is still collected however, and I suppose why not? It will “log credentials and activities of bank accounts, [...] take screenshots of webpages, [and] log and report on other web accounts (e.g., Facebook, PayPal, Gmail) and banks from other countries” (Finjan, 2009). It monitors the system, and when a new instance of an application it knows how to attack be-gins, it uses API hooking to inject a DLL into the process and intercept system messages. Its primary targets were German banks, but given its level of access there was no reason for it not to steal available data while it was installed. “It limits itself to collect data that is sent by the user using POST method with less than 2,000 bytes” (Chechik, 2009) so as to evade notice by security applications, and only becomes active when the data returned to it are from specified domains.

Modifying html

URLzone makes most of its money through live modification of outgoing data, but this causes a problem for it. The fraudulent transac-tions it makes need to remain in place for long enough for the money to be transferred to a safe location, but if the customer notices that a modification has been made they will report it to the bank as fraud, which will in turn revoke the transaction. Therefore, the modification must be disguised from the victim, so that the server response will appear as they expect it to. More powerful versions of the data-selection scripts are used here to not only to recognize the critical fields in transaction logs, but also to substitute over these fields ex tempore in the raw html, injecting a copy of the original user submitted value of the field in place of the new and fraud-revealing value returned by the server. This requires that the Trojan have

an excellent working knowledge of the format of the banking pages it targets, since there will be many fields per transaction, or transactions altogether, from which it must select one.

Modifying Outgoing Data

When the Trojan reports captured data from a targeted domain to its controller, the controller has the option to specify that an attack should be carried out. This decision is handled by automation at the server side, and is the only way in which URLzone will perform an active attack – the Trojan itself has no capacity to carry out this kind of attack on its own. This is beneficial in two ways – firstly it avoids the need for the Trojan to use local CPU cycles to compose attacks, and secondly it allows all at-tacks to be made with the latest specifications. That is to say, specifications can be altered at the server in immediate response to changes made in the target sites, and will be used im-mediately without requiring the Trojan to update its configuration files.

The specific modifications made are chosen very carefully so as to maximize the probability that the attack will succeed. Two data it will steal are the account balance and the maximum transaction allowed. From these it determines an amount that is close to (but slightly less than) the lesser of these two data, including a factor of randomization to deceive anti-fraud systems designed to notice suspicious patterns in transactions. This determined amount is then returned from the server to the Trojan along with a holding account controlled by the attacker to which this amount should be sent. These two fields overwrite those in the original form the victim intended to post, and then the form sent on to the bank, which is none the wiser as to the alteration.

Choosing Targets

The targeting is in two parts – selecting which field values to steal as determined by a local configuration file, and which site transactions to actively attack as determined remotely by the C&C server. Once again, this remote operation



allows the time taken to perform complex cal-culations to be independent of local hardware constraints, and any reduction in client-side processing will help the Trojan remain unde-tected by client-side security software. Lo-cally determined target fields are selected by comparing the originating domain of the stolen POST data to a list of domain name masks – if it matches, then the data is chosen and stolen.

Communicating with HQ

“The communication between the Trojan and the C&C server is conducted over HTTP, hav-ing the data XOR-encrypted” (Finjan, 2009). After initial configuration, all communication from the Trojan is triggered by the domain matching described. Unlike Torpig and Zeus, there is no regular contact with the server, and also unlike Torpig & Zeus, that server is hard coded (MCRC, 2009) – a less flexible approach as we shall see.

4.2. Torpig

Stealing Data

Torpig “can inspect all the data handled by [programs on compromised machines, including web browsers] and identify and store interest-ing pieces of information, such as credentials for online accounts and stored passwords” (Stone-Gross, et al., 2009) by using DLLs, again injected through hooking. This is passive data theft in the same manner as used by URLzone, although not restricted to POST data, and in-cluding data extracted from browsers’ password manager services and miscellaneous system data including Windows user account login passwords. Active data theft is also carried out by way of phishing attacks, externally controlled as described below. These attacks take the form of novel pages injected to replace pages on the target domain, which request user data in excess of that which would be requested by a legitimate security conscious site. This goes beyond site-specific passwords, and may include personal details and multi-factor security components. These will be sent to C&C without any encryp-

tion or input obfuscation; another advantage of creating a new page rather than lifting data from fields in current legitimate pages.

Modifying html & Modifying Outgoing Data

Since Torpig is solely concerned with data theft, it does not modify outgoing data. Since it does not modify outgoing data, it does not need to hide its tracks, and only html modifica-tion it makes is to create phishing pages. This can be achieved trivially, since the injection server returns to the Trojan a URL to a fully formed version of the novel page, which can then be directly substituted for the content of the legitimate page it is replacing.

Choosing Targets

Targets are chosen in the same way as Torpig picks what POST data to steal – domains of interest are listed in the configuration file ob-tained from the C&C server, and all data the user enters there is stolen.


The bot sends the accumulated data it has sto-len at fixed intervals, and all communication between Torpig C&C and its bots is carried out over HTTP POST messages encrypted with Torpig’s own base64 + XOR encryption algo-rithm, using a symmetric key sent in the clear (Stone-Gross et al., 2009). Torpig is particularly notable, and follows a current trend, in that it does not report to a static server in the same way that URLzone did. Based on an algorithm that uses different pieces of date information it generates a list of addresses of potential C&C servers. It then starts from the top of the list sending requests to these putative domains until it receives a valid C&C response, at which point the responding server becomes the control server for that bot until the next scheduled switchover. The attackers have the means to generate the same list, and can register some or all of the domains listed in advance, which is very clever because it removes the single point of failure



that was exposed by URLzone. The addresses can be linked to a physical server of the at-tacker’s choosing, and if one address is taken down, Torpig will automatically run through the rest of the list until it reaches the next domain attached to a C&C server. Likewise, if a C&C server is taken down, the currently registered addresses can be assigned to a new server and the botnet can continue about its business in the same way.1

4.3. Zeus

Stealing Data

Zeus steals data according to both hard-coded general practices and configurable selection. It will lift passwords stored in insecure local repositories such as Windows Protected Stor-age, and any login data that is handled in an insecure manner, i.e., sent without encryption. The configuration will additionally allow the attacker to nominate domains from which Zeus should intercept all user input prior to encryp-tion, which can then be forwarded to C&C. In this way, it is like a middle ground between URLzone and Torpig. It has some extra capa-bilities as well, in that it can be configured to capture screenshots upon mouse click events on pages in target domains, and has “a special-ized routine that allows you to configure match patterns to search for transaction numbers in data posted to online banks. The match patterns include values such as the variable name and length of the TAN.” (Falliere & Chien, 2009)

This latter is especially powerful, as TANs (Transaction Authentication Numbers) are often used to provide the second part of two-factor authentication, which has been successful in preventing fraud from credential theft, since each TAN expires after a single use. Attacks that steal this data must have some way of dealing with its expiration, and so will usually replace the user’s TAN with a randomly chosen incorrect alternative – I cannot find a source to confirm that this is true also for Zeus, but it seems likely that is how it operates. What makes this “TANGrabber” routine particularly

useful is that Zeus does not need explicit data about where it should expect to find the TAN in user input, but rather can identify TANs by certain shared attributes and harvest as many as it comes across.

Modifying html

Zeus performs html injection in the same way that URLzone does, and for the same reason that Torpig does. Based on a configured basic understanding of pages on targeted sites, Zeus inserts single or multiple fields into otherwise legitimate pages. The way it does so is fully customizable, and has the benefit of brevity in that only a small change is required, rather than having to request an entire page of html from an injection server – the overhead is low enough that it can be carried out client-side. The field will usually be set up to request extra authentica-tion data such as sought by Torpig, which will be input in the clear and can be siphoned off directly to C&C. It can also “modify or hijack JavaScript that is used for client side security purposes” (Falliere & Chien, 2009) in the same way, in order to bypass a site’s security.

Modifying Outgoing Data

Zeus, like Torpig, is only concerned with data theft, and so does not perform any real-time attacks. The only minor outgoing data modifica-tion it makes is substitution of chosen URLs in DNS requests in order to carry out traditional phishing attacks.

Choosing Targets

All targeting is handled through two libraries of filters, which it compares against the URLs visited by the browser in a similar manner as in Torpig’s target selection. These are either general masked domain names from which all user data is lifted (“WebFilters”), or URL masks associated to pieces of text that must be present in a user submission for Zeus to select it for appropriation.




Zeus communicates with C&C via POSTed mes-sages similarly to Torpig, but does so whenever it has data to send as well as at timed intervals – it does not allow data to accumulate at client side. Server responses from Torpig offer some control over its bots, but Zeus has a great deal more. It can order various functions from C&C varying from stealing extra files, through to re-booting the infected machine, and even deleting Windows’ system322. This control comes more from Zeus’ aspect as a full botnet suite rather than anything pertaining to MitB, but says a lot about how evolved and powerful Zeus is. Combined with the wideness of its infection, this is probably why Zeus has received so much more media attention than other botnets.

4.4. General Characteristics & Techniques

It should be clear from the limited sample ex-plored that a great many different techniques are available to support, carry out and take advantage of MitB attacks. One question raised by this array of tools and techniques again regards definitions. At what points does MitB begin and end? Many of the functions carried out in furtherance of the attack do not take place “in the Browser”, and the ways in which the browser can be compromised (though touched on only lightly here) are many and varied. They include API hooking and custom scripting as discussed, Document Object Model exploitation via Browser Helper Objects and Extensions, and even full virtualization (although this is only speculated by Gühring and seems not to have occurred in practice yet.) Because of this, it is probably fairer to see MitB as a Trojan tool rather than a Trojan type.

Most of what these MitB implementations have in common are intentions, and general abstract concepts under which to perform their attacks (substitution, misdirection, intelligent selection etc). Where they differ is in terms of technical execution as in the preceding para-graph, and in where and whom they target. Bank-

ing customers in Europe and North America are definitely the primary targets, but the long tail of less profitable data theft extends across a broad range of other private data, which can either be abused directly or sold.

5. HOW MITB CAN BE STOPPED

Despite being perhaps the most important sec-tion in this paper, it will also be the shortest, as there is only one currently long-term guaranteed way to defend against MitB, and even that will cease to be so in time. Different companies endorse different (proprietary) methods of de-tection and prevention. Entrust (2010) advise the use of behaviour monitoring tools that can detect suspicious user actions, but this can be defeated by intelligent MitB programming that includes pseudorandom and conservative decision trees. More sophisticated monitoring would lead to more sophisticated decision trees, an arms race in which many would not be protected whenever attackers temporarily gained the upper hand. TriCipher (Litan & Allan, 2006) offers multifactor authentication, which has already been defeated in one form or another by all three Trojans of the case studies. Arcot (2010) offers digital signing embedded in Adobe Systems clients (which will inevitably transfer the problem from Man-in-the-Browser to Man-in-the-Adobe) and Virtual Private Ses-sions that rely on returning confirmation in a human-readable but obfuscated state in an image file. This latter may or may not work for now, but will also inevitably be overcome as machine reading improves and cracks are found in their proprietary security.

The only thing guaranteed to work, ad-mirable also for its simplicity, is out of band confirmation. The Arcot whitepaper trashes OOB authentication via passcode, but does not allow for OOB reporting (via either automated phonecall or text message) that provides the user with a précis of all transactions their accounts attempt, and preferably the option to confirm or reject. There are two problems with this (setting



aside the possibility that attackers could steal phone details and then hack personal phones, but if that has happened to you then you have bigger problems than banking fraud), which are:

1. It costs money, and unlike other paid-for solutions, this cost scales with the level of use.

2. It takes Internet banking (and whatever other forms of Internet transaction you wish to protect) at least partially off the Internet, which rather defeats the point of having them on the Internet in the first place.

It is probably reasonable to hope for an intelligent and satisfying solution at some time in the future, but one does not appear to be available at this time. Of course, if web us-ers did not get malware infections then there would not be an issue, but this is unlikely to ever come about.

6. CONCLUSIONS & CONSEQUENCES

There is some confusion of terminology around MitB. Some sources (Entrust, 2010; Mushaq, 2010) define MitB as any attack that uses browser infection. This occurs even though MitB may only account for one facet of a multi-part attack, one technique in the arsenal of a Trojan. Others (Falliere & Chien, 2009; Stone-Gross et al., 2009) tend to brush over the MitB aspect of a piece of malware, or use it as another word for phishing. It is in any case a subtle and powerful technique, which gives criminals access to a great deal of opportunity for profit.

Furthermore, the sophistication of MitB attacks has grown over time, and can be expected to continue to grow as time passes (Imperva, 2010). Security solutions will need to improve similarly, and meanwhile, many people are going to be swindled. The best way to improve security until the industry catches up is to practice good computer hygiene and if

possible to keep valuable transactions at least partially off the Internet.

In short, an improved level of user edu-cation regarding the dangers of the Internet would be effective at preventing most types of client-side attack, but such caution as would be taken in response to education is lacking among many. On the one hand, you could see the increasing general aptitude among many who access the Internet at providing basic data sanitation for their devices as a sign that improved understanding over time will solve this problem. On the other hand, you could ac-cept that no amount of education will provide protection to the percentage of people who are not willing or able to keep up with changing trends and practices in computing. It follows that these people are exactly the ideal targets for this type of fraud – in effect, distribution of aptitude focuses the attacks upon those least able to protect themselves against them. General understanding must and will improve, and will help, but will not be a solution.

One of the consequences of MitB can be seen by contrast to the effectiveness of one technique successful in defeating MitM – certi-fication. This works by allowing communication between client and server to be encrypted using public key cryptography, based on keys from certificates provided by the server, which are themselves issued by Certification Authorities. These authorities are themselves certified by other bodies, which are in turn also certified, creating a chain of trust that leads back to a small number of internationally recognised (and browser hard-coded) authorities that can usually be relied upon (Hallam-Baker, 2011) to vouch only for trustworthy servers. However, certification of this type only protects a data stream after it leaves the user’s browser, and does not have any control over how that browser displays any server response. MitB bypasses this security entirely, since it has access to data before encryption, and has control over what the browser displays after a server response has been decrypted.

MitB undermines the reliability of security in this way with regards to all of the other forms



of security ineffective against it. It is clear that the possibility of MitB weakens the trust that a user can have in the integrity of their system, but it also weakens the trust that the server can have in the authenticity of messages received from clients. This two way weakening is an obstacle that will need to be overcome in the future, since the establishment of mutual trust is one of the main impediments to growth in the utility of the Internet.

“Cybercriminals” are getting better at cybercrime, especially as Computer Science education spreads in 2nd and 3rd world countries with less than stringent Internet law enforce-ment. The examples taken above all seem to have originated in Soviet Bloc countries, but similar attacks have been identified from all over the world, including even the well known “Nigerian Prince” scam. A consequence of the Information Economy, insofar as information is very easy to move from place, is that traditional borders to the scalability of some types of crime will be eroded in the same way as has happened for the borders to some types of legitimate busi-ness. Therefore, we can expect to see a superior successor in some form to MitB as MitB was to MitM, and thence onward – also we can expect these attacks to become increasingly successful and costly.

REFERENCES

Arcot. (2010). ProtectingOnlineCustomers fromMan-in-the-BrowserandMan-in-the-MiddleAttacks. Retrieved from Arcot Resources - Briefs and White Papers for Online Identity Fraud Protection website: http://www.arcot.com/resources/docs/ Protection_from_MITM_&_MITB_Attacks_White_Paper.pdf

Chechik, D. (2009, September 30). MalwareAnalysis–TrojanBankerURLZone/Bebloh. Retrieved April 5, 2011, from M86 Security Labs website: http://labs.m86security.com/ 2009/09/malware-analysis-trojan-banker-urlzonebebloh/

Entrust. (2010). Defeating Man-in-the-Browser. Retrieved April 3, 2011, from Internet Security and Encryption White Papers website: http://www.entrust.com/resources/download.cfm/24002/

Falliere, N., & Chien, E. (2009). Zeus:KingoftheBots. Retrieved from Security Response Whitepapers Symantec Corp. website: http://www.symantec.com/content/en/us/ enterprise/media/security_response/whitepapers/zeus_king_of_bots.pdf

Finjan. (2009, July). CybercrimeIntelligenceReport,Issueno.3. Retrieved March 20, 2011, from M86 Security website: http://www.finjan.com/GetObject.aspx?ObjId=679

Gühring, P. (2006, September 12). ConceptsagainstMan-in-the-Browser Attacks. Retrieved March 3, 2011, from CAcert.org website: http://www2.fu-tureware.at/svn/sourcerer/CAcert/SecureClient.pdf

Hallam-Baker, P. (2011, March 23). The RecentRACompromise. Retrieved March 25, 2011, from Comodo Blogs website: http://blogs.comodo.com/it-security/data-security/ the-recent-ra-compromise/

Imperva. (2010, November 16). Top ten securitytrendsfor2011. Retrieved from Continuity Central website: http://www.continuitycentral.com/fea-ture0830.html

Litan, A., & Allan, A. (2006, September 12). Threats:ManintheBrowser. Retrieved April 10, 2011, from Tricipher website: http://www.tricipher.com/threats/man_in_the_browser.html

MCRC. (2009, July 22). Howa cybergangoper-atesanetworkof1.9million infectedcomputers. Retrieved April 2011, from SecureTweets Blog website: http://www.finjan.com/SecureTweets/Blog/post/ How-a-cybergang-operates-a-network-of-19-million-infected-computers.aspx

Murchu, L. O. (2008, January 8). Trojan.Silent-bankerTechnicalDetails. Retrieved April 3, 2011, from Symantec Security Response website: http://www.symantec.com/security_response/ writeup.jsp?docid=2007-121718-1009-99&tabid=2

Mushaq, A. (2010, February 19). ManintheBrowser:InsidetheZeusTrojan. Retrieved April 9, 2011, from threatpost: Kaspersky Lab Security News Service website: http://threatpost.com/en_us/blogs/man-browser-inside-zeus-trojan-021910

RSA FraudAction Research Labs. (2008, October 31). OneSinowalTrojan+OneGang=HundredsofThousandsofCompromisedAccounts. Retrieved March 15, 2011, from Speaking of Security – The RSA Blog and Podcast website: http://blogs.rsa.com/rsafarl/one-sinowal-trojan -one-gang-hundreds-of-thousands-of-compromised-accounts/



Stone-Gross, B., Cova, M., Cavallaro, L., Gilbert, B., Szydlowski, M., Kemmerer, R., et al. (2009). YourBotnetisMyBotnet:AnalysisofaBotnetTakeover. Retrieved April 2, 2011, from Taking over the Torpig botnet website: http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf

Symantec. (2009). Zeus:KingoftheBots. Retrieved April 5, 2011, from Security Response Whitepapers Symantec Corp. website: http://www.symantec.com/content/en/us/enterprise/media/ security_response/whitepapers/zeus_king_of_bots.pdf

Tanenbaum, A. S., & Wetherall, D. J. (2011). Com-puterNetworks (5th ed.). Boston, MA: Pearson.

ENDNOTES1 Note however that this is how Stone-Gross

et al. were able to hijack the Torpig botnet. Note too that because the domain selection algorithm can be changed, they were only able to maintain control for 10 days.

2 Which will not make your computer run faster, despite what you may have heard.

KevinCurranBSc(Hons),PhD,SMIEEE,FBCSCITP,SMACM,FHEAisaReaderinCom-puterScienceattheUniversityofUlsterandgroupleaderfortheAmbientIntelligenceResearchGroup.HisachievementsincludewinningandmanagingUK&EuropeanFrameworkprojectsandTechnologyTransferSchemes.Dr.Curranhasmadesignificantcontributionstoadvancingtheknowledgeandunderstandingofcomputernetworkingandsystems,evidencedbyover650publishedworks.Heisperhapsmostwell-knownforhisworkonlocationpositioningwithinindoorenvironments,pervasivecomputingand internet security.Hisexpertisehasbeenac-knowledgedbyinvitationstopresenthisworkatinternationalconferences,overseasuniversitiesandresearchlaboratories.HeisaregularcontributortoBBCradio&TVnewsintheUKandiscurrentlytherecipientofanEngineeringandTechnologyBoardVisitingLectureshipforEx-ceptionalEngineersandisanIEEETechnicalExpertforInternet/Securitymatters.HeislistedintheDictionary of International Biography,Marquis Who’s Who in Science and EngineeringandbyWho’s Who in the World.Dr.CurranwasawardedtheCertificateofExcellence forResearchin2004bySciencePublicationsandwasnamedIrishDigitalMediaNewcomeroftheYearAwardin2006.Dr.CurranhasperformedexternalpaneldutiesforvariousIrishHigherEducationInstitutions.HeisafellowoftheBritishComputerSociety(FBCS),aseniormemberof theAssociation forComputingMachinery (SMACM),aseniormemberof the InstituteofElectricalandElectronicsEngineers(SMIEEE)andafellowofthehighereducationacademy(FHEA).Dr.Curran’sstatureandauthorityintheinternationalcommunityisdemonstratedbyhisinfluence,particularlyinrelationtothedirectionofresearchincomputerscience.Hehaschairedsessionsandparticipatedintheorganisingcommitteesformanyhighly-respectedin-ternationalconferencesandworkshops.HeistheEditor-in-ChiefoftheInternational Journal of Ambient Computing and Intelligenceandisalsoamemberof15JournalEditorialCommitteesandnumerousinternationalconferenceorganisingcommittees.HehasservedasanadvisortotheBritishComputerSocietyinregardtothecomputerindustrystandardsandisamemberofBCSandIEEETechnologySpecialistGroupsandvariousotherprofessionalbodies.