Sinisterly
Tutorial PyDoSing extended 3 - Upgrading your DoS tool METHODS - Printable Version

+- Sinisterly (https://sinister.li)
+-- Forum: Coding (https://sinister.li/Forum-Coding)
+--- Forum: Python (https://sinister.li/Forum-Python)
+--- Thread: Tutorial PyDoSing extended 3 - Upgrading your DoS tool METHODS (/Thread-Tutorial-PyDoSing-extended-3-Upgrading-your-DoS-tool-METHODS)

PyDoSing extended 3 - Upgrading your DoS tool METHODS - 3SidedSquare - 05-02-2014

These tutorials require no order, you may do them in any order you like
Previous - https://www.sinister.ly/Thread-Tutorial-PyDoSing-extended-2-Upgrading-your-python-DOS-tool-SPOOFING
First - https://www.sinister.ly/Thread-PyDoSing-101-Your-Guide-to-Making-a-Python-DoS-Tool

Attacks
If you've gone through the other two tutorials, we've been using a DoS method called "Flooding", basically sending tons of data to a target, trying to not let anyone else send data. In this tutorial, we'll be going over a few ways to make your DoS tool more powerful by changing the data you send to the target. I'll be going over 3 categories of attacks that I think most other categories can fit into.

Resource attacks - somehow ties up resources, causing the server to not work or be so slow it's unusable.

Amplification - Using other services to send more data to the target than what your computer alone can send.

Buffer Overflows - (Usually) causes the system to crash. While this can take down a server, it usually isn't associated with DoS'ing.

This tutorial can get very wall-of-text-ey at some points, I recommend takeing a short break after each section in order to prevent your head from breaking out of your skull.
Resource attacks
The classic example of a resource DoS is a piece of software written by "RSnake" called Slowloris. To understand the attack, we have to talk a little bit about web servers. A website is really just a piece of software that runs on a computer, and waits for other computers to talk to it. Part of the software makes sure that more that one person can be requesting web pages at a time, when a computer is doing multiple things all at once, we call it concurrency. Some servers only allow a certain number of "threads" or things it can do at one time. The goal in a Slowloris attack is to hit that limit, so the server drops anyone else who tries to connect.

To create the attack, you need to know what the server is expecting, and how long the 'timeout' is, so it doesn't error out or drop your connection. For example, a web server expects a HTTP request, which looks like
Code:
GET /index.html HTTP/1.1 Host: www.example.com
An http request times out after 4 seconds, so you need to send a little more data before then to keep the connection "alive". To preform this attack, I'm going to keep track of where I am in sending the GET request, and sleep the thread for 3 seconds each time I send another byte.
Code:
##s is a socket ##import time REQUEST = b"""GET /index.html HTTP/1.1 Host: www.example.com""" track = 1 while(track < len(REQUEST): s.send(REQUEST[track-1:track] time.sleep(3)
Using the code with some form of parallelism, see this tutorial, you can use up the "thread pool" and stop the server from allowing outside connections.

Amplification
To preform an amplified DoS attack, you need to find one or more services that send out more data than they take in. You then spoof the source IP for the attack, to make it look like it came from the victim; so that the response traffic gets sent there. The best way to find services to use in an amplification attack is to look at the RFC for the service.

For the purpose of this tutorial, we're going to find an amplification using DNS servers. You can find the related RFCs here and here. For the sake of your sanity, I'll help you go through these, at some point you want to be able to read and understand an RFC on your own, but today is not that day (shit's hard, yo). Starting with the first link (RFC 1034) scroll down to page 11 - 12, you'll see a list of information that all "Resource Records" (RR's) have. Think of this as a menu of all the things you can pick from in your DNS request. In the second link, scroll down to page 24 - 25, which shows a table. If you're doing these in order, it should look familiar to the tables you saw in my previous tutorial. If not, don't worry.
Copy/paste/paraphrasing from the RFC
Code:
A DNS request header 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
As you go through each field, remember that your goal is to MAXIMIZE the response size. The bigger the response, the bigger the amplification.
  • ID - an ID for the request, used by the server to match up clients to request, since we're spoofing anyway, you can give this a random number.
  • QR - 0 for request, 1 for response. Since all we're doing is sending requests, this should always be 0
  • Opcode -
    1. 0 - Standard query (you promise to give a domain name and expect the RR)
    2. 1 - Inverse query (instead of giving a domain name and expecting the RR, you promise to give an ip and expect the domain name, or names.)
    3. 2 - Server status request (Used by administrators to find the zones this server is used for)
  • AA - 1 if the DNS server is used for the ip in question, 0 otherwise. I assume you don't know where your target is, so it's a pretty safe bet to set this to 0
  • TC - 1 if the message was truncated (cut off) because of some limit on length. Since this doesn't affect response length, set this to 0.
  • RD - 1 if you want to pursue the RR recursively, since this DOES have an effect on response size, we always want to set this to 1. As a side not, recursive search is OPTIONAL for an DNS server. Even if you set it to 1, it might not search recursively. No harm in trying though.
  • RA - This is set in the response, and tells you if the DNS server supports recursion.
  • Z - Not yet implemented, set to 0.
  • Rcode - Used in response to tell you if something went wrong. It might be good to check that this works without a spoofed address, but once you start spoofing the IP and TCP headers as your victim's you don't even get the request anyway. Set to 0 for the request.
  • QDCount - Number of domains we're asking RR's for
  • ANCount - Number of RR's we're getting (this is used in the response, set it to 0 for the request)
  • NSCount - Number of RR's the server has, used in the response
  • ARCount - Number of RR's in the "Additional records" section, used in the response
Whew, that took a while, but we're not done yet, that was just the header. We still need a question.
Again, copy/paste/paraphrasing from the RFC:
Code:
Question section of the response 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  • QName - Section of names to be requested, made of "labels". One label is created by: 1 byte, specifying the length of the label, bytes specifying the label, then a null byte. This section does not need to be padded.
  • QType - Two bytes containing one of the RR codes. Remember that first RFC you opened so long ago? Go to it now. The Type describes what you can use for the QType field. From what I can find, looks like A will generate a good bit of data
  • QClass - IN for internet CH for Chaos protocol. You can read more about Chaosnet here. While it sounds neat, IN is the one you want.
That wraps up the DNS request, there are two more parts to the request, but since they're only set in the response, I'm going to leave them at 0. Finally, let's write some code. Since I want you to go through the other tutorials as well, i'll only be writing the code to create the DNS request. Take a look at the original tutorial to send it over the network.
Code:
from struct import pack DOMAINS={"www.google.com","www.yahoo.com"} #More domains = bigger response dnsheader = pack('!HIIHHHH', 0, 137, #10001001 0, #00000000 len(DOMAINS), #Number of domains 0, #\ 0, # }Stuff set in the response 0) #/ dnsquestion = pack('!') for name in DOMAINS: dnsquestion += bytes([len(name)]) for letter in name: dnsquestion += pack('!c',bytes(letter,'UTF-8')) dnsquestion += b'\00' dnsquestion += b'\x01\x02' dnspacket = dnsheader + dnsquestion + pack('HHH', 0, 0, 0)


Buffer Overflows
A buffer overflow is caused when a programmer doesn't put in certain safe checks. Buffer overflows are not usually associated with DoS attacks, but I think that if I didn't put this in here, someone would ask why I didn't include the classic example of a buffer overflow, the Ping of Death. Ping of Death was a specially created ping request, that would never end. The programmers of various servers, firewalls, routers etc. didn't consider that ping packet could be larger than the maximum length of a TCP/UDP packet, and it certainly wan't supposed to be. However, a malicious attacker could send a large ping packet, and the target services would continue putting data into a buffer until the system crashed. To understand this attack a little better, you need to understand memory.

When a request or response is sent through a network, it (usually) is all read into memory somewhere at some point. If I expect a packet to contain up to 65536 bytes, then I need a 65536 area of memory to potentially read the whole packet into. Memory beyond the start+65536 point is called "unallocated" and can be used by any other program to store information, including critical system data. The ping of death worked by continuously sending data to the target until it went past the start+65536 point, and kept going until it overwrote a critical address the system was using, causing a crash.

The ping of death was a very famous example of a buffer overflow because it could happen over a network, more commonly buffer overflows can happen when data is being read in from files, and there are no checks to make sure the file is as long as it says it is. If you want to find a buffer overflow yourself, consider looking at recently-published software written in low-level languages that process a file somehow. Chances are you can have it read in a mal-formed file to either cause the software to crash, or, more exciting, inject arbitrary code into memory. A good starting point for more about buffer overflows:
Spoiler:



Comments, criticisms, cardboard, other words that begin with c below.

This is the last tutorial in the series of 3, unless I or someone decides to write more.

RE: PyDoSing extended 3 - Upgrading your DoS tool METHODS - Adorapuff - 05-02-2014

Buffer Overflows are a beautiful thing. They are hard to find as you must be able to write into an app or system DLL with enough space to store shellcode.

RE: PyDoSing extended 3 - Upgrading your DoS tool METHODS - 3SidedSquare - 05-02-2014

(05-02-2014, 12:45 AM)Adorapuff Wrote: Buffer Overflows are a beautiful thing. They are hard to find as you must be able to write into an app or system DLL with enough space to store shellcode.

No joke, I would have loved to include an example of a buffer overflow, but truth is I've never spent the time to find one.