Nuevo canal de comunicación de alertas sobre fraude online

24 de junio de 2010 Por

Como todos ustedes saben, día a día se suceden las alertas sobre fraude en la red, comúnmente conocido por su término inglés phishing. Para evitar que los atacantes tengan éxito es crucial, además del sentido común al navegar por la red de redes, la rápida detección de las páginas fraudulentas, para que estas puedan ser reportadas a las autoridades competentes y bloqueadas lo antes posible.

En este sentido la NFCTA (National Cyber-Forensics and Training Alliance), junto con otras organizaciones estadounidenses y empresas dedicadas al comercio electrónico como Accuity, eBay o Pay-Pal, y con el soporte tecnológico de Microsoft, han desarrollado un canal de comunicación llamado Internet Fraud Alert, con el que pretenden mitigar los efectos de las estafas bancarias y robos de identidad.

Pero, ¿en qué consiste Internet Fraud Alert?

Internet Fraud Alert es un nuevo sistema de comunicación directo y centralizado entre todas las entidades u organismos implicados en los casos de fraude en la red, incluyendo a los investigadores que descubren credenciales o números de tarjeta de crédito robadas, las entidades (ya sean bancarias o de otro tipo) con que se pueden usar las credenciales robadas, y otras entidades como proveedores de servicio y gobiernos, entre otros. También cabe destacar que este grupo no es cerrado, y las empresas y entidades interesadas e involucradas en la investigación del fraude online pueden solicitar su adhesión a Internet Fraud Alert rellenando el formulario existente en su web.

Con este canal se pretende reducir el tiempo necesario para encontrar el origen de la estafa e intentar reducir dentro de lo posible los usuarios afectados y las pérdidas económicas que puedan ocasionar. Según el Anti-Phishing Working Group, en 2009 se reportaron más de 410.000 alertas por phishing, y el número de entidades explotado por los atacantes crece de forma continuada.

Como no podría ser de otra manera, desde Security Art Work apoyamos este tipo de iniciativas que contribuyen a lograr un Internet más seguro y a mejorar la imagen de la Red como medio para realizar compras y transacciones bancarias, dos elementos que todavía generan desconfianza entre el grueso de la población.

Vía: Genbeta
Nota de prensa original: Microsoft

Nueva encuesta: En estos tiempos de crisis, ¿Cuánto inviertes en seguridad?

23 de junio de 2010 Por

Los resultados de la encuesta ¿Que consideras más adecuado para tu/una organización, la certificación en ISO 27001 o en ISO 20000? que hemos tenido hasta hoy mismo han sido bastante dispares, ya que ninguna de las opciones destaca claramente por encima de las demás. Parece ganar por “una cabeza” la certificación ISO 27001 (31% de los votos), continuando con un empate técnico entre la certificación ISO 20000 y la opción de no certificar pero implantar antes una gestión en base a ITIL que un SGSI (20% de los votos cada una). En cuarto lugar se sitúa la opción de no certificar, pero implantar primero un SGSI y luego una gestión en base a ITIL (15% de los votos). Por último, un 14% de los votos no se deciden por ninguna de las anteriores opciones.

Sin olvidar el limitado número de votos (aunque, todo sea dicho, es mayor que la población en las que las grandes corporaciones de productos cosméticos fundamentan la mayoría de los resultados de las cremas que anuncian en televisión), los resultados parecen indicar que un SGSI se percibe como potencialmente más certificable, o directamente más relacionado con un “sello” ISO 27001, mientras que la gestión en base a ITIL se mantiene más “independiente” de la certificación, quizá por la menor difusión y conocimiento que hay de ISO 20000 frente a ISO 27001. Aunque esto está cambiando poco a poco, concuerda con la experiencia de S2 Grupo, en la que (en términos generales) el cliente nos plantea en primer lugar la implantación y certificación de su organización en base a la norma ISO 27001, para entrar a valorar posteriormente la gestión en base a ITIL, con o sin certificación.

Dicho esto, les dejo con una nueva encuesta, propuesta por Toni Villalón. Esperamos sus respuestas.

[poll id=”20″]

Conferencias sobre ingeniería de software avanzada

22 de junio de 2010 Por

logoFastFixRecientemente, S2 Grupo, ha conseguido un proyecto del 7º Programa Marco, sección TIC, de la Comisión Europea. La primera reunión de trabajo del consorcio va a tener lugar esta misma semana en Valencia.

El viernes, día 25 de junio, se va a celebrar una sesión abierta del proyecto, en el que se impartirán tres conferencias sobre tres temas muy interesantes en el ámbito de la ingeniería de software:

“Intention-Based Integration of Software Engineering Tools”
Prof. Walid Maalej, Technische Universität München

