Me sigue dando igual

Ya que mi post anterior no hizo despertar tu conciencia de seguridad voy a hacer un último intento. Puede que incluso lo lograra, pero quizá no lo suficiente: ahora te bajas todas las actualizaciones de Microsoft y tienes cuidado con lo que haces por Internet, pero... pero no te das cuenta de que el problema puede estar más cerca de lo que piensas, en tu casa, a dos metros de ti. La moda ahora es irte al sofá y chatear mientras ves la tele, gracias a los maravillosos routers inalámbricos, pero ¿te has parado a pensar en la seguridad de tu router? ¿has cambiado la configuración por defecto? ¿has cambiado la contraseña desde que te lo instalaron? cada vez es menos habitual, pero hace unos años lo normal es que te dejaran el router sin contraseña, sin siquiera avisarte de ello. Ahora no es muy distinto. Seguramente tendrás en tu casa un cifrado WEP, la instalación por defecto, pero no te avisan de que este sistema se puede saltar en cuestión de minutos o incluso segundos, no te avisan de que la opción ideal sería el uso de WPA2, aparte de filtrado de MACs, ocultación del nombre de tu red (aunque no es demasiado útil), cambio del usuario y contraseña de acceso a tu router...Nadie te avisa y tú no te preocupas.

Teniendo la contraseña de cifrado de tu red inalámbrica ya no sólo podrán ver todos los datos que salen de tu ordenador, sino también los de tus familiares. Quizá a ti no te importe, pero ¿y a tu padre? ¿a tu pareja? ¿a tu hijo? creo que ellos sí que usan diariamente la banca electrónica, y realizan transacciones importantes en internet. Claro que ese tráfico importante conlleva un cifrado propio aparte del de tu red, seguramente a través de SSL, ese candadito del navegador que indica que es seguro. Estamos tan acostumbrados a darle al botón "Aceptar" para la aceptación del certificado digital cuando se entra en una página que usa cifrado que no se van a dar cuenta de que se trata de uno falso, y que el tráfico ha sido rederigido a un clon del portal de sus bancos, que después de recolectar todos sus datos de acceso les llevará al portal real. Seguramente harán un agujero en sus cuentas corrientes, y seguramente, de una forma u otra, acabará afectándote también a ti. ¿Cambiarás entonces el sistema de cifrado de tu red inalámbrica? ¿no sería mejor prevenir que curar?

Otra de las bonitas cosas que podrían hacer sería alistarte en el ejército de zombies de una de las llamadas botnets, concepto explicado a la perfección en el documento Botnets – The Silent Threat de David Barroso. A través de la instalación de un programita "muy malo", usando algunas técnicas como las comentadas en la primera parte de este post, ellos tendrán el control total de tu ordenador, sin darte cuenta, por supuesto. Y no sólo podrán estar registrando todas tus contraseñas, sino que además tu ordenador será usado para cometer delitos informáticos como puede ser el envío masivo de SPAM, la denegación de servicio distribuida (DDoS) a ciertos sitios o sistemas informáticos, etc. De esta forma, ellos se cubren las espaldas, porque el que realmente delinque eres tú.

¿No te vale con todo esto? quizá te moleste más que tu ordenador personal se convierta en el almacén de todo tipo de material ilegal, y estés propiciando y ayudando a los que se lucran con negocios tan bajos como puede ser la pornografía infantil o la pederastia.

Como ves, hay miles de cosas que se pueden hacer con tu ordenador, cosas que van bastante más lejos del robo de tus fotos personales. Todo depende de la imaginación y pericia del atacante. Pero tú cuentas, y se lo puedes poner bastante dificil, sólo tienes que tener un poco de conciencia en este tema, y preocuparte por la seguridad de tu sistema. No hace falta ser un gurú para conseguirlo, basta con tener un poco de sentido común y preocupación por este asunto. Al igual que no dejas la puerta de tu casa abierta de par en par, ni la ventana aun viviendo en un sexto piso, tampoco deberías hacerlo en tu ordenador. Así que esta noche, antes de comer las uvas, acordaos de este post y añadid un punto más a la lista de buenos propósitos;) Feliz 2008!!


José Miguel Esparza
S21sec labs

Bruce Schneier

Hace unas semanas se realizó una interesante entrevista en el blog de Freakonomics del New York Times a Bruce Schneier, que como muchos de vosotros sabréis, es un profesional muy respetado en diversos ámbitos que tiene una visión global de la seguridad, y por supuesto, sus propias ideas alrededor de todo lo que tiene que ver con la seguridad: pasado, presente y futuro (hace poco comentamos su visita a España en el ISMS Forum).

Independientemente de reconocer las aportaciones del señor Schneier al escenario de la Seguridad, que son muchas (aunque personalmente no comparto muchas de sus ideas en sus libros donde mezcla negocio+seguridad), durante la entrevista aparecen varios comentarios que merecen la pena reseñar, además de que las ideas que expone en general son muy prácticas y razonables en la mayoría de los casos:

Q: What do you think needs to be done to thwart all of the Internet-based attacks that happen? Why it is that no single company or government agency has yet to come up with a solution?

A: That’s a tall order, and of course the answer to your question is that it can’t be done. Crime has been part of our society since our species invented society, and it’s not going away anytime soon. The real question is, “Why is there so much crime and hacking on the Internet, and why isn’t anyone doing anything about it?”

The answer is in the economics of Internet vulnerabilities and attacks: the organizations that are in the position to mitigate the risks aren’t responsible for the risks. This is an externality, and if you want to fix the problem you need to address it. In this essay (more here), I recommend liabilities; companies need to be liable for the effects of their software flaws. A related problem is that the Internet security market is a lemon’s market (discussed here), but there are strategies for dealing with that, too.

Aunque puede ser una buena idea (y mucho mejor que esta otra, donde Howard Schmidt propone que los responsables sean los programadores de forma individual, ¡quién va a ser programador entonces!), tiene sentido en EEUU, donde los abogados tienen un futuro asegurado, pero dudo que en Europa pueda ser igual. Además, sólo las empresas grandes de software podrían permitirse pagar sus responsabilidades;¿y que pasaría con el software open-source, puesto que también tiene vulnerabilidades? Es una buena idea en la teoría pero muy difícil de llevar a la práctica. La relación entre Seguridad Informática y Economía no es tan fuerte como Schneier comenta:

Computer security isn't a technological problem -- it's an economic problem. Socialists might imagine that companies will improve software security out of the goodness of their hearts, but capitalists know that it needs to be in companies' economic best interest. We'll have fewer vulnerabilities when the entities that have the capability to reduce those vulnerabilities have the economic incentive to do so. And this is why solutions like liability and regulation work.

Personalmente, considero más acertado el otro sentido, premiar a las empresas que no tienen vulnerabilidades en su software, antes que castigar a las que lo tienen.

Q: How worried are you about terrorists or other criminals hacking into the computer systems of dams, power plants, air traffic control towers, etc.?

A: Not very. Of course there is a security risk here, but I think it’s overblown. And I definitely think the risk of cyberterrorism is overblown (for more on this, see here, as well as this essay on cyberwar).

Quizás pueda estar magnificado por los medios de comunicación, pero el riesgo es real, sobre todo después de la incursión de bandas criminales y terroristas en Internet. Más aún, en EEUU es posible que esté todavía más magnificado (han hablado mucho siempre de un "electronic Pearl Harbour"), pero precisamente puede que sea uno de los primeros objetivos de la lista de naciones amenazadas. Schneier divide el riesgo en:

