Español | English
rss facebook linkedin Twitter

Matrículas v2.0

Leo en una noticia que en Filipinas va a ser obligatorio tener identificados los vehículos registrados mediante etiquetas RFID ubicadas en las lunas. La finalidad: perseguir el robo de vehículos, vehículos sin seguro, etc.

En el tag irá almacenada información del vehículo y del conductor, incluyendo número de bastidor, modelo, año de fabricación y matrícula entre otros. Mediante un sistema de lectores repartidos por la red viaria del país será posible reconocer las etiquetas de los vehículos y mediante un sistema centralizado disparar alarmas en caso de anomalías como las comentadas anteriormente.

Algunos pueden aducir -y lo harán- que este sistema viola gravemente la privacidad de los conductores. Sin embargo, creo que es una medida que por muy poco dinero permite proporcionar tranquilidad tanto al conductor como al gobierno del país. Los sistemas de localización GPS con GSM llevan tiempo siendo instalados en los vehículos de forma opcional, siendo de especial utilidad en colectivos que los usan como herramienta de trabajo. No obstante, el beneficio que puede proporionar es menor que un sistema RFID.

Pensandolo bien, podría ser algo similar al pasaporte biométrico pero para vehículos. Si el sistema está correctamente diseñado se asume que los datos contenidos en la etiqueta estarán debidamente cifrados y firmados con un sistema de clave asimétrica. Si los países se ponen de acuerdo sería una solución idónea para la identificación de vehículos de forma internacional, que aseguraría un menor índice de delincuencia por robos de vehículos y serviría para controlar el parque móvil de los paises. ¿Una buena iniciativa para aplicar en Europa?

Álvaro Ramón
S21sec labs





Detectando un ZeuS

Ya llevamos un tiempo hablando de nuestro inseparable amigo, casi un colega de trabajo más: el ZeuS. Sigue dando guerra después de más de 3 años, cambiando y evolucionando para conseguir ocultarse mejor y realizar un fraude de mayor calidad. Pero lo que quizá no hemos comentado es cómo saber si nuestro amiguito está con nosotros, espiando todos nuestros movimientos e informando con detalle a sus padres, ya que los antivirus no son siempre efectivos.

Existen varias evidencias que nos pueden hacer pensar que estamos infectados por un ZeuS, en sus diferentes versiones:

  • Sistema de archivos

  • ZeuS deja rastro en el sistema de archivos cuando se encuentra instalado en el sistema, pero oculta y bloquea todos los archivos que crea, de tal forma que un usuario normal no podría verlos ni eliminarlos. La opción para lograr ver estos archivos es el uso de un software antirootkit que muestre archivos ocultos, dejando claro que algo pasa en nuestro equipo.


    Ahora mismo el nombre más habitual del binario es sdra64.exe y su directorio de configuración c:\windows\system32\lowsec, pero esto varía según versiones. Ya se hizo mención de los distintos nombres de los archivos de configuración, así que ahora enumeraré la nomenclatura de los binarios que hemos visto:

    ntos.exe
    oembios.exe
    twext.exe

    twex.exe
    sdra64.exe

    bootlist32.exe

    userinit32.exe

    bootwindows.exe


  • Registro de Windows

  • Otra forma de detectar la infección es a través del registro de Windows. El troyano asegura su ejecución al arrancar el equipo mediante la inclusión de la ruta del binario en la siguiente entrada del registro:


    HKLM/SOFTWARE/Microsoft/WindowsNT/Winlogon@Userinit

    De esta forma, simplemente abriendo el editor del registro (regedit.exe) podríamos localizar nuestro ZeuS:



  • Hooks

  • ZeuS necesita de varios hooks en diferentes funciones para poder realizar la inyección de código, captura de credenciales, etc. Estos hooks se situarán en en la mayoría de los ejecutables que se inicien y los más habituales son los siguientes:


    • ntdll.dll
    NtCreateThread
    LdrLoadDll
    LdrGetProcedureAddress
    NtQueryDirectoryFile
    • user32.dll
    GetClipboardData
    TranslateMessage

    Para saber si están colocados en nuestros procesos deberemos usar también algún software antirootkit:



  • Comportamiento raro en la banca electrónica

  • Es de esperar que a la gente que usa a diario la banca electrónica les resulte rara la adición de un campo extra pidiendo más credenciales de acceso, como puede ser la clave de firma, o que tras el login se soliciten todas las posiciones de la tarjeta de coordenadas. Quizá sea más complicada la detección para las personas que hacen un uso más ocasional del aplicativo, pero en cualquier caso lo ideal sería consultar con la entidad bancaria cuando se note alguna diferencia o elemento extraño. Este sería un ejemplo antes y después de la inyección de ZeuS:



  • Parámetros extra (lado del servidor)

  • Normalmente al añadir campos adicionales mediante inyección HTML estos parámetros extra viajan también al servidor del banco, que, dependiendo del código inyectado, podrá localizarlos y generar una alerta informando de una posible infección.



  • Mutex creados por el troyano

  • Por último, y como detección de nivel avanzado, se puede comprobar la ejecución del troyano en el sistema gracias a la existencia de varios mutex que éste crea. Se podría entonces realizar una llamada a una función como OpenMutex intentando abrir los mutex típicos de ZeuS y si no da error sería signo de una infección clara. Los mutex localizados hasta el momento son:

    __SYSTEM__64AD0625__
    _H_64AD0625_
    _AVIRA_2109
    _LILO_1909
    _SOSI_1909


Jose Miguel Esparza
S21sec e-crime




English version





Fugas de Información

En este post queremos concienciar a la gente de lo importante que es controlar los activos de información de una empresa.

Todos pensamos y sabemos que lo que se pueda decidir dentro de un consejo de dirección no debería ser conocido por el "gran público" e incluso los propios empleados hasta tener la certeza de que esa información puede ser divulgada. No sólo las grandes y no tan grandes corporaciones empresariales deberán tener en cuenta este tipo de escenarios, ya que también se han dado casos de partidos políticos que dicen haber sido espiados. No es cuestión de entrar en el debate de si es información certera o no, sino un simple ejemplo de qué puede pasar con una "posible fuga de información".

Independientemente de si ha sido por un espionaje industrial, o una fuga -intencionada o por descuido- de información confidencial, las consecuencias de que cierta información sea de carácter público (con público se refiere a que personas no autorizadas que puedan divulgar/explotar dicha información) pueden ser muy graves, tanto económicas como a nivel de marca o posicionamiento estratégico.

Pongamos tres escenarios de ejemplo:

  • Imaginemos que la empresa A que cotiza en bolsa está pensando en adquirir o desprenderse de otra empresa para adhesionarla/venderla. Si la información es pública (cierto que a veces la rumorología hace estragos en este tipo de situaciones) la cotización de dichas empresas podrá variar sustancialmente provocando por un lado un perjuicio económico importante y por otro la posibilidad de sospechas de divulgación de información para beneficio propio por organismos oficiales.
  • Pongamos ahora el caso de que la empresa B, decide en su consejo de dirección "prescindir" de los servicios de un determinado departamento de su empresa. Si esta información se conoce, ¿cómo reaccionarán dichos empleados?, está claro que aumentarán riesgos de robo/divulgación de proyectos hacia empresas de la competencia o simplemente la desmotivación (con el impacto en el rendimiento laboral).
  • En este caso la empresa C está pensando en cambiar su imagen corporativa (logo por ejemplo) e invierte cierto dinero en "ir preparando" la nueva imagen. Resulta que otra empresa D "se entera" de esta maniobra y antes de que la empresa C dé a conocer al público su logo, D modifica el suyo, o genera uno nuevo para una nueva línea de servicios en los que es prácticamente igual. Consecuencia: la campaña publicitaria de C no tendrá el efecto deseado, con el consiguiente perjuicio económico.

En resumen, -la información es poder- y nosotros como el que más debemos proteger y controlar la nuestra para poder estar enterados por si existe algún tipo de filtración y así tomar medidas correctivas.

José María Arce Guillén
S21sec e-crime





Profibus (II)

Hoy continuaré con el post que escribió mi compañero Jairo la semana pasada sobre el protocolo de comunicación Profibus, más concretamente sobre la estructura de la trama y forma de comunicación.
Como bien se comentó en post anterior el protocolo Profibus establece reglas de comunicación desde el nivel de enlace hasta el nivel de aplicación. La estructura está basada únicamente en tres niveles (1, 2 y 7 de OSI) y trata de integrar redes de rango superior que usen el modelo OSI completo. Para ello necesita una pequeña adaptación de los niveles 2 y 7 que se realiza mediante una subcapa del nivel 7 llamada LLI, mediante una interfaz de protocolo llamada FMA (Fielbus Management) que enlaza con los servicios de los niveles inferiores.

En cuanto a la trama, se pueden distinguir tres formatos diferentes: tramas de longitud fija sin datos, tramas de longitud fija con datos y tramas de longitud variable. A continuación se muestra un esquema con los tres formatos:



