martes, 25 de febrero de 2014

Apple iPhone vulnerabilidad SSL: ¿cómo sucedió, y lo que sigue?


Vulnerabilidad SSL de iPhone, iPad y en Mac OS X apareció en septiembre de 2012 -, pero la causa sigue siendo un misterio tan antiguo empleado llama a la falta de pruebas de "vergonzosa"

Vulnerabilidad de Apple SSL
Vulnerabilidad SSL de Apple todavía está activo en Safari en Mac OS X, como se muestra en el sitio gotofail.com. Fotografía: Dominio público
Apple ha publicado una corrección urgente de una vulnerabilidad en su código (Secure Sockets Layer) SSL, utilizado para crear conexiones seguras a los sitios web a través de Wi-Fi u otras conexiones, para sus dispositivos iPhone, iPad y iPod Touch.
La solución, que ya está disponible tanto para iOS 6 iOS y 7, es un defecto que parece haber sido introducido en un cambio de código hecha antes del lanzamiento de iOS 6.0.
El fallo también afecta a los ordenadores Mac con Mac OSX - para el que no hay aún anunciada revisión, aunque Apple dice uno es "muy pronto".
El error, y su descubrimiento, plantean una serie de preguntas. Esto es lo que sabemos, lo que no sabemos, y lo que esperamos saber. (Apple no quiso hacer comentarios en relación a una serie de preguntas que ponemos sobre la vulnerabilidad.)

¿Cómo puedo comprobar si estoy vulnerable?

Ir a gotofail.com y ver cuál es el mensaje que recibe. Si todo va bien obtendrá un mensaje ecologista. En un dispositivo iOS, obtendrá una advertencia para actualizar. Si estás en un Mac, usted obtendrá ya sea un mensaje verde (su sistema es seguro) o un mensaje de color amarillo (en un navegador seguro señalando que otras aplicaciones podrían ser vulnerables) o un mensaje de color rojo (que le dice que parchear su navegador).

¿Qué debo hacer?

Si utiliza un iPhone, iPad o iPod Touch, actualice su software operativo. Ir a Ajustes -> General -> Actualización de Software. Para los dispositivos que utilizan iOS 7, la actualización a iOS 7.0.6, para los dispositivos de iOS 6, que no se pueden actualizar a iOS 7 (el iPhone 3GS o iPod Touch 4G), la actualización a 6.1.6.
Tenga en cuenta que Apple no está ofreciendo una actualización de iOS 6 para los dispositivos que se pueden actualizar a iOS 7 (iPhone 4, iPad 2, etc). Para aquellos, sus únicas opciones son para actualizar, o vivir peligrosamente.
Si usted está usando un Mac en una versión anterior del sistema operativo, es decir, 10.8 ("León de la Montaña") o una versión anterior, estás a salvo.
Si usted está usando un Mac en el más nuevo OS, 10.9 (también conocido como "Mavericks"), no utilizar Safari para conectarse a sitios web seguros hasta que haya una actualización. Utilice Mozilla Firefox o Chrome de Google: utilizan su propio código para conectarse a sitios web seguros. No se error se ha encontrado que en.

¿Qué hizo el error?

En teoría (y tal vez, en función de que lo sabía, en la práctica) que podría permitir que sus conexiones a sitios seguros para ser espiado y / o sus datos de acceso capturados. Actualización del software impide. El fallo afectó a la conexión cifrada SSL / TLS a sitios remotos.

¿Cuál es la importancia de SSL / TLS?

