8

I don't know how known is this tool, but an admin in our organisation is using RunAsTool v1.5 : https://www.sordum.org/8727/runastool-v1-5/

I did not hear about it before, the website seems to propose a multitude of free softwares that are supposed to give more control over windows.

Saw around 200 comments of users, so I guess some people are using it and seem quite satisfied.

However do people with more experience then me see some risk in here ? were there any known security issues with this tool ?

Improve this question
0

3 Answers 3

Reset to default
21

To run Properly RunAsTool need to install on a windows system which has an Administrator account with password.The login information for the application like username and password are read from an encrypted file – You don’t have to worry about your Admin Password.

From the webpage of the tool.

This means that it stores the password. If the tool can retrieve the password, so can an attacker. The fact that the authors tell you not to worry signifies that they are... not security minded. I would thus suspect the tool to harbour several pitfalls and security problems.

In addition, if you allow users to run some software with raised privileges, assume that the user can run any software with raised privileges.

If you ever have the need for this piece of software, it is better to use the built in Windows feature UAC. UAC provides real security, and doesn't create additional problems.

Improve this answer
10
  • 10
    Also "As a security check, administrators can use “check the file size before run” feature." - Not a hash of the file; that also sounds very insecure!
    – Ken Y-N
    Commented Sep 20 at 3:57
  • 2
    @Hobbamok The tool provides the admin privileges you need for manipulation. An Open File dialogue allows you to paste a file... with admin privileges. In addition the tool has to be able to read and decrypt the file containing password, thus the user can as well. It can't be secure.
    – vidarlo
    Commented Sep 20 at 18:26
  • 3
    UAC in its default "split token" "admin approval mode" configuration is not super secure - there are known bypasses that Microsoft has announced they don't consider important to fix - but that assumes the user is a member of the Administrators group. UAC as a convenient alternative to the runas.exe tool - where the user is not an Admin and must supply an administrator account's credentials to run anything elevated - is real security.
    – CBHacking
    Commented Sep 21 at 3:31
  • 3
    @Hobbamok I disagree. A properly configured and patched windows environment is fairly secure, and this tool would be easy target compared to other common problems. It's well within the reach of a curious end user. The statement is correct; if the tool can read it, so can the user.
    – vidarlo
    Commented Sep 21 at 20:20
  • 2
    @Hobbamok With all due respect, your statement is far, far more "bullshit" than what OP said. We're talking about use within an org with an IT admin, so hopefully the machines are fully patched. Thus you're comparing the difficulty of "find/obtain a weaponized EoP vuln in Windows for which no patch exists" vs. "use any of a number of ways to attack this obviously-incompetently-written software, such as finding the encryption key or using a debugger or exploiting other flaws already pointed out". Those are not remotely the same thing.
    – CBHacking
    Commented Sep 22 at 7:05
7

I'm going to come out and say it. There is no possible way RunAsTool does what it says it does securely. "Requires a local administrator account to run". No way. They did it wrong.

Attach a debugger and set a breakpoint at CreateUserWithLogonW. Bet you get the correct password.

Here's how I know. The only builtin API that operates at this level is CreateProcessWithLogonW, and it only works if you give the password. Therefore, they've done something boneheaded.

Now let us suppose they did it correctly and found a way that's actually secure. Knowing the solution, I know what the moving pieces are, and it boils down to NtCreateToken. Had they done this any way that works; they wouldn't need the administrator password to set this up.

Correct way #1: Create a new user account, and give it a bunch of privileges including Act as Part of the Operating System, Create a Process Token, Assign Primary Token, and Log on as a service. Create a service for tool tool. Set permissions on the tool so any user can start and stop it. This process then goes through the steps to build the token with the correct session and mandatory ACL for the windows session and launches the process with that token.

Correct way #2: Create a Local System service for tool (trust me; an Administrator account won't work; we need Act as Part of the Operating System). Set permissions on the tool so any user can start and stop it. This process steals the token from LSASS.EXE (so it has Create a Token privilege) and starts a process with that token that goes through the steps to build the token with the correct session and mandatory ACL for the windows session and launches the process with that token.

Most of the time what you're doing this for doesn't need access to any particular administrator account; so there's a different tool they could have made that uses a service that operates by a different method: steal the winlogon token from the active window session. This token can be used to start a System process (which has admin access) that has GUI access on the active desktop.

As you can see; having a local administrator account is neither here nor there; and doesn't get anywhere on the path of getting the token built the right way. Therefore; they must have done it wrongly.

Improve this answer
5
  • This is mostly right but also kind of misleading. First of all, you obviously need Admin-level access to set up those approaches (though you don't need the admin password, per se). Second, while they are probably doing something that caches out in CreateProcessWithLogon, you wouldn't necessarily find it in this process; they might be invoking runas.exe instead. Or giving Administrators SeAssignPrimaryTokenPrivilege (which can be done with only Admin privileges) and doing LogonUser->CreateProcessAsUser. Or there are various ways to get a primary token without involving lsass.
    – CBHacking
    Commented Sep 22 at 9:33
  • One thing you should consider, though: creating a token without a logon gives you an unauthenticated token. It can be used for purposes of authorization (access control checks), but it can't be used for anything that requires authentication (such as accessing user DPAPI or EFS keys).
    – CBHacking
    Commented Sep 22 at 9:35
  • @CBHacking: Normal users can't call CreateProcessAsUser though. My trace program sees through child processes. Does yours?
    – Joshua
    Commented Sep 22 at 13:55
  • Debuggers can but don't have to attach to child processes, sure. You did see the part about giving Administrators the AssignPrimaryToken privilege (which solves the CreateProcessAsUser problem), right? It's better to use the System account - your second approach basically does what psexec.exe does, though there are other ways to get from there to the solution than stealing the LSASS token - but Administrators can assign any privilege to any account.
    – CBHacking
    Commented Sep 22 at 19:00
  • @CBHacking: PSExec starts the process on the service session; the trick is to get an actual interactive process. I finally figured out the other thing you were talking about. You could run the service as the administrator account with extra privileges; this is merely a different bad idea. Dedicated account is highly recommended.
    – Joshua
    Commented Sep 22 at 19:32
3

I believe it is important here to challenge the premise, that not having any know issues makes software safe. As a rule, it is not considered good security policy to allow people to run, with administrative privileges, any random exe from any random website, as long as there are no known issues. "No known issues" is a default state, achievable in complete ignorance, and if that's the best thing that can be said for a piece of software, then it is as far from safe as it is possible to be without being knowingly actively malicious.

The questions you should ask of a vendor of security critical software of course depends on what it does and the standards of your own organisation, but it should definitely be more than "Do you have a website with positive comments", which basically anyone can create very easily and "Can you give me a random executable that you'll promise will do what I want and is totally not a trojan but which you don't want me to reverse engineer to verify".

So no, not really. Your admins should not be giving their admin passwords to random exes they downloaded off the internet unless they have a very good explanation of both who made that random exe and why they really really need it to do their job.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .