Is it theoretically possible to deploy backdoors on ports higher than 65535?

Question

Assuming you were able to modify the OS/firmware/device for server/client to send and listen on ports higher than 65535, could it be possible to plant a backdoor and have it listen on, say, port 70000?

I guess the real question is this:

If you rebuilt the TCP/IP stack locally on the machine, would the overall concept not work due to how the RFC 793 - Transmission Control Protocol Standard works as mentioned below in some of the answers? Making it impossible to access a service running on a port higher then 65535.

There has been so much talk about hardware and devices having backdoors created that only government have access to for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

Answer 1

No, the port number field in a TCP header is technically limited to 2 bytes. (giving you 2^16=65536 possible ports)

If you alter the protocol by reserving more bits for higher ports, you're violating the specification for TCP segments and wouldn't be understood by a client. In other words, you're not speaking TCP anymore and the term "port" as in "TCP source/destination port" wouldn't apply. The same limitation exists for UDP ports.

That said, a backdoor could instead communicate over a different protocol than TCP or UDP to obscure its communication. For example, icmpsh is a reverse shell that uses ICMP only. Ultimately, you can also implement your own custom transport-layer protocol using raw sockets that can have its own notion of ports with a greater range than 0-65535.

Answer 2

No, it's that number because the TCP field for that is only 16 bits long (65536, but starting at 0), so it is fundamentally impossible to communicate a higher port than 65535

This post has a really nice writeup on why this is so in IPv4, how it's the same in IPv6, and how you can reuse ports in regular use.

Answer 3

If you rebuilt the TCP/IP stack locally on the machine, would the overall concept not work due to how the RFC 793 - Transmission Control Protocol Standard works as mentioned below in some of the answers? Making it impossible to access a service running on a port higher then 65535.

There are no TCP/UDP services on ports higher than 65535. If it supports port numbers above 2¹⁶-1, then it no longer is TCP (or UDP).

Can you have something else that...? Sure. And could it be very similar to TCP? To the point of being backwards compatible? Yes to both questions.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

If I had developed such a device, it would rely on a protocol common enough as to be unremarkable. An unknown/illegal protocol packet, after which some extra traffic ensues, would be quite suspicious.

Hide in (almost) plain sight

What such a device could do might be, for example, inspect some bytes in the payload. They would usually be noncorrelated values; I could then send packets to the target, or if it is a router, without even a IP address of its own, to some random, possibly even nonexistent host beyond the target, masquerading as (say) a HTTPS request, or a SSH login attempt.

If you see a packet you do not know, you might get suspicious. But even if you saw in the logs something like

SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance

you would not worry, especially if you had no user "maintenance". You would perhaps assume someone, somewhere, discovered an attack against some device with a default user of "maintenance" (heck, if I was a government, I could market such a device, have it vulnerable, and not fix it, for the sole purpose of justifying such connections on totally different devices. What's the first thing you would do in seeing such attempts? Either nothing ("harmless bruteforce. Idiot"), google and shrug ("Oh, someone thinking I have a CheapRouter 2000. Idiot", possibly write a firewall rule to block the IP - except that the packets still arrive to the network card).

And what actually happens is that the evil firmware in the router, network card, motherboard or what have you, recognizes the packet and sends back an answer. It could do so by forging response packets overwriting the "real" ones.

The only symptom of something very bad happening would be if you compared, say, the inbound and outbound traffic from an evil router:

Host with SSH server:

--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH S+A <-- HOST
--> SSH ACK --> ROUTER --> SSH ACK --> HOST
...
--> LOGIN ----> ROUTER --> LOGIN ----> HOST
<-- FAIL2------ ROUTER <-- FAIL1 <---- HOST    packets are different!

Host without SSH server:

--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH RST <-- HOST    wait, WTF?
--> SSH ACK --> ROUTER                 HOST
...
--> LOGIN ----> ROUTER                 HOST
<-- FAIL2------ ROUTER                 HOST

If you sniffed on a cable, either to the left or to the right of the compromised device, you would notice nothing immediately amiss.

The other suspicious thing would then be that the sender apparently uses the TCP Fast Open extension. Note that you can send extra data in the SYN even without TCP/FO, it will simply be ignored by devices that are both non-FO and non-compromised.

Answer 4

As already said, port numbers are represented with unsigned 16-bit integer and cannot be above 65535.

But there is a possibility to use different protocols (not TCP or UDP). In IP header there is a 8-bit field called «protocol number», which denotes what transport protocol is used inside this packet.

You can look at the table of transport protocols here: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Some protocols from this list are user widely (for example, TCP or UDP), some more rarely (DCCP or UDPLite). Some protocol numbers are not used yet, and some are deprecated (ARGUS, EMCON).

So, backdoor can use unused protocol numbers to send data to its server. Of course, this technique are difficult to implement (needs access to rawsocket or implementing backdoor as OS kernel module).

Answer 5

This would be possible to achieve but you would not be able to use protocols such as UDP and TCP since their max port is 65535.

You would need to implement your own protocol on top of the IP protocol.

This may be possible using raw sockets.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

I don't think this would help making the connection stealthier since you would still be able to see packets going though the network.

Answer 6

I thought about this for a couple days, and I think the answer may actually be yes, but in an odd way.

So as a lot of the other answers have pointed out, TCP says port numbers are 16 bits. That 16 1s and 0s. This has a limit of 65535 repeatable ports. For the rest of the example were going to use 4 bits because I am lazy.

So with 4 bits I can represent 15 ports.

Your theatrical backdoor would have to rely on how it handled malformed TCP packets. So (remember 4 bits instead of 16). Lets send some traffic on port 17.

The header would be malformed as 10001. Your TCP stack could state that if you get a malformed header, then go down a different logic path, attaching data to the port of the "right most" four bits. In this case port 1 or 0001. The real trick is that TCP just uses bit count. It's not like xml where there is a [port]10001[/port]. So you would need some way to detect your port header overflow. SYN is right next to port so you could do, a SYN of exactly "1073741823" means your destination port is larger by one.

This different logic path could then stay active for the entire time the connection is active on port 1.

In this way it you could have a TCP backdoor around somewhere that accepted malformed packets and did something special with them. The real problem is that nothing but your special TCP stack could understand them. Routers, smart switches, even in theory some NIC cards would drop the packet, because it is malformed. There would be almost no way to tell if a packet would make it to it's destination with that malformed header.

But, if you connected two devices with the wonky TCP stack to a "dumb" switch or hub. In theory, you could get this to work, however this would not be in the TCP spec.

Answer 7

Everyone explained it in terms of TCP/IP packet: the port field is only 16bits long.

But how about the Linux kernel source code and how it handle the port? Everywhere in linux kernel, for TCP/IP port it is always cast as "short", or 16 bits. And when it is compiled into x86 assembly, the 16bit version of the instructions are used for handling the 16bit data.

And if you are wondering about IPv6, then it is the same os IPv4 - everything about TCP and UDP.

https://stackoverflow.com/questions/186829/how-do-ports-work-with-ipv6

But of course you could setup a weird communication like using TWO server for communcation - each one having individual 16-bit ports and so when you combine them you have a virtual 32-bit port. But the whole world only you will know how to talk to the two server - eg, splitting the data in half and dividing it between the two server, to be reconstructed back again at the client side.

It really seemed like longer than 16bits is almost impossible.

Answer 8

Source: https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TCPIPREPETITION

This truly extensive document clearly indicates how bits are assigned on the internet over TCP. It show the source and destination ports next to each other.

So you made a 32 bit source port? NOPE as soon as it touch the internet bytes 3 & 4 (the lower order) of your source port will be treated at the destination.

The destination port with wipe out the sequence number, and everything will be push further down the line.

Now since the sequence number has been smashed the destination won't be expecting that sequence number, and it will drop it like it was a spoofed packet.

Even if it made it past this point the acknowledge number will be smashed by the sequence number and since that number is now invalid, as far as the internet is concern, it will never be acknowledged.

Answer 9

Yes, since you specified that you can modify the OS, but with the major caveat that only modified devices would see it as being at a non-standard port number.

Most current implementations store the port number in a 16-bit field, so all possible combinations of bits are mapped to integers from 0 to 65,535. These implementations simply can't recognize any other port number because no combination of bits would map to it.

But, if you really wanted a particular client to recognize traffic as though it were at a different port number, you could rewrite how that client interprets packets at the lower level. Instead of just using the 16-bit port number, you could write the OS to recognize modifications to it based on the data contained in the Options or Message sections of the packet. The system could then could then operate as though there were a wider range of possible port numbers.

This trick would only function on devices that have their packet-interpretation algorithms rewritten. External devices could still forward these packets without being compromised, but they would view the packets as being on a standard port number.