Getting Started
This support article provides the requirements for installing an on-premises, air-gapped deployment of ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) on a Kubernetes cluster. We will also cover the required system specifications to host the deployment, configuration requirements, and an installation process overview.
BinLens uses Kubernetes to increase binary vulnerability analysis speed and scalability. This is accomplished by parallelizing the computation required for binary assessment across multiple nodes in a Kubernetes cluster.
Technical Requirements:
To facilitate a successful on-prem BinLens Kubernetes deployment, the following system specifications are recommended:
- Each node in the Kubernetes cluster has a minimum of 4GB of RAM (recommended 8-16GB), and one node must be a minimum of 6GB.
- Kubernetes cluster nodes must have a minimum of 80GB of available storage.
- All remaining nodes in the Kubernetes cluster must have a minimum of 20GB of available storage.
- Each node in the Kubernetes cluster has a minimum of 2 CPU cores (recommended 4 CPUs).
- Minimum of 3 nodes in the Kubernetes cluster.
Preparing for a BinLens Kubernetes Cluster Deployment:
Estimated time to completion: two hours
This preparation guide assumes you have multiple virtual machines and bare-metal machines on the same network that the Kubernetes cluster can use.
Preferably, the sole purpose of these machines should be to act as nodes in the BinLens Kubernetes cluster (e.g., the nodes should not be used for other computations). If this is not the case (e.g., you have a pre-configured Kubernetes cluster running pre-existing applications for your organization), then the minimum technical requirements must be increased accordingly. For example, suppose your pre-existing Kubernetes applications consume approximately 4GB of RAM on every node in the cluster. The cluster must have at least 8GB of available RAM to support BinLens.
Additionally, this guide assumes that a one-time Internet connection can be performed to download the BinLens installer files and container images necessary from the ObjectSecurity Secure SFTP Portal to run the BinLens Kubernetes deployment. If this is not the case or raises any other concerns, please let the ObjectSecurity Sales and Support Team know. Alternatively, we can send you the installer files and container images that are approved for your air-gapped lab via flash drive, disk, or another offline method.
Cluster Setup and Configuration:
It is preferred that a net-new Kubernetes cluster be configured using MicroK8s (https://microk8s.io/), as the Kubernetes distribution will primarily support BinLens. Other Kubernetes distributions (e.g., Rancher, K3s, etc.) are also supported.
Instructions for installing and starting with MicroK8s can be found here: https://microk8s.io/docs/getting-started. It is important that the add-ons mentioned in Step 6 of the article be enabled:
Instructions for using MicroK8s to create a multi-node cluster (i.e., adding nodes) can be found here: https://microk8s.io/docs/clustering. Once complete, a Kubernetes cluster containing at least three nodes that meet the required system specs should be running.
Additional documentation for configuring and managing a production Kubernetes cluster can be found here: https://kubernetes.io/docs/setup/production-environment/.
If you are using an insecure docker image registry (e.g., a registry exposed over HTTP instead of HTTPS), you must configure microk8s to be aware of the insecure registry. This can be done by following the instructions here: https://microk8s.io/docs/registry-private. Other Kubernetes distribution may have different requirements for working with insecure registries, so please refer to your Kubernetes distribution’s documentation for details.
Kubectl
A Kubernetes cluster is managed using a command-line tool called Kubectl. Kubectl is used to create, destroy, and update Kubernetes resources. MicroK8s comes with Kubectl pre-installed and can be aliased using the following command (which may be placed in ~/.bash_aliases):
Alternatively, basic installation instructions for Kubectl can be found here: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/. Documentation for using Kubectl can be found here: https://kubernetes.io/docs/reference/kubectl/.
Helm
Helm (https://helm.sh/) is a package manager for Kubernetes that installs Kubernetes applications using a packaging format called chartsInstallation. BinLens is installed as a Helm chart, so it is necessary to install Helm. Installation instructions can be accessed here: https://helm.sh/docs/intro/quickstart/.
Helm uses kubectl to run commands when managing charts. It uses the kubectl config found at $HOME/.kube/config. By default, microk8s does not store its configuration here. This can be remediated with the following command:
Container Image Registry
A Docker container image registry hosted in (or accessible to) the same network as the Kubernetes cluster is required. This registry can be hosted either inside or outside of the cluster itself. This registry stores the images required to run BinLens. Instructions for creating and deploying a registry can be found here: https://docs.docker.com/registry/deploying/.
Additionally, it is recommended that your username/password protect this registry. Instructions to do so can be found in the same article: https://docs.docker.com/registry/deploying/#restricting-access.
Network Filesystem Dependencies
BinLens Kubernetes deployment utilizes a Network File System (NFS) to store binary assessment result data. This NFS does not have to be configured manually and will be installed as part of the Helm chart. However, each node in the Kubernetes cluster needs specific dependencies configured to host/communicate with this NFS. These dependencies can be installed and enabled by running the following commands on each node in the cluster.
NOTE: The commands above reflect Debian-based systems. Other operating systems may require a slight tweak.
Installation of the BinLens Helm Chart
Once the Kubernetes cluster has been configured according to the previous instructions, BinLens may be installed according to the following steps:
1. Download the following files from the ObjectSecurity Secure SFTP portal:
a. binlens.tgz: The BinLens Helm Chart, exported as an archive file.
b. binlens_install_images.sh: A shell script used to pull the docker images required by BinLens and push them to a local docker registry.
c. binlens_license: A license used to authenticate the BinLens deployment.
2. Run the binlens_install_images.sh script to push the required docker images to the local image registry. To save storage space, the docker images should be deleted from the host’s set of local docker images (by default, they are stored redundantly in your local image registry):
3. One of the nodes of the cluster will be used to store all binary assessment data: this node will run the binlens-nfs-server pod. You must specify the node you want to host this pod by running kubectl label nodes
4. Install the Helm Chart using Helm install. Helm installation includes the following optional parameters, each of which
should be changed depending on the installation environment:
a. registry: The URL and port of your local docker image registry.
b. registryUsername: The username used to access your local docker image registry.
c. registryPassword: The password used to access your local docker image registry.
d. memLimit [16]: The amount of memory (in Gi) you wish to make available to the BinLens deployment. Increasing this number will enable more assessments to run in parallel, dramatically increasing the speed of all analyses. The binlens-operator pod will consume 4Gi of memory on one of the nodes, so the value of memLimit should be set with this in mind. For example, if you have a Kubernetes cluster with 20 Gi of total memory, you must subtract the 4Gi of memory required by the binlens-operator and set memLimit to 16Gi.
e. hostPath [/var/nfs]: The file path on a host node wherein data will be stored.
f. nfsIP [10.96.5.74]: The static internal ClusterIP of the binlens-nfs-service. This value may change if the default internal ClusterIP (10.96.5.74) is allocated or unallocatable for various reasons.
When running Helm install, these optional parameters can be set using the –set argument. An example follows:
This example installs the BinLens Kubernetes deployment using a container image registry that can be found on the network at registry:5000, wherein this registry is protected with the username admin and the password password. The deployment only uses up to 16GB of RAM across the whole cluster due to the memLimit argument.
5. Use your license file (binlens_license) to validate the deployment by logging into the platform as the SUPERADMIN and uploading the license file on the Settings Page. The settings page can be found at http://localhost:30004/#/settings once the deployment has been installed. Without a valid license, BinLens will refuse to start any assessments.
Installed Kubernetes Objects:
A successful installation of the BinLens Kubernetes deployment will install the following Kubernetes Objects (https://kubernetes.io/docs/concepts/overview/working-with-objects/):
- binlens Namespace: This namespace incorporates all the following Kubernetes objects together so that they may be cleanly separated from other applications running on pre-existing Kubernetes clusters.
- binlens-registry-secret Secret: This secret encodes the local container image registry’s username and password such that images may be pulled from it at runtime.
- binlens-nfs-server Deployment: This deployment hosts a Network File System used by other Deployments/Pods running in the cluster.
- binlens-nfs-service Service: This service exposes the binlens-nfs-server IP address for use inside the cluster.
- binlens-operator Deployment: This deployment performs the bulk of BinLens’s assessment orchestration, authentication, extraction, and input handling. It spawns other assessment containers at runtime to perform binary analyses.
- binlens-operator Service: This service exposes the user interface of the binlens-operator outside of the cluster as a NodePort (i.e., port 30004).
- binlens-operator-service-account ServiceAccount, binlens-operator-role Role, and binlens-operator-rolebinding RoleBinding: These objects are used to give the binlens-operator deployment permissions to run binary assessment pods within the cluster.
- binlens-pv Persistent Volume, binlens-pvc Persistent Volume Claim, binlens-nfs Storage Class: These objects are used to wrap the Network File System such that other Deployment/Pods may perform read/writes to/from it.
At runtime, ephemeral Pods are spawned and despawned within the cluster by the binlens-operator while performing binary analyses.
Uninstallation
To uninstall BinLens from the Kubernetes cluster, the following command may be used:
How-To Unzip Files Using 7-Zip File Manager
Certain binary file types are not supported for analysis until decompressed. For example, a .zip file will raise the following error when uploaded for analysis:
If you encounter this, refer to the following instructions on decompressing and uploading these file types for analysis.
The following file types are compressed:
- .upn
- .bin
- .zip
- .rar
- .tar
The user must first install a file decompression utility on their device to upload these file types.
There are some popular, free, and open-source file archivers available (ObjectSecurity is not endorsing any of these tools, nor do we receive any form of benefit from you using these tools.):
PC and Mac compatible options:
7-Zip File Manager – 7-Zip File Manager | download
WinRAR – WinRAR | download
Also available for Mac users is the built-in Archive Utility.
For this tutorial, we will be showing how to decompress files using 7-Zip File Manager. However, the process is the same for all tools above.
1. Once installed, open 7-Zip File Manager.
2. Within the 7-Zip File Manager, navigate to the location of the compressed binary file. In this example, we are uploading the contents of uconnect.upn for analysis. Once found, double-click the file to unpack.
3. Once unpacked, the file contents will be visible within the active directory. From here, locate the file contents you want to run binary analysis on, select all of the associated files, and right-click.
4. Choose the “Copy To…” option.
5. Choose the location where you would like to copy the files and hit “OK.”
6. Now, navigate to ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) and select “Upload Files” on the binary upload prompt. Select your files from the location you chose to copy and upload the binary files.
How-To Install ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Offline VM Version in VMware or VirtualBox
To deploy BinLens on-premises and offline, you need to download the BinLens .ova file and deploy it on a virtual machine.
Before You Get Started:
– Check to make sure your system meets the minimum technical requirements.
– Install 7-Zip File Manager
– Install Oracle VirtualBox (or VMWare)
[PART 1] Download and Combine .zip Instructions:
Download the BinLens .ova from the ObjectSecurity secure download portal provided to you.
- Enter your unique downloader login credentials provided. Please note that these are not the same credentials as your BinLens login credentials. If you have not already set up your downloader account, follow the invite link you were provided to create your account and validate your email.
Download each of the .ova fragment files (.001, .002 etc.) and the license file. Downloading the .ova files may take anywhere from 30-60 minutes.
Next, open 7-Zip File Manager and navigate to the file location where the downloaded files are being kept. Within 7-Zip File Manager, right-click on the first file titled “OT_AI_V…_.zip” and select the “Combine files…” option.
Now you will have access to an .ova file called binlens.ova. Proceed to the next part of this tutorial for how to import the .ova into your virtual machine platform.
[PART 2] How-To Import BinLens Using Oracle VirtualBox
Open Oracle VirtualBox and select File>Import Appliance.
Next, select the icon highlighted in red and locate the binlens.zip file obtained from the steps listed above in the download portion of this tutorial. Once the file has been selected, click Open and then Next.
Set the configuration, so there are at least 4 Cores for CPU and 16000 MB for RAM. To set the property, double-click on the field and enter the value. Once finished, click Import in the bottom right corner to continue. The Import may take a few minutes.
You are now ready to log in to the platform! Click Start within VirtualBox to boot up the virtual machine containing BinLens.
[PART 3] How-To Import BinLens Using VMWare
Open VMWare and select “Open a Virtual Machine.” Next, please navigate to the location where your binlens.ova file is stored, ensure it is selected, and click Open.
Next, enter a name for the virtual machine:
Name: ObjectSecurity's BinLens
The storage path will automatically be filled in once you enter a name.
Once finished, click Import. The Import may take a few minutes.
Once the Import has been completed, click “Edit virtual machine settings.”
Set the configuration, so there are at least 4 Cores for Processors (CPU) and 16000 MB for RAM (Memory). Once finished, click OK in the bottom right corner.
ObjectSecurity’s BinLens™ Offline VM version is ready to be deployed.
How-To Import a Pre-Built ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Metrics Kibana Dashboard
This article will explain importing a pre-built BinLens Metrics Dashboard into Kibana. A sample dashboard will be included towards the end of this article.
This article aims to expedite the process of building a custom BinLens metrics dashboard by showing how to import one that already shows some useful metrics about assets, binaries, and analysis results. For more instructions on configuring Kibana dashboards, please refer to the Kibana documentation.
Importing a Dashboard
3. In the top right corner, select “Import”.
4. Click in the “Import” section and then select the dashboard file, which can be downloaded from the attachments of this article, then click the blue “Import” button.
5. The dashboard has now been imported and can be viewed under the “Dashboard” section of the hamburger menu in the top left corner. The dashboard will be imported under the name “Demo Dashboard.”
This dashboard can be modified however the user pleases.
How-To Install ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Server Logs and seek help from the support team
If you ever encounter an issue with BinLens, it may be useful to look through the server logs for any indication of failure. Once you’ve identified an issue with the BinLens and obtained the server logs covering the time when the issue emerged, you can submit a ticket through the support portal with the server logs attached and request for a team member to take a look.
Obtaining server logs:
To obtain the server logs, navigate to the right-hand navigation panel, near the logout and knowledge base buttons.
Click on the “Download Server Logs” button.
Once clicked, a download will begin and the server logs will be found in a text file within your downloads.
After you’ve obtained your server logs, submit them to a team member to receive support regarding BinLens issues
How to Customize a Report
Some organizations may value the detection of certain vulnerabilities over others. For example, a specific CVE may be considered highly threatening in one organization, whereas the same CVE is considered unimportant in another. For this reason, Report Customization is necessary,
To begin customizing a report, either navigate to the “Reports Page” icon, using the left-side menu bar, or by selecting the “Customize Report” option while viewing a binary assessment on the Binary Analysis page.
After selecting a specific binary to customize a report for, the following screen will appear:
Here, you can see a PDF preview of your custom report on the left, with customization options on the right. Specific vulnerabilities appear listed out in the report like so:
You may toggle report content on or off using the right-side-bar. For compliance reasons, no new content may be added to the report. Report content is simply shown or hidden.
How to Share/Download a Report
Customized reports may be downloaded and then shared via a single button press. Once you have customized the report to your liking, simply press the download button to the right of the report PDF:
This will produce and download a PDF file that may then be printed, emailed, or shared with anyone you like.
How-To Apply a Patch to the ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Offline VM Version
To apply a patch to BinLens, you first need to download the BinLens patch files from the ObjectSecurity SFTP download portal.
Before You Get Started:
– Track down your SFTP download portal credentials, or ask an ObjectSecurity support team member for your login information.
Once you have your ObjectSecurity SFTP login credentials on hand, navigate to the SFTP Download portal here and sign in.
Once you’ve logged in, accept the EULA
Once you’ve accepted the EULA, download all of the patch.zip files from the portal.
Now that you’ve downloaded the patch.zip files, navigate to your BinLens instance and go to the settings page. From the settings page, go to “Patch Management”. Click “Choose File” to select your downloaded patch file and apply it to your instance.
While the patch applies a spinning wheel will be visible on screen to indicate that the patch is loading. This will take 1-2 minutes.
Once the patch has completed applying, shut down the virtual machine using the “Send the shutdown signal” option.
After shutting down, restart the VM. Once the VM has restarted, the web page UI can be refreshed and the new patch will be active.
To facilitate a transparent user experience and to enable full third-party integration with ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform), OpenAPI Initiative functionality is natively integrated into the platform.
The “OpenAPI Page” details the API routes for interacting with BinLens. The API routes, corresponding description, and ‘Send” button are all listed on the left panel. Clicking the “Send” button queries the route, producing output on the right panel. Additionally, you may toggle between different API routes via a dropdown menu:
Additionally, some API routes require additional parameters or arguments. These parameters and arguments are listed on the left panel if needed:
External Usage
Our API may also be queried externally from any network connection with access to your deployment. Depending on your deployment type, the URL used to query the routes will differ.
Offline/On-Prem Virtual Machine:
Typically, an Offline/On-Prem virtual machine will be accessible via localhost. In this case, the following URL format will suffice:
https://localhost/rbui/
If your On-Prem virtual machine is hosted on a private network, the following URL format will suffice, with ip_address referring to the IP address of your deployment on your local network.
https:///rbui/
(The
Cloud Deployment:
For Cloud Deployments, the API will be accessible from anywhere on the Internet. The following URL will be used, with deployment_name referring to the name of your cloud deployment.
https://.objectsecurity.io/rbui/
(The
Note on bearer token:
Most BinLens API routes require a Bearer authentication token. You can learn to get this Bearer token under Authentication in the Available Routes section.
You can read more about Bearer tokens here.
Available Routes
This section provides a general overview of the purpose and output of each route. Information regarding the specific parameters and exact output schema can be found in the application itself.
General:
General routes handle the most basic usage of BinLens, mainly including fetching data to view.
- GET /assessor/getassets
You can use this route to get a list of your assets. Assets have a set of binaries that have each been analyzed.
- POST /assessor/getbinaries
Use this route to get the set of analyzed binaries in a given asset.
- POST /assessor/getresults
Use this route to get analysis results for a given binary.
- POST /assessor/getcwe
Get additional information on specific CWEs.
Assessments & Analysis:
These routes handle the analysis process, including the ability to queue up and start various assessments.
- GET /assessor/getassetprogress
Gets the current analysis progress of all ongoing analyses in the user’s current organization.
- GET /assessor/listbinaries
Gets the set of binaries uploaded to the dropzone.
- POST /saas/addfile
Uploads a binary to the dropzone.
- POST /saas/rmfile
Removes a binary from the dropzone.
- POST /saas/start
Starts the analysis procedure on the binaries in the dropzone.
Asset Management:
These routes handle the managing of assets after they have been analyzed. Various actions can be taken on assets, including deleting or updating multiple asset fields.
- GET /assessor/getnumnew
Gets the number of new assets in an organization. New assets are those that haven’t been viewed yet after being analyzed.
- POST /assessor/deleteasset
Deletes an asset from an organization.
- POST /assessor/renameasset
Renames an asset.
- POST /assessor/update/assetdescription
Updates an asset’s description.
- POST /assessor/updateassettype
Updates an asset’s type.
- POST /assessor/markassetviewed
Marks an asset as viewed.
- GET /saas/asset/{assetid}/audit
Gets the audit log for an asset.
Facility Management:
These routes handle the management of facilities. Facilities each have a location and set of child assets located within the facility.
- GET /assessor/getfacilities
Gets all the facilities in the organization.
- POST /assessor/createfacility
Creates a new facility.
- POST /assessor/updatefacility
Updates an existing facility.
- GET /assessor/getassetsinfacility/{facility_id}
Get the assets in a facility.
- GET /assessor/deletefacility/{facility_id}
Deletes a facility.
- GET /assessor/getdefaultfacility
Each organization has a default facility that cannot be deleted. All assets in an organization are analyzed in this default facility by default.
Authentication:
Authentication routes manage user login, role-based querying, and 2FA.
- POST /saas/mfalogin
Gets an “access_token” that may be set as the Bearer Token when calling the “/saas/validate_totp” route. This route acts as the first factor of 2-factor authentication. “/saas/validate_totp” acts as the second factor.
- GET /saas/generate_totp
Generates a time-based one-time password for the current user. This TOTP can be converted into a QR code and scanned with Google Authenticator for 2 Factor Authentication.
- POST /saas/validate_totp
Validates a user’s time-based one-time password and returns to them a token that may be set as the Bearer Token when accessing all other routes of the API. This route acts as the second factor of 2-factor authentication, with “/saas/mfalogin” being the first.
- POST /saas/auth/user/add
Creates a new user.
- POST /saas/auth/password
Updates a user’s password.
- GET /saas/auth/userinvite/user/{user_id}
Invites a user to the server. Returns a token specific to the “user_id” set in the API route. The token may be redeemed by the user using the “/saas/auth/userinvite/redeem/{invite}” route.
- GET /saas/auth/userinvite/redeem/{invite}
Redeems an invite generated using the “/auth/userinvite/user/{user_id}” route. Returns a token that may be used to set up a new account.
- POST /saas/auth/user/eula/accept
Accepts the EULA for the calling user.
- GET /saas/auth/user/{userid}/profile
Gets a user’s profile.
Organization Management:
These routes handle the managing of organizations. Organizations each have a set of child facilities and a set of child users. Organizations may have multiple administrators. The server SUPERADMIN is a part of every organization, and there may only ever be one SUPERADMIN at a time.
- GET /assessor/getdashboard
Gets the data needed to generate the dashboard on the UI.
- GET /saas/auth/userall
Gets all the users in an organization.
- POST /saas/auth/user/addroles
Assigns a user new roles in an organization. This is equivalent to adding a user to an organization, should the user not already have roles in the organization.
- POST /saas/auth/user/removeroles
Remove roles from a user in an organization. This is equivalent to removing a user from an organization, should the user not have any remaining roles in the organization after this route has been called.
- POST /saas/auth/user/setorg
Swaps the org a user is currently viewing.
- POST /saas/auth/organization/add
Adds an organization.
- POST /saas/auth/organization/update
Updates an organization.
- GET /saas/org/audit
Gets the audit log of an organization. The audit log tracks the history of all analyzed assets in the organization.
This article will explain configuring ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) to send logs to Elasticsearch, Logstash, and Kibana (ELK) Stack for more accessible logkeeping and parsing.
ObjectSecurity’s BinLens™ UI provides an excellent interface for viewing results from your analyses. However, sometimes, users would like to search for assessment results with more granularity or create more complicated search queries for their results. This can be accomplished with the assistance of ELK Stack, which provides the Kibana query language interface for finer search support.
Configuring ELK Stack to Accept Logs from BinLens
To receive logs fromObjectSecurity’s BinLens™, the user must first configure a Logstash pipeline to accept logs from BinLens. To do this, the user will need root access to the computer or server hosting their ELK stack.
- Creating a Logstash Config file. First, the user must create a new Logstash configuration file.
With root access, navigate to ~/etc/logstash/conf. d on the ELK server. Once there, the user should create a new configuration file, “objectsecurity.conf,” for ObjectSecurity-specific logs. By default, Logstash reads any file with the extension “.conf” as a valid configuration file. ObjectSecurity’s BinLens™ supports HTTP, UDP, and TCP protocols for sending logs to the ELK stack, so depending on which protocol the user would like to use, they may edit the following configuration file as they wish. Paste the contents below within the file to open ports for receiving logs via all three protocols (the user may delete whichever input blocks they don’t plan on using):This file will create a Logstash configuration file that will receive logs via HTTP at port 31311, TCP at port 31312, and UDP at port 31313. Please note that this configuration expects Elasticsearch to be hosted on port 9200, the default port for Elasticsearch. If you have changed the Elasticsearch location, you must update the port number accordingly.
In addition to this, if your Elasticsearch has authentication configured, you will need to update the output fields with the information used to authenticate for your Elasticsearch instance:
-
Activating a Logstash Pipeline. The user must start the pipeline after creating the configuration file for BinLens logs.
Navigate to the ~/etc/logstash directory on the ELK server. From here, use your favorite editor (vi, vim, or nano for example) to open the “pipelines.yml” file. Add the following lines to the file to enable the pipeline, then save the file. Please note that if you have named your logstash config file something other than “obejctsecurity.conf”, you will need to update the path.config line to agree with your chosen file name.
- pipeline.id: objectsecurity path.config: "/etc/logstash/conf.d/objectsecurity.conf"Once these steps have been completed, your logstash configuration file is now active and your pipeline is ready to receive logs at the ports you have enabled in the configuration. Now that this is done, you are ready to configure BinLens settings to point to your ELK stack and begin sending logs.
Configuring ELK Stack Location within ObjectSecurity’s BinLens™
To get started using the ELK stack integration feature, the user will need to go to BinLens settings and insert the information for the Elasticsearch IP and port that will be receiving the logs. To find the ELK stash configuration settings within BinLens, go to Settings > Deployment > Configure ELK Stack. From here, the user must select the protocol they would like to use to send the logs, the IP to send the logs to, and the port which the IP will be receiving the logs.
The protocol you select should agree with the whichever protocols you enabled in the Logstash configuration, which you set within the “Creating a Logstash Config file” step of the “Configuring ELK Stack to Accept Logs from BinLens” section outline above.
Note: The user must configure the port from within the Logstash configuration files (these files are stored at /etc/logstash/conf. d). For more info about how to configure the Logstash and the inputs, please refer to the “Configuring ELK Stack to Accept Logs from BinLens” section above on how to set up Logstash and ELK Stack for the purposes of this feature.
To clarify, the IP entry should be the IP of the instance hosting the user’s ELK stack. Once the information has been entered correctly, select Submit to save the settings for BinLens logging destination.
To verify that the configuration is set up properly, each time the submit button is clicked, a test log will be sent to the configured ELK stack instance. The best way to test the configuration is to modify the fields and click submit until the ELK Stack instance receives the test log.
This Getting Started Guide serves to help new users login into ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) for the first time. This guide also briefly explains how to analyze your first OT/ICS asset binary files for weaknesses (CWEs), vulnerabilities (CVEs), and unpublished vulnerabilities (Zero-Days).
1. Receiving the first invite link to and navigating to the application.
In order to begin using the application, another user must send you an invitation link.
2. Creating a password.
You will then be prompted to create a password:
Please choose a secure password, and enter the same password twice to continue.
3. Setting up Google Authenticator.
You will then be prompted to set up Google Authenticator. Google Authenticator can be downloaded on your mobile device using one of the following links:
Once you have downloaded the Google Authenticator app on your mobile device, add your account by following the instructions listed below the QR code. Once your account has been added to Google Authenticator, you will see a 6-digit code that updates every second or so. Please enter this code now, as well as when prompted on subsequent logins.
4. Starting your first analysis.
To start analyzing your first asset, please select the big-blue plus button in the top left corner of the screen:
This will then prompt you for information regarding the asset including asset type, name, and a set of binary files:
Binary files can be uploaded using the “Upload Files” button, or by simply dropping any number of binary files onto the page.
Once you are satisfied with your asset, press “Start Analysis” to begin the analysis process. This process may take several minutes. Analysis progress is shown in the top right corner of the screen.
5. Viewing the produced analysis results.
Once your asset has finished analyzing, the following numbered blue icon will appear next to the Binary Analysis Page navigation link:
Please click on this navigation link to navigate to the Binary Analysis Page. There, you will see your newly-analyzed asset displayed:
Click on the asset to view it in detail. The binary files you uploaded with your asset will also appear and may be clicked on to view in further detail.
Congratulations on analyzing your first asset!
FAQ’s
Dedicated Compute Machine:
We suggest that the machine being used to host ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) On-Prem, Offline VM deployment be dedicated. The host machine should not be used to run any other applications, processes, or services that may cause resource conflicts with ObjectSecurity’s BinLens™. This prevents the installed On-Prem, Offline VM from encountering resource restriction issues (e.g., failure to properly access the RAM, CPU, and storage you allocated for it). If a dedicated machine isn’t able to host ObjectSecurity’s BinLens™ in your environment, we recommend that you make sure the installed VM has access to the computational resources you allocated for it at all times by other means.
Backup:
We suggest that you create a backup/copy of the ObjectSecurity’s BinLens™ On-Prem, Offline VM .OVA file provided to you by ObjectSecurity before proceeding with the installation.
Computer (hosting VM) Specifications:
- RAM – minimum of 16GB of usable RAM – 32GB to 64GB of usable RAM is recommended
- CPU Cores – minimum 4
- Available Storage – minimum 80GB of available space
- System Type – 64-bit operating system, x64-based processor
Virtual Machine Options:
- Oracle VirtualBox – Link to Oracle VM VirtualBox Download Page
- VMware Workstation Player – Link to VMware Workstation Player Download Page
Note: Other options may be available, but the above have been tested.
[Optional] Multi-Factor Authentication Device:
Note: Organizations may choose to have MFA disabled if they are in an environment where mobile devices/other devices are not permitted. If you need this feature disabled, please email ObjectSecurity’s BinLens™ Support Team.
- Google Authenticator [Recommended] on any Mobile Device – Link to Google Authenticator Download on Google Play
- Other rotating time-based code authenticator apps are also compatible.
When importing ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Offline VM .OVA file to VMware Fusion, Workstation, or Player, you may see this error:
The import failed because .OVA did not pass the OVF specification conformance or virtual hardware compliance checks
If you see this error, click “Retry” with lower specifications to relax the specification and restart the import.
For more information, please reference this support article on how to import a VM from the VMWare Support Documentation.
To Receive the Virtual Appliance Package File:
- Via ObjectSecurity Provided Secure FTP – ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Support Team will provide the user with login credentials to access the ObjectSecurity SFTP portal, where the .OVA package can be downloaded from.
- Via End User Provided Secure FTP – Please provide ObjectSecurity’s BinLens™ Support Team with the login credentials to upload the .OVA package to your secure file transfer system.
ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) offers extensive firmware image analysis capabilities. BinLens development team is always working on expanding coverage. Additional file types and architectures are added to the supported category frequently.
Note: Non-standard MIME-type binary files that produce “non-addressable” results.
Supported File Systems:
Ext4, JFFS2, YAFFS, UBIFS, SquashFS, NTFS, FAT, ExFAT, UFS 1, UFS 2, EXT2FS, EXT3FS, HFS, YAFFS2, EnCase, AFF, EPROM
Supported Binary File Types:
Elf, WASM, PE/PE+, SPX, MBN/SBL bootloader, DEX, OMF, COFF, MZ, EXE, QNX, Fatmach-O, Mach-O, DYldcache
Supported Packed File Types (auto-extract and analyze the packed file):
ZIP, TAR, GZIP, BZIP2, XAR, BIN, MSI, MS CAB, ARJ, LZH, LZS, PMA, LZO, UPN, XZ, APK, ISO 9660, BIOS/UEFI
Currently Not Supported (updated 8.29.23):
Source Code, Browser/Interpreted Languages, JIT Languages (e.g., Java Class Files), Image Files (e.g., JPG, PNG, GIF, ART), Non-Executable Binary Files (e.g., TextEase (TE) CT Database Files, SELinux/Type Enforcement Files), Bell Labs Plan 9 EXE (untested)
ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) offers extensive firmware image analysis capabilities. BinLens development team is always working on expanding coverage. Additional file types and architectures are added to the supported category frequently.
Supported CPU Architectures:
x86-16, x86-32, x86-64, ARM32, ARM64, AARCH64, MIPS16, MIPS32, MIPS64, MicroMIPS, PowerPC, RISC-V, PA-RISC, SPARC 32/64, PIC 12/16/17/18/24, CR16, Z80, 6502, 8048, 8051, ARC, MSP430, AVR8, AVR32, SuperH, V850, Atmel AVR, Motorola 68k and H8, Ricoh 5A22, TMS320Cxxx
BinLens currently detects ~140 CWEs. 90% of these CWEs are detected on 30 common CPUs, including x86, ARM, MIPS, PowerPC, and SPARC. A majority of the CWE scans extend to cover x86-16, MIPS, AARCH, etc. Approximately 20% of the CWEs are also detected on specialized CPUs (i.e., RISC-V).
A Weak Pointer is any pointer that can be maligned to point outside the bounds to which it was initially allocated in the binary code. An example could be either a stack pointer or heap pointer. When allocated, the Weak Pointer was given a base value and maximum size. It is thought that binary-level vulnerabilities cannot occur without the ability to force a pointer to fall outside the range it was allocated. Other forms of exploitation can happen without it, but it stops the attacker from obtaining control flow.
To secure the Weak Pointer, several steps can be taken:
- An automated control flow integrity (CFI) or software fault isolation (SFI) solution is often available from compilers. Just rebuilding with these protections enabled is usually a victory because it eliminates the need for a patch. But, be warned that practically all of these implementations are restricted by their critical neo and do not impose much performance overhead, so they often have glaring holes. Not to impose much performance and do
- Another step that can be taken is the data pointer that faulted can be efficiently and effectively masked to prevent it from falling outside its bounds. To do this, a user with source access will modify the source to add a couple of operations to update the pointer to restrict it to within its bounds. If the pointer is already within that, there will be no effect.
An example:
const int SIZE_SMALL = 4;
const int SIZE_LARGE = 131072;
int f(int argc) {
if (argc > 1) {
char *dst = malloc(SIZE_SMALL);
dst[argc]='�';
}
}
int main(int argc, char *argv[]) {
f(argc);
return 0;
}This example has several obvious weak pointers.
ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) Weak Pointer Analysis finds these successfully; they have a path, and confidence score reports successfully for these.
What exactly can be done for any allocated dst? The following function repairs a pointer given the original and updates the math of the pointer to restrict it before using the Wepointer.
void * repair(void * orig, int size, void * ptr) {
if (ptr < orig) ptr = orig; if (ptr > (orig+size)) ptr = (orig+size)
return ptr;
}
int f_repaired(int argc) {
if (argc > 1) {
char *dst = malloc(SIZE_SMALL);
char *dst_access = dst + argc;
dst_access = repair(dst, SIZE_SMALL, dst_access);
*dst_access='�';
}
}This approach is the same for all Weak Pointers, but remember that you now may need to keep track of the pointer’s bounds up to the point at which the pointer is weak to have the bounds to restrict the pointer. Why point that out? Because the vulnerable pointer is a reassignable data value, the protection can’t be glued to the code that accesses it if it has potentially different values. To make that more clear, here is another example (just in the narrative this time):
- A Weak Pointer occurs at an address.
- That address accesses a pointer that was passed around as a variable.
- Therefore, the correct bound must be looked up for that pointer before it is applied.
Below shows the completion times for a sample configuration with the minimum hardware requirements:
Analysis time predictions (using 8 GB of RAM):
| Number of binaries (5MB average size) | Average time to complete in the cloud | Average time to complete on-prem |
|---|---|---|
| 1 |
20 minutes |
40 minutes |
| 4 |
1.5 hours |
2 hours |
| 8 |
2.6 hours |
5 hours |
| 16 |
5 hours |
10 hours |
| 32 |
10 hours |
20 hours |
| 64 |
1 days |
2 days |
| 128 | 2 days | 4 days |
The times listed above are the estimated completion times when the system is running with 8GB of available RAM. The more RAM is made available to the system, the more the user can expect the times to completion to decrease.
The times presented only represent average estimates, and analysis times may vary.
Troubleshooting
Troubleshooting Options – An analysis does not initiate after a prolonged period of time on Offline VM Distributions
If you have encountered issues with analyses not beginning after a prolonged period of time on offline distributions, consider trying some of these solutions to resolve your issue.
Try these solutions in order and move on to the next if one does not work. If you still encounter issues after attempting these solutions, please reach out to an ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) support team member, or submit a ticket through the ticketing portal.
- Sanity Check: Refresh the page, log out and log back in, then attempt to restart the analysis.
- Expiration Check: Ensure that the VM isn’t expired. If the VM isn’t expired, it will display a countdown in the bottom right of the page after logging in. The time of the host machine may affect this expiration.
- Hardware Check: Turn the VM off and on. Check that the specs are met (# vCPUs, 16GB RAM, 443 port forwarded). Ensure the host machine also meets the hardware specs.
- Organization Check: In the Platform, navigate to the Settings Page and create a new Organization. Swap to the new organization from the top navigation bar. Attempt to restart the analysis.
- Reinstall: Reinstall the VM. Give the import a new name to avoid any issues that exist in some versions of VirtualBox. Ensure the specs in step 3 are met before ever starting the VM.
Release notes
What’s Changed with This Release:
What’s New:
-
Added SymbEx assessment.
-
Added HeapOverflow SymbEx analysis. Detects instances of CWE-122: Heap-Based Buffer Overflow and CWE-415: Double Free.
-
Added StackOverflow SymbEx analysis. Detects instances of CWE-121: Stack-Based Buffer Overflow.
-
Added StringFormat SymbEx analysis. Detects instances of CWE-134: Use of Externally-Controlled Format String.
-
Added SymbolicIP SymbEx analysis. Detects instances of CWE-121: Stack-Based Buffer Overflow that overwrite the instruction pointer.
-
Added SymbolicWrite SymbEx analysis. Detects instances of CWE-129: Improper Validation of Array Index and CWE-823: Use of Out-of-range Pointer Offset.
What’s Updated:
-
Fixed various minor bugs and performance issues.
Feature details
New Feature: SymbEx assessment
The SymbEx assessment uses symbolic execution to detect and report memory-safety violations and other forms of undefined behavior in binary programs at a significantly lower false-postive rate compared to other competing approaches.
New Feature: HeapOverflow SymbEx analysis
Detects instances of CWE-122: Heap-Based Buffer Overflow and CWE-415: Double Free.
New Feature: StackOverflow SymbEx analysis
Detects instances of CWE-121: Stack-Based Buffer Overflow.
New Feature: StringFormat SymbEx analysis
Detects instances of CWE-134: Use of Externally-Controlled Format String.
New Feature: SymbolicIP SymbEx analysis
Detects instances of CWE-121: Stack-Based Buffer Overflow that overwrite the instruction pointer.
New Feature: SymbolicWrite SymbEx analysis.
Detects instances of CWE-129: Improper Validation of Array Index and CWE-823: Use of Out-of-range Pointer Offset.
TABLE OF CONTENTS
- New Feature: Added the Binary Delta Feature
- Updated Feature: Improved the descriptions of various CWEs
- Updated Feature: Password Recovery via Email from the sign-in screen
What’s Changed with This Release:
What’s New:
What’s Updated:
-
Improved the descriptions of various CWEs. When detected, these CWEs are reported with more context than before.
-
Added the ability to recover a user’s password via email from the sign-in screen.
-
Fixed bugs and performance issues relating to user authentication.
Feature details
New Feature: Binary Delta Feature
The Binary Delta Feature allows you to compare binary assessment results for different versions of the same binary executable or firmware image (e.g., between updates, patches, upgrades, mergers, debloats, remediation, etc.). This can be used to verify that a remediation removed an issue, or that a merger did not introduce new vulnerabilities.
You may select two assets for which to generate a Binary Delta Report. The Binary Delta Report is viewable in the user interface and may be exported to PDF. The Binary Delta Report will report any Binaries that are added, updated, removed, or unchanged between the two assets.
Updated Feature: Improved the descriptions of various CWEs.
When detected, some CWEs are reported with more context than before.
Updated Feature: Added the ability to recover a user’s password via email from the sign-in screen
Passwords can now be reset via email directly from the sign-in screen.
What’s Changed with This Release:
What’s New:
-
The CWEs tab is now organized according to the parent-child CWE hierarchy defined by MITRE.
-
[On-prem Offline VM Only] New deployments now allow the user to set the initial SUPERADMIN account credentials.
What’s Updated:
-
The asset vendor, product, and version text inputs have been turned into dropdowns.
-
The speed and performance of CPE/CVE detection has been improved.
-
ThreatAI assessment results now map to CWEs.
-
Weak Pointer assessment results now map to CWEs.
-
Various other new detectable CWEs have been added.
-
The 3D embedded system graph has been replaced with a colored Critical/Vulnerable/Safe grid component.
Feature details
New Feature: CWE Tab Organized by Parent-Child Hierarchy
The CWE tab within the binary analysis page is now organized in a way that allows the user to follow the hierarchy of the CWE from parent to child relationships. Hierarchical organization provides a structured and systematic representation of different types of weaknesses, allowing for a clear and organized view of the relationships between them.
This helps in categorizing and classifying weaknesses based on common traits and characteristics. At higher levels, weaknesses can be broadly categorized, providing an overview. At lower levels, more specific and detailed information about each weakness is available. Users can drill down into specific categories or climb up to see broader classifications.
Users can quickly locate and understand the context of a particular weakness within a broader category. This organizing strategy facilitates the identification of common patterns, root causes, and related weaknesses, aiding in the development of effective countermeasures.
New Feature: [On-Prem Offline VM] New Deployments Allow User to Set Initial SUPERADMIN Account Credentials
When users start up their On-Prem Offline VM for the first time, they are prompted to set their SUPERADMIN login credentials before running analyses. Allowing users to set their login credentials, such as usernames and passwords, promotes user autonomy and security.
Updated Feature: The Asset Vendor, Product, and Version CPE Inputs Have Been Turned Into Dropdowns
This has been updated for ease of use and to improve the user experience when entering CPE information. The user’s entry will auto-complete if ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) contains CPE data associated with the entry.
Updated Feature: Speed and Performance of CPE/CVE Detection Has Been Improved
The CPE and CVE detection mechanisms have been improved, and the results now return faster, improving the overall analysis completion speeds.
Updated Feature: ThreatAI Assessment Results Now Map to CWEs
ThreatAI assessment results now map to related CWEs, helping the user understand how the different analysis results are connected to the weaknesses of the binary overall.
Updated Feature: Weak Pointer Assessment Results Now Map to CWEs
Weak Pointer assessment results now map to related CWEs, helping the user understand how the different analysis results are connected to the weaknesses of the binary overall.
Updated Feature: Various Other New Detectable CWEs Have Been Added
CWE mappings have been improved upon and the CWEs that are detected are now more specifically mapped to the problems that are present.
Updated Feature: 3D Embedded System Graph Replaced with Colored Critical/Vulnerable/Safe Grid Component
The 3D Embedded System Graph has been replaced with a more readable numerical component. This change was made because the 3D embedded system graph did not provide much utility and was ultimately only there for visual purposes. It has been removed and replaced with a more utilizable graph to avoid confusion.
What’s Changed with This Release:
What’s New:
-
Common Platform Enumerations (CPEs) are now detected based on the analyzed asset vendor, product, and version information.
-
CISA Known Exploited Vulnerabilities (KEV) Catalog has been integrated into ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) CVE detection mechanism.
What’s Updated:
-
Each Binary Analysis Tab includes explanatory text to describe the purpose of each tab.
-
The detection of Weak Pointers now results in a binary to be scored Red.
-
The Crypto Tab now warns the user if certain detected cryptographic signatures indicate a deprecated or unsafe cryptographic algorithm.
-
The OpenAPI routes have been reformatted according to the affected data type.
Feature details
New Feature: CPE Search Support for Uploaded Analyses
With the addition of the CPE Search feature, the user may enter the asset vendor, product, and version to show a complete list of CVEs associated with each CPE search result. To use this feature, enter a vendor (optional), product (optional), and version (optional) when uploading assets for analysis. If the user enters only a vendor, the CPEs tab will search all products and versions for that vendor. If the user enters a vendor and a product, the CPEs tab will search all product versions. By this means, the user can selectively narrow down the CPE search. CPEs are displayed on the Asset Summary Panel of the Binary Analysis Page, next to the Base analysis tab.
New Feature: CISA Known Exploited Vulnerabilities (KEV) Catalog Integration
With the integration of the CISA Known Exploited Vulnerabilities (KEV) Catalog, the user now receives insights about which CVEs are known to have been exploited. This feature adds a new classification for CVEs under the Risk column. CVEs that have been exploited will be labeled “EXPLOITED” in the severity Risk score. To use this feature, upload your binaries as usual, and the results will begin showing CVEs that are identified as exploited.
Updated Feature: Analysis Descriptions
Analysis results can be viewed on the Binary Analysis Base Tab and now includes explanatory text to describe the purpose of each tab. This text explains how the displayed assessment results can be interpreted for remedial purposes.
Updated Feature: Weak Pointers Scoring
Assets that have Weak Pointers present are now scored as Red.
Updated Feature: Crypto Tab Deprecated or Unsafe Cryptographic Algorithm Warnings
The Crypto Tab warns if certain detected cryptographic signatures indicate a deprecated or unsafe cryptographic algorithm.
Updated Feature: OpenAPI Route Reformatting
The OpenAPI routes have been reformatted to start with the data type to which they apply. This change came as part of a logical restructuring of the routes available and to increase clarity about which resources were being accessed.
What’s Changed with This Release:
What’s New:
- The SUPERADMIN can forward all assessment results to an ELK stack of their choosing. This can be configured in the SUPERADMIN’s Settings Page.
- [On-Prem Only] The SUPERADMIN of on-prem deployments can now update the CVE signature database in the Settings Page.
- [On-Prem Only] The SUPERADMIN of on-prem deployments can now update the Malware signature database in the Settings Page.
What’s Updated:
- The CVE detection assessment has been frontloaded. It will be executed before other assessment types.
- Users can now change their password from the Settings Page.
- On-Prem users can now apply their deployment license from the Settings Page.
Feature details
New Feature: Assessment Result Forwarding to ELK Stack
With the addition of the Results Forwarding to ELK Stack feature, the user may now set the location (IP and port) for their analysis assessment results to be easily forwarded. The ELK Stack forwarding feature makes processing and storing results much more accessible and gives the user flexibility to search through and process results with more granularity. Since ELK Stack provides a unique Kibana query system, the user can sort results in a way that is not limited to what the front-end GUI provides.
This feature can be accessed by the SUPERADMIN and configured within the settings page. There are three supported protocols: UDP, TCP, and HTTP. Instructions for configuring each of these can be found here.
New Feature: [On-Prem Only] CVE Signature Database Update Ability
With the addition of the CVE Signature Database Update feature, On-Prem users may now pull updates from the NVD CVE Signature Database to update the range of mapping possibilities for their CVE analysis mapping results. This feature is for On-Prem offline users who want to stay on top of the newest CVE published daily. Since On-Prem deployments have no connectivity to the internet, users with On-Prem deployments must use this feature to update their master CVE mapping database.
New Feature: [On-Prem Only] Malware Signature Database Update Ability
With the addition of the Malware Signature Database Update feature, On-Prem users may now pull updates to the Malware Signature Database. This feature is for On-Prem offline users who want to stay on top of the newest Malware published daily. Since On-Prem deployments have no connectivity to the internet, users with On-Prem deployments must use this feature to update their Malware mapping database.
Updated Feature: CVE Detection Assessment Frontloading
With this update to the assessment order, the CVE assessment is completed before other assessments. This re-ordering was done to take advantage of the fast analysis time produced by the CVE assessment and to show users the most critical information first.
Updated Feature: Password Update From Settings Page
With this update, users can now update their password from the settings page without the assistance of the SUPERADMIN.
Updated Feature: License Applying From Settings Page
With this update, the SUPERADMIN can now apply for the platform license from the settings page- making the initial setup much more accessible.
What’s Changed with This Release:
What’s New:
- CWEs can now be mapped to the NIST 800-82 compliance framework.
- MSI files are now extracted and analyzed.
- [Cloud Only] Analyses now run in parallel and complete significantly faster.
What’s Updated:
-
The Weak Pointer path Confidence Score is now color-coded to indicate status.
Feature details
New Feature: NIST 800-82 Compliance Mapping
With the addition of NIST 800-82 Mapping, the user can gain valuable insight into how CWEs affect their compliance standing.
New Feature: MSI Extraction and Analysis
MSI files are now able to be uploaded, unpacked, and analyzed.
New Feature: [Cloud Only] Parallel Analyses, Increased Performance
Binaries analyzed on cloud distributions now analyze faster. In addition, more binaries may be analyzed simultaneously.
What’s Changed with This Release:
What’s New:
- Added the ability to generate custom PDF vulnerability reports for assets.
- Added the ability to generate custom PDF vulnerability reports for facilities.
- Added the dashboard system stats, including CPU and memory usage.
- Added the ability to ingress binary files for analysis from an S3 bucket.
What’s Updated:
-
The assessment queue has been updated to display the percentage completion for every assessment conducted per binary.
-
The assessment queue has been updated to enable users to re-prioritize assessments, binaries, and assets in the queue, stop assessments, stop binaries, and stop assets.
-
The Deep Dive Page has been updated to enable the user to jump between functions in the disassembler and decompiler.
-
The CVEs table has been updated to enable sorting by different columns.
-
The pricing option allows instances to be configured by the binary scan or asset.
-
Weak Pointers now have an associated confidence score.
-
Weak Pointers may now be added to the Binary Scan Analysis Report. You can learn about Weak Pointers here.
New Pricing Option
Pay Per Binary Scan: With the Pay Per Binary Scan pricing option. This pricing option is ideal for customers focused on Binary scans versus assets.
Feature details
New Feature: Custom Binary Scan Analysis Vulnerability Reports for Assets in PDF Format
With the addition of the Custom PDF Vulnerability Reports for Assets feature, the user may now generate customized reports for an asset. The asset reports are customizable and allow users to select information per binary to include in their asset report.
New Feature: Custom Binary Scan Analysis Vulnerability Reports for Facilities in PDF Format
With the addition of the Custom PDF Vulnerability Reports for Facilities feature, the user may now generate customized reports for a facility. The facility reports are customizable and allow users to select information per asset to include in their report.
New Feature: Pricing Option Usage Indicator by Number of Binary Scans or Number of Assets
With the addition to the per binary scan basis, the indicators now change to reflect which pricing model you have selected.
New Feature: Resource Usage Indicators (On-Prem, Offline VM Edition Only)
With the addition of the Resource Usage Indicators, the user may now observe the resource consumption of ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) on screen.
New Feature: S3 Bucket Binary File Ingress Option
With the addition of the S3 Bucket Ingress feature, the user may now upload binaries to an asset directly from an AWS S3 bucket. Connecting an S3 bucket to Binlens allows users to create workflows to conduct analyses without manually uploading files.
Updated Feature: Analyses Progress Status Displayed for Each Active Binary Scan Assessment
With the addition of analysis progress indicators, the user has even further visibility on individual test progress. They can also re-prioritize assessments (see reordering below).
Updated Feature: Active Asset Binary Scans, Individual Binary Scans, and Assessments can be Reordered During Processing
With the addition of the queue reorder feature, the user may now reorder analyses, binary, and assessment positions in the queue after they’ve been added. This enables the user to prioritize which analyses are completed first. If a user is more concerned with one assessment finishing before another, this feature allows them to have that flexibility and control the flow of assessment completion.
Updated Feature: Offensive Binary Analysis, Deep Dive Tool, Now Supports Jump-To Functions
With the addition of the deep dive jump-to-function feature, the user can seamlessly navigate between functions and instructions in the disassembler and decompiler. The deep dive jump-to-function feature introduces the ability to leap directly between instructions in the disassembled view and their corresponding functions in the decompiled view.
New Function: CVE Table Now Supports Sort by Column
With the addition of the sort-by-column for CVEs feature, the user may now view CVE results in their chosen order. CVE results are sortable by CVE name, risk level, and product vendor.
New Feature: Weak Pointer Analysis Can Be Added to the Binary Scan Analysis Vulnerability Reports
Adding the Weak Pointers Analyses Results to Reports gives users more flexibility to create an advanced and all-encompassing vulnerability report.
New Feature: Weak Pointers Analysis Provides Confidence Score
With the addition of the Weak Pointers Analysis Confidence Score, the user now has insight into the exploitability of a given Weak Pointers path. The confidence score adds extreme value in determining if a weak pointer path is exploitable. A high confidence score indicates a Weak Pointers path is confirmed with no false positives or false negative results.
What’s changed with this release:
What’s New:
-
Global binary search (search for any binary analyzed on the platform by name).
-
Global CWE search (search for any binary analyzed on the platform by CWE discovered).
-
Weak pointers and path-finding assessments.
What’s Updated:
-
Improved ISA/IEC 62443-3-3 and 62443-4-2 Standard to CWE Mapping (accuracy and quantity).
-
Improvements to our decompilation technique (modifying the decompiler used depending on the type of file uploaded).
- Unassessable binaries are now given additional rationale for why they are unassessable upon being clicked.
Feature details
New Feature: Global Binary Search
With the addition of the global binary search feature, the user may perform asset searches based on asset name. To use this feature, click “assets” as the search type and type the asset’s name into the search bar.
New Feature: Global CWE Search
With the addition of the global CWE search feature, the user may perform asset searches based on CWEs contained within the assets. To use this feature, click “CWE” as the search type and type the asset’s name into the search bar.
New Feature: Weak Pointers and Path-finding Assessments
With the addition of the weak pointers assessments, the user may now discover weak pointers and the paths to access those.
What are Weak Pointers and how does it contribute to OT/ICS binary analysis for vulnerabilities?
Weak Pointers is a novel binary code analysis science that automates identification of known code vulnerabilities and weaknesses, like buffer overflow.
To speed remediation of code weaknesses, ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform) provides the path of the weakness (also known as a Weak Pointer) guiding DevSecOps and Application Security specialists to zone in directly to the problem lines of code that need to be remediated.
Once the code has been remediated, the repaired binary files can be re-uploaded to BinLens for another round of vulnerability analysis. A green light report informs you that the code is ready for production. A yellow or red light report informs you that additional remediation is needed before committing the code to production.
Each round of binary file code analysis is recorded in the Audit Log.
What’s changed with this release
What’s been updated:
- Fixed a bug wherein the custom PDF report feature was causing crashes on some older browser versions.
- Fixed a bug where the labels for passing Lineage Analysis assessments were written incorrectly.
- Fixed a bug where binary executable files with no discovered CWEs appeared unassessable.
What’s New – Release Notes for the most recent version of ObjectSecurity’s BinLens™ (formerly ObjectSecurity OT.AI Platform).
Note on release
This release is a GA release.
What’s changed with this release:
What’s New:
- Flash alerts feature: the SUPERADMIN can now generate Flash Alerts which can be read by every user in an organization.
- There is now an OT vulnerability RSS feed on the Dashboard.
- Unassessable files are now given a reason for being unassessable: their mime-type is displayed.
What’s Updated:
- The Login, Pincode Login, EULA, Set Password, and Google Authentication Pages have been given an updated look and feel.
- ThreatAI assessments have improved accuracy: Double Free Check and Access Free Memory Check.
- More routes have been added to the OpenAPI page.
- All loading spinners now have a consistent look and size.
What’s Been Removed:
- The Reanalyze Asset option has been removed, as it was non-functional.
Feature details
New Feature: Flash Alerts
With the addition of the Flash Alerts feature, the super admin may now post organization-wide priority alerts. When a flash alert is posted, each user in the organization managed by the super admin will receive notice of the alert in the corner of their screen.
New Feature: National Vulnerability RSS Feed
With the addition of the National Vulnerability RSS Feed, the user may easily access the most recently published CWEs- pulled directly from the MITRE database.
New Feature: Unassessable Reasoning Specification
When binaries are deemed unassessable, more reasoning for their unassessability is provided.
What’s changed with this release:
What’s New:
- Assets now have an associated list of “tags”. This list of tags can be added to and removed at will from the Binary Analysis Page.
- Searching for a tag by name will display all of the assets that have the corresponding tag.
What’s Updated:
- The custom reporting feature has been re-tooled with a new look and feel.
- Vulnerabilities added to a custom report may be re-ordered via drag-and-drop.
- Vulnerabilities added to a custom report that have associated compliance mappings will display these mappings on the report.
- Vulnerabilities added to a custom report that have associated deep dive locations will display these locations on the report.
- The audit log viewable from the Dashboard and Asset Summary Panel now displays the name of the user who caused the audit entry.
- Assets can now have their type updated from the Binary Analysis Page.
What’s Been Removed:
- Some asset types have been removed due to the tagging feature making them redundant.
What’s changed with this release:
What’s New:
-
Binary analysis now checks for encryption and other cryptographic anomalies.
- A total of 5 new ThreatAI tests have been added.
- A total of 17 new asset types have been added. Additionally, the user can now filter their analysis results by asset type.
-
Discovered binary vulnerabilities now map to OWASP 10:2021, ISA/IEC 62443-3-3, and ISA/IEC 62443-4-2 standards frameworks.
-
Users can now view/export server logs from the right sidebar.
What’s Updated:
- Binary vulnerability scoring has been updated to improve accuracy. This includes incorporating additional factors into the aggregate color score.
- The reason a binary was assigned a specific vulnerability color score can now be seen from the Binary Summary Base tab.
-
Discovered dangerous functions now map to an associated CWE.
- CWEs viewed in the Binary Summary Panel now display a preview of the Deep Dive Page. Users can jump to where the CWE was discovered from here.
- Facilities can now be edited after they have been created.
-
Zip files are now automatically unzipped and extracted.
This update has added a number of features to enhance usability, organization, and the look and feel of ObjectSecurity's BinLens™ (formerly ObjectSecurity OT.AI Platform). In addition, new mapping capabilities were added.
Feature details
New Feature: Cryptographic Keys and Anomalies Analysis
With the addition of the Cryptographic Keys and Anomalies Analysis feature, the user can now find info about cryptographic keys, program entry points, strong and weak encryption used, and hash signatures. To use this feature, click the crypto tab under binary analysis results.
New Feature: Added Asset Types
The addition of new asset types gives the user even more flexibility to classify and organize assets within their organization.
New Feature: OWASP 10:2021, ISA/IEC 62443-3-3, and ISA/IEX 62443-4-2 Mappings
With the addition of the OWASP 10:2021, ISA/IEC 62443-3-3, and ISA/IEX 62443-4-2 mapping features, the user can now directly track their organization’s compliance with popular standards as they relate to discovered vulnerabilities. To use this feature, click the arrow to expand the dropdown and select your standard of interest.
New Feature: Download Server Logs
This feature allows the user to see the log of actions taken on their instance of BinLens.
Note on release
This release is a BETA release, and features are subject to change.
What’s changed with this release:
What’s New:
- Facilities are now fully functional: Facilities can now be created. They have specific locations and a set of child assets.
- The user management page has been updated to enable the creation of multiple organizations. Each organization can be assigned admins, who can then assign general users.
- Users can now toggle their view between different organizations: viewing the assets/facilities/binaries in each.
What’s Updated:
- Assets have been refactored, greatly reducing load time.
- EULA accept/decline now gets sent to an audit log, and a user only has to accept the EULA once.
- Users can now upload many binaries at once. Additionally, the analysis progress viewer has been improved.
Note on release
This release is an ALPHA release, and features are subject to change.
What’s changed with this release:
- Organization-Wide Dashboard Page: A user can see a high-level overview of their organization. This overview includes a map of facilities in the organization, a graph of vulnerable assets in the organization, a set of organization-specific metadata, and a list of most threatening binary vulnerabilities in the organization.
- Added a better way to view specific assets: assets now appear on the Binary Analysis Page as parents to a child set of binaries. Clicking on an asset displays it on the right-hand-side of the screen, summarizing it in detail.
- A user on-boarding tutorial has been added to the application, explaining how to upload, analyze, and then view binaries.
Note on release
This release is an ALPHA release, and features are subject to change.
What’s changed with this release:
- Binary Analysis Page: Users can upload binary executable files for analysis. Analysis results can be viewed in a panel on the right hand side of the page.
- Reports Page. A binary analysis report PDF can be generated and exported here. Users can customize what vulnerabilities appear in the report.
- Deep Dive Page. A disassembled and decompiled view of uploaded binaries can be viewed here.
- OpenAPI Page. The set of backend API calls used by the application are explained here. They can also be queried.
- Settings Page: A user can manage all users on the server and toggle visual settings.
