Hace algo más de dos años David Reed (que entre sus credenciales tiene el hecho de haber diseñado el protocolo UDP) causó un importante revuelo (cierto que en círculos más bien reducidos) al indicar y razonar que los problemas de alta latencia de la red 3G de AT&T se debían a un problema de diseño de la misma y no tanto a la proverbial falta de espectro (la secuencia de mensajes se puede encontrar aquí). En concreto el problema se debía, según Reed, al uso de buffers de gran tamaño en las RNCs para evitar las pérdidas de paquetes.

La idea de que el uso de buffers de mayor capacidad, algo cada vez más habitual dado el bajo precio de la memoria, puede llegar a ser perjudicial para el retardo y la congestión en las redes puede parecer algo ‘contra-intuitivo,’ si se me permite la expresión. Pero afortunadamente las causas de este problema, que se conoce como bufferbloat y que afecta también a las redes fijas, están ahora explicadas con mucha claridad en un artículo de Jim Gettys (que fue editor de HTTP/1.1 en IETF) disponible aquí. Por lo que parece, el excesivo tamaño de los buffers confunde a los algoritmos que TCP implementa para evitar la congestión e impide que se informe a tiempo a los nodos que están generando la misma. Como se explica en el artículo, no es un problema que no se conociera o para el que no exista una solución disponible (AQM – Adaptive Queue Management), solo parece que había caído en el olvido.

Lo único constante es el cambio. Parece un tópico pero sin duda alguna afirmación, de François de la Rochefoucauld y que Heráclito en la antigua Grecia ya nos adelantaba con su “nadie se baña dos veces en el mismo río” (sobre todo si hay pirañas J) puede ser un buen resumen del informe de la Sociedad de la Información que ha sido recientemente presentado por Telefónica

Parecía que iba a ser un año de continuidad, de cubrir el expediente,  dado el elevado grado de desarrollo de algunas variables, y más aún con la crisis económica condicionando nuestras decisiones. Pero no… la velocidad no solo no aminora sino que acelera y se recordará el año 2011 como un año clave en el que se han producido avances de gran importancia tanto cuantitativos como cualitativos.

De todos ello creo que merece la pena destacar el aumento de la Internet productiva, porque tras unos años en los que el ocio ha sido el motor del crecimiento y que el resto de los servicios estaban pero no acababan de entrar a formar parte de la vida de los usuarios, al menos de una forma masiva, esto ha cambiado. Y es que este año mucha gente ha descubierto que Internet es mucho más que películas, vídeos, fotos…, y ha crecido substancialmente el número de personas que han recurrido a Internet para realizar cursos, comprar, relacionarse con las administraciones, en definitiva como herramienta en las actividades cotidianas haciéndolas más productivas. Como coautor del Informe de la Sociedad de la Información de Telefónica, en el presente post voy a poner la lupa en este hecho, ampliando la información para los que se hayan quedado con ganas de un poquito más.

Destaca como este cambio hacia la Internet productiva se ha producido en todas las franjas de edad, tanto en el género masculino como femenino y en todas las actividades (tan solo se ha producido un leve descenso entre los más jóvenes en la actividad de buscar noticias, quizás influido por los nuevos medios como las redes sociales para acceder a información). No obstante, este crecimiento no se ha producido de forma homogénea y en general los crecimientos porcentuales han sido más elevados en el género masculino y entre la población mayor. En el caso de la población mayor (de 65 años o más) destaca que en seis de las siete actividades analizadas el crecimiento es superior al 100%, y tan solo es inferior en la de acceso a contenidos audiovisuales, o sea la única que no se encuadra entre las actividades productivas.

Figura 1: Evolución de la utilización de Internet para la realización de actividades en el segmento de mayores de 65 años 

Fuente: Telefónica

De entre todas las actividades en las que Internet puede jugar un papel importante creo que merece la pena destacar recibir cursos de formación. Todos somos conscientes del  grado de exigencia de la sociedad en cuanto formación y lo importante de este aspecto para sobrevivir en un mercado tan competitivo, por eso especialmente ahora se convierte en una variable clave para poder mejorar la productividad y afrontar una situación económica delicada como la actual. Internet puede ser una herramienta muy interesante en este aspecto por lo que vamos a analizar en más profundidad cómo ha evolucionado la adopción de Internet con este fin. Como se observa en la figura 2, se ha producido un crecimiento muy importante en todos los segmentos de la población en este aspecto. Este incremento es mucho más importante, al menos en números relativos, en el segmento más maduro desde 45 años hasta más de 65, con incrementos en todos los segmentos superiores al 100%.

Figura 2: Evolución de la utilización de Internet para recibir cursos de formación 

Fuente: Telefónica

