Resumen— Este documento pretende ser una guía para todos

quienes hagan uso del sistema operativo Linux en especial para los

que trabajan en Seguridad Informática utilizando la versión Kali

Linux. Este documento corresponde a un manual que orienta al

lector acerca sobre Criptografía. El documento contiene algunas

imágenes y conceptos del proceso de encriptación, utilización de

firmas digitales, md5 claves privadas y públicas, también se

muestran imágenes de la vulnerabilidad de las contraseñas al

poderlas descifrar con un script que emplea openssl y con

herramientas que posee Kali Linux como es Jhon The Ripper.

Palabras clave— Máquina Virtual, Sistema Operativo,

Hardware, Software, Autenticación, Claves, firmas digitales,

script, md5, hash, salt, vulnerabilidad

Abstract— This document is intended as a guide for all those

who use the Linux operating system especially for those

working in Information Security Kali using the Linux version.

This document pertains to a manual that guides the reader

about on Cryptography. The document contains some images

and concepts of the encryption process, using digital signatures,

md5 private and public keys, pictures of the vulnerability of

passwords are also shown by taking them decipher a script that

uses openssl and tools that owns Kali Linux Jhon The Ripper.

Keywords— Virtual machine, Operating system, Hardware,

Software, Authentication, keys, digital signatures, script, md5, hash,

salt, vulnerability

I. INTRODUCCIÓN

os numerosos riesgos inmersos no solo en la gran red de

redes, Internet, sino en las mismas redes domésticas y/o

empresariales, hacen necesario adoptar mecanismo de

“protección” para garantizar en la medida de lo posible, la

confidencialidad de la información, uno de los tres grandes

pilares de la seguridad de la información.

Una de las medidas que se pueden adoptar es el empleo de la

criptografía, herramienta que permite evitar que cuando un

intruso intercepte de alguna forma los datos de una víctima,

este no pueda leer la información, ni la pueda manipular

posteriormente de acuerdo con su conveniencia.1

La protección que deben proporcionarle los administradores a

estos medios de almacenamiento, debe garantizar que la

información tenga los principios de seguridad de la información

los cuales son:

Integridad: la cual permite garantizar que los datos no han sido

modificados por personas ajenas a la entidad.

Confidencialidad: este principio permite no develar los datos a

usuarios no autorizados, es decir, la privacidad de la

información (protección de datos) y el principio de

Disponibilidad: que garantiza que la información debe estar

accesible a los usuarios autorizados en el momento que lo

requieran.

II. DESARROLLO DEL ARTÍCULO

Cabe destacar que se deberán leer y comprender las

referencias requeridas para identificar el problema presentado

en la actividad referente a firma digital y ataques de

diccionarios.

III. DISEÑO Y CONSTRUCCIÓN

Archivos descargados, figura 1.

Fig. 1 Archivos descargados

Fuente: los autores

Diseño y Construcción de trabajo del curso

“Criptografía”

L

Jaime Henao, Luis Ardila, Fabio Castro, Amaury Gamarra, Jaider Contreras

Escuela de Ciencias Básicas Tecnología e Ingeniería

Colombia

jhhenao@gmail.com, fabies79@hotmail.com, jaider.contreras@gmail.com,

amauryg77@gmail.com

Universidad Nacional y a Distancia “UNAD”

Escuela de Ciencias Básicas, Tecnología e Ingeniería

Colombia

2

Verificamos el contenido del archivo: archivo_z.ps, fig. 2.

Fig. 2 archivo_z. ps

Fuente: Los autores

Verificamos el contenido del archivo: archivo_y.ps, fig. 3.

Fig. 3 archivo_y. ps

Fuente: Los autores

IV. GENERACION DE FIRMA DIGITAL DE UN

ARCHIVO

Lo primero es generar la llave rsa de 2048 privada, después

se procede a generar la llave pública por medio de la llave

privada. Y con las opciones expresadas en el protocolo,

generamos el archivo ver figuras: 4 y 5.

Fig. 4 Generación de llave privada

Fuente: Los autores

Fig. 5 Llave Privada

Fuente: Los autores

Ahora generamos la llave pública, figuras 6 y 7.

Fig. 6 Llave Pública

Fuente: Los autores

Fig. 7 Llave Pública

Fuente: Los autores

Ahora bien procedemos a generar la firma del archivo con

salida a otro archivo llamado firma_archivo_y.txt. Para ello

