Kali Linux > Information Gathering > SSL Analysis
sslcaudit
Prueba de SSL / TLS para comprobar la resistencia de los clients contra los ataques MITMsslcaudit es una utilidad para automatizar la prueba de SSL / TLS para comprobar la resistencia de los clients contra los ataques MITM, centrándose en las fallas explotables en la práctica.
Pruebas sslcaudit:
• certificados de servidor que el cliente confía lo suficiente como para establecer conexión SSL / TLS,
• ¿Qué sabores de los apoyos protocolo SSL de cliente (que viene en sslcaudit v1.1).
En general, una correcta aplicación de SSL / TLS cliente presenta el comportamiento siguiente:
En cuanto a la validación del certificado del servidor:
C1 Rechaza certificados autofirmados, certificados no firmados por una CA de confianza
En la práctica una falta de aplicación de C1, C2, C3 o es el más peligroso y permite un sencillo ataque MITM.
C2 Valida las restricciones básicas de la CA intermedias
C3 Sólo acepta el certificado del servidor con CN coincida con el destino previsto
C4 no acepta los certificados caducados
Abusar de un certificado caducado que un atacante pueda para obtener un legítimo, pero vencido o anulado certificado para el servidor o una CA intermedia / root
confianza para el cliente. En circunstancias normales este no es posible para atacante MITM.
C5 No acepta certificados revocados
La mayoría de SSL / TLS clientes no admiten CRL / OCSP apoyo al diseño.
C6 no te dejes engañar por NUL caracteres en CN.
Para explotar C5 un certificado válido con NUL bytes en CN se necesita. Según los conocimientos del autor, hoy en día CAs públicas no emitir dichos certificados.
Comprobable comportamiento relacionado con SSL / TLS protocolo:
P1 No apoye SSLv2 (versión / cifrado downgrade)
La imposibilidad de aplicar P1 conduce a la teórica posibilidad de ataques de downgrade de cifrado. Para el autor la explotación del conocimiento práctico es muy difícil, hay una herramienta gratuita o comercial por ello.
P2 no son compatibles con SSL y TLS 1.0 (CBC ataque)
Un ataque dando lugar a robo de cookies en los navegadores web se demostró [BS-BEAST]. Tiene un requisito previo de que un atacante puede inyectar un malicioso
código JavaScript en el navegador de la víctima. Según onocimiento del autor del ataque no suele ser aplicable a las aplicaciones que utilizan SSL / TLS para machine-to-machine comunicación.
P3 No apoye el intercambio de claves débiles protocolos, bajas longitudes de clave, cifras bajas fortalezas
Si cifras fuertes son compatibles con los compañeros, la presencia de los débiles es sólo explotable mediante cifrado ataque downgrade.
Las pruebas de C1, C2, C3 (cadena de confianza, falta de coincidencia CN) ya están implementadas en sslcaudit v1.0. Protocolo de nivel de las pruebas vendrá en v1.1. C4, C5, C6 parecen tener menor interés práctico y el poder ser implementadas en las versiones posteriores.
Más específicamente, sslcaudit utiliza el algorighm siguiente para generar certificados de prueba del servidor.
Si el usuario ha proporcionado un certificado a través de opciones -user-cert/--user-key,
• sslcaudit intenta utilizar el certificado proporcionado por el usuario como es,
A continuación, sslcaudit genera solicitudes de certificado con las siguientes propiedades:
• default hardcoded CN (www.example.com), a menos que desactivar - no-default-cn
• CN especificado por el usuario, si se suministra a través de - user-cn
• Los atributos coincidentes de un certificado descargue de usuario especificado SSL / TLS servidor, si se establece por
- Servidor HOST: PORT opción
Cada solicitud de certificado es firmado en las siguientes formas:
• auto-firmado, a menos que - no-auto-firmado se especifica
• firmado por el certificado proporcionado por el usuario, para deshabilitar el uso - no-user-cert-firmado
• firmado por la CA suministrado por el usuario (- user-ca-cert / - user-ca-key)
• firmado por la CA suministrado por el usuario con una CA intermedia
◦ sin BasicConstraints
◦ con BasicConstraints CA: FALSO
◦ con BasicConstraints CA: TRUE
De esta manera, se sslcaudit tratar a los clientes con un máximo de 19 certificados especialmente diseñados.
Version de protocolo
• Las pruebas de la versión del protocolo y el apoyo cifra llegará en v1.1. La funcionalidad sera similar a sslaudit [SSLAUDIT], pero hacia atrás.
• "SSL 3.0/TLS ataque renegociación 1,0" [TLS-RENEG]
• [OSCP-ATTACK], al parecer ejecutados por ssnsliff. Se aplicará en el futuro versiones.
COMO USAR LA HERRAMIENTA
Configuracion de red y cliente
Para utilizar sslcaudit, un probador de penetración tiene que convencer al cliente a prueba al establecer una serie de conexiones para el oyente de sslcaudit. Pertinentes conexiones TCP se supone que se redirige a el oyente local creada por sslcaudit. Esto puede hacerse en varias formas, por ejemplo por cambiar el archivo hosts del cliente bajo prueba o el uso de Marvin [MARVIN]. El asunto de conexión redirección está fuera del alcance de este documento.
Sslcaudit desempeña un papel de un pícaro SSL / TLS servidor, presentando el cliente con diversos certificados y registro de los resultados de las pruebas.
Para una mejor cobertura de la prueba sslcaudit deben contar con información adicional:
1. Si es posible, una CA controlado por el usuario, debe añadirse a la lista de CA de confianza para el cliente bajo prueba. Certificado y una clave de CA que se debe pasar a sslcaudit. Esto permitirá generación de la más amplia gama de certificados y realizar todas las pruebas pertinentes y la validación de la configuración de prueba.
2. Si no es posible añadir una costumbre CA en la lista de entidades emisoras de certificados de confianza para el cliente, tratar de conseguir apoderarse de cualquier válido no certificado de CA (y su clave privada) emitido por la CA de confianza para el cliente. Si dicho certificado se pasa a través de sslcaudit --user-cert/--user-key, se utiliza para producir certificados utilizados para la validación BasicConstraints.
3. Sslcaudit deben contar con CN del servidor se comunica el cliente. Puede ser dada explícitamente por - user-cn opción, o mediante la especificación de la dirección del servidor y el puerto con
- Server. En el último caso sslcaudit a tratar de buscar la información del certificado de la servidor.
Sslcaudit no es (todavía) hacer cualquier evaluación de riesgos. En su lugar, se muestra información sobre lo que configuraciones de certificados han sido juzgados y cómo el cliente ha estado comportando. Es responsabilidad del usuario para sacar conclusiones, que son evidentes en la mayoría de los casos de todos modos.
A continuación vamos a considerar cuatro ejemplos que muestran cómo sslcaudit ayuda a probar el comportamiento de los clientes de SSL
Comprueba si un cliente confía en sí mismo arbitrario
certificado firmado (ejemplo 1)
Abrir dos ventanas de terminal, ejecute sslcaudit en uno de ellos.
Sslcaudit
Cuando se inicia sslcaudit empieza a escuchar en todas las interfaces en el puerto 8443.
En otro terminal de dejar correr openssl para conectarse a sslcaudit.
$ Openssl s_client-connect localhost: 8443
CONECTADO (00000003)
profundidad = 0 / CN = www.example.com/C=BE/O=Gremwell bvba
verificar error: num = 18: certificado autofirmado
verificar volver: 1
profundidad = 0 / CN = www.example.com/C=BE/O=Gremwell bvba
verificar volver: 1
En el primer terminal verá un resultado de la prueba.
$. / Sslcaudit
127.0.0.1:38849 selfsigned (www.example.com) conectado, lea el tiempo de espera (en 3.0s)
La salida dice:
• una conexión se recibió 127.0.0.1:38849
• La conexión se maneja con un certificado auto-firmado con CN = www.example.com
• La conexión SSL se ha establecido correctamente, pero el cliente no ha enviado datos en 3 segundos
El cliente establece sesión SSL con un servidor presentando un certificado autofirmado y no
cerrar inmediatamente. Al parecer, el cliente no comprueba nada en absoluto y es vulnerable al ataque MITM.
Comprueba si un cliente confía en sí mismo arbitrario
certificado firmado (ejemplo 2)
Ahora haga lo mismo que el anterior, pero en lugar de utilizar socat openssl. Socat valida los certificados de servidor por defecto y no se conecta a un par arbitrario. Ahora corre sslaudit como en el ejemplo anterior, entonces iniciar socat:
$ Socat - OPENSSL: localhost: 8443
05/01/2012 10:50:50 socat [18692] E SSL_connect (): error: 14090086: SSL
rutinas: SSL3_GET_SERVER_CERTIFICATE: Certificado de no verificar
En el lado de sslcaudit veremos:
127.0.0.1:38889 selfsigned (www.example.com) TLSv1 alerta desconocido ca
Una vez más:
• una conexión se recibió 127.0.0.1:38889
• La conexión se maneja con un certificado auto-firmado con CN = www.example.com
• Configuración de la conexión SSL no ha podido
El cliente se niega la conexión con el servidor de la presentación de un certificado autofirmado para un CN arbitraria.
En base a esto, sólo se puede concluir que el cliente no está completamente roto y se niega la conexión al servidor obviamente inseguro.
Supongamos que no se puede lesionar lista de clientes de CA de confianza ni encontrar ningún certificado emitido por una CA ya confianza para el cliente. Una cosa que debe hacer en esas circunstancias es sslcaudit punto hacia el servidor real y dejar que imitar certificado de servidor. Conexión con socat otra vez, pero ahora
ejecutarlo en un bucle infinito:
$ while true ; do socat - OPENSSL:localhost:8443; sleep .5; done
A continuación aparece en el lado de sslcaudit:
$ ./sslcaudit --server 62.213.200.252:443
...
127.0.0.1:41264 selfsigned (www.example.com) TLSv1 alerta desconocido ca
127.0.0.1:41265 selfsigned (brufeprd1.hackingmachines.com) TLSv1 alerta desconocido ca
Podemos ver que el cliente rechaza un certificado autofirmado incluso si su objeto coincida con el que trajo desde el servidor. Hasta el momento no hay evidencias de un comportamiento inseguro. Todavía no hay pruebas de hecho que confirma el cliente hace la validación BasicConstraints adecuada.
Re-propósito un certificado
Si no tenemos la oportunidad de modificar la lista de entidades emisoras de certificados de confianza para el cliente, sólo hay un adicional
Lo que podemos hacer: suministrar sslcaudit con algún certificado emitido por la CA ya la confianza del cliente. Si dicho certificado se pasa a sslcaudit (a través de --user-cert/--user-key), se utiliza para producir certificados para los ejercicios BasicConstraints validación.
Para simular cliente que utilizamos socat nuevo, pero pasar parámetros adicionales para hacer que la confianza CA que ha emitido el certificado.
$ while true ; do socat - OPENSSL:localhost:8443,cafile=test/certs/test-ca-cacert.pem ;
sleep .5; done
Ejecución de sslcaudit, pasándole el certificado y la clave:
$ ./sslcaudit --server 62.213.200.252:443 \
--user-cert test/certs/www.example.com-cert.pem
--user-key test/certs/www.example.com-key.pem
127.0.0.1:41764 suministrado por el usuario (www.example.com) conectado, leer tiempo de espera (en 3.0s)
127.0.0.1:41765 selfsigned (www.example.com) TLSv1 alerta desconocido ca
127.0.0.1:41766 selfsigned (brufeprd1.hackingmachines.com) TLSv1 alerta desconocido ca
127.0.0.1:41767 signed1 (www.example.com, www.example.com) TLSv1 alerta desconocido ca
127.0.0.1:41768 signed1 (brufeprd1.hackingmachines.com, www.example.com)
TLSv1 alerta desconocido ca
El resultado de la primera prueba indica que el cliente ha establecido la conexión y no cerrarla derecha de distancia. Esto sugiere que el cliente valida CA, pero se ignora desajuste CN. Esta debilidad es explotable si un atacante puede hacerse con un certificado (y clave privada) emitidos por cualquier CA de confianza el cliente.
Las dos últimas líneas corresponden a intentos de producir un certificado con su firma con suministrada por el usuario certificado. El cliente bajo prueba ha rechazado estos certificados, lo que sugiere que el cliente valida BasicConstraints del certificado de la cadena de confianza.
Pruebas con CA suministrado por el usuario
Como se mencionó anteriormente, para la prueba más completa, es necesario agregar la prueba de CA para el cliente configuración. Aquí asumimos que fue hecho y es certificado CA (test / certs / test-ca cacert.pem-) ya se añade a la lista de CA de confianza para el cliente.
Para simular el lado del cliente se utilizará socat nuevo.
$ while true ; do socat - OPENSSL:localhost:8443,cafile=test/certs/test-ca-cacert.pem ;
sleep .5; done
$ ./sslcaudit --server 62.213.200.252:443 \
--user-ca-cert test/certs/test-ca-cacert.pem \
--user-ca-key test/certs/test-ca-cakey.pem
127.0.0.1:41907 selfsigned (www.example.com) TLSv1 alerta desconocido ca
127.0.0.1:41908 selfsigned (brufeprd1.hackingmachines.com) TLSv1 alerta desconocido ca
127.0.0.1:41909 signed1 (www.example.com, test-ca) conectado, leer tiempo de espera (en 3.0s)
127.0.0.1:41911 signed1 (brufeprd1.hackingmachines.com, test-ca) conectado, lea tiempo de espera (en 3.0s)
127.0.0.1:41912 signed2 (www.example.com, ca-ninguno, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:41913 signed2 (www.example.com, ca-falso, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:41914 signed2 (www.example.com, ca-verdadero, test-ca) conectado, lea tiempo de espera (en 3.0s)
127.0.0.1:41916 signed2 (brufeprd1.hackingmachines.com, ca-ninguno, test-ca)
TLSv1 alerta desconocido ca
127.0.0.1:41917 signed2 (brufeprd1.hackingmachines.com, ca-falso, test-ca)
TLSv1 alerta desconocido ca
127.0.0.1:41918 signed2 (brufeprd1.hackingmachines.com, ca-verdadero, test-ca) conectado, lea tiempo de espera (en 3.0s)
Desde la salida de sslcaudit anterior es evidente que el cliente valida correctamente la confianza de la cadena,pero acepta el certificado con cualquier CN. Esto es consistente con lo que se espera de socat.
Además esto demuestra que sslcaudit produce bien formateados "confiables" certificados.
Pruebas con CA suministrado por el usuario
Finalmente reiteramos la última prueba, pero en contra de un cliente SSL apropiado, curl, invocó la siguiente manera:
$ while true ; do curl --cacert test/certs/test-ca-cacert.pem https://localhost:8443/ ;
sleep .5 ; done
Ahora corremos sslcaudit. Aquí asumimos que de alguna manera sabe lo que el cliente espera CN y especificar directamente a través de - user-cn parámetro.
$ ./sslcaudit --user-cn localhost \
--user-ca-cert test/certs/test-ca-cacert.pem \
--user-ca-key test/certs/test-ca-cakey.pem
127.0.0.1:42028 selfsigned (www.example.com) TLSv1 alerta desconocido ca
127.0.0.1:42029 selfsigned (localhost) TLSv1 alerta desconocido ca
127.0.0.1:42030 signed1 (www.example.com, test-ca) conectado, EOF antes de tiempo de espera (en 0.001s)
127.0.0.1:42031 signed1 (localhost, test-ca) conectada, tiene 155 octetos en 0.0s
127.0.0.1:42032 signed2 (www.example.com, ca-ninguno, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:42033 signed2 (www.example.com, ca-falso, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:42034 signed2 (www.example.com, ca-verdadero, test-ca) conectado, EOF antes de tiempo de espera (en 0.001s)
127.0.0.1:42035 signed2 (localhost, ca-ninguno, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:42036 signed2 (localhost, ca-falso, test-ca) TLSv1 alerta desconocido ca
127.0.0.1:42037 signed2 (localhost, ca-verdadero, test-ca) conectada, tiene 155 octetos en 0.0s
Aquí podemos ver que el cliente sólo establece la conexión con los servidores de haber certificado firmado por una CA de confianza. Los certificados autofirmados y el certificado firmado por una CA intermedia con seguro BasicConstraints son rechazados. Además, el cliente cierra la conexión inmediatamente si hay un desajuste en el CN.
Este tipo de producción en general significa que la validación del certificado del servidor se ejecuta correctamente. (El comportamiento del cliente hacia los servidores con un certificado caducado o un certificado con NUL- personajes de CN sigue siendo no probada).
Sintaxis
sslcaudit [OPCIONES]
Opciones
-h, --help, - help muestra este mensaje de ayuda y termina
-L LISTEN_ON Especifique la dirección IP y el puerto TCP para escuchar, en formato HOST: PORT. El valor predeterminado es 0.0.0.0:8443
-m MODULES Lanzamiento de módulos específicos. Por ahora sólo lo funcional módulo es 'sslcert'. También hay 'dummy' módulo utilizado para la prueba interna o como un código de la plantilla para el nuevo módulos. El valor predeterminado es sslcert
-v VERBOSE Aumentar nivel de detalle. El valor predeterminado es 0. Ensayo: 1.
-d DEBUG_LEVEL Ajuste el nivel de depuración. El valor predeterminado es 0, que desactiva depuración. Ensayo: 1 para habilitarlo.
-c NCLIENTS Número de clientes a manejar antes de salir. Sslcaudit por defecto se cerrará tan pronto como se pone un cliente totalmente procesado.
-N TEST_NAME Establezca el nombre de la prueba. Si se especifica aparecerá en la columna de la izquierda en la salida.
-T SELF_TEST lanzamiento auto-test. 0 - simple cliente TCP, 1 - NC cliente verificar, 2 - rizo.
--user-cn=USER_CN Set especificado por el usuario CN.
--server=SERVER servidor donde ir a buscar el certificado de servidor, en HOST: PORT formato.
--user-cert=USER_CERT_FILE Establecer ruta al archivo suministrado que contiene el usuario certificado.
--user-key=USER_KEY_FILE Establecer ruta al archivo que contiene la clave proporcionada por el usuario.
--user-ca-cert=USER_CA_CERT_FILE Establecer ruta del archivo del certificado que contiene para el usuario CA suministrado.
--user-ca-key=USER_CA_KEY_FILE Establecer ruta al archivo de claves que contiene para CA suministrado por el usuario.
--no-default-cn No utilice CN por defecto
--no-self-signed No trates de certificados autofirmados
--no-user-cert-signed No firme los certificados de servidor con el usuario suministrado
No hay comentarios:
Publicar un comentario