Nuevas herramientas del Microsoft SDL próximamente

En Junio comentaba la apertura del Microsoft Security Development Lifecycle, una interesante iniciativa de la empresa de Bill Gates para el desarrollo de aplicaciones en forma segura.

Hasta ahora, dicha iniciativa constaba principalmente de una serie de documentaciones y recomendaciones describiendo lo que Microsoft propone para lograr la creación y mantenimiento de soluciones de software con un alto grado de seguridad.

Ahora, se están agregando varias herramientas a la iniciativa, que estarán disponibles en breve, y de las cuales existen dos de alto interes para aquellos equipos de programadores que quieran mejorar los procesos de desarrollo de sus aplicaciones.

Una de ellas es un modelo de optimización (SDL Optimization Model) que estará pronto disponible para descarga desde el sitio de Microsoft y tiene como objetivo facilitar la implementación de SDL.

La otra que me ha resultado interesante es una herramienta de modelaje de amenazas (Microsoft SDL Threat Modeling Tool 3.0) que permitirá realizar un analisis estructurado para la mitigación de potenciales riesgos de seguridad en el desarrollo de aplicaciones.

La iniciativa SDL de Microsoft me parece que tiene varios aspectos muy positivos, tanto para la comunidad de desarrolladores como para conocer en detalle cómo son pensadas y desarrolladas las aplicaciones de la empresa.

Interesante lectura para todos los interesados, que está disponible en el siguiente enlace:

http://msdn.microsoft.com/es-es/security/cc967276(en-us).aspx

/is

Mes del Cyber Security Awareness del ISC / SANS

Tal como comenté el año pasado, Octubre es el mes de la campaña de awareness del Internet Security Center del SANS, y en esta ocasión, en el Handler's Diary, están dando consejos diarios sobre manejo de incidentes relacionados a la seguridad informática.

Estos consejos han comenzado desde la preparación previa necesaria para poder luego responder a incidentes, para luego pasar por las distintas etapas propuestas por el SANS, como la identificación, la Contención, la Erradicación, la Recuperación y las lecciones aprendidas por el incidente.

Les recuerdo que la información está en inglés, y les recomiendo leer estos consejos, dado que dan un paneo interesante de lo necesario para detectar y responder ante un incidente de seguridad.

Guia de Seguridad en Windows Vista

Como esta semana estoy algo complicado de tiempo, al menos les quiero dejar algo interesante que vi el día de hoy: La Guía de Seguridad en Windows Vista.

Es un documento al estilo manual que analiza diversos aspectos de seguridad en el último sistema operativo de Microsoft, incluyendo aspectos como malware, políticas, protección de datos, etc.

La guía solamente está en inglés (y francés), pero no deja de ser interesantes para quienes tengan la posibilidad de leerla, más allá de que algunos conceptos es bueno tomarlos con pinzas, porque no es tan bonito como lo pintan ahi.

Está más bien orientada a usuarios avanzados o administradores, pero también se las recomiendo a aquellos que tienen ganas de experimentar un poco en materia de seguridad con sus equipos.

Está disponible desde al año pasado, en:

http://technet.microsoft.com/es-ar/bb629420.aspx

Visto en Segu-Info y DragonJAR.

Para quienes anden interesados en ver la de XP, algo más antigua, aquí también les dejo el enlace:

http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/default.mspx

El drama de los DNS (II)

Como dije en el último post sobre el tema de la vulnerabilidad del cache poisoning en los servidores DNS, mi idea es mantenerlos al tanto sobre los distintos avances de este tema tan problemático para todos los que usamos Internet a diario.

Primero comentarles que además de la posibilidad de chequear si sus DNS son vulnerables a través de la página de Dan Kaminsky, el descubridor de la vulnerabilidad, DNS-OARC también liberó una herramienta similar (hacer click en la opción Test my DNS en el centro de la página disponible aquí).

Es importante contar con dos herramientas porque nos dará más seguridad sobre si nuestros DNS aún son vulnerables o no.

Con lo complicado del alcance de esta vulnerabilidad, se hace más marcada la diferencia entre tres tipos de proveedores de servicios y/o software de de DNS:

• Los que ya han liberado parches y repiten continuamente las palabras “Patch now!” (“¡Parcheen ahora!”, por implementar las actualizaciones cuanto antes) 
• Los que hasta ahora no han liberado o aplicado los parches, como Apple o algunos de los principales proveedores de Internet del mundo
• Los que no han sufrido vulnerabilidad ahora porque se han anticipado a la posibilidad y han implementado mayores medidas de seguridad contra el envenenamiento de caché, como OpenDNS, PowerDNS y MaraDNS
  