En cuanto a los mensajes, pueden ser cíclicos y acíclicos. Los mensajes cíclicos permiten el intercambio de datos de baja prioridad, por lo que su tiempo de respuesta no es tan importante. Este tipo de mensajes disponen de los siguientes servicios:

  • SDN (Send Data with No Acknowledge): mensajes de difusión del maestro a todos los esclavos.
  • SDA (Send Data with Acknowledge): mensajes mediante los que se envian datos o funciones de control del maestro a uno de los esclavos (punto a punto).
  • RDR (Request Data with Replay): mensaje por el cual el maestro solicita datos a uno de los esclavos (punto a punto).
  • SRD (Send and Request Data): mensajes que permiten al maestro enviar y recibir datos de un esclavo (punto a punto).

La respuesta a cualquiera de estos mensajes está relacionada con el tiempo del ciclo de testigo entre todos los nodos que están activos.
Los mensajes acíclicos en cambio, permiten acortar el tiempo de respuesta de los datos críticos. De este modo, cuando llega el turno de cada estación maestra, ésta puede enviar un mensaje de difusión con todos los valores críticos de todos los esclavos. Esos valores están almacenadas en una tabla a la que pueden acceder todas las estaciones maestras.
Los mensajes acíclicos pueden ser de 2 tipos:

  • CRDR (Cyclic Request Data with Reply): permite transferir datos a una única estación remota y al mismo tiempo solicitar datos que el usuario remoto había dejado disponibles previamente. La transferencia de datos, en este caso, es opcional. Tan pronto como se recibe la trama sin error, se transmiten los datos solicitados.
  • CSRD (Cyclic Send and Request Data)

La petición de este tipo de mensajes se hace mediante un mensaje de difusión por el que la estación maestra realiza una petición a cada estación esclava (realiza dicha peticiones de manera consecutiva) y la respuesta de cada esclavo es de forma escalonada mediante una instrucción de lectura rápida (no se pierde tiempo en la orden de procesamiento en cada estación esclava ya que la petición se realiza anteriormente mediante un mensaje de difusión). El esquema es el siguiente:


Una de las ventajas de Profibus respecto a otros buses de campo puede ser al existencia de una norma estable EN 50170 y las características que tiene por las que se cubren un gran abanico de aplicaciones en procesado, fabricación y automatización de procesos. Se podría mencionar alguna ventaja más como bajo coste de conexión y cableado, permite integrar dispositivos menos inteligentes, tiene una fácil configuración, cubre necesidades en tiempo real, transmite pequeñas cantidades de datos...

Fuentes:
http://www.santiagoapostol.net/srca/buses/profibus.pdf
http://www.etitudela.com/profesores/mpm/profibusomron/downloads/profibus1.pdf
http://www.dte.upct.es/personal/manuel.jimenez/docencia/GD6_Comunic_Ind/pdfs/Tema%208.pdf


Iker Berriozabal
S21sec labs





Seguridad Vial

Hace muy poco tiempo, más concretamente la semana pasada, en este mismo blog se publicó una noticia haciendo referencia a la modelización de forma automática del comportamiento de peatones y conductores dentro de una calle. De esta forma, visualizando el comportamiento de ambos actores (peatones y conductores) se pueden evitar numerosos accidentes de tráfico.

Pero bien, este modo de actuar solo es válido en ciudades y zonas urbanas donde podamos instalar infinidad de cámaras para la monitorización del tráfico. Es por esta razón, la de evitar accidentes de tráfico y, de esta forma, aumentar la seguridad al volante, lo que ha llamado mi atención el proyecto Drivsco.

El proyecto Drivsco, propulsado por la universidad de Granada en conjunto con otras universidades europeas, tiene como objetivo la creación de un sistema capaz de aprender el comportamiento de un conductor y actuar de forma proactiva ante un comportamiento no habitual de dicho conductor dando uso a diversos mecanismos de predicción.

Para hacer efectivo el sistema y atendiendo con las publicaciones del proyecto, el sistema está dotado de un sistema GPS para un primer análisis del terreno a analizar, de una FPGA basada en flujos ópticos capaz de analizar los índices lumínicos, velocidad u otros factores del medio. Además de estas dos características principales, unido al uso de cámaras y otros sensores necesarios, el sistema se ha basado en redes neuronales de tercera generación, conocidas como Spiking Neural Network (SNN), para el aprendizaje del comportamiento del conductor.

Entre los resultados publicados en revistas científicas como "IEEE Transactions on Image Processing", "IEEE Transactions on Vehicular Technology" e "IEEE Transactions on Circuits for Video Technology" cabe destacar que el sistema diseñado por estas universidades ha aprendido de una manera precisa la forma de conducir de la persona al volante, un paso muy importante en este campo.

Como conclusión mencionar que el sistema es un gran adelanto en el mundo del automovilismo como medio para la prevención de accidentes al volante. Del mismo modo y haciendo alusión a las palabras de uno de sus creadores el sistema no ha sido diseñado para conducir por nosotros sino como medio de ayuda para la conducción.

Aitor Corchero Rodríguez
S21sec labs





S21sec en el SIMO 2009

Estos días estamos participando en el SIMO 2009 (Feria internacional de Servicios y Soluciones TIC para empresas) como Partners de Microsoft. Podéis encontrarnos en el pabellón 7, pabellón exclusivamente dedicado a Microsoft y todos sus Partners.

Estamos realizando la presentación de nuestro nuevo producto Bitacora Horizon, gestión remota de la seguridad de los equipos informáticos. Os animamos a conocerlo en nuestra página web.



Para inscribiros, podéis hacerlo directamente a través de la página del SIMO 2009

Nos encantará conoceros y poder compartir impresiones con vosotros.

Podéis descargaros aquí el folleto informativo.





Hackeando la gripe A

Hackeando la gripe A

En plena fiebre de la gripe A, leí un artículo escrito por Andrew «bunny» Huang
estudiante del MIT que pasó a ser mundialmente conocido por ser la primera persona en conseguir hackear la consola XBox de Microsoft y por la posterior publicación del paper Keeping Secrets in Hardware: the Microsoft XBoxTM Case Study en el que detallaba cómo consiguió «romper» el criptosistema hardware de la consola que me llamó mucho la atención por lo audaz de la reflexión y por las consecuencias que podría tener en el futuro lo que en él se planteaba.

Dado que el artículo original no tiene desperdicio, creo que sería imposible hacer un resumen del mismo sin una pérdida importante de información, así que, me he tomado la libertad de hacer una traducción más o menos libre del mismo que copio a continuación.



Sobre la gripe A (H1N1)


He leído un artículo fantástico en la revista Nature (vol. 59, pags. 931-939, publicado el 18 de junio de 2009) que resumía, no solo el estado actual en cuanto a conocimiento se refiere de la novedosa H1N1 —también conocida como «gripe porcina»— sino que, además, compara el virus H1N1 con otras cepas de gripe; en particular, describe en profundidad cómo los componentes patógenos —es decir, la parte que puede llegar matarnos— difieren entre si.

El virus de la gripe es realmente fascinante. Permitidme que me explaye un poco sobre él...

Comparación con los virus informáticos

¿Cuantos bits hacen falta para matar a un ser humano?

El virus H1N1 ha sido «desensamblado» (secuenciado) completamente y su «código» se encuentra disponible en la Base de Datos de Virus de la Gripe del NCBI (Centro Nacional de Información Biotecnológica). Por ejemplo, la secuencia completa de una muestra de gripe conocida como A/Italy/49/2009(H1N1) aislada de un homo sapiens femenino de 26 años que regresaba desde los EE.UU. de América a Italia (me encanta la precisión de los registros de esta base de datos), está disponible en la página web del NCBI; es sorprendente.

Estos son los primeros 120 bits de la secuencia:
atgaaggcaa tactagtagt tctgctatat acatttgcaa ccgcaaatgc agacacatta
Recordemos que cada símbolo representa 2 bits de información. Esta cadena se puede representar también como una secuencia de aminoácidos —a través de lo que, en informática, se conoce como tabla de lookup— en los siguientes péptidos:
MKAILVVLLYTFATANADTL
En este caso, cada símbolo representa un aminoácido que equivaldría a 6 bits (serían 3 codones de ARNm por aminoácido). En este «alfabeto», M sería Metionina, K Lisina, A Alanina, etc. (podéis encontrar la tabla de equivalencias aquí)

Para aquellos que no estén familiarizados con la biología molecular, el ADN tiene una equivalencia con el ARN en una relación uno a uno; el ADN, sería el equivalente al programa en disco, y, el ARN, sería la copia en memoria del mismo. Tras la «carga» del ADN, se produce una transcripción mediante la cual, las bases «T», se transforman en bases «U» (Uracilo). Recordad: cada par de bases representa uno de los cuatro posibles símbolos, es decir: A, T/U, G y C por lo que, cada una, se corresponde con 2 bits de información.

