Saltar al contenido

Actualización de seguridad para iPhone 2G y para iPod touch

Apple lanzó el pasado viernes la versión 2.0 del firmware para los dispositivos iPhone 2G y iPod touch. La actualización incluye parches para un total de trece problemas de seguridad que podrían ser aprovechados por un atacante remoto para acceder a información sensible, falsificar ciertos datos, provocar que el sistema deje de responder o incluso ejecutar código arbitrario en un dispositivo vulnerable.

De los trece fallos de seguridad corregidos, ocho corresponden al navegador Safari y otros tres a WebKit el motor de código abierto en el que se basa el navegador de Apple. De los dos restantes, uno está localizado en el kernel de sistema operativo y el otro en CFNetwork.

A continuación se describen con brevedad todos los problemas solventados, que no afectan al modelo de iPhone 3G que fue lanzado a la venta también el pasado viernes, puesto que éste ya trae de serie la versión 2.0 del firmware.

1- Un fallo en CFNetwork que podría permitir que un servidor proxy HTTPS falsificase ciertas páginas web seguras.

2- Un problema en el Kernel al manejar ciertos paquetes IP que podría provocar que el dispositivo se reiniciase al intentar procesar un paquete especialmente manipulado.

3- Un fallo en Safari haría que se interpretasen los espacios entre signos ideográficos codificados con Unicode en la barra de direcciones, lo que podría permitir la falsificación de URLs.
Actualización de seguridad para iPhone 2G y para iPod touch

Cross-Site Scripting a través de Outlook Web Access en Exchange Server

Dentro del conjunto de boletines de seguridad de junio publicado el pasado martes por Microsoft y del que ya efectuamos un resumen, se encuentra el anuncio (en el boletín MS08-039) de una actualización para Exchange Server que solventa dos vulnerabilidades que podrían ser aprovechadas por un atacante remoto para realizar ataques de cross-site scripting.

* La primera vulnerabilidad está causada porque Outlook Web Access (OWA) para Exchange Server no valida de forma suficiente los campos del email al abrirlo en una sesión individual de OWA. Esto podría ser explotado por un atacante remoto para acceder a los datos de la sesión individual del cliente de OWA, permitiendo una escalada de privilegios.

Cross-Site Scripting a través de Outlook Web Access en Exchange Server

Escalada de privilegios en Microsoft SQL Server

Dentro del conjunto de boletines de seguridad de junio publicado el pasado martes por Microsoft y del que ya efectuamos un resumen, se encuenta el anuncio (en el boletín MS08-040) de una actualización para Microsoft SQL Server que solventa cuatro vulnerabilidades que podrían ser aprovechadas por un atacante remoto para escalar privilegios y ejecutar código arbitrario.

  • * La primera vulnerabilidad está causada por la forma en la que SQL Server administra la reutilización de las páginas de memoria. Al realojar memoria, SQL Server falla al inicializar las páginas de memoria. Esto podría causar una revelación de información.
  • * La segunda vulnerabilidad está causada por una comprobación de entradas insuficiente en la función de conversión en SQL Server. Esto podría causar un desbordamiento de búfer y permitir a un atacante remoto escalar privilegios y ejecutar código arbitrario.
  • Escalada de privilegios en Microsoft SQL Server

Contenidos Criptored Junio 2008

Breve resumen de las novedades producidas durante el mes de junio de

2008 en CriptoRed, la Red Temática Iberoamericana de Criptografía y Seguridad de la Información.

1. NUEVOS DOCUMENTOS Y SOFTWARE PARA DESCARGA LIBRE DESDE CRIPTORED Y LA CÁTEDRA UPM APPLUS+

* Actualización Artículo Proceso Implementación Infraestructura de Clave Pública (María Paula Espinoza, artículo pdf, 15 páginas, Ecuador) http://www.criptored.upm.es/guiateoria/gt_m538b.htm

