miércoles, 31 de julio de 2013

Crónica del ataque a los foros de Ubuntu

El pasado día 21 de julio Canonical anunciaba la detección de una intrusión en el servidor correspondiente a los foros de la comunidad de Ubuntu (ubuntuforums.org). Los datos sustraídos comprendían las cuentas de correos de los usuarios así como los hashes de las contraseñas de acceso a los foros.

Días después, Canonical, ha publicado un interesante estudio sobre como se efectuó el ataque a sus foros.

ubuntuforums.org usa el software vBulletin para la gestión de los foros. vBulletin está basado en PHP, posee licencia propietaria, y su desarrollo se inició en el año 2000. La última versión publicada data del 25 de mayo de 2012, hace más de un año.

Según parece, el atacante consiguió una cuenta de moderador de los foros y accedió con ella el 14 de julio. Aunque en principio no tienen claro como la obtuvo, los privilegios de esta cuenta permiten a un moderador publicar comunicados (announcements) con contenido HTML sin filtrar, posibilitando que el atacante inyectara código javascript dentro del mismo. Esto convertía la página en una trampa, ya que todo usuario registrado que la visitara ejecutaría el código incrustado en su navegador. Evidentemente la intención era extraer las cookies de sesión de cuentas más privilegiadas.

Publicado el comunicado, el atacante envió un mensaje privado a tres administradores. En dicho mensaje les informaba que se producía un error de servidor en la página de comunicados y les conminaba a  visitar dicha página.

Uno de los administradores visitó la página que el atacante preparó y no observando nada anormal respondió al atacante. Este último ya se habría logueado con la sesión del administrador, al haber sido extraída su cookie de sesión, elevando así sus privilegios en vBulletin.

Ahora con una cuenta de administrador y a través de una funcionalidad propia de vBulletin, el atacante podía ejecutar código PHP. Con esto consiguió subir dos shells en PHP y a través de ellas hizo un volcado de la base de datos (MySQL) asociada a los foros. Posteriormente volvió a loguearse el día 20 de julio para cambiar la página de inicio por un mensaje reivindicando el ataque.

Como podemos observar en este ataque, la elevación de privilegios no es un concepto aislado del sistema operativo, tiene su correspondencia en la web, perfectamente extrapolable. Los administradores de los foros no tienen claro que tipo de código javascript se usó en la página creada por el atacante, esta fue borrada por uno de los administradores.

Aun así, podemos ver aquí el ejemplo perfecto de lo que supone una vulnerabilidad de Cross-site scripting (del tipo permanente). A menudo infravalorada, ya que cuesta demostrar su verdadero impacto y entenderla, este tipo de vulnerabilidad se califica de gravedad alta en las auditorias, mientras que su percepción por parte del personal no relacionado con seguridad es habitualmente menor.

También se evidencia aquí un vector interesante: la ingeniería social. El mensaje convincente de un moderador sobre un tipo de error casual. Este hecho causa un elemento de confianza en el administrador, mientras que el tipo de mensaje, una petición poco sospechosa (¿Quien no ha visto un error HTTP 500 de manera casual?) y que no deriva en ninguna actuación adicional (caso cerrado) hace que el administrador baje la guardia ante un problema que no existe y se olvide pronto de este evento.

El resto del ataque no se diferencia más de otros: subir una shell y el resto es historia.  

Nos queda una pieza para completar el puzzle y es la forma en la que se hizo con la cuenta de moderador (no son empleados, son voluntarios), no se aportan detalles, tan solo, Canonical, afirma no conocer como el atacante consiguió esta cuenta. También destaca el hecho de que el atacante se logueara por primera vez el día 14 de julio y concluyera el ataque el día 20. Una paciencia estratégica.

Más información:

Notice of security breach on Ubuntu Forums site

Ubuntu Forums are back up and a post mortem



David García
Twitter: @dgn1729

martes, 30 de julio de 2013

Fallo en LinkedIn permitía extraer el token de OAuth del usuario autenticado

LinkedIn ha corregido un fallo en su web que permitía extraer el token del protocolo OAuth del usuario autenticado.

