I have a testing program through which employees can submit JAR files to be executed. This is obviously a security concern, and it gets even worse as the executables have to be trusted since they normally need to access enterprise data.
To that end, I was wondering if it was, at least, possible to use the Windows account of the employee sending the JAR to execute it instead of some surrogate account. Is it somehow possible? What would it imply?
You might want to look into the SSPI functionality of Windows, which may allow you to transparently transfer an authentication token so that you can execute the JAR in the context of the user.
Unless you submit the credentials of the user passing in the JAR file, the saved credential wil not work later on. You might be able to execute it immediately, as long as the sending machine and executing machine are one hop away. Otherwise, the credential will not travel any farther.
Related
I've created a communication between two applications using named pipes.
The first application creates a named pipe with CreateNamedPipe and reads the received messages with ReadFile sent by the second application. Both applications are able to communicate that way as intended.
Is it somehow possible to identify the sender of a received message?
Without some sort of identification (like getting the sender exe path) or authorization every other application could use that pipe to send messages to my application.
(Edit) Further details, because it seems it's important in this case:
The application that creates the pipe is running as a Windows service.
Both applications run locally on the same system.
The GetNamedPipeClientProcessId() will give you the process ID of the client process. You can then open a handle to the process with OpenProcess() and call GetModuleFileNameEx() to determine what application is running in that process. You can then vet the application in whatever way you think best, e.g., you might want to check the identity of the digital certificate or you might prefer to just check that the pathname is as you expect it to be.
Note that attempting to restrict access to a particular application rather than a particular user is never going to be robust; an attacker could always take control of the approved application and replace its code with their own. Basically it isn't going to be more than a speed bump, but if you feel it is worth doing, it can be done.
If what you really want to know is what user has connected, you should instead be using ImpersonateNamedPipeClient() as already suggested in the comments, followed by OpenThreadToken() and so on. Or better still, set the permissions when creating the named pipe so that only the authorized users are able to connect in the first place.
Now that you've clarified that the client runs with elevated privileges, I can make a more concrete recommendation: do both of the above. Configure the permissions on the named pipe so that only members of the Administrators group can access it; that will ensure that only applications running with elevated privilege can access it. Checking the executable as well won't hurt, but it isn't sufficient by itself, because an attacker could launch a copy of your application, suppress the requested elevatation, and inject their own code into the process. (Or, as conio points out, modify their own process to make it look as if they are running your executable; GetModuleFileNameEx() is not intended to be used as a security measure, so it makes no effort to avoid spoofing.)
In windows 7, is there a way to have every login go to the same user session. So when a person is met with the login screen, they login and can continue working on that same user session. I am asking this because each user has their own login, but on this machine I need a program to be running across all user sessions. Since that doesn't seem feasible, I was just going to have them all login to the same user session.
Is this possible?
The appropriate way to solve this would be to have the program run as a service, and have a client UI that loads on startup 'hook' into the service process. Loading multiple users to the same session space would effectively violate the entire windows security model.
So, you either need to use a shared user for this, or a shared process (either local as a service, or remote as a server)
So, there's one possible way you might be able to get this to work, and that's to set this up as an interactive service. Definitely not a secure way to keep your system, but if you are able to make it work, it should work for your purposes:
Interactive services (in particular, read 'using an interactive service'):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx
Making srvany.exe (to run non-services as a service) on Windows7/Windows 2008:
http://social.technet.microsoft.com/Forums/en-US/winserverMigration/thread/98a97aee-c62b-4683-94ab-3777899cf7de/
My service program executes another instance of itself with, essentially, CreateProcess(GetCommandLine()). The child process then uses OpenProcess to get a handle to its parent process (so it can detect when the parent has stopped running). For some customers, OpenProcess fails with ERROR_ACCESS_DENIED. I'm trying to determine the reason and reproduce the circumstances for in-house testing.
I want something I can send to customers (either a program, or instructions for using programs that are already commonly installed on Windows servers) for them to run and generate a report that includes what account the service runs as and what privileges that account and its groups have been granted or denied. How can I collect that information from customers?
Getting the account name is easy -- GetUserName. Getting the rights assigned to that account is a bit more work. If memory serves, the sequence runs something like:
GetKernelObjectSecurity(Current_oject, &security_descriptor)
GetSecurityDescriptorDacl(security_descriptor, &dacl)
GetEffectiveRightsFromAcl(dacl, user_name, &rights)
You might prefer to use GetExplicitEntriesFromAcl for that last step. There is one problem with all this: if they've restricted the user too much, some (or all) of it might fail as well.
Imagine I have an existing process running under windows as a particular user. Would it be permitted for that process to take its current token (with something like OpenThreadToken and DuplicateTokenEx), pass it to another process on the same machine (perhaps through a network socket or some other IPC), and then expect that process to be able to use it to call CreateProcessAsUser?
From the documentation I have read (http://msdn.microsoft.com/en-us/library/ms682429%28VS.85%29.aspx), I've seen nothing which prohibits this but perhaps the token can only be used by the thread or process which created it.
(Why would you? I want to has a web request come to IIS, be authenticated, have IIS arrange the impersonation of the remote user and then pass the impersonation token to another server process (on the same machine) so that the server process can perform some security checks in the context of the remote user)
Yes, that is possible. You can use DuplicateHandle to get a handle that is valid for the target process (send the new handle value to the target process, so it knows it.).
However, the target process must still have the privileges to use the token accordingly. E.g. SE_IMPERSONATE to impersonate the user and SE_ASSIGN_PRIMARY to be used by CPAU. Of course there are some exceptions that you can read in MSDN for ImpersonateLoggedOnUser and CPAU.
I haven't tried it, but it seems that this is the same question asked here. The description seems to make sense. Pass the process ID via whatever mechanism you choose (e.g., IPC), then call OpenProcess, OpenProcessToken, and finally ImpersonateLoggedOnUser. The resulting handle could be passed to CreateProcessAsUser. Well ... I know it could be passed to that function but whether it would have the desired result I do not know. Interesting question, though.
Why not just use named pipes, and then call ImpersonateNamedPipeUser() - it's safe and secure and easy! Note that the process doing the impersonation MUST have the Impersonation privilege.
I would like to improve the way how an application is checking that another instance is not already running. Right now we are using named mutexes with checking of running processes.
The goal is to prevent security attacks (as this is security software). My idea right now is that "bulletproof" solution is only to write an driver, that will serve this kind of information and will authenticate client via signed binaries.
Does anyone solved such problem?
What are your opinions and recommendations?
First, let me say that there is ultimately no way to protect your process from agents that have administrator or system access. Even if you write a rootkit driver that intercepts all system calls (a difficult and unsafe practice in of itself), there are still ways to use admin access to get in. You have the wrong design if this is a requirement.
If you set up your secure process to run as a service, you can use the Service Control Manager to start it. The SCM will only start one instance, will monitor that it stays up, allow you to define actions to execute if it crashes, and allow you to query the current status. Since this is controlled by the SCM and the service database can only be modified by administrators, an attacking process would not be able to spoof it.
I don't think there's a secure way of doing this. No matter what kind of system-unique, or user-unique named object you use - malicious 3rd party software can still use the exact same name and that would prevent your application from starting at all.
If you use the method of checking the currently executing processes, and checking if no executable with the same name is running - you'd run into problems, if the malicious software has the same executable name. If you also check the path, of that executable - then it would be possible to run two copies of your app from different locations.
If you create/delete a file when starting/finishing - that might be tricked as well.
The only thing that comes to my mind is you may be able to achieve the desired effect by putting all the logic of your app into a COM object, and then have a GUI application interact with it through COM interfaces. This would, only ensure, that there is only one COM object - you would be able to run as many GUI clients as you want. Note, that I'm not suggesting this as a bulletproof method - it may have it's own holes (for example - someone could make your GUI client to connect to a 3rd party COM object, by simply editing the registry).
So, the short answer - there is no truly secure way of doing this.
I use a named pipe¹, where the name is derived from the conditions that must be unique:
Name of the application (this is not the file name of the executable)
Username of the user who launched the application
If the named pipe creation fails because a pipe with that name already exists, then I know an instance is already running. I use a second lock around this check for thread (process) safety. The named pipe is automatically closed when the application terminates (even if the termination was due to an End Process command).
¹ This may not be the best general option, but in my case I end up sending data on it at a later point in the application lifetime.
In pseudo code:
numberofapps = 0
for each process in processes
if path to module file equals path to this module file
increment numberofapps
if number of apps > 1
exit
See msdn.microsoft.com/en-us/library/ms682623(VS.85).aspx for details on how to enumerate processes.