In questo post abbiamo trattato la Top 10 di OWASP utilizzando il materiale in ProvaHackMe OWASP Top 10 Camera. Di seguito puoi trovare le risposte alle domande della stanza insieme a una playlist video di procedure dettagliate per spiegazioni approfondite.

Abbiamo anche coperto le soluzioni per ProvaHackMe OWASP Top 10 – 2021 camera.

Note sullo studio OSCP

Il corso pratico completo sul Penetration Testing delle applicazioni Web

Secondo OWASP, le 10 principali vulnerabilità delle applicazioni web sono

Vulnerabilità dell'iniezione

I difetti di iniezione sono molto comuni nelle applicazioni odierne. Questi difetti si verificano perché l'input controllato dall'utente viene interpretato come comandi o parametri effettivi dall'applicazione. Gli attacchi injection dipendono dalle tecnologie utilizzate e da come esattamente l’input viene interpretato da queste tecnologie. Alcuni esempi comuni includono:
SQL Injection: si verifica quando l'input controllato dall'utente viene passato alle query SQL. Di conseguenza, un utente malintenzionato può passare query SQL per manipolare il risultato di tali query.
Iniezione di comandi: si verifica quando l'input dell'utente viene passato ai comandi di sistema. Di conseguenza, un utente malintenzionato è in grado di eseguire comandi di sistema arbitrari sui server delle applicazioni.

Se un utente malintenzionato riesce a passare con successo un input interpretato correttamente, sarà in grado di effettuare le seguenti operazioni:
Accedi, modifica ed elimina le informazioni in un database quando questo input viene passato alle query del database. Ciò significherebbe che un utente malintenzionato può rubare informazioni sensibili come dettagli personali e credenziali.
Esegui comandi di sistema arbitrari su un server che consentirebbero a un utente malintenzionato di accedere ai sistemi degli utenti. Ciò consentirebbe loro di rubare dati sensibili e di effettuare ulteriori attacchi contro le infrastrutture collegate al server su cui viene eseguito il comando.

La principale difesa per prevenire gli attacchi injection è garantire che l'input controllato dall'utente non venga interpretato come query o comandi. Esistono diversi modi per farlo:
Utilizzando un elenco consentiti: quando l'input viene inviato al server, questo input viene confrontato con un elenco di input o caratteri sicuri. Se l'input è contrassegnato come sicuro, viene elaborato. In caso contrario, viene rifiutato e l'applicazione genera un errore.
Stripping input: se l'input contiene caratteri pericolosi, questi caratteri vengono rimossi prima di essere elaborati.

I caratteri o gli input pericolosi sono classificati come qualsiasi input che può modificare il modo in cui vengono elaborati i dati sottostanti. Invece di costruire manualmente elenchi di autorizzazione o anche solo eliminare l'input, ci sono varie librerie che eseguono queste azioni per te.

Iniezione di comandi del sistema operativo

Il Command Injection si verifica quando il codice lato server (come PHP) in un'applicazione web effettua una chiamata di sistema sulla macchina host. Si tratta di una vulnerabilità web che consente a un utente malintenzionato di sfruttare la chiamata di sistema effettuata per eseguire comandi del sistema operativo sul server. A volte questo non porterà sempre a qualcosa di dannoso, come un whoami o semplicemente la lettura di file. Non è poi così male. Ma il vantaggio dell’iniezione di comandi è che apre molte opzioni per l’aggressore. La cosa peggiore che potrebbero fare sarebbe generare una shell inversa per diventare l'utente con cui è in esecuzione il server web. Un semplice ;nc -e /bin/bash è tutto ciò che serve e possiedono il tuo server; alcune varianti di netcat non supportano l'opzione -e. In alternativa è possibile utilizzare un elenco di queste shell inverse.

Una volta che l’aggressore ha preso piede sul server web, può avviare la consueta enumerazione dei vostri sistemi e iniziare a cercare modi per girarsi intorno. Ora che sappiamo cos'è il command injection, inizieremo ad esaminare i diversi tipi e come testarli.

Attività 5 Risposte

Quale strano file di testo si trova nella directory principale del sito web?
drpepper.txt
Quanti utenti non root/non servizi/non demone ci sono?

0
Con quale utente viene eseguita l'app?

www-dati
Come è impostata la shell dell'utente?

/usr/sbin/nologin
Quale versione di Ubuntu è in esecuzione?

18.04.4
Stampa il MOTD. Quale bevanda preferita viene mostrata?

