November 6, 2023

November 6, 2023

November 6, 2023

---

---

---

Passive SSH Key Compromise via Lattices

https://eprint.iacr.org/2023/1711.pdf

Comment https://news.ycombinator.com/item?id=38161792

To give some easier explanation: This is an attack against faulty RSA implementations. There is a common optimization in RSA signature implementations that splits up an expensive mathematical operation into two smaller operations. If one of these throws out a bad result then you can break the key. Why does this happen? Multiple reasons. Implementations of big number math can and does contain bugs. (I used to hunt for those via fuzzing, which turned up an amazing number of them.) Hardware failures. Other bugs that corrupt numbers in memory. The basic attack is well known. Florian Weimer has demonstrated this against TLS in the wild: _{https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfec...} The new thing this paper adds is applying this attack to SSH. There is a countermeasure against this attack, and this is to verify the signature before revealing it. It works. As the paper says, openssh uses openssl's RSA implementation, and it has been doing that since forever (2001). So in summary: Applying a well-known attack against RSA to its use in SSH. Only works if you have an RSA implementation that outputs results of flawed computations. Countermeasures exist, and RSA implementations should use them

---

Such as it is, it’s not bad. It’s not great, but given that it’s for a general audience it does include some relevant details. A couple of Russian operations are mentioned.

---

---

---

---

---

https://www.sec.gov/files/litigation/complaints/2023/comp-pr2023-227.pdf

1. The Security Statement was materially misleading because it touted the Company's supposedly strong cybersecurity practices. For example, that statement asserted that SolarWinds created its software products in a “secure development lifecycle [that] follows standard security practices including vulnerability testing, regression testing, penetration testing, and product security assessments.” And the Security Statement claimed that SolarWinds' “password policy covers all applicable information systems, applications, and databases [and we] enforce the use of complex passwords.” It also stated that SolarWinds had “[a]ccess controls to sensitive data in our databases, systems, and environments [that are] set on a need-to know / least privilege necessary basis.” All those statements were materially false and misleading.
2. The misleading Security Statement concealed from the public the Company's known poor cybersecurity practices throughout the Relevant Period. These poor cybersecurity practices included SolarWinds' (a) failure to consistently maintain a secure development lifecycle for software it developed and provided to thousands of customers, (b) failure to enforce the use of strong passwords on all systems, and (c) failure to remedy access control problems that persisted for years

This is an incredibly low bar. An SDL, a password policy, and basic access controls. Of course, I’d venture to bet that many companies fail to meet these standards consistently across all systems… but still, it’s damning how trivial these issues are.

I wonder if this means that all those managers and executives that “accept the risk” for security issues will have to reveal those issues in their public statements. I’m also curious if revealing the security vulnerabilities in a company will improve that company’s resilience against cyber attack? Seems like a paradoxical problem, if you don’t declare your vulnerabilities you’re committing securities fraud, and if do declare them you’re posting an attack plan for malicious actors.

Maybe the safest option is: just don’t get caught

---

---

---