COMMAND

	Lucent Brick multiple weakness

SYSTEMS AFFECTED

	Lucent LSMS 5.5 (Lucent Brick, Bridging VPN Firewall)

PROBLEM

	In FX [fx@phenoelit.de] and kim0 [kim0@phenoelit.de] of Phenoelit  Group
	[http://www.phenoelit.de]                                       advisroy
	[http://www.phenoelit.de/stuff/Lucent_Brick.txt] :
	

	The Lucent Brick VPN Firewall is a  layer  2,  NCSA,  US  Army,  and  US
	National  Security  Agency  (NSA)   Approved/Certified   Firewall   that
	operates on Inferno, an  Embdedded  Operating  System.  "Brick"  devices
	come in many sizes from the SOHO Brick 20 to the Enterprise 1000(GiG).
		

	The Brick suffers from several design failures in handling  of  the  ARP
	protocol.
	

	1. It is possible to interrupt any  connection  between  the  Brick  and
	critical devices such as the LSMS (Brick Management Server)  by  binding
	the IP Address of the device in question to the attackers interface  and
	"pinging"  the  Brick  or  any  address  behind  it.  The   Brick   will
	immediately update its ARP cache and  drop  the  connection,  no  matter
	where the attacker is located (internal/outside segment). This  requires
	the "Floating MAC" setting to be turned on.
	

	2. The Brick will forward  any  ARP  request  and  response  across  all
	interfaces, regardless of the existing firewall rules.
	

	3. All Bricks are identifiable  during  reconnaissance  using  the  most
	basic of techniques (pinging all addresses in segment). The device  that
	sends ARP requests for the attacker IP address is the Brick.
	

	[ Example ]
	

	1. # man ping

	2. # man arp

	3. # for i in ´cat ipaddresses.txt´; do ping $i; done

	

	

SOLUTION

	 Update (02 August 2002)

	 ======

	

	Lucent responds :
	

	Version  7.0   of   the   Lucent   VPN   Firewall,   scheduled   to   be
	generally-available in September, 2002, contains features  that  enhance
	the administrator's ability to so configure the Brick.
	

	DISCUSSION
	

	The   attached   advisory   addresses   three   potential   sources   of
	vulnerability:
	

	1) An attacker may be able to, via misuse of  the  ARP  protocol,  cause
	the Lucent Brick to lose connection  with  its  management  server  (the
	Lucent Security Management Server, or LSMS).
	

	2) An attacker may be able to, via misuse of the ARP  protocol,  perform
	discovery of IP hosts through the Lucent Brick, regardless  of  security
	policy.
	

	3) An attacker may be able  to  perform  system  identification  of  the
	Brick itself due to the Brick's dynamic host discovery procedure,  which
	may use the ARP protocol.
	

	The Lucent VPN Firewall team  ("Lucent"  hereafter)  acknowledges  that,
	under certain configuration, the Lucent VPN Firewall  Brick  may  behave
	as indicated in  the  advisory.  However,  Lucent  has  several  general
	responses to the entire class of reported vulnerabilities,  as  well  as
	responses specific to each of the itemized points.
	

	Since the ARP protocol is a Layer-2 protocol, it will  not  pass  beyond
	the local segment. That is, ARP messages do NOT pass through  a  router.
	As a result, for an attacker to exploit any  of  these  vulnerabilities,
	he must already have control of a host directly connected  to  a  Brick.
	If the Brick is installed between two or more routing points,  any  ARPs
	generated will be stopped by those routing points, and go no further.
	

	When configured such that each interface is assigned to a  different  IP
	subnet, the Brick does not exhibit behaviors (1) and  (2).  To  be  more
	specific, ARP requests will not be forwarded across subnets, so  placing
	an interface (or VLAN) on a different subnet causes it to be  immune  to
	any attack based on the  Brick's  forwarding  ARP  messages.  Simply  by
	placing the LSMS on a different network than the  inband  data  traffic,
	issue (1) is eliminated.
	

	Furthermore, the Brick _does_ have a  checkbox  which  controls  whether
	MAC addresses may be dynamically moved. This checkbox may  be  unchecked
	in sensitive topologies,  to  ensure  that  MAC  addresses  may  not  be
	spoofed. By default, the brick is configured in the more secure mode.
	

	Although the Brick does use ARP messages  to  stimulate  responses  from
	locally-connected hosts, regardless of security policy, it will  not  do
	so if the MAC address of the host has been  cached  at  any  time  since
	boot (since that MAC table is not automatically aged).
	

	

	Lucent VPN Firewall version 7.0, scheduled to be Generally Available  in
	September, 2002, contains the following additional features,  which  may
	additionally mitigate the concerns illustrated above.
	

	a] Static ARP and MAC entries The Brick will now  have  the  ability  to
	create manual static ARP and MAC bindings. With this ability, issue  (1)
	above can be completely eliminated.
	

	b] Elimination  of  periodic  ARP  Request  generation  for  local  host
	discovery purposes The Brick  will  now  only  retransmit  periodic  ARP
	messages  for  statically-configured  IP  addresses,  including  gateway
	addresses in the routing table, the LSMS hosts,  and  the  Lucent  Proxy
	Agent hosts. The Brick will no longer perform  persistent  ARP  requests
	for other end hosts when  performing  simple  host  discovery;  after  a
	single request/response, the ARP Request will not be repeated.
	

	c] Further limits on ARP Requests used for local host discovery  If  the
	Brick does need to perform MAC  discovery,  the  Brick  will  no  longer
	transmit ARP requests on the original interface on  which  the  original
	packet was received. This mitigates issue (3) listed above.
	

	This Response applies to ALL models of the  Lucent  VPN  Firewall  Brick
	hardware running version 6.0 or later  software  (There  is  no  version
	5.5)