La posibilidad de backdoors en Linuxes comerciales

Una hipótesis

Similar al caso de varias empresas (la de las ventanas es la última), y el que se vean obligadas a colaborar con cualquier pedido para "facilitar futuros accesos que puedan ser solicitados" a sus servicios y productos, encontramos que los Linux comerciales que tienen sus empresas creadoras con sede en países que tienen leyes desfavorables para la privacidad de datos  podrían estar igual, potencialmente backdoreados.

Muchos creen que no se puede, sin embargo se olvidan que quien controla la infraestructura de actualización de paquetes, controla qué se instala en el sistema operativo.

Los updates "oficiales" de los Linux comerciales se hacen contra un grupo de IPs puntuales, que son el front-end de una infraestructura mayor que brinda updates de paquetes a todo el mundo vía Internet.

En el caso de un Linux no comercial como Debian, los servidores de actualización pueden estar en cualquier IP y país. Si queremos que los updates se hagan eligiendo al azar servers de Brasil, China, Chile, Uruguay, etc. y solamente saltando entre esos servers, se puede hacer fácilmente.

De todos modos, al estar tan replicados los servers de update de Debian a nivel internacional sería muy difícil lograr ubicar un software de backdoor o alguna vulnerabilidad crítica en algun paquete de Debian, sin que eventualmente sea detectado. Como ya pasó antes:

Random Number Bug in Debian Linux

Debian Bug Leaves Private SSL/SSH Keys Guessable

En una infraestructura privada de update de paquetes las cosas son muy diferentes, cada una de las IP de front-end puede redirigir el tráfico hacia cualquier servidor interno de la infraestructura, que puede estar ubicado en cualquier país, inclusive esos que tienen "issues" con la privacidad últimamente, de hecho, muchas infraestructuras privadas de actualización están totalmente localizadas fronteras adentro de estos países con "issues".

Problemas posibles

Una infraestructura privada de actualización de paquetes va a tener problemas para desplegar un software de backdoor a nivel global, ¿cuales? el que casi seguramente dicho acto será detectado en algún momento, por varios motivos técnicos, pero si en cambio se ataca a un solo cliente, a unos cuantos servidores puntuales de entre millones, la chance de ser detectados por comparaciones y análisis - de paquetes, de fechas de update, de conexiones realizadas, de tráfico que atravesó la red en X cantidad, en X fecha, para X IPs hacia Y IPs para unos servers sí, pero para otros no, para una empresa sí, para otra empresa no, etc. -  es mínima, casi nula inclusive.

El ataque dirigido

Es decir, tiene mucho más sentido un ataque dirigido, después de todo los Linux comerciales pueden efectivamente tener en algun lugar un código identificador únido (similar a un user id), y se lo puede emparejar con otros datos importantes: Nombre y ubicación del cliente*, IPs usuales desde donde se producen las conexiones a la infraestructura, etc.

* Al hablar de "cliente" aquí, me estoy refiriendo a "Empresa SRL", "Banco de la Región SA", "Ministerio de lo Quesea de la Pcia. de LoQueSea", "Subsecretaría de LoQuesesa", "Administración Federal de Manejo de lo Quesea", etc. y sus datos puntuales: dirección y código postal, teléfono, datos de contacto con el cliente (telefóno directo de un contacto, mail del contacto, horarios de disponibilidad), etc.

[Las IPs de origen de las conexiones suelen ser estáticas, por ser servidores. De todos modos, un identificador único va a permitir asociar un server/workstation que se conecta desde una conexión dinámica a los datos de un cliente específico, por cierto.]

Si se apunta a un cliente específico a backdorear, cuando el cliente se conecta para actualizar su instalación, es redireccionado a un server "especial" de actualización, donde el primer paquete que va a pedir actualizar va a ser el mismo cliente de actualización. Luego de terminar de instalar el nuevo cliente de actualización, este ya contiene un poco del código necesario para hacer que aunque se descargue un software X y sus chequeos de integridad fallen, igualmente se instale, sin informar de ninguna manera al cliente (sin dejar rastros de los fallos de chequeos de integridad de los paquetes a nivel de logs, etc.etc.). Y un componente más: la posibilidad de bajar e instalar un paquete transparentemente, sin que dicha descarga/instalación sea visible de cualquier manera para el usuario, y sin que quede tampoco registro alguno de esa tarea a nivel de logs o interfaces gráficas.

En criollo, el usuario no se va a dar cuenta de nada, a menos que esté monitoreando directamente lo que hay en la memoria del sistema operativo, los procesos activos y al mismo tiempo el tráfico de red, justo en el momento que supuestamente se descarga e instala 2 mb de paquetes (y ocupan 4 mb en storage local), pero en realidad bajan 2.4 mb (y en realidad ocupan 6 mb en storage local).

Luego de esto, en la siguiente actualización (que va a ser disparada casi de inmediato, o quedará scheduleada para la siguiente iteración de actualizaciones), si este cliente target se conecta, no accederá a ningun servidor estándar de la infraestructura de actualización (que contiene paquetes libres de todo backdoor), sino a un servidor "especial" que puede llegar a contener "actualizaciones" que serán instaladas transparentemente sobre las versiones actuales, inclusive sin llegar a modificar las versiones del software que se puede ver desde las herramientas estándares. Esas "actualizaciones" pueden contener el software que sea, desde un backdoor que habilite un servicio "fantasma" con SSH corriendo en un puerto alternativo (no el 22), hasta un túnel HTTP, DNS, o de cualquier protocolo que tenga comunicación a Internet.

El trabajo

Desde ese punto lograr la comunicación desde Internet hasta dentro del server es trivial y los métodos son comunes: port knocking, que el backdoor solo responda si hay intentos de conexión desde un rango de IPs específico (esto evitaría esos servicios "fantasma" sean visibles para escáneres como Nmap y similares), que los servicios "fantasma" solo se activen (sean arrancados y se carguen a memoria), en un rango horario limitado (de 4 a 5 de la mañana), cada X cantidad de días, y solo si encuentran una respuesta en servers de C&C (comando y control), prosigan con más actividades, etc. etc.

La transferencia - masiva si es necesario - de datos salientes se gestiona igualmente por métodos comunes: en gral. se va a buscar algún protocolo encriptado que tenga tráfico saliente y se lo va a usar, para evitar que los dispositivos de threat management que puedan estar inspeccionando el tráfico de protocolos encriptados, se suele recurrir a técnicas diversas (en gral. esteganografía en lo que haya "en movimiento" en el tráfico: audio, video, documentos, etc.). Eso claro, si es que los mismos dispositivos de threat management no tiene backdoors intercontruídos que simplemente se accedan y permitan desactivar contramedidas y detecciones varias, antes de iniciar el tráfico de datos saliente masivo.

Si hace falta, la transmisión de datos masiva - GBs de datos - se puede realizar por etapas o aleatoriamente, enviando unos pocos GBs de datos de a poco, durante días o semanas, hasta completar el trabajo.

