Encuentran fallas CSRF en importantes sitios Web

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

www.segu-info.com.ar

Encuentran fallas CSRF en importantes sitios Web

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

www.segu-info.com.ar

Encuentran fallas CSRF en importantes sitios Web

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

www.segu-info.com.ar

Aventuras de un argentino en Canadá

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

www.segu-info.com.ar

Aventuras de un argentino en Canadá

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

www.segu-info.com.ar

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

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

www.segu-info.com.ar

Uno de cada diez menores ha sentido miedo cuando navegaba por internet

El informe EU Kids On line recoge el uso que hacen los niños europeos de la red.

Un equipo de la UPV ha participado en este estudio sobre nuevas tecnologías

Los niños españoles están por debajo de la media europea en el uso de la red. La emplean para comunicarse con amigos, buscar información o divertirse.

El 11% de los menores españoles que navegan por internet ha sentido miedo, según el informe de EU Kids On line en el que participan un grupo de investigación de la UPV/EHU. En el proyecto EU Kids On line (niños europeos en la red) toman parte investigadores de 20 países, entre los que se encuentran los profesores de la UPV/EHU del Departamento de Periodismo Carmelo Garitaonaindía y de Sociología Maialen Garmendia. El informe es fruto de 250 estudios empíricos realizados en 21 países europeos y en el mismo se abordan temas como el uso de internet por los niños, percepciones de riesgo y mediación parental.

El uso de internet por parte de los menores en España se sitúa en el 37%, un porcentaje “relativamente bajo” respecto a la media europea (50%), según los datos del Eurobarómetro 2005. Los niños europeos usan de igual modo internet en el hogar que en el colegio, aunque cuanto más lo utilizan en casa “más tienden a usarlo en la escuela y viceversa”.

El estudio recoge que los menores utilizan la red “como recurso para la educación, el entretenimiento, para buscar información en general y como medio socializador para compartir experiencias con personas que se encuentran en otras partes del mundo”.

Un uso que, según EU Kids On line, “puede acarrear diversos riesgos”. “El más común es ofrecer información personal porque afecta a la mitad de los adolescentes online en Europa”, explica Garmendia. Le sigue la posibilidad de acceder a contenidos pornográficos (40%), visualizar contenidos violentos que incitan al odio (33%), bullying, acoso o persecuciones obsesivas (20%) y los comentarios sexuales no deseados (10%). Sin embargo, uno de cada cuatro adolescentes de Noruega, Reino Unido y Suecia sufre este tipo de riesgos, y la mitad de los internautas jóvenes en Polonia.

Por otro lado, el riesgo menos frecuente es la cita con desconocidos (1 de cada 11). En el caso de España este tipo de citas afectan al 15,1% de los adolescentes entre 15 y 17 años, mientras que en menores de 12 a 14 años el porcentaje desciende hasta el 8,2%.

En este sentido, un 11% de los menores que se han conectado alguna vez a internet han sentido “miedo on line” y un 36% ha desconectado alguna vez el ordenador “porque se sentían incómodos con las personas con las que estaba chateando”. Ante esta preocupación, los padres prohiben a sus hijos dar información personal, especialmente si se trata de niñas, que llega al 63% de los casos frente a un 42% de los niños.

El informe recoge además que los padres prefieren “medidas sociales” para controlar el uso de internet de sus hijos. Aunque la mediación parental aumenta hasta los 10 y 11 años de edad, a partir de ahí tiende a relajarse endureciéndose el control para la televisión. Según ha explicado la profesora del departamento de Sociología de la UPV, Maialen Garmendia, “los padres controlan más los contenidos de la televisión y han establecido unas normas para su uso en un 49,7% de los casos, pero son menos los que establecen esas reglas para el uso de internet, un 40,1%”.

Entre las estrategias que usan los progenitores españoles para mediar en las actividades on line de sus hijos, destacan las limitaciones de tiempo o sentarse con ellos para navegar, frente a los mecanismos técnicos de monitorización por software. Además, los datos evidencian que los padres que más controlan estas actividades de sus hijos son los de mayor estatus social, igual que ocurre en casi toda Europa.

Fuente: http://argijokin.blogcindario.com/2008/09/09489-uno-de-cada-diez-menores-ha-sentido-miedo-cuando-navegaba-por-internet.html

www.segu-info.com.ar

Redes sociales e información pública

Este post, aunque ya se ha hablado mucho sobre este tema, va a tratar sobre ese gran contenedor de información que es Internet y las redes sociales.

Ahora bien, ¿qué pasa con la información de Internet?, generalmente el usuario da por buena cualquier información que encuentre sobre un tema determinado. Podría ser cierto, pero… ¿nos podemos fiar?, si somos un poco paranoicos…

¿Qué pasa con las redes sociales?

Si intentamos darnos de alta en una red social, sólo nos piden nombre y apellidos (cosa muy fácil de mentir) y una dirección de correo electrónico (siempre se pueden crear cuantas anónimas o con nombres falsos), y una fecha de nacimiento. Con estos datos, yo mismo podría hacerme pasar por cualquier persona y difundir datos falsos, despectivos o incluso incriminatorios de una persona pública o de una empresa. Porque… ¿por qué no hacerme pasar por George Bush o Vladímir Putin?, o por ejemplo podría hacerme pasar por un ingeniero del CERN (que ahora está muy de moda) y lanzar rumores sobre el funcionamiento del mismo o incluso por qué no, del fin del mundo?

¿Cuánto daño puede hacer una información falsa en Internet?,

Depende, ya que influyen muchos factores: repetición, medio de publicación, etc. Por eso se hace cada vez más necesario el poder conocer y cuantificar la mayor cantidad de información que esté “circulando” por la red, para poder detectar y mitigar en la medida de lo posible estos riesgos.

José María Arce Guillén
S21sec labs

Fuente: http://blog.s21sec.com/2008/09/redes-sociales-e-informacin-pblica_24.html

www.segu-info.com.ar

Spam malicioso “agrega a un amigo” de Facebook

La empresa de seguridad Websense advierte sobre este nuevo engaño.

Websense Security Labs informó de una nueva campaña de spam de ingeniería social que se hace pasar como un correo electrónico oficial enviado por el popular sitio de redes sociales Web 2.0, Facebook.

El correo parece provenir del dominio facebookmail.com, un dominio oficial utilizado por Facebook para enviar correos para notificar a sus usuarios sobre un evento.

Es común que Facebook envíe un correo electrónico para notificar a sus usuarios cuando otro usuario los agrega como amigos a la red social. Sin embargo, los creadores de spam incluyeron un archivo zip adjunto que afirma contener una fotografía para hacer que el receptor dé doble clic en él. El archivo adjunto es realmente un caballo de Troya.

Se incluye una página de inicio a Facebook en el cuerpo del mensaje. Hemos alertado antes sobre nuestro descubrimiento a través del sistema HoneyJax de una campaña de phishing viral de Facebook, y por lo tanto no nos sorprende si la página de inicio presentada es un una página falsa usada para el sitio de phishing.

Un análisis del código fuente de la forma HTML muestra que contenía el nombre de usuario y contraseña para Facebook. Esto podría utilizarse para aumentar la legitimidad del correo electrónico para evadir los filtros de spam basados en reputación.

Fuente: http://www.identidadrobada.com/site/index.php?idSeccion=19&idNota=1976

www.segu-info.com.ar

El motor de navegador WebKit ganador en el test Acid3, reclama el puesto No. 1

Traducido para Segu-Info por Raúl Batista.

Los desarrolladores que trabajan en el WebKit anunciaron al final de la semana pasada que la última versión del motor de navegador, el cual es el motor tanto del Safari de Apple como del Chrome de Google, ha ganado en todos los requerimientos de un importante test de estándares Web.

“WebKit es el primer motor de navegador que pasa todas las pruebas del Acid3,” dijo el desarrollador Maciej Stachowiak en el blog del WebKit.

La afirmación está relacionada al último alarde de Marzo de los desarrolladores de WebKit que dijeron que el motor de navegador había calificado con 100 sobre100 en la prueba Acid3. La prueba, que fue aprobada en marzo último por el Proyecto de Estándares Web, está diseñada para verificar cuan cerca cumple un navegador los estándares, particularmente las especificaciones para las aplicaciones Web 2.0, así como también los estándares relacionados con DOM (Modelo de Objeto de Documento), CSS2 (Cascading Style Sheets) y SVG (Gráficos de Vector Escalables).

El último jueves, sin embargo, Stachowiak dijo que la última versión también alcanzó el requerimiento de “animación suave” del Acid3, algo en lo que fallaron en marzo, completando cada test en menos de .033 milisegundos. Cuando un navegador finaliza cada prueba en ese tiempo o menos, Acid3 muestra el mensaje “Ningún error JS [JavaScript] ni problemas de tiempo” en una ventana emergente.

WebKit provee el corazón del motor no sólo para el Safari, sino que desde comienzos de este mes, también del Chrome de Google . El navegador de Google, sin embargo, depende de una versión más Antigua del WebKit que aquella promocionada por Stachowiak.

Computerworld probó el WebKit más nuevo, el build r36882, en una máquina virtual corriendo Windows XP SP3 en una iMac con un procesador Intel 2.4GHz Core 2 Duo. Aunque WebKit obtuvo un 100 perfecto, no pudo completar en la máquina virtual todas las pruebas en el tiempo requerido; una prueba falló repetidamente en alcanzar el límite de 0.33 milisegundos.

Sin embargo, cuando la se probó la versión más nueva de WebKit para Mac OS X, el build r37012, en la misma máquina, consiguió el 100 y terminó cada prueba debajo de la marca de los 0.33ms, confirmando la afirmación de Stachowiak.

Las pruebas de Computerworld también confirmaron que su declaración respecto que ningún otro navegador importante puede alcanzar la marca del WebKit en Acid3. En la máquina virtual Windows XP SP3, todas las versiones de producción y las preliminares estas últimas indicadas por su número de versión o estado entre paréntesis, consiguieron menos de 90 puntos en la prueba.

Los resultados fueron:
WebKit, (r36882) — 100
Firefox 3.1, (nightly) — 89
Opera 9.6, (RC1) — 85
Opera 9.52 — 84
Chrome, (0.2.153.1) — 79
Safari 3.1.2 — 75
Firefox 3.0.3 — 71
IE8 (Beta 2) — 21
IE7 — 12

El único otro navegador en reclamar un puesto en la prueba Acid3 ha sido el Opera, que dijo hace seis meses que una versión de su aplicación de bandera consiguió los 100 puntos.

En noticias relacionadas, Stachowiak también reveló recientemente que una modernización importante en el motor de JavaScript del motor WebKit, apodado “SquirrelFish Extreme,” fue más del doble de rápido que su predecesor, y tres veces más rápido que el motor incluido en la edición actual del Safari.

Los comentarios de Stachowiak siguieron a las afirmaciones similares hechas por Mozilla el último mes, cuando la compañía describió las importantes aumentos de velocidad de su proyecto TraceMonkey. Mozilla planea agregar el TraceMonkey a la próxima edición, Firefox 3.1, previsto para lanzarse en algún momento de este final de año o comienzos de 2009.

Según los informes, Apple integrará las nuevas versiones de WebKit en su navegador Safari 4, que ha sido proporcionado a algunos desarrolladores para pruebas y se espera que sea lanzado públicamente con el Mac OS X 10.6, conocido como “Snow Leopard,” la próxima versión del sistema operativo de la compañía. Snow Leopard, el cual dijo Apple que liberará en algún momento del próximo año , se enfocará en mejoras de estabilidad y performance, más que en añadir más características al sistema operativo.

Autor: Gregg Keizer

Fuente: http://www.networkworld.com/news/2008/092908-webkit-browser-engine-aces-acid3.html?inform?ap1=rcb

www.segu-info.com.ar