Can Log4Shell be exploited without access to external networks

Question

As I first read about Log4Shell my first thought was "ok, this is severe but professionally hosted systems should not be at risk" as most internal systems should be hidden behind a reverse proxy and the actual application servers should have no direct access to external network resources like arbitrary servers on the internet. The PoCs and tests most providers currently offer to check if systems are affected is to check for the DNS lookup of a particular domain. This proves a system is potentially vulnerable but doesn't really show that the vulnerability can be exploited as it doesn't check for a network connection from the affected system.

However lately I read a comment stating that Log4Shell could be exploited even without internet access by somehow providing the malicious classes directly in the lookup URL. Is this true?

To be clear: I don't want to say that log4j doesn't need to be updated in such cases but that you probably don't need to run in escalation mode. log4j should be updated ASAP no matter what.

Answer 1

... as most internal systems should be hidden behind a reverse proxy and the actual application servers should have no direct access to external network resources like arbitrary servers on the internet.

Yeah, that would actually be nice. I only doubt this. Restricting inbound connections but widely allowing outbound connections is pretty common.

... check for the DNS lookup of a particular domain. This proves a system is potentially vulnerable but doesn't really show that the vulnerability can be exploited as it doesn't check for a network connection from the affected system.

While DNS can not be used to load an exploit payload it is still possible to exfiltrate information contained in environment variables etc - see here for an example.

However lately I read a comment stating that Log4Shell could be exploited even without internet access by somehow providing the malicious classes directly in the lookup URL. Is this true?

I don't think so. There might be a misunderstanding. With the first exploits it was needed to first contact an external LDAP (or RMI) server to download the serialized object which then led to contacting an external HTTP server to download the implementation of the class. The latter one is not strictly needed if locally existing classes can be misused. The initial LDAP (or RMI) connection to download the serialized object is still needed though.