The easiest bug bounties I have won
josipfranjkovic.blogspot.com
The easiest bug bounties I have won
1–10 of 29 posts
Re: The easiest bug bounties I have won
#2Mobile would be great for taking this kind of approach to bug hunting.
Especially since Android just launched a (proper) bug bounty program [0]. A ton of old problems are new again on Android, especially due to the fact a significant percentage of the OS stuff is being re-implemented in Java (IPC, sandboxing, etc). The more I dig into it the more I'm convinced very few people are conducting serious security reviews outside of Google.
Take this bug as an example: http://seclists.org/fulldisclosure/2014/Nov/81 An apk with system privileges (the settings app) would accept IPC messages from any unprivileged app and relay them with system privileges.
[0] http://techcrunch.com/2015/06/16/google-launches-bug-bounty-...
Re: The easiest bug bounties I have won
#3It is quite saddening that there is a recent trend of hiding the complete URL from the user when the URL itself conveys much information. When the URL is hidden the user is not given the incentive to look at the URL, let alone modify it. This kind of bug should have been discovered much sooner when the user is given the opportunity to directly look at the URL and experiment with it.
Re: The easiest bug bounties I have won
#4Been following your work for years now and I think that this is actually the first bug I fully understand.
Re: The easiest bug bounties I have won
#5Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kernel.
No-one would accept such a shoddy design in an OS, yet in today's web apps it is apparently standard practice...
Re: The easiest bug bounties I have won
#6Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions.
The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac state where we're suddenly careless.
Re: The easiest bug bounties I have won
#7Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
Well actually you can look at it exactly like a kernel, where the backend is the kernel and http clients are the processes, and access control is done at resource level access, by the kernel. The things is, you couldn't even model facebook access with unix perms, and if you've played with acl, I think you realize that the problem is not solely due basic soft architecture.
That said, Facebook should have addressed this problem seriously by now.
Re: The easiest bug bounties I have won
#8Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
Well actually you can look at it exactly like a kernel, where the backend is the kernel and http clients are the processes, and access control is done at resource level access, by the kernel. The things is, you couldn't even model facebook access with unix perms, and if you've played with acl, I think you realize that the problem is not solely due basic soft architecture. That said, Facebook should have addressed thi…
But Facebook permissions can be modelled. They may not be direct mappings to UNIX permissions or ACLs, but that's taking my OS analogy too literally. The point is, Facebook should have a shared component that does the permission checks, rather than giving each page global access and relying on the author to do the checks themselves.
Re: The easiest bug bounties I have won
#9Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions. The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac stat…
Given the relentless appearance of this style of security bug in multiple Facebook pages, I think your description of a careless, amnesiac state is spot on.
Re: The easiest bug bounties I have won
#10Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kerne…
But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions. The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac stat…
In my app, I've been quite pleased with REST API endpoints mapping segments to objects the API will work on and explicitly declaring the permission before any page specific code runs.
So if you have an URL like /{username}/year/{year}/profile_lists you would in a declarative style, say that "username" must match an existing Facebook user ID, and that the page viewer must be able to view certain privacy related settings of the username. When your code runs, you get the current user, the username from the URL is mapped to another user object, year is mapped to an integer etc.
It's an error to declare an API which needs access to a resource without saying what type of access is required. In Facebook's case maybe I'd go one step further and create a proxy object for the user that codifies those rules. So if you ask for "view profile friend stats" access, and it's granted, the user object your function gets cannot start modifying things.