Cuando el dispositivo (portátil o PC) se conecta a un sitio web utilizando el método de SSL / TLS (Secure Sockets Layer / Transport Layer Security), el sitio presenta una cadena de cifrado "certificado" que identifica a sí mismo y la autoridad que emitió el certificado. Su dispositivo ya dispone de una lista de autoridades que gozan de la confianza de emisión, y se comprobará el nombre del sitio y el certificado se presenta con esa autoridad.
Es un proceso de cuatro pasos: 
• Sitio presenta una cadena de certificados 
• Certificado de su dispositivo comprueba del sitio coincide con el nombre del sitio que está en 
• Su dispositivo verifica que el certificado proviene de autoridad emisora ​​válido 
• Su navegador verifica que la firma cadena de certificado coincide con la clave pública del sitio .
En teoría, un certificado que tiene el nombre equivocado para el sitio, o que no ha sido emitido por la autoridad, o que está fuera de fecha, no será de confianza. En este punto, usted obtendrá un aviso en su navegador que le dice que hay algo malo y que no se debe proceder o sus datos podría estar en riesgo.
Un certificado falso podría significar que el sitio que se está conectando realmente está siendo dirigido por alguien que quiere recoger sus datos de acceso de los usuarios - como ha ocurrido en Irán. En 2011, el gobierno de ese país se calcula que han utilizado un certificado expedido por una autoridad certificada subvertido para configurar un sitio que (a través de la desviación DNS) podría pretender ser gmail.com de Google - y capturó los datos de los disidentes que pensaban que estaban ingresando a el sitio .
Así que es importante que el dispositivo puede autenticar certificados SSL correctamente. A veces usted se encontrará con los sitios donde se obtiene una advertencia de certificado, pero que decir que usted debe confiar en él (por ejemplo, porque se trata de una filial con un nombre diferente de la que posee el certificado). Tenga cuidado. No aprobaremos certificados sin ser cauteloso.

¿Cuál fue el error?

Debido a una reiterada línea singe de código en una biblioteca de Apple, casi cualquier intento de verificar un certificado en un sitio tendría éxito - si o no la firma del certificado era válido. Sólo sería un error si el certificado en sí no era válida (debido a ser fuera de fecha, por ejemplo).
El error está en el código de abajo: es la segunda "Ir a fallar;", y se llevará a cabo en todas las circunstancias.
estática OSStatus 
SSLVerifySignedServerKeyExchange (SSLContext * ctx, bool isRsa, SSLBuffer signedParams, 
uint8_t * firma, UInt16 signatureLen) 

OSStatus err; 
... 
if (! (err = SSLHashSHA1.update (& hashCtx, y serverRandom)) = 0) 
Ir a fallar; 
si ((err = SSLHashSHA1.update (& hashCtx, y signedParams)) = 0!) 
Ir a fallar; 
Goto fallar; 
if ((err = SSLHashSHA1.final (& hashCtx, y hashOut)) = 0!) 
Ir a fallar; 
... 
falte 
SSLFreeBuffer (& signedHashes); 
SSLFreeBuffer (& hashCtx); 
retorno err; 
}

¿Cuándo apareció el error?

En iOS 6.0, que se hizo pública en septiembre de 2012. Todavía no está claro exactamente cuándo apareció el error en Mac OSX, pero es probable que sea a la vez, ya que los sistemas operativos móviles y de escritorio utilizan árboles de códigos comunes. El error no estaba en la versión final de iOS 5, 5.1.1, lanzado 05 2012 . El mismo código, aparentemente se ha llevado adelante a través de iOS en 7 y Mac OSX 10.9, es incluso en las últimas versiones de iOS 7.1 , que aún está en beta.
El diff de las dos versiones de código muestra la adición de la declaración adicional en la línea 62:

Código SSL diff de Apple
SSL / TLS código de verificación de Apple, que muestra las diferencias entre las versiones. Las líneas rojas se eliminaron en la actualización, se añadieron las líneas verdes. El cambio fundamental que se rompió SSL es la línea 62. Fotografía: Dominio público

(Las líneas rojas son eliminados en el código actualizado, se añaden las líneas verdes.)
No es una diferencia obvia, a menos que estés en busca de ella, en cuyo caso, se destaca como un pulgar dolorido para cualquier programador.

¿Cómo surgió el error llegar?

