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.
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.
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.
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.
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
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.
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.
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.
Am aware. Still don’t think it’s worth the hassle for most situations. Can leak information, but context is really important. I have rarely seen it be an issue over many years of app assessments. Just something to keep in the threat model for when it’s relevant.
There was one wireless ISP many years ago in a city I lived in that had a signal/reception page to see your signal to their closet tower. The URL included the customer number to identify your location. I quickly discovered it had no authorisation checks. You could easily find the exact addresses of all of their customers. Inactive/old customers returned no data.
What hassle is it? Where in your codebase do you assume sequentiality? It should be a one line change in your db configs to generate GUIDs instead of ids. You have to do it eventually anyway as sequentiality can't be assumed once you shard.
Depends on the needs I suppose. I don’t like starting off with GUIDs until it’s proven they are needed, because, as you say, it’s a simple change. Sharing does complicate the picture, but how many apps really need sharding.
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.
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).
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
If you follow the "defense in depth" paradigm, then sequential identifiers bad when the other controls are defeated. Sequential ID make it trivial to crawl the entire dataset - which could be the difference between "Information on 4 million users was stolen" and "information from 4 users was stolen"
> This is misleading and false. Clubhouse has not been breached or hacked. The data referred to is all public profile information from our app, which anyone can access via the app or our API.
So just like what happened to Parler and LinkedIn. A so-called 'data breach' of its public data via scraping.
But last time I checked on the private API in a GitHub repo, Clubhouse is using integer IDs which are not random alphanumberic strings for its users.
This can essentially be scraped by a while loop, incrementing all the way to whoever last signed up.
Did Clubhouse even implement rate limiting to combat this?
Does anyone remember the ATT "Hack"? These two just used curl to get e-mail address and ICC-ID of ATT iPad users which where publicly accessible. [1] It was still labeled a hack and went through the brain dead media that way. Instead of ATT getting in trouble Auernheimer got a 41 months sentence and the judge also ordered him and Spitler to pay $73,000 in restitution.
weev had a lot of friends come forth to defend his actions, but then he went full neonazi in prison and all of that support disappeared.
He now runs admin for The Daily Stormer and somehow finds a way to keep popping up in the worst places, can't seem to shake the guy.
Additionally, he didn't even do the legwork for the AT&T op, but really wanted to take credit for something for cool hacker cred, and it came back and bit him. I keep company with several people involved in that ordeal.
I think this comes down to an oft-repeated discussion of what we (society) consider the "proper" securing of data.
If a company leaves data available in a manner that is accessible without using any kind of vulnerability, but rather allows the unintended (ab)use of a poorly implemented service, then that's not a "hack", that's on the company, and they should be held accountable.
Personally I think an SQL injection still falls under the above. Securing public endpoints against long-known and easily mitigated vulnerabilities is 100% the company's responsibility..
There is no "we couldn't have prevented this" bullshit defense in that case.
The company probably deserves punishment for negligence, but that should have zero impact on how we view the actions of the "hacker".
>If a company leaves data available in a manner that is accessible without using any kind of vulnerability, but rather allows the unintended (ab)use of a poorly implemented service, then that's not a "hack", that's on the company, and they should be held accountable.
Is it "theft" if you leave your keys in your car and I take it?
IMO the “car with keys inside” analogy is not great for poorly implemented infosec. The latter is both more benign (no physical property directly stolen) and at the same time worse (the scale means multitudes of people will become vulnerable to further attacks, identity theft, doxxing and so on, rather than just one person losing the means of movement). It’s just different qualitatively.
What should have impact on how we view the actions of a hacker is the context of said actions, not just the “hacking” part.
If the hacker exploited company’s infosec negligence to profit in some way (say, by selling the data), or irresponsibly disclosed the data or the vulnerability possibly causing harm to affected users, it is one thing.
Otherwise, the same sequence of hacker’s actions that exploits the vulnerability does not compare to stealing a car with keys inside—it is (another faulty analogy warning) more like looking at a car through some magical looking glass that highlights the keys left inside by the owner.
It's only a problem if you think it's a problem for someone to trivially build a social graph for every person on your exclusive social network with lots of high profile people.
Not a great response on their part since the article they reference in the tweet does not say that they have been breached or hacked. Only that there's a limited dataset of users out there and that Techmeme reached out to Clubhouse to know if they are aware of any breaches of their systems.
Pretty bad optics if the other stuff is true: incremental IDs, no rate limiting, tokens that don't expire.
I understand why people are saying this is not a breach and I tend to agree. I do think there are some basic measures you can put in place to make this kind of abuse harder.
The real problem is that most users don’t understand when they sign up for a service like clubhouse, what information is public, how easy it is for bad actors to get access to that information and how this information can be used to harm them later (phishing, identity theft etc.).
Who should be educating the average non technical user about the risk of agreeing to share you information publicly and even if they knew would it actually change anything.
Personally, I have hit the point where I have accepted that all my -and my families information is public and for that reason with people like my parents I tend focus on teaching them to avoid falling for phone scams and phishing.
Which one are you referring to? The recent millions of contacts that were exposed from FB contained phone numbers. It had my phone number and it's not public.
Guess their user id and you could get someones whole contact list, access their voicemail, or start a 30 person conference call which could dial out internationally with calls billed to the affected user...
The entire top management had user ids below 100...
I found the problem because on login all it set was a cookie with the userid, and so of course I tried changing it.
When I alerted my manager to the problem they put in place 'encryption' of said cookie.
It was base64 encoding.
They were shocked when I broke that too.
Writing this now it sounds invented, but it's not. To be fair this was more than 20 years ago, and a lot of developers did not yet have any understanding of security, so they at least had a shred of an excuse.
I never figured out what thought process led to them considering base64 a security feature. I mean, I could tell just by looking at the cookie it was base64, but I expected that meant they'd encrypted it and then base64 encoded the result. But no. It made me treat every bit of code I was handed with extreme caution.
It's definitely a grey area here. Clubhouse strongly encourages using real names on their platform. That can be considered personal information that should be protected by security controls that they seem to lack, based on what others have mentioned here, that could have limited this "leak".
That someone who wrote an iOS app with such a lame concept of security that anyone could dump the entire database (even if its only "public" data) in a script is not surprising, as most startups and even big companies don't give a crap about security. I've seen this way too often. If you are so cavalier about security in simple rest queries, imagine what lurks beneath not yet discovered.
The generated graph is interesting. I guess everyone in the middle are early adopters and people with high numbers of followers. Then the clusters on the outer edges are people catering to a niche audience. Then those niche audiences spawn their own microcosm
I'm completely done with centralized social media "apps." I'm not signing up for any more and other than HN I've stopped using all of them and recommended that my friends do the same (surprisingly, many have listened.)
I think we're watching the implosion of the cloud. Those leaks are not even illegal, yet they will lead to a lot of spam, a lot of phishing, and a lot of other clumsy actions by clumsy actors that will alienate users and make them more reluctant to give their information next time. At least, i hope we re post peak cloud and falling fast into the norm of the internet the way it was meant to be: pseudonymous
I don’t get it. This “leaked” information looks like something that would be displayed on a public website for each user. As far as I can see it’s just public information, like user names and avatars on e.g. stack overflow.
Honestly, I Clubhouse will fail. Telegram also launched a feature with podcasts. And in order to listen to lectures, you need some kind of material other than audio, so that everything is better assimilated and remembered. For this reason I use https://audext.com/
Why is this a leak? Looks like someone scraped the data any user has access to. If this is a leak, then the cybernews.com feed should be filled with linkedin/if/fb/etc leaks every minute.
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.
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.
* 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.
Do you mean that you trick the app into accepting a wrong cert? How does one do that, apart from decompilation?
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 [2]: https://techblog.mediaservice.net/2020/08/ios-13-certificate...
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
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
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.
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.
https://www.charlesproxy.com/documentation/ios/
https://www.raywenderlich.com/1484288-preventing-man-in-the-...
But considering how the API is documented now (and alternative third party apps exist), it might not even be necessary.
Also see the German Tank Problem[1].
1. https://en.m.wikipedia.org/wiki/German_tank_problem
For security incidents, "when they are needed" will be too late to do anything. If it's all the same to you, I'd advise that you default to GUIDs.
> This is misleading and false. Clubhouse has not been breached or hacked. The data referred to is all public profile information from our app, which anyone can access via the app or our API.
So just like what happened to Parler and LinkedIn. A so-called 'data breach' of its public data via scraping.
But last time I checked on the private API in a GitHub repo, Clubhouse is using integer IDs which are not random alphanumberic strings for its users.
This can essentially be scraped by a while loop, incrementing all the way to whoever last signed up.
Did Clubhouse even implement rate limiting to combat this?
[0] https://twitter.com/joinClubhouse/status/1381066324105854977
[1] https://www.wired.com/2013/03/att-hacker-gets-3-years/
He now runs admin for The Daily Stormer and somehow finds a way to keep popping up in the worst places, can't seem to shake the guy.
Additionally, he didn't even do the legwork for the AT&T op, but really wanted to take credit for something for cool hacker cred, and it came back and bit him. I keep company with several people involved in that ordeal.
What if they had exploited the heartbleed bug, would that have been a hack?
If a company leaves data available in a manner that is accessible without using any kind of vulnerability, but rather allows the unintended (ab)use of a poorly implemented service, then that's not a "hack", that's on the company, and they should be held accountable.
Personally I think an SQL injection still falls under the above. Securing public endpoints against long-known and easily mitigated vulnerabilities is 100% the company's responsibility..
There is no "we couldn't have prevented this" bullshit defense in that case.
>If a company leaves data available in a manner that is accessible without using any kind of vulnerability, but rather allows the unintended (ab)use of a poorly implemented service, then that's not a "hack", that's on the company, and they should be held accountable.
Is it "theft" if you leave your keys in your car and I take it?
What should have impact on how we view the actions of a hacker is the context of said actions, not just the “hacking” part.
If the hacker exploited company’s infosec negligence to profit in some way (say, by selling the data), or irresponsibly disclosed the data or the vulnerability possibly causing harm to affected users, it is one thing.
Otherwise, the same sequence of hacker’s actions that exploits the vulnerability does not compare to stealing a car with keys inside—it is (another faulty analogy warning) more like looking at a car through some magical looking glass that highlights the keys left inside by the owner.
So...it's a problem.
Pretty bad optics if the other stuff is true: incremental IDs, no rate limiting, tokens that don't expire.
The real problem is that most users don’t understand when they sign up for a service like clubhouse, what information is public, how easy it is for bad actors to get access to that information and how this information can be used to harm them later (phishing, identity theft etc.).
Who should be educating the average non technical user about the risk of agreeing to share you information publicly and even if they knew would it actually change anything.
Personally, I have hit the point where I have accepted that all my -and my families information is public and for that reason with people like my parents I tend focus on teaching them to avoid falling for phone scams and phishing.
Yes: that is public info. This is all no more a "leak" than the original service is a "leak" of itself.
For example: https://www.joinclubhouse.com/@clubhouse
https://twitter.com/mikko/status/1379686946117668867
Almost as if there was an endpoint /profiles/id that someone just scrapped by using id 0..9999999999
For private data.
Guess their user id and you could get someones whole contact list, access their voicemail, or start a 30 person conference call which could dial out internationally with calls billed to the affected user...
The entire top management had user ids below 100...
I found the problem because on login all it set was a cookie with the userid, and so of course I tried changing it.
When I alerted my manager to the problem they put in place 'encryption' of said cookie.
It was base64 encoding.
They were shocked when I broke that too.
Writing this now it sounds invented, but it's not. To be fair this was more than 20 years ago, and a lot of developers did not yet have any understanding of security, so they at least had a shred of an excuse.
I left that company first chance I got.
Made me chuckle.
Also it reads more like an advertisement for the author's services.
I'd like to see a more credible source.
https://twitter.com/wbm312/status/1360014416087945222?s=21