El mayor problema está en que no solo la vulnerabilidad ya es conocida públicamente, sino que ya existen herramientas para explotarlas, tales como Evilgrade, o lo incluido en Metasploit.

Lo anterior hace que ya se comiencen a encontrar algunos casos de ataques que podrían estar dándose gracias al aprovechamiento de esta vulnerabilidad, y como se dijo anteriormente, todavía hay demasiados proveedores y fabricantes que no han logrado parchear o liberar actualizaciones.

Todo esto no ha hecho que algunas soluciones ya seguras, como OpenDNS, comiencen a recibir mucha atención y las recomendaciones para utilizarlos pululan en Internet. No es que sea mala idea, todo lo contrario; si no saben si su DNS es vulnerable, o si comprueban que lo es con las herramientas anteriores, les recomiendo analizar la posibilidad de utilizar estos proveedores ya asegurados.

Algunos enlaces de interes para todos:

• Para administradores que usen Snort, en el blog de Sergio Hernando se pueden encontrar firmas para esa aplicación a fin de detectar posibles ataques aprovechando esas vulnerabilidades
• Para aquellos administradores que quieran detectar si han sufrido ataques de este tipo, existe la herramienta CacheAudit 
• Una curiosidad: uno de los responsables de hacer que los exploits para esta vulnerabilidad se comiencen a masificar, fue víctima de los mismos

En resumen: si son administradores, ¡parcheen ya! Si son usuarios, comprueben si sus DNS son vulnerables, y sino, cambien a algunos que no lo sean.

"is"

Novedad de seguridad en Internet Explorer 8: Filtro XSS

Me enteró por el blog Security Vunerability Research & Defense de Microsoft, de una nueva funcionalidad de seguridad que será integrada en la Beta 2 de Internet Explorer 8, aún en desarrollo.

Esta nueva funcionalidad es un filtro XSS (cross-site-scripting) que busca proteger a los navegantes contra ese tipo de ataque, muy utilizado en la actualidad. Los ataques XSS son aquellos que aprovechan fallas de seguridad en el desarrollo de sitios web que pueden permitir, entre otras cosas, el acceso a las cookies del visitante, interactuar con su navegación en los sitios web para obtener información sensible, etc.

Dichas vulnerabilidades se deben, puntualmente, a que los desarrolladores de algunos sitios web no comienzan su trabajo pensando en la seguridad, dejando de lado controles básicos en su programación.

El filtro que se incorporará en Internet Explorer 8 bloqueará el acceso a aquellas URLs que puedan intentar aprovechar vulnerabilidades XSS, mostrando un mensaje de aviso al usuario. La funcionalidad es explicada en detalle en el blog de Internet Explorer de Microsoft.

Para evitar problemas de acceso a ciertos sitios web que puedan ser falsos positivos, la aplicación del filtro puede ser anulada por el propietario del sitio web, mediante una cabecera HTTP particular (X-XSS-Protection: 0).

En los comentarios del blog que anuncia esto ya se ven algunas preocupaciones al respecto de este filtro, tales como lo confuso que puede ser para el usuario promedio, así como la efectividad que pueda llegar a tener.

Vale recordar que el plugin NoScript de Mozilla Firefox ya protege contra muchos de estos tipos de ataques.

Es bueno, de todas formas, ver que Internet Explorer se va aggiornando a las necesidades de seguridad de sus usuarios.

"is"

Windows Server 2008, Firewall y Servicios

Es bien sabido que Microsoft viene trabajando en implementar cada vez más medidas de seguridad en sus sistemas operativos. Sus iniciativas pueden ser bien o mal recibidos, y considerarse acordes o no, pero eso no quita que no se esté haciendo.

Windows Server 2008 es el último miembro de la familia de sistemas operativos para servidores de Microsoft, lanzada durante este año, que implementa varias medidas de seguridad. Una de ellas es la integración de un firewall propio, al estilo de lo que Microsoft hizo con Windows XP SP2 y Windows Vista.

Esta es la primera vez que Microsoft incluye un firewall en su S.O. para servidores, y no solo eso, sino que viene activado por defecto.

Esta decisión está basada en el hecho de que hay una gran cantidad de equipos, con servicios directamente publicados en Internet, que no siempre tienen la seguridad adecuada para ello.

Por ejemplo, una investigación realizada por David Litchfield, de NGS Software, encontró que alrededor de 368.000 equipos con SQL Server son accesibles desde Internet, así como alrededor de 124.000 con la base de datos de Oracle.

