Posts

Showing posts from November, 2020

Be careful when using websockets!

I was playing skribbl.io with a couple of my friends the other day, and I decided to download this Chrome extension called AutoDraw for skribbl.io . Basically, what it would do is you drag and drop in an image, and then it would automatically draw your super awesome image onto skribbl.io. I was having a lot of fun playing around with this extension, so I decided to check out what was going on under the hood.  It turns out that skribbl.io actually opens up a websocket connection from your browser to their server (mine was probably located somewhere probably in France (the IP belonged to OVH and the ping was 18ms from both London and Amsterdam) and it was sending my mouse movements every 50ms to the server in 195 byte messages. For those keeping count at home, this is around 0.0312 Mbps that I have to pay. Now, my friends in the game were also receiving these 0.0312 Mbps from the server to their browsers, free of charge.  If we had max-ed out the room to the size limit of 12 pla...

The Internet version of an old prank

Back in the 19th century in London, a prankster named Theodore Hook "DDoS'ed" a large part of London in what became known as the Berners Street hoax. Hook played a prank on the residents of 54 Berners Street by sending out letters requesting various random people to all arrive at 54 Berners Street on the exact same day at around the exact same time. Apparently first to arrive were chimney sweeps, followed by people delivering coal, and it eventually culminated to doctors, dignitaries, and delivery men carrying pianos and organs all arriving at around the same time to the same house. This brought traffic to a halt in a large part of London, effectively DDoS-ing the city. In the Internet age, Hook's Berners Street hoax idea has taken a new identity in the form of a DDoS attack called the Distributive Reflective Denial of Service (DRDoS). The idea is simple: Sometimes when you send a packet requesting a response to a server, it will respond with a bunch of packets back t...

Play-by-play of the Mirai botnet source code - Part 2 (scanner.c)

Image
Continuing on with our read-through of the Mirai botnet source code, let's take a look at the lines that come after the lines that we covered last time. These lines of code are in charge of more setup that includes setting up the socket, setting up some of the IP and TCP headers, and setting up the array of passwords that the bot will try when attempting to brute force a telnet connection. // (A) // Set up raw socket scanning and payload if ((rsck = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1) { #ifdef DEBUG printf("[scanner] Failed to initialize raw socket, cannot scan\n"); #endif exit(0); } // (B) fcntl(rsck, F_SETFL, O_NONBLOCK | fcntl(rsck, F_GETFL, 0)); i = 1; if (setsockopt(rsck, IPPROTO_IP, IP_HDRINCL, &i, sizeof (i)) != 0) { #ifdef DEBUG printf("[scanner] Failed to set IP_HDRINCL, cannot scan\n"); #endif close(rsck); exit(0); } // (C) do { sou...

A Play-by-play of the Mirai botnet source code - Part 1 (scanner.c)

Today I've decided to start learning something very new and unfamiliar to me, as someone who mostly works with very high-level languages like Python and Kotlin, and attempt to understand the source code behind the Mirai botnet that managed to control over 380,000 IoT devices at one point in its life. I'll likely get a lot of things wrong the first time around, and this may take quite a few blog posts to complete, but my goal is to document everything I figure out, so that in the future, someone else in a similar position will be able to use this blog as a resource to understand the C and Go that ran this ground-breaking botnet. To begin, I'll start by reading  scanner.c , which is the code that is in charge of the scanning for and infecting new IoT devices. I'll be taking my time with it, so this might take a few blog posts. scanner.c  has most of its logic in a function called  scanner_init , which is triggered either from  main.c  (which seems like how it is t...

You can control individual packets using WinDivert!

Image
WinDivert is one of the most interesting packages I've recently come across. What WinDivert allows you to do is apply a filter to grab some subset of packets that pass through your Windows computer, and then apply some logic to the packet to maybe modify, and then drop or re-inject the packet. Here's a great diagram from this website that sums it up: Using PyDivert , a WinDivert Python binding, we can specify the PROGRAM portion in the above diagram, which means that we can now capture whatever packets we want, change them however we want, and then either drop them or re-inject them to be sent out whenever we want. The big sell here is that WinDivert allows you to play with packets on Windows without writing code that modifies the core operating system components that run in the kernel! The drawback is of course speed and efficiency, but for a lot of blog-post-worthy applications, we don't need that much speed and efficiency. Stay tuned for more stuff if this piqued your ...