Log4net Exploit

[Irati Klute]

Multiple NetApp products incorporate Apache Log4net. Log4net versions prior to 2.0.10 are susceptible to a vulnerability which when successfully exploited could lead to disclosure of sensitive information, addition or modification of data, or Denial of Service (DoS).

If you do the log4net.dll file properties you can see that it is version 2.0.8.0 and according to CVE-2018-1285 it has a vulnerability. The solution is to update the log4net.dll to version 2.0.10 or higer.

It looks like that dll is found in old version. So you need to remove app-3.4.7 from C:\Users\XXX\AppData\Local\SourceTree. When there is any version of Sourcetree is available then it gets downloaded into C:\Users\XXX\AppData\Local\SourceTree with new folder and we updates from there. Currently old version cleanup from AppData is not supported.

Apparently, no features which allow the Apache log4net vulnerability to be exploited have been implemented. Theoretically, even if Fortinet reports the CVE, it would be safe to say that it cannot be used to cause a breach.

Apache log4net versions before 2.0.10 do not disable XML external entities when parsing log4net configuration files. This allows for XXE-based attacks in applications that accept attacker-controlled log4net configuration files.

The EMS GUI will show which software/application is using log4net, which you need to upgrade. If the software is not listed, you will need to look the Endpoint log and find the software associated with the log4net.

Please let me know if this helps :)

Hi, i have a problems with this vulnerability. Anyone will help me please. The EMS sometimes appear 10 pc with this problem. Other day the EMS appear only 2 pc with these problem. I dont know how to resolve this problem log4net.

The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.

Following on from the recent vulnerabilities reported last month with Log4J it has since been reported that there are additional vulnerabilities with different versions of Log4J. During this investigation, we have also identified a potential vulnerability with the Log4Net used for logging in some of the other products used in conjunction with Autoform DM.

By default, the JMS Appender is not configured within Formpipe Products and we have never recommended that anyone should configure it. In order to exploit this vulnerability, an attacker would have to have access to the logging configuration file, reconfigure logging and then restart the service.

Although for the sake of complete openness and security, it is possible to remove the appender in question by removing the Org/apache/log4j/net/JMSAppender.class file from the Log4J file.

While reviewing Apache libraries, it has also been identified that some Formpipe Products are running older versions of Log4Net with a potential vulnerability ( -2018-1285) which would allow an attacker to perform an XXE (XML External Entity Reference) attack if able to supply a configuration file to an application. This has no relation to the recently identified Log4Shell vulnerability which targets Log4J.

This affects Log4Net versions prior to 2.0.10 of which a number of the .Net based applications use. However, the vulnerability specifically requires the ability for the attacker to provide a configuration file at runtime. Having analysed the affected applications, we can confirm that none of them support this and thus do not provide a means by which to exploit the issue.

As such this is classified as low risk. For anyone concerned about the issue, we recommend that they review our standard security recommendations - namely to ensure application installations are protected with appropriate file permissions and access controls, and that user access follows the principal of Least Privilege.

This module uses Log4Net as a logging library and has a new version released with an updated library. While new releases of Lasernet will contain this fix, it can also be manually updated using the files available here:

A vulnerability in a widely used logging library has become a full-blown security meltdown, affecting digital systems across the internet. Hackers are already attempting to exploit it, but even as fixes emerge, researchers warn that the flaw could have serious repercussions worldwide.

A vulnerability has been discovered affecting the Bosch Fire Monitoring System (FSM-2500, FSM-5000, FSM-10k and obsolete FSM-10000). The issue applies to FSM server with version 5.6.630 and lower, and FSM client with version 5.6.2131 and lower. Bosch recommends customers to update vulnerable components with the provided patch. The vulnerability has been discovered in field.

The vulnerability CVE-2018-1285 in the affected component Apache log4net is rated with a CVSS v3.1 Base Score of 9.8 (critical), but the exploitability is reduced in a proper installation of Fire Monitoring System (FSM): local system access with administrative access rights is required to exploit the vulnerability. This leads to a lower Environmental/Overall CVSS v3.1 Score of 6.7 (medium).

It is your responsibility to download and/or install any security updates provided by us, for example to maintain product or data security. If you fail to install a security update provided to you within a reasonable period of time, we will not be liable for any product defect solely due to the absence of such security update.

Alternatively, we are entitled to directly download and/or install security updates regardless of your settings. In these cases, we will provide you with the relevant information, e.g. in this security advisory.

The easiest way to add the log4net and the InsightOps Target libraries to your application is to install the R7Insight.Log4net Nuget package. This package will install the InsightOps Target library and will also automatically install the log4net package as a dependency.

If you would rather install the InsightOps appender manually, you can download the complete code in this GitHub repository, compile the R7InsightLog4net Visual Studio project within it into a DLL file, and then reference this file in your application. If you choose this option you must install log4net yourself.

log4net allows log messages to be sent to multiple destinations. In log4net terminology, such an output destination is called an appender. Appenders must implement the log4net.Appenders.IAppender interface. The InsightOps Appender library provides such an appender component that is specifically designed to send log messages to InsightOps in an efficient manner.

Our recommended method of sending messages to InsightOps is via Token TCP over port 10000. To use this method, select Token TCP as the source type when creating a new log in the InsightOps UI, and then paste the token that is printed beside the log in the value for the Insight.Token credential setting.

The InsightOps appender supports sending log data over SSL/TLS with both of the above logging methods by setting the useSsl logging setting to true in the appender definition. This is more secure but may have a performance impact.

The InsightOps appender keeps an internal queue of log messages and communicates with the InsightOps system using a background thread which continuously sends messages from this queue. Because of this, when an application is shutting down, it is possible that some log messages might still remain in the queue and will not have time to be sent to InsightOps before the application domain is shut down.

To work around this potential problem, consider adding the following code to your application, which will block for a moment to allow the InsightOps appender to finish logging all messages in the queue. The AreAllQueuesEmpty() blocks for a specified time and then returns true or false depending on whether the queues had time to become empty before the method returns.

The first vulnerability, CVE-2023-45252, enabled privilege escalation due to the service being installed in a directory that grants write privileges to regular users. The second vulnerability, which was identified as CVE-2023-45253, enabled local privilege escalation through a privileged file operation executed by the service under the SYSTEM user context.

The vulnerabilities were reported on August 10, 2023, and Huddly promptly addressed them by releasing a fix on September 21, 2023. The solution to resolve these vulnerabilities involves upgrading to version 8.0.7 of the program, officially released on September 21, 2023. Our team has thoroughly tested this patch, and it has effectively rectified the issues.

By using Microsoft's Process Monitor (ProcMon), which can be used to analyze and monitor file operations on a Windows system, it was found that the HuddlyCameraService.exe file was executed as NT AUTHORITY\SYSTEM from the C:\Windows\Temp\.net\HuddlyCameraService folder, as highlighted in Figure 1. Additionally, the process attempted to load missing dynamic-link library (DLL) files from the same folder.

Due to regular users having write permissions in C:\Windows\Temp\.net\HuddlyCameraService, which contains permissions inherited from C:\Windows\Temp, the service was susceptible to a local privilege escalation attack that could be exploited through a DLL hijacking attack. The permission inheritance is demonstrated in Figure 2 and Figure 3.

To exploit the vulnerability, an adversary could drop a payload as one of the missing DLLs into C:\Windows\Temp\.net\HuddlyCameraService\IQQF1G9DDW8qNL0XgxzvxAVCQLDvvYE=, and then reboot the machine. This often works because Windows uses a pre-defined search path to find DLL, which searches in a specific order.

3a8082e126