Common Booter Source Exploit 03-28-2014, 06:50 PM
#1
EDIT August 30: Wow, I was so tired when I wrote this, I gave the wrong URLencoded character. We want an &, not a '.
Fuck it, we're not doing anything with this... go wild.
OK, so I'm in a hurry to write this. I'll explain it better later today.
There's a pretty interesting bug in most booter sources that allows someone to gain root (yes, root) access to the backend attack servers.
These booters send a command to their servers via SSH or HTTP API, and the frontend does very little filtering on them, especially for layer7 attacks.
Code will be here later today
Anyway, the bug lies in the fact that there's no actual escaping of shell metacharacters. It just checks if your input looks like a valid URL, and if it is, executes it without a second thought.
We can construct an evil payload that looks like a URL like so:
http://0day.xxx/lol.php?rootingyou=yes%26commands$(IFS)gohere
The %26 gets url-decoded and becomes an & when sent to the backend attack server. The $(IFS) is used here because %20, for some reason, breaks the backend and so do raw spaces (raw spaces make it an invalid URL), so we have to use bash's Internal Field Separator.
I apologize for my brevity. I'll improve on this at some point.
Fuck it, we're not doing anything with this... go wild.
OK, so I'm in a hurry to write this. I'll explain it better later today.
There's a pretty interesting bug in most booter sources that allows someone to gain root (yes, root) access to the backend attack servers.
These booters send a command to their servers via SSH or HTTP API, and the frontend does very little filtering on them, especially for layer7 attacks.
Code will be here later today
PHP Code:
if(filter_var($host, FILTER_VALIDATE_URL)){
$insertLogSQL -> execute(array(':user' => $_SESSION['username'], ':ip' => $host, ':port' => $port, ':time' => $time, ':method' => $method));
echo '<div class="nNote nSuccess hideit"><p><strong>SUCCESS: </strong>Attack has been sent to '.$host.':'.$port.' for '.$time.' seconds using '.$method.'</p></div>';
}
Anyway, the bug lies in the fact that there's no actual escaping of shell metacharacters. It just checks if your input looks like a valid URL, and if it is, executes it without a second thought.
We can construct an evil payload that looks like a URL like so:
http://0day.xxx/lol.php?rootingyou=yes%26commands$(IFS)gohere
The %26 gets url-decoded and becomes an & when sent to the backend attack server. The $(IFS) is used here because %20, for some reason, breaks the backend and so do raw spaces (raw spaces make it an invalid URL), so we have to use bash's Internal Field Separator.
I apologize for my brevity. I'll improve on this at some point.
PGP
Sign: F202 79C9 76F7 40BB 54EC 494F 5DEF 1D70 14C1 C4CC
Encrypt: A5B3 1B21 55E1 80AF 4C6E DE83 467B 8EFC 3DEE 681C
Auth: CD55 E8A5 1A08 2933 8BA6 BC88 D81F 1943 739A 3C47
Sign: F202 79C9 76F7 40BB 54EC 494F 5DEF 1D70 14C1 C4CC
Encrypt: A5B3 1B21 55E1 80AF 4C6E DE83 467B 8EFC 3DEE 681C
Auth: CD55 E8A5 1A08 2933 8BA6 BC88 D81F 1943 739A 3C47














![[+]](https://sinister.li/images/modern/collapse_collapsed.png)









![[Image: 7ajmN5P.jpg]](https://i.imgur.com/7ajmN5P.jpg)







![[Image: dHJ4Beo.gif]](http://i.imgur.com/dHJ4Beo.gif)







![[Image: CDUAq9d.png]](http://i.imgur.com/CDUAq9d.png)