Live data from Hacker News

DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

micahflee.com

181–190 of 209 posts

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#181
post #20
post #9

Earlier quoted context omitted.

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.

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

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.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#182
post #2

So one of their servers had a /heapdump endpoint that publicly served a heap dump of the server? This whole saga is out of control. 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.

> They’re also not saying how much actual message content they have because the 410GB of heap dumps makes for a bigger headline number. 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 c…

Most of the the heap dump will be filled with stuff like java.util.String!blahjava.util.ArrayList!

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.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#183
post #176

Earlier quoted context omitted.

Protecting your name is perfectly fine. You're allowed to make a fork of Firefox, you just can't call it Firefox or use any of Mozilla's branding. You're allowed to fork the open source part of VS Code, you just can't call it that or use Microsoft's branding. etc. etc. - you're free to do with open source whatever the license allows, but you're not allowed to use the original name or branding because you have zero ri…

That's not the issue here. VSCode and FireFox are false equivalents. Even if you'd rebrand the fork, Signal forbids non-official clients/builds from connecting to their servers. Enforcement has been selective but the last official word AFAIK is that you are not allowed to fork, rebrand, and distribute a client which alllows you to chat with Signal users. Mozilla still allows you to install and download add-ons and us…

Two wrote a two-part complaint, one part about clients, and the other part about Signal going after people using the Signal name. My comment was only about that second part (hence why it starts the way it starts).

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#184

Earlier quoted context omitted.

> The citizens of affected nations need to be made angry by their leaders' failure to do their jobs correctly, and that's only gonna happen when there are consequences for their actions. This is a really dangerous line of thinking. It's the line of thought that slides forwards to "I love America so much, but to save America I have to get Americans to really feel the pain, and to do that I need to to them to wake them…

You're describing accelerationism and while the ethics behind it are iffy at best, history contends that it does work to help spur revolution.

Lots of shitty, evil things work really well. Most people don't do evil just because they love evil. They do it because it works best.

Lying, propaganda, and shooting a bunch of people are also really effective techniques to spur revolution, but that doesn't mean they're good ideas.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#185
post #78

Earlier quoted context omitted.

> 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…

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

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.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#186

Earlier quoted context omitted.

Imaging putting up a firewall to mitigate this, then docker compose helpfully opening the ports for you. Security comes in layers.

This feature of docker compose is insane.

Right!? I learned with a colleague: Didn’t you restrict everything to the Tailnet? Yes, feel free to check UFW. Hmm, then why does nmap show all this stuff when scanning from the lan? Wtf??

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#187
post #4

Earlier quoted context omitted.

Can you imagine co-opting a trusted and secure (and free) bit of software and just making it worse at seemingly every turn? And charging for it?! I’m not sure what is more embarrassing: to be the company or to be a user.

This is why Signal is so opposed to third-party apps (or forks) that connect to their service. 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.

If your product is a strong brand then that would make total sense.

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.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#188

Earlier quoted context omitted.

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.

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 endp…

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.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#189
post #48

Earlier quoted context omitted.

And SBF of FTX fame was ex-Jane St so obviously was a serious finance professional. This is why using past employers as a shorthand for capability is unwise.

In fairness, FTX had a profitable bankruptcy [1]. So it's still better to be scammed by Jane Street alumni than to be scammed by the usual alumni of Goldman Sachs, JP Morgan etc [1] https://www.bloomberg.com/news/articles/2024-05-15/ftx-bankr...

It's not profitable. They are getting their money back from value of the assets in 2022 when they went bankrupt but most of crypto assets have gone up significantly in value so it's 2.5 years of lost profit.

Re: DDoSecrets publishes 410 GB of heap dumps, hacked from TeleMessage

#190

Earlier quoted context omitted.

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.

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 endp…

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.

Post reply on HN