Fallas en SSL 2015 y antes

Posted on Actualizado enn

Marzo 2015

Logjan

http://thehackernews.com/2015/05/logjan-ssl-vulnerability.html

SKIP-TLS y FREAK (Factoring RSA Export Keys)

Skip TLS

En un entorno en el que un cliente y un servidor quieren comunicarse de forma cifrada, pero hay un atacante en el medio de la red. Este atacante tiene acceso a todos los mensajes pero no puede manipularlos todos porque le saldría una alerta de seguridad en el navegador si el proceso de negociación de claves no es correcto.  Sin embargo, se ha demostrado que existen implementaciones que, saltándose alguno de los pasos o enviando mensajes errores, creen que han negociado las claves de cifrado y establecido el canal cifrado cuando no es así. Este bug afecta, a servidores de Google, Paypal o Amazon Web Services. Afectación en la implementación TLS que hace JSSE – que venían con el JDK de Java desde la versión 1.5 hasta la versión 1.8 antes de la actualización crítica de Enero 2015.

Esto quiere decir que, un atacante en el medio de la comunicación podría manipular los mensajes para hacer que la máquina de estados del servidor y del cliente llegaran al estado final de “negociado un canal cifrado de forma segura” sin que esto haya sido así.

Freak

Lo que debe suceder es que tanto el servidor como el cliente permitan esta negociación, algo que en el lado del servidor se permiten los algoritmos marcados para exportación con EXP y en el cliente se soportan, como es el caso de Android o Apple Safari. Si las dos partes tienen estos algoritmos permitidos, lo que el atacante deberá hacer es lo que se conoce como un ataque de Downgrade, es decir, forzar al cliente y al servidor a negociar una sesión uno de estos algoritmos inseguros.

Normalmente, servidor y cliente se intercambian la lista de algoritmos que soportan y se elige el más seguro, lo que hace el hombre en medio es hacer creer a cada uno de ellos que el otro solo soporta el algoritmo inseguro

Fuente; Eleven Paths http://www.elladodelmal.com/2015/05/logjam-o-el-bug-que-pudo-usar-la-nsa.html

Bar Mitzvah

Presentado en BlackHatAsia2015, afecta conexiones ssl/tls con el algoritmo de cifrado RC4, el concepto Invariance Weakness la produce el sistema pseudo-aleatorio que tiene el algoritmo RC4 para generar las claves, en el cual hay muchas claves generadas que pueden romperse
Estas claves con el bug de Invariation Weakness permiten que un atacante pueda descifrar en poco tiempo los primeros 100 bytes de una conexión SSL/TLS, dejando parte del tráfico de la sesión al descubierto. Esos 100 bytes no son mucho, más teniendo en cuenta que el Handshake de la sesión SSL/TLS ya se lleva 35 bytes, pero conseguir descifrar 65 bytes puede ser más que suficiente, como han demostrado.

Ataque 1: Captura de tráfico de red sin ataque man in the middle
En un escenario de ataque de red en el que solo se pueda acceder al tráfico, se podrían estar escuchando todas las sesiones SSL y descifrar los 65 bytes de aquellas que vinieran cifradas con una clave “Hit“. Una vez analizados esos 65 bytes, se procedería a ver qué contenido va en esos, para lanzar un ataque a posteriori.
El éxito del ataque es cuando en esos 65 bytes se puede sacar parte de la cookie de sesión de la aplicación. Con una parte de 65 bytes de una cookie de sesión deASP.NET o de PHP, se puede realizar un ataque de fuerza bruta para conseguir obtener una cookie válida en tiempo y forma. Una vez conseguida las cookies, se podría hacer un hijacking completo. En el estudio, los investigadores también hacen sus cálculos de si en esos 65 bytes vienen partes de una contraseña, para saber cuánto se tardaría en crackear la contraseña de forma total.
Ataque 2: Captura de tráfico de red con un ataque man in the middle
Como se puede suponer en el ataque 1, para conseguir tener éxito hay que tener algo de fortuna para capturar las claves “Hits” y que en los 65 bytes que se pueden descifrar haya algo que permita crackear información sensible para secuestrar una cuenta o sesión. Sin embargo, si se tuviera un control en el cliente mediante unataque de man-in-the-middle similar al que propone BEAST, se puede entonces generar mucho más tráfico en la sesión del cliente para conseguir más “Hits” y por tanto conseguir más partes de la cookie de sesión o de una clave.
Conclusión: Deshabilita RC4 en el servidor y en el cliente.

http://www.elladodelmal.com/2015/03/bar-mitzvah-nuevo-ataque-ssltls-te-roba.html

HTTPs “secure”

El protocolo HTTP-s que está pensado para dar seguridad y privacidad a los usuarios de la web mediante dos principios básicos: Confianza y Cifrado robusto.

