IPv4 Hijacking For Idiots

Mailman List Mirror (Read Only)
1

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.

2

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

3

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?)
  BIX.BG (AS15669) Looking Glass - show ip bgp summary
  (search for 206776 ->
BIX.BG (AS15669) Looking Glass - show ip bgp neighbors 193.169.198.191
)

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

4

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

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+(IPv4)
  (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

5

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.

6

In message <CAL9jLaZRhH8+5mD0Tgu1SdnEjG5zvxkKs+SaFFqk3FAjfnVjaw@mail.gmail.com>

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)?

7

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

8

In message <CAL9jLaZ3zED6tamFHo+W31SgPiP22Ms2Qt0BkudoJphrevCxiw@mail.gmail.com>

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

9

In message <CAP-guGUt_JVjk0pa_ao2FGJuudun389UyAReqVhfy7Oah8eSSQ@mail.gmail.com>

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. :slight_smile:

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. :slight_smile:

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. :slight_smile:

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

10

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.

11

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 :slight_smile:

Regards,
Hank

12

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:
List of Internet exchange points - Wikipedia

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.

13

(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.

14

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

15

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

16

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

17

>
>
> > 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:
> RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol

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.

18

And what of legacy address holders? ARIN will not permit RPKI use of their
blocks.

19

> 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

20

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.