domingo, 14 de noviembre de 2010

la especificación de las cookies


A cuento del post de hace un mes y algo sobre las cookies y sus tamaños, os dejo un post rapidito para mencionar un artículo muy bueno sobre las debilidades en la especificación de las cookies HTTP, en el blog de lcamtuf.

Nos cuenta sobre los orígenes de las cookies, de sus flags más conocidos, y una serie de problemillas de seguridad muy interesantes que surgen debido a la forma en que se especificó su uso. Para no perdérselo.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS o seguirlo en Twitter...

jueves, 28 de octubre de 2010

En Twitter


Para el que lo prefiera, se puede seguir el contenido de este blog por Twitter. Hice una cuenta para el blog hace como un siglo, y ya iba siendo hora de usarla. Hoy día lo utiliza todo el mundo, y parece un tanto estúpido no emplear también esta forma de difusión. En informysegurata.

El acceso, por cierto, está restringido, lo digo para que no se sorprenda nadie. Se acepta a todo el mundo, por supuesto, pero como no espero un volumen exagerado de gente apuntada (seguro que somos dos y el de la guitarra), pues me gustaría saber cuándo se ha apuntado alguien nuevo, y dedicarle un poco de atención :) . .

Slds!

Actualización 2011/03/14: después de usarlo una temporada, lo de restringirlo parece una bobada, así que lo dejo abierto :)


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

sábado, 23 de octubre de 2010

Sensibles con la protección de datos


Le contaba ayer a un amigo: tengo que preparar material sobre sensibilización en protección de datos personales, para un proyecto en el que estoy trabajando ahora. Su respuesta fue desmoralizante:

"¿La ley de protección de datos?. ¡Vaya puta MIERDA!. A mi empresa vino un consultor a contarnos de qué iba, y le despaché en dos minutos, que sí, que los ficheros blablabla... ¿pero qué va a pasar, a ver?. Qué un hacker se va a colar... ¿para llevarse qué?. ¡Es un puto ordenador tío!. ¿Sabes para lo que sirve?. Para que no pueda coger los curriculums de la peña que viene a dejarlos, fíjate, si me dejan un curriculum y se queda por ahí, ¡multa de 60.000 euros!. Así que le digo: lo siento, tu curriculum va a ir inmediatamente a la destructora de papel, sí, posiblemente necesite gente, y puede que hasta sirvieras, ¡pero la LOPD manda!. Y las cosas que me dicen que ponga... le voy a decir a uno de mis curritos: 'la nueva contraseña del ordenador es b@$t8?op5d!. Y no te preocupes en recordarla, que el mes que viene te la voy a cambiar'. Así seguro que me la dejan en un posit, ya ves. Pero si es que no lo entiendo, es muy fácil hoy día conseguir todo tipo de información de cualquiera, seguro que si pongo tu nombre en el Google encuentro tu dirección, por ejemplo, y si no, pues podré tirar de tus contactos de feisbuk, o del tuenti, da igual todo el mundo lo deja todo por ahí. ¿Y me tengo que preocupar yo?".

En fin, la verdad es que me dio ideas por un tubo. Desde luego estaba sensibilizado, pero no de la manera que me gustaría. A ver cómo le explico que la protección de datos personales estaba ya recogida en el artículo 18.4 de la Constitución Española: "La Ley limitará el uso de la informática para garantizar el honor y la intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos".

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

martes, 14 de septiembre de 2010

cookies y sus tamaños


Hoy que me han dejado algo de tiempo para leer y ponerme al día, he estado leyendo entre otras cosas, este magnífico paper de la presentación de Robert Hansen y Josh Sokol en Blackhat, sobre cómo HTTPS no es bastante para garantizar la confidencialidad de la información de un sitio web. En el paper, y después en este post, se menciona un detalle que llama la atención: es posible hacer una denegación de servicio, no a un sitio web entero, sino a una porción del mismo nada más.

