Into the symmetry

Posts

Historical courses and resorts in Elliptic Curves Cryptography - Is Curve25519 dead?

tl;dr This short blog post serves to me to recollect some of the thing I have been learning ( climbing ) about Elliptic Curves Cryptography (ECC from now on) during the last months/years, so please take it with a grain of salt since it might contains some erroneous beliefs. '80 - Introduction Giambattista Vico was an Italian political philosopher and rhetorician, historian and jurist, of the Age of Enlightenment famous (also) for the concept of historical courses and resorts. This can be resumed with: "some events are repeated in the same way even after a long time; and this is not by chance" . Well it seems that this might also applies to ECC so he maybe he was right :) Elliptic Curve made its first appearance in cryptography with Lenstra in 1984 (eventually published in 1987). Curiously enough he introduced them not while trying to come up with a new crypto system but he employed EC in order to factor integers (a side note, there is a really beauti...

Cross-origin brute-forcing of Github SAML and 2FA recovery codes

Yesterday while reading my Twitter stream I found this interesting article about downloading GitHub SSO bypass codes . Same as Yasin Soliman I was invited to a Github pre-release of the organisation SAML single sign-on (SSO) private program. And same as him I found an issue in the same endpoint. So I thought to write a quick blog post about it. Github already published a tl;dr about this, I will try to fill the blanks here. As mentioned by Yasin, Github offers an endpoint where privileged users can recover bypass codes. These recovery codes were accessible for download as plaintext and had the content-type as text/plain , something like: What immediately caught my attention was that the format of the code forms (with some exceptions) a valid JavaScript file with lines in the format of XXXXX-XXXXX , ten hex digits separated by a hyphen. This is interpreted in JavaScript as the subtraction of two variables! This remember an old blog post of mine ...

OAuth Worm II - The revenge

We all know about this massive Google Doc Phishing Attack that hit about 1 million accounts right? Image from https://arstechnica.com/security/2017/05/dont-trust-oauth-why-the-google-docs-worm-was-so-convincing/ Well this really "sophisticated attack" (really??) was based on a really spread Internet procol named OAuth . It also turns out that during the early stage of the standardization someone reported this very own attack vector but as often happens he was ignored. Back in 2015 I also reported another "hidden feature" of OAuth that turns an OAuth server into an open redirector that makes phishing a piece of cake. Yesterday I was twitting about this and today I decided to imitate Eugene Pupov (lol) and work on my master thesis project. So this is the resulting mail. Have fun: Fret not, go ahead and click and you will be redirected to: that is not a Github page but is rather controlled by me. Well that's all folks...

Meh : CSRF in Facebook Delegated Account Recovery

Note this is going to be a quick post. This year, at Enigma 2017 Conference , Facebook introduced a way to move Account Recovery beyond Email and the "Secret" Question . After the presentation the moved operationally and presented the first integration partner : Github . These days I have seen a lot of press around this and both Facebook and Github open sourced their implementation and s pecification (also presented at F8 ). Well it turned out that Facebook side was susceptible to Cross Site Request Forgery. Really simple explanation: The attacker start the integration with Github and stop the flow at the right moment. The create an attacker page as https://github.com/asanso/asanso.github.io/blob/master/facebook/test_fb.html <html> <img src="https://www.facebook.com/recovery/delegated/save/?fr=OkpK%2FnF9oZk%3D& relay_token=AfFdhnFYiPWXlcS17dG19Tz4sJT%2B%2FzBorBbDwEKgNMvxUHRIqMAnmmEGrGZlMheUfJdNHv40xyraKOfj64fR7ZgZ8HNNmincyRiHdu6Nju...

CSRF in Facebook/Dropbox - "Mallory added a file using Dropbox"

tl;dr Facebook Groups offers the option to upload files directly from the Dropbox account. This integration is done using the OAuth 2.0 protocol and suffered from a variant of the classic OAuth CSRF (defined by Egor Homakov as the the Most Common OAuth2 Vulnerability ), see video below: Introduction Facebook Groups offers the option to upload files directly from the Dropbox account: This will allow to surf via browser the Dropbox account and post a specific file to the group. This integration is done using a variant of the OAuth 2.0 protocol seen in this blog many many times . But once more, OAuth is an access delegation protocol standardized under the IETF umbrella . A typical OAuth flow would look like: From “OAuth 2 In Action” by Justin Richer and Antonio Sanso, Copyrights 2017 Usually the client initiates the OAuth flow in the following way: From “OAuth 2 In Action” by Justin Richer and Antonio Sa...

Critical vulnerability in JSON Web Encryption (JWE) - RFC 7516

tl;dr if you are using go-jose , node-jose , jose2go , Nimbus JOSE+JWT or jose4j with ECDH-ES please update to the latest version. RFC 7516 aka JSON Web Encryption (JWE) hence many software libraries implementing this specification used to suffer from a classic Invalid Curve Attack . This would allow an attacker to completely recover the secret key of a party using JWE with Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) , where the sender could extract receiver’s private key. Premise In this blog post I assume you are already knowledgeable about elliptic curves and their use in cryptography. If not Nick Sullivan 's A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography or Andrea Corbellini's series Elliptic Curve Cryptography: finite fields and discrete logarithms are great starting points. Then if you further want to climb the elliptic learning curve including the related attacks you might also want to visit https://s...

All your Paypal OAuth tokens belong to me - localhost for the win

tl;dr I was able to hijack the OAuth tokens of EVERY Paypal OAuth application with a really simple trick. Introduction If you have been following this blog you might have got tired of how many times I have stressed out the importance of the redirect_uri parameter in the OAuth flow. This simple parameter might be source of many headaches for any maintainer of OAuth installations being it a client or a server. Accepting the risk of repeating myself here is two simple suggestions that may help you stay away from troubles (you can always skip this part and going directly to the Paypal Vulnerability section): If you are building an OAuth client, Thou shall register a redirect_uri as much as specific as you can i.e. if your OAuth client callback is https://yourouauthclient.com/oauth/oauthprovider/callback then DO register https://yourouauthclient.com/oauth/oauthprovider/callback NOT JUST h ttps://yourouauthclient.com/ or https://yourouau...