Nuevos IM-Services en SbD.bot

Ya hace tiempo que lanzamos nuestro sbd.bot como idea revolucionaria frente a los omniscientes widgets-web. Hoy toca anunciar nuevos servicios que hemos añadido a nuestro bot.

Los servicios, están implementados en forma de comandos que puedes escribir directamente al bot.

• genpass: En muchas ocasiones necesitamos crear una contraseña; porque nos estamos dando de alta en algún servicio web, alguna aplicación o similar. Este comando permite crear una contraseña aleatoria de 8 caracteres con cierta complejidad: mayúsculas, minúsculas y números.

genpass

sbd.bot: La password generada es: mh8hraQq

• additem: Siempre viene bien tener la posibilidad de 'apuntar' datos y poder tenerlos de forma online disponibles siempre a mano e incluso entre diferentes ubicaciones. Con este comando puedes almacenar información en el bot que podrás recuperar desde cualquier otro sitio. Puede ser útil para guardar una dirección web, un e-mail o simplemente una anotación. La información permanece almacenada en una base de datos cifrada con RC4, no es muy recomendable guardar contraseñas en un servicio online, pero de hacerlo, al menos puedes tener la seguridad que no acaban en texto-plano. El comando admite dos parámetros: un nombre identificativo para ese ítem y la información. El nombre ha de ser una palabra y el texto admite frases completas
  

additem CorreoLuis luis.garcia@sudominio.com

sbd.bot: Item correoluis creada en tu BD

• delitem: Es el comando opuesto al anterior, permite eliminar de tu base de datos un registro, para ello has de invocar el comando con el nombre del registro

delitem correoluis

sbd.bot: Registro correoluis borrado

• listaitem: El comando que permite leer los registros que tengas almacenados en tu base de datos

listaitem

sbd.bot: Nombre descriptivo: sbd Texto: http://www.securitybydefault.com

Nombre descriptivo: mirarluego Texto: http://www.unaweb.com

Nombre descriptivo: comprar Texto: varias unidades de disco, tres monitores y una impresora

Nombre descriptivo: tareaspendientes Texto: resolver incidencia con el firewall, terminar aplicación

Esperamos que estos nuevos IM-Services sean útiles y les saquéis mucho rendimiento. Seguimos abiertos a sugerencias interesantes

Leer más...

Seguridad práctica en Unix e Internet (Libro)

Después de haber recomendado otros libros de publicación mas o menos reciente, hoy toca un clásico entre los clásicos: Seguridad Práctica en Unix e Internet.

Desde mi punto de vista, este libro debería estar en el curriculum escolar de cualquier programa universitario que contemple algo, no ya de seguridad, de informática a nivel avanzado. Tal vez, leído por alguien recién llegado, le pueda parecer que la temática esta obsoleta: RPC, NIS, herramientas que aparecen en packetstorm, casi casi, catalogadas como históricas... Pero lo cierto es que la esencia del libro permanece vigente al 100%.

La forma en la que enfoca preceptos básicos como la responsabilidad del usuario, monitorizar el sistema, tener una idea clara de cual es la estrategia adecuada en materia de seguridad y como la vas a implementar, son ideas fácilmente transportables al 2008.

Además la forma en la que explica conceptos criptográficos de una forma muy pragmática sirven y mucho como genial iniciación al tema.

En definitiva, un libro que tal vez necesite una dosis extra de cariño para leerlo, pero que su valor formativo es inconmensurable.

Lo podéis encontrar aquí

Leer más...

Protección de aplicaciones web mediante WAF (Web Application Firewalls) - Episodio II

Por no hacer excesivamente ardua la lectura del análisis sobre los mecanismos que implementan los cortafuegos de aplicaciones web, decidí publicarlo en varias entregas. Así que aquí vamos con la parte que os debía.

Al hilo de lo que detallábamos en el post sobre los Modelos de Seguridad Positiva vs. Seguridad Negativa, los diversos motores de un WAF responden a estos mismos criterios. Así, podemos permitir todo el tráfico entrante excepto aquel que nosotros consideramos un ataque (modelo de seguridad negativa), o podemos definir que todo tipo del tráfico web está prohibido excepto aquel que nosotros permitamos expresamente (modelo de seguridad positiva).

De esta manera, los motores basados en lista negra o en lista ponderada podrían encuadrarse en el modelo de seguridad negativa, y los análisis basados en lista blanca pertenecerían indudablemente al modelo de seguridad positiva.

