9 ms·
Deleting any Facebook album
- BinaryIdiot 12y agoIt's really surprisingly to me that a user could take their access token and request a deletion of a resource that they do not have authorization to delete...and it deletes it. I wonder if they have anymore authorization issues like this.
- fakeempire 12y agoI'm struggling to not sound rude, but that's the whole point of the submission. He was surprised, you're surprised, I'm surprised, everyone here is surprised. Facebook was so surprised that they gave him money.
- msie 12y agoNice! Easy $12500. I'm kicking myself but then again, who woulda thunk?
- Tideflat 12y agoMight not have been easy depending on how many other things he had to test before he found this error.
- msie 12y agoI really don't understand the down-voting here. It wouldn't take an experienced security researcher to discover this bug and I think many missed it because they assumed such a vulnerability wouldn't exist.
- drubio 12y agoI think this post is a hoax. A lot of things don't add up. I thought there would be more interesting security posts and this is the only post on the entire site. The site was registered just 2 days ago, see http://www.whois.com/whois/7xter.com http://www.whois.com/whois/7xter.com . Then if you search on Google for the email that registered the site (laksshmanan51@gmail.com) you get this http://apnahindisms.blogspot.mx/2014/09/bewafa-shayari-in-hindi.html http://apnahindisms.blogspot.mx/2014/09/bewafa-shayari-in-hi... that has "You can earn huge using your Facebook page. Please let me know if you are interested. Shoot me a mail laksshmanan51@gmail.com"
- Fedorasupreme 12y agoShhh, don't interrupt the circle jerk. ;)
- Someone1234 12y agoHoly heck, $12.5K? That's one heck of a nice bug bounty program Facebook has there. That is likely more than the black market would pay for this, or at least a lot less hassle (plus the black market might have little interest as this cannot be used for hijackings, just trolling/harrassment).
- deleted 12y ago[deleted]
- dsacco 12y agoIt's not very useful to compare bug bounty payouts to what the "black market" would pay for a vulnerability. Let's look through the challenges of selling a vulnerability that allows for arbitrary account takeover (much more serious than this): 0. Find the vulnerability. Assume that no one will find it by the time you find a third party buyer. 1. Look for a buyer. If you're not well-connected, you might stumble into an FBI honeypot (a sting operation) because you don't know what you're doing. But let's assume you know what you're doing and you find a buyer. 2. You negotiate a price. You don't receive much more than Facebook would pay you (if they even give you that much) for a few reasons: a. The vulnerability can only be used on Facebook, so it's not vendor agnostic (compare Heartbleed, Shellshock); b. The vulnerability has an extremely small window of capitalization - it will be discovered within a week of use, maybe less. The Facebook incident response team is spectacular. c. You need to figure out a sufficient monetization strategy for distributing malware or spam using profiles that are taken over using this vulnerability. You have a week of use, much less if you try to take over accounts too aggressively. Now you're going up against all of Facebook's other protections - once you have the account, spreading malware will either be algorithmically discovered by Facebook or reported by other users. With an organized crime unit composed of professional hackers, this might pay off. Maybe. And that is for one of the most serious bugs you can find. You're better off just taking what Facebook (generously) gives you. The classical fallacy people fall into is believing that a web application vulnerability is worth much, especially the variety most tech companies have to offer. It's certainly serious, yes, but it's only worth what a market will pay for it. It's worth a lot to Facebook for brand integrity. It's not worth a lot to hackers looking to make money. The only web applications that might be worth real money would be banks or government institutions (or similar platforms). Real money is found in vulnerabilities on desktop clients, especially memory corruption vulnerabilities, or in ubiquitous software that affects servers. You want to be able to compromise a user for use in a botnet or distribute malware to steal their money or personal information. Alternatively, you want to be able to attack, say, 30% of the websites on the internet with a wide variety of options after you get in. Examples include: • Vulnerabilities in Flash. • Vulnerabilities in Python, Ruby or corresponding web frameworks. • Code execution in iOS that allows a jailbreak (most sources indicate the going price for this is $500,000). Other vulnerabilities as well, such as compromising app store receipts or in-app purchase checks. • Vulnerabilities in Android, up to and including code execution. • A game over flaw in any number of ubiquitous software packages used on Linux servers with root access. • A sandbox escape in OS X or Windows (you'll be paid more for Windows but both are lucrative).
- aarondf 12y agoThat seems a princely sum of money, but then again, this was a pretty serious flaw. Kudos!
- sillysaurus3 12y agoIf $12,500 seems like a lot of money, remember that Facebook theoretically loses $22,453 for every minute their website is down. In other words, they generate $12,500 every 33 seconds. Paying out that sum of money to increase the number of people searching for security flaws is quite smart.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- MichaelGG 12y agoYet there's no way to tell FB about problems without having an account (that I could find in 5 minutes). I found potential phishing attempts in the Windows Store, suggested apps right from the start menu. MS refuses to do anything about phishing/scams on their store, and FB offers no way to contact them (I tried a few email addresses like legal@, to no response).
- jessaustin 12y agoYeah there's no way that's enough money to submit to creating a FB account. [only half-joking... EDIT: three-quarters?]
- compbio 12y agoYou can (and preferably should) use a Whitehat Test Account to perform your research/make your report: https://www.facebook.com/whitehat/accounts/ https://www.facebook.com/whitehat/accounts/ apps.facebook.com (Facebook Windows Store) is not in the scope of this bug bounty program though.
- MichaelGG 12y agoI'm just trying to let FB know of a potential phishing attempt that's targeting all Windows users. I don't care about the bounty, in fact I only care a: to teach MS a lesson and b: to annoy the "developers" scamming people. I don't care enough to sign up for FB. Every other company I've dealt with on this, except some of the large media companies, have been easy enough to contact about the problem. To be clear, the issue is: Windows users using the Windows search feature, or directly using the Windows Store, are presented with fake FB apps claiming to be official. Contacting MS support gets useless replies, as they are trying to pump their app counts. Meanwhile, normal users end up installing a potentially malicious app, claiming to be the official FB app. FB needs to send a takedown.
- febin 12y agoThat was brilliant :)
- snikch 12y agoI'm not 100% sure on this, could you only delete albums for users who had given access to your app, or was it any user at all?
- mpeg 12y agothe app was "Facebook for Android" so there would have been a large surface area regardless.
- dsacco 12y agoGood work. I see a lot of people are surprised at the amount received for this report. Yes, that is typical of both Facebook and Google (and to a lesser extent, Yahoo will pay large sums for particularly bad bugs). They are extremely generous - Facebook recently paid $5000 for a bug report that existed in their careers portal despite that infrastructure being entirely third party. If anyone wants to try and replicate this sort of thing, consider this: the mobile applications (touch.facebook.com, iOS/Android apps) that Facebook use very often take advantage of legacy api calls and code that the main web application has long since disposed of. A well known researcher, Stephen Sclafani ('ssclafani) receiced a bounty of $25,000 for arbitrary account takeover using the legacy api. Legacy code is generally the first place to look for vulnerabilities. Legacy apis which are still allowed to exist for backwards compatibility are prime areas to search for bug bounties. Good luck.
- patio11 12y agoAnother good place is at edges of systems, particularly where they rub each other in fraught ways. What's the rule that says that computer systems invariably take on the architecture of the organizations that make them? You can predict Terrible Code Exists Here by getting a list of team names from the target (trivial -- use LinkedIn or ask anyone who works there) and then figuring out where those teams have shipped half-assed worked-on-my-machine glue code to tie their systems together. A common example: any handoff between a marketing site (or email) and a SaaS app more complicated than "Clicking this unchanging link takes you to a login form" almost certainly involves two teams and was somebody's perceived least important thing to do that day.
- taprun 12y agoThe "rule" that you're thinking of is Conway's Law: http://en.wikipedia.org/wiki/Conway%27s_law http://en.wikipedia.org/wiki/Conway%27s_law
- downandout 12y agoIf anyone wants to try and replicate this sort of thing, consider this: the mobile applications (touch.facebook.com, iOS/Android apps) that Facebook use very often take advantage of legacy api calls and code that the main web application has long since disposed of. Agreed. Touch/m.facebook.com have had major holes exist for long after they have been plugged on the main site. It was iframeable long after the main site wasn't (and thus subject to clickjacking). Also, for a long time you could invite anyone to events by Facebook ID by posting the correct calls to the mobile site, essentially without limit, even after the issue was fixed on the main site. Since custom messages could be embedded in the invitations, it was a spam free-for-all.
- element11 12y agoAmazing ! :)
- itsbits 12y agothats a easy 12500$ for a hack...but still you cracked it which many would ignored it..
- xienze 12y agoIs anyone else kind of shocked that this particular vulnerability exists given that Facebook employs "the best and brightest" in the industry? This isn't one of those vulnerabilities that relies on numerous seemingly unrelated steps and makes you wonder how the person ever thought it up. Instead, this is security 101 stuff. Facebook simply wasn't making sure userFor(appKey) == owner(albumId). I would've assumed obvious holes like this don't even exist in the API. So, props to the author trying it out. Wish I had.
- NathanCH 12y agoSomething tells me you're new to this industry
- duncans 12y agoMistakes happen. When you're pen-tested for the first time (by a decent pen-tester) you go through the 5 Stages of Grief with the stuff they find.
- deleted 12y ago[deleted]
- ch0wn 12y agoThat is not how a scalable architecture looks like. You don't want to handle authorization in the same service that's responsible for deleting the resource. Yes, there should have been tests in place, but no it's not a missing if condition.
- ponyous 12y agoCan you elaborate?
- tomjen3 12y agoCouldn't you have a service which checked you were allowed to delete something, then handed a deletion order back (essentially a signed xml blob) which would then get passed on to the actual deletion service (and here validated)? That way no issue with scalable architecture and no issue with hacks like this.
- Hortinstein 12y agosorry if this is trivial, but how easy is it to get the Mobile API access token? I thought api access tokens should be safeguarded like credentials
- geetee 12y agoYou didn't need the target's access token. Your own worked just fine.
- murki 12y agoExactly, that in itself is the whole point of this being a security bug.
- sleepyhead 12y agoWoah, didn't catch that when I first skimmed through the article. $12,500 wasn't enough then.
- sadfaceunread 12y agoIt seems like Facebook's Bug Bounty Program payment processor bugbountypayments.com is down http://isup.me/bugbountypayments.com http://isup.me/bugbountypayments.com . Anyone have any experience with that site? I haven't heard of it coming up before in security program discussions on HN or elsewhere.
- Untit1ed 12y agoThat actually works for me even though isup.me thinks it's down :/
- duncans 12y agoworks over https https://www.bugbountypayments.com https://www.bugbountypayments.com Wonder if it's intentional, i.e.: If you are truly L337 then you'd work it out eventually, or it's some sort of HSTS type-thing.
- darrhiggs 12y agoSo here seems like as good a thread as any. What do you do when you think a company would just fix the bug based on your report and not pay out anything? I have seen so many bugs in the wild like this. For example a site in the uk where I can get access to any account I wish. Are there any data protection laws that would provide leverage? How would you make first contact with a company that doesn't advertise a bug bounty program? Does this kind of email seem ok? "Hi, I have seen a security vulnerability on your site. How do I report it? What do you pay?… May you respond in the next 7 days or I will be forced to take this to xxx.org for the protection of your users"
- dsacco 12y agoNo, that email doesn't seem okay at all. That's extortion. A company has every right to not offer a bug bounty, and to fully prosecute you for trying to find a vulnerability (you can quibble about what "trying to find a vulnerability" means, but they have the right, like it or not). You have no right to demand payment for a perceived vulnerability in a company's infrastructure, even if they have a bug bounty program. The most serious vulnerabilities I ever found (read: the greatest potential for exploitation) came from reports to companies without bug bounties, so I know the position you're in. But looking for payment in return for vulnerabilities outside of the context of a bug bounty sets a precedent for the wrong motivation and is inherently adversarial to the company. Do not fish for vulnerabilities, then try to hold out your report for payment. Whether or not you believe it is unethical is a matter of personal opinion I suppose (I believe it's unethical), but it is at least illegal. Now, let me clarify: there is nothing wrong with giving a company a deadline before you go public. But 7 days is far too small of a deadline. 90 days is better. And if you do this, you don't seek payment, you do it because you're a professional security researcher who cares about their security, not because you're trying to make a quick buck. When you find a vulnerability like this, you proceed carefully. Contact a software developer, or better yet, a security team member (if they have one) who is technically savvy enough to understand your report. It would be best to do this anonymously. Email is strongly preferable, but you can escalate to Twitter if it means being put in contact with the right person. Obviously this means asking for help with security on Twitter, not disclosing the vulnerability publicly.
- chx 12y agoI suspect, of course have no proof that the bounty was this size because FB found a large number of other API calls similarly exploitable and locked them down in one go.
- andrewstuart 12y ago$12,500 man Facebook got that cheap. That's a $100M or more bug - there's no real way to put a price on it.
- mVChr 12y agoYou guys are missing a key factor. FB paid him $12.5k but didn't lose anything. Find line of code containing bug and: git blame -L2469,2469 -- app/core/shitty_auth.php | \ egrep -oh '[A-Z][a-z]+ [A-Z][a-z]+' | \ xargs -I {} python dock_monthly_pay.py \ --employee-name="{}" --amount=1041.67
- drubio 12y agoDidn't anyone else find this post suspicious ? I browsed through the site thinking there were some other interesting security posts. Turns out this is the only post on the site. Then I did a Whois and this site was created 2 days ago. It's registered to laksshmanan51@gmail.com which is apparently the same guy on the post. Then I did a search on Google for laksshmanan51@gmail.com and there are search results with "You can earn huge using your Facebook page. Please let me know if you are interested. Shoot me a mail laksshmanan51@gmail.com" This just doesn't pass the smell test with me, seems to me this guy just pwned a lot of people to get ad clicks or something else.
- monochromatic 12y agoAlso, the guy who found this vulnerability doesn't know not to use jpegs for text?? That doesn't pass the smell test either.
- deleted 12y ago[deleted]
- wodenokoto 12y agoThose are two completely different skill sets. one is knowledge of vulnerabilities and security, the other is about good web practices. There is no overlap in skill set here.
- Johnbrian 12y agoNope i see his name listed here for the last two years. https://www.facebook.com/whitehat/thanks https://www.facebook.com/whitehat/thanks
- notadocta 12y agoGreat job. I am supremely jealous. I REALLY could use $12,500 right about now. I really need to bring my curious nature back into the forefront.
- dennisgorelik 12y agoIt's impressive how many security bugs were reported on facebook: https://www.facebook.com/whitehat/thanks https://www.facebook.com/whitehat/thanks About 725 independent researchers contributed.
- xtrumanx 12y agoI've never been more motivated to sign up for FB like I am now so I checked out the eligibility rules for the bug bounty and I found one interesting rule: > Not reside in a country under any current U.S. Sanctions (e.g., North Korea, Libya, Cuba, etc.) Keyword there is any. Some Russian officials are under U.S. sanctions, does that mean Russian citizens are not eligible for the bounty? I ask cause according to Wikipedia[0], I reside in a country under U.S. sanctions but the sanctions apply to certain people instead of the entire country. [0] http://en.wikipedia.org/wiki/United_States_embargoes http://en.wikipedia.org/wiki/United_States_embargoes
- hastalavista 12y agoVery nice one buddy, but sorry to say , i think for this bug , the reward is a little too high :P no offense though
- aMadMan 12y agoIn the post the album id for the attackers album and the victims album are the same, 518171421550249. I'm not surprised the delete worked...