An attacker has compromised an advertising affiliate wwwtoom

An attacker has compromised an advertising affiliate (www.too-many-ads.com) of a banking website (www.legitbank.com). Because of this, when a user logs into their bank account and the advertising content is fetched from the compromised ad site, the attacker is able to inject arbitrary javascript into the bank’s webpage, as loaded by the user’s browser.

Explain what technical control enforced by modern browsers prevents the malicious javascript from accessing data retrieved from the legitimate bank site. Also, identify the type of attack the attacker needs to conduct in order to circumvent this control along with a brief discussion of how the bank can prevent such an attack.

Solution

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

How Cross-site Scripting works
In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload.

In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.

payload such as <script>doSomethingEvil();</script>

The consequences of what an attacker can do with the ability to execute JavaScript on a web page may not immediately stand out, especially since browsers run JavaScript in a very tightly controlled environment and that JavaScript has limited access to the user’s operating system and the user’s files.

However, when considering that JavaScript has access to the following, it’s easier to understand how creative attackers can get with JavaScript.

Malicious JavaScript has access to all the same objects the rest of the web page has, including access to cookies. Cookies are often used to store session tokens, if an attacker can obtain a user’s session cookie, they can impersonate that user.
JavaScript can read and make arbitrary modifications to the browser’s DOM (within the page that JavaScript is running).
JavaScript can use XMLHttpRequest to send HTTP requests with arbitrary content to arbitrary destinations.
JavaScript in modern browsers can leverage HTML5 APIs such as accessing a user’s geolocation, webcam, microphone and even the specific files from the user’s file system. While most of these APIs require user opt-in, XSS in conjunction with some clever social engineering can bring an attacker a long way.
The above, in combination with social engineering, allow attackers to pull off advanced attacks including cookie theft, keylogging, phishing and identity theft. Critically, XSS vulnerabilities provide the perfect ground for attackers to escalate attacks to more serious ones.

Email scams while nothing new are evolving from random email blasts to hundreds of thousands of targets, to targeted, deliberate email scam attacks. I wrote a blog article with examples here, but to summarize, email scammers are cleverly using social engineering as follows:

1. Research and select a target company.

a. This is a significant change from historical attacks which were random.

2. Purchase the required tools of the attack (almost identical domain name as the target company).

3. Select the appropriate executives of the target company.

4. Devise the scam, which usually involves a well-written email meant to exploit the trust of C-level executives who are too busy to properly vet their emails.

In the I.T. world, we find that no matter what steps we take, no matter what technology we implement, end-user training is the best protection against these types (and most types) of scams. Raise an eyebrow to anything that looks odd, just doesn\'t feel right or that you weren\'t expecting. If you\'re unsure, pick up the phone and call a trusted resource.