Que estos servidores estén expuestos a Internet no quiere decir que sean vulnerables, pero que se encuentre un agujero de seguridad explotado con algún código 0-day puede llegar a hacerlos inseguros a todos al mismo tiempo.

En ese sentido, la recomendación es elegir una política de seguridad adecuada, que incluya un firewall de seguridad perimetral o en el mismo servidor, y por ello Windows Server 2008 lo trae activado.

Sin embargo, no todo el mundo lo sabe, y al migrar de plataformas anteriores (como Windows Server 2003) se puede encontrar con que sus servicios, como SQL Server, dejan de funcionar.

Por ello, el blog de seguridad SQL de Microsoft publicó un artículo con las acciones recomendadas a tener en cuenta en estos casos, que se aplican no solo a SQL Server, sino también a cualquier servicio que se tenga en Windows Server 2008 y pueda ser bloqueado por el firewall integrado.

Visto en el blog de Michael Howard.

Herramienta de código abierto de análisis de sitios web, by Google

El día de hoy, Google liberó ratproxy, una herramienta que permite analizar sitios web en busca de potenciales vulnerabilidades varias.

Esta herramienta está pensada para analizar sitios de internet y automáticamente determinar posibles vulnerabilidades, así como priorizarlas y brindar información sobre las mismas.

Entre otras cosas, busca por posibles XSS, XSRF, inyecciones de datos, inclusiones potencialmente peligrosas, y mucho más. Lo interesante es que es gratis, de código abierto y puede incluso encadenarse con otras aplicaciones similares.

Para aquellos que estén interesados en probar esta aplicación, deben tener en cuenta que está pensada para usuarios avanzados, y no funciona directamente sobre Windows sin tener implementado cygwin previamente.

Más información en:

http://code.google.com/p/ratproxy/
http://code.google.com/p/ratproxy/wiki/RatproxyDoc

Origen de los sitios con códigos maliciosos

Ví en Segu-info, que tomó la noticia de The Inquirer, una estadística sobre el origen o fuente de los sitios que están alojando, sabiendo o no, códigos maliciosos en estos días.

Según el informe original de StopBadware.org, la mitad de los sitios en cuestión provienen de solamente 10 redes, las cuáles están basadas en China, y que un 2 % de los destinos inseguros que circulan en la web son blogs alojados en servicios de Google.

Uno tiende a pensar, con la maquinaria actual de las botnets, que estas últimas son las responsables de estar alojando los sitios con códigos maliciosos, pero en realidad no es así, sino que los atacantes están aprovechando las grandes infraestructuras de redes para obtener mejores resultados.

Y esto también muestra que no solo los usuarios no prestan atención a las recomendaciones de seguridad, sino que los administradores de redes, sin importar si es de una empresa pequeña o grande, tampoco lo hacen. La excusa muchas veces es la falta de tiempo, pero el malware hace que se consuma aún más tiempo que el que lleva aplicar prevención de problemas mediante el correcto control y monitoreo de los servidores.

Si no practicamos computación segura todos, gobierno, empresas, usuarios, etc., la internet seguirá siendo tan insegura como el peor barrio de cualquier gran ciudad, y cada día hará más falta que contemos con "ojos en la nuca" cuando navegamos por Internet.

"is"

Microsoft Security Development Lifecycle (SDL) disponible abiertamente

Mucho se le achaca en materia de seguridad informática a Microsoft (en realidad, mucho se le achaca en materia de casi cualquier cosa), pero es cierto que en lo que va de esta década han hecho grandes avances en dicha área.

Esto ha sido posible gracias a un cambio cultural interno de la empresa que se viene dando desde el año 2002, lentamente, pero real, y que en parte se debe a lo que Microsoft da en llamar Ciclo de Vida del Desarrollo de Seguridad (Security Development Lifecycle ó simplemente SDL).

SDL es una serie de lineamientos, procesos y controles que conforman la forma en que Microsoft trabaja durante el ciclo de desarrollo de sus aplicaciones con el fin de que el producto final contengan la menor cantidad de problemas de seguridad.

Desde la semana pasada, gran cantidad de material sobre este proceso de desarrollo ha sido hecho público por Microsoft para que cualquier desarrollador, equipo o empresa pueda también utilizarlo. He comenzado a revisarlo y realmente se ve muy interesante.

Para más información:
http://msdn.microsoft.com/en-us/security/cc448177.aspx

Para revisar el blog de SDL:
http://blogs.msdn.com/sdl/

Para ver los recursos disponibles:
http://msdn.microsoft.com/en-us/security/cc448120.aspx

