Post Syndicated from Rapid7 original https://blog.rapid7.com/2023/09/25/introducing-active-risk/

Cyber risk is increasing both in volume and velocity. Given the landscape of threats, weaknesses, vulnerabilities, and misconfigurations, organizations, teams and vulnerability analysts alike need of better prioritization mechanisms. That’s why we developed a new risk scoring methodology: Active Risk.

Rapid7 has offered five risk strategies for many years, each strategy with its own specific approach to surfacing that which matters most. Our sixth risk strategy, Active Risk, is designed to focus security and remediation efforts on the vulnerabilities that are actively exploited in the wild or most likely to be exploited.

Active Risk uses CVSS scores along with intelligence from threat feeds like AttackerKB, Metasploit, ExploitDB, Project Heisenberg, CISA KEV list, and other third-party dark web sources to provide security teams with threat-aware vulnerability risk scores on scale of 0-1000.

Active Risk is available via InsightVM, InsightCloudSec, Nexpose, and our recently released Executive Risk View.

Enter Active Risk

Exploitability has become one of those terms that the security community has maligned, not out of spite, but simply because it’s been applied to too many use cases. Exploitability refers to the ease with which a vulnerability in a computer system, software application, or network can be exploited. But, even that definition can be misleading. Semantics aside, exploitability is really a question of likelihood.

This new risk strategy is focused on delivering unambiguous near-time intelligence, by systematically including a number of threat intelligence sources to enhance vulnerability risk score(s).

There are a number of vulnerability intelligence sources that fuel prioritization in Active Risk, including:

1. AttackerKB: Launched in 2020, a forum for the security community at large to share insights and views that help cut through all the hype and chaos, with a primary purpose to inform infosec professionals on vulnerabilities and security threats
2. Project Heisenberg: A network of low interaction honeypots with a singular purpose, to understand what attackers, researchers, and organizations are doing in, across, and against cloud environments. This global network established in 2014, by Rapid7, it records telemetry about connections and incoming attacks to better understand the tactics, techniques, and procedures used by bots and human attackers
3. Metasploit: Arguably the most widely used, community supported, ethical hacking framework on the planet, used by whitehats, security researchers and generalists in pentesting, <pick-your-color> teaming, CTF drills, education as well as broad or very specialized security assessment exercises
4. Exploit Database (exploit-db.com): Widely used online repository and reference for security researchers, pentesters, and ethical hackers; it’s become a go-to resource offering an extensive archive of exploits and vulnerabilities, allowing users to track the evolution of security threats over time across software, hardware, and operating systems
5. CISA Key Exploited Vulnerabilities (KEV) Catalog: Established in 2021 to “provide an authoritative source of vulnerabilities that have been exploited ‘in the wild,’” by the Cybersecurity & Infrastructure Security Agency; witnessing fairly broad and hasty adoption across industries as a method to focus and improve remediation throughput
6. OSINT and Commercial Feeds: Dependent on the nature of the vulnerability or threat the sources above are combined and validated with additional intelligence and context to enhance prioritization results and ultimately customer outcomes

The immediate value in threat intel data ingestion and normalization alone, that Active Risk delivers, will incentivize and amplify the interest for potential adoption. Active Risk is also CVSS 3.1 compliant across all new CVEs and makes ready future adoption of revised scoring systems (CVSS v4.0 is targeting October 31, 2023 publication). There is strong market demand and intensifying use and application of ‘exploitability’ intelligence as seen in CVSS v4.0 and in CISA KEV as previously mentioned.

Normalize vulnerability risk scoring across cloud and on-prem environments

Active Risk normalizes risk scores across cloud and on-premises environments to effectively assess and collaborate with teams across an organization.

Security teams can leverage Active Risk dashboard cards in InsightVM and Executive Risk View in our Cloud Risk Complete solution to support cross-functional conversations.

Active Risk is a step change along the path of risk prioritization improvement, and the much longer and windier road we travel together towards improved risk management outcomes.

Post Syndicated from John Hartman original https://blog.rapid7.com/2023/04/26/using-rapid7-insight-agent-and-insightvm-scan-assistant-in-tandem/

Background

Rapid7 Insight Agent and InsightVM Scan Assistant are executables that can be deployed to assist in understanding the vulnerabilities in your environment. Frequently there are questions around when and where you would deploy each, if you need both, what they actually monitor, etc. This article will answer those questions, but first let’s look at each executable in more detail.

Rapid7 Insight Agent

Notice the name of this starts with Rapid7. This is important, because the Insight Agent can be used for multiple tools, primarily InsightVM and InsightIDR. However, the agent does different things for each. For InsightIDR, the agent monitors process start and stop events and has log collection abilities. For InsightVM, the Insight Agent is used for assessment of vulnerabilities. In this article, we’ll focus on using Insight Agent for InsightVM.

