In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >
Share
Shulou(Shulou.com)05/31 Report--
This article will explain in detail the case analysis from SSRF to finally obtaining access to AWS S3 Bucket. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.
This should be a targeted penetration, I focus on LFI (local file inclusion) vulnerability search, so I am very keen on file interaction-related features and endpoints. One of the common "Android Google Play" and "iPhone App store" options for downloading App caught my attention.
When I clicked on it, it redirected me to another page with the following link address-
Then immediately redirect to the previously referenced page, and when I open it in the invisible window to see what the response is when there is no reference to the page, it is redirected to a 404 page, so it is obviously looking for certain conditions and parameters, and then makes a simple if/else logic judgment. To see if there are any missing parameters, I stumbled across the following HTML code on the page-
The logic is very clear, as you can see in the red box, there is a php file "download_handler.php" missing in URL, which requires the parameter "path" as the URL name of finaldownloadlink and "name", which is why nothing has been downloaded. So the final URL should be-
Downloadcallback/download_handler.php?path=
I tried a directory traversal attack (.. / etc/passwd), and luckily almost all files were given maximum permissions (a common error: /), and I was able to read the contents of the / etc/passwd file and various other files-
I can read various Linux system files, configure, access logs, and get user access tokens and other more sensitive information in the get parameters. The culprit for this vulnerability is "download_handler.php"-
The PHP file simply takes the file as input and reads it back to the client. It's easy to see that it should be and very vulnerable to SSRF attacks-
Try using different URL schemas (file:///, dict://, ftp:// and gopher://) to read / etc/password, or you can use file:/// scheme to do the same-
Earlier, when I was grabbing sensitive files through a LFI attack, I happened to read the / etc/motd file, which indicated that the application was deployed through AWS ElasticBeanstalk.
It also made me decide to continue searching for AWS instance metadata and user data through SSRF-
I can also retrieve the AWS account ID and Region from the following API-
Http://169.254.169.254/latest/dynamic/instance-identity/document
When I read the AWS Elastic Beanstalk, I encountered an API call that fetches AWS Access Key,Secret Access Key and Token.
Http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role
I quickly made a call through SSRF, and I was able to get their AWS Access key,ID,token, and before that I also got their account ID, which shows that the vulnerability has become more serious than before-
Now is the time to authenticate the AWS account. To ensure that the credentials did not expire, I configured aws-cli to attempt to list and download S3 bucket data to my local machine-
Copy S3 bucket content to the local machine-
While looking at each individual S3 bucket, I found some key files in some bucket, such as database.js,config.js,app.js,payment.config. These documents soon caught my attention. As I expected, it contains information such as payment hash key and salt (which can be used to tamper with order payments), multiple database credentials, and some internal tool usernames and passwords. There is also a running MongoDB instance whose credentials can be found in the plain text of the configuration file, and when I tried to connect to it, I found that their customer data was also stored in it-
Although it does not contain the details of all users, it already contains more than 10000 pieces of data. Then I immediately reported the loophole to them, and they actively and quickly fixed it. Thank you for reading!
This is the end of the case analysis from SSRF to finally getting access to AWS S3 Bucket. I hope the above content can be of some help and learn more knowledge. If you think the article is good, you can share it for more people to see.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.