Si el grado de securización de la infraestructura es bajo y/o manejable, ello inclusive podría llegar a acelerar los tiempos prescindiendo de diversas tareas de ocultamiento y prevención de detecciones.

La despedida

Una vez terminado el interés en el objetivo, la misma infraestructura de actualización puede fácilmente devolver a los paquetes instalados a su estado anterior, y dejar efectivamente cero rastro de la intrusión dentro del server. A lo sumo, el tráfico saliente - y en protocolos y puertos totalmente autorizados a hacerlo - del server es lo único podría permitir pinpointear una intrusión de este tipo, luego de eliminado todo rastro de los binarios que la permitieron.

Luego de esto, al revisar el server no se va a detectar ninguna diferencia entre los binarios instalados y los oficiales, son los mismos.

El trabajo puede durar desde pocos minutos a varias semanas, inclusive intercalando ataques con períodos "limpios", offline, donde los servers atacados son limpiados y devueltos a su estado original, para luego ser atacados de vuelta.

Contramedidas?

Si hubiera otro tipo de medidas de seguridad para prevenir el uso de binarios alterados, un HIDS (HostIDS), fácilmente podría ser pinpointeado por un componente de software "fantasma" antes de instalar nada más que el update del cliente de actualización que arrancara totalmente autorizado (y no va a disparar ninguna alarma porque es una versión nueva justamente, y es esperable que los nuevos binarios en disco disparen alarmas en el HIDS, que rápidamente van a ser descartadas como "falsas alarmas", si que directamente ya no hay reglas que impiden que el HIDS dispare alarmas cuando se actualiza el cliente de actualización), y luego efectivamente desactivado, inclusive para ello hiciera falta "actualizar" los binarios y librerías del HIDS.

Conclusiones

Es decir, quien controla la infraestructura de actualización y además cuando los servidores de actualización son privados, y no hay acceso público o semipúblico que permita controlar qué hay en esos repositorios en cualquier momento y además controla el código fuente del cliente de actualización, está en perfecta posición para montar una infraestructura de backdoring y troyanización perfectamente efectiva, pudiendo entrar, instalar, borrar y luego salir de cualquier server conectado a Internet, sin que los administradores (de sistemas, redes, seguridad, etc.), a cargo de los servidores lleguen a darse cuenta siquiera de que hubo algún acceso no autorizado.

Learn from the IT Masters == Empty your cup

* For you guys tired of reading from google-trans :-), thanks for passing by.


There's an old chinese saying: "you cannot fill a cup which is already full" (yep, and from the Avatar thing too).

In IT training, you could say it something like this "you need to learn not to listen, but to understand".


The issue
The chinese saying applies when you're training in IT: you probably know something, a little, more than a little, but when you're about to learn from an IT master, you've got to empty your cup.

Some IT guys/girls don't like to be trained, they just want you to provide them the information, accurate, straight, with a "please-go-to-the-point" attitude included. This won't work when you're trying to teach many complex IT topics, and the guy/girl will learn little to nothing in the end.

Trying "to distill" the key points in the information you're "just listening" (not "learning"), will just prevent you to understand the full scope of the topics, and you'll end in fact, learning much less - very, very close to nothing - than what you think you did.


Masters
At information technology there's a lot people who knows quite a lot of things, there are newbies, semi-seniors, and also there are masters. 

The masters are IT guys senior enough to provide deep technical and toughful answers and insights about most to all of the usual hard topics in her/his professional scope (without having to google much, or google at all, for doing so), for an infrastructure guy/girl that would be probably:

http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

Not to mention common technical topics...

http://meta.serverfault.com/questions/1986/what-are-the-canonical-answers-weve-discovered-over-the-years


Previous knowledge
But anyway, when you're learning something from an IT master, what you already know is mostly an obstacle for what you're about, for what you need to (re)learn. This is because what you know is more than knowledge about something, is a point of view about the information you have.

The master has another point of view, looking at, understanding the topics he/she is about to teach you about, from a usually deeper insight in the knowledge.

That point of view provides a much perfect picture of the topics you need to (re)learn about. Following that lead, you'll get to achieve a comprehension far more interesting and useful, than what you have now. And actually a lot faster than what you could learn not emptying the damn cup.

But first, you need to empty your cup.

Conclusions
The IT masters actually know their s#$"t, all the way to the binaries and/or source, deep down inside the protocols he/she knows, or even protocols he/she haven't seen ever before right know. 

To get a clue about that kind of sorcery, you've got to release control a little, and let the IT master do her/his job, letting her/him train you in her/his "fu", in the way she/he sees/thinks/does the things, you being truely commited not only to be merely "listening about stuff", but to learn from him/her.

When you're done with the training, the training will provide you a refined point of view, summarizing your previous knowledge and expertise with the new insights you learned, creating a full new vision and scope, and actual new skills.


# Found typos? Tell me about, thanks in advance.

Doble zero day de un año de duración

Siempre que converso sobre seguridad IT le digo a quien quiera escuchar que los especialistas de AR son de lo mejor que se encuentra en la red. Son así los "buenos" (AKA "security engineer") y también los "malos" ("black hat dude").

Respecto del zero day de Java (son dos en realidad), que estuvo asolando la red desde abril de 2011, sin que nadie se entere hasta hace unos días, encontré un informe muy bueno de Esteban Guillardoy (una "java guy" de Immunity Inc. en AR). Programador Python de título y fama, también, según leo en:

http://www.linkedin.com/in/eguillardoy


La cosa es que escribió este informe:
http://immunityproducts.blogspot.com.ar/2012/08/java-0day-analysis-cve-2012-4681.html

Donde se puede leer exactamente cómo funcionan estos zero days.


Sigo leyendo las noticias de hace un par de días con pro-pánico mensajes de "desactiven Java ya!!!!", pero al día de hoy ya tenemos solución en puerta y parches de Oracle disponibles, pasen, vean, descarguen e instalen..nos vemos en 6 meses de vuelta! ...broma :-)

http://www.oracle.com/technetwork/java/javase/7u7-relnotes-1835816.html


El racconto de ley: desde el 28 de Julio de 2011 existe este zero day (no sé si da llamarlo un "zero day" a algo que lo habrán explotado hasta reventar los servers), y en el mismo artículo podemos entrever cómo los kits se estuvieron "moviendo" en el inframundo del black hat hacking, probablemente proveyendo el zero day a los miembros de un círculo "de confianza", luego a los "de confianza" del círculo y así sucesivamente.

Obviamente la disciplina del secreto funcionó muy bien (durante un año++ completo), "saltando" la existencia del zero day por la "fuerza bruta" al haber tal cantidad de explotaciones que llamaba a los gritos a las empresas de seguridad para que prestaran recursos a investigar esa tormenta silenciosa de explotaciones.

El comentario y los detalles de los kits aca:
"Esteban Guillardoy, a developer at the security firm Immunity Inc., said the underlying vulnerability has been around since July 28, 2011."

http://krebsonsecurity.com/2012/08/java-exploit-leveraged-two-flaws/

Siempre que estoy en presencia de algun aspirante a security engineer que dice "estamos seguros porque está todo parcheado al día", me acuerdo de estas noticias y bue, no comment (no, no puedo sacarle el "aspirante" a quien se exprese de esa forma, sin alguna excusa razonable, como por ej. estar fuertemente medicado, etc.).

Layered Security please (for $DEITY sake), do the needful.
http://en.wikipedia.org/wiki/Layered_security

Malware y ataques destructivos y dirigidos

Finalmente luego de un par de décadas desde los viejos Stoned y especialmente el Michellangelo

http://en.wikipedia.org/wiki/Stoned_(computer_virus)
http://en.wikipedia.org/wiki/Michelangelo_(computer_virus)

Que atacaban la integridad de las computadoras en sí afectando el MBR de los discos, la vieja "moda" de infectar estaciones de trabajo para que definitivamente se "rompan" está volviendo.

http://en.wikipedia.org/wiki/Shamoon
http://es.wikipedia.org/wiki/Flame_(malware)

El nivel de sofisticación de lo último que se va encontrando en malware es razón suficiente para ser alarmante ya que las contramedidas usuales en funcionamiento son efectivamente consideradas y superadas por el malware, por ejemplo: se usa certificados robados y los drivers a instalar en Windows están firmados correctamente, por lo que el virus los instala sin problemas en el sistema luego de obtener permiso de Administrador.

Kits y Presupuesto
Una clave del problema actual son los kits disponibles en el mercado negro de malware en la red, del que son habitues los hackers y script kiddies locales. En gral. los kits tienen un costo no fácilmente pagable por un script kiddie, sin embargo, los trabajos por encargo no son desconocidos para los hackers locales ni carecen de antecedentes en la justicia (es decir, fueron delitos reales, detectados, investigados, algunos sancionados inclusive).

Un ejemplo de compra de kits para hacking en el bajo mundo en Argentina lo vemos en los delitos practicamente constantes (pero que se detectan y llevan a la justicia más o menos cada 6 meses), de robo de credenciales para homebanking.

Habiendo un trabajo por encargo de por medio, tenemos el issue de la financiación, es decir, el hacker va a tener acceso a un presupuesto que le va a permitir pagar por un kit.

Antecedentes:
Un prejuicio habitual entre los no expertos en seguridad IT es que los Kits son mayormente "assembles" (rejuntes), de código, impredecibles y mayormente inutiles. Claro, es una posibilidad, sin embargo la tecnología de Kits es muy vieja en el mercado negro y de vez en cuando algun kit en venta resulta ser muy bueno.

http://en.wikipedia.org/wiki/Virus_Creation_Laboratory


Multiplicando la capacidad de ataque
Los kits representan una particular amenaza, ya que potencian radicalmente la capacidad de un grupo pequeño de atacantes o inclusive de individuos.

Sin kits, un atacante debe investigar y desarrollar un malware suficientemente potente para ser efectivo y lograr el objetivo. Por ejemplo, borrar o destruir un par de miles de discos rígidos de las pcs de los empleados de una organización.

El kit dispara los tiempos: la compra de un kit le permite a un individuo y/o a un grupo pequeño de atacantes dirigir una ofensiva contra una infraestructura altamente protegida con probabilidades altas de éxito y con tiempos de preparación del ataque muy reducidos (días a semanas).

* Un kit aparece en el mercado y contiene vectores de ataque que van a funcionar por plazos muy cortos, de días a semanas como máximo. Se vende muy caro cuando es nuevo y va bajando de precio a medida que pasan los días (y el kit se vuelve potencialmete menos efectivo y/o totalmente inutil).

* Sin embargo, habiendo la suficiente motivación, el acceder a un kit precipita un ataque efectivo y altamente destructivo contra una organización, con la cualidad intrínseca de ser imprevisible.

* Es decir, hace 10 días atrás no existía el kit (ni los medios técnicos que posee), y no era viable atacar a ciertas organización, 10 días después, el kit es accesible y un grupo de hostiles puede pagar (a un hacker o varios), para que realicen un ataque dirigido.


Romper, no afectar
Hace tiempo, los virus no eran dirigidos, no se buscaba afectar a una empresa u organización en particular, hoy es muy distinto. Habiendo la suficiente motivación política (y tal vez ni siquiera económica), un grupo de interés puede buscar atacar e intentar destruir la infraestructura informática de una organización.

Por ejemplo:
"Saudi Aramco Oil Producer's 30,000 workstations victim of Cyber Attack"
http://thehackernews.com/2012/08/saudi-aramco-oil-producers-30000.html


Romper estaciones de trabajo, no servers ni redes y el MTTR
La actual motivación para atacar fuerte, rápida y decisivamente al mayor número de estaciones de trabajo de una organización "target" es simple: las infraestructuras centrales, redes y servidores están altamente fortificadas y aseguradas casi de seguro y hay un punto clave aquí: el MTTR.

*MTTR
http://en.wikipedia.org/wiki/Mean_time_to_repair

El MTTR de los puntos centrales de una infraestructura informática, servidores y redes, es casi siempre el más bajo posible de obtener con los recursos de la organización. Por ejemplo:

a) un ataque puede borrar completamente un server, luego, usando backups el server es restaurado en muy poco tiempo

b) un ataque puede hacer un takedown completo y muy rápido de un centro de datos, luego, es rápidamente reeemplazado por un centro de datos secundario.

[ Ejemplo de ataque para b): se puede realizar usando vulnerabilidades zero day de routers, y sobreescribiendo los firmwares de todo el equipamiento de networking de "core" de la infraestructura, fácilmente "ubicable" gracias a tener "a mano" la ubicación lógica de los routers con recursos como trazadores y análisis de configuraciones de ruteo (gateways, etc.)]

Si bien atacar los puntos centrales de una organización permanece como un objetivo muy deseable en los ataques dirigidos de la actualidad, es mucho más fácil y mucho más probable de ser efectivo directamente al afectar a un grupo masivo de estaciones de trabajo.

La motivación de "romper estaciones de trabajo" implica un impacto variopinto:
 - hace falta tiempo para reconstruir, digamos 2000 estaciones de trabajo;
 - hace falta tiempo para recuperar los datos privados, es casi seguro que si el malware logró permiso de administrador en una estación de trabajo el tiempo suficiente, los datos locales fueron destruídos efectivamente;
- hace falta tiempo - mucho en gral. - para recuperar los datos desde backup centralizado para todas las estaciones de trabajo afectadas por el ataque (típicamente la infraestructura de recuperación de backups va a ser saturada muy rápido, ya que suele prever una carga probable máxima mucho menor a la requerida para tolerar un uso masivo y repentino).
- La cantidad de información no backupeada en las estaciones de trabajo suele ser masiva (típicamente ubicada en directorios no añadidos a los sets de backup locales ni remotos), lo que implica que al perderse, la organización va a perder una fuerte capacidad operativa durante un tiempo considerable.
- etc. etc.

