Realmente se trata de esto. Es un thriller tecnológico contado a través de pantallas de ordenador, ventanas, webcams… Tiene una temática bastante relacionada con la seguridad, principalmente hacking y privacidad. Y, bueno, nada más el ir identificando sistemas operativos, software, comandos, etc. ya merece la pena echar el rato.

En definitiva, que da para verla y luego comentarla echandonos unas cervezas en algún sitio cercano al cine.

¿Qué os parece, alguien se apunta?

¿Que qué día será tan feliz evento?? Pues NUNCA. Porque la película no ha durado ni un mes en los cines de esta mierda de ciudad retrógrada…

Así que, si alguien ha tenido la suerte de verla, que nos cuente qué tal. Desde el punto de vista de seguridad y cosas informáticas, nada de spoilers o referencias a la anterior vida de Sasha Grey, ¿eh?

Como este es un tiempo de contricción, os propongo que os confeséis de la última vez que os desviasteis del camino correcto de la seguridad. El que se sienta muy avergonzado debe venir descalzo y dándose los correspondientes latigazos.

El que quiera también puede venir de NATzareno, de costhacklero o de penitenster.

Recordad que Jesucripto se secuirificó por todos nosotros en la CRUD y nadie encontró nada raro en el análisis forense.

¿Cuándo será tan esperado evento? Pues el próximo miércoles 9 de abril a partir de las 20:00 en el Arte y Solera de Torneo.

Así que, por la presente os convoco el próximo miércoles 26 en la cervecería Europa de Nervión (en su nueva localización que antes era un chino en la calle detrás del corte inglés) a eso de las 20:00h.¿Os parece?

Esta convocatoria pretende ser algo más positiva, porque al final siempre nos estamos quejando de las cosas. Que si este no me hace caso, que los de desarrollo son malos, que no me aprueban las cosas, que los de producción la lían, que si las cosas cambian mucho, que cuántas cosas tengo que cumplir, que qué malos son los demás, pilar malo, magerit caca, ENS flojo, …

Pues en esta convocatoria, esa actitud derrotista va a tener su castigo. Así que el primeo que se queje de algo paga la ronda. Pues eso, a tener pensamientos positivos y a mirar el lado bueno de las cosas.

Y aprovechando al coyuntura de que nos visita un fugado de la Gran Bretaña (que si no es por él igual ni hay convocatoria :)) pues ahí va la foto de estos Monty Ruby (esto lo pongo así sólo por chinchar a Eloy y a Manolo) crucificados viendo el lado bueno de las cosas, como deberíais hacer vosotros, al fin y al cabo, si todo fuera seguro ¿qué estaríamos haciendo nosotros?

Ya sabéis, si quieres asistir a la reunión y aun no eres miembro puedes:

• pedirle a un miembro de Sevilla Sec&Beer que te apadrine
• escribirnos un correo a reuniones@sevillasecandbeer.org
• pasarte por allí, pedirte una cerveza y hablar con nosotros sobre seguridad

Nos vemos…

He aquí la muestra gráfica.

Se aprecia claramente que indican que el ENS “no trabajará correctamente”… Es algo que todos sabíamos pero no está de más que lo reconozcan abiertamente.

Los cortafuegos Palo Alto (muy de moda últimamente, no entremos si mejores o peores, bla bla bla) permiten realizar pruebas sobre las reglas desde la línea de comando entrando por ssh. Esto permite probar sin necesidad de tener que generar tráfico real, lo cual viene muy bien para comprobar reglas, solventar incidencias, etc.

Sin embargo, es un poco coñazo por varias razones:

• Tienes que escribir un chorizo directamente en la línea de comando cada vez
• Si quieres repetir más adelante (por ejemplo, después de un commit) tienes que volver a escbirilo
• Si quieres probar varias reglas, tienes que ir una a una

Lo ideal sería poder tener un fichero con las pruebas que quieres hacer, lanzarlo de golpe, ver los resultados, hacer cambios, añadir pruebas o lo que sea, y poder volver a lanzarlo. Y cuando se realicen cambios, poder comprobar como afectan a estas pruebas.

