New bgp hijack isn't very new. - SANS Internet Storm Center

New bgp hijack isn't very new.
Several news sources have been carrying a story about the DEFCON BGP hijack. While that “trick” was pretty cool it was not new. Original DEFCON paper is here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt Wired article here: http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html As Pieter Zatko (aka Mudge of L0pht) is quoted in this article: "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail." What is new here? The TTL adjustment was cool and new to me. Getting the data back to the hijacked network was also kind of cool but as prepending isn’t new just not used in this way in the past as far as I know:) The rest is old very OLD. BGP4 was always capable of directing traffic that is what it was designed to do. Path-prepending is a technique that's equally well known. This is no easy to attack this as you need to be trusted by your upstream ISPs. Since those ISPs have neither the interest nor the need to trust their customers to announce only their own BGP information many ISPs filter what customers can announce to them. Large ISPs are in a position to do it as they are trusted but have even less motivation in performing BGP hijacking. A successful BGP hijack by a large ISP would result in peers publicly mocking them and front page headlines that would not be good for business. Attracting a substantial amount of traffic and sending it out again is going to get noticed. Both on your bandwidth usage with the potential for a self inflicted fill the pipe ddos and by people watching traffic patterns/announcements in BGP. Here is one of the early bgp hijacks it was an accident but in 1997 this accident caused major outages and traffic to be redirected when as7007 hijacked a large portion of the internet. http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html If you want to prevent what they did at DEFCON implementing the following template should help. http://www.cymru.com/Documents/secure-bgp-template.html Additionally ISPs should add router-filter statements (junos) policy-statement CUSTOMER.COM.AS201020 { term 10 { from { as-path CUSTOMER.COM.AS201020; route-filter 1.1.1.0/24 orlonger; } then next policy; } term 20 { then reject; } Or cisco prefix-lists ip prefix-list 201020 seq 10 permit 1.1.1.0/22 le 24 To limit what your customers can announce to you. It is described here: http://puck.nether.net/bgp/cisco-config.html A more complete PKI based solution is being developed by the sidr working group at IETF. Here is several of the drafts others are available at ietf.org. http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-03.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-02.txt A good collection of BGP security papers is available here: http://www.cs.cmu.edu/~dwendlan/routing/	donald 206 Posts Sep 3rd 2008
Thread locked Subscribe	Sep 3rd 2008 1 decade ago
Pilosov and Kapela don't claim that the attack they presented is new. They claim that it's a problem that needs to be addressed, hence the talk. Also, while many ISPs responsibly filter routes received from customers, many others don't, and it only takes one weak link.	Anonymous
Quote	Sep 4th 2008 1 decade ago
The recent BGP hijacking demo is interesting. However, the fact that the routing has been hijacked is immediately obvious -- just do a traceroute. More insidious would be MPLS hijacking. There, the only way to tell that label switching (routing) has been hijacked would be an increase in packet latency -- which would not always be significant enough to be detectable. The biggest problem with MPLS is that service providers are in deep denial that MPLS has any security issues. They rate hijacking as an "impossibility." Worse, service providers claim that MPLS is "totally secure." They try to sell MPLS as "so secure you do not need encryption." I have even had one service provider threaten to block all IPSec traffic because it introduced "too much needless network overhead." Others have threatened to remark all IPSec traffic as default precedence and ignore customer DSCP markings. I fear that too many users of MPLS are falling for the security marketing hype that is prevalent with MPLS and they not encrypting their MPLS traffic. They forget that if their traffic crosses national borders, it is probably being monitored. If you have sensitive intellectual property that transits national borders on unencrypted MPLS networks, you can pretty much guarantee that foreign governments are stealing this information in transit for distribution to their country's companies, giving them a competitive advantage through government-sponsored industrial espionage. Using MPLS? Not encrypting? Not concerned? You should be. It could be the weakest link in your organization's security.	Johannes 4513 Posts ISC Handler
Quote	Sep 7th 2008 1 decade ago

