Wednesday, 2 November 2016

Por qué NO deberías pagar el rescate a los creadores de malware

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/por-que-no-deberias-pagar-el-rescate-los-creadores-de-malware/
TAGS: Malware, Ransom
A menudo, cuando hablamos de los ransomware que cifran archivos, recomendamos que las víctimas no paguen el rescate. Para empezar, el pago anima a los creadores de malware a continuar con su negocio. Es la ley de la oferta y la demanda: si paga más gente, aumentará el volumen de mercado, lo que conducirá a la creación de más malware (y todos tendremos más problemas).

no-no-ransom-ig-recuperado_es_edited

Además, pagar el rescate no garantiza que vayas a recuperar tus archivos sanos y salvos. Piénsalo un minuto: estas personas son delincuentes que ya te han engañado al infectar tu ordenador con malware muy peligroso para robar tus archivos. ¿Cuáles son las posibilidades de que se vuelvan honorables después de recibir el pago?

¿Suena pesimista? Quizá, pero nuestro reciente estudio lo confirma. Una de cada tres víctimas paga el rescate que piden los delincuentes para recuperar sus archivos. Pero un sólido 20 % de los usuarios que pagaron el rescate nunca recuperaron sus archivos.

Andrei Mochola, jefe de consumer business de Kaspersky Lab, comentó: “Pedimos a todas las víctimas de ransomware, sean grandes empresas o personas únicas, que no paguen el rescate que demandan los delincuentes. Si lo hacéis, estaréis dando vuestro apoyo a los negocios de los ciberdelincuentes. Y, como demuestra nuestro estudio, no hay garantía de que el pago del rescate vaya a daros acceso a vuestros archivos cifrados”.

Esto es lo que deberías hacer para proteger tus datos del ransomware o para recuperarlos en el caso de que ya te hayas infectado.



1. Haz copias de seguridad regulares de tus archivos importantes.

2. Utiliza una solución de seguridad de confianza. No tiene que ser un producto de Kaspersky Lab, modestia aparte, pero te aseguramos que esto se nos da muy bien.

3. Si utilizas una de nuestras soluciones de seguridad, asegúrate de que no has desactivado System Watcher. Esta proactiva característica de seguridad es de gran ayuda para proteger tus archivos de los últimos tipos de malware y, en especial, es efectiva luchando contra el ransomware. Este es un vídeo sobre System Watcher y sobre su funcionamiento:

https://www.youtube.com/watch?v=iX9Ajl8j1Ls




4. Si no has tenido suerte y te has convertido en víctima de un cifrador, que no cunda el pánico. Utiliza un sistema limpio para entrar en nuestra web No More Ransom; quizá dispongamos de una herramienta de descifrado que te pueda ayudar a recuperar tus archivos. No te cobraremos ni un céntimo por ello.




Noticias de seguridad informática

Quieren utilizar “malware bueno” para acabar con la botnet Mirai

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/quieren-utilizar-malware-bueno-para-acabar-con-la-botnet-mirai/
TAGS: botnet Mirai, Malware

Lo más seguro es que todos aún recordemos el ataque DDoS que tuvo lugar hace dos semanas contra DynDNS y que consiguió dejar sin servicio a medio Internet, incluidas grandes plataformas como Twitter y WhatsApp. Este ataque se llevó a cabo a través de Mirai, una botnet formada por millones de dispositivos zombie del Internet de las Cosas desprotegidos e infectados por este malware y controlados por piratas informáticos.


Es prácticamente imposible que los usuarios sean conscientes de que sus dispositivos están infectados y, por lo tanto, también es prácticamente imposible acabar con esta botnet. Sin embargo, un ingeniero experto en seguridad ha encontrado la forma de acabar con la botnet Mirai, aunque esto supone la creación y distribución de un nuevo malware igual que hacen los piratas informáticos.


