Last week, Cyberscoop reported that someone was launching a scan of the entire internet using packets spoofed with a source address of major American banks. That event is interesting in its own right, and follows an occasional pattern by which attackers occasionally try to manipulate the automation our industry uses to protect against attackers.

This event seems to be related to a squabble between a security researcher and Spamhaus, whereby Spamhaus sends abuse complaints for scanning events, leading to servers being suspended. While the drama is an interesting side story, that’s not the point of this article. Someone decided to take the drama to the next level by launching spoofed scans of SYN() and FIN() packets.

Generally, spoofing source addresses in UDP traffic is easy. If you control the network interface, you can send any traffic you want. While network providers should implement BCP 38 (i.e. to not allow any traffic leave their network unless the source is an internal IP address), in practice many do not. What this means is that its trivial to generate fake UDP traffic appearing as anyone you want. This problem is essentially the entire crux of the Distributed Denial of Service problem. It’s why honeypots also generally don’t end up as created threat feeds with UDP traffic; you can’t really be sure if you are blocking the attacker.

What happened here is that someone sent spoofed TCP packets, but made no attempt to complete the three-way-handshake. Normally, this isn’t done because the response to an attacker gets sent “some place else.” In this case, that didn’t matter, someone was trying to make a point and poison Spamhaus (and other’s) data.

One of our feed providers generated its threat feeds by anyone that ever sends a packet to one of the honeypots, whether a handshake is complete or not. This led to some false positives our customers experienced, which we quickly rectified, in part, by removing that source from our primary policies and implementing additional whitelisting. (That was already in progress on a much quicker timescale)

 

The key point here is that automation is extremely important in how we scale to address the sheer number of threats. However, it is important that such data sources automate indicators in a sound way. Attackers can, and do, try to manipulate that automation. The most dangerous thing in computer security is accepting and processing untrusted inputs. Without our automation, we are overtly processing malicious individuals’ inputs.

The same type of attack has been observed from time to time in DNS. We know malicious domains, but the attacker is in complete control over their DNS and can resolve their infrastructure to anywhere they want.

Addressing this problem is complicated and multipronged. It involves whitelisting critical infrastructure, strong post-validation of indicators, and to avoid those situations where the attacker can generate fake input that then gets put into feeds and security policy.

 

Update: 

The key takeaways from this incident is depending on your policy preferences, there are perfectly legitimate reasons to block scanners from hitting your network. We have a target that identifies and blocks Shodan because customers requested it. This traffic is often looking for vulnerabilities.

However, if you are going to block scanning traffic, you need to be sure the IP addresses you are blocking are the actual source of the scan, which you can’t do when it is just a SYN() or FIN() scan. While you could whitelist to prevent egregious false positives, there is no way to create a globally representative whitelist and your systems can easily be manipulated into creating collateral damage.

The short version is, make sure to block the attackers not the digital equivalent of kids painting graffiti in an alley.

 

While these attacks are obscure and infrequent, the growing reliance on automation means we’ll see more of these in the future.

To learn more about how ThreatSTOP protects and addresses these vital security issues, request a demo or sign up for a free 14-day trial today.

 Learn More

 

If you are already a ThreatSTOP customer, make sure to put into your User Defined Lists (UDL) whitelist entries for the critical infrastructure in your environment to ensure that your business operations are not disrupted by such attacks.