Apache incluye un módulo llamado mod_md. Podemos usarlo para el aprovisionamiento de certificados a través del protocolo ACME. Este artículo explica cómo instalar, configurar y poner en marcha Apache con un módulo mod_md para asegurar el tráfico con el certificado gratuito Let’s Encrypt TLS/SSL en un servidor Debian 10 Buster.
Categoría: Seguridad
1- Como primera instancia debemos instalar el paquete que se encuentra en los repositorios
$ sudo apt-get install john
2 – El siguiente paso es generar generar un archivo intermedio entre la lista de usuarios y sus contraseñas cifradas.
$ sudo unshadow /etc/passwd /etc/shadow > usuarios.db
3 – Luego comenzamos el proceso de verificación de contraseñas por fuerza bruta
$ john usuarios.db
4 – Debemos destacar que este escaneo puede llevar bastante tiempo y recursos de procesamiento. En cualquier momento es posible consultar las contraseñas que ya han sido determinadas. John the Ripper guarda las contraseñas crackeadas en ~/.john/john.pot. Para mostrar estas contraseñas ejecutamos el siguiente comando:
$ john -show usuarios.db
5 – En caso de que el proceso haya sido cortado se puede continuar el escanero con solo ubicárse en el mismo directorio donde se encuentra el archivo de datos y ejecutando la siguiente línea
$ john -restore
Podría ocurrir que al ejecutar el comando john usuarios.db nos encontremos frente a este mensaje de error: “No password hashes loaded“. Este error se puede producir por alguno de los siguientes motivos:
- El fichero de contraseñas que le estamos pasando a John no tiene las contraseñas. Esto se debe a que o bien no hemos escrito bien el nombre del fichero (usuarios.db) o bien ha ocurrido algún tipo de error en el paso 2 (por ejemplo, se nos olvidó escribir el sudo).
- Todas las contraseñas del fichero que se le pasa como parámetro (usuarios.db) ya han sido crackeadas. Ejecutamos
john --show usuarios.dby las mostrará.
Categorías
Seguridad en protocolos de mensajería
Con la transición del PC en casa a los dispositivos de tipo portátil y smart*, pasamos de entornos ‘seguros’ a entornos potencialmente mas peligrosos como Wifis públicas o centros de trabajo, donde es realmente fácil interceptar comunicaciones.
Existen muchos mitos sobre ‘que te pueden hacer’ si haces login en el MSN o Gtalk desde un lugar donde haya ojos curiosos, por eso vamos a explicar como funciona cada protocolo y el tipo de riesgos potenciales de cada uno.
Empezamos por el más difundido:
MSN / Messenger
Sin duda el protocolo mas empleado y con mas cuota de usuarios en España. El protocolo MSN no es un protocolo estático, va mutando periódicamente y Microsoft va sacando actualizaciones en las que varia ligeramente su funcionamiento. Dado que sus internals no son públicos, toca ‘reversear’ y deducir como funciona. A día de hoy la última especificación de la que se cuenta con información es esta y la parte que mas nos interesa es la que concierne a como se realiza la autenticación.
A grosso modo:
- El cliente lanza la petición de login al servidor MSN,
- El servidor MSN facilita un ‘reto’ (un montón de caracteres aleatorios para generar entropía) y un servidor ‘de tickets’
- El cliente envía el Login + Password + Reto mediante una conexión SSL al servidor de tickets y, en caso de ser válida, obtiene un ticket
- El cliente envía ese ticket al servidor MSN
Una vez completada esta secuencia, el resto de la comunicación se realiza en texto plano sin codificación alguna
Gtalk (cliente oficial)
Como es bien sabido, Google para implementar su sistema de mensajería se ha decidido por una implementación basada en XMPP / Jabber. El problema es que Jabber aun siendo un protocolo estandarizado admite mil y una forma de hacer las cosas (algunas mas seguras, otras mas inseguras). En concreto, Google en su implementación ofrece como formas de hacer auth dos posibilidades, una llamada Google-Token (totalmente fuera de especificación y propietaria de Google) y otra basada en TLS. El cliente oficial, como es lógico, emplea Google-Token y ciertamente debilita mucho la seguridad del sistema. Funciona de la siguiente manera:
- El cliente se conecta vía SSL a Google para hacer el auth
- Google entrega un token al cliente
- El cliente usa ese token como método de autenticación
Terminada esta fase, el resto de la comunicación va en texto plano
Gtalk (clientes XMPP / Jabber alternativos)
Si obviamos el cliente oficial de Google y nos decantamos por alternativas como Gajim o Pidgin (necesario si empleas una plataforma como Linux), la cosa cambia radicalmente. El método empleado está completamente basado en TLS.
- El cliente inicia la comunicación con el servidor XMPP
- Se negocia un túnel TLS
- Se envían las credenciales
A partir de ahí toda la comunicación va cifrada
Facebook
Recientemente Facebook ha abierto su chat públicamente mediante una plataforma basada en XMPP / Jabber. Como ya decía anteriormente, las formas en las que se puede hacer auth en XMPP son increíblemente versátiles. En el caso de Facebook han optado por un método basado en Digest SASL. SASL es un protocolo ampliamente utilizado para autenticación en servicios como IMAP o SMTP. Para hacerlo aun mas divertido, SASL soporta tres modos de autenticación en función de la seguridad que se quiera aplicar. El primero llamado ‘auth’ únicamente sirve para intercambiar credenciales de forma segura basado en retos, el servidor genera una cadena aleatoria y el cliente debe responder con un hash de sus credenciales + el reto. El segundo modo ‘auth-int’ añade una capa de integridad añadiendo a cada intercambio un ‘código de integridad’ empleando HMAC. El tercero, ‘auth-conf’ añade a todo eso una capa de cifrado. ¿Cual método ha elegido Facebook? auth normal.
Después de eso la conversación continua en texto plano
Conclusiones
Una vez explicado como funciona cada protocolo, a modo resumen una tabla con los riesgos potenciales que podemos sufrir si una sesión de chat es interceptada.
Los criterios de evaluación han sido
[ ] Crackeable: La posibilidad de que un atacante que capture la autenticación pueda aplicar fuerza bruta sobre lo interceptado para averiguar la contraseña
[ ] Usuario deducible: Se evalúa si durante la fase de autenticación un atacante podría averiguar el login / dirección de correo ej: fulano@hotmail.com
[ ] Sniffing conversación: El hecho de que los mensajes de chat intercambiados sean susceptibles de leerse en texto plano
** En el caso de Gtalk solo se contempla en formato ‘cliente alternativo’
