View
154
Download
16
Category
Preview:
DESCRIPTION
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.
Citation preview
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.
Recommended