Yik Yak Hack(silverskylabs.github.io)
silverskylabs.github.io
Yik Yak Hack
http://silverskylabs.github.io/yakhak/
20 comments
Like if all new social network need to be hacked before explode :
Tinder : http://www.cammipham.com/tinder-hack/
WhatApp : http://techcrunch.com/2014/03/12/hole-in-whatsapp-for-androi...
Snapchat : http://www.reddit.com/r/Thefappening3/comments/2j4lql/90000_...
I don't quite understand what the hack was for the Tinder one. She just optimized her profile for likes? And added a banner saying match of the day? Not the hack I was expecting.
sorry, the good link : http://www.businessweek.com/articles/2014-02-19/new-tinder-s...
This one is much more troubling, and fits in more with your other links. I guess the lesson here is to treat everything like it's a beta, because that seems to be the nature of app and game development these days.
Agreed. Seemed more like 'growth hacking' or social engineering for popularity.
Don't forget the much publicized co-founder fight coered by every tech blog, deposition videos to follow.
Surprising they only used the User ID for auth. Surely you'd also generate a private key on the device and either use it as a password, or do public key cryptography to authenticate?
By the sounds of the Wikipedia article the developers were novices, however, which might be why they didn't think of doing this.
By the sounds of the Wikipedia article the developers were novices, however, which might be why they didn't think of doing this.
If the userID is long enough (it is) and all the communication is https (it almost is), then you dont need anything else.
It's not the most secure, but it's actually a pretty elegant solution. The userIDs are never used anywhere else, just as a cookie session ID essentially. They should have had them expire though. Your public key solution is definitely more secure and would accomplish hthat.
It's not the most secure, but it's actually a pretty elegant solution. The userIDs are never used anywhere else, just as a cookie session ID essentially. They should have had them expire though. Your public key solution is definitely more secure and would accomplish hthat.
There's no visible usernames in the app. I'm not sure what good taking over someone's account would do you.
Did you not read the part in the article about de-anonymizing user ids?
Delete something they posted about you.
1. Hack someone in your office
2. Hack someone in your home (one of your kids for example)
3. Hack someone in a coffee shop
Generally, when someone thinks they're anonymous and they aren't, bad things are going to happen.
2. Hack someone in your home (one of your kids for example)
3. Hack someone in a coffee shop
Generally, when someone thinks they're anonymous and they aren't, bad things are going to happen.
By "hack", you mean "discover the userIDs of users launching the app in your {office/home/coffee shop}." But this does not equate to a deanonymization of ANY past posts necessarily. userIDs are generated on app install, so anyone hoping to be anonymous needs only connect via a VPN to avoid a MITM on that particular connection, post the anonymous secret, and re-install the app. Then any further use of the app will not leak that they posted the secret, and in fact the information has been destroyed.
And I'm sure that's exactly what most users will do.
So you can MITM and take over someone's anonymous account, so what? There's no associated personal information, no logins or anything, so you wouldn't even know who owns that account, let alone passwords or emails.
You can view all the posts they've made and make a reasonable guess as to which person it was, I suppose, but that seems like a pretty flimsy argument.
You can view all the posts they've made and make a reasonable guess as to which person it was, I suppose, but that seems like a pretty flimsy argument.
Being able to link an account to a local IP address and MAC address would probably let you deanonymize the account. At the least, you could find the wifi MAC and then walk around measuring signal strength until you found the right table.
See my post above. You can hack someone geographically near you (i.e. in the same room or building). If you know the person, it wouldn't be hard to figure out who they are.
This doesn't seem like it will be too much of a practical problem. As said in the article, YikYak is mostly used on university campuses and odds are if a student is on campus they would be connected to the university wifi. From personal experience most university's use some form of WPA2-Enterprise authentication which which wireshark can't decrypt.
That's assuming the attacker would be a fellow student connecting to the wifi network, and not the school, who has full control of the the network beyond the access point.
I'm long out of undergrad so I've never used this app, but I've read that YikYak is at least somewhat known for controversial content regarding schools, school employees/faculty, and fellow students.
Seems like there would've been just as much, if not more, incentive for a university administrator to want to get people's post histories in order to divine who posted a particular piece of content.
I'm long out of undergrad so I've never used this app, but I've read that YikYak is at least somewhat known for controversial content regarding schools, school employees/faculty, and fellow students.
Seems like there would've been just as much, if not more, incentive for a university administrator to want to get people's post histories in order to divine who posted a particular piece of content.
> As said in the article, YikYak is mostly used on university campuses
University campuses, where students are constantly using the free WiFi in cafes, are on private WiFi networks shared with friends, etc. Even if the University's own WiFi was magically invulnerable, there will be many associated venues ready for use of this exploit.
University campuses, where students are constantly using the free WiFi in cafes, are on private WiFi networks shared with friends, etc. Even if the University's own WiFi was magically invulnerable, there will be many associated venues ready for use of this exploit.
1. Setup an open access point in the middle of campus.
2. Give it a default name (e.g. 'linksys').
3. Capture packets.
4. Profit.
2. Give it a default name (e.g. 'linksys').
3. Capture packets.
4. Profit.
Or set one up called "Free WiFi" in a location with a WiFi blackspot that many students congregate at.
There is no profit though, no one uses YikYak for posting anything remotely important.
Don't take it so literally. In this case "profit" is just synonym for "goal".
See: http://knowyourmeme.com/memes/profit
See: http://knowyourmeme.com/memes/profit
Ehh, people sometimes post embarassing/hateful things on YikYak, being able to out them would be a problem.
Or to blackmail them so you don't reveal their identity.
An app should not be considered "secure" because it doesn't currently have important data.
Twitter wasn't much of a honeypot, either, until activists and corporations started using it. Did Twitter know the exact moment that happened? No. They should have been secure long before that.
Twitter wasn't much of a honeypot, either, until activists and corporations started using it. Did Twitter know the exact moment that happened? No. They should have been secure long before that.
There's this thing called a "jasager" that you might also be interested in looking into. Particularly combined with airdrop-ng. I was a bit shocked when I learned how that particular aspect of 802.11 is implemented.
> YikYak is mostly used on university campuses and odds are if a student is on campus they would be connected to the university wifi
Based on some of the vague locations that Yik Yak gives with each post I'd say a little less than half are actually sent from on campus.
Based on some of the vague locations that Yik Yak gives with each post I'd say a little less than half are actually sent from on campus.
What about ARP spoofing? Have all wireless routers ever built somehow gotten this right?
It's my understanding that unless the wireless access point is sufficiently smart, any device on the same network can claim to be the router and your phone won't know the difference. Even if an attacking device can't passively decrypt your radio transmissions, it won't matter because the router will actively decrypt and re-encrypt your packets before forwarding them on to the attacking device.
It's my understanding that unless the wireless access point is sufficiently smart, any device on the same network can claim to be the router and your phone won't know the difference. Even if an attacking device can't passively decrypt your radio transmissions, it won't matter because the router will actively decrypt and re-encrypt your packets before forwarding them on to the attacking device.
Actually, yes! *For enterprise-grade APs generally deployed at university campuses...[0] Moreover, such APs usually have methods to prevent communication between peers on the same wireless network.
[0] http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mo...
[0] http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mo...
Was this responsibly disclosed? It doesn't seem to say whether it was. I'm fearing the worst.
Does the website disclose who is posting what?
Turnabout is fair play.
Turnabout is fair play.
They could just one way hash the userid then send that to the analytics service.
[deleted]
Sacrificing users' security just to load ads and generate revenue says a lot about this company's ethics.
Do you know anything about Yik Yak? It doesn't have ads, at least not on Android.
The article says they temporarily disable HTTPS to make a call to Flurry, which is an advertising/analytics company. They must be accessing the analytics side.
To be fair to YikYak, they didn't switch off HTTPS, Flurry switches it off by default. Maybe they didn't know of that? In any case, they should enable it and Flurry should make it the default.
to me it speaks more about poor security auditing. Treating the User ID as a public key instead of a private one to me signals lax security policy.
Client-side code (even native apps) must be considered public. That means your API is also publicly discoverable.
A user ID is fine to use as a public key, but it must be paired with something private. Generally some sort of unique, crypographically-secure auth token is fine when combined with forced HTTPS connections.
A user ID is fine to use as a public key, but it must be paired with something private. Generally some sort of unique, crypographically-secure auth token is fine when combined with forced HTTPS connections.
big take away: if you're using dependencies that talk across the internet, make sure they're ALSO using HTTPS
There's genuinely no excuse for Flurry (or any other vendor) to have an API that is not secured with HTTPS by default. I can't think of any reason other than stupidity or laziness, and those aren't excuses.
This is especially true of Flurry, which is tailored for connections directly from devices.
This is especially true of Flurry, which is tailored for connections directly from devices.
They're hosted on AWS and probably using server name indication (SNI) for their SSL. Android's version of HttpClient is outdated (and won't be upgraded [1]). This is why SNI is not supported in that library and this may be why they chose to use some dirty hacks [2] so that they can use SSL with HttpClient.
[1] http://android-developers.blogspot.de/2011/09/androids-http-... [2] https://developer.android.com/training/articles/security-ssl...
[1] http://android-developers.blogspot.de/2011/09/androids-http-... [2] https://developer.android.com/training/articles/security-ssl...
"To perform user-based analytics, Flurry needs some way of keep tracking of individual users. Yik Yak gave them the only user identification they have available: the userID."
And, while reading the article, we all probably were: "No, please, I hope they didn't do what I'm afraid is following now ..."
And, while reading the article, we all probably were: "No, please, I hope they didn't do what I'm afraid is following now ..."
[deleted]
What the hell? All that talk, plus a toolkit download, and not a word about responsible disclosure?
I'm not sure if I'd ever want SilverSky (the firm behind this) to have my money.
I'm not sure if I'd ever want SilverSky (the firm behind this) to have my money.
Silversky disclosed this to the Yik Yak team on December 2nd.
The original source appeared on their blog on Friday, December 3rd after Yik Yak had released an update to the App Store.
https://www.silversky.com/blog/yik-hak-smashing-the-yak
The original source appeared on their blog on Friday, December 3rd after Yik Yak had released an update to the App Store.
https://www.silversky.com/blog/yik-hak-smashing-the-yak
Would it be illegal to use this and post photos of the idiots using this app on my campus with their associated comments?
I don't see how this matters much. YikYak is anonymous, so if you stole my "account", all you'd get it my yakkarma. Potentially having a history of past yaks would reveal something about the user (not in my case).
This is the app that all those highschool kids almost killed themselves over right? Hack away, I would say responsibly disclose but this app only hurts people.
So another session hijacking hack using easily available tools?
Oooow snap!
I still don't quite get why people would want to disclose real private message anonymously on the internet. It should be common knowledge that nothing is ever 100% secure. It's all about the amount of efforts people are ready to put in order to hack it.
For me it's a pointless app, with a hack that require way too much effort to get such a small value. But that is nonetheless a vulnerability and I agree that this reveals some neglecting from Yik Yak engineers.
It's a big fail for them to be advertising privacy when they don't even check the security of the 3rd party tools they include in their flow.
This should serve as a reminder for the rest of us engineers to never blindly trust 3rd party tools and always cover your ass! Thanks for sharing :)
>real private message
That's not the point of Yik Yak. You're just broadcasting to the community, and rarely is something super incriminating posted, at least in my college's community.
That's not the point of Yik Yak. You're just broadcasting to the community, and rarely is something super incriminating posted, at least in my college's community.
A truly futile 'vulnerability'.
Sorry, in what way? Because Yik Yak is pointless?
Probably because the hack is value-less.
I doubt the users find the app pointless, but there isn't much reason to steal someone's account. You can't even link it to their real name to blackmail them.
I doubt the users find the app pointless, but there isn't much reason to steal someone's account. You can't even link it to their real name to blackmail them.
As a high schooler surrounded by a lot of Yik Yak users, the real value I see people finding from this exploit is the ability to associate multiple posts to a single user, allowing you to make connections and potentially find their identity. A lot of people I know also selectively tell people about some of their Yaks, so with one Yak you can find the rest.
Sorry, I'm really ignorant about these things, but once you have the ip of the phone that sent some message, couldn't you trace that to the physical phone? So you want to know who posted "foobar", you wait until you have someone's user id that posted "foobar", and then use the IP address of the most recent outgoing message to identify the phone. Since there's typically one user per phone, won't that identify the user?
Knowing the IP is pretty useless. The closest you can get publicly if you know that is the general region, but this app is already a nearby radius app, so you already know that. If you have law enforcement powers you can try to get the subscriber info who was using that IP during that time period, but normal people don't have that ability.
Even the article has to fall back to saying you have to just keep monitoring packets with that IP and hope the user uses some non-HTTPS web site that reveals their name. Although, honestly, most ISPs don't give you a static IP any more so the same user could be a different IP address multiple times a day.
Even the article has to fall back to saying you have to just keep monitoring packets with that IP and hope the user uses some non-HTTPS web site that reveals their name. Although, honestly, most ISPs don't give you a static IP any more so the same user could be a different IP address multiple times a day.
As demonstrated in the article, this gives you a local IP address which you could use to find the hostname of the device. For iOS devices, the hostname often contains the owner's name.
Yik Yak is an anonymous network, so a userID here is only on the device and not associated with any post. A user can't get the userID from a post.
Get User ID, log in as user (no passwords), check "your" post history.
Let's say you're the NSA. Edward Snowden posts "the NSA is spying on u" on yik yak. You see the yak on the Ft. Meade yak feed.
How do you get Edward Snowden's yik yak userID? This post doesn't show anything that lets you do this from a posted yak.
How do you get Edward Snowden's yik yak userID? This post doesn't show anything that lets you do this from a posted yak.
Deploy the hack on the local network and grab the ID of every user. Then check each ID to see if they made that post. Of course, this requires either foresight or for Edward to keep posting afterwards, but neither is outlandish.
This assumes that Edward Snowden continues posting in the same geofence as well. Using a GPS spoofer, you can just pick a random geofence each time.
Further, you can obtain a new userID just by reinstalling the app, so the information can be totally destroyed by the user as well.
It's very hard to leverage this attack into anything more interesting than getting a userID banned.
Further, you can obtain a new userID just by reinstalling the app, so the information can be totally destroyed by the user as well.
It's very hard to leverage this attack into anything more interesting than getting a userID banned.
I think you might be surprised by the type and value of information posted to these services.
http://www.theguardian.com/world/2014/oct/16/-sp-revealed-wh...
http://www.theguardian.com/world/2014/oct/16/-sp-revealed-wh...
Not a lot of Data brokers on HN.