Jira Software is a proprietary issue tracking product developed by Atlassian that allows bug tracking and agile project management.
So from a vulnerable Jira Software we will get AWS Instance Credentials
Below are the 5 attack stages we will take: From Reconnaissance to Command & Control of AWS Instance
- Here we use nmap network scanner, so that we need to take more specific information on the product we are testing.
- And it is telling that is hosted on Amazon Web Services, and there are 2 open ports : 80 HTTP & 443 HTTPS
2. We open the IP in browser and the Jira Software Appears!
- As in any basic test that should be seen what the version contains a software product etc.
Jira here comes with a version 7.1.2
3. Researching about vulnerabilities on Jira Software
- Here we do some research about this version, and we see that all versions earlier than 7.3.6 are affected by the SSRF vulnerability.
4. SSRF Vulnerability is found in the consumerUri = parameter
5. Weaponization — Testing Vulnerability
- We test the parameter with an open redirect on the google.com site, where it works
- Testing at other weaknesses enables us to create an open redirect that leads the creation of an XSS Payload to this parameter!
6. Delivery — Delivering SSRF Attack on AWS Instance!
- We have to send the vulnerability to the AWS Instance, with exactly IP 169.254.169.254 that are relevant to Amazon’s services.
7. Exploitation — Exploitation of AWS Instance, on parameter consumerUri=
- So it worked successfully and as we can see here, there is information about the instance like private IP, version, InstanceId etc.
- Grabbing Credentials of AWS Instance
- We will attempt to get the AWS Instances Credentials, whereas can be seen the access key id and the secret access key that are fundamental to get access on it.
8. Command & Control — Configuration of AWS Instance
- apt update awscli
- Here we will configure AWS CLI, in our terminal.
- Exporting the credentials that we saw earlier.
9. Command & Control — Getting Full Access on AWS!
- And finally after configuration, this enabled us to get access to AWS Instances, strictly in control of the website.
- We could proceed further up to the upload of any shell, but all this testing was done in the client’s own proctoring, where which was enough to prove it and to further escalate with this weakness.
11. Prevention ways — Some ways to not get affected by this vulnerability
//Hope, you had a great time reading this write up, and learned new things.
//Thank you very much.