• Cyberwar: el incidente de Estonia, China, etc.
• Cyberterrorism: cualquier ataque de grupos terrorista a infraestucturas mediante el uso de redes de comunicaciones
• Cybercrime: fraude, DDoS, lo que más se puede apreciar
• Cybervandalism: web defacement, también bastante visible

En el ensayo anterior, además comenta un dato interesante: la cyberwar es una batalla de igualdad, puesto que los dos bandos utilizan el mismo hardware y el mismo software, aunque realmente luego existen ciertas ventajas, puesto que siempre pueden existir vulnerabilidades no públicas en el software utilizado.

Q: Is there any benefit to password protecting your home Wifi network? I have IT friends that say the only real benefit is that multiple users can slow down the connection, but they state that there is no security reason. Is this correct?

A: I run an open wireless network at home. There’s no password, and there’s no encryption. Honestly, I think it’s just polite. Why should I care if someone on the block steals wireless access from me? When my wireless router broke last month, I used a neighbor’s access until I replaced it.

Aunque parece una respuesta inocente y que en un mundo ideal sería perfecta, realmente hay muchos casos demostrados de uso de redes wireless personales para la realización de delitos en Internet. Además, si te interesa mantener tu privacidad y evitar usurpaciones de identidad, es deseable que no compartas tu conexión wireless con gente de poca confianza.

Realmente merece la pena leer la entrevista, puesto que expresa con claridad y sin tapujos muchas de las cuestiones que siempre están rodeadas de una cierta nebulosa, aunque la visión del señor Scheier está fuertemente influenciada por cómo transcurren las cosas en EEUU (por otra parte, totalmente razonable), y muchas veces la realidad no se corresponde al 100% con la visión que se tiene de los hechos.

David Barroso

S21sec labs

Inocentada

Solamente comentar que el post anterior se trataba de una inocentada.

Mientras que la primera parte del post es cierta, no se conoce que se haya obtenido una "técnica nueva y mucho más sencilla" que permita "construir un ordenador cuántico con un numero arbitrario de q-bits".
Además, habréis podido comprobar que el documento enlazado trata sobre computación cuántica, pero no comenta nada de esto, y este documento no tiene un "apartado 5". Para terminar, la firmante tampoco puede ser la autora del post.

S21sec labs

RSA realmente en peligro

En un post anterior, hablábamos de los peligros a los que se enfrenta RSA. Si hace no muchos meses una empresa canadiense presentaba un ordenador cuántico capaz de hacer ciertas operaciones sencillas. Este ordenador tiene 16 q-bits, insuficientes para romper el cifrado, teniendo en cuenta el tamaño de las claves que se utilizan hoy en día. Aunque prometen un prototipo con 1024 q-bits, las dificultades para conseguirlo son obvias.

Por otro lado, investigadores japoneses aseguran haber desarrollado un prototipo de ordenador cuántico de 32 bits, utilizando una técnica nueva y mucho más sencilla que las conocidas hasta ahora. Han publicado los primeros resultados y utilizado el prototipo para factorizar números primos. Como explican en el apartado 5 de esta publicación, la tecnica que han utilizado puede utilizarse sin cambios importantes para construir un ordenador cuántico con un numero arbitrario de q-bits.
Al parecer, la técnica para romper la seguridad de RSA ya existe. Solo hace falta que alguien pague lo necesario.

Emilia Brenda

Diseño del Reto 3 - Segunda pista.

Ya tenemos una solución en nuestro poder, y otra a punto de caer, por lo que damos la pista que teníamos prevista y la semana que viene publicamos las soluciones.

El crackme del tercer reto es una prueba de concepto de un pequeño estudio sobre como crear una protección en la que se prenteden utilizar uno de los puntos débiles del atacante, a la vez que una de las mayores ventajas del programador:

- El punto débil es el atacante en si, que es un ser humano y tiene una capacidad limitada de análisis de complejidad.
- La ventaja del programador es la posibilidad de crear la protección a su antojo, hacer software "inteligente", utilizar estudios previos, etc.

Se buscaba un sistema de protección que una vez lanzada la ejecución evolucione hacia un final correcto si y solo si se cumplía la premisa inicial, que en este caso era el keyfile correcto. Tras valorar otras alternativas como un algoritmo genético, se utilizaron Redes de Petri

Una red de Petri se puede ver como una red de distribución de fichas entre lugares interconectados por transiciones. Para disparar una transición, cada lugar que le apunta deberá tener una ficha y, al dispararse la transición, perderá la ficha, a la vez que se lanzará una ficha a cada lugar apuntado por la transición lanzada.

La siguiente imagen ilustra una transición de una red sencilla (se muestra en rojo la transición que se va a disparar)

También podemos dibujar el árbol de alcanzabilidad del dicha red:

Por supuesto, se pueden diseñar redes de Petri más complejas, como la que se muestra a continuación, y que ha sido utilizada en el crackme:

Junto con su árbol de alcanzabilidad:

En cada ejecución el programa puede tomar un camino diferente del árbol, pero siempre llegará a la misma solución.

La red debe estar diseñada de tal manera que si se cambia alguna ficha, no se alcance la solución correcta. Por ejemplo, si añadimos una ficha en P2, el nuevo árbol de alcanzabilidad demuestra que no se llega a la solución, por lo que el avance de la red quedara atascado y saltará el timer diciendo que la solución no es correcta.

En resumen, se aborda de manera un poco más sofisticada el arte de tocar las narices.

Referencias:

Una herramienta muy intuitiva para trabajar con redes de Petri:
http://pipe2.sourceforge.net/
Un escrito sobre el tema (requiere registro): http://www.codebreakers-journal.com/content/view/47/27/

Mikel Gastesi
S21sec labs

Emerging Threats

Hace un mes aproximadamente, Matt Jonkman, de Bleeding Threats cerraba su página despues de estar durante más de cinco años manteniendo un conjunto de reglas "alternativo" para el IDS Snort (Bleeding Snort). Estas reglas se caracterizaban principalmente por estar más actualizadas y era cuestión de horas el disponer de, por ejemplo, la detección de un exploit remoto que acababa de publicarse.

También eran muy interesantes las reglas que tenía relacionadas con el malware, principalmente de conexión de los ordenadores infectados con su C&C ("calling home!"), que permitian a los administradores detectar algunos ordenadores infectados en sus redes.

Pero como la conocida marca de turrones, todo lo bueno vuelve por Navidad. Matt acaba de confirmar que su proyecto sigue en pie, con un nuevo nombre, Emerging Threats. Así que podemos seguir contando con reglas tan interesantes como el tráfico de la ya extinta Russian Business Network, o conexiones a C&C conocidos.

¡Felices Fiestas!

David Barroso

S21sec labs

Felices Navidades...¡seguras!

Sin lugar a dudas la Navidad es el momento del año en que se disparan las compras, se envían más paquetes y cartas y se producen más comunicaciones personales. Este fenómeno hace años que ya se traslado a Intenet, siendo también este periodo del año en el que más mails de carácter personal se envían, y más compras y transferencias on-line.

La asociación habitual de Navidad con las buenas intenciones de la gente no debe sin embargo hacernos bajar la guardia. En este periodo del año los ciberdelincuentes (que no suelen entender de Navidades y/o buenas intenciones) aprovechan todo este trasiego y envío masivo de E-Christmas y demás mails para sacar provecho del incremento del tráfico y comunicaciones.

Así, es común por estas fechas la aparición de troyanos y demás malware que aprovecha el envío de felicitaciones navideñas con adjuntos tipo MerryX.A o emails falsos que nos invitan a seguir un enlace a un sitio fraudulento en el que posteriormente captar nuestros datos con fines ilícitos, como se detalla en este post del blog Infospyware o en este otro de Hoax-Slayer.

