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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
I imagine it's disabled by default because at one point in time (not sure if it's changed in the last few years) any application on the iOS App Store using SSL required registration with the US Government for export control.
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.
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.
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.
"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 ..."
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.
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.
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.
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.
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 :)
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.