"is"

Malware contra el mundo (menos China)

En estos días, una tendencia común en la distribución del malware es inyectar códigos maliciosos directamente en sitios web, aprovechando vulnerabilidades en algunos de ellos. Luego, cuando el usuario visita uno de sus sitios favoritos, puede llegar a infectarse. La tendencia se viene acentuando desde fines del año pasado.

Ayer, por ejemplo, Dancho Danchev reportaba un nuevo caso donde varios miles de sitios se encontraban infectados por una amenaza que, aprovechando una vulnerabilidad, podía infectar a sus visitantes.

Lo interesante que encontré, al analizar el código inyectado mediante el script reg.js, fue que la misma hacía una diferenciación basada en el idioma del navegador del usuario, como se puede ver a continuación:

if (navigator.systemLanguage=='zh-cn')
{}
else
{
document.writeln("{iframe con página maliciosa}");
}

La primera línea de este script chequea si el lenguaje del sistema es 'zh-cn', y si es así, no hace nada. Solo en los casos en que el lenguaje sea distinto a 'zh-cn', se intentará infectar el equipo del visitante. 'zh-cn' es el código que identifica al lenguaje Chino Simplificado.

Hay dos opciones respecto a esto:

• Que el autor sea chino, utilice ese lenguaje en su equipo, y para hacer pruebas sin infectarse, desarrollara su amenaza para evitar afectar su equipo (menos probable)
• Que el autor, sea chino o no, quisiera infectar a cualquier visitante, salvo a los chinos

De China es donde están viniendo la mayor cantidad de amenazas informáticas que aprovechan las técnicas de inyección de malware en páginas web. ¿Será esto una señal de que quieren infectar al resto del mundo menos a sus compatriotas? Esto es una especie de discriminación "racial" aplicada al malware...

"is"

Ciertas tendencias de técnicas de phishing se afianzan

Distintos investigadores de seguridad informática han comentado recientemente sobre como ciertas técnicas de phishing que se han usado esporádicamente en el pasado se han ido afianzando notablemente durante los últimos tiempos.

Entre estas tendencias ya afianzadas, se destacan dos de ellas, de las que hablaré a continuación.

La primera de ellas es la utilización de equipos infectados, que forman parte de las propias botnets que envían el phishing, para alojar los sitios falsificados de entidades bancarias y demás objetivos de los atacantes.

De esta forma, en lugar de crear sitios específicos, con dominios propios similares a los de las entidades bancarios, los responsables detrás del phishing, instalan un servidor web en el equipo de algún usuario infectado y éste, sin saberlo, termina colaborando con la estafa.

Una vez hecho, preparan el mensaje de phishing para que cuando los destinatarios hagan click en los enlaces del mismo, sean llevados al servidor web instalado en el equipo del usuario infectado.

La otra técnica es la explotación de vulnerabilidades en sitios web de empresas y organizaciones, para alojar allí las páginas de las entidades suplantadas, y así también evitar tener que crear el sitio y dominio desde cero.

Con esto, los atacantes diversifican las fuentes desde donde pueden conseguir información de aquellos que caen víctimas del phishing.

Un “valor agregado” para la primera de las técnicas es que, sin lugar a dudas, debe ser más difícil dar de baja un sitio de phishing alojado en el equipo infectado de un usuario de Internet, que hacer lo propio en un servidor cualquiera. Seguramente, esta es una de las principales razones por la que los que están detrás de este tipo de estafas están aplicando cada vez con mayor frecuencia esta técnica.

Lo mejor que podemos hacer para evitar ser parte de esto, es intentar mantener nuestro equipo seguro, siguiendo las mejores prácticas de seguridad, instalando antivirus y firewall, y aplicando las últimas actualizaciones de seguridad de nuestro sistema operativo, navegador y aplicaciones más utilizadas.

“is”

Fuente: El blog de Dancho Danchev

WMF Episodio III: La venganza de los Sith, El Regreso del Rey o el Retorno del Jedi

Hace mucho tiempo, en una galaxia muy lejana…

Sepan disculpar el inicio de este post, pero fue lo primero que pensé al ver lo que está sucediendo con la vulnerabilidad para la cual Microsoft publicó un parche en su boletín MS08-021.

En el 2006 tuvimos a la vulnerabilidad en los archivos WMF, que durante mucho tiempo permitió que apareciera una gran cantidad de malware reproduciéndose rápidamente, explotándola.

En el 2007, se dio algo similar con otro agujero de seguridad, dicha vez en los archivos ANI (cursores animados).