La proteínas son el resultado de la ejecución de un «programa» ARN. Estas, se sintetizan a partir de las instrucciones de ARN a través de una correspondencia «tres a uno». Como símil, podemos considerar las proteínas como pixels en un frame-buffer. Una proteína, vendría a ser una imagen completa en la pantalla; cada aminoácido de la proteína, sería un pixel y, cada uno de estos, tendría una profundidad de seis bits (correspondencia 3 a 1 empleando un «soporte» que almacena 2 bits por cada par de bases) y, el color de cada pixel, se obtendría tras realizar una búsqueda en una paleta de colores (la tabla de traducción de codones) para, finalmente, ser renderizado en la pantalla. A diferencia del típico frame-buffer, las distintas proteínas varían en cuanto al número de aminoácidos (número de pixels).

Para asentar esto, veamos un ejemplo concreto: seis bits almacenados como «ATG» en el disco duro (ADN) se cargan en memoria (ARN) como «AUG» (recordad el caso especial de la transcripción T→U). La «ejecución» del programa RNA provoca la transformación de la secuencia «AUG» en un pixel (aminoácido) de «color» «M» o Metionina (que, biológicamente, es el codón de «inicio», es decir, es la primera «instrucción» de cualquier programa ARN válido). Para abreviar, y dado que existe una equivalencia 1:1 entre ADN y ARN, los bioinformáticos representan las secuencias genéticas en el formato del ADN a pesar de que, el mecanismo biológico, esté en formato ARN (tal y como ocurre con la gripe; veremos la importancia de esto más adelante).

Volviendo a la idea central del artículo, la subrutina ARN mostrada arriba, representa el gen HA que codifica la proteína Hemaglutinina, en particular, la variante H1 (este sería el origen del «H1» de la denominación de la ya famosa gripe H1N1)

Si pensásemos en los organismos como ordenadores con direcciones IP, cada grupo funcional de células del organismo estaría «escuchando» el entorno a través de su propio puerto. Así, al igual que el puerto 25 se corresponde con los servicios SMTP de un ordenador, el puerto H1 se corresponde con la la región de la traquea en los humanos. Como curiosidad, ese mismo puerto —el H1— se corresponde con la sección del tracto intestinal en los pájaros. Por tanto, el virus H1N1 atacaría al sistema respiratorio en un humano y el intestino de un pájaro. Por contra, el H5 —la variedad presente en el virus H5N1, causante de la mortífera «gripe aviar»— tiene como «puerto» la región que se corresponde con los pulmones. Como resultado, la variante H5N1 es mucho más mortífera porque ataca al tejido pulmonar provocando graves pulmonías. El H1N1 no es tan mortífero ya que se limita a atacar un puerto mucho menos peligroso provocando congestión nasal, y estornudos en vez del cese de la respiración.

Los investigadores siguen descubriendo más cosas acerca del puerto H5; el artículo de Nature indica que, quizás, ciertas personas tengan una mutación genética que impida que sus pulmones «escuchen» en el puerto H5 por lo que, los individuos que tuviesen dicha mutación, tendrían una mayor probabilidad de sobrevivir ante una infección por gripe aviar mientras que, aquellos de nosotros que tuviéramos abierto el puerto H5 tendríamos menos oportunidades de sobrevivir lo cual se podría expresar como "al your base pairs are belong to H5N1".

Así que, ¿cuantos bits tiene una instancia de H1N1? Según mis cálculos, en bruto, serían 26.022; realmente habría 25.054 bits codificadores —y digo aproximadamente porque, el virus, posee el equivalente a código auto-modificable con el fín de secuenciar dos proteínas distintas a partir del mismo gen (una característica muy interesante, por cierto), por tanto, es difícil identificar qué contaría como código y qué sería equivalente a los NOP sleds típicamente utilizados cuando se escribe código auto-modificable—

Por tanto, hacen falta unos 25 kilobits —3,2 kbytes— de datos para programar un virus que posea ciertas oportunidades de matar a un ser humano. Es bastante más eficiente que un virus de ordenador como el MyDoom que precisa de unos 22 kbytes para realizar su «trabajo».

Es humillante que hagan falta apenas 3,2 Kb de información genética, para matarnos. Supongo que, con 850 Mbytes de información genética en nuestro genoma, entra dentro de lo posible que haya uno o dos exploits en él.

Hackeando la gripe porcina

Una consecuencia interesante de haber leido el artículo de Nature y tener acceso a la secuencia del virus es que, ahora, sé como modificar la secuencia del virus para hacerlo más mortífero.

Sería así:

El artículo de Nature menciona, por ejemplo, que las variantes del gen PB2 de la gripe con un aminoácido de tipo Glutámico en la posición 627 de la secuencia, tienen una patogenicidad bastante baja (no son especialmente mortíferos). Sin embargo, las variantes PB2 con Lisina en esa misma posición, son más peligrosas. Veamos, por tanto, la secuencia del PB2 de la variante H1N1. Buscando en la base de datos del NCBI nos encontramos:

601 QQMRDVLGTFDTVQIIKLLP
621 FAAAPPEQSRMQFSSLTVNV
641 RGSGLRILVRGNSPVFNYNK

Tal y como se puede ver en la anotación de arriba, en la posición 627 hay una E que es la representación del ácido Glutámico. Por suerte, se trata de la versión menos mortífera; quizás es la razón por la que, al final, en contra de los malos augurios pronosticados por los medios, no está habiendo tantos casos de fallecimiento por gripe A. Transformemos el código de arriba en código de ADN:

621 F A A A P P E Q S R
1861 tttgctgctg ctccaccaga acagagtagg

tal y como se puede ver, la secuencia «GAA» es la responsable de la codificación de «E» (ácido Glutámico); para modificar esta secuencia genética —y hacerla más peligrosa— simplemente hay que reemplazar la secuencia «GAA» por alguna de las codificaciones de la Lisina («K») que se puede expresar o bien como «AAA» como por «AAG». Por tanto, una variante más mortífera de H1N1 tendría una secuencia genética como la siguiente:

621 F A A A P P K Q S R
1861 tttgctgctg ctccaccaaa acagagtagg
^ changed

Ahí está. Un simple cambio en una de las bases —modificar dos bits— sería quizás suficiente para transformar la variante actual de gripe porcina H1N1, relativamente inofensiva, en una variante del virus de la gripe más peligroso.

Teóricamente podría aplicar una larga serie de procesos biológicos bien conocidos para sintetizar esta secuencia e implementar esta variante más mortífera; como primer paso, podría ir a cualquiera de las muchas páginas web de empresas dedicadas a la síntesis de ADN (como, por ejemplo, a esta llamada «Mr. Gene») y pedir la secuencia modificada para completar mi pequeño y mortífero proyecto por algo menos de $1.000. Hay que tener en cuenta, sin embargo, que Mr. Gene, dispone de un proceso de supervisión para evitar la síntesis de secuencias de ADN que pudieran ser utilizadas para crear productos biológicamente peligrosos. No sé si monitorizarán específicamente variantes de HA como este gen de H1 pero, incluso si lo hicieran, existen procedimientos bien conocidos para producir mutaciones dirigidas que, posiblemente, podrían ser utilizadas para alterar una única base de ARN obtenido de una muestra de la variante normal de H1N1.

[Nota: acabo de darme cuenta de la existencia de esta cita en el artículo de Nature: Neumann, G. et al Generation of influenza A viruses entirely from cloned cDNA. Proc. Natl Acad. Sci. USA 96, 9345-9350 (1999). Este artículo explica como fabricar tu propio virus de la gripe A. Una lectura interesante.]

Gripe adaptable

Antes de que alguien se pueda sentir insultado por este pequeño hack, démosle a la gripe el respeto que se merece; después de todo, es capaz de matar con apenas 3,2 Kbytes de información y, a pesar de todos nuestros esfuerzos, no somos capaces de erradicarla. Realmente ¿sería capaz la gripe de averiguar esto por sus propios medios?

La respuesta sencilla sería sí.

De hecho, el virus de la gripe, ha evolucionado para permitir este tipo de adaptaciones. Normalmente, cuando se realiza una copia del ADN, una proteína de «detección de errores» es ejecutada sobre el genoma copiado para verificar que no se ha cometido ningún error. Esto mantiene la tasa de errores bastante baja pero, dado que la gripe utiliza una arquitectura basada en el ARN, necesita un mecanismo distinto al del ADN para realizar las copias.

Resulta que la gripe contiene dentro de su cápsula vírica un complejo protéico (Polimerasa Del ARN ARN-Dependiente) que está ajustada a su estilo de copia basado en ARN y que, de forma significativa, omite la proteína de detección de errores. El resultado, es que se suele cometer un error por cada 10.000 pares de bases copiadas. ¿Y cuantas bases contiene el genoma de la gripe? pues, unas 13.000 por lo que, de media, cada copia del virus de la gripe contiene una mutación.

Algunas de estas mutaciones no suponen ninguna diferencia; otras, transforman el virus en algo inocuo; y, probablemente, muchas, transforman el virus en algo mucho más peligroso. Dado que los virus se replican y distribuyen en cantidades astronómicas, la probabilidad de que este pequeño hack pueda terminar ocurriendo de forma natural es, de hecho, bastante alta. Esta podría ser, en parte, la razón por la que las autoridades sanitarias están tan preocupadas por el H1N1: no tenemos defensas contra ella y, aunque a día de hoy no es demasiado peligrosa, probablemente está a un par de mutaciones de transoformarse en un problema mucho más grave de salud pública.

