It feels like the presence of the Google and Slack API keys should have been responsibly disclosed to the company before writing this article. Now that it hits the front page of HN there's a strong change someone's going to exploit that.
You should honestly take this post down. You've literally revealed how to gain access to their API keys, mentioned that it can be used to devestate the company and commit fraud, then just added a message in parentheses asking the reader not to do it.
This is a shitty article that isn't humorous at all. It would've been funny if you had reported it, they had fixed and you'd posted the article after. This reads like an engineer trying to get an ego boost and a pat on the back.
It's not just bad taste. Some of the described actions would legally be considered fraud (both in the U.S., and in France where the author and app are based).
Reading this made me confused. You have a 'hire me' link on a page where you talk about exploiting someone's app? If you're not writing this up like a white hat, isn't the article counterproductive to you?
I can understand why you did all this (and hopefully, you reached out to the app provider to let them know about these holes), and it seems like you know enough about what you're doing. I'm just scratching my head at the end of all of this, and the article itself feels like it lacks structure.
The idea is to show my work. I tried to add a touch of humor, I think it's funny to try to earn money like this (actually you can't because they verify all transaction). If you think I can be seen as a black hat, I might modify some of it.
Also, a lot of developer (and some of my colleague too) tends to think that "hacking" doesn't exist like in movies or even doesn't exist at all (because they use ORM, don't laugh, I really got this one). By taking a real world example, I think It's a cool way to get people back in reality.
Anyway, people and my customers, hire me for my skills, and for what I did. Nobody care that you hacked an office, but if this office is the CIA, then it's cool.
For the lack of structure, it probably is, if you can give me example that I could fix, It would be very kind of you.
I would like to highlight the parent post's comment about attempting to contact the people whose work you are exposing vulnerabilities in.
I have to say that if this is "showing your work" then the most important thing you've shown is poor judgement in publishing their secrets in a submission to a very popular website. The fact that they have followed such shockingly bad security practices themselves is absolutely no excuse.
The work I wish we saw was the valiant effort you made to contact the company and help them see their mistakes. That is an area where we can all use more good examples, even if only to show how difficult it is to get something so obviously problematic taken seriously.
I'm certain you mean no ill will, but the lack of consideration here is concerning.
[EDIT] As per the posters comments, the keys included weren't the real ones. I still think the point stands: they are trivial to obtain when you know they are included in the package so their exclusion only means so much.
You're going to get a lot of hate here from the tech bros.
This, however, is much more inline with Defcon, CCC, and hacking culture. And this sort of writeup about (React, API endpoint insecurity, cheating apps) would be a straight-up accepted submission to the respective cons.
First off, you've done useful and valid work. Not that you should need me to say it, but I'll throw some kudos.
Explaining that it's not possible to actually 'cash out' would be great, and that would probably help deter script kiddies from trying to defraud the app. There are real people on the other side!
Tokens should be marked as redacted imo, and code sections could probably do to be snipped.
If you wanted a tl;dr, I guess it would be that it looks like ctrl-c and ctrl-v were your primary editing tools. They're great, and I use them all the time, but that w(t) thing took me 10 seconds of scrolling to get through when skimming, which was 10 seconds with none of your own words on screen. Less can often be more! Especially if I'm looking at disassembled gibberish.
Aside from now doing the Google API work client side, how to build an app like this, securely? If the server does work based on client data, I can still do more "normal" work by modifying the client.
That is, what is a non-hackable way to measure the physical environment of a consumer smartphone?
Can the critical data be stored in a DRM module protected by OEM TPM module?
> to measure the physical environment of a consumer smartphone?
At this point you need to be more precise about what you exactly intend to measure. Even if you build something perfectly unbreakable, nothing prevents an attacker from simulating the environment around it, whether movement (by building a robot to shake the device), visual (monitor in front of camera sensor), radio (GPS constellation simulators, etc).
I've seen physical security companies enforce patrols by having their guards tap their phone on a physical device in the secured property (which does a challenge-response) to prove that they've indeed been there at a given time, but even that can be defeated by attaching a device with a microcontroller and some out-of-band channel (cellular, etc) to relay the signals over the internet and allow them to "check-in" at every location without physically being there. The system works because in most cases the cost & skill required for such an attack isn't worth it (if you have those skills you typically already have access to better-paying jobs).
Health tracker apps typically don't have this problem because the incentives are aligned - the user has no incentive to lie to their health tracking app so no security is needed. It's a problem for this particular app because the true purpose of the app isn't to encourage healthy living, it's "growth and engagement" where advertisers can pay to get people to go to certain places and most likely buy their location data as well - in this case the relationship is adversarial and there's no bulletproof solution, it will always be a game of cat & mouse. The proper solution is to just find a better business model where incentives are aligned.
Niantic tried to implement anti-cheat measures around Pokemon Go. They hashed a lot of data available to the client and the phone. With some math/ML it's easy to do outlier detection and find the hacked/spoofed clients based on their GPS/gyroscope/accelerator/... data. It took ~4 days for the community (some bot devs, mostly map / tool developers) to figure it out, although the scene has never been the same since.
A solution would be for the OS developers (Apple/Google) to provide a way to retrieve data from the backend. This would not fully prevent it to be hacked but would change the difficulty:
- wanna be GPS spoofers would need to emulate the whole OS/sensors to send spoofed data to Apple/Google
- the platform/OS developers would have more ressources and incentives to detect spoofed data
The cat&mouse game is harder when played against Apple/Google than against a single small developer.
Readit News
EDIT: I'm waiting for WeWard answer. And will help them fix stuff presented in this article.
This is a shitty article that isn't humorous at all. It would've been funny if you had reported it, they had fixed and you'd posted the article after. This reads like an engineer trying to get an ego boost and a pat on the back.
I can understand why you did all this (and hopefully, you reached out to the app provider to let them know about these holes), and it seems like you know enough about what you're doing. I'm just scratching my head at the end of all of this, and the article itself feels like it lacks structure.
Also, a lot of developer (and some of my colleague too) tends to think that "hacking" doesn't exist like in movies or even doesn't exist at all (because they use ORM, don't laugh, I really got this one). By taking a real world example, I think It's a cool way to get people back in reality.
Anyway, people and my customers, hire me for my skills, and for what I did. Nobody care that you hacked an office, but if this office is the CIA, then it's cool.
For the lack of structure, it probably is, if you can give me example that I could fix, It would be very kind of you.
Thanks for your feedback.
I have to say that if this is "showing your work" then the most important thing you've shown is poor judgement in publishing their secrets in a submission to a very popular website. The fact that they have followed such shockingly bad security practices themselves is absolutely no excuse.
The work I wish we saw was the valiant effort you made to contact the company and help them see their mistakes. That is an area where we can all use more good examples, even if only to show how difficult it is to get something so obviously problematic taken seriously.
I'm certain you mean no ill will, but the lack of consideration here is concerning.
[EDIT] As per the posters comments, the keys included weren't the real ones. I still think the point stands: they are trivial to obtain when you know they are included in the package so their exclusion only means so much.
A lot of us think it is unethical and would take it as a huge red flag.
This, however, is much more inline with Defcon, CCC, and hacking culture. And this sort of writeup about (React, API endpoint insecurity, cheating apps) would be a straight-up accepted submission to the respective cons.
Deleted Comment
Explaining that it's not possible to actually 'cash out' would be great, and that would probably help deter script kiddies from trying to defraud the app. There are real people on the other side!
Tokens should be marked as redacted imo, and code sections could probably do to be snipped.
If you wanted a tl;dr, I guess it would be that it looks like ctrl-c and ctrl-v were your primary editing tools. They're great, and I use them all the time, but that w(t) thing took me 10 seconds of scrolling to get through when skimming, which was 10 seconds with none of your own words on screen. Less can often be more! Especially if I'm looking at disassembled gibberish.
That is, what is a non-hackable way to measure the physical environment of a consumer smartphone?
Can the critical data be stored in a DRM module protected by OEM TPM module?
At this point you need to be more precise about what you exactly intend to measure. Even if you build something perfectly unbreakable, nothing prevents an attacker from simulating the environment around it, whether movement (by building a robot to shake the device), visual (monitor in front of camera sensor), radio (GPS constellation simulators, etc).
I've seen physical security companies enforce patrols by having their guards tap their phone on a physical device in the secured property (which does a challenge-response) to prove that they've indeed been there at a given time, but even that can be defeated by attaching a device with a microcontroller and some out-of-band channel (cellular, etc) to relay the signals over the internet and allow them to "check-in" at every location without physically being there. The system works because in most cases the cost & skill required for such an attack isn't worth it (if you have those skills you typically already have access to better-paying jobs).
Health tracker apps typically don't have this problem because the incentives are aligned - the user has no incentive to lie to their health tracking app so no security is needed. It's a problem for this particular app because the true purpose of the app isn't to encourage healthy living, it's "growth and engagement" where advertisers can pay to get people to go to certain places and most likely buy their location data as well - in this case the relationship is adversarial and there's no bulletproof solution, it will always be a game of cat & mouse. The proper solution is to just find a better business model where incentives are aligned.
- wanna be GPS spoofers would need to emulate the whole OS/sensors to send spoofed data to Apple/Google
- the platform/OS developers would have more ressources and incentives to detect spoofed data
The cat&mouse game is harder when played against Apple/Google than against a single small developer.