Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.
Have you ever wondered what all the unsolicited TCP SYN/ACK or RST packets to destination ports 1024 and 3072 are? Go watch those ports for awhile if you’ve just not noticed you’re getting them (it is not constant, but I predict you will see some if you keep an eye out). For nearly 10 years many of my colleagues and I puzzled over them too. It was in August of 2000 when I first noticed the activity and sent off a report about it to the source network. They were nice enough to respond and told me their service had been attacked, indicating they were not purposely originating any malicious traffic towards the network I had been monitoring. In other words, I was reporting traffic that was nothing more than backscatter.
If you keep a careful watch over your network you may have undoubtedly seen what may at first look like TCP scans to those ports, often with the source port of a well known service such as IRC and a source address that maps back to a well known IRC server. For years, I occassionally watched as others would occasionally mention a situation that fit this very pattern. It was 2009 when I realized someone would ask about these signature packets once or twice a year. Yet, I never saw a satisfactory answer as to their ultimate origin. Then it came up internally at Team Cymru when our NOC noticed many packets with this pattern associated with some address space I was using for another project. I was asked about it and noted that this traffic pattern has been seen periodically for many years, but I didn’t have a more specific answer than “backscatter”. Knowing that there must be something specific that caused this particular pattern of packets, but not knowing what that was really bugged me. I asked on the Freenode IRC #dragon channel if anyone knew what tool was responsible. As a guess, jlc3 suggested perhaps a variant of an old DDoS tool named juno was responsible, but then he quickly recanted that suggestion after not seeing any reference to 3072 in its C source. juno is a relatively simple TCP SYN flooder. It spoofs the source address so that any SYN/ACK or RST response from the target will be reflected to random destinations. I looked at the source code anyway and noticed the following line:
syn->sport = htons(1024 + (random() & 2048));
Eureka! This line was apparently originally intended to randomize the source port value, but in fact, rather than randomize the source port value to any 16-bit value, or perhaps even some more reasonably-looking set, it will only set the source port to a value of either 1024 or 3072 (in decimal). It will choose one randomly, but out of all possible source ports, this is a very small set to choose from and certainly not very random in the grand scheme of things.
Working from inside out beginning on the right side of the statement, this algorithm says to take a random number using random(), then AND it, using the & operator, with the static decimal value 2048. The random() function will generate a random long integer value. The AND operation will compare the corresponding bits of the random long integer value with the static integer value of 2048. 2048 written in binary, ones and zeros, is 100000000000. A bitwise AND operation will set the result to 1 only if both bits being compared are 1, otherwise the result is 0. When you AND any other binary number to an integer value of 2048, the result, as an integer, will only ever be 0 or 2048 since only the 12th bit from the right of the integer value 2048 is a 1. The algorithm takes that ANDed result then adds it to the static integer value of 1024. The resultant sum will only ever be an integer value of 1024 or 3072. Quite simply, the simple addition operation will be either 1024 + 0 or 1024 + 2048, giving a sum or source port of either 1024 or 3072.
The original and still surprisingly widely used juno code therefore generates packets where the source port is only ever those two values, matching the fingerprint we have been seeing for years. Much to my chagrin, only after the relationship between the source code of the juno attack tool and years of bewilderment did I happen to stumble upon a post at Web Hosting Talk from 2001 where the the relationship was already known. D’oh! Oh well. With any luck this blog post is easily and quickly found in a net search for those looking for an answer to a similar question many of us had for years.
Finally, I should note, not long after I first reported this finding to others in a different forum, and still unaware of the Web Hosting Talk post, Conor McGrath, who I first saw inquire publicly about this pattern, was happy and relieved to have a definitive answer, but he did leave me with one humbling thought, “One annoying mystery down, millions to go!”. Indeed. :/