This article is not very information rich, but one thing is clear: this is not a github leak, the code was just posted to github by whoever got access to it. So the headline is pretty misleading.
I figured the iOS bug somehow leaked credentials that gave access to GitHub.
Regardless, many of us agree that the title suggests GitHub as a central role to the leak. If, as other commenters say, it was just used as a file host.. it doesn't belong in the title imo. It's just there to pull in more views. It may as well been Piratebay.
Exactly what I was wondering about -- couldnt illegitimate DMCA requests be an attack vector to shut down a public GitHub repo temporarily? There wasn't much to the quoted DMCA request.
Edit: I'm guessing there's enough in the redacted part of the notice to prove SC's identity. But I think the question of DMCA abuse remains.
Actually it could be and it is sometimes abused. You don't need to proof that you are the copyright holder to submit the request. Companies tend to err on the side of removing things to make sure they don't become liable for copyright violation.
This happened to the SickRage project a while ago when a developer was not happy about the project being forked. The repositories were down for some time.
it's so comically bad that I think it was written by the leaker (i5aaaald/i5xx) himself, as a way to get extra publicity via the streisand effect. there's no way that snapchat doesn't have lawyers to write a proper request.
It has previously happened, in the special case of repos GitHub removed (like DMCAed ones). That is a different case from the original repo owner removing it voluntarily.
You're not doing work for years that lives solely on GitHub - it's cloned onto your local storage and the GitHub deletion does not affect your local copy.
GitHub might go and delete all the forks in this case, but that's not what happens in general. Normally on GitHub, if a public repo is deleted or made private, all of the forks survive [1].
I'm not trying to nitpick or be a jerk; I just wanted to point this out because I think that forking in general on GitHub is less useless than you imply.
What is the effect of this? Apart from some security through obscurity measures that might now be useless, what could the worst negative effect of this be? I can't imagine it could hurt Snapchat.
Same potential damages from source code leaks : revealing secret projects in roadmap, security or privacy malpractices, lack or respect of SW licenses.
You can probably scavenge code looking for possible leaks and attack vectors. Plus (I didn't check the code) you can find some tokens/salts/whatever used internally, or new features already there and hidden, a/b tests, etc....
Don't these guys have a super-secretive work culture? Like, you can't even ask what your colleague from another building is currently working on. I'd imagine they'd be very displeased with this leak, and somebody probably got fired.
I’m confused, did they somehow just include the source code in the app bundle? As a resource perhaps? Or can source code leak into the app through some other vector?
Once I was hacking an android app to get free coupons. After some investigation I found out they decided to generate the same coupon for n-customers, the coupons were changed every day, the coupon was based on MD5 or SHA1 of generated deterministic value (based on customer ID and date). There were 32k possible coupons per day. App was checking if the account and coupon is valid on their server, but it was always valid as they used the same algorithms in the app and on server... The core of the application was written in C#, launched by Mono on Android.
Java was compiled correctly with ProGuard (code obfuscator), but C# code was compiled in debug mode. C# in debug mode keeps variable/class/method names as they are in source code, leaves comments in the binary, binary file is bigger and slower. You can decompile it to compilable source code, literally.
I managed to get incorrectly protected secret key (they used GPG to encrypt JWT to server lol), later I managed RE of their API, make my own app with identical UI and working coupons. This allowed me to get free coupons every day for next almost 2 years. There were several updates in Google Play since then, but they haven't changed the logic or anything, the app is still in debug mode and anyone can use it. What is interesting, they have also app for iOS which is not in debug mode. Consistency is the key.
After I stopped using their services, I checked their ToS that you have to accept before registering and they prohibit app decompilation, but I never registered and never before read ToS, so it's OK for me ;) I wanted to report the problem but they have literally no contact information, I spent a few hours trying to find their contact details, Twitter is dead since 2014, no contact@ email, no contact form on website... nothing.
Lesson for you: check if your apps are correctly compiled and secrets protected, there are tools for it. In my previous company we had a Jenkins job to test it before release.
No, but it's great story on how not to make apps with coupons. I've learnt a lot from it and you can too. Just look at the bigger picture of it how many antipatterns they implemented and how many things they did wrong.
> Lesson for you: check if your apps are correctly compiled and secrets protected
And remember: no matter how well you think you have protected the secret, if it is in the client-side application then someone will be able to find it if they want to enough. It must be unpackable by your local code so it must be unpackable by someone who can unpack and understand that code.
Even if they used proguard or similar stuff, if they're putting the full code for that check client side they're dead in the water. People have been cracking obfuscated stuff forever and there's plenty of tooling to make it easier.
Honestly, it seems so stupid that their best defense is probably that no cracker even thought to check.
> The problem is that we tried to communicate with you but to no avail. The source code has been published on Github and I will publish it again until we get a response.
This is a case of the Streisand Effect[1] in action.
If anyone is really curious, it is called Source-SnapChat and it is all over Github.
Github is going to have to mass delete these mirrors, and prevent anyone from re-commiting it anywhere. Snapchat sending DMCAs is not going to be enough.
When specific repos are blacklisted on GitHub, they have a system that automatically flags uploaded forks. Not sure if/why they haven't blacklisted this codebase yet.
I'm guessing that somehow a chunk of their source code got marked as "copy to the bundle" from within the project's build phase. One scenario I could think of this happening is a bug in a custom build script that was intended to copy other resources (images, sounds, etc.) to the bundle and copied an unintended directory containing the leaked source code as well.
Is it weird that all of their methods start with SC? I guess we do that a little bit for the product I work on but it's also just one product in a much larger company and part of an entire platform. Snap is just snap.
64 comments
[ 3.3 ms ] story [ 132 ms ] threadIf the source was not already on GitHub, then a "GitHub Leak" of that source could not possibly be caused by a software error.
Regardless, many of us agree that the title suggests GitHub as a central role to the leak. If, as other commenters say, it was just used as a file host.. it doesn't belong in the title imo. It's just there to pull in more views. It may as well been Piratebay.
Edit: I'm guessing there's enough in the redacted part of the notice to prove SC's identity. But I think the question of DMCA abuse remains.
https://www.reddit.com/r/sickrage/comments/6oep02/false_dmca...
It's been forked 49 times so far.
But git is a distributed version control system, so git clone before the takedown would help.
If you fork a public repo and the original is deleted, your fork survives.
I'm not trying to nitpick or be a jerk; I just wanted to point this out because I think that forking in general on GitHub is less useless than you imply.
[1] https://help.github.com/articles/what-happens-to-forks-when-...
Java was compiled correctly with ProGuard (code obfuscator), but C# code was compiled in debug mode. C# in debug mode keeps variable/class/method names as they are in source code, leaves comments in the binary, binary file is bigger and slower. You can decompile it to compilable source code, literally.
I managed to get incorrectly protected secret key (they used GPG to encrypt JWT to server lol), later I managed RE of their API, make my own app with identical UI and working coupons. This allowed me to get free coupons every day for next almost 2 years. There were several updates in Google Play since then, but they haven't changed the logic or anything, the app is still in debug mode and anyone can use it. What is interesting, they have also app for iOS which is not in debug mode. Consistency is the key.
After I stopped using their services, I checked their ToS that you have to accept before registering and they prohibit app decompilation, but I never registered and never before read ToS, so it's OK for me ;) I wanted to report the problem but they have literally no contact information, I spent a few hours trying to find their contact details, Twitter is dead since 2014, no contact@ email, no contact form on website... nothing.
Lesson for you: check if your apps are correctly compiled and secrets protected, there are tools for it. In my previous company we had a Jenkins job to test it before release.
And remember: no matter how well you think you have protected the secret, if it is in the client-side application then someone will be able to find it if they want to enough. It must be unpackable by your local code so it must be unpackable by someone who can unpack and understand that code.
Honestly, it seems so stupid that their best defense is probably that no cracker even thought to check.
Every Play Store app has a contact email in the listing.
> The problem is that we tried to communicate with you but to no avail. The source code has been published on Github and I will publish it again until we get a response.
If anyone is really curious, it is called Source-SnapChat and it is all over Github.
Github is going to have to mass delete these mirrors, and prevent anyone from re-commiting it anywhere. Snapchat sending DMCAs is not going to be enough.
[1]: https://en.wikipedia.org/wiki/Streisand_effect