Three months ago I described XSS which I found in Google Colaboratory. Before you start reading this article, I recommend you go back to the previous one first, because I am going to develop the topic which started there.
In a nutshell, however, what previously happened:
- I was looking for XSS in Google Colaboratory (an application that is based on Jupyter Notebook, allowing you to share text in MarkDown and execution of Google python code on the cloud side).
- I discovered that it uses the Mathjax library.
- I found a bug in the MathJax library in the \unicode{} macro that allowed me to execute arbitrary JS code.
From a purely technical point of view, this error was not in MathJax itself, but in the plug-in, which is enabled by default, named: Assistive MathML.
Before the creator of MathJax fixed a bug in his library, Google simply disabled Assistive MathML as a patch. This seemed a sensible approach, because the main source of XSS vulnerabilities was completely disabled.
Turning Assistive MathML back on
Unless, of course, there is a way to turn the plug-in back on!
One day, by clicking on Google Colaboratory and looking for further bugs in it, I noticed that when I added the LaTeX code in the markdown header and clicked on it in the form rendered in the outline, the MathJax menu displayed. Interestingly, this menu did not appear in plain text. You can see this on the video below:
1. First I right-click on “plain” text and get a standard menu with Colaboratory.
2. Then I right-click on the outline and get a menu from MathJax.
Why is this menu so important? Because thanks to it I discovered that it is possible to turn on the Assistive MathML plug-in again (Picture nr 1)!
It turned out that after enabling this option in the menu, I was able to execute the same XSS as before, meaning, once again use the code. For example:
|
1 |
$ \unicode {41<img src=1 onerror=alert(document.domain)>} $ |
Results can be seen on picture nr 2
Does it mean that we already have XSS ready on the tray and can ask for a bounty? Not entirely. So far, Assistive MathML has been activated manually via the menu. The question of whether this option can by activated remotely to someone else remains open.
Storage of Assistive MathML information
So I started to browse the places where MathJax could save information about whether Assistive MathML option is enabled. In the first moment I set up on localStorage, but it was empty there. The second type were cookies and there I actually found the following entry:
|
1 |
mjx.menu=assistiveMML%3Atrue |
I once described it in other text on this blog. In short, the attack boils down to the fact that:
1. We have XSS in the domain Whatever.google.com.
2. Execute the code there: document.cookie=”mjx.menu=assistiveMML%3atrue; Domain=.Google.com; Path=/”
3. As a result, the cookie mjx.menu=assistiveMML%3atrue is sent to all subdomains of google.com.
I simulated the attack by attaching /etc/hosts of some-random-domain.google.com to 127.0.0.0.1, and then I executed the code in it:
|
1 2 3 4 5 6 7 8 9 |
<!doctype html><meta charset=utf-8> <button onclick=exploit() style=font-size:48px>Set cookie and redirect to Colaboratory!</button> <script> function exploit() { const COLAB_URL = "https://colab.research.google.com/notebooks/welcome.ipynb"; document.cookie = "mjx.menu=assistiveMML%3atrue; Domain=.google.com; Path=/"; location = COLAB_URL; } </script> |
Results can be seen in the video:
Summary
Two important conclusions can be drawn from the description above:
- If we manage to find one error in the bug bounty, it is worth looking for errors “around” this error.
- When we use external JS libraries, it is worth looking at where they can save data during their audits. As the example of MathJax shows, it may turn out that data from the application configuration can be overwritten by cookies!
Google paid the same amount of bounties as for the previous XSS in Colaboratory ($3133.70) despite the fact that this case was undoubtedly more difficult to use in practice (because it requires XSS in another application). From this we can probably conclude that in Google’s bug bounty it is worth looking for XSS through cookies.