The Insight Agent performs an “assessment” roughly every six hours. Notice the word “assessment” and not “scan”. The Insight Agent has the permissions necessary to gather information about the asset that it is installed on and then forward that information directly to the Insight Platform. The Insight Platform then forwards that data to the InsightVM Security Console. The Security Console then takes that data and runs it against a scan template to determine what vulnerabilities that asset has. Once done, the Security Console updates its own database with the results for that asset and then on the interval of communication with the Insight Platform it will forward the assessment results back to the Insight Platform.

With the Insight Agent, you do not determine a scan schedule or have the ability to kick off ad hoc or remediation scans on that asset. As noted above, assessments occur every six hours. However, not every agent is being assessed on the same six hour interval. The schedule is maintained entirely by the Insight Platform.

Another key takeaway about the communication path mentioned above: The Insight Agent does not communicate directly to the console. This makes Insight Agent particularly beneficial when it comes to protecting your remote workforce. Given that remote assets are not on your network, you typically cannot scan them directly. So, Insight Agent is the main option to view the vulnerabilities for those assets.

Recently, Rapid7 released the ability to perform Policy Scans using the Insight Agent as well. This ability is limited to assets that are available for the installation of the InsightAgent though (Windows, Linux, Mac), however that typically covers a large portion of the policy scanning needed. Policy scanning occurs every 12 hours.

InsightVM Documentation: Insight Agents with InsightVM

InsightVM Scan Assistant

The InsightVM Scan Assistant executable is solely dedicated to InsightVM and is configured to display a certificate on port 21047. The Scan Assistant can only be used when being accessed from a scan engine (distributed or local). Unlike the Insight Agent, which monitors and performs assessments on a scheduled basis, the Scan Assistant is dormant unless called upon by a Scan Engine either through a manual or scheduled scan configured from the Security Console.

For this to work, first you must generate a certificate from InsightVM in the credential setup. Then, you need to edit any scan templates being used to additionally look for port TCP 21047 on both Asset and Service discovery. From there, the Scan Engine will use those credentials and look for that port to be open on the endpoint servers. If the certificate being presented on that port matches the certificate created within InsightVM, the scan engine will use it to authenticate to the endpoint asset. The Scan Assistant has the permissions necessary to perform all local checks on the endpoint asset.

Using the Scan Assistant instead of regular domain credentials offers better security, as it eliminates the possibility of a domain account with elevated permissions to be used in your environment. Additionally, the Scan Assistant has proven to be more efficient and perform scans quicker than domain credentials.

InsightVM Documentation: Using the Scan Assistant

So why use both?

As stated above, the two executables are completely independent of each other. The Insight Agent communicates to the platform whereas the Scan Assistant talks directly to the Scan Engine performing the scan. The Insight Agent is not configurable in its scheduled assessment whereas the Scan Assistant is completely dormant until scanned and is completely reliant on an administrator configuring scanning.

So, WHERE should each executable be installed? I would suggest having the Insight Agent on all local and remote assets—everything capable of having the Insight Agent installed. For the Scan Assistant, only internal assets would be applicable. You could install the Scan Assistant on remote assets as well, if you have a policy that requires users to connect to the VPN on set schedules and you plan to scan through that VPN or office wi-fi. However, in most situations, the Insight Agent is the only way to assess your remote assets.

So that brings us to the internal assets that should have BOTH the Insight Agent and the Scan Assistant installed. You might be asking ‘why in the world would I want to deploy yet another executable if the Insight Agent is already performing the assessment on those assets?’ Well, let’s circle back to the fact that the Insight Agent is only performing the local checks. So, you will need to perform at least monthly scanning of those assets to view network vulnerabilities. Additionally, as mentioned above, the Insight Agent is incapable of kicking off an ad-hoc scan. This is where the Scan Assistant comes into play for remediation scans specifically.

Scenario: I have an asset “abc.company.com.” InsightAgent discovers a local vulnerability on the asset at 10AM and it’s only 1030AM. I send the finding off to my system administrator to patch the vulnerability immediately. By 11AM the vulnerability is patched, and I want to verify that the vulnerability has been remediated. Without a credentialed scan, I have to wait another five hours before InsightAgent conducts another assessment. However, with the Scan Assistant I can immediately kick off an authenticated vulnerability scan against that asset to determine that the vulnerability is no longer present.

The other main use case for the Scan Assistant is to take advantage of the full breadth of the Policy Scanning. Currently, InsightAgent can only assess up to 100 different policies and can only assess for the default values of the policies through CIS or DISA.

Using the Scan Assistant with the scan engine you have access to ALL categories of Policy Scans, including CIS, DISA, FDCC, and USGCB. Additionally, you can use the custom policy builder to edit values within typical benchmarks. For example, you might change the minimum password length from 14 characters to 20 characters if that’s what your internal policy dictates.

Post Syndicated from Roshnee Mistry Shah original https://blog.rapid7.com/2023/03/31/whats-new-in-insightvm-and-nexpose-q1-2023-in-review/