Es decir,

* el MTTR de la estaciones de trabajo es potencialmente mucho mayor en la organización, que el MTTR de los núcleos informáticos (centros de datos, servidores, redes, etc.).

* la cantidad de recursos organizacionales dedicados a proteger las estaciones de trabajo suele ser los mínimos posibles para la mayoría de las estaciones de trabajo (haciendolas potencialmente más vulnerables), mientras que los núcleos informáticos tienen cuantiosos recursos invertidos en protección (backup, redundancia, disaster recovery, etc.).

Es decir,

Los ataques dirigidos masivamente contra estaciones de trabajo no son una coincidencia o simplemente "el camino de menor resistencia" (al menos no solamente eso), sino que estamos en presencia de ataques calculados y pensados, con un alto nivel de motivación potencial dada por la altas chances de éxito en la búsqueda de afectar la infraestructura.

Soluciones de hardware customizado II: Corrientes

En mi experiencia IT en Corrientes (AR) pude ver mucho de self-made hardware solutions para datacenters. Resulta que los bajos presupuestos IT de la región son desde hace tiempo una gran motivación para montar este tipo de soluciones de hardware de datacenter customizadas.

Servers customizados
Desde hace décadas, es lo más básico como tener una máquina potente corriendo servicios de misión crítica, pero, se tiene típicamente hardware de repuesto en cold stand-by (apagados, listos para reemplazar cualquier parte que falle en el hardware principal), inclusive se puede reemplazar el servidor customizado completo.

Para ello, típicamente se hace una compra de hardware duplicada o triplicada inclusive: se compra dos o tres partes de cada componente de hardware del server custom made. De ese modo el sysadmin se asegura total soporte del hardware subyacente en un sistema operativo redumpeado - por ejemplo - a un nuevo disco, luego de la falla de uno que estuviera en producción.

Las imágenes se toman justo luego de terminar la instalación inicial de todo el software que correrá en el servidor, teniendo así un registro "limpio" con el software - aplicaciones y sistema operativo - totalmente configurado y funcional, que puede ser dumpeado directamente a un nuevo disco a utilizar en otro server con idéntico hardware.

En gral. la política de backup de este tipo de solución de hardware customizada obliga a tomar imágenes de disco del server en cuestión, al menos una vez por semana, típicamente los viernes, de modo de - en un fatídico lunes - poder reconstruir un server nuevo directo desde una imagen, sin necesidad de utilizar la imagen "limpia" y restaurar "arriba" de ella los backups de la semana. Según la criticidad de los datos, la "imaginación" del server se llega a realizar diariamente inclusive.

Más o menos lo anterior son policies vigentes en el NEA desde finales de los 80', básicamente con ya una historia de dos décadas de uso de hardware customizado en producción en muchos datacenters que el público (CEOs, directores, presidentes, políticos, etc. incluídos), no llegaría a sospechar que usan soluciones "hechas en casa".

UPS customizadas
Una variación muy habitual vista en datacenters de Corrientes tiene que ver con soluciones customizadas de UPS, imprescindibles para prevenir los típicos cortes de suministro de energía eléctrica que suelen ocurrir justamente en pleno horario laboral, exponiendo a la organización no solo a la pérdida de servicios IT, sino también a perder hardware por daños ocasionados por el corte de energía súbito.

La solución tradicional (luego de 20 años de historia se vuelve tradición), es montar un set de baterías de automovil, típicamente hablamos de 5 a 30 baterías de automovil, compradas en el mercado abierto, que se montan utilizando infraestructura de ingeniería eléctrica armada localmente e in situ. En algunos casos, esta solución de hardware self-made llega a custodiar servicios de muy importantes entes privados y públicos en la ciudad, incluso largo tiempo después que los - esforzados - directores logran conseguir mejores asignaciones de presupuesto y ya podrían comprar UPS de nivel industrial, sin embargo, siguen confiando en los buenos resultados obtenidos - durante años - por las UPS hechas "a mano" (y aprovechando el excelente TCO que brindan versus tener que adquirir soluciones comerciales de UPS de nivel industrial).

Soluciones de networking customizadas
Es prácticamente obvio que los bajos presupuestos que previenen a los directores de adquirir servidores de nivel industrial cuando son una necesidad inclusive, también hacen que sea poco viable adquirir hardware de networking de nivel industrial.

La solución pasa por utilizar routers y firewalls construídos sobre software Linux, pero mayormente *BSD. Muchas - muchas - infraestructuras IT de nivel comercial y con tráfico que se mide en Gigabits por día funcionan interconectando sus distintas redes a través de Internet vía links VPN y enrutando su tráfico con este tipo de soluciones.

El hardware subyacente suele ser customizado en el 100% de los casos.

Conclusiones
Hay muchos ejemplos más por supuesto, en gral. hoy en día en los datacenters de Corrientes se trata de aprovechar los nuevos estándares en hardware barato, por ejemplo, la inclusión de controladoras RAID hardware en muchas placas madre (y se configuran los discos en RAID1 como mínimo), así también es un poco menos habitual, pero suele estar disponible en hardware nuevo, son las fuentes de poder redundantes (al menos dos por server). Cada vez se ve más clustering de sistemas operativos y aplicaciones, etc.

Muchas infraestructuras intentan tomar lo mejor del hardware propietario y al menos adquirir uno o dos servers "de marca" para tener al menos un par de nodos de alta fiabilidad (algo que se espera del hardware propietario), con lo que eso conlleva para beneficio de la organización.

Ataque viable para resetear cuentas de Gmail - Junio 2012

Antes que nada, la vulnerabilidad ya está solucionada, pero todavía no hay detalles precisos de ello.

En segundo lugar, el ataque de escalada de privelegios en Gmail fue exitoso el 01/06/2012 y durante mayo 2012, y logró acceder:

- una cuenta de Gmail estándar
- una cuenta de Gmail corporativa (Google Apps, Gmail pago), con two-factor authentication configurada

Acá tienen detalles de cómo se configura la autenticación two-factor para gmail:
http://googleblog.blogspot.com.ar/2011/02/advanced-sign-in-security-for-your.html

De momento la noticia no parece muy difundida, pese a que es de una fuente muy fiable: el CEO de la empresa CloudFlare y menciona la participación del equipo de seguridad de Google, algo que no fue desmentido hasta el momento.

El post del blog ya fue actualizado dos veces por Mattew Prince, el 02/06/2012 confirmando que CloudFlare y el equipo de seguridad de Google terminaron con el ataque.

De momento no hay noticias de otros ataques similares a cuentas de Gmail, pero es evidente que fue posible durante bastante tiempo, así que las medidas de seguridad recomendadas son

- resetear la password,
- configurar autenticación two-factor (es posible hacer en cuentas Gmail no pagas)
- configurar una cuenta de correo para recuperación de contraseña que no se use para ninguna otra cosa (que no aparezca ni se mencione en ningun mail ni posteo online).