Aquí tenemos dos teorías divergentes: accidente o conspiración. O es un error estúpido en el interior de manzana, o es un plan nefasto por la NSA (o los demás?) Para atrapar a las comunicaciones objetivos "mediante la plantación de una puerta trasera en una pieza clave del código.
Argumentando en contra del plan de la conspiración es el hecho de quede Apple publica este código en su página de código abierto . Sobre la base de que "muchos ojos hacen bichos poco profunda", y que toda la Internet ha sido capaz de mirar a esta epopeya "Ir a fallar" para las edades. Si la NSA pone sus puertas traseras secretos al descubierto de esta manera, lo que espera de ellos que se pueden encontrar mucho más rápido.
Argumentando por conspiración infame es - bueno, no mucho. Apple debería haber encontrado, pero no lo hizo, ya sea de sus compiladores (GCC y Clang) debería haber tirado un error, pero las pruebas de otros ha demostrado que no tiene a menos que usted tenga una bandera de advertencia en particular (por "código inalcanzable" ) establecido. Un compilador que apuntaba a "código inalcanzable" (es decir, un segmento de código que nunca se activó porque se encuentra debajo de una desviación de código que se aplica siempre) habría cogido.
Un ex empleado de Apple que trabajó en Mac OSX dijo a The Guardian que es "muy poco probable, al menos en circunstancias normales" que la falla se añadió maliciosamente. "Hay muy pocas personas en cualquier equipo dado a Apple, y así conseguir cambios perdidos en la confusión sería difícil. La otra cara es que no hay fuertes controles de consistencia / integridad internas sobre la base de código, así que si alguien era lo suficientemente inteligente como para subvertir los procesos normales no habría maneras fáciles pulg "
Pero, el programador agregó, "este cambio no destaca especialmente como maliciosos por naturaleza." La forma es casi seguro que pasó es que fue un error de copiar / pegar, o un problema de fusión (entre dos ramas de código) que pasó desapercibida - "dos cambios similares podrían causar un conflicto" (donde el código tiene un flujo lógico) "y en la resolución de este conflicto un ingeniero podría haber cometido un error."

¿Qué dicen los programadores?

Un ex empleado de Apple que trabajó en Mac OSX, incluyendo actualizaciones de envío y las actualizaciones de seguridad, dijo a The Guardian que Apple va a ser capaz de identificar quién hizo el check-in de código que crea el error. "Si bien la gestión de código fuente está sobre una base del equipo por equipo (no hay política en toda la compañía), casi todos los equipo utiliza algún sistema ( Git o SVN ) que sería capaz de seguir se compromete a [cambios en el código que están "comprometidos" para su uso] y asignar la culpa ".
La explicación más probable es que se produjo a través de la fusión de las dos ramas de código (cuando dos o más personas estaban trabajando en el segmento de código). Fusión de código es completamente común en la programación profesional, la conciliación de los conflictos entre las distintas ramas tiende a hacerse a mano, utilizando editores que se mostrarán "diffs" (diferencias) entre el viejo, nuevo y alternativo nuevo código.
Adam Langley, que trabaja en la seguridad para el navegador Chrome de Google (pero no ha trabajado para Apple), dice :
Esta especie de sutil error profundo en el código es una pesadilla. Creo que es sólo un error y me siento muy mal por quien podría haber resbalado en un editor y creado.
El hecho de que Apple está arreglando el agujero ahora sugiere que no es inspirada por la NSA. Aunque como John Gruber ha señalado , es perfectamente posible que la NSA descubrió este orificio para iOS 6 fue liberado y sabía que podía explotarla.
Un dato curioso: si la NSA era consciente de este agujero de seguridad, no parece que le dijo el Departamento de Defensa de EE.UU., que pasó iOS 6 para su uso en el gobierno 05 2013.

¿Cuándo Manzana encontrar el error?

