> So, there's a Chinese botnet package known as "Destroyer" (破坏者). It, ironically, can itself be destroyed, thanks to a stack buffer overflow. I wasn't able to get full RCE, but a jump to "call ExitProcess" should be enough, no? It can be triggered directly after "start DDoS", for even more lulz.
> The C2 for this shitty chinese skiddie ddos-botnet has a stack buffer overflow in the parsing of packet opcode 3. This opcode is used for sending ddos-stats, so it only works when a packet with opcode 6 (start-ddos) is sent to us.
> Unfortunately, two addresses are written to before returning; these addresses get clobbered, and the C2 binary is compiled with an ancient compiler (VC++6 lol). No null bytes, so we can only overwrite two addressses, one of which has to be the return address... We can get eip control via SEH, but the full packet buffer is too far away on the stack for us to be able to jump to a ROP chain :(
> So the best we can do here is return to "call ExitProcess", at least there the bots are neutered enough to be absolutely useless... (there's additional functionality in the bot, but it seems the C2 that i have has no UI to send those packets lol)
> So, exploitation: (1) connect to C2. (2) send initial (system info) packet, this includes OS info string (we provide the string sent for "unknown OS" here), and CPU info (number of CPUs + CPU speed), we provide the specs of the highest-range Ryzen Threadripper here, because we can. (3) wait for packet 6 (start ddos) to be sent to us. (4) send our evil packet 3. (5) ??? (6) C2 killed :)
I like the fact that malware authors also seem to have trouble setting up a (secure) software development lifecycle. On the other hand if they were to threat model it, expoiting weaknesses in the agent does not cross a trust boundery so why bother. Imagine this would be different for their command and control infrastructure.
I’ve been trying to gain an understanding of threat modeling and one thing I’m struggling with is the definition of trust boundary - none of the descriptions I’ve read really clicked for me. Could you describe what it means?
Minus the lulz, what is the point of this? It seems there's some possibility of remotely disabling malware... and then some more possibility of malicious piggy backing on already installed malware.
It's an interesting point that malware is typically poorly developed, but not sure what the point of this research is.
Wait how? It's quite contrasty, plenty for comfortable readability, more so than many other sites. Even without my glasses (strong astigmatism and near sightedness), this is not a bad site.
The font differs, as usual, significantly between platforms and browsers though. Is it possible that you have poor black levels and maybe an overly blurred font rendition?
Astigmatism could also contribute here, as it leads to lines in certain orientations (e.g. vertical) being harder to distinguish than others—this can severely limit font legibility.
[+] [-] segfaultbuserr|5 years ago|reply
https://mastodon.social/@slipstream/99116564964787956
> So, there's a Chinese botnet package known as "Destroyer" (破坏者). It, ironically, can itself be destroyed, thanks to a stack buffer overflow. I wasn't able to get full RCE, but a jump to "call ExitProcess" should be enough, no? It can be triggered directly after "start DDoS", for even more lulz.
> Here's the exploit: https://gist.github.com/Wack0/d0aa7f56d5d044fb918056207d2149...
> The C2 for this shitty chinese skiddie ddos-botnet has a stack buffer overflow in the parsing of packet opcode 3. This opcode is used for sending ddos-stats, so it only works when a packet with opcode 6 (start-ddos) is sent to us.
> Unfortunately, two addresses are written to before returning; these addresses get clobbered, and the C2 binary is compiled with an ancient compiler (VC++6 lol). No null bytes, so we can only overwrite two addressses, one of which has to be the return address... We can get eip control via SEH, but the full packet buffer is too far away on the stack for us to be able to jump to a ROP chain :(
> So the best we can do here is return to "call ExitProcess", at least there the bots are neutered enough to be absolutely useless... (there's additional functionality in the bot, but it seems the C2 that i have has no UI to send those packets lol)
> So, exploitation: (1) connect to C2. (2) send initial (system info) packet, this includes OS info string (we provide the string sent for "unknown OS" here), and CPU info (number of CPUs + CPU speed), we provide the specs of the highest-range Ryzen Threadripper here, because we can. (3) wait for packet 6 (start ddos) to be sent to us. (4) send our evil packet 3. (5) ??? (6) C2 killed :)
[+] [-] __jf__|5 years ago|reply
[+] [-] magicconch|5 years ago|reply
[+] [-] eugenekolo|5 years ago|reply
It's an interesting point that malware is typically poorly developed, but not sure what the point of this research is.
[+] [-] spzb|5 years ago|reply
[+] [-] arghwhat|5 years ago|reply
The font differs, as usual, significantly between platforms and browsers though. Is it possible that you have poor black levels and maybe an overly blurred font rendition?
Astigmatism could also contribute here, as it leads to lines in certain orientations (e.g. vertical) being harder to distinguish than others—this can severely limit font legibility.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] chrisweekly|5 years ago|reply
[+] [-] tsar_nikolai|5 years ago|reply