La explicación del procedimiento de hacking:

"Este ataque parece haber comenzado a mediados de mayo, al parecer un account request fue enviado a Gmail para mi cuenta de correo personal. El procedimiento de Google hace varias preguntas para verificar que el solicitante es el propietario de la cuenta de correo. No tenemos claro como funciona el proceso, pero parece ser que semanas luego de que el proceso fue iniciado, el hacker de alguna manera convenció al sistema de recuperación de contraseñas de Google para que añadiera una cuenta de correo adicional para recuperar contraseñas perdidas a mi cuenta de correo personal. La clave usada en mi correo era de más de 20 caracteres de largo, altamente aleatorios, y la clave no la usé para ningun otro servicio, así que es poco probable que fuera atacada vía técnica de diccionario o adivinada.

Luego de que la cuenta de correo para recuperar contraseñas fuera añadida, el hacker pudo hacer de vuelta el procedimiento de recuperación de contraseña perdida y conseguir resetear mi cuenta de correo Gmail. Con ese reseteo, ingresaron en mi cuenta de correo esta mañana.

Como miles de otras empresas, CloudFlare usa Google Apps para mails, Cuando creamos la cuenta de CloudFlare.com, configuré mi cueta de correo personal - de Gmail - como correo para recuperar contraseñas. El hacker logró hacer que el sistema de recuperación de contraseñas de Google reseteara la clave del correo de CloudFlare.com y la enviara a mi correo personal. Sorprendentemente, todas las cuentas de correo de CloudFlare usan two-factor authentication; todavía estamos trabajando con Google para entender cómo fue que el hacker fue capaz de resetear la clave de CloudFlare sin proveer un token two-factor válido."

[Nota: el comentario de que no se explican cómo la cuenta Gmail con two-factor authentication fue reseteada es porque en teoría, al tener el celular configurado para recibir el token, cuando se resetea la contraseña, se recibe un correo con el link a un página, donde hay que cargar el token que se recibe vía sms en el celular, recien luego de eso se puede cambiar la contraseña de esas cuentas.

El problema es que el hacker no tuvo - todo indica que es así con seguridad - acceso al celular del CEO de CloudFlare, por lo que no habría recibido el token para poder cambiar la contraseña, de todos modos, pudo cambiarla. Es posible que mientras avance la investigación surjan nuevos hechos, por ahora es sorprendente el reset de pass sin tener el token. ]

Luego de comprometida la cuenta de correo de CloudFlare, el atacante procedió a resetear la password de la cuenta de un cliente puntual de CloudFlare, y modificó los DNS para el cliente, redirigiendo el tráfico hacia los sites durante un tiempo, hasta que el issue fue detectado.

Links
"Post Mortem: Today's Attack; Apparent Google Apps/Gmail Vulnerability; and How to Protect Yourself"
Fecha 01 / 06 / 2012
http://blog.cloudflare.com/post-mortem-todays-attack-apparent-google-app

Howto - Cómo arreglar rápido un cargador de notebook (issue común)

Más de uno se quedó “de a pie” cuando el cargador de la notebook dejó de andar sin motivo aparente; acabo de reparar un cargador de notebook y quería dejarles el howto por si les pasa alguna vez lo que es un issue común en cargadores Dell y HP. El mismo howto aplica a cargadores Dell y HP.
 
1) Cómo abrir el cargador (lo del cuchillo+martillo funciona bien por cierto)
http://www.youtube.com/watch?v=oP51TF1nhdM

2) Un problema común de los cargadores que no alimentan tiene que ver con los cables que dan power a la notebook. El cargador suele seguir funcionando de lo más bien, pero los cables se están tocando dentro del plug, eso bloquea el cargador. Más datos, acá:
http://13norte.blogspot.com/2011/07/cargador-marca-dell-no-enciende.html

 3) Ya abierto el cargador, luego de cortar un poco el plug de goma con una trincheta, pueden probar separando un poco los cables semi-quemados y viendo si el cargador funciona con los cables separados (suele funcionar). Acá pueden ver una reparación rápida (explicación + video)
http://www.punksunidos.com.ar/2012/03/reparar-o-arreglar-adaptador-notebook.html

Lo ideal por supuesto es desoldar los cables individuales, rearmarlos y volverlos a soldar (se hace en 15 min. + pegamento y el cargador queda “nuevo”), pero esto funciona si tienen apuro.

Clickjacking en la red

Hay un tema muy movido en la red, mucho texto corre al momento sobre él: la vulnerabilidad de clickjacking.

Los hackers, investigadores, etc. que descubrieron esta vulnerabilidad dicen que no tiene nada que ver con el uso de javascript y que es inherente a la actual tecnología de browsers, por lo que todos ellos están afectados, también explican que no se soluciona con un simple parche lo que lleva a pensar que puede ser un problema lógico en la arquitectura estándar de diseño de los browsers a nivel de programación (de hecho, es así al parecer).

Por otra parte en algunos sitios ya se publican distintos ejemplos de código con javascript que dan supuestos "ejemplos de clickjacking" cuando los que descubrieron esta vulnerabilidad siguen negando que esos ejemplos sean la nueva vulnerabilidad. Los ejemplos funcionan realmente, e incluso hay reportes en foros que confirman que ya están en uso en la red y circulando en avisos publicados en sitios de alto volumen de tráfico.

Sin embargo queda el hecho de que esos ejemplos usan Javascript, que como ya se mencionó, no sería parte de la vulnerabilidad de clickjacking, incluso está la pauta dada por los descubridores de que deshabilitar javascript no serviría para impedir que funcione la vulnerabilidad, algo que sí frena en cambio, las técnicas de clickjacking que ya circulan al momento basadas en javascript (buscar "clickjacking+noscript" en google para ver más detalles).

La línea de tiempo de los acontecimientos del descubrimiento de la vulnerabilidad fue, básicamente,

- la investigación inicial,
- desarrollo de la prueba de concepto,
- de ahí se pensó que era una cuestión limitada a parches de los teams de desarrollo de los navegadores, luego los investigadores hicieron publico el tema anunciando su participación en el evento OWASP para explicar la nueva vulnerabilidad,
- al poco tiempo la prueba de concepto derivó en un exploit muy efectivo y que al parecer afecta mucho a Adobe,
- luego el pedido de Adobe de mantener esto en secreto hasta que no se tenga mayor capacidad para resolver el problema,
- y ahora la pura "seguridad por oscuridad" donde los descubridores están brindando cero información concreta sobre la vulneratibilidad.

Las diversas especulaciones iniciales luego llevaron a la aparición en la red de código hostil basado en javascript, que si no llegara a ser el clickjacking "autentico" ya resulta bastante peligroso de por sí.