In Q1, our team continued to focus on driving better customer outcomes with InsightVM and Nexpose by further improving efficiency and performance. While many of these updates are under the hood, you may have started to notice faster vulnerability checks available for the recent ETRs or an upgraded user interface for the console Admin page. Let’s take a look at some of the key updates in InsightVM and Nexpose from Q1.

[InsightVM and Nexpose] View expiration date for Scan Assistant digital certificates

Scan Assistant, a lightweight service deployed on the asset, leverages the Scan Engine and digital certificates to securely deliver the core benefits of authenticated scanning without the need to manage traditional account-based credentials.

Customers can now easily determine the validity of a Scan Assistant digital certificate by viewing the Expiration Date on the Shared Scan Credential Configuration page.

[InsightVM and Nexpose] A new look for the Console Administration page

We updated the user interface (UI) of the Console Administration page to facilitate a more intuitive and consistent user experience across InsightVM and the Insight Platform. You can even switch between light mode and dark mode for this page. This update is part of our ongoing  Security Console experience transformation to enhance its usability and workflow—stay tuned for more updates!

[InsightVM and Nexpose] Checks for notable vulnerabilities

Rapid7’s Emergent Threat Response (ETR) program flagged multiple CVEs this quarter. InsightVM and Nexpose customers can assess their exposure to many of these CVEs with vulnerability checks, including:

• Oracle E-Business Suite CVE-2022-21587: Added to the CISA Known Exploited Vulnerabilities (KEV) catalog, this vulnerability affected a collection of Oracle enterprise applications and can lead to unauthenticated remote code execution. Part of our recurring coverage, learn more about the vulnerability and our response.
• VMware ESXi Servers CVE-2021-21974: VMware ESXi is used by enterprises to deploy and serve virtual computers. VMware ESXi servers worldwide were targeted by a ransomware that leveraged CVE-2021-21974. Part of our recurring coverage, learn more about the vulnerability and our response.
• ManageEngine CVE-2022-47966: ManageEngine offers a variety of enterprise IT management tools to manage IT operations. At least 24 on-premise ManageEngine products were impacted from the exploitation of CVE-2022-47966, a pre-authentication remote code execution (RCE) vulnerability. Learn more about the vulnerability and our response.
• Control Web Panel CVE-2022-44877: Control Web Panel is a popular free interface for managing web servers. In early January, security researcher Numan Türle published a proof-of-concept exploit for CVE-2022-44877, an unauthenticated remote code execution vulnerability in Control Web Panel (CWP, formerly known as CentOS Web Panel).  Learn more about the vulnerability and our response.
• GoAnywhere MFT CVE-2023-0669: Fortra’s GoAnywhere MFT offers managed file transfer solutions for enterprises. CVE-2023-0669, an actively exploited zero-day vulnerability affected the on-premise instances of Fortra’s GoAnywhere MFT. Learn more about the vulnerability and our response.
• Jira Service Management Products CVE-2023-22501: Atlassian’s Jira Service Management Server and Data Center offerings were impacted by CVE-2023-22501, a critical broken authentication vulnerability that  allows an attacker to impersonate another user and gain access to a Jira Service Management instance under certain circumstances. Learn more about the vulnerability and our response.
• ZK Framework CVE-2022-36537: The vulnerability in ZK Framework, an open-source Java framework for creating web applications, was actively exploited due to its use in ConnectWise R1Soft Server Backup Manager, and allowed remote code execution and the installation of malicious drivers that function as backdoors. Learn more about the vulnerability and our response.

Up Next for InsightVM | Custom Policies with Agent-Based Policy Assessment

Guidelines from Center for Internet Security (CIS) and Security Technical Implementation Guides (STIG) are widely used industry benchmarks for configuration assessment. However, a benchmark or guideline as-is may not meet the unique needs of your business. Very soon (next quarter soon), you can start using Agent-Based Policy for custom policy assessment.  

Post Syndicated from Tom Caiazza original https://blog.rapid7.com/2023/01/09/year-in-review-vulnerability-management/

For Rapid7’s vulnerability management team, 2022 began with a lot of introspection on how we can add more value and keep meeting our customer needs in the best possible ways.

Over the course of 2022, we launched many new features and improvements — some highly anticipated, many customer-requested. Log4J was difficult, but we learned from it, particularly when it comes to Emergent Threat Response.

Additionally, we recently refreshed our coordinated vulnerability disclosure (CVD) policy and philosophy. We found that we couldn’t treat every vulnerability equally and there was a need to be more agile with our CVD approach. So, we came up with six classes of vulnerabilities (and a meta-classification of “more than one”) and some broad strokes of what we intend to accomplish with our CVD for each of them.

We reimagined many of our internal processes and teams to drive better customer outcomes. For instance, we are making a significant investment in re-architecting the InsightVM/Nexpose database to ensure VM programs scale with the customers evolving IT environment.

We will continue to prioritize what really matters, even if it means making some hard decisions, and further improve communication with our customers. Here’s a snapshot of 2022 in InsightVM.

Key Product Improvements

Agent-based policy assessment