Se observa por tanto como Internet está entrando en una fase más avanzada y empieza a ser visto por muchos ciudadanos como una herramienta fundamental en su día a día. Destaca además como es esta nueva visión de Internet la que está constituyendo como el motor de crecimiento en los segmentos maduros, muy por encima del consumo de servicios audiovisuales que ha sido el principal motor en los segmentos más jóvenes.

Los días 13 y 14 de Diciembre se celebró en Madrid la V jornada STIC del CCN-CERT

El CCN-CERT es el centro de respuesta ante incidentes dependiente del Centro Nacional de Inteligencia (CNI), creado como Capacidad de Respuesta ante Incidentes de Seguridad y como CERT Gubernamental encargado de velar por la seguridad de los sistemas de toda la Administración.

Quizás esta definición no sea lo suficientemente clara. Para ayudarnos a comprender que es un CERT la web del CCN-CERT nos ofrece la siguiente definición:

El término CERT proviene de las siglas en inglés Computer Emergency Response Team y viene a definir a un equipo de personas dedicado a la implantación y gestión de medidas tecnológicas con el objetivo de mitigar el riesgo de ataques contra los sistemas de la comunidad a la que se proporciona el servicio. También es conocido por las siglas CSIRT (Computer Security and Incidente Response Team) y ofrece servicios de respuesta ante incidentes y de gestión de seguridad.

El primer CERT se creó en 1988 en la Universidad Carnegie Mellon, en Estados Unidos (propietaria de esta marca registrada), y desde entonces han ido creándose este tipo de Equipos en todo el mundo y en distintos ámbitos de la sociedad (Administración, Universidad, investigación, empresa, etc).

Más información en CCN-CERT FAQ.

Las jornadas estuvieron orientadas a la puesta en común del trabajo realizado por el CCN-CERT y todas las administraciones públicas. Según indican en la presentación de la jornada: “Durante los últimos cinco años, las jornadas STIC CCN-CERT se han convertido en una cita ineludible del personal de la Administración para la puesta en común de conocimientos, el análisis de las amenazas y el estudio de las soluciones y tendencias con las que hacer frente a estos ciberataques.“

Las jornadas no fueron de libre acceso, e incluso la primera jornada estuvo limitado el acceso a personal de la administración pública.

En esta quinta edición se presentó el Esquema Nacional de Seguridad y se trataron temas relacionados con Denegación de Servicio, sistemas SCADA, compromiso de información, APT, protocolos en infraestructuras críticas e incluso el eDNI. En la mesa redonda titulada “Necesidad en la coordinación de gestión de incidentes” han colaborado los CERTs: Andalucia-CERT; CCN-CERT; CESICAT; CSIRT-CV; INTECO-CERT; IRIS-CERT.

Este año Telefónica Digital tuvo presencia en este evento por partida doble: David Barroso y dos miembros del Equipo de Hacking, Carlos Díaz y Francisco Gómez, han tenido la oportunidad de participar tratando temas relacionados con los ataques de denegación de servicio distribuidos (DDoS) y las medidas que se pueden tomar para mitigarlos, y las capacidades de protocolos claves de Internet como el DNS en las “botnets” y el cibercrimen.

https://www.ccn-cert.cni.es/index.php?option=com_content&view=article&id=2583&Itemid=198&lang=es

En los últimos tiempos van saliendo noticias que hablan de “agujeros negros” en las comunicaciones radio, así como la posibilidad teórica de aumentar la capacidad del espectro radioeléctrico empleando “vórtices” radio. La lectura de las noticias resulta complicada, y más complicada aun la lectura de las referencias técnicas que explican los conceptos, ya que rápidamente se entra en teoría electromagnética y surgen como hongos ecuaciones vectoriales. El propósito de esta nota es intentar explicar qué es eso de los vórtices radio, y qué significa desde un punto de vista teórico y práctico el aumento de capacidad de transmisión radio al que se hace referencia.

Es bien conocido que hay fibras ópticas monomodo y multimodo. Y quizás algo menos conocido el hecho de que en las guías de onda, en los terremotos y en el sonido debajo del agua las ondas se pueden propagar de diferentes maneras. Estas diferentes maneras se llaman modos. Se puede decir incluso que diferentes modos son ondas diferentes, que se transmiten juntas.  Y ¿por qué puede haber diferentes modos? Porque la naturaleza está hecha así, y si se resuelven las ecuaciones que definen la propagación se obtienen conjuntos de soluciones, cada solución correspondiente a una manera diferente de respuesta del medio.