Realmente el clickjacking sería la vulnerabilidad que reside en la posibilidad de usar diversas tecnologías web actuales para redireccionar clicks del usuario hacia otros enlaces diferentes del que él cree que está accediendo; hay un ejemplo repetido en la red basado en iFrames, pero se menciona también que sería aplicable vía Java, Flash, Silverlight, etc. Lo que lleva claramente a la idea de que desactivar Javascript solo haría disminuir marginalmente el riesgo de clickjacking y también nos da una pista de que tanto (daño) se podría llegar a efectivizar iniciando una cadena de acontecimientos desde el click de un usuario.

Al parecer desactivar el uso de cualquier plugin además de Javascript aparentemente es la solución definitiva actual para el clickjacking. Es sumamente impracticable esta contramedida y no elimina el riesgo por completo (un simple exploit previo a la ejecución de un browser podría activar un plugin necesario para el clickjacking, por ejemplo), así que esperemos que alguno de los responsables de solucionar este problema desarrolle una mejor idea rápido.

El post de los hackers que todavía no explican en que consiste el clickjaking "realmente":
http://ha.ckers.org/blog/20080915/clickjacking/

Ejemplos de código que no serían clickjacking (pero funcionan redireccionando engañosamente al usuario al hacer click):
http://www.breakingpointsystems.com/community/blog/clickjacking

Una explicación de clickjacking con iFrames y algunas ideas sobre sus implicaciones:
http://www.webmonkey.com/blog/A_Look_at_the__Clickjacking__Web_Attack_and_Why_You_Should_Worry

Las tres formas para impedir el clickjacking basado en javascript :
http://www.cyberciti.biz/tips/firefox-stop-clickjacking-attack.html

IT Forensics en Argentina/Corrientes

Un caso en Ctes.
Al parecer el análisis forense informático (o peritaje informático) no tuvo un buen momento en Ctes, Argentina en alguna fecha de 2006. Tuve en ese tiempo contacto con un caso donde se habían secuestrado computadoras como evidencia, y el peritaje de las mismas estuvo a cargo de un LSI con bastantes años de experiencia laboral. Según comentó el LSI IT Pro, el "peritaje" consistió en enchufar la máquina, bootearla y "mirar por el disco si no había algún tipo de información relevante para el caso" (usando Explorer).

Un procedimiento técnico de análisis forense informático debe garantizar que el hardware, el software y especialmente los datos, se conserven como fueron obtenidos, inalterados y por ello, admisibles como prueba en juicio.

Obviamente, bootear una PC definitiva e inevitablemente altera los datos contenidos en un disco rígido e invalida legalmente cualquier conclusión obtenida de esos datos.

Como para dar una perspectiva técnica, hablemos del tema particular dentro de IT forensics: los discos rígidos. El análisis de cualquier disco rígido nunca se realiza con el hardware del disco en capacidad de alterar físicamente los datos dentro del HD. Se toma una imagen del contenido del disco, pero antes se monta sobre el HD un dispositivo que impide el ingreso de cualquier orden de escritura (borrado, modificación), y que así garantiza que el contenido del disco permanece inalterado aún mientras se lo esté leyendo para tomar la imagen. Un simple "dd if= of=" es válido para la captura de la imagen.

Forensics en la justicia argentina
Puertas adentro de la Justicia en Argentina se suele considerar muchas actuaciones y sentencias basadas (indirectamente al menos) en evidencia informática, como altamente innovadoras en casi en cada caso.

Es crítico cuando algunos magistrados ignoran las incidencias positivas o negativas de la tecnología informática sobre alguna causa y se pierde valiosa evidencia simplemente por falta de un pertinente análisis por parte de un perito cualificado.

¿Para qué usar análisis forense informático en la justicia? Siguiendo el principio del análisis forense en general: para obtener conclusiones basadas en evidencia científica que respalden una decisión judicial que asigna y/o hace respetar responsabilidades a personas físicas y/o jurídicas.

Algunos casos típicos; un proveedor de software podría solicitar una pericia IT para deslindar responsabilidades por la pérdida de datos (por ejemplo: si la corrupción de un BD fue por causa de la aplicación o por malas prácticas de administración, etc.) . El caso jurídico típico de causas de familia, donde datos en una PC pueden servir de fundamento a importantes imperativos económicos dentro de un fallo en una causa de divorcio. Los casos en que los datos de una PC sirven para "guardar" a turbios personajes involucrados en pornografía infantil y similares.

Justamente estos últimos dos tipos de causas son las que más se benefician cuasi-regularmente de la evidencia informática y donde también se producen más errores de peritaje que conllevan serias consecuencias para brindar el servicio de justicia a los involucrados.

Conclusiones
Muy diferente a lo que se ve en películas/libros donde son protagonistas principales los (en realidad raros/pocos), casos espectaculares de hacking y cracking de altos niveles de seguridad.

Hay relativamente poco material sobre Forensics IT, pero lo bueno es que es bastante mejor que la media de calidad en libros/papers/tutoriales acerca de otros temas IT. Claro que es una especialidad no habitual y en crecimiento desde hace pocos años atrás, y de ahí tenemos muchos especialistas IT Pro a los que se encarga trabajo de IT forensics y no tienen los conocimientos apropiados para hacerlo.

(casi) Cero Seguridad en routers WIFI vía UPnP

Se publicó hace poco un par de papers sobre el uso del protocolo UPnP como un herramienta para el acceso ilegal a un sistema. Acá hay un artículo muy bueno, en buen español, contando rápidamente y en general algunos bits & bytes de este tema. A diferencia de lo que sigue.


UPnP
UPnP (Universal Plug and Play Protocol), es un protocolo que permite la interacción punto a punto (p2p) entre dispositivos, cualquier dispositivo y medio en gral. puede soportar UPnP (routers, dispositivos que usan bluetooth, dispositivos firewire, cámaras web inalámbricas, un sistema operativo, etc.), y no se requiere drivers (instalados) para que funcione (se usa protocolos comunes ya incluídos en los dispositivos "UPnP Compatibles").

Qué se puede hacer con UPnP? Un dispositivo UPnP compatible de cualquier marca y tipo puede unirse dinámicamente a una red, obteniendo de otro/s dispositivo (un router x ejemplo) la dirección IP (servidores DHCP y DNS son opcionales), tambien anuncia su nombre y publica sus propias capacidades, al igual que puede preguntar a otros dispositivos sobre las suyas. Lo último, los dispositivos pueden abandonar la red sin dejar atrás ninguna información de estado detrás.


Cómo funciona UPnP
El protocolo funciona en texto plano, sin autenticación y en muchos dispositivos (el 90% al parecer), permite realizar tareas administrativas.

Sigo la explicación traduciendo libremente el texto de Gnucitizen (claro y conciso):

"UPnP está basado en varias tecnologías: SSDP (Simple Service Discovery Protocol), GENA (Generic Event Notification Architecture), SOAP (Simple Object Access Protocol) y XML (formato libre). Cada una de estas tecnologías es responsable de tratar con partes particulares del stack UPnP, Aquí hay algunas pocas cosas que deberías conocer acerca de UPnP:

- Direccionamiento: primero que todo, dado el hecho de que cada dispositivo necesita ser conectado en caliente a una red, este dispositivo debería tener un cliente DHCP (que le permitiría tomar una IP automáticamente). No es muy interesante, pero es cierto que casi siempre que el dispositivo no tiene habilitado DHCP, tampoco suele tener habilitado UPnP. 

(N.del T. yo discrepo de esto, si en el conjunto de instrucciones UPnP de un dispositivo "consultante" hubiera una extensión - privada - de comandos UPnP que permitiera configurar la IP/DNS del dispositivo "consultante" UPnP - por ejemplo, una aplicación UPnP en modo Administrador en XP que puede cambiar la configuración de red de la PC - , el cliente DHCP sería irrelevante, y si el dispositivo "consultado" brinda todos datos necesarios para conectarse a la red, bingo! conexión sin DHCP)

- Descubrimiento: Hay un momento en que SSDP entra en escena. Cada dispositivo UPnP compatible publica sus servicios en una URL particular. Para detectar todos los dispositivos UPnP se necesita enviar paquetes que tengan el formato SSDP (un paquete). No voy a detalles de cómo hacer esto, pero es trivial, muy similar a cómo funciona HTTP con pocas excepciones.

- Descripción: Una vez que los dispositivos son descubiertos, es momento de leer la descripción del dispositivo. Esta información está en archivos XML que pueden ser traídos desde la URL obtenida en el proceso de descubrimiento. Una vez que leemos los archivos, ya sabremos que clase de métodos (comandos) y parámetros son soportados por ese dispositivo en particular.

- Control: Aquí ya podremos controlar el dispositivo enviando los tipos correctos de pedidos como mensajes SOAP. En el cuerpo del mensaje SOAP colocamos el nombre del método (comando), parámetros y valores; luego lo envíamos al punto de control del dispositivo, el cual procesa el comando y envía algún tipo de output, que es tambien encapsulado en un mensaje SOAP.

Esto es cómo funciona en general UPnP. Se sugiere leer más sobre el procolo porque es algo que vale la pena conocer (como se ve luego)."

Hackeando con UPnP
Acá sigo con la traducción libre de uno de los papers:

"En general, cualquier dispositivo que soporte UPnP es hackeable. Supongamos que te conectas a una red WIFI y puedes ver que el gateway es algún tipo de router. Como atacante/pen-tester, tratarás de adivinar la contraseña de administración para poder usar la interfaz web de administración del equipo. Si el dispositivo fue dejado con la configuración por defecto es cuestión de pocas pruebas (o google) para encontrar la contraseña correcta. Qué ocurre si la contraseña fue cambiada? Agarrar los forzadores (de claves) por fuerza bruta!!!

Alto ahí. En situaciones como esa, yo probaría en cambio con UPnP. Primero que todo, UPnp no soporta ningun tipo de autenticación, segundo, muchos routers WIFI proveen funcionalidades UPnP para modificar todas las opciones de configuración del dispositivo y así, exponerlo a otros (tipos de) ataques subsiguientes.

En muchos dispositivos puedes modificar los valores de los DNS que usa el router (ello es equivalente a controlar el tráfico de capa 3: http, ftp, correo, etc.), otros soportan cambiar la contraseña de administración directamente, otros soportan el añadido de puertos redireccionados (port forwarding), rebootear el router, desconectar PPP, obtener (robar) las credenciales (user/pass) PPP, borrar las credenciales PPP, configurar valores WIFI, obtener valores WIFI, etc."

Por si no queda claro, la gente de Gnucitizen resalta en el paper claramente:

"La verdad es que es trivial acceder sin autorización y controlar un router WIFI, todo lo que un atacante necesita es: localizar el AP (router WIFI), enviar un pedido SSDP, leer la descripción del AP, verificar si existe un método (comando) para modificar los DNS, si es así (bastante seguro), ejecutar un pedido SOAP para cambiar el/los DNS a uno controlado por el atacante y luego seguir con el siguiente objetivo."

Todo ello sin ninguna autenticación, solo tu PC/notebook en el rango de la red WIFI, y con las herramientas apropiadas puedes hacer lo anterior.

UPnP desde LAN y/o Internet
Una cuestión clave de UPnP es que se creía que solo podía ser usado en entornos LAN. Gnucitizen ha publicado dos papers más,

- uno donde explican detalladamente cómo usar una vulnerabilidad XSS para acceder dispositivos UPnP
- otro donde explican cómo utilizar flash para hacer lo mismo de antes (sin ninguna vulnerabilidad de por medio), no está demás aclarar que ningun antivirus/antispyware/firewall detendría esto.

Conclusiones
Hasta el momento en que aparezcan la herramientas más automatizadas, es limitado el ámbito en que puden utilizar estos conocimientos; sin embargo la customización de paquetes en general es muy conocida a nivel de especialistas en seguridad/hackers, y la necesaria para utilizar UPnP como medio de penetración de sistemas no se sale de lo normal.

La gente de Gnucitizen declara que publican toda la información para hacer conocer estos riesgos y con la idea de que en poco tiempo la situación mejore dramáticamente en cuanto la seguridad de las implementaciones de UPnP en dispositivos.

Referencias

Hacking con UPnP
http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play

Hacking con UPnP desde Internet, usando XSS
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5

Hacking con UPnP desde Internet, usando Flash
http://www.gnucitizen.org/blog/hacking-the-interwebs

http://es.wikipedia.org/wiki/Universal_Plug_and_Play (muy general)
http://en.wikipedia.org/wiki/Universal_Plug_and_Play (mucho mejor)

Bots, algunos detalles

Los bots son la peor amenaza actual en la red. No sería demasiado importante si no fuera porque un bot en particular puede infectar decenas de miles de máquinas en relativamente muy poco tiempo y luego una persona puede controlarlos (a todos) en forma centralizada.


Bots: su uso típico
Para comenzar podemos explicar el concepto de botnet, "red de bots"; que es una red de pcs comprometidas ("infectadas" se diría si estuviésemos hablando de virus). 

Un bot es un spyware? Sí y no, sí porque realiza algunas tareas donde puede recabar información de la PC y no porque a veces el software del bot solo se dedica a acceder sin autorización a la PC y establecer comunicaciones subrepticias hacia la red.

Una botnet es sumamente valiosa para alguien que controle el total de pcs, algunas aplicaciones típicas son: 

- Spamming: usando las pcs para enviar el correo desde muchas IPs/dominios no bloqueados y que no figuran - todavía - en listas de dominios baneados).

- DDOS (Ataque Distribuído de Denegación de Servicios): donde usando muchas pcs se bombardea con tráfico un determinado servicio/s (haciendo que todas las pcs intenten acceder simultaneamente a un sitio por ejemplo).

- Keylogging: se guarda todo lo que se ingresa desde el teclado a un archivo y luego de lo envía a un punto central, donde el receptor puede buscar información relevante (claves, nros. de cuentas bancarias, etc.)