Las diferentes comprobaciones que los WAFs efectúan son las siguientes:

* Normalización de URL (modelo de seguridad positiva): controlar el tamaño de los nombres y de los valores de los parámetros y de las cabeceras, de manera que no excedan lo permitido en la RFC de HTTP. Permitir los métodos HTTP estándar (GET y POST) y prohibir los extendidos (HEAD, OPTIONS, métodos WebDav, etc...). Eliminar los diferentes posibles Encodings o Decodings de los parámetros (mecanismos de evasión ante IPS o WAF). Deshacer los posibles intentos de Directory Traversal eliminando las repeticiones de "..\..\", etc,...

* Lista Negra (Modelo de Seguridad Negativa): Si la petición llega siendo "sana", enfrentamos la petición contra una serie de expresiones regulares referidas a ataques conocidos contra aplicaciones comunes (OWA, Lotus Notes, SAP, Horde, etc,... ) de manera que si en algún caso hacen "pattern matching" contra alguna expresión de la lista se denegará dicha petición. Esto puede generar gran cantidad de falsos positivos debido a que aplicaciones que puede que no sean vulnerables al ataque de la lista pero que coincidan con una expresión regular, provoquen una denegación de servicio. Asimismo, las listas negras no son un mecanismo óptimo para detener ataques del tipo SQL injection, XSS (Cross-Site Scripting), command injection. Un ejemplo muy claro de esta limitación sería por ejemplo un parámetro en una GET de la manera "index.php&action=drop". En esta situación, una lista negra excesivamente estricta provocaría un bloqueo puesto que "drop" puede conllevar el borrado de una tabla de una base de datos, por lo que debería vetar el acceso.

* Lista Ponderada (o Scoring List): Este mecanismo de análisis de tráfico funciona de manera similar a un antispam. Pertenece al modelo de seguridad negativa. Asigna pesos a aquellas porciones de la petición web de manera según tenga definidos en una tabla de scoring. Finalmente si la suma de los diferentes pesos asignados a una petición supera un determinado umbral, la bloquea. En el caso anterior, si suponemos que el umbral de bloqueo es 1, y asignamos 0.30 a la cadena "drop", la dejaría pasar. Sin embargo, en una petición de la forma "index.php&action=';drop * from data;--" al asignar 0,30 a "drop", 0,50 a "*" y 0,30 a "from" y 0,20 a "-", tendríamos 0,3 + 0,5 + 0,3 + 0,2 + 0,2 = 1,5 > 1 por tanto bloquearía el intento de SQL injection. De esta forma tenemos una forma mucho más "inteligente" de bloquear este tipo de ataques. El único WAF que conocemos que incorpore este sistema de análisis es rWeb de DenyAll.

* Lista Blanca (modelo de seguridad positiva): Para determinado tipo de aplicaciones en las que el formato de los parámetros de entrada en las GET o POST no varíe muy a menudo, puede resultar interesante definir dicho formato a nivel de lista blanca, de manera que sólo aquellas peticiones que encajen ante dicha plantilla podrán acceder a la aplicación, denegándose todas las demás opciones.

Y hasta aquí puedo leer esta vez. En la siguiente entrega terminaré de contar otros mecanismos implementados para evitar ataques en aplicaciones web. Asímismo, haré una breve recopilación de los diferentes productos comerciales y libres expuestos en la entrega anterior, indicando las diferencias entre unos y otros.... Y que sea el lector quien elija en qué herramienta quiere confiar la seguridad de sus aplicaciones web (tanto las expuestas a Internet como las aplicaciones internas...no olvidéis que el principio de pareto tiene múltiples ejemplos en la naturaleza)

Leer más...

Hackeos memorables: la-moncloa.es

Estamos hablando del 11 de Agosto de 1999, por aquella época, había una impresionante 'scene' en el submundo de la seguridad informática en España.

El irc era el mecanismo de comunicación que estaba de moda, tanto las redes oficiales como otras muchas redes clandestinas creadas en maquinas que habían sido comprometidas y en las que se había escondido un servidor de IRC.

En ese momento el numero de grupos 'hacktivistas' en activo era bastante considerable, globalmente y particularmente en España.
Por aquella época, si tenias la suficiente paciencia era relativamente sencillo encontrar maquinas que respondían prestas a un comando como 'showmount -e'. El uso de cortafuegos no era para nada tan habitual como lo es ahora, y Windows 98 había asombrado a la gente al mantener uptimes superiores a 24 horas.

