Leía hace unos días el artículo algorithmic complexity attacks and libc qsort() donde se hace un análisis del Quick Sort, lo que pueden costar algunas de sus implementaciones y fantasea con la posiblidad de utilizarlo para algún tipo de ataque de denegación de servicio (o al menos ralentización).
Son de esas cosas que nos trae el software libre e internet.
Seguimos con el tema de la enseñanza. En este caso, en What They Don’t Teach You in «Thinking Like the Enemy» Classes.
Según el autor el proceso en este tipo de cursos suele ser:
– Find who and what interacts with your target.
– Search those things for weaknesses.
– Attack.
– Clean up some of your tracks.
– Profit!
Pero, claro, hay más cosas en las que pensar y el autor nos las recuerda:
– The enemy is not homogenous.
– The enemy will invest much more resources in staging an attack than you think is worth it.
– The enemy can and will readily exploit the one thing in our society that we think has made us so advanced and civilized: trust.
– The enemy is very capable of planning and interweaving multiple attacks across multiple channels to get to their target.
– The enemy probably doesn’t have everything you have but that doesn’t mean that if we don’t have it they don’t either.
– The enemy will take advantage of your superego.
Esto es, que el enemigo no es único y que puede sacar partido de muchas posibilidades.
Sobre el segundo punto, la inversión en recursos necesarios para el ataque.
For a little perspective on how hard it is to value something the same as someone else, how often have you been asked by a friend or neighbor to check out their computer because they think it’s infected. They say, «Come on, it’ll just take you ten minutes and I’ll buy you a drink.» But what they don’t realize is that it actually took you at least ten years to be able to analyze and diagnose the problem in «just ten minutes» and no drink will compensate you for ten years and ten minutes worth of work.
¿Somos nosotros muchas veces los que no nos damos cuenta del esfuerzo que otros pueden estar dispuestos a invetir?
La solución no sería pensar como el malo, sino tratar de prevenir todo lo
que podría ir mal:
Your best recourse is stop trying to guess what the attacker is going to do next and practice good preventative security. But you can find the details from this in Chapter 14 of the OSSTMM 3:
– Make separations between your assets and what shouldn’t be interacting with them.
– Lock down and control those interactions which are allowed.
– Actively manage all trusts.
Rompemos varias costumbres de esta bitácora (además de la de volver a publicar, hacerlo varias veces la misma semana) hablando de algo de bastante actualidad: en Facebook computers compromised by zero-day Java exploit.
Según nos cuentan se ha tratado de un ataque dirigido a algunos ingenieros de Facebook:
Rather than using typical targeted approaches like «spear phishing» with e-mails to individuals, the attackers used a «watering hole» attack—compromising the server of a popular mobile developer Web forum and using it to spring the zero-day Java exploit on site visitors.
«The attack was injected into the site’s HTML, so any engineer who visited the site and had Java enabled in their browser would have been affected,» Sullivan told Ars, «regardless of how patched their machine was.»
Esto es, aprovechar un fallo de Java en un sitio web que esperas que visiten tus víctimas y luego aprovechar para obtener otro tipo de ventajas.
Ya habíamos hablado en el pasado de ataques a medida:
Ataques a medida con hojas de cálculo.
Vigilancia en el Tíbet.
Actualización (2013/02/21): Ahora le ha pasado algo parecido a
Apple a través de un portal que visitarían sus desarrolladores y parece que
el fallo de Twitter de hace unos días también tenía que ver con lo mismo.
Lo cuentan en Java detrás de los ataques a Apple, Facebook y Twitter.
Recuerden: no visitar sitios ‘delicados’ con la máquina del trabajo.
Y seguimos con ataques de fuerza bruta al SSH. En este caso nos lo cuentan en El extraño caso del SSH y el ataque de fuerza bruta donde se cuenta otra batallita de intentos de acceso por SSH, uso de un equipo para lo que no se debe y el tiempo perdido tratando de encontrar el problema.
Este tipo de artículos son de los que más me gustan: normalmente llevan bastante trabajo y no son suficientemente genéricos pero nos dan algunas pistas. En este caso, además, hablan del SSH que es un protocolo que si uno tiene una máquina conectada a internet es relativamenet fácil observar los intentos de bots aleatoriamente sin mucha dificultad.
En Observations from two weeks of SSH brute force attacks hablan justamente de eso.
Intentos sencillotes:
As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234″, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).
Algunos más sofisticados:
Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’).
Y, finalmente, otros más interesantes:
here were, however, some more interesting attempts. One category was passwords far too complicated to be in a standard password dictionary, or even found through offline-brute-force attacks on a hashed password database (e.g. “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, and “kx028897chebeuname+a”). The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client.
Muy interesante.
Parece que el tema de este verano ha estado siendo Stuxnet, un gusano que anda propagándose por ahí y que, como novedad, incluye un rootkit para PLC’s: esencialmente, si se dieran las condiciones adecuadas podría atacar entornos industriales ya que estos dispositivos controlan máquinas y otros sistemas.
Por lo demás, casi todo son elucubraciones y cosas que se piensa que
podrían pasar. Algunos enlaces:
Y podríamos relacionarlo con dos tipos de entrada que hemos puesto por aquí de vez en cuando: sistemas inseguros porque no se piensa que nadie vaya a atacarlos, como aquella historia de Más ataques a coches y los enlaces que allí se contienen o Los electrodomésticos y la seguridad.
La otra línea serían los ataques dirigidos, como los que se comentaban en Ataques a objetivos concretos.
Hablábamos no hace tanto de Vigilancia en el Tibet y cómo se había atacado mediante documentos preparados a propósito, entre otras cosas.
Como continuación, en Targeted Attacks with Excel Files hablan de la alternativa utilizando hojas de cálculo apropiadamente preparadas.
Curioso.
Ya hablamos de Los electrodomésticos y la seguridad, refiriéndonos a robots de juguete y marcapasos.
En Experimental Security Analysis of a Modern Automobile (pdf) han comprado un par de coches iguales (para ver que los fallos eran reproducibles) y se han dedicado a probar sus sistemas informáticos: han descubierto todo tipo de fallos, que afectan al vehículo tanto en parado como en marcha y que permiten hacer cosas como apagar las luces, frenar, cambiar lo que muestra la instrumentación …. Todo ello tanto en local como en remoto (a través de algunos sistemas de comunicación disponibles).
Impresionante, si lo pensamos con cuidado.
Ya habíamos hablado de ¿Virus en el coche? y Jugando con Cabir sobre ataques maliciosos a los sistemas informáticos de los coches.
También de Coches y reparaciones, o de Cuando tu coche no te hace caso, Coche asesino, Coches, computadoras y riesgos que no harían sino confirmar lo que dicen los autores del artículo: los problemas aparecen en una variedad de marcas y modelos. También lo que veníamos sugiriendo con lo de los ‘electrodomésticos’: la informática en cualquier cosa que no sean ordenadores está bastante descuidada y tiene fallos, problemas y agujeros de seguridad que pueden ser peligrosos.
Siempre se habla de que se podrían tener ataques personalizados como una posibilidad pero nunca se comenta demasiado sobre esto en los medios de comunicación y sitios de noticias. Supongo que se debe a que los ataques personalizados no son tan publicitados (a lo mejor hasta pasan desapercibidos) y tampoco son de interés general. Sin embargo, leíamos el otro día un par de ellos donde los objetivos eran de suficiente nivel como para no pasar desapercibidos: en On-going Targeted Attacks Against US Military Contractors hablaban de ataques a contratistas de las fuerzas armadas de EEUU y en Intelligence Sector Hit by a Targeted Attack.
En ambos casos se trata de aprovechar una vulnerabilidad del lector de PDF y un documento malicioso adecuadamente preparado, que abriría una puerta trasera que permitiría al propietario del PDF conectarse al ordenador comprometido.
Por aquí sí que habíamos hablado de ataques personalizados en Puedes estar vigilado.
En People Vs Worms un resultado poco sorprendente pero que está validado por datos y que, por lo tanto, vale la pena reseñar: se comparan sistemas comprometidos por personas y por gusanos. La conclusión es que los gusanos son mucho más rápidos que las personas ante las vulnerabilidades que ‘conocen’ (pocas dudas: son programas, actúan de manera automática) y las personas son más lentas, pero consiguen atacar más sistemas.
En Measures with meaning hablan de la supervivencia en un experimento controlado de máquinas corriendo XP con diversos niveles de vulnerabilidades: ninguna de ellas con más de 6 vulnerabilidades sin parchear y accesibles desde la red aguantó más de 15 días sin ser comprometida. Uno de los sistemas con dos vulnerabilidades conocidas fué comprometido en cuatro días.
Mbpfernand0's Blog 