Por último, estas Navidades ha de extremarse la precaución respecto de años pasados ya que el incremento global de malware en 2007 ha sido espectacular. El siguiente estudio de la empresa de seguridad informática Finlandesa F-secure ha hecho un cálculo en el que estima que sólo en 2007 se ha generado tanto malware como en los anteriores 20 años. Basta echar un vistazo al gráfico suyo adjunto.

Así que cuidadito, seguir con las recomendaciones habituales de no confiar en remitentes no seguros, ni navegar por páginas de contenido dudoso, y por si acaso no fiarse mucho ni de Santa ni de los pajes de los reyes, como mucho del Olentzero, que no parece muy puesto en las nuevas tecnologías (no tiene cobertura ADSL en su bosque).

En cualquier caso, desde S21sec labs, desearos unas felices fiestas a todos, y gracias por vuestras lecturas y apoyo al blog.

Jon Asín

S21sec labs

Ya está aquí el nuevo Reglamento de Protección de Datos

Después de esperar durante más de 2 años, finalmente el Consejo de Ministros del pasado viernes, 21 de diciembre, ha aprobado el nuevo reglamento.

Según la misma Presidencia del Gobierno, los aspectos más relevantes son:

El aumento de la seguridad jurídica al aclarar aspectos dudosos y lagunas interpretativas.

• La aplicación a los ficheros y tratamientos no automatizados (papel).
• Garantías en la información previa al tratamiento.
• Simplificación del ejercicio de los derechos ARCO.
• Cambios de nivel de varios tipos de datos (en especial, los de violencia de género que pasan a nivel alto). También tendrá un efecto importante la consideración de nivel medio de los datos de tráficos gestionados por los operadores de servicios de comunicaciones electrónicas.

Muy importante también, es el régimen transitorio. Básicamente, se establece un plazo de 1 año de adaptación, 18 meses y 2 años para los ficheros en papel de niveles básico, medio y alto, respectivamente. Y, por otra parte, también 1 año y 18 meses para los cambios de nivel, para aquellos datos que pasan a nivel medio y alto.

Lógicamente, la Agencia Española de Protección de Datos valora "positivamente" en una nota de prensa el nuevo reglamento y el incremento de seguridad jurídica que aporta.

Antonio Ramos
Director de Consultoría

Operación Bot Roast

La policía de Nueva Zelanda, en colaboración con el F.B.I., ha llevado a cabo hace pocos días la segunda fase de la operación Bot Roast, en la que se ha conseguido detener a uno de los líderes del uso de botnets, a quien se acusa de contar con el control de cerca de un millón de ordenadores.

La operación Bot Roast comenzó de manera oficial el pasado junio en Estados Unidos con la detención de tres personas, en Seattle y Arlington, acusadas en alguno de los casos de infectar los ordenadores de varios hospitales de Chicago, además de infectar miles de ordenadores en todo el mundo que usaban para generar ataques DDoS, además de mandar millones de correos spam a través de estos ordenadores o de robar identidades y blanqueo de dinero en otros.

La segunda fase de la operación ha llevado a los investigadores hasta Nueva Zelanda. La policía del país, junto con el servicio secreto de los Estados Unidos y el F.B.I. ha descubierto la trama dirigida por uno de los cabecillas detenidos, que en la red se hace llamar Akill.

Akill es un chico de 18 años que habría infectado, según estimaciones, cerca del millón de ordenadores en todo el mundo, con intención de usarlos como arma para actividades ilegales, principalmente ataques DDoS, y haber obtenido unos beneficios ilegales de cerca de 25 millones de dolares. En total han sido detenidas 8 personas desde junio en dicha operación, todos relacionados con el uso de botnets. Las investigaciones continúan abiertas.

Las autoridades estadounidenses han advertido a los usuarios que protejan sus ordenadores, aunque la eterna pregunta es si son los usuarios los responsables de proteger sus ordenadores, o es tarea de los vendedores de software el hacer sus programas y sistemas operativos más robustos para evitar este tipo de problemas. La gran mayoría de estos usuarios ni siquiera saben que su ordenador está siendo usado para realizar actividades maliciosas.

Sin embargo, a pesar de la cantidad de ordenadores infectados, estas detenciones no deben ser consideradas como el fin de los correos spam. Se ha conseguido detener una pequeña parte, pero queda mucho por hacer. Aunque los datos existentes ofrecen para nosotros un número de ordenadores infectados un poco exagerado, ¿cuántos de esos ordenadores pertenecen a usuarios españoles?

Miguel López-Negrete
S21sec labs

¿Se podrían manipular unas elecciones?

Pues parece ser que la respuesta es si. O al menos eso es lo que se puede entrever del informe EVEREST (Evaluation and Validation of Election-Related Equipment, Standards and Testing), iniciativa de miembros de la universidad de Pensilvania, WebWise Security y diversos equipos de investigación de Pennsilvania.

El informe EVEREST, que estudia sistemas de votación electronicos de las empresas "Election Systems and Software (ES&S)" y "Hart InterCivic and Premier Election Solutions" antes conocido como "Diebold", pone en evidencia el sistema de voto electrónico de Estados Unidos (el 80% del voto en estados unidos es manejado por máquinas fabricadas por estas empresas).

Se han detectado fallos de todo tipo, como por ejemplo, fallos debidos a "buffer overflows", cifrado insuficiente (inexistente en algunos casos) y fallos de firmware, que posibilitan alterar el resultado de unas elecciones, en algunos casos con el simple uso de herramientas ofimáticas muy comunes.

Para empeorar las cosas, estas máquinas no funcionan de manera constante, lo que significa que se podría instalar malware y no ser detectado hasta el día de las elecciones.

Afortunadamente para los ciudadanos estadounidenses, el informe EVEREST ya ha comenzado a tener sus primeros resultados, ya que la oficina de la secretaría de estado de Colorado, ya ha "descertificado" las máquinas de voto electrónico usadas en las pasadas elecciones.

La conclusión que se puede sacar de todo esto es, que, previamente a las elecciones no se hizo una auditoría de seguridad adecuada a las máquinas utilizadas para el voto electrónico.

¿Qué pasaría si se optase por el sistema de voto electrónico en España?.¿Nuestros políticos se fiarían?. Lo que si que es seguro (sobre todo para una empresa como nosotros) es que es una posibilidad de la que hay que estar al tanto.

Asier Marruedo
S21sec labs

Bitacora 4.0, solución ideal para la adaptación a la normativa PCI DSS

Como fruto de una progresiva concienciación sobre seguridad que lleva promoviendo S21sec junto a otros agentes desde hace tiempo, ya han visto la luz o se encuentran en trámite normativas o estándares de ámbito nacional o internacional como la ley Sarbanes-Oxley (SOX), la Norma ISO/IEC 27002, “Código de Buenas Prácticas para la Gestión de la Seguridad de la Información”, la legislación en materia de protección de datos de carácter personal (LOPD y Reglamento de Medidas de Seguridad) o COBIT (Control Objectives for Information and related Technologies), que contemplan aspectos relacionados con la gestión de la seguridad de la información. La mayoría de ellas incluye requerimientos específicos en relación a la monitorización de los sistemas de información y la retención de registros de auditoría.

La monitorización de los sistemas es uno de los aspectos contemplados por el Payment Card Industry Data Security Estándar (PCI DSS), estándar que establece un conjunto de medidas que pretenden garantizar la seguridad en el tratamiento de la información asociada a pagos realizados con tarjeta. Estas medidas son aplicables a todos aquellos sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas (host, firewalls, routers, servidores de banca electrónica, bases de datos asociadas, aplicaciones específicas de banca,…).

