How I Earned $750 Bounty Reward From AT&T bug Bounty -Adesh Kolte
Hello Guyz
This Is Adesh Nandkishor Kolte
An Independent Security Resercher From India
AT&T Bug Bounty Board has authorized a payout of $750.00 for Me in recognition of on one or more report submissions that AT&T have remediated during 1Q18..
AT&T Inc. is an American multinational conglomerate holding company headquartered at Whitacre Tower in downtown Dallas, Texas. AT&T is the world’s largest telecommunications company.
Arbitrary Code Execution Vulnerability
Recently, I found an interesting issue Remote Code Execution for AT&T bug bounty program.
But before going into this let’s understand Arbitrary Code Execution –
Arbitrary Code Execution also know as command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications.
The issue which I found was straight forward and needs no explanation
I was able to execute the OS level command
Clickjacking Vulnerability
Vulnerable Website URL or Application
https://www.teleconference.att.com/servlet/ATTClogin
X-FRAME-OPTIONS header is missing in RTA application. It might be possible for a web page controlled by an attacker to load the content of this response within an iframe on the attacker’s page. This may enable a "clickjacking" attack, in which the attacker’s page overlays the target application’s interface with a different interface provided by the attacker. Impact: Attacker can trick user to visit malicious page containing vulnerable application inside the frame and by inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions. Recommendation: To effectively prevent framing attacks, the application should return a response header with the name
Proof Of Concept
<html>
<head>
<title>cj</title>
</head>
<body>
<iframe src=”https://www.teleconference.att.com/servlet/ATTClogin" width=”500" height=”500"></iframe>
</body>
</html>
Cross Site Scripting Vulnerability
Vulnerable Website URL or Application:
Vulnerable Parameter:
controller.do?
Payload:
‘-confirm(`1`)-’
Vulnerable URL
Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded
user input within the output it generates. By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially
using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
How Cross-site Scripting works
In order to run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject a payload into a web page that the victim visits. Of course, an attacker could use social engineering techniques to convince a user to visit a vulnerable page with an injected JavaScript payload. In order for an XSS attack to take place the vulnerable website needs to directly include user input in its pages. An attacker can then insert a string that will be used within the web page and treated as code by the victim’s browser.
WordPress 4.5.1 is vulnerable against a Same-Origin Method Execution (SOME) vulnerability
Vulnerable URL:
Simple PoC: http://example.com//wp-includes/js/plupload/plupload.flash.swf?target%g=alert&uid%g=hello&
WordPress 4.5.1 is vulnerable against a Same-Origin Method Execution (SOME) vulnerability that stems from an insecure URL sanitization process performed in the file plupload.flash.swf. The code in the file attempts to remove flashVars in case they have been set GET parameters but fails to do so, enabling XSS via ExternalInterface
Reward
Thanks for Reading :)
