49 lines
1.8 KiB
Markdown
49 lines
1.8 KiB
Markdown
# rr-dev
|
|
based on observations made by cloudflare in the excellent blog: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
|
|
|
|
no clue if this actually works, but it seems to match the same behavior
|
|
mentioned in the blog's pcap, which seems to no longer be available
|
|
from their blog link.
|
|
|
|
## collecting and analyzing
|
|
1. start http/2 enabled nginx server:
|
|
```
|
|
cd server
|
|
docker compose up -d
|
|
```
|
|
|
|
2. start capturing traffic in wireshark
|
|
|
|
3. run poc script:
|
|
```
|
|
python rr.py
|
|
```
|
|
|
|
4. decode traffic in wireshark using `ssl-keylog.log` as the ssl keyfile
|
|
5. compare against the cloudflare blog notes (unless you have the pcap which seems to be gone now)
|
|
|
|
## notes
|
|
server advertises maximum stream concurrency of 128:
|
|
|
|
|
|
|
|
1000 stream headers are sent split into two packets:
|
|
|
|
|
|
|
|
>Interestingly, the RST_STREAM for stream 1051 doesn't fit in packet 15, so in packet 16 we see the server respond with a 404 response. Then in packet 17 the client does send the RST_STREAM, before moving on to sending the remaining 475 requests.
|
|
|
|
despite exceeding maximum number of advertised streams, the server never sends a RST_FRAME:
|
|
|
|
|
|
|
|
> No server RST_STREAM frames are seen in this trace, indicating that the server did not observe a concurrent stream violation.
|
|
|
|
obviously to weaponize it, it will take some extra effort like implementing concurrency. but don't do
|
|
that shit for any reason other than research. i'm saying this explicitly because
|
|
we've seen examples of "illegal code" before. i do this solely for research, and fun of
|
|
course, because c'mon this shit is so interesting.
|
|
|
|
## greetz
|
|
greetz to psyk0, shifty, and slerig. who needa stop slackin, but i still love em anyway.
|