Short explanation

Satellite DVB-S/2 connections are, sometimes, unencrypted so with cheap hardware and some free software the downlink can be sniffed. By using the satellite as the downlink of an Internet connection, an attacker can use another connection which let to spoof IP address as a uplink and then have a hijacked IP from the satellite provider to use as a normal one and almost completely anonymous.

One good thing about this technique is to have an anonymous broadband connection directly to the attackers base/home/server/laptop without proxies/bouncers – if you have ever used TOR, you’ll probably realise know how useful these characteristics can be.

In summary, the attackers were using satellite link to anonymise their activities and prevent them being tracked. In this blog post I’ll show some ideas to track malicious agents trying to hide behind satellite links.

The anonymous connection

What to do when these connections are being used for “bad things”? I have also tried to research about different ways to locate these rogue connections. Here are a few ideas on how to solve this challenge:

The attacker connection is also vulnerable to attacks

If an attacker is using a connection vulnerable to sniffing and “Man-In-The-Middle” attacks, the communication stay vulnerable, so we can attack these:

Hijack communications with the systems the attacker is connecting with.

If the attacker navigate through HTTP, in some circumstances we can inject HTML or JavaScript code to get information of the target system.

Sometimes we can inject fake executable, ActiveX or Applets and try to cheat the attacker.

If the attacker system is configured as I proposed in my talk, that system can be reached with an satellite IP address, we can try to attack it.

Definitely these attacks can provide us information about the attacker but, most probably, not an address or a name.

Attack the network

Let’s redraw again the network diagram:

Here I draw R1 and R2, which are the routers of the ISP the attacker is using as the uplink channel of the hijacked satellite-based connection.

It’s not possible to get an IP address of the attacker because it is configured with the hijacked IP address, but, is it possible to get the IP address of R1 or R2? Getting that information can be really useful in the hunting of an attacker, remember that the target must use a local internet connection as uplink.

How can we get router IP addresses?

We can wait till the attacker do a traceroute, that can be a lot of time. We can´t control the TTL of an IP packet leaving the target host so let´s think in other way.

Record route

Another option is to ping the target and activate the record route option on IP, you can do that using hping:

# hping3 -1 IPsat -G

The record route option provides a means to record the route of an Internet packet. When an Internet module routes a packet it checks to see if the record route option is present. If it is, it inserts its own Internet address as known in the environment into which this packet is being forwarded into the recorded route.

We have it? No, this option must be activated in all routing devices, from you to the target and back, and usually this option is disabled – in a lot of years doing pentesting, I have only seen it work in a small fraction of cases.

ICMP errors

Another option I found with possibilities is to create IP traffic rejected by the uplink ISP routers (R1 or R2), and sniff the ICMP Destination Unreachable packets to get the IP of R1 or R2.

For example, pinging the satellite IP of the target from an internal address, the remote system will respond to the private IP echo with a ICMP echo response. If the traffic to that internal subnet is rejected by the uplink ISP routers, and usually it is, the routers will send an ICMP error to the satellite IP from the router own IP, so we can sniff that ICMP packet and get the IP address:

1. We send a ping request spoofing the source address:

   # hping3 -1 IPsat -a 10.30.16.41
   

   
   
2. The target system send a ping response to 10.30.16.41:
   
   
3. Traffic to 10.30.16.41 is not allowed so the packet is rejected by R1 to IPsat, so we can sniff that packet and know the IP of R1:
   
   

Some problems we find to use this technique:

What private IP addresses are rejected? We have to send several packets to the IP of the target, 69781, one packet per private C range or 17891228 which is the number of all private IP addressed.

What if the private IP addressed are filtered and not rejected? Bad luck.

The target host filter packets which come from private IP addresses via satellite interface? Bad luck.

What if the target host have filtered the ICMP ping? Please…

The idea of the target sending traffic to internal IP addresses can be exploited from several angles, for example, injecting malicious JavaScript on the targets browsers if he use it. Imagination! Imagination! Imagination!

Conclusion

So, if the attacker who is hijacking the satellite Internet connection is clever enough, this kind of connections are still anonymous. But, as I thought some attacks to break the anonymity, sure you people can follow this way.

The post Locating SAT based C&Cs appeared first on Portcullis Labs.

I suspect that the reasons why I was selected to lead this task were two fold: one I happen to co-own AS28792 and am not therefore an Internet n00b and two, rumour has it that I once “heckled” a talk on just this subject. Rumours can be unfair and I don’t recall the full details but, as I remember it, I simply answered a question from a fellow audience member on how MPLS labels are meant to be processed.

For those of you that may not have heard of it, MPLS is not a commonly used protocol, at least not outside of tier 1 networks. The purpose of this blog post isn’t to discuss the ins and outs of the protocol, but rather to show how we used the Scapy framework to quickly craft MPLS labelled packets and to highlight why it is important that testers can code.

Given the testing requirements, the Team examined the options available to complete the assessment. There are few, if any, tools that can be used to appropriately test MPLS implementations. The toolset I had in mind (having previously used it) was no longer available and whilst Google has a “not yet mainline” MPLS implementation for the Linux kernel, it seemed an inefficient use of time to get that running. In such circumstances, we would need to develop our own code quickly.

