Proceedings
`
`1997
`Symposium on Network and
`Distributed System Security
`
`February 1 0 - 11 , 1997
`
`San Diego, California
`
`Sponsored by the
`The Internet Society
`
`In cooperation with the
`IEEE Computer Society
`
`IEEE Computer Society Press
`Los Alamitos, California
`
`Washington • Brussels • Tokyo
`
`J. ROBEI{T VAN PnT LIBRARY
`.CHJW T£CHNOLOSICAL DNIYtRSJn
`HOUGHTON, MICHIGAN
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`IEEE Computer Society Press
`10662 Los Vaqueros Circle
`P.O. Box 3014
`Los Alamitos, CA, 90720-1314
`
`Copyright © 1997 by The Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved.
`
`Copyright and Reprint Pennissions:, Abstracting is permitted with credit to the source. Libraries may
`photocopy beyond the limits of US copyright law, for private use of patrons, those articles in this volume
`that cany a code at the bottom of the first page, provided that the per-copy fee indicated in the code is paid
`through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923.
`
`Other copying, reprint, or republication requests should be addressed to:, IEEE Copyrights Manager, IEEE
`Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855- 1331.
`
`The papers in this book comprise the proceedings of the meeting mentioned on the cover and title page. They
`reflect the authors' opinions and, in the interests of timely dissemination, are published as presented and
`without change. Their inclusion in this publication does not necessarily constitute. endorsement by the
`editors, the IEEE Computer Society Press, or the Institute of Electrical and Electronics Engineers, Inc.
`
`IEEE Computer Society Press Order Number PR07767
`Library of Congress Number 96-80101
`IEEE Order Plan Catalog Number 97TB 100100
`ISBN 0-8186-7767-8 (paper)
`ISBN 0-8 I 86-7769-4 (fiche)
`
`IEEE Computer Society Press
`Customer Service Center
`10662 Los Vaqueros Circle
`P.O. Box 3014
`Los Alamitos, CA 90720-13 14
`Tel:, +1-714-821-8380
`Fax:, +1-714-821-4641
`Email:, cs.books@computer.org
`
`Additional copies may be ordered from:
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`Tel:, +1-908-981- 1393
`Fax:, +1-908-981-9667
`
`IEEE Computer Society
`13, Avenue de I'Aquilon
`B-1200 Brussels
`BELGIUM
`Tel:, +32-2-770-2 198
`Fax: +32-2-77()..8505
`
`IEEE Computer Society
`Ooshima Building
`2-1-9-1 Minami-Aoyama
`Minato-ku, Tokyo 107
`JAPAN
`Tel:, +81-3-3408-31 18
`Fax: +81-3-3408-3553
`
`Editorial production by Regina Spencer Sipple
`Cover design by Lawrence Livennore National Laboratory Technical Publications Department
`Printed in the United States of America by KNI, Inc.
`
`•
`
`The Institute of Electrical and Electronics Engineers, Inc.
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`' 0
`
`•
`
`•' .. . ·'
`
`Proceedings of the 1997 Symposium on Network and Distributed System Security
`
`, 1,}
`
`Table of Contents
`
`General Chairs Message ........................................................................................................ vii
`Program Chairs' Message ...................................................................................................... viii
`Organizing Committee ............................................................................................................. ix
`Program Committee .................................................................................................................. x
`Privacy and Security Research Group ................................................................................. xi
`
`SESSION 1: THINGS THAT GO BUMP IN THE NET
`Chair: Stephen T. Kent- BBN Corporation
`Experimental Results of Covert Channel Limitation in
`One-Way Communication Systems .......................................................................................... 2
`N. Ogurtsou, H. Orman, R. Schroeppel,
`S. O'Malley, and 0 . Spatscheck
`Blocking Java Applets at the Firewall ...................................................... : ........................... 16
`D.M. Martin Jr., S . Rajagopalan,
`and A.D. Rubin
`Continuous Assessment of a Unix Configuration: Integrating Intrusion
`Detection and Configuration Analysis ................................................................................... 27
`A. Mounji and B . Le Charlier
`
`SESSION 2: PANEL- SECURITY OF DOWNLOADABLE EXECUTABLE
`CONTENT .............................................................................................................. 38
`Chair: Aviel D. Rubin - Bellcore
`
`SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS
`Chair: Christoph Schuba -Purdue University
`An Interface Specification Language for Automatically Analyzing
`Cryptographic Protocols ......................................................................................................... 40
`S.H. Brackin
`Probable Plaintext Cryptanalysis of the IP Security Protocols ............................................ 52
`S.M. Bellovin
`Misplaced Trust: Kerberos 4 Session Keys ............................................................................ 60
`B. Dole, S. Lodin, and E . Spafford
`
`SESSION 4: PANEL- SECURITY OF THE INTERNET
`INFRASTRUCTURE ........................................................................................... 72
`Chair: Russ Mundy - Trusted Information Systems
`
`v
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`SESSION 5: ROUTING SECURITY
`Chair: Hfuu:ie Orman-DARPAIITO
`Securing the Nimrod Routing Architecture .......................................................................... 7 4
`K.E. Sirois and S . T . Kent
`Securing Distance-Vector Routing Protocols ......................................................................... 85
`B.R. Smith, S . Murthy, and J .J . Garcia-Luna-Aceves
`Reducing the Cost of Security in Link-State Routing ........................................................... 93
`R. Hauser, T. Przygknda, and G. Tsudik
`
`SESSION 6: PANEL- SECURITY FOR THE WORLD WIDE WEB
`Chair: Win Treese - OpenMarket, Inc.
`Securing Web Access with DCE ........................................................................................... 102
`B.C. Schimpf
`PANEL: Security and the World Wide Web ....................................................................... 109
`Chair: Win Treese- OpenMarket, Inc.
`
`SESSION 7: PUBUC KEY MANAGEMENT
`Chair: Jonathan Trostle - CyberSafe
`Hierarchical Organization of Certification Authorities
`for Secure Environrnents ...................................................................................................... 112
`L. L6pez and J . Carracedo
`Trust Models in ICE-TEL ..................................................................................................... 122
`A Young, N.K. Cicovic, and D. Chadwick
`Distributed Authentication in Kerberos Using
`Public Key Cryptography ..................................................................................................... 134
`MA Sirbu and J.C.-I. Chuang
`
`SESSION 8: PANEL-WEB PRIVACY ANDANONYMITY ................................... 144
`Chair: B . Clifford Ne wnan- USC Information S cknces Institute
`
`Author Index ........................................................................................................................... 145
`
`vi
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`(cid:3) (cid:55)(cid:75)(cid:76)(cid:86)(cid:3)(cid:80)(cid:68)(cid:87)(cid:72)(cid:85)(cid:76)(cid:68)(cid:79)(cid:3)(cid:80)(cid:68)(cid:92)(cid:3)(cid:69)(cid:72)(cid:3)(cid:83)(cid:85)(cid:82)(cid:87)(cid:72)(cid:70)(cid:87)(cid:72)(cid:71)(cid:3)(cid:69)(cid:92)(cid:3)(cid:38)(cid:82)(cid:83)(cid:92)(cid:85)(cid:76)(cid:74)(cid:75)(cid:87)(cid:3)(cid:79)(cid:68)(cid:90)(cid:3)(cid:11)(cid:55)(cid:76)(cid:87)(cid:79)(cid:72)(cid:3)(cid:20)(cid:26)(cid:3)(cid:56)(cid:17)(cid:54)(cid:17)(cid:3)(cid:38)(cid:82)(cid:71)(cid:72)(cid:12)(cid:3)
`
`Blocking Java Applets at the.Firewall
`
`David M. Martin Jr.1
`Department of Computer Science
`Boston University
`111 Cununington Street
`Boston, MA 02215
`dm@cs.bu.edu
`
`Sivaramakrishnan Rajagopalan
`Bellcore
`445 South St.
`Morristown, NJ 07960
`sraj@bellcore.com
`
`Aviel D. Rubin
`Bellcore
`445 South St.
`Morristown, NJ 07960
`rubin@bellcore.com
`
`Abstract
`
`This paper explores the problem of protecting a site on
`the Internet against hostile external Java applets while al(cid:173)
`lowing trusted internal applets to run. With careful imple(cid:173)
`mentcuion, a site can be made resistant to current Java se(cid:173)
`curity weaknesses as well as those yet to be discovered. In
`addition, we describe a new attack on certain sophisticated
`firewalls that is most effectively realized as a Java applet.
`
`1. Introduction
`
`Java is hot stuff. The hype that has surrounded Java and
`Java-enabled browsers such as Netscape mirrors the hype
`associated with the Internet and the World Wide Web. It is
`inevitable that this trend will not only continue, but that the
`acceptance and use of Java will grow. In spite of the many
`security concerns about using Java within browsers [8, 11),
`the momentum that has resulted from the convenience and
`functionality of downloadable executables has taken the In(cid:173)
`ternet by storm.
`Flaws in the design and implementation of Java-enabled
`browsers have repeatedly been discovered. Some of these
`exploit weaknesses in the type checking of Java, while oth(cid:173)
`ers exploit system-level bugs. These vulnerabilities can al(cid:173)
`low Java applets to erase files, leak sensitive information,
`aJIId corrupt a user's environment. At the very least, mali- ·
`cious applets can cause great inconvenience.
`Dimly aware of the dangers, most users are nonetheless
`unwilling to disable Java in their browsers, and an "It won't
`
`1 This worir. was performed while lhe author was a summer student at
`Bell core.
`
`happen to me" attitude prevails. One contribution of this
`paper is the description of an attack that allows an invading
`Java applet to convince certain firewalls to open arbitrary
`TCP holes to the applet' s host. A variant of this attack even
`allows the attacker to use a firewall's proxying software-(cid:173)
`intended to protected the site from intruders-as a spring(cid:173)
`board for further attacks on the internal network. Either
`way, by simply visiting a Web page or reading email in a
`Java-enabled browser, users can· unknowingly provide their
`attacker a route through the protecting firewall.
`While Java presents security concerns to users who
`download applets from the Internet. it is nonetheless very
`useful as a programming language. Java applets are being
`developed and deployed for internal use in corporate and
`other networks at a rapid pace [ 14). There are many reasons
`why people want to run Java within their protected network.
`Java is platform independent, so multi-platform demos can
`be built with relative ease. The object-oriented features of
`Java and the inheritance mechanism it provides make it an
`easy and convenient programming language, and the many
`available class libraries make things like network program(cid:173)
`ming much easier than before.
`A site wishing to protect itself from hostile Java applets
`has few options. If users are required to disable Java in
`their Web browsers, then that site is missing out on all of
`the benefits of a new and useful programming language, or
`at least those features that make it convenient to run within
`a browser. Also, there is little to stop a user from indepen(cid:173)
`dently obtaining a Java-enabled browser from the Internet
`and running it. Cutting the site off from the Internet entirely
`would probably not sit well with most users.
`In this paper, we discuss a compromise. We describe var(cid:173)
`ious techniques to block Java applets at a site's firewall so
`
`0-8186-7767-8/96 $10.00 © 1997 IEEE
`
`16
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`that internal applications can run Java in their browsers, but
`untrusted applets from the outside cannot penetrate. 1bese
`techniques are already partially available in the public do(cid:173)
`main (7), and commercial firewall developers are rapidly
`releasing products that offer the techniques in various com(cid:173)
`binations.
`Section 2 contains a review of basic firewall concepts.
`Section 3 describes an applet attack on certain firewalls. In
`Section 4, an applet's path from server to host is described,
`and Section 5 evaluates three common methods for blocking
`Java applets at the firewall. Section 6 briefly describes the
`authors' experimental implementation of a Java-blocking
`firewall.
`
`2. Firewall Design
`
`A firewall is an intentional bottleneck between two net(cid:173)
`works designed to prohibit certain types of internetwork
`communication such as login attempts and network file sys(cid:173)
`tem access (6, 5, I, 3, 10, 15, 16, 20]. The firewall hard(cid:173)
`ware typically consists of one or more computers, routers,
`ln this paper, we envision
`or special-purpose machines.
`a firewall protecting a corporate network as a single dual(cid:173)
`homed host, i.e., a computer with two network interfaces
`able to examine ttaffic attempting to cross from one inter(cid:173)
`face to another in order to decide whether to permit the traf(cid:173)
`fic ftow. The particulars of the firewall's network connectiv(cid:173)
`ity, such as screened host versus screened subnet architec(cid:173)
`ture (5], precise location of the decision-making host, etc.,
`are not crucial to the line of reasoning we wish to pursue, so
`we leave these details unspecified. We assume that one of
`the firewall' s two network interfaces connects to the trusted
`but vulnerable local network, and the other connects to the
`external and untrusted Internet. Since one of the networks
`is the Internet, we restrict our attention to data in the form
`of IP packets.
`Computers behind the firewall are the local hosts that the
`firewall protects, and computers outside the firewall are the
`renwte hosts, which we assume to be potential attackers.
`TCP connections across the firewall that originate from the
`Internet are called inbound connections, and those that orig(cid:173)
`inate behind the firewall are called outbound connections; in
`each case, TCP permits full-duplex communications.
`When designing a firewall, the essential decision to be
`made is what level of granularity to use when regulating
`the traffic flow. The granularity choice has a significant im(cid:173)
`pact on equipment costs, operating costs, throughput, and
`security. Fine-grained, lightweight designs operate at the IP
`packet level and are called padcet filters. Coarser-grained,
`heavyweight designs usually operate at the TCPIUDP level
`and are called gateways or application proxies. We discuss
`both approaches in the following sections.
`
`2.1. Packet Filters
`
`A packet filtering firewall examines each JP packet inde(cid:173)
`pendently, and by examining the JP source, JP destination,
`and other fields, decides whether to forward the packet o r
`not. Ordinary packet filters make this decision by match(cid:173)
`ing the packet against a static set of simple rules. For in(cid:173)
`stance, one rule could prevent NFS packets from crossing
`the firewall in either direction, and another rule could block
`and log the initial packets of inbound TCP telnet port con(cid:173)
`nections, where "initial" means that ACK=O in the packet's
`TCP options field. The latter rule allows local hosts to telnet
`to Internet hosts, but prevents Internet hosts from telnetting
`into the local hosts. By blocking only the initial packets
`of a TCP session, such a packet filter implicitly relies on
`the local hosts to safely discard remaining packets when the
`initial packet doesn' t arrive. This in turn relies on the as(cid:173)
`sumption that all local hosts are trustworthy.
`More sophisticated packet filters allow the administrator
`to specify complex rules based on previous packet contents,
`time elapsed, and other parameters; these are sometimes
`called dynamic packet filters.
`F'trewalls consisting primarily of packet filters are used
`at many sites. However, packet filters cannot easily enforce
`policies such as "only users in group X may telnet from the
`Internet to local hosts." The problem is that a user's mem(cid:173)
`bership in group X is a property that bas to be described
`in a relatively high-level protocol. Because JP packets may
`be arbitrarily fragmented and reordered and packet filters
`do not retain (much) state between packets, another solu(cid:173)
`tion is required if the policy is to be enforced at the firewall.
`Indeed, many useful protocols such as FTP, Xll, and talk
`are difficult although not impossible to provide in a secure
`fashion using a packet filter alone.
`
`2.2. Application Proxies
`
`Application proxies can be thought of as man-in-the(cid:173)
`middle session forwarders. In this firewall scheme, a router
`or simple packet filter is configured to forward all rele(cid:173)
`vant packets to a secured proxy host. For each protocol to
`be supported across the firewall, a user-mode program lis(cid:173)
`tens at the appropriate TCP port1 on the proxy host. Such
`prognuns.-the individual proxies-implicitly use the proxy
`host's kernel to reassemble IP packets into TCP streams.
`Not only are these streams considerably easier to parse and
`forward than raw JP, but unwelcome packets will rarely
`make it deeper into the local network than the proxy host.
`1be effect is to isolate the local network from the Internet
`in a very strong way.
`For example, the "only group X may telnet" policy above
`is easily implemented using an application proxy: the proxy
`
`1 Or UDP pon. For our purposes, we COIICelllnlle on the TCP case.
`
`17
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`immediately presents an authentication challenge to users
`attempting inbound tel net from the Internet. Once authenti(cid:173)
`cated, the proxy opens a telnet connection to the local host
`and binds the two connections. The remote user seems to
`have a direct connection to the desired equipment, but all of
`the data actually ftows through the proxy host. In this mode,
`the proxy acts as a tunnel through the firewall.
`
`3. A New Attack
`
`We have discovered a new attack against certain firewalls
`that is most appropriately realized as a Java applet. The suc(cid:173)
`cess of the attack depends on the firewall' s ability to parse
`and react to an FTP control session in a particular way so
`that local hosts can use FTP to obtain files from the Internet.
`In addition, we assume that the firewall is transparent, i.e.,
`it intercepts and forwards the TCP streams opened by the
`browser without the browser' s knowledge or cooperation.
`Both transparent packet-filtering and proxying firewalls are
`at risk, at least in principle. Ironically, transparent firewalls
`tend to be the most sophisticated ones.
`We strongly recommend that firewall administrators re(cid:173)
`quest updates from their vendors. While this attack by it(cid:173)
`self may or may not concern firewall administrators, it is
`certainly a good indication of the security risks of allow(cid:173)
`ing local hosts to execute a program chosen by an adver(cid:173)
`sary, even under the severe functionality restrictions im(cid:173)
`posed upon Java applets.
`
`3.1. ITP and PORT
`
`To explain the attack, we first review how FTP ordinarily
`works [17]. A local user connects to a remote FrP server
`(port 21) and is authenticated, say as the "anonymous" user.
`To retrieve the file 1 file. txt, the user's FTP client first
`chooses an arbitrary TCP port where it will wait for the
`file to arrive. The client then sends a PORT command to
`the server announcing this choice, and only then issues the
`command to fetch the file. The server responds by actively
`opening an inbound TCP connection to the specified port on
`the client and transmitting the file on this connection. See
`Figure 1 for a transcript of a sample session.
`If the client's network is protected by a simple packet
`filter, the standard FTP transfer scenario will fail when the
`server attempts to open the agreed-upon port of the client.
`To a packet filter, this seems like an unsolicited probe of the
`client. However, a firewall susceptible to our attack con(cid:173)
`tains special code that watches for precisely such a PORT
`command. In response, the firewall creates a window of
`opportunity for the remote host to open the named port on·
`the client. If the remote host establishes this inbound con(cid:173)
`nection, it can stay open an arbitrarily long time in order to
`transfer the file.
`
`220 mrr96 FTP server (SunOS 4.1) r eady.
`USER anonymous
`331 Guest login ok, send ident as password.
`PASS ftp
`230 Gue.st login ok, access restrictions apply .
`PORT 172,16,1 , 1 , 19 , 233
`200 . PO_RT command s uc.cessful .
`RETR l file.txt
`150 ASCII data connection for lfile.txt
`(172,16,1,1,5097) (1 07 bytes) .
`226 ASCII Transfer complete.
`QUIT
`221 Goodbye.
`
`Figure 1. A sample FTP session. Lines be(cid:173)
`ginning with numbers are server responses.
`The contents of 1 file . txt arrive on port
`5097 = 19 * 256 + 233, not on the control port
`shown here.
`
`3.2. Taking Advantage
`
`But the firewall has no way of knowing that it was a legit(cid:173)
`imate FTP client that generated the PORT command. Sup(cid:173)
`pose that a malicious insider opens an FTP connection to a
`remote accomplice and announces that it intends to receive
`a transmission on port 23-the telnet port. The firewall will
`dutifully open a hole allowing the remote host to access the
`client's telnet port. The client·, in response to the inbound
`te1net connection, will issue a login prompt as always, giv(cid:173)
`ing the accomplice an opportunity to attempt a login in spite
`of the firewall. We have verified that this attack works in
`some environments. Of course, it does amount to an insider
`attack.
`
`3.3. A Java Realization of the Attack
`
`However, the attack can also be realized as a Java applet.
`Java provides an almost imperceptible means to get attack(cid:173)
`ing code running on the client-;-a user need only stumble
`onto the wrong Web page or read email or news in a Java(cid:173)
`enabled browser-and from that point, the firewall treats
`that code as a trusted entity. That is, permitting the unre(cid:173)
`stricted transfer of Java applets totally automates the in(cid:173)
`sider's role in this attack: The user controlling the browser
`need never even know that the attack took place.
`When a victim obtains and invokes our applet from an
`attacking machine, the applet issues an appropriate PORT
`command and instructs a server running on the attacking
`machine to attempt a telnet session to the victim's machine.
`See Figures 2 and 3. The applet is written in perfectly legal
`Java, and the server is a simple Perl script. Our applet can
`
`18
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`I
`
`f'O.Jt7 172,1 •• 1.1.0,~)
`
`_joo
`
`<@>
`<e>
`
`~
`
`<@>
`<e> ---
`
`I
`..... -
`I ~
`
`login-I
`
`I.OCII~172.1S.1.1
`
`Ar-lo< local-
`
`I.Oealr.l tn.t&.1.1
`
`Fnw.lfrot ~noM~
`
`Figure 2. First step.
`Java's security(cid:173)
`Manager prevents the attacking applet from
`accessing the local telnet port directly. The
`applet Instead sends the PORT command to
`an FTP control port on the accomplice server.
`The firewall pennlts the outbound connec(cid:173)
`tion.
`
`Figure 3. Second step. Having noticed the
`PORT command, the firewall gives the remote
`host an opportunity to open the named port(cid:173)
`the telnet port (23)- supposedly for a file
`transfer. The local host reacts to the open by
`Issuing the accomplice a telnet login prompt.
`The firewall was supposed to prevent this.
`
`bypass susceptible firewalls to penetrate any TCP port on
`the client.
`
`3.5. PartiaJ Solutions
`
`3.4. Discussion of the Attack
`
`This attack has been independently discovered by other
`researchers [2, 8] and was alluded to in section 5. 1 of [8].
`Indeed, the fundamental weakness being exploited in the
`attack-FTP's use of inbound TCP connections for receiv(cid:173)
`ing tiles--has long been recognized as a special problem for
`tirewalls [6, 5, 3].
`Before the advent of portable executable formats, every
`process running inside the firewall was seen to be authen(cid:173)
`ticated (albeit weakly) as an insider, so permitting unre(cid:173)
`stricted outbound FfP didn't conflict with the security pol(cid:173)
`icy stating "that which is not explicitly permitted is for(cid:173)
`bidden." The PORT command crossing the firewall could
`be taken as proof that the insider initiated the transfer, and
`so the inbound TCP connection delive.ring the tile was as(cid:173)
`sumed to be associated with the permitted outbound FTP
`session. However, now that Java-enabled Web browsers in(cid:173)
`vite adversaries to determine the insider's actions, such an
`assumption is no longer valid. If users can run applets ob(cid:173)
`tained from outside the firewall, then the firewall must treat
`unauthenticated insiders as adversaries. This changes the
`firewall 's role in the security la.ndscape dramatically. It is
`particularly interesting to note that even under the assump(cid:173)
`tion that the Java and firewall systems are each indepen(cid:173)
`dently secure, they do not compose to produce a secure sys(cid:173)
`tem.
`
`Sites that require strong authentication (e.g., a challenge(cid:173)
`response sequence) of users attempting outbound FTP are
`not susceptible to this attack, since an applet will not be able
`to authenticate itself as the user. While strong authentica(cid:173)
`tion is often required for inbound FTP connections, some
`designers reason that since inside users are already authen(cid:173)
`ticated, no separate authentication should be required for
`outbound connections. See [I) for an example of a high(cid:173)
`security environment in which this reasoning was used.
`(Note that this paper predates Java-enabled browsers.)
`Currently susceptible firewalls can be strengthened by
`modifying them to ignore PORT commands that announce
`transfers to any "well-known" ports [18] (including ports
`less than 1024, the so-called "privileged ports"), at the risk
`of colliding with FI'P sessions that innocently happen to
`choose one of these ports for a tile transfer. lf an innocent
`collision occurs, a subsequent attempt will probably suc(cid:173)
`ceed; only a tiny fraction of the port space is well-known.
`Of course the firewall must be also made aware of any sen(cid:173)
`sitive local applications listening on non-well-known ports.
`Another method of decreasing vulnerability is to allow
`only passive mode FTP across the packet filter [ 17, 3). The
`passive mode transfer scenario works almost like the stan·
`dard mode, except that the server chooses a port number to
`listen on, and the client actively opens that port. (TCP con(cid:173)
`nections are always full-duplex, so it makes little difference
`which end opens the connection.) In this way, the firewall
`sees the client opening an outbound connection and permits
`
`19
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`it; no fancy PORT command interpretation is required. In
`particular, our Java applet then sends its malicious PORT
`command in vain, for the firewall ignores it. Unfortunately,
`some FrP servers do not properly implement passive mode,
`and so this is not always an option. In this case, the network
`administrator could establish an FrP proxy that understands
`passive mode, use a packet filter to forbid all FTP packets
`across the firewall unless one of the hosts is the proxy host,
`and disable any special reaction to PORT commands. The
`proxy would then be able to access FTP servers that do not
`understand passive mode on the clients' behalf. If the FrP
`proxy is not transparent, then the FrP clients on the local
`hosts will have to be modified (or the users retrained to use
`the existing clients in a different way) so that communica(cid:173)
`tion with the proxy is possible.
`
`3.6. Variants of the Attack
`
`Bellovin [2] points out that the attack may even be pos(cid:173)
`sible without the use of Java. If a browser can be coaxed
`into sending an HTI'P request containing a properly format(cid:173)
`ted PORT command to a server's FTP port, for instance by
`uploading a multipart form to http: I /evil. com: 21/,
`then the firewall will open the corresponding TCP bole.
`Netscape will not honor a URL indiciating an "unnatu(cid:173)
`ral" low-numbered port (such as HTfP over port 21), so
`Netscape cannot be used to carry out the attack. However,
`this approach should work with other Web browsers.
`Our attack relies on the assumption that the firewall
`is "transparent", i.e., it intercepts and forwards the TCP
`streams opened by the browser without the browser's
`knowledge or cooperation. At other firewalled sites, users
`are instead required to explicitly configure their browsers
`to use a forwarding proxy, and. packet filters forbid com(cid:173)
`munications across the firewall except for those addressed
`to or from the proxy host. The browser can therefore only
`reac h the outside network by connecting to the proxy. Sup(cid:173)
`pose that the firewall at site xxx . com is designed in this
`manner and has its proxy listening on proxy. xxx . com
`at port 1200. When instructed to fetch a URL of the form
`http: I I evil. com/path, the browser instead opens a
`TCP connection to proxy. xxx. com: 12 00 and issues
`the request GET http: I /evil.com/path HTTP/
`1. 0. (The string HTTP 11. 0 identifies the protocol in use.)
`The proxy then forwards the request to evil. com andre(cid:173)
`turns the result to the browser.
`If a browser uses a proxy to fetch an applet from
`http://evil.com/PokeHole.class, it then in(cid:173)
`forms the Java Securi tyManager that the applet "came
`from" evi 1 . com, even though the browser actuaily ob(cid:173)
`tained it directly from proxy. xxx. corn. That is, the
`browser trusts that the proxy did what it was supposed to
`do. See (4] for details on proxying in HTfP/1.0.
`
`Our attack fails wben explicit proxying is used, because
`the Securi tyManager prevents the applet from open(cid:173)
`ing a TCP connection to any host other than evil. com,
`but the site's packet filter prevents the browser from directly
`connecting to that host Therefore, the FTP connection for
`the malicious PORT command can never be constructed.
`· (There is no SecurityManager equivalent restricting
`TCP connections in Bellovin's suggested attack above, so
`it will probably still succeed under explicit proxying.)
`Another pernicious attack is possible in an explicit
`proxying environment. Our assumptions are that an at(cid:173)
`tacker knows or can find out the HTfP proxy host
`and port, say proxy. xxx. com: 12 00 as above, that
`the victim's browser is configured to use this proxy,
`and that the proxy's configuration does not prohibit in(cid:173)
`bound HTfP requests from the proxy itself.
`Sup(cid:173)
`pose the browser is instructed to load an applet from
`the bizarre URL http: I /proxy .xxx.com: 1200/
`http://evil.com/PokeHole .class.Then:
`
`1. The browser opens a TCP connection to its configured
`proxy host proxy. xxx . corn: ~200 and issues the
`request GET http: I /proxy .xxx. corn: 1200/
`http://evil .corn/PokeHole.class HTTP/
`1. 0.
`
`2. The proxy, in response to the TCP open and GET
`command from step 1, opens a TCP connection to
`proxy. xxx. com: 12 00 (the host and port specified
`in the GET command) and requests the resource named
`http: I /evil.com/PokeHole. class. That is,
`it writes GET http: I /evil . corn/PokeHole.
`class HTTP I 1. 0 onto the new TCP connection.
`
`3. The proxy, in response to the TCP open and GET from
`step 2, opens a TCP connection to evi 1 . com and
`requests the resource named PokeHole. class by
`writingGE~ /PokeHole.class HTTP/1.0.
`
`4. The host evil. corn complies and returns the applet
`class file, which then ripples back through the two
`chained proxy sessions to the browser.
`
`5. The browser, examining the original URL requested,
`informs the Java Secur i tyManager that the applet
`"came from" the host proxy. xxx. com, and starts
`the applet.
`
`Therefore the applet actually supplied by evil. corn
`seems to have come from proxy. xxx . com, and so it is
`(only) able to open TCP connections to the host proxy.
`xxx. corn. But the proxy host is designed to forward TCP
`streams, so the applet can repeat the proxy self-reference
`trick to access arbitrary hosts supposedly protected by the
`firewall. We have verified that this attack works in some
`
`20
`
`BLUE COAT SYSTEMS - Exhibit 1025
`
`

`
`proxying environments: our applet, delivered by evil.
`com, can bounce off the proxy host to access any host
`reachable from the proxy.
`Although this "arbitrary" access to hosts is limited to the
`protocols supported by the proxy, the proxy's implement