Well, the title sumarizes my question, but I will elaborate. I have always thought that any process runing with no admin rights shouldn't be able to access the memory space of any other process, and of course shouldnt be able to halt it's execution.
However, with visual studio running under a non-privileged account, I am able to attach to some processes runing under the same account and debug them. Why is this possible? Shouldn't the operative system prevent this?
Thanks in advance and cheers
for access say memory space of any other process we need open process with PROCESS_VM_READ|PROCESS_VM_OPERATION|PROCESS_VM_WRITE .. for this not mandatory need have SE_DEBUG_PRIVILEGE - if process running in same session as debugger, have the same token - usually it security descriptor (DACL) let open it for this debugger. this is absolutely expected. so question here - are we can open process with full access for debugging ? if this "peer" process (running under same user, with same privileges) - why not ?
and from DebugActiveProcess function
The debugger must have appropriate access to the target process, and
it must be able to open the process for PROCESS_ALL_ACCESS.
DebugActiveProcess can fail if the target process is created with a security descriptor that grants the debugger anything less than full
access. If the debugging process has the SE_DEBUG_NAME privilege
granted and enabled, it can debug any process.
and remark from yourself - except protected processes, if only your debugger when called DebugActiveProcess also protected process (with not less level of protection) (yes this is possible debug protected processes also)
Related
I am trying to understand what Image File Executions Options can do and what it's normally used for. I know it is used for debugging purposes but how do I know its used for malicious purposes? Is this registry key used with every executable? If not, is it suspicious?
For example what does \Image File Execution Options\DevOverrideEnable do?
PS: I have looked a these sources already:
https://gooroo.io/GoorooTHINK/Article/17352/Image-File-Execution-Options-Good-Evil-Fun/28441
https://blog.malwarebytes.com/101/2015/12/an-introduction-to-image-file-execution-options/
Normally debuggers can run a process or attach to existing process to debug it and it's enough for normal projects but in some projects like services debugger can't start the service because of Windows service architecture. in this scenario we should attach debugger to running service process but if we want to debug some codes in startup of service we can't do it by this method because debugger attached to process after the startup codes executed.
In scenarios like this we can use Image File Executions Options (IFEO) by configuring to launch debugger when process start, when specified process start Windows launch process inside specified debugger and let developer to debug the process from beginning of born !
The problem of this option is Microsoft Windows do not (and cannot ;) check the specified debugger is really a debugge.
On the other hand malware authors use this option as a trick to start they malicious process when some process run, for example they can run a injector every time "explorer.exe" process run and inject some malicious code to it.
Finally IFEO is not malicious option by it self but maybe! and there is not simple way to know it's malicious or not. if you want to be sure it's malicious or not the debugger should be analyze and check manually for malicious activity.
If you are not computer skilled person the easiest way for you is to find the IFEO registry keys and find debugger's path from theme and upload debugger file to online scanner website like VirusTotal and hope they tell the truth :))
Whenever one wants to attach to a process from Visual Studio, one receives this nasty message:
This question and its answers show the struggle to get rid of it. This Microsoft article tells us about the potential dangers of attaching for the debugging process/machine:
However, many developers do not realize that the security threat can
also flow in the opposite direction. It is possible for malicious code
in the debuggee process to jeopardize the security of the debugging
machine: there are a number of security exploits that must be guarded
against.
Question: how does the debugged process is able to exploit the debugging process? (I am interested in just a few highlights, as I imagine that one can write a book about it).
And also, what is the purpose of having this warning when debugging on local machine's w3wp.exe process (I imagine that the vast majority of debugging sessions happen within the development machine). If local machine's w3wp process is compromised, you are in deep trouble anyway.
You get this warning when you attach to a process that runs with a limited user account. Like w3wp.exe, a web server is typically configured with such account so that an attacker cannot do too much damage after he figured out how to compromise the web server. Note how you normally use an account with admin privileges to debug the web server.
This opens up a generic security hole that is very similar to the one exploited by a "shatter attack". A privilege escalation, the unprivileged process exploiting the privileges of another process. The conduit is the debugger transport, the channel that lets a debugger control the debuggee. I think a socket in the case where the process runs on another machine, a named pipe if it runs on the same machine. The compromised process could fake the messages that the debugger interprets as normal responses. Anything is possible, nothing is simple, none of this is documented. Intentionally.
Note how you still use the remote debugger when w3wp.exe runs locally. It is normally a 64-bit process and VS is 32-bit, the remote debugger (msvsmon.exe) is required to bridge the bitness difference.
It is the kind of attack scenario where Microsoft has to throw up their hands and can no longer guarantee that such an attack cannot succeed and do real damage to your machine. The attack surface is too large. So they display the dialog, you have to interpret it as a "we are no longer liable for what happens next". Plausible deniability when it ever comes to a lawsuit. The info it displays is not actually useful to judge whether the process is compromised, but it is all they got. Life is too short to worry about it every single time you click Attach, lawyers never once made a programmer's job easier :)
When you func eval something in the debuggee, you are effectively running code on the debugger. This is where the potential security problem could be.
For example, suppose the debuggee has some types that will load a natvis into the debugger. And suppose that the C++ Expression Evaluator has a security hole in it, that allows a buffer overrun attack through a natvis. Just by debugging a certain process, the remote process could take control of your local machine. Granted this isn’t likely, but the debugger isn’t hardened against this sort of attack. The nature of debugging means you have to let any code run.
In the other direction, once a process is being debugged, the debugger have the same permissions as it does. You can do anything you want.
This warning below pops up when attaching to an unknown users’ process. See this article:
https://msdn.microsoft.com/ro-ro/library/ms241736.aspx
I have some processes running on Windows 10 and I don't want them exit or close by anything inside or outside. I want to protect them. Anyone can tell me what I need to do or introduce me some tools to do this. Thank you so much
If you implement your "important" process as a service then a normal user will not be able to stop or kill it.
Preventing someone with administrator privileges from killing your process is very hard and I would recommend that you don't try to stop them.
Administrators can stop services, debug (and therefore kill) processes they did not start, run code as the system user and load kernel drives. There are only two ways to (try to) stop them:
If you are a real Antivirus/Antimalware vendor then you can create ELAM drivers and protected services. (Protected services can be debugged by a kernel debugger)
Create a kernel driver that prevents certain access rights when processes call OpenProcess and/or use dirty tricks to hide your process from the list of processes so it does not show up in task manager and other tools. Most people would consider this a pretty evil thing to do! You will have to fight with PatchGuard and Antivirus software if you try to do this.
Is it possible to get a C++ application running in Windows to request administrator privileges from the operating system at run time?
I know it can be done at compile time, but can't seem to find anywhere whether it can be done at run time.
Thanks for your help!
EDIT: What if I want the current instance to have elevated privileges? For example, I might have data stored in memory which I want to keep.
If you want the application to always elevate, you can give it a manifest, either by building one in (not compiling technically) or by putting an external manifest in the same folder as the exe. If you want to decide, as a person, to run it elevated, you right click the exe or short cut and choose Run As Administrator. If you are launching it from code, then as #vcsjones comments, you use the runas verb when you launch that process. For example:
ShellExecute( NULL,
"runas",
"c:\\windows\\notepad.exe",
" c:\\temp\\report.txt",
NULL, // default dir
SW_SHOWNORMAL
);
You can elevate a process only during its creation. When a process already runs, there's no way to change its security token: it either runs elevated or not.
If your application needs to perform an administrative task, and it usually runs non-elevated, you have to create another .exe which will request elevation with its manifest. To start a process elevated, you have to use ShellExecute or ShellExecuteEx function. From your main process you will need a way to pass the commands to that new process that will run elevated.
For more information about UAC, read Designing UAC Applications for Windows Vista series.
Not quite, but you can do the opposite—you can drop privileges if you already have them. So, you can have your program start out running as an Administrator, using one of the methods listed by Kate Gregory. Then, drop your unneeded privileges; see Dropping privileges in C++ on Windows for how to do that.
Add a manifest file into your EXE as described here.
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Your process (and threads) have a token assinged to them. That token already have all your groups set up. Under UAC, the Administrator group is disabled. UAC will remove that disabled group so you end up with a full administrator token.
To acheive the same, you must have the TCB priviledge. In other words, to elevate a process at runtime, you will need help from a process running under the SYSTEM account, and Microsoft isn't providing one, nor an API to control the current UAC implementation. Otherwise, it would defeat the purpose.
For the sake of completness, there is a whitelist of process that can perform some elevated operations without prompting. In short, your executable needs :
To be signed by Microsoft
To perform predefined operations, like with IFileOperation
The best explanation I found is this hack. It has been fixed since then, but is sheds some light on the whole thing.
I've written a program with a manifest that includes requireAdministrator. On Windows 7 systems with UAC enabled, Windows pops up a dialog asking for permissions, as it should. Works great.
If a user starts my program by right-clicking it and choosing "Run as administrator", then Windows 7 also pops up a dialog asking for permissions. However, there are some slight differences in how my program operates in some of the more esoteric parts of my program.
So what are the differences between "Run as administrator" and a manifest with requireAdministrator? Any links to documentation that describe differences would be appreciated.
Edit: This is with UAC enabled.
Edit: As promised below is the full explanation of the difference I'm seeing.
I'm using the EasyHook library to inject a DLL into another process. When my application is run with "Run as administrator", the injected process crashes and EasyHook returns the error "Unknown error in injected assembler code". None of the code in my DLL gets a chance to execute; the crash occurs before then. (Moreover, the crash occurs even if I strip the DLL down to nothing)
If I run my program normally (i.e., elevated via requireAdministrator), everything works fine.
My application is composed of a few different executables. The process that the user launches is not the same process that performs the injection.
With the information given there would be no differences in the permissions between the two processes.
If you request an execution level of "requireAdministrator" via the applications manifest your application will either be launched with the full access token of an administrator or not at all if the user denies consent (see Create and Embed an Application Manifest (UAC) for further information).
The same will happen when a user chooses Run as Administrator.
The only difference is the way that the process is started. When you start an executable from the shell, e.g. by double-clicking in Explorer or by selecting Run as Administrator from the context menu, the shell will call ShellExecute to actually start process execution. The whole process of elevation is hidden inside this function. Kenny Kerr describes this process in more details in Windows Vista for Developers – Part 4 – User Account Control:
ShellExecute first calls CreateProcess to attempt to create the new process. CreateProcess does all the work of checking application compatibility settings, application manifests, runtime loaders, etc. If it determines that the application requires elevation but the calling process is not elevated then CreateProcess fails with ERROR_ELEVATION_REQUIRED. ShellExecute then calls the Application Information service to handle the elevation prompt and creation of the elevated process since the calling process obviously doesn’t have the necessary permissions to perform such a task. The Application Information service ultimately calls CreateProcessAsUser with an unrestricted administrator token.
If on the other hand you want to create an elevated process regardless of what application information is available then you can specify the little-known “runas” verb with ShellExecute. This has the effect of requesting elevation regardless of what an application’s manifest and compatibility information might prescribe. The runas verb is not actually new to Windows Vista. It was available on Windows XP and Windows 2003 and was often used to create a restricted token directly from the shell. This behavior has however changed. Here is a simple example:
::ShellExecute(0, // owner window
L"runas",
L"C:\\Windows\\Notepad.exe",
0, // params
0, // directory
SW_SHOWNORMAL);
So essentially starting an executable using the Run as Administrator option means that ShellExecute bypasses the checks for compatibility settings, application manifests etc and directly requests elevation.
Kenny Kerr's article also has sample code to query the current process' token for its permission using the OpenProcessToken function. Possibly you can use the example to identify that there are no differences in the way your process is elevated.
I'm definitely curious to know which differences you are observing as I strongly doubt they are related to elevation.
As a last thing: Can you double check that you really request a level of requireAdministrator and not by mistake only a level of highestAvailable?
One possible difference might be the rarely used/understood/deliberately-chosen uiAccess attribute. Can you create two manifests, one with uiAccess=false and one with uiAccess=true, then tell us whether one of them gives the same behaviour as you see with right-click-run-as-admin?
The EasyHook documentation for the RemoteHooking class' IsAdministrator property mentions:
Due to UAC on Windows Vista, this property in general will be false even if the user is in the builtin-admin group. As you can't hook without administrator privileges you should just set the UAC level of your application to requireAdministrator.
It's hard to imagine why this is happening, but it is conceivable (especially as you are seeing it happen!) that assets, processes, assemblies, &c, with possibly different trust levels and so forth, will not inherit the elevation of your main app. Setting the requireAdministrator flag may handle/enforce this globally across the entire scope of resources and dependencies. Would love to know how this turns out.
I thought I was seeing a difference between these as well. However, it turned out that in my case the issue was this:
When I click "Run as Administrator" from my file browser (Q-Dir), the working directory is different than when I try simply double clicking an application with requireAdministrator set in the manifest. This changed the behavior of some buggy DLLs I had received. In fact, it turned out that 100% of the differences I saw were due to running from different working directories (specifically, it mattered whether I was on C: drive or a different drive letter) and that the method of getting the program to run as administrator had nothing to do with it.
It's an issue that is specific to my computer's exact configuration, but it is a possible clue into the type of thing that might be happening (or might have happened 7 years ago . . . )