Maliciously Verified

My team was recently contacted to dig into an issue with an application. A specific module refused to load while the rest of the app worked fine.



Our level 2 team had dome some preliminary work, so I began looking at their packet captures. Like anybody who has operated behind a firewall, my first question was whether or not our firewall was blocking the traffic.

There was plenty of traffic to the IP address, and a lot of it was being blocked by our firewall, starting around the time the users reported the issue.

The interesting thing was that it was being flagged as malicious. Taking a look at the capture, it seems they were malformed HTTPS packets.

Continuing to dig we narrowed down the destination IP addresses and took a closer look at the traffic.

Now that's interesting. No SYN,ACK, but the server was kind enough to send a RESET,ACK after three attempts? Odd. We decided to do a packet capture on our external firewall interface and saw this.

Now that fits a little better. Our workstation was sending SYN packets with no response.

I looked up the owner of the IP using whois and called them, got redirected to email their support system, and got a call about an hour later. As it turned out they had configured their system to blacklist any IP addresses caught sending malformed SSL packets, and sure enough we had sent them a malformed HTTPS packet a few weeks ago.

Is that a little overzealous? Perhaps. Packets can be malformed for lots of reasons, including (but by no means limited to) an attempt to exploit Heartbleed. I imagine they're blacklisting a large number of IPs and preventing legitimate customers from getting ahold of them.

Perhaps a better response would be to watch for malformed Heartbeat packets, or even Heartbeat packets with the string and buffer size parameters out of sync.

NOTE: I thought about titling this something like, "Heartbleed implications" but I feel I've used that bandwagon enough at this point, plus I like the word play in the chosen title.