←back to thread

Cyber Scarecrow

(www.cyberscarecrow.com)
606 points toby_tw | 1 comments | | HN request time: 0.272s | source
Show context
mdip ◴[] No.40717914[source]
Setting aside the concerns with this specific implementation and thinking more of "the idea" I think the biggest concern is this sort of application causing legitimate software to fail to run[0] and how one would "white-list" an application from seeing these "fake artifacts designed to trick malware."

The problem is "the fake components" would have to be prevented from being detected by legitimate software and the only way I can think to do that would be to execute everything in a sandbox that is capable of: (a) hiding some contained running processes (the fake ones) from the rest of the OS while (b) while allowing the process that "sees the fake stuff" to be seen by everything else "like any old process."

Applying ACLs (and restricting white-listed processes) might work in some cases; might equally just be seen as a permissions problem and result in a nonsensical error (because the developers never imagined someone would change the permissions on an obvious key), or it might be that the "trick" employed is "Adding a Russian Keyboard" which can be very disruptive to the user "if they use more than one input language" or "is one of those places where a program may read from there never expecting to encounter an error."

A lot of this seems like it would require use of containerization -- docker/docker-like -- for Windows apps. I'm familiar with a few offerings here and there, but I've worked with none of them and I run Linux more than Windows these days. So my questions really boil down to:

Where's Windows containerization at? Would it be possible to run an application in a docker or docker-like container with a Windows kernel which can have its environment controlled in a manner that is more transparent to the application running within the container? Is there any other approach which would allow for "non-white-listed applications" to run containerized and "see the Scarecrow artifacts", while allowing the white-listed applications[1] to run outside of the container in a manner that hides some of the processes within the container. Can it do all of that in a manner that would work if the same "check" were repeated immediately after confirming an Elevation dialog[2]? from the white-listed application in a manner that couldn't be defeated by repeating the same "check" after presenting an elevation dialog?

Again, that's assuming "this is a brilliant idea" -- and there's some evidence that as a concept, at least, it would help (ignoring this particular implementation of the idea), but it still suffers from its success, so the extent that it helps/is adopted equates to how long any of these techniques aren't defeated. And just from the sense I get of the complexities required to "implement this in a manner that legitimate won't fail, too", I suspect it will be easier to defeat a tool like this than it will be to protect against its defeat. In other words, the attacker is a healthy young cat chasing a tired old mouse.

[0] Anti-cheat being the most obvious, but those are often indistinguishable from malware. I'd encountered plenty of games/apps in the 90s that refused to run when I ran software to trace aspects of their memory interaction. I had some weird accounting app that somehow figured out when my own code (well, code I mostly borrowed from other implementations) was used for the same purpose.

[1] The assumption being that "a legitimate application which does these kinds of checks" is also likely to refuse to run within a container unless it's impossible to detect the container as reliably as everything else (and vendors are completely tolerant of false positives if the affected customers don't represent enough in terms of profit, or the solution is "don't run that unusual security software when you run ours").

[2] I've seen it enough with Easy Anti-cheat that I just click "Yes" like a drone. There was at least one occasion when it popped up after I had installed some developer tooling but not had a game update come down between launches. Because it was a huge install, it may just have been that the game detectedI have no idea why this happens -- on a few occasions, I had no update applied between loads but had installed other software so it could have been "to fix something that software broke" but it could also have been "to re-evaluate the environment as an administrator because something changed enough on the system to warrant a re-check that it is still compliant with the rules"

replies(1): >>40718789 #
1. wizzwizz4 ◴[] No.40718789[source]
> Where's Windows containerization at?

Doesn't exist. Not even UAC is a reliable security boundary. Likely, it will never exist.

> Is there any other approach which would allow for "non-white-listed applications" to run containerized and "see the Scarecrow artifacts",

Sounds a bit like WoW64. It should be easy enough to replicate this behaviour with a rootkit. However, the software would always be able to peek behind the curtain.

> In other words, the attacker is a healthy young cat chasing a tired old mouse.

I always thought of the attackers as the mice, and anti-malware folk as the cats.