De hecho, quizás debería estar intentando coger la cepa de la gripe H1N1 actual ya que, su peligrosidad, actualmente, está en la linea de la gripe normal —según escribía este artículo, el centro de control de enfermedades, ha contabilizado 87 víctimas de 21.449 casos confirmados o, un 0.4% de mortalidad (por contra, la gripe normal tiene una tasa de mortalidad inferior al 0.1% mientras que la famosa gripe Española, tuvo un índice de mortaildad del 2,5%; la gripe Aviar o H5N1 está ¡por encima del 50%! pero, por suerte, tiene dificultades para propagarse entre humanos). Contrayendo a día de hoy la variante H1N1 tendría la ventaja de desarrollar una inmunidad natural por lo que, si posteriormente, mutara y volviese de nuevo, tendría mayores oportunidades de luchar contra ella aplicando el famoso refrán de que «lo que no te mata, te hace más fuerte» ... bueno, quizás sería mejor esperar a que se desarrolle una vacuna.

Hay otra pequeña pero importante particularidad en el diseño de la arquitectura basada en RNA del virus de la gripe —aparte de la perfectamente ajustada frecuencia de mutación que demuestra— esta particularidad, consiste en que, la información genética, está almacenada dentro del virus como 8 pequeños fragmentos de ARN en vez de en una simple hebra (tal y como aparece en otros muchos virus y en las células). ¿Por qué es importante esto?

Veamos qué ocurre cuando un paciente sufre la infección simultanea de dos tipos de gripe. Si los genes estuviesen almacenados en una única cadena de ADN habría pocas posibilidades de que se produjera un intercambio de genes; sin embargo, dado que la gripe almacena sus genes en ocho partes bien diferenciadas, los bloques pueden combinarse libremente dentro de la célula infectada y son transformados de forma aleatoria en nuevas cepas según van replicándose. Por tanto, si uno tiene la mala suerte de coger simultaneamente dos variantes de la gripe, el resultado es —potencialmente—, una nueva variante de gripe según el ARN es copiado, mezclado y seleccionado de un metafórico sombrero y es, posteriormente, encapsulado en partículas virales. El proceso es elegante en cuanto a que, el mismo mecanismo, permite la mezcla de un número arbitrario de cepas en un solo individuo cuyo resultado es una mayor variación todavía en las partículas gripales.

En parte, esta es la razón por la que el H1N1 es llamado un virus triplemente-recombinante: ya sea mediante una serie de infecciones duales o, quizás, una desastrosa infección de múltiples variedades de gripe, la nueva H1N1 ha adquirido una mezcla de fragmentos de ARN que ha perfeccionado más aún, si cabe, su velocidad de propagación que, junto a la vulnerabilidad innata que sufre la humanidad frente al virus, supone la confluencia perfecta de factores para que se desencadene una pandemia.

No he estado siguiendo los últimos movimientos por parte de los creadores de virus de ordenador pero, si existiese una equivalencia a este modelo de intercambio de ARN, sería la de un virus que se distribuyese a si mismo como ficheros de código objeto sin enlazar junto a un pequeño programa que, tras la infección del huesped, re-enlazaría esos ficheros de una forma aleatoria antes de copiarse y distribuirse a si mismo. Aparte de hacer esto, intentaría localizar virus similares que estuvieran ya presentes en dicho ordenador y enlazaría partes de código de otros virus que se ajustasen a unas determinadas plantillas. Esta reordenación —y la novedosa técnica de re-enlazado de código— permitiría evitar la detección por parte de algunos antivirus que se basan para la detección en ciertos patrones fijos de código. Adicionalmente, provocaría la proliferación de un variado conjunto de virus que camparían a sus anchas y con comportamientos menos predecibles.

Por tanto, el virus de la gripe es notable por sus técnicas para lograr un mecanismo de adaptación multi-nivel basado tanto en la lenta evolución —en cuanto a las mutaciones se refiere—, como en la capacidad para alterar de forma drástica sus propiedades en una sola generación a través de los mecanismos de intercambio a nivel genético con otros virus (no es exáctamente como el sexo, pero es probablemente tanto o incluso más eficiente que este). Es también significativo que estas dos importantes características del virus surjan como consecuencia del uso de ARN en vez de ADN como medio de almacenamiento genético.

Bueno, ya es suficiente por esta noche, y, si habéis sido capaces de llegar hasta aquí, aprecio vuestra atención. Tiendo a irme por las ramas en mis artículos «reflexivos»; de hecho, hay más información muy interesante sobre la gripe A en el artículo de Nature. Si deseáis saber más sobre el tema, os recomiendo firmemente su lectura.



Fernando Braquehais
S21sec. e-crime





Monitorizando automaticamente el tráfico

Hace unos días salió la noticia sobre un sistema desarrollado por la Universidad de Castilla-LaMancha (UCLM) para monitorizar de forma automática en una calle el comportamiento de los conductores y peatones y por dónde cruzan éstos últimos. Aunque el sistema se ha diseñado para monitorizar un paso de peatones concreto, la parte más dificil, el saber cómo hacerlo de forma automática, ya está hecha. Ahora toca aplicar lo aprendido a más sitios.

El grupo de desarrollo además ha puesto una demostración online de la herramienta de monitorización en su servidor. Si vamos avanzando los frames o vamos a un frame determinado, podemos ver las distintas evaluaciones que da la herramienta sobre el comportamiento de los peatones y de los vehículos.

Analizando un poco las secuencias de ejemplo:

  • En los frames 300 a 350 podemos ver como analiza a un coche y podemos ver actividad normal,
  • Del frame 1600 al 1800 el cruce de un peatón por los bordes del paso de cebra dispara la alarma el sistema le asigna una conducta probablemente anormal
  • En el 3100 y siguientes como analiza una situación más compleja con varios coches, peatones y un camión.


La verdad es que cada vez abundan más sistemas automáticos de monitorización de "actividades humanas", alguno de los cuales ya hemos nombrado en este blog, como por ejemplo "Te vigilo.", "Vídeo-vigilancia inteligente contra los delincuentes en potencia", "Propicios días, agente Huxley..." en donde describíamos otros sistemas.

Pensad a dónde puede llegar este tipo de tecnología, si por ejemplo detecta un atropello o accidente en tiempo real y los encargados de protección civil sólo tienen que comprobar que realmente ha ocurrido un accidente, en vez de estar mirando cientos de monitores. Esto permite que con el mismo personal, se monitorice mucho más de lo que se hace actualmente y de forma mucho más eficiente. Sistemas que detectan un robo de forma activa y dan un aviso para su comprobación, que controlen de forma automatica los semáforos y por qué no, que lo hagan de forma conjunta. Para ésto ya existe un estándar de la FIPA (Foundation for Intelligent Physical Agents) que podéis consultar aquí.


[1] http://www.plataformasinc.es/index.php/esl/Noticias/Los-pasos-de-peatones-podrian-ser-vigilados
[2] http://www.alphagalileo.org/ViewItem.aspx?ItemId=61131&CultureCode=en
[3] http://grievous.inf-cr.uclm.es:1880/oculus/

Eduardo Morrás

S21sec - e-crime





Conferencias SOURCE Barcelona 2009

Estamos a tres días del comienzo de las conferencias SOURCE en Barcelona, y desde S21sec nos vamos preparando ya que haremos dos ponencias en las mismas; Vicente Díaz y David Barroso del departamento de e-crime hablarán sobre novedades en la evolución del troyano Zeus y Christian Martorella del departamento de Auditoría hablará de "Tactical Information Gathering" en la cual repasará nuevas fuentes de recolección de información pública en la etapa previa a un ataque.

Aún es posible apuntarse a las conferencias en este enlace (código con 25% de descuento "CMSOURCE")

Nos vemos en las conferencias





Tengo un 44 de talla de pie

Si ya es por sí difícil crear un correo de phishing donde no existan faltas de ortografía, o donde se utilicen imagenes de otras entidades financieras, o donde se mezclen idiomas, recientemente se ha encontrado al fin la forma de intentar engañar a todo el mundo sin tener que preocuparnos por esos nimios detalles.

Básicamente, tan sólo tenemos que pedir por todos los datos que nos interesan, y esperar que el usuario nos lo devuelva. ¿Para qué esforzarnos en intentar parecernos a una entidad y no levantar ninguna sospecha?

Estimado usuario, para comprobar que realmente es Usted, necesitamos que nos confirme los siguientes datos:
  • Dígame de qué banco es, y su usuario online
  • La contraseña del usuario anterior
  • ¿Tiene VISA, MasterCard, AEX?
  • ¿Hasta cuándo es válida?
  • ¿A nombre de quién está?
  • Necesitamos su código de seguridad
  • Y no olvide el PIN del cajero
  • ¿Qué número de permiso de conducción tiene?
  • ¿Está casado?
  • ¿Cuando nació?
  • Dígame su número de la seguridad social
  • ¿Cuál es el apellido de soltera de su madre?
  • ¿Y el de su padre? (si alguna vez ha tenido apellido de soltero!!)
  • Díganos sus inquietudes culturales
