4 ms·

> 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

by 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
  - flarecoder 1y ago
    I'm the original author of the Spring Boot feature for heapdumps: https://github.com/spring-projects/spring-boot/pull/5670 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 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.
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.

by n2d4 1y ago

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
- flarecoder 1y ago
  I'm the original author of the Spring Boot feature for heapdumps: https://github.com/spring-projects/spring-boot/pull/5670 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 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.

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.