INTI, a novel, intention-based integration approach. An intention is a mental state that underpins the user’s actions during the work. Intentions “sessionize”the work and facilitate the management and switching of context. Intentions also group and describe related changes that are made in different tools. We introduce a reference framework for the realization of such intention-based integration. The framework automatically links related pieces of information by observing the user’s interactions with the tools. It handles the heterogeneity of the tools and information by using Semantic Web technologies

[Read more…]

Evasión en IDS (I)

21 de junio de 2010 Por

Empezando con esta, y durante una serie de entradas, vamos a tratar una de las herramientas de seguridad más empleadas: la detección de intrusos a nivel de red (IDS en adelante), y cómo posibles atacantes pueden intentar eludir dicha herramienta. Como ya probablemente sepan, y como hemos visto en anteriores entradas, los IDS consisten en simples sniffers que leen todo el tráfico que circula por una red, lo tratan y lo analizan sobre un conjunto de reglas buscando posibles patrones de ataques en el tráfico escuchado.

Seguro que muchos de ustedes estarán pensando que existen también los IDS a nivel de red que actúan por comportamientos anómalos del tráfico de red. Es cierto, existen como tal pero dichos IDS sólo suelen ser eficaces para puertas traseras, gusanos de rápida propagación (fast spreading worms) y ataques de denegación de servicio; para el resto de ataques no suelen dar un buen resultado. Es por ello que las siguientes entradas se centrarán únicamente sobre la evasión en IDS a nivel de red que empleen un motor de reglas para la detección de posibles ataques.

Antes de explicar las distintas formas de poder evadir un IDS, hagamos una breve introducción al funcionamiento básico de un IDS, ya que aunque no todos los IDS funcionan exactamente igual pero siguen el siguiente patrón:

1. Un sniffer lee todo el tráfico mediante una interfaz en modo promiscuo conectada a una interfaz espejo de un switch, un router, un hub, etc. En el caso de dispositivos empotrados, directamente se emplea la propia interfaz espejo.

2. Unos preprocesadores tratan los datos leídos por el sniffer, con el objeto de que sean procesados de una forma más rápida por el motor de reglas. Tienen además otras funciones, entre ellas intentar evitar que un atacante pueda eludir el motor de reglas, aspecto que se verá más adelante.

3. Un motor de reglas y un conjunto de reglas. A partir de los paquetes tratados por los preprocesadores, el motor de reglas pasa el paquete tratado por cada una de las reglas, buscando un patrón de ataque que coincida con una de éstas. Si encuentra que alguna coincide, realiza la operación indicada por la regla, normalmente considerar que se trata de un ataque (accept) o rechazar el paquete (drop, pass, reject…). En caso de tratarse de un ataque se notifica a los postprocesadores.

4. Los postprocesadores son los encargados de tratar el ataque, ya sea notificando del ataque vía correo electrónico, almacenando el ataque en texto plano o en una base de datos, bloqueando el ataque (por lo que el IDS pasaría a ser un sistema de prevención de intrusos IPS), etc.

Una vez se ha explicado el funcionamiento sencillo de un IDS a nivel de red, vamos a explicar de forma breve los posibles vectores de ataque que permiten evadir estos sistemas. Principalmente existen cuatro vectores de ataque y un quinto, que pese a no ser un vector de ataque hay que tenerlo presenta ya que se trata de una limitación de los IDS:

1. Evasión mediante paquetes fragmentados en los preprocesadores. Existen dos posibles evasiones en este vector de ataque.

2. Codificación empleada en el ataque. No todos los IDS soportan el mismo tipo de codificación, que si soporta el servicio atacado.

3. Gusanos polimórficos y metamórficos (polymorphic and metamorphic worms).

4. Tratamiento de los datos de entrada (parseo) incorrecto por parte de los preprocesadores, que pueden dar lugar a denegación del servicio y por tanto la anulación del IDS.

5. Cifrado de las comunicaciones. Pese a que no se trata de un vector de ataque, hay que tenerlo en cuenta. Como resulta natural, si una comunicación entre un atacante y un servidor victima va cifrada, el IDS no puede reconocer ningún patrón de ataque. De hecho, el motivo por el cual las comunicaciones van cifradas es para que ningún elemento intermediario pueda entender los datos entre ambos.

Sí es cierto que algunos IDS lo que emplean es un certificado intermedio: el atacante al conectarse con el servidor mediante protocolo seguro, realmente lo que hace es conectarse al certificado del IDS, y el IDS a su vez, conectarse con el servicio solicitado por el atacante, es decir, un man in the middle (MITM). Por lo que el IDS es capaz de analizar el tráfico. Pero, ¿qué ocurre si es justamente el IDS el servidor atacado? Pues que el atacante podría leer el tráfico cifrado. Teniendo en cuenta que para ello el IDS tendría que tener una conexión con la red analizada, algo que no es aconsejable.