¿Cómo?. Inyectando una cookie demasiado grande en el navegador del usuario. En el caso de que un sitio web reciba una cookie demasiado grande... ¿qué puede pasar?. Algunas opciones posibles para que se dé este DoS son:
  • el valor de la cookie malformada, una vez recibido por el servidor de web, es almacenada en una o más variables en el aplicativo web correspondiente. Podría darse el caso de que esta variable tenga un límite de tamaño, y por tanto que fuera posible realizar un overflow. Y por tanto, ser posible una denegación de servicio. Esta posibilidad depende, por supuesto, de cómo se haga la gestión de memoria a nivel de sistema y en el entorno de ejecución correspondiente. Aquí va un ejemplo (extraído de la guía Owasp Testing) , en que se usa esta posibilidad sobre un aplicativo web CGI (o sea, tecnológicamente más viejo que la tos)
  • en tecnologías más modernas, podría ocurrir que la cookie de marras, al tener un valor malformado, no fuera tratada adecuadamente por la lógica del programa y se disparara una excepción no controlada (el resto os lo podéis imaginar)
  • el servidor de web recibe una petición HTTP más grande de lo que puede tratar, y la rechaza
El tercer punto es el más curioso: ¿cuál es el tamaño máximo de una petición HTTP?. Se configura en cada servidor de web. IIS 6.0 tiene un valor predeterminado de 16 KB, de acuerdo a este artículo de la web de Symantec. Para aplicaciones ASP.NET, parece que es 4MB (es el valor por defecto del parámetro httpruntimesection.maxrequestlength). Apache Tomcat 5.5 tiene un valor por defecto de 4 KB, 8 KB en Tomcat 6.0, según su documentación (véase parámetro maxHttpHeaderSize). Y es diferente para otros servidores (me gustaría tener una lista más completa, pero no tengo más tiempo para hacerla, por desgracia).

La idea, entonces, es inyectar una cookie en el navegador del usuario (con un xss, por ejemplo), lo suficientemente grande como para que se rechace la petición HTTP, asignándole como ruta una parte determinada del sitio web atacado (/logout.aspx, por ejemplo). ¿Cuál es el tamaño máximo que puede tener una cookie, en un navegador web?. ¿Cuántas cookies puedo tener por dominio?. El RFC 2965 dice que un navegador debería ("should") permitir al menos 20 cookies por dominio, con un tamaño máximo garantizado para cada una de 4 KB al menos. Internet Explorer parece que cumple de sobra, de acuerdo a este post de IEBlog de 2007.

Con lo cual, pues parece que este tipo de DoS es perfectamente posible, aunque cantará muchísimo en los logs del servidor de web, proxies, IDS, etc. No he contado nada que no se supiera ya, pero espero que la información de este post sirva: yo mismo no me sabía los detalles de los tamaños, etc, y me ha costado lo mío buscarlos. Cualquier aportación (particularmente si hay erratas), es bienvenida. Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

viernes, 27 de agosto de 2010

sdl cc


Esta es una noticia para resaltar: Microsoft cambiará el modelo de licenciamiento de su SDL, que ahora tendrá una licencia Creative Commons. Este cambio permite a todas aquellas organizaciones que deseen implantar su propia metodología de desarrollo seguro, utilizar como base (de forma legal) la información que Microsoft acoja a esta licencia. De acuerdo al blog "The Security Development Lifecycle", será bastante.

Otros modelos y guías a seguir son (no necesariamente libres o gratuitos):
Si algún otro te parece interesante, no dejes de escribir un comentario :) .


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 12 de agosto de 2010

el osvdb de la nube


Para informarnos a todos un poco más sobre el Cloud Computing, tenemos ahora un nuevo recurso: cloutage.org. Este sitio web, nacido de la mano de los creadores de OSVDB, recopilará información y recursos adicionales sobre este tema tan de moda en el último año y medio (por lo menos), y que tanta confusión ha generado.

