Security Analysis of World-Wide Web Browsers

Languages like Java and JavaScript have been developed to embed programs into HyperText Markup Language (HTML) documents (pages). Java applets, which are designed to be downloaded from the web and run directly by the Java virtual machine within a browser, are also increasingly being included in web pages to provide more sophisticated animation and other desirable features. Downloading and executing code from anywhere on the Internet brings security problems along with it. That is, the host computer is open to a variety of attacks, ranging from attacks that simply monitor the environment to export information, to attacks that change the configuration or the behavior of the host (changing files, consuming resources), and finally to attacks that open a back door to let intruders get into the host.

Attacks succeed either because the implementation of the browser is weak (from flaws in the specification and/or from poor implementation) or because the environment in which the browser is executed has flaws. Weaknesses in the environment are mainly due to the new open nature of software. Conventional computing paradigms assume that programs are installed and configured once on any and every machine and that these programs only exchange data. This means that a user can make all possible checks over a new program before running it. This assumption is no longer valid for open and mobile environments, such as Java and the web.

Many security holes in web browsers have been discovered and brought to the attention of the public. Although most of these holes have been patched, a systematic analysis of the features of both the Java and JavaScript languages and the web environment is needed to identify possible design weaknesses in order to avoid similar problems.

Most of the attacks carried out so far require the attacker to have substantial capabilities, such as taking over a web server or a domain name server or assuming that the user will navigate only through hyperlinks. These assumptions, therefore, often limit the likelihood of the attacks due to the low probability that the assumptions would be satisfied or because they require so much knowledge that only highly-skilled programmers could implement the attacks.

The purpose of this project is to investigate attacks that can be carried out by exploiting only features provided by the standard environment. These attacks can be realized without assuming that the attacker has any capabilities beyond those granted to every user on the net and without assuming that the attackers are highly skilled programmers with complex programs for carrying out the attacks. That is, the attacks are straightforward to set up and are of limited complexity.

We developed two attacks. The first one deals with the violation of privacy, and it requires only that the victim downloads a page that includes an attacker applet, which collects and sends information back to its server. The second attack is as powerful as a ``man-in-the-middle'' attack, but it too requires only that the victim downloads a honey-pot page that includes an applet that can detect when the victim visits a certain site and displays an imposter page for that site in order to steal sensitive information, such as credit card numbers or personal identification numbers.

Papers

This is a paper, or in html format, that describes the new Javascript flaw (4.01a) and attack for Communicator 4.01a.

The paper , or in html format, that describes the attack that works with Navigator up to version 3.01 and Explorer, presented at the 20th National Information Systems Security Conference, October 1997.

Another paper that describes the attacks was included in the book "Mobile Agents and Security", LNCS, vol.1419, pg. 235-256.

Demos

This demos were developed in March 1997. They do not work with Communicator version 4.0 or higher

We provide all the sources, so if you want (and need) to clone, you can implement and test.

We are not responsible for any misuse or damage resulting from using this code and do not expect anybody to use it maliciously. The demos are provided only as pedagogical instruments.

Building a dossier

Blueprint of the attack

  1. Put a HoneyPot page that when the user retrieves it, it has the spy applet that spawns a new named browser with a possibly different page.
  2. The spy applet keeps monitoring the threads in the named page from the now background browser.
  3. When the user gets a page with an applet embedded that signals that he/she is looking at the page that the attacker is interested in, the spy applet calls showDocument in the named page substituting for the real page with the faked page.
  4. The faked page uses javascript to fool the user that checks the status line, to think that hyperlinks that will keep the user in the attackers site takes him/her to the expected place.
  5. After capturing all relevant information calls, showDocument again to substitute for the faked page the real page and possibly call showDocument to show some different page in the background browser, so it is not obvious to the user that it had HoneyPot in the background.

Implementation of the attack

The attack was implemented using UCSB's computer sciences web server as the insecure server of the attacker, and a Jeeves server in a specific computer of our laboratory as the secure server of the attacker.

The attack will start if the user points his/her browser to the page http://www.cs.ucsb.edu/~seclab/projects/browsers/demo/honeypot.html. At this point a new browser will pop up to the user with the page http://www.cs.ucsb.edu/~seclab/projects/browsers/demo/honeypot2.html. From this point on I am assuming the user does not close the first browser, and only uses this second browser.

The user will then browse the Internet, and at some point he/she decides to access his/her account in the US Bank. The US Bank home page http://www.usbank.com, has an applet that my spy applet can sense, so as soon as the user goes to the US Bank's home page, the spy applet will intervene and open in the browser the page , that is an exact copy of US Bank's home page with the link to online banking substituted to point to a page that is located at . This page is also an copy of the page that would be in the US Bank, with the link to log-on substituted to point to . This is a form page that will execute a CGI written in PERL, at plover.cs.ucsb.edu and log the user's data in a file and change the page of the browser to US Bank's site.

The honeypot page that starts the attack

And the honeypot page that starts the attack if using Netscape 3.01(Working)

The spy applet to steal password

Stealing sensitive personal data

Blueprint of the attack

  1. Set a daemon application in the attacker's server that keeps listening to a specific network port
  2. Put a HoneyPot page that when the user retrieves it, it has a spy applet that overwrites its stop method, so never dies, and open a connection to the daemon application mentioned in 1. This page also uses javascript to send an e-mail to the server with the user's login name and the time in the user's machine. The spy applet uses the time, gotten from the user's machine, to stamp all information with this initial time.
  3. The spy applet keeps monitoring the threads and sending their name to the attacker's server.
  4. Since the attacker's can cross reference, through the time stamp, the user's login name with the information sent, it can build a dossier about the user's preferences on the internet.

Implementation of the attack

The attack was implemented in a Jeeves server in a specific computer of our laboratory as the server of the attacker.

The attack will start if the user points his/her browser to the page http://www.cs.ucsb.edu/~seclab/projects/browsers/email2.html. At this point the user has sent an e-mail to rsg@cs.ucsb.edu and a daemon is collecting information about the applets on the pages that the user sees from now on. With this information a more elaborated dossier can be built.

The page that starts the attack

The source code of the page

The spy applet to build dossier

The server daemon to receive information from the spy applet