A grandes rasgos, este ingeniero ha creado un “malware bueno” que utiliza las mismas técnicas de distribución que Mirai pero que, una vez infecta un dispositivo IoT y hacerlo formar parte de una botnet, cambia sus credenciales por defecto por otros aleatorios para, posteriormente, eliminarse del dispositivo sin dejar rastro. De esta manera, Mirai, y otros gusanos similares, no podrán conectarse a los dispositivos ni tomar el control de los mismos a través de los credenciales por defecto.


Este “malware bueno” ha sido denominado como “anti-worm worm (o nematode)” y, aunque fue publicado en GitHub, actualmente no se encuentra disponible por motivos desconocidos.


Debido a que la mayoría de los dispositivos del Internet de las Cosas no tienen un sistema de actualizaciones como tal, es muy complicado lanzar y distribuir una actualización que, además de acabar con el fallo de seguridad, elimine el gusano del dispositivo infectado. Por ello, a día de hoy, el concepto de este ingeniero experto en seguridad es la opción menos mala para intentar acabar con esta peligrosa botnet.


mirai-botnet



¿Son los “virus buenos” una mala idea aunque se usen para acabar con Mirai y otras botnets?


Este ingeniero es consciente de que, aunque es una forma de acabar con Mirai, también estamos rozando una línea que no se debería traspasar, y es que, aunque las intenciones sean buenos, no estamos haciendo otra cosa que crear un malware, igual que hacen los piratas informáticos, para cambiar una configuración de dispositivos que no son nuestros igual que hace el malware malo.


De todas formas, este concepto se encuentra con un gran número de dificultades, tanto éticas como legales. Además, aunque estemos creando y liberando un malware totalmente autónomo (cosa aún más preocupante, la verdad), estamos abriendo la puerta a que otros piratas informáticos se hagan con él y lo modifiquen para hacerlo aún más peligroso y dotarle, por ejemplo, de un módulo de control remoto.


Sin duda, los virus son virus, y no hay virus buenos aunque las intenciones con las que se han creado no sean malas. La única forma de asegurarse de proteger los dispositivos del Internet de las Cosas es que los fabricantes tengan la obligación de configurar credenciales aleatorios por defecto de manera que, aunque queden abiertos otros vectores de ataque, al menos sea más complicado explotar este preocupante fallo de seguridad.


Fuente: http://www.redeszone.net


Noticias de seguridad informática

Honeypot para ataques de Google Hacking.

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/hacking-incidentes/honeypot-para-ataques-de-google-hacking/
TAGS: ataques de Google Hacking, Honeypot

GHH es la reacción a un nuevo tipo de tráfico web malicioso: los atacantes que utilizan los motores de búsqueda para atacar Webs. GHH es un honeypot  para técnicas de Google Hacking. Está diseñado para proporcionar reconocimiento contra los atacantes que utilizan los motores de búsqueda como una herramienta de ataque contra recursos Web. GHH implementa la teoría del honeypot para proporcionar seguridad adicional para este tipo de ataques.


diagram


Google ha desarrollado una poderosa herramienta, su motor de búsqueda, que permite buscar en una cantidad inmensa de información. Su indice de búsquedas crece a pasos agigantados, este crecimiento del indice de Google se refleja en la difusión de aplicaciones basadas en web, también ha  aumentado  el número de aplicaciones web mal configuradas y vulnerables disponibles en Internet. Estas aplicaciones inseguras, cuando se combinan con la potencia de un motor de búsqueda y el índice que ofrece Google, resulta un vector de ataque conveniente para los usuarios malintencionados.


GHH emula una aplicación web vulnerable y es indexada por los motores de búsqueda. Está oculto de los navegadores web, pero se encuentra a través del uso de un rastreador o motor de búsqueda. Esto hace a través del uso de un enlace transparente que no es detectado por la navegación casual, pero se encuentra cuando un motor de búsqueda rastreador indexa un sitio. El enlace transparente (cuando está bien elaborado) reducirá los falsos positivos y evitará  que sea detectado el honeypot.

