full-disclosure - piercing NetScreen firewalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20030709140542.4970.qmail@operamail.com>
From: inquisiteam at operamail.com (new InquisiTeam)
Subject: piercing NetScreen firewalls

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