Into the symmetry

Posts

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...

The RFC 5114 saga

Back in January I posed a question "to the Internet": What the heck is RFC 5114? It looks like a lot happened since then around it. I would like to use this post to recollect some of the stuff around RFC5114 . Chapter 0: October 2007 RFC5114 draft was submitted to the IETF . Chapter I: January 2016 In short RFC5114 is an IETF Informational RTC that " describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. " . One of the thing about this RTC that attracted the attention of many (and also mine) is that violates the Nothing up my sleeve principle. The other peculiar thing about this RTC (that caught my attention) was that the P s specified for groups 22/23/24 were not safe primes but were indeed DSA primes adapted to Diffie Hellman. So far so good. Except that all the p-1 specified for those groups factored in a really nice way! So I decided to intensify a bit my r...