Dr. Pepper

Autenticazione interrotta

L'autenticazione e la gestione delle sessioni costituiscono componenti fondamentali delle moderne applicazioni web. L'autenticazione consente agli utenti di accedere alle applicazioni Web verificando la propria identità. La forma più comune di autenticazione utilizza un meccanismo di nome utente e password. Un utente immetterebbe queste credenziali, il server le verificherebbe. Se sono corretti, il server fornirà quindi al browser dell'utente un cookie di sessione. Un cookie di sessione è necessario perché i server Web utilizzano HTTP(S) per comunicare senza stato. Allegare cookie di sessione significa che il server saprà chi sta inviando quali dati. Il server può quindi tenere traccia delle azioni degli utenti.

Se un utente malintenzionato riesce a trovare difetti in un meccanismo di autenticazione, riuscirà ad accedere con successo agli account di altri utenti. Ciò consentirebbe all'aggressore di accedere a dati sensibili (a seconda dello scopo dell'applicazione). Alcuni difetti comuni nei meccanismi di autenticazione includono:

Attacchi di forza bruta: se un'applicazione web utilizza nomi utente e password, un utente malintenzionato è in grado di lanciare attacchi di forza bruta che gli consentono di indovinare nome utente e password utilizzando più tentativi di autenticazione.
Utilizzo di credenziali deboli: le applicazioni web dovrebbero impostare politiche di password complesse. Se le applicazioni consentono agli utenti di impostare password come "password1" o password comuni, un utente malintenzionato sarà in grado di indovinarle facilmente e accedere agli account utente. Possono farlo senza forzature brute e senza tentativi multipli.
Cookie di sessione deboli: i cookie di sessione sono il modo in cui il server tiene traccia degli utenti. Se i cookie di sessione contengono valori prevedibili, un utente malintenzionato può impostare i propri cookie di sessione e accedere agli account degli utenti.
Possono esserci varie attenuazioni per i meccanismi di autenticazione non funzionanti a seconda del difetto esatto:

Per evitare attacchi che indovinano la password, assicurati che l'applicazione applichi una politica di password complessa.
Per evitare attacchi di forza bruta, assicurati che l'applicazione imponga un blocco automatico dopo un certo numero di tentativi. Ciò impedirebbe a un utente malintenzionato di lanciare più attacchi di forza bruta.
Implementare l'autenticazione a più fattori: se un utente dispone di più metodi di autenticazione, ad esempio utilizzando nome utente e password e ricevendo un codice sul proprio dispositivo mobile, sarebbe difficile per un utente malintenzionato ottenere l'accesso a entrambe le credenziali per accedere al proprio account .

Attività 7 Risposte

Qual è la bandiera che hai trovato nell'account di Darren?
fe86079416a21a3c99937fea8874b667
Ora prova a fare lo stesso trucco e vedi se riesci ad accedere come Arthur.

Nessuna risposta necessaria
Qual è la bandiera che hai trovato nel conto di Arthur?

d9ac0f7db4fda460ac3edeb75d75e16e

Esposizione di dati sensibili

Quando una webapp divulga accidentalmente dati sensibili, si parla di “esposizione di dati sensibili”. Si tratta spesso di dati direttamente collegati ai clienti (ad esempio nomi, date di nascita, informazioni finanziarie, ecc.), ma potrebbero anche essere informazioni più tecniche, come nomi utente e password. A livelli più complessi ciò spesso implica tecniche come il “Man in The Middle Attack”, in base al quale l’aggressore forza le connessioni dell’utente attraverso un dispositivo che controlla, quindi sfrutta la crittografia debole su tutti i dati trasmessi per ottenere l’accesso alle informazioni intercettate. (se i dati sono addirittura crittografati in primo luogo…). Naturalmente, molti esempi sono molto più semplici e le vulnerabilità possono essere trovate nelle app Web che possono essere sfruttate senza alcuna conoscenza avanzata di rete. In alcuni casi, infatti, i dati sensibili si trovano direttamente sul webserver stesso…

Attività 11 Risposte

Dai un'occhiata alla webapp. Lo sviluppatore ha lasciato una nota in cui indica che sono presenti dati sensibili in una directory specifica.

Qual è il nome della directory menzionata?
/risorse
Passa alla directory che hai trovato nella domanda uno. Quale file risulta probabile che contenga dati sensibili?

