Jump to content
Mark Williams

ShellExecute and passing of password

Recommended Posts

I would like to shellexecute one app from another. Both apps require username and password. I would like to be able to pass the password securely from one app to the other.

 

Obviously, command-line parameters are out and I would imaging a memory mapped file will also not be secure.

 

Is there any relatively simple and secure way of achieving this.

Share this post


Link to post

Consider using pipes, I believe they're a bit harder to sniff than command-line params. Of course you'll need full-featured CreateProcess for this. Or you may encrypt your data and send it via any channel. You can even implement full TLS handshake.

  • Like 1

Share this post


Link to post

Afaik ShellExecute returns nothing, it does not even confirm if the command line was executed or not. By sticking to it you have no other options but command line parameters, best case scenario is to encrypt the password and decrypt it from the second app. You can check the running processes after ShellExecute and grab it's handle for data transfer but this introduces a lot of unnecessary checks, like timeout (don't wait for the second process until you can find it, what if it did not even launch), did it already initialize and ready to accept data?

 

If you use CreateProcess and map the stdin and stdout, you can make your first application to "type in" the user name and password to the second one and read back the output to verify if authentication was successful.

 

However if both applications are written and managed by you, move the worker method to a .DLL and make the first and the second application to load and use it. You also have to validate the legitimacy of the library, though. Or to a helper unit, and do not even include a secondary file.

 

However, external files will always pose a major security risk, especially if they need to share sensitive information. It's really easy to put a malicious .EXE file in place of yours (even if it's running) just to steal the credentials.

  • Like 1

Share this post


Link to post

An encrypted password on the command line, decrypted by the second app, may not help security very much; if an attacker sees it in the command-line of the second process, they can send the same password later to the second process.  Seeding the encryption and decryption with for example the current process ID makes this exploit harder, but not impossible.  Everything suggested here has to be interpreted in the light of how secure you actually need all this to be, which we do not know.

Share this post


Link to post

Sure, every security measures should be estimated from the point of what you want to achieve and what skill level of a hacker you want to withstand. In general, every local solution is hackable by design; and not every solution with remote server is non-hackable.

Edited by Fr0sT.Brutal

Share this post


Link to post

Thanks again. I have decided to go down a different route altoghether and instead of having separate apps, house them all within the same app.

Share this post


Link to post

I assume it's on the same computer.
1- And if you want to do the same user.
The easy way. Encrypt the password and sendmassage (..); you send it with.

2- If you are going to communicate between programs in different users, you should use namepipe.

Share this post


Link to post

It’s not clear what you want to do, I can suggest using Windows API function

CreateProcessWithLogonW =
    function(const lpUsername: PWideChar;
    const lpDomain: PWideChar; const lpPassword: PWideChar;
    dwLogonFlags: DWORD; const lpApplicationName: PWideChar;
    lpCommandLine: PWideChar; dwCreationFlags: DWORD;
    lpEnvironment: Pointer; const lpCurrentDirectory: PWideChar;
    lpStartupInfo: PStartupInfo;
    lpProcessInfo: PProcessInformation): Boolean; stdcall

Share this post


Link to post
On 11/4/2019 at 10:40 AM, Mark Williams said:

I would like to shellexecute one app from another. Both apps require username and password. I would like to be able to pass the password securely from one app to the other.

Then DON'T pass the password on the command-line, use an IPC mechanism instead, such as a pipe, or even anonymous shared memory (coupled with this), or if you really want to be sneaky, there is an undocumented way to pass arbitrary data (up to 65531 bytes) to a child process via CreateProcess() (be careful though, it doesn't work under WOW64).

 

Share this post


Link to post

Anyway if a user has admin rights in your system, he is able to dump process memory or even debug it. If he hasn't, encrypt your data and transfer it in any manner.

  • Like 1

Share this post


Link to post
On 2/27/2020 at 8:53 AM, Fr0sT.Brutal said:

Anyway if a user has admin rights in your system, he is able to dump process memory or even debug it.

For way too long this is haunting my coding experience. A simple Hello World is becoming thousands of lines due to encryption, obfuscation and filler NoOps. At the end of the day you are only making the life of the attacker harder. Never impossible.

On 2/27/2020 at 8:53 AM, Fr0sT.Brutal said:

If he hasn't, encrypt your data and transfer it in any manner.

True and not true. If password is sent as a parameter and the application is stored in %APPDATA% for example, you can replace the secondary .EXE to just dump the password. Command line passwords are a really bad idea from this perspective.

Share this post


Link to post
2 hours ago, aehimself said:

True and not true. If password is sent as a parameter and the application is stored in %APPDATA% for example, you can replace the secondary .EXE to just dump the password. Command line passwords are a really bad idea from this perspective. 

Like anything in protection field: one has to estimate how much efforts he is ready to put into protection and how much efforts an attacker will have to make to crack the protection and will it ever worth it. Of course, estimation must include app environment as well. We know nothing about the conditions topicstarter has so it's useless to just guess. Probably xor-ing credentials with a key contained inside the app binary will suffice his needs.

Share this post


Link to post

If you have Azure AD, using PowerShell and storing credentials in Azure Vault is a good alternative to passing credentials on the command line.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×