Having fun: Fuzzing, MITM, SYN Scan, Handshake scanning, Denial of Service

First I tried just sending random bytes to the service tested. After around 4 million handshake attempts I gave up. After that I created small TLS MITM proxy and logged the existing handshakes. And started to replay those with random modifications. Many of the packets seem to be pretty low level and basically just are like like c-struct data structures in memory. After thinking that for a while, I thought what if I try to change those randomly. My first version of the MITM recording playback fuzzer changed 1-5 bytes per handshake with random values. This usually lead to crash in around 200 handshakes. After that I changed it so, that it only changed one byte randomly. Now it took of course a longer time, around 500 handshakes to crash the server. Then I started to log the handshakes triggering crash. After analyzing around ten logs, I had isolated bytes in the message which can be changed to trigger the crash. The bytes are such that those probably lead to invalid memory allocation, and it also means this could be an exploit making RCE possible. Not just DoS attack.

Wrote and played with a few fuzzing python scripts, I really didn't expect results but I got those faster than I expected. It took me around 15 minutes to find a DoS attack vector which works repeatedly and reliably against database server. Ouch! Next thing I'll do, I'll scan the whole IPv4 for the vulnerable servers, just for fun. After this I've got ready list of vulnerable systems. Which I can crash at will, in no time. I know the normal handshake, which I can log, to know exactly what the system is. And then I just need to make a few modifications to that handshake to crash the system. I'm not disclosing what the exact changes are. But if I got it figured out in this very short time using basic fuzzing, it's not hard for anyone to repeat these steps. After the scan of vulnerable systems, I can figure out how bad this is. I'll start with the default process. First I quick scan the address space with nmap to get list of addresses with the port of interest being open. With that list, I'll rerun the scan with my own tool, which also completes the handshake (without crashing the system) and verifying that the system is vulnerable. -> Then I've got the short list on hand.

Read all nmap documentation to decide best parameters for the scan task. Decided to use Vultr as hosting provider for scanning, because I don't want to use any of my primary hosting providers which I regularly use, in case they'll get upset and ban me from their platform. Yet this is very low impact scan, I'll try to do it as stealthy as possible. It's more or less like the internet background radiation. After this data collection step, I decided to continue to completing the handshake using my own handshaker project and logging the results. After thinking it through, I started the operation with highly limited scope, I did scan IP addresses of the three major Finnish ISPs using IP ranges based on BGP ASN IP address information. That scan was completed in a such short time, I scanned a few major cloud providers as well.

After that initial pre-mapping of open ports using nmap, I cleaned the results of the scan and started second phase, which is actually completing the protocol handshake and collecting detailed server version information and logging it. This also allows me to exclude all of the systems, which do not provide correct handshake. Initially I thought I would use official client, but using my own client allows much me to control the network traffic and scanning process in much more detail. Let's see what the results are.

For the second scan sweep of the pre-screened addresses I slowed the scan down a lot. Now I'm only checking ten hosts per every three seconds. I did find bunch of systems which I know from previous testing would be 100% vulnerable to the DoS attack. Sending just a single message after the initial TCP handshake, would crash the server process. The handshake response also reveals the target systems name and CPU thread count and OS version, which gives you good indication in many cases what the target system might be actually being used for. This seems to take a while, now I'll go sleeping. Let the machines do the work.

During the night the final detailed full hand shake scans were finished. I found nice four digit number of vulnerable systems which were verified using the full handshake. And this was only by scanning Finnish IP address space and two cloud providers.

After this I also decided to scan third cloud service provider and ended up with good results as well. Batch of vulnerable servers was quite quick to figure out using the methods tested with the previous set. Tooling isn't fully automated, but each step produces a file, which can be then automatically processed by next step, without manual modifications. As example, my handshaker reads directly nmap logs.

I also found all kind of interesting bycatch. But I won't be reporting about that, because it would tell too much about the ports and protocols I were scanning for. It would be so nice to talk about, but in the current context I can't. Yet this is of course something which is totally normal for anyone doing wide security scans on the network.

Based on this information, I could easily crash all instances of the specific server application globally from one VPS every minute. Unless they change their IP address, or block traffic, which are things which probably would take quite a while, before they'll figure out what's going on. Just as fun as the good old WinNuke, boom, and your Windows is BSOD again and again. Good old times. I'm also quite sure world is absolutely full of such applications, if anyone would just bother trying the methods I've mentioned above. Yes, I've disclosed the issue to the vulnerability coordination team of the application developer and they've provided a patch. Yet as we know, who bothers to patch systems when those work just fine without patching. Ahem, until they don't. Yet, purpose of this work was to be aware of potential problems and get the issues fixed, not to actually attack the systems. By acknowledging the issue and being aware of the problem, allows configuring IPS to detect and drop attack traffic which would trigger the DoS and service crash.

This was something I have wanted to do for a quite while, but I haven't just been in the right mood. Now I had the right mood and job got done in a few days (as calendar time) actual work time was more like 4 hours.

Just after I finished all this, I got call from Telia, and they were wondering the SYN SCAN traffic from my servers. Oh, it's good that someone is watching. No wonder Finnish networks are so clean in global comparison. Because someone cares. ref: "Botnet tracker reported netscan/attack".

Thank god it's Friday, connection reset by beer.

2020-03-08