Pues con esta introducción, lo siguiente no debe sorprender: en el espacio libre las ondas se pueden propagar también con modos diferentes. Este es un hecho muy conocido en el campo de la óptica, pero no tan conocido en el de la radio. Y no es tan conocido porque generar y extraer estos modos diferentes en las ondas electromagnéticas requiere antenas de un tamaño muy superior a la longitud de onda. Una excepción es la de la polarización: la polarización vertical es un modo, y la horizontal otro. Y en los enlaces fijos de microondas se lleva más de cincuenta años doblando la capacidad de transmisión emitiendo en las dos polarizaciones diferentes, porque cada modo es independiente y se puede separar. No se puede hacer lo mismo en comunicaciones móviles, pero esto daría para otra entrada al blog.

Hace ya más de quince años estos diferentes modos en el espacio libre (diferentes de la propagación de toda la vida, la onda plana) se pusieron de moda en el campo de la óptica. Y ha sido cuestión de tiempo que alguien haya querido experimentar con ellos en el campo de la radio. Y por fin han conseguido hacer un experimento, al que hace referencia el hipervínculo del primer párrafo. Ha sido un experimento heroico, con una antena de dos modos muy artesanal, y por supuesto sin posibilidad de aplicaciones prácticas, pero experimento pionero y por tanto muy meritorio. Para el lector interesado, estos modos reciben el nombre de Laguerre-Gauss.

El nombre de vórtice se asocia a estos modos porque presentan la propiedad de que en el eje de propagación el campo electromagnético es nulo. Y gente con imaginación ha equiparado este nulo con un “agujero negro”, que obviamente no lo es tal. Ha habido gente imaginativa con sentido del negocio que también ha dicho “y con esto podemos aumentar muchísimo la capacidad de la radio, sin tener que comprar más espectro”. Esto también es incorrecto. Dejando aparte los problemas asociados al tamaño de una antena que soporte en las longitudes de onda radio varios modos de Laguerre-Gaus, lo que eventualmente se podría obtener es una antena muy grande con varios conectores de salida, y por cada conector de salida se obtendría la señal proviniente de un modo diferente. Una especie de generalización de la multiplexación por polarización. Y, por supuesto, esto sería eventualmente (es decir, con mucha dificultad y coste) posible en radioenlaces fijos. En comunicaciones móviles no.

En consecuencia, no podemos recomendar a las operaciones que dejen de comprar espectro por la existencia de los modos de Laguerre-Gauss.

Hace un rato me ha llegado un correo que reproduzco a continuación:

Para que el correo fuese más bonito, hasta le dije al Thunderbird que descargase la imágenes, tras verificar que, efectivamente, la descarga era de la web de la policía. Si bien a primera vista (bueno, a primera vista rápida desde una cierta distancia) el correo puede parecer legítimo, una vez nos ponemos las gafas de leer, el correo es más sospechoso que un duro de madera. No solo la palabra ‘procedimiento’ aparece escrita de tres formas distintas (una incluso correcta), sino que no se han molestado ni en disimular con el ‘adjunto’. Ya avisan de que es un “documiento”, el enlace es a un servidor web externo, y ni se han molestado en esconder el tipo del archivo (SCR).

Claro que, por otra parte, ¿por qué tiene un usuario medio, digamos mi hermana, que saber que SCR es la extensión de los salvapantallas, y que en realidad son ficheros ejecutables a los que simplemente se les cambia la extensión? Particularmente si desde Windows 200 para acá en Microsoft decidieron que eso de las extensiones era una cosa fea y cutre y decidieron ocultarlas.

En cualquier caso, no se trata hoy de despotricar contra la extendida costumbre de confundir ‘facilidad de uso‘ con ‘ocultar la información‘ sin mirar que implicaciones puede tener no mostrar la información. Y, afortunadamente para mi ordenador, mi tranquilidad mental, y posiblemente mi cuenta corriente, yo no soy mi hermana.

Ni siquiera se trata de pensar en la ironía de usar un supuesto correo de la policía para distribuir malware. Supongo que en este caso con lo que juegan más que con la curiosidad o la lujuria de los usuarios es con su mala conciencia de los mismos (posiblemente relacionado con la curiosidad o la lujuria ) y esperarán que cuando reciban el correo pensarán ‘¿que habré hecho?’ y pulsarán rápidamente el enlace sin pararse a leer el texto, ni a pensar que puñetas significará “el procedimiento de investigación de que se trata en esta conducta regional“.

Así pues hagamos un ejercicio de imaginación y pensemos que somos alguien que no sabe lo que es un SCR, y que pulsa compulsivamente en los enlaces que le vienen en los correos. Pero supongamos además que, irónicamente, estamos concienciados de que la red es un sitio peligroso y por lo tanto tenemos instalado un antivirus. Así que, confiando en nuestras medidas profilácticas, pulsamos el enlace, y descargamos el fichero.