Para eso, os incluyo aquí este pequeño script en expect que permite tener en un fichero las pruebas a realizar, se conecta por ssh y automáticamente lanza las pruebas que haya definidas. Si tenéis clave ssh, mejor. Si no, podéis descomentar las líneas para introducir la contraseña.

Instrucciones sobre cómo usarlo las podéis ver en el propio script.

Espero que os sirva para algo a los que tengáis cortafuegos Palo Alto.

Happy testing!

Hoy quiero hablaros de algo de lo que no hablaba desde hace tiempo (eso que os habéis ahorrado). Y es que recientemente me he visto involucrado en asuntos sucios como cumplimiento del ENS o… el motivo del post de hoy, el análisis de riesgos.

Pero esta vez no voy a quejarme demasiado sino que os voy a contar de la forma más directa posible qué pienso realmente de las metodologías de análisis de riesgos: sólo sirven para predecir lo obvio.

Veamos, lanzo la pregunta abierta siguiente: ¿para qué necesito un análisis de riesgos? Yo pienso que sólo sirven : para decirme cosas que ya sé.

No necesito un análisis de riesgos para que me diga que tengo que poner en alta disponibilidad el cortafuegos, es obvio.

No necesito un análisis de riesgos para saber que tengo que cumplir la legislación o tarde o temprano me pillarán, es obvio.

No necesito un análisis de riesgos para implantar copias de seguridad o algún día perderé algo importante, es obvio.

No necesito que un análisis de riesgos me diga que tengo que hacer auditorías de seguridad web, si no lo hago, alguien encontrará las vulnerabilidades por mí, es obvio.

No necesito un análisis de riesgos para saber que hay que intentar concienciar a los usuarios, es obvio.

No necesito un análisis de riesgos para obligar a los usuarios a elegir contraseñas que no sean fáciles de adivinar, es obvio.

(…)

Entonces… ¿para qué hago un análisis de riesgos? ¿Para convencer a alguien cuadriculado para que suelte el dinero para esas cosas? Igual, pero entonces es mejor elaborar un informe descriptivo en el que se analice la situación y no liarse a rellenar valores aleatorios en una aplicación de pseudociencia.

Lo que no niego es que el análisis de riesgos genera en los ‘gestores’ cierta fascinación, como si de verdad estuvieran desvelando el secreto de la naturaleza a través de ese análisis que les descarga de la necesidad de decidir en base a opiniones de ‘expertos’, cosa que, aparentemente, está muy mal vista.

¿Hay alguien que, de verdad, haya sacado partido de este tipo de análisis? (Mañas, tú no vales que ya sabemos qué partido sacas de todo esto).

Algo similar pasa a menudo en el mundo de las TI y afecta considerablemente a la seguridad de la información.

Cada producto que utilizamos: dispositivos de red, equipos, sistemas operativos, herramientas, software base, aplicaciones, etc. requiere de un conocimiento que supera el simple montaje o uso de la interfaz de administración.

Por ejemplo, para gestionar un cortafuegos es necesario conocer cómo funciona la interfaz, qué conceptos se manejan (objetos, reglas, NAT, etc.) pero también es necesario conocer cómo usarlo, qué configurar, disponer de un criterio de configuración y de monitorización.

Lamentablemente, muchos cursos y manuales están enfocados a contar las opciones de los menús de la interfaz o las variables del fichero de configuración pero no enfocadas a definir y enseñar los criterios que deben seguirse para poner el producto en producción ni la estrategia de operación del mismo.

De hecho, mucha gente relaciona el saber de un producto o tecnología en conseguir instalarlo y echarlo a andar o en saberse determinadas opciones de los menús, cuando realmente no saben como instalarlo bien o como configurarlo adecuadamente. Y lo contrario, viene a ser cierto a veces también. El que sabe configurar Cisco, Juniper y CheckPoint pero te dice que sólo esos, que no otro producto de cortafuegos.