* ISO 27001 y las PyMEs (Alejandro Corletti, artículo pdf, 6 páginas,

España)

http://www.criptored.upm.es/guiateoria/gt_m292k.htm

* El nicho de mercado principal de ISO-27001 son las PyMEs (Alejandro Corletti, artículo pdf, 2 páginas, España) http://www.criptored.upm.es/guiateoria/gt_m292l.htm

* Metodología de implantación y certificación en las PyMEs (Alejandro Corletti, artículo pdf, 5 páginas, España) http://www.criptored.upm.es/guiateoria/gt_m292m.htm

* Problemática, ventajas y desventajas de ISO-27001 en PyMEs (Alejandro Corletti, artículo pdf, 5 páginas, España) http://www.criptored.upm.es/guiateoria/gt_m292n.htm

* Análisis forense de dispositivos móviles con Symbian OS (Rodrigo Hernández, Carlos Agualimpia, Coord. Jeimy Cano, artículo pdf, 6 páginas, Colombia) http://www.criptored.upm.es/guiateoria/gt_m142e1.htm

* 316 documentos para su libre descarga http://www.criptored.upm.es/paginas/docencia.htm#gteoria

Contenidos Criptored Junio 2008

Mitos y leyendas: «Compruebe el candadito del navegador para estar seguro» II (Troyanos)

Si mezclamos SSL con troyanos, el resultado es una completa confusión por parte del usuario. Un sistema troyanizado es un sistema en el que no se puede confiar, muestre el navegador una conexión segura o no. De nuevo, esta recomendación del candadito (válida, pero que necesita muchos matices) se convierte en un arma de doble filo. Si un sistema queda infectado, ya no solo puede aparecer el candadito, sino que el certificado puede ser válido y de hecho, estaremos en la página legítima del banco, pero nuestros datos pueden ser robados.

 

Las técnicas que usan los troyanos más difundidos hoy día, pueden invalidar la recomendación de la comprobación de la conexión segura. De hecho, los troyanos permiten la conexión a la página real del banco, pero pueden estar robando la información entre bambalinas gracias a diferentes técnicas.

 

Delephant

Mitos y leyendas: «Compruebe el candadito del navegador para estar seguro» II (Troyanos)

Mitos y leyendas: «Compruebe el candadito del navegador para estar seguro» I (Phishing)

Via: HispaSec
Esta frase es una de las recomendaciones de seguridad básicas que todo sistema de banca online ofrece a sus usuarios. Ha sido uno de los consejos estrella para intentar evitar el phishing en los últimos años.
En realidad, SSL podría ser un arma poderosa contra le phishing pero no ha sido así. En parte porque no se entiende la tecnología, en parte porque se ha vuelto tan popular y barata que ha dejado de tener el efecto deseado. El SSL y «el candadito del navegador» simplemente ya no significan nada. Tanto, que se ha tenido que crear un nuevo concepto de certificado. Un consejo obsoleto que ofrece una falsa sensación de seguridad de la que se están aprovechando los phishers.

¿Para qué sirve el SSL?

Incluso entre los profesionales de la informática existe cierta confusión al entender el SSL y qué significa que se navegue bajo el protocolo HTTPS. Se sabe que es un «canal seguro», pero ¿seguro por qué?
Sin entrar en tecnicismos, hay que decir que SSL debería cumplir dos funciones. Primero es una conexión cifrada sobre un canal público. Cifra la conexión de forma que en teoría sólo el servidor y el navegador pueden acceder al flujo de datos entre ellos. Lo que olvidan muchos es que SSL también autentica al servidor. Nos ayuda a estar seguros de que el servidor es quien dice ser y también que pertenece a la empresa a la que debería pertenecer. Esto lo hace gracias a la criptografía de clave pública, que garantiza que el servidor al que nos conectamos tiene la clave privada que corresponde con la pública que dice tener.