El honeypot se conecta a un archivo de configuración y el archivo de configuración escribe en un archivo de registro que se elige durante la configuración. El archivo de registro contiene información sobre el host, incluido: la dirección IP, la información de referencia y el agente de usuario. Utilizando la información reunida en el archivo de registro, un administrador puede obtener más información sobre los atacantes que realizan un reconocimiento de su sitio. Un administrador puede cruzar los registros de referencia y ver una mejor imagen de atacantes específicos.


Fuente:http://www.gurudelainformatica.es


Noticias de seguridad informática

Seguridad en cámaras web: entendiendo un vector de ataque moderno

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/seguridad-informatica/seguridad-en-camaras-web-entendiendo-un-vector-de-ataque-moderno/
TAGS: cámaras web, Seguridad en cámaras web



El 21 de junio de 2016, Mark Zuckerberg, el CEO de Facebook, publicó un mensaje en la red social para celebrar un nuevo récord de Instagram. La plataforma para compartir fotografías y vídeos, propiedad de la empresa de Zuckerberg, ya contaba con más de 500 millones de usuarios activos mensuales.


Zuckerberg escribió: “Este es un homenaje a la visión de Kevin Systrom y Mike Krieger, y a todas las personas que han abierto una ventana a su mundo: desde grandes eventos hasta los momentos cotidianos. Gracias por hacer de Instagram un lugar tan hermoso”.


Hasta aquí todo parece ir bien y sobran motivos para que la estrella de la red social esté feliz. Sin embargo, este momento trascendental quedó rápidamente en segundo plano. ¿Por qué? Porque la publicación resultó tener una interesante imagen adjunta donde Zuckerberg sostiene un marco que simula una fotografía de Instagram.


Una vez más, parecería algo bastante rudimentario. Sin embargo, detrás de él, sobre el escritorio, se ve una MacBook personal, que suponemos es la suya, y que no solo tiene tapado el enchufe de audio con cinta adhesiva, sino también la cámara web integrada. Está de más decir que esta imagen provocó una gran conmoción online.


shutterstock_442040116-623x410



(In)Seguridad en cámaras web: un problema muy real


La comprensión colectiva de la seguridad cibernética está mejorando en forma lenta pero segura. Esto es algo positivo, ya que la amenaza de la ciberdelincuencia crece día a día. Tanto es así que los profesionales de seguridad y ciertas autoridades han admitido que están muy preocupados por su rápido crecimiento.


No obstante, definitivamente aún hay falta de concientización entre los usuarios de computadoras. Una de las consecuencias positivas que tuvo la publicación viral de Zuckerberg en Facebook es que aumentó la toma de conciencia sobre la seguridad en cámaras web y otras vulnerabilidades asociadas, que hace muy poco tiempo se ha convertido en un área de preocupación real en los círculos fuera de la industria de la seguridad informática.


Por otra parte, en la Internet de hoy, donde todo está mucho más conectado mediante la Internet de las Cosas, este problema va a ser cada vez mayor. Por eso es importante que aprovechemos este súbito incremento en la atención que está recibiendo la seguridad en cámaras web, por cortesía del pionero en redes sociales.



Todo comenzó con un café


Los orígenes de la cámara web son sorprendentemente peculiares. Unos investigadores de la Universidad de Cambridge en el Reino Unido querían asegurarse de que siempre podrían tomar una taza de café con el menor esfuerzo posible. Como había muchas personas trabajando en diferentes pisos, encontrar algo de café en la cafetera era cuestión de suerte: la cafetera estaba en una sala y no era visible para la mayoría de la gente. Por lo tanto, cuando iban a tomar un café, la cafetera podía estar llena, vacía o en algún punto intermedio.


Esto les resultaba bastante molesto a los investigadores, por lo que algunos decidieron colocar una cámara en el cuarto para vigilar el estado de la cafetera. De esta forma, todos los equipos de la Universidad que estuvieran interesados podrían ver si había café a través de la red informática interna. Pero esto solo fue el comienzo: el gran avance para la Web llegó en noviembre de 1993, cuando el Dr. Martyn Johnson creó un script con las imágenes capturadas.


