De nuevo por aquí... después de una semana de vacaciones en la que he estado apurando una investigación muy prometedora (tengo ganas de contaros, podría llenar unas diez entradas explicando todos los detalles de la investigación y el desarrollo - y los planes de futuro - pero, ya llegará...).
Hoy vengo a terminar de explicaros el asunto del "Data Poisoning".
¡Vamos allá!
Quedaba por explicar los siguientes focos de envenenamiento
- Debido a "ACCEPT"
- Debido al uso de ficheros con múltiples propósitos
- Debido a un mal uso de LINKAGE SECTION
De los tres, el más peliagudo es el primero, ya que un "ACCEPT" puede involucrar interacción con el usuario, y por tanto, puede darse de manera intencionada y/o maliciosa.
Data Poisoning en COBOL por ACCEPT
El comando "ACCEPT" de COBOL sirve para recibir (aceptar) una línea de texto desde el exterior. Un equivalente sería la función "gets()" de C.
Esta instrucción se puede dar principalmente en dos casos:
- En entorno CICS (Screen Section)
- En entorno BATCH
Accept en entorno CICS (Screen Section)
Como ya explicamos hace tiempo, se pueden codificar las pantallas en la WORKING-STORAGE SECTION, para luego obtener todos los datos con ACCEPT.
En este caso, la mayoría de distribuciones de COBOL están preparadas para realizar validaciones automáticamente (por ejemplo, si nuestro PIC es 2(9), no podremos introducir "AB" como valor), pero hay que tener cuidado con las máscaras genéricas (por ejemplo, PIC X(10)).
¿Qué quieres decir con eso?
Sencillo... supongamos que en nuestra pantalla tenemos una variable TELEFONO PIC X(9). ¿Qué nos impide informar "NO TENGO!"? En este caso, la validación corre de parte del desarrollador, y no del propio entorno (podemos, simplemente preguntar IF TELEFONO IS NOT NUMERIC).
Como veis, es posible "colar" datos inesperados, pero el rango de acción es mucho más limitado en este caso.
Accept en entorno BATCH
En este caso, el problema suele venir por descuidos o desconocimiento del entorno BATCH y su sistema de ejecución (JCL - Job Control Language).
En entorno BATCH, el comando ACCEPT sirve para leer una línea de datos de la cola de entrada (que bien puede estar escrito en el mismo JCL, o bien puede existir dentro de un fichero).
El problema está en que cada ACCEPT va a leer exactamente 80 posiciones de texto.
Supongamos que tenemos un fichero con los siguientes datos
----+----1----+---2----+----3----+----4----+----5----+----6----+----7----+----8
Lunes..........................................................................
Monday.........................................................................
01.............................................................................
01.............................................................................
2020...........................................................................
09.............................................................................
00.............................................................................
00.............................................................................
En este caso, tenemos el día de la semana (castellano e inglés), y la fecha (día / mes / año / hora / minuto / segundo).
Cada vez que hagamos "ACCEPT", vamos a obtener una línea del fichero, pero ojo, los 80 caracteres.
¿Qué pasa si nuestra WORKING-STORAGE SECTION no está bien definida?
WORKING-STORAGE SECTION
01 VARIABLES-ACCEPT
05 DIA-SEMANA-CAS PIC X(20).
05 DIA-SEMANA-ENG PIC X(20).
05 DIA PIC X(02).
05 MES PIC X(02).
05 ANYO PIC X(04).
05 HORA PIC X(02).
05 MINUTO PIC X(02).
05 SEGUNDO PIC X(02).
01 CONTADORES
05 CONTADOR-REG PIC 9(09).
Tan pronto como se lea la primera línea y se almacene en DIA-SEMANA-CAS, la variable "CONTADOR-REG" se va a envenenar con LOW-VALUES, y por tanto, si hiciéramos un ADD sobre esa variable sin antes mover un dato, nuestro programa terminaría en error (concretamente un error tipo OC7).
Lo correcto sería hacer lo siguiente
01 VARIABLES-ACCEPT
05 DIA-SEMANA-CAS-ACC.
10 DIA-SEMANA-CAS PIC X(20).
10 FILLER PIC X(60).
[...]
01 CONTADORES
05 CONTADOR-REG PIC 9(09).
Es decir, reservar 80 posiciones para lectura de ACCEPT.
Si vamos más lejos, si nuestro fichero tuviera el siguiente contenido
----+----1----+---2----+----3----+----4----+----5----+----6----+----7----+----8
Lunes..........................................................................
Monday.........................................................................
01.............................................................................
01.............................................................................
2020...........................................................................
09.............................................................................
00.............................................................................
00999999999....................................................................
El último ACCEPT cambiaría el dato de CONTADOR-REG por "999999999".
Data Poisoning en COBOL por Fichero multipropósito
El siguiente caso es poco frecuente, pero merece un pequeño inciso en la entrada.
Debido a varios factores, un fichero puede usarse con varios propósitos (por ejemplo, el fichero del ejemplo anterior).
En este caso, hay que tener muy claro con qué tipo de información se está trabajando, y limpiar siempre correctamente las áreas de trabajo correspondientes.
De no hacerse, podemos estar arrastrando datos del registro anterior en la memoria de WORKING-STORAGE SECTION, y por tanto, estamos envenenando nuestros datos.
Data Poisoning en COBOL por LINKAGE SECTION
Como ya sabréis, la LINKAGE SECTION sirve para comunicar dos componentes COBOL, es un área de memoria compartida.
Es de esperar que tanto el programa emisor como el receptor tengan la misma estructura de variables, ¿verdad?
Pero, ¿y si no la tienen? Pues sencillo... ¡se produce data poisoning!
El principal problema del sistema de comunicación a través de LINKAGE SECTION es que es estático y previo a la compilación, por lo que un cambio en el emisor implica la necesidad de volver a compilar el receptor, y viceversa.
Por tanto, hay que tener muy en cuenta este aspecto y compilar siempre los componentes por grupos de trabajo (es decir, todos aquellos que comparten LINKAGE SECTION); de lo contrario, nos vemos abocados a envenenar nuestros datos de manera involuntaria.
Y, hasta aquí nuestro pequeño monográfico sobre Data Poisoning en COBOL.
Espero que haya sido instructivo, al menos, para demostrar que el hacking en COBOL es posible!
¡Nos vemos!
¿Te han resultado útiles mis conocimientos de COBOL?
¡Llévatelos donde quieras!
No hay comentarios:
Publicar un comentario