- Espionaje de tráfico: un bot puede revisar el tráfico de una pc buscando,archivando y enviando información relevante similar al keylogging.

- Distribución de más "malware": un bot puede intentar infectar más PCs con bots, virus, etc.

- Instalación de addons de publicidades y Browser Helper Objects (BHOs). Por ejemplo un operador de un sitio negocia con algunas empresas que le paguen por clicks recibidos en avisos. Con la ayuda de una botnet, dicho operador puede "automatizar" un clikeo frecuente de los avisos desde muchas PCs desde la botnet, incrementando sus ganancias y haciendo indetectable el fraude (las IPs de origen de los clicks pueden hacerse lo suficientemente pseudo-aleatorias para ello, según el tamaño de la botnet).

- Abuso de Google AdSense: algo parecido a lo anterior, pero sobre el sistema de publicidad de Google. Es relativamente poco común debido a la necesaria asociación de una persona real con una cuenta de Google a ser "abusada", estableciendo por ello una vía para la toma de medidas directas contra la persona (denuncia).

- Manipulación de estadísticas y juegos en línea: Debido a que cada nodo de la botnet tiene diferente IP, los mecanismos web de prevención de fraude basados en IP origen son sobrepasados, pudiendo fácilmente inclinar una encuesta en línea a favor de cierto tópico. El abuso de bots en juegos en línea es una línea de investigación seria actualmente, pero sin embargo debido al limitado uso debido a la sofisticación del ataque y las reglas de privacidad de los sitios atacados (sitios de apuesta en línea por ejemplo), ha habido pocas detecciones efectivas y la publicidad consecuente.

- Robo Masivo de Identidad: Utilizando la combinación factible de las varias tareas antes descritas se puede montar un mecanismo de robo de información suficiente para llegar a reemplazar o mimetizar el comportamiento online de una persona con fines ilícitos (utilizando todas sus claves, nombres, alias, cuentas de correo, cuentas de mensajería, cuentas bancarias y cuentas de pago en linea - paypal, etc.). Adicionalmente, el anonimato efectivo de las IPs dinámicas de PCs hogareñas (teniendo en cuenta las múltiples leyes de muchos países, la múltiples jurisdicciones policiales y múltiples jurisdicciones legales involucradas), las hace perfectos websites de phishing (sitios para robar información bancaria y otras) dinámicos, que aparecen y cambian de ubicación en la red tan aleatoriamente como sus dueños prenden y apagan sus PCs.


Modos de Infección
La pregunta que siempre queda sin responder es cómo se llega a infectar una pc. Una respuesta es obvia para cualquier especialista en seguridad pero para nada obvio desde el punto de vista del usuario hogareño.

Hay múltiples modos de infectar las PCs con bots. Normalmente un bot utiliza mecanismos automatizados para buscar e implantarse a sí mismo en una PC. Lo hace escaneando Internet en busca de PCs hogareñas, las que normalmente no están tan parcheadas o aseguradas como servidores o estaciones de trabajo empresariales conectadas a la red.
 
Otros modos, no automatizados tienen que ver con la interacción normal del usuario hogareño con Internet. Visitar páginas no seguras, abrir correos (spam especialmente), abrir attachments de correos (un ppt, flash, etc.), aceptar y abrir un archivo enviado vía mensajería (msn, yahoo, aol, etc.). El usuario hogareño no suele entender que muchas veces, aunque un remitente de correo sea conocido, una táctica muy normal de los bots es enviar correos con attachments desde máquina ya bajo control; otra posibilidad es utilizando un cuenta MSN en funcionamiento, enviar una imagen para que sea abierta en la PC de un conocido (que confía plenamente en un archivo enviado desde un contacto conocido).

Mecánica de Infección
Una vez descubierta la PC, según la sofisticación del bot, se prueba desde algún típico problema de seguridad asociado a puertos específicos, por ejemplo:
 
42 - WINS (Host Name Server) 
80 - www (vulnerabilities in Internet Information Server 4 / 5 or Apache)
903 - NetDevil Backdoor
1025 - Microsoft Remote Procedure Call (RPC) service and Windows Messenger port
1433 - ms-sql-s (Microsoft-SQL-Server)
2745 - backdoor of Bagle worm (mass-mailing worm)
3127 - backdoor of MyDoom worm (mass-mailing worm)
3306 - MySQL UDF Weakness 
3410 - vulnerability in Optix Pro remote access trojan (Optix Backdoor)
5000 - upnp (Universal Plug and Play: MS01-059 - Unchecked Buffer in Universal Plug and Play can Lead to System Compromise)
6129 - dameware (Dameware Remote Admin - DameWare Mini Remote Control Client Agent Service Pre-Authentication Buffer Overflow Vulnerability);

[Puedes ver información de background sobre algunas de estas vulnerabilidades buscando en los Boletines de Seguridad de Microsoft:

MS03-007 Unchecked Buffer In Windows Component Could Cause Server Compromise
MS03-026 Buffer Overrun In RPC Interface Could Allow Code Execution
MS04-011 Security Update for Microsoft Windows
MS04-045 Vulnerability in WINS Could Allow Remote Code Execution]

llegando en algunos casos a un análisis de vulnerabilidades para determinar si posee alguna que el bot tenga disponible para usar. Luego de esto la PC es "explotada" (se le aplica un software que hace uso de la vulnerabilidad para obtener acceso no autorizado a la PC), luego de tener acceso, el bot de la PC recien infectada realiza una serie de tareas, típicamente:
 
 - implantar una puerta trasera para acceder luego a la máquina (puede ser un rootkit o algo menos sofisticado)
 - abrir una vía de comunicación con el "comando central" de la red bots.
 - ponerse en stand-by para ordenes del comando central una vez que ha sido exitosamente agregada a la red bots.
 
 Siempre un paso adelante
 Algunos bots llegan hasta a descargar y parchear las vulnerabilidades que han utilizado y/o detectado al ingresar a la máquina. Incluso llegan a añadir archivos propios a la lista de excepciones de antivirus/antispyware/firewalls para asegurar un uso sin molestias de parte del software de seguridad de la PC, que luego de eso sigue funcionando casi normalmente.
 
 Muchos bots nuevos incorporan tremendos mecanismos que les permiten recibir actualizaciones y modificar sus archivos para camuflarse de los antivirus y antispyware.
 
 Los bots más exitosos sin embargo no son estándares, es decir fueron creados o fuertemente modificados por alguien y por ello la mayoría del software de seguridad no lo detectará. Por qué? simplemente porque el software de seguridad trabaja sobre software (bots, virus, etc.) que en general ya se ha difundido masivamente. Un nuevo bot o uno muy modificado puede incorporar nuevos mecanismos para engañar al soft de seguridad; luego de ese paso y con la PC ya incorporada a la red de bots, solo es cuestión de que el "manager" de la red de bots mantenga el código del bot un paso por delante de las actualizaciones del software de seguridad.
 
 Referencia:

 http://www.honeynet.org/papers/bots/

Dardo A. Valdez (yaco)