Unvalidated Redirect Through HTML Viewer – Element Messenger

Element (formerly Riot and Vector) is an open source instant messaging application implemented over the Matrix protocol. Matrix is known for supporting end-to-end encryption and the application itself is available for various platforms, including Desktop, Mobile and Web. This post will only be addressing the mobile version, which contained the vulnerability at the time this was written.

Firstly, the Android application in question is available at this link, with the code base for the application hosted here. The vulnerability in question is present in the native HTML Viewer application that Element is opening attachments with, instead of a browser, which does not correctly implement a sandbox mode, leading to Cross Site Scripting (XSS) being present via meta tag injection.

If a HTML attachment is uploaded to a room or chat, with a payload such as <meta http-equiv=”refresh” content=”0; URL=’http://sakshamanand.com/xss.html'” /> in the header, the built in viewer/browser functionality should be preventing scripts and plugins from executing, when the download/view attachment button is clicked. This is correctly being done on the servers, where the files are being rendered in the browsers with appropriate headers in place, as shown in screenshot below:

However, if the same attachment is opened in the Android Element application, the logic first tries to render the HTML file through the native HTML Viewer, then the meta header gets accepted and the user is forwarded to the the attack vector/site via external browser, as shown in the screenshots below:

This is considered a low level security vulnerability as if a client of any user shares a malicious payload (especially in public Matrix channels), anyone who clicks (accidentally, or intentionally) on it can be vulnerable to a variety of attacks, including, but not limited to:

  • Misleading or Automated Infected File Downloads;
    1. Due to human nature, a user may be in the mindset that in order to view the attachment they have to first download the file and open in. An attacker is able to name the file a user may be expecting, for example ‘sales_results.pdf’, if Matrix is being used in a commercial environment, and the file will be downloaded (at times without any prompt) and opened by the user.

      Depending on the device and it’s setting, a variety of actions can trigger; the file may automatically download and open on click, the actual extension of the file can be hidden (a user may think they are downloading a pdf file, when in fact it may be app package) and so on.

    2. The payload target can be replaced with Android Deep Link URLs, some which accept body content. For example “example://sakshamanand?data=malciousContent” can allow for stacked vulnerabilities, if the target application contains this type of behaviour.

  • Phishing Portals & Techniques;
    1. A web page can be created with a similar domain name (for example if victim is example.com, then attacker uses example.co), where the user is prompted to login using their credentials, in order to view the “attachment” they just clicked on.

  • Various other applicable XSS type attacks.

The issue above was tested with 10+ Android devices/users, and present in all instances. Additionally, this vulnerability was reported to upstream developers, on 29th October 2020, through the security policy listed on GitHub.

Update 01/12/20: Matrix Security team responded regarding the issue above and mentioned that given the issue is with native HTML Viewer in Android, no action can be taken at Element application level. I believe the bug ultimately then comes due to difference in expectations from the HTML Viewer and Element Android application. Given the minor nature of this issue, publishing this article.