¿Que pasará? A juzgar por los dos antivirus que yo tengo en este PC, que el ejecutable será considerado benigno y digno de confianza.

Es más, suponiendo una distribución uniforme de ventas de los antivirus, que tendremos un 88.4% de posibilidades de que el antivirus nos diga que el fichero que hemos descartado es puro y limpio, y que lo podemos ejecutar con total alegría:

Y, para eso, tres de los cinco que lo detectan deben dar falsos positivos a mansalva. Solo dos de los antivirus (cuales es irrelevante) lo identifican como un Troyano/descargador. El resto lo identifica como ‘sospechoso‘ simplemente porque está empaquetado con AsPack, es decir el ejecutable real está comprimido/cifrado dentro del ejecutable descargado. Supongo que en AsPack Software no cabrán en sí de gozo de que todo el software que sus clientes hagan, bueno o malo, sea marcado como sospechoso por algunos antivirus.

Tras esto no me queda otra que inclinarme ante los comerciales de la industria de seguridad. No se me ocurre ningún otro campo en el que se venda un producto profiláctico que consume recursos constantemente, es irritante, y que, cuando de verdad hace falta, falla en un casi 90% de los casos.

Y lo mejor de todo es que visto el enorme éxito que tiene el modelo en los PCs de sobremesa para controlar las infecciones, la industria está lanzada a toda máquina para exportar el mismo modelo hacia los nuevos dispositivos: Una búsqueda de ‘antivirus móvil’ en Google devuelve casi 40 millones de resultados. Y, solo en el primero, hay 38 antivirus para descargar.

Podría haber titulado el post como ‘No dejes que la realidad te estropee un buen titular’, pero como total parece que todo el mundo ha copiado el titular de The Register, que es justo el del post, para que molestarme. Es una de las noticias estrella del mundillo de la seguridad de hace unos días, y se puede leer en el enlace anterior por ejemplo.

Para aquellos que no tengan tiempo o ganas de leer la noticia completa, el primer párrafo lo resume muy bien:

Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that’s passing between a webserver and an end-user browser.

Ahí es nada. Hay una vulnerabilidad muy seria en prácticamente todos los sitios que usan SSL/TLS que permite a un atacante realizar ataques de Man-in-the-middle. Que es, precisamente, una de las dos cosas que se supone impide SSL.  A partir de ahí la noticia se dedica a asustarnos más contándonos que a partir de ahora (bueno, en realidad desde antes, ahora solo se ha presentado una prueba de concepto) nuestra navegación ha dejado de ser segura y vamos a tener que volver a ir al supermercado a hacer la compra a mano. Y todo porque los navegadores no implementan TLS 1.1 y 1.2. Y no lo hacen porque los desarrolladores de NSS y OpenSSL son una panda de vagos que no han implementado un estándar que tiene cinco años. Curiosamente, yo hubiese jurado que Chrome usa CryptoAPI y no NSS, pero en realidad es lo de menos.

Pero… ¿es cierta la noticia? ¿Tenemos de verdad que volver a ir al banco a hacer las transferencias en persona? ¿Que va a ser de nuestra vida online?