Bueno, no sé si me estoy explicando con esto pero, en esencia, lo que quiero decir es que hay una parte de estrategia en todos los productos y que cada uno requiere un estudio de la situación y de para qué quieres usarlo y requiere lectura de documentación, libros, presentaciones, etc. para comprender cuándo usarlo y cómo. De hecho, la mayor parte de las veces, la estrategia es independiente de los productos, por lo que si la conoces bien, puedes utilizar cualquiera con una pequeña curva de aprendizaje, ya que todos te deben permitir implementarla de una forma u otra.

El ejemplo del cortafuegos es bueno porque, pese a ser teóricamente sencillo, luego es difícil ver uno bien gestionado y configurado. Pero hay muchos más. De hecho, como decía arriba, cualquier producto que pongas en producción tiene un conjunto de consideraciones que hay que tomar y, normalmente, no ‘funciona sólo’ como te dicen los vendedores.

Y en algunos casos es hasta comprensible porque es difícil encontrar donde te cuenten la mejor forma de actuar, por ejemplo, gestión de logs, pero otros no tienen perdón.

A veces, cada uno tiene que encontrar el modo que le funciona para que lo que hace sea perdurable, sea mantenible, sea legible y sea seguro. Y eso requiere cierto esfuerzo que luego se ve recompensado.

Lo que no debemos hacer es dejar que esto pase, cosas medio configuradas, nada de estrategia, no conocer cómo monitorizar, etc. porque al final, tarde o temprano, ya sea por seguridad o por operativa, se acaba pagando el pato.

¿Y qué pasa? Pues pasa que no se atreve nadie a actualizar nada, ni a migrar nada, ni a tocar nada  y, cuando falla, nadie saber por qué y que cualquier cambio se convierte en un exorcismo.

En fin, creo que ha quedado más o menos claro lo que quería decir con eso, os dejo para que penséis si lo que hacéis es jugar al ajedrez o sólo mover las piezas…

Con el nombre de Zenguridad (suena mal pero la imaginación no me da para más) intentaré iniciar un conjunto de artículos enfocados en aplicar el Budismo Zen en la seguridad en particular y las TI en general. Por favor, perdonad cualquier imprecisión que pueda cometer respecto al Budismo Zen ya que no soy experto en la materia y, probablemente, lo esté pervirtiendo para mis propios fines.

El Budismo Zen está enfocado en simplificar, actuar y evitar los bloqueos debidos a la super-racionalización de los procesos naturales. Algo que nos sonará a los que trabajemos en seguridad en los entornos de TI actuales.

Para empezar, veamos el concepto de Tao. Una de las máximas del Budismo es que no hay dualidad, todo es una única cosa o, más bien, ninguna cosa (por lo que suelen denorminarlo el Vacío). El Tao va en contra de la división y la separación mediante conceptos.

Es curioso que la mayor parte de los estándares, metodologías y legislaciones se empeñan en comenzar siempre precisamente haciendo una división y categorización que no siempre se adapta a la realidad cambiante y continua de los sistemas de información y de la propia información.

Esto supone unos quebraderos de cabeza grandísimos en determinar qué es un sistema, qué es un fichero, dónde están los límites, etc. que rozan la misma metafísica y que requieren un esfuerzo en tiempo y recursos para que, al poco, se queden obsoletos debido al estado de cambio continuo.

¿Habéis intentado implantar el ENS? ¿Hacer análisis de riesgos con MAGERIT? ¿Habéis intentado identificar qué ficheros de carácter personal hay en vuestra organización?

Realmente todo está relacionado (es una misma cosa). Hacer divisiones, en el caso de la seguridad, sólo nos sirve para creer que hay cierto aislamiento entre sistemas, cuando eso normalmente no es cierto. Si bien puede ayudar a la hora de planificar o de hacerse una idea de la arquitectura no se debe pensar que se trata efectivamente de ‘cosas distintas’ porque, al final, todo es el Tao.

Esto se descubre amargamente cuando te hacen un análisis de seguridad (test de penetración) y, a través de un sistema poco importante, se pueden explotar otros sistemas aparentemente no relacionados. Y es que, a un externo a la organización, poco le importan las divisiones que tú hayas hecho en tu documentación.