webapp.db
Utilizza il materiale di supporto per accedere ai dati sensibili. Qual è l'hash della password dell'utente amministratore?

6eea9b7ef19179a06954edd0f6c05ceb
Rompi l'hashish.
Qual è la password in chiaro dell'amministratore?

qwertyuiop
Accedi come amministratore. Cos'è la bandiera?

THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

Iniezione di entità esterne XML

Un attacco XML External Entity (XXE) è una vulnerabilità che abusa delle funzionalità dei parser/dati XML. Spesso consente a un utente malintenzionato di interagire con qualsiasi backend o sistema esterno a cui l'applicazione stessa può accedere e può consentire all'utente malintenzionato di leggere il file su quel sistema. Possono anche causare attacchi Denial of Service (DoS) o utilizzare XXE per eseguire Server-Side Request Forgery (SSRF) inducendo l'applicazione Web a effettuare richieste ad altre applicazioni. XXE può persino abilitare la scansione delle porte e portare all'esecuzione di codice remoto.

Esistono due tipi di attacchi XXE: in banda e fuori banda (OOB-XXE).
1) Un attacco XXE in banda è quello in cui l'attaccante può ricevere una risposta immediata al payload XXE.

2) attacchi XXE fuori banda (chiamati anche XXE ciechi), non c'è una risposta immediata da parte dell'applicazione web e l'aggressore deve riflettere l'output del proprio payload XXE su qualche altro file o sul proprio server.

Attività 13 Risposte

Forma completa di XML
Linguaggio di markup estensibile
È obbligatorio avere il prologo XML nei documenti XML?

NO
Possiamo convalidare i documenti XML rispetto a uno schema?

SÌ
Come possiamo specificare la versione XML e la codifica nel documento XML?

Prologo XML

Attività 14 Risposte

Come si definisce un nuovo ELEMENTO?
!ELEMENTO
Come si definisce un elemento ROOT?

!DOCTYPE
Come si definisce una nuova ENTITA'?

!ENTITÀ

Esempio di carichi utili XXE

<!DOCTYPE replace [ ]>
<userInfo>
falco
&nome;
</userInfo>

<?xml version=”1.0″?>
<!DOCTYPE root [ ]>
&Leggere;

Attività 16 Risposte

Prova a visualizzare il tuo nome utilizzando qualsiasi payload.
Nessuna risposta necessaria
Vedi se riesci a leggere il file /etc/passwd

Nessuna risposta necessaria
Qual è il nome dell'utente in /etc/passwd

falco
Dove si trova la chiave SSH di Falcon?

/home/falcon/.ssh/id_rsa
Quali sono i primi 18 caratteri della chiave privata di Falcon

MIIEogIBAAKCAQEA7

Vulnerabilità del controllo degli accessi interrotto

I siti web hanno pagine protette dai visitatori abituali, ad esempio solo l'utente amministratore del sito dovrebbe essere in grado di accedere a una pagina per gestire altri utenti. Se un visitatore del sito Web è in grado di accedere alla pagina o alle pagine protette che non è autorizzato a visualizzare, i controlli di accesso vengono interrotti.

Un visitatore abituale che riesce ad accedere a pagine protette può portare a quanto segue:
Essere in grado di visualizzare informazioni sensibili
Accesso a funzionalità non autorizzate
OWASP ha elencato alcuni scenari di attacco che dimostrano i punti deboli del controllo degli accessi:

Scenario #1: l'applicazione utilizza dati non verificati in una chiamata SQL che accede alle informazioni sull'account:
pstmt.setString(1, request.getParameter(“acct”));
Risultati ResultSet = pstmt.executeQuery( );

Un utente malintenzionato modifica semplicemente il parametro "acct" nel browser per inviare il numero di conto che desidera. Se non adeguatamente verificato, l'aggressore può accedere all'account di qualsiasi utente.
http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: un utente malintenzionato forza semplicemente la navigazione negli URL di destinazione. Per accedere alla pagina di amministrazione sono necessari i diritti di amministratore.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

Se un utente non autenticato può accedere a una delle due pagine, è un difetto. Se un non amministratore può accedere alla pagina di amministrazione, si tratta di un difetto (riferimento agli scenari).

In parole povere, il controllo degli accessi interrotto consente agli aggressori di aggirare l’autorizzazione che può consentire loro di visualizzare dati sensibili o eseguire attività come se fossero un utente privilegiato.

Vulnerabilità dell'IDOR

