14

As we know Google DNS server (8.8.8.8) in 14th and 15th March was hijacked in Sao Paulo. And subsequent to this event, BGPmon.org announced an alert.

BGPmon alert

Now, In a course assignment, we are asked to find AS number of the attacker. I for this question have downloaded related dump files from routeviews.org and found this related messages:

TIME: 03/15/14 17:23:56
TYPE: BGP4MP/MESSAGE/Update
FROM: 187.16.216.20 AS28571
TO: 187.16.216.223 AS6447
ORIGIN: IGP 
ASPATH: 28571 1251 20080 7908 
NEXT_HOP: 187.16.216.20 
ANNOUNCE 
   8.8.8.8/32 

TIME: 03/15/14 17:23:56
TYPE: BGP4MP/MESSAGE/Update
FROM: 187.16.218.21 AS52888
TO: 187.16.216.223 AS6447
ORIGIN: IGP
ASPATH: 52888 1251 20080 7908
NEXT_HOP: 187.16.218.21
ANNOUNCE
   8.8.8.8/32

Our TA would say the attacker's AS was 7908 (BT LATAM Venezuela, S.A). But in my opinion it wasn't, because in my view there is no advantages to be exploited by the attacker if he does redirect traffics to his own AS. Despite of this, I couldn't find any update messages originated by this AS in dump files. In other hand, in the picture above, time of attack has been announced 17:23 and from this time onwards, I couldn't find any interesting messages in dump files.

My question is, can anyone please tell me what's the real AS number of attacker?

Thanks in advance

frogatto
  • 265
  • 1
  • 11
  • 3
    Why are there no advantages to redirecting to their own AS? Isn't that the whole point? To redirect traffic to a resource controlled by the attacker? – schroeder Jan 04 '15 at 07:26
  • 1
    @schroeder Because an attacker would not want to leave any traces of himself. "_...a resource controlled by the attacker..._" No, all traffics redirected to "BT LATAM Venezuela" and so far no malicious site has been detected. so we cannot say that the intention of attacker was redirecting people to a malicious website (phishing) – frogatto Jan 04 '15 at 07:36
  • 1
    If an attacker with BGP access mount an attack on internet infrastructure, it is very unlikely they just want to phish a few sites. But by any definition, they're the attacker of the routing system regardless of their ultimate goals. – billc.cn Jan 04 '15 at 11:54
  • 1
    @billc.cn Yes, I'm agree with you, why would they leave a trace of them self while there is no phishing and malicious destination for traffics – frogatto Jan 04 '15 at 13:33
  • 4
    I think our point is that the phrase "the attacker's AS" is inaccurate. The attacker could be anywhere. You could be in Guam and redirect people to Russia. But the goal of the attacker is to route traffic to a specific destination. That destination is what your TA is terming, "the attacker's AS". – schroeder Jan 04 '15 at 19:59
  • @schroeder Yes sir, you're right, the destination is obviously `AS7908` as we can see in the AS PATH. But what I need is not destination AS whereas I was asked to find AS number of attacker who started this hijacking – frogatto Jan 04 '15 at 20:22
  • 1
    Then I'm not sure that the answer is in the data you have. I'm not sure that it would be possible to determine that at all. – schroeder Jan 05 '15 at 01:05
  • I don't see how it's possible with the information provided to identify the AS of the attacker. Nor do I see the question as truly relevant. If they are trying to teach you howto identify the AS, they are successful. You seem to know what it is. If they are trying to teach you how to find the attacker, I think they are failing. Best of luck in your studies (genuinely). – Citizen Mar 12 '15 at 08:50
  • 3
    For anyone who comes looking at unanswered questions, an examination of the issue (and conclusion that it was probably someone tinkering, because 7908 had other leaks earlier in the day / also for China, because it's using those blocks internally): http://arstechnica.com/information-technology/2014/03/google-dns-briefly-hijacked-to-venezuela/ – ǝɲǝɲbρɯͽ Apr 01 '15 at 20:28
  • Re "TA" meaning? – Pacerier Dec 28 '16 at 07:22

1 Answers1

2

The real AS to feed a false route is any AS along the AS path:

7908 --> 20080 --> 1251 --> |28571|
                            |52888| --> 6447

you see in the 2 wrong announces of route to:

8.8.8.8/32

Hence all traffic toward 8.8.8.8/32 shoud be routed since this attack through ASes:

|28571|
|52888| --> 1251 --> 20080 --> 7908

If the target of this attack is to redirect all the flow toward Google to a booby trapped web server mimicking perfectly Google, then this booby trapped server must be inside of the under control AS which is at the end of this faked route. It is:

7908

which belongs to:

BT LATAM Venezuela, S.A.

And clearly the university of Oregon doesn't have to route its Google traffic through a cache located in Venezuela.

This isn't sufficient to diagnose this is a real attack or rather a human error (leak of an internal route on the allowed ones to broadcast to BGP neighbours). If this is an human error then the origin is most probably within:

AS 7908

But if this is an attack, then this is most probably conducted remotely and you can't locate its first hop of access without the connections logs on BGP router inside AS 7908.

dan
  • 3,033
  • 14
  • 34
  • This seems more sensible. In case of a remote attack, the connection logs are necessary - one question is; how to _legally_ get access of these logs? – Shritam Bhowmick Aug 29 '15 at 05:14