Actualmente, las botnets se han convertido en una de las herramientas principales para el cibercrimen, dado que otorgan la posibilidad de realizar ataques a gran escala desde todos los sistemas infectados y de forma anónima.
Una botnet es una red de equipos infectados por códigos maliciosos que siendo controlados por un atacante, disponen de sus recursos para que trabajen de forma conjunta y distribuida. Cuando una computadora ha sido afectada por un malware de tipo bot se dice que se trata de un equipo robot o zombi.
Al controlar los sistemas remotamente (total o parcialmente), los dueños de las botnets pueden disponer de éstas para llevar a cabo diversas tareas maliciosas. Entre las principales se encuentra el envío de spam, la realización de ataques de denegación de servicio distribuido (DDoS), el alojamiento de archivos para sitios web (material pornográfico, pedófilo, warez, cracks, sitios de phishing, etc.), distribución e instalación de nuevo malware y abuso de publicidad online.
A continuación detallamos cuáles son los indicios que pueden indicar que nuestro equipo forma parte de una botnet. Cabe destacar que si bien cualquier código malicioso puede causar casi todos los síntomas de un bot, aún así, hay algunos signos que no deben pasarse por alto:
1. El ventilador arranca a toda marcha cuando el equipo está inactivo: Esto puede indicar que un programa se está ejecutando sin el conocimiento del usuario y que se están utilizando una cantidad considerable de recursos. Por supuesto, esto también podría ser producto de la instalación de actualizaciones de Microsoft, por ejemplo. Otro problema que puede hacer que el ventilador trabaje es el exceso de suciedad en el equipo o un ventilador de la CPU fallando.
2. Su equipo tarda mucho tiempo para apagarse, o no lo hace correctamente: Con frecuencia el malware posee errores que pueden causar una variedad de síntomas, incluyendo que el apagado del sistema sea muy largo o directamente falle. Desafortunadamente, los errores del sistema operativo o conflictos con programas legítimos también pueden causar el mismo síntoma.
3. Observar contenidos en su muro de Facebook que no has enviado: Existen algunas otras razones distintas al malware o el acceso no autorizado a la cuenta para que aparezca este problema. Si ve que ocurre, definitivamente deberá cambiar su contraseña y asegurarse que el sistema no está infectado. Lo ideal es asegurarse que la computadora no tiene malware antes de cambiar la contraseña y no usar la clave de Facebook en varios sitios distintos.
4. Las aplicaciones andan muy lento: Esto puede ocurrir porque programas ocultos estén utilizando una gran cantidad de recursos del equipo. Pero también podría ser causado por otros problemas.
5. No se pueden descargar las actualizaciones del sistema operativo: (siempre y cuando el sistema operativo sea legitimo) Este es un síntoma que no se puede ignorar. Incluso si no está siendo causado por un bot u otro malware, si no mantiene los parches de seguridad actualizados el sistema se va a infectar.
6. No se pueden descargar actualizaciones del antivirus o visitar sitios web de los proveedores: El malware a menudo trata de evitar que soluciones antivirus o de seguridad sean instaladas o ejecutadas. La imposibilidad de actualizar el antivirus o de visitar el sitio web del fabricante es un muy fuerte indicador de la presencia de código malicioso.
7. El acceso a Internet es muy lento: Si un bot está en ejecución en el sistema para, por ejemplo, enviar grandes cantidades de spam, realizar un ataque contra otros equipos o subir/bajar gran cantidad de datos, puede causar que el acceso a Internet sea muy lento.
8. Sus amigos y familiares han recibido mensajes de correo electrónico que usted no envió: Esto puede ser señal de un bot u otro tipo de malware, o bien que su cuenta de correo web haya sido comprometida por un atacante.
9. Se abren ventanas emergentes y anuncios, incluso cuando no se está usando un navegador web: Si bien este es un clásico signo de adware, los bots pueden instalar este programa malicioso en el equipo. Definitivamente debe atender este problema.
10. El Administrador de tareas de Windows muestra programas con nombres o descripciones extrañas: El uso del Administrador de Tareas requiere cierta habilidad e investigación. A veces software legítimo puede utilizar nombres extraños. Una entrada en el Administrador de Tareas no es suficiente para identificar un programa como dañino. Si bien puede ayudar a encontrar software malicioso, deben realizarse otros pasos adicionales para validar los resultados. Eliminar procesos, archivos o entradas del registro sólo porque se sospecha que es un bot u otro malware, puede resultar en que el equipo ni siquiera inicie. Tenga mucho cuidado al hacer suposiciones y tomar acciones sobre ellas.
“Si bien estas señales pueden ser también indicadores de otro tipo de código malicioso, son signos de relevancia que alertan sobre la posible infección del equipo. Para confirmar si efectivamente se trata de una botnet, lo recomendable es explorar el equipo con una solución antivirus”.
Fuente http://vulnerabilityteam.blogspot.com/
Comunidad dedicada a la seguridad de información (noticias, foros, charlas, actualidad)
Bienvenido a la Comunidad Ethical Shields
Ethical Shields les da la bienvenida a nuestra comunidad, queremos invitarlos a compartir sus experiencias, noticias en el ambito de seguridad de información. Esta comunidad se enriquece con sus comentarios, y en ella estaremos publicando todo lo relacionado con esta importante tema. Aqui podras ver las ultimas noticias de interes, compatir con otros profesionales y estudiantes del area, experiencias, casos, anecdotas y podras estar en contactos con nuestros especialistas en el area.
Para mas información sobre nosotros visita www.ethicalshields.com
Para mas información sobre nosotros visita www.ethicalshields.com
Mostrando entradas con la etiqueta hacking. Mostrar todas las entradas
Mostrando entradas con la etiqueta hacking. Mostrar todas las entradas
lunes, 30 de agosto de 2010
Como saber si nuestro equipo es parte de una Botnet
Etiquetas:
botnet,
hacking,
Vulnerabilidades
jueves, 12 de agosto de 2010
Hackean automóviles a través de sensores de presión de aire
Hace algunas semanas una investigación conjunta de la Universidad de Washington y la Universidad de California San Diego, demostró que es posible “hackear” la Unidad de Control Electrónico de un automóvil (ECU en inglés, lo que muchos llaman “computador de a bordo”) dándole a los atacantes la posibilidad de jugar con los controles, ya sea tocando la bocina o cortando los frenos.
Lo anterior no sonaba tan inquietante porque si hay un cracker conectado por puerto serial RS232 a tu auto sería difícil no notarlo. Sin embargo ahora las cosas cambiaron, cuando una reciente publicación de la Universidad Rutgers y la Universidad de Carolina del Sur demostró que puede hacerse todo eso remotamente, usando los sensores inalámbricos de presión en los neumáticos.
Desde el año 2008, la regulación estadounidense requiere la presencia de sensores wireless en los neumáticos que informen la Unidad de Control Electrónico de la presión de aire, cosa de desplegar una alerta cuando ésta marque niveles inusuales que signifiquen algún peligro.
En la mentada investigación se explica que con un equipo de USD 1.500 (contando sensores de radio y software especial) se puede detectar y espiar los sensores inalámbricos de autos cercanos. Además, tales sensores tienen un ID único, por lo que provisto que se tuviera acceso a una cantidad suficiente de equipos de detección, se podría monitorear la posición aproximada de un vehículo sin que su dueño lo sospechara.
Además de rastrear el móvil, se puede usar los sensores neumáticos para inyectar información errónea en la ECU, y eventualmente provocar una falla que dejara el auto temporalmente inutilizado. Ahora en las películas de espionaje en vez de mostrar tiroteos en movimiento bastará un geek premunido de un netbook para detener al vehículo rival. Pero hey, también tiene usos positivos: A lo mejor la policía podría usar un sencillo control remoto para detener cualquier auto que intentara eludir un control.
Actualmente, los sensores neumáticos envían información a la ECU cada 60 o 90 segundos, por lo que hay una ventana muy precisa en la cual se podría causar un daño real. Sin embargo este experimento -presentado en la conferencia USENIX- demuestra que como mínimo los computadores de a bordo fueron diseñados con estándares de seguridad demasiado relajados.
tomado de fayerwayer.com
Lo anterior no sonaba tan inquietante porque si hay un cracker conectado por puerto serial RS232 a tu auto sería difícil no notarlo. Sin embargo ahora las cosas cambiaron, cuando una reciente publicación de la Universidad Rutgers y la Universidad de Carolina del Sur demostró que puede hacerse todo eso remotamente, usando los sensores inalámbricos de presión en los neumáticos.
Desde el año 2008, la regulación estadounidense requiere la presencia de sensores wireless en los neumáticos que informen la Unidad de Control Electrónico de la presión de aire, cosa de desplegar una alerta cuando ésta marque niveles inusuales que signifiquen algún peligro.
En la mentada investigación se explica que con un equipo de USD 1.500 (contando sensores de radio y software especial) se puede detectar y espiar los sensores inalámbricos de autos cercanos. Además, tales sensores tienen un ID único, por lo que provisto que se tuviera acceso a una cantidad suficiente de equipos de detección, se podría monitorear la posición aproximada de un vehículo sin que su dueño lo sospechara.
Además de rastrear el móvil, se puede usar los sensores neumáticos para inyectar información errónea en la ECU, y eventualmente provocar una falla que dejara el auto temporalmente inutilizado. Ahora en las películas de espionaje en vez de mostrar tiroteos en movimiento bastará un geek premunido de un netbook para detener al vehículo rival. Pero hey, también tiene usos positivos: A lo mejor la policía podría usar un sencillo control remoto para detener cualquier auto que intentara eludir un control.
Actualmente, los sensores neumáticos envían información a la ECU cada 60 o 90 segundos, por lo que hay una ventana muy precisa en la cual se podría causar un daño real. Sin embargo este experimento -presentado en la conferencia USENIX- demuestra que como mínimo los computadores de a bordo fueron diseñados con estándares de seguridad demasiado relajados.
tomado de fayerwayer.com
Etiquetas:
hacking,
vulnerabilidad
martes, 10 de agosto de 2010
OWASP: Guias básicas de prevención y protección
El proyecto OWASP ha publicado una serie de guias basicas para la prevencion y proteccion relacionadas a diferentes campos dentro de la seguridad, las que nos pueden ayudar a la hora de asegurar nuestras aplicaciones web para tener todos y cada uno de los frentes controlado.
* Cheat Sheet de Autenticación - En esta hoja veremos reflejadas tanto las buenas prácticas para un proceso de autenticación como gestión de sesiones. Puntos como la implementación de un adecuado mecanismo de recuperación de contraseña, mensajes de error provocados por una autenticación fallida, cifrado de las comunicaciones...
* Cheat Sheet para prevención de ataques CSRF - El famoso Cross-Site Request Forgery, que últimamente tanto se usa, pero que suele llevar a equívocos sobre su concepto y relación con los Cross-Site Scriptings (XSS). En esta hoja además se enumeran aquellas medidas que realmente no consiguen prevenir los CSRF.
* Cheat Sheet sobre almacenamiento criptográfico - Hay que tener cuidado con los datos que almacenamos, tanto por la confidencialidad como por la integridad de la información sensible que maneje nuestra aplicación. Se proponen una serie de reglas a tener en cuenta a la hora de implantar una solución de tratamiento de la información. Es un buen resumen, aunque se recomienda en primer lugar también la Guía de Criptografía también dentro del proyecto OWASP.
* Cheat Sheet para prevención de inyecciones SQL - No hay que quedarse únicamente con la recomendación de validar todos los valores de entrada que proporcionen los usuarios, hay otras medidas que se recomienda encarecidamente llevar a cabo, como es el uso de procedimientos almacenados y peticiones SQL previamente parametrizadas.
* Cheat Sheet de protección de la capa de transporte - Este documento está bastante ligado también al de almacenamiento criptográfico. Las reglas que se nos proponen están enfocadas a las comunicaciones de nuestra aplicación web, que partes deben asegurarse y cómo, seguridad en los certificados del servidor, etc. Punto muy importante, cuando todavía a día de hoy seguimos encontrando formularios de login, registro y demás que siguen siendo válidos si los utilizamos mediante HTTP.
* Cheat Sheet para prevención de Cross-Site Scripting - Que decir del Cross-Site Scripting, una vulnerabilidad en muchas ocasiones infravalorada, pero con un poco de astucia puede hasta hacerte salir en los periódicos. En esta ocasión, a diferencia de las inyecciones SQL, aquí lo más importante es validar correctamente los parámetros. Documento que si acompañamos de la famosa cheat sheet de RSnake, podremos estar mucho más tranquilos.
fuente: securitybydefault.com
* Cheat Sheet de Autenticación - En esta hoja veremos reflejadas tanto las buenas prácticas para un proceso de autenticación como gestión de sesiones. Puntos como la implementación de un adecuado mecanismo de recuperación de contraseña, mensajes de error provocados por una autenticación fallida, cifrado de las comunicaciones...
* Cheat Sheet para prevención de ataques CSRF - El famoso Cross-Site Request Forgery, que últimamente tanto se usa, pero que suele llevar a equívocos sobre su concepto y relación con los Cross-Site Scriptings (XSS). En esta hoja además se enumeran aquellas medidas que realmente no consiguen prevenir los CSRF.
* Cheat Sheet sobre almacenamiento criptográfico - Hay que tener cuidado con los datos que almacenamos, tanto por la confidencialidad como por la integridad de la información sensible que maneje nuestra aplicación. Se proponen una serie de reglas a tener en cuenta a la hora de implantar una solución de tratamiento de la información. Es un buen resumen, aunque se recomienda en primer lugar también la Guía de Criptografía también dentro del proyecto OWASP.
* Cheat Sheet para prevención de inyecciones SQL - No hay que quedarse únicamente con la recomendación de validar todos los valores de entrada que proporcionen los usuarios, hay otras medidas que se recomienda encarecidamente llevar a cabo, como es el uso de procedimientos almacenados y peticiones SQL previamente parametrizadas.
* Cheat Sheet de protección de la capa de transporte - Este documento está bastante ligado también al de almacenamiento criptográfico. Las reglas que se nos proponen están enfocadas a las comunicaciones de nuestra aplicación web, que partes deben asegurarse y cómo, seguridad en los certificados del servidor, etc. Punto muy importante, cuando todavía a día de hoy seguimos encontrando formularios de login, registro y demás que siguen siendo válidos si los utilizamos mediante HTTP.
* Cheat Sheet para prevención de Cross-Site Scripting - Que decir del Cross-Site Scripting, una vulnerabilidad en muchas ocasiones infravalorada, pero con un poco de astucia puede hasta hacerte salir en los periódicos. En esta ocasión, a diferencia de las inyecciones SQL, aquí lo más importante es validar correctamente los parámetros. Documento que si acompañamos de la famosa cheat sheet de RSnake, podremos estar mucho más tranquilos.
fuente: securitybydefault.com
Etiquetas:
ataques CSRF,
Cross-Site Scripting,
hacking,
Seguridad,
SQL inyection
Suscribirse a:
Entradas (Atom)