En el Budismo Zen, el Universo no está formado por la adición de múltiples elementos sino que es una única cosa que ‘va creciendo’. ¿No os resulta familiar? En los entornos de TI la proliferación de máquinas virtuales, sistemas, bases de datos, relaciones, reglas de acceso, etc. se parece más a un continuo que va creciendo que a un conjunto de elementos independientes que juntos forman sistemas de información independientes.

Os dejo con esta reflexión y espero que os guste esta ‘sección’ y que sirva para que entendamos mejor este mundo que intentamos hacer más complicado de lo que realmente es. En próximas entregas seguiremos investigando otros conceptos extraídos del Budismo Zen, su relación con la seguridad y resultados prácticos derivados.

Actualmente sólo anuncian que admiten ISO 14000 e ISO 9000 pero seguro que no le hacen asco a otras certificaciones igualmente inútiles como la ISO 27000 o la ISO 20000.

He aquí una foto del contenedor para que no tengáis dudas, a ver si lo vais a echar a reciclar y los folios reciclados que surjan no quiero ni pensar lo que puede pasarle a quién los use.

Podéis echar documentos, libros, soportes informáticos, carteles, propaganda, etc.

Desde aquí felicitamos a esta genial iniciativa que esperemos que nos ayude a salir de la crisis haciendo que la gente se centre en hacer las cosas y no en engañar a auditores.

Por otro lado, quizá como un vestigio de la era pre-redes sociales, todavía siguen existiendo formularios de ‘envía a un amigo‘ en muchas páginas.

Quiero compartir aquí algunas experiencias con estos formularios que, si no se hacen bien, pueden presentar ciertos riesgos.

El principal riesgo es la posibilidad de envío de correos desde las redes y servidores del afectado de forma automatizada hacia direcciones de correo arbitrarias. Otro riesgo consiste en saturar los destinatarios internos con múltiples consultas a través de estos formularios.

En el primer caso, se puede utilizar para realizar ataques de phishing, con la ventaja de que realmente los mensajes salen de un servidor ‘confiable’.

Veamos algunos errores a la hora de diseñar estos aparentemente inofensivos formularios.

No hay CAPTCHA

Si no hay CAPTCHA o algún mecanismo que limite el uso automatizado, podemos encontrarnos con las situaciones arriba descritas de saturación de buzones internos o, en el caso de que el formulario lo permitiese, envío automatizado de mensajes.

Muchos formularios no lo incluyen porque es un coñazo para el usuario descifrar el CAPTCHA, que cada vez lo ponen más difícil.

El CAPTCHA es repetible

Hay veces, que ya me he encontrado más de una, en las que el CAPTCHA es ‘repetible’. O sea, que el sistema te permite re-utilizar los mismos datos. Normalmente suele ir asociado a que almacenan un hash de la solución en el HTML. Esto es claramente inefectivo y se puede automatizar muy fácilmente.

Nunca se debe confiar en lo que envías al navegador. Siempre tiene que haber algún chequeo en la parte del servidor.

El destinatario puede elegirse

En en caso de ‘enviar a un amigo’, el destinatario puede elegirse y, el problema recae en hasta qué punto es posible manipular el contenido.

En el caso de un formulario de contacto, ya he visto varios en los que puedes elegir al destinatario porque se codifica en campos hidden del HTML.

Se pueden elegir múltiples destinatarios

En algunos casos es posible separar por puntos y coma varios destinatarios, lo que hace que aumentemos nuestros poderes de Spammers. Imaginaos que se puede enviar hasta 50 direcciones… pues os hacéis una idea del peligro, ¿no?

El servidor envía un mensaje automático al remitente

Hay veces que el servidor envía un mensaje automático al supuesto remitente. Como ahí puedes poner cualquier dirección ‘origen’, el resultado es que realmente le estás enviando un mensaje a quién tú quieras.

El contenido puede manipularse

