Mar 07 2023

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

Category: Log Management,Security logs,Windows Security — DISC @ 8:13 am
Diving Deeper Into Windows Event logs for Security Operation Center (SOC) – Guide

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(Critical, High, Low & 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 Security — DISC @ 6:00 pm
Windows-Event-LogDownload

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 logs — DISC @ 8:26 am
Experts spotted Syslogk, a Linux rootkit under development

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 11 2022

Night Sky ransomware operators exploit Log4Shell to target hack VMware Horizon servers

Category: Information Security,Log Management,Log4j,Ransomware — DISC @ 10:40 am
Night Sky ransomware operators exploit Log4Shell to target hack VMware Horizon servers

The Night Sky ransomware operation started exploiting the Log4Shell flaw (

CVE-2021-44228
) in the Log4j library to gain access to VMware Horizon systems.

The ransomware gang started its operations on December 27, 2021, and has already hacked the corporate networks of two organizations from Bangladesh and Japan respectively. The gang has also set up a leak site on the Tor network where it will publish files stolen to the victims that will not pay the ransom.

Researchers from MalwareHunterteam first spotted the ransomware family, once encrypted a file, the ransomware appends the ‘.nightsky‘ extension to encrypted file names.

In early January, threat actors started targeting VMware Horizon systems exposed on the Internet. VMware has addressed Log4Shell in Horizon with the release of 2111, 7.13.1, 7.10.3 versions, but unfortunately many unpatched systems are still exposed online.

On Monday, Microsoft posted a warning about a new campaign from a China-based actor it tracks as DEV-0401 to exploit the Log4Shell vulnerability on VMware Horizon systems exposed on the internet, and deploy Night Sky ransomware.

Tags: Log4shell, Night Sky ransomware

Jan 07 2022

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

Category: Log Management,Log4j,Security logs — DISC @ 10:14 am
Log4Shell-like security hole found in popular Java SQL database engine H2

“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 06 2022

A Deeper Dive Into the Value of Centralized Logging

Category: Log Management,Security logs — DISC @ 10:34 am
A Deeper Dive Into the Value of Centralized Logging

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 logs — DISC @ 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 logs — DISC @ 11:39 am
Apache Log4j 2.17.1 fixes new remote code execution flaw (CVE-2021-44832)

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 Security — DISC @ 11:14 am

Windows-event-log-analysis-1Download

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 27 2021

Experts monitor ongoing attacks using exploits for Log4j library flaws

Category: Log Management,Log4j — DISC @ 11:01 am
Experts monitor ongoing attacks using exploits for Log4j library flaws

Researchers from DrWeb monitored attacks leveraging exploits for vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE2021-4104, and CVE-2021-42550) in the Apache Log4j library warning of the need to adopt protective measures.

The vulnerabilities can allow threat actors to execute arbitrary code on the target systems, trigger a Denial of Service condition, or disclose confidential information.

Dr. Web set up one of its honeypots to analyze the impact of the Log4J vulnerabilities on systems exposed online and discovered an intense activity between December 17th-20th.

log4j

“We record attacks using exploits for the vulnerabilities on one of our honeypots–a special server used by Doctor Web specialists as bait for fraudsters. The most active threat occurred between December 17th-20th, but attacks still continue.” reads the analysis published by DrWeb.

DayNumber of attacks
December 107
December 1120
December 1225
December 1315
December 1432
December 1521
December 1624
December 1747
December 1851
December 1933
December 2032
December 2114
December 2235
December 2336

The attacks are carried out from 72 different IP addresses, most of them were German IP addresses (21%), followed by Russia (19.4%), the USA and China (9.7%).

Log4J by [J. Steven Perry]

Tags: Log4j library flaws

Dec 20 2021

Log4Shell: The Movie
 a short, safe visual tour for work and home

Category: Log Management,Log4j,Security vulnerabilities — DISC @ 11:52 am
Log4Shell: The Movie… a short, safe visual tour for work and home

As Christmas 2021 approaches, spare a thought for your sysamins, for your IT team, and for your cybersecurity staff.

There may be plenty of mice stirring all through the IT house right up to Christmas Eve



because that’s the deadline set by the US Cybersecurity and Infrastructure Security Agency (CISA) for patching the infamous Log4Shell vulnerability, a dangerously exploitable flaw in Apache’s widely used Log4j (Logging for Java) programming toolkit.

Since news first broke of the problem on 09 December 2021, Apache has a-patched the code not once but three times, variously fixing CVE-2021-44228 with version 2.15.0, quickly followed by 2.16.0 to fix a related bug dubbed CVE-2021-45046, foillowed quickly yet again by 2.17.0 to deal with CVE-2021-45105.

Why the pressure from CISA? Why the rush when we’re supposed to enjoying a global holiday season? Why not wait until New Year and deal with things then?

Here’s why your sysadmins are taking one (three, actually) for the team


Log4Shell Response and Mitigation Recommendations

