As we said in our recent blog, we believe the Solorigate incident is an opportunity to work together in important ways, to share information, strengthen defenses and respond to attacks. Like other SolarWinds customers, we have been actively looking for indicators of the Solorigate actor and want to share an update from our ongoing internal investigation.
Year: 2020
Nobelium Resource Center – updated March 4, 2021
UPDATE: Microsoft continues to work with partners and customers to expand our knowledge of the threat actor behind the nation-state cyberattacks that compromised the supply chain of SolarWinds and impacted multiple other organizations. Microsoft previously used ‘Solorigate’ as the primary designation for the actor, but moving forward, we want to place appropriate focus on the actors behind the sophisticated attacks, rather than one of the examples of malware used by the actors.
Customer Guidance on Recent Nation-State Cyber Attacks
Note: we are updating as the investigation continues. Revision history listed at the bottom.
This post contains technical details about the methods of the actor we believe was involved in Recent Nation-State Cyber Attacks, with the goal to enable the broader security community to hunt for activity in their networks and contribute to a shared defense against this sophisticated threat actor.
Security Update Guide: Let's keep the conversation going
Hi Folks,
We want to continue to highlight changes we’ve made to our Security Update Guide. We have received a lot of feedback, much of which has been very positive. We acknowledge there have been some stability problems and we are actively working through reports of older browsers not being able to run the new application.
新しいセキュリティ更新プログラム ガイド (Security Update Guide) を使ってみよう
新しいバージョンのセキュリティ更新プログラムについては下記の関連ブログもご覧ください。 「新しいセキュ
Detecting vulnerable software on Linux systems
The Wazuh security platform can identify if the software installed on your endpoints has flaws that may affect your infrastructure security, so it detects vulnerable software. In a previous post, we showed how to scan Windows systems to determine which vulnerabilities affect them, showcasing Wazuh integration with the National Vulnerability Database (NVD).
For this blog post we will focus on Wazuh support for Linux platforms, including distributions such as CentOS, Red Hat, Debian, or Ubuntu. Detecting vulnerabilities on these systems presents a challenge, since it requires integrations with different data feeds.
Vulnerabilities data sources
Wazuh retrieves information from different Linux vendors, which it uses to identify vulnerable software on the monitored endpoints. Here are some CVE (Common Vulnerabilities and Exposures) statistics from these vendors:
These charts expose the first challenge of vulnerability detection: data normalization. Wazuh not only pulls information from the different vendor feeds, but it processes the data so it can be used to identify vulnerabilities when scanning a list of applications.
The second challenge is that the vendor feeds only provide information about the packages published in their repositories. So, what about third-party packages? Can we detect vulnerabilities in those cases? This is where the NVD (National Vulnerability Database) comes in handy. It aggregates vulnerability information from a large number of applications and operating systems. For comparison with the Linux vendor charts, here is the number of CVEs included in the NVD database.
To see how useful the NVD data is, let’s see an example.
CVE-2019-0122
According to the NVD, this vulnerability affects the Intel(R) SGX SDK for Linux. More specifically, it affects all its software packages up to version 2.2.
In this case, the vendor website claims that the vulnerable versions of the package (the ones before version 2.2) can be installed on Ubuntu 16.04 and RHEL 7. Unfortunately, the Ubuntu and RHEL vulnerability feeds do not include this CVE . The reason, as expected, is that their repositories do not provide this software package.
At this point we wonder if the NVD includes this vulnerability. Which data feed should we trust? The answer presents another challenge for proper vulnerability detection: data correlation.
Vulnerability Detector architecture and workflow
The next diagram depicts the Vulnerability Detector architecture. This Wazuh component has been designed to simplify the addition of new vulnerability data sources, so support for other platforms and vendors can be added in the future.
At first, the Vulnerability Detector module downloads and stores all vulnerabilities data from different sources. Then, it analyzes the list of software packages installed on each monitored endpoint, previously gathered by the Wazuh agent component. This analysis is done correlating information from the different data sources, generating alerts when a software package is identified as vulnerable.
Analysis workflow
To fully understand the process of data correlation, let’s see step by step what the Vulnerability Detector module is doing when analyzing a list of Linux packages.
- At first, it reads the list of packages installed on the monitored endpoint. This information is collected by the Wazuh agent.
- For each software package, using the Linux vendors and NVD feeds, it now looks for CVEs with the same package name.
- When the package name is affected, it now checks that the package version is also reported as vulnerable in the CVE report.
- When both software attributes, the package name and its version, are reported as vulnerable then correlation is done looking for false positives. Alerts are discarded when:
- For a CVE reported by the NVD, the Linux vendor states that the package is patched or not affected.
- For a CVE that requires multiple software packages present, one or more packages are missing.
- For a CVE reported by a Linux vendor, the NVD identifies the software as not affected.
- Finally, after the correlation is done, the Vulnerability Detector module alerts on vulnerable software when necessary.
Reviewing detected vulnerabilities in the UI
After the process mentioned above is completed, we can find the CVE alerts in the Wazuh User Interface. To see the details of these alerts, let’s take an interesting example: the CVE-2020-8835.
This is a Linux kernel vulnerability that affects the BPF (Berkeley Packet Filter) component and can be used to achieve local privilege escalation in Ubuntu systems. It was exploited during the recent Pwn2Own 2020 computer hacking contest, to go from a standard user to root.
Conclusion
The correlation of the vulnerability data, provided by each Linux vendor and NVD feeds, gives Wazuh the ability to report known CVEs for software packages that are not provided by the official Linux vendor repositories. Besides, it shortens the detection time to the fastest CVE publisher and helps discard false positives. Finally, it enriches the data provided by the alerts, giving users more context around the detected vulnerabilities.
References
- Ubuntu OVAL Data
- Debian OVAL Data
- Red Hat CVE Database
- NVD Vulnerabilities Database
- Zero Day Initiative – PWN2OWN 2020
- Zero Day Initiative – CVE-2020-8835: Linux kernel privilege escalation
If you have any questions about this, don’t hesitate to check out our documentation to learn more about Wazuh or join our community where our team and contributors will help you.
The post Detecting vulnerable software on Linux systems appeared first on Wazuh.
Wazuh 4.0 released
We are glad to announce that Wazuh 4.0.0 is released. Discover the new additions and improvements here! Wazuh is now better than ever.
New features and changes in Wazuh 4.0
The Wazuh API is now a part of the Wazuh manager package. Its performance has been improved, it incorporates role-based access control (RBAC) capabilities and it is easier to use and deploy.
The manager and agent’s default communication protocol is now TCP. This change guarantees a reliable delivery of the data collected by the agents, the pushing of centralized configuration settings in real-time and faster execution of active responses.
This version includes a new feature for agent auto-enrollment. Now agents automatically request a registration key when needed, preventing them from losing their connection with the Wazuh manager when keys are lost or corrupted.
API RBAC (Role-Based Access Control)
The Wazuh API now includes role-based access control. This feature manages the access to API endpoints, using policies and user roles. It also allows role and policy assignments to users that will fulfill different functions in the environment.
You can access the RBAC configuration menu on the Wazuh WUI on Wazuh > Security
This capability will, for example, allow the access restriction of a user to the FIM monitored files of a group of agents. You can read here more about how to add roles to users.
Agents auto-enrollment
There is no need to request a key using an external CLI because the agents can now request the key autonomously. When an agent has a manager IP defined on its ossec.conf it will automatically request the key to the manager if does not have a valid key at startup.
The auto-enrollment functionality also allows the agent to request a new key in case of losing the connection with the manager. If this happens, the agent will check if the manager is defined on theossec.conf and if it is, it will request a new key by default every 10 seconds up to 5 consecutive times. Both the number of request attempts and the frequency these keys are requested can be customized on the ossec.conf.
The agent enrollment can still be done using the agent-auth, but with the auto-enrollment, there is no need to request the key. It is worth mentioning that all the agents from previous versions are still 100 % compatible with the 4.x version.
FIM: Disk quota limitations
FIM implements a group of settings to control the module temporal files disk usage. This means that we can now choose the amount of disk space used by the report change utility. The diff option reports changes in the monitored files by creating a compressed copy of the file and checking if it changes. This method may use a lot of disk space depending on the number of files monitored, so this new setting will help prevent this situation by allowing the user to set limits. Wazuh 4.0 introduces new capabilities to limit the space used:
disk_quota: This field specifies the total amount of space thediffutility can use. By default, this value is set to 1GB.file_size: This option limits the file size which will reportdiffinformation. Files bigger than this limit will not reportdiffinformation. By default, this limit is set to 50MB.
Here is an example of how to use disk_quota and file_size:
<diff>
<disk_quota>
<enabled>yes</enabled>
<limit>1GB</limit>
</disk_quota>
<file_size>
<enabled>yes</enabled>
<limit>50MB</limit>
</file_size>
<nodiff>/etc/ssl/private.key</nodiff>
</diff>
In addition, you can now monitor directories using environment variables. More information about how to set a list of directories to be monitored.
Wazuh Kibana plugin
The Wazuh Kibana plugin adds support for Open Distro for Elasticsearch v1.10.1 and Elastic Stack v7.9.1 and v7.9.2.
Apart from the RBAC support, this upgrade brings new configuration view settings for GCP integration and has expanded the supported deployment variables.
The Wazuh Kibana plugin also adds statistics for the listener engine:
And the analysis engine:
To learn more about all the new features and changes in the Wazuh Kibana plugin, visit its repository.
More information and links about Wazuh 4.0
This release includes a lot more features, you can find more information in the following links:
If you have any questions about Wazuh 4.0, don’t hesitate to check out our documentation to learn more about Wazuh. You can also join our Slack and our mailing list where our team and other users will help you.
The post Wazuh 4.0 released appeared first on Wazuh.