https://github.com/team-tritan/sharex-ripper
This tool was designed specifically to prove a flaw in many open source ShareX image hosts.
https://github.com/team-tritan/sharex-ripper
attack post sharex tool
Last synced: 6 months ago
JSON representation
This tool was designed specifically to prove a flaw in many open source ShareX image hosts.
- Host: GitHub
- URL: https://github.com/team-tritan/sharex-ripper
- Owner: Team-Tritan
- Created: 2022-10-25T10:00:23.000Z (almost 3 years ago)
- Default Branch: master
- Last Pushed: 2023-07-11T17:12:05.000Z (about 2 years ago)
- Last Synced: 2025-02-15T12:44:27.978Z (8 months ago)
- Topics: attack, post, sharex, tool
- Language: TypeScript
- Homepage:
- Size: 76.2 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: ReadMe.md
Awesome Lists containing this project
README
# ShareX Attack Tool
This tool was designed specifically to prove a flaw in many open source ShareX image hosts.
[x] figured out a way to null specific unnamed ShareX servers due to reasons that are native to with the way node handles file uploads.
Uploads need to be routed somewhere and typically are held in ram for some time during the upload process until the files are entirely uploaded and ready to be written to the disk. With that being said, this attack tool takes advantage of that by initiating a post for a handful of 1gb files at 1gbps speeds. When the server is fed multiple files of this nature, it stores them all in ram which will effectively cause a drive fault because docker will allow node to continue over-allocating ram.
This codebase was made for informational, educational, and inner-development testing purposes; it does not represent any malice of any kind.
## Instructions
- Install dependencies, preferably using yarn.
- Fill out config file
- Run `npm start` or start from `./src/`.
- Read da console logs, maybe open a network activity window to peep progress.
## Moral of the Story
- Always set upload limits on your web servers to prevent things like this! This ez project took me under 2 hours on a Wednesday morning at like 4am, imagine if someone actually dedicated wanted to exploit your services using a method like this.