Welcome to our Pentest Files blog series.
Each blog post will present an interesting or dangerous finding one of our testers has identified in an actual recent pen-test, so you can see the kinds of cool things our pen-testers get up to, and also to help you take steps to prevent similar vulnerabilities in your own assets.
These findings are taken from real reports, anonymised, and published with kind permission from our clients.
Tester: Adam
Vertical: Ed-Tech/Training/Learning
Impact: Compromise of AWS instance and all user data on the instance
What Happened?
Adam exploited a Server-Side Request Forgery flaw to devastating effect here, using it to eventually retrieve EC2 credentials.
Some Background
Ever heard of Server-Side Request Forgery? This flaw is very dangerous, but less well known than classic web vulnerabilities like SQL injection or Cross-Site Scripting. This class of issue is often more difficult to identify and exploit.
Essentially, an SSRF vulnerability occurs when an attacker can instruct an application to load an internal resource not normally accessible from an external perspective.
Below, you’ll read how Adam used the SSRF flaw on an application hosted on AWS to make a request to the AWS EC2 Instance metadata Service. This service provides a method for EC2 administrators to access user data and credentials associated with the particular EC2 instance.
The metadata is usually made accessible to the administrator over the internal link local address at http://169.254.169.254/latest/meta-data/
The Finding
In this instance, Adam found an SSRF vulnerability in a function that allowed users to ‘Download from URL’. The attack started by playing around with this URL.
Adam initially exploited this functionality by supplying an URL to an external tester-controlled server.
Adam had created a simple HTML page on our server running on this URL, which contained an image referencing the internal EC2 metadata API. As the URL Downloader functionality only accepted images, testers tricked it into believing the metadata API served images by appending the URL fragment #test.png at the end of the URL. This would not alter responses from the metadata API itself but would pass the sanity check of the URL Downloader plugin.
The HTML source of this page which Adam created was as follows - you can see the img tag containing the EC2 metadata service URL.
<html><img src="http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/#test.png"></html>
Essentially, once the setup was complete, Adam caused the ‘download URL’ functionality to trigger a request to the MetaData service, with the response (i.e. the data from the MetaData Service) being available in the subsequently downloaded image.
The raw response from the downloaded image can be seen below. Boom!
The Fix
Again, the fix is made by improving the configuration settings of the environment, namely by restricting acceptable ports to 443 only and restricting all internal IP ranges, including 127.0.0.1, the EC2 Metadata API on 169.254.169.254 and their IPv6 equivalents.
In this instance, we also recommended removing the functionality altogether.
Updates
We actually found this same vulnerability across multiple tests, which turned out to be an issue with the software our client was using, Moodle, hosted in AWS. After research, it appeared that this vulnerability had previously been discovered by an external security researcher who had notified the Moodle team and some ongoing discussion and development work was ongoing to help remediate the issue.
While a patch from the vendor was not immediately available the first time we observed this issue, we recommended some immediate security mitigations for our client to help protect their deployment of the application whilst the Moodle team worked on a patch for the issue.
This patch was released by the Moodle team a few months later and modified some default Moodle configuration settings to make this issue more difficult to exploit.
OnSecurity recommends keeping your software regularly up to date with the latest patches and ensuring that any application configuration conforms to best practices.
Bedtime Reading
https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ https://blog.hacktivesecurity.com/index.php?controller=post&action=view&id_post=47
Want to check for yourself if your application is free from this kind of vulnerability? Why not get a quote or contact us to set up a pentest.