mostramos los archivos localizados y generados con openssl,

figuras: 8 y 9.

3

Fig. 8 Generación de firma

Fuente: Los autores

Fig. 9 Firma generada

Fuente: Los autores

Podemos observar que la información ha sido modificada por

medio del algoritmo RSA, figuras: 10 y 11.

Fig. 10 Información Encriptada

Fuente: Los autores

Fig. 11 Archivo visto desde el editor gedit

Fuente: Los autores

Después procedemos a verificar el resultado por medio de la

llave pública y la encriptación md5. Verificamos que tanto el

archivo firma_archivo_y.txt como el archivo_z.ps sean los

mismos.

Fig. 12 Archivo visto desde el editor gedit

Fuente: Los autores

Qué Resultados obtuvieron en este proceso de firma

Digital? ¿Esto sí debería suceder o ser posible?

Se crearon un par de claves: una privada y una pública; para

firmar documentos.

¿Qué firmaron realmente en el proceso que se llevó a cabo?

Se firmó el archivo_y.ps y se generó el archivo

firma_archivo_y.txt correspondiente a la firma digital del

archivo_y.ps. Con el proceso de firma digital: se aplicó una

función hash que se encarga de hacer un resumen del contenido

del documento, para luego realizar el cifrado con la clave

privada del usuario.

¿Por qué obtuvieron dicho resultado? ¿Cuál es la debilidad

en el sistema de firma digital OpenSSL?

Se generó un archivo con la firma digital utilizando el hash

criptográfico MD5 para el archivo_y.ps, pero al verificar el

archivo de la clave se utilizó el archivo_z.ps y dando como

resultado OK. Esta es una demostración de una vulnerabilidad

del cálculo del hash dentro del proceso de firmado, que se puede

verificar con la función md5sum, figura 13.

Esta vulnerabilidad se denomina como ataque de colisión hash,

en realidad es un error en la forma en que MD5 calcula el hash,

pero como openssl usa esa función allí es donde vemos el error.

Este consiste en la creación de dos archivos diferente en

contenido pero que tengan el mismo valor hash firmado, para

aprovecharse de esta circunstancia y utilizar la firma sobre el

segundo mensaje, no se sabe con qué intensión.

Fig. 13 Información Encriptada

Fuente: Los autores

V. SEGURIDAD DE CONTRASEÑAS

Utilizaremos un script que se relacionará en el aula virtual.

Este script tiene una característica que permite realizar un

ataque de fuerza bruta para encontrar contraseñas.

Descargamos y mostramos el scrip, para poder realizar la

decriptación de las contraseñas offline, para ello utilizamos, la

descarga y la revisión del script, figura 14

4

Fig. 14 script descargado

Fuente: Los autores

Verificamos el contenido del archivo script, figura 15.

Fig. 15 Contenido del archivo script

Fuente: Los autores

Ahora utilizamos el script con el alfabeto 1, pero antes

debemos asignar privilegios plenos pues si no se realiza este

paso se genera error de acceso denegado, figura 16.

Fig. 16 Asignación privilegios plenos

Fuente: Los autores

En la figura 16 también se muestra como queda des-encriptada

la primera clave o el hash.

En la siguiente imagen vemos como para la clave 2 no se

muestra el resultado. Después de procedimientos varios,

notamos que el problema está en el hash para ésta clave. El

punto no debía escribirse, figura 17.

Fig. 17 Obtención segunda clave

Fuente: Los autores

Editamos el archivo original para cambiar los space de tal

forma que pueda identificar las claves, figura 18.

Fig. 18 Intercambio de spaces

Fuente: Los autores

Como no se podía identificar si el hash era correcto o no porque

no nos estaba mostrando la clave, entonces se decidió buscar

otra aplicación que permitiera captar más información de la

entrada o el hash, empleamos JOHN THE RIPPER. Una

función que está incluida dentro de kali linux, para no tener que

instalarla en debian, hicimos las pruebas en kali-linux.

Buscamos la aplicación, como la aplicación está en una ruta

específica de PATH para su ejecución, decidimos asignar la ruta

cambiando la variable PATH, y creamos los 5 archivos de los

hash que faltaban.

Esta aplicación envía un mensaje en caso de que el hash esté

mal escrito o no sea reconocido, además de la cantidad de

intentos realizados por el algoritmos, pero no solo eso, también