A principios de enero. El 8 de enero se puso en contacto CVE, la base de datos de vulnerabilidades y errores (utilizado por los principales desarrolladores de software) para reservar el número de errores CVE 2014-1266 para la vulnerabilidad descubierta recientemente, aunque CVE no sabía lo que era la vulnerabilidad.
Apple parece entonces haber empezado a trabajar en la revisión y la manera de extenderla. Lo curioso es que a pesar de encontrar la vulnerabilidad a continuación, no se soluciona en dos versiones beta de iOS 7.1 que se publicaron después de ese tiempo. Una posibilidad - aunque la compañía no confirmará esto - es que se descubrió la falta de autenticación de certificado en enero, pero hubo que esperar hasta ahora para reducir la pieza defectuosa de código - aunque, dada la rapidez con que se llevó el resto de la web para hacer lo mismo (una cuestión de unas pocas horas), esto parece poco probable.

¿Por qué Apple no detectar el error antes?

Sus pruebas no lo encontraron. La compañía no dirá qué métodos utiliza - si las pruebas unitarias (en el que trozos de código individuales se prueban individualmente) o pruebas de regresión . donde el nuevo código se prueba con pruebas conocidas 
El ex programador no dice "Apple no tiene una fuerte cultura de la prueba o desarrollo basado en pruebas. De Apple se basa excesivamente en 'dogfooding' [por sus propios productos] para los procesos de calidad, lo que a la situación de seguridad no es apropiado. 
"Desde un punto de vista de la buena ingeniería de software, este tipo de problema se debería haber encontrado. Es una vergüenza que no se están ejecutando análisis de código estático en absoluto (y mucho menos de forma automática) en dichas bases de código importantes "El problema con el análisis estático de código es que puede generar falsos positivos -. advertencias sobre fallas que no son - lo que llevó a varios equipos rechazando la idea, aunque no está claro si el equipo de seguridad era uno de ellos.

¿Cómo encontrar el error de Apple?

Parece haber sido de una revisión línea por línea de código, casi con toda seguridad provocado por las revelaciones publicadas por el Guardián de los esfuerzos de la prisma de la NSA - y sus otros reclamos para tener SSL agrietada . En un momento se especuló con que la revisión del código fue instigada por Kristin Paget, quien fue hasta hace poco a cargo del núcleo de seguridad de OS X de Apple, que se unió en septiembre de 2012.
Pero Paget (quien acaba de comenzar a trabajar para Tesla) ha desatado un virulento ataque a Apple en su blog para liberar la solución para iOS, pero tampoco un parche en el escritorio al mismo tiempo:
LO QUE LA F ** K siempre amorosa, MANZANA???!!¿Sabía usted seriamente sólo tiene que utilizar una de sus plataformas para colocar un 0 días SSL en su otra plataforma? Mientras estoy aquí sentado en mi mac Soy vulnerable a esta y no hay nada que pueda hacer, porque no se podía lanzar un parche para ambas plataformas al mismo tiempo? Usted sabe que hay un montón de intentos de explotación de trabajo en vivo para este en el medio silvestre en estos momentos, ¿no?
Como ella señala, el propio sistema de actualización de seguridad de Apple utiliza SSL - por lo que podría ser hackeado por un "hombre en el medio" ataque a plantar software malicioso?
¿Qué hay de tu sistema de actualización en sí - es tan vulnerable?
Venga el infierno en la Apple. Usted acaba de caer un 0 días feos [vulnerabilidad de día cero] en nosotros y luego se fue a casa para el fin de semana - Ir fallan en verdad.
FIX. TU. LA MIERDA.

¿Por qué Apple no soluciona el bug para Mac OSX, al mismo tiempo que lo hizo para iOS?

Sin duda, debe tener, como Paget señala. Otro ex empleado de Apple está de acuerdo, al parecer, Apple ha decidido en lugar de desplegar el arreglo para Mavericks como parte de su actualización de software 10.9.2 y no como una actualización de seguridad por separado (que lo ha hecho antes). Pero otros insectos se encontraron en 10.9.2, retrasando su lanzamiento - y la reducción de la seguridad de los usuarios de Mac.

