Developers with Pocket recently fixed vulnerabilities that could have allowed users to exfiltrate data from the company’s servers, including sensitive information regarding web services, internal IP addresses and more.
Pocket, formerly known as Read it Later, is an online bookmarking app that allows users to save and manage articles from the internet to read later, usually offline.
Clint Ruoho, a security researcher, described the vulnerabilities in a blog post on Tuesday, claiming he first looked into the security of Pocket after learning that developers at Mozilla had implemented an opt-out, non-removable Pocket extension into Firefox back in June.
One of the first issues that Ruoho noticed was that Pocket in some respect functions as an internal network proxy. By making a request via Apache, he discovered that Apache’s mod_status could give him limited information about Pocket users, including “internal source and destination IP addresses, parameters of URLs currently being requested, and query parameters.”
This meant that if an attacker wanted to, assuming ExtendedStatus was enabled in Apache, they could determine via a GET request what articles or URLs certain users were saving or reading.
“The server-status page, when ExtendedStatus was enabled on the backend Pocket server, would return the first 60 characters or so of a GET request,” Ruoho told Threatpost Wednesday, “This could include URLs being read or saved by Pocket users.”
Another issue Ruoho discovered in the app was that he could parse through the metadata from Pocket’s backend servers, which were running on an Amazon Elastic Compute Cloud (EC2) system, without authentication.
This could give an attacker access to the following information that could be used in portscans for HTTP services on localhost to identify web apps, and potentially exploit further issues within Pocket:
- IAM credentials
- Availability zone
- Instance type
- Network type
- MAC address
- Details on attached block storage, etc.
The last and perhaps the most alarming vulnerability Ruoho found is that if someone placed a link in their Pocket queue that resulted in a redirect, it could allow an attacker to read any file on the filesystem with root privileges on the back-end server. In Ruoho’s case, he stumbled upon the contents of “file:///etc/passwd,” something that if Pocket hadn’t fixed, could have opened the service up to a slew of other attack vectors.
It would require a little work but since Pocket uses EC2-Classic style servers, it could have made the servers a prime target for an attacker to access.
“The back-end web servers ran in EC2-Classic networking which would allow any instance in the US-EAST-1 region to access them over ports 22 and 80,” Ruoho told Threatpost Wednesday.
Ruoho makes it clear in his blog that while they may sound sophisticated, the bugs were relatively easy to dig up, acknowledging he only needed a browser, the Pocket mobile app, and access to a server in Amazon EC2 to carry out his exploits.
“No sophisticated tooling was required to exploit these issues, nor was even basic scripting,” Ruoho writes.
Despite mild protest on its governance mailing list, Mozilla has opted to keep the Pocket functionality in Firefox. Pocket meanwhile did fix the issues and was cooperative in doing so.
Read It Later, Inc., which owns the app, follows a responsible disclosure policy and while it didn’t reward Ruoho with compensation for the vulnerabilities, it was fairly quick to address the issues. In fact, the company fixed some of them within three days. On two occasions during the 23 day review process Ruoho found bypasses for bugs the company thought it had fixed, but everything was eventually sorted out and patched in a scant three weeks.
