November 7, 2017 by Corelight
Zeek releases 4.0.8/5.0.1 resolve some denial of service attacks on the sensor. In its default configuration they do not apply, but if you have enabled MODBUS or DNS EDNS header parsing and are DDoSed that way, you will need to disable them again. This is a low priority fix we will address in the regular release cadence. Link 4..0.8 to https://github.com/zeek/zeek/releases/tag/v4.0.8
Zeek has been patched (v4.0.7 and 4.2.2) for a denial of service vulnerability against specially crafted packets. We intend to release version 1.5.1 of the software sensor shortly to address. Version 25.3 of the Appliance with the changes is expected next week.
Both open source Zeek and Corelight products are vulnerable to CVE-2022-0778. A patched version of the software sensor has been released and an appliance sensor version (including VM and cloud) is in verification. You can expect a v24.1 update late Friday or over the weekend to prevent any denial of service attacks via 0778.
Corelight sensors are not subject to the polkit pkexec 0-day (CVE-2021-4034).
Since the announcement of CVE-2021-44228, customers have been asking questions about whether the Corelight products are susceptible to this exploit and if they can be used to detect it. Our research into this shows that there are no exploitable log4j vulnerabilities in Corelight Sensors or Fleet Manager. See https://support.corelight.com/hc/en-us/articles/4412592547731-CVE-2021-44228-Log4j for updates and tips on detections.
The Zeek project announced two security fixes in September. Corelight’s v22.1 already resolves one of them, and v23 will resolve the denial of service vulnerability. Concerned customers can receive a patch in advance of v23 through support.
The underling OS has a sudo that is vulnerable per this CVE. However users (including admin) can't access the underlying OS because of the appliance design. (In particular the diagnostic shell, which is the closest admins can get, does not have a sudo binary.) And on top of that it's jailed anyway. All that said, we plan on fixing it; it'll be in the list of CVEs addressed on the support site.
It's all over the press, so we wanted to jump in with our "Sunburst" thoughts. First, we're not an Orion customer. Second, an internal investigation saw no Orion activity, nor any hits on the IOCs published. Third, while the details of how the supply chain attack succeeded are sparse, we have high confidence the the security of our product's upgrade chain, so we see no reason for our customers to be concerned about Corelight as a vector. Finally, Zeek was instrumental in tracking them down! Read more at: https://corelight.blog/2020/12/15/finding-sunburst-backdoor-with-zeek-logs-and-corelight/
Securty-related changes in our Sensor releases are below, note that many minor CVEs are patched in release without detail here, see the support site for the list:
v20 Added more logging to the Audit log and pulled in some Open Source Zeek security fixes (denial of service ones).
v19.2 Pulled in Zeek security fixes for potential stack overflow in Netbios-SSN or DNS analysis
v19.1 Fixed privilege escalation bug
v19 Fixed a bug that potentially failed to report errors in applying configurations.
Added more events to audit log
Upgraded to Zeek 3.0.4, including security patches
v18.1 Added an option to disable TLSv1.1
v18 Upgraded Bro to 2.6.4 including security fixes
Expanded sensor logging and authentication options, including an audit log, a security banner, cipher suite compliance, and user session timeouts.
v1.15 Updated Bro to include version 2.5.5’s security patches.
v1.14.1 Updates Bro to version 2.5.4, which is a security release
v1.14.1 Corelight Announces FIPS 140-2 compliance for the sensors.
v1.13 has been released with the Meltdown patch. Please update to v1.13 or later for the latest in protection.
Given widespread concern about the Intel Meltdown vulnerability we wanted to provide an update on steps we're taking to address this issue. While the Corelight Sensor uses Intel processors we believe the risk of data compromise via a Meltdown exploit is very low due to the sensor's design, which limits access to logged in accounts via the Diagnostic Shell. Consequently, we recommend that you verify that SSH access to your Corelight Sensor(s) is appropriately limited. The forthcoming v1.13 sensor software release will also include a patch that fixes this vulnerability.
Corelight Sensor v1.12.1: Open source Bro release 2.5.2 fixed an out-of-bounds write condition which would crash Bro. This could be used as a denial of service attack against the Corelight Sensor, so we have released v1.12.1 to include Bro 2.5.2 and resolve any potential issue.