Para la parte de autenticación, los servidores con SSL activo ofrecen al navegador un certificado para que lo compruebe, que es como una especie de DNI. En él, una autoridad (Verisign, Godaddy….) certifica con su firma que la clave pública realmente pertenece al sitio. Para conseguir un certificado, el dueño del servidor ha generado dos claves, y la pública la ha enviado a estas autoridades certificadoras para que la firmen, junto con otras pruebas de identidad como pueden ser documentos de empresa u otros, dependiendo del criterio del certificador (y de lo que se quiera pagar). Cuando un usuario se conecta a la página, de forma transparente el navegador comprueba que el certificado es correcto.
Siguiendo con la analogía del DNI, sólo el Estado (las autoridades
certificadoras) puede certificar (firmar critográficamente) que la fotografía y los datos (la clave pública) pertenecen a una persona (servidor web de esa empresa).

¿Es efectivo contra el phishing?

Idealmente, autenticar al servidor es la solución contra el phishing, pero no es así. El usuario medio a veces comprueba que hay un candadito, o una conexión HTTPS al visitar una web. Con esta mínima comprobación, comprende que está sobre un sitio seguro (se le ha repetido hasta la
saciedad) y confía en la página en la que va a introducir sus datos. Muy pocos confirman que el certificado es válido. Para ello abría que hacer doble click sobre el candado y comprobar la ruta de certificación, que debe culminar en una autoridad certificadora que ha firmado el certificado. Pero, hoy en día, incluso si el certificado es válido, es posible que no se esté sobre la página que se desea. Para evitar esto, el usuario debería interpretar además qué información está ofreciendo esa cadena de certificación y a qué datos está asociado. El conjunto de usuarios que llega a este punto es mínimo.

Lo que los phishers están haciendo cada vez con más frecuencia, es comprar certificados que sólo certifican que el dominio pertenece a quien lo compró. La autoridad certificadora no pide más documentos ni pruebas, sólo que el dominio te pertenece. Los hay por 20 euros.
Empresas como Godaddy certifican que el dominio te pertenece, y con ello el navegador aparecerá con el candadito y bajo el protocolo HTTPS.
Efectivamente, la información irá sobre un canal seguro, y el servidor será el del auténtico phisher, que ha podido comprar un dominio con un nombre parecido al legítimo, o añadir en la URL dominios de tercer nivel para confundir.

Existen certificados de hasta 300 euros al año, y estas autoridades certifican el dominio, los datos… es un proceso caro y costoso que se paga. Pero como se ha dicho también los hay «light» en los que toda la gestión se hace online y con una mínima comprobación. Esto es legítimo y válido, pero llevado al contexto del phishing, resulta ventajoso para los atacantes. Los phishers pagan 20 euros (con tarjetas que a su vez han robado) y tendrán un candadito y una conexión HTTPS en su phishing.
El nivel de credibilidad aumenta con respecto a sus víctimas.

El SSL se ha convertido en algo tan popular y accesible que ya no es exclusivo de los sitios seguros, y lo que con tanto esfuerzo se ha conseguido inculcar en el subconsciente del usuario: «si tiene candadito, es seguro», se ha vuelto en contra. Por tanto, los phishings bajo conexión segura siguen aumentando con éxito.

Extended Validation Certificates al rescate

Mitos y leyendas: «Compruebe el candadito del navegador para estar seguro» I (Phishing)

Mitos y leyendas: Seguridad en ActiveX I (Introducción)

Via: Hispasec

ActiveX es una tecnología propia de Microsoft que con el tiempo ha sido clasificada prácticamente de maldita en cuestión de seguridad. Los numerosos problemas tanto en la tecnología en sí como en los programas que la han usado, han hecho que se gane esta fama a pulso. ¿Cuáles son los riesgos y problemas de seguridad que presenta ActiveX realmente? ¿En realidad es tan peligrosa? Como siempre, no hay respuestas absolutas y todas estas cuestiones son bastante discutibles.