Guarda le note degli altri utenti. Cos'è la bandiera?

bandiera{cinquequattrotre}

Errata configurazione della sicurezza

Le configurazioni errate della sicurezza sono distinte dalle altre 10 principali vulnerabilità, perché si verificano quando la sicurezza avrebbe potuto essere configurata correttamente ma non lo è stata.

Le configurazioni errate della sicurezza includono:

Autorizzazioni mal configurate sui servizi cloud, come i bucket S3
Avere funzionalità non necessarie abilitate, come servizi, pagine, account o privilegi
Account predefiniti con password invariate
Messaggi di errore eccessivamente dettagliati che consentono a un utente malintenzionato di scoprire di più sul sistema
Non utilizzare intestazioni di sicurezza HTTP o rivelare troppi dettagli nell'intestazione Server: HTTP
Questa vulnerabilità può spesso portare a ulteriori vulnerabilità, come credenziali predefinite che consentono l'accesso a dati sensibili, XXE o inserimento di comandi nelle pagine di amministrazione.

Per maggiori informazioni, ti consiglio di dare un'occhiata alla top 10 di OWASP per gli errori di configurazione della sicurezza

Password predefinite
Nello specifico, questa VM si concentra sulle password predefinite. Questi sono un esempio specifico di un'errata configurazione della sicurezza. Potresti e dovresti modificare le password predefinite, ma le persone spesso non lo fanno.

È particolarmente comune nei dispositivi embedded e Internet of Things e nella maggior parte dei casi i proprietari non modificano queste password.

È facile immaginare il rischio delle credenziali predefinite dal punto di vista di un utente malintenzionato. Essere in grado di accedere a dashboard di amministrazione, servizi progettati per amministratori di sistema o produttori o persino all'infrastruttura di rete potrebbe essere incredibilmente utile per attaccare un'azienda. Dall'esposizione dei dati alla facile RCE, gli effetti delle credenziali predefinite possono essere gravi.

Nell'ottobre 2016, Dyn (un provider DNS) è stato messo offline da uno degli attacchi DDoS più memorabili degli ultimi 10 anni. L'ondata di traffico proveniva principalmente dall'Internet delle cose e da dispositivi di rete come router e modem, infettati dal malware Mirai.

In che modo il malware ha preso il controllo dei sistemi? Password predefinite. Il malware aveva un elenco di 63 coppie nome utente/password e tentava di accedere ai servizi telnet esposti.

L’attacco DDoS è stato notevole perché ha messo offline molti siti e servizi di grandi dimensioni. Amazon, Twitter, Netflix, GitHub, Xbox Live, PlayStation Network e molti altri servizi sono rimasti offline per diverse ore in 3 ondate di attacchi DDoS su Dyn.

Entra nella webapp e trova la bandiera!

thm{4b9513968fd564a87b28aa1f9d672e17}

Spiegazione del Cross Site Scripting

Lo scripting cross-site, noto anche come XSS, è una vulnerabilità di sicurezza tipicamente presente nelle applicazioni web. È un tipo di iniezione che può consentire a un utente malintenzionato di eseguire script dannosi e di eseguirli sul computer della vittima.