Aunque este tipo de correos no es nada nuevo, denota una falta de profesionalización y especialización total por parte de la gente que está detrás, nada que ver con su extremo, la gran complejidad y avanzada tecnología de software como Sinowal/Mebroot y los mecanismos o procedimientos de sus autores. En este blog se ha hablado ya varias veces de estos temas y realmente cada vez es más asombrosa la capacidad de mutación, adaptación al medio, y sobre todo, conocimiento de Internet para gozar de todos sus privilegios (anonimato, lavado de dinero, infraestructuras bullet-proof, etc.)

David Barroso
S21sec e-crime





PROFIBUS

Profibus es un bus para unir la red de proceso y de campo. Su nombre deriva de la contracción de su definición: PROcess FIeld BUS. Fue creado a finales de los 80 por una serie de empresas donde destacaban grandes empresas alemanas. Es un bus de tecnología abierta y definida en la norma EN50170 en el año 1996.

Profibus está divido en tres partes:
  • Profibus-DP: Orientado a las fábricas. Destinado a sustituir el cableado eléctrico entre PLCs y elementos de I/O.
  • Profibus-FMS: Automatización de propósito general. Para conectar dispositivos de campo inteligentes como PLCs, PCs y HMIs.
  • Profibus-PA: Orientado al proceso. Es el sustituto adecuado para reemplazar la tecnología de 4-20 mA.
Como todos los buses de campo, solo contempla las capas básicas dentro del nivel de capas establecido por la OSI, es decir, solo implementa las capas 1, 2 y 7.


En la norma se define que puede aceptar transmisiones desde los 9,6Kbit/s hasta los 12Mbit/s y puede llegar hasta distancias de 150 Km utilizando la fibra óptica como medio físico y jugando con la velocidad de la transmisión (cuanto más veloz sea menor será la distancia) y repetidores .

Profibus acepta hasta un total de 127 componentes, de los cuales solo 32 pueden estar establecidos como maestros. Los componentes se conectan mediante conexiones DB9. En la norma hay dos variantes de funcionamiento permitidas, maestro-esclavo y paso de testigo, si bien también se puede realizar una mezcla de ambos métodos en una configuración en árbol. En este último caso el modo de funcionamiento será de paso de testigo entre los maestros (activos) y mediante sondeo entre cada maestro y sus esclavos (pasivos).


Durante una trasmisión todas las estaciones escuchan a excepción de la que envía, la estación a la que va dirigido el mensaje responderá. Esto se cumple para todos los mensajes a excepción del paso del testigo. El testigo se va pasando de un elemento a otro tras un tiempo establecido, retornando al primero al finalizar la lista de elementos activos.

De Profibus han surgido una serie de ampliaciones como ProfiSafe, para dotar al conjunto de las medidas de seguridad más altas; y ProfiNet, aparecido en el año 2002 para comunicar los buses de campo con la red Ethenet mediante pasarelas o proxies.

Hoy en día es el bus más usado, tanto dentro de Alemania como fuera de ella para niveles de celda o célula (supervisión) y campo (controladores). Cada año se venden más componentes compatibles con este protocolo que lo hacen mantener su posición de liderazgo frente a otros modelos. Sus continuas actualizaciones y su comité de aceptación y test, hace que los productos que quieran cumplir el protocolo sean probados por lo que siempre serán garantía de funcionamiento.

En proximos post profundizaremos en el funcionamiento del protocolo y su formato de tramas.

Jairo Alonso
S21sec Labs





La (poca) sensibilidad de algunos

Ayer nos levantábamos con la triste noticia de la muerte de Patrick Swayze. Sin embargo, ya había gente preparada para hacer negocio con este tema, y no hablo de periodistas queriendo dar la primicia en su informativo. El spamdexing comenzó desde el momento de la muerte del actor, como indican en F-Secure, demostrando que además de tratar de defraudar, algunos tienen poca sensibilidad.

Y es que cualquier método sirve... Cada noticia de interés supone un aumento de peligrosidad, principalmente con ataques rogueware mediante posicionamiento en buscadores, como ha ocurrido con la muerte de Michael Jackson, la elección de Obama, los atentados del 11-S y todos sus aniversarios o más recientemente con el incidente de la tenista Serena Williams en el US Open.

Este método se presenta actualmente como una buena alternativa al spam tradicional, cuya calidad cada vez es peor y empieza a estar en desuso. Durante un tiempo se pensó que los datos que los coleccionistas de perfiles almacenaban servirían, entre otras cosas, para realizar spam de mayor calidad, personalizando los mensajes a los intereses de las víctimas y en su propio idioma. Sin embargo, podemos comprobar la mala calidad del spam a fecha de hoy:



Solamente ciertos casos de spam con concienciación social, como salvar el Amazonas, llevan actualmente al engaño, pero no hay que dejarse engañar, para salvar el Amazonas hay otros métodos ;)


Miguel López-Negrete
S21sec labs





Los peligros de ser popular

Las redes sociales, por su propia naturaleza, representan un objetivo atractivo para cualquier creador de código malicioso o malhechor dispuesto a realizar fraude de cualquier tipo.

No únicamente por la gran cantidad de datos personales y relaciones que se exponen en estas redes, que pueden permitir intentos de suplantación de identidad, ingeniería social o utilizar los datos para ataques de spear phishing. Hasta ahora el segundo motivo de atractivo no era semántico sino topológico, ya que la estructura de grafo altamente conectado de una red social permite una difusión óptima de cualquier tipo de gusano, permitiendo el acceso a una gran cantidad de víctimas potenciales en tiempo récord. Ejemplos de este tipo de ataques son el gusano Koobface que atacaba Facebook, o el de Mikeyy en Twitter.

Este tipo de códigos (o usuarios) maliciosos se aprovechan de servicios que permiten acortar URLs para la difusión inadvertida de direcciones maliciosas y que infectan el equipo del visitante al acceder a las mismas. Diversos fallos de Cross-site scripting han potenciado la proliferación de este tipo de ataques.

Sin embargo, el nuevo uso malicioso que se realiza de este tipo de servicios es el referente a su infraestructura. Algunos troyanos bancarios utilizan
servicios como el de Twitter trends para el registro de los dominios que usan en su red de servidores dedicada al fraude, evitando la anticipación en el bloqueo de los mismos.

La guinda final la pone el uso de estos servicios, que en el fondo son de mensajería para... mensajería! De este modo se ha descubierto recientemente la utilización de Twitter para la comunicación entre los bots para recibir órdenes del botmaster. Por una parte es una especie de covert channel que tiene altas probabilidades de pasar inadvertido entre el ingente tráfico que generan cada día tales servicios. Por otra, utiliza una infraestructura de alta disponibilidad y accesibilidad desde cualquier tipo de dispositivo.

Esto redunda en un ahorro por parte del desarrollo y de mantenimiento de infraestructura de la botnet, utilizando fraudulentamente un servicio de mensajería. Las nuevas fórmulas de utilización de la red siempre tienen su contrapartida en usos fraudulentos de las mismas, muchas veces sorprendiendo por su ingenio y haciendo patente la dificultad de anticipar amenazas o de detenerlas una vez descubiertas.

Vicente Díaz
S21Sec e-crime





Aldea Digital 2009 - México

Se ha realizado en México la primera Aldea Digital, lo que en España se conoce como "Euskal Party". Desde el pasado día 10 hasta el 13 de Septiembre de 2009, miles de jóvenes, aficionados y profesionales del mundo de la informática, se dieron cita en el Palacio de los Deportes, en la que será una de las primeras “LAN Party” de México organizado gracias a los esfuerzos del grupo mexicano OCESA, Euskal Encounter de Bilbao, España y el patrocinio de La Comisión Bi100/Bicentenario en la Ciudad de México.

S21sec estuvo presente con el equipo conformado por: Sergio Perea, Enrique Delgado, Manuel Pérez, Jesus Arizmendi, Aldo Medina. En la aldea Digital se contó con una red que fue capaz de conectar a más de 2000 computadoras a la vez contando con 10 GB de velocidad.

Tomando en cuenta de los comentarios que Perea nos había hecho acerca de la Euskal Party, puesto que en México no se había hecho algo similar, la verdad esta "LAN Party" sobrepasó por mucho las expectativas que teníamos. Había de todo un poco: Aficionados a las consolas, Diseño gráfico, Seguridad, Modificación de Hardware, Programadores y gente que simplemente iba a aprovechar el ancho de banda de la party para descargar lo que se les venia en mente en sus diferentes sistemas operativos. Se podía ver computadoras MAC, Windows en todas sus versiones y no podía faltar el amado GNU/Linux en todos sus colores y sabores.

Las actividades que se realizaron concursos de Scripting, Break-it, Diseño Gráfico en 2D y 3D, Quake 3, Mario Kart Wii, FIFA 2009, entre otros. El equipo decidió entrar al concurso del Break-it, que se trataba de un concurso de asalto al sistema, teniendo que pasar una serie de pruebas para llegar al final. No se trataba de tirar el sistema o infiltrarse, simplemente de sortear diversas pruebas o acertijos. Teniendo alrededor de 36 horas para completar los mayores niveles para ganar la competencia.

A decir verdad de tantas cosas que hubo en la Aldea Digital, nuestro tiempo se centralizó en ese concurso. El Break-it en principio se manejaba que duraba 24 horas, pero los organizadores decidieron alargarlo 12 horas más, en las cuales tuvimos el primer lugar y lo perdimos al final, todavía ni nos enteramos como fue.

Sin embargo, nos sentimos muy orgullosos de haber obtenido el "Segundo Lugar", no tanto por el premio, que la verdad muy significativo con respecto al primer lugar que fue una portátil DELL INSPIRON.

Sino porque para nosotros fue un verdadero reto, ir resolviendo cada prueba con la apremiantes del sueño, cansancio, investigación de temas que eran desconocidos, y que al final fueron bien recompensadas porque dejamos nuestro mejor esfuerzo, y esto no lo vemos como una derrota, sino más bien un aliciente para ¿porque no? prepararnos más y el año que viene traernos el Primer Lugar de este concurso en la Segunda Aldea Digital 2010, uno nunca sabe.

Aquí les dejo una foto de como se veía la aldea el primer día a las 10 am.




S21sec México





Mebroot Parte II: SCSI vs Object callbacks.

En el articulo anterior veíamos como el Mebroot había parcheado el sistema para evitar ser detectado intentado leer CLASSPNP!ClassReadWrite. Ahora le toca mover ficha a los anti-rookits.

Hasta este momento de la evolución del mebroot la forma habitual de leer a bajo nivel el MBR era lanzar una IRP a la dirección de CLASSPNP!ClassReadWrite:

mov edi, pdevice_object;
mov esi, irp;
push esi;
push edi;
mov eax, addr_ClassReadWrite;
call eax;


Llegados a este punto, esto no es posible ya que addr_ClassReadWrite esta oculta por el rootkit. Las herramientas de seguridad ya no podían trabajar a nivel de disk.sys había que trabaja a más bajo nivel si querían leer el contenido original del MBR y verificar la detección del malware.

La solución aportada fue trabajar a nivel de scsi:

La figura muestra el orden en que llegan las peticiones de lectura de disco a los diferentes drivers, de modo que si las herramientas anti-rootkits envían peticiones al driver de scsi, los hooks puestos en disk.sys no afectarán a la petición de lectura de disco y podremos hacer una lectura correcta.

El problema esta en hacer llegar esta petición de lectura( IRP ) a scsi. La forma utilizada fue hacer llegar la IRP a scsi.sys a través de MJ_INTERNAL_DEVICE_CONTROL de disk.sys. Vemos que en la solución aportada todavía hay una ligera dependencia de disk.sys.

Nueva detección y nuevo sample a escena! Esta versión del Mebroot nada tenía que ver con las anteriores en la forma de ocultarse en el sistema. Si anteriormente el método utilizado para ocultar el contenido del MBR era hookear la dispatch routine de los drivers, ahora el método evoluciona. El mebroot utiliza Object callbacks para ocultarse en el sistema. Esta técnica fue comentada por Skywing y Skape en Uninformed 8.

Para poder entender que son y como funcionan los objetos en Windows una lectura recomendada es Windows 2000 Object Management.

Este nuevo sample crea un nuevo _OBJECT_TYPE_ en Device\Harddisk0\DR0 de disk.sys y hookea la función ParseProcedure en la cabecera del objeto ( estructura _object_header ). Para comprobar que se ha creado un objeto nuevo, comprobamos antes de la infección que los dos devices de disk.sys son del mismo tipo, es decir, su _OBJECT_TYPE está descrito en la misma dirección de memoria. Sin embargo una vez que una máquina es infectada volvemos a comprobar la dirección de memoria del campo OBJECT_TYPE y comprobamos que se ha creado un nuevo objeto.

+0x008 Type             : 0x81689e70   _OBJECT_TYPE -->Nuevo Object type

.......

+0x038 DeleteProcedure : 0x805a0004 void nt!IopDeleteDevice+0
+0x03c ParseProcedure : 0x81305c20 long +ffffffff81305c20--> Hook
+0x040 SecurityProcedure : 0x8059ba70 long nt!IopGetSetSecurityObject+0


El objetivo de poner estos hooks en los objetos es hacer llegar al malware todos los intentos de lectura de disco, en este caso cuando se crea un handle de Device\Harddisk0\DR0 que es un device de disk.sys( vemos que sigue dependiendo de este driver ). De este modo si se crea un handle de Device\Harddisk0\DR0 el malware pone un hook en la dispatch routine de scsi.sys que evalúa( igual que el la versión anterior) las peticiones de leer el MBR de la máquina. Una vez cerrado el dispositivo( se cierra el handle ) el mebroot quita este hook de la dispatch routine y sigue invisible en la máquina.

En resumen, el modo utilizado para ocultarse lo sigue haciendo en las dispatch routine, pero en este caso en el driver scsi.sys, que está en un nivel de profundidad mayor que disk.sys. Como novedad aporta que el hook es "dinámico", por ponerle un nombre, solo lo pone cuando detecta que se van hacer lecturas de disco. La capacidad de que este hook se ponga y se quite cuando se produzcan lecturas de disco se debe a la manipulación de los objectos comentada en Device\Harddisk0\DR0 de disk.sys.

Una técnica muy limpia y hasta ese momento efectiva...

Alonso Candado Sánchez
S21Sec e-crime






Extracción de Información (1)

Reconocimiento y Clasificación de Entidades con Nombre

En este mismo blog se ha hablado múltiples veces sobre reputación online, búsqueda de personas en la web y en general el análisis de contenido textual con el objetivo de proteger los activos de información de una compañía en la web.

Para conseguir este objetivo repasaremos en sucesivos posts las tareas principales dentro de la Extracción de Información. El objetivo de la Extracción de Información es el de extraer automáticamente información estructurada a partir de documentos no estructurados. Algunos ejemplos son la extracción de todos los datos personales de un texto, la relación existente entre dos compañías, localización de eventos, etc.

Una de las principales tareas dentro de la Extracción de Información es el Reconocimiento y Clasificación de Entidades con Nombre (NERC). Esta tarea trata de reconocer unidades de información tales como nombres de persona, organizaciones, lugares y expresiones numéricas como fechas, cantidades monetarias, etc. Una de las personas más influyentes en este campo es Satoshi Sekine, quien definió un conjunto de 150 clases de entidades con nombre.

Algunos factores a tener en cuenta antes de enfrentarnos a esta tarea son:
  • Lengua: las particularidades lingüísticas de cada idioma y la gran diferencia a nivel de investigación y desarrollo en el procesamiento del lenguaje hace que el NERC obtenga resultados heterogéneos según la lengua en la que están escritos los documentos

  • Género literario y corrección lingüística: artículos periodísticos, científicos, informales, etc. utilizan distintos criterios semánticos, sintácticos y formales en su composición.

  • Dominio: textos sobre deportes, economía, cultura, etc. incluyen vocabulario y expresiones específicas del dominio.

Las técnicas empleadas en el NERC pueden dividirse en dos grupos: aquellas que utilizan reglas gramaticales construidas a mano, y sistemas de aprendizaje automático.

En el primer caso se codifican reglas particulares para cada tipo de entidad capaces de reconocer las entidad bajo un contexto y determinadas características como el tipo de caja tipográfica (palabras en mayúsculas, minúsculas, capitalizadas o con caja mixta), la categoría morfosintáctica (categoría gramatical, género, número, etc.) y características semánticas, definidas como listados de palabras que comparten un rasgo semántico en común (listado de ciudades, nombres de persona, etc.). Un regla sencilla para reconocer Universidades podría ser:

Universidad [PALABRA-CAPITALIZADA]? de [LUGAR]

donde el símbolo "?" indica opcionalidad. Esta regla reconocería Universidad Autónoma de Barcelona, Universidad Complutense de Madrid, Universidad de Navarra, etc.

En el segundo caso, el NERC mediante sistemas de aprendizaje automático, codifican un conjunto de rasgos de la palabra a analizar y su contexto en vectores. Algunos rasgos habituales son la caja tipográfica, categoría morfosintáctica, prefijos, sufijos, signos de puntuación (p.ej. I.B.M.), etc. Los métodos de aprendizaje supervisado se basan en la anotación manual del tipo de entidad en textos (corpus de entrenamiento) para que el sistema automáticamente cree un modelo a partir del cual reconocer y clasificar las entidades en nuevos textos sin anotar.

Estos sistemas han conseguido rendimientos similares a los humanos. Un 93,39% en la medida f-measure, que resume cobertura y precisión, frente al 97.60% en anotaciones realizadas por humanos, según el mejor resultado de la conferencia MUC-7.

El Reconocimiento y Clasificación de Entidades con Nombre se ha convertido en la piedra angular en cualquier sistema de Extracción de Información, y sirve de base en la resolución de tareas más complejas relacionadas con el procesamiento del lenguaje.


Israel Varea
S21Sec e-crime





NIST y audits para NESSUS