Ahora, parece que la vulnerabilidad anunciada en la las librerías GDI, que permitiría aprovechar archivos EMF (y también WMF) para ejecutar código arbitrario en un sistema en forma remota (es decir, que no hagamos nada y nos podamos infectar con algún malware, entre otras cosas), está comenzando a ser explotada activamente.

Al menos eso informa Arbor Networks en su blog:

http://asert.arbornetworks.com/2008/04/elevated-atlas-threat-index-gdi-exploits-in-the-wild/

Es un tema grave si lo comparamos con los dos casos anteriores, dado que brinda a la comunidad creadora de malware un nuevo vector de ataque de alto impacto, y no se sabe exactamente toda la extensión de las aplicaciones que indirectamente podrían verse afectadas ya que está en un componente del sistema operativo ampliamente utilizado.

Veremos cómo evoluciona, pero entre tanto, y como es debido, actualicen sus sistemas operativos a la brevedad y estén pendientes de las novedades sobre el tema.

Mejor prevenir que curar, y la gente de Arbor Networks nunca hablar por hablar…

“is”

Spam y Fraude de Clics todo en uno (en teoría, Marge)

Spam y Fraude de Clics todo en uno

Como siempre, revisando el spam que recibo para ver qué hay de nuevo o para intentar encontrar algo que me llame la atención, me encontré con uno que contenía básicamente un enlace como el siguiente:

http://www.google.de/pagead/iclk?sa=l&ai=XXXXXX&num=XXXXXX&adurl=XXXXXX

(Quiero destacar que obviamente, donde dice XXXXXX había otro dato pero lo reemplacé para que el enlace no funcionara)

Esto no es algo completamente nuevo (es más, creo que anda dando vueltas desde el 2006 o antes), pero es interesante el “2 por 1” que buscan los autores con este tema.

Vayamos por partes:

• Ya todos sabemos lo que es spam, así que no lo vuelvo a explicar (por las dudas, es todo ese correo basura que nos llega a nuestra casilla y que nosotros nunca solicitamos)
• El fraude de clics (o click fraud, o clickfraud) es lograr obtener más ganancias (haciendo trampa) de los servicios de publicidad que pagan por clic y que muchos de los webmasters pueden incluir en su sitio gratuitamente (más clics en la publicidad, más dinero reciben, en teoría)

Ya en otro post anterior sobre spam y google había mostrado una forma que existía (ya no, al menos no igual) para poder usar al buscador como redireccionador para llevar a otro sitio. El concepto que se aplica aquí es el mismo, pero sumando la posibilidad de hacer fraude de clics (en teoría).

Si observan la URL que puse más arriba como ejemplo, verán que pertenece a google, y el script iclk recibe los parámetros ai, num, y adurl. Los primeros dos son parte de la identificación del advertiser (para usar términos “modernos” ;-P) y el último es la dirección web de destino.

Ahora bien, esa dirección URL de destino puede ser cambiada arbitrariamente por cualquiera, es decir, que si ahora vamos a google, hacemos una búsqueda y copiamos la URL de cualquiera de los enlaces patrocinados, se podrá cambiar la url de destino en el mismo, y usar al contabilizador de clicks de Adsense/Adwords de Google como redireccionador, haciéndole gastar dinero, en teoría, al anunciante.

De esta manera, también podría usarse para enviar masivos correos de spam, con enlaces de este tipo, para que cuando la gente haga clic en el enlace, no solo vaya al destino del correo basura, sino también el responsable del spam pueda ganar dinero (si Google no penaliza su cuenta).

Es otro tipo de técnica de spam más que cumple con los objetivos que siempre se han planteado los spammers: que el usuario confie/crea/se vea motivado por el mensaje, y que a su vez, haga clic en el enlace (y quien no haría clic en un enlace de Google ;-P).

Como dije, la técnica no tiene demasiado de innovación, pero si es interesante repasarla, porque, si se me lo permite, aquí Google ha cometido un grave error de diseño: permitir que se pueda cambiar fácilmente la dirección de destino de su redireccionador de clics, al ponerla tan claramente, en texto plano, al alcance de quien quiera hacerlo.

Puede ser que Google esté filtrando este tipo de cosas de su lado, y que los clics no sean contabilizados, pero sin embargo, cualquiera puede usar esta técnica (vayan, hagan la prueba de lo fácil que es usar un enlace patrocinado como redireccionador a cualquier sitio web).

