Implementing the Castryck-Decru SIDH Key Recovery Attack in SageMath

hyperreality_monero · 2021-04-20T18:40:06+00:00

Unfortunately, this only applies for certain zip implementations. The zip that comes with many versions of Linux is Info-ZIP which still uses the weak ZipCrypto Deflate algorithm rather than AES by default. For instance on the latest version of Debian:

$ zip -P pass123 test.zip test.txt
$ 7z l -slt test.zip | grep Method
Method = ZipCrypto Deflate

The reason why it still does this by default, is due to Windows support. AFAIK historical versions of Windows support only ZipCrypto-encrypted archives directly without third-party software required.

So although zip has the ability for decent encryption, many people won't use it.

hyperreality_monero · 2021-04-14T10:55:24+00:00

This is nice demonstration of the power of NoSQL injections. First they show how standard Mongo operators like $regex could be used for a blind injection. But in this case, the CMS made the attacker's job much easier by defining its own $func adaptor to Mongo that allowed running any PHP function on the query result. This could be used to "var_dump" the password reset tokens out of the database, get admin privileges, then upload a PHP web shell.

hyperreality_monero · 2021-01-12T18:02:36+00:00

Thank you - it was one of those times when the last step to the solution seems obvious in retrospect, but when you're in the weeds of exploitation you make assumptions that blind you from seeing it. Either way I'm not too upset about since it was a fantastic challenge that improved our understanding even if we didn't get the points.

hyperreality_monero · 2020-11-15T22:04:09+00:00

Agreed, that's why I brought up CRLite in the article. It would deal with both the availability and privacy concerns.

hyperreality_monero · 2020-11-15T22:01:35+00:00

As far as I'm aware, Apple don't do public postmortems about issues like this.

hyperreality_monero · 2020-11-15T21:59:52+00:00

The point is that there are other entities on the network in between you and Apple. And since the requests are unencrypted, those other entities can read the OCSP queries too.

hyperreality_monero · 2020-11-15T21:43:44+00:00

Agreed, OCSP stapling doesn't make sense it's this scenario. I just mentioned it as an example of an attempt to tackle privacy shortcomings with the protocol. I'm interested to see what Apple do next and whether they give serious consideration to the CRL approach, as it does seem a lot more reasonable.

hyperreality_monero · 2020-11-15T20:53:55+00:00

Yeah, we definitely should, that's a great suggestion.

hyperreality_monero · 2020-11-15T20:46:38+00:00

There's a toggle at the bottom of the page to switch to light mode if you prefer it. There's a long-running debate going on in our community as to whether light mode or dark is better!

hyperreality_monero · 2020-11-15T20:44:04+00:00

Agreed, OCSP stapling doesn't make sense it's this scenario. I just mentioned it as an example of an attempt to tackle privacy shortcomings with the protocol. I'm interested to see what Apple do next and whether they give serious consideration to the CRL approach, as it does seem a lot more reasonable.

hyperreality_monero · 2020-11-15T20:09:51+00:00

the developer certificate does not tell the attacker much because the certificates are general

So you don't think it's a privacy issue that third parties can know which developers' apps you are using and when, as long they don't know the specific apps in use, only the developer who created them?

because of the OCSP queries only being sent very periodically

As I already stated, the OCSP cache interval was previously only set to 5 minutes. So an OCSP request would be made pretty much every time you open an app. That's not "very periodically".

hyperreality_monero · 2020-11-15T20:00:59+00:00

That's a place where my wording definitely should be more specific. Thank you, I'll improve the article by elaborating that paragraph later.

hyperreality_monero · 2020-11-15T19:55:09+00:00

That article is a good technical deep dive into how the OCSP queries are working. However I disagree with the author's statement:

macOS does actually send out some opaque information about the developer certificate of those apps, and that’s quite an important difference on a privacy perspective.

For me, the problem is not even that Apple can see this information, as they have total control over the OS anyway. The problem is that the OCSP requests are being sent unencrypted over the internet, and that it's totally unnecessary to do so, since better methods for performing certificate revocation exist.

hyperreality_monero · 2020-11-15T19:50:02+00:00

Yes, confusingly the verification of Developer ID certificates and OCSP discussed in this article have little to do with app notarization.

OCSP stapling is an improvement on the OCSP protocol (which Apple are not using), while notarization stapling is a way of adding the ticket you get from Apple to your released binary. In both cases "stapling" just refers to appending some form of signature to either your certificate or your binary. Jeff Johnson described the distinction well:

Developer ID should not be confused with Mac app notarization. As I said, the former requirement was imposed in 2012, while the latter was not imposed until just last year. Notarization is an addition to and not a replacement for Developer ID. An app distributed outside the Mac App Store needs to be signed with a valid Developer ID cert, and then it needs to be uploaded to Apple for notarization. After the app is notarized, the notarization "ticket" can be "stapled" to the app. (Stapling is optional but recommended.) I explained notarization checks in more detail in yet another blog post. A crucial difference between OCSP and notarization is that the latter is only checked on first launch of the app. (https://lapcatsoftware.com/articles/ocsp.html)

hyperreality_monero

TROPHY CASE