Micro Focus Fortify WebInspect helps to find and fix exploitable web application vulnerabilities with automated dynamic application security testing.
This post will have the monthly Fortify WebInspect Tips and Tricks which will be a consolidation of various common issues in Fortify WebInspect. Do check out this article for troubleshooting tips and tricks for other tools.
Fortify WebInspect – Tips and Tricks – Jan 2021
1. Running a scan on the site with the real-user entries successfully
The users often try to log in; they are unable to set up the scan with the login process’s real-user entries. Usually entering an ID and password is all that is needed for logging in on the site. And after that, the site sends an automated email with an ‘auth code’ that users need to proceed forward. The usual queries from users are regarding the configuration of the scans. It seems that the interactive scans do not apply to this case.
This error can be solved by reading the PIN that is received. It is necessary to read the PIN specifically from a .txt file that is present on the computer that needs to be updated with the current PIN.
- You need to record your macro.
- Then you need to make sure that it does playback. Then you need to let it determine a logout condition on its own.
- After that, you need to save the macro to prevent losing the changes made, but do not close it.
- Then you need to select the Toolbox that is available from the Side Menu.
- Then you need to add a Wait step above the PIN entry. It is recommended that you begin with a value of 20 seconds and later adjust according to your needs.
- After that, you need to change the PIN entry to read the value of a text file, as given below:
- The action should be Type.
- For the argument’s value, the saved path would be:
- You need to add a text file named pin.txt to the location you assigned in the previous steps recently. In the wait step 3, you need to edit and then save this text file respectively with the PIN that you get.
- Then the wizard on the screen would suggest that you play the macro again to check. So, you need to check, and when it is working, you need to save it for the scan.
- Then you need to save a copy for that select File. Then select Save As, then name it as required for future purposes.
- Then the automatic time out may cause the scan to halt or time out. When that happens, you can increase the Request timeout to give more room for the wait time. Accordingly, the default time out is approximately 30 seconds, which is barely long.
2. Updating your WebInspect product without the Internet
Users come across many queries regarding the Fortify WebInspect Offline Smart Update. Some of the most significant ones are about how to update their WebInspect product without Internet access.
WebInspect utilizes SmartUpdate to retain the Secure Base, including all the rules, checks, database. It keeps it updated, yet Smart Update needs access to the fortify servers to execute this procedure. Hence, the users’ major question is if it is possible to update the database manually without having an internet connection on the computer.
In accordance with the authorized documentation, the user needs to contact support to Open a support case. The Fortify Customer Support personnel will provide the offline FTP server URL along with all the login credentials required.
3. Fixing the absence of the activity bars in the Network or Analysis graphs
It often happens that users are unable to locate any bars of activity in the Network or Analysis graphs when they are running a scan. The users observe that the scan runs perfectly, and it finishes accurately. However, the problems arise when the graphs do not generate after that. The WIE, Sensor, and SSC remain on the same VM, which is an unsupported configuration. Also, the FIPS is enabled in the background of the system.
The noted activity shown in the graphs that were collected are mentioned below for reference purpose:
The Network graph is getting the network utilization of the WebInspect process from Windows.
And the analysis one is getting the CPU utilization of the WebInspect process from Windows.
There may be issues related to permissions in the environment, preventing WIE from seeking the process stats from Windows. The most plausible solution for this problem is to rectify the permission errors.
4. Method to load TruClient not properly when it misbehaves
It usually happens with the users that the left pane or sidebar of TruClient cannot load completely. This occurs when TruClient (Login Macro Recorder – Macro Engine 5.0 or Workflow Macro Recorder) is used, but the error message is displayed on the device screen. Not only is the sidebar unable to load, but the toolbox is also missing, and the menu is not the accurate one.
This error’s root cause is that the internal calls are blocked by the user’s web filter or proxy. When the users are trying to load elements on specific ports, the traffic is blocked completely.
It is quite easy to fix this issue; you just need to add some exclusions not to filter local traffic; for that you can follow the steps given below:
- You need to navigate to the Control Panel and then double click on Internet Options.
- Then click on the Connections tab and then select the Lan Settings option.
- Then you need to select the box to Bypass proxy server for local addresses, or you can perform the following:
You need to select the Advanced button.
Then you need to Add the following to the exceptions list:
4. Then, you need to click on the OK option to confirm and save the settings for each of the open Internet Properties dialog boxes just made.
5. Adding parameters from login macro in WIE Guided Scan
Users often wonder where to add/edit values for the login macro parameters in WIE Guided Scan.
Whenever the users scan with their own authentication, then it becomes preferable not to edit the macro. Then the outcome documentation shows that the solution to this is the reason for the parameterized macro. Notables are appearing on the screen when the values are to be entered for the parameters. Where I can enter the values for the parameters.
The professional developer knows about this issue in Guided Scan via the WebInspect Enterprise (WIE) Desktop. And also aware that the parameter table does not show up after choosing the macro.
You can use the workaround given below to solve this issue:
- After the selection of your login macro in the Guided scan, you need to select Advanced in the settings from the top menu.
- Then you need to scan Setting Window and then select Authentication.
- Then under Site Authentication, you need to locate the macro selected along with a Login Macro Parameters table.
6. Initiating the WebInspect Enterprise Website Scan at the occurrence of an error
It often happens that the users are not able to start the WebInspect Enterprise Web Site Scan. When they log in to the WIE server and try to start a scan, that is the usual process. They would open the console and then use it to open the Internet browser. When the Internet Explorer page loads from the console, none of the user’s applications are visible. That specific area is blank, where the list of the applications should have been.
The following solution is for Internet Explorer 11:
- You need to click on Gear.
- Then find Compatibility View Settings and click on it.
- Then in the Compatibility View Settings dialogue, you need to UNCHECK Display intranet sites in the Compatibility view.
- After that, close it, then restart the Internet Explorer and then try again.
7. Instruction to solve the malfunctioning of SSC after a scan on WIE
Usually, whenever there are any vulnerabilities detected, it is usually resolved on its own on SSC. Yet users seem to have some issues regarding this, especially after a scan finishes on WIE. Whenever there is an error after the detection, the result is uploaded to SSC without any difficulties. And then, some need changes are applied on the site, and another scan will be generated.
And after that, WIE will react to the issues and then mark those issues on SSC as resolved. The issue arises when that is not happening automatically as the users are meant to visit WIE. Not only that, after that, they need to perform some steps:
- Open the Scan,
- Then select on the Not found tab,
- Then change the SSC Status and then select Publish scan to SSC, and only after these steps are they able to update SSC Status.
It could be due to some issues in the values set to true. Then it must have been set to upgrade to 20.1 overwrote the web.config file.
Users can simply edit the web.config file to activate Fortify Software Security Center to directly mark as fixed any vulnerability that was not visible in the earlier scan. You can easily access this feature with the help of the steps given below:
1. You need to open the file that is given below:
C:\Program Files\Fortify\Fortify WebInspect Enterprise 20.1.0\ManagerWS\web.config
2. Then, you need to edit the value and change it from False to True.
3. Now save it, and then close the file.
8. Fixing the problems related to scanning with Web Inspect when outdated or weak
It is observed that users have errors while scanning with Web Inspect. That happens due to its outdated or weak protocols and because the cipher suites are disabled.
Users cannot render/scan any of the HTTPS sites, but HTTP sites on their own work without any problems.
This issue can be solved easily; we just need to pinpoint the cause of this error and act upon it. Fortify Web Inspect (WI) needs the OS mainly to support the old outdated or weak protocols and the cipher suites for WI. It is necessary for testing the weaknesses. This error could have happened due to the OS being locked down to restrict all of the outdated or weak ciphers, SSL/TLS, etc. Generally, the system is locked down through GPO.
You need to inspect the System logs in the Windows Event Viewer for any SCHANNEL messages. It is also advised that a quick test is performed in order to remove all Group Policies returning the OS to a non-hardened state. This is a very easy and efficient path to establish that the issue is present in the OS and that is removing other upcoming issues.
Users can manually compare a familiar working OS registry config side by side with the customer’s non-working one; this way, they can easily know the differences.
Users also need to make sure that the Web Inspect Root cert is present in the Trusted Root Certification Authorities store. It is also needed to authenticate that they do not have any of the SSL/TLS locked down at the Operating System level.
Thus, we have concluded that this appears to be an OS or .NET SSL-related issue most of the time. As the OS/.NET SSL is locked down in a specific way, WI is unable to perform a proper handshake. As previously mentioned, this is generally because of a combination of registry keys/GPO and the Windows patches.
9. Solving the ‘Scans failing due to the agent not found’ error
The users often go through some problems when they have performed an upgrade to 19.2 of the Web Inspect. The scans result in a failure due to:
“Agent not found” "Web inspect Agent Not Detected"
After that users try to locate an option to ignore the agent feature when they are setting up the template. Some more details about the scan customer are performing:
The customer has verified the URL-Scan type is standard and method is audit and crawl-Policy is Audit and Crawl-Application authentication is set and confirmed-Customer is also scanning a specific path on this application and has told the scan to only scan that path and subdirectories.
This issue is merely related to the Web Inspect Agent but it was actually related to Secure Channel between Client (WIE and LMR) and the server (Web App Server). The specific error that occurred on the macro recording:
The client and server cannot communicate, because they do not possess a common algorithm.
This problem can be fixed as well, the user needs to upgrade the Java in the Web App Server. It should strictly be based on Linux OS. This feature allows communication between the client and the server using TLS 1.2. And before this, previously the Web App Server has only activated up to these: SSL 3.0, TLS 1.0, and 1.1.
10. Generating a user instance of SQL Server successfully
It happens that when the users are running a scan in Web Inspector on a sensor they encounter the error given below:
“Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed.”
Basically, this error is related to SQL Server Express but there can be other reasons as well. Other reasons for this are mentioned below:
- Due to the corrupt Microsoft SQL Server Express Cache (or a version change of SQL Server Express).
- Permission related issues.
- Due to Single-use settings
- Due to the corrupted install of SQL Server Express
- Due to the third party Antivirus / Anti-Malware misbehaving with Web Inspect.
You need to login to the computer through the user that will enable the execution of the scans. For a Sensor, this could be a service account as well. These specific user accounts are necessary, and they must have local administrator rights on the workstation/server.
1. You need to make sure that no antivirus or anti-malware software is running in it. You need to disable it or else the accurate exclusions are put into place.
2. Then you need to make sure the SQLServerExpress service is running in the background with the accurate credentials.
They need to be set to Local or Domain Service Account, not the Local System or any Network Service.
3. Then you need to ensure the SQLServerExpress process and all of the Web Inspect processes are stopped or ended.
4. (skip this for the sensor) Then you need to delete Scans.XML from %USERPROFILE%\AppData\Local\HP\HP WebInspect\ScanData\
Please do not delete the entire folder or you will lose all of your scans.
5. Then you need to delete the SQLEXPRESS folder from %USERPROFILE%\AppData\Local\Microsoft\Microsoft SQL Server Data\
6. Once you have deleted the cache, you need to start the SQLEXPRESS service.
7. Then you need to run SQLCMD (located in C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\<ver>\Tools\Binn) in order to connect to the default SQLExpress instance. <ver> could be 110, 130, or some different value it totally depends on the version of Microsoft SQL Server that is installed.
sqlcmd.exe -S .\SQLEXPRESS
8. Then you need to execute the commands given below, both of the commands are to be run separately:
sp_configure 'user instances enabled' ,1 ; go reconfigure; go
In case the steps given above do not solve the problem then the user may need to open a ticket with Fortify Support for further analysis.