Several news sources have been carrying a story about the DEFCON BGP hijack. While that “trick” was pretty cool it was not new. Original DEFCON paper is here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt

Wired article here:
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html
As Pieter Zatko (aka Mudge of L0pht) is quoted in this article:
"I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail."

What is new here?
The TTL adjustment was cool and new to me.
Getting the data back to the hijacked network was also kind of cool but as prepending isn’t new just not used in this way in the past as far as I know:)

The rest is old very OLD.

BGP4 was always capable of directing traffic that is what it was designed to do.

Path-prepending is a technique that's equally well known.

This is no easy to attack this as you need to be trusted by your upstream ISPs. Since those ISPs have neither the interest nor the need
to trust their customers to announce only their own BGP information many ISPs filter what customers can announce to them.

Large ISPs are in a position to do it as they are trusted but have even less motivation in performing BGP hijacking. A successful BGP hijack by a large ISP would result in peers publicly mocking them and front page headlines that would not be good for business.

Attracting a substantial amount of traffic and sending it out again is going to get noticed. Both on your bandwidth usage with the potential for a self inflicted fill the pipe ddos and by people watching traffic patterns/announcements in BGP.

Here is one of the early bgp hijacks it was an accident but in 1997 this accident caused major outages and traffic to be redirected when as7007 hijacked a large portion of the internet.
http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html


If you want to prevent what they did at DEFCON implementing the following template should help.

http://www.cymru.com/Documents/secure-bgp-template.html
Additionally ISPs should add router-filter statements (junos)
policy-statement CUSTOMER.COM.AS201020 {
      term 10 {
          from {
              as-path CUSTOMER.COM.AS201020;
              route-filter 1.1.1.0/24 orlonger;
          }
          then next policy;
      }
      term 20 {
          then reject;
}

Or cisco prefix-lists
ip prefix-list 201020 seq 10 permit 1.1.1.0/22 le 24
To limit what your customers can announce to you. It is described here: http://puck.nether.net/bgp/cisco-config.html

A more complete PKI based solution is being developed by the sidr working group at IETF. Here is several of the drafts others are available at ietf.org.

http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rescerts-provisioning-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-02.txt

A good collection of BGP security papers is available here:

http://www.cs.cmu.edu/~dwendlan/routing/

donald

206 Posts

Sep 3rd 2008

Pilosov and Kapela don't claim that the attack they presented is new. They claim that it's a problem that needs to be addressed, hence the talk.

Also, while many ISPs responsibly filter routes received from customers, many others don't, and it only takes one weak link.

Anonymous

The recent BGP hijacking demo is interesting. However, the fact that the routing has been hijacked is immediately obvious -- just do a traceroute.

More insidious would be MPLS hijacking. There, the only way to tell that label switching (routing) has been hijacked would be an increase in packet latency -- which would not always be significant enough to be detectable.

The biggest problem with MPLS is that service providers are in deep denial that MPLS has any security issues. They rate hijacking as an "impossibility."

Worse, service providers claim that MPLS is "totally secure." They try to sell MPLS as "so secure you do not need encryption." I have even had one service provider threaten to block all IPSec traffic because it introduced "too much needless network overhead." Others have threatened to remark all IPSec traffic as default precedence and ignore customer DSCP markings.

I fear that too many users of MPLS are falling for the security marketing hype that is prevalent with MPLS and they not encrypting their MPLS traffic. They forget that if their traffic crosses national borders, it is probably being monitored. If you have sensitive intellectual property that transits national borders on unencrypted MPLS networks, you can pretty much guarantee that foreign governments are stealing this information in transit for distribution to their country's companies, giving them a competitive advantage through government-sponsored industrial espionage.

Using MPLS? Not encrypting? Not concerned? You should be. It could be the weakest link in your organization's security.

Johannes

4513 Posts
ISC Handler