A robust vulnerability management program should assess IT assets for misconfigurations along with vulnerabilities. That’s why we were thrilled to introduce Agent-Based Policy in InsightVM. Customers can now use Insight Agents to conduct configuration assessments of IT assets against widely used industry benchmarks from the Center for Internet Security (CIS) and the U.S. Defense Information Systems Agency (DISA) to help prevent breaches and ensure compliance.

Remediation Project improvements

Remediation Projects help security teams collaborate and track progress of remediation work (often assigned to their IT ops counterparts). Here are our favorite updates:

• Remediator Export – a new solution-based CSV export option, Remediator Export contains detailed information about the assets, vulnerabilities, proof data, and more for a given solution.
• Better way to track project progress – The new metric that calculates progress for Remediation Projects will advance for each individual asset remediated within a “solution” group. This means customers no longer have to wait for all the affected assets to be remediated to see progress.

Scan Assistant

Scan Assistant provides an innovative alternative to traditional credentialed scanning. Instead of account-based credentials, it uses digital certificates, which increases security and simplifies administration for authenticated scans.

• Scan Assistant is now generally available for Linux
• Automatic Scan Assistant credential generation – taking some more burden off the vulnerability management teams, customers can use the Shared Credentials management UI to automatically generate Scan Assistant credentials
• Improved scalability – automated Scan Assistant software updates and digital certificate rotation for customers seeking to deploy and maintain a fleet of Scan Assistants.

Dashboards and reports

Customers like to use dashboards to visualize the impact of a specific vulnerability or vulnerabilities to their environment, and we made quite a few updates in that area:

• New dashboard cards based on CVSS v3 severity – we expanded CVSS dashboard cards to include a version that sorts the vulnerabilities based on CVSS v3 scores (along with CVSS v2 scores).
• Threat feed dashboard includes CISA’s KEV catalog – we extended the scope of vulnerabilities tracked to incorporate CISA’s KEV catalog in the InsightVM Threat Feed Dashboard to help customers prioritize faster.
• 5 New Dashboard Cards – We launched a set of five new dashboard cards that utilize line charts to show trends in vulnerability severity and allow for easy comparison when reporting.
• Distribute Reports via Email – Customers can now send InsightVM reports to their teammates through email.

Agent improvements for virtual desktops

Pandemic fueled remote work and with it the use of virtual desktops. InsightVM can now identify agent-based assets that are Citrix VDI instances and correlate them to the user, enabling more accurate asset/instance tagging. This will create a smooth, streamlined experience for organizations that deploy and scan Citrix VDIs. Expect similar improvements for VMware Horizon VDIs in 2023.

Improved support

A new, opt-in feature eliminates the need for customers to attach logs to support cases and/or send logs manually, ensuring a faster, more intuitive support process.

Notable Emergent Threat Responses and Recurring Coverages

In 2022, we added support for enterprise systems like Windows Server 2022, AlmaLinux, VMware Horizon (server and client), and more to the recurring coverage list. Learn about the systems with recurring coverage.

Rapid7’s Emergent Threat Response (ETR) program is part of an ongoing process to deliver fast, expert analysis alongside first-rate security content for the highest-priority security threats. This year we flagged a number of critical vulnerabilities. To list a few:

• Microsoft Exchange Server Server-Side Request Forgery and Remote Code Execution (CVE-2022-41040 and CVE-2022-41082)
• OpenSSL Buffer Overflows (CVE-2022-3786 and CVE-2022-3602)
• Confluence Server and Data Center Unauthenticated Remote Code Execution (CVE-2022-26134)
• Fortinet FortiOS Authentication Bypass (FortiGate, FortiProxy, FortiSwitch Manager) (CVE-2022-40684)

That’s not all. We added over 21,000 new checks across close to 9000 CVEs to help customers understand their risk better and thus secure better.

Check out our past blogs – Q1, Q2, and Q3 – to get more information on product improvements and key vulnerability coverages.

Customer Stories and Resources

The past year, we had the privilege to share stories of how our customers are using Insight VM to secure their environment. Check out how your peers are leveraging InsightVM.Here’s what one customer had to say:

“That is one of the things we value most about InsightVM; it has the capacity to pinpoint actively-exploited vulnerabilities, so we can prioritize and direct our attention where it’s needed most.”

• Daniel Hernandez, Information Security Analyst III at Pioneer Telephone Cooperative, Inc.

For customers looking to improve the utilization of the Vulnerability Management tool, check out this webcast series that covers the different phases of VM lifecycle – Discovery, Analyze, Communicate, and Remediate. Lastly, customers can always leverage Rapid7 Academy to participate in workshops and training to continue their learning journey.

Looking forward to 2023

We will maintain the customer-centricity in 2023 as we continue to deliver features and improvements in customers’ best interests. We will be holding a webinar on January 24 around configuration assessment in InsightVM agent-based policy. And, as always, be on the lookout for our annual vulnerability intelligence report coming soon to a Q1 near you (here’s last year’s)!

