Encuentran fallas CSRF en importantes sitios Web

septiembre 30, 2008 § Deja un comentario

Traducido para Segu-Info por Raúl Batista.

Investigadores de la Universidad de Princeton revelaron cuatro sitios con fallas de falsificación de requerimiento inter-sitios y revelan herramientas para protegerse de estos ataques.


SEPTEMBER 29, 2008 | Investigadores de la Universidad de Princeton revelaron hoy su descubrimiento que cuatro sitios web importantes son susceptibles al silencioso pero mortal ataque de falsificación de requerimiento inter-sitios (CSRF), incluyendo uno en el sitio INGDirect.com que permitiría a un atacante transferir dinero fuera de la cuenta bancaria de la víctima.


ING, YouTube, y MetaFilter, todos ellos han reparado esta vulnerabilidad después de haber sido alertados por los investigadores, pero al momento de escribir este reporte, el cuarto sitio, el de
The New York Times, sigue alojando la falla CSRF en su sitio Web que le permitiría a un atacante seleccionar y abusar de las direcciones de correo electrónico de los suscriptores del sitio.

Bill Zeller, un candidato al doctorado en Princeton, dice que la falla CSRF que él y su compañero investigador Edward Felton encontraron en INGDirect.com representa una de la primeras fallas CSRF en un sitio bancario que se hace pública. “Es el primer ejemplo de un ataque CSFR que permite extraer dinero de una cuenta bancaria, del que tenga conocimiento”, dijo Zeller.


La falla CSRF que encontraron en el sitio de ING permitiría a un atacante mover fondos de la cuenta de la víctima a otra cuenta que abra el atacante en nombre del usuario, sin que el usuario se de cuenta. Incluso usando una sesión SSL no protegería al usuario de tal ataque, dijeron los investigadores. “Ya que ING no protege explícitamente contra los ataques CSRF, transferir fondos de la cuenta de un usuario fue tan sencillo como reproducir los pasos que daría el usuario cuando transfiere dinero,” según un
informe escrito por Zeller y Felton.

En un ataque CSRF, el atacante puede forzar el navegador del usuario a pedir una pagina o determinada acción sin que se de cuenta el usuario, o que el sitio Web reconozca que el pedido no viene del legítimo usuario conectado. CSRF es poco entendido en la comunidad de desarrollo Web, y consecuentemente es una vulnerabilidad muy común en los sitios. “CSRF es extremadamente común. Está prácticamente en cualquier lugar que mire,” dice Jeremiah Grossman, CTO de
WhiteHat Security .

Más allá de la falla de ING, los investigadores de Princeton también encontraron vulnerabilidades CSRF en YouTube que permitirían al atacante, por ejemplo, amigarse a un usuario, agregar videos a la lista de favoritos del usuario, y enviar mensajes en nombre del usuario atacado. La falla en el sitio de blog MetaFilter le permite al atacante fijar la dirección de correo del usuario con la dirección del atacante, y entonces básicamente tomar el control de la cuenta de la víctima. Mientras que tanto YouTube como MetaFilter arreglaron sus fallas CSRF, el
The New York Times no lo hizo.

La vulnerabilidad permite que un atacante se apodere de las direcciones de correo electrónico de los usuarios registrados en el sitio y las use para enviar spam, o encontrar las direcciones de todos los usuarios que visiten un sitio que el atacante les induzca a visitar mediante un correo falso. “Este ataque es particularmente peligroso porque un gran numero de usuarios que tienen cuentas en el NYTimes y porque el NYTimes mantiene a la sesión de usuario hasta por un año,” dicen en el informe los investigadores. También encontraron que la nueva red social del Times, TimesPeople es vulnerable a los ataques CSRF.

“La gravedad de los ataques que encontramos ilustra que los desarrolladores no están tan familiarizados como debieran con este tipo de ataques,” dice Zeller.

Mientras tanto, Zeller y Felton también han desarrollado algunas herramientas para protegerse de los ataques CSRF. Produjeron un “plugin” para el Firefox para proteger al cliente, y una herramienta para agregar al entorno PHP Code Igniter, para impedir ataques en esos sitios. Zeller dice que el “plugin” para el navegador es limitado porque sólo protege las solicitudes POST inter-sitio, no las solicitudes GET. “Si hubiéramos bloqueado las solicitudes GET, muchas imágenes del sitio no funcionarían,” explicó. “[El plugin] puede proteger a los usuarios de las vulnerabilidades en sitios que no se protegen por si mismos.”

