Bekijk Volledige Versie : Potential Security Flaw in Symantec Gateway Security 360R
I think we have discovered a possible security flaw in the wireless security
routines for the SGS 360R.
While configuring Secure WLAN settings in the 360R we have discovered that
the "Enforce VPN Tunnels/Disallow IPSec pass thru" and "Enforce VPN
Tunnels/Allow IPSec pass thru" setting in both 2.1 build 300 and build 415
firmware do not appear to actually prohibit non-VPNed wireless connections
from reaching the internal LAN. According the documentation when using
either of the "Enforce VPN Tunnel" modes, only DNS, DHCP, and ARP traffic
are allowed to reach (we believe this also include ICMP, but its not
documented) the internal network without being encrypted by the VPN. We have
been able to send a wide variety of TCP/IP traffic (including ODBC and HTTP)
to the internal LAN over a connection that is suppose to allow only traffic
traveling inside a VPN.
We have confirmed this internally using a single SGS 360R with the Symantec
Wireless Access Point card and two Win2K laptops with WPC45G Linksys WiFi
cards.
This occurs whether or not WEP is being used.
Has anyone experienced this problem? Can anyone reproduce it?
We have reported the problem to Symantec and they are investigating.
thanks,
DN
Symantec Product Security Team
11/06/04, 19:45
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Symantec is currently investigating this issue. Our testing to this
point indicates that default configurations do not appear to be
vulnerable. The Symantec Product Security Team is working with the
poster to try and identify the conditions where they are seeing this
issue occur.
Symantec is fully committed to the prompt and timely resolution of
all security vulnerabilities in our products. Potential
vulnerabilities in Symantec products should be reported to
secure@symantec.com. This email address is monitored by the Symantec
Product Security tteam. In addition, a web page has been created at
http://www.symantec.com/security/ that contains a copy of or our
response policy and the public PGP key for secure@symantec.com
=2D --=20
=2D -------------------
Symantec Product Security Team
secure@symantec.com
http://www.symantec.com/security
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAyOJgAux7PDRKDmERAiIIAJ0WQlDbxGWUJnIanpncve bH5cRHCwCghFI/
qsnKYlB/AtHepjqTIsDmgdA=3D
=3DXFn/
=2D----END PGP SIGNATURE-----
In-Reply-To: <BCEBFFBB.ED1%devnull@cox.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 t
he 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 t
he 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 la
n 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 reboote
d, 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 be
ing 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?
>
Thanks Ed for confirming however what this shows is that Symantec has made a
very serious mistake in the Enforce VPN tunnels code. It is dependent on MAC
filtering. Since it is trivial on a wireless (or wired) lan to contaminate a
client's arp table AND to impersonate any MAC address the security of the
SGS is easily compromiseable. The way the "enforce VPN tunnels" should have
been written is:
1) packet comes in over wireless connection
2) SGS checks to see if packet is DNS, DHCP, ARP or ICMP
a) if one of those it allows the packet to go thru. BTW Symantec should
have a configuration option not to allow ANY packets including icmp, arp,
dns, or dhcp to go thru the device without being ipsec encrypted. Allowing
DNS and DHCP and ARP potentially opens up significant holes in the internal
network (i.e. There are multiple exploits using dns, dhcp, and arp).
b) If its not, then the packet but be ipsec encrypted. Period no
exceptions. Currently it appears (based on your email) that it is checking
the destination MAC address however this is very unsafe and must be changed.
The destination of the packet should be irrelevant in the above packet
check. The only thing relevant is the type of packet not the destination.
Destination only comes into play once the security check is complete.
So this is quite a bit more than a design choice.
On 6/12/04 2:17 AM, "ed p" <firewall1e@netscape.net> wrote:
> In-Reply-To: <BCEBFFBB.ED1%devnull@cox.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?
>
>>
>