Entre la información que podremos encontrar, hay (o habrá) una base de datos de incidentes de seguridad, relativos a la nube. Lo que ya tenían en OSVDB, orientado a aplicaciones, servidores, etc, pero ahora orientado a los servicios en la nube. Nos lo cuentan en su propio blog.

Nos contarán además sus propias experiencias, ya que sus propios servicios estarán basados en la nube.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 10 de junio de 2010

I like it


Me ha gustado este ejemplo, publicado hace unos días en el diario de SANS sobre Clickjacking.

El Clickjacking es una técnica cuyo objetivo es engañar al usuario, haciéndole creer que pulsa en un determinado enlace, cuando en realidad está utilizando otro completamente diferente. En este caso, una página maliciosa usa esta técnica para agregarse a un sitio determinado al feisbuk del usuario, mediante el plugin "Like". Para ello, se situa mediante javascript un iframe completamente invisible por encima del enlace de la página legítima, y que contiene un enlace apuntando al plugin "Like" de Facebook con la url del site malicioso como parámetro. A continuación el usuario pincha en el enlace que ve, o eso cree, porque en realidad lo hace en el enlace malicioso que tenemos en el frame oculto... Lo cuenta también Social Hacking en More recent problems in Facebook platform, así como SpamLoco, Sophos, el CCN-Cert...

Buscando medidas de defensa contra este problema, veo que se proponen medidas de frame-busting (código javascript escrito en nuestra página, con el fin de evitar que esta pueda ser colocada en un iframe), así como el uso de una cabecera no-estándar, X-FRAME-OPTIONS, que propuso Microsoft como una de las medidas de seguridad de IE8. Podemos encontrar esto en la web de Owasp, aunque me parece un resumen escaso, porque no explica bien estas dos medidas.

Este paper de la universidad de Stanford detalla muchísimo mejor un buen número de medidas de frame-busting propuestas, cómo un atacante podría saltarselas, y cuál es la forma que los autores recomiendan. Habla también de X-FRAME-OPTIONS. Además, también se mencionan algunas medidas de defensa a nivel de navegador, que es útil conocer (al final del doc, son sólo un par de líneas). Me llama la atención el que algunas medidas de seguridad, como el filtro anti-XSS de IE8, o el atributo "sandbox" de la etiqueta iframe en Html5, pueden ser usadas para cargarse precisamente la medida de frame-busting, puesta también por seguridad.

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 29 de marzo de 2010

ESSoS y otros


Ha pasado mucho mucho tiempo desde la última vez que escribí algo en el blog (la carga de trabajo no lo permite), y en estos días ha habido muchísimas cosas interesantes en el mundo de la seguridad informática que valía la pena reflexionar y contar. He perdido algunos eventos buenos, como la RootedCon, que al parecer ha sido todo un éxito (¡felicidades a los organizadores!), algunos noticiones como los relacionados con la red Mariposa y cómo ha sido distribuido el malware que la hace posible, o el advenimiento del esquema nacional de seguridad (en Seguridad y Gestión le dieron una vuelta al tema).

Para volver a la carga en el blog, hoy he leído la noticia de una nueva conferencia de seguridad informática: ESSoS estará dedicada al desarrollo seguro, acaba de lanzar su call-for-papers, y se celebrará en Madrid en Febrero 2011. Para no perdérselo.

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

jueves, 4 de febrero de 2010

Guías rápidas de seguridad web de Microsoft


El sitio Microsoft Security Development Lifecycle presentó hace unos cuantos días unas nuevas guías para explicar los principales ataques de seguridad en web, según puede leerse en el blog de SDL.

Estas están diseñadas para aquél que no tiene idea sobre en qué consiste el ataque, como de grave podría llegar a ser, para qué podría ser utilizado, etc, y ofrece una visión diferente sobre el ataque descrito, en función del rol que desempeñe la persona que lo lea: desarrollador, arquitecto de software, tester, así como perfiles más gerenciales (denominados "Bussiness decision makers"). Se centra en tecnologías Microsoft, claro está, para ofrecer posibles soluciones y ejemplos.