El descubrimiento de fallas CSRF en sitios Web destacados es solo la punta del iceberg de CSFR. “estamos comenzando a ver más y más de estos ataques, y creo que continuará hasta que los desarrolladores se eduquen más sobre CSRF,” dice Zeller. “Una diferencia importante entre CSRF y XSS es que XSS necesita que un desarrollador cree un agujero, un camino por el cual inyectar código en un sitio, mientras que los ataques CSRF solo requieren que el desarrollador no arregle el agujero (el cual por defecto ya existe).”

Fuente: http://www.darkreading.com/document.asp?doc_id=164854&f_src=darkreading_section_296

Encuentran fallas CSRF en importantes sitios Web

septiembre 30, 2008 § Deja un comentario

Traducido para Segu-Info por Raúl Batista.

Investigadores de la Universidad de Princeton revelaron cuatro sitios con fallas de falsificación de requerimiento inter-sitios y revelan herramientas para protegerse de estos ataques.


SEPTEMBER 29, 2008 | Investigadores de la Universidad de Princeton revelaron hoy su descubrimiento que cuatro sitios web importantes son susceptibles al silencioso pero mortal ataque de falsificación de requerimiento inter-sitios (CSRF), incluyendo uno en el sitio INGDirect.com que permitiría a un atacante transferir dinero fuera de la cuenta bancaria de la víctima.


ING, YouTube, y MetaFilter, todos ellos han reparado esta vulnerabilidad después de haber sido alertados por los investigadores, pero al momento de escribir este reporte, el cuarto sitio, el de
The New York Times, sigue alojando la falla CSRF en su sitio Web que le permitiría a un atacante seleccionar y abusar de las direcciones de correo electrónico de los suscriptores del sitio.

Bill Zeller, un candidato al doctorado en Princeton, dice que la falla CSRF que él y su compañero investigador Edward Felton encontraron en INGDirect.com representa una de la primeras fallas CSRF en un sitio bancario que se hace pública. “Es el primer ejemplo de un ataque CSFR que permite extraer dinero de una cuenta bancaria, del que tenga conocimiento”, dijo Zeller.


La falla CSRF que encontraron en el sitio de ING permitiría a un atacante mover fondos de la cuenta de la víctima a otra cuenta que abra el atacante en nombre del usuario, sin que el usuario se de cuenta. Incluso usando una sesión SSL no protegería al usuario de tal ataque, dijeron los investigadores. “Ya que ING no protege explícitamente contra los ataques CSRF, transferir fondos de la cuenta de un usuario fue tan sencillo como reproducir los pasos que daría el usuario cuando transfiere dinero,” según un
informe escrito por Zeller y Felton.

En un ataque CSRF, el atacante puede forzar el navegador del usuario a pedir una pagina o determinada acción sin que se de cuenta el usuario, o que el sitio Web reconozca que el pedido no viene del legítimo usuario conectado. CSRF es poco entendido en la comunidad de desarrollo Web, y consecuentemente es una vulnerabilidad muy común en los sitios. “CSRF es extremadamente común. Está prácticamente en cualquier lugar que mire,” dice Jeremiah Grossman, CTO de
WhiteHat Security .

Más allá de la falla de ING, los investigadores de Princeton también encontraron vulnerabilidades CSRF en YouTube que permitirían al atacante, por ejemplo, amigarse a un usuario, agregar videos a la lista de favoritos del usuario, y enviar mensajes en nombre del usuario atacado. La falla en el sitio de blog MetaFilter le permite al atacante fijar la dirección de correo del usuario con la dirección del atacante, y entonces básicamente tomar el control de la cuenta de la víctima. Mientras que tanto YouTube como MetaFilter arreglaron sus fallas CSRF, el
The New York Times no lo hizo.

La vulnerabilidad permite que un atacante se apodere de las direcciones de correo electrónico de los usuarios registrados en el sitio y las use para enviar spam, o encontrar las direcciones de todos los usuarios que visiten un sitio que el atacante les induzca a visitar mediante un correo falso. “Este ataque es particularmente peligroso porque un gran numero de usuarios que tienen cuentas en el NYTimes y porque el NYTimes mantiene a la sesión de usuario hasta por un año,” dicen en el informe los investigadores. También encontraron que la nueva red social del Times, TimesPeople es vulnerable a los ataques CSRF.

“La gravedad de los ataques que encontramos ilustra que los desarrolladores no están tan familiarizados como debieran con este tipo de ataques,” dice Zeller.

Mientras tanto, Zeller y Felton también han desarrollado algunas herramientas para protegerse de los ataques CSRF. Produjeron un “plugin” para el Firefox para proteger al cliente, y una herramienta para agregar al entorno PHP Code Igniter, para impedir ataques en esos sitios. Zeller dice que el “plugin” para el navegador es limitado porque sólo protege las solicitudes POST inter-sitio, no las solicitudes GET. “Si hubiéramos bloqueado las solicitudes GET, muchas imágenes del sitio no funcionarían,” explicó. “[El plugin] puede proteger a los usuarios de las vulnerabilidades en sitios que no se protegen por si mismos.”

