As FreeBuf recently reported, the developers of the Pocket app recently fixed several data leaks that allowed hackers to access sensitive information from the server. Here is a tutorial for everyone to learn and exchange.
What is the Pocket
I haven’t used Firefox as my primary browser in years, so I hadn’t actually heard of Pocket until I saw this post on Bugzilla about how the Mozilla Foundation pre-installed the Pocket plugin in all versions of Firefox and it couldn’t be uninstalled. Despite the outcry from users, the foundation has stubbornly stuck with Pocket.
Pocket’s function is to let users save web pages to “read later”. Pocket can mark the pages you want to read or haven’t finished for a while, then sync them to the server, and you can read them on different devices. As an information security practitioner, I find that this function usually leads to security problems, so I plan to check whether there are any problems with Pocket.
In fact, most of these vulnerabilities can be exploited by attackers. Attackers don’t need sophisticated tools, or even knowledge of scripts, to exploit these vulnerabilities.
Attempt 1: Protocol handler
Users can add urls to queues through the queue management function on Pocket website. Since the main purpose of the application is to browse web pages, these urls should be limited and only HTTP and HTTPS links should be allowed. So first I tried adding the following link to the queue:
file:///etc/passwd ssh://localhost telnet://localhost:25
Unfortunately, when tested, none of this worked
Attempt 2: Use the Pocket function as an Intranet proxy
I’ve seen an Apache error message on the Apache server status page before. Htaccess or Apache configuration files prevent localhost or some trusted network segment from accessing server-status:
Forbidden You don't have permission to access /server-status on this server.
I added a new link to my Pocket queue: http://127.0.0.1/server-status. After joining, the back-end server sends an HTTP request for the content. Does Apache trust requests from Localhost?
As it turned out, this worked, and I saw the following information in the Pocket queue:
Apache Server Status for 127.0.0.1 Server Version: Apache/2.2.29 (Unix) DAV/2 Server Built: Mar 12 2015 03:50:17 Current Time: Tuesday, 28-Jul-2015 10:07:45 CDT Restart Time: Tuesday, 28-Jul-2015 03:20:12 CDT Parent Server Generation: 12 Server uptime: 6 hours 47 minutes 32 seconds Total accesses: 241913 - Total Traffic: 4.1 GB CPU Usage: u1209.24 s110.06 cu0 cs0 - 5.4% CPU load 9.89 requests/sec - 177.5 kB/second - 17.9 kB/request 40 requests currently being processed, 14 idle workers ...
The entire output of the server state is synchronized to my Android. Apache’s mod_status can display a lot of useful information, including internal source and destination IP addresses, parameters for urls in sent requests, and query parameters. For Pocket applications, the requested URL includes the URL that Pocket users are viewing, because these requests are made through HTTP GET.
To hide this server information, we can turn ExtendedStatus off in Apache. Most of Pocket’s back-end servers have ExtendedStatus turned off, but a small number of servers are still open, so attackers can obtain such useful information.
In addition, by modifying the GET parameter of server-status, the attacker can force Pocket to download the page again, so that the hacker may obtain the information of different servers.
http://127.0.0.1/server-status?meaningless_parameter=1 http://127.0.0.1/server-status?meaningless_parameter=2 http://127.0.0.1/server-status?meaningless_parameter=3
Pocket is built on Amazon EC2
Since there is a loophole in Pocket that allows users to obtain relevant information of Pocket back-end server, let’s take a look at what other information we can obtain by using this loophole. With a simple dig command, we can see that Pocket uses Amazon’s EC2 server. Amazon’s EC2 has an instance metadata service. This service can only be accessed internally, without authentication, and is available on all EC2 instances. We can try using this service to get more information:
http://169.254.169.254/latest/meta-data/ http://169.254.169.254/latest/meta-data/hostname http://169.254.169.254/latest/meta-data/ami-id
After adding the links above to the Pocket queue, I can see the full server response. EC2 metadata contains a lot of information useful to attackers, including IAM login information, as well as details about the instance, including availability, instance type, network type, MAC address, block storage information, and so on.
What else can an attacker do?
Port scanning is carried out on the HTTP service of Localhost, which can bypass the firewall rules of EC2 to analyze the port scanning results and identify the opened Web applications to exploit vulnerabilities in the internal environment of Pocket
Many large and small businesses have web applications that are only accessible internally, often without authentication, and can easily be exploited by attackers.
What can you do with these internal IP addresses in server-status
As can be seen from the AMAZON EC2 metadata, the EC2 server used by Pocket is in US-EAST-1 (East Region 1 of the United States), and the network type is Classic (EC2 has two network types: EC2-Classic and VPC. VPCS are better, and some instance types are only available in VPCS. A VPC has more flexibility in creating subnetworks and access control lists (ACLs).
Since Pocket uses EC2-Classic, to access the internal IP address in server-Status, you only need to rent a 2-cent/hour T1.micro instance in THE US-East-1 area. This allows an attacker to use rfC-1918 addresses to access services running on these instances, such as SSH and HTTP, and even to perform port scans.
Using these internal IP addresses to access back-end servers has several advantages:
You can bypass things like front-end load balancers and front-end WAF firewalls. With front-end load balancers, an attacker can set x-Forwarded-For to a modified source IP address. Hackers can bypass ACLs or forge logs by doing this.
Input redirection
Applications like Pocket are likely to ignore some problems when dealing with HTTP redirected links, causing security risks. What happens when you add a redirected link to the URL queue? I typed file:///etc/passwd and the consequences were severe:
HTTP/1.1 301 Moved Permanently Location: file:///etc/passwd Content-Length: 52 Date: Tue, 28 Jul 2015 18:42:58 GMT Connection: keep-alive Moved Permanently. Redirecting to file:///etc/passwd
After I refreshed the Pocket app on my Android, file:///etc/passwd was added to the queue. After clicking on it, the complete /etc/passwd content appears in front of me.
At Pocket’s request, the /etc/passwd content has been removed
The impact of the bug can be left to the reader.
What can I do with /etc/passwd
When testing Pocket, I used this redirection vulnerability to request file:///proc/self/status, which can be used to get more information about the running process.
Here are some of the process status information:
Uid: 0 0 0 0 Gid: 0 0 0 0
The consequences of running this process as root are also left to the reader.
Combine the holes
Pocket responded quickly to my report, so I wasn’t able to combine the bugs. But imagine what a malicious attacker could do if he did discover these vulnerabilities.
1. Use a 301 redirection to obtain the file:///etc/passwd file and the home directory of the EC2 user. 2. Obtain the SSH private key from the user home directory. 3. Run the /server-status command to obtain the internal IP address. 5. Use the obtained SSH private key to connect to the IP address of the Pocket back-end server
What can I do next, you know
Pocket’s vulnerability disclosure policy is very responsible. I submitted all details of vulnerabilities to the Pocket official at the first time, and the disclosure time is decided by the subtracter, but it should be 21 days after the submission of vulnerabilities, so that Pocket can have time to deal with the vulnerabilities. The bugs have now been fixed.
Freebuf hackers and Geeks (FreeBuf.COM)