Pues sí, y no. Lo que no cuenta la noticia es cual es el problema real. El problema para el que se ha presentado una prueba de concepto se conoce desde el año 2002 (al menos el enlace más antiguo que yo he encontrado eshttp://www.openssl.org/~bodo/tls-cbc.txt que incluye correos de Febrero del 2002), y se debe a la forma en la que se realiza el cifrado en SSL.

De forma muy sencilla, y obviando algunas cosas, cuando se manda un mensaje cifrado normalmente el mensaje se parte en bloques de un tamaño fijo (tamaño de la clave normalmente). Hay varias formas de cifrar los bloques, a su vez. El mecanismo más sencillo es ECB (Electronic Codebook Cipher), que consiste en cifrar cada bloque de forma independiente:

Este es el mecanismo más sencillo, pero tiene un problema básico: un bloque se cifra siempre de la misma forma. Y esto da lugar a dos problemas:

• da información del contenido del mensaje
• permite ataques de texto elegido: Un atacante que capture un mensaje cifrado cuyo valor sea ‘ABCD’ no puede descifrarlo para saber que es en realidad ‘HOLA’ cifrado. Pero si puede inyectar bloques, o incluso mensajes completos, puede introducir ‘HOLA’, obtener ‘ABCD’ y así sabrá lo que se había transmitido. En un ejemplo más real, si sabemos que hay una parte del mensaje interceptado es un PIN que tiene un valor entre 0000 y 9999, y podemos inyectar bloques en el proceso de cifrado, podemos probar todos los valores y así averiguar cual era el PIN original.

Para solucionar estos dos problemas hay otros mecanismos de cifrado por bloques. El usado por SSL se conoce como CBC (Cipher Block Chaining) y podemos verlo en la siguiente figura:

 Este mecanismo de cifrado evita los dos problemas que tiene ECB: un mismo bloque de texto en claro se cifrará de forma distinta según la posición del mensaje en la que esté. Y, si además el mensaje de inicialización es aleatorio (o pseudoaleatorio), un mismo mensaje completo, cifrado con la misma clave, dará un mensaje cifrado distinto cada vez que se introduzca en el sistema. Y el problema que tiene TLS 1.0 es que usa un vector de inicialización pseudoaleatorio para el primer mensaje que se intercambia. Pero para el resto de los mensajes se usa como vector de inicialización el último bloque cifrado del mensaje anterior.

Así pues, si llamamos

• C(K,B) a la función que cifra un bloque B con clave K,
• (B1,…,Bn) a los bloques de un mensaje M
• + a la función XOR (ya, ya sé que tradicionalmente + es OR, pero no sé poner el + con un círculo en ASCII)

Entonces, los bloques cifrados son

• C1=C(K,IV+B1)
• C2=C(K,C1+B2)
• …
• Ci=C(K,Ci-1+Bi)
• …
• Cn=C(K,Cn-1+Bn)

Y, en SSL, el mensaje M’, que está compuesto por los bloques (B’1,…,B’n) se cifrará como

• C’1=C(K,Cn+B’1)
• C’2=C(K,C’1+B’2)
• …
• C’n(C(K,Cn-1+B’n)

Ahora supongamos que el que realiza el cifrado es un navegador web que usa SSL, que yo soy un pirata ruso, que creo que Bi es un PIN, y quiero verificar si el valor del PIN es 1234. Y supongamos que yo, con los superpoderes que me proporciona el ser un pirata ruso, puedo generar mensajes (o bloques) con el valor que yo quiera en el navegador del usuario. Entonces simplemente genero un mensaje cuyo primer bloque sea Cn+Ci-1+’1234′, y lo envío tal cual. El mecanismo de cifrado, amablemente, me calcula C’1=C(K,Cn+Cn+Ci-1+’1234′). O lo que es lo mismo, C’1=C(K,Ci-1+’1234′).

Entonces, si Bi=’1234′, C’1 será igual a Ci. Y ya sé el PIN. Si sé que Bi contiene el PIN, pero no es ‘1234′ basta con repetir esta operación otras 9999 veces y sacaré el PIN.

Como decía, este ataque se conoce desde el 2002, pero se creía que no era explotable porque los superpoderes de los piratas rusos no incluían el envío de paquetes escogidos desde el navegador del usuario. He encontrado un paper del 2006 que explica el problema y propone un ataque factible basado en applets en el navegador.

Y la ruptura del SSL a la que hace referencia el artículo de The Register es una prueba de concepto basada en Javascript, que lo que permite es realizar ataques de fuerza bruta remota. O sea, adivinar el PIN generando todas las opciones posibles, mandándolas cifradas como comentaba antes, y verificando en un Sniffer si el valor que se envía es el que se capturo originalmente. En la noticia dicen que funciona para extraer cookies, supongo que porque es más fácil saber en que bloques se envían las cookies.

Para que el ataque sea práctico, es necesario:

• Que la víctima descargue un Javascript malicioso. El Javascript debe quedarse corriendo en segundo plano.
• Que la víctima visite el sitio de el que el pirata quiere obtener algún dato, como por ejemplo Paypal (es el ejemplo del artículo).
• Que sea factible sacar el valor de la cookie por fuerza bruta. O tienen un valor pequeño, o tienen una estructura conocida. Por cierto, en este caso el que el cifrado sea en bloques es una ventaja para el atacante. Si los bloques son de 4 bytes, para romper un PIN de 8 dígitos hay que probar  100.000.000 de combinaciones. Solo hay que probar 20.000 combinaciones, o sea los cuatro primeros dígitos y los cuatro últimos por separado.
• Que la víctima no cierre el navegador mientras estamos haciendo el ataque.
• Y que la sesión SSL no caduque en el proceso, porque  caduca cambia la clave K.

¿Es un ataque interesante? Sí. ¿Práctico? No mucho, la verdad. Creo que sigue siendo más sencillo mandarle un correo a la víctima en perfecto castellano powered-by-Google diciéndole que vaya a piratasrus.com a cambiar la contraseña de Paypal o le cerramos la cuenta.

Fuente:

• The Register
• OpenSSL
• Citeseer

Autor: David Barroso

Cualquiera que esté metido en el mundo de la seguridad habrá escuchado o leído alguna vez (sobre todo los dos últimos años) el término APT en algún lugar. APT son las siglas de Advanced Persistent Threat, es decir, una amenaza (una persona motivada con un objetivo claro), avanzada (por el método y la técnica utilizada), y persistente (generalmente en el tiempo, pero también por la forma y los objetivos de los atacantes). Aunque realmente el término proviene del mundo militar (parece ser que fue la US Air Force la que inventó el término en el año 2006) y la amenaza puede ser de cualquier estilo, últimamente se ha asociado a los ataques por medios informáticos.

Al final después de tanto usarlas, las siglas APT han perdido todo su significado en el contexto actual en el que se mencionan, puesto que es normal encontrarlas en cualquier presentación o artículo donde se relacionan con incidentes normales, y la gran mayoría de los ataques recientes que han sufrido grandes empresas no se pueden considerar como APTs propiamente dichos aunque los atacados digan lo contrario.

La mayoría de los incidentes informáticos son ataques masivos en donde lo importante es conseguir cuantos más ordenadores infectados mejor, puesto que:

• Existirá una probabilidad mayor de que el usuario de ese ordenador infectado se conecte a páginas web ‘interesantes’ (entidades financieras, pagos on-line, subastas, loterías, páginas de compra/venta de acciones, redes sociales, etc.) para el atacante
• Podremos enviar más spam por segundo
• Lograremos tener un ancho de banda más grande para realizar ataques de denegación de servicio distribuido (DDoS)
• Ganaremos más dinero engañando al usuario de ese ordenador infectado con el pretexto de que está muy infectado y que nos tiene que comprar nuestro (fake) antivirus; o le diremos que hemos cifrado todos sus datos y que nos tiene que pagar para descifrarlos (ransomware)
• Podremos ganar más dinero con nuestras campañas de Pay-per-install, o pay-per-click (clickfraud)
• Obtendremos más proxies para poder anonimizar nuestras operaciones posteriores
• Cualquier otra idea malévola que se nos ocurra

En definitiva, son ataques indiscriminados que generalmente instalan algún tipo de malware, y muchas veces revenden el control de ese ordenador infectado a terceros; generalmente va a existir una conexión a un panel de control (C&C) para poder gestionar el ordenador remotamente, y ese C&C podrá estar en cualquier país del mundo, y muchas veces en un bullet-proof hosting.

¿Y qué tiene que ver con los APTs? Realmente el problema es que cuando alguien encuentra una máquina infectada, con un malware que está haciendo cualquiera u otra de las actividades anteriores, y se conecta a un C&C remoto para enviar los datos, muchas veces la presión, histeria, o el intento de no mancillar la reputación obliga a decir que ha sido un ataque muy avanzado dirigido al robo de información de una empresa/gobierno, acusando directamente al grupo/país que más de moda esté en ese momento (Anonymous, Lulzsec, China o Irán, por ejemplo).

El resto de ataques que no son masivos e indiscriminados, sí que son ataques dirigidos, pero muchas veces distan de ser un APT en el sentido estricto de la palabra. Muchos ataques de robo de información mediante SQL Injection, Remote File Inclusion (RFI), o servicios mal configurados son ataques dirigidos, pero la mayoría de las veces son simples (aunque eficaces). Y ya por fin, los que quedan, podríamos considerarlos APTs, donde generalmente el acceso a información confidencial es la principal razón de estas amenazas.

Los verdaderos APTs son muy difíciles de detectar, y sobre todo, muy difícil de responder ante ellos, con lo que muchas veces sólo la pericia del equipo de respuesta a incidentes podrá contrarrestar los efectos de tales ataques; muchas de las herramientas de seguridad que tenemos actualmente no nos servirán de mucho para detectar a tiempo estos ataques, y tendremos que fijarnos en los pequeños detalles (con un foco importante en network security monitoring - conoce lo que tus sistemas y redes suelen hacer, e investiga si de repente ves algo nuevo) para poder enlazar todos los indicios que nos lleve a detectar un ataque de estas características.

El problema es que en la industria de seguridad la palabra APT se utiliza hoy en día como se utilizaba la palabra zero-day (0-day), donde muchos fabricantes se suben a la ola y aseguran que su producto detecta ya no sólo contra zero-days, sino también contra APTs. Algunos otros fabricantes, aún sabiendo que están cometiendo un grave error, incluyen también el tema de los APTs en su estrategia de marketing, puesto que hoy en día parece que tu producto no funciona si no es capaz de parar todo lo que aparezca.

En resumen, las siglas APT,como la palabra zero-day, cyber-perl harbour,cyber-9/11, etc. son palabras que se utilizan generalmente con un objetivo totalmente diferente al que fueron concebidas, con lo que es necesario cuidar nuestro lenguaje para no caer en malinterpretaciones.

La eterna discusión entre full-disclosure vs responsible disclosure tiene un nuevo área relativamente reciente: la protección de infraestructuras críticas (CIP). Es bastante común, que cada cierto tiempo se vuelva a discutir la mejor forma de reportar una vulnerabilidad a un fabricante, puesto que a día de hoy, todavía no se ha institucionalizado un procedimiento que pueda satisfacer a ambas partes (la persona que encuentra la vulnerabilidad, y el fabricante).

Existe todo tipo de alternativas, sin ser ninguna más exitosa que otra: agradecer al investigador su ayuda (como por ejemplo Microsoft), pagarle una determinada cantidad de dinero (Google), o simplemente, utilizar alguna compañía que funciona como broker para pagar las vulnerabilidades (iDefense VCP o Tippingpoint ZDI por ejemplo). Pero la realidad es que el sistema no funciona, y ejemplos como el del año pasado de la vulnerabilidad descubierta por Tavis Ormandy en Windows, es el ejemplo perfecto que demuestra que es necesario tener algún procedimiento que contente a todas las partes.

A día de hoy lamentablemente algunos fabricantes no consideran que la seguridad es un elemento crítico para no poner en riesgo a sus usuarios (la lista de ZDI sobre las vulnerabilidades aún no parcheadas es bastante ilustrativa), y por el otro lado, algunos investigadores también piensan que los fabricantes deben cumplir con sus exigencias de forma inmediata, llegando incluso a extorsionar al fabricante. Si bien han existido siempre intentos de procedimentar el reporte de vulnerabilidades (desde el famoso procedimiento de RFP, pasando por un intento del IETF, Responsible Vulnerability Disclosure Process, que acabo siendo la base de un procedimiento de la Organization for Internet Safety, hasta la iniciativa de No More Free Bugs promovida por varios investigadores).

Si nos movemos en el campo de la protección de las infraestructuras críticas, recientemente estamos viendo lo mismo que ocurrió hace ya varios años: después de intentar hacer las cosas bien, al ver que a menudo no se obtiene ningún resultado, nos encontramos con posiciones como la de Digital Bond, donde su política de reporte de vulnerabilidades es tan simple como: haremos lo que nos de la gana; cansados de ver cómo los grandes fabricantes industriales, después de todos los ríos de tinta que han provocado incidentes como Stuxnet o las vulnerabilidades encontradas por Dillon Beresford, parece que no reaccionan, ni siquiera cuando se involucra al ICS-CERT (puede que incluso el fabricante desee denunciarte).

Al final del día, lo que importa es cómo cada fabricante se preocupa de manejar y coordinar estas incidencias (la comunicación con los investigadores y empresas), puesto que, si por fin nos hemos dado cuenta que ninguna de las políticas de reporte de vulnerabilidades globales funciona, es trabajo de cada fabricante organizar su propia política que sea de gusto de ambas partes. Por poner un ejemplo, Mozilla, Barracuda, Google, FaceBook o Twitter ya lo han hecho, y no todas ellas pagan por vulnerabilidad encontrada, sino que algunas simplemente reconocen la ayuda.

En definitiva, más vale prevenir que curar, y es necesario que todas las grandes empresas tengan en marcha una política clara y publicada sobre las vulnerabilidades que terceras personas encuentren sobre sus productos, servicios, o simplemente, sobre sus portales web, y que se reconozca también la labor de las personas anónimas o no, que, positivamente, colaboran en la mejora de la seguridad en la red.

El martes salió la noticia de que se había detectado en Irán un ataque de suplantación SSL contra los usuarios que querían conectarse a la web de Gmail.

Se trata de un ataque man-in-the-middle en el que se emplea un certificado falso. Cuando el usuario intenta conectarse a Google de forma segura, en realidad se conecta al atacante, que para establecer la conexión le envía un certificado falso diciendo que es Google. La autoridad certificadora es legítima (DigiNotar), pero DigiNotar no tiene autoridad para expedir certificados de Google.

El problema es que en algunos sistemas y navegadores se chequea que la autoridad certificadora es legítima, pero no se chequea que además de ser legítima tenga autoridad para emitir ese certificado en particular.

El resultado en esos navegadores es que el usuario no percibe absolutamente nada y cree estar en una conexión segura con Google, cuando en realidad está en una conexión segura con el atacante (que a su vez establece una conexión segura con Google para redirigirle el tráfico y que el usuario no perciba nada). Con ello, el atacante tiene acceso a todo lo que circule por la conexión (usuario, contraseña, correos enviados o leídos, destinatarios, etc.). También podría manipular la conexión para enviar información falsa al usuario, ocultarle información, suplantar al usuario para enviar información en su nombre, etc.

 Si el navegador está programado correctamente, en estos casos debe generar una alerta de seguridad para avisar al usuario (otra cosa es que el usuario decida ignorar la alerta y conectarse de todos modos…)

Ayer jueves nos enteramos que además de Gmail y otros servicios de Google, también han sido atacadas por el mismo sistema las conexiones de usuarios iraníes a Yahoo, Mozilla y WordPress, entre otras. Se sospecha que puede estar un Gobierno (presumiblemente el iraní) detrás del ataque.

 La entidad certificadora (DigiNotar, de Holanda) ha reconocido que le han robado una docena de certificados en un ataque que sufrió en julio de hackers iraníes. Mientras se resuelve el problema, tanto Google (Chrome), como Microsoft (Internet Explorer) como Mozilla han retirado a DigiNotar del listado de autoridades de certificación de confianza.

El problema aparece con Mac OS X, ya que a raíz del problema anterior se ha descubierto un bug por el cual Mac OS X no es capaz de desconfiar de certificados emitidos por una Entidad revocada por el usuario. Esto significa que, hasta que se resuelva el problema, se recomienda a los usuarios que no se fíen de los sitios web firmados por DigiNotar cuando se navegue con Apple Safari…

Por otra parte, Apple también ha tenido este mismo problema con el iOS, ya que no chequeaba en las conexiones que la autoridad certificadora realmente tuviera autoridad para emitir los certificados que enviaba al terminal. Esto afecta tanto a iPad como a iPhone en las versiones anteriores al iOS 4.3.5

Así que si el iPhone (o la iPad) tiene una versión de SO anterior a la 4.3.5, cuidado…

Por cierto, el jailbraking más sencillo del iPhone se hace hasta la versión 4.3.3, con lo que el que quiera hacer jailbraking en su iPhone debe saber que va a tener este bonito agujero de seguridad en sus conexiones SSL…

]]> http://www.lacofa.es/index.php/general/apple-y-los-certificados-falsos-2/feed 0 http://www.lacofa.es/index.php/agenda/se-donde-has-estado http://www.lacofa.es/index.php/agenda/se-donde-has-estado#comments Wed, 17 Aug 2011 09:59:57 +0000 cplaza http://www.lacofa.es/?p=3448 Autor: Carlos Plaza