Las principales marcas de tarjetas, como Visa, Mastercard o American Express, exigen el cumplimiento de PCI DSS tanto por parte de las entidades financieras como por parte de los comercios y proveedores de servicios. Con el fin de validar este cumplimiento, se exige la realización de escaneos de red trimestrales y, en determinados casos, de auditorías anuales in situ que deberán revisar, entre otros aspectos, los mecanismos de gestión de logs implantados en el marco de los planes y programas de seguridad de la Organización.

No todas las herramientas en las que subyace esta necesaria gestión de logs se adaptan todavía al estándar PCI-DSS. S21sec ha conseguido, en cambio, disponer de un instrumento acorde con esta regulación, que cumple eficazmente su misión de detección, solución y prevención de problemas de seguridad críticos en este campo, así como de proveedor de información anticipada antes de que se produzca un posible ataque. Lo ha logrado gracias a la adaptación de la herramienta Bitacora, en su nueva versión 4.0, tras la incorporación de nuevas funcionalidades desde el centro de I+D+ i de S21sec.

Bitacora es una solución avanzada que facilita la gestión y análisis de cualquier tipo de evento, posibilitando el empleo de los logs de auditoría como posibles evidencias en un proceso judicial. No sólo reporta datos de seguridad, sino que además ofrece indicadores que ayudan en la toma de decisiones a nivel de dirección. Adicionalmente, sus nuevas funcionalidades permiten a la plataforma alinearse con diferentes productos y servicios avanzados de S21sec, para adaptarse a las necesidades reales de cada organización, según el sector en el que se encuentre. Los más comunes son el de las comunicaciones (Operadores o ISP), sector financiero, medios de pago, comercio electrónico y las administraciones públicas.

Esta herramienta es pues una solución válida para adaptarse al cumplimiento del estándar PCI DSS, ya que se encuentra en posición de cumplir los siete requisitos contemplados en el Requerimiento 10 de dicho estándar, ‘Revisión y Monitorización de todos los accesos a los recursos de red y a los datos de titulares de tarjetas’. Para empezar, Bitacora es capaz de relacionar todos los accesos a los componentes del sistema (aquellos que almacenan, procesan o transmiten datos de titulares de tarjetas) con un individuo en concreto, así como registrar todos los eventos exigidos por PCI DSS (accesos de los usuarios a la información, intentos de acceso no autorizados, acciones realizadas por los administradores de los sistemas,…), siempre que el dispositivo genere el correspondiente log.

El tercer requerimiento que cumple Bitacora para adaptarse a PCI DSS es permitir el registro de los campos exigidos por el estándar para cada uno de los eventos (identificación del usuario, origen del evento, fecha y hora). Contempla, asimismo, la necesaria sincronización de horas de sistemas críticos.

Por otra parte, en relación a la securización de los registros, y en base a los requerimientos de PCI DSS, Bitacora permite proteger los archivos de auditoría de posibles modificaciones no autorizadas (mediante firma digital y sellado de tiempo), realizar una copia de respaldo de los logs de forma inmediata y establecer diferentes perfiles de acceso, con el fin de limitar la visualización de los registros de auditoría a aquellos usuarios que lo necesiten para el ejercicio de sus funciones.

Existen dos últimas exigencias que han sido satisfechas gracias a las nuevas funcionalidades de Bitacora 4.0: la revisión de logs de todos los componentes del sistema al menos una vez al día, mediante la creación de un conjunto mínimo de alertas que permita monitorizar estos eventos, y el mantenimiento de un histórico de los registros de auditoría durante al menos un año, con un mínimo de tres meses de disponibilidad online.

Debido a ello, se puede afirmar que Bitacora constituye la herramienta idónea para apoyar la implantación de los requerimientos establecidos en el estándar PCI DSS en relación a la monitorización de los sistemas, favoreciendo y facilitando, al mismo tiempo, el cumplimiento de normativas y estándares aplicables a nivel internacional en materia de gestión de seguridad de la información.


Vanesa Gil (Manager Consultoría, Qualified Security Assessor)
Gonzalo Asensio (Manager Bitacora y Vulnera)

Pistas para el Reto 3

Se ha cumplido el plazo establecido para la resolución del reto 3, y todavía no hemos recibido ninguna solución, por lo que vamos a dar alguna pista.

Una vez desensamblado el crackme, podemos observar que el código es muy feo, que ha sido ofuscado, por lo que en primer lugar lidiaremos con este problema.

Para ello, podemos observar que todo el código es similar. En este caso se han utilizado un par de macros que introducen basura. En la imagen vemos muchos saltos que no pretenden más que dificultar el análisis del código.

Para combatir esto, nos bastará con eliminar este código muerto (instrucciones inútiles). Para ello utilizaremos, por ejemplo, el depurador OllyDbg con el plug-in OllyScript y el siguiente script.

//Inicializamos variables
var dir_obf
var pos_mem
mov pos_mem,00401000

//buscamos los bytes que nos interesan en memoria
find pos_mem, #740975070FEB06EBFD7401EB010F#
mov dir_obf, $RESULT
bucle:
//y los reemplazamos con instrucciones NOP
repl dir_obf, #740975070FEB06EBFD7401EB010F#, #9090909090909090909090909090#,14
find dir_obf, #740975070FEB06EBFD7401EB010F#
mov dir_obf, $RESULT
//hasta no encontrar ningún resultado más
cmp $RESULT, 0
je fin
jmp bucle
fin:
ret

Lanzamos este script, y como resultado obtenemos un código más legible, aunque comprobareis que queda alguna otra macro para quitar.

Seguimos analizando el funcionamiento del crackme, y vemos que la razón del alto consumo de CPU y el tiempo que tarda en mostrar el mensaje es debido a que lanza numerosos hilos que se encargan de la comprobación.

Ante esto, y viendo que el código de cada hilo es muy simple, yo me decanto por un análisis estático.
Personalmente opino que un método correcto puede consistir en sentarse con un papel y bolígrafo en frente del código y empezar a dibujar círculos y rayas. ;)

Eso sí, queda bastante claro que nos enfrentamos a una labor tediosa.

¡Que cada uno ataque por donde quiera!

No dudeis en enviar vuestra solución a labs@s21sec.com. Podeis enviar también vuestros avances/dudas en caso de que no consigais resolverlo.

Mikel Gastesi
S21sec labs

European Privacy Seal

El sello europeo de seguridad es un consorcio formado entre otros por la Agencia de Protección de Datos de la Comunidad de Madrid (APDCM), por la Commision National de l’Informatique et des Libertes CNIL (regulador de Protección de Datos en Francia) y la UDL (Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein regulador de protección de datos del estado alemán de Schleswig-Holstein).

Dicho consorcio tiene por objetivos:

• Proveer de seguridad a los datos de los usuarios cuando la privacidad y confianza están en juego.
• Proveer unas mejores prácticas para el B2B.
• Fomentar la privacidad en el desarrollo de la sociedad de la información y en los mecanismos y servicios de marketing.
• Certificar la conformidad y alineamiento con los criterios de privacidad de bienes, productos y servicios.

Desde la UDL se han emitido dos sellos de privacidad, en la actualidad desde el estado federado de Schleswig-Holstein se están acreditando a diferentes empresas hasta 40 por parte de al menos 30 certificadores acreditados, productos y servicios mediante la concesión de los siguientes sellos:



Sello de Auditoria de Privacidad y Protección de Datos






Sello de homologación de organizaciones y/o productos (tales como dispositivos de electrónica de red, Sistemas operativos, ERP)


Por el momento se está desarrollando un piloto en el que participan seis países, Alemania, Austria, Eslovaquia, España, Suecia y el Reino Unido, dicho piloto consiste en certificar productos y servicios IT conforme a las normativas europeas en materia de privacidad y seguridad de los datos.