Este es interesante en los formularios de ‘enviar a un amigo’ es importante asegurar que el remitente no puede controlar el texto a enviar. Por ejemplo, me he encontrado formularios que deja poner la dirección de correo origen y el nombre del remitente y lo mismo para el destinatario. En este caso, si no se limita el tamaño del nombre ni se filtra (véase el siguiente epígrafe) resulta que es posible insertar un texto considerable e incluso HTML.

Igualmente, he visto casos en los que el texto estaba en un campo hidden del formulario.

En los casos de formulario de contacto está claro que el contenido debe poder ser manipulado por el usuario, pero hay que tener cuidado en evitar que pueda modificarse el título del mensaje, por ejemplo. En muchos casos, se mete como un campo hidden en el código, por lo que mejoraría nuestra capacidad para crear mensajes falsos.

Se puede modificar el enlace a la página

A veces para el formulario es importante la página origen. Por supuesto en ‘enviar a un amigo’ lo es. En el contacto, puede serlo si se trata de alguna notificación respecto a la página.

En este caso, suele ocurrir que la página se envía en un campo adicional o se toma del Referer y en ambos casos, se puede manipular.

Si se trata de una URL completa, tenemos suerte y podemos sustituirla por otra.

Si se trata de una URL relativa, dependerá de si somos capaces de insertar o no HTML para añadir nuestro propio enlace (véase el siguiente epígrafe).

El contenido no se filtra

Si no se filtra el contenido (aunque sea el nombre del usuario, el enlace, el propio mensaje, etc.) nos encontramos con la posibilidad de introducir código HTML o incluso javascript.

El éxito dependerá de cómo lea el correo el destinatario. Si lo hace en el navegador con un sitio web no muy cuidadoso (o sea, no con Gmail) podemos tener suerte. No he probado demasiados sitios pero los que utilizan un servicio web propio suelen ser más laxos en este sentido.

Si controlamos el HTML podemos meter imágenes, iframes, enlaces, código para lanzar acciones cuando el usuario pase por encima, etc.

Se pueden enviar mensajes a usuarios internos

Una gracia de seleccionar la dirección de correo es que el que la resuelve es el servidor de aplicación. Por lo tanto, se puede intentar enviar correo a usuarios locales o a listas internas.

Por ejemplo root@localhost.localdomain me ha colado alguna vez. Y si conseguimos llenar el disco a base de mensajes…

No se monitorizan los mensajes

Los mensajes que envía el servidor de la aplicación no se monitorizan de forma habitual. Suele ocurrir que si alguien aprovecha estos inofensivos formularios para enviar Spam no se da cuenta nadie. A menos que los Spammers sean tan poco cuidadosos de no dejar de mandar mensajes a saco, en cuyo caso ya saltará alguna alerta de uso de la red o alguien avisará de que está recibiendo Spam o los meterán en algunas listas negras.

Pero en definitiva, no hay monitorización que permita detectar esto pronto.

Almacenamiento online del mensaje

Lo peor que he visto ha sido un formulario de contacto que no enviaba un correo, sino que guardaba el mensaje “sin filtrar” en una base de datos Notes (sí, no es broma) a la que podías acceder siempre que quieras con el identificador correspondiente y además, enviaba un mensaje al emisor.

Así que tenemos XSS almacenado más mensaje de la fuente fidedigna al usuario para que se lo crea del todo.

Sin palabras.

Concluyendo

Pensándolo bien, lo mejor es no tener ninguno de esos formularios. Para compartir, añadid los típicos botoncicos de las redes sociales y listo.

Y para contactar con la organización pues casi mejor el mailto: o también a través de las redes sociales. Todo lo demás es meterse en problemas y, por otro lado, molestar al usuario con CAPTCHAs.

Ah, por último, yo para hacer pruebas de estas cosas siempre uso Mailinator, un servicio que te permite usar cualquier cuenta de correo que se te ocurra (siempre con sus dominios) sin necesidad de registro ni de nada. Muy útil para registrarse en sitios y que no te manden publicidad y también para hacer pruebas de envíos de mensajes.