El descubrimiento de fallas CSRF en sitios Web destacados es solo la punta del iceberg de CSFR. “estamos comenzando a ver más y más de estos ataques, y creo que continuará hasta que los desarrolladores se eduquen más sobre CSRF,” dice Zeller. “Una diferencia importante entre CSRF y XSS es que XSS necesita que un desarrollador cree un agujero, un camino por el cual inyectar código en un sitio, mientras que los ataques CSRF solo requieren que el desarrollador no arregle el agujero (el cual por defecto ya existe).”

Fuente: http://www.darkreading.com/document.asp?doc_id=164854&f_src=darkreading_section_296

Encuentran fallas CSRF en importantes sitios Web

septiembre 30, 2008 § Deja un comentario

Traducido para Segu-Info por Raúl Batista.

Investigadores de la Universidad de Princeton revelaron cuatro sitios con fallas de falsificación de requerimiento inter-sitios y revelan herramientas para protegerse de estos ataques.


SEPTEMBER 29, 2008 | Investigadores de la Universidad de Princeton revelaron hoy su descubrimiento que cuatro sitios web importantes son susceptibles al silencioso pero mortal ataque de falsificación de requerimiento inter-sitios (CSRF), incluyendo uno en el sitio INGDirect.com que permitiría a un atacante transferir dinero fuera de la cuenta bancaria de la víctima.


ING, YouTube, y MetaFilter, todos ellos han reparado esta vulnerabilidad después de haber sido alertados por los investigadores, pero al momento de escribir este reporte, el cuarto sitio, el de
The New York Times, sigue alojando la falla CSRF en su sitio Web que le permitiría a un atacante seleccionar y abusar de las direcciones de correo electrónico de los suscriptores del sitio.

Bill Zeller, un candidato al doctorado en Princeton, dice que la falla CSRF que él y su compañero investigador Edward Felton encontraron en INGDirect.com representa una de la primeras fallas CSRF en un sitio bancario que se hace pública. “Es el primer ejemplo de un ataque CSFR que permite extraer dinero de una cuenta bancaria, del que tenga conocimiento”, dijo Zeller.


La falla CSRF que encontraron en el sitio de ING permitiría a un atacante mover fondos de la cuenta de la víctima a otra cuenta que abra el atacante en nombre del usuario, sin que el usuario se de cuenta. Incluso usando una sesión SSL no protegería al usuario de tal ataque, dijeron los investigadores. “Ya que ING no protege explícitamente contra los ataques CSRF, transferir fondos de la cuenta de un usuario fue tan sencillo como reproducir los pasos que daría el usuario cuando transfiere dinero,” según un
informe escrito por Zeller y Felton.

En un ataque CSRF, el atacante puede forzar el navegador del usuario a pedir una pagina o determinada acción sin que se de cuenta el usuario, o que el sitio Web reconozca que el pedido no viene del legítimo usuario conectado. CSRF es poco entendido en la comunidad de desarrollo Web, y consecuentemente es una vulnerabilidad muy común en los sitios. “CSRF es extremadamente común. Está prácticamente en cualquier lugar que mire,” dice Jeremiah Grossman, CTO de
WhiteHat Security .

Más allá de la falla de ING, los investigadores de Princeton también encontraron vulnerabilidades CSRF en YouTube que permitirían al atacante, por ejemplo, amigarse a un usuario, agregar videos a la lista de favoritos del usuario, y enviar mensajes en nombre del usuario atacado. La falla en el sitio de blog MetaFilter le permite al atacante fijar la dirección de correo del usuario con la dirección del atacante, y entonces básicamente tomar el control de la cuenta de la víctima. Mientras que tanto YouTube como MetaFilter arreglaron sus fallas CSRF, el
The New York Times no lo hizo.

La vulnerabilidad permite que un atacante se apodere de las direcciones de correo electrónico de los usuarios registrados en el sitio y las use para enviar spam, o encontrar las direcciones de todos los usuarios que visiten un sitio que el atacante les induzca a visitar mediante un correo falso. “Este ataque es particularmente peligroso porque un gran numero de usuarios que tienen cuentas en el NYTimes y porque el NYTimes mantiene a la sesión de usuario hasta por un año,” dicen en el informe los investigadores. También encontraron que la nueva red social del Times, TimesPeople es vulnerable a los ataques CSRF.

“La gravedad de los ataques que encontramos ilustra que los desarrolladores no están tan familiarizados como debieran con este tipo de ataques,” dice Zeller.

Mientras tanto, Zeller y Felton también han desarrollado algunas herramientas para protegerse de los ataques CSRF. Produjeron un “plugin” para el Firefox para proteger al cliente, y una herramienta para agregar al entorno PHP Code Igniter, para impedir ataques en esos sitios. Zeller dice que el “plugin” para el navegador es limitado porque sólo protege las solicitudes POST inter-sitio, no las solicitudes GET. “Si hubiéramos bloqueado las solicitudes GET, muchas imágenes del sitio no funcionarían,” explicó. “[El plugin] puede proteger a los usuarios de las vulnerabilidades en sitios que no se protegen por si mismos.”

El descubrimiento de fallas CSRF en sitios Web destacados es solo la punta del iceberg de CSFR. “estamos comenzando a ver más y más de estos ataques, y creo que continuará hasta que los desarrolladores se eduquen más sobre CSRF,” dice Zeller. “Una diferencia importante entre CSRF y XSS es que XSS necesita que un desarrollador cree un agujero, un camino por el cual inyectar código en un sitio, mientras que los ataques CSRF solo requieren que el desarrollador no arregle el agujero (el cual por defecto ya existe).”

Fuente: http://www.darkreading.com/document.asp?doc_id=164854&f_src=darkreading_section_296

Los niños y la inseguridad informática

septiembre 30, 2008 § Deja un comentario

La inseguridad de la información siempre está atenta a descubrir el eslabón más débil de la cadena para materializarse y hacernos saber que evoluciona y aprende de nuestras propias debilidades. En este sentido, una población vulnerable a estas insinuaciones son los niños, quienes utilizan su conexión a internet para descubrir un universo de conocimiento y conversar con sus amigos; la cual, sin una adecuada orientación por parte de sus padres, puede convertirse en una pesadilla informática que impacte la salud mental o integridad física de los chicos en el mediano y largo plazo.

En este contexto, se detallan a continuación algunas recomendaciones tecnológicas y sociales que pueden ser útiles para conversar con los chicos y así, ir fojando su carácter crítico frente a los contenidos disponibles en internet, el manejo de su información privada y las buenas prácticas de uso de los recursos tecnológicos.

Algunas medidas tecnológicas
Existen programas que se denominan en el contexto de la industria, niñeras. Estas niñeras son programas que establecen un control sobre los contenidos de las páginas web que se visitan. Este tipo de estrategia, viene disponible en paquetes de seguridad para computadores personales, como son ZoneAlarm Security Suite, Norton Internet Security, Mcafee Personal Firewall Plus, Panda Internet Security, Kaspersky Internet Security, OutPost Pro Firewall, entre otros., los cuales adicional al control de contenidos, cuentan con antivirus, anti software espía y firewall. Es importante anotar que estos productos mencionados deben ser adquiridos con licenciamiento anual o según sea la oferta del proveedor. En algunas ocasiones ofrecen versiones de prueba totalmente funcionales que pueden ser descargadas y utilizadas en el computador, que luego se inhabilitan una vez el tiempo de prueba (por lo general 30 días calendario) ha concluido.

Un sistema de control de contenidos debe tener las siguientes características mínimas para que sea útil y confiable:

1. Facilidad de configuración de los filtros
2. Integración con otros sistemas de seguridad disponibles en la máquina (si éste no viene ya integrado en un paquete, como los mencionados previamente)
3. Capacidad de aprendizaje y evaluación de sitios confiables en Internet
4. Cuando no se pueda evaluar el contenido del sitio, tener la opción de bloqueo automático.
5. Registros o logs detallados de la navegación en la web
6. Ejecución silenciosa en la máquina
7. Control de acceso con contraseña al módulo de configuración

De otra parte, existen programas especializados en control de contenidos como son: CyberPatrol 7.6, Safe Eyes 5.0 y Net Nanny 5.6 los cuales, al igual que los paquetes anteriores, deben ser licenciados para su utilización en el equipo. Estos programas reúnen varias de las características deseables de un sistema de control de contenido mencionados previamente. De acuerdo con el proveedor puede haber versiones de prueba de los mismos.

La efectividad de estos programas depende de su configuración y afinamiento permanente del mismo, dado que en la red aparecen a diario nuevos sitios que se pueden camuflar para pasar desapercibidos por éstos programas. Precisamente en este sentido la característica No.4 de este tipo de sistemas.

Es importante anotar, que existen programas gratuitos de control de contenidos, que son iniciativa de personas u organizaciones que piensan en los peligros a los cuales están expuestos los chicos, los cuales presentan algunas de las características mencionadas y que por lo general, no cuentan con soporte o mantenimiento, como si lo pudiesen tener aquellos que son licenciados. Entre los más destacados tenemos:

Control Kids – http://www.controlkids.com/es/
Windows Vista Parental Control – http://www.microsoft.com/windows/windows-vista/features/parental-controls.aspx
Parental control bar – http://www.wraac.org/
Crawler Parental Control – http://www.crawlerparental.com/
Pikluk – http://www.pikluk.com

Recomendaciones para los chicos y sus padres
Si bien las medidas indicadas anteriormente nos permiten filtrar los contenidos que puedan ser impropios para los chicos, se hace necesario otro componente, que es el psicológico y social, que debe ser desarrollado por los padres de familia, adicional a las medidas de seguridad tecnológicas previamente detalladas.

Microsoft en este sentido establece un decálogo que denomina “Las 10 cosas que ud le debe enseñar a los niños para navegar con seguridad en Internet” (http://www.microsoft.com/protect/family/guidelines/rules.mspx).

A continuación detallamos el decálogo sugerido por este proveedor:

1. Anime a sus niños a compartir con usted sus experiencias al navegar por internet. Anímese a navegar con ellos.

2. Enseñe a sus niños a confiar en sus instintos. Si ellos se sienten nerviosos con cualquier cosa en su interacción en línea, ellos deben comentárselo inmediatamente.

3. Si sus chicos visitan salas de conversación (Chat rooms), usan programas de mensajería instantánea (MSN, Yahoo Messenger, Google Talk, etc) o cualquier otro programa que exija la identificación de ellos, oriéntelos para escoger su nombre y asegurar que no se revela información personal sobre ellos.

4. Insista que los chicos nunca deben dar la dirección física de su vivienda, número telefónico o cualquier otra información personal, incluidos por donde se va a su escuela o donde le gusta jugar.

5. Enseñe a sus niños que la diferencia entre lo correcto e incorrecto es la misma en internet, como lo es en la vida normal.

6. Muéstrele a los chicos como respetar a otros al interactuar en línea. Asegúrese que ellos conocen las reglas de buen comportamiento, las cuales no cambian sólo porque ahora están al frente de un computador.

7. Insista en el respeto de la propiedad de otros en internet. Explíqueles a los chicos que hacer copias ilegales de trabajos de otros, como pueden ser música, videos y otros programas, equivale a habérselos llevado sin pagar de la tienda.

8. Dígale a los niños que ellos nunca deberían reunirse en persona con sus amigos del Chat. Explíqueles que esos amigos pueden no ser quienes dicen ser.

9. Enséñele a sus niños que no todo lo que lea o vea en internet es verdad. Anímelos a preguntas y revisar el tema si no están seguros de lo que encontraron.

10. Utilice programas de control de contenidos, que permitan filtrar y monitorear los sitios que visitan sus chicos, para así revisar que estaban mirando o revisando en esos sitios.

Comentarios finales
Navegar por Internet, es como un recorrido por una ciudad que tiene lugar históricos, museos y parques, pero igualmente sitios de acceso restringido, delincuencia común y pervertidos o personas con inclinaciones impropias. Por tanto, el paseo que se den sus hijos dependerán de que tan buen guía puede ser usted en esta ciudad y de los sistemas de monitoreo y control que tenga previstos para la visita.

Más que los controles tecnológicos que se puedan implementar, es la conversación y acompañamiento de los padres a los chicos en el uso de las tecnologías de información. Que encuentren en sus padres, un motivo para conocer y descubrir la Internet, la forma de hacer amigos y desarrollar un sentido crítico de los contenidos que se puedan encontrar allí.

Si bien el control de contenidos es una estrategia que se puede utilizar para restringir el acceso a los lugares que no son adecuados para los niños, no es suficiente para ampararlos de las amenazas reinantes en la red. Se hace necesario avanzar en iniciativas gubernamentales, académicas y familiares, para que todos unidos, podamos advertirle a los maleantes que estamos preparados para enfrentarlos y denunciarlos; y que nuestros niños estarán respaldados y entrenados para evadir sus estrategias.

Fuente: http://www.eltiempo.com/participacion/blogs/default/un_articulo.php?id_blog=3516456&id_recurso=450012860&random=2131

Aventuras de un argentino en Canadá

septiembre 30, 2008 § 2 comentarios

Sé que estaban terriblemente preocupados por mi salud así que les cuento que hemos llegado a la ciudad de Ottawa para la conferencia Virus Bulletin 2008 a desarrollarse entre el 1 y el 3 de octubre. En esta ocasión estoy representando a la empresa para la que trabajo (no Segu-Info) y me acompaña la ganadora del premio anual de ESET y UTN.

Yo me encontraba en la ciudad de México DF y por ese motivo mi acompañante viajó desde Buenos Aires para encontrarnos en México y desde ahí viajar juntos a Ottawa, con escala en Toronto.

El viaje se puede resumir de la siguiente manera.

0. El vuelo sale de México DF a horario y llega a horario (con lluvia sobre la ciudad de Toronto).

1. En Toronto nos detienen durante 2 hs porque nos revisaron absolutamente todos los bolsos y electrónicos y como les quedaban dudas nos revisaron de nuevo, y de nuevo. Curiosamente los detenidos sólo eramos latinoamericanos. Durante esa revisón cada uno de nosotros dos respondía preguntas por separado para posterior verificacion de si las historias coincidian. Algunas preguntas realizadas fueron:
– ¿Qué es DF? Refiriédose a la ciudad de México DF.
– ¿Qué es mate? Refiriédose a la típica infusión argentino/uruguaya. De todos los utensillos se tomó muestra y se analizó en un laboratorio.
– ¿Sólo Ud usa este cepillo de dientes? ¿Sólo Ud, está seguro?. Vaya al laboratorio para análisis.
– Los cactus no se permiten en esta ciudad. Aclaro que colecciono cactus y llevaba algunos especímes únicos desde México. Luego de que me los tiraron encuentro que en la ciudad de Ottawa se venden cactus para regalo.
– ¿Tiene dinero en efectivo? ¿Sólo eso? ¿Tiene tarjetas de créditos? ¿Cuántas?
– ¿Siempre viaja solo? ¿Por qué?
– Revisón de cámara de fotos que no tenía fotos. ¿Por qué su camará esta vacía?
– Da vuelta el bolso donde tengo la laptop y comienza otra aventura para mí.

2. La revisión de mi laptop fue muy graciosa:
– Revisión de bateria
– Enciendala. ¿Your password please?
– ¿Qué tiene en esta laptop? Yo describiendo y ella verificando si decia la verdad
– ¿Es suya o de la empresa?
– Mirando fotos que no tengo cifradas me pregunta. ¿Cuándo estuvo en México? ¿Cuándo estuvo en Chile? Verificando las fechas de las fotos confirma que es verdad.
– Viaja mucho Ud. Verificación de sellos de pasaporte.
– ¿Está casado? ¿Tiene hijos? ¿Y mascotas?
– ¿De qué trabaja? Pregunta realizada por tercera vez… Le llama la atención que “no tenga documentos en el disco” pero no me pregunta.

3. Por ese motivo perdimos el avión de conexión a Ottawa y debimos esperar el siguiente. Ese avión salió una hora más tarde porque había una tormenta sobre Toronto. Comentarios en esta estapa: “si Ud. pierde el avión no importa… lo revisamos y luego lo ponemos en otro”.

4. Llegamos a Ottawa (milagro).

5. Tomamamos un taxi y la direccion del hotel en el cual estabamos registrados estaba mal (terrible error de mi parte). Incluso era otro hotel.

6. Tomamamos otro taxi y nos fuimos al hotel correcto.

7. Llegamos a las 12 hs al hotel y nuestras habitaciones se desocupan a las 15 hs. Ninguna sorpresa… ya me lo imagibaba de todos modos.

8. Dos hs de paseo por la ciudad de Ottawa bajo la lluvia (linda fotos) y de nuevo en el hotel (el correcto al menos).

9. Sólo una habitación se encotraba desocupada. Bueno, al menos la mitad de nosotros llegó ¿no?

10. La direccion del hotel donde se desarrollará mañana de la conferencia también estaba mal. De hecho es otro hotel. Nota mental: debo dejar de beber cuando anoto direcciones de hotel.

11. ¡UNA BUENA! El hotel (real) de la conferencia queda mas cerca del hotel (real) donde estamos en este momento.

12. En el hotel la recepcionista me preguntó ¿Where is La-ti-no-a-me-rrrri-ca?

Cosas q todavia no salieron mal:
– los aviones no se cayeron (aún)
– las tarjetas de crédito no rebotaron (aún)
– no me secuestraron el mate (aún)
– no nos rechazaron la visa (pero aun no salimos del país)
– mi inglés mejora en lo que es insultos y “piropos” a los canadienses (y a mí mismo por anotar mal las direcciones)
– la luz y wi-fi todavia no se cortaron
– aún no nos rechazaron el ingreso a la conferencia
– Como el gran hermano todo lo ve, seguramente están leyendo esto y seré deportado en breve.

Moraleja: sonríe, siempre puedes estar peor.

PD: Ottawa es una hermosa ciudad
Cristian

Aventuras de un argentino en Canadá

septiembre 30, 2008 § 1 comentario

Sé que estaban terriblemente preocupados por mi salud así que les cuento que hemos llegado a la ciudad de Ottawa para la conferencia Virus Bulletin 2008 a desarrollarse entre el 1 y el 3 de octubre. En esta ocasión estoy representando a la empresa para la que trabajo (no Segu-Info) y me acompaña la ganadora del premio anual de ESET y UTN.

Yo me encontraba en la ciudad de México DF y por ese motivo mi acompañante viajó desde Buenos Aires para encontrarnos en México y desde ahí viajar juntos a Ottawa, con escala en Toronto.

El viaje se puede resumir de la siguiente manera.

0. El vuelo sale de México DF a horario y llega a horario (con lluvia sobre la ciudad de Toronto).

1. En Toronto nos detienen durante 2 hs porque nos revisaron absolutamente todos los bolsos y electrónicos y como les quedaban dudas nos revisaron de nuevo, y de nuevo. Curiosamente los detenidos sólo eramos latinoamericanos. Durante esa revisón cada uno de nosotros dos respondía preguntas por separado para posterior verificacion de si las historias coincidian. Algunas preguntas realizadas fueron:
– ¿Qué es DF? Refiriédose a la ciudad de México DF.
– ¿Qué es mate? Refiriédose a la típica infusión argentino/uruguaya. De todos los utensillos se tomó muestra y se analizó en un laboratorio.
– ¿Sólo Ud usa este cepillo de dientes? ¿Sólo Ud, está seguro?. Vaya al laboratorio para análisis.
– Los cactus no se permiten en esta ciudad. Aclaro que colecciono cactus y llevaba algunos especímes únicos desde México. Luego de que me los tiraron encuentro que en la ciudad de Ottawa se venden cactus para regalo.
– ¿Tiene dinero en efectivo? ¿Sólo eso? ¿Tiene tarjetas de créditos? ¿Cuántas?
– ¿Siempre viaja solo? ¿Por qué?
– Revisón de cámara de fotos que no tenía fotos. ¿Por qué su camará esta vacía?
– Da vuelta el bolso donde tengo la laptop y comienza otra aventura para mí.

2. La revisión de mi laptop fue muy graciosa:
– Revisión de bateria
– Enciendala. ¿Your password please?
– ¿Qué tiene en esta laptop? Yo describiendo y ella verificando si decia la verdad
– ¿Es suya o de la empresa?
– Mirando fotos que no tengo cifradas me pregunta. ¿Cuándo estuvo en México? ¿Cuándo estuvo en Chile? Verificando las fechas de las fotos confirma que es verdad.
– Viaja mucho Ud. Verificación de sellos de pasaporte.
– ¿Está casado? ¿Tiene hijos? ¿Y mascotas?
– ¿De qué trabaja? Pregunta realizada por tercera vez… Le llama la atención que “no tenga documentos en el disco” pero no me pregunta.

3. Por ese motivo perdimos el avión de conexión a Ottawa y debimos esperar el siguiente. Ese avión salió una hora más tarde porque había una tormenta sobre Toronto. Comentarios en esta estapa: “si Ud. pierde el avión no importa… lo revisamos y luego lo ponemos en otro”.

4. Llegamos a Ottawa (milagro).

5. Tomamamos un taxi y la direccion del hotel en el cual estabamos registrados estaba mal (terrible error de mi parte). Incluso era otro hotel.

6. Tomamamos otro taxi y nos fuimos al hotel correcto.

7. Llegamos a las 12 hs al hotel y nuestras habitaciones se desocupan a las 15 hs. Ninguna sorpresa… ya me lo imagibaba de todos modos.

8. Dos hs de paseo por la ciudad de Ottawa bajo la lluvia (linda fotos) y de nuevo en el hotel (el correcto al menos).

9. Sólo una habitación se encotraba desocupada. Bueno, al menos la mitad de nosotros llegó ¿no?

10. La direccion del hotel donde se desarrollará mañana de la conferencia también estaba mal. De hecho es otro hotel. Nota mental: debo dejar de beber cuando anoto direcciones de hotel.

11. ¡UNA BUENA! El hotel (real) de la conferencia queda mas cerca del hotel (real) donde estamos en este momento.

12. En el hotel la recepcionista me preguntó ¿Where is La-ti-no-a-me-rrrri-ca?

Cosas q todavia no salieron mal:
– los aviones no se cayeron (aún)
– las tarjetas de crédito no rebotaron (aún)
– no me secuestraron el mate (aún)
– no nos rechazaron la visa (pero aun no salimos del país)
– mi inglés mejora en lo que es insultos y “piropos” a los canadienses (y a mí mismo por anotar mal las direcciones)
– la luz y wi-fi todavia no se cortaron
– aún no nos rechazaron el ingreso a la conferencia
– Como el gran hermano todo lo ve, seguramente están leyendo esto y seré deportado en breve.

Moraleja: sonríe, siempre puedes estar peor.

PD: Ottawa es una hermosa ciudad
Cristian

¿Todavía es necesario ejecutar escaneos programados en máquinas protegidas por sistemas antivirus?

septiembre 30, 2008 § Deja un comentario

Traducido para Segu-Info por Raúl Batista.

Un compañero profesional de TI dijo que nunca más sería necesario ejecutar un escaneo de virus en una PC porque la mayoría de los antivirus escanean el sistema en tiempo real, ¿es cierto esto?

Si bien es cierto que los sistemas antivirus escanean la mayoría de los archivos verificando que se cumplan las condiciones establecidas por las firmas más nuevas instaladas, no escanean el sistema de archivos en tiempo real. El sistema de archivos es monitoreado efectivamente por accesos y manipulaciones de archivos de una forma que el programa antivirus considera que es una amenaza.

Bueno, analicemos estos hechos. He asistido a varias conferencias de seguridad de TI y leído más que suficiente del material de referencia sobre Hawking y técnicas forenses para proteger de intrusiones a las computadoras. Aunque no hay una biblia en este tema, la mayoría de los profesionales de TI que conozco, que tienen bastante exposición en estos temas, están de acuerdo en que ningún producto antispam o antivirus puede atraparlo todo.

Por ejemplo, no estoy escogiendo a Symantec específicamente, ni voy a citar un ejemplo preciso, pero este asunto sucedió de verdad. El antivirus tiene las últimas firmas actualizadas. El servidor fue emparchado con las últimas actualizaciones críticas y recomendadas. Sin embargo, había un alto uso de memoria en el servidor en cuestión. Fue solo después de escrutarlo con Process Explorer de Systinternals, PsList (también de Sysinternals) Netstat, Task Manager, una conexión remota de archivo UNC, y un escáner remoto de puertos que pude confirmar que había una intento de intrusión en progreso.

El servidor había sido emparchado apenas después de unas 16 horas que se había publicado un parche para una vulnerabilidad conocida. A través de este diminuto agujero, sucedió un ataque de elevación de privilegios. Luego se instaló una herramienta de intrusión y se plantó un “rootkit”.

El “rootkit” ocultó claves del registro, procesos y archivos. Una vez descubierto, fue eliminado con suficiente facilidad mediante herramientas conocidas.

Sin embargo quedaron otros problemas (esto fue confirmado por las fechas de archivos y verificando las copias de resguardo) y resultó que otro troyano, que el AV supuestamente podía detectar y limpiar, permaneció en la máquina. Aquí es donde viene la parte interesante. El troyano en realidad no fue eliminado. Hubo errores humanos en los cuales los registros no fueron escrutados para confirmar que el intento de limpieza en realidad había fallado. Este troyano no era la misma iteración que detectaba el antivirus. Mientras el servidor comenzó a ser monitoreado con filemon, psexplorer vigilando los hilo de ejecución, y netstat, la infección original permanecía allí.

Se envió anónimamente una copia al fabricante del AV y en pocas horas, publicaron un “rapid release” que atrapaba el archivo infectado con la protección de tiempo real. El fabricante del AV dijo que era la misa iteración de un virus conocido, pero un programador de un fabricante de AV de la competencia citó diferencias en la mutación.

Mientras sucedía esto, otro sistema fue infectado así que se procedió de la misma forma para monitorearlo. Se realizó un escaneo en tiempo real antes que apareciera el “rapid release”, y el archivo fue puesto en cuarentena exitosamente.

Claramente, las compañías de AV están haciendo lo mejor que pueden para actualizar su documentación precisamente a medida que se sale la información, pero la solución es crítica y usualmente se publica más rápido. En parte, es por esto que quizás los fabricantes acepten envíos anónimos de archivos, para ayudar a mantenerlos actualizados con los virus que hay “sueltos”.

Lo que quiero señalar es que el escaneo de antivirus en tiempo real no detecta todo. Para ser honesto, a un escaneo programado también puede escapársele un virus, pero si un archivo tiene síntomas similares a un virus conocido, podría tener código oculto adicional o funcionalidad que se pueda ocultar de los escáneres actuales de tiempo real.

Así que mi respuesta a la pregunta es SI, los escaneos programados en las PC son altamente recomendables como parte de su estrategia de defensa en profundidad contra el Spyware, malware, troyanos y virus.

Autor: Brad Bird

Fuente: http://blogs.techrepublic.com.com/security/?p=607

¿Dónde estoy?

Actualmente estás viendo los archivos para septiembre, 2008 en Seguridad Informática.