Domanda SQLmap non injecta parametro vulnerabile

Cutl4ss

Utente Electrum
25 Giugno 2017
344
10
53
116
Salve, questo è l'output che ricevo:

sqlproblem.JPG


Il parametro "id" è vulnerabile al 100% in quanto testato manualmente. Questo invece è il comando utilizzato per l'injection:

problemsqlmap2.JPG


Ho anche provato ad utilizzare i tamper (nello specifico "unionalltounion", che sostituisce tutte le query UNION ALL SELECT con UNION SELECT), in più ho aggiunto i parametri --prefix="' " e --suffix="-- -" per iniziare e terminare l'iniezione del payload, ma nulla.

Qualcuno può aiutarmi a capire il motivo? Inutile dire che non ci sono WAF, IPS ecc attivi.
 
@PdP_03 in realtà l'apice non è l'unico carattere che potrebbe generare un errore di quel genere.
@Cutl4ss a che livello è settata DVWA?
C'è anche la possibilità di intercettare una richiesta con BurpSuite, salvarla su un file ed utilizzarla con SQLMap, potrebbe essere una buona opzione.
Un' altra cosa che potresti tentare è eliminare il carattere cancelletto (#) dalla fine dell' URL, anche se non credo sia quello il problema.
 
Perchè mai dovresti utilizzare sql map? Allenati a fare una sqli a mano, sqlmap serve ad assai poco, oltretutto se non sbaglio usa solo la timebased sqli che è molto lenta, mentre tu puoi usare la error based e poi usare funzioni sql come order, union select eccetera per dumpare il db
 
Per rispondere a
Perchè mai dovresti utilizzare sql map? Allenati a fare una sqli a mano, sqlmap serve ad assai poco, oltretutto se non sbaglio usa solo la timebased sqli che è molto lenta, mentre tu puoi usare la error based e poi usare funzioni sql come order, union select eccetera per dumpare il db
, posso dire che non e' del tutto vero: sqlmap si basa su injection varie, e non solo blind, dato che nel sito ufficiale e' riportato:
Codice:
Full support for six SQL injection techniques:
boolean-based blind,
time-based blind,
error-based,
UNION query-based,
stacked queries and
out-of-band.
. Saper fare a mano un injection e' sicuramente indispensabile, ma sono sicuro che Cutl4ss gia' le sappia realizzare, e non per nulla ha detto di aver testato manualmente il parametro in questione. Un punto a favore di usare un tool come SqlMap [se si sa' come usarlo correttamente], e' che oltre alle varie opzionalita' che aggiunge e agli strumenti che mette disposizione, a un supporto completo a:
Codice:
Full support for MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, HSQLDB and Informix database management systems.
, dunque, sfido chiunque a conoscere alla perfezione tutte le sintassi SQL di questi db, che sicuramente si assomigliano, ma che in fatto di funzioni, struttura e permessi, discostano molto [basti vedere la differenza tra sqlite/mysql e oracle db ...... quasi un abisso per le funzioni che puoi utilizzare e per la struttura del db].

Ora, non dico di usare solo sqlmap, ma neanche di ammattirsi manualmente: facendolo manualmente si fa' buona pratica, ma imparare ad usare i tools che abbiamo a dispozione, e saperli usare nel modo migliore, e' una carta vincente nel pentesting, soprattutto web.

@PdP_03 in realtà l'apice non è l'unico carattere che potrebbe generare un errore di quel genere.
@Cutl4ss a che livello è settata DVWA?
C'è anche la possibilità di intercettare una richiesta con BurpSuite, salvarla su un file ed utilizzarla con SQLMap, potrebbe essere una buona opzione.
Un' altra cosa che potresti tentare è eliminare il carattere cancelletto (#) dalla fine dell' URL, anche se non credo sia quello il problema.
Il cancelletto in mysql e' l inizio di un commento, ma non va' ad influire sulla query sql mandata al db, quindi non e' assolutamente questo il problema.
Il fatto di usare Burp e' utile nel caso in cui il pacchetto compia una richiesta completa, ma poiche' viene solamente mandato un payload, e' sprecato burp in questa situzione, anche se utilizzandolo manualmente puo' portare alla soluzione del problema che adesso vi spieghero' [quasi sicuramente e' questo infatti che non permette lo scan]:
mi sono ricordato che dvwa usa un login form ...... quindi la pagina, se non usi i cookies della tua sessione che puoi trovare semplicemente vedendo gli headers in risposta alla richiesta da browser con i dev tools [fedelissimi nei test secondo me], in realta' non testi un bel niente.