En ese momento los organismos oficiales, partidos políticos y muchas organizaciones habían empezado tímidamente a tener presencia en internet y como era de esperar, mucha gente pagó la novatada del primerizo y en esos momentos se pudieron ver 'defaces' por doquier.

La web que nos ocupa hoy es la-moncloa.es que llevaba online desde 1996 como se puede comprobar en archive.org y en 1999 tenia este aspecto.

El 11 de Agosto de 1999 un grupo de hacktivistas llamado Aliance la dejaron tal que así.

Los detalles técnicos del ataque fueron bastante bien explicados en ibrujula. Baste decir como resumen que se trataba de un IIS no parcheado en una época donde los programadores de IIS habrían ganado todos los oros en una competición de malas practicas de programación.

El mensaje que dejaron en la web tenia como premisa rebatir la frase que en aquella época estaba de moda: "España va bien" ¿os suena, verdad?

Leer más...

"Dame 20.000 euros y te cuento más..."

La noticia empezaba en un primer momento bastante impactante, pero al final, lo que ha resultado más impactante es la frase que nuestro protagonista de hoy, el investigador Adam Gowdiak, ha lanzado al mundo y en especial a Nokia y Sun, haciendo referencia a una grave vulnerabilidad que afecta a los teléfonos móviles cuyo sistema operativo sea S40, y que según su entrada en la Wikipedia, afecta a más de 100 millones de dispositivos de dicha marca Nokia. 

"The pricing for the early access to the research material:

    *      early access for employees of one enterprise - 20 000 €"

El 11 de Agosto, en la página TheRegister, podíamos leer un primer análisis de este hecho, en el que se constata que este agujero encontrado en J2ME permitiría a un atacante instalar aplicaciones Java en cualquier aparato antes de que se permitiese a dichas aplicaciones acceder a las funciones del teléfono que deberían asegurarse gracias a su modelo de seguridad. Las aplicaciones son instaladas incluso sin que exista interactuación alguna con el usuario. En resumen, podríamos decir que la vulnerabilidad permitiría que cualquier aplicación Java tendría acceso completo a cualquier funcionalidad del teléfono, a cualquiera.

Lo que más asusta de todo esto, es que cualquier persona con acceso a este fallo, podría hacerse con el control de los teléfonos de la marca y versión descrita que estén a su alcance, y poder manejarlos a su antojo, como si de sistemas zombie se trataran. Mejor no imaginarnos el alcance de todo esto, porque aún sabiendo que la versión del sistema operativo S40 puede parecer algo anticuada, ¿cuantos de nosotros conocemos a gente que únicamente utiliza el teléfono para hacer llamadas y escribir mensajes SMS, y se conforman con su terminal de hace X años, aunque su pantalla tenga sólo dos colores y sus tonos se puedan hacer con un "organillo" Casio?

[+] Lista de teléfonos Nokia de la serie S40

Dejando a un lado la parte técnica de la vulnerabilidad, Adam Gowdiak, como ya comentábamos en la introducción de esta entrada, se compromete a ofrecer absolutamente todos los detalles así como las correspondientes pruebas de concepto a aquel que le pague una cantidad de 20.000€. En la página Web del grupo para el que trabaja, Security Explorations, describe el material que facilitaría en el caso de que alguien le ofrezca el dinero que pide. 

Según informa DiarioTI, Nokia parece que no se ha pronunciado sobre si ha aceptado la propuesta del investigador, pero lo que si parece claro es que gracias a los pequeñísimos detalles que posee sobre estos agujeros, ya está trabajando en una solución.

[+] Fuentes : TheRegister, InfoWorld y DiarioTI

Leer más...

Servidores de RedHat - Fedora comprometidos

Según se ha podido conocer este fin de semana, RedHat ha publicado una nota indicando que ciertos servidores Fedora fueron comprometidos.

Inicialmente se están analizando las causas de las intrusiones y reinstalando las máquinas comprometidas.

Para evitar que en la distribución de contenido de paquetes lícitos por parte de Fedora puedan estar troyanizados (no quiero ni imaginar lo que podría suceder si algo así llegase a pasar, la cantidad de servidores zombies disponibles para atacar cualquier objetivo sería brutal) han facilitado un script para los usuarios de Red Hat. Este script permite verificar si los paquetes openSSH existentes han sido firmados por una clave que se ha calificado como tampered. Asimismo se ha publicado nuevos paquetes openSSH que se ha comprobado que están sanos y se han empaquetado. Se acompañan los paquetes en el enlace de las sumas de verificación para comprobar que los paquetes descargados son lícitos.

