PDA

Bekijk Volledige Versie : Making unidirectional VLAN and PVLAN jumping bidirectional



Andrew A. Vladimirov
20/12/05, 00:15
Arhont Ltd.- Information Security

Arhont Advisory by: Arhont Ltd
Advisory: Making unidirectional VLAN and PVLAN
jumping bidirectional
Class: design bug
Vulnerable protocols: 802.1q, various PVLAN implementations
Model Specific: This is a protocol, and not vendor-specific attack

DETAILS:

Wepwedgie, a tool by Anton Rager for traffic injection on 802.11
networks protected by WEP, solves the problem of unidirectional
communication by bouncing packets from the target host to a third
external host under the attackers control. We employ exactly the same
principle to bypass both VLAN and PVLAN network segmentation.

1. Modification of the double-tagging VLAN jumping attack.

The attacker tags his malicious data with two 802.1q tags and sends the
packet with a spoofed source IP of a host under his or her control. This
can be any host to which a valid route from the target VLAN is present,
including an external host on the Internet. The first tag gets stripped
by the switch the attacker is plugged into and the packet is forwarded
to the next switch. The remaining tag contains a different VLAN number,
to which the packet is sent. So, data is forced to pass between the
VLANs. The receiving host will check the source IP of the arriving
packet and send the reply to this IP, which is a host that belongs to
the attacker.

This attack can be launched using Yersinia
(http://sourceforge.net/projects/yersinia/).

2. Modification of the MAC spoofing PVLAN jumping attack.

The attacker sends a packet with a valid source MAC but a spoofed source
IP of a host under his or her control. This can be any host to which a
valid route from the target PVLAN is present, including an external host
on the Internet. The target MAC address is replaced with the one of a
gateway router. A switch would forward such packet to the router, which
will then look at the IP and direct the packet to the target. Of course,
the source MAC of the packet will be replaced by the one of the router,
which would then direct the reply packet from the target to the host
that belongs to the attacker.

This attack can be launched using pvlan.c from the Steve A. Rouiller's
"Virtual LAN Security: weaknesses and countermeasures" GIAC Security
Essentials Practical Assignment.

Note: Such attacks can be used for different purposes from portscanning
to communicating with a backdoor on a different VLAN or PVLAN.

Risk Factor: Medium

Workarounds: There are no direct workarounds. Implement strict egress
filtering against the spoofed packets described.

Communication History: sent to CERT on 17/10/05

*According to the Arhont Ltd. policy, all of the found vulnerabilities
and security issues will be reported to the manufacturer at least 7 days
before
releasing them to the public domains (such as CERT and BUGTRAQ).

If you would like to get more information about this issue, please do
not hesitate to contact Arhont team.*

Clayton Kossmeyer
20/12/05, 00:45
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Response
==============

This is Cisco PSIRT's response to the statements made by Arhont
Ltd. in their message: Making unidirectional VLAN and PVLAN jumping
bidirectional, posted on 2005-Dec-19. An archived version of the
report can be found here:

http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/
040333.html

Cisco confirms the statements made.

We would like to thank Arhont Ltd. for reporting this issue to us.

We greatly appreciate the opportunity to work with researchers on
security vulnerabilities, and welcome the opportunity to review and
assist in product reports.

Additional Information
======================

Cisco is aware of VLAN spoofing attacks and recommends that customers
apply best practices where possible to reduce the impact of such
attacks on their networks. Many best practices are discussed in Cisco's
SAFE Blueprint for Layer 2 security:

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/
networking_solutions_white_paper09186a008014870f.s html

As mentioned in the Arhont advisory, this is a protocol issue with
802.1q VLANS, and not a vendor-specific issue. However, there are
techniques available on Cisco devices that may allow you to reduce your
exposure to the mentioned attacks.

The Cisco SAFE Blueprint for Layer 2 security discusses double tagging
attacks here:

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/
networking_solutions_white_paper09186a008014870f.s html#wp1002270

The recommended configuration is to disable 802.1q trunking everywhere
it is not required so that tagged frames are discarded on ports not
configured for trunking.

The publication by Arhont also leverages an IP spoofing component to
enable the attack. Cisco recommends IP anti-spoofing techniques and
features such as Unicast Reverse Path Forwarding (uRPF) to guard
against spoofed IP packets.

The Unicast Reverse Path Forwarding (Unicast RPF) feature helps to
mitigate problems that are caused by spoofed IP source addresses. It is
available on Cisco routers and firewalls. For further details, please
refer to:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr
/fsecur_c/fothersf/scfrpf.htm

By enabling Unicast Reverse Path Forwarding (uRPF), all spoofed packets
will be dropped at the first device. To enable uRPF, use the following
commands.

router(config)# ip cef
router(config)# interface
router(config-if)# ip verify unicast reverse-path

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's worldwide website at
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This
includes instructions for press inquiries regarding Cisco security
notices. All Cisco security advisories are available at
http://www.cisco.com/go/psirt.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (SunOS)

iD8DBQFDpzDwEHa/Ybuq8nARAutnAJ9cFhTKVv8C5K4QcIWJiMYomuLnWgCeJU8Q
Xd773GAB2i9O6ad8ZQ1+F9o=
=toA7
-----END PGP SIGNATURE-----