S21sec participa en el piloto de European Privacy Seal certificando a sus profesionales como expertos en seguridad y privacidad, capacitados en un futuro próximo para auditar y certificar productos y servicios IT como auditores y certificadores independientes.

Se trata de un largo camino que esperemos que fructifique en la ansiada certificación de auditores en materia de protección de datos de carácter personal que vienen persiguiendo los diferentes reguladores, nacionales y autonómicos como la APDCM.

Koldo Peciña
David Imizcoz
Dpto. Consultoría S21sec

Colossus vs. Copacobana

Las máquinas Colossus fueron dispositivos de computación electrónicos creados por los ingleses durante la Segunda Guerra Mundial, con el objetivo de descifrar los mensajes enviados por los generales alemanes desde el campo de batalla al mando central de Berlín. Podría considerarse que estas máquinas fueron los primeros dispositivos programables del mundo (a pesar de que no podían considerarse máquinas de Turing), permitiendo a los ingleses acelerar los procesos matemáticos de manera que los cálculos pasaban de requerir semanas a realizarse en cuestión de días.

Existieron dos generaciones de Colossus, que fueron desarrollados en el Bletchley Park: la Colossus Mark I, operativa a partir de diciembre de 1943, y la Colossus Mark II, una versión mejorada del primer prototipo que comenzó a funcionar en junio de 1944. Estas máquinas estaban diseñadas para ayudar en las tareas de descifrado de los teletipos que habían sido cifrados por los alemanes usando su máquina Lorenz SZ40/42. Su tarea consistía en comparar dos flujos de datos, cuantificando cada coincidencia mediante el uso de una función booleana. El mensaje cifrado se leía de una cinta de papel perforada, a alta velocidad (48 Km/h) y proporcionaba los datos de uno de los flujos. El otro flujo de datos se generaba internamente, mediante una simulación de la máquina de Lorenz configurada con varios valores (prueba y error). Si una de las configuraciones producía un número de coincidencias por encima de un umbral, sacaba la información por una impresora.

Colossus Mark I empleaba 1500 válvulas de vacío, y su versión posterior, la Mark II, usaba 2400 válvulas. Las mejoras de la segunda versión le proporcionaban un aumento de la velocidad considerable, siendo 5 veces más rápida que la primera versión. Además era más sencilla de manejar. Hubo un momento en el que llegaron a funcionar simultáneamente 10 máquinas Colossus en el Bletchley Park.

La existencia de Colossus se mantuvo en secreto durante muchos años después de la guerra, por lo que no ha sido incluida en la historia del hardware de ordenadores durante bastantes años. Debido al carácter secreto de esta máquina, no ha influenciado el desarrollo de ordenadores posteriores. Al terminar la guerra, Winston Churchill ordenó la destrucción de todas las máquinas Colossus en piezas de un tamaño no superior a una mano humana. Tras varios años de silencio, la información sobre el proyecto Colossus empezó a surgir a finales de los 70 tras finalizar el periodo de vigor de la Ley de Secretos Oficiales (1976). Más recientemente, un informe técnico de 500 páginas sobre su sistema de cifrado y su criptoanálisis ha salido a la luz de mano del "Government Communications Headquarters" (organismo gubernamental de inteligencia británico).

Gracias a toda esta documentación, ha sido posible que un equipo de voluntarios liderado por Tony Sale comenzara la construcción de una réplica completamente funcional de una Colossus Mark II. Esta reconstrucción, que ha llevado 16 años de trabajo, está actualmente expuesta en el Museo Bletchley Park. Esta réplica, tras 60 años de silencio, se ha encargado de descifrar de nuevo mensajes cifrados con una máquina Lorenz SZ40/42 y transmitidos por radioaficionados de Paderborn (Alemania).

Cabe preguntarse qué tiempo puede necesitar Copacobana, un craqueador de códigos programable con FPGAs y disponible para cualquiera que tenga poco más de 7000 euros en el bolsillo, en descifrar el código de la máquina Lorenz, ¿un segundo?

Álvaro Ramón
S21sec labs

¿Por qué un Plan Director de Seguridad?

Conceptualmente podríamos definir un Plan Director de Seguridad como la herramienta que permite a una organización definir sus actividades en Seguridad de los Sistemas de Información a corto, medio y largo plazo. De alguna forma es un traje a medida para la organización.

Los Planes Directores de Seguridad pretenden analizar y dar a “conocer” a las compañías su grado de seguridad, y proponer las medidas correctoras planificadas en el tiempo para garantizar el nivel de seguridad más adecuado a las necesidades del negocio.

A estas alturas de la película cualquier organización reconoce que el buen funcionamiento de los sistemas de información es crítico en el desarrollo de sus actividades y, al mismo tiempo, que dichos sistemas se encuentran en situación de riesgo tanto por la propia vulnerabilidad inherente a los sistemas como por una insuficiente implantación de mecanismo y controles de seguridad. Estas vulnerabilidades pueden producir perdidas de activos de la organización (BBDD, ficheros, documentación de sistemas, software de aplicación o de sistema, equipos de tratamiento informático, etc.) o incluso afectar a la continuidad del negocio. Por tanto, alguno de los motivos que justifican la necesidad de disponer de un Plan Director de Seguridad pueden ser los siguientes:

• Importancia cada vez mayor de la seguridad de la información.
  Consideración de la seguridad con una visión integral (tecnológica, organizativa, legal, recursos humanos,...).
• Evitar iniciativas de seguridad tomadas de forma aislada.
• Heterogeneidad de sistemas e infraestructuras.
• Diferentes requisitos de seguridad a lo largo de la Organización.
• Necesidad de abordar la seguridad en un plan coherente y sistemático que marque las pautas y directrices a seguir.

El desarrollo de un Plan Director de Seguridad está basado en tres pilares fundamentales:

• Punto de partida inicial: Análisis de la situación actual.
• Objetivo marcado: Determinar estrategias y requisitos organizativos para llegar a una situación deseada.
• Camino a recorrer entre ambos.

En el proceso de definición de un Plan Director de Seguridad es necesario identificar los objetivos y las necesidades en materia de Seguridad de la Información tales como los requisitos de seguridad en el negocio, la criticidad de la información, la legislación aplicable, los requisitos impuestos por dicha legislación, etc. El proceso para la elaboración de un Plan Director de Seguridad, de forma genérica, pasa por la ejecución de las siguientes fases principales:

• Identificar los requisitos organizativos de la seguridad de los Sistemas de Información.
• Identificar los activos y realizar una valoración de su importancia.
• Análisis de riesgos: identificar amenazas reales y potenciales sobre los activos.
• Alinear la seguridad con la estrategia de negocio: Determinar objetivos, estrategia y políticas.
• Gestionar los riesgos: establecer los controles y las salvaguardas a implantar.
• Seguimiento de la gestión de riesgos.

Tras la elaboración de un Plan Director de Seguridad los resultados obtenidos deberían contemplar, al menos, los siguientes aspectos:

1. Las medidas de Seguridad actualmente existentes en la Organización y la identificación de puntos débiles: ¿Qué está bien?, ¿Qué está mal?, ¿Qué necesita mejorar?, ¿Se cumple con los objetivos?, ¿Cuáles los riesgos principales y a qué son debidos?, ¿Sobre qué procesos de negocio me impactan estos riesgos?, es decir, ¿en qué procesos existe un mayor riesgo?, ¿Qué procesos de negocio están afectados por las vulnerabilidades detectadas?....
2. El nivel de seguridad que se desea alcanzar: Definir la situación objetivo ¿Hasta dónde queremos llegar?, ¿Dónde va a estar nuestro umbral de riesgo? ¿Cómo vamos a gestionar los riesgos (Evitándolos, Suprimiéndolos, Transfiriéndolos, Reduciéndolos)?.
3. Las necesidades reales en materia de Seguridad para la Organización: Estas necesidades quedarán recogidas en forma de proyectos o acciones a realizar/ejecutar.
4. La planificación de la implantación: Proyectos a Corto Plazo (a iniciar en los próximos 1 meses), Proyectos a Medio Plazo (a iniciar en el período comprendido entre los 12-24 meses desde la fecha actual), Proyectos a Largo Plazo (a iniciar en el período comprendido entre los 2-36 meses desde la fecha actual).
5. Secuencia temporal y dependencia entre los proyectos: Una hoja de ruta que defina y establezca las relaciones de precedencia y dependencia entre las diferentes acciones identificadas, así como el marco temporal propuesto para su ejecución (Acciones predecesoras y vinculadas).
6. La inversión a realizar: para cada una de las acciones o proyectos que se identifiquen.
7. Cuantificación de recursos y costes: considerando la totalidad de los costes asociados en caso de apostar por soluciones de terceros (costes de adquisición, implementación, mantenimiento, formación a usuarios y operadores) y la dedicación de los recursos internos.

Joan Ayerbe.
Manager de Consultoría, CISM.

La seguridad en los foros

Me paseaba yo tranquilamente repasando los foros oficiales de World of Warcraft cuando observe un post que me llamaba la atención por encontrarse totalmente fuera de lugar.
En primer lugar el asunto del post estaba en ingles, así como su contenido (raro en un foro en castellano) y en segundo lugar invitaba a ver fotos de chicas “ligeritas”.

Realmente era un reclamo burdo y poco elaborado para un foro de esa temática (en otras ocasiones he visto enlaces a objetos del juego, etc ) pero aun así y por curiosidad me dispuse a analizarlo.

Lo primero fue visitar el enlace... con un cliente http raw :D y se podía observar que no era un enlace a una foto, sino que el servidor devolvía un html con un par de frames. El primer frame si apuntaba a una foto, el segundo apuntaba contra otro dominio y otro html donde se encontraba el código del infector en si.

El código del infector en si no tenia mayor relevancia, era un simple html que diversos frames y scripts para explotar diversas vulnerabilidades ya conocidas.. desde la ya famosa del .ani introduciendo un cursor “tt.gif”, hasta el lanzamiento de un wav con payload....

Todos los infectores realizaban la misma tarea, bajarse un fichero “lese.exe” desde diversas localizaciones (cada infector de una distinta) y ejecutarlo en la maquina local.

El nombre ya lo conocía, “lese.exe” era el nombre de un conocidillo troyano roba contraseñas del World of Warcraft que ya había visto en el pasado y estuve a punto de “dejarlo pasar”, pero me di cuenta de que no era el mismo que había visto en el pasado y su diferencia de tamaño era notable... era una nueva versión pero no era un “refrito” del anterior.

Así que me puse manos a la obra. Lese.exe estaba sin comprimir ni cifrar, llevaba un binario empaquetado dentro y realizaba tareas bastante sencillas.. así que, maquina virtual, discos de deshacer y a infectarla monitorizando con filemonitor / regmon,etc.
El ejecutable instalaba en el sistema una dll llamada “kbass1p.dll”, dicha dll se incrusta como una garrapata en mil sitios (asociaciones de ficheros, carga en aplicaciones, etc).

El primer análisis de la dll me indicaba que estaba empaquetada, además, si había variado mucho ya que la versión que conocia del “lese” instalaba unas cuantas cosas mas, no una simple dll y además tan pequeña (36k’s). Deje el equipo infectado, active el remote debugger y ... a verla. Empecé a navegar por su código y vi cosas bastante curiosas como por ejemplo la rutina para componer la ip destino de sus datos y como se enganchaba al sistema (básicamente un keyloger basado en un hook al bucle de mensajería de Windows). Como no tenia ni tiempo ni excesivas ganas de desensamblar absolutamente todo el código, simplemente la deje correr. Situé un Wireshark en el adaptador de red en la maquina host, puse filtros para ver solo las comunicaciones de la maquina virtual y en esta ultima abrí un simple Internet Explorer y me dedique a navegar. Cual fue mi sorpresa que tras una conexión https que llevara “user” y “password” en el código de la pagina.... se establecía una misteriosa conexión a una maquina situada en China al puerto TCP 2034 y con unos datos de naturaleza poco clara


El anterior troyano solo enviaba cuentas de World of Warcraft y además lo hacia con una conexión http .. encima en el propio get... esto sin embargo pasaba unos datos (que no sabia que eran) a una maquina con su propio protocolo (y lógicamente usando el contexto de la aplicación que hubiera capturado, esto es , en mi caso, el Internet Explorer)

Había que romper el cifrado que usaba, así que, análisis diferencial y búsqueda de patrones... capture un par de paquetes que enviaba después de haber usado yo de usuario y contraseña “abcdefg” y “gfedcba”, analizando las diferencias se observaba esto:

26 67 0b 0e 67 a8 c5 07 c4 ed 8e 0d ac 4e a7 8e
ac 0f 8e 6b ae 6e ac 4e cd 2c ad ac ab 2c 4c 6c
8c ac cc ec e5 0e 2c 6e 6e ee ed 4e 8c 6b 0e 2c
6e 6e ee ed 4e 8c ab 2c 4c 6c 8c ac cc ec e5  

Paquete “abcdefg” en user y password

26 67 0b 0e 67 a8 c5 07 c4 ed 8e 0d ac 4e a7 8e
ac 0f 8e 6b ae 6e ac 4e cd 2c ad ac ab ec cc ac
8c 6c 4c 2c e5 0e 2c 6e 6e ee ed 4e 8c 6b 0e 2c
6e 6e ee ed 4e 8c ab ec cc ac 8c 6c 4c 2c e5  

Paquete “gfedcba” en user y password

Vaya! Bingo! Hay correlación :D ahora solo hay que sacar el patrón... además el algoritmo de cifrado no cambia en el tiempo!
Como hemos observado, aparece la secuencia de valores a la inversa así que, tomando el primer caso suponemos que “2c” es la “a” es decir “64” en hexadecimal. Elaboro una simple tabla con los números en binario, el correspondiente en el paquete capturado y...

01100001-00101100 – “a”
01100010-01001100 – “b”
01100011-01101100 – “c”
01100100-10001100 – “d”
01100101-10101100 – “e”
01100110-11001100 – “f”
01100111-11101100 – “g”

Anda! Si es fácil! Si rotamos los bits 5 posiciones a la izquierda obtenemos el valor “codificado” :D Entonces aplicando rotación a la derecha, descifraremos. Aplicando eso al total de paquete obtenemos la información que este keyloger / troyano es capaz de enviar:

01 01 01 01 01 00 18 00 30 00 68 08 06 80 73 69 64 ........0.h..€sid
3d 77 6f 77 6f 76 65 72 33 36 35 26 75 72 6c 3d 2f =wowover365&url=/
77 77 77 2e 77 6f 77 2d 65 75 72 6f 70 65 2e 63 6f www.wow-europe.co
6d 2f 6c 6f 67 69 6e 32 2f 6c 6f 67 69 6e 3f 73 65 m/login2/login?se
72 76 69 63 65 3d 68 74 74 70 73 25 33 41 25 32 46 rvice=https%3A%2F
25 32 46 77 77 77 2e 77 6f 77 2d 65 75 72 6f 70 65 %2Fwww.wow-europe
2e 63 6f 6d 25 32 46 61 63 63 6f 75 6e 74 25 32 46 .com%2Faccount%2F
25 33 42 6a 73 65 73 73 69 6f 6e 69 64 25 33 44 41 %3Bjsessionid%3DA
39 44 36 37 33 46 35 31 41 32 33 32 46 32 32 35 45 9D673F51A232F225E
35 34 39 32 45 46 36 39 31 41 30 37 42 46 2e 61 70 5492EF691A07BF.ap
70 30 38 5f 30 35 26 6c 6f 63 61 6c 65 3d 66 72 5f p08_05&locale=fr_
46 52 26 70 63 3d 43 65 72 62 65 72 6f 63 6c 69 65 FR&pc=Cerberoclie
6e 74 3b 31 37 32 2e 31 37 2e 31 2e 31 31 31 3b 58 nt;172.17.1.111;X
70 3b 45 2e 38 26 6f 74 68 65 72 3d 74 65 78 74 5b p;E.8&other=text[
75 73 65 72 6e 61 6d 65 5d 61 62 63 64 65 66 67 2f username]abcdefg/
....

Manda la url, el idioma de la maquina, versión de operativo, nombre de maquina ip así como los campos de usuario y contraseña capturados! :D Cuanta cosa y solo por visitar un inocente enlace en unos foros oficiales de un juego... y que encima no me habría salvado aunque no usara IE (ya que dispone de exploits para Firefox también)

Encima, para rematar el asunto, decidí subir el binario inicial a una web de análisis de malware online ¿resultado? Ayer tarde 13 de Diciembre, solo 4 motores de antivirus de 32 de los que disponía la web eran capaces de detectar “algo” por heurística en este bichito, es decir, que disponer de Antivirus no te salva y disponer de Firewall tampoco (si tiene permisos el Wow, Internet Explorer, Firefox,etc como es lógico, el troyanito este enviara información)

¿Cuál es la solución? Dos, sentido común y proteger las webs, aquellas que son visitadas por amplias multitudes mediante sistemas de análisis automáticos de aquellos enlaces colgados por los usuarios.

Victor Jurado.
S21sec Labs

La no-seguridad debe tener un coste

Hace ya algunas semanas tuvimos la oportunidad de escuchar a Bruce Schneier en la II Jornada Internacional del ISMS Forum (ya os lo comenté) y volvieron a surgir algunos temas recurrentes en Bruce como el efecto de la complejidad sobre la seguridad. Pero lo más interesante (desde mi punto de vista) fue la reflexión relativa a la aplicación de conceptos económicos a la gestión de la seguridad. En concreto, me llamó mucho la atención la reflexión sobre la importancia de lo que se conoce como 'externalidad' (externality) [me encanta que mi formación como Economista tenga, al fin, una utilidad clara].

En resumidas cuentas, la externalidad se produce cuando nos encontramos en una situación en la que los costes o beneficios privados a los productores o compradores de un bien o servicio difiere del coste o beneficio social total relacionado con su producción y consumo. La externalidad existe siempre que las acciones de un agente afectan al bienestar de otro agente (para bien o para mal) de formas que no necesitan ser pagadas de acuerdo a la definición existente en la sociedad de los derechos de propiedad.

Lo mejor es recurrir a un ejemplo práctico: Un empresario que produce poco respetuosa con el medio, afectándonos a todo no tiene que pagar más por esa producción (por eso existe una legislación medioambiental).

Y lo cierto es que, en el mundo de la seguridad ocurre exactamente lo mismo y es algo sobre lo que también habíamos hablado en algún momento previo. Todo esto ha surgido al hilo del artículo publicado aquí en el que se propone la aplicación de un "impuesto" a las vulnerabilidades del software. Estoy de acuerdo con el autor (Kelly Jackson) en que se debe establecer algún mecanismo para que a los fabricantes les resulte rentable fabricar software seguro. En definitiva lo que hemos de encontrar es un mecanismo para resolver la externalidad existente en el mundo de la seguridad y en este punto, en lo relativo a las vulnerabilidades del software: Si un fabricante produce un coste al bienestar del consumidor superior a lo que éste paga por el software, debe existir algún mecanismo para igualar ambos costes.

¿Es un impuesto el mejor mecanismo? No lo sé, se abre el debate...

Antonio Ramos
Director de Consultoría Estratégica

Basilea II y la integración del análisis de riesgos

¿QUE ES BASILEA?

Se trata del comité para el entendimiento y la calidad bancaria en el mundo, para lograrlo se basa en el intercambio de información a través de acuerdos internacionales de supervisión, el desarrollo de la efectividad de las medidas de supervisión y el establecimiento de estándares. Uno de los principales estándares desarrollados ha sido los “Principios de la Gestión de Riesgos para la Banca Electrónica”.

DEFINICIÓN DEL RIESGO PARA BASILEA II

• Riesgo Tecnológico, definido como la perdida ocasionada por daños, interrupción, alteración, fallos derivados de la dependencia de tecnologías de la información en la prestación de servicios bancarios.
• Riesgo Legal, definido como la pérdida ocasionada por incumplimientos de las disposiciones legislativas, normativas, administrativas y judiciales.
• Riesgo Operacional, riesgo a la pérdida debido a la inadecuación o a fallos imprevistos de los procesos, el personal y los sistemas internos.

LA SEGURIDAD DE LA INFORMACIÓN EN EL RIESGO OPERATIVO

El riesgo operativo contiene una alta importancia por el componente eminentemente tecnológico de muchos de los procesos de negocio, los procesos tecnológicos que componen el riesgo operacional de una entidad financiera pasan entre otros por la Seguridad de los sistemas de información.

La seguridad de la información juega un papel determinante para el riesgo operacional de acuerdo a Basilea II, dentro de estas causas se podrían identificar las siguientes amenazas:
El resto de procesos tecnológicos del riesgo operacional presentan además numerosas amenazas que podría comprometer la entrega de los procesos de una entidad financiera, tales como:

• Tecnología obsoleta.
• Ausencia de un análisis de riesgos.
• Falta de herramientas de seguimiento y monitorización.
• Inexistencia de ciclos de auditoria
• Problemas en el control de cambios a programas y sistemas
• Inadecuada seguridad física y lógica
• Falta de control de los servicios prestados por terceros.

METODOLOGÍA PARA LA EVALUACIÓN CUALITATIVA DE LOS RIESGOS OPERACIONALES ASOCIADOS A LOS COMPONENTES TECNOLÓGICOS

De cara la gestión de los riesgos de acuerdo a riesgo operacional de los procesos tecnologicos en una entidad financiera, sería recomendable realizar una evaluación de acuerdo a las siguientes fases.

De acuerdo a los postulados de Basilea II las entidades financieras deberán de estar adecuadas en 2008.

Según Basilea el riesgo en las entidades financieras se reparte de la siguiente manera:

• 70% de riesgo Crediticio.
• 18% de riesgo Financiero.
• Y 12% de riesgo Operacional.

De ahí la importancia y la necesaria gestión del riesgo Operacional de las entidades financieras y su cada vez más relevante componente tecnológico.

David Imizcoz
Manager de Consultoría S21sec

Police 'Honey-Pots' in Germany ?

On the hunt for terror suspects, investigators of the German BKA propose to the German government to spy out private homes with hidden cameras, catch W-Lan-Communication and intercept telephone calls even if the participants are not accused.

The investigators argue for a fundamental change of the existing law to allow a "covert search with hidden cameras" of suspicious homes. The police regulations of the countries shall also be uniformly arranged, so that officials can preventive intercept telephone calls, even if the affected still had no suspects.