La BBC dijo hace unos años: “Y así fue como la imagen granulada de una sucia cafetera en un laboratorio universitario entró al folklore de la ciencia informática, como parte esencial de la primera cámara web del mundo”.



Aprovechamiento de vulnerabilidades de las cámaras web


Como era de esperar, esta tecnología, que desde aquellos tiempos ha evolucionado para ofrecer conversaciones de vídeo online, conferencias remotas y videologs, comenzó a atraer la atención de los ciberdelincuentes. Si por ejemplo se logra instalar una herramienta de acceso remoto, les puede dar a los atacantes un alto grado de “acceso” al hogar y a los aspectos más íntimos y cotidianos de la vida de un usuario.


Al igual que ocurre con la mayoría del malware que logra su cometido, la víctima en general no se da cuenta de que algo anda mal; es decir, los ciberdelincuentes pueden espiar a la gente desde una ubicación remota con la tranquilidad de saber que nadie sospecha lo que están haciendo. Y todo por culpa de una tecnología que ahora es parte integral del smartphone, la tableta o la computadora personal.


Como el analista de seguridad independiente Graham Cluley advirtió el año pasado: “Prácticamente todos los equipos que se venden en la actualidad vienen con un pequeño secreto: pueden espiar a los usuarios. Lo que es más, si los atacantes logran infectar tu equipo con malware, pueden secuestrar tu cámara web y observarte sin que te des cuenta: más allá de que estén cruzando la calle o del otro lado del mundo”.


Sin embargo, en algunos casos, los atacantes dejan que sus víctimas sepan que los están vigilando. ¿Por qué? En algunos casos, tiene que ver con una conducta desviada, como lo demuestra el caso que señaló Graham Cluley de Cassidy Wolf, una modelo estadounidense que fue coronada Miss Teen USA en 2013. En otros casos, tiene que ver con la extorsión, amenazando con publicar fotos íntimas si la víctima se rehúsa a pagar el rescate.



Sigue el ejemplo de Mark Zuckerberg


Por lo tanto, es evidente que debemos prestar mayor atención a la seguridad en cámaras web. Es sumamente importante saber qué cosas debemos buscar y qué hay que hacer, ya que puede marcar una gran diferencia si nos vemos ante la necesidad de responder a una situación.


“Imagina que estás trabajando en tu computadora portátil y de repente la luz verde al lado de la cámara web integrada parpadea por un segundo e inmediatamente se vuelve a apagar”, señaló el especialista en seguridad de ESET Ondrej Kubovič. “¿La ignorarías? ¿O empezarías a indagar para ver si se trata de algo más serio?”.


Lo más importante que hay que entender es que, cuando se trata de la seguridad de la cámara web, debemos ser proactivos: por ejemplo, cambiar la contraseña predeterminada, ya que de lo contrario es muy fácil que los ciberdelincuentes puedan obtener acceso.


Como dijo el especialista en seguridad de ESET Mark James: “Aquí, el punto clave es la educación: el usuario final tiene que ser plenamente consciente de que existe una contraseña de acceso predeterminada y que las instrucciones para cambiarla son muy sencillas”.


Otro consejo es cubrir la cámara web (una vez más, esto requiere que el usuario tome la iniciativa). Aunque pegar un pedazo de cinta es útil, como lo hizo Zuckerberg, es probable que prefieras invertir en algo que sea más profesional (y fácil de usar). De este modo, simplemente deberás cubrir la cámara cuando no esté en uso.


Vivimos en un mundo en el que las innovaciones tecnológicas están transformando y mejorando la forma en que vivimos. Los smartphones nos permiten hacer todo tipo de cosas desde cualquier lugar, las tecnologías inteligentes nos permiten comunicarnos con heladeras y automóviles, y las cámaras web nos dan la oportunidad de ver más a nuestros amigos, familiares y compañeros de trabajo, por más lejos que estén.