La struttura del comando dovrebbe essere quindi la seguente: sqlmap -u 'http://192.168.1.102/DVWA-master/vulnerabilities/sqli/?id=67&Submit=Submit#' --cookie="PHPSESSID=<tuo cookie>; security=<livello sicurezza>" -p 'id' --level=5 --risk=3 ...........
Il cookie lo trovi come ti ho detto semplicemente analizzando la richiesta dal browser con i developer tools, e ti basta copiarli nella riga di comando [prendilo tutto ..... anche il security cookie], e avviare lo scan.

Come stai facendo tu invece non riesce proprio a mandare una richiesta completa poiche' non hai effettuato il login nella web app. Tale ipotesi la puoi confermare semplicemente avviando il comando: curl -s 'http://192.168.1.102/DVWA-master/vulnerabilities/sqli/?id=67&Submit=Submit#', che ti riportera' un html che conduce ad un errore o al form di login di dvwa.
 
  • Mi piace
Reazioni: Cutl4ss e HellIn
@Gorate il tuo modo di ragionare mi piace parecchio. Non so quanti anni tu abbia o se già lavori, ma nel caso così non fosse, non avrai assolutamente problemi a trovare il tuo posto. E a tal proposito, ci sono miei ex colleghi che cercano gente in gamba.
 
@Gorate il tuo modo di ragionare mi piace parecchio. Non so quanti anni tu abbia o se già lavori, ma nel caso così non fosse, non avrai assolutamente problemi a trovare il tuo posto. E a tal proposito, ci sono miei ex colleghi che cercano gente in gamba.
Purtroppo ancora non lavoro e mi ci vorra' tanto per arrivare ad una eta' in cui lavorare mi sara' concesso, ma in un campo cosi' giovane sono fiducioso, poi secondo me, si puo' fare il lavoro peggiore al mondo e meno remunerato, ma se ti piace, hai fatto tombola ;)
 
  • Mi piace
Reazioni: 0xbro
I miei complimenti allora. Hai un critical thinking di tutto rispetto e son sicuro che quando arriverà il momento, non avrai problemi nel realizzarti.
 
  • Mi piace