Esto podría ser fácilmente evitable con Google si en lugar de mantener la URL de destino del anuncio en texto plano, la misma estuviera almacenada en una base de datos del buscador, y que la URL solamente tuviera un id(entificador) del anuncio, que luego sirviera para obtener en los sistemas de Google la URL de destino.

Espero que mejoren esto, dado que me parece un aspecto clave de la seguridad, ya que dejan la puerta abierta a ataques de ingeniería social, usando su propio dominio como la fuente de confianza.

“is”

PD: Si alguien hace la prueba, deje un comentario, para corroborar esto y que Google no se la agarre conmigo solo ;-P

PD2: Si alguno conoce más sobre la arquitectura del enlace de AdSense/AdWords para aportar más datos a este tema, bienvenido será :-)

Cambios de objetivos de los defacers

Los defacers son aquellos que realizan defacement de páginas web, lo cual es cambiar un sitio de internet a partir de una vulnerabilidad en el mismo de algún tipo (software, humana, etc).

Es una práctica común de los pseudo-hackers para mostrar de lo que son capaces, y es algo que hasta hace poco se hacia cada vez más común.

Sin embargo, Zone-H.org, un sitio cuyo objetivo es monitorear y publicar los defacements que se van dando, informa de una estadística muy interesante: en el 2007, hubo menos de lo normal.

Según informan en su página web, este tipo de ataques solía subir alrededor de un 30% de año a año, pero durante el 2007, se produjo una baja del 37 %, algo que nunca había ocurrido antes:

http://www.zone-h.org/content/view/14940/31/

Las conclusiones de los responsables del sitio son:

• Cada vez hay menos interes de los medios por este tipo de ataques, por lo que no da la fama que daba antes
• Los responsables de este tipo de ataques están cambiando a otros que les puedan dar más beneficios

Específicamente, la gente de Zone-H.org marca el descenso en los defacements realizados por los conocidos grupos brasileños.

Es otro dato más que nos muestra que quienes están detrás de los ataques informáticos están enfocándose cada vez más hacia la obtención de dinero, ya que Brasil es uno de los principales productores de troyanos bancarios y otros códigos maliciosos relacionados.

"is"

No responda este mensaje...

Muchos de nosotros recibimos notificaciones y mensajes de los servicios de Internet que utilizamos. Estos mensajes nos son enviado en forma automática, y el remitente del mismo usualmente es una dirección inexistente tal como noresponder@dominio.com o noreply@dominio.com, entre otras tantas opciones.

Es una práctica muy común cuya intención es que el destinatario comprenda que no debe responder al mensaje, además de eviar recibir muchas notificaciones de rebotes de correo (p.e. por direcciones de destino inexistentes) en alguna casilla real.

Más allá de eso, muchos usuarios desconocen de esto y por ende, responden a los mensajes a esas inexistentes direcciones. En la mayoría de los casos, dicha dirección simplemente no recibe mensajes, por lo que la respuesta del destintario, se pierde.

Ahora, ¿qué pasa cuando no se usan direcciones de un dominio propio de la fuente del mensaje? Si observan las direcciones de ejemplo que puse más arriba, verán que las mismas corresponden a un sitio (dominio.com) que existe pero no está en uso. Si enviamos un mensaje de correo allí, no sabremos realmente quien lo recibirá o si alguien realmente lo verá o no.

Sobre este caso hay un interesante, y extraño, post en el blog de seguridad del Washington Post, llevado adelante por Brian Krebs, el cual nos trae una entrevista al dueño del dominio donotreply.com (en español, no responder . com).

Parece ser que varias empresas y negocios de Estados Unidos envian notificaciones a sus usuarios y clientes usando una dirección con ese dominio como remitente. No lo hacen con ninguna intención, en teoría, sino que lo hacen para que quede claro al destinatario que no debe responder... pero mucha gente lo hace igual y quien recibe esas respuestas no son las empresas que envian el mensaje sino Chet Faliszek, el dueño del dominio donotreply.com.

Chet ha recibido muchas cosas que deberían no haber sido enviadas a desconocidos (documentación confidencial, por ejemplo) debido a que algunas empresas y financieras hacen envios a sus clients poniendo una dirección con su dominio como remitente.

Más en Security Fix, el blog sobre seguridad del Washington Post:
http://blog.washingtonpost.com/securityfix/2008/03/they_told_you_not_to_reply.html

La culpa no la tiene Chet, sino los administradores de esas empresas y financieras que deberían usar una dirección de correo que controlen como remitente, en lugar de una de un dominio existente.

Para clarificar un poco el tema, les dejo este simple gráfico:

Esto funciona así:

1. Nosotros recibimos una notificación desde una empresa que utilizamos normalmente llamada suservicio.com.
2. Al recibirlo, respondemos al mensaje para hacer alguna consulta a dicha empresa o para enviarles información porque nos la solicitan.
3. Dado que dicha empresa usa una dirección @donotreply.com en lugar de una @suservicio.com como remitente de la notificación cuando nosotros respondemos, no lo hacemos a la empresa, sino al servidor de Chet
4. Chet entonces recibe nuestra respuesta y no la empresa

Este tema no es tan peligroso como parece pero si muestra dos claras malas costumbres:

• Las empresas deben ser más cuidadosas con los envios que hacen a sus clientes. Las direcciones de remitente de las notificaciones que envien deben ser cuentas en dominios que controlen adecuadamente y no inventadas y sin verificación
• Los usuarios tenemos la mala costubre de no leer correctamente todo el contenido del mensaje. Normalmente, esas notificaciones le dan al destinatario información de cómo es la forma correcta de comunicarse con el servicio pero el mismo no presta atención y responde igual, enviando el mensaje a direcciones que no conoce

Interesante caso para ilustrar que los usuarios debemos ser más responsables con lo que hacemos y prestar atención a los mensajes que recibimos.

"is"

NOTA AL PIE: dominio.com y noresponder.com son dos dominios que actualmente no muestran ninguna página ni servicio en particular; suservicio.com es el sitio de una empresa existente cuyo dominio se utilizó solamente para ejemplificar el caso en cuestión y no tiene ninguna relación con lo comentado en este post.

Análisis de los robots de spammers

Un reciente post en el blog de Sergio Hernando explica claramente, a través de un caso práctico, algunos conceptos sobre los robots que usan los spammers para encontrar y guardar direcciones de correo electrónico, conocidos normalmente como spiders.

El artículo es muy interesante y recomiendo su lectura:

http://www.sahw.com/wp/archivos/2007/11/13/analisis-de-aranas-de-spam-en-servidores-web/

El análisis paso a paso es muy bueno, y sirve de aprendizaje.

"is"

Seguridad vs. Usabilidad

Si hay dos conceptos que se enfrentan, en muchos casos en una lucha que ninguno parece tener las de ganas, son la seguridad y la usabilidad.

Según la UPA (Usability Professionals Association), la usabilidad es el grado en que algo – software, hardware o cualquier otra cosa – es fácil de usar y adecuado para la gente que lo usa.

En muchos casos, sucede que algunas de las cosas que mayor nível de usabilidad tienen, no son tan seguras, y viceversa. Tal como se puede ver en una reciente edición de la tira cómica de Dilbert, muchos llegan a pensar que en un mundo completamente seguro, “nadie tendría que ser capaz de usar nada”:

Esto sucede debido a que, por ejemplo en el software, aquello que es muy fácil de usar, pasa de largo en su diseño ciertos aspectos básicos de seguridad informática, para que el usuario pueda hacer las cosas de una forma más sencilla.

A su vez, en sistemas extremadamente seguros, el usuario casi no es capaz de hacer nada sin tener que realizar montones de acciones previas de autenticación y configuración, que se basan en distintos principios de seguridad.

Vayamos por ejemplo a un ejemplo claro: las contraseñas. Normalmente se recomienda que las contraseñas que se utilicen deben ser fáciles de recordar y difíciles de descifrar, al mismo tiempo.

Para el común de los usuarios, que hoy en día tienen usuarios y contraseñas para acceder a múltiples servicios (homebanking, email, sitios varios, webmail, mensajero instantáneo, etc), lograr cumplir esa máxima es muy difícil. Para que sus servicios sean más usables, fáciles, suelen utilizar una o dos contraseñas sencillas (cumpleaños, nombres de mascotas, etc) en todos los servicios, lo cual es altamente inseguro… Sino, terminamos en el otro extremo, como yo, que tengo varias decenas de contraseñas distintas, con diversas formas de crearlas y recordarlas, pero que en algún momento llevan a que no recuerde alguna de ellas.

En el caso anterior, vemos claramente el enfrentamiento entre usabilidad y seguridad; cuanto más usable una contraseña es (más fácil de recordar), más fácil suele ser de descifrar… Esta es una de las razones de muchos de los problemas de seguridad de la actualidad.

Luego nos encontramos con otros casos, donde muchos de los estándares de seguridad más importantes, son diseñados sin tener la usabilidad en mente, llevando a que sean difícil de aplicar y comprender, y hasta molestos para utilizar, tales como los controles de acceso de usuario de Windows Vista (UAC). (Esa ventanita me vuelve loco! ;-P, así que la terminé desactivando...)

El problema es claro y requiere de un factor importante que aún nos llevará mucho tiempo lograr: la educación de los usuarios. Nos encontramos hoy con unas tres generaciones de individuos utilizando computadoras: los que nacieron mucho antes de que estas existan, los que nacimos casi al mismo tiempo y tuvimos que aprenderlo durante el camino, y los que están naciendo junto a las nuevas tecnologías. Cada una de estas generaciones le dan un uso distinto a las tecnologías, y las encuentran más o menos fáciles de usar… y cuando se diseña software, se debe hacer que todos lo puedan usar, lo cual lleva a que bajemos los estándares de seguridad a fin de que incluso el usuario con menos conocimientos pueda usar los nuevos productos tecnológicos.

La única forma de lograr que los productos tengan un grado adecuado de seguridad al mismo tiempo que un alto nivel de usabilidad es a través de la educación de los usuarios en general, desde la base, enseñándoles lo que se debe hacer y lo que no, al mismo tiempo que aprenden a cómo usar las tecnologías. Solo así, lograremos que la tecnología sea segura y usable al mismo tiempo.

“is”

El Storm Worm en las primeras planas

Si hay un malware del que se viene hablando largo y tendido en cuanto blog, medio de comunicación, sitio web y demás en estos días es el famoso gusano Storm Worm (también conocido como Peacomm, Nuwar, etc).

Les dejo aquí algunos enlaces para su lectura (estar al día, es un paso más hacia nuestra protección contra el malware):

• El Storm Worm no elige sus víctimas al azar
• Análisis varios
  
• Análisis de tráfico de red del gusano
• ¿Qué tan peligroso es el Storm Worm?
  

¡Que les sea provechoso!

“is”

La importancia de una política de seguridad en las empresas

Una de las cosas que siempre me gusta destacar es que para lograr un alto nivel de seguridad informática es necesario combinar una buena estrategia de implementación y uso de software de seguridad sumada a la educación y formación.

Cuando pensamos en empresas, hay otros factores a considerar, entre ellos, la definición, implementación y constante actualización y monitoreo de una política de seguridad. En términos sencillos, una política de seguridad es una lista detallada de temas sobre lo qué se debe hacer y lo qué no se debe hacer en materia de seguridad de la información.

Incluye aspectos que cubren temas tan diversos como los procesos que deben tenerse en cuenta, el software a utilizar, seguridad física, backup (resguardo), contraseñas, autentifación, control de riesgos, protección, etc.

Resume, en un documento único, más o menos extensa, todo lo que el responsable de seguridad de la información de la empresa debe llevar adelante y controlar, así como lo que todos los recursos y empleados de la empresa deben tener en cuenta para mantener la información lo más segura posible.

Aquí les dejo algunos enlaces para explorar más en el tema:

• Sección de Políticas de Seguridad en Segu-Info
• Definición de una política de seguridad en RedIRIS
• Sección de Políticas de Seguridad en ArCERT
• Interesante post sobre Políticas de Seguridad en el Blog de Talsoft

En toda empresa se debe comprender que una política de seguridad no es necesaria, sino que es una prioridad básica, tan importante como el uso de antivirus y/o la educación de los usuarios, y si realmente quieren tener un nível de seguridad alta, deben contemplarla, implementarla y ejecutarla.

"is"

Virus Revealed: Libro sobre virus informáticos

Hay mucha literatura sobre virus informáticos, malware y seguridad de la información, pero en su gran mayoría está en inglés, salvos contados casos. Más allá de eso, hay muchos más libros sobre seguridad informática, que sobre malware.

En este caso, me encontré disponible en Internet (publicado el día de hoy por un sitio web), el libro "Virus Revealed: Understanding and Counter Malicious Software", escrito en el 2001 por David Harley, Robert Slade and Urs Gattiker.

Aunque no es lo más nuevo en cuestión de malware, dado que no contiene información sobre las novedades después del año de publicación, es una buena forma de iniciar la lectura en materia de virus informáticos y relacionados, desde sus comienzos, hasta el pasado reciente, y con bastante información conceptual, bien explicada, que ayudará a muchos a comprender mejor el mundo del malware y cómo mejorar la seguridad de sus computadoras.

Los 3 autores son ampliamente reconocidos en el ambiente de la seguridad, y tienen pergaminos suficientes como para que confíemos en los que nos cuentan en su libro. El único "problema": está en inglés... :)

"is"

PD: ¿Algún voluntario interesado en traducirlo? ;-P