6 ms·

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

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.

hypeatei 1y ago
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.
- dylan604 1y ago
  >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
- n2d4 1y ago
  > 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.
  - g-b-r 1y ago
    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).
  - barbazoo 1y ago
    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.
  - notpushkin 1y ago
    I mean, one doesn’t preclude the other. This could be an incompetent intentional intelligence gathering.
  - jojohohanon 1y ago
    There’s room for both sides of the razor. The heapdumpz could be there maliciously, but incompetently made globally accessible.
    - pigbearpig 1y ago
      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.
      - evrflx 1y ago
        This feature must be explicitly enabled, it is not on by default nor by accident.
        bryanrasmussen 1y ago
        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!
        szundi 1y ago
        [dead]
        terom 1y ago
        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/endpoints.html#actuator.endpoints.security https://docs.spring.io/spring-boot/reference/actuator/endpoi... [2] https://github.com/spring-projects/spring-boot/pull/45624 https://github.com/spring-projects/spring-boot/pull/45624
  - michaelt 1y ago
    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.
- donnachangstein 1y ago
  > 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 1y ago
    > ... 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 1y ago
      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.
  - hristov 1y ago
    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.
- bigbacaloa 1y ago
  [dead]
- aucisson_masque 1y ago
  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.
deleted 1y ago
[deleted]
kube-system 1y ago
The changes to the application are intentional by all parties because message archiving was required by law.
- brookst 1y ago
  Sure, but they were not required to be done incompetently and insecurely.
  - sneak 1y ago
    The fundamental concept of plaintext archiving (escrow) of messages from e2ee messaging apps is insecure by most definitions. 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.
    - kevincox 1y ago
      I don't think it is. I can archive my own messages and E2E security on the messaging layer means I don't have to trust the operator of the messaging service to not read my messages because they can't. The choice of how I archive the messages is completely orthogonal to the choice of messaging platform security. I could choose to use an E2EE approach if I want but in that case it probably wasn't even desired as the point was to have these be archived for audit purposes. (Of course they are more secure options such as archiving to an audit key, but this is still orthogonal to the concern of the messaging protocol)
- _kb 1y ago
  Well, I suppose technically this /heapdump endpoint does satisfy that archive requirement.
HenryBemis 1y ago
(read with sarcastic tone) But hey, this is a 'lite' version or a 'red' version (icon is red) or a 'purple' version (icon is purple), so I am cooler that then others that have the standard. 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.
yapyap 1y ago
User for sure
miki123211 1y ago
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.
- calvinmorrison 1y ago
  That doesn't seem to be a problem for protocols and having a single implementation can lead to bugs that defy spec yet cause no issues obviously.
  - ctxc 1y ago
    But you're not branding or selling implementations
    - ctxc 1y ago
      *protocols
  - deleted 1y ago
    [deleted]
- pchristensen 1y ago
  That was Apple's same reasoning for shutting down that iMessage client app. These leaks seem to justify their concerns.
  - xandrius 1y ago
    Nah, that was to keep their users hostage and force them to buy a iPhone.
    - fn-mote 1y ago
      This is a shallow dismissal of an argument that should be given more consideration. 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.

hypeatei 1y ago

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.

dylan604 1y ago
>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
n2d4 1y ago
> 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.
- g-b-r 1y ago
  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).
- barbazoo 1y ago
  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.
- notpushkin 1y ago
  I mean, one doesn’t preclude the other. This could be an incompetent intentional intelligence gathering.
- jojohohanon 1y ago
  There’s room for both sides of the razor. The heapdumpz could be there maliciously, but incompetently made globally accessible.
  - pigbearpig 1y ago
    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.
    - evrflx 1y ago
      This feature must be explicitly enabled, it is not on by default nor by accident.
      - bryanrasmussen 1y ago
        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!
        szundi 1y ago
        [dead]
      - terom 1y ago
        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/endpoints.html#actuator.endpoints.security https://docs.spring.io/spring-boot/reference/actuator/endpoi... [2] https://github.com/spring-projects/spring-boot/pull/45624 https://github.com/spring-projects/spring-boot/pull/45624
- michaelt 1y ago
  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.
donnachangstein 1y ago
> 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 1y ago
  > ... 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 1y ago
    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.
- hristov 1y ago
  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.
bigbacaloa 1y ago
[dead]
aucisson_masque 1y ago
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.

deleted 1y ago

[deleted]

kube-system 1y ago

The changes to the application are intentional by all parties because message archiving was required by law.

brookst 1y ago
Sure, but they were not required to be done incompetently and insecurely.
- sneak 1y ago
  The fundamental concept of plaintext archiving (escrow) of messages from e2ee messaging apps is insecure by most definitions. 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.
  - kevincox 1y ago
    I don't think it is. I can archive my own messages and E2E security on the messaging layer means I don't have to trust the operator of the messaging service to not read my messages because they can't. The choice of how I archive the messages is completely orthogonal to the choice of messaging platform security. I could choose to use an E2EE approach if I want but in that case it probably wasn't even desired as the point was to have these be archived for audit purposes. (Of course they are more secure options such as archiving to an audit key, but this is still orthogonal to the concern of the messaging protocol)
_kb 1y ago
Well, I suppose technically this /heapdump endpoint does satisfy that archive requirement.

HenryBemis 1y ago

(read with sarcastic tone) But hey, this is a 'lite' version or a 'red' version (icon is red) or a 'purple' version (icon is purple), so I am cooler that then others that have the standard. 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.

yapyap 1y ago

User for sure

miki123211 1y ago

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.

calvinmorrison 1y ago
That doesn't seem to be a problem for protocols and having a single implementation can lead to bugs that defy spec yet cause no issues obviously.
- ctxc 1y ago
  But you're not branding or selling implementations
  - ctxc 1y ago
    *protocols
- deleted 1y ago
  [deleted]
pchristensen 1y ago
That was Apple's same reasoning for shutting down that iMessage client app. These leaks seem to justify their concerns.
- xandrius 1y ago
  Nah, that was to keep their users hostage and force them to buy a iPhone.
  - fn-mote 1y ago
    This is a shallow dismissal of an argument that should be given more consideration. 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.