El cifrado robusto debería ser el menor de nuestros problemas en vista de que el punto donde más falla el sistema es en la confianza, pero digamos que salvo ataques como BEAST, CRIME o BREACH presentado en BlackHat USA 2013 y el uso de certificados antiguos con algoritmos débiles y claves demasiado cortas no se han encontrado “grandes problemas”. No olvidar, por supuesto, del ataque de TLS-Renegotiation de Steve Dispensa y Marsh Ray.

La parte de confianza es  un asco tras todo lo visto, y el control legal que Estados Unidos o China tienen sobre las grandes empresas de certificación digital, lo que les puede llevar a hacer cumplir leyes como la Patriot Act o Foreing Intelligence Survilliance Act. Para entendernos, digamos que el proceso de conseguir un canal cifrado privado pasa porque superemos un proceso de confianza, y ese proceso de confianza es difícil de sostener. Pongamos un ejemplo.

Supongamos que quiero entrar a una cuenta de servicio de Internet donde tengo mis cosas importantes – cada uno las suyas – y tengo un portal de acceso donde he de poner mis credenciales que funciona bajo HTTP-s. Para que se establezca un canal seguro y privado, primero he de confiar en que estoy conectándome al sitio que deseo y esa comprobación la hace mi sistema operativo – sea Windows, Mac OS X o iOS, por poner algún ejemplo -. ¿Cuáles son las reglas de la confianza? Pues sencillo:

1) Que no esté caducado
2) Que sea un certificado digital emitido para ese sitio
3) Que esté emitido por una entidad de confianza

Las dos primeras son bastante sencillas de superar, y el truco recae por supuesto en la tercera. Pero sigamos con el ejemplo. Para que esto funcione, el sitio al que vamos a conectarnos tiene que obtener un certificado digital emitido por una de esas entidades de confianza. Para ello va y paga a la entidad de confianza – poco si quiere uno normalito, mucho si quiere uno de validación extendida, que se ponga verde cuando el usuario navegue por ese sitio garantizando que ha habido una comprobación manual de todos los datos.

A partir de ese momento el usuario que se conecta desde su navegador al servidor recibe la parte pública de ese certificado donde comprueba que no está caducado, que está emitido para ese sitio y que está emitido por una de esas entidades de confianza.

La pregunta es ¿Quiénes son esas entidades de confianza? Y la respuesta es que es difícil saber el número de ellas que hay por el mundo…. Y pueden ser infinitas.

Las entidades de confianza

El sistema operativo Microsoft Windows tiene una lista de entidades de confianza cargadas por defecto, pero que además se actualizan dinámicamente, por lo que no es fácil en un determinado momento cuantificar cuántas son. Yago Jesús creo una utilidad llamada CertMon para que el sistema avise cada vez que se carga una nueva. En Mac OS X hay una lista que puedes gestionar – en alguna versión sin éxito– y en iOS no es posible dejar en una entidad de confianza marcada por Apple. Algunas herramientas, como el navegador Mozilla Firefox, decide no utilizar la lista de entidades de confianza marcadas por Microsoft o Apple, por lo que él mismo tiene un almacén de entidades de confianza en las que confía por defecto.

Todas estas, son las Entidades de Certificación Raíz de Confianza. Pero no acaba aquí en quién confías. 

Las entidades de confianza intermedias

Una entidad de certificación raíz de confianza, además, tiene la capacidad de emitir certificados para entidades de certificación con la capacidad de emitir certificados digitales para cualquier sitio. Y estás, podrían a su vez crear nuevas entidades de certificación. No importa. Siempre que la raíz de los certificados sea una de las de confianza del equipo, entonces el sistema confía. 

Digamos que la entidad A en la que confías emite un certificado para la entidad B (en la que no confías por defecto) y esta emite un certificado para el sitio web C, cuando tu sistema compruebe la raíz de confianza no mostrará ninguna alerta, porque tu confías en A y A ha gestionado esa confianza delegándola en B y B ha emitido el certificado del sitio C, así que tu confías. 

No todos los certificados digitales pueden ser utilizados para emitir certificados, así que digamos que emitir un certificado para una entidad certificadora intermedia es un proceso restringido, pero incluso hemos visto en el pasado como creando certificados para sitio con un certificado que no era de entidad certificadora los navegadores se lo han comido como de confianza. No hay más que ver el caso de los ataques de SSLSniff. 
Y todo esto es mucho peor cuando te das cuenta de que el certificado de un sitio no tiene por qué ser único. 

¿Cuántos certificados que sean de confianza se pueden crear para un sitio? 

La respuesta es sencilla. Infinitos. El certificado de http://www.google.com para que tu sistema confíe en él puede estar emitido por miles de entidades de certificación. Si recibes un certificado emitido para http://www.google.com de una entidad de certificación raíz de confianza tu sistema lo dará por bueno. Si lo recibes por una entidad intermedia autorizada por otra entidad intermedia que a su vez ha sido autorizada por otra entidad certificadora raíz, como confías en la raíz, confías en él y no hay problema alguno. 