Advisory: 2021-007: Log4j vulnerability – advice and mitigations

Apache Log4j 2 v. 2.17.0 User’s Guide

Tags: Log4j, Log4shell

Dec 16 2021

Active scanning for Apache Log4j 2

Category: Log Management,Log4j,Security vulnerabilities — DISC @ 3:56 pm

Active-scanning-for-Apache-Log4j-2-1Download

Tags: Apache Log4j 2

Dec 14 2021

Here We Go Again: Second Log4j Flaw Surfaces

Category: Log Management,Log4j,Security logs — DISC @ 11:03 pm
Here We Go Again: Second Log4j Flaw Surfaces

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

May 08 2021

Records and Information Management: Fundamentals of Professional Practice

Category: data security,Information Security,Log Management — DISC @ 11:06 am

Records and Information Management: Fundamentals of Professional Practice, Fourth Edition presents principles and practices for systematic management of recorded information. It is an authoritative resource for newly appointed records managers and information governance specialists as well as for experienced records management and information governance professionals who want a review of specific topics. It is also a textbook for undergraduate and graduate students of records management or allied disciplines—such as library science, archives management, information systems, and office administration—that are concerned with the storage, organization, retrieval, retention, or protection of recorded information.

The fourth edition has been thoroughly updated and expanded to:

  • Set the professional discipline of RIM in the context of information governance, risk mitigation, and compliance and indicate how it contributes to those initiatives in government agencies, businesses, and not-for-profit organizations
  • Provide a global perspective, with international examples and a discussion of the differences in records management issues in different parts of the world. Its seven chapters are practical, rather than theoretical, and reflect the scope and responsibilities of RIM programs in all types of organizations.
  • Emphasize best practices and relevant standards.

The book is organized into seven chapters that reflect the scope and responsibilities of records and information management programs in companies, government agencies, universities, cultural and philanthropic institutions, professional services firms, and other organizations. Topics covered include the conceptual foundations of systematic records management, the role of records management as a business discipline, fundamentals of record retention, management of active and inactive paper records, document imaging technologies and methods, concepts and technologies for organization and retrieval of digital documents, and protection of mission-critical records. In every chapter, the treatment is practical rather than theoretical. Drawing on the author’s extensive experience supplemented by insights from records management publications, the book emphasizes key concepts and proven methods that readers can use to manage electronic and physical records.

Records and Information Management 4th Edition by Dr. William Saffady now available

Tags: DPO, Information Management, Records Management, Records Managementrecords and information management

Jul 18 2020

Seven ‘no log’ VPN providers accused of leaking – yup, you guessed it – 1.2TB of user logs onto the internet

Category: Log Management,VPN — DISC @ 2:34 pm

Maybe it was the old Lionel Hutz play: ‘No-logging VPN? I meant, no! Logging VPN!’

Source: Seven ‘no log’ VPN providers accused of leaking – yup, you guessed it – 1.2TB of user logs onto the internet

 

Download a Security Risk Assessment Steps paper!

Subscribe to DISC InfoSec blog by Email

Take an awareness quiz to test your basic cybersecurity knowledge

DISC InfoSec 🔒 securing the business 🔒 via latest InfoSec titles




Jan 14 2014

What to Log for Authentication and Access Control

Category: Access Control,Log Management — DISC @ 10:30 am

Authentication and access control plays a critical role in web application security.  Mostly for logging, all authentication and access control events should be logged which includes but not limited to successes and failures. If  we are logging only the successful events, someone may brute force attack the passwords without any detection or notice. On the contrary, let’s say only failures are logged, a legitimate or valid user may misuse, corrupt, harm or simply abuse the system without any detection. Besides that all other authentication and access control related events (such as account lockout) are important and must be logged.

  • Failed log in
  • Successful log in
  • Account locked /disable
  • Account unlocked / enabled
  • Account created
  • Password changed
  • Username changed
  • Logged out

Logs should include the resources involved in the web application (IP address, URL, user name, http method, protocol version, etc…) and document the reason why access was denied for the failed event. Some application provides much better logs than others. generally log entries should contain (user ID, timestamp, source IP, Description of the event, error code, priority).

All error conditions should be logged including simple stuff as sql query errors, which can help to detect sql injection attack. Some errors related to the availability of the application are important for early sign to trigger BCP. Availability is one of the main pillar of information security, so it should be logged and monitored. Log error conditions should include but not limited to (failed queries, file not found and cannot open error, unexpected state, connection failure and timeout)

Besides the inherent benefits of log management, a number of laws and regulations further compel organizations to store and review certain logs. The following is a listing of key regulations, standards, and guidelines that help define organizations’ needs for log management – ISO 27001, ISO 22301, FISMA, GLBA, HIPAA, SOX, and PCI-DSS.

Guide to Computer Security Log Management: Recommendations of the National Institute of Standards and Technology: Special Publication 800-92

Security Log Management

 

Related articles




Tags: Access Control, authentication, Log Analysis, logging, Security, Site Management