En las próximas entradas explicaré con ejemplos reales el funcionamiento de estos vectores de ataque y como algunos sistemas actuales son vulnerables a dichos ataques. Manténganse a la escucha.

Éramos pocos y llegó el “Kindle DX”

18 de junio de 2010 Por

No malinterpreten el título de este post. A diferencia de algunos “elementos” del mercado no estoy, ni mucho menos, en contra de los libros electrónicos y menos del dispositivo de Amazon. Todo lo contrario, fui de los primeros en adquirir uno. Invertir en un libro electrónico es invertir en salud y si no lo creen ustedes no duden en preguntarle a mi espalda. Tengo muchas ganas de que mis hijas puedan ir al colegio con una mochila en la que lo más pesado sea su bocadillo o su zumo, aunque creo que tendré que esperar a que estén en la Universidad a juzgar por la reacción que las editoriales españolas están teniendo en esta materia. En mi modesta opinión es una vergüenza, pero es lo que tenemos.

Mostrada mi postura claramente a favor de semejante utensilio del siglo XXI he de hacer una puntualización a mi apoyo. Un apoyo, por tanto, condicional, con alguna fisura fruto de la falta de previsión de los fabricantes o de los ingenieros que lo diseñaron y que se está resolviendo con las últimas versiones del software que se están publicando (versión 2.5.2).
No sé si ustedes se han parado a pensar en el impacto que sobre la sociedad van a tener, o están teniendo ya, los libros electrónicos. Creo que va a ser una revolución a corto plazo equivalente a la de la fotografía digital. El impacto en todos los ámbitos de la sociedad ya se está empezando a notar. Hasta hace no mucho los libros electrónicos eran unas maquinitas con una utilidad incuestionable para los devoradores de novelas, libros de bolsillo, ensayos y demás piezas literarias.

Los que queríamos el libro electrónico como dispositivo simultáneamente de ocio y negocio le encontrábamos algunas pegas, sobre todo por lo relacionado con el tamaño y la calidad de visualización de documentos en tamaño A4, fundamentalmente documentos en formato pdf. Pero los libros electrónicos de 10 pulgadas ya han irrumpido en nuestras vidas y con ellos llegó un nuevo capítulo de preocupación para los que nos dedicamos a la seguridad.

¿Por qué a los señores de Amazon no se les ocurrió inicialmente dotar de algún mecanismo mínimo de seguridad al Kindle DX? Si de verdad se postula este dispositivo para llevar una versión digital del Quijote o el último documento de auditoría de seguridad entregado por nuestro equipo externo de consultores ¿no creen ustedes que debería haberse pensado desde el principio en algún mecanismo de seguridad que garantizase la confidencialidad de la información contenida en el mismo? ¿Qué pasa si al director de RRHH de una gran empresa le roban su Kindle con una versión de la aplicación inferior a la 2.5.2 donde, con el fin de aprovechar los ratos muertos del aeropuerto, había guardado el borrador del ERE que se está diseñando o la lista de los empleados que van a ser despedidos durante este ejercicio? Amazon lo ha intentado resolver hace poco tiempo con su nueva versión de la aplicación pero, ¿qué está ocurriendo con el resto de libros electrónicos?

Pero aquí no termina la historia. Como ustedes supongo sabrán Kindle hace uso de una maravillosa red global, Whispernet, mediante la cual estos dispositivos están permanentemente conectados. Esto tiene en si mismo utilidades incuestionables de las cuales hago uso con cierta frecuencia, como por ejemplo “comprar” libros en el portal de Amazon con un solo click y con una seguridad cuestionable, pero también nos permite recibir en nuestro dispositivo correos electrónicos a través de una cuenta gratuita que se nos proporciona con la compra del dispositivo. La seguridad que nos propone Amazon para que los correos sean lícitos es la de dar de alta listas blancas de remitentes de correo. ¿Creen ustedes que es esto suficiente? La respuesta es evidente: NO y si no miren ustedes la figura adjunta que muestra una utilidad mediante la cual enviar correos haciendo uso de una cuenta falsa. Además, la estructura de la cuenta de los clientes es una estructura estándar y por tanto fácilmente deducible en un gran número de casos. El envío de correos electrónicos a esa cuenta tiene muchísima utilidad y un pequeño coste asociado. El problema radica en la falta de seguridad de este mecanismo. A priori cualquiera, con ciertos conocimientos perfectamente alcanzables, te puede enviar un documento que como por arte de magia aparece en tu kindle. Esto quiere decir que en “mi” dispositivo puede aparecer un documento “incómodo” sin haberlo cargado yo y sin tener posibilidad de saber quién lo ha introducido en el sistema. ¡¡Vaya!! Esto puede tener algunas utilidades curiosas más allá incluso del coste asociado que lleva, simplemente hace falta dejar volar un poco la imaginación, ¿no creen?