se descubrió que puede realizar decriptación de archivos de

MYSQL y mostrar el listado de todas las claves, figura 19.

5

Fig. 19 Obtención segunda clave

Fuente: Los autores

Posteriormente realizamos los demás obtenciones de claves,

figura 20.

Fig. 20 Obtención de las siguientes claves

Fuente: Los autores

Los resultados fueron:

Clave 1: yep

Clave 2: YEP

Clave 3: ;-)

Clave 4: 9Y;

Clave 5: marta

Clave 6: madrid

Ahora procedemos a descifrar la segunda clave del Alfabeto 2,

pero antes modificamos el script, el cual lo realizamos con un

editor de Debian, en mi caso Leafpad y remplazamos así, figura

21.

Fig. 21 Cambio de alfabeto

Fuente: Los autores

Modificamos y guardamos, figura 22.

Fig. 22 Alfabeto modificado

Fuente: Los autores

Después de esto procedemos a buscar la contraseña.

Ahora procedemos a descifrar la tercera contraseña del Alfabeto

3, pero antes modificamos el script, el cual lo realizamos con

un editor de Debían, con Leafpad y remplazamos así, figura 23.

Fig. 23 Cambio de alfabeto

Fuente: Los autores

Modificamos y guardamos, figura 24.

Fig. 24 Alfabeto modificado

Fuente: Los autores

Nos dirigimos al directorio y creamos archivos con leafpad o

con otro editor para ingresar el hash de contraseña en este caso

U./Se8tPqytD2 y guardamos con el nombre hash3, figuras 25 y

26.

Fig. 25 Alfabeto modificado

Fuente: Los autores

Fig. 26 Ubicación del hash

Fuente: Los autores

Ahora procedemos a descifrar la cuarta contraseña del Alfabeto

4, pero antes modificamos el script, el cual lo realizamos con

un editor de Debian, en mi caso Leafpad y remplazamos así,

figuras 27 y 28.

6

Fig. 27 Cambio de alfabeto

Fuente: Los autores

Fig. 28 Alfabeto modificado

Fuente: Los autores

Por tal motivo se procedió a realizar el proceso con la función

John para las dos contraseñas que faltaron realizando el proceso

de crear dos archivos de texto hash5 y hash6 cada uno con sus

respectivas hash de contraseña, figura 29.

Fig. 29 Hash 5 y 6

Fuente: Los autores

Ejecutamos la función John y los resultados fueron

sorprendentemente rápidos. Para el hash5 fue de inmediato,

figura 30.

Fig. 30 Hash 5

Fuente: Los autores

Y para el hash6 se demoró 2 segundos, figura 31.

Fig. 31 Hash 6

Fuente: Los autores

A continuación se muestra una tabla que contiene datos como

el número de caracteres que contiene la contraseña ya cifrada

y los tiempos de proceso, figura 32.

Fig. 32 Tabla con: salt, hash, contraseña, tiempo

Fuente: Los autores

¿Por qué el script no encontró todas las contraseñas?

Porque con el salt puesto en el cifrado dentro del ciclo que

compara con el hash no lo encuentra con el diccionario.

¿Por qué se demoró tanto tiempo en encontrar las

contraseñas el Script?

Porque el script que se manejó en la práctica compara carácter

por carácter, haciendo que los ciclos sean más extensos y por

ende se demore más.

¿Cómo puedo mejorar la búsqueda de las contraseñas?

El script de John the riper realizo las búsquedas de manera más

ágil, toda vez que el diccionario de datos sea más completo,

genera más palabras, que pueden ser contraseñas típicas, y las

va probando todas. Para cada palabra, la cifra y la compara con

el hash a descifrar. Si coinciden, es que la palabra es la correcta.

Es por eso que mejoró la búsqueda de las contraseñas

VI. EXPLOTACIÓN DE VULNERABILIDAD CON

LIVE HTTP HEADERS.

Luego de haber visto el video expuesto por el tutor y haber

realizado la práctica para corroborar el aprovechamiento de la

vulnerabilidad con el complemento liveHTTP header se puede

responder los siguientes interrogantes:

¿Por qué se presenta esta falla de seguridad?

Esta falla de seguridad se presenta porque en este caso en el

sitio web, para enviar los datos proporcionados se usó el tipo de

autenticación basada en formularios, cuyo método de

autenticación funciona enviando sus credenciales a través del