¿Qué es?

De forma resumida, ActiveX es una tecnología de Microsoft. Es una librería (básicamente un ejecutable) con funciones, como otro cualquiera, con la peculiaridad de que implementa una interfaz llamada IDispatch que permite al «objeto» interactuar de una forma concreta (más

abstracta) con el programa que lo aloja (llamado contenedor). Por tanto no son programas «independientes» y suelen crearse con cualquier lenguaje que admita el modelo COM. «Físicamente» tienen forma de librería DLL o OCX. Internet Explorer o Office son programas contenedores que admiten esta tecnología. Un componente ActiveX es pues, código ejecutable (desarrollado por y para Microsoft) encapsulado en un objeto desarrollado mediante esos estándares. De esta forma al tener este código encapsulado, se facilita su portabilidad y reutilización.

Así, es posible usar un objeto ActiveX (llamar a sus funciones) insertándolo en cualquier aplicación que lo soporte, independientemente del lenguaje con el que haya sido creado el control ActiveX. Un ejemplo común es usarlos para interactuar con Internet Explorer y el sistema, llamándolos a través de JavaScript. Un típico ejemplo de llamada a un objeto ActiveX a través de una página es:

<HTML><object id=»nombrecualquiera»

classid=»CLSID:012345567-12345-1234-A1234-F1234567789A»></object>

<script language=»javascript»>

nombrecualquiera.FuncionCualquieraDentroDelActiveX(a, b); </script></HTML>

Mitos y leyendas: Seguridad en ActiveX I (Introducción)

España, los novenos del mundo en número de sistemas zombi

Via HispaSec

Según G Data, España ocupa el noveno puesto mundial en número de sistemas zombi, casi en empate técnico con Estados Unidos y Rusia. Lo que además, quiere decir que somos grandes productores de spam, una de las funciones más importantes de los sistemas secuestrados. Aun así, se siguen ofreciendo los mismos consejos de hace años para paliar la plaga.

El informe está realizado por G Data según la geolocalización de las direcciones IP. El número de zombis utilizados cada día ronda una media de 350.000, con momentos en los que se utilizan hasta 700.000 ordenadores para los distintos fines de estas botnets. De los diez países más infectados, la mayoría pertenece a Europa. Según el informe, es el continente que goza de líneas de conexión más rápidas y mayor número de ordenadores.

Los países con más ordenadores zombi se reparten así:

  • Alemania: 10 %
  • Italia: 10 %
  • Brasil: 8 %
  • Turquía: 8 %
  • China: 6 %
  • Polonia: 6 %
  • Estados Unidos de América: 5 %
  • Rusia: 5 %
  • España: 5 %
  • India: 4 %

España, los novenos del mundo en número de sistemas zombi

Mitos y leyendas: Las contraseñas en Windows III (LM y NTLM)

Microsoft ha mejorado gradualmente la seguridad de su fichero SAM, pero también ha mantenido la compatibilidad hacia atrás con sistemas inherentemente inseguros como Windows 9x. Con la cada vez mayor sofisticación de herramientas capaces de atacar por fuerza bruta los hashes LM y NTLM, el cifrado (sobre todo el LM) se ha vuelto virtualmente inútil si la contraseña no es realmente entrópica y compleja. En Vista, por fin, se ha eliminado al menos el eslabón más débil, el hash LM.

Si se estudia el resultado de un volcado online u offline (tras ‘saltarse’ el syskey) de la SAM, veremos algo así:

Administrador:500:42f29043y123fa9c74f23606c6g522b0:71759a1bb2web4da43e676d6b7190711:::

que oculta en realidad el hash LM de la contraseña

(42f29043y123fa9c74f23606c6g522b0) y el hash NTLM

(71759a1bb2web4da43e676d6b7190711)

Mitos y leyendas: Las contraseñas en Windows III (LM y NTLM)