Al margen de este “pequeño” detalle otra cuestión a tener muy en cuenta por la propia existencia de esa “conexión global” es la seguridad de la conexión inalámbrica en si misma o la capacidad que tiene el propio Amazon de acceder a todos los dispositivos del mundo y, por ejemplo, eliminar un determinado documento o actualizar el firmware en remoto como ya ha ocurrido.

En fin, creo que a pesar de que el Kindle DX es un magnífico instrumento lleno de posibilidades, también creo que en las versiones actuales del dispositivo debemos de llevar bastante cuidado con el uso que del mismo hacemos sobre todo cuando de trabajo se trata. Mientras tanto suplicaremos para que los ingenieros que desarrollan aplicaciones o productos en la era digital se acostumbren, de una vez por todas, a hacer desde el principio un catálogo de “CASOS DE ABUSO” en paralelo al maravilloso catálogo de “CASOS DE USO” que seguro ya hacen. ¿Por qué no se dedican a pensar brevemente en cómo se pueden “mal usar” los dispositivos que diseñan? O mejor aún ¿Por qué no contratan empresas especializadas (dicho sea de paso, como S2 Grupo :), repletas de profesionales que dedican su inteligencia y su tiempo a pensar precisamente en esto?
Disfruten señores de sus libros electrónicos pero, por favor, con “sentido común”

SELinux II: Práctica

16 de junio de 2010 Por

Bueno, lo prometido es deuda, y aunque debería de pagar intereses por el tiempo transcurrido, vamos a pasar de la teoría de SElinux a la práctica.

Lo primero antes de trabajar con SElinux, es asegurarse de que lo tenemos habilitado, de que esta configurado en el modo adecuado y de la política de que tenemos. Para todo ello, en un sistema Red Hat, inspeccionamos el fichero /etc/sysconfig/selinux

jvela@centos:~$ less /etc/sysconfig/selinux
SELINUX=enforcing 
SELINUXTYPE=targeted

[Read more…]

Habilitaciones, titulaciones… y todo lo demás

14 de junio de 2010 Por

Leía esta mañana en BELT una noticia que hacía referencia a la falta de habilitación profesional del Director de Seguridad del Barça: esto es, no tiene un TIP en vigor que lo habilite como Director de Seguridad por el Ministerio del Interior. En España, las figuras contempladas en el ámbito de la seguridad privada vienen definidas en la Ley 23/1992, de 30 de julio, de Seguridad Privada (LSP), y entre ellas encontramos al Director de Seguridad, al Jefe de Seguridad, al Escolta Privado o al Guarda Particular del Campo, por citar unas cuantas… todo lo que se salga de ahí, no está reconocido a día de hoy en España. Caso aparte es cómo las empresas de seguridad, sobre todo las que trabajan -o trabajamos- principalmente en seguridad de la información, denominen a su personal: CISO, CSO, CRO… son denominaciones que se utilizan con mayor o menor fortuna en cada caso, pero que desde luego no están oficialmente contempladas (ojo, hasta donde yo sé, y que alguien me corrija si me equivoco). Debate aparte es si es lícito, o ético, que una empresa utilice para su personal cargos que se corresponden con titulaciones oficiales si dicho personal carece de éstas, argumentando siempre que se trata de responsabilidades internas en la organización, no de atribuciones reconocidas oficialmente.

Más allá del hecho de que el Director de Seguridad del Barça tenga o no la habilitación correspondiente, esta noticia viene a plantearnos algunas cuestiones. La primera es relativa a la (necesaria, IMHO) regularización del personal de seguridad; como hemos dicho, todo lo que se salga de la LSP en España no está reconocido, y no debemos olvidar que el negocio de la seguridad de la información al que se dedican -o nos dedicamos- muchas empresas no deja de ser Seguridad Privada… pero sin legislar. Para ser Vigilante de Seguridad o Escolta Privado debes poseer una habilitación, pero para ser técnico de, consultor de o responsable de, no necesitamos nada… Volvemos a insistir en cosas ya comentadas en este mismo blog: ¿no sería necesario que se ampliaran las figuras del personal de seguridad reconocidas en la Ley de Seguridad Privada? Esta ley no se ha movido significativamente desde hace dieciocho años -una eternidad si hablamos de seguridad-, por lo que muchos creemos que ya va siendo hora de que se revise la ley y podamos empezar a hablar de otras figuras, como comentaba en mi post sobre la Ley Ómnibus. Así, todos tendríamos claro cuáles son las figuras oficialmente reconocidas con nuestra perspectiva actual de seguridad (convergencia, PIC, etc.), y quién está capacitado para dirigir un departamento de seguridad, para pertenecer a él o simplemente para desarrollar ciertos trabajos dentro del ámbito de la seguridad privada… más allá de la vertiente “clásica”.

