This group didn’t really “publish” anything, though. They’re offering access to journalists through a request form. They’re also not saying how much actual message content they have because the 410GB of heap dumps makes for a bigger headline number.
And charging for it?!
I’m not sure what is more embarrassing: to be the company or to be a user.
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
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.
So the heapdumps being available is a Spring Boot feature so it does not appear to be malicious.
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
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.
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.
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...
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.
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.
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.
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.)
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.
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.
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.
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.
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”.
They could have used user-custody public key cryptography, where the end devices have the pubkey of the customer, and archive only re-encrypted messages to TM that they can’t read.
That is not, of course, what they did. They just archive them in plaintext.
I haven't used WhatsApp for 'a very long time' as I have exited the FB ecosystem, but back in the day I remember seeing "lite" or "WhatsApp+" or other variations of the software. I wouldn't be surprised that those "lite" or "+" come with baggage.
If you want to keep the branding of Signal being the secure app, you need to make sure that all Signal users are actually using a secure version of Signal.
If an insecure fork (like this one) becomes too popular, most groups will have at least one member using it, and then the security is gone.
Sure, this is HN, we know one of the effects of locking the ecosystem and coloring in-system messages differently is to encourage people to be in the ecosystem.
At the same time, you ALSO need to consider that obviously there will be leaks.
Malicious/advertising apps will target the new messaging interface to gain more data on their victims, etc.
Locking down a platform is not an acceptable solution to the above conundrum - it doesn't matter if the user is using an official device/app whatever if they are untrusted. They can always turn around and leak everything you say without any technical measures.
Should we have no security? No, if you want to color messages differently based on perceived platform, fine. This is just an illustration that no technical measures can replace the fundamental trust necessary in these types of situations.
The third-party federation problem is real, but the vulnerability caused by TeleMessage isn't solved by removing federation.
I believe the main criticism against Signal is that they should focus on getting widespread traction of secure messaging, and that perhaps the brand can be a relatively distant concern.
That's very important to say. I went through one of these massive data dumps recently and it was literally all cached operating system package updates and routine logs. Nothing at all of interest.
It's easy to cut the size on a heap dump. When it's not done it seems sketchy. But it could be a 512GB dump and already pruned, so I could be wrong.
Though the heap dump would have messages in flight at the time. It's obviously not as useful if you are just trying to grab messages for a specific person.
Frankly the most useful part might be any in-memory secret keys, which could be useful for breaking deeper into the system.
But these guys are only interested in "journalists" not people who spent decades digging into ad server heap dumps
I hope the message dump is juicy.
The US only has voluntary military service, so the dynamics are different
Big presumption.
If I were israeli, there’s no way in hell anybody with half a brain would want me near their spy agency.
When a gov is committing a genocide, their decisions are based on control and fear, not getting the best out of people.
Edit: downvote all you want. Israel is still committing a genocide. No hospitals left standing. Killing aid workers, journalists, and doctors. A million people on the brink of starvation. Literally salting the earth to prevent crops from being grown. That is war crimes, ghettoization, and genocide.
[1] https://www.bloomberg.com/news/articles/2024-05-15/ftx-bankr...
This is a country of 10 million people, a rather heterogeneous one at that. There are going to be better and worse companies.
It’s especially true for spooks of a certain entity. Also, it’s easy to confuse brazenness, being protected from consequences, and usually downplayed or secret Western complicity with competence.
Working with a few companies like these, I can tell you that the marketing is top-notch, and very aggressive. The products not so. Most get better with time.
I just wonder where they were storing them all? At one place I worked, we jiggered up an auto shutdown dump that then automatically copied the compressed dump to an S3 bucket (it was an ephemeral container with no persistent storage). Wonder if they got in through excessive cloud storage policies and this was just the easiest way to exfiltrate data without full access to a DB.
"Spring Boot Actuator. “Up until version 1.5 (released in 2017), the /heapdump endpoint was configured as publicly exposed and accessible without authentication by default."
Took a while to workout that for some reason docker-compose is messing directly with iptables to shoot holes in the firewall we'd configured. Figured out you have to write your compose in some super special way to disable that functionality. Compose should never ever open network ports, ever in my book - to do so without a warning or anything though is like I said, insane!
napkin math:
410GB/1000 dumps = 410MB per dump?
410GB/2000 dumps = 205MB per dumpEdit: reading the description on the dump again, seems exactly what they did:
> Some of the archived data includes plaintext messages while other portions only include metadata, including sender and recipient information, timestamps, and group names. To facilitate research, Distributed Denial of Secrets has extracted the text from the original heap dumps.