Post Syndicated from Shane Queeney original https://blog.rapid7.com/2022/09/12/insightvm-best-practices-to-improve-your-console/

Over the years, our recommendations and best practices for the InsightVM console have changed with the improvements and updates we’ve made to the system. Here are some of the most common improvements to help you get the most out of your InsightVM console in 2022.

Ensure everything is up to date

The first step to ensuring the health of your console is ensuring it is up to date. For InsightVM product updates, the typical release schedule is weekly on Wednesday, with the occasional out-of-band update. To stay on the latest version, you can set the update frequency to every 24 hours and set it to off-hours to perform that check. This will ensure the latest update is being applied and the console isn’t rebooting in the middle of the workday.

The InsightVM content updates include new vulnerabilities updated every 2 hours. As these don’t require a system reboot, it is recommended to leave them set to automatically update.

Make sure your scan engines are properly updated as well. As long as the scan engine has enough storage space and can reach the InsightVM console, it should be able to receive the latest update.

Unless you are on a Rapid7-hosted console, you are also in charge of updating the underlying operating system. That means not just applying the latest security patch, but also making sure the OS version itself is not end-of-life.

Lastly, you want to make sure you’re running the latest version of the InsightVM postgreSQL database — version 11.7. If you are still running version 9.4, this can cause some potential issues with the database, as well as general slowdown in the console and running reports.

With the latest InsightVM product updates, we also have a database auto-tune feature which automatically tunes based on the amount of RAM on the console server. This feature does not work if you are still on version 9.4. If you are on version 11.7, to activate it, go to Administration -> Run and then run the command tune assistant to make sure everything is tuned correctly. This will have a greater impact if you have 64GB RAM or above.

Check out this doc on tuning the PostgreSQL database for more detail. If you don’t feel comfortable tuning your own database, you can always contact Rapid7 support for assistance.

Reduce the number of sites

One of the largest improvements to the console is the increase in scan efficiency. Before October 2020, the discovery portion of the scan would only hit 1,024 assets simultaneously. Now, we are running discovery against 65,535 IPs at once. This leads to much faster discovery of larger IP ranges. Because of this, we recommend having fewer sites with larger IP scopes, such as /16 or /8 CIDR ranges.

The best way to organize these new, larger sites is based around function or geographical region – for example, having a separate site for all stores and one for all corporate ranges. Another example would be to break up the sites based on continents, or as large of a geographical region as possible.

Having fewer sites with a larger scope will help reduce the micromanagement of schedules and allow for ease of scalability when scanning more devices. For granular reporting, use asset groups, which are much more flexible than IP ranges and are designed to let you set the scope for reports and access management.

Prevent scan overlap

Besides having too many sites, the next-largest problem most consoles face is when scans overlap on the same scan engine. Having fewer sites helps with having fewer scheduled scans, but you should still be aware what scan engine is being used for those sites. Running a scan uses up RAM on the scan engine, and having too many scans running at once can cause scan slowdown or potentially engine crashes due to lack of memory.

The best-case scenario is to have one scan engine per site. That way, your sites can be scanned at the same time without any chance of them overloading a single engine. If you have some sites or locations that are much larger than others, you can always deploy more engines to that location and pool them together for even greater scan efficiency.

And remember, if you’re scanning more than 2,000 devices or have a segmented network, you should not be using the local scan engine, as that takes away resources from the console and PostgreSQL database.

Optimize scan templates

After making sure your scans aren’t overlapping on the same engine, the next step is to speed up the scans by optimizing your scan template. My colleague Landon Dalke wrote a great blog post documenting the best practices for your scan templates. Here are a few highlights from his post:

Assets scanned simultaneously per scan engine: Please use the following table for reference depending on how much CPU and RAM your scan engines have. Make sure your engines have a 1:4 ratio of CPU to memory for the best performance. Also, if your scan engines are virtual, make sure to reserve the allocated memory to avoid insufficient memory issues.

Send UDP packets to ports: We recommend disabling. It’s unlikely a device will be reachable that doesn’t respond to ICMP, ARP, or TCP but is somehow found only using UDP.

Do not treat TCP reset responses as live assets: We recommend enabling. This will help prevent “ghost assets” with no hostname or operating system from appearing, as some routers or IDS/IPS send TCP reset responses.

Nmap Services Detection: We recommend disabling this, as it can cause scans to take five to 10 times longer to run. Having a credential or agent on a device gives the same information.

Skip checks performed by the Insight Agent: We recommend enabling. If the agent is detected on a device, it will skip the vulnerability checks the agent is already performing, reducing scan time.

If all of your scan engines have the same resources, you can get away with needing one optimized scan template, reducing potential confusion and further simplifying your scan configurations.

After following these steps, your console should be in a much better place to reduce micromanagement and improve overall efficiency. If you need continued help and support, don’t hesitate to reach out to Rapid7 Support or your Customer Success Manager.

Additional reading:

• 5 Steps for Dealing With Unknown Environments in InsightVM
• What’s New in InsightVM and Nexpose: Q2 2022 in Review
• InsightVM Release Update: Let’s Focus on Remediation for Just a Minute
• Maximize Your VM Investment: Fix Vulnerabilities Faster With Automox + Rapid7

Post Syndicated from John Hartman original https://blog.rapid7.com/2022/09/06/5-steps-for-dealing-with-unknown-environments-in-insightvm/

Trying to deal with a large network can be difficult. All too often, engineers and admins don’t know the full scope of their environment and have trouble defining the actual subnets and the systems that exist on those subnets. They know of a couple /24 subnets here or there, but it’s very possible they’re missing a few. Once you get over a couple thousand assets, it can get fairly unruly pretty quick. Different teams own different servers and different network ranges. With regards to InsightVM, how do you know what sites create if you don’t even know what you own?

Luckily, in InsightVM, we can use a little bit of SQL, an overarching site with a ping sweep, and a nifty little tag to help get a handle on things – all outside any third-party software or  other management tools you may acquire to help you wrangle in your IP space. This method in InsightVM lets you find all live assets and identify all network spaces being used in your environment. Then, we can correlate this list against our known subnets and begin building out defined sites for scanning. As we create our known sites, we can start whittling down the number of unknown or undefined subnets.

1. Ping Sweep template

The first step is to create a new scan template dedicated solely to a ping sweep. This template isn’t scanning for any other services or ports, fingerprinting, or performing any other action –  it is simply sending pings to see what is alive. If we get a response back, we assume there is a live asset there, and this will help build out our known networks.

Create your template using these screenshots as guidance. Note that pretty much everything is off except ICMP and ARP pings, and we’re not treating TCP resets as live assets (we don’t want firewalls throwing us off). This scan should take just a few minutes to complete, as it’s not doing all the other functions that a typical scan can do.

2. Overarching site

The second step in this process is to create an overarching site. Give it a simple name like “Full Network” or whatever floats your boat. What’s important is that, within this site, you define as large of a network range as you know of. Think /16 here, or even a couple /16 networks. I don’t know your network, so use your judgment as to what you think exists. The idea is to be as broad as possible.

Now, within this site, set the default scan template as your “.Ping Sweep” template, as in my example above. Set your default scan engine or pool, and then save and scan.

What you should get back now is a full list of every live IP that exists within the defined network. If your defined network includes all the possible IP space, and we are assuming that all assets are online and able to respond, then you should have a pretty robust list of found assets.

3. Known Networks report

The next step is to go to the Reports tab and create a SQL Query Export. Throw the following SQL query in the definition, and scope the query from the GUI to your “Full Network” site.

WITH a AS (
SELECT
asset_id,
CONCAT(split_part(ip_address,'.',1),'.',split_part(ip_address,'.',2),'.',split_part(ip_address,'.',3),'.0/24') AS Network
FROM dim_asset
)
 
SELECT DISTINCT Network
FROM a
ORDER BY Network ASC

Save and run this report, and you will get a CSV output of all the /24 networks that have at least one live IP in them. You can use this CSV to compare to your known list of networks and start defining the actual sites within your environment. For example, if this report lists out 10.0.0.0/24 and you know that network as your main corporate server’s VLAN, then you can include that network into a separate site for vulnerability scanning.

4. Dynamic tagging

Now that we’ve started defining our known networks into sites, we need to create a dynamic tag that gets applied to all assets within any site. Now, in my example, I exclude the Rapid7 Insight Agents site, because depending on your environment and whether people are working from home, the Insight Agent may report the IP of their computer when logged onto their home network. We obviously can’t scan home networks, so we want to exclude this site to deter any of that bad data.

Create a dynamic tag with several lines to include each site. Note that if your site structure is large enough that you have hundreds of sites, you may want to use the API for this part, but we won’t go into that here – that’s a whole other conversation.

In my example below, I only have four sites – keep in mind I did not select the Rapid7 Insight Agents or my Full Network site. Make sure the operator is set to match ANY of the specified filters. Apply a tag called “Defined Network” to this criteria to tag all assets within a defined site.

You could also optionally create a secondary tag for “Undefined Networks,” but it’s not exactly necessary for this process. The below query would get you the Undefined Network assets. Basically, the query is just looking for any assets that don’t have the Defined Network tag and are not in the Rapid7 Insight Agents sites.

5. Undefined Networks report

Now, we can set up our secondary SQL report to show us all networks that are not defined within the scope of a site. Once again, go to the Reports tab, create a SQL Query Export report, and throw this query into the definition.

WITH a AS (
SELECT
asset_id,
CONCAT(split_part(ip_address,'.',1),'.',split_part(ip_address,'.',2),'.',split_part(ip_address,'.',3),'.0/24') AS Network
FROM dim_asset
)
 
SELECT DISTINCT Network
FROM a
 
WHERE a.asset_id NOT IN (
SELECT DISTINCT asset_id
FROM dim_asset
LEFT JOIN dim_tag_asset USING (asset_id)
LEFT JOIN dim_tag USING (tag_id)
WHERE tag_name = 'Defined Network'
)
 
