Esta vez quiero
mostrar cómo determinar si los ataques de privilegio de Java se han producido
en su base de datos, tanto como medida de precaución como para el análisis
forense después del incidente, con el fin de verificar si un ataque de esta
naturaleza ha ocurrido o no.
En primer lugar veamos la situación en la que un atacante utiliza DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY para concederse a sí mismos cualquier privilegio Java de CREATE SESSION debido a ejecutar DBMS_JVM_EXP_PERMS.
Si su base de datos está recogiendo mensajes de error a continuación, busca errores del tipo ORA-29532:
SQL> DECLARE
2 POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
3 CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','$','execute',
'ENABLED' FROM DUAL;
BEGIN
OPEN C1;
4 5 FETCH C1 BULK COLLECT INTO POL;
6 CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
7 8 END;
9 / 10
DECLARE
*
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception:
java.lang.SecurityException: policy table update java.lang.RuntimePermission,
loadLibrary.*
ORA-06512: at "SYS.DBMS_JVM_EXP_PERMS", line 189
ORA-06512: at line 8
La escalada de
privilegios aún ha tenido éxito por lo que el mensaje de error es un poco
engañoso, pero podría ser un indicador útil.
SQL> SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST'; TYPE_NAME -------------------------------------------------------------------------------- NAME -------------------------------------------------------------------------------- ACTION -------------------------------------------------------------------------------- java.io.FilePermissionVamos a centrarnos en la identificación de la escalada de privilegios de Java.$ execute
Una vez que se han asignado privilegios de Java existen múltiples formas de utilizar el privilegio de ganar SYSDBA, y una vez adquirido, el atacante tendría limpiar el rastro que habían dejado atrás, primero instalando un rootkit, y luego revocar privilegios y eliminando las cuentas que se crearon en el camino.
Así, el reto de un investigador forense es buscar pistas que un atacante puede no haber sido lo suficientemente diligente para limpiar.
Así, en primer lugar, ¿cómo podemos saber si un usuario se ha concedido privilegios Java? DBA_JAVA_POLICY es la vista fundamental, y esto muestra amablemente todos los privilegios concedidos por orden cronológico de Java utilizando el número de secuencia de incrementar…
SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST'; TYPE_NAME -------------------------------------------------------------------------------- NAME -------------------------------------------------------------------------------- ACTION -------------------------------------------------------------------------------- java.io.FilePermission ALL FILES executeAsí que si un atacante sabe esto, es probable que ha ga drop de a cuenta de ataque y lo recrea si es necesario como parte de un ataque posterior. Sin embargo, si nos fijamos en la tabla base sys.java $ policy $ para la vista DBA_JAVA_POLICY, veremos que la tabla realmente persiste en las concesiones de Java, incluso después de que el usuario haya sido eliminado !!! Esto es útil para una investigación posterior a incidentes.
SELECT * FROM sys.java$policy$ ORDER BY key DESC;
KIND# GRANTEE# TYPE_SCHEMA# TYPE_NAME NAME ACTION STATUS# KEY
-----------------------------------------------------------------------------------------------------
0 101 0 java.io.FilePermission ALL FILES execute 2 282
0 100 0 java.io.FilePermission ALL FILES execute 2 262
0 54 0 java.io.FilePermission ALL FILES execute 2 242
--Note that the GRANTEE# correlates to the sys.user$.USER# column and we can see
-- that user 101 and 100 both had execute on ALL FILE
-- ,but these users no longer exist in sys.user$ and still the privs are recorded in sys.java$policy$ ~which could be very useful info..
SQL> select name from sys.user$ where user# in (101, 100);
no rows selected
SQL> select name from sys.user$ where user# in (54);
NAME
------------------------------
SCOTT
--Of course a clever attacker that had gained SYS could delete from the base table..
SQL> delete from sys.java$policy$ where key='242';
1 row deleted.
SQL> commit;
Commit complete.
--And the evidence of the escalation has gone.. How would an investigator see that the table had been modified in this case?
--Tracing back further it would hopefully be possible to use the dba_tab_modifications view:
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$'
2 ;
no rows selected
--This empty result set is due to the fact that MONITORING is not set on this table by default. This could be rectified as follows in this example.
SQL> exec dbms_stats.gather_table_stats ('SYS','JAVA$POLICY$');
PL/SQL procedure successfully completed.
SQL> delete from sys.java$policy$ where key='282';
0 rows deleted.
SQL> delete from sys.java$policy$ where key='242';
1 row deleted.
SQL> execute dbms_stats.flush_database_monitoring_info;
PL/SQL procedure successfully completed.
SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$';
TABLE_OWNER TABLE_NAME PARTITION_NAME SUBPARTITION_NAME INSERTS UPDATES DELETES TIMESTAMP TRU DROP_SEGMENTS
------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------- ----------
SYS JAVA$POLICY$ 0 0 1 31-MAR-10 NO 0
--It is unlikely that a DB will have had this default setting changed beforehand though..
--So what else can be done to see if the DBA_JAVA_POLICY table has been changed recently?
SQL> select scn_to_timestamp(Max(ora_rowscn)) from sys.java$policy$;
SCN_TO_TIMESTAMP(MAX(ORA_ROWSCN))
-----------------------------------------------------
30-MAR-10 06.10.06.000000000 PM
Nota: esta consulta normalmente trabajará hasta 7 días después de que el cambio haya ocurrido, por lo que si obtiene este error ORA-08181 la tabla probablemente no ha tenido comandos de manipulación de datos (DML) en él durante ese tiempo.
ORA-08181: specified number is not a valid system change number
