Flaws found in Pocket

Flaws found in Pocket
Flaws found in Pocket

A security researcher has described flaws in the security of servers for the Pocket add-on that comes with the Firefox browser. The vulnerabilities could have allowed hackers to exfiltrate data and fill reading lists with links to malware.

Writing on his blog, security researcher Clint Ruoho says the flaws come about because Pocket works in some ways as an internal network proxy. Ruoho was able to deduct from an Apache server error that Apache's mod statue could help in gleaning limited information about users, such as internal source and destination IP address, parameters of URLs currently being requested, and query parameters.

A hacker could use this, when ExtendedStatus was enabled in Apache, to determine via a GET request what articles or URLs some users were reading or saving.

“Additionally, by modifying GET parameters to server-status, an attacker could force the page to be downloaded again, possibly giving the response from a different server,” he said.

Ruoho said that as the vulnerability allowed him to see that Pocket was running on an EC2 instance on AWS. The vulnerability allowed him to inspect metadata on EC2, such as IAM credentials, in addition to details about the instance such as availability zone, instance type, network type, MAC address, details on attached block storage, and so on.

He said attackers could then automate portscans for HTTP services on localhost, bypassing EC2 security group firewall rules, identify web applications identified from portscan and attempt to exploit issues within the internal Pocket environment.

“From large enterprises to small startups, it's relatively common to encounter web applications that are only accessible internally, either from a network segment or the localhost interface on a server,” he said. “These applications often don't require authentication, so a malicious attacker would likely attempt to take advantage of this.”

Ruoho said that since Pocket was using EC2-Classic, obtaining access to the internal IP addresses revealed in server-status is as simple as spinning up a 2 cent/hour t1.micro instance in us-east-1. 

“From there attackers can use the RFC-1918 addresses to access services running on these instances, such as ssh or http. Portscanning these address is also trivial from an EC2-Classic instance in the same region. These instances are protected by EC2 security groups, however these are often setup in a less restrictive fashion when an elastic IP is not connected,” he added.

Elad Sharf, security research manager, at cyber-security firm Performanta told SCMagazineUK.com that the flaw was worrying.

“It is part of a bigger trend where a large amount of unsecure apps is being written. Take an average coder, he might make one mistake in 1000 lines, an experienced coder might make 0.0001 mistake in 1000 lines, but those mistakes might still create a vulnerability that can be exploited, which makes you wonder how many flaws have been discovered and not reported?” he said.

Sharf said the context of the app must be considered. “Is the host server secure, and who is the administrator on that network?”

“In the case of Pocket, I believe the Amazon Web Service server that was running the service was set to operate as a root user rather than with restricted privileges, which is a huge security blunder, and one of the first things you would instruct people to change.“

“As the tools for finding these vulnerabilities become more advanced and widespread, more will be found which can be exploited, and they will not always be found by white-hat hackers,” added Sharf.

Gavin Reid, vice predsident of Threat Intelligence at Lancope, told SCMagazineUK.com that the flaw was a “black mark for the owners of Pocket as people can abuse the service and access files and process that should only be available to the internal admin staff.”

“It is a server-side issue and has been patched so no-one is at risk anymore,” he added.

Reid said that the tool should have been tested by good pentesters to “find and fix any easily abused/found issues”.

Reid said that there was “very little” users of the service could have done to protect themselves from hacking. “We depend on the security consciousness of the 3rd parties (like Pocket) to provide a safe, secure, service. Unfortunately, security has not always been prioritised in a way that is dependable,” added Reid. 

Konrads Smelkovs of the Cyber Academy Team at KPMG told SCMagazineUK.com that while Pocket applied basic sanity checks to ensure that users couldn't just request files from their systems, they failed to account for address validation and redirection.
"In the first case, if you asked the Pocket system to retrieve a web page and specified an internal Pocket network address, it would do as instructed. This is not so useful as a would-be hacker would need to spend time searching ‘interesting pages' on their internal networks,” he said.
 
Smelkovs said that more worryingly was the second oversight of re-direction. "When a web server needs to redirect a web page, (to request to another resource, for example), if it has moved it issues a “302 Redirect” response and Pocket would follow this. Pocket would not validate the new destination of redirection and so the hacker could simply redirect it to the password file on the server. Pocket would then retrieve this information and send it to the hacker's mobile device for offline enjoyment,” he added.