odd hijack

I recently brought up a prefix hijack that the NANOG community solved,
the AS had accidentally started announcing their bogon list.

Here is one that is somewhat the opposite, the AS announced a
significant portion of IANA allocated space. Note, they are large
blocks and as such probably did not cause much damage because most
networks announce more specifics. My question to the community is,
what kind of misconfiguration could cause this set of prefixes to be
announced? I asked the AS responsible, but have not had a response.

If you would like more information on the hijack, please see the
Internet Alert Registry forums at http://cs.unm.edu/~karlinjf/IAR/

Following are the AS's announced prefixes during the ~10 minute hijack
from earlier today:

11.0.0.0/8
12.0.0.0/7
121.0.0.0/8
122.0.0.0/7
124.0.0.0/7
126.0.0.0/8
128.0.0.0/3
15.0.0.0/8
151.99.190.0/24
16.0.0.0/6
160.0.0.0/5
168.0.0.0/6
172.0.0.0/8
188.0.0.0/8
189.0.0.0/8
190.0.0.0/8
191.0.0.0/8
192.0.0.0/8
193.0.0.0/8
194.0.0.0/7
196.0.0.0/8
198.0.0.0/8
199.0.0.0/8
20.0.0.0/7
200.0.0.0/8
201.0.0.0/8
202.0.0.0/7
204.0.0.0/7
206.0.0.0/7
208.0.0.0/8
209.0.0.0/8
210.0.0.0/7
210.170.0.0/18
212.0.0.0/7
214.0.0.0/7
216.0.0.0/8
217.0.0.0/8
218.0.0.0/7
22.0.0.0/8
220.0.0.0/7
222.0.0.0/8
24.0.0.0/8
25.0.0.0/8
26.0.0.0/8
28.0.0.0/7
30.0.0.0/8
32.0.0.0/6
32.1.21.168/32
38.0.0.0/8
40.0.0.0/8
41.0.0.0/8
43.0.0.0/8
44.0.0.0/6
48.0.0.0/6
56.0.0.0/7
58.0.0.0/8
59.0.0.0/8
6.0.0.0/8
60.0.0.0/7
62.0.0.0/8
63.0.0.0/8
64.0.0.0/5
72.0.0.0/7
74.0.0.0/7
76.0.0.0/8
77.0.0.0/8
78.0.0.0/7
8.0.0.0/7
80.0.0.0/7
82.0.0.0/8
82.143.0.0/18
82.143.0.0/20
82.143.0.0/21
82.143.10.0/23
82.143.12.0/24
82.143.16.0/20
82.143.32.0/19
82.143.32.0/24
82.143.33.0/25
82.143.8.0/23
83.0.0.0/8
84.0.0.0/6
88.0.0.0/7
90.0.0.0/8
91.0.0.0/8
96.0.0.0/6

Thanks,

Josh

Misconfiguration? :slight_smile: That's a nice word for spammer. See Joe's PPT at:
http://www.uoregon.edu/~joe/maawg8/maawg8.ppt

AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest Italia) and AS286 (KPN) that let this crap leak.

-Hank Nussbacher
http://www.interall.co.il

Wouldn't they want to hijack more specifics to spam? I doubt much of
that space is going to correctly route for spamming purposes.

Read Joe's PPT. All explained there.

Hank Nussbacher
http://www.interall.co.il

the preso link is below, you didnt read it yet.. :slight_smile:

you can hijack any address space providing your route is preferred either because it is more specific, less specific, shorter as-path..

Steve

My question to the community is,
what kind of misconfiguration could cause this set of prefixes to be
announced?

11.0.0.0/8
12.0.0.0/7
121.0.0.0/8
122.0.0.0/7
124.0.0.0/7
126.0.0.0/8
128.0.0.0/3

etc ...

This looks to me like some large multinational leaked
their internal announcements to an ISP. It is not unusual
for large companies to use random unregistered /8 blocks
in their internal networks. There are all kinds of
applications that need to talk across networks which do
not need any Internet connectivity or any direct
connectivity to general use workstations. This network
traffic would normally be hidden inside some kind of
VPN on the same infrastructure as other corporate
traffic.

So to answer your question, first look for all the ways
that a misconfiguration could allow routing information
to leak out of some flavor of VPN.

--Michael Dillon

Wouldn't they want to hijack more specifics to spam?

no. see nick feamster's work, and the lightning talk i proxied
for him in dallas.

randy

> Wouldn't they want to hijack more specifics to spam?

no. see nick feamster's work, and the lightning talk i proxied
for him in dallas.

randy

Right, you might want to announce less specifics so that you go
unnoticed and then you can spam from blocks not in use. I'm just
somewhat surprised that they would announce /3's, /6's, and /7's and
be so incredibly obvious about it rather than actually be covert and
just announce a few more specifics that likely noone would notice.

But I guess at this point they're still not being caught so why worry.

Josh

Here are the links from our observations on this, from our Feb NANOG talk:
http://www.nanog.org/mtg-0606/pdf/nick-feamster.pdf

and our SIGCOMM paper:
http://sigcomm06.stanford.edu/discussion/showpaper.php?paper_id=28"

Cheers,
Nick

Slides 13-15 of our Feb 2006 NANOG talk show examples of this and describe the
motivation.

The technique us also described in detail in our SIGCOMM paper, along with
several other observations about why doing things like looking at "uncommon
origin ASes" to detect a determined hijacker is unlikely to ever be successful
at detecting a malicious hijack (as opposed to a misconfiguration).

-Nick

In fact, it may not even be the immediate upstreams. In our paper, we
describe specific examples where it's very hard to track exactly who's at
fault, because so much of the AS path appears to be forged. See finding #5 in
the excerpt below.

I include the most germane excerpt from the paper below, for people's
convenience. btw, Randy Bush helped us understand this technique a bit better
and coined the phrase spectrum agility.

"...

We have called this technique ``spectrum agility'' because it allows a
spammer the flexibility to use a wide variety of IP addresses within a
very large block from which to send spam. The large IP address block
allows the mail relays to ``hop'' between a large number of IP
addresses, thereby evading IP-based filtering techniques like DNSBLs.
Judging from Figure~\ref{fig:dnsbls} and our analysis in
Section~\ref{sec:dnsbls}, the technique seems to be rather effective.
As an added benefit, route announcements for shorter IP prefixes (\ie,
larger blocks of IP addresses) are less likely to be blocked by ISPs'
route filters than route announcements or hijacks for longer prefixes.

Upon further inspection, we also discovered the following interesting
features: (1)~the IP addresses of the mail relays sending this spam are
widely distributed across the IP address space; (2)~the IP addresses
from which we see spam in this address space typically appear only once;
(3)~on February 6, 2006, attempts to contact the mail relays that we
observed using this technique revealed that that roughly 60-80\% of
these hosts were not reachable by {\tt traceroute}; (4)~many of the IP
addresses of these mail relays were located in allocated, albeit
unannounced and unused IP address space; and (5)~many of the AS paths
for these announcements contained reserved (\ie, to-date unallocated AS
numbers), suggesting a possible attempt to further hamper traceability
by forging elements of the AS path.
...
"

-Nick

I'm just somewhat surprised that they would announce /3's, /6's,
and /7's and be so incredibly obvious about it

if it was incredibly obvious, why did it take us so long to see it?

and no, please let's not all have a "i saw it first" contest.

randy