Hoy vamos a continuar el camino abierto en este post hace un par de semanas sobre las configuraciones en los equipos y como comprobar si son las correctas. Como ya se indicaba, algunos de estos ficheros están creados en colaboración con organismos de normalización, y dan las configuraciones óptimas para diversos sistemas operativos o ciertas aplicaciones. Aquí vamos a tratar de comentar cuanto se asemejan los ficheros que crean estos organismos de normalización a sus propias normas. En concreto vamos a realizar el estudio sobre el NIST, y sobre los controles que se usan en los sistemas de control.

En primer lugar vamos a comentar que pese a tener una normativa para sistemas industriales, la NIST SP 800-82, no posee ningún fichero de configuración para comprobar el cumplimiento en esta norma, por lo que el estudio tiene que ser independiente. En contraposición tiene varios ficheros de cumplimientos para los diferente sistemas operativos, pero solo tiene estándares para dos de ellos, en concreto son Windows y no los que se usan en el ámbito industrial. A la vista de estas premisas, lo que haremos será comprobar los cumplimientos con la normativa propia de seguridad, NIST SP 800-53, y de sistemas industriales, NIST SP 800-82, analizando los contenidos de los audits y viendo el cumplimiento sobre esta normativa.

Hemos de destacar de estas normas, que hay muchos puntos que no pueden ser verificados mediante los audits por no corresponder a seguridad informática, sino a seguridad física, documentación, etc.

Más o menos en todos los audits de sistemas operativos que hemos analizado presentan la misma estructura y los mismos controles. Estos controles son, agrupados por tareas: comprobación de servicios activos, permisos en ficheros y carpetas, política de contraseñas, configuraciones de sesión de usuario y de red, privilegios de los usuarios, cuentas de usuario y los logs. Si comprobamos todos los controles vemos que se comprueban aproximadamente el 90% de los controles que la norma aplica sobre los equipos. Además, los audits controlan más categorías que las que se definen en estas normas aumentando el nivel de seguridad en algunos puntos.

Como ejemplo podemos ver:
1.- Control AU-4: Audit Storage Capacity: Se asigna suficiente espacio para el log y se configura para que no pueda sobrepasar dicha capacidad.

<custom_item>
type: REGISTRY_SETTING
description: "MaximumApplicationLogSize"
value_type: POLICY_DWORD
value_data: [16384000..MAX]
reg_key: "HKLM\System\CurrentControlSet\Services\EventLog\Application"
reg_item: "MaxSize"
info: "Title - Maximum Application Log Size"
info: "Description - Inadequate log size will cause the log to fill up quickly and require frequent clearing by administrative personnel. An exception is for NT workstations that do not share resources. The smaller size should allow sufficient audit information for supporting the investigation of suspicious events, but since it is overwritten, does not require administrator interaction for clearing the file. Microsoft recommends that the combined size of all the event logs (including DNS logs, Directory Services logs, and Replication logs on Servers or Domain Controllers) should not exceed 300 megabytes. Exceeding the recommended value can impact performance."
</custom_item>


2.- Control SC-10: Network Disconnect: La conexión a la red de termina con el fin de sesión o por un tiempo prefijado de inactivdad.

<if>
<condition type:"and">
<custom_item>
type: REGISTRY_SETTING
description: "SessionTimeout"
value_type: POLICY_DWORD
value_data: [MIN..15]
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "AutoDisconnect"
info: "Title - Microsoft network server: Amount of idle time required before suspending session"
info: "Description - Administrators should use this setting to control when a computer disconnects an inactive SMB session. If client activity resumes, the session is automatically reestablished."
</custom_item>
<custom_item>
type: REGISTRY_SETTING
description: "SessionTimeout"
value_type: POLICY_DWORD
value_data: 0
check_type: CHECK_NOT_EQUAL
reg_key: "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item: "AutoDisconnect"
info: "Title - Microsoft network server: Amount of idle time required before suspending session"
info: "Description - Administrators should use this setting to control when a computer disconnects an inactive SMB session. If client activity resumes, the session is automatically reestablished."
</custom_item>
</condition>
<then>
<report type:"PASSED">
description: "SessionTimeout"
info: "Title - Microsoft network server: Amount of idle time required before suspending session"
info: "Description - Administrators should use this setting to control when a computer disconnects an inactive SMB session. If client activity resumes, the session is automatically reestablished."
</report>
</then>
<else>
<report type:"FAILED">
description: "SessionTimeout"
info: "Title - Microsoft network server: Amount of idle time required before suspending session"
info: "Description - Administrators should use this setting to control when a computer disconnects an inactive SMB session. If client activity resumes, the session is automatically reestablished."
</report>
</else>
</if>

En definitiva podemos decir que los audits ayudan con el cumplimiento de estándares, pero no podemos fiarnos de ellos solos para decir que se cumple una norma u otra por lo que es necesario un estudio posterior; si bien, nos valen para darnos cuenta de que nuestro sistema no cumple con ella y por lo tanto puede tener graves problemas de seguridad.

Jairo Alonso
S21sec Labs





Este mensaje se auto-destruirá en 5 segundos .... 4 .... 3 ....

Este final de mensaje más típico de las películas de espías o de los cómics de Mortadelo y Filemón ha llegado también a nuestros días y ha saltado de lleno a la era digital. En algunos post pasados [1, 2] se ha hablado sobre la necesidad de que la información perviva a lo largo del tiempo de forma indefinida. Sin embargo hay otra posición a tener en cuenta, el hecho que queramos garantizar que la información sea perecedera y no pueda volver a ser accesible en un periodo de tiempo determinado. En un principio puede parecer algo sin mucha utilidad ya que basta con borrar la información una vez utilizada, sin embargo, la cosa no está tan clara. Un vez enviamos algo a través de Internet perdemos, en parte o totalmente, el control sobre esa información. ¿Quién nos dice que el email que hemos mandado no haya sido cacheado o almacenado en los backups del servidor de correo?. Lo mismo pueda pasar con objetos web como mensajes privados de Facebook, documentos de Google Docs o fotos privadas almacenadas en servicios Flirk o Picasa Web. La información ahí almacenada puede persistir incluso después haber cancelado nuestra cuenta, y puede que bien por una brecha de seguridad o por requerimientos legales esta información pueda volver a salir a la luz.

En realidad esta no es una inquietud nueva. Ya han surgido servicios que, por ejemplo, permiten que los mensajes al móvil o emails sean de una sola lectura. Ésto se consigue generalmente almacenando el mensaje en un servidor y enviando un link de acceso; de forma que una vez se accede al mensaje la primera vez, el mensaje se borra y no vuelve a ser accesible. O el curioso DVD-D comercializado por Einmal, DVD que deja de ser utilizable pasadas 48 horas desde que abrimos la caja. Sin embargo, el tema no ha dejado de estar de actualidad. Recientemente, investigadores de la Universidad de Washington, han propuesto un sistema basado en el cifrado de datos que permite que la información tenga un tiempo de vida y no pueda ser recuperada pasado un intervalo de tiempo. El sistema en cuestión se presentó en un artículo en 18º USENIX Security Symposium (18th USENIX Security Symposium). Vanish, que así es como se llama el sistema, está basado en un cifrado de datos donde el mensaje en cuestión es encriptado y la clave se divide en diversos fragmentos que se distribuyen aleatoriamente por una red P2P. Estos objetos que contiene la clave tienen un tiempo de vida, pasado el cual, se destruyen automáticamente de forma que no se pueda recuperar la clave y por tanto no se pueda descifrar el mensaje original. De esta forma, cualquier persona que tenga el mensaje puede descifrarlo usando el sistema Vanish si el tiempo de vida de éste no ha expirado. Actualmente existe un prototipo del sistema que, bien a través de un plug-in de Firfox o bien a través de un servicio web, permite probar parte su funcionamiento de forma experimental.
Obviamente, Vanish no es un sistema de protección de datos, ya que podemos descifrar el mensaje y guardarlo en su forma original. Sin embargo, es una forma que puede permitir tener cierto control sobre la persistencia de elementos que distribuimos a través de Internet. Aunque no sea tan espectacular como que nuestro ordenador se incendie repentinamente una vez el mensaje haya caducado.


Guzmán Santafé
S21sec labs





Your Malware has been updated !

De entre las características añadidas a los troyanos de banca resulta curiosa la relativa a las actualizaciones, la posibilidad de que mientras un antivirus está descargando sus actualizaciones pertinentes, es posible que paralelamente un troyano bancario esté descargando información para actualizarse a sí mismo, y así por ejemplo, enviar los datos robados a una nueva dirección aún no añadida a las blacklists de los dispositivos de filtrado en nuestra red corporativa.

Uno de los mejores ejemplos de troyano para ilustrar el caso es nuestro archiconocido Zeus (Zeus/Zbot/Wnspoem), el cual ya hemos diseccionado en otras ocasiones en este blog.

Una vez ejecutado el binario de Zeus, éste crea una copia de si mismo y escribe la clásica entrada en el registro que garantiza su ejecución al reinicio del sistema. Pero esto no es todo, además Zeus se encarga de que la máquina infectada pueda recibir actualizaciones, tales como la dirección del servidor al que se envían los datos capturados, o fragmentos de código HTML maligno para inyectar en las peticiones que se realizan desde la máquina infectada.