Otra cuestión es qué pasa actualmente con estos puestos de seguridad privada “no oficial”… se trata de roles tan habituales que nadie se plantea sus implicaciones, pero lo cierto es que únicamente están reconocidos dentro de una organización, no más alla; un Director de Seguridad o un Ingeniero en Informática es eso mismo aquí y en la China Popular (como diría alguien), mientras que un “Ingeniero de Seguridad Perimetral” o un “Responsable de Riesgos” no tienen sentido fuera de la organización que les ha asignado esa categoría. Volvemos al tema de las atribuciones profesionales, al quién puede hacer qué; “Director de Seguridad” es una habilitación propia del Ministerio del Interior, mientras que “Director de Seguridad de la Información” -el famoso CISO-, o “Consultor de Seguridad” no es ninguna titulación oficial, con lo que cualquiera puede adjudicarse este papel en su tarjeta de visita… De nuevo lo de siempre: ¿quién puede firmar una auditoría? ¿quién puede dirigir un departamento de seguridad que trabaje en protección de la información? Ahora mismo no existe regulación alguna más alla de la LSP (que por supuesto no toca seguridad de la información como tal), por lo que cada organización hace de su capa un sayo; yo puedo decir que tal persona es Técnico de Seguridad, Consultor de Seguridad o Ingeniero Jefe de Seguridad… ¿y? Sólo dependerá del buen criterio -o del mal criterio- de cada empresa el titulito que se asigne a su personal de seguridad…

Creo que una regulación del personal de seguridad sería muy conveniente tanto para nuestra profesión como para nuestros clientes, que por fin podrían saber quién les puede realizar determinados proyectos o prestar ciertos servicios, y en base a qué; y por supuesto, si llegamos al punto en que el personal de seguridad se regula correctamente más allá de la seguridad tradicional, no olvidemos que dicho personal tendrá una serie de obligaciones y responsabilidades -no como sucede ahora en seguridad de la información-; en el momento en el que alguien puede retirarme mi habilitación como Director de Seguridad si hago mal mi trabajo, impidiéndome desempeñar ese puesto en un futuro, me pensaré dos veces el entregar un informe o el resultado de un análisis de riesgos, por poner un ejemplo.

Para acabar, un último apunte: no empecemos ahora con que si para dirigir, auditar o implantar hace falta un CISSP, un SANS, un CISA, un CISO o un CASI, que me entra la risa… estas -y otras- certificaciones son títulos de una “academia” concreta (ISACA, ISC2, SANS…), y por muy reconocidos que estén o dejen de estar, hasta donde yo sé no son oficiales, al menos de momento; otra cosa es si demuestran o no conocimiento, o simplemente demuestran tiempo y dinero… pero para empezar a discutir quién puede hacer qué en seguridad, prefiero hacerlo por titulaciones oficiales o por habilitaciones propias del Ministerio del Interior, nos gusten más o menos…

Ataques contra usuarios de Twitter

11 de junio de 2010 Por

Kaspersky Lab ha alertado a los usuarios de Twitter sobre una herramienta que están usando los criminales cibernéticos para crear botnets que se controlan a través de Twitter. Según ciertas publicaciones (TechnologyReview, FaqMac y otros), miles de cuentas de Twitter hackeadas a la venta en foros forman un nuevo mercado negro dentro de la ciberdelincuencia. Las cuentas se ofrecen por lotes a menos de 200 dólares, dependiendo del número de seguidores que tengan.

El principal objetivo de los compradores, en la mayoría de casos, es vender falsos antivirus (Rogueware) a través de los tweets enviados por estas cuentas; el hecho de hacer clic en en enlace de un tweet hackeado infecta al equipo del usuario con la publicidad de un producto de antivirus falso. La infección provoca una notificación emergente que anuncia que el equipo está infectado y ofrece una versión completa del falso antivirus por unos 50 dólares (o más) que te asegura que desinfectará el equipo en cuestión, y se estima que 1 de cada 100 personas probablemente paguen esa cantidad. Con que sólo un tweet hackeado tenga éxito, podría tener graves repercusiones si procede de un usuario de confianza (generalmente, entre el 10-20% de los usuarios hacen clic sobre un enlace enviado por una fuente de confianza). Twitter tiene más de 75 millones de usuarios, de los cuales entre unos 10-15 millones envían tweets regularmente. Si por ejemplo simplemente sólo un 1% de esos 75 millones de miembros se infectara, y que de ese 1% de usuarios infectados, un 1% creyera en el falso antivirus y pagara por su adquisición, supondría un fraude de unos 7500 dólares. Este tipo de botnets también se usa para distribuir spam o realizar ataques de denegación de servicio, entre otras cosas.