Sin embargo, al mismo tiempo, los cibercriminales siempre están buscando la manera de aprovecharse de las tecnologías, es decir que nuestras heladeras, nuestros automóviles e incluso nuestras cámaras web son vulnerables a todo tipo de ataque. Pero con un poquito de esfuerzo, una solución de seguridad instalada en todos los dispositivos y un poco de atención, es posible mantener estas amenazas a raya y disfrutar de todos los beneficios que los aparatos más modernos tienen para ofrecer.





 Fuente:http://www.welivesecurity.com

Noticias de seguridad informática

Tuesday, 1 November 2016

Protocolo Call Relay de Apple: ¿una puerta abierta al ciberespionaje?

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/seguridad-movil/protocolo-call-relay-de-apple-una-puerta-abierta-al-ciberespionaje/
TAGS: Apple, Protocolo Call

Durante la pasada edición de ekoparty en Buenos Aires, Argentina, pudimos atestiguar increíbles exposiciones de la mano de grandes oradores internacionales que presentaron sus hallazgos en materia de ciberseguridad. Ciertamente, uno de los speakers que dejó una muy buena impresión entre el público fue Martin Vigo, ingeniero en seguridad oriundo de Galicia, España.


POR QUÉ APPLE NO SIGUIÓ SUS PROPIOS CONSEJOS DE SEGURIDAD, TAL VEZ NUNCA LO SABREMOS


Tras un pequeño curso introductorio que bien podría haberse titulado “Cómo identificar a un gallego 101” más algunos desopilantes chistes y acompañado de un aire distendido, muy similar a otro investigador español que ya todos conocemos, Martin se puso manos a la obra para probar cómo es posibleconvertir un iPhone y una Mac en un verdadero equipo de ciberespionaje, comenzando su charla Do-it-Yourself Spy Program: Abusing Apple’s Call Relay Protocol.



¿Qué es el protocolo Call Relay?


Con iOS 8 y OS X Yosemite, Apple presentó su protocolo de gestión de llamadas multidispositivo llamado Call Relay. Este protocolo P2P propietario basado en UDP permite a los usuarios tomar llamadas recibidas por su iPhone desde otros equipos Apple conectados en la misma red LAN, como Macs y iPads. La funcionalidad fue presentada al público durante la Apple WWDC 2014.


https://youtu.be/5mdxgsmsdFI

Lo curioso de este protocolo es que –como explicó el conferencista– utiliza entradas no confiables para tomar decisiones de seguridad, en este caso referidas al manejo de llamadas y la privacidad de los usuarios. Este error está enumerado dentro de las diez peores malas prácticas de seguridad según OWASP.


Aún más, el protocolo utiliza el servicio APNS (Apple Push Notification Service) cuando, paradójicamente, es Apple quien en sus recomendaciones de seguridad estipula que este tipo de notificaciones nunca debiesen ser utilizadas para acciones sensibles.


Por qué Apple no siguió sus propios consejos de seguridad, tal vez nunca lo sabremos. Pero sí sabemos que este fue el puntapié inicial para que Vigo lograse explotar exitosamente este protocolo.



Explotación del protocolo


Luego de realizar la ingeniería reversa del protocolo de comunicación con Netzob, Martín descubrió que era posible espiar una llamada telefónica a través de algunas vulnerabilidades bastante sencillas.


c66c1987-c280-491b-9bb3-1f3c57532ce2


El atacante puede simplemente generar un ataque de ARP spoofing para comprometer a la víctima en un escenario de Man-In-The-Middle (MITM). Acto seguido, debe llamar al teléfono de la víctima y, una vez iniciada la comunicación, debe enviar un paquete especialmente diseñado para bloquear el tráfico. Esto será interpretado por la GUI (Graphical User Interface o Interfaz gráfica de usuario) como el final de la llamada y el sistema mostrará al usuario la opción de colgar; no obstante, la conexión continúa activa en segundo plano y el teléfono sigue transmitiendo datos al atacante.


