A problem with PrimeFaces Expression Language (EL) in Tufin SecureChange has been found. CodeWhite points out that in SecureChange an EL Injection is possible, allowing unauthenticated attackers to inject arbitrary EL code to PrimeFaces custom EL Parser.

Tufin has published a Security Advisory regarding this fact on August, 24th.

All TOS versions with SecureChange installed are affected. Not affected are systems if SecureTrack only is installed.
Fixes are available for most supported TOS versions.

TOS R17-2: Fix will be published End of August
TOS R17-1: Fix is included in R17-1HF3 which is available in Tufin Download Center
TOS R16-4: Fix is included in R16-4HF5 which is available in Tufin Download Center

If a fix is needed for TOS R16-3 or TOS R16-2 Tufin asks customers to contact Tufin Support
(support at tufin dot com).

Earlier versions are no more supported, so a fix will not be published. In this case, upgrading to a supported version is strongly recommended.

 

 

 

In a workflow the field „Manager“ can be used. This might be useful if the manager has to approve a ticket requested by a member of his team.

The requester provides the E-Mail address of his manager so this person can approve the request in the next step.It's mandatory to have in the next step a "Manager Assignment" so the decision who has to work on the ticket is flexible. Besides this, if the mail address provided by the requester isn's valid for Manager function, the E-Mail will be sent to a "Default Manager" provided in the following step. This person (named Default_Manager below) is able to approve/reject the ticket as well to reassign it.

 

If the manager gets the E-Mail from SecureChange, logging in to SecureChange is necessary. After this, working on the ticket is possible.

Having local users configured, the validity of the mail address is checked. Examples:

  • If the assigned manager has the appropriate right, approval is possible.
  • If there is no right for approval, but a link sent by E-Mail, the approval is possible for this case.
  • If the mail address isn't known in SC, Default Manager is taken.

So as a result, when this option is used with local users, everything works as designed in SecureChange.The Manager is able to approve a step even if he doesn't have "global rights by role" to do so. Having a LDAP Server connected to SecureChange, this is the result:

  • If the assigned manager has the appropriate right, approval is possible.
  • If there is no right for approval, but a link, then the approval is possible for this ticket.
  • If the mail address isn't known in SC but in LDAP, the ticket is assigned and even without being defined in SecureChange, the manager can follow the link and to approve the step.
  • If the mail address is "external", the Default Manager is taken.

Please be aware, that the MANAGER as well as the DEFAULT-MANAGER need to be known in SecureChange or LDAP Server. The MANAGER doesn't need appropriate rights in every case.

 

 

Sometimes it's necessary to have a documentation about changes at the system itself or about changes in Workflows defined in SecureChange. System changes can be documented in SecureTrack easily, but what about changes in Workflows that are defined and used in SecureChange?
Currently there is no option in the WebUI to get a report about these changes, but they are recorded in the system, i.e. in the database table change_audit.

To view the table content, a SQL query is used at the CLI of the SecureChange Server:

# psql -Upostgres securechangeworkflow -x -c " select * from change_audit"

This delivers all changes to the CLI, including the name of the user as well as a XML output of the workflow before and after. If necessary, the output can be redirected to a file, e.g. for further inspection.

 

 

 

 

Bug in TOS if SecureChange is run in HA mode


Tufin points out a potential vulnerability in Tufin Orchestration Suite (TOS) if SecureChange is run as a cluster. It might happen that MongoDB provides a simple HTTP interface that might be accessable from external sources. This could deliver information to external persons.

 

Affected are only HA deployments running SecureChange R15-3 or higher. Clusters running SecureTrack only aren't affected as standalone installations of SecureChange are. A fix will be included in R16-2 HF4, R16-3 GA and R16-4 RC1 and above. If you run an elder version not being able to upgrade, you will need to check the configuration of your HA installation of SecureChange.

 

To address this issue, just edit the configuration of MongoDB on the systems:

  1. Backup the original file /etc/mongod.conf
  2. Edit the file /etc/mongod.conf and add this option at the end of the file:
       nohttpinterface = true
  3. Save the file with your changes
  4. Restart the MongoDB service using
       # service mongod restart

Tufin states that this change won't interfere with the performance, stability, or functionality of TOS.

 

 

In SecureChange an Access Request can be configured. If wanted, the use of ANY for Source, Destination and Service can be allowed.

If a requestor wants access from a specific IP to ANY he or she will write e.g.:

If (accidently) an IP address has been entered into the Destination field, there is (at the first glance) no chance to re-configure an ANY or any accepted by the system.

 

Solution:
Just delete the entry in the Destination, so you have an empty field. Pressing OK delivers the Destination ANY back again.

 

 

 

When a ticket is worked on, the ticket goes step for step through the workflow.
There is an option called "Redo Step" to jump back to an earlier step which will be redone then. To do so, just select the earlier step and press the "Redo Step" button.

 

In this example we are currently at step 5 while step 3 shall be repeated (and therefore step 4 and 5 also becuse in the repeated step a change could have be configured).
Here, in step 5 the step 3 is selected and shown (read only).

After having selected the step, press the "Redo Step"button.

So the ticket goes back in the workflow to the step selected (in this case back from step 5 to step 3).

BUT - this sometimes doesn't seem to work

In the upper example, step 2 is shown with a "skip" sign. This sign is shown if the step of the workflow has been skipped in this ticket. Due to this, a "Redo Step" can't be assigned. At the first glance, it seems to be strange that this step can't be selected, but with a second look it's quite logical. Btw - if a ticket using other conditions is going through the step, a "Redo Step" for this step can be configured later on. In this case, the "skip" sign doesn't show up in the ticket.

 

Lesson learned:

The option "Redo Step" can be used to go back to any step the ticket has passed before.
If a step has been skipped, going back to this step using "Redo Step" isn't possible.