“La técnica de robar credenciales de cuentas y la publicación de enlaces maliciosos en Twitter es cada vez mas popular. (…) Los criminales cibernéticos están dándose cuenta de que se puede abusar de los sitios de redes sociales de manera muy eficiente y acorde con sus necesidades.”, afirma Costin Raiu, director de Kaspersky Lab.

La herramienta en cuestión es TwitterNET Builder, de la cual actualmente existen dos variantes conocidas. La primera, la original, utiliza órdenes maliciosas con nombres estáticos que pueden ejecutar funciones como descargar y ejecutar ficheros, realizar ataques de denegación de servicio, redirigir a otras páginas web o controlar la comunicación entre el equipo infectado y Twitter (http://sunbeltblog.blogspot.com/2010/05/diy-twitter-botnet-creator.html)). El equipo de http://sunbeltblog.blogspot.com notificó en su momento a Twitter, y curiosamente comentan en su blog que Twitter tardó sólo 13 minutos en contestarles (impresionante). La segunda, descubierta por Kaspersky Lab, es una ligera variación de la primera variante que permite al atacante especificar los nombres del comando, lo que hace más difícil identificar qué cuentas de Twitter se están utilizando para controlar las botnets.

“Este código malicioso no incluye ningún mecanismo de distribución y debe instalarse de forma manual en el ordenador del usuario víctima, pero puede ejecutarse cuando se combina con un ataque drive-by o con un gusano que se distribuye a través de una nueva vulnerabilidad”, afirma David Jacoby de Kaspersky Lab. Las cuentas se comprometen usando dos métodos: troyanos que roban las credenciales de Twitter directamente del usuario y estafas de phising que utilizan falsas peticiones de autorizaciones en sitios fraudulentos que imitan la página original. Una vez los atacantes tienen acceso a una cuenta, pueden comenzar un mailing malicioso, que aparentemente envía el legítimo dueño de la cuenta, o simplemente pueden vender la cuenta a otros para propósitos similares.

Para protegernos, dado que esta herramienta no tiene sus mecanismos de distribución propia y necesita ser descargada y ejecutada manualmente (por ejemplo, nos podría llegar como archivo adjunto en un correo electrónico, o como un archivo enviado a través de un cliente de mensajería instantánea), es importante estar atentos a la hora de ejecutar este tipo de archivos. También hay que tener cuidado de no infectarse a través de un ataque drive-by, que pueda explotar por ejemplo una vulnerabilidad en el navegador y es aconsejable (sobre todo si eres de los que no te fijas mucho donde haces clic :) que tengamos el antivirus actualizado y tengamos también instalados todos los parches de seguridad de los diferentes proveedores.

Monitorizando usuarios en Solaris

9 de junio de 2010 Por

Como llevo algunas noches de insomnio me ha dado por refrescar, tras algunos años olvidados en un cajón, aspectos de monitorización de usuarios en Solaris (Solaris 10, para ser exactos); y la verdad es que de lo que conocía -dejé de administrar máquinas Solaris “en serio” en su versión 7- a lo que me he encontrado en las nuevas versiones del operativo, hay alguna que otra diferencia que sorprende gratamente, y es que a pesar de que ahora sea un producto de Oracle, Solaris sigue siendo Solaris :)

Como siempre, para generar trazas “en serio” de la actividad de los usuarios podemos utilizar el Basic Security Module, habilitado mediante bsmconv(1M) y que nos dirá hasta qué usuario pestañea demasiado delante de la consola :) ¿Problemas? Alguno que otro… para empezar, requerimos reiniciar el sistema, cosa que ya de por sí a nadie le gusta mucho… y para continuar, tenemos el problema histórico del volumen de datos que generamos: por muy bien que configuremos el módulo de auditoría, incluso si lo hacemos por usuario, la cantidad de registros que se almacenan en la máquina no deja de ser considerable… y lo peor de todo: la marcha atrás tras habilitar BSM en nuestro sistema implica de nuevo detener servicios (la orden bsmunconv hay que lanzarla en runlevel 1).

Aunque BSM es la solución correcta y definitiva si necesitamos un registro de auditoría al detalle, me ha sorprendido en Solaris 10 DTrace, un framework que permite monitorizar en tiempo real y sin parada de sistema determinados aspectos tanto del núcleo como del espacio de usuario; este framework incorpora un lenguaje de programación propio (“D”), que nos permite registrar, de forma sencilla, actividad en el sistema de cara a detectar problemas, a “tunear”, o simplemente a monitorizar determinada actividad en la máquina (accesos a un fichero, cambios en inodos, etc.). Por supuesto, para esto último no es tan completo como BSM -que insisto, es la solución correcta-, pero nos puede servir para sacarnos de más de un apuro en cuanto a conocer qué hacen nuestros usuarios.