En Internet muchos de los dispositivos diseñados para hacer el “bien” se utilizan para hacer el “mal” cuando hablamos de seguridad y privacidad.

Por ejemplo, el hecho de que la petición http incluya información sobre el tamaño de pantalla,  versión e idioma del navegador o las fuentes disponibles, etc., se realizaba para que los sitios web pudieran personalizar la distribución y localización del contenido ofrecido.

Sin embargo, esta información también se utiliza para obtener la huella digital de dispositivos con el fin de rastrear a los usuarios.

De la misma manera, la característica que se suele utilizar, mostrando mediante distintos colores un enlace visitado y no visitado ha sido empleado para “robar historiales”, por ejemplo una página web sospechosa contiene una lista de enlaces, y con JavaScript se revisa el color de los enlaces para saber si has visitado una de esas webs.

De esta manera, esa web puede aprender “cosas interesantes” como bancos (de datos)  visitados para identificar ataques “phising”

 Existen incluso empresas que venden productos o servicios que son utilizados por programadores de la Web para “robar historiales” o empresas que quieren saber si un usuario que visita su web ha visitado antes otras webs con información acerca de la empresa (Tealium).

Este dispositivo se ha extendido por comprometer la privacidad del usuario de una forma sofisticada, según han publicado   investigadores de la Universidad de Stanford  recientemente: un profundo estudio de una empresa rastreadora online la cual comprueba si el usuario ha visitado alguna página web de una lista de más de 15000 enlaces, divididos cuidadosamente en categorías como compras de grupo, aplicaciones para casa ,coches, o incluso información delicada como la salud o asuntos financieros…

¿Cuál es la protección de usuario disponible?

Navegadores como Firefox incorporan en sus últimas versiones un seguro para protegerse del “robo de historiales”, aunque nunca se garantiza al 100%  que los asaltantes no sean capaces de burlar la seguridad( por ejemplo, en vez de utilizar JavaScript utilizan máscaras de pantalla para los enlaces visitados)… De hecho, en la comunidad Mozilla han tardado unos años en elegir un mecanismo, ya que no había una opción clara para eliminar el ataque sin afectar a otras funcionalidades.

Así que no es una mala idea utilizar algunos complementos gratis- como Ghostery  u otras herramientas que previenen el rastreamiento y evitan la ejecución de comandos por parte de rastreadores bloqueados- o NoScript para bloquear /permitir comandos de forma selectiva. Y por supuesto, configurar tu navegador para eliminar el historial una vez terminado.