In addition, because previous terrorists repeatedly used unprotected WLAN Access Points from private persons to communicate with functionaries of the "Islamic Jihad Union" (IJU) in Pakistan, the police chiefs want to install nationwide also called W-Lan-Catcher. The devices are used to simulate an access point with Internet connection and allow it to monitor and analyze traffic data.

Until now this idea is only favored by the conservative party CDU , others like the social SPD and the green party 'Die Gruenen' disapprove. Let's see what the future brings.

(read more(in German))


Clemens Kurtenbach
S21sec labs

¿IP en el coche?

En la actualidad los sistemas electrónicos de automóvil pueden verse como un conjunto de sistemas embebidos, sensores y actuadores interconectados por diversos sistemas de comunicaciones propietarios (CAN, LIN, MOST o Flexray). Estos sistemas electrónicos permiten controlar diferentes subsistemas del vehículo: motor, sistema de estabilidad, panel de mandos, sistema antirobo, control de crucero, espejos, elevalunas eléctricos, etc. Es habitual que muchos de estos subsistemas tengan requisitos muy exigentes en cuanto a tiempos de respuesta y de hecho se les conoce como sistemas de tiempo real; una actuación a destiempo de algunos de estos subsistemas puede llegar a comprometer la seguridad del viajero (control de estabilidad, de motor, …). Por otro lado, cada vez más modelos de todos los segmentos y marcas de automóvil incluyen nuevos sistemas electrónicos orientados hacia el entretenimiento y la comunicación (piénsese en las flexibilidades del “diente azul”) aunque la verdad es que las funcionalidades que ofrecen son todavía bastante limitadas.

En base a lo anterior los señores del departamento de investigación y desarrollo de BMW, en su afán por prever las características del vehículo del futuro, han pensado que la tendencia es la inclusión de todo tipo de capacidades multimedia y de comunicaciones; desde la navegación por Internet, pasando por la videoconferencia hasta la conexión de dispositivos plug&play. Vamos, al más puro estilo Multimedia Center de Microsoft pero en el coche.

Sin embargo hay varios problemas que solventar antes de alcanzar este idilio tecnológico. Por un lado, hay que compaginar un sistema seguro para el conductor basado en estrictos requisitos de tiempos de respuesta, con un sistema multimedia que requiere grandes anchos de banda. Por otro lado, hay que mantener los costes de producción y al mismo tiempo ofrecer todas estas nuevas funcionalidades. Todo esto suena a economías de escala, calidad de servicio, estándares, etc.

La gente de BMW ha decidido probar suerte con IP, como sustituto de los protocolos de comunicaciones propietarios arriba mencionados, y utilizando técnicas de calidad de servicio y catalogación de tráfico (“traffic shaping”). Básicamente han montado un sistema de control de motor, otro de control de estabilidad y un tercero de panel de mandos y los han comunicado vía IPv4 entre sí y con un servidor multimedia y una cámara de vídeo. Parece ser que los resultados han sido muy prometedores, ya que los requisitos de ejecución en tiempo real han sido cubiertos con creces de tal manera que no se compromete la seguridad del conductor y los acompañantes.

Antes de lanzar las campanas al vuelo cabe preguntarse por otro tipo de seguridad. ¿Qué ocurriría si a través de Internet se causara una denegación de servicio? ¿Y si entrase un troyano que permitiera controlar de manera remota el sistema electrónico de nuestro coche? ¿Tendríamos que empezar a instalar cortafuegos, detectores de intrusiones y antivirus? ¿Qué sistema operativo utilizaríamos? …

Elyoenai Egozcue
S21sec labs

Bugs de silicio

Una anécdota muy conocida es la de la polilla que hacía fallar un relé en uno de los grandes ordenadores de los años 50. El término “bug” ya se utilizaba para referirse a errores o comportamientos no esperados en ingeniería y esta polilla se considera como el primer bug (en sentido literal y figurado) encontrado en un procesador.


Hasta ahora, los procesadores siempre han tenido errores. Diseñar e implementar un procesador es cada vez más complicado, supone más lineas de código y lógicamente más bugs. Algunos adquieren cierta fama, como el famoso FDIV de los primeros Pentium, pero normalmente pasan desapercibidos. Existen muchos más documentados de los que en principio se pueda pensar, tanto en procesadores Intel (Core duo y Core solo, Septiembre 2007) como AMD (Athlon64 y Opteron, Octubre 2007) .

Lo cierto es que la gran mayoría de estos errores se hacen notar en muy raras ocasiones y sus efectos suelen provocar que el procesador se pare, genere interrupciones que no deberían ocurrir o empeore el rendimiento. Es molesto, pero no supone un riesgo desde el punto de vista de la seguridad. Al menos de momento. En los últimos procesadores hay varios bugs que sí podrían suponer un riesgo para la seguridad, como flags de permisos de escritura o ejecución que son ignoradas o incluso intrucciones RET que en ciertas condiciones saltan a una dirección de memoria incorrecta.

Hoy en día estamos acostumbrados a aplicar parches a nuestro software y es algo que se realiza de una manera cada vez más automatizada. En el caso del hardware, hay varias posibles soluciones. Como consecuencia del bug FDIV, Intel cambió los procesadores defectuosos. Lógicamente, esta no es una solución práctica. En la actualidad, parte del código de los sistemas operativos se dedica a corregir en software los errores de los procesadores. Basta buscar las palabras quirk, workaround o errata en la carpeta arch del código de Linux.

Otra forma de combatir estos errores es que esa mayor complejidad de los procesadores ha traído también la posibilidad de actualizar su microcódigo, que define las instrucciones internas del procesador y que son distintas a las de la arquitectura x86. De cara al usuario esto se traduce normalmente en una actualización de la BIOS. Esta última solución pueden ser un poco engorrosa. La tendencia es utilizar actualizaciones del microcódigo que se envían al procesador durante el arranque del sistema operativo. Microsoft ya ha publicado un parche de este tipo, mientras que en Linux 2.6.20+ hay una aplicación llamada microcode_ctl que permite cargar descripciones del microcódigo que suministra Intel en su página web (ejemplo).

Parece que vamos a tener que acostumbrarnos a actualizar nuestro procesador, aunque sin duda, lo que deberían hacer los fabricantes es prestar más importancia a la seguridad del hardware, antes de que se descubra una vulnerabilidad aprovechable. Ahorraría muchos problemas y mucha publicidad negativa para la empresa afectada.

Patxi Astiz
S21sec labs

S21sec en el congreso de PCI Europe (Amsterdam)

El congreso se celebra el día 6 de Diciembre en el Renaissance Hotel (Amsterdam). En él Carmen Dufur (Senior Security Manager) ofrecerá una conferencia (alrededor de las 16:30 hora local) titulada "Strategic Considerations in Tracking and Monitoring Access to Network Resources and Cardholder Data" y abordará temas como:

• La comprensión del rango de dificultades en el cumplimiento del procedimiento 10; monitorización de redes, sistemas operativos y aplicaciones que generan distintos tipos de logs.
• Recolección y análisis de la información para obtener inteligencia en el proceso de monitorización y cómo este proceso ayuda en la toma de decisiones estratégicas
• Cómo asegurar que los logs permanecen intactos en caso de que se requieran como prueba en un juicio
• Cumplimiento del requerimiento 10; consejo práctico en la gestión de logs.

Además de esto, en el stand nº8 podréis ver demos en directo del nuevo Bitacora 4.0, Plataforma integral de seguridad a través de los logs, mediante alarmas e indicadores.
Esperamos veros por allí para poder saludaros personalmente.
Podéis ver toda la información de las actividades programadas y de los asistentes aquí.