This article is a continuation of the last post on the BGP protocol. If you haven’t read it yet, do so before you start.
Let’s remember where we left off in the previous post. What we think is happening is that a user who will be on AS-200 is connecting to FTP, and we want to find out his login credentials, but the packet doesn’t go through us, it goes from AS-200 straight to AS-300. However, we can do a BGP hijacking attack so that we announce on our AS-100 router that we have a faster route to go to the FTP service, and so that AS-200 sends the packet to us instead of to AS-300, believing that it will be faster.
That way we will get all the information, which as you know from the post about the FTP protocol, is in clear.
To start the attack, you have to enter the configuration mode:
Now we are going to announce the route to get to ip 10.120.15.10, but instead of doing it by putting the subnet 10.120.15.0/24, we are going to do it by putting the subnet 10.120.15.0/25, because normally the most specific subnet is the one that wins, the idea is that our route is the one chosen as the preferred route.
Now run the following command to reset all routes and re-announce them:
If we now run the command show ip bgp 10.120.15.0/25, to see the details of the routes, we will see that our route now appears:
And if we look at the routes that the AS-200 router advertises, we see that it now advertises ours:
Now let’s run a tcpdump capturing the ftp packets for a little while, a minute or so:
If we now analyse the trace with wireshark, we see that something strange is going on, and it is not responding as it should, it is never completing the handshake:
If we do the same but analysing a ping that we send, we will not receive a reply, and analysing the traces we see that a loop is forming between us (AS-100) and the AS-300. So to solve it we have to eliminate the route to that router:
To do this, if we look at the configuration, we see that the line “route-map to-as300 permit 10” is allowing communication, let’s change it to a deny.
To do this, we need to create an “ip-prefix” that will serve as an identifier, it can have any name, in this case it is “PleaseSubscribe” and we indicate the subnet we are announcing:
The 5 that we put here or the 10 that we see above is only the sequence to insert or delete a value from the route-map, we could put from 1 to 65535 and first would be the 1 then the 2 etc. It is usually put 10 by 10 (the first the 10, the second the 20, etc) because in case of having to reorder it is very difficult to do if it is done 1 by 1. In our case as there is already a rule that has the 10 and we want to put one that goes before, then we put the 5.
Finally we have to assign to the subnet that we have added in the prefix-list PleaseSubscribe this logic that denies the route.
(We had to create a prefix-list and add that subnet because the match ip address command does not give you the option to add a subnet, you have to add a prefix-list).
If we now check the configuration, we can see that it has changed:
Now we go back to cleaning and re-announcing:
However, there is still something wrong. If we try again to do the ping test, we see that we do not receive anything either, analyzing we will see that now what happens is that we send the ping from AS-100 to AS-300 (because what we have cut is the route from AS-300 to AS-100, since AS-300 does not know how to send it that way because we did not announce, but we know how to send it from AS-100 to AS-300). AS-300, seeing that it cannot send it to AS-100 directly, is sending it first to AS-200, and from there to AS-100:
What happened before:
What happens now:
So we still have the loop.
So what we have to do is apart from not announcing the route we have created to AS-300, when we announce it to AS-200 we have to tell it not to announce it to anyone:
We need to edit the “route-map to-as200 permit 10” line to tell it not to advertise our network.
And with this command we tell it not to announce it:
We go out, clean up, and if we ping it now, we receive it correctly:
We repeat now the tcpdump to see the ftp as we did before, and when we look at the trace we will see that now we are receiving FTP packets and we can track them, seeing the user and the password:
With that password we get access to the machine where the victim of our attack was.
As an extra, we can list with “lxc list” the containers that we can access, and we see the 3 authority routers:
We can connect to each other with lxc exec — bash
If we ping or traceroute to 10.120.15.10, where the FTP is, we can see that our hijaking works perfectly:
(in the ping we can see it because the ttl that we receive is 62, if it were direct the ttl would be 63 (what the ttl does is that a packet does not make more than 64 hops, for this reason it is subtracted by each router and if it reaches 0 it dies. So if it has jumped 1 time because it goes straight we receive a ttl of 63 and if it has jumped 2 times because it has been diverted, we receive a ttl of 62)).
As a bonus, there is an unintentional way in which we can trick the router to receive the information. Basically, we do what we did at the beginning of the whole thing, we simply announce that we know how to get the packets to 10.120.15.0/25:
Here we see that we don’t receive any response from the ping because the initial loop that we saw between AS-100 and AS-300 is created.
Well, here what we are going to do is to modify our IP so that the router AS-100 believes that we are 10.120.15.10, and when AS-200 sends the packet (because let’s remember that it is going to send it to AS-100 before AS-300 because we have put /25 instead of /24) what AS-100 will do is to send the packet directly to us:
We receive the first root USER sent by the victim:
However, when it receives no response from us, it simply terminates the connection.
What we are going to do is that when we send USER root we are going to reply with 331, which is the valid user identifier sent by the FTP server when we connect, and as we can see the victim replies with the password:
We receive the first root USER sent by the victim:
And in this way we have successfully completed the BGP Hijacking. This is all about the BGP protocol, as you can see it is a complex attack because to perform the attack is necessary to have a good conceptual picture of the entire infrastructure, but although we have had some problems, once you understand what is happening is easy to find a solution.
If you liked the article, I recommend you to visit the rest of the articles on infrastructure hacking.