Reazioni: 0xbro
Saper fare a mano un injection e' sicuramente indispensabile, ma sono sicuro che Cutl4ss gia' le sappia realizzare, e non per nulla ha detto di aver testato manualmente il parametro in questione. Un punto a favore di usare un tool come SqlMap [se si sa' come usarlo correttamente], e' che oltre alle varie opzionalita' che aggiunge e agli strumenti che mette disposizione, a un supporto completo a:
Codice:
Full support for MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, HSQLDB and Informix database management systems.
, dunque, sfido chiunque a conoscere alla perfezione tutte le sintassi SQL di questi db, che sicuramente si assomigliano, ma che in fatto di funzioni, struttura e permessi, discostano molto [basti vedere la differenza tra sqlite/mysql e oracle db ...... quasi un abisso per le funzioni che puoi utilizzare e per la struttura del db].

Ora, non dico di usare solo sqlmap, ma neanche di ammattirsi manualmente: facendolo manualmente si fa' buona pratica, ma imparare ad usare i tools che abbiamo a dispozione, e saperli usare nel modo migliore, e' una carta vincente nel pentesting, soprattutto web.
Il punto è che nel pentesting è mille volte meglio documentarsi sulla sintassi di un database che non si conosce piuttosto che lasciare fare ai tools, questo per svariati motivi, il primo è ovviamente che si impara qualcosa di nuovo, il secondo è che sqlmap non sempre è preciso al 100%, così come qualsiasi altro tool (OWASP ZAP, nikto, etc..), mentre invece con una certa esperienza si può trovare fin da subito un problema, anche magari non legato all'sqli/xss/lfi/qualsiasi tipo di injection, basta pensare a quanti exploit non derivano da problemi di sicurezza di questo tipo, per esempio Verge (una criptovaluta) è stata "hackerata" perchè il tempo da aspettare per la creazione di un nuovo blocco era gestito male, in fine rimanendo in parte legati al primo motivo, documentandosi e facendo le cose "manualmente", se in un futuro ti ritrovi davanti ad un problema simile potresti riuscire a risolverlo, magari documentandoti ancora di più o facendo dei "test".

Non dico che sia sbagliato usare dei tools, dico solo che non sono la soluzione migliore se si vuole imparare, personalmente preferisco imparare la sintassi anche se in modo minimale di 20 strutture di database diversi piuttosto che imparare un tool che fa le cose da se, può sembrare controproducente ma le nozioni voglio che siano nella mia testa e non dentro un codice scritto da qualcun'altro, se non conosco la sintassi di postgres mi documento, così come quella di qualsiasi altro linguaggio sql, il pentesting consiste (a mio parere) nel sapere quel qualcosina di più che ti porta a poter sfruttare gli errori degli altri per raggiungere obbiettivi dei quali non era previsto il raggiungimento.

Ho due CVE sul mitre, pur quanto non siano di grossa importanza posso dire che ci sono, ho fatto non so quante sqli, ho trovato diverse falle pur quanto magari non dentro sistemi di grossa portata e, sinceramente, non so usare sqlmap ne nikto, ho usato qualche volta owasp zap ma alla fine di quegli scan per lo più incontravo solo falsi positivi. La premessa non l'ho fatta per tirarmela (non sono nessuno) bensì per far capire che i tool in fondo non servono ed anzi, se usati in modo incosciente, portano all'ignoranza, è un po' come una maratona dove ti catapulti al traguardo senza avere idea di come fosse il percorso.

Riassumendo il mio discorso, se sai farlo a mano fallo a mano, se non sai farlo a mano impara a farlo. Poi vabbè se sai farlo a mano ma vuoi capire come funziona sqlmap fai pure, ma una volta che lo sai fare senza bisogno di tools non vedo perchè dovresti usarli
 
Il punto è che nel pentesting è mille volte meglio documentarsi sulla sintassi di un database che non si conosce piuttosto che lasciare fare ai tools, questo per svariati motivi, il primo è ovviamente che si impara qualcosa di nuovo, il secondo è che sqlmap non sempre è preciso al 100%, così come qualsiasi altro tool (OWASP ZAP, nikto, etc..), mentre invece con una certa esperienza si può trovare fin da subito un problema, anche magari non legato all'sqli/xss/lfi/qualsiasi tipo di injection, basta pensare a quanti exploit non derivano da problemi di sicurezza di questo tipo, per esempio Verge (una criptovaluta) è stata "hackerata" perchè il tempo da aspettare per la creazione di un nuovo blocco era gestito male, in fine rimanendo in parte legati al primo motivo, documentandosi e facendo le cose "manualmente", se in un futuro ti ritrovi davanti ad un problema simile potresti riuscire a risolverlo, magari documentandoti ancora di più o facendo dei "test".

Non dico che sia sbagliato usare dei tools, dico solo che non sono la soluzione migliore se si vuole imparare, personalmente preferisco imparare la sintassi anche se in modo minimale di 20 strutture di database diversi piuttosto che imparare un tool che fa le cose da se, può sembrare controproducente ma le nozioni voglio che siano nella mia testa e non dentro un codice scritto da qualcun'altro, se non conosco la sintassi di postgres mi documento, così come quella di qualsiasi altro linguaggio sql, il pentesting consiste (a mio parere) nel sapere quel qualcosina di più che ti porta a poter sfruttare gli errori degli altri per raggiungere obbiettivi dei quali non era previsto il raggiungimento.

Ho due CVE sul mitre, pur quanto non siano di grossa importanza posso dire che ci sono, ho fatto non so quante sqli, ho trovato diverse falle pur quanto magari non dentro sistemi di grossa portata e, sinceramente, non so usare sqlmap ne nikto, ho usato qualche volta owasp zap ma alla fine di quegli scan per lo più incontravo solo falsi positivi. La premessa non l'ho fatta per tirarmela (non sono nessuno) bensì per far capire che i tool in fondo non servono ed anzi, se usati in modo incosciente, portano all'ignoranza, è un po' come una maratona dove ti catapulti al traguardo senza avere idea di come fosse il percorso.

Riassumendo il mio discorso, se sai farlo a mano fallo a mano, se non sai farlo a mano impara a farlo. Poi vabbè se sai farlo a mano ma vuoi capire come funziona sqlmap fai pure, ma una volta che lo sai fare senza bisogno di tools non vedo perchè dovresti usarli
Come concetto e' giusto, e sinceramente neanche io so' come usare sqlmap, semplicemente ho fatto 2+2, ho guardato il contenuto ritornato dall opzione help e ho aggiunto il cookie [che se @Cutl4ss ha provato puo' dirci o meno se funziona].
Ora, e' sicuramente sempre importante capire come lavora un tool e sono d accordissimo con il tuo punto di vista, nel senso che la ricerca di vuln va' fatta manualmente [mentre per il recon io mi affido solamente a tools che mi programmo], ed e' sicuramente vero [testato e provato], che sqlmap non sempre e' certo al 100%, e' ovvio che injectando molti payloads e' facile essere intercettati da eventuali WAF o IDS, e ancora, untraffico del genere non fa' certamente bene al povero sever lol.
Ma le funzionalita' che offre in alcuni contesti sono molto interessanti, e spaziano al di la' della possibilita' di qualcuno di imparare tutte quelle sintassi SQL di cui non si conoscera' mai tutto, e di cui [se non sono presenti gli errori stessi], potrebbero riportarci a conclusioni affrettate.
Inoltre, almeno per me, se devo impararmi un linguaggio con molte espressioni, come mysql o oracle db [che conosco,quindi vado sul sicuro], devo praticare molto tempo e se lo lascio, poi devo ritornarci sopra svariate volte. Ora, tutto questo lavoro manuale, finche' si usano sintassi che si padroneggiano bene, e' piu' che ottimale, ma se dovessi adottare "qualcosaSQL" [esempio di uno dei tanti sql syntax che non conosco], che non usero' mai piu' nella mia vita, preferisco affidarmi al tool, magari provando anche manualmente, ma senza andare troppo a fondo. Ora, so' bene che quello che ho detto e' un insulto a tutti i bug hunter e vuln finder, il cui motto e' "dig depper", ma un target presenta molti aspetti da testare, e' perdere tutto questo tempo per una sql inj, non e' proprio il massimo mettendo in conto le varie difese all interno del server che sicuramente limitano accesso e permessi.

Ora, un punto per usare sqlmap, e' ad esempio il supporto all out-of-band, che da fare manualmente sarebbe veramente un casino enorme: apri il server dns, trova una macchina remote, port forwarding, query specifiche ...... tutte cose che fanno perdre tempo, ma che puoi usare su sqlmap autonomamente e indipendentemente dall esecuzione di uno scan.
O ancora, le tecniche di evasione di WAF sono migliaia, e avere raccolte in un tool che le usa, e' sicuramente un buon punto da cui riprendere un test manualmente, ma senza andare alla cieca.

Pero' sono pienamente d' accordo con te: se si ha la possibilita' e le conoscenze per farlo manualmente, meglio farlo in tale modo.
 
Per rispondere a

, posso dire che non e' del tutto vero: sqlmap si basa su injection varie, e non solo blind, dato che nel sito ufficiale e' riportato:
Codice:
Full support for six SQL injection techniques:
boolean-based blind,
time-based blind,
error-based,
UNION query-based,
stacked queries and
out-of-band.
. Saper fare a mano un injection e' sicuramente indispensabile, ma sono sicuro che Cutl4ss gia' le sappia realizzare, e non per nulla ha detto di aver testato manualmente il parametro in questione. Un punto a favore di usare un tool come SqlMap [se si sa' come usarlo correttamente], e' che oltre alle varie opzionalita' che aggiunge e agli strumenti che mette disposizione, a un supporto completo a:
Codice:
Full support for MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, HSQLDB and Informix database management systems.
, dunque, sfido chiunque a conoscere alla perfezione tutte le sintassi SQL di questi db, che sicuramente si assomigliano, ma che in fatto di funzioni, struttura e permessi, discostano molto [basti vedere la differenza tra sqlite/mysql e oracle db ...... quasi un abisso per le funzioni che puoi utilizzare e per la struttura del db].

Ora, non dico di usare solo sqlmap, ma neanche di ammattirsi manualmente: facendolo manualmente si fa' buona pratica, ma imparare ad usare i tools che abbiamo a dispozione, e saperli usare nel modo migliore, e' una carta vincente nel pentesting, soprattutto web.


Il cancelletto in mysql e' l inizio di un commento, ma non va' ad influire sulla query sql mandata al db, quindi non e' assolutamente questo il problema.
Il fatto di usare Burp e' utile nel caso in cui il pacchetto compia una richiesta completa, ma poiche' viene solamente mandato un payload, e' sprecato burp in questa situzione, anche se utilizzandolo manualmente puo' portare alla soluzione del problema che adesso vi spieghero' [quasi sicuramente e' questo infatti che non permette lo scan]:
mi sono ricordato che dvwa usa un login form ...... quindi la pagina, se non usi i cookies della tua sessione che puoi trovare semplicemente vedendo gli headers in risposta alla richiesta da browser con i dev tools [fedelissimi nei test secondo me], in realta' non testi un bel niente.

La struttura del comando dovrebbe essere quindi la seguente: sqlmap -u 'http://192.168.1.102/DVWA-master/vulnerabilities/sqli/?id=67&Submit=Submit#' --cookie="PHPSESSID=<tuo cookie>; security=<livello sicurezza>" -p 'id' --level=5 --risk=3 ...........
Il cookie lo trovi come ti ho detto semplicemente analizzando la richiesta dal browser con i developer tools, e ti basta copiarli nella riga di comando [prendilo tutto ..... anche il security cookie], e avviare lo scan.

Come stai facendo tu invece non riesce proprio a mandare una richiesta completa poiche' non hai effettuato il login nella web app. Tale ipotesi la puoi confermare semplicemente avviando il comando: curl -s 'http://192.168.1.102/DVWA-master/vulnerabilities/sqli/?id=67&Submit=Submit#', che ti riportera' un html che conduce ad un errore o al form di login di dvwa.

Si, in effetti è molto probabile che il problema sia l'assenza di qualsivoglia cookie (cosa effettivamente ovvia e me ne vergogno a non averci pensato ahah). In ogni caso, in una molto vecchia versione di SQLMap, il cancelletto veniva considerato come un carattere chiave per non ricordo quale operazione, questo è perché ho supposto potesse dipendere da quello; purtroppo SQLMap l'ho utilizzato veramente molto poco pertanto non so come funzioni ora.
 
Come concetto e' giusto, e sinceramente neanche io so' come usare sqlmap, semplicemente ho fatto 2+2, ho guardato il contenuto ritornato dall opzione help e ho aggiunto il cookie [che se @Cutl4ss ha provato puo' dirci o meno se funziona].
Ora, e' sicuramente sempre importante capire come lavora un tool e sono d accordissimo con il tuo punto di vista, nel senso che la ricerca di vuln va' fatta manualmente [mentre per il recon io mi affido solamente a tools che mi programmo], ed e' sicuramente vero [testato e provato], che sqlmap non sempre e' certo al 100%, e' ovvio che injectando molti payloads e' facile essere intercettati da eventuali WAF o IDS, e ancora, untraffico del genere non fa' certamente bene al povero sever lol.
Ma le funzionalita' che offre in alcuni contesti sono molto interessanti, e spaziano al di la' della possibilita' di qualcuno di imparare tutte quelle sintassi SQL di cui non si conoscera' mai tutto, e di cui [se non sono presenti gli errori stessi], potrebbero riportarci a conclusioni affrettate.
Inoltre, almeno per me, se devo impararmi un linguaggio con molte espressioni, come mysql o oracle db [che conosco,quindi vado sul sicuro], devo praticare molto tempo e se lo lascio, poi devo ritornarci sopra svariate volte. Ora, tutto questo lavoro manuale, finche' si usano sintassi che si padroneggiano bene, e' piu' che ottimale, ma se dovessi adottare "qualcosaSQL" [esempio di uno dei tanti sql syntax che non conosco], che non usero' mai piu' nella mia vita, preferisco affidarmi al tool, magari provando anche manualmente, ma senza andare troppo a fondo. Ora, so' bene che quello che ho detto e' un insulto a tutti i bug hunter e vuln finder, il cui motto e' "dig depper", ma un target presenta molti aspetti da testare, e' perdere tutto questo tempo per una sql inj, non e' proprio il massimo mettendo in conto le varie difese all interno del server che sicuramente limitano accesso e permessi.

Ora, un punto per usare sqlmap, e' ad esempio il supporto all out-of-band, che da fare manualmente sarebbe veramente un casino enorme: apri il server dns, trova una macchina remote, port forwarding, query specifiche ...... tutte cose che fanno perdre tempo, ma che puoi usare su sqlmap autonomamente e indipendentemente dall esecuzione di uno scan.
O ancora, le tecniche di evasione di WAF sono migliaia, e avere raccolte in un tool che le usa, e' sicuramente un buon punto da cui riprendere un test manualmente, ma senza andare alla cieca.

Pero' sono pienamente d' accordo con te: se si ha la possibilita' e le conoscenze per farlo manualmente, meglio farlo in tale modo.
Per quanto riguarda l'OOB sinceramente non l'avevo mai sentita (in questi giorni mi documenterò meglio), comunque per lo WAF bypass non è il massimo usare sqlmap, manualmente puoi trarre conclusioni più certe su che WAF usano e su come poterlo bypassare, anche magari documentandosi online.

Per quanto riguarda il "qualcosaSQL" che non userai mai più nella tua vita, se effettivamente fosse così (cioè che non lo usi più) andrebbe bene usare un tool, ma il punto è che non puoi saperlo, potresti ritrovartelo davanti tutti i giorni così dal nulla, dovendo quindi imparare la sua sintassi per capire come arrivare ad una vulnerabilità.

Poi penso sia sempre bello imparare cose nuove, se dovessimo smettere di imparare la sicurezza informatica diventerebbe noiosa :)
 
Aggiungo qualcosa legata all'esperienza lavorativa, visto che avete tutti detto cose molto giuste:

dipende spesso dal tipo di engagement con cui si ha a che fare. L'approccio utilizzato per un white box di un applicativo web è totalmente differente da un black-box pentesting di un'architettura infrastrutturale o da un semplice vulnerability assessment. Lo scope detta l'approccio; nel primo caso, l'analisi meticolosa è d'obbligo, perchè tool automatici possono generare falsi positivi o, ancora peggio, falsi negativi. Inoltre, ci sarebbe tutto un discorso da fare legato alla logica dell'applicativo, che non può essere analizzata con dei tool automatici.

Detto questo, le tipologie di encoding, evasion, injection e chi più ne ha più ne metta sono davvero troppe e non a caso nei team in cui mi è capitato di lavorare avevano persone dedicate ad ogni tipo di tecnologia / analisi; se non ho a disposizione tali persone e la mole di lavoro diventa troppa, oltre ad esserci un grosso problema di business, i tool automatici salvano tempo, cattivo sangue e denaro, in un certo senso.
 
  • Mi piace
Reazioni: WarCrimeLover69
Aggiungo qualcosa legata all'esperienza lavorativa, visto che avete tutti detto cose molto giuste:

dipende spesso dal tipo di engagement con cui si ha a che fare. L'approccio utilizzato per un white box di un applicativo web è totalmente differente da un black-box pentesting di un'architettura infrastrutturale o da un semplice vulnerability assessment. Lo scope detta l'approccio; nel primo caso, l'analisi meticolosa è d'obbligo, perchè tool automatici possono generare falsi positivi o, ancora peggio, falsi negativi. Inoltre, ci sarebbe tutto un discorso da fare legato alla logica dell'applicativo, che non può essere analizzata con dei tool automatici.

Detto questo, le tipologie di encoding, evasion, injection e chi più ne ha più ne metta sono davvero troppe e non a caso nei team in cui mi è capitato di lavorare avevano persone dedicate ad ogni tipo di tecnologia / analisi; se non ho a disposizione tali persone e la mole di lavoro diventa troppa, oltre ad esserci un grosso problema di business, i tool automatici salvano tempo, cattivo sangue e denaro, in un certo senso.
Sul piano lavorativo sono d'accordissimo sul fatto che usare tools salvi del tempo, dico solo che, quando possibile, è sempre meglio espandere le proprie conoscenze, soprattutto se si è alle prime armi e si sta facendo dei test in locale per capire come funzionano le cose.

Diciamo che, finchè ti approcci al mondo del pentesting in modo didattico, è sempre meglio non usare tools, in quanto si imparano ad usare in molto meno tempo rispetto a quello che ci si mette a capire come funzionano davvero le cose, altro motivo per cui purtroppo (e per certi versi per fortuna) non può esistere un manuale ne un corso che ti insegna ad "hackerare", questo soprattutto per l'immensa vastità di tecnologie, linguaggi, strutture di dati, protocolli, algoritmi di crittografia eccetera, non conoscendo in modo avanzato ciascuno di questi non si può pensare di trovare una vulnerabilità nel processo/implementazione del codice. Per esempio se uno non conosce come funziona un include su php, come funzionano i filter per l'include e come funziona in generale la gestione delle cartelle, non potrà mai capire come effettuare un LFI, o comunque come poter leggere il codice di un file php dove c'è l'input di un include in mano all'utente, allo stesso modo in cui non si può capire come funziona una SQLi se non si sa come funziona un server SQL e come fa php/python/C/qualsiasi linguaggio a collegarcisi.

Appunto per questi motivi a parer mio finchè non si entra nel mondo del lavoro non ha senso affidarsi ai tools, eccetto per alcuni casi tipo il wifi hacking e il port scanning, dove il tool effettivamente velocizza processi lunghi o, come nel primo caso, abbastanza complicati da fare a mano, senza generare falsi positivi/negativi, in quel caso invece do il pieno appoggio ad usare aircrack/nmap in quanto usandoli non ottenete nulla di possibilmente diverso o discordante da quello che potreste fare a mano (eccetto magari per il riconoscimento dell'OS).

In sostanza reputo che esista una sottospecie di "processo logico" per capire se conviene usare un tool nel processo didattico o fare le cose a mano, la prima domanda da farsi è sicuramente "Posso ottenere risultati diversi facendo le cose a mano?", se la risposta è sì dobbiamo capire quanto degli ipotetici risultati trovati senza tool discostano da quelli trovabili col tool, per poi domandarci "Lo so fare a mano?", se entrambe le risposte sono positive è meglio farlo a mano, se lo è solo la prima bisogna a quel punto studiare per capire come fare (se si è in un ambiente puramente didattico e non lavorativo, o comunque in un ambiente lavorativo dove l'idea di studiare è accettata e non si hanno scadenze "brevi"). Riassumo in una breve scaletta


Codice:
(Scaletta pensata per un processo didattico)

Posso ottenere risultati diversi facendo le cose a mano?

No --> Usa un tool

Sì --> Lo so fare?

          Sì --> Fallo a mano

          No --> Studia come si fa
 
Purtroppo ancora non lavoro e mi ci vorra' tanto per arrivare ad una eta' in cui lavorare mi sara' concesso, ma in un campo cosi' giovane sono fiducioso, poi secondo me, si puo' fare il lavoro peggiore al mondo e meno remunerato, ma se ti piace, hai fatto tombola ;)

Purtroppo ancora non lavoro e mi ci vorra' tanto per arrivare ad una eta' in cui lavorare mi sara' concesso, ma in un campo cosi' giovane sono fiducioso, poi secondo me, si puo' fare il lavoro peggiore al mondo e meno remunerato, ma se ti piace, hai fatto tombola ;)
Quanti hanni hai, sul serio. Perchè se ti aggiri intorno ai 14-15 (i miei) mi sparo
 
Ultima modifica:
Hai indovinato a prima botta ..., sono 14enne, tra un mese 15enne lol

Ora, getta la pistola che senno' perdiamo un utente attivo ;)
No, no, non ci posso credere. Come fai a sapere tutte ste cose pls. Insegnamelo ti prego.
Messaggio unito automaticamente:

più che altro non riesco a visualizzare nulla del tuo profilo
 
No, no, non ci posso credere. Come fai a sapere tutte ste cose pls. Insegnamelo ti prego.
Messaggio unito automaticamente:

più che altro non riesco a visualizzare nulla del tuo profilo
Allora, premesso che stiamo andando off topic .... quindi meglio smetterla, e che se visualizzassi il mio profilo vedresti ben altre informazioni [dato che condividevo l account con un amico che fa' gia' l universita' e che ha creato il profilo con i propri dati], non so' nulla di trascendentale, anzi sono ben piu' ignorante di molti altri.

Insegnare non si puo' perche' l informatica e' come uno sport: non posso insegnarti a mettere KO qualcuno, posso consigliarti [come su forum], come applicare una determinata tecnica, come migliorare la tua performance, ma per questo c'e' il forum, ed e' pieno ;)
Il grande devi farlo tu, programmando, sfidando te stesso e gli altri, leggendo manuali e reperendo materiale da Google, che ne e' pieno.
 
  • Mi piace
Reazioni: MasterPlo
Allora, premesso che stiamo andando off topic .... quindi meglio smetterla, e che se visualizzassi il mio profilo vedresti ben altre informazioni [dato che condividevo l account con un amico che fa' gia' l universita' e che ha creato il profilo con i propri dati], non so' nulla di trascendentale, anzi sono ben piu' ignorante di molti altri.

Insegnare non si puo' perche' l informatica e' come uno sport: non posso insegnarti a mettere KO qualcuno, posso consigliarti [come su forum], come applicare una determinata tecnica, come migliorare la tua performance, ma per questo c'e' il forum, ed e' pieno ;)
Il grande devi farlo tu, programmando, sfidando te stesso e gli altri, leggendo manuali e reperendo materiale da Google, che ne e' pieno.
c'è un posto in cui possiamo scrivere in pace?
 
c'è un posto in cui possiamo scrivere in pace?
Contattami in privato se devi dirmi qualcosa, ma in linea di massima sono un po' come Stefano, nel senso che preferisco che le cose vengano dette sul forum [se ci sono domande], se invece e' per chiacchierare pvt va' bene

@Stefano Novelli ho un problema con il rilascio di una release , ti ho scritto sul profilo.