bugtraq - Re: Potential Security Flaw in Symantec Gateway Security 360R

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>] [thread-next>] [day] [month] [year] [list]

Date: 12 Jun 2004 06:17:45 -0000
From: ed p <firewall1e@...scape.net>
To: bugtraq@...urityfocus.com
Subject: Re: Potential Security Flaw in Symantec Gateway Security 360R

In-Reply-To: <BCEBFFBB.ED1%devnull@....net>

  I have tested this thoughrouly and reproduced the symptoms of the reported issue. When Enforce VPN is enabled for internal wireless traffic on the appliance something interesting happens. The appliance changes the virtual lan mac addresss to that of the wireless nic installed on the appliance. This can cause some confusing results.

Explanation:
The firmware loads the mac address of the firewall appliance/vpn gateway assigned to the virtual interface on the lan side. When either using wireless or connected to the internal lan ports of the 360 that mac address is cached by the clients/servers on the lan. A unique feature of the SGS 360 appliance is that instead of using WEP you can secure your wireless connection by using Symantec VPN client which terminates at the appliance. In this manner all traffic from the wireless client uses ipsec through the vpn tunnel to the lan instead of WEP. To accomplish this you must selct "Enforce VPN Tunnels/Disallow IPSec pass thru" or "Enforce VPN Tunnels/Allow IPSec pass thru" setting which enforces the vpn traffic to the appliance to the lan. 

Heres what happens next:
When  "Enforce VPN Tunnels/Disallow IPSec pass thru" or "Enforce VPN
>Tunnels/Allow IPSec pass thru" setting is saved, the mac address of the wireless card now binds its mac address to the virtual interface instead of the original lan mac address.( it actually assumes the mac of the wireless nic) "The mac address on the lan interface is now that of the wireless" Since the clients/servers on the lan and the wireleless clients already have the original mac address of the vitual interface cached in the ARP table, they are still attached the lan segment, until they are rebooted, the ARP cache cleared, or the ARP table times out in approximately 10 minutes. Since all traffic should now only be allowed to the lan when the VPN internal tunnel is connected,the observation that you can still ping the lan due to the arp cache not being cleared, one could conclude that  "Enforce VPN Tunnels/Disallow IPSec pass thru" or "Enforce VPN>Tunnels/Allow IPSec pass thru" settings are not working.

Test results:
The fact is that enforcing the vpn tunnels does work in the tests but that the appliance does not send out a gratuitous ARP to clear the clients arp cache. Therefore it appears that even though the enforcment of the VPN is enabled, for several minutes you can still ping the lan. WHEN THE CACHE IS CLEARED YOU CAN ONLY PASS TRAFFIC TO THE LAN THROUGH THE VPN TUNNEL as it should. Reason being the clients/servers now have the mac address of the wireless card cached in the arp table. So unless you pass traffic through the connected VPN you can not get to the lan segment, which does work. This was repeated in tests many times successfully.

Conclusion:
This is more of a design issue than anything else, and I am sure it can be corrected by changeing the firmware to send gratuitous arps on the lan when the wireless mac address is bound to the virtual interface, or similar code change

RE:
>Has anyone experienced this problem? Can anyone reproduce it?
>