El fallo fue reportado por el británico Richard Mitchell y según comenta en su blog se dio cuenta como al acceder al sitio de ayuda de LinkedIn (http://help.linkedin.com) este procedía a autenticar al usuario con su ID de LinkedIn sobre HTTP.

Mitchell se detuvo a observar por curiosidad, a través de las herramientas de desarrollador de Chrome, como se efectuaba el proceso. Encontró que existía un script que efectuaba una petición con la llave API correspondiente al sitio web de ayuda y este respondía con el token OAuth del usuario.

Intentó hacer la misma petición copiando el script en una página local y comprobó que, como era de esperar, que las peticiones eran denegadas desde otro dominio. El problema era que la manera de chequear esto, en primer lugar, se hacía desde el propio script, consultando la variable "window.location.host" y comparándola con un grupo de valores, dominios controlados por LinkedIn: "*.linkedin.com" y "*.custhelp.com". Este primer filtro pudo evadirlo trivialmente sobreescribiendo la función "window.String.prototype.match" para que siempre devolviera "true".

Posteriormente comprobó como la petición volvía a ser denegada por el servidor de LinkedIn, así que verificando que la única diferencia entre una petición desde el navegador (dentro del dominio LinkedIn) y desde su página modificada en local (dominio local) era la cabecera "Referer", procedió a cambiar el HTML local para que su "Referer" no indicara su origen:

    <meta name="referrer" content="never">

De esta forma podía recoger el token OAuth sin que el servidor se percatara del origen de la petición.

El fallo, que ya ha sido corregido, nos muestra doblemente algo que repetimos continuamente: No creas nada que venga del cliente (navegador). Primero por filtrar desde Javascript el dominio desde el cual se está efectuando la petición y segundo por filtrar la petición en el servidor comprobando la cabecera "Referer" del cliente.

Por cierto, Mitchell fue premiado por el reporte de este bug con una camiseta.

Más información:

Stealing OAuth tokens from the LinkedIn API using meta referrer

David García

Twitter: @dgn1729

lunes, 29 de julio de 2013

Boletines de seguridad de Wireshark

Se han publicado las versiones 1.8.9 y 1.10.1 de Wireshark que solucionan 18 vulnerabilidades que pueden provocar denegación de servicio a través de múltiples disectores.

Wireshark es una aplicación de auditoría orientada al análisis de tráfico en redes. Su popularidad es muy elevada, puesto que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark es software libre (sujeto a licencia GPL) y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, así como en Microsoft Windows.

Las vulnerabilidades corregidas pueden ser aprovechadas para provocar una denegación de servicio, bien dejando de funcionar el software, bien consumiendo todos los recursos de la máquina. Los identificadores CVE van desde el CVE-2013-4920 al CVE-2013-4936 y una modificación para el CVE-2013-4083. Los boletines publicados van desde wnpa-sec-2013-41 hasta wnpa-sec-2013-53 y afectan a los disectores PROFINET Real-Time, ASN.1 PER, GSM A Common, DVB-CI, DCOM IsystemActivator, Radiotap, P1 y en Netmon file parser; también se puede provocar un bucle infinito o excesivamente grande en los disectores GSM RR, DIS, Bluetooth OBEX, Bluetooth SDP, DCP ETSI.

Todas las vulnerabilidades podrían ser explotadas a través de la inyección de paquetes en la red, o convenciendo a un usuario para que abriese un fichero de captura de tráfico especialmente manipulado. Las versiones afectadas son la rama 1.8 (1.8.0 a 1.8.8) y la versión 1.10.0.

Disponibles las nuevas versiones para su descarga en:

Más información:

Wireshark 1.10.1 and 1.8.9 Released



Fernando Castillo

domingo, 28 de julio de 2013

Denegación de servicio en el servidor DNS BIND

ISC ha liberado una nueva versión del servidor DNS BIND. Esta versión corrige un error que podría causar una denegación de servicio a través de una consulta especialmente manipulada.

El servidor BIND es uno de los más usados en Internet. Creado en 1988, en la universidad de Berkeley, actualmente es desarrollado por el ISC (Internet System Consortium). BIND tiene licencia BSD y se encuentra disponible para una amplia gama de sistemas tanto Unix como Microsoft Windows.

El fallo, calificado por ISC de crítico (puntuación CVSS de 7.8), permitiría causar una denegación de servicio en el servidor al procesar una consulta manipulada. El error afecta a las versiones de las ramas 9.7, 9.8 y 9.9. ISC avisa en el boletín correspondiente que no se publicará parche para la rama 9.7 debido a que dicha versión ya no está soportada. El fallo no afecta a las versiones 9.6 y la rama más reciente 9.10.

Aunque el boletín no proporciona detalles sobre el problema, las notas de la publicación de la nueva versión hablan de una falta de comprobación en los límites de cierto valor del tipo privado 'keydata'. Un valor inapropiado causaría un fallo de aserción en la macro REQUIRE y la terminación el proceso.

El parche en cuestión se encuentra en el archivo /lib/dns/rdata/generic/keydata_65533.c:

static inline isc_result_t
fromwire_keydata(ARGS_FROMWIRE) {
	isc_region_t sr;

	REQUIRE(type == 65533);

	UNUSED(type);
	UNUSED(rdclass);
	UNUSED(dctx);
	UNUSED(options);

	isc_buffer_activeregion(source, &sr);
-	if (sr.length < 4)
+      if (sr.length < 16)
		return (ISC_R_UNEXPECTEDEND);

	isc_buffer_forward(source, sr.length);
	return (mem_tobuffer(target, sr.base, sr.length));
}

La vulnerabilidad tiene asignado el CVE-2013-4854 y fue reportada por Maxim Shudrak a través del programa de Zero Day Initiative de HP.

Más información:

CVE-2013-4854: A specially crafted query can cause BIND to terminate abnormally



David García
Twitter: @dgn1729

sábado, 27 de julio de 2013

Algunos apuntes sobre la intrusión en los servidores de Apple

El pasado día 20 de julio, algunos de los usuarios de pago del portal de desarrolladores de Apple recibieron un correo en el cual se les pedía que resetearan su contraseña. Poco tiempo antes, en la correspondiente web, Apple colgaba el cartel de mantenimiento sin más información que unas disculpas por la interrupción del servicio. La red se iba llenando de las quejas de los desarrolladores. Aunque los motivos no estaban claros, una web cerrada y un correo del Apple solicitando un reseteo de la contraseña hablaban por si solos: El sitio había sido objeto de una intrusión.

Ibrahim Balic se presenta a si mismo como investigador de seguridad independiente, el cual ha encontrado varios fallos en la red social Facebook (se encuentra listado en los agradecimientos del programa Whitehat bajo el pseudonimo 'CanimAnnem'). Según asegura, ha reportado hasta 13 vulnerabilidades distintas a Apple. Balic declaraba, en un comentario a un post de TechCrunch, que uno de esos fallos reportados a Apple le proporcionaba acceso a información detallada de los usuarios del portal de desarrollo, en concreto, como prueba de concepto, extrajo los detalles de las cuentas de 73 usuarios de pago, algunos de ellos trabajadores de Apple.

El día 21 la propia Apple modificó el mensaje en el portal de desarrolladores, esta vez indicaba que, efectivamente, el motivo del cierre temporal había sido una intrusión. La reacción de Balic, ante esta declaración de Apple, fue la de aclarar públicamente, a través de Twitter, que él era quien estaba detrás del ataque pero que no quería que fuese considerado una acción maliciosa sino producto de su investigación, la cual, además había sido reportada previamente a Apple.

La respuesta de Balic, ante el silencio de Apple y su acusación indirecta, le llevó a dar un paso más, grabando un video del resultado de su investigación. En el video, colgado en YouTube (actualmente borrado por el propio Balic), podía observarse cómo extraía progresivamente la información de las cuentas de los desarrolladores. El problema, desde el punto de vista ético, es que en el video se podía ver claramente datos concretos y personales sobre las cuentas, hecho que fue criticado en las redes sociales. Habitualmente este tipo de información es borrada o disimulada para hacerla ilegible, pero por algún motivo (¿Las prisas por aclarar las acusaciones?) Balic no lo hizo.

Una semana después Apple volvió a abrir el portal de desarrolladores tras parchear la vulnerabilidad y aunque sin respuesta de Apple, el propio Balic continuó su trabajo e incluso volvía a reportar vulnerabilidades (un Cross-site scripting permanente en iTunes Connect).

Hipótesis sobre el fallo de seguridad

El mismo día 22 de julio, un usuario del sitio Hacker News comentaba, presumiblemente tras ver el video, la posibilidad de que la vulnerabilidad podría encontrarse en el framework Struts. Un framework para aplicaciones web basado en Java y desarrollado por la fundación Apache. Java es un lenguaje ampliamente usado por Apple en sus sitios web. El usuario indicaba que la semana anterior un boletín de seguridad crítico describía la posibilidad de ejecutar código remoto a través de OGNL (Object Graph Navigation Library), un lenguaje de expresión usado por Struts para el acceso avanzado a propiedades de objetos Java. Se da la circunstancia de que este mismo usuario de Hacker News declaraba ser anterior colaborador del proyecto Struts y posiblemente el responsable de la vulnerabilidad.

La vulnerabilidad en concreto reside en la clase DefaultActionMapper del paquete org.apache.struts2.dispatcher.mapper. Dicha clase proporciona un método para operar sobre acciones que contengan como prefijo: "action:", "redirect:" y "redirectAction:". El problema es que no efectúa un filtrado adecuado de los valores que son asignados por el cliente. Posteriormente dichos valores son evaluados por el lenguaje de expresión OGNL posibilitando que se ejecute código (Java) malicioso en el servidor.

El fallo, ya corregido, tiene asignado el CVE-2013-2251 y fue reportado por Takeshi Terada de Mitsui Bussan Secure Directions.

Más información:

Hacker News

OGNL

Reporte del fallo en el bugtracker de Struts

Struts 2 Remote Code Execution via OGNL Double Evaluation



David García

Twitter: @dgn1729

viernes, 26 de julio de 2013

Múltiples vulnerabilidades en Cisco Video Surveillance Manager

Cisco ha publicado un aviso de seguridad en el que informa de la existencia de múltiples vulnerabilidades en Cisco Video Surveillance Manager anteriores a 7.0.0 que podrían permitir a un atacante remoto tomar el control de los sistemas afectados.

Cisco Video Surveillance Manager (VSM) permite a gerentes de operaciones e integradores de sistemas montar una red de videovigilancia totalmente personalizada. Proporciona configuración centralizada, gestión, visualización y control de cámaras de vídeo.

Las vulnerabilidades se detallan a continuación:

CVE-2013-3429: Revelación de información sensible a través de una escalada de directorios al no controlar debidamente las entradas de usuario en ciertas páginas.

CVE-2013-3430 y CVE-2013-3431: No se requiere de autenticación para acceder a páginas "sensibles" como configuración, logs del sistema, historiales de monitorización... lo que puede permitir crear, modificar y eliminar cámaras, historiales, logs y usuarios de forma remota y sin necesidad de estar autenticado.

Dichos fallos se han corregido en las versiones Cisco VSM 7.0 y Cisco VSM 7.0.1, ambas disponibles para su descarga en los canales oficiales de Cisco.

Más información:

Multiple Vulnerabilities in the Cisco Video Surveillance Manager


Fernando Castillo

jueves, 25 de julio de 2013

Entrevista a Brian Krebs

Hispasec ha tenido el placer de entrevistar a Brian Krebs (https://twitter.com/briankrebs). Conocido por su etapa anterior como reportero del Washington Post y actualmente por su blog "Krebs on Security", Brian es un referente en cuanto a investigación y análisis de las técnicas y "estado del arte" del mundo del crimen en Internet. En particular destacan su serie sobre Skimmers (técnicas de fraude en cajeros automáticos), pero sobre todo por el detalle con el que destapa y relata los movimientos de auténticos capos y organizaciones criminales que pueblan la red.

https://krebsonsecurity.com/
Os reproducimos la entrevista realizada traducida al español y también el original en inglés para aquellos de nuestros lectores que dominen la lengua inglesa.


Pregunta: Debes de ser una de las personas más odiadas por los criminales de Internet. Has sido amenazado e incluso, hace unos meses te enviaron a casa a los SWAT. Saben dónde vives. Después de ese incidente, ¿crees que merece la pena continuar? Significa que estás haciendo las cosas "bien" o estás molestando a la gente equivocada, ¿Dónde estaría el límite?.

Respuesta: ¿El más odiado, eh?, quizás. Mi objetivo principal es acercar al máximo el cibercrimen haciéndolo comprensible y quizás menos misterioso a los lectores. Hoy en día hay mucho "hype" (exageración, humo) en la información del ámbito de la seguridad, pero pienso que dar pruebas y hechos de primera mano a la gente, más allá del "hype”, nos ayuda a todos  a tomar mejores decisiones sobre cómo debemos protegernos en un entorno online. Respecto a tu pregunta ¡me sentiría ofendido si los criminales no se hubieran percatado! He documentado diferentes pruebas que indican que sí que lo han hecho, la noticia aquí:

P: ¿Creés que más allá de que los criminales te tengan como objetivo o del posible "odio" que te profesen, también hay un cierto respeto?. ¿Es posible que los atacantes te utilicen para difundir sus actividades? ¿Ves esto como un “juego” o realmente como una batalla donde alguien ganará y perderá al final?.

R: Me gusta pensar que -al menos en este área- hay una delgada línea entre el amor y el odio.  Es difícil saber cuánto hay de odio y cuánto de admiración a regañadientes o  agradecimientos. Por ejemplo, mi impresión tras leer diariamente algunos de esos foros criminales, es que un gran número de las personas involucradas en el cibercrimen no tienen una buena opinión de los estadounidenses en general y en particular no les gusta que la gente que ellos creen que no están cualificados critiquen su trabajo. Por otro lado, como se dice en el gremio del periodismo -No existe la "mala prensa"- y muchos de los vendedores de innovadores servicios criminales pueden verlo como publicidad gratuita por parte de un periodista occidental. Si de verdad se enfadan por algo que he escrito, suele ser porque uno de sus "dominios" ha salido a relucir a la atención pública viéndose obligados a moverlos u ocultarlos.

P: Algunas veces, la información que facilitas en tu blog podría ser previamente desconocida, y hacerla pública podría verse como inconveniente, porque las fuerzas de la ley pueden usarla para arrestar gente, por ejemplo. Nos encontramos con el dilema del "full disclosure". ¿Qué piensas al respecto? ¿Sacrificarías una buena historia por una buena causa?

R: Esto es normal y pienso que hay una natural y sana tensión dentro del área de seguridad -- entre recolectar información por cualquier motivo y actuar sobre dicha información. Actuar sobre ella causa casi siempre un inconveniente en alguien más que en los malos, ya sean los investigadores, fuerzas de la ley o empresas de seguridad.

Las fuerzas de la ley tienen un duro trabajo. No solo tienen que saber quiénes son y dónde están los malos y cómo realizaron el crimen con detalle, sino que tienen que tener pruebas. Esto puede parecer obvio e incluso sencillo para el lector ocasional, pero los que están en seguridad pueden atestiguar sin duda que se puede ofrecer lo que podría considerarse un caso criminal en bandeja de plata, solo para luego oír a las autoridades decir que necesitan recolectar la información a su manera y según sus propias normas.

Así que, como muchas veces ocurre, lo que parece una apertura y cierre de un caso bajo el punto de vista de los expertos en seguridad, es un proceso mucho más complicado y laborioso. En cierta manera, así es como debería ser: Por razones de privacidad y desconfianza en general hacia el gobierno, la mayoría de la gente no desea que sus autoridades locales o federales sean demasiado eficientes a menos que, por supuesto, el caso les afecte a ellos directamente.

Pero es cierto que me he encontrado en más de una ocasión con historias que he dado en considerar muy buenas, con un completo conocimiento de que las fuerzas de orden estaban trabajando para llegar a las mismas conclusiones.  Algunas veces una historia que parece lista para salir, se vuelve mejor cuando puedes añadir la perspectiva de una fuente oficial o presuntos implicados. Nunca he considerado esas historias como "sacrificios". Las buenas historias no caducan, incluso el paso del tiempo les sienta bien. De hecho en este momento me enfrento a un caso mientras hablamos, en parte porque el individuo en cuestión es un menor, tengo curiosidad por saber cómo va a resultar.

Pero hablando como periodista, generalmente no retraso o aplazo una historia solo porque pueda resultar inconveniente a las fuerzas de la ley. Haciéndolo ganaría pocos puntos de cara a los investigadores puesto que raras veces parecen querer convertirlo en algo recíproco o entablar un acuerdo de intercambio de información.

P: ¿Qué piensas sobre cooperar con las fuerzas de la ley para intentar detener el crimen de Internet? ¿Tienes buenas relaciones con ellos?

R: Por supuesto, suelo estar en contacto con agentes federales que investigan historias publicadas o casos de fraude sobre los que escribo y buscan más información al respecto.

Nunca revelo las fuentes y métodos con las fuerzas de la ley, pero normalmente no dudo en compartir o responder preguntas directas sobre algo que he escrito, asumiendo que la información no es privilegiada de alguna manera. Pero de nuevo, seria una tontería esperar una actitud recíproca cuando se comparte información: las fuerzas de la ley de  los EE.UU son muy buenas tomando información pero reconocidamente tacaños a la hora  de ofrecer algo útil a cambio. Tengo una relación de "toma y daca" con un puñado de fuentes policiales, pero estos son amigos que han acabado en estos puestos o bien  gente que he ido conociendo desde hace tiempo - son la excepción y no la regla.

P: Cuando necesitas un conocimiento técnico más profundo, ¿a quién acudes?

R: He tenido la suerte como periodista de poder trabajar en el Washington Post, lo cual te abre muchas puertas en la comunidad de la seguridad que quizás de otra manera no se hubieran abierto tan fácil o rápidamente. Dicho esto, me esfuerzo en cuidar las fuentes que no solo tienen un profundo conocimiento de la materia, sino que además disponen de habilidades prácticas, para meterse entre toneladas de datos y encontrar la aguja en el pajar que ayuda a enhebrar el resto de la historia. A menudo, estos no son los mismos que ofrecen las mejores citas en el artículo  (o incluso que tengan permiso para ser citados en un artículo). No podría conseguir la mayoría de mis historias sin la decisiva ayuda de estos profesionales mucho más inteligentes que yo que saben discernir y analizar los detalles importantes de la paja. Por desgracia, estas personas a menudo no pueden aceptar el reconocimiento público de su ayuda.

P: Si tuviera que apuntar a algo o alguien como responsable de fraude organizado en Internet (aparte de los atacantes), ¿quién o qué sería?, ¿el tratamiento de vulnerabilidades? ¿la impunidad de las empresas de pago?

https://twitter.com/briankrebs
R: Tal y como mencionas, hay una gran oscurantismo sobre los pagos financieros, creo que ese es exactamente el objetivo de los malos. Actualmente, hay un gran aumento de las innovaciones y ofertas en las tarjetas de prepago. Es precisamente donde estamos viendo un gran crecimiento en la actividad criminal. Son instrumentos financieros casi tan transparentes como el mercado del revendedor de hosting. Muchas veces es difícil incluso para los profesionales financieros entender cómo están interconectados los sistemas de pago, o incluso qué empresa se encarga de la gestión y supervisión de una red de prepago específica. A los estafadores les encanta esto porque cuanto menor es la transparencia en un sistema que quieren explotar, menos probable es que haya suficiente supervisión/control y equilibrio para detectar y bloquear la actividad en  un tiempo significativo y  eficaz. Lo hemos visto una y otra vez con cajeros automáticos que usan plataformas de prepago comprometidas. La retirada de dinero de los cajeros son incidentes del tipo "coge el dinero y corre" muy lucrativos, y por lo tanto de un alto "nivel criminal". Pero los fraudes prepago basados en pequeñas cantidades pero mayor volumen están tomando cada vez más importancia en el mundo criminal de otras muchas maneras menos perceptibles.

Los otros dos grandes contribuidores al fraude son probablemente la geografía y la inercia. Un enorme porcentaje de los responsables de la innovación y herramientas que se utilizan en la mayoría de los delitos informáticos viven en países que por lo general no se han mostrado muy cooperativos ayudando a otros países a llevarlos ante la justicia. Si esto no fuera así, les sería mucho más caro y difícil a las organizaciones criminales conseguir los medios para realizar sus delitos.

Por último, aunque soy consciente del hecho de que las compañías de software necesitan mejorar sus procesos de testeo y la seguridad de sus propios productos antes y después de su publicación, esto no excusa el importante papel del usuario. No voy a voy a hacer ninguna de las manidas y aburridas analogías  que comparan el usuario a un conductor de coche o al software con la seguridad del automóvil, pero la realidad es que de alguna manera tenemos que hacer un mejor trabajo para concienciar a la gente la importancia de tomarse en serio la seguridad.

Hay una tensión constante y natural entre la seguridad y la facilidad de uso, todo el mundo podría beneficiarse de herramientas de seguridad más fáciles de usar y eficaces. Pero la seguridad es algo que debe primar, porque, de lo contrario, ya sería demasiado tarde. Así que el usuario necesita, en primer lugar, ser informado acerca de la naturaleza de la amenaza, y comprender que para la gran mayoría de nosotros, no es una amenaza personal, sino más bien oportunista. Esta es la idea principal que he tratado de transmitir con mis gráficos educativos,  el valor residual de un PC comprometido (http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited), y el valor de una cuenta de correo electrónico comprometida (http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/). Te des cuenta o no, el equipo y la información que contiene tienen un valor que puede ser extraído y revendido. Y si fallas a la hora de proteger adecuadamente algo que tiene un valor de reventa tan sencillo, al final dejará de pertenecerte.

P: ¿Se ha perdido la figura del verdadero reportero con los blogs? ¿Qué es lo que les está echando a perder?

R: No lo sé. Por conversaciones con mis colegas de los medios de comunicación sé que en mayor medida se les está pidiendo hacer más con menos, y por menos. Las publicaciones buscan cada vez más el número de visitas que historias que tienen un impacto, historias que necesitan tiempo para ser investigadas profundamente. Al mismo tiempo, hemos visto una explosión de investigadores independientes y escritores que han tomado el relevo. Dejaré la especulación sobre el futuro de la industria de los medios y las tensiones entre los "nuevos" y "viejos medios" a los demás, pero parece claro que, al menos, en el espacio de seguridad no falta periodismo de investigación por hacer.

P: ¿Cuál es su percepción del ciber-crimen organizado en el futuro?

R: Uno mejor financiado, a tiempo completo y teniendo en cuenta seguridad operacional. Incluso si sólo uno de esos puntos se convierten en la norma, la lucha contra la ciberdelincuencia se volverá mucho más difícil.

P: ¿Tomas alguna medida preventiva antes de utilizar un cajero automático? ¿Alguna vez has descubierto un skimmer? Si es así, ¿cómo reaccionó el personal del banco?

R: Primero me centro en mi propia seguridad, segundo en skimmers y mirones. Cuando manejas grandes cantidades de efectivo es más probable que te asalte un ladrón a que te hagan un skimmer. Pero es curioso... una vez que sabes lo rertorcidamente bien diseñados y hechos que pueden ser los skimmers, es muy difícil evitar forcejear y curiosear con los cajeros que usas para retirar el dinero. De hecho, se ha vuelto tan obsesivo para mí que incluso inspecciono cajeros por los que paso por delante y ni tengo intención de usar. Por desgracia, todavía me queda por descubrir un skimmer personalmente.

P:¿Crees que podrían tratar de infectarte con algún malware hecho a mano dirigido especialmente contra ti (aprovechando algún 0day, tal vez)? ¿Lo han intentado, ya?

R: Soy tan susceptible a los "0 day" como el que más, pero soy muy paranoico, y prefiero hacer la mayor parte de mi trabajo online dentro de las máquinas virtuales (o al menos en máquinas que no tengan Windows). Ya sabes lo que dicen: ¡Que seas paranoico no significa que no todo el mundo esté tratando de seguirte!

P: ¿Cuáles son las medidas preventivas que tomas en tu sistema Windows personal para evitar el malware? ¿Y para evitar las amenazas más avanzadas? ¿Cuál consideras que es la herramienta más útil, aunque personalmente no la hayas utilizarlo?

R: Tener el control del scripting en el navegador es muy importante, pero también es de las fórmulas que más cuesta adoptar al usuario ocasional de Internet. Sandboxear aplicaciones cuando sea posible con herramientas como Sandboxie y aprovechar al máximo la herramienta EMET de Microsoft son consejos muy útiles para el bloqueo de muchos ataques. Eliminar el software que no se necesita y los plugins del navegador es muy importante también.



Q: You may be one of the most hated person among criminals on the Internet. You have been threaten and they even got to SWAT your house three months ago. They know where you live. After that incident, do you think it is worth to go on? Does it mean you are doing it "right" or that you are disturbing the wrong people? Where would the limit be?

A: “Most-hated, eh? :) Maybe. My main focus is on bringing cybercrime up close, making it understandable and perhaps less mysterious for readers. There is so much hype in the information security field today, but I find that letting people see firsthand the facts and realities behind the hype helps all of us make better decisions about how we protected ourselves online. To your question, I would be offended if the criminals responsible did not take notice! I have documented a few ways they've indicated their notice here:

Q: Do you think behind that "hate" and criminals focusing on you, there is as well some respect? Don't you think attackers may use you as a broadcaster of some of their activities? Do you understand this as a "game" you are playing or a battle some may win or lose eventually?

A: I like to think that -- in this area at least -- there is a fine line between love and hate. It’s tough to know how much of the attention is hatred vs. grudging admiration or gratitude. For example, my impression from reading many of these crime forums on a daily basis is that a great number of people involved in cybercrime don’t have a high opinion of Americans in general, and don’t particularly appreciate people who they may perceive as unqualified or unskilled critiquing their work. On the other hand, as they say in the news business – there’s no such thing as "bad press" – and a lot of guys selling and marketing innovative criminal services may look at a Western journalist highlighting their work as free advertising. If they do get upset from the something I write, it’s usually because one of their domains gets shuttered due to the public attention, and they’re forced to move somewhere else or move further underground.

Q: Sometime, information you give in your blog may be previously unknown, and making it public may be seen "inconvenient", because law enforcement may use it to arrest people, for instance. In some way it works as "full disclosure" dilemma. What do you think about it? Would you sacrifice a good story for a good cause?

A: This is a natural and I think healthy tension in the security space -- between hoarding information for whatever reasons, and acting on that information. Acting on it almost always inconveniences someone other than the bad guys -- be it researchers, law enforcement or security firms.

Law enforcement officials have a tough job: They not only have to know who and where the bad guys are and exactly how they did the crime, but they have to have proof that that said bad guys did the crime. This may sound obvious and even simple to the casual reader, but those in security can no doubt attest to handing law enforcement what may seem like a criminal case on a silver platter, only to have the authorities say they need to gather the information in their own way and according to their own rules.

So, many times, what may seem like an open and shut case from the security practitioner’s or defender’s perspective is a much more laborious and complicated process. In some ways, this is as it should be: For reasons of privacy and general distrust of government, most people really don’t want their local or federal authorities to be too efficient – unless of course the matter in question relates to an incident that affects them personally.

But certainly there has been more than one occasion where I have sat on what I considered to be very good and complete stories with full knowledge that law enforcement officials were working toward the same conclusions. Sometimes what seems like a good story that’s ready to go gets even better when you can add more perspective from an official accounting of the incident and alleged individuals involved. I would never consider such stories to be "sacrifices,"; good stories don’t have an expiration date, and some stories actually age pretty well. In fact, I am sitting on one such case as we speak – in part because the individual in question is a minor – and also because I’m now curious how this is all going to shake out on its own.

But speaking as a journalist, I generally don’t delay or defer publishing stories just because it might inconvenience law enforcement officials. Doing so earns journalists few points with investigators, since they seldom seem willing to reciprocate or engage in a tit-for-tat information sharing agreement.

Q: What do you think about cooperating with law enforcements to try to stop crime on the internet? Do you have a good relation with them?

A: Sure. I get contacted quite often by federal agents who are researching a story I broke or a particular fraudster I wrote about and are looking for more background information. I never discuss sources and methods with law enforcement, but I usually don’t mind sharing knowledge or answering direct questions about something I’ve written, assuming the information is not privileged in some way. But again, it’s foolish to expect reciprocity for this information sharing: Law enforcement here in the U.S. at least are notoriously good at taking information and famously stingy about offering anything useful in return. I do have an give-and-take relationship with a handful of law enforcement sources, but these are for the most part friends who segued into that role or otherwise people I have known for some time now -- and they are the exception rather than the rule.

Q: When you need some deep technical knowledge during your work, who do you rely on?

A: I’m fortunate as a journalist to have had the opportunity to work at The Washington Post, which certainly opened a lot of doors into the security community that perhaps would not have swung open so easily or quickly otherwise. That said, one thing I have focused on heavily is cultivating sources who really know their stuff and have not only a general knowledge about threats but who also have a "hands-on" skills. That is, the ability to help dig through mounds of disparate or maybe just overwhelming amounts of data to look for that needle in the haystack that helps thread the rest of the story. Often these are not the same people who offer the most eloquent quotes (or even have permission to be quoted in a story), but I could not get most of my stories done without significant assistance from people a lot smarter than me who know how to isolate and parse the important stuff from the chaff. Unfortunately, these individuals are often not able to accept public acknowledgement of their assistance.

Q: If you had to point at something or someone as responsible for organized fraud scheme on the internet (apart from attackers themselves), who or what would it be? Vulnerability handling? Impunity of payment companies?

A: As you alluded to, there is a great deal of opacity in the financial payments space, and I do think that’s exactly what the bad guys target. Currently, there is an explosion of innovation and new offerings in the prepaid cards space, and this is precisely where we’re seeing a lot of growth in criminal activity and attention. These are financial instruments that are about as transparent as the hosting reseller’s market – often times it’s difficult even for financial professionals to understand how these payment systems are interconnected, or even which company is responsible for managing and overseeing a specific prepaid network. The crooks love this because the more opacity there is in a system they want to exploit, the less likely there will be sufficient oversight/checks and balances to detect and block that activity in any meaningful or effective time frame. We have seen this over and over again with the ATM cashouts using compromised prepaid card platforms. These ATM cashouts are high-dollar smash-and-grab incidents, and as such are very high-profile crimes. But more smaller-amount but higher-volume prepaid fraud is powering a growing share of the fraud these days in a lot of other, far less visible ways.

The two other big contributors are probably geography and inertia. A huge percentage of the individuals responsible for the innovation and tools that are used by the majority of the cybercrime underground live in nations that typically have not been super-cooperative with other nations in bringing those folks to justice. If that were not the case, it would be far more expensive and difficult for many of these criminal operations to gain the capital, momentum and protection they need to thrive.

Finally, while I’m cognizant of the fact that software companies need to dramatically ramp up their game and do a far better job testing and securing their own products prior to and after their release, this does not excuse the user’s very important role. I won’t invoke any of the tired analogies comparing the user to a car driver or software to automobile safety, but the reality is that somehow we need to do a better job impressing on people the importance of taking security seriously.

There is a constant and natural tension between security and usability, and everyone could benefit from more user-friendly and effective security tools. But security cannot be an afterthought; because of course by then it is too late. So the user needs, first and foremost, to be informed about the nature of the threat, and to understand that for the vast majority of us, it’s not a personal threat but more of an opportunistic one. This is the main idea I’ve tried to communicate with my educational graphics, The Scrap Value of a Hacked PC (http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited), and The Value of a Hacked Email Account (http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/): Whether you realize it or not, your machine and your information has value that can be extracted and resold, and if you fail to properly secure something that has such easy resale value, eventually that something will no longer belong to you.

Q: Is the figure of genuine "reporter" lost already with blogs? What is spoiling them?

A: I don’t know. I do know from speaking to my colleagues in the media that more of them are being asked to do more with less, and for less. More publications are chasing more eyeballs and pageviews than pursuing stories that have an impact, stories that take the time to dig deeply. At the same time, we have seen an explosion of independent researchers and writers who have taken up the slack. I’ll leave the speculation as to the future of the media industry and tensions between “new” and “old” media to others, but it seems clear that in the security space at least, there is no shortage of investigative journalism to be done.

Q: What is your perception of organized ciber-crime in the future?

A: One that is better funded, more full-time, and has more well thought-out operational security. Even if just one of these things become the norm, fighting cybercrime will become much, much harder.

Q: Do you take any prevention measure before using an ATM? Have you ever discovered a skimmer yourself? If so, how did the staff in the bank reacted?

A: My focus is on my personal safety first, skimmers second and shoulder-surfers second. Anytime you’re handling large amounts of cash, you’re far more likely to get mugged by a thief than by a skimmer. But it’s funny…once you know about how devious and well-designed these skimmers can be, it’s really hard to avoid pulling on and poking at any ATM that you use to withdraw money. In fact, it’s gotten so bad for me that I even tug on and inspect those ATMs that I’m merely passing by with no intention to use.  Sadly, I have yet to discover an ATM skimmer personally.

Q: Do you think they could try to infect you with some hand-made malware made specially for you (taking advantage of some 0day, maybe)? Have they already tried?.

A: I am just as susceptible to 0days as the next guy, but I am extremely paranoid, and prefer to do most of my internet-facing daily work inside of virtual machines (or at least non-Windows machines). You know what they say: Just because you’re paranoid doesn’t mean everyone’s not out to get you!

Q: What are the preventive measures you take on your personal Windows to prevent malware? And to prevent more advanced threats? Wich one do you think is the most useful measure or tool, even if you personally do not use it.

A: Getting a handle on active scripting in the browser is fairly important, but it’s also one of those protections that a lot of casual internet users have no patience for adopting. Sandboxing applications wherever possible with tools like Sanboxie and taking full advantage of Microsoft’s EMET tool goes a long way toward blocking many attacks. Removing unneeded software and browser plugins is very important as well.

Más información:

Twitter Brian Krebs

Krebs on security


Laboratorio Hispasec

miércoles, 24 de julio de 2013

Investigadores consiguen vulnerar y controlar los sistemas de un coche

Los investigadores Charlie Miller y Chris Valasek han descubierto, a través de un programa de investigación financiado por la agencia estadounidense DARPA, la manera de controlar ciertos parámetros en los computadores de algunos vehículos.

Desde que los coches aumentaron su dependencia a los ordenadores y sistemas empotrados el control de componentes tales como el frenado, las revoluciones del motor o las luces fueron pasando de las manos humanas hacia los sistemas expertos y redes de sensores de los ordenadores de a bordo. Miller y Valasek han analizado como funciona toda esta red de eventos y toma de decisiones con un claro objetivo: la seguridad.

Aunque los detalles serán mostrados públicamente el 21 de agosto durante la conferencia BlackHat en un avance de los logros puede observarse como mediante una orden deshabilitan el sistema de frenado de un Toyota Prius. No importa la fuerza con la que se presione el pedal de freno, el vehículo omite al conductor y prosigue su camino.

En la demostración Miller y Valasek se conectan al vehículo a través de un conector, sin embargo y de manera independiente, en 2011, investigadores de las universidades de Washington y California consiguieron el mismo grado de control vulnerando la red WiFi del vehículo. Es decir, ni siquiera es necesario tener acceso físico al coche objetivo para controlar sus sistemas críticos.

La red WiFi es un vector, pero también es posible atacar los sistemas del coche a través de sus conexiones Bluetooth, conexiones telefónicas o aplicaciones específicas de control móvil ofrecidas por los fabricantes. Incluso es posible vulnerar el software de un vehículo a través de un CD insertado en su sistema de audio.

Se suele decir que la imprudencia de un conductor hace que el control pase del humano a la máquina, ahora podría ser posible que el control pase del humano a la máquina y de esta al atacante sin la imprudencia del conductor.

Más información:

How Easily Can a Moving Car Be Hacked?

Center For Automotive Embedded Systems security

Hackers Reveal Nasty New Car Attacks--With Me Behind The Wheel (Video)



Laboratorio Hispasec

martes, 23 de julio de 2013

Vulnerabilidad de ejecución de código en múltiples productos Autodesk

Se ha anunciado una vulnerabilidad que afecta a una larga lista de más de 50 productos Autodesk, que podría permitir a un atacante remoto comprometer los sistemas afectados.

La vulnerabilidad, con CVE-2013-3665, reside un error del que no se han facilitado detalles en el tratamiento de archivos DWG. 

La lista de productos afectados es:
     AutoCAD Architecture 2011, 2012, 2013 y 2014
     AutoCAD 2011, 2012 y 2013
     Autodesk AutoCAD 2014
     AutoCAD Electrical 2011, 2012, 2013 y 2014
     AutoCAD LT 2011, 2012 y 2013
     Autodesk AutoCAD LT 2014
     AutoCAD Mechanical 2011, 2012, 2013 y 2014
     AutoCAD Structural Detailing 2011, 2012, 2013 y 2014
     AutoCAD Utility Design 2012 y 2014
     AutoCAD Civil 3D 2011, 2012, 2013 y 2014
     AutoCAD ecscad 2011, 2012, 2013 y 2014
     AutoCAD Map 3D 2011, 2012, 2013 y 2014
     AutoCAD MEP 2011, 2012, 2013 y 2014
     AutoCAD Plant 3D 2011, 2012, 2013 y 2014
     AutoCAD P&ID 2011, 2012, 2013 y 2014
     DWG TrueView 2011, 2012, 2013 y 2014

Autodesk ha proporcionado el "Hotfix CodeExecutionVulnerabilityHotfix.exe", para solucionar el problema. Disponible desde:

Más información:

Autodesk® AutoCAD® Code Execution Vulnerability – Security Hotfix

Autodesk® AutoCAD® Code Execution Vulnerability – Security Hotfix Readme



Antonio Ropero
Twitter: @aropero

lunes, 22 de julio de 2013

Diversas vulnerabilidades en Sybase EAServer

Se han confirmado diversas vulnerabilidades en Sybase EAServer, que podrían permitir a un atacante remoto obtener archivos de los sistemas afectados.

EAServer es un servidor de aplicaciones desarrollado por la empresa Sybase, incluye un conjunto de herramientas que se usan para crear y ejecutar aplicaciones Web con soporte a altos niveles de tráfico, contenido dinámico y procesamiento intensivo de transacciones en línea.

Una primera vulnerabilidad reside en que no se validan de forma adecuada las entradas dadas por usuario en el plug-in redirector, lo que puede permitir realizar una escalada de directorios para visualizar archivos en el sistema vulnerable:

https://[víctima]/myapp/%5C../console/Login.jsp

Por otra parte existe otra vulnerabilidad XXE (XML eXternal Entity) en el procesador XML a través de la función testDataTypes() que puede permitir a un atacante remoto listar directorios arbitrarios y visualizar cualquier archivo de los sistemas afectados. Esto podría permitir la obtención de credenciales administrativas de los archivos de configuración.

Sybase ha publicado parches para evitar estas vulnerabilidades disponibles desde:

Más información

Multiple vulnerabilities Sybase EAServer

Antonio Ropero
Twitter: @aropero


domingo, 21 de julio de 2013

Vulnerabilidades en McAfee ePolicy Orchestrator

Se han anunciado diversos problemas de seguridad en McAfee ePolicy Orchestrator que podrían permitir la realización de ataques de Cross-Site Scripting y de inyección SQL.


McAfee ePolicy Orchestrator, también conocido como McAfee ePo, es una consola de administración que permite la gestión centralizada de la seguridad para sistemas, redes, datos y soluciones de cumplimiento de normativas.

Estos problemas de seguridad afectan a McAfee ePolicy Orchestrator 4.6.6 (y versiones anteriores) y a ePO Extension para McAfee Agent (MA) 4.5 a 4.6.

Se han detectado multiples scripts que no filtran de forma adecuada el código HTML de las entradas de usuario antes de ser devueltas al usuario. Esto permite a usuarios remotos generar ataques de cross-site scripting que podrían permitir la ejecución arbitraria de código script en el navegador del usuario. Con ello el atacante podría acceder a las cookies (incluyendo las de autenticación) y a información recientemente enviada, además de poder realizar acciones en el sitio haciéndose pasar por la víctima.

Los archivos afectados son los siguientes:
    /core/loadDisplayType.do [parámetro instanceId]
    /console/createDashboardContainer.do [parámetro monitorUrl]
    /console/createDashboardContainer.do [parámetro monitorUrl]
    /ComputerMgmt/sysDetPanelBoolPie.do [parámetro uid]
    /ComputerMgmt/sysDetPanelQry.do [parámetro uid]
    /ComputerMgmt/sysDetPanelQry.do [parámetro sysDetPanelQry]
    /ComputerMgmt/sysDetPanelSummary.do [parámetro sysDetPanelSummary]
    /ComputerMgmt/sysDetPanelSummary.do [parámetro uid]

Un segundo problema reside en la posibilidad de realizar ataques de inyección SQL ciega. Solo usuarios autenticados pueden explotar esta vulnerabilidad que reside en los siguientes archivos .do:
/core/showRegisteredTypeDetails.do [parámetro uid]
/EPOAGENTMETA/DisplayMSAPropsDetail.do [parámetro uid]

Los problemas de cross-site scriptong se solucionarán en ePO 4.6.7, que está planificado para publicar a finales del tercer cuatrimestre del 2013. 

Más información:

Multiple Vulnerabilities in ePO 4.6.6 and earlier

McAfee Security Bulletin – McAfee ePO Extension for McAfee Agent 4.5 and 4.6 Blind SQL Injection Vulnerability



Antonio Ropero
Twitter: @aropero

sábado, 20 de julio de 2013

Actualización del kernel para Red Hat Enterprise Linux 6

Red Hat ha publicado una actualización del kernel para toda la familia Red Hat Enterprise Linux 6 que solventa 11 vulnerabilidades que podrían ser aprovechadas por un atacante para provocar denegaciones de servicio o elevar sus privilegios en el sistema.

Los problemas corregidos se deben a errores en la implementación del protocolo IPv4 TCP/IP en la forma en que se tratan los los búfers de sockets (skb), fugas de información en el kernel, fallos de formato de cadenas en la implementación del sistema de archivos ext3 y de la implementación del driver b43, y por último, una desreferencia a puntero nulo en las implementaciones de ftrace y tracer.


Además se han solucionado otros fallos de menor importancia. Ésta actualización está disponible desde Red Hat Network.

Más información:

Moderate: kernel security and bug fix update


Antonio Ropero
Twitter: @aropero