[HN Gopher] Malvuln - Malware Vulnerability Research
___________________________________________________________________
Malvuln - Malware Vulnerability Research
Author : tsar_nikolai
Score : 44 points
Date : 2021-01-14 10:41 UTC (12 hours ago)
(HTM) web link (www.malvuln.com)
(TXT) w3m dump (www.malvuln.com)
| [deleted]
| __jf__ wrote:
| 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.
| magicconch wrote:
| 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?
| __jf__ wrote:
| 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.
| segfaultbuserr wrote:
| 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" (Po
| Pi Zhe ). 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 :)
| chrisweekly wrote:
| Mods: typo in title
| tsar_nikolai wrote:
| Oops, fixed
| spzb wrote:
| 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.
| arghwhat wrote:
| 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.
| spzb wrote:
| 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
| SeriousM wrote:
| I love HN for this, thank you for teaching me about
| contrast space in a vuln thread!
| arghwhat wrote:
| 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.
| spzb wrote:
| The 4.5:1 ratio is a minimum not a perfect score.
| arghwhat wrote:
| 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.
| eugenekolo wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-14 23:02 UTC)