Como decíamos antes, una vez ejecutado el binario se crea el fichero de configuración, que toma diferentes nombres, como por ejemplo video.dll, sysproc86.sys, o local.ds.

En la siguiente lista encontramos ejemplos de donde se suele encontrar el fichero de configuración de Zeus en una máquina infectada.

C:\WINDOWS\system32\wsnpoem\video.dll
C:\WINDOWS\system32\sysproc64\sysproc86.sys
C:\WINDOWS\system32\twain32\local.ds
C:\WINDOWS\system32\lowsec\local.ds

El fichero de actualización nuevo se suele colgar en un servidor web desde donde posteriormente la máquina infectada lo descarga y ejecuta la actualización.

Si localizáis alguna copia de este fichero, veréis que el código está cifrado. Las primeras versiones de este fichero eran relativamente “fáciles” de descifrar, las nuevas versiones implementan un sistema más complejo y exclusivo, que vincula al fichero de configuración con un binario único que contiene la clave que lo descifra. Si bien, en los laboratorios de S21sec e-crime hemos desarrollado una suite de herramientas que nos permiten manejar estos ficheros con flexibilidad y extraer la información rápidamente.


Sergi Roselló León
S21sec e-crime





Informe de ENISA sobre el fraude en cajeros automáticos


Ante la alarmante cifra desvelada por ENISA que revela unas pérdidas de unos 500 millones de euros, ENISA hace un llamamiento entre los consumidores para que sean más conscientes de los riesgos existentes y tomen precauciones para evitar convertirse en víctimas del fraude. El rápido crecimiento del número de cajeros automáticos, combinado con ataques más sofisticados y el incremento e innovación de técnicas de fraude, se ha traducido en un aumento alarmante del 149% en el fraude a través de cajeros automáticos en 2008.


Estos preocupantes resultados, junto con la información y los estudios que se han realizado sobre fraude en cajeros automáticos y las recomendaciones para ayudar a detectarlos y evitar convertirnos en nuevas víctimas, se han publicado en el estudio de ENISA titulado "Fraude en cajeros automáticos: Descripción de la situación europea y las reglas de oro para poder evitarlo”.

El número de incidentes en cajeros automáticos en Europa creció un 6% el año pasado alcanzando los 400.000 casos, muchos de las cuales se localizaron en aeropuertos y gasolineras. El setenta y dos por ciento de los casos de fraude en cajeros automáticos europeos se localizan en sólo cinco países: Reino Unido, España, Alemania, Francia e Italia.

El dinero en efectivo obtenido a través del fraude en cajeros continua siendo el método preferido por los delincuentes que obtienen los números PIN con una amplia gama de técnicas que van desde el ‘shoulder surfing’ (cuando ven el PIN que metes en el cajero mirando por encima de tu hombro) a técnicas de skimming complejo (cuando instalan algo en el lector de tarjetas para clonar la tarjeta). Estas técnicas pueden implicar el uso de una pequeña cámara espía, una superposición falsa de teclado e incluso cajeros falsos, mientras que cada vez más, la tecnología Bluetooth es utilizada para transmitir información tanto de la tarjeta como de su PIN a un portátil cercano. Tan solo, durante 2008, un total de 10.302 incidentes de skimming se registraron en Europa.

Otros métodos utilizados en este tipo de fraude para extraer dinero son la captura y recuperación de las tarjetas de los usuarios, detener la retirada en medio de una transacción y completarla una vez que el usuario ha abandonado el cajero. Las bandas criminales organizadas también están utilizando sofisticadas técnicas de phishing y piratería en los sistemas informáticos de los bancos y los sitios web para obtener información de cuenta y PIN.

Los robos en cajeros automáticos y las agresiones físicas también han sufrido un aumento de un 32% en los últimos 12 meses a partir de los ataques físicos contra la integridad del cajero.

ENISA ha elaborado su lista de reglas de oro para ofrecer la máxima protección con el mínimo esfuerzo.

Las Reglas de Oro de ENISA:

Elección de un cajero automático

1. No utilizar los cajeros automáticos que contengan algún tipo de señalización adicional o de advertencias
2. Trate de usar los cajeros automáticos situados dentro de las entidades bancarias
3. No utilizar los cajeros automáticos independientes o fuera de las oficinas bancarias.

Entorno físico

4. Utilice cajeros automáticos que estén a la vista y bien iluminados
5. Tenga cuidado con los extraños y compruebe que se encuentran a una distancia razonable

La realización de operaciones en los cajeros

6. Preste especial atención a la parte delantera de la máquina para observar si han sido manipulados
7. Preste atención al lector de tarjetas para ver si hay signos de algún dispositivo adicional
8. Mire cuidadosamente si nota alguna diferencia o algo inusual en el teclado de marcación
9. Compruebe que hay cámaras
10. Proteja su PIN tapando el teclado durante la marcación
11. Informe de inmediato cuando el cajero no le devuelva su tarjeta

Comprobaciones

13. Examine con frecuencia su extracto del banco
14. Informe inmediatamente cualquier actividad sospechosa





Drive-by ejemplo

El ataque de descargas inadvertidas más conocido como "drive-by downloads" ya se comentó en nuestro blog en cuanto a su funcionamiento. Pero nunca está de más realizar una pequeña aproximación para comprobar que realizan estos ataques en nuestros equipos.

Las técnicas actuales para distribuir malware se pueden dividir en dos categorías principales:
  1. Técnicas de ingeniería social: usadas por los atacantes para que el usuario se descargue y ejecute el malware. Todos hemos visto páginas con dudosos métodos de análisis informándonos de que nuestro equipo está plagado de virus y necesitamos descargarnos un soft{mal}ware para dejar nuestro equipo más limpio que el cuello de un sacerdote.
  2. Aprovechamiento de vulnerabilidades del navegador: Es el método más enrevesado y totalmente transparente para nosotros los usuarios. También es el método de infección más común tal y como se muestra en el gráfico de abajo. Consultad el paper "All your iFRAMEs point to us" para más detalles de cómo funcionan y la infraestructura que lo sustenta.



Según el informe "Digital World, Digital Life", pasamos un 30% de nuestro tiempo libre navegando por internet. Imaginad una situación corriente, navegando por nuestro portal favorito de noticias, pulsamos sobre ese enlace que nos lleva a la fuente original, ahora este otro para ver comentarios y así sucesivamente hasta terminar con decenas de páginas visitadas. Una de estas tantas páginas que hemos visitado apenas unos segundos, nos ha dejado un regalito MADE IN LOS MALOS.

Lo que ahora mostramos es un pequeño ejemplo real de lo que paso en nuestro equipo "controlado" simplemente por visitar una web que contenía un ataque de este tipo y sin realizar ninguna acción por nuestra parte, apenas estuvimos visitándola durante 30 segundos y esto es lo que nos hizo:

1. El proceso iexplore.exe creó el binario C:\WINDOWS\Temp\svhost32.exe
2. Este binario se encargó de modificar varias entradas del registro para:
Deshabilitar la cache: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache"
Deshabilitar cookies: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cookies"
Deshabilitar historial: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\History"
Habilita la navegación por proxy: "SetValueKey","HKLM\SYSTEM\ControlSet001\Hardware Profiles\0001\Software\Microsoft\windows\CurrentVersion\Internet Settings\ProxyEnable"
Configurar un proxy: "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer"
Y crear el fichero: "C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5 \1YMCNUWN\hosts[1].txt"
3. No contento con todo esto también se creo el binario c:\i1gb0a.exe que a su vez se encargó de crear otro binario sdra64.exe con otras pretensiones.


Todo lo anterior se creó en nuestro S.O sin nuestro consentimiento ni conocimiento. El análisis de la secuencia total de lo ocurrido así como de los archivos, conexiones y binarios creados conlleva un esfuerzo de horas de trabajo fuera del alcance de este post.

El objetivo de este post es concienciar a las 2 principales víctimas sobre la existencia de este tipo de ataques; nosotros los usuarios y a los responsables de las webs que sin percatarse de ello favorecen la difusión de este tipo de contenido malicioso.

Cómo ya comentó Elvira en el post "Drive-by downloads" el dejar de visitar sitios de contenido para adultos apenas disminuye las posibilidades de sufrir uno de estos ataques. Cualquier web del estilo que sea puede contenerlo. Uno de los consejos que suele funcionar es navegar con software totalmente actualizado para que estas webs no se puedan aprovechar de una vulnerabilidad de nuestro navegador o alguno de sus plugins, principales vectores de entrada de estos ataques.

En cuanto a los responsables de sitios web, vigilad el código de vuestros sitios, especialmente los iFRAMES, y los logs y estadísticas de tráfico son una buena fuente para busar patrones sospechosos de que algo ocurre antes de que nos denuncien por colaborar con nuestra web en la difusión de contenido malicioso o peor aún, ensuciar nuestra imagen de confianza.

Emilio Casbas
S21sec e-crime






(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2012 - Todos los derechos reservados


login