ORDER BY Network ASC

Save and run this report, and you will get a new CSV that lists out all /24 networks where there was at least one live asset found but the assets are within a /24 that has not been defined within the scope of a created site. You can use this CSV to work your way through those networks to determine what they are and who owns them and then ensure they are included in future or current sites.

Large environments with unknown network components can be difficult to manage and monitor for vulnerabilities. These five steps in InsightVM help make the process easier and more intuitive, so you can maintain better oversight and a stronger security posture within your environment.

Additional reading:

• What’s New in InsightVM and Nexpose: Q2 2022 in Review
• InsightVM Release Update: Let’s Focus on Remediation for Just a Minute
• Maximize Your VM Investment: Fix Vulnerabilities Faster With Automox + Rapid7

Post Syndicated from Emmett Kelly original https://blog.rapid7.com/2022/03/15/insightvm-scanning-demystifying-ssh-credential-elevation/

Written in collaboration with Jimmy Cancilla

The credentials to log into the assets on the network are one of the most critical inputs that can be provided to a vulnerability assessment. In order to capture and report on the full risk of an asset, the scan engine must be able to access the asset so that it can collect vital pieces of information, such as what software is installed and how the system is configured. For UNIX and UNIX-like systems, access to a target is primarily achieved through the Secure Shell Protocol (SSH). Thus, scan engines accessing these systems should have access to the appropriate SSH credentials.

However, this raises the question: What are appropriate SSH credentials? In order for a vulnerability or policy assessment to provide accurate and comprehensive results, the scan engine should ideally be able to gain root-level access to the systems being assessed. Understandably, many security teams are wary about providing the scan engine with root credentials to all of their systems. Instead, security teams prefer to provide a non-root set of credentials that are capable of elevating to become root. In this context, credential elevation means logging into a system with one set of credentials that has fewer privileges and then elevating that credential to gain root-level privileges. In this way, IT administrators can provide service users that can be monitored and easily disabled if necessary.

In the next section, we will look at the different ways that credentials can be elevated.

Elevation options

sudo

The sudo command enables users to run commands with the security privileges of another user, which by default happens to be the root user (superuser). The ability to use the sudo command to elevate to root is a privilege that is provided by the system administrator. The administrator explicitly grants users (or groups) permission to use the sudo command — this is typically done by modifying the /etc/sudoers file on Linux-based systems.

The benefit of having access to the sudo command means that a user does not need to know the root password in order to gain root-level privileges. However, the user attempting to elevate to root-level privileges via sudo may still need to authenticate themselves by providing their own password. This is different from the behaviour of the su command, which will be discussed later.

What this means in terms of configuring sudo elevation in the Security Console is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the user attempting to elevate to root.

su

Like the sudo command, the su command enables users to run commands with the security privileges of another user, the default being to run the commands as the root user (superuser). However, unlike the sudo command, the su command typically does not require a system administrator to provide explicit permission to use the command. Instead, users can use the su command to switch to any other user on the system but must provide the password of the target user. The implication of this is that in order to use the su command to elevate to root-level privileges, the user must authenticate by providing the root password.

What this means in terms of configuring su elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the root user.

sudo+su

If you have read the above sections on sudo and su, you may be asking yourself why you would need to combine the two commands. The answer comes down to a subtle but important difference between the two commands, namely the environmental context in which those commands are invoked. When using sudo to execute another command with root-level privileges, the command is run within the current user’s environment. This means that any environment-specific properties (for example, environment variables) are retained. When using su to execute another command with root-level privileges, su will invoke the default shell used by root and then run the command within that environment. This implies that any environment-specific properties loaded by default when logging into the root user will be set.

Given this explanation, combining the sudo and su commands provides a best of both worlds situation: It allows a user to elevate their privileges to root by providing their own user password, and it will execute the command within the context of the root environment (as opposed to the user’s environment). How does this work?

The first command executed is sudo, which will prompt the user to authenticate themselves by entering their own password. Then, the su command will be run. However, since it is running with root-level privileges, it won’t prompt for another password but instead will execute any commands within the context of the root environment. So to summarize, sudo+su allows for executing commands with root-level privileges within the context of root’s environment but without requiring knowledge of the root password.

What this means in terms of configuring sudo+su elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the password of the user attempting to elevate to root.

Important note about sudo, su and sudo+su

The Permission Elevation User should be root. A common misconfiguration when configuring permission elevation is to set this value to the user’s username. This leads to the scan engine logging in as the initial user, then using permission elevation to attempt to elevate to the same user! The credential status will be reported as successful, but the scan results will not have the same accuracy of a correctly configured scan with root permissions.

pbrun

The pbrun command is a utility within the PowerBroker application provided by BeyondTrust. It works similarly to the sudo command in that it allows a user to elevate to root-level privileges without having to provide the root password.

Configuring privilege escalation with pbrun in the Security Console is fairly straightforward, as it does not require any additional passwords beyond the user’s password.

