SUBJECT: piercing NetScreen firewalls =====================================
This is an advisory of a major flaw discovered on NetScreen firewall devices. You may publish it "as is". The software vendor -- NetScreen Technologies -- was notified 3 weeks ago. ========== I. SUMMARY ========== ========= I.1 FACTS ========= There is no way to configure NetScreen firewalls so as to block traffic carried by protocols other than IP and ARP (this occurs at least in bridge mode on 20x and 50x models, with the latest version of screenOS). For instance, brodcast frames carrying protocols like SNA, IPX CDP, CDP, VST ... will all happily cross the firewall in and out without being checked nor logged, possibly reaching remote parts of corporate networks. Even the zone used for managing the firewall is not immune !!! Not only is the flaw infamous, but here is the worst: NetScreen devised a FAKE, dummy screening option: "bypass non-IP traffic". Toggling it on or off has absolutely no effect: The NetScreen firewall standing in the middle this times really deserves being called "transparent". It seems that the lower layers of NetScreen devices are (poorly) designed like switches or hubs -- which means the exact opposite of security. They talk you about VLANs and these have a bad bad reputation. ================ I.2 CONSEQUENCES ================ The flaw is infamous because it allows communications to be established thru the Netscreen device in any direction between arbitrary hosts, I mean hosts which you probably classified as unreachable ... from the IP point of view ... Indeed, many network architects have only protocol "IP" in mind when thinking about routing and firewall rules -- this is a common blunder. Suppose you are an external bad guy, Mr H. Using Ethernet broadcast, you can sweep entire networks behind NetScreen firewalls, including the sensitive administration zone !!! Thus, from outside, Mr H can hope that a router or mainframe machine will answer CDP or SNA protocols. Maybe Mr H will then be able to join a cluster of Cisco routers, take control and bounce/penetrate further. Or maybe that, Mr H is really skilled or just a spy and that the frames (s)he sends will wake a dormant backdoor providing control access to some deeply nested host. Provided some traffic can flow without control and getting logged, nor noticed by commercial Intrusion Detection Systems, nearly everything is possible; limits are the imagination's. For instance, you can think about using the channel as an IP tunnel, using the internal host as a VPN gateway to scan and penetrate further. Risks are incredibly high: one single forgotten or untrusted machine in your internal networks can compromise everything. And no security policy can handle this; besides, how would you be aware of a dormant backdoor ? e.g. check http://www.securitytracker.com/topics/topics.html for vulnerabilities in Cisco's products and have a thrill. ======== II. NEXT ======== In the past few years, piercing vulnerabilities have been discovered, but it seems that the community focused too much on IP only: Great, complicated exploits using fragmentation attacks were published (defeating the state engine of IPFilter and Firewall-1), ... but the simple, raw aspects of layer-2/layer-3 filtering seem to have been completely overlooked. It would be intersting to probe other firewall products for similar flaws. ===================================================== DESIGN RULE #1 When you pretend to sell a firewall, ensure that it blocks traffic which it is not able to inspect !!! ===================================================== If you don't want to run into issues like these, use either open source or firewalls -- and software versions !-- that are agreed for diplomatic and military communications. --- Paul -- civil counter-spy -- ____________________________________________ http://www.operamail.com Get OperaMail Premium today - USD 29.99/year Powered by Outblaze _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html