Un ejemplo de monitorización sencilla: ¿qué órdenes ejecuta un determinado usuario? Mediante dtrace(1M), es trivial obtener esta información: ponemos “vigilantes”, generadores de información, en las llamadas al sistema exec() y familia, y la condición de que el UID del usuario que usa estas llamadas – que pasaremos como argumento al programa- sea uno en concreto; si esto se cumple, imprimimos la información que nos interesa:

# cat t.d
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
# dtrace -s prueba.d 100
dtrace: script 'prueba.d' matched 2 probes
CPU ID FUNCTION:NAME
0 108 exece:return exece 2010 Jun 9 18:54:17 ls
0 108 exece:return exece 2010 Jun 9 18:54:28 more prueba.d
#

Seguro que el código se puede mejorar, ya lo sé :) Más cosas que nos pueden interesar de la actividad de un usuario: archivos abiertos, conexiones de red…todo esto es bastante sencillo obtenerlo mediante dtrace(1M), sus probes y las condiciones adecuadas; podemos poner todo junto, y en bonito (para que nos muestre la información más legible, básicamente) en un script que invocaremos desde línea de órdenes:

# cat luser.d
#pragma D option quiet
/*
* Ejecucion de ordenes
*/
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
/*
* Acceso a FS
*/
syscall::open:entry, syscall::creat:entry,
syscall::open64:entry, syscall::creat64:entry,
syscall::unlink:entry, syscall::rename:entry
/ uid==$1 && strstr(stringof(copyinstr(arg0)), "/proc") == NULL /
/* Nos quitamos de la condicion el acceso a procfs */
{
printf("%s %Y %s\n", probefunc, walltimestamp, stringof(copyinstr(arg0)));
}
/*
* Acceso a red / TCP
*/
::tcp_send_data:entry
{
self->lport=((unsigned int) args[0]->tcp_tcph->th_lport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_lport[1];
dig1=(unsigned int) args[0]->tcp_tcph->th_fport[0];
dig2=(unsigned int) args[0]->tcp_tcph->th_fport[1];
dig1=dig1< <8; self->rport=((unsigned int) args[0]->tcp_tcph->th_fport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_fport[1];
srcaddr=(unsigned int) (args[0]->tcp_ipha->ipha_src);
dstaddr=(unsigned int) (args[0]->tcp_ipha->ipha_dst);
self->octect[0]=srcaddr>>3*8 & 0xFF;
self->octect[1]=srcaddr>>2*8 & 0xFF;
self->octect[2]=srcaddr>>1*8 & 0xFF;
self->octect[3]=srcaddr>>0*8 & 0xFF;
self->octect[4]=dstaddr>>3*8 & 0xFF;
self->octect[5]=dstaddr>>2*8 & 0xFF;
self->octect[6]=dstaddr>>1*8 & 0xFF;
self->octect[7]=dstaddr>>0*8 & 0xFF;
self->ok=1;
}
::tcp_send_data:entry
/ self->ok && uid==$1 /
{
printf("%s %Y %d.%d.%d.%d:%d -> %d.%d.%d.%d:%d\n", probefunc,walltimestamp,self->octect[0],self->octect[1],self->octect[2],self->octect[3], self->lport,self->octect[4],self->octect[5],self->octect[6],self->octect[7],self->rport);
self->ok=0;
}
#

Al invocarlo mediante dtrace(1M), la salida que obtendremos será similar a la siguiente -con muchos más datos que habrá que filtrar, no estoy ahora para pulir el código que, insisto, es un simple ejemplo y tendrá N fallos y mejoras-):

tcp_send_data 2010 Jun 9 19:00:37 192.168.1.2:22 -> 192.168.1.5:37963
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37964
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37963
exece 2010 Jun 9 19:00:38 cat /home/toni/fbsd-como\0
open 2010 Jun 9 19:00:38 /var/ld/ld.config
open 2010 Jun 9 19:00:38 /lib/libc.so.1
open 2010 Jun 9 19:00:38 /platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Así, mediante dtrace(1M), y de una forma muy sencilla, estamos en disposición de monitorizar muchísimas acciones -en este caso de un usuario concreto- que pueden servirnos para incrementar considerablemente la seguridad de nuestros sistemas Solaris desde el punto de vista de monitorización de la actividad (aparte de para resolver algún problema en las máquinas). Por supuesto, con un ratito de búsqueda en Google tendremos acceso a un montón de ejemplos de programas en D que podemos adaptar y aprovechar para crear un luser.d en condiciones :)

