[hypeatei]

Why would the company be embarrassed? The users (i.e. high level U.S. officials) did no due diligence. Of course a private company is going to take the easiest and cheapest route. If it goes bad, just shut down and spin up a new entity.

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

[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.

[aucisson_masque]

The Israeli would have made it secure so only them can access the data because knowing someone else's secret is worth something only when it's still a secret, if china, Russia and everyone can read the log of the American government it's worth nothing.

[dylan604]

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

Which does not bode well for the customers' counter intelligence abilities

[donnachangstein]

> The users (i.e. high level U.S. officials) did no due diligence.

But why would they? It's not their job. They have massive IT staff supporting them. "High level U.S. officials" are just executives; the pointy-haired bosses to the pointy-haired boss. Only difference is these wear little decorative pins over their breast pocket.

Every Fortune 500 company has dedicated IT staff for execs; someone you can call 24/7 and say "my shit's broke" and they respond "we just overnighted you a new phone".

These people couldn't even install an app on their MDM-controlled device, now the narrative has become we expect them to be making low-level IT decisions too?

Next week we'll be scrutinizing Pete Hegseth's lack of thoughts on rotating backup tapes.

[Jedd]

> ... narrative has become we expect them to be making low-level IT decisions too?

I think that's a misdirection.

The narrative is that:

a) they were using a compromised piece of software

b) they should not have been using that software - not (necessarily) because it was compromised, but because it wasn't US DoD accredited for that use case.

(I understand your point that these guys are not tech savvy, and do not need to be, but they should be regulation-savvy (clearly they either are not, or willingly broke those regulations), and they should be following organisational guidelines that presumably cover the selection and use of these tools types.)

[da_chicken]

Yeah, and the purchase approval process is in place specifically so that someone who knows what to look for has looked at it and verified that it's an acceptable configuration.

This is the exact same problem as Clinton's blackberry enterprise server. Doing it right was hard and time consuming, so they ignored that and did what they wanted.

Only we should be a lot more demanding that our officials in 2025 have a better basic understanding of the importance of computer security than in 2005.

[nkrisc]

> now the narrative has become we expect them to be making low-level IT decisions too?

If their staff makes bad decisions, that’s their failure too.

We expect them to be ultimately responsible for what happens on their watch.

Was it Truman who said, “Woah, don’t bring the buck anywhere near me, it stops with my assistant”.

[microtonal]

It is too early to tell, but given that these people openly attack scientists and other experts (they don’t agree with), I wouldn’t be surprised if they ignored advise of their IT experts.

[input_sh]

It's not too early to tell, we knew from the beginning that the use of Signal (let alone its clone) was not authorised to be used for such communications.

Yes, there's a fleet of people who are supposed to make such tech decisions. The people involved specifically went against those rules. The existence of a group chat using an authorised app is a violation on its own, adding a journalist to it is a violation on top of a violation.

Adding a journalist was accidental, but using such an app (despite it not being approved) is very intentional.

[cornholio]

IT staff that knew it was illegal to provide them tools for a conspiracy were fired or silenced. So the only people left were their cronies, who instantly complied with their illegal request, to the best of the cronies' abilities. For such national failures, the buck has to stop at the very top, not on some IT monkey.

This is typical for highly corrupt governments and autocracies, they crumble from within because the autocrats can't trust random, competent people so their inner circle becomes saturated with people who are selected on the basis of loyalty not competence, and these people end up making the most important decisions and running the country.

[3rdDeviation]

Would tend to agree with most of that, but I think the assertion is Petey needed to ask his IT leadership to do the due diligence before diving in, not that he needed to decide using his own depth of skills and experience.

I assume he did and they said it was a bad idea - the memo they'd released a few weeks prior about Signal vulnerabilities seems to suggest a lack of faith in that approach - but he was already banging away on his phone with all the grocery reminders and definitely not battle plans he needs to keep pushing out. Which is also how it feels in the enterprise space these days.

Strange thing to see our bureaucracy start to behave like a corporation instead of the other way around.

[hristov]

Their massive it staff provides them with a way to communicate securely and they ignore it deliberately so that their communications are not preserved for history or for future court cases.

[TeMPOraL]

One man's low Integrity (in the "CIA triad" sense) of communications is another man's improved plausible deniability.