Cross Domain ScriptingIntroduction.
The idea to write this article came to me after it was necessary to give a novice a reference to a detailed and understandable explanation of this term. Having climbed the search engines, I was surprised to find that finding such an article is not easy enough. The term either was not explained at all, either in two words and in English . Meanwhile, Windows vulnerabilities of this type are found quite often and they are more than serious! Therefore, in this article I tried to describe this type of attacks, the peculiarities of exploiting this type of vulnerabilities and protection against them, as well as to give concrete examples, as detailed and clear as possible. The article was written mostly, of course, for beginners, but I hope that it will be useful for more experienced readers.
What is Cross Domain Scripting?
Initially, Cross-Domain Scripting (CDS) was associated with flaws in the security model of all known "donkey" aka Internet Explorer (IE). However, since architectural features of modern browsers do not differ much from each other, then attacks of this type are currently subject to almost all known web browsers. Nevertheless, the existing differences between the programs of this class lead to the fact that the most often found CDS is "browser-independent", ie, for example, it works on IE, but does not work on Opera or vice versa.
The basis of vulnerabilities such as CDS is the concept of "domain". In this context, the meaning of this concept is somewhat different from the generally accepted one. "Domain" is not just the website address on the Internet, and not even the "area of hierarchical Internet namespace" - this concept denotes a certain "security boundary", which no user script is allowed to go beyond.
The basis of the security model of any web browser is the principle that the resources of different domains (pages, scripts, etc.) can not intersect with each other in any way, i.e. to access the inner content and data of each other. If this were possible, for example, a script on the home page of the young Vasya hacker could access the Mail.Ru mailbox data from an unsuspecting user whom Vasya lured to his page. That would be fun. !! Moreover, according to the architecture of Windows and the concepts of building modern browsers, any network resource in the local network and the client's own file system are also "domains", which means that it is possible to access them from scripts just like to any resource on the Internet! Actually, it is the client's local file system that is most often the target of cross-domain attacks.
At the same time, the interaction between resources (pages and scripts) inside the domain (and all of its subdomains!) Is allowed by the Microsoft security concept and in principle is not limited in any way. It's hard to judge whether it's right or not, but what's so simpler and at the same time, the possibilities of web surfing are expanding - that's for sure.
So what is Cross-Domain Scripting? In the context of the foregoing, this term can be translated as "cross-domain scripting"; "Scripted domain boundaries crossing" is a violation of that cherished security line, access for which gives access to data from other domains, including the client's local file system. This violation is most often accompanied by the ability to write and execute arbitrary HTML and Java code in the context of other domains, read data from other domains (for example, password forms or files on the client system) and even execute arbitrary commands on the remote computer.
Often the concept of cross-domain scripting is replaced by the concept of cross site scripting (XSS). Indeed, it often happens that the external manifestations of these vulnerabilities are very similar, especially when CDS inserts Java code into the context of another domain. However, despite the similarity, the essence of these vulnerabilities is different:
First, the scope of XSS is by definition limited to one domain. While CDS is generally affected by all domains + the client's local file system.
Secondly, the cause of XSS vulnerabilities lies in the errors of scripts located on the server, and, as a rule, consists in insufficient filtering of data received from the user. The source of CDS vulnerabilities is the client software (browser and operating system), and it is usually not associated with user data.
Well, we should not forget that the level of danger from the successful exploitation of an attacker by XSS is much lower than from CDS. After all, in the first case, as a maximum, there will be a leak of confidential user data (passwords, etc.), and only from one site, and with CDS it is possible to steal confidential data from any sites, and often execution of arbitrary commands on the client system, that allows you to take over it full control.
How it works?
So why is this type of attack possible? The reason is that the same "security line" between domains is created artificially, that all the work to prevent cross-domain scripting is performed by the web browser and its components - there are no architectural restrictions. So, there is always a possibility of errors in the verification procedures, the possibility of circumventing them, which is being successfully done now.
For more than a decade of using web browsers, many ways have been found to overcome the domain's cherished domain boundary. However, most of them can be divided into two classes:
1. Use of security errors in the object-oriented browser model;
2. Use an intermediate link to perform an attack.
Let's consider these classes of attacks in more detail.
At the heart of the first is a clearly expressed object-oriented architecture of modern browsers and the Java virtual machine. Indeed, everything that we see on the screen of a web browser is objects of certain classes with their properties, events and methods. Using this object-oriented model and Java scripts, we can access any element of the page loaded into the browser, read and write data into it, open new windows, etc. Moreover, using scripts, it is possible to partially control the elements of the web browser itself and even user actions: moving Forward / Back to pages, adding to Favorites, etc.
However, individual windows or page elements in a web browser may belong to different domains, which means that it is necessary to prevent access to them. You can not allow a custom script to open another domain in a new browser window, have the ability to write something there or take it from there. You can not allow a script on a page with a frame where the resource from another domain is loaded, could access this frame and access its data. Moreover, data leakage from one domain to another is possible not only through properties, but also through methods and events of objects! Say a script on the page of the young Vasi hacker, where he lured an unsuspecting user, should not "know" which keys he presses when he enters the password for logging into Mail.Ru, opened in another browser window. Well, there are a lot of such examples!
Unfortunately, and maybe fortunately;), such security checks are often performed incorrectly, and sometimes even completely absent! Therefore, it becomes possible to access elements of pages from other domains, read data from them, write their Java code into the context of other domains, etc. Due to the rather complex architecture of the object-oriented model, such "holes" are often found in it. Below is an example of this class of attacks (Example 1).
To perform second-class attacks, use some intermediate. What should I do when direct access to another domain is prohibited? Correctly! Going around! And suddenly there is someone going something to whom this appeal is not prohibited, and it will be able to take data from there and transfer it to us, or vice versa - to write our data into the context of another domain. The most vulnerable from this point of view is Microsoft's ActiveX technology. ActiveX technology provides the user with objects, their properties and methods that are used by the operating system for any auxiliary purposes. For example, to view the Windows Help files (* .chm) through the web browser, use the HTML Help ActiveX component. Is not it convenient? However, often ActiveX objects act as a kind of "Trojan horse"! The fact is that there is a way to manage these components (download, access to their properties and methods) via a web page. To do this, use the tag. But often these ActiveX objects contain methods of manipulating the file system, launching applications, navigating through web pages, etc. Thus. there is a possibility to make all these actions from the outside and, moreover, to carry out a full exchange of data with the victim! For example, read the contents of local client files and send this data back to the script, or use ActiveX to open another domain and write its Java code into its context. It is with this class of attacks that sometimes it is possible to achieve arbitrary code execution (running cmd.exe with the required parameters) on the client system. Currently, this type of CDS is also widely distributed and constantly find new vulnerable ActiveX objects. The following is an example of such a vulnerability (Example 2).
In addition to the CDS classes considered, there are other ways of circumventing interdomain restrictions. True, often these methods are very exotic and are rare. For example, the Cross-Cookie vulnerability discovered in July 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). It allowed under certain conditions to access (read / write) to the cookies of other domains. And this was one of the few cases where many browsers were vulnerable: IE, Mozilla, Opera, Konqueror.
Thus. CDS is currently a very common type of attack and new ways of exploiting these vulnerabilities are constantly being discovered (the "attack vector").
Examples of CDS
To make everything described above clearer - consider a couple of examples of real CDS vulnerabilities. All of them were found in Internet Explorer and allow you to insert your Java code into the context of other domains. Usually this is used to steal cookies or perform arbitrary actions within the current user session.
Example 1. Similar Method Name Redirection Cross Domain Vulnerability - CAN-2004-0727 (MS04-038)
This vulnerability was discovered in July 2004 and is associated with a security error in the object-oriented model of IE (the first class of CDS vulnerabilities from the ones discussed above).
Its essence is as follows. As you know, to load another page into the current browser window (possibly from another domain), you can use the location.href property or the location.assign () method. However, after loading the required page, further execution of the Java code of the current script is impossible - otherwise the script could load Mail.Ru and execute arbitrary actions in the context of this domain. However, it was possible to work around this restriction by redirecting the location.assign () method to the exact same but different window (after all, we have an object-oriented model and we can assign the methods of different objects to each other). As a result, it became possible to execute Java code in the context of the current window, but after downloading the required page - as required! The following script performs the required actions:
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";
First, a new window opens, which in the loop waits for the page (in our case with localhost) to be loaded into the main (current) window. Meanwhile, the script reassigns the location.assign () methods and starts loading the main window of the requested page (localhost). As soon as the download is finished, the trigger triggers a trigger in the new window's loop, assigns Java code to the assign () method (because of the reassignment of the methods, the insertion occurs in the context of the main window) and the new window closes immediately. As a result of executing the script in the context of localhost, it executes document.cookie.
Apparently, Microsoft developers did not provide for the redirect function and did not insert a security check (or inserted incorrectly) in this event. To exploit this vulnerability, you must have Active Browsing enabled in your browser. Read more about this vulnerability and find a working example of an exploit here: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.
Example 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN-2004-1319 (MS05-013)
This vulnerability was discovered at the end of last year, but it was fixed only in February. It refers to the 2nd type of CDS attacks from the ones considered above, i.e. uses an intermediate (DHTML ActiveX) to conduct the attack. To successfully exploit the vulnerability, you must perform the following sequence of actions:
1. Download DHTML ActiveX. This is done with the help of a tag.
2. Download the desired page to the ActiveX object (arbitrary domain). This is done by running our script in the context of DHTML ActiveX.
exploit.DOM.Scrypt.execScript ("window.name =" new "; open (" http: // localhost "," new ");");
3.Well, and after that you can already embed our HTML and Java code. It will be executed in the context of the loaded domain. Everything is simple to disgrace !!
exploit.DOM.Scrypt.execScript ("alert (document.cookie)");
What are the causes of this vulnerability? I would single out two of them:
First, the ability to externally execute arbitrary scripts inside the ActiveX object - in my opinion, this is too much freedom!
Secondly, when loading a page in DHTML ActiveX, everything is loaded there - even cookies! Question: Why? This ActiveX object can be used for editing pages and why there are cookies needed - it's unclear ...
Naturally, to exploit this vulnerability, it is necessary that the browser allows ActiveX execution. Read more about this vulnerability and find a working example of an exploit here: http://greyhatsecurity.org/abusiveparent-discussion.htm.
How to defend yourself?
Protecting from cross-domain scripting is not so easy. Because The variants of exploitation (the "vector of attacks") of these vulnerabilities are very diverse, most of the measures will be of a very limited and temporary nature. It is almost impossible to block all "attack vectors". Therefore, I will give a few recommendations that are only able to reduce the risk of a successful attack, but not to protect completely.
1. Maintaining caution when surfing the web.
To successfully execute almost all types of CDS, you first need to lure an unsuspecting user to an exploit page, after which he will undergo this attack. You can not trust links, as if by chance, thrown in the conversation, various "home pages", etc. This is probably the main recommendation of all. Unfortunately, correctly applied XSS can cross out all caution.
2.Operately install patches for the operating system and browser.
Usually for all vulnerabilities published on the Internet the manufacturer (even Microsoft ) in a short time produces a patch (patch). It will protect against this particular vulnerability, but not from others not yet found (or found, but not publicized). Naturally, the vulnerabilities examined in the examples have been fixed for a long time already by Microsoft, and whoever wanted it has already taken care of its security.
3. Disabling in the browser ActiveX and Active Scripting.
This measure will make it impossible to run ActiveX and execute Java or VBS scripts. This will really make most CDS attacks ineffective, though it can significantly affect the functionality of the sites visited. However, not always CDS for a successful attack requires support from the ActiveX browser or Active Scripting - and this is not a panacea for all ills!
4. Work on the Internet only with limited rights.
The implementation of this recommendation will, even in the event of a successful attack, reduce possible damage from it. As you know, the browser (and therefore all the scripts in it) is run with the rights of the current user. Do not let hacker Vasya get cmd.exe with Administrator rights !!
Following all of these recommendations will help become difficult to attack for Cross-Domain Scripting!