El orador demostró cómo este ataque es factible incluso cuando se tienen llamadas simultáneas: cuando el usuario asume erróneamente que la llamada con el atacante ha concluido, la interfaz de usuario le muestra que ahora está hablando con el otro interlocutor, cuando realmente sigue en comunicación con el atacante. Esto permitiría al atacante suplantar la identidad de un tercer individuo para robar información de la víctima.


Al explotar el protocolo, un atacante podría no solo realizar ataques DoS, sino también espiar conversaciones mantenidas por la víctima y, en general, todos los sonidos a los que el dispositivo se vea expuesto.


Pero ¿por qué no ir un paso más allá? Fue entonces cuando Martín recordó el programa Nosey Smurf mencionado por Edward Snowden y su capacidad de tener acceso a la cámara y al micrófono de cientos de smartphones.


https://youtu.be/ucRWyGKBVzo


Explotación a gran escala


Un escenario mucho más macabro que se desprende de esta falla es la posibilidad de escalar el ataque a través de cientos de dispositivos comprometiendo los routers encargados de realizar la conexión con el APNS. Como estos dispositivos de red poseen dos interfaces, una para el tráfico interno y otra para la red WAN, es posible fingir el fin de la llamada simplemente dando de baja la interfaz externa, bloqueando así el tráfico hacia el Apple Push Notification Service.


Como indicó el orador, la pregunta se vuelve entonces cómo sería posible comprometer estos dispositivos masivamente. Una de las alternativas posibles es nada más ni nada menos que el war dialing, una vieja estrategia donde se realizan llamadas a una gran cantidad de números telefónicos para identificar routers vulnerables.


Para aumentar la efectividad del ataque, sería posible filtrar los números telefónicos según el código de área y las características del equipo realizando fingerprinting de este y analizando el número correspondiente al fabricante en la dirección MAC.


La inclusión de técnicas de Ingeniería Social para dar comienzo a la llamada maliciosa completa el escenario de compromiso. Por ejemplo, los cibercriminales podrían fingir la realización de una encuesta para así explotar la vulnerabilidad y activar la escucha por el micrófono del terminal; esto podría pasar aún más desapercibido en épocas de elecciones políticas. Del mismo modo, podría fingirse una llamada a un número equivocado.



¿Qué tan indefensos estamos?


Por suerte, un parche de seguridad ha sido incluido a partir de iOS 10.1, solucionando esta vulnerabilidad que se encontraba presente desde iOS 8. Por esto, todos aquellos que posean la nueva actualización del sistema ya pueden contestar sus llamadas desde sus computadores Mac sin miedo a perder su privacidad.





 Fuente:http://www.welivesecurity.com

Noticias de seguridad informática

Aprendiendo con el Malware del Wp-login de WordPress

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/aprendiendo-con-el-malware-del-wp-login-de-wordpress/
TAGS: Malware, WordPress

Cuando un sitio web es hackeado, el ataque no termina con el payload de contenido malicioso o spam. Los hackers saben que la mayoría de los administradores del sitio web podrán eliminar la infección y buscarán por ella. Algunos admins fijan software vulnerable, cambian sus contraseñas, y realizan otros pasos después del hackeo. Todo esto es bueno, pero los hackers tras el ataque también buscan formas de reinfectar fácilmente el sitio web.


Después de invadir un sitio web, los hackers aseguran que todavía tengan acceso al sitio web si se reparó la falla de seguridad original. La mayor parte del tiempo, cargan puertas traseras o crean nuevos usuarios maliciosos. También combinan los dos enfoques: login bypasses. Por lo tanto, los atacantes obtenen derechos administrativos sin autenticación mediante un parámetro especial en la petición HTTP.



Login Bypass en WordPress


Recientemente, hemos encontrado este código de bypass con un error en un archivo wp-login.php de WordPress.



Login bypass with kidsid parameter
Login bypass usando el parametro kidsid

