9 ms·

I reported this to Clubhouse in February, no response whatsoever (I am not involved in this leak, just to be extra clear). Essentially anyone with the token fro

I reported this to Clubhouse in February, no response whatsoever (I am not involved in this leak, just to be extra clear). Essentially anyone with the token from the iOS app (MITMproxy + SSL kill switch) can query through the entire public (records are cleaned) user profile database. It supports wildcard queries and just responds with some 20M records you can page through if you have the time. It luckily (!) doesn't expose e-mail and phone number, which is why I also agree with others here that this is only mildly interesting. The news won't care, however. I think at around 4M users or so they switched from auto-increasing IDs to a better numbering format, until then all records remain as-is (increasing). I think Clubhouse can fix this quite easily (limit the records returned in search!!!) and apply some harsher rate limits on a per-token basis (tokens never expire, that's another thing). I think they relied a bit too much on certificate pinning. Once that's bypassed, it's relatively easy to query your way through the data. If you managed to grab someone else's token (which doesn't expire), you impersonate them (without logging the other session out), and continue to show up/talk in rooms using the Agora SDK as that person. They also do upload phone numbers of the address book in clear-text (non-hashed), although I can see that there's not too much of a point because reverse-hashes can maybe work around this easily if not salted.

aasasd 6y ago
> Once that's bypassed Do you mean that you trick the app into accepting a wrong cert? How does one do that, apart from decompilation?
- captn3m0 6y ago
  You usually recompile the app, or if you have a jailbroke phone - you can do it at runtime. But considering how the API is documented now (and alternative third party apps exist), it might not even be necessary.
- jeroenhd 6y ago
  Jailbreaking an iPhone and using a tool like SSL Kill Switch [1] or just plain, old Frida with a script like [2] will do the job. Jailbreaking is the hard part, especially for an up to date iPhone, after that there's loads of guides you can follow that disable certificate validation for pretty much every application. It all boils down to hooking the necessary validation functions and having the APIs lie to the app code. Some apps package their own crypto helpers (often with big crypto problems) to make this harder and require actual reverse engineering, but those are a pain to maintain and it's only a matter of time before someone finds a way around them. If you can extract the symbols (so if the app has not been obfuscated well) you can use Frida's API to hook those as well through any language you like. There's even an interactive Javascript console you can hook into the apps you're hooking! Certificate pinning is a great way to protect users' security and privacy, especially in countries with questionable governments or ISPs, but it won't protect your app's secrets. [1]: https://github.com/nabla-c0d3/ssl-kill-switch2 https://github.com/nabla-c0d3/ssl-kill-switch2 [2]: https://techblog.mediaservice.net/2020/08/ios-13-certificate-pinning-bypass-for-frida-and-brida/ https://techblog.mediaservice.net/2020/08/ios-13-certificate...
  - mittermayr 6y ago
    That's exactly right. The hardest part is finding a phone that runs iOS 13+ and can be jailbroken still. I think I used an iPhone 7 or 8. If someone's really curious, it's probably even worth the $50-$100 for a used iPhone that can be jailbroken, it opens up A LOT of similar doors for investigating.
    - lukec11 6y ago
      FWIW, the iPhone 12 I bought 2 weeks ago came with 14.2.1 (which has 2 jailbreaks available for it, unc0ver and Taurine) Not sure if older iPhones would come with older versions too, I assume used ones would normally be up to date - though iPhone X and earlier are jailbreakable on all versions via checkm8
      - z33k 6y ago
        You can jailbreak any non-A14 device running 14.2.1 or lower right now by following this guide to update to 14.3 and then jailbreaking with unc0ver https://www.reddit.com/r/jailbreak/comments/mm0g3f/news_new_method_of_updating_to_ios_143_if_you_are/ https://www.reddit.com/r/jailbreak/comments/mm0g3f/news_new_... Jailbreaking iOS 14 with checkra1n breaks faceID because it requires an additional SepOS exploit https://checkra.in/news/2020/09/iOS-14-announcement https://checkra.in/news/2020/09/iOS-14-announcement
  - aasasd 6y ago
    > Some apps package their own crypto helpers Didn't even know that mobile OSes have APIs for cert validation, since that's not a part of the OS in my books. Though the motivation for shared libs is understandable (Facebook being an example of what not to do). I guess one drunken evening I'm gonna read through lists of the APIs just to see what kinds of stuff are crammed there.
    - jeroenhd 6y ago
      I'm not sure why you're surprised, Windows has come with a library for certificate validation since the late 90s. The OSX documentation library has an example of using SecureTransport all the way back to 2004, but the API is probably older. The *nix systems, with their modular nature, may be technically usable without a TLS library, but even your average RTOS comes with fully-featured TLS support built in these days. Mobile operating systems provide a very broad API so that access management and sandboxing is made easy. I'm not sure how things are done on the iOS side, but on Android you can enable certificate pinning application-wide by just putting an XML file with the right name in the right place and adding a key/value pair for the hostname and the pinned public key (anywhere in the validation chain, AFAIK). The same XML file also allows disabling plain text requests from your application runtime, preventing accidental data leaks to insecure networks. Because adding security is so easy, there's loads of apps enforcing a security setting that otherwise would be considered obscure to most application developers. Exposing an optional, application-wide API is a pretty solid idea in my book; I'm not aware of any Linux system API that can easily enforce certificate pinning on an application-wide level.
- nerdbaggy 6y ago
  iOS you can use Charles app and intercept https request without any extra device. https://www.charlesproxy.com/documentation/ios/ https://www.charlesproxy.com/documentation/ios/
  - atommclain 6y ago
    My understanding is that Charles (man in the middle attacks) will only work with apps that don’t use certificate pinning. If an app uses that, I’m not aware of a way around without jailbreaking. https://www.raywenderlich.com/1484288-preventing-man-in-the-middle-attacks-in-ios-with-ssl-pinning https://www.raywenderlich.com/1484288-preventing-man-in-the-...
bitexploder 6y ago
Nothing wrong with auto incrementing identifiers if actual security controls (authorization) are implemented for already authenticated users.
- yardstick 6y ago
  Sequential is still bad if you don’t want to disclose the size of your customer base or other commercially sensitive information. Also see the German Tank Problem[1]. 1. https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem
  - jgalt212 6y ago
    true, but if you do sequential for users and free trials, the information leakage can be close to zero. Think about if all those AOL CDs were sequentially numbered.
    - SahAssar 6y ago
      That's not zero information leakage. That's just leaking another statistic that is somewhat correlated to the one you want to hide (you're leaking the production of trial AOL CDs, and production of trial AOL CDs have some correlation to number of new users).
  - jbluepolarbear 6y ago
    Don’t return indexes with user queries.
    - wongarsu 6y ago
      Usually you need some external unique identifier so you can interact with the object. Sure, that doesn't have to be the db index, but it is the convenient choice
      - azinman2 6y ago
ramoz 6y ago
I was in some of those CH convos with you. I was actually suspended for a little while and tried clearing it up with them. Sent all the details I had and the original google doc I published w/ a lot of styprs work. They never responded but I was unbanned and given some fresh invites... but yea... strange it hasn't been cleared up. Ultimately I think the premise is around a completely open and a transparent digital experience. Clubhouse still needs to defend against those with malicious intent and a new realm of psychographics to abuse. Side note: I was hooked on the app until that suspension (lasted ~2w)... I haven't been able to get back into a groove. I rarely log on anymore.
rsj_hn 6y ago
Reading your post, it's amazing the checkboxes of failed access control efforts: * trying to control clients * obfuscating IDs * rate limiting data ...rather than the more boring yet standard approach of thinking through an access control policy and then enforcing that at the server.

aasasd 6y ago

> Once that's bypassed Do you mean that you trick the app into accepting a wrong cert? How does one do that, apart from decompilation?

captn3m0 6y ago
You usually recompile the app, or if you have a jailbroke phone - you can do it at runtime. But considering how the API is documented now (and alternative third party apps exist), it might not even be necessary.
jeroenhd 6y ago
Jailbreaking an iPhone and using a tool like SSL Kill Switch [1] or just plain, old Frida with a script like [2] will do the job. Jailbreaking is the hard part, especially for an up to date iPhone, after that there's loads of guides you can follow that disable certificate validation for pretty much every application. It all boils down to hooking the necessary validation functions and having the APIs lie to the app code. Some apps package their own crypto helpers (often with big crypto problems) to make this harder and require actual reverse engineering, but those are a pain to maintain and it's only a matter of time before someone finds a way around them. If you can extract the symbols (so if the app has not been obfuscated well) you can use Frida's API to hook those as well through any language you like. There's even an interactive Javascript console you can hook into the apps you're hooking! Certificate pinning is a great way to protect users' security and privacy, especially in countries with questionable governments or ISPs, but it won't protect your app's secrets. [1]: https://github.com/nabla-c0d3/ssl-kill-switch2 https://github.com/nabla-c0d3/ssl-kill-switch2 [2]: https://techblog.mediaservice.net/2020/08/ios-13-certificate-pinning-bypass-for-frida-and-brida/ https://techblog.mediaservice.net/2020/08/ios-13-certificate...
- mittermayr 6y ago
  That's exactly right. The hardest part is finding a phone that runs iOS 13+ and can be jailbroken still. I think I used an iPhone 7 or 8. If someone's really curious, it's probably even worth the $50-$100 for a used iPhone that can be jailbroken, it opens up A LOT of similar doors for investigating.
  - lukec11 6y ago
    FWIW, the iPhone 12 I bought 2 weeks ago came with 14.2.1 (which has 2 jailbreaks available for it, unc0ver and Taurine) Not sure if older iPhones would come with older versions too, I assume used ones would normally be up to date - though iPhone X and earlier are jailbreakable on all versions via checkm8
    - z33k 6y ago
      You can jailbreak any non-A14 device running 14.2.1 or lower right now by following this guide to update to 14.3 and then jailbreaking with unc0ver https://www.reddit.com/r/jailbreak/comments/mm0g3f/news_new_method_of_updating_to_ios_143_if_you_are/ https://www.reddit.com/r/jailbreak/comments/mm0g3f/news_new_... Jailbreaking iOS 14 with checkra1n breaks faceID because it requires an additional SepOS exploit https://checkra.in/news/2020/09/iOS-14-announcement https://checkra.in/news/2020/09/iOS-14-announcement
- aasasd 6y ago
  > Some apps package their own crypto helpers Didn't even know that mobile OSes have APIs for cert validation, since that's not a part of the OS in my books. Though the motivation for shared libs is understandable (Facebook being an example of what not to do). I guess one drunken evening I'm gonna read through lists of the APIs just to see what kinds of stuff are crammed there.
  - jeroenhd 6y ago
    I'm not sure why you're surprised, Windows has come with a library for certificate validation since the late 90s. The OSX documentation library has an example of using SecureTransport all the way back to 2004, but the API is probably older. The *nix systems, with their modular nature, may be technically usable without a TLS library, but even your average RTOS comes with fully-featured TLS support built in these days. Mobile operating systems provide a very broad API so that access management and sandboxing is made easy. I'm not sure how things are done on the iOS side, but on Android you can enable certificate pinning application-wide by just putting an XML file with the right name in the right place and adding a key/value pair for the hostname and the pinned public key (anywhere in the validation chain, AFAIK). The same XML file also allows disabling plain text requests from your application runtime, preventing accidental data leaks to insecure networks. Because adding security is so easy, there's loads of apps enforcing a security setting that otherwise would be considered obscure to most application developers. Exposing an optional, application-wide API is a pretty solid idea in my book; I'm not aware of any Linux system API that can easily enforce certificate pinning on an application-wide level.
nerdbaggy 6y ago
iOS you can use Charles app and intercept https request without any extra device. https://www.charlesproxy.com/documentation/ios/ https://www.charlesproxy.com/documentation/ios/
- atommclain 6y ago
  My understanding is that Charles (man in the middle attacks) will only work with apps that don’t use certificate pinning. If an app uses that, I’m not aware of a way around without jailbreaking. https://www.raywenderlich.com/1484288-preventing-man-in-the-middle-attacks-in-ios-with-ssl-pinning https://www.raywenderlich.com/1484288-preventing-man-in-the-...

bitexploder 6y ago

Nothing wrong with auto incrementing identifiers if actual security controls (authorization) are implemented for already authenticated users.

yardstick 6y ago
Sequential is still bad if you don’t want to disclose the size of your customer base or other commercially sensitive information. Also see the German Tank Problem[1]. 1. https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem
- jgalt212 6y ago
  true, but if you do sequential for users and free trials, the information leakage can be close to zero. Think about if all those AOL CDs were sequentially numbered.
  - SahAssar 6y ago
    That's not zero information leakage. That's just leaking another statistic that is somewhat correlated to the one you want to hide (you're leaking the production of trial AOL CDs, and production of trial AOL CDs have some correlation to number of new users).
- jbluepolarbear 6y ago
  Don’t return indexes with user queries.
  - wongarsu 6y ago
    Usually you need some external unique identifier so you can interact with the object. Sure, that doesn't have to be the db index, but it is the convenient choice
    - azinman2 6y ago

ramoz 6y ago

I was in some of those CH convos with you. I was actually suspended for a little while and tried clearing it up with them. Sent all the details I had and the original google doc I published w/ a lot of styprs work. They never responded but I was unbanned and given some fresh invites... but yea... strange it hasn't been cleared up. Ultimately I think the premise is around a completely open and a transparent digital experience. Clubhouse still needs to defend against those with malicious intent and a new realm of psychographics to abuse. Side note: I was hooked on the app until that suspension (lasted ~2w)... I haven't been able to get back into a groove. I rarely log on anymore.

rsj_hn 6y ago

Reading your post, it's amazing the checkboxes of failed access control efforts: * trying to control clients * obfuscating IDs * rate limiting data ...rather than the more boring yet standard approach of thinking through an access control policy and then enforcing that at the server.