Scouring the Internet, I came across a post on the use of Scapy to craft MPLS packets. The code has a couple of bugs (IMO), around misnaming the bottom of stack marker bitfield and the author’s choice of default TTL, but otherwise it does the trick.

Consider the following code, taken from the post:

class MPLS(Packet):
        name = "MPLS"
        fields_desc =  [
                BitField("label", 3, 20),
                BitField("experimental_bits", 0, 3),
                BitField("bottom_of_label_stack", 1, 1), # Now we're at the bottom
                ByteField("TTL", 255)
        ]

This snippet specifies an MPLS class which, given Packet, will add 4 fields worth of data. The fields in question map on to the 32-bits of an MPLS header. I’ll leave you to read up on what the header will actually look like, but suffice it to say, label affects where packets go, TTL affects how far they go and bottom_of_label_stack and experimental_bits affect how the labels are processed along the way by routers (technically it’s a bit more complicated than that, but it will do as a starting point). The label has a length of 20 bits and a default value of 3 (a special reserved label meaning Implicit NULL Label), whilst the bottom_of_label_stack marker has a length of 1 bit and a default value of 1. As a byte field, TTL has an implicit length of 8 bits.

Next we have the following:

bind_layers(Ether, MPLS, type = 0x8847) # Marks MPLS
bind_layers(MPLS, MPLS, bottom_of_label_stack = 0) # We're not at the bottom yet
bind_layers(MPLS, IP)

In Scapy, we use bind_layers() to specify how various headers can be ordered within the overall packet. What this says is that an MPLS header can follow either an Ethernet header (with a type of 0×8847) or another MPLS header. In the latter case we should set the previous MPLS header’s bottom_of_label_stack marker to 0, to indicate that there is at least one further label header. Finally, we must follow our MPLS layer headers up with an IP header, before traversing into the more traditional TCP or UDP packet structure.

To craft a MPLS labelled packet, we can then call the following Python code:

p = Ether(src = "<my MAC address>", dst = "<next hop MAC address>") / MPLS(label = 255, TTL = 255) / IP(src = "<my IP address>", dst = "<target IP address>") / TCP(dport = 80)
p.show()
sendp(p, iface="eth0")

In layman’s terms, this means we will create an Ethernet frame, containing an MPLS header, with a label and TTL of 255, with an IP header and finally a TCP header.

Having shown how we can craft a TCP packet, let us look at the minimum set of MPLS protocol vulnerabilities we need to test for. The client had obviously read some papers on MPLS security, or at least RFC 4381, since the aims of the assessment identified the main points of concern as follows:

• Test for rejection of MPLS labelled packets on a P(provider) E(dge) interface
• Test for rejection of MPLS labelled packets with no bottom_of_label_stack marker
• Test for rejection of MPLS labelled packets with an early bottom_of_label_stack marker
• Test for rejection of MPLS labelled packets with large numbers of labels

The first test is about ensuring that the PE router cannot be tricked into misdirecting malicious packets, whilst the latter 3 are a minimum test set designed to ensure that it does not misprocess the packets in a way that may lead to Denial of Service or worse. A correct implementation will therefore gracefully reject MPLS packets in each of these cases.

There are of course more test cases that we could consider, and indeed the Team ended up using p.fuzz() to create infinite malformed packets, but let’s look at these test cases which formed the basis of our assessment.

An analogy for those of you that are unfamiliar with MPLS would be 802.11q tagging and whether a switch will accept a pre-tagged packet with a spoofed VLAN ID. In the VLAN world, acceptance of a spoofed ID would place the attacker on a VLAN for which they have not been authorised. In the case of MPLS, acceptance of a spoofed MPLS label might give the attacker access to another customer’s private virtual network. MPLS networks, and the P routers from which they are constructed, inherently trust the labels, so if you gain access beyond the PE, all bets are off.

In order to answer our client’s questions, we need to determine whether our MPLS labelled packets are rejected. RFC 4364 states that “a backbone router does not accept labelled packets over a particular data link, unless it is known that that data link attaches only to trusted systems”. In this instance, the client’s MPLS core was fiber and it was not possible to connect a testing laptop directly to it, either to simulate the PE router itself or indeed to simulate any of the inner P routers that made up the core. We could however mimic a C(ustomer) E(dge) router and see the PE router which gave us some ideas on how determining acceptance could be achieved.

Firstly, the client was able to configure a spanning port on the PE router. This gave us the ability to visually inspect the traffic as it passed through and confirm that our crafted packets never left the incoming CE to PE interface. The second solution was a bit less reliable but avoided the need for the PE router (or indeed the client’s collaboration, in this instance). The Team had already observed that the PE router itself had an SSH service listening on a loopback interface for management and that it was possible to route to and indeed connect to this. The Team hypothesised that, if a TCP packet was sent (with the SYN flag set) and if the packets were labelled with MPLS headers, then the connection would fail and no response would be seen from the SSH service on the router. As expected, both approaches proved successful and the Team was able to show that our labelled packets were ignored by the PE router.

One last note and something our Technical Director commented upon. Isn’t it nice when implementations actually follow design? Hats off to the various MPLS RFC authors for producing a set of standards that can be followed by both the developers of these routers and the administrators who ultimately commission them.

The post This way to 10.10.10.1: Playing with labelled switching appeared first on Portcullis Labs.