Oct 30 2022
In this Help Net Security video, Dmitry Bestuzhev, Most Distinguished Threat Researcher at BlackBerry, talks about some of the most interesting tactics, techniques, and procedures employed by cybercriminals in recent months.
These are:
Mar 21 2022
By now, we are all familiar with the fact that Log4Shell is just about as critical as a critical vulnerability can get â scoring a 10 out of 10 on the National Institute of Standards and Technologyâs CVSS severity scale.
As it targets a library â Apache Log4j2 â that nearly every Java application uses to log requests, this vulnerability is ubiquitous. Many applications use Log4j2 without even realizing it, meaning that even those with no apparent dependency on Log4j2 can still be at risk.
With its massive impact across nearly every industry, Log4Shell has taken its place in the cybersecurity hall of fame â among the likes of HeartBleed, WannaCry and ShellShock.
Difficult to locate but easy to exploit, remediating this vulnerability would prove incredibly complex, with several detection methods required. In fact, three months into Log4Shell, the Qualys Cloud Platform suggests that 30% of the Log4j instances still remain unpatched.
When it came to tracking the impact of Log4Shell, Qualys occupies a unique vantage point. The Qualys Cloud Platform indexes more than 10 trillion data points across its installed enterprise customer base and completed 6 billion IP scans per year with 75 million cloud agents deployed in hybrid IT environments globally. With that kind of scale, the Qualys Research Team was able to uncover unique insights into how global enterprises have and are managing Log4Shell:
Log4j has been and will continue to be a headache for security professionals due to how difficult it is to fully understand where this vulnerability may be within an organization.
As with most vulnerabilities, understanding how and where the flaw will affect your business is crucial. Discovery processes are unique to each organization â meaning that depending on architecture and deployment, timetables vary.
This paired with obstacles such as the complexities of skeleton IT staff, potential lack of visibility into IT assets and an overall influx of other real-time sophisticated attacks and threats, could present a tumultuous road to immediate remediation.
The main culprit for why vulnerable versions continue to be downloaded is likely because of automated build systems. These are configured to download a specific version build of their dependencies. Lesser maintained projects may automatically download a specific version to avoid conflicts with updated software, which has the potential to break their code. If the maintainer of that software hasnât been paying attention to Log4j news their application is left open to the risk of exploitation.
Another scenario is the intentional download by researchers or adversaries to test exploitation of their latest wares. It is useful for both good and bad guys to continually validate that their exploitations or defenses are in working order outside of production areas.
Flawed forms of the code are still available because many other pieces of software still rely on them. Removing these downloads could potentially cause breakage in several systems if eliminated.
Further, The Qualys Research team found that more than 50% of application installations with Log4j were flagged as âend of support.â These publishers will likely not be providing Log4Shell security patches for these apps. End of life/support technology is one of the leading factors that put organizations at risk of being exploited by threat actors.
In fact, earlier this year, CISA developed a catalog of âBad Practicesâ to showcase what is exceptionally risky. Landing at number one â especially for organizations supporting Critical Infrastructure or NCFs â was the use of unsupported software.
Jan 11 2022
The Night Sky ransomware operation started exploiting the Log4Shell flaw (
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.
Jan 07 2022
â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.
I Survived Log4Shell 2021
Dec 21 2021
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 (1, 2), 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.
â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?
Dec 20 2021
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âŠ
Dec 16 2021
American web infrastructure and website security company Cloudflare warns that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library.
The CVE-2021-45046 received a CVSS score of 3.7 and affects Log4j versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (which was released to fix CVE-2021-44228).
The Apache Software Foundation (ASF) has already released a patch for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially address the flaw in certain non-default configurations. An attacker 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) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.
Both issues were assessed with the release of Log4j 2.16.0 version that addresses the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.
âHot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.â states CloudFlare.âThis vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.â
The bad news are not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.
This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.
âHowever, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.â states the post published by Praetorian.
Secure By Design
Secure Software Development Fundamentals Professional Certificate
Dec 15 2021
The recent discovery of a second Log4j vulnerability (CVE-2021-45046) has shown that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
This vulnerability could allow attackers to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DoS) attack.
âNote that previous mitigations involving configuration such as to set the system property âlog4j2.noFormatMsgLookupâ to âtrueâ do NOT mitigate this specific vulnerability,â the Apache Log4j security team noted.
â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).” The team advises users either to upgrade to version 2.12.2 (for Java 7) or 2.16.0 (for Java 8 or later), in which the Message Lookups feature has been removed and access to JNDI has been disabled by default, and explained why some of the mitigation measures shared a few days ago are incomplete.
PoCs are constantly popping up on GitHub and getting forked. GitHub is steadily working on removing them, but the proverbial cat is now out of the bag, and there is no going back.
Exploitation attempts detected so far in the wild can be tied to ransomware groups and access brokers, botnet herders (delivering coin miners), and nation-backed APTs.
âThe way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers â cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints,â says Michael Assraf, CEO at Vicarius.
âAs fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting. Examples include: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE, and many more.â
Gallagher says that the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems.
âWhere systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third party vendors who may also be at risk,â he advised.
Mathew Eble, VP of Services at Praetorian, also warned the issue will be prone to false negatives.
âExternally there is no way to cover all the possible paths that exploitation can take. Even when external scanning tools get more sophisticated in how they identify the issue, we strongly advocate not relying on scan results as strong indicator of your risk,â he noted.
This recommendation is based on four issues the company has confirmed when working with customers. Based on this, they have expanded their initial recommendations for defenders.
Secure By Design
Secure Software Development Fundamentals Professional Certificate
Dec 14 2021
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.â
CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog
Dec 13 2021
CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added 13 new vulnerabilities to the Known Exploited Vulnerabilities Catalog, including recently disclosed Apache Log4Shell Log4j and Fortinet FortiOS flaws.
Below is the list of new vulnerabilities added to the Known Exploited Vulnerabilities Catalog, which is the list of issues frequently used as attack vector by threat actors in the wild and that pose significant risk to the federal enterprise.
| CVE Number | CVE Title | Remediation Due Date |
| CVE-2021-44228 | Apache Log4j2 Remote Code Execution Vulnerability | 12/24/2021 |
| CVE-2021-44515 | Zoho Corp. Desktop Central Authentication Bypass Vulnerability | 12/24/2021 |
| CVE-2021-44168 | Fortinet FortiOS Arbitrary File Download Vulnerability | 12/24/2021 |
| CVE-2021-35394 | Realtek Jungle SDK Remote Code Execution Vulnerability | 12/24/2021 |
| CVE-2020-8816 | Pi-Hole AdminLTE Remote Code Execution Vulnerability | 6/10/2022 |
| CVE-2020-17463 | Fuel CMS SQL Injection Vulnerability | 6/10/2022 |
| CVE-2019-7238 | Sonatype Nexus Repository Manager Incorrect Access Control Vulnerability | 6/10/2022 |
| CVE-2019-13272 | Linux Kernel Improper Privilege Management Vulnerability | 6/10/2022 |
| CVE-2019-10758 | MongoDB mongo-express Remote Code Execution Vulnerability | 6/10/2022 |
| CVE-2019-0193 | Apache Solr DataImportHandler Code Injection Vulnerability | 6/10/2022 |
| CVE-2017-17562 | Embedthis GoAhead Remote Code Execution Vulnerability | 6/10/2022 |
| CVE-2017-12149 | Red Hat Jboss Application Server Remote Code Execution Vulnerability | 6/10/2022 |
| CVE-2010-1871 | Red Hat Linux JBoss Seam 2 Remote Code Execution Vulnerability | 6/10/2022 |
The CVE-2021-44228 flaw made the headlines last week, 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.
The impact of the issue is devastating, thousands of organizations worldwide are potentially exposed to attacks and security experts are already reported exploitation attempts in the wild.
CISA also warns of a recently disclosed arbitrary file download vulnerability in FortiOS, tracked as CVE-2021-44168, that is actively exploited.
âA download of code without integrity check vulnerability [CWE-494] in the âexecute restore src-visâ command of FortiOS may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.â reads the advisory published by Fortinet. âFortinet is aware of an instance where this vulnerability was abused and recommends immediately validating your systems for indicators of compromiseâ
Log4Shell update: Attack surface, attacks in the wild, mitigation and remediation
Log4Shell explained â how it works, why you need to know, and how to fix it
Dec 11 2021
Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for a critical remote code execution zero-day vulnerability, tracked a CVE-2021-44228 (aka Log4Shell), in the Apache Log4j Java-based logging library.
The Log4j is widely used by both enterprise apps and cloud services, including Apple iCloud and Steam.
A remote, unauthenticated attacker can exploit the CVE-2021-44228 to execute arbitrary code on a vulnerable system leading to a complete system takeover.
The vulnerability was discovered by researchers from Alibaba Cloudâs security team that notified the Apache Foundation on November 24. According to the experts, the vulnerability is easy to exploit and does not require special configuration, for this reason, it received a CVSSv3 score of 10/10. Researchers pointed out that Apache Struts2, Apache Solr, Apache Druid, Apache Flink are all affected by this vulnerability.
Now researchers from cybersecurity firm Cybereason have released a script that works as a âvaccineâ(dubbed Logout4Shell) that allows remotely mitigating the Log4Shell vulnerability by turning off the âtrustURLCodebaseâ setting in vulnerable instances of the library.
âWhile the best mitigation against this vulnerability is to patch log4j to 2.15.0 and above, in Log4j version (>=2.10) this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath. Additionally, if the server has Java runtimes >= 8u121, then by default, the settings com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase are set to âfalseâ, mitigating this risk. However, enabling these system property requires access to the vulnerable servers as well as a restart.â reads the GitHub Page set up for the Log4Shell project.
Cyberreson experts pointed out that enabling these system property requires access to the vulnerable servers, and the servers have to be restarted.
A zero-day exploit for Log4j Java library could have a tsunami impact on IT giants
Defensive Security Handbook: Best Practices for Securing Infrastructure
