Microsoft says no known ransomware runs on Windows 10 S, so we tried to hack it | Hacker News Reader

Microsoft says no known ransomware runs on Windows 10 S, so we tried to hack it

zdnet.com

45 pointshelloworld31 comments

"Word was opened with administrative privileges through Windows' Task Manager"

So the whole point of Windows 10 S is that it's so locked down it will only run applications from Microsoft's App Store. (That alone make it useless beyond elementary school level.) Yet it will run Microsoft Word with administrative privileges? Why would you ever want to run Microsoft Word with administrative privileges?

I think it means if you launch Word normally it is not running with administrative privileges.

you have to launch from Task Manager to run Word with administrative privileges. (which researcher claims can also be automated)

Yes, but for a locked down OS version it should be possible to have administrator privileges denied to an application. So the Store could have a flag of which apps might need admin, and only those apps can be run as admin. This would prevent Word from being run as admin, since it certainly shouldn't have that flag.

The point of Task Manager here was that Word was being launched "directly"—the process was being spawned, outside of the framework that cares about concepts like "apps" or their security manifests.

No matter how sandboxed you make your high-level abstraction layer, you can always just remove the sandbox by removing the abstraction layer. Docker (for example) won't protect you if you cd inside your Docker image and run a binary from it directly on the host.

The only way to really "leak-proof" the abstraction here would be to build "apps" as a concept into the OS kernel itself, such that the exec/spawn syscall itself is responsible for doing the sandboxing and the OS's executable-binary format itself is responsible for containing the privilege manifest. So far, I haven't seen any OS interested in taking steps in that direction, though (which is odd, given that a similar conceit—code-signature verification—was embedded into said syscall in every OS quite recently.)

Why should Task Manager, on such a locked-down machine, allow you to run arbitrary applications?

As far as I understand the setup:

Task manager runs elevated (Admin)

DLL injection allows the attacker to launch a child process (Word) inheriting the task manager privileges. Now you have word running as admin

Maybe the DLL injection API (one of Windows' stranger features) should be disabled for anything running at admin level. Yes, this inhibits debugging. If you want to debug, install a developer build that allows it.

> DLL injection API

DLL "injection"? What API is that?

There are ways in Windows to start a new thread in another process.[1] Most of these involve the OpenProcess function.[2] This gives one process access to the state of another process. Once a handle to another process has been obtained, it can be used for starting a new thread in that process, which can load code into the process's address space.

There are security checks, but they suffer from the usual problem of assuming that the security entity is the user, not the application. This is mostly a debug facility, but it has other misuses.

[1] https://www.codeproject.com/Articles/4610/Three-Ways-to-Inje... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

I know what DLL injection is. I was challenging the "DLL injection API" expression, because there's no such thing as an API that allows you to arbitrarily inject a DLL into a target process. Put it this way: InjectDllIntoProcessEx() does not exist.

> (one of Windows' stranger features)

It is not a feature by any means. It's hackery and, by the time you've got a handle to the process with PROCESS_CREATE_THREAD (you don't even need PROCESS_VM_WRITE), it's game over. Use ACLs to disallow getting a handle with the necessary permissions if you want to avoid code injection.

This post, however, makes no sense. Running an infected Word document with admin permissions is, like somebody else said on this thread, running 'rm -rf /' as root.

I wish:

(1) Microsoft would actually document clearly how its security works.

(2) Solve these security problems.

E.g., decades ago we had time sharing systems where rarely or never did the work of one user cause security problems for another user.

One partial approach is to run a program in a particular file system directory and arrange that the program the program has very limited access to anything outside that directory and possibly limited access to what is in that directory.

Then ransom ware? Okay, such a program might make a mess but only within some one directory. In that case, junk the program and delete the directory.

Or a program gets its own access control list with its own capabilities for whatever resources are or might be on the computer.

A clear goal is for Windows to be able to run any software, including malicious software, safely. Why not?

What you describe is roughly how the AppContainer used by modern apps on Windows works. Windows RT could only install apps based on this system.

The problem is that Windows RT was perceived to have failed for lack of compability. So they introduced Centennial which brings back compatibility with some legacy Windows apps, but also brings back most of the same problems that drove them to want to move away from legacy Windows apps in the first place

Yes, when heard about containers, with no details, and I still have yet to read any details, on either containers or how Windows security really works, then just from the word containers I guessed something like what I wrote and you confirmed.

Sure, I have some legacy Windows apps. I'd be glad to log in with Administrator capabilities and, then, put those safe as a stuffed Teddy bear apps on a list of permitted apps.

I'm sure there are a lot of details.

One solution is just to be running a time sharing system with lots of users, each with rigidly delineated capabilities. Then do all Web browsing as just such a user. If the Web browsing lets in ransom ware, fine with me: The damage will be only for that user, and fine with me: I just delete that user.

And there are virtual machine solutions.

IMHO Microsoft should have gotten a good solution long ago.

>decades ago we had time sharing systems where rarely or never did the work of one user cause security problems for another user.

How much of that was due to people not trying to cause those problems, though?

Well, they wrote and ran a lot of software with outrageous bugs, especially writing out of array bounds.

But likely a biggie difference is that the attack surface was smaller.

Also it may be that some of what Microsoft is still struggling with is being able still to have Windows run old software that thinks it's just fine to read files from nearly anywhere, write lots of files it should have no business writing, run other programs, etc.

E.g., on Windows, I can download and install software, e.g., a new version of Firefox. That writes to my boot drive. What the heck security door did that software pass through?

I'd like to know the details of Windows security, but so far I've never seen any good descriptions or documentation.

I'm interested in Windows security because Windows is the source of the computing for my startup.

Otherwise, and in general, I hope that Microsoft gets the security problems fixed.

So, they didn't install and attempt to run any ransomware. I suspect they could have, but if the claim is that it "won't run," it seems you need to actually go ahead and try to run it.

Not really. Most Proof of Concepts for Windows exploits merely launch something like calculator.exe as a placeholder, just to prove that malicious code could have run here. I think it's sufficient that if they could prove they achieved privileged code execution, it is safe to assume that ransomware could have run at that point unabated.

Running calculator.exe isn't sufficient enough for the claims that are made in this article, since it's already in the 'trusted' domain of the OS.

If they could get 'myPersonallyDevelopedExecutable.exe' to run, then the article would have a point, but the researcher stopped short of trying, so this article ends up being shitty journalism.

[disclaimer, MS employee].

> Hickey created a malicious, macro-based Word document on his own computer that when opened would allow him to carry out a reflective DLL injection attack, allowing him to bypass the app store restrictions by injecting code into an existing, authorized process.

That's enough to show that you could have run ransomware. Unsigned code execution under Word privileges (which presumably has write permissions to user documents) is enough to encrypt user documents.

I think the point is that it's dishonest/irresponsible for Microsoft to advertise 10 S in this way. Even though technically they're not saying you can't get hacked by ransomware--anyone without technical knowledge can reasonably assume that's the case. The article showed that MS didn't really put too much work into adding extra security/mitigation. Just shutting down side loading isn't work proportional to what they advertise.

As an MS employee: Is SYSTEM really restricted by the sandbox as well?

Why? They are already running their own unsigned DLL injected code that can do anything they want. Even if the OS wouldn't allow it to launch an unsigned .exe, any malware can just be shipped in that DLL as easily.

This is an argument against running word as an admin and then explicitly allowing macros to execute, it has little to do with breaking the app-containment, which is the claim made in the article.

Seems Word macros will also run, with the expected results.

https://arstechnica.com/information-technology/2017/06/micro...

imo this isn't so much an Office problem as a general Centennial problem. As long as Centennial apps run with full user privileges, some of them are going to have some mechanism allowing someone to run untrusted code, and I doubt it's feasible to fix this if you also have a goal of allowing a large portion of the legacy apps people want to run, without requiring onerous modifications

> can only run apps from the app store

So basically this is nothing but a control ploy by M$? Even Apple doesn't restrict things like that (on macOS)

They tried: http://www.osnews.com/story/25619/Mac_OS_X_10_8_restricted_t...

Didn't get past the autoplay video with sound on your page. Pah

Oh hey let me be a dumb ass and run untrusted code with Admin and blame it on Microsoft. - "Security researcher"

The whole freaking point of Windows S is that it's not supposed to be possible to do that.

I think it's fair to say there's an implicit assumption that a user, given the right knowledge and intent, could circumvent this protection at which point they're on their own.

Yup, you're already on the wrong side of the water-tight door at that point.

It's not like you can't sudo rm -rf / on unix. Once you pull out your He-Man sword and shout, "I have the power!!!" you need to know what you're doing.

Reply on news.ycombinator.com