Habiendo tantos certificados, tu sistema puede estar dando la confianza a muchos certificados distintos de un determinado sitio, y cada vez que se da la confianza se negocian las claves de cifrado con ese servidor y ese servidor tendrá la capacidad de descifrar todo el contenido. 

¿Podría la NSA o el GCHQ descifrar el tráfico si va todo en HTTP-s?

Pues claro que sí. Lo único que se necesitaría es hacer un ataque man in the middle en lugar de pinchar el cable únicamente. Ahora mismo podría estar haciéndolo, igual que lo hace China con el Great Firewall of China. Lo único que se necesita es que todas las comunicaciones cifradas se hagan con el nodo donde se intercepten las comunicaciones. Basta con que sea él, con un certificado de entidad intermedia de confianza quien emita los certificados digitales para todos los sitios de Internet a los que se visite. 

El sistema del cliente confiará por provenir de una entidad de confianza raíz, y negociará todas las claves de cifrado, lo que le permitirá al nodo acceder al tráfico descifrado.

¿Cómo controlar la confianza en las entidades de certificación? 

Pues no es fácil. En primer lugar hay que decir que el sistema funciona delegando la confianza en entidades de certificación en modo lista blanca, es decir, cada sistema tiene una lista de las entidades en las que confía, y si no las quiere, tiene que quitarla de la lista. Esto no es fácil en sistemas como Windows donde la lista es dinámica, por lo que habría que pedir el certificado manualmente para luego bloquearlo.

En el caso de las entidades de certificación intermedias, la única manera es que se haya creado una lista negra para cada una de ellas, pero de nuevo debes tener antes la clave pública de la entidad de certificación en tu sistema, y por supuesto ante un ataque que aún no se ha producido esto es complicado. La mejor solución para Windows para tener una aproximación al bloqueo de entidades de certificación de poca confianza es SSLCop de Yago Jesús, que permite hacer un bloqueo por países en los que confíes menos.

En segundo lugar, si dejas de confiar en una entidad, dejas de confiar en todos los certificados que haya emitido esa entidad. Todos. Eso significa que, por ejemplo, si te cargas Verisign dejas de confiar en una cuarta parte de Internet. Moxie Marlinspike proponía hace un par de años el uso de notarios en lugar de la regla de confiar de forma transitiva.

¿Y otros sistemas de protección extra?

No voy a extenderme en otros mecanismos de protección extra, pero os dejo algunas ideas sobre ellos:

Las redes VPN: Las soluciones VPN (Virtual Private Network) son otra parte que podría ser utilizada para obtener privacidad, pero sólo vale entre tu equipo y el servidor VPN, a partir de ese momento todo lo que envíes por Internet estará sujeto a las reglas de HTTP o HTTP-s. Además, no olvides que si estás en una compañía de un país tendrá que cumplir las leyes, y no hace falta que te cuente FISA otra vez.

La red TOR: La red TOR, dentro de la red TOR, utiliza cifrado que sólo puede romperse si hay nodos rogue metidos en ella. Visto lo que le pasó a nuestro amigo Hache, pensar que no hay nodos capturando tráfico de red para alimentar las bases de datos de los servicios de “inteligencia” es para solo los más cándidos.

El correo electrónico: El último punto de este artículo que ya se me ha ido de las manos se lo quiero dedicar al correo electrónico, ya que por ahora, la transmisión de mensajes entre servidores de correo de organizaciones remotas va sin cifrar. Así que para alguien que pinche los cables como enTempora o X-Keystore, será fácil leer siempre los mensajes SMTP. Se podrían utilizar soluciones como SMTP-s para el envío de mensajes entre servidores de correo o Mutual-TLS para que fueran cifrados, pero no sólo no se ha extendido ninguno, sino que además recaen en el uso de las reglas de confianza citadas anteriormente, lo mejor es que te cifres tú tus correos extremo a extremo con tu con PGP o S/MIME.

http://www.elladodelmal.com/2013/08/podria-http-s-acabar-con-el-esiponaje.html

Anuncios

Thread Modeling

Posted on Actualizado enn

Todo proyecto de seguridad informática debe iniciar con un modelado de amenzas.

1.-Decompose the application

  1. Uses Cases (how the app is used, identify entry points), assets (valores, recursos), trust levels
  2. DFD data flow diagrams, with previous information can generate this diagrams, to find targets
    1. Data sources, process, data flows, and interaction with users, these threat can be identified further as the roots for threats  trees

A list of: External dependencìes; entry points; assets; roles (set of priviledges, trust levels)

