Malvuln – Malware Vulnerability Research | Hacker News Reader

Malvuln – Malware Vulnerability Research

malvuln.com

47 pointstsar_nikolai14 comments

A funny malware exploit I've recently seen was this one...

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 :)

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?

Trust boundaries make most sense when used in a data flow diagram, where for every flow between processes you ask yourself: “what could go wrong here?”

That question deserves additional attention if these flows reach processes controlled by different people, or are running under different privileges. That’s when they cross a trust boundary.

So a db server with local storage: single trust boundary around db and storage. But! But! What about the kernel!?

At this point it becomes important ask to another question: does the current abstraction level of the model help you think better about risk? It depends. Perhaps not if the db is part of a larger infrastructure with a global CDN, loadbalancers, webservers and some in memory caching layer.

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.

What's with the color scheme on that website? I have good eyesight and I'm struggling with the contrast ratio. God help anybody with vision problems.

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.

It's possibly the lighting or the monitor but I don't have a problem with using any other websites in this configuration.

The orange on gray has a 2.5:1 contrast ratio, the main body text (dark gray on gray) is 4.1:1, both of which are below the WCAG 2.1 AA accessibility minimum of 4.5:1

Orange on gray is not great, but that's only the headlines, which are also much larger which takes care of the worst problems.

Based on those numbers it would appear to me that the main text is only slightly below perfect accessibility in the contrast department, so it shouldn't be a problem at all unless you have bigger problems.

The 4.5:1 ratio is a minimum not a perfect score.

The guidelines are for accessibility—minimum/recommended score would presumably be set so that someone with moderate vision disability would not at all be troubled.

That puts it way above what someone with good eyesight should need for comfortable reading.

I am mostly questioning it being hard to read, with good color/font rendering, for someone with good eyesight. Mine is pretty bad, and while ugly, it wasn't hard to read at all.

I love HN for this, thank you for teaching me about contrast space in a vuln thread!

Mods: typo in title

Oops, fixed

Reply on news.ycombinator.com