Cisco Enable / Privileged Exec

This option specifically allows a user to elevate to superuser-level privileges on certain Cisco devices using the enable command. Administrators of the Cisco devices will need to have configured an enable password to allow for privilege elevation.

What this means in terms of configuring Cisco Enable / Privileged Exec elevation in the Security Console, is that the Permission Elevation Password on the “Add Credentials” page must be set to the Cisco Enable password configured on the devices.

Perils of not elevating

Elevation is critical to accurately assess an asset for vulnerabilities and system configurations. There are several key pieces of information that can only be collected with root-level privileges. Improperly configuring credential elevation is one of the most common causes of inaccurate or incomplete assessment results. The following table outlines a few key operations and pieces of data that require root-level privileges. It is important to note that this is a non-exhaustive list operations and data requiring root-level privileges – an exhaustive list would quickly become outdated as new data collection techniques are constantly being added to the product.

Conclusion

When it comes to vulnerability management, retrieving accurate and comprehensive results is paramount to mitigating risks within your organization. The most accurate data is collected when the scan engine has root-level access to the systems it is scanning. However, not all organizations may be in a position to provide the root password to these systems.

In this case, a best practice is to provide the vulnerability management software with a service account that is capable of elevating its permissions to root. This allows system administrators to more easily manage who is capable of elevating to root and, if necessary, revoke access. However, there are several different ways that an account can elevate its permissions. Each method comes with subtle but important differences. Understanding those differences is critical to ensuring that elevation to the correct level of permissions occurs successfully.

Additional reading

• InsightVM Scan Engine: Understanding MAC Address Discovery
• What’s New in InsightVM and Nexpose: Q4 2021 in Review
• Distribute Reports to Email Addresses in InsightVM
• InsightVM Scan Diagnostics: Troubleshooting Credential Issues for Authenticated Scanning

Post Syndicated from Emmett Kelly original https://blog.rapid7.com/2022/03/07/insightvm-scan-engine-understanding-mac-address-discovery-2/

Written in collaboration with Jimmy Cancilla

When scanning an asset, one key piece of data that the InsightVM Scan Engine collects is the MAC address of the network interface used during the connection. The MAC address is one of several attributes used by the Security Console to perform asset correlation. As a result of the volatile nature of IP addresses, identifying assets using the MAC address can provide increased reliability when integrating scan results. In some cases, the MAC address can be used as a rudimentary means of fingerprinting an asset. Several manufacturers will use the same first 3 bytes when assigning a MAC address to a device (for example, several CISCO SYSTEMS, INC devices use 00000C as the MAC address prefix).

When performing an authenticated scan (a scan whereby the engine has the necessary credentials to authenticate to the target), collecting the MAC address is relatively straightforward, as all operating systems provide tooling to gather this information. However, collecting the MAC address with an unauthenticated scan (a scan where no credentials are provided) is less reliable. This is due to limitations of network protocols and modern network topologies.

Breaking down IP protocols

In order to understand these limitations, it is important to first understand the fundamentals of the IP protocol suite.

The IP protocol suite can be thought of in 4 layers:

The MAC address is part of the bottom layer called the Link Layer. The MAC address is used by the hardware when communicating with other devices on the same network equipment. Any devices communicating at the Link layer do so without the use of routers.

On the other hand, IP addresses are part of the Network layer. IP addresses are used to communicate with devices across different networks, traversing through routers.

MAC address discovery with unauthenticated scans

This leads to the limitation in unauthenticated scans. When performing an unauthenticated scan against assets that are accessed via a router, the scan engine is only able to communicate with that asset via the Network layer. The implications of this are that the MAC address is not included in the network packets received by the scan engine. This is not a limitation or defect of the scan engine, but rather a reality of the IP protocol suite and modern network infrastructure.

To work around these limitations in the IP protocol suite, the InsightVM scan engine uses several alternative methods to attempt to collect the MAC address of assets being scanned. In general, these alternative methods attempt to authenticate to an asset over various protocols using known default credentials. As a result of this capability in the scan engine, asset results from unauthenticated scans may include the MAC address despite being scanned over a router. However, it is important to note that the success rate is dependent on whether assets are configured to allow authentication using default credentials.

Note: SNMPv1 and SNMPv2 are more likely than most protocols to be configured with known default credentials.

Summary

The following tables outline the different methods that the scan engine will use to collect MAC addresses from targets, and whether or not authentication is required.

Windows

Linux

Over the years, the engineering team here at Rapid7 has partnered with dozens of security teams to identify pain points and develop solutions. The importance of collecting the MAC address for targets being scanned is well understood. As a result, the InsightVM Scan Engine has been designed to utilize a multi-pronged approach to collecting MAC addresses from assets.

Additional reading:

• What’s New in InsightVM and Nexpose: Q4 2021 in Review
• Log4Shell 2 Months Later: Security Strategies for the Internet’s New Normal
• Dropping Files on a Domain Controller Using CVE-2021-43893
• Distribute Reports to Email Addresses in InsightVM