A researcher netted a $9,000 payday last summer after digging up a XML external entity (XXE) vulnerability in a third-party backup software system used by Uber.
The vulnerability, which could have given an attacker access to the user backup data of any company using the software, including Uber, was patched in May 2016 but wasn’t disclosed until this week.
The issue appears to have existed in Crashplan, a service provided to Uber by Code42, a Minnesota-based company that backs up data for companies in real time. The service counts Lockheed Martin, Adobe, and the National Park Service among its users.
Vladimir Ivanov, a penetration tester at Positive Technologies in Moscow, uncovered the vulnerability last May when he stumbled upon the login page for Uber’s Code42 service. Ivanov had been poking around for URLs that qualified for Uber’s bug bounty program; the company offers bug bounties through HackerOne for researchers who discover in-scope vulnerabilities–such as XXE vulnerabilities–on in-scope properties, such as Uber’s Code42 site, backup.uberinternal.com.
Ivanov went to work trying to break the site; extracting any APIs that were publicly accessible and brute forcing them. He was able to find one API call, on Code42’s Crashplan.com site that he determined would contain XML authentication data that accepted getParameter(“SAMLResponse”).
After composing a XXE that received a response back, Ivanov determined the server was vulnerable to an XXE out-of-band attack, something that could have allowed him to read directories and extract data via XXE-FTP server, a tool that helps emulate an FTP server.
Out-of-band XXE attacks allow for the exfiltration of data even when the contents of the XML aren’t being directly reflected back to the attacker.
Ivanov was able to pull the contents from one of Uber’s servers as a proof of concept for his HackerOne report.
“The application had API through which all communications were held. I was able to communicate with API and retrieve data from server,” Ivanov told Threatpost Thursday.
According to Ivanov, from there, Uber’s security team got in touch with Code42, which was able to confirm the vulnerability and its severity. He was able to go deeper with his discovery after getting the green light from Uber. He went on to provide Uber with a screencap containing data from one of its servers where backup logs were kept, including information about a recently backed up user–their name, email address, IP address, globally unique identifier number, and so on.
While Code42 doesn’t have a bug bounty program, Uber does and since the vulnerability affected their servers, it rewarded him with a $9,000 bounty about seven weeks after he reported the issue.
“Uber was simply the proof of concept for the researcher and we helped him through the responsible disclosure process with Code42 since they don’t have a public bug bounty program,” an Uber spokesperson told Threatpost of the vulnerability Wednesday.
While the vulnerability was not publicly disclosed by HackerOne, Jobert Abma, the company’s cofounder told Threatpost Wednesday that it’s not unusual for one company to reward a researcher for identifying vulnerabilities in another company’s code.
“It’s not uncommon for companies to reward hackers for vulnerabilities in code maintained by someone else when it impacts their systems.” Abma said, “Seeing that they coordinated the disclosure of the vulnerability to the vendor shows how mature their company is in terms of security.”
According to Ivanov, while Code42 applied a fix on May 23, 2016, the company told him to wait until clients had installed the update before publishing his research. Ivanov believes that Code42 updated its corporate customers within a month after developers fixed the vulnerability, “due to high severity, ease of exploitation and high impact” and cited a lack of time when asked why he didn’t disclose the vulnerability until this week.
When reached Wednesday, a spokesperson from Code42 told Threatpost that the vulnerability stemmed from an issue with an unnamed third party code library it uses.
“The vulnerability as described in the article, was generated based on the use of a third party code library. It was identified by our internal team and resolved in May 2016,” a Code42 spokesperson said, “Exploiting this vulnerability does not grant access to customer backed up files. The security and safety of customer data is our top priority at Code42 and we take every action needed to ensure our customer’s data is fully protected.”
Ivanov told Threatpost that Code42 told him roughly the same thing last summer; the third party code library just hadn’t been updated at the moment he exploited the app on Uber’s site.
That said, Ivanov told Threatpost he wasn’t surprised, adding that there are “tons of such libraries,” many which are infrequently updated.
“Unfortunately I have no idea which particular parser and version they were using at that moment…” Ivanov said, “I do believe that they have a complex product with lots of code dependencies, and using an older version of any third-party libraries is not a big surprise, since it’s hard to always be updated with latest news of all libraries which developers are using. I can’t blame developers of third-party libraries that they do not always update their products, since they never know which companies inherit their libraries.”
While it appears the vulnerability could have given an attacker access to backed up data, as Code42 points out, it doesn’t appear it could have given them access to backed up files.
Ivanov told Threatpost he couldn’t confirm Code42’s stance that the vulnerability didn’t grant access to customer backed up files. While an attacker could use a XXE vulnerability to read contents of plaintext files, like application logs, configuration files, and system data, he said they wouldn’t be able to access or download binary files, ZIP archives, or JAR files. Since Uber’s bug bounty rules frown upon allow privilege escalation Ivanov only went as far as the company’s security team instructed him to.