En definitiva, dtrace(1M) es una herramienta que no conocía más que de oídas y que, a poco que he empezado a tocarla, me ha sorprendido muy gratamente (tanto por su capacidad como por su sencillez) para la monitorización de ciertas actividades concretas del sistema o de nuestros usuarios, sin necesidad de meternos en el “gran” BSM… además, puede ser muy útil en aquellos casos en los que BSM no esté habilitado de antemano, por ejemplo si nos enfrentamos a un análisis forense de una Solaris comprometida… en fin, que seguiremos informando :) Por cierto, ¿alguien se anima a explicarnos algo similar en Linux, Windows, AIX, etc.? Sé que Dtrace se ha migrado -o se está migrando- a BSD, pero no sé si tenemos algo de capacidades similares en otros entornos (es que ya no soy técnico :)

Publicado el borrador del RD de Protección de Infraestructuras Críticas

7 de junio de 2010 Por

Fue allá por el 92 cuando la aparición de la LORTAD, que evolucionó hasta la actual LOPD, marcó un antes y un después en el marco de la seguridad y la protección de datos. Actualmente, están surgiendo otras iniciativas de referencia que claman por convertirse en otro punto de inflexión en materia de seguridad en España.

La primera de ellas la vimos nada más empezar el año con la aparición del Esquema Nacional de Seguridad, el cual se propuso como objetivo el establecer las condiciones y medidas necesarias para garantizar la seguridad de los sistemas, los datos, las comunicaciones, y los servicios electrónicos en la Administración Pública.

Ahora nos encontramos con otro hito, publicándose hace pocas algunas semanas el borrador del RD de Protección de Infraestructuras Críticas. Este nuevo Real Decreto que se aproxima, nace con el propósito de regular la protección de las infraestructuras que presten servicios públicos esenciales para la sociedad frente a ataques deliberados de todo tipo, poniendo especial interés en el campo del terrorismo, mediante la definición y el desarrollo de un sistema y unos procedimientos que abarcan a todos los sectores públicos y privados afectados.

Echándole un vistazo a la norma nos encontramos, como principales pilares para la gestión de la misma, la definición de un catálogo en el que se identifican, para cada sector, aquellas infraestructuras críticas para la sociedad, que como define la norma son aquellas cuyo funcionamiento resulta indispensable y que su destrucción o interrupción supondría un grave impacto sobre los servicios públicos esenciales. Éstas se clasifican, según su ámbito, en Infraestructuras Críticas (IC) o Infraestructuras Críticas Europeas (ICE), si afectan a dos o más estados miembro de la Unión Europea. Así mismo, para determinar la criticidad de estas infraestructuras, se valoran principalmente en base a tres parámetros: el número potencial de víctimas que se pueda producir, el impacto económico y el impacto público.

Otro de los pilares con los que nos encontramos es el diseño de un plan estratégico que contenga medidas de prevención y protección eficaces contra las posibles amenazas hacia tales infraestructuras críticas. Como toda estrategia de seguridad, ésta parte en primer lugar de un análisis de riesgos, en el que se evalúan las amenazas y vulnerabilidades, seguido del análisis de las fortalezas y debilidades frente a los mismos. Dicho análisis permite determinar cuáles son las prioridades y la capacidad para, con ello, coordinar y planificar los esfuerzos necesarios del Gobierno, las Administraciones Públicas y el sector privado para hacerlos frente.

En cuanto a las figuras responsables, surge el Centro Nacional para la Protección de Infraestructuras Críticas (CNPIC), como órgano director y coordinador, y que depende únicamente de la Secretaría de Estado de Seguridad. Así mismo, detalla todas aquellas relaciones y obligaciones de los diferentes actores involucrados.

Como punto destacado, cabe mencionar la especial atención que este Real Decreto presta hacia las tecnologías de la información, reconociendo la fuerte dependencia actual, tanto para su gestión como por su vinculación con otros sistemas. De la misma forma, se aboca por la implantación de las medidas de seguridad necesarias para garantizar la confidencialidad, integridad y disponibilidad de la información en los sistemas y las comunicaciones (véase al respecto el artículo 26, Seguridad en las comunicaciones).

No obstante, tengo que decir que esta norma cae un poco en la ambigüedad en cuanto a medidas técnicas se refiere, dejando dicho criterio al Centro Criptológico Nacional, como órgano encargado de certificar y acreditar la seguridad de los sistemas de información y comunicaciones. Veremos con el paso de los días como queda la versión final de esta norma y también cómo afecta la situación actual de crisis en el desarrollo e implantación de la misma.