Un'applicazione Web è vulnerabile a XSS se utilizza input utente non disinfettati. XSS è possibile in Javascript, VBScript, Flash e CSS. Esistono tre tipi principali di cross-site scripting:
XSS archiviato: il tipo di XSS più pericoloso. È qui che proviene una stringa dannosa dal database del sito Web. Ciò accade spesso quando un sito Web consente l'input dell'utente che non viene ripulito (rimuove le "parti difettose" dell'input di un utente) quando viene inserito nel database.
XSS riflesso: il payload dannoso fa parte della richiesta delle vittime al sito web. Il sito Web include questo payload in risposta all'utente. Per riassumere, un utente malintenzionato deve indurre una vittima a fare clic su un URL per eseguire il proprio payload dannoso.
XSS basato su DOM – DOM sta per Document Object Model ed è un'interfaccia di programmazione per documenti HTML e XML. Rappresenta la pagina in cui i programmi possono modificare la struttura, lo stile e il contenuto del documento. Una pagina web è un documento e questo documento può essere visualizzato nella finestra del browser o come sorgente HTML.
Per ulteriori spiegazioni ed esercizi XSS, controlla la sala XSS.

Carichi utili XSS
Ricorda, il cross-site scripting è una vulnerabilità che può essere sfruttata per eseguire Javascript dannosi sul computer di una vittima. Dai un'occhiata ad alcuni tipi di payload comuni utilizzati:

Popup's (): crea un messaggio popup Hello World sul browser di un utente.
Scrittura di HTML (document.write): sovrascrivi l'HTML del sito Web per aggiungerne uno tuo (sostanzialmente deturpando l'intera pagina).
XSS Keylogger (http://www.xss-payloads.com/payloads/scripts/simplekeylogger.js.html) – È possibile registrare tutte le sequenze di tasti di un utente, acquisendo la sua password e altre informazioni sensibili digitate nella pagina web.
Scansione delle porte (http://www.xss-payloads.com/payloads/scripts/portscanapi.js.html) – Un mini scanner delle porte locali (ulteriori informazioni al riguardo sono fornite nella stanza TryHackMe XSS).
XSS-Payloads.com (http://www.xss-payloads.com/) è un sito Web che contiene payload, strumenti, documentazione e altro ancora relativi a XSS. Puoi scaricare payload XSS che acquisiscono istantanee da una webcam o persino ottenere una porta e uno scanner di rete più capaci.

Passare a http://MACHINE_IP/ nel browser e fare clic sulla scheda "XSS riflesso" sulla barra di navigazione; crea un payload XSS riflesso che causerà un popup che dice "Ciao".

C'è più di quanto pensi in XSSS
Nella stessa pagina riflettente, crea un payload XSS riflesso che causerà un popup con l'indirizzo IP della tua macchina.

RiflettenteXss4TheWin
Ora vai su http://MACHINE_IP/ nel tuo browser e fai clic sulla scheda "XSS memorizzati" sulla barra di navigazione; fare un conto.

Quindi aggiungi un commento e vedi se riesci a inserire parte del tuo codice HTML.

HTML_T4gs
Nella stessa pagina, crea una finestra popup di avviso visualizzata sulla pagina con i cookie del documento.

W3LL_D0N3_LVL2
Cambia "XSS Playground" in "Sono un hacker" aggiungendo un commento e utilizzando Javascript.

siti_web_possono_essere_facilmente_defaced_with_xss

Vulnerabilità della deserializzazione non sicura

“La deserializzazione non sicura è una vulnerabilità che si verifica quando dati non attendibili vengono utilizzati per abusare della logica di un’applicazione” (Acunetix., 2017)

Questa definizione è ancora piuttosto ampia, per usare un eufemismo. Semplicemente, la deserializzazione non sicura sta sostituendo i dati elaborati da un'applicazione con codice dannoso; consentendo qualsiasi cosa, da DoS (Denial of Service) a RCE (Remote Code Execution), che l'aggressore può utilizzare per prendere piede in uno scenario di pentesting.

Nello specifico, questo codice dannoso sfrutta il legittimo processo di serializzazione e deserializzazione utilizzato dalle applicazioni web. Spiegheremo questo processo e perché è così comune nelle moderne applicazioni web.

OWASP classifica questa vulnerabilità come 8 su 10 per i seguenti motivi:

Bassa sfruttabilità. Questa vulnerabilità viene spesso valutata caso per caso: non esiste uno strumento/un framework affidabile per risolverla. A causa della sua natura, gli aggressori devono avere una buona conoscenza del funzionamento interno del ToE.
L'exploit è tanto pericoloso quanto lo consente l'abilità dell'aggressore, a maggior ragione, il valore dei dati esposti. Ad esempio, qualcuno che può solo causare un DoS renderà l'applicazione non disponibile. L’impatto aziendale di ciò varierà a seconda dell’infrastruttura: alcune organizzazioni si riprenderanno bene, altre, invece, no.

Cos'è vulnerabile?

In sintesi, in definitiva, qualsiasi applicazione che archivia o recupera dati in cui non sono presenti convalide o controlli di integrità per i dati interrogati o conservati. Alcuni esempi di applicazioni di questo tipo sono:

Siti di commercio elettronico
Forum
API
Runtime delle applicazioni (Tomcat, Jenkins, Jboss, ecc.)

Se un cookie avesse il percorso webapp.com/login, quale sarebbe l'URL che l'utente deve visitare?
webapp.com/login
Qual è l'acronimo della tecnologia web su cui funzionano i cookie sicuri?

HTTPS

Attività 25 Bandiere

1° flag (valore del cookie)
THM{good_old_base64_huh}
2° flag (dashboard di amministrazione)

THM{qui_the_admin_flag}

Compito 26 Bandiera

flag.txt
4a69a7ff9fd68

Componenti con vulnerabilità note

Occasionalmente, potresti scoprire che l'azienda/entità su cui stai effettuando il pen-test utilizza un programma che presenta già una vulnerabilità ben documentata.

Ad esempio, supponiamo che un'azienda non aggiorni la propria versione di WordPress da alcuni anni e, utilizzando uno strumento come wpscan, scopri che è la versione 4.6. Alcune rapide ricerche riveleranno che WordPress 4.6 è vulnerabile a un exploit RCE (Remote Code Execution) non autenticato e, ancora meglio, potrete trovare un exploit già realizzato su exploit-db.

Come puoi vedere, ciò sarebbe piuttosto devastante, perché richiede pochissimo lavoro da parte dell'aggressore poiché spesso, poiché la vulnerabilità è già ben nota, qualcun altro ha creato un exploit per la vulnerabilità. La situazione diventa ancora peggiore quando ti rendi conto che è abbastanza facile che ciò accada, se un'azienda perde un singolo aggiornamento per un programma che utilizza, potrebbe essere vulnerabile a un numero qualsiasi di attacchi.

Pertanto, poiché OWASP ha valutato questo valore 3 (che significa alto) nella scala di prevalenza, è incredibilmente facile per un'azienda perdere un aggiornamento per un'applicazione.

Attività 29 Risposte

Quanti caratteri ci sono in /etc/passwd (usa wc -c /etc/passwd per ottenere la risposta)
1611

Registrazione e monitoraggio insufficienti

Quando vengono configurate le applicazioni Web, ogni azione eseguita dall'utente deve essere registrata. La registrazione è importante perché, in caso di incidente, è possibile tracciare le azioni degli aggressori. Una volta tracciate le loro azioni, è possibile determinarne il rischio e l’impatto. Senza la registrazione, non ci sarebbe modo di sapere quali azioni esegue un utente malintenzionato se riesce ad accedere a particolari applicazioni web. Gli impatti maggiori di questi includono:

danno normativo: se un utente malintenzionato ha ottenuto l'accesso alle informazioni personali dell'utente e non vi è alcuna traccia di ciò, non solo vengono colpiti gli utenti dell'applicazione, ma i proprietari dell'applicazione possono essere soggetti a multe o azioni più severe a seconda delle normative.
rischio di ulteriori attacchi: senza registrazione la presenza di un aggressore potrebbe non essere rilevata. Ciò potrebbe consentire a un utente malintenzionato di lanciare ulteriori attacchi contro i proprietari di applicazioni Web rubando credenziali, attaccando l’infrastruttura e altro ancora.
Le informazioni archiviate nei registri dovrebbero includere:

Codici di stato HTTP
Timbri temporali
Nomi utente
Endpoint API/posizioni delle pagine
Indirizzi IP
Questi registri contengono alcune informazioni sensibili, quindi è importante garantire che i registri siano archiviati in modo sicuro e che più copie di questi registri siano archiviate in posizioni diverse.

Come avrai notato, la registrazione è più importante dopo che si è verificata una violazione o un incidente. Il caso ideale è disporre di un monitoraggio per rilevare eventuali attività sospette. Lo scopo di rilevare questa attività sospetta è fermare completamente l'aggressore o ridurre l'impatto che ha avuto se la sua presenza è stata rilevata molto più tardi del previsto. Esempi comuni di attività sospette includono:

più tentativi non autorizzati per una particolare azione (solitamente tentativi di autenticazione o accesso a risorse non autorizzate, ad esempio pagine di amministrazione)
richieste da indirizzi IP o posizioni anomale: sebbene ciò possa indicare che qualcun altro sta tentando di accedere all'account di un particolare utente, può anche avere un tasso di falsi positivi.
utilizzo di strumenti automatizzati: particolari strumenti automatizzati possono essere facilmente identificabili, ad esempio utilizzando il valore delle intestazioni User-Agent o la velocità delle richieste. Ciò può indicare che un utente malintenzionato sta utilizzando strumenti automatizzati.
payload comuni: nelle applicazioni web, è normale che gli aggressori utilizzino payload Cross Site Scripting (XSS). Il rilevamento dell'utilizzo di questi payload può indicare la presenza di qualcuno che conduce test non autorizzati/dannosi sulle applicazioni.
Il semplice rilevamento di attività sospette non è utile. Questa attività sospetta deve essere valutata in base al livello di impatto. Ad esempio, alcune azioni avranno un impatto maggiore rispetto ad altre. È necessario rispondere tempestivamente a queste azioni a impatto più elevato, pertanto dovrebbero sollevare un allarme che attiri l'attenzione della parte interessata.

Metti in pratica queste conoscenze analizzando questo file di registro di esempio.

Quale indirizzo IP sta utilizzando l'aggressore?
49.99.13.16
Che tipo di attacco viene effettuato?

Forza bruta

ProvaHackMe OWASP TOP 10 2021 | Risposte in camera

Guarda le note degli altri utenti. Cos'è la bandiera?

bandiera{cinquequattrotre}

Dai un'occhiata all'app Web. Lo sviluppatore ha lasciato una nota in cui indica che sono presenti dati sensibili in una directory specifica.

Qual è il nome della directory menzionata?

/risorse

Passa alla directory che hai trovato nella domanda uno. Quale file risulta probabile che contenga dati sensibili?

webapp.db

Utilizza il materiale di supporto per accedere ai dati sensibili. Qual è l'hash della password dell'utente amministratore?

6eea9b7ef19179a06954edd0f6c05ceb

Rompi l'hashish.
Qual è la password in chiaro dell'amministratore?

qwertyuiop

Accedi come amministratore. Cos'è la bandiera?

THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

Quale strano file di testo si trova nella directory principale del sito web?

drpepper.txt

Quanti utenti non root/non servizi/non demone ci sono?

Come è impostata la shell dell'utente?

apache

Come è impostata la shell dell'utente?

/sbin/nologin

Quale versione di Alpine Linux è in esecuzione?

3.16.0

Qual è il valore della bandiera nel racconto di Giuseppe?

THM{Not_3ven_c4tz_c0uld_sav3_U!}

Qual è il nome del file del database (quello con estensione .db) nella directory corrente?

cose da fare.db

Modificare il codice per leggere il contenuto del file app.py file, che contiene il codice sorgente dell'applicazione. Qual è il valore del secret_flag variabile nel codice sorgente?

THM{Solo_una_piccola_configurazione}

Qual è il contenuto del file /opt/flag.txt?

THM{But_1ts_n0t_myf4ult!}

Qual è la bandiera che hai trovato nell'account di Darren?

fe86079416a21a3c99937fea8874b667

Qual è la bandiera che hai trovato nel conto di Arthur?

d9ac0f7db4fda460ac3edeb75d75e16e

Di cosa è composto l'hash SHA-256 https://code.jquery.com/jquery-1.12.4.min.js?

sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=

Prova ad accedere all'applicazione come ospite. Qual è la password dell'account ospite?

ospite

Qual è il nome del cookie del sito Web contenente un token JWT?

jwt-session

Qual è il flag presentato all'utente amministratore?

THM{Dont_take_cookies_from_strangers}

Quale indirizzo IP sta utilizzando l'aggressore?

Che tipo di attacco viene effettuato?

Forza bruta

Esplora il sito web. Qual è l'unico host autorizzato ad accedere all'area di amministrazione?

localhost

Seleziona il pulsante "Scarica curriculum". Dove punta il parametro del server?

secure-file-storage.com

Utilizzando SSRF, fai in modo che l'applicazione invii la richiesta al tuo AttackBox anziché all'archiviazione sicura dei file. Sono presenti chiavi API nella richiesta intercettata?

THM{Ciao_Sono_solo_una_chiave_API}

Procedure dettagliate sulla playlist video

CTF Writeups, OWASP, provami

Mostra commenti

Motasem

Circa l'autore

Creo note sulla sicurezza informatica, note di marketing digitale e corsi online. Fornisco anche consulenza di marketing digitale, inclusi ma non limitati a SEO, annunci Google e Meta e amministrazione CRM.

Visualizza articoli

TryHackMe OWASP Top 10 Soluzione 2021-2024 [Aggiornato]

Lascia un commento Annulla risposta

Motasem

Circa l'autore

Altre storie

Vulnerabilità PAC di Windows Active Directory | HackTheBox Mantide

Spiegazione della vulnerabilità Log4j

Premere ESC per chiudere

Lascia un commento Annulla risposta

Motasem

Circa l'autore

Condividi articolo:

Altre storie

Vulnerabilità PAC di Windows Active Directory | HackTheBox Mantide

Spiegazione della vulnerabilità Log4j