De momento, tenemos dos: para prevenir problemas de XSS, y para prevenir problemas de inyección SQL. Me ha gustado el enfoque :)

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

martes, 26 de enero de 2010

Guía del Cloud Computing


Si hace unos meses mencionaba en este blog los recursos de NIST para informarse acerca del Cloud Computing, ahora tenemos algo mejor: el Cloud Computing Security Alliance presentó no hace mucho tiempo la versión dos de su guía sobre Cloud Computing (lo cuentan en Segu-Info, a través de los cuales me he enterado).

Esta contiene, además de la definición del término "Cloud Computing", el conjunto de áreas críticas a las que prestar atención en lo relevante a la implantación de servicios de cloud computing o la contratación de los mismos, bien descritas, con sus listas de consejos y buenas prácticas, etc.

Tenemos la traducción al castellano gracias a ISMS Forum Spain, que nos lo irá presentando poco a poco (el enlace es un resumen ejecutivo, según puede leerse en el propio documento).

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

viernes, 22 de enero de 2010

Las 10 mejores técnicas de hacking web 2009


Jeremiah Grossman publica, desde 2006, un listado con las mejores técnicas de hacking en aplicaciones y servicios web que han aparecido el año anterior. Acaba de presentar la de este año: Top Ten web hacking techniques of 2009 (Official), elegida por algunos de los mejores expertos en seguridad (web) que podemos encontrar a escala internacional: el propio Jeremiah, Rich Mogull, Dinis Cruz, Chris Hoff, HD Moore, Billy Rios, Dan Kaminsky, Steven Christey, Jeff Forristal, Michal Zalewski, y Romain Gaucher.

La producción o innovación de nuevas técnicas en el año pasado ha sido bastante elevada, con un registro de hasta 82 nuevos ataques presentados en foros, conferencias, revistas, blogs, etc, con lo que lo han tenido difícil para elegir. Se puede consultar el top ten en el blog del propio Jeremiah.

Yo, personalmente, me quedo con estas, no por seguir orden particular, temática concreta, o hacer mi propio top ten, sino sencillamente porque me llaman la atención (advierto que no he podido leer detenidamente más que unos cuántos ataques de la lista de Jeremiah):

Slds!


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 11 de enero de 2010

domingo, 3 de enero de 2010

WASC Classification v2


Acaba de salir la versión 2 del diccionario de amenazas web de WASC, una clasificación de los distintos tipos de vulnerabilidades web que podemos encontrar, clasificadas según los ataques que se realizan, y las debilidades que permiten que estos ataques funcionen. La lista ha quedado de la siguiente manera:

Attacks Weaknesses
Abuse of Functionality Application Misconfiguration
Brute Force Directory Indexing
Buffer Overflow Improper Filesystem Permissions
Content Spoofing Improper Input Handling
Credential/Session Prediction

Improper Output Handling

Cross-Site Scripting Information Leakage
Cross-Site Request Forgery

Insecure Indexing

Denial of Service Insufficient Anti-automation
Fingerprinting Insufficient Authentication
Format String Insufficient Authorization
HTTP Response Smuggling Insufficient Password Recovery
HTTP Response Splitting Insufficient Process Validation
HTTP Request Smuggling Insufficient Session Expiration
HTTP Request Splitting Insufficient Transport Layer Protection
Integer Overflows Server Misconfiguration
LDAP Injection
Mail Command Injection
Null Byte Injection
OS Commanding

Path Traversal
Predictable Resource Location
Remote File Inclusion (RFI)
Routing Detour
Session Fixation
SOAP Array Abuse
SSI Injection
SQL Injection
URL Redirector Abuse
XPath Injection
XML Attribute Blowup
XML External Entities
XML Entity Expansion
XML Injection
XQuery Injection

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...