¿Se han producido errores como esto antes?

Los errores abundan en software - y los errores de codificación son sorprendentemente fáciles de hacer. En mayo de 2011, un investigador de seguridad señaló que las cuentas de usuarios de WhatsApp podrían ser secuestrados porque no estaban codificadas en absoluto, hasta septiembre de 2011, se produjo una falla en la misma aplicación que permiten a las personas enviar mensajes falsos que fingen ser de nadie.
Un error común es el uso de conexiones por defecto que se dejan activa: millones de routers de todo el mundo tienen ID de usuario y contraseñas por defecto (a menudo "admin" y "admin") que pueden ser explotadas por los hackers.
Un error de codificación similares bricked Zune de Microsoft en el último día de 2008 - que, como la suerte lo tendría, era un año bisiesto. Hubo unerror de codificación en el software para el chip temporizador que no permitiría que se muestre una fecha equivalente al día 366 del año.
Apple también ha hecho algunos errores flagrantes similares - principalmente en tener alarmas que no se adaptaron al horario de veranohizo, y así mantuvo despertar a la gente, ya sea una hora antes o después.
Google también tuvo un error en la versión 4.2.0 de su software Android : no se podría agregar los cumpleaños de las personas nacidas en diciembre a sus contactos, ya que ese mes no se incluyó.
Más en serio, las versiones de Android de Google hasta la versión 4.2 pueden ver las conexiones realizadas a través de Wi-Fi abierta secuestrados y código malicioso inyectado , laboratorios de MWR en el Reino Unido, dijo en septiembre de 2013. No está claro si eso todavía no se ha parcheado, millones de dispositivos Android siguen utilizando versiones 4.2 a continuación. Ars Technica, informando que falla, señaló que "si bien la debilidad en gran medida se puede prevenir en Android 4.2, los usuarios están protegidos sólo si los desarrolladores de cada aplicación siguen las mejores prácticas."
Y Microsoft tenía un defecto de larga ejecución en Windows 95 y Windows 98, que significa que si el equipo había estado funcionando continuamente durante poco menos de 50 días, sería repentinamente colgar - y usted tendría que reiniciar el sistema. ¿Por qué? Debido a que mide "tiempo de actividad" con un registro de 32 bits, lo que incrementa cada milisegundo. Después de 2 ^ 32 milisegundos (también conocido como 49 días y 17 horas), el registro fue de todos los 1 - y la única manera de restablecer se estaba convirtiendo la alimentación. Eso es muy aparte de las muchas fallas explotadas en su software de ActiveX para instalar programas maliciosos en equipos Windows en las llamadas "instalaciones drive-by".

¿Qué lecciones hay de esto?

En las palabras de Arie Van Deursen , profesor de ingeniería de software en Universidad Tecnológica de Delft en los Países Bajos,

Al ver por primera vez el código, que fue capturado una vez más, por lo increíblemente frágil es la programación. Sólo añadir una sola línea de código puede llevar un sistema al borde del desastre.
No sólo eso - pero el código defectuoso se ha utilizado tanto y publicado por 18 meses, y probado por una organización de seguridad del gobierno que fue aprobada para su uso. Los errores de software pueden ser perniciosa - y pueden estar al acecho en las áreas más esenciales. E incluso las empresas que han estado escribiendo software durante décadas pueden caer mal de ellos.
Pero el ex empleado de Apple dice que a menos que la compañía presenta mejores regímenes de pruebas - Análisis de código estático, pruebas unitarias, pruebas de regresión - "No estoy sorprendido por esto ... que sólo será cuestión de tiempo hasta que otra bomba como esta impacta. "La única - minimal - consuelo:" Dudo que sea malicioso ".

No hay comentarios:

Publicar un comentario