[n2d4]

> Some speculate this was intentional intelligence gathering by the Israelis which is plausible too.

How does this make sense? If they were gathering data, why would they add a public download? Surely the Israeli officials would not want foreign powers to access this?

Per Hanlon's razor, I don't think this is attributable to anything other than incompetence.

[barbazoo]

Two things can be true at once. Them using their access to unencrypted messages for nefarious purposes and them being incompetent at the same time leaving that endpoint open.

[jojohohanon]

There’s room for both sides of the razor. The heapdumpz could be there maliciously, but incompetently made globally accessible.

[pigbearpig]

From the Wired article: "The archive server is programmed in Java and is built using Spring Boot, an open source framework for creating Java applications. Spring Boot includes a set of features called Actuator that helps developers monitor and debug their applications. One of these features is the heap dump endpoint,"

So the heapdumps being available is a Spring Boot feature so it does not appear to be malicious.

[flarecoder]

I'm the original author of the Spring Boot feature for heapdumps: https://github.com/spring-projects/spring-boot/pull/5670.

It seems that users commonly misconfigure Spring Boot security or ignore it completely. To improve the situation, I made this PR: https://github.com/spring-projects/spring-boot/pull/45624.

When the PR was created in 2016, endpoints were marked as "sensitive" and, for example, the heapdump endpoint would have to be explicitly enabled. However, Spring Boot has evolved over the years, and only the "shutdown" endpoint was made "restricted" in the later solutions. My recent PR will address that weakness in Spring Boot when users misconfigure or ignore security for a Spring Boot app so that heapdumps won't get exposed by default.

[stackskipton]

I don't get why 2+ years after Log4J we are still dealing with this from Java libraries developers.

Your end users are not security savvy, they will never be security savvy and you need to protect them from themselves instead of handing them loaded handgun. This language more than most is filled with people punching buttons for paycheck.

- Signed, Angry SRE who gets to deal with this crap.

[testplzignore]

In my opinion, the original sin of Spring Boot Actuator is allowing server.port and management.server.port to be the same. It makes it too convenient for developers to skip the security review that would be done for opening a non-standard port.

I think it would be wise to either disallow the ports being the same, or if they are the same, only enable the health endpoint.

[smaudet]

I'm more of the opinion that developers will make smart choices, when motivated.

Sure, punching buttons for money is a widespread issue in the industry, but devs also like convenience.

Security has the hard problem that it's infuriatingly difficult to troubleshoot (ever tried to write security policies for an app or figure out how to let an app through a firewall, or set of firewalls?), and there's a bit of a culture of "security by obscurity".

So it's kind of expected that this is the behavior...

Sure some people will really just not care, mistakes will be made, but secure defaults, easy to configure and simple to understand are features not often seen from security products generally. This is driven by poor motivations from security folk who want to protect their industry...

[evrflx]

This feature must be explicitly enabled, it is not on by default nor by accident.

[bryanrasmussen]

huh, I sure seem to be needing to debug this a lot, I guess I'll just leave it turned on all the time that way I can say a few seconds next time. Larry Wall says one of the virtues of being a great developer is laziness!

[terom]

Based on [1] it seems like one `management.endpoints.web.exposure.include=*` is enough to expose everything including the heapdump endpoint on the public HTTP API without authentication. It's even there in the docs as an example.

Looks like there is a change [2] coming to the `management.endpoint.heapdump.access` default value that would make this harder to expose by accident.

Let's look for `env` next...

[1] https://docs.spring.io/spring-boot/reference/actuator/endpoi...

[2] https://github.com/spring-projects/spring-boot/pull/45624

[g-b-r]

I mean, it could theoretically have been to provide plausible deniability, but it seems extremely more likely to have been incompetence and carelessness (and if they were also sending everything to Israel, it was probably through some unencrypted ftp upload).

[michaelt]

Imagine you ran a spy agency and you were infiltrating signal, Facebook, Google, aws, cloudflare, and so on.

Would you have them make a secure back door that could only be intentionally designed, and potentially traced back to you?

Or would you just have them be incompetent in plausible, deniable ways?

Nobody’s getting shot for espionage because they chose log4j and it had the shell shock bug.

[notpushkin]

I mean, one doesn’t preclude the other. This could be an incompetent intentional intelligence gathering.