Lucent VPN Firewall Brick Weakness in Processing the ARP Protocol Lets Remote Users on the Local Network Disrupt Management Communications
|
|
SecurityTracker Alert ID: 1004854 |
|
CVE Reference: GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Jul 27 2002
|
Impact: Denial of service via network, Host/resource access via network
|
Exploit Included: Yes
|
Advisory: Phenoelit Group
|
Version(s): 5.5 (LSMS)
|
Description: A vulnerability was reported in the Lucent VPN Firewall Brick. A remote user on the local network can disrupt communications between the VPN Firewall Brick appliance and the management server.
It is reported that the Lucent VPN Firewall does not securely handle the ARP protocol in certain cases.
A remote user on the local
network can reportedly interrupt connections between the VPN Firewall Brick and the Lucent Security Management Server. The remote
user can bind the IP address used by the Brick for management purposes to the remote user's interface and then ping the Brick management
address or an address of any host protected by the Brick. This will apparently cause the Brick to update its ARP cache and drop
the existing management connection. For this attack to work, the "Floating MAC" setting must be turned on.
It is also reported
that the Brick will forward any locally generated ARP request and response across all interfaces, regardless of the existing firewall
rules.
A remote user on the local network can reportedly identify a Brick by pinging all addresses in the local network segment.
The device will generate an ARP request for the remote user's IP address.
The vendor has reportedly been notified.
|
Impact: A remote user on the local network segment can disrupt management communications. A remote user on the local segment can send ARP
requests or responses through the Brick. A remote user on the local segment can identify the MAC address of the Brick.
|
Solution: No solution was available at the time of this entry.
|
Vendor URL: www.lucent.com/security/ (Links to External Site)
|
Cause: Access control error, State error
|
Reported By: kim0 <kim0@phenoelit.de>
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Sat, 27 Jul 2002 12:17:45 +0200
From: kim0 <kim0@phenoelit.de>
Subject: Phenoelit Advisory 0815 ++ -- Brick
|
--------------020106060506060805030901
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
--
kim0 <kim0@phenoelit.de>
Phenoelit (http://www.phenoelit.de)
90C0 969C EC71 01DC 36A0 FBEF 2D72 33C0 77FC CD42
--------------020106060506060805030901
Content-Type: text/plain;
name="Lucent_Brick.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="Lucent_Brick.txt"
Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 ++->
[ Authors ]
FX <fx@phenoelit.de>
kim0 <kim0@phenoelit.de>
Phenoelit Group (http://www.phenoelit.de)
http://www.phenoelit.de/stuff/Lucent_Brick.txt
[ Affected Products ]
Lucent
LSMS 5.5 (Lucent Brick, Bridging VPN Firewall)
Lucent Bug ID: Not assigned
[ Vendor communication ]
06/28/02 Reply to inquiry regarding "who to notify"
06/29/02 Initial Notification to Brick team
*Note-Initial notification by phenoelit
includes a cc to cert@cert.org by default
07/02/02 Ack. of receipt by Lucent Brick team
07/06/02 Weekly follow-up by central POC at
Lucent (Right on Time)
07/08/02 Additional tech-discussions
07/19/02 Notification of intent to post publically
in apx. 7 days.
07/25/02 Notification that due to personnel changes at Lucent,
our POC has changed. The new person is supposed to be
contacting us...
[ Overview ]
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).
[ Description ]
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 ]
None known at this time.
[ end of file ]
--------------020106060506060805030901--
|
|