formulario al sitio web para verificación en el lado del servidor,

se usa petición POST en la cual los datos a enviar al servidor se

incluyen en el cuerpo de la misma petición con las cabeceras

HTTP asignadas correspondientemente respecto al tipo de

petición, en este caso los datos enviados no fueron codificados

en el cliente o navegador.

Una falla adicional ligada al tema de seguridad, ya no técnica

sino humana y aunque al parecer no se sale del objetivo del

curso pero es importante destacar es la evidenciada en la NO

precaución del usuario en revisar que programas se ejecutan en

el navegador o junto a él.

7

¿Que se debería encriptar para que no suceda este error?

En este caso se debería encriptar el campo tipo password html

del formulario que almacena la contraseña, antes de generarse

la petición HTTP y ser enviada al el servidor, es decir generar

encriptación del lado del cliente sin evidenciar el algoritmo de

encriptación que se usa del lado de servidor, pues un hacker

podría obtener la contraseña a través de un Rainbow Tables.

¿Cuál sería la solución para solventar este error?

Mejoras en los aplicativos y sitios web en mecanismos de

Encriptación del lado del cliente antes que se realice la petición

HTTP. También es pertinente la implementación de protocolos

HTTPS en las aplicaciones web para realizar peticiones

seguras.

Y para solventar el error humano, es importante tener una

cultura de precaución en temas de seguridad informática, con el

fin de revisar y verificar nuestro equipo y navegador a la hora

de realizar transacciones con formularios web.

¿Qué semejanza existe entre un keylogger y el complemento

http headers?

LiveHTTP headers es un complemento para el navegador

Firefox, sirve para la captura de los encabezados de mensajes

generados en las páginas web. Aunque este complemento es útil

para la solución de problemas, para el análisis y la optimización

de un sitio web, también como se vio en la práctica, esta

información aloja datos sobre el conjunto de caracteres,

lenguaje, memoria caché, la autorización y la caducidad del

contenido y normalmente estos datos no se muestran en el

navegador, pero con la utilización Live HTTP Headers se

pueden observar, tal como ocurrió en este caso en el cual se

pueden ver los datos transmitidos a través de una petición HTTP

por autenticación vía formulario web.

Un keylogger es sistema que permite el registro de las

pulsaciones que se realizan en el teclado en un fichero. A partir

de esta información se puede tener acceso a información

sensible de los usuarios.

La similitud en este caso entre los dos es que ambos son capaces

de capturar digitada en las cajas de textos del sitio web, aunque

el mecanismo sea distinto para los dos.

La diferencia entre los dos es que el keylogger fue pensado para

el robo de contraseñas y otra información importante que es

digitada o tecleada, en cambio el complemento liveHTTP

headers fue creada y es usada por administradores de sistemas,

desarrolladores web y profesionales de la seguridad informática

para la detección de errores y vulnerabilidades en sus

aplicaciones y desarrollos web y en los sistemas de navegación

y transporte de datos.

III. CONCLUSIONES

Si no corrigen MD5, openssl debería cambiar de

función para el cálculo del hash.

Las firmas electrónicas viene para solucionar un

problema de autentificación.

La utilización de la firma digital asegura que el emisor

y el receptor del mensaje puedan realizar una

transacción fiable.

Las metodologías, herramientas y técnicas que se

aplican en Criptografía son indispensables en la

búsqueda de evidencias en los delitos realizados.

Las vulnerabilidades referentes a las contraseñas, se

destacan actualmente por la poca importancia que el

usuario le da, esto conlleva a que los delincuentes

informáticos puedan descifrar contraseñas de manera

muy rápida.

IV. REFERENCIAS

[1] Página Oficial de Debían. Recuperado de:

https://www.debian.org/index.es.html

[2] Instalacion de Debian. Recuperado de:

http://debianfacil.wordpress.com/instalar-debian/

[3] Actualidad sobre seguridad Informática. Recuperado de:

http://www.vnunet.es/Actualidad/Noticias/Seguridad/Vulnera

bilidades/20030911031

[4] John the Ripper password cracker - Openwall. Recuperado

de: www.openwall.com/john/

[5] Firmando archivos digitalmente en Linux. Recuperado de:

www.wreyes.net/blog/firmando-archivos-digitalmente-en-

linux/

[6] Cómo utilizar Live HTTP Headers Recuperado de:

http://www.ehowenespanol.com/utilizar-live-http-headers-

como_6646/

[7] Keylogger. Recuperado de :

http://es.wikipedia.org/wiki/Keylogger

[8] Generar y convertir claves y certificados con OpenSSL.

Recuperado de: http://picodotdev.github.io/blog-

bitix/2014/02/generar-y-convertir-claves-y-certificados-con-

openssl/

[9] OpenSSL: Generating an RSA Key From the Command

Line. Recuperado de:

https://rietta.com/blog/2012/01/27/openssl-generating-rsa-key-

from-command/

[10] P. M. Darbisi, Estudio de factibilidad para actualización

de algoritmo de hash en la infraestructura nacional de

certificación electrónica del estado venezolano, Ministerio del

8

poder popular para la ciencia, tecnología e industrias

intermedias, 2011.

V. BIOGRAFÍA

Jaime Henao nació en Bogotá, el 12 de enero de 1958. Se graduó bachiller en el Colegio Nacional de San Simón,

Licenciado en Matemáticas y Física en la Universidad del

Tolima, Ingeniero de Sistemas de la Unad, Especialización en Ingeniería de software en la Universidad Distrital.

Ejerció profesionalmente la dirección docente para la

secretaría de educación del Tolima, Universidad Colegio Mayor de Cundinamarca, Escuela Nacional de Impuestos

de la Dian. En el área de TI: Director de informática en la

Dian, Director de Informática de Telecom, asesor en informática en Ecopetrol, asesor en informática en el Seguro Social, asesor en informática en Siesa,

Director de Calidad en desarrollo informático en Sertisoft. Asesor y

desarrollador de soluciones de software. Experiencia acumulada en el área de TI por más de 25 años. Vinculado como estudiante a la Unad desde 2007, con

periodos de interrupción. Vinculado al CEAD de Barranquilla, aunque por

razones laborales estoy ahora radicado en Bogotá.

Luis Ardila. De nacionalidad colombiano, Nació en Cartagena bolívar, es Tecnólogo en administración de

empresa, Ingeniero de Sistemas y administración de

empresa graduado de la Universidad Nacional y a Distancia UNAD y Especialista técnica en seguridad

industrial y está realizando estudios en la Especialización en Seguridad Informática que ofrece la UNAD.

Labora como administración de las salas informática de la universidad de

Cartagena como Responsable de todas las sedes , enlace municipal jóvenes en acción DPS

Fabio Castro, nació en Barranquilla, Colombia, el 12

de marzo de 1981. Ser graduó en la Universidad Abierta y a Distancia UNAD en Ingeniería

Electrónica.

Trabaja actualmente en UNE EPM Telecomunicaciones en la cabecera de TV, tiene 7

años laborando en la empresa, vive en la ciudad de

Barranquilla, sus expectativas como ingeniero son seguir creciendo en el ámbito laboral y profesional.

Pertenezco al CEAD Simón Bolivar de la ciudad de Cartagena.

Amaury Gamarra nacio en Cartagena Bolivar, el 24

julio 1977 se gradu en el Instituto Tecnologico Comfenalco en convenio con la Universidad

Tecnologica de Bolivar en Ingenieria de Sistemas,

realizo estudios especiallizado en Administracion de

Bases de datos en el Servicio Nacional de

Aperendisaje SENA.

Ejerció profesionalmente en la Departamento administrativo Nacional de Estadísticas DANE desde 2008 como ingeniero de

soporte.

Su experiencia profesional está enfocada en la administración de las base de datos y en la seguridad de los Dispositivos Móviles, actualmente trabaja en el

Departamento Administrativo Nacional de Estadísticas DANE como ingeniero

de plata como apoyo y soporte informático en la captura y transmisión de los datos recolectados en campo de las Investigaciones estadísticas que se llevan a

cabo en la ciudad de Cartagena.

Jaider Contreras nació en Sincelejo Sucre, Colombia,

el 25 de Septiembre de 1983. Se graduó en 2006 como

Ingeniero de Sistemas en la Corporación Universitaria

del Caribe. Sus experiencias profesionales incluyen la

corporación autónoma regional de Sucre (CARSUCRE),

el SENA, ParqueSof, entre otras, actualmente se

desempeña como ingeniero de sistemas en el cargo de

profesional especializado dentro de la Oficina de Tecnologías de la

Información de la Unidad de Restitución de Tierras.