Leer más...

Protección de aplicaciones web mediante WAF (Web Application Firewalls) - Episodio I

Mucho se ha hablado en este blog sobre diversos mecanismos de protección de aplicaciones web programadas en PHP, como PHPIDS incluso sobre herramientas relacionadas. Este tipo de aplicaciones que se ejecutan en los propios servidores web proveen de una funcionalidad bastante interesante, desde el punto de vista de la protección de las aplicaciones web ante algunos tipos de ataque de nivel 7 como el que mencionaba Yago en el post de ayer.

Sin embargo, herramientas del tipo PHPIDS o URLScan proveen de protección de forma muy focalizada y dedicada al tipo de lenguaje de programación de las aplicaciones (PHP en caso de PHPIDS) o para el tipo de servidor Web (en el caso de URLScan sólo se integra con Microsoft IIS). No hemos mencionado en este blog aún otras posibilidades como mod_security, herramienta libre que permite integrarse en servidores Apache de forma embebida para proteger las aplicaciones servidas por ellos.

Existe, sin embargo, alternativas que proveen de un nivel de seguridad mucho más genérico ante cualquier tipo de servidor web, y ante cualquier tipo de aplicación, sin importar el lenguaje en el que estén escritas: los WAF o Web Application Firewalls. Este tipo de plataforma se integra dentro de la arquitectura de red de la organización (generalmente en la DMZ) de manera que se altera la ruta del tráfico web (HTTP y/o HTTPS) para que atraviese este dispositivo. En general se trata de una máquina que simula ser, a ojos del cliente final que solicita un recurso web (página o servicio web) el servidor final. En realidad es lo que se denomina Proxy Inverso, puesto que la petición web del cliente es analizada más o menos inteligentemente por el software WAF y, si la considera "sana", genera él una petición contra el servidor Web final (no enrruta el tráfico ni lo NATea, sino que se hacen dos peticiones diferentes, una desde el cliente hasta el WAF y una nueva desde el WAF hasta el servidor web final). Lo que viene siendo un proxy convencional, pero hacia dentro.

Con nombre y apellidos, dentro del mundo libre podemos mencionar como más conocido a mod_security. Aunque antes lo hemos mentado como módulo integrado para Apache, también puede configurarse conjuntamente con mod_proxy, de manera que se realice un análisis con mod_security y se reenvíe la petición al servidor web final que corresponda mediante mod_proxy. Como herramientas comerciales, podemos mencionar a F5 (su módulo ASM para plataformas BIG-IP), rWeb o sProxy de DenyAll, Imperva, IBM DataPower (exclusivamente para servicios Web), Barracuda (que absorbió a NetContinuum), Citrix (después de comprar Teros)

Si bien nos gustaría detallar las capacidades de unos y otros, quizá nos posicionaremos (de momento) de forma más genérica al explicar lo que todos en conjunto son capaces de hacer, indicando las características diferenciadoras entre ellos.

El funcionamiento de un WAF se basa en un proxy inverso, por lo que nos obligará a efectuar cambios en las tablas de DNS o de NAT de los cortafuegos, de manera que el tráfico que antes iba a las granjas de servidores web o de aplicaciones, ahora se direccionará a nuestro nuevo dispositivo. En la configuración del WAF habremos de indicar el servidor correspondiente al que enviamos el tráfico. Se puede virtualizar, de manera que podemos analizar varios dominios o aplicaciones con un único dispositivo, de manera que dependiendo del dominio donde vaya, se reenvíe a un servidor físico u otro. Existen WAFs que permiten interactuar en modo transparente, de manera que no es necesario hacer cambios en la topología de red ni en el flujo del tráfico, tienen como pega ante el WAF basado en proxy inverso que los despliegues requieren una parada de servicio mucho mayor, obligando además a comenzar siendo muy poco restrictivos en la política de seguridad e ir endureciéndola progresivamente, no permitiendo hacer suficientes pruebas iniciales con las aplicaciones en producción desde un primer momento sin correr riesgos como en los basados en proxy inverso.

En líneas generales, las peticiones al servidor web son analizadas por diferentes motores que llevarán a cabo comprobaciones sobre las mismas. Cada motor suele intentar evitar un conjunto de ataques según una determinada filosofía.

Por no hacer tan duro de leer de un solo viaje este análisis sobre los diferentes mecanismos de protección de los WAF, publicaré en una entrega posterior el resto del artículo.

Leer más...