2.-Determine and rank threats

  1. A thread  categorization like STRIDE can be used or ASF application security frame.
    1. Defensive ASF
      1. Auditing and logging
      2. Authentication
      3. Authorization
      4. Configuration Managment
      5. Data protection in storage and transite
      6. Data validation
      7. Exception management
    2. Attacker
      1. Spoofing of user identity (illegal access) – Security control => Authetication
      2. Tampering (Maliciously add/modify persistent data) – Security control => Integrity
      3. Repudiation (are associated with users who deny performing an action without other parties having any way to prove ) – Security control => No repudiation
      4. Information disclosure (privacy breach or data leak, read data that was not granted) – Security control => Confidentiality
      5. Denial of service (D.o.S) (Make service unavailable) – Security control => Availability
      6. Elevation of privilege (Gain privileged access) – Security control => Authorization
    3. Determination of the security risk for each threat, use DREAD or a less subjective qualitative risk model
      1. Do nothing, inform about the risk, mitigate the risk, accept the risk, transfer the risk, terminate the risk

3.-Countermeasures and mitigation

  1. Mapping list of risk, mitigation strategy, level of mitigation, effort, business impact, owner

Rastreo de intrusos en la red

Posted on Actualizado enn

Existen métodos específicos para Microsoft Windows (Wireless Network Watcher o Microsoft Network Monitor), así como para Apple (Mac OS X Hints) y dispositivos móviles o Android (Fing, Network Discovery, Net Scan) e iOS (Fing, IP Network Scanner, iNet).

El mejor sistema para proteger nuestra red doméstica es el protocolo WPA2-PSK

Si la configuración nos permite modificar también el encriptado, tenemos que elegir la opción AES”

Ligar GoDaddy con Azure

Posted on Actualizado enn

Lo que se tiene que hacer es en ambos anotar información cruzada.

  1. Primero Azure
    1. Obtener IP y pointsto
      1. En Azure, después de seleccionar la appweb hay que elegir ADMINISTRAR DOMINIOS PERSONALIZADOS y tomar la DIRECCIÓN IP QUE SE USA AL CONFIGURAR REGISTROS A, por ejemplo 23.101.169.175; luego se toma el awverify.prod-aeinmobiliaria.azurewebsites.net
  2. GoDaddy
    1. Configurar Settings principales
      1. En settings, forwarding, domain poner el sitio de Azure http://prod-aeinmobiliaria.azurewebsites.net/(forward with masking)
    2. Configurar DNS
      1. En host, @ points to 23.101.169.175
        Host Points To TTL Actions
        @ 23.101.169.175 600 seconds
      2. En CNAME (Alias) awverify y awverify apuntando a awverify.prod-aeinmobiliaria.azurewebsites.net, tambien el www apunta a @
        Host Apunta A TTL Acciones
        awverify awverify.prod-aeinmobiliaria.azurewebsites.net 600 segundos
        awverify.www awverify.prod-aeinmobiliaria.azurewebsites.net 600 segundos
        email email.secureserver.net 1 Hora
        ftp @ 1 Hora
        www @ 600 segundos
  3. Regresar a Azure y configurar nombres de dominio
    1. En nombre del dominio se pone aeinmobiliaria.com.mx y http://www.aeinmobiliaria.com.mx (hay que esperar unos 10mins para que refresque GoDaddy el dns) Hay que ser paciente. Y hay que esperar más para que ponga los directorios en la URL

Imagenes

azure

daddy0

daddy1

más ayuda
http://blogs.msdn.com/b/kaushal/archive/2013/07/06/windows-azure-web-sites-how-to-configure-a-custom-domain.aspx

Avoid Cross Site Scripting

Posted on

Regex r = new Regex(@”^[\w]{1,40}$”);

if (r.Match(strName).Success) {

// Cool! The string is ok

} else {

// Not cool! Invalid string

}

https://msdn.microsoft.com/en-us/magazine/cc188938.aspx

hacking herramientas

Posted on Actualizado enn

Algunos conceptos de seguridad informática…

Hijacking, secuestro de sesión, a través de un sniffeo de red se pueden robar la galleta de un usuario y tener acceso a lo que él esté viendo, esto claro si la galleta no cuenta con seguridad casada con la máquina del cliente.

Herramientas: cain y abel http://es.slideshare.net/TotusMuertos/manual-cain-abel-sniffer-en-windows gost phiser / Xplico

Penetration Testing Training with Kali Linux https://www.kali.org/penetration-testing-with-kali-linux/ https://www.kali.org/

Herramienta para generar metasploit payloads que no son detectados por antivirus, ah con Python

https://www.veil-framework.com/tutorial-veil-payload-development/
https://github.com/Veil-Framework/Veil-Evasion

Página para revisar archivos y sitios si contienen virus

Posted on

wikipedia dice: VirusTotal is a website, originally developed by Hispasec, that provides free checking of files for viruses

https://www.virustotal.com