“I find it interesting to find solutions and learn by making mistakes. Each scenario is different from the next, so I learn something new each time,” Osanda says.
Osanda is currently in his first year at the Asia Pacific Institute of Information Technology in Sri Lanka, where he was born. He’s working towards a degree in Computer Networks & Security and has future plans to get his Master’s degree in Computer Security Engineering.
A curious soul since childhood, it’s that inquisitiveness which led him to his passion of application security. He began reading blog posts from security researchers around the world and realized those exploit discoveries were something he aspired to do. He taught himself the basics through hacker essentials like Metasploit: The Penetration Tester’s Guide. That pervasiveness has paid off for Osanda, who now boasts hundreds of honors and gifts from the organizations which he’s responsibly disclosed to or received through bug bounties and keeps track of on his blog.
This past January, Osanda discovered a flaw in the way LinkedIn displays 3rd degree profiles – the connections of your connections. Over the years, LinkedIn has been reducing free accounts’ accessibility to profiles of people not directly in one’s network. It’s been filtered to the point where today free users can only see the first name and last initial of a 3rd degree profile along with their current and recent past positions while premium users can see full profiles. That wasn’t always the case, and Osanda discovered an issue where free users could act as premium users in viewing profiles in the 3rd degree network.
After receiving an email from LinkedIn telling him who had looked at his profile that week, he got a bit curious about one of the viewers, who happened to be a 3rd degree connection of his. However, lacking a premium account, he wanted to find a way around the paywall.
As a first step, he compared the GET request in the URL of one of his 1st degree connections to the info returned in the URL of a 3rd degree connection. For his 1st degree connection, an “authType” parameter was set to ‘NAME’ and an authToken contained the profile identifier. For the 3rd degree relation, the authType parameter was ‘OUT_OF_NETWORK’, and the authToken value had a different format, as well.
As a second step, Osanda tested LinkedIn’s ‘Export to PDF’ feature to see if he could glean any more information regarding these parameters. ‘Export to PDF’ allows users to download PDF’s of other user’s profiles. The PDF should contain the same information one can get from the online profile. This means that if you’re not a 1st connection, you shouldn’t see much more than what you see on their online profile, so Osanda, ever-curious, set out to test it.
What Osanda found was that the URL for a 3rd degree profile PDF still read ‘OUT_OF_NETWORK.’ However, when he changed that parameter to ‘NAME’ (the default value for the profiles of those he’s already connected to) he was able to download the PDF of his 3rd degree connection that showed her full profile. More so, Osanda realized that because the authType was changed to ’NAME’, the authToken was changed in the PDF’s URL, as well.
Osanda’s third step was to replace the old authToken value with this new authToken in the profile’s original URL. As a result, he was able to see the full online version profile, as well. In essence, Osanda had escalated his privileges to those of a premium account.
Following responsible disclosure practices, Osanda reported his finding to LinkedIn, which quickly fixed the vulnerability and thanked him with a small token of appreciation, a t-shirt. He says he never expects money out of his findings, and “as an honest researcher,” he says he is “prepared to except whatever they give me.”
The issue LinkedIn suffered from was one of missing authorization, in which the application doesn’t check for a user’s authorization upon accessing a resource. The vulnerability is listed in SANS 25 Most Dangerous Software Errors as well as in OWASP’s Top 10, under Missing Function Level Access Control. In the case of a site like LinkedIn, it only allowed Osanda to bypass the paywall between regular users and paid accounts, but other sites could and have suffered worse consequences through the same vulnerability, as happened to Citibank just a few years prior.
In 2011, Citibank suffered a breach that left over 360,000 Citi-issued credit cards exposed as well as some personally identifiable information. The breach was found to have been perpetrated by hackers accessing “account information through Account Online by logging in with an account number and password, and then modifying a few characters in the resulting URL bar in a browser in order to access additional accounts.” The missing authorization vulnerability had apparently been there since 2008 when it was finally discovered after the breach.
Bug hunting has only been an interest of Osanda’s for under a year; he found his first XSS issue on an Adobe site in October. Osanda says he was just browsing and noticed the bug, which he then relayed to Adobe and received his first acknowledgement. XSS remains his favorite find, simply because there are so many of them.
Besides Adobe and LinkedIn, Osanda has found hundreds of other vulnerabilities through the increasingly popular responsible disclosure and bug bounty programs at Microsoft, Apple, Oracle, GitHub, WordPress and many more. Bug bounty programs especially have seen an explosion over the past year, with major initiatives like the Internet Bug Bounty program allowing white hat hackers to show off their skills and gain recognition for the security bugs they find. That program’s supporting platform, HackerOne, just announced they’ve raised $9 million to continue helping companies create bug bounty programs, a sign that we’re moving towards a more crowd-sourced way of finding and fixing bugs.
The way Osanda sees it “is that every company should have some kind of a policy in which people can report any kind of vulnerability in a responsible manner to the organization.” He understands that having too many researchers at one time on the server can cause delays in service for the actual users, but “if the company has a huge presence on the internet, it’s obvious that maintaining security would be really hard by the employees themselves,” Osanda adds.
HackerOne’s CTO Alex Rice, who used to run the product security team at Facebook, has a very similar view. He was actually the one who launched the social media giant’s bug disclosure and bug bounty programs, and understands “the general problem is that vulnerabilities are inevitable. No matter what your security system, you are going to find issues. A researcher that finds [a bug] in the wild doesn’t know what to expect,” Rice said.
Osanda told BugCrowd a few months ago, “bug bounties do great work for security researchers and also give us a chance to show our skills in an ethical manner, but to be honest I am eternally glad to help people to secure their organizations, their publicly facing websites and software. I really enjoy being honest and helpful.”
Bug bounty programs are mostly a win-win for both vendors and the researchers themselves. For the researcher, having the opportunity to get rewarded for the work they’re already doing in discovering vulnerabilities and security bugs is a major bonus. Without at least a responsible disclosure program, ethical hackers don’t know whether they’ll be rewarded or arrested for reporting a vulnerability to the organization, and many researchers, Osanda included, won’t touch a site without a program. It’s just not worth the risk for them.
“If researchers find something, they don’t know if they’ll be welcomed with open arms or delivered to the FBI kicking in their door,” Mr. Rice said. “There’s a long stream of people with good intentions being treated very poorly as a result of that work.”
For the vendors, these programs create trust and positive relationships with researchers who will be much more likely to report vulnerabilities directly to them as opposed to selling them on the black market for a pretty penny. The vendors, in return, are aware of security bugs they may not have known about without the program. Osanda’s LinkedIn vulnerability discovery is a perfect example of the mutually beneficial relationship researchers and organizations with web apps can attain.
On top of bug hunting, Osanda has also developed several tools to help him and others hack. This past March, he released ChromeFreak, a cross-platform forensic tool, coded in python, for researchers to be able to investigate the “history, downloads, bookmarks, cookies,” of a Google Chrome client and even download a report of their findings.
He’s also coded a similar application for Skype data, aptly named SkypeFreak, as well as an automated tool called BrowserFreak for dumping stored browser passwords from Chrome, Firefox, Opera, Safari and Internet Explorer clients. The tool helps pen testers, in the post-exploitation phase, dump and download passwords with an added option of self-destruction for the downloads and tool. “I love exploring applications and how they work behind the scenes,” Osanda says.
Osanda also recently published his first white paper, ‘SQL Injection in Insert, Update and Delete Statements.’ Osanda says he was interested in researching payloads other than the traditional SQL injection ‘SELECT’ method, which gets the majority of the attention surrounding the long-time leader of the OWASP Top 10. Insert, Update and Delete statements are still commonly found, for example, when changing or creating new passwords, changing names, or deleting accounts.
His curiosity into the world of hacking hasn’t diminished in the slightest, and he expects it won’t for years to come. “I want to research for the rest of my life,” the student says. “I enjoy learning what I really like to do. I’ve only made a small step into security researching, and there’s a lot to learn, but I love doing what I’m good at and what I know.”
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.