Security / Robot managing assets/credentials

Hi all,

We identified the risk that the persons who are managing the assets (credentials for applications) and the persons that manage the credentials of Robot-user, can use these credentials anonymously and login to systems they are not allowed to login to.

I think I can make a Robot that changes his own password (for application or WindowsID) but can the robot update the orchestrator with this new password? So change an asset-value and change the Robot Credentials.

If we can build a robot like that, no human knows the passwords of the robot and there the identified risk is gone.

Hope anybody can help me.

Greets

Robert

4 Likes

@badita @aksh1yadav @ovi

Hello,

if you have a good use of Roles settings in Orchestrator, you should be able to achieve not to allow the Robot Manager to Edit robots credential.
Note that even an Admin will not have access to a Robot Password once it was entered (it will be encrypted and the field value will be hidden.
Same thing applies to Assets Credentials.

If you have a person/services having a specific role (or acces level) responsible for maintaining robot credentials, only this one will “know” the credentials when they will enter them the first time.
Also not that every changes that you be applied to robot configuration/assets should be auditable under the “Audit” Menu option on the top right menu option.

Cheers,

2 Likes

Hi Robert,

First, you cannot make a robot change it’s own values in Orchestrator if it’s connected to Orchestrator(Busy robot cannot be edited). I wouldn’t recommend it because of the dynamic selectors of the web application(but you could try it).

As @Florent_Salendres said, Roles are useful in this case.

Alternatively you can use CyberArk for storing robot credentials. But you’ll end up with the same problem (an admin can retrieve the password). We are considering this for future developments.

@Florent_Salendres answer makes sense. In an enterprise environment you are able to track/audit who changed the password and also what IP have been used to RDP connect to the robot.

1 Like

Sorry for reviving an old thread, but we’re having pushback on this in our working environment. We were supposed to be getting CyberArk, but that project has been delayed many times.

I understand that the robot credentials can be managed by someone with that role. However, what we’re concerned about is that the person who manages those credentials can now log into the application as the robot - I’m not sure how to prevent that?

Hi,

We managed by dividing the password.

I know part 1, my collegue knows part 2.

Setting up the robot in orchestrator is done by the 2 of us. Once you filled the password and save the credentials, you cannot see them anymore.

In this case, nobody can logon by it’s own. Tou always need 2 people.

This is also approved by the security officers.

Greets

Robert

2 Likes

Thanks for the reply Robert.

How do you stop the person that knows the robots username and password from logging in directly to the applications?

E.g. Person A is responsible for managing the password the robot uses to log in to Application A because the password must be changed every 90 days. What prevents Person A from logging to Application A directly, by using the robot credentials?

We also splitted these passwords.

So we have an asset in orchestrator (credential) with username/password of that application.

When setting the password, 2 people are needed.

When setting the asset, again these 2 people are needed.

Each 90 days there is an action to change the password of the application and changing the asset. (again with 2 people)

What we are planning to do is to make a robot for applications. A robot can change it’s own password for an application AND change the asset in the orchestrator. But then nobody knows the password anymore. If there is something wrong with the robot between setting the new password in the application and changing the asset, you have to reset the password manualy.

4 Likes

Thank you for your patience and multiple replies!

I’m still having trouble wrapping my head around how this works. When you say it requires 2 people, does that mean that the robot has 1 password, composed of 2 parts?

So robot password = Password1234

Person 1 knows the first part “Password” and Person 2 knows the second part “1234”. So both Person 1 and Person 2 physically go on the same computer at the same time to type in the credentials in orchestrator and the application? Then this same process is repeated as needed for new applications or when passwords need to be updated?

What we are planning to do is to make a robot for applications. A robot can change it’s own password for an application AND change the asset in the orchestrator. But then nobody knows the password anymore. If there is something wrong with the robot between setting the new password in the application and changing the asset, you have to reset the password manualy.

This would be ideal, but not sure how to do it either.

Person 1 knows the first part “Password” and Person 2 knows the second part “1234”.

So both Person 1 and Person 2 physically go on the same computer at the same time to type in the credentials in orchestrator and the application? Then this same process is repeated as needed for new applications or when passwords need to be updated?

Yes. This is how we do it now.

2 Likes

You could have the robot setup a variable with a random key generated once at initialization an then push that as credential in Orchestrator but i think that will still be editable within Orchestrator by the user who added the robot.

Interesting topic. But you could also create a robot, which retrieves the credentials and output them in a notepad instead of password input field.

2 Likes

That is my concern about the security issue in orchestrator.

I think that´s the blind spot of Assets in orchestrator.

Does anyone know how to solve this security fault?

Thank you!

1 Like

Hello everybody,

This is also my concern. The two part password is a great idea but this still doesn’t take into account that, with a simple robot you can retrieve the credentials from an asset and let the robot login to that application.

Sorry for opening up this thread but I’d really like to know how to fix this security risk.

Thanx in advance for the advice! :+1:

I don’t know if there could be a “Fix” for this, as long as a Credential or SecureString can be converted into Plain Text… it comes down to managing risk by putting controls, policies, and best practices into place. And there are use cases were one might want to be able to convert a credential or secure string into plain text when working with legacy applications that don’t support modern authentication/authorization mechanisms.

Whether you are doing basic auth, OAuth, Certificates, whatever… there is a level of trust that needs to be in place for those that should have access and if they shouldn’t have access then the controls, policies, and best practices should be developed to support that risk mitigation.

  • Audit Controls
  • Code Reviews
  • Deployment Gates
  • etc.

This scenario isn’t limited to UiPath… Take into consideration a machine that uses a certificate to authenticate or maintain authenticity… in the M2M scenario those that manage the machines and other domain admins, etc. most likely do or can gain access but you manage that risk but appropriate File System ACLs, Policies, etc.

Going back to UiPath…

  • Setup appropriate Folders and Access
  • Setup appropriate Roles
  • Audit / Review Code/Packages before they are allowed to be pushed to Orchestrator
  • Setup Audit / Monitoring for Robot Usage and Access so you can trace Invocation of a Job to usage of a Credential / Account
  • Deploy a platform like CyberArk to help manage your Risk Mitigation and support any security policies or controls for you company.

We use CyberArk, which helps us with Password complexity and rotation. Some Safes are restricted to the Orchestator/Robots and Safe Managers, others are restricted to Orchestrator/Robots and Process Owner and we have some that are accessible by Orchestrator/Robots, Developers, and Safe Managers.

Even with that in place… if someone were able to deploy malicious code/package and run it under the right Robot in the right Folder they would be able to get the Credential from the Asset.

Thanx for your quick reply Tim.
I’ll have to Google for this thing you said:

Setup Audit / Monitoring for Robot Usage and Access so you can trace Invocation of a Job to usage of a Credential / Account

I didn’t know this was possible. Solid advice.

I’m pretty new to this and haven’t heard about CyberArk so I’m also gonna look into this:

Deploy a platform like CyberArk to help manage your Risk Motivation and support any security policies or controls for you company.

Thanx again for the advice, it’s really helpful.

Yeah, it’s not so much that there are specific products or services gear towards monitoring the “Robots”, but if your using Domain Credentials for your Robots or in your Assets you could have an audit trail of Login Attempts (Success / Failure) with your domain controller along with the application/service you are interacting with ideally has authentication attempts being logged to.

In addition to this, you could send your Robot and Orchestrator logs to [insert your logging/monitoring platform here] and start to generate Alerts / Reports based on curtain events or sequence of events.

I’m not familiar with all the players in the [Identity / Access Management] space, CyberArk is just one that we happen to use and encourage to use by our Security Team, I understand it to not be the cheapest solution available but the capabilities, modules, products they have available are vast.

I know HashiCorp has their own Vault product, but I haven’t used it before. A year or so ago there was a user on the forums that was compiling an Orchestrator Credential Store Plugin for Thycotic… If you or your company has interest I’m sure there is a product out there that will meet your needs/budget.