la petición fue puesta dentro de un comentario legítimo, lo que la hizo más sospechosa, ya que este truco sólo es utilizado por el malware.


El objetivo de este código es proporcionar un ID de usuario de administración al parametro kidsid al buscar por wp-login.php. Esto permite al atacante acceder al panel de WordPress con el permiso de administrador.


Por ejemplo, con N como ID del usuario admin:



httx://infected-site.com/wp-login.php?kidsid=N

Mejor que Admins Falsos


Esta técnica tiene ventajas con respecto a la creación de nuevos usuarios que se pueden notar y se eliminar. No se eliminará un usuario legítimo administrador durante una limpieza. Los hackers ni siquiera necesitan saber el nombre del usuario administrador. Muchos sitios web de WordPress todavía tienen el usuario administrador por defecto creado durante la instalación. Este usuario tiene ID 1. Sin embargo, los atacantes no tienen que usar sólo el conocimiento de este hecho.


Con herramientas como wpscan, es facil para cualquiera descubrir los ID de usuario de administración de WordPress. Si el atacante puede inyectar código en wp-login.php, más probable es que se le permita ejecutar un SQL query sencillo e identificar todos los ID del administrador del sitio web.



Código con Bug


La intención del bug es bastante clara. Sin embargo, este código no funcionará en particular por razones obvias para cualquiera que esté familiarizado con la API de WordPress o incluso sólo PHP. El error es muy tonto.


Teniendo en cuenta que este código se basa casi por completo en un ejemplo que se puede encontrar en el WordPress Codex, se puede sugerir que el hacker es un “script kiddie”, que sólo puede utilizar scripts de terceros y tiene habilidades copy/paste limitadas.


Además, la inyección en wp-login.php está condenado a ser eliminada porque este archivo se sobrescribe durante las actualizaciones de WordPress.



Secuestrando el Login Form


Otra manera de asegurarse de que tiene credenciales válidas en WordPress es secuestrando el formulario de acceso (login form). Para ello, los hackers suelen inyectar el malware en el wp-login.php como habíamos visto.


Sigue otro ejemplo reciente:



Credentials stealer in wp-login.php
Ladrón de credenciales en wp-login.php

Cuando un usuario entra correctamente en WordPress, este código envía un correo electrónico con la dirección URL del sitio web y las credenciales del usuario al atacante.


Detalle interesante: Ese malware también tiene un bug.


Si usted verifica la línea 843 en la imagen de arriba, ve que la concatenación $body no es completa y no hay el punto y coma al final de la línea. Parece que el atacante modificó esta línea, pero se olvidó de terminarla correctamente.


PHP es muy indulgente cuando se trata de este tipo de errores (que por lo general resultan en todo tipo de efectos secundarios inesperados) y este código realmente funciona. El PHP sólo convierte literales sin comillas en strings y concatena el $bodycon los $headers en la línea siguiente. Como resultado de ello, el texto del correo electrónico termina con MIME-Version: 1.0 (que debe ir a los encabezados de los correos electrónicos), pero aún así, funciona.



Aprendiendo con el Malware


Incluso si estas muestras tienen errores y el código de desvío no es funcional, nos enseña algunas lecciones de seguridad.



  1. Sepa si sus archivos core de WordPress están intactos. El monitoreo de integridad va a ayudarle a detectar este tipo de inyección.

  2. Remueva el usuario administrador por defecto de WordPress con el ID 1. La primera cosa que debe hacer después de instalar un nuevo blog de WordPress es la creación de un nuevo administrador con un nombre difícil de adivinar y eliminar el usuario administrador por defecto. Esto reducirá significativamente las posibilidades de ataques de fuerza bruta, y también cambiará el ID del administrador por defecto.

  3. No se debe publicar cualquier cosa usando la cuenta de administrador. Es fácil encontrar los ID de usuario que publican mensajes en su blog. Utilice una cuenta especial en el editor o autor para postar en el blog y utilizar la cuenta de administrador sólo para las tareas de gestión del sitio web. Por lo tanto, los atacantes sólo serán capaces de encontrar cuentas limitadas cuando escanearem su sitio web.

  4. Sea notificado cuando un administrador iniciar sesión en su sitio web para ver si su cuenta se ha visto comprometida. Hay muchos plugins que lo hacen.

  5. Considere la posibilidad de restringir el acceso al área de administración de WordPress. Proteja el área protegida por contraseña en el servidor, o proporcione acceso sólo a las direcciones IP fiables. Incluso si los hackers roban las credenciales de WordPress o inyectan un código de bypass, no estarán en condiciones de usar, incluso el área de administración de WordPress.

  6. Mantenga copias de seguridad de su sitio web. Los hackers no son los mejores programadores. Los errores no son poco comunes, tanto en sus herramientas como en las inyecciones de malware. A menudo vemos como sus errores corrompem archivos legítimos. Por eso hay que tener una buena estrategia de copias de seguridad que incluya el almacenamiento de copia de seguridad en un servidor diferente.

Por supuesto, esto no es una lista completa de cosas que debe hacer para proteger a un sitio web de WordPress. Es altamente recomendable la lectura de la guía oficial de Hardening de WordPress en WordPress Codex, así como los recursos especializados de los miembros de la comunidad, como Yoast.


Fuente:https://blog.sucuri.net/


Noticias de seguridad informática

Google vuelve a destapar un bug antes que Microsoft pueda resolverlo

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/vulnerabilidades/google-vuelve-destapar-un-bug-antes-que-microsoft-pueda-resolverlo/
TAGS: Kernal, MICROSOFT


La compañía de Mountain View se dedica –entre muchas otras cosas- a analizar el software de otros en busca de vulnerabilidades. Y entre esos ‘otros’ está Microsoft. No es la primera vez que el equipo de seguridad informática de Google encuentra problemas en el sistema operativo Windows, y tampoco es la primera vez que Microsoft protesta porque ‘Google pone en peligro a miles de usuarios’ haciendo pública la información sin dar tiempo suficiente para que se resuelvan los problemas encontrados en su código.






En su blog de seguridad, la compañía de Mountain View ha vuelto a alertar de una vulnerabilidad en el kernel de Windows, según la cual un atacante podría escalar privilegios a través de win32k.sys. Y esta información –con mayor detalle-, Google la ha hecho pública en el blog que comentábamos 7 días después de avisar a Microsoft, tal y como explican en su política de actuación para este tipo de casos. Y según Microsoft, la divulgación de estos problemas pone en riesgo a sus usuarios, lo cual es cierto, y justifican por el breve tiempo cedido a sus ingenieros para la aplicación de un parche.


windows bug



Google sigue presionando a Microsoft con sus problemas de seguridad


No es la primera vez que chocan la compañía de Mountain View y Microsoft por este mismo problema, y es que Google tiene un equipo de seguridad informáticadedicado, como ya comentábamos, a buscar problemas de seguridad en software de terceros ‘por el bien de los usuarios de Internet’. El problema, según Microsoft, es que la publicación de los problemas de seguridad que afectan a su software y el de otras compañías no supone una ayuda para los usuarios de Internet, y de las plataformas afectadas, sino que los expone en tanto que se divulga la forma de ‘explotación’ de estos agujeros de seguridad.





En esta ocasión en concreto, Google no sólo ha hecho públicos los problemas de Microsoft –que sigue sin resolver el problema aún-, sino que también han publicado vulnerabilidades que afectan a Flash. Y en este caso sí se ha aplicado en el plazo cedido por la compañía de Mountain View una actualización que lo resuelve. En las múltiples quejas que Microsoft ha planteado, no sólo en esta sino en anteriores ocasiones, desde Google no se han pronunciado y únicamente se han limitado a seguir publicando los problemas que les afectan a ellos, y también a otros desarrolladores.


 Fuente:http://www.adslzone.net


Noticias de seguridad informática