IPv4 Hijacking For Idiots
The more I know, the less I understand. Maybe some of you kind folks can help. Please explain for me the following scenario, and how this all actually works in practice. Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise. OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991. That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right? So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.) But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet?? I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?) Thanks in advance for any enlightenment. Regards, rfg P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia. Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April. And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.
One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T. It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done. -mel beckman
On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
The more I know, the less I understand.
Maybe some of you kind folks can help.
Please explain for me the following scenario, and how this all actually works in practice.
Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise.
OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991.
That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right?
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet??
I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?)
Thanks in advance for any enlightenment.
Regards, rfg
P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia.
Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April.
And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.
On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman <mel@beckman.org> wrote:
One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T.
that doesn't seem to be what's happening in ron's example though... it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776) 3) start doing the bgps with the IX fabric's route-server 4) profit (or something) so here the IXP operator (balkans ix actually?) http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 (search for 206776 -> http://lg.bix.bg/?query=bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4) ) should probably look more than just side-eyes at their customer...
It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done.
err, you'll have to better explain this I think. Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does) this doesn't get you a peering/transit contract though... -chris
-mel beckman
On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
The more I know, the less I understand.
Maybe some of you kind folks can help.
Please explain for me the following scenario, and how this all actually works in practice.
Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise.
OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991.
That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right?
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet??
I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?)
Thanks in advance for any enlightenment.
Regards, rfg
P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia.
Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April.
And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.
Chris, I didn’t research Ron’s specific example. I was speaking in generalities. I’m assuming any BGP hijacker already has two or more DIA connections. It only costs $100 to add BGP peering to that setup. Yes, they will need an ASN. I was only talking about the cost of adding an upstream BGP session. -mel On Jun 5, 2017, at 9:03 AM, Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> wrote: On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T. that doesn't seem to be what's happening in ron's example though... it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776) 3) start doing the bgps with the IX fabric's route-server 4) profit (or something) so here the IXP operator (balkans ix actually?) http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 (search for 206776 -> http://lg.bix.bg/?query=bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4)) should probably look more than just side-eyes at their customer... It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done. err, you'll have to better explain this I think. Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does) this doesn't get you a peering/transit contract though... -chris -mel beckman
On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com<mailto:rfg@tristatelogic.com>> wrote:
The more I know, the less I understand.
Maybe some of you kind folks can help.
Please explain for me the following scenario, and how this all actually works in practice.
Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise.
OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991.
That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right?
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet??
I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?)
Thanks in advance for any enlightenment.
Regards, rfg
P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16<http://168.176.0.0/16> which, from where I am sitting, would appear to belong to the National University of Columbia.
Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April.
And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24<http://190.90.88.0/24> block seems to be filled, wall-to-all, with snowshoe spammers so far.
On Mon, Jun 5, 2017 at 12:28 PM, Mel Beckman <mel@beckman.org> wrote:
Chris,
I didn’t research Ron’s specific example. I was speaking in generalities. I’m assuming any BGP hijacker already has two or more DIA connections. It only costs $100 to add BGP peering to that setup. Yes, they will need an ASN. I was only
most times i've seen isp DIA links bgp was 'free' or had been..
talking about the cost of adding an upstream BGP session.
ok. so either free or some up-charge by the isp.
-mel
On Jun 5, 2017, at 9:03 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Jun 5, 2017 at 7:05 AM, Mel Beckman <mel@beckman.org> wrote:
One way is for the hijacker to simply peer with himself. The hijacker has an existing peering arrangement with, say, AT&T. He then tells AT&T that he will be transit for ASxxxx advertising XYZ routes, by dint of a cheerfully forged LOA. Once filters have been updated, the hijacker advertises the space to himself, and then from thence to AT&T.
that doesn't seem to be what's happening in ron's example though...
it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776) 3) start doing the bgps with the IX fabric's route-server 4) profit (or something)
so here the IXP operator (balkans ix actually?) http://lg.bix.bg/?query=summary&addr=&router=rs1.bix.bg+%28IPv4%29 (search for 206776 -> http://lg.bix.bg/?query= bgp&addr=neighbors+193.169.198.191&router=rs1.bix.bg+(IPv4))
should probably look more than just side-eyes at their customer...
It's no great trick getting peering set up. Just fill out a ten-question BGP app and pay a one-time fee of maybe $100, and you're done.
err, you'll have to better explain this I think.
Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does)
this doesn't get you a peering/transit contract though...
-chris
-mel beckman
On Jun 5, 2017, at 3:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
The more I know, the less I understand.
Maybe some of you kind folks can help.
Please explain for me the following scenario, and how this all actually works in practice.
Let's say that you're a malevolent Bad Actor and all you want to do is to get hold of some ASN that nobody is watching too closely, and then use that to announce some routes to some IPv4 space that nobody is watching too closely, so that you can then parcel out that IP space to your snowshoe spammer pals... at least until somebody gets wise.
OK, so you pull down a copy of, say, the RIPE WHOIS database, and you programatically walk your way through it, looking for contact email addresses on ASN records where the domain of the contact email address has become unregistered. Say for example the one for AS34991. So then you re-register that contact domain, fresh, and then you start telling all of your friends and enemies that you -are- AS34991.
That part seems simple enough, and indeed, I've seen -this- part of the movie several times before. However once you have stepped into the identity of the former owners of the ASN, if you then want to actually proceed to -announce- some routes, and actually ave those routes make it out onto the Internet generally, then you still have to -peer- with somebody, right?
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys? (I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to? And if you are going to push your route announcements out to, say, the specific routers that are run by AS206776 and AS57344, i.e. the ones that will send your desired route announcements out to the rest of the Internet... well.. how do you find out the IP addresses of those routers on those other networks? Do you call up the NOCs at those other networks and do a bit of social engineering on them to find out the IP addresses you need to send to? And can you just send BGP messages to the routers on those other networks without -any- authentication or anything and have those routers just blindly accept them -and- relay them on to the whole rest of the Internet??
I've read article after article after article bemoanging the fact that "BGP isn't secure", but now I'm starting to wonder just how massively and unbelieveably unsecure it actually is. I mean would these routers being run by AS206776 and AS57344 just blindly accept -any- route announcements sent to them from literally -any- IP address? (That seems positively looney tunes to me! I mean things can't really be THAT colossally and unbelievably stupid, can they?)
Thanks in advance for any enlightenment.
Regards, rfg
P.S. It would appear to be the case that since some time in April of this year the "Bulgarian" network, AS34991, had evinced a rather sudden and pronounced affinity for various portion of the IPv4 address space nominally associated with the nation of Columbia, including at least five /24 blocks within 168.176.0.0/16 which, from where I am sitting, would appear to belong to the National University of Columbia.
Oh well. They apparently haven't been missing those five gaping holes in their /16 since the time the more specifics started showing up in April.
And anyway, so far it looks like the new owners of AS34991 haven't actually sub-leased any of those /24s to any spammers yet. Only the 190.90.88.0/24 block seems to be filled, wall-to-all, with snowshoe spammers so far.
In message <CAL9jLaZ3zED6tamFHo+W31SgPiP22Ms2Qt0BkudoJphrevCxiw@mail.gmail.com> Christopher Morrow <morrowc.lists@gmail.com> wrote:
most times i've seen isp DIA links bgp was 'free' or had been..
talking about the cost of adding an upstream BGP session.
ok. so either free or some up-charge by the isp.
Wait a minute. I just wanna make sure that I am getting this. So you're saying that whichever criminal is behind this stuff, that he maybe could have pulled it all off for the astounding and impressive sum of zero dollars and zero cents ($0.00) ? (Well, I guess that's not quite accurate. I guess that he at least had to pay for the cost of re-registering the wirelessnetbg.info domain name. I don't know what .info domains cost anymore, but the last time I looked you could get one of those for less than ten bucks. I suppose that Internet criminals everwhere will be greatly heartened by the low cost of entry into this game. I'm guessing that it probably costs much much more to become an Amway distributor, for example. Even second-story men have to invest more than this for a set of appropriate tools.) Regards, rfg
On Mon, 05 Jun 2017 18:04:54 -0700, "Ronald F. Guilmette" said:
So you're saying that whichever criminal is behind this stuff, that he maybe could have pulled it all off for the astounding and impressive sum of zero dollars and zero cents ($0.00) ?
(Well, I guess that's not quite accurate. I guess that he at least had to pay for the cost of re-registering the wirelessnetbg.info domain name.
Anybody who didn't just fall out of a tree will use a stolen but still functional credit card for that. So yeah, it's zero money out of their own pocket.
In message <CAL9jLaZRhH8+5mD0Tgu1SdnEjG5zvxkKs+SaFFqk3FAjfnVjaw@mail.gmail.com> Christopher Morrow <morrowc.lists@gmail.com> wrote:
that doesn't seem to be what's happening in ron's example though...
it looks, to me, like the example ron has is more a case of: 1) register contacts for lost asn (AS34991) 2) setup equipment/etc at an IX (bulgaria-ix it seems, at least) with another shill/lost-child asn (AS206776)
I'm perplexed at why you would call AS206776 a "lost child", so perhaps you could explain that. From where I'm sitting, it does look rather entirely dodgy... being (allegedly) located as it is in the British Virgin Islands, and having only been created (manufactured?) circa 2016-11-04. But bpg.he.net is showing that it has 35 peers, and that it is peering even with the likes of big boys like HE.net and Level3, just to name a few.
3) start doing the bgps with the IX fabric's route-server
Yeabut again, I personally would like to be enlightened about the basic mechanics of how one causes this to happen. If I am Joe Blow criminal and I somehow manage to finnagle my way into having a machine which is physically present within some IX at some locale, somewhere on planet earth, then does that mean that, by definition, I know -where- to inject bogus routes and -how- to inject bogus routes and that I have the -capability- in inject bogus routes into the kind of "fabric route server" you speak of? And by the way, I see now that I botched the Subject: for this thread that I started. I meant to say "IP Hijacking for Dummies". Obviously, this activity has become so popular that it is high time that somebody wrote one of those "XYZ for Dummies" books, you know, with the yellow and black covers, so that aspiring but ignorant criminals don't have to always start from scratch and learn how to do this stuff from the ground up, based just on piecing together little scraps and fragments of information scattered all over the Internet.
4) profit (or something)
Yea. I don't think that hijackers are doing this stuff just for fun. But they've already figured out how to MAKE MONEY FAST from the purloined IP space, so that part probably doesn't even need to go in the book.
err, you'll have to better explain this I think.
Are you saying: "get an ASN from RIR that costs 100USD" (might, probably does)
this doesn't get you a peering/transit contract though...
Yea, this is a part of what I'm still mystified about. Have AS206776 and AS57344 been paid to pass the routes given to them by AS34991 ? And have they been paid an extra premium, above and beyond the normal fee for this service, you know, to look the other way and do the old Muhammad Ali rope-a-dope and act stupid/innocent when and if anybody ever calls them out for this rather entirely blatant and brazen bogosity? I've seen this movie before, and not that long ago. And it's just not nearly as entertaining the second time around. The upstreams shrug and offer the lame excuse of "Oh... well... the routes are all properly registered in the RIPE route registry, so, you know, how could we have possibly known that anything was amiss?" But as I learned last time this lame excuse was used, any baboon with a keyboard and a pulse can get himself a RIPE account and then create all of the bogus route objects he or she desires. And since it took me less than a day to find out this ludicrous but true fact last time, I have to wonder if network operators, and particularly those in the RIPE region, are in some cases being -willfully ignorant- of the fact that a route object's presence within the RIPE data base has a reliability value roughly equal to that of a three dollar bill. Regards, rfg P.S. I'll be more than happy to take it upon myself... even being the basically unknown nobody and non-network-operator that I am... to send polite emails to both AS206776 and AS57344, asking them, as politely as I can manage, to please explain just WTF they think they are doing. But if past experience from the last such event is any guide, these emails will have no effect whatsoever. So that leads me to ask the obvious next question: Is it at all likely that anybody at, say, HE.net and/or Level3 might give enough of a damn about any of this ludicrous and clearly malevolent bogosity so that they mught actually be inclined to have a friendly word with the folks at AS206776 and AS57344? And if so, how might I get in touch with any such people (at HE and/or Level3)?
On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys?
Hi Ron, You actually got lost a couple steps back. First, you want to control the POC emails for the IP addresses. Controlling just the POC emails for the AS number won't do you any good. Let's say you have gained control of the POC emails for the IP address block. Stay completely away from the historical BGP peers. They might know the real registrant and get suspicious when you show up. Go to somebody else, dummy up some letterhead for the purported registrant and write yourself a letter authorizing the ISP to whom the letter is presented to route those IP addresses. Explain that you're a networking contractor working for the organization holding the registration and give them adequate contact information for yourself: postal address, email, phone. Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the cash-bought debit card. You get the idea. Then you pay the ISP to connect you to the Internet and present your letter. Until the inevitable complaints roll it, that's it: you have control of those IP addresses.
(I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to?
You don't. Even if the session wasn't disabled when the customer stopped paying, you're not physically connected to the same network interface where it was configured. This reasoning path is a dead end. I've read article after article after article bemoanging the fact that
"BGP isn't secure",
They're talking about a different problem: ISPs are supposed to configure end-user BGP sessions per BCP38 which limits which BGP announcements the customer can make. Some ISPs are sloppy and incompetent and don't do this. Unfortunately, once you're a level or two upstream the backbone ISP actually can't do much to limit the BGP announcements because it's often impractical to determine whether a block of IP addresses can legitimately be announced from a given peer. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
In message <CAP-guGUt_JVjk0pa_ao2FGJuudun389UyAReqVhfy7Oah8eSSQ@mail.gmail.com> William Herrin <bill@herrin.us> wrote:
You actually got lost a couple steps back.
First, you want to control the POC emails for the IP addresses. Controlling just the POC emails for the AS number won't do you any good.
Ummm... in this case there doesn't seem to be any reason to believe that the hijacker(s) have gotten anywhere near to controlling the POC emails for any, let alone -all- of the relevant (Columbian) IP blocks... only the POC emails for the ASN. But you are suggesting that they -did- get control of those, all essentially simultaneously (or anyway sometime during the past 2 months), for all of about five or six or seven separate and different Columbian entities. That theory would seem to fail the Occam's razor test. It just doesn't seem at all liklely.
Let's say you have gained control of the POC emails for the IP address block. Stay completely away from the historical BGP peers. They might know the real registrant and get suspicious when you show up.
Good point! I'll have to remember to put that in the book. :-)
Go to somebody else, dummy up some letterhead for the purported registrant and write yourself a letter authorizing the ISP to whom the letter is presented to route those IP addresses. Explain that you're a networking contractor working for the organization holding the registration and give them adequate contact information for yourself: postal address, email, phone. Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the cash-bought debit card. You get the idea.
Yes. The whole general identity theft ruse isn't that complicated to understand. I still don't get how these crooks managed to get past that occular biometric scan, but I guess the check cleared, so maybe that goes a long way towards explaining -that- mystery. :-)
Then you pay the ISP to connect you to the Internet and present your letter. Until the inevitable complaints roll it, that's it: you have control of those IP addresses.
I guess that I must be hoplessly naive to believe that the likes of either Hurricane or Level3 might employ some warm body, at least part time, to actually look for this kind of blatant gibberish, and flag it for further inquiry when it arises. I would volunteer to do the job for them if they would just keep me in Cheetos. (Cheetos are my new favorite snack ever since last November's election. :-)
I've read article after article after article bemoanging the fact that
"BGP isn't secure",
They're talking about a different problem: ISPs are supposed to configure end-user BGP sessions per BCP38 which limits which BGP announcements the customer can make. Some ISPs are sloppy and incompetent and don't do this.
Yea. I kinda thought that most or all of the very public hand-wringing over the "insecurity" of BGP was indeed about this other aspect of the problem. But I just wanted to be sure that I was clear in my own mind about this. The insecurity -isn't- that any Joe Blow can just willy nilly connect up to any router on the Internet and push bogus routes into it. The insecurity is only that people/entities you know, trust, and have actual business relationships with can (and apparently do), in many cases, pass goofy stuff to you, and if you are not fastidious enough about washing up after such contacts, then you pass those bits of nonsense along to everybody else who you have relationships with... sort-of like chlamydia. Regards, rfg
On 06/06/2017 03:20, William Herrin wrote: Ronald, Here is how I would do it: 1. As you noted in your first email in this thread, find an abandoned ASN, lets call it AS12345, with a POC of support@acme.com 2. Create a domain called acme-corp.com and a user called peering 3. Contact an IX, preferably not one in a Westernized, clueful area: https://en.wikipedia.org/wiki/List_of_Internet_exchange_points 4. Using peering@acme-corp.com, state that you are AS12345 and you wish to join their wonderful IXP and to bring you router to their IXP for peering purposes and to pay full membership dues. 5. In general, not much due diligence will be done, since all Acme is requesting is to colo their router in the same room/floor/building as the IX and the IX is always trying to increase membership. Not every IX in the world is as diligent as LINX (example): https://www.linx.net/join-linx/joining-procedure 6. In the event the IX does ask for some documentation, create a logo, forge a few documents, create a nice corporate landing page with the logo, etc. Remember, the ASN hijacker will have done their homework and shy away from clueful IXs. 7. Pay your membership, bring your router to the IX and install it 8. IX announces to all members about the existence of a new IX member. 9. Major/large peers will shy away from small unknown ASNs, but there are always many smaller IX members who are willing to peer with you simply by sending them an email. 10. Of the 56 IX members at clueless IX, 18 have peered with you within a week and you have established your bona-fides. You are now in your way to growing your business :-) Regards, Hank
On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
So, I guess then, if you're clever, you look and see who the ASN you've just successfully hijacked has historically peered with, and then you somehow arrange to send route announcements to those guys, right? (I'm talking about AS206776 and AS57344 here, BTW.)
But see, this is where I get lost. I mean how do you push your route announcements to these guys?
Hi Ron,
You actually got lost a couple steps back.
First, you want to control the POC emails for the IP addresses. Controlling just the POC emails for the AS number won't do you any good.
Let's say you have gained control of the POC emails for the IP address block. Stay completely away from the historical BGP peers. They might know the real registrant and get suspicious when you show up. Go to somebody else, dummy up some letterhead for the purported registrant and write yourself a letter authorizing the ISP to whom the letter is presented to route those IP addresses. Explain that you're a networking contractor working for the organization holding the registration and give them adequate contact information for yourself: postal address, email, phone. Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the cash-bought debit card. You get the idea.
Then you pay the ISP to connect you to the Internet and present your letter. Until the inevitable complaints roll it, that's it: you have control of those IP addresses.
(I don't actually know that much about how BGP actually works in practice, so please bear with me.) How do you know what IP address to send your announcements to?
You don't. Even if the session wasn't disabled when the customer stopped paying, you're not physically connected to the same network interface where it was configured. This reasoning path is a dead end.
I've read article after article after article bemoanging the fact that
"BGP isn't secure",
They're talking about a different problem: ISPs are supposed to configure end-user BGP sessions per BCP38 which limits which BGP announcements the customer can make. Some ISPs are sloppy and incompetent and don't do this. Unfortunately, once you're a level or two upstream the backbone ISP actually can't do much to limit the BGP announcements because it's often impractical to determine whether a block of IP addresses can legitimately be announced from a given peer.
Regards, Bill Herrin
Hank Nussbacher wrote:
2. Create a domain called acme-corp.com and a user called peering
Or one could register aсme.com (If the reader can't tell the difference between acme.com and aсme.com , the reader is using one of the multitude of email clients and/or fonts that presents Unicode poorly.)
3. Contact an IX, preferably not one in a Westernized, clueful area: https://en.wikipedia.org/wiki/List_of_Internet_exchange_points
I don't think the ordinary Westernized IX is immune to this. Any system requiring human scrutiny is only as secure as the laziest human employed by it. Don't underestimate the "too busy to check this crap" attitude and its potential for serious problems. -- Regards, S.C.
In message <1496754899.2014592.1000384072.3E55368A@webmail.messagingengine.com>, Scott Christopher writes:
Hank Nussbacher wrote:
2. Create a domain called acme-corp.com and a user called peering
Or one could register aсme.com
(If the reader can't tell the difference between acme.com and aсme.com , the reader is using one of the multitude of email clients and/or fonts that presents Unicode poorly.)
3. Contact an IX, preferably not one in a Westernized, clueful area: https://en.wikipedia.org/wiki/List_of_Internet_exchange_points
I don't think the ordinary Westernized IX is immune to this. Any system requiring human scrutiny is only as secure as the laziest human employed by it. Don't underestimate the "too busy to check this crap" attitude and its potential for serious problems.
-- Regards, S.C.
Route hijacking is theoretically preventable. You have machines verify the bonifides. This does require that people take the time to get the bonifides machines can process but we do have the tech to do this. Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews <marka@isc.org> wrote:
Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight.
i don't think any transit providers were used in the previous thread worth of examples/comms... I don't know that IXP folk either: 1) want to be the police of this 2) should actually be the police of this (what is internet abuse? from who's perspective? oh...) The 'solution' here isn't new though... well, one solution anyway: https://tools.ietf.org/html/rfc6810
In message <CAL9jLaZNRdE0gL4nVn93vhv1BOBtx0EKgJet8pVXa3Mve1Gy_Q@mail.gmail.com>, Christopher Morrow writes:
On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews <marka@isc.org> wrote:
Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight.
i don't think any transit providers were used in the previous thread worth of examples/comms... I don't know that IXP folk either: 1) want to be the police of this 2) should actually be the police of this (what is internet abuse? from who's perspective? oh...)
The 'solution' here isn't new though... well, one solution anyway: https://tools.ietf.org/html/rfc6810
You missed the point. We have the mechanisms to prevent hijacking today. We just need to use them and stop using the traditional mechanisms which cannot be mathematically be verified as correct. Getting to that stage requires several companies to simultaneously say "we will no longer accept <list> as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Jun 6, 2017 at 9:13 PM, Mark Andrews <marka@isc.org> wrote:
In message <CAL9jLaZNRdE0gL4nVn93vhv1BOBtx0EKgJet8pVXa3Mve1Gy_Q@mail. gmail.com>, Christopher Morrow writes:
On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews <marka@isc.org> wrote:
Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight.
i don't think any transit providers were used in the previous thread
worth
of examples/comms... I don't know that IXP folk either: 1) want to be the police of this 2) should actually be the police of this (what is internet abuse? from who's perspective? oh...)
The 'solution' here isn't new though... well, one solution anyway: https://tools.ietf.org/html/rfc6810
You missed the point. We have the mechanisms to prevent hijacking today. We just need to use them and stop using the traditional
apologies for taking your bait.
mechanisms which cannot be mathematically be verified as correct.
i agree.
Getting to that stage requires several companies to simultaneously say "we will no longer accept <list> as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do.
agreed here as well.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 6/6/17 9:13 PM, Mark Andrews wrote:
Getting to that stage requires several companies to simultaneously say "we will no longer accept <list> as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do.
And what of legacy address holders? ARIN will not permit RPKI use of their blocks. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
In message <2541cadf-4a76-b172-b395-0822f18898f8@bryanfields.net>, Bryan Fields writes:
On 6/6/17 9:13 PM, Mark Andrews wrote:
Getting to that stage requires several companies to simultaneously say "we will no longer accept <list> as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do.
And what of legacy address holders? ARIN will not permit RPKI use of their blocks.
This really doesn't prevent it being used. RPKI could have a forth CA for legacy holders that don't accept ARIN's terms for issuing of RPKI. You just need to co-ordinate yourselves. There is nothing magical about the current three other than they are accepted by everyone. Or we can just abandon IPv4 and its legacy baggage and do it for IPv6. Mark
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 6 Jun 2017, at 9:25 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
On 6/6/17 9:13 PM, Mark Andrews wrote:
Getting to that stage requires several companies to simultaneously say "we will no longer accept <list> as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do.
And what of legacy address holders? ARIN will not permit RPKI use of their blocks.
Note that ARIN does provide RPKI services for legacy blocks, but it is true that we require more legalisms than other RIRs… You can caulk this up to the abundance of legacy resources of questionable provenance in this region, to the colorful US legal environment, and/or to a desire not to endanger the services we’re already providing to thousands of customers. (Interestingly enough, parties in the other regions agree to very similar terms and conditions when they use the respective RPKI services, only the binding is implicit and thus somewhat unseen to the user… <chuckle>) Thanks! /John John Curran President and CEO ARIN
On 7/2/17 1:28 PM, John Curran wrote:
Note that ARIN does provide RPKI services for legacy blocks, but it is true that we require more legalisms than other RIRs… You can caulk this up to the abundance of legacy resources of questionable provenance in this region, to the colorful US legal environment, and/or to a desire not to endanger the services we’re already providing to thousands of customers.
Only if you sign the RSA and give up certain legal rights to your legacy blocks/property. I can't speak for everyone, but those I do know are not willing to do this. I'd propose there must be a better way that doesn't require legacy holders sign the RSA. RPKI is important enough that something should be possible. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
On 3 Jul 2017, at 10:18 AM, Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: Only if you sign the RSA and give up certain legal rights to your legacy blocks/property. the word 'certain' is not apt given that the LRSA Ts&Cs may be arbitrarily changed by ARIN Randy - Not quite arbitrarily - ARIN can change it because of a change in the applicable caselaw, but otherwise RSA changes happen only with the consent of the Members - <https://www.arin.net/resources/agreements/rsa.pdf> "(e) ARIN may only modify the terms of this Agreement under the following circumstances: (1) The Board finds an immediate and compelling need to amend the Agreement due to a definable, discrete, identifiable change in relevant statute or caselaw; or (2) Upon recommendation of the Board and ratification by Member vote.” (Yes, this is one the changes that rolled out with the most recent RSA/LRSA, so you might not have been aware of same.) Thanks! /John John Curran President and CEO ARIN
On 2 Jul 2017, at 2:22 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
On 7/2/17 1:28 PM, John Curran wrote:
Note that ARIN does provide RPKI services for legacy blocks, but it is true that we require more legalisms than other RIRs… You can caulk this up to the abundance of legacy resources of questionable provenance in this region, to the colorful US legal environment, and/or to a desire not to endanger the services we’re already providing to thousands of customers.
Only if you sign the RSA and give up certain legal rights to your legacy blocks/property. I can't speak for everyone, but those I do know are not willing to do this.
And they may choose to do so. Others have no problem signing the LRSA/RSA (which are effectively the same T&C’s now aside from fee schedule), and like having a very clear statement of their rights to the number resources, such as right to transfer, access to arbitration, etc. (These rights weren’t well spelt out in the earlier versions of the LRSA or RSA, but we eventually got their in the current form.) Of course, the other little detail isn’t whether they’re willing to sign, it is whether they are entitled to sign, since the only parties that can enter an LRSA is the recipient or their legal successor to the rights. (It can be amusing when recently created entities attempt to explain why they are the legal rights holder to a legacy number block…)
I'd propose there must be a better way that doesn't require legacy holders sign the RSA. RPKI is important enough that something should be possible.
RPKI is quite important, but it also requires a solid legal foundation – Resource certification absent the proper legal details as to who has the rights and what rights that they have) is likely worse than no RPKI at all. Thanks, /John John Curran President and CEO ARIN
Mark Andrews wrote:
but we do have the tech to do this.
I wholeheartedly agree.
All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight.
This is the hard part. It seems trivial - being probably only a handful of transit providers - but then again, these providers have massive infrastructure spread globally, often ancient legacy systems that still work, and management has a legal responsibility in most places to maximize the profits of their shareholders. Look at the rollout of EMV in the U.S.: the world "has done had that tech to do that" for decades (in Europe) but it only arrived in the U.S. two years ago. And the U.S. doesn't do the (more secure) chip-and-pin like the rest of the world (that costs too much money according to the banks) but rather chip-and-signature. Whereas U.S. banks are (sometimes) liable for fraud on their systems, transit providers don't have any liability for anything in the U.S. And they are actively fighting for their right to transit some packets faster than others - for an additional fee, of course! I think the solution is legislation + regulations. -- Regards, S.C.
In message <1496816542.3628250.1001312328.70DF4DB2@webmail.messagingengine.com> , Scott Christopher writes:
Mark Andrews wrote:
but we do have the tech to do this.
I wholeheartedly agree.
All it takes is a couple of transit providers to no longer accept word-of-m outh and the world will transition overnight.
This is the hard part.
It seems trivial - being probably only a handful of transit providers - but then again, these providers have massive infrastructure spread globally, often ancient legacy systems that still work, and management has a legal responsibility in most places to maximize the profits of their shareholders.
Look at the rollout of EMV in the U.S.: the world "has done had that tech to do that" for decades (in Europe) but it only arrived in the U.S. two years ago. And the U.S. doesn't do the (more secure) chip-and-pin like the rest of the world (that costs too much money according to the banks) but rather chip-and-signature.
Whereas U.S. banks are (sometimes) liable for fraud on their systems, transit providers don't have any liability for anything in the U.S. And they are actively fighting for their right to transit some packets faster than others - for an additional fee, of course!
Actually they do have liability. It just needs someone to sue them for them to wake up. The injured party isn't a customer of the transit provider so there isn't any weasle worded contract to sace the transit provider.
I think the solution is legislation + regulations.
-- Regards, S.C. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 6/6/17 6:14 AM, Scott Christopher wrote:
Or one could register aсme.com
For what it's worth, that domain name (with a Cyrillic character 0441 replacing the "c" in "acme") wouldn't be allowed based on this: https://www.verisign.com/en_US/channel-resources/domain-registry-products/id... (See section 3, "For example, a character from the Latin script cannot be used in the same IDN with any Cyrillic character.") But those rules are not foolproof. "асе.com" is entirely Cyrillic (0430 0441 0435), and is in fact registered. Compare these in Firefox: http://ace.com/ http://асе.com/ Chrome has protection against this, displaying the latter as "http://xn--80ak9a.com/" due to: https://www.xudongz.com/blog/2017/idn-phishing/ But it's all very much ad-hoc.
(If the reader can't tell the difference between acme.com and aсme.com , the reader is using one of the multitude of email clients and/or fonts that presents Unicode poorly.)
Even the Unicode sample glyph charts render code points 0063 and 0441 identically: http://www.unicode.org/charts/PDF/U0000.pdf http://www.unicode.org/charts/PDF/U0400.pdf And there are lots of other examples. It's hard to say how to fix all possible cases of what amounts to a human language problem. -- Robert L Mathews
On Tue, Jun 6, 2017 at 2:25 AM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote: (I think this is really Ron and Bill chatting, but some of the linkage got lost on the tubes)
I've read article after article after article bemoanging the fact that
"BGP isn't secure",
They're talking about a different problem: ISPs are supposed to configure end-user BGP sessions per BCP38 which limits which BGP announcements the customer can make. Some ISPs are sloppy and incompetent and don't do
this.
Unfortunately, once you're a level or two upstream the backbone ISP actually can't do much to limit the BGP announcements because it's often impractical to determine whether a block of IP addresses can legitimately be announced from a given peer.
just a clarifying note: I don't think bcp38 talks about BGP at all, actually... I think bill is actually saying: "ISPs are supposed to configure bcp38 to filter TRAFFIC from their customers/peers and BGP filters to limit the scope of the customer routes sent/received" I don't think the filtering of customer prefixes/announcements is actually covered in a BCP though.
participants (13)
-
Bryan Fields -
Christopher Morrow -
Hank Nussbacher -
John Curran -
John Curran -
Mark Andrews -
Mel Beckman -
Randy Bush -
Robert L Mathews -
Ronald F. Guilmette -
Scott Christopher -
valdis.kletnieks＠vt.edu -
William Herrin