My Protected Files is flawed

Learn about Computer Security Leak Testing/Attacks/Vulnerability Research
1

Many of you know how to use My Protected Files to protect against programs opening various devices. For example, you can add \Device\Beep to My Protected Files, and CIS will alert you whenever a program tries to open the Beep device. However, there is a way to work around this protection, bypassing CIS. A test program is attached. Instructions:

  1. Add \Device\Beep (or another device if you want, but it must actually exist) to My Protected Files.
  2. Open a command prompt window.
  3. TestOpenDevice.exe -n Beep (replace Beep with the device you chose, if you did that). Allow the program to run, and an alert will be displayed when TestOpenDevice tries to open \Device\Beep. If you allow the action, TestOpenDevice will report “Success.” and exit. If you deny the action, TestOpenDevice will report “Error: Access is denied” and exit.
  4. TestOpenDevice.exe -rd -n Beep (again, replace Beep with your chosen device). Allow the program to run, and this time you won’t get any alert. TestOpenDevice will use the workaround, and will successfully open the device.

Short technical explanation: open the directory object \Device. When calling NtOpenFile, simply put the handle to \Device in ObjectAttributes.RootDirectory and use “Beep” as the object name. CIS will not detect this.

[attachment deleted by admin]

2

While posting POC tools, can you please do us a favor and write them in C or C++ rather than C#.

Thanks,
Egemen

3

Why? If you can’t run them there must be something wrong with your machine, since everyone else can. It’s also 10x faster for me to code the test programs in C#. If you want more technical detail I’d be happy to give it to you, although in this case I doubt it would be required.

4

//long time since I used C++…
#include
int main() {
while(1) {
std::cout<<“I will not code PoC’s in C#.”;
}
}

(:LGH) EDIT:: don’t get me wrong here… I too have a hard time seeing why C# should be an issue… :stuck_out_tongue: Great work! =)

5

OK, I am getting a little frustrated here. Can any of you confirm that the bypass works?

6

I got this alert when doing it without the -rd thinggy… (attached…)

When I did it with -rd no such alert was presented… (an execution alert was lunched in both scenarios…)

[attachment deleted by admin]

7

wj32,

Me Received these results but for \Device\NdisWanIp :

8

Thanks, so the bug is real. What this means is that if you add a device to My Protected Files, any program can still silently access the device.

9

And as with the last time I found a security hole (NtDuplicateObject on Vista), this thread is going to be completely ignored. Developers, learn to show some respect for the community by at least responding to threads. Maybe I’ll contact Matousec and your score won’t be 100% anymore…

10

Your POC is a valid one. I can confirm it.

In my experience devs usually don’t report back to the community. May be I stuck around too long at the Opera forums that I got to assume this. For me it is common practice to see bug reports being sucked into a black hole. We usually suffer in silence after reporting them.

I hope egemen will report back.

11

Come on…PM him. :stuck_out_tongue:

You have to be annoying you know to get anything done! ;D ;D

12

Which is a sad state of affairs. :frowning:

It doesn’t do much to instill confidence in the users. Not to mention that the product will suffer because users will get frustrated and stop reporting things.

13

I have learned bugs will get fixed, not always as fast as one wishes, as well as that its usually a group of regulars that will report the bugs; the same regulars also tend to make bugs their “pet” bugs… I have had my pet bugs and got over them… :wink: O0

14

This is not a “pet bug”. This is a serious security vulnerability. Imagine if a program could open \Device\PhysicalMemory without the user’s consent and unhook system calls, rendering CIS useless. This is possible due to this bug. I haven’t actually tested this particular scenario, but it’s possible.

15

No it is not a serious vulnerability but it is a bug that can cause problems in the future.

Just a couple of points about this:

1 - You can NOT use this bug to bypass filesystem protection i.e. you can not modify a protected file on the disk
2 - You can NOT use this bug to access the physical memory memory etc.

However, you can use this bug to obtain access to some “non-filesystem” files like \Device\xxx.

The bug is fixed. The fix will be available with the next planned release which is CIS v4 as of today.

Thanks,
Egemen

16

Egemen, thank you for clarifying the nature and extend of the bug.

17

And thanks to wj32 for the find… 8) :-TU

18

Yes, thanks for fixing in record time. :stuck_out_tongue: I would like to ask you how it is not possible to open PhysicalMemory, but I know you’re not going to say. I’ll just assume the bug is only in NtOpenFile, not NtOpenSection…

19

Yes. NtOpenSection has another bug which was similar to this one. It can be possible to access because of another bug though. Anyway, it is, along with NtSetSecurityObject bug, fixed and will be available with the next scheduled release.

20

Cool, thanks a lot! I’m looking forward to CIS 4 :smiley: