Suscribete a Mi Canal en YOUTUBE , da Click --> AQUÍ.

Canal acádemico donde se enseñará como atacan los ciberdelincuentes y como protegerse de estos ataques.

miércoles, 30 de noviembre de 2016

Vulnerabilidades en computadores Lenovo (de nuevo el software propietario preinstalado)

Se han reportado dos vulnerabilidades en ordenadores Lenovo(incluyendo portátiles, servidores y equipos de sobremesa). Las vulnerabilidades son consideradas de gravedad alta y podrían permitir a un atacante local ejecutar código arbitrario y elevar privilegios dentro del sistema. Una vez más los problemas residen en el software propietario preinstalado por Lenovo.

No es la primera vez que Lenovo tiene problemas con aplicaciones propiasinstaladas en Windows. De nuevo volvemos a recordar y remarcar el peligro del software preinstalado.

En el primer problema, con CVE-2016-8223, en el que un atacante local con privilegios limitados podría aprovecharse de un error en Lenovo System Interface Foundation (Lenovo.Modern.ImController.exe o Lenovo.Modern.ImController.PluginHost.exe que funciona como servicio en el administrador de tareas de Windows 10) para ejecutar código arbitrario dentro del sistema con privilegios de administrador. Lenovo Sistem Interface Foundation proporciona servicios, drivers y aplicaciones de ayuda a otros softwares propios de Lenovo y otros servicios dentro de Windows 10.

 

 

Afecta a todos los Thinkpad, Thinkcentre, ThinkStation y sistemas Lenovo preinstalados con Windows 10 u cualquier otro sistema que ejecute Lenovo Companion, Lenovo Settins o Lenovo ID.

Se recomienda actualizar a la última versión de Lenovo System Interface Foundation (http://support.lenovo.com/downloads/ds105970).

El segundo problema, con CVE-2016-8224, podría permitir a un atacante con privilegios administrativos en el sistema causar una denegación de servicio y/o elevar privilegios dentro del sistema a través de una aplicación especialmente manipulada que eluda restricciones de las protecciones del Intel Management Engine.

Intel Management Engine (ME) es un conjunto de características hardware desarrolladas por Intel para administrar, reparar y proteger ordenadores dentro de sus propias redes.

Afecta a los siguientes sistemas y productos:

Lenovo Notebook modelos: 

110-14IBR/110-15IBR

B70-80

E31-80

E40-80

E41-80

E51-80

G40-80

G50-80

G50-80 Touch

Ideapad 300-14IBR/300-15IBR

Ideapad 300-14ISK/300-15ISK/300-17ISK

Ideapad 510S-12ISK

K21-80

K41-80

MIIX 710-12IKB 

XiaoXin Air 12

YOGA 510-14ISK/510-15ISK

YOGA 710-11IKB

Yoga 710-11ISK

Yoga 900-13ISK

YOGA 900S-12ISK

ThinkServer TS150

ThinkServer TS250

ThinkServer  TS450

ThinkServer  TS550

Lenovo ha publicado actualizaciones para los sistemas afectados, se recomienda consultar la página

https://support.lenovo.com/es/es/solutions/LEN_9903

para determinar por la versión de la BIOS si el sistema está afectado y la actualización requerida.

Las vulnerabilidades han sido reportadas a través de auditorías internas de la propia compañía y por Alexander Ermolov de Digital Security ltd.

______________________________
Tomado de:  http://unaaldia.hispasec.com/2016/06/otra-vez-lenovo-y-las-aplicaciones.html
Se Respetan Derechos de Autor.

domingo, 27 de noviembre de 2016

Presentan 6 principios estratégicos para proteger a la IoT (Internet de las Cosas)


El Departamento de Seguridad Nacional de los Estados Unidos publicó esta semana un documento titulado Principios Estratégicos para Asegurar la Internet de las Cosas (IoT), con el objetivo de informar a usuarios, operadores y fabricantes para que tomen decisiones conscientes al trabajar con dispositivos conectados.
“Nuestra dependencia de tecnologías conectadas creció más rápido que las formas de asegurarla”
“A medida que integramos cada vez más conexiones de red en la infraestructura crítica de nuestra nación, procesos importantes que antes se ejecutaban manualmente (y gozaban de inmunidad contra la actividad cibernética malintencionada) son ahora vulnerables a ciberamenazas. Nuestra creciente dependencia de tecnologías conectadas en red a nivel nacional ha crecido más rápido que las formas de asegurarla”, sentenció el informe.
Su publicación llega en un contexto ideal, en el que la seguridad de la IoT está en discusión a lo largo de la comunidad de expertos, empresas y autoridades, sobre todo después de dos casos emblemáticos: el primero y más reciente lo constituyen los ataques DDoS del 21 de octubre pasado, que dejaron brevemente sin acceso a Internet a los Estados Unidos e interrumpieron ciertas actividades online cotidianas.
“La seguridad de la IoT es ahora un asunto de seguridad nacional”
El segundo es el ciberataque del año pasado que deshabilitó temporalmente el suministro eléctrico en partes de Ucrania. Es ante hechos como estos, entonces, que se debe actuar para delinar planes y proteger a la IoT en relación al contexto.
“Porque nuestra nación depende de redes que funcionen en forma apropiada para realizar actividades que contribuyen al mantenimiento de la vida, la seguridad de la IoT es ahora un asunto de seguridad nacional”, afirmaron los autores del documento.

¿Cuáles son estos principios estratégicos?

El Departamento de Seguridad Nacional determinó que los problemas de seguridad en la IoT se deben a varios motivos:
  1. No siempre queda claro quién es responsable de las decisiones de seguridad: una compañía diseña un dispositivo, otra provee el software, otra opera la red en la que se lo integra y otra pone a disposición el equipo.
  2. No hay normas y estándares aceptados a nivel internacional.
  3. No hay incentivos a los desarrolladores para que aseguren adecuadamente los productos, dado que no necesariamente enfrentan los costos ni las consecuencias de fallar en este sentido.
Entonces, para pensar en forma abarcadora en cómo proteger la Internet de las Cosas, se proponen los siguientes principios:

1. Incorporar la seguridad en la fase de diseño

Las medidas propuestas en este aspecto tienen que ver con el establecimiento de contraseñas por defecto únicas, robustas y difíciles de adivinar, de manera que no estén disponibles en la Web. También se propone usar siempre el sistema operativo más reciente, dentro de lo que sea técnica y económicamente viable, para evitar vulnerabilidades conocidas; y diseñar pensando en posibles fallas e interrupciones, para que los dispositivos fallen “en forma segura”, sin causar una mayor disrupción sistémica.

2. Actualizaciones de seguridad y gestión de vulnerabilidades de avanzada

Este eje hace hincapié en automatizar tanto la corrección de fallas como la liberación de parches y actualizaciones. A la vez, se propone coordinar la publicación de vulnerabilidades entre desarrolladores, fabricantes, proveedores de servicio y los equipos CSIRT y CERT, por ejemplo.
Otro aspecto importante tiene que ver con el ciclo de vida de las actualizaciones: “No se podrá parchear y actualizar a todos los dispositivos IoT en forma indefinida”, por lo que es importante alertar a fabricantes y usuarios sobre los riesgos de usar un dispositivo después de su fecha de usabilidad.

3. Construir sobre prácticas de seguridad probadas

Un punto de partida es considerar las buenas prácticas ya publicadas por algunas industrias, por ejemplo la automotriz. Luego, se propone implementar la defensa en capas y compartir información relacionada a incidentes y vulnerabilidades para que todos los miembros de la cadena sepan cómo afrontarlos.

4. Priorizar las medidas de seguridad según el impacto potencial

Lo principal es identificar el entorno de uso deseado de cada dispositivo, para determinar qué características técnicas debe tener, cómo debe funcionar y qué medidas no deben faltarle. Luego, se propone auditar los equipos para ver qué podría mejorarse y, una vez en uso, se deberían aplicar reglas de autenticación para su conexión a la red.

5. Promover la transparencia a lo largo de la IoT

Las evaluaciones de riesgo deberían abarcar a todos los componentes e incluir a desarrolladores y fabricantes; a la vez, todos deberían poder conocer los materiales y procesos utilizados por los demás actores. Los programas de recompensas por encontrar vulnerabilidades también contribuyen a la generación de confianza y transparencia en la gestión de fallas.

6. Conectar con cuidado y deliberadamente

En este punto es necesario preguntarse: ¿necesita cada dispositivo en red estar conectado en forma continua y automática a Internet? Según el documento, ciertas funciones críticas, sobre todo en el sector industrial, podrían no necesitar de una conexión directa y esto podría reducir los vectores de ataque. Por lo tanto, se propone la implementación de “conexiones intencionales” y selectivas.
“Este documento es un primer paso para fortalecer los esfuerzos en proceso, articulando principios generales de seguridad. Pero seguramente se requerirán próximos pasos“, concluyó el informe.

________________________________________________________
Tomado de: http://www.welivesecurity.com/la-es/2016/11/17/principios-estrategicos-proteger-a-la-iot/
Se Respetam Derechos de Autor.

sábado, 26 de noviembre de 2016

CUIDADO CON DESCARGAR IMÁGENES JPG DE FACEBOOK, PUEDE SER RANSOMWARE.

Investigadores han descubierto que es posible compartir ransomware a través de Facebook con lo que parecen simples imágenes.

Compartir malware a través de Facebook no es fácil; la red social tiene sus propias medidas para evitar que cualquier archivo sospechoso pase por sus servidores y hasta los usuarios.

Sin embargo, algunos hackers parecen haberse saltado esas medidas, y están compartiendo ransomware a través de Facebook; si los usuarios abren esos archivos, acabarán infectados. A esta técnica se le conoce como ImageGate.

IMAGEGATE, UN MÉTODO PARA COMPARTIR RANSOMWARE A TRAVÉS DE FACEBOOK

Lo interesante es que a simple vista el archivo parece una imagen; los usuarios que han sufrido el ataque inicialmente recibieron una imagen de uno de sus amigos a través de Facebook Messenger (también funciona en LinkedIn). A primera vista parece una imagen jpg normal y corriente.

Si hacemos click en la imagen para verla más grande, nos aparecerá el mensaje de Windows para guardar el archivo; sólo entonces nos daremos cuenta de que tiene una extensión extraña. Se sabe que algunas de las extensiones usadas son .hta, svg o js. Recientemente también se ha añadido la extensión .zzzzz.

Pero claro, es muy fácil que no nos fijemos en la extensión del archivo una vez que hemos pulsado para descargarlo; sobre todo si inicialmente parecía que tenía la extensión .jpg.

Finalmente, si hacemos click en el archivo (o en la barra de descargas del navegador) para ver la imagen a tamaño completo, seremos infectados. Locky es el ransomware más usado por los atacantes que usan este vector de ataque.

CÓMO PODEMOS EVITAR INFECTARNOS USANDO FACEBOOK

Locky funciona como la mayoría de ransomware; cifra todos nuestros archivos y a continuación pide un pago en Bitcoin para conseguir la clave que los descifre. Los expertos recomiendan no pagar a los atacantes, porque nunca hay ninguna certeza de que realmente recuperaremos los archivos.

Por esto, los expertos que han descubierto el bug de Facebook y LinkedIn recomiendan tomar dos pasos para protegernos:

Si pulsas en una imagen y te pide guardar un archivo, no lo hagas; todas las imágenes que comparten contigo en Facebook deberían verse en el propio navegador.No abras “imágenes” con extensiones extrañas, sin importar de dónde las hayas conseguido.

_______________________________
Tomado de: http://noticiasseguridad.com/hacking-incidentes/cuidado-con-descargar-imagenes-jpg-de-facebook-puede-ser-ransomware/
Se Respetan Derechos de Autor.

jueves, 24 de noviembre de 2016

Fortifica tu SSH para evitar un SSHowDowN Attack!!!


El pasado mes de octubre salió a la luz una nueva debilidad en SSH y las configuraciones por defecto que millones de dispositivos IoT tienen que fue aprovechado por la botnet Mirai. Este fue uno de los vectores que se han utilizado en diferentes ataques DDoS alrededor del mundo y que ha llegado a afectar a empresas tecnológicas tan importantes como Twitter, WhatsApp o Netflix. Hoy en día, se siguen investigando todas las causas del incremento de los ataques en los que se utilizan dispositivos IoT. Una de las vías utilizadas ha sido la debilidad conocida como SSHowDown Proxy.



Figura 1: Fortifica tu SSH para evitar un SSHowDowN Attack!!!

¿Dónde se encuentran los servicios SSH? La respuesta es fácil de entender, en la mayoría de los sistemas conectados a Internet y, es más, en la gran mayoría de los dispositivos IoT. El servicio de SSH nos lo encontramos en televisiones, circuitos de televisión, routers, vídeos, neveras, puntos de acceso y un largo etcétera de dispositivos.



Figura 2: SSHowDownN Proxy

La debilidad de las configuraciones de estos servicios críticos hace que SShowDown Proxy pueda ser utilizado para enviar tráfico a través de dichos dispositivos. El problema radica en los dispositivos y en su configuración por defecto. En como salen de las fábricas y, por supuesto, en la dificultad que tendremos para actualizar firmwares a posteriori. El artículo de hoy no pretende hacer un repaso a SSHowDown, ya que para ello tenemos un artículo interesante de la gente de Akamai, donde se explica en detalle la vulnerabilidad y el riesgo. Aunque a modo de resumen, debemos tener en cuenta:

• Siempre cambiar configuración por defecto del servicio. Por ejemplo, no utilizar contraseñas por defecto, sobretodo en dispositivos conectados a Internet.
• No permitir el reenvío de tráfico TCP, es decir, directiva del fichero sshd_config AllowTcpForwarding a “No”.
• Configurar reglas de tráfico entrante en el firewall para prevenir acceso a SSH en dispositivos IoT. Esto se puede considerar.
• Considerar reglas salientes en el firewall para prevenir la creación de túneles.
• Deshabilitar el servicio SSH a no ser que sea absolutamente necesario.
• Autenticación basada en clave pública en entornos críticos. No permitir usuario y contraseña.En el artículo de hoy, queremos hablar de una herramienta que debe ser una obligatoria de uso en los equipos de pentesting, y sobre todo en las pruebas de la gente de seguridad que podemos encontrar en un equipo de QA. Se debe revisar que las configuraciones, los algoritmos y las implementaciones utilizadas sobre los dispositivos que salen son seguras.

SSH Audit

Hace unos meses hablamos de herramientas que automatizan la auditoría básica sobre un sistema, una serie de verificaciones que permiten ver potenciales fallos de configuraciones o de utilización de software obsoleto. Esta herramienta que podíamos lanzar sobre sistemas GNU/Linux se llamaba Lynis como parte de un proceso completo de fortificación de servidores GNU/Linux, y que permitía hacer ciertas labores de auditoría sobre el sistema.



Figura 3: SSH Audit en GitHub

En esta ocasión, ssh-audit nos permite hacer la auditoría y pasar un listado de buenas prácticas de configuración e implementación sobre un servicio SSH. La herramienta ssh-audit puede encontrarse en su Github. Las verificaciones, que a día de hoy, se encuentran disponibles en la herramienta son:

• Soporte para protocolo 1 y 2 de SSH. Se puede forzar a la herramienta a intentar conectar a través de la versión 1 del protocolo, lo cual no es seguro.
• Banner Grabbing e identificación de dispositivo y software. Además, de verificar la compresión.
• Recopilación del intercambio de claves, host-key, evaluación del cifrado y de los algoritmos que se pueden utilizar.
• Proporciona información sobre la calidad del algoritmo disponible, indicando si se debe eliminar, si no está disponible, si es débil, si no es seguro, etcétera.
• Proporciona información sobre el listado de CVE relacionados, como el Time-Based Info Leak que permite enumerar usuarios en servidores SSH.
• Analiza las implementaciones más comunes como son OpenSSH, Dropbear SSH y libssh.Lanzamos la herramienta para que conecte a través del protocolo versión 2 de SSH y podemos ver cómo se empiezan a lanzar diferentes pruebas basadas en lo enunciado anteriormente:



Figura 4: Ejecución de SSH Audit

Los apartados que la herramienta va cubriendo con las diferentes pruebas son:

• Información general sobre la aplicación, dispositivo o sistema operativo.
• Algoritmos del intercambio de clave. Como puede verse en la imagen anterior, la herramienta comienza a darnos información de que algoritmos debemos mirar con lupa, para ver si deberíamos quitarlos de lo que ofrece nuestro servicio.
• Algoritmos de Host-Key. Como se puede ver en la imagen, nos indican si estamos utilizando pocos bits.

Figura 5: Análisis de sistemas criptográficos

• Calidad de los algoritmos de cifrado que se pueden utilizar con el SSH. Además, nos indican información tan interesante como a partir de que versión se dejó de utilizar el algoritmo.
• Recomendaciones sobre los algoritmos que nuestro servicio está ofreciendo. En este caso, la versión de OpenSSH es la 6.6.1 y podemos obtener un listado de cosas a mejorar.

Figura 6: Recomendaciones de seguridad para este SSH

Las opciones de la herramienta permiten configurar el nivel de verbose que podemos lograr, mediante el uso del parámetro -v o –verbose, podemos indicar el nivel de información (info, warn o fail) con el parámetro –level, el puerto en el que se encuentra el servicio, si el servicio se encuentra en IPv4 o IPv6, lo cual es algo interesante para los servicios que están ya en el direccionamiento IPv6. A continuación, os dejamos una imagen dónde podemos ver la ayuda de la herramienta.



Figura 7: Ayuda de la herramienta SSH Audit

Esta herramienta es realmente útil para los equipos de seguridad de las organizaciones, para la gente de IT y los de QA, ya que en estos ámbitos cada uno necesitará monitorizar la seguridad de los servicios SSH antes de que vayan a ser publicados, comprobar la seguridad de terceros o probar los propios desarrollos y dispositivos que se realizan “in house”. Herramienta que debemos tener a mano, ya que nos permitirá auditar un servicio crítico y de actualidad hoy día.



Figura 8: Configuración de Latch para SSH

Por último, recuerda que si eres responsable de un servicio SSH lo suyo es que pongas medidas extras en la protección de los usuarios. Puedes configurar Latch para SSH o Cloud Latch TOTP para SSH tal y como se explican en esos artículos, y si además te gustan las protecciones de portknocking, puedes configurar un sistema basado en Latch para que el puerto de tu servidor SSH no sea tan fácil de localizar.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell

______________________________________________________________
Se Respetan Derechos de Autor

lunes, 7 de noviembre de 2016

CAINE 8.0: la nueva suite para análisis forense.




En los últimos años han ganado un gran protagonismo todo tipo de distribuciones Linux orientadas a la seguridad informática, a la auditoría de sistemas y redes y al análisis forense de datos. Mientras que si estamos buscando una distribución enfocada a llevar a cabo auditorías de seguridad una de las mejores opciones a tener en cuenta es Kali Linux, a la hora de llevar a cabo análisis forenses de datos, una de las que debemos tener en cuenta es la nueva CAINE 8.0.

La suite forense CAINE, acrónimo de “Computer Aided INvestigative Environment”, es una de las distribuciones Linux más completas para llevar a cabo análisis forense de sistemas y redes. Esta suite cuenta por defecto con un gran número de aplicaciones y herramientas clasificadas en varias categorías, como aplicaciones de análisis de malware, software de recuperación de datos, herramientas para el análisis y la gestión de discos duros y memorias Flash, herramientas de Hash, bases de datos y análisis forense de redes, entre otras.

Novedades del nuevo CAINE 8.0
Recientemente, los responsables de esta suite han lanzado una nueva versión de esta suite, CAINE 8.0, “blazar”, la cual se basa en Ubuntu 16.04 LTS, viene por defecto con el Kernel Linux 4.4 y habilita el clásico escritorio MATE.

Además, sumado al gran número de programas y herramientas incluidas en las versiones anteriores, el nuevo CAINE 8.0 llega con nuevos programas para facilitarnos su trabajo con ella, entre los que podemos destacar IMG_MAP, XAll 1.5, RecuperaBit, SQLParse, PEFrame, Yara, PDF analysis, MemDump, ADB, LibMobileDevice, Gigolo, Shrew, wxHexEditor, Jeex, XRCed, PffLib, imount, vhdimount y vhdiinfo, samba, vblade, iscsitarget, hashdb y Tilda.

Otra de las mejoras que llegan con el nuevo CAINE 8.0 es que ahora la distribución se ejecuta íntegramente desde la memoria RAM (aunque tenemos herramientas para instalarla físicamente, en caso de querer hacerlo a través de SystemBack, una herramienta compatible con sistemas UEFI) siendo capaz incluso de montar todas las unidades en modo “solo lectura” para evitar problemas, pudiendo activar a mano los permisos de escritura en las suites que lo necesitemos. Además, esta suite viene preparada para poder conectarnos a ella de forma remota a través del escritorio VNC.

Como hemos dicho, esta nueva versión de la suite forense ya se encuentra disponible, y podemos descargarla sin coste alguno desde su página web principal, solo disponible para equipos de 64 bits. Si vamos a probar esta suite en VirtualBox, debemos tener en cuenta que puede no funcionar correctamente (especialmente los gráficos y las conexiones) debido a un fallo en el propio VirtualBox que se espera que esté solucionado en las próximas actualizaciones.


__________________________________________________
Tomado de: http://www.redeszone.net/2016/11/02/ya-podemos-descargar-caine-8-0-la-nueva-suite-analisis-forense/
Se Respetan Derechos de Autor

Actualiza Ya! Dos exploit 0-Day para MySQL y MariaDB.

Hace más de un mes el investigador de seguridad polaco Dawid Golunski de descubrió un par de vulnerabilidades críticas en MySQL y publicó los detalles técnicos y la prueba de concepto sólo del segundo error (CVE-2016-6663).

Este martes, Golunski ha publicado una prueba de concepto (PoC) y los exploits de las dos vulnerabilidades: una de ellas es la vulnerabilidad anterior de elevación de privilegios (CVE-2016-6663), y la otra es una nueva vulnerabilidad de escalamiento de privilegios (CVE-2016-6664) que podría permitir a un atacante tomar el control total sobre la base de datos y el sistema operativo.

Las vulnerabilidades afectan a la versión de MySQL 5.5.51 y anteriores, MySQL 5.6.32 y anteriores, y MySQL versión 5.7.14 y anteriores, así como Percona Server y MariaDB.

Escalamiento de privilegios / Condición de carreras Bug (CVE-2.016 a 6663)

La vulnerabilidad más grave de las dos es una condición de carrera (CVE-2016-6663) que puede permitir que una cuenta con privilegios bajos (con permisos de CREATE / INSERT / SELECT) pueda escalar privilegios y ejecutar código arbitrario como usuario del sistema de base de datos (por ejemplo 'mysql').

Elevación de privilegios a Root (CVE-2016-6664)

El otro error crítico es un escalamiento de privilegios que podría permitir a los atacantes con privilegios de usuario "mysql" obtener privilegios de usuario "root" y comprometer totalmente el sistema.

Los errores se deben a la manipulación no segura de archivos de registros que dependen de MySQL, lo que le permite ser reemplazados con otros archivos arbitrarios, lo que abre la puerta a los privilegios de root.

Todas estas vulnerabilidades podrían ser explotadas en entornos de alojamiento compartido, donde a los usuarios se les asigna un acceso a bases de datos separadas. Mediante la explotación de los errores se podría obtener acceso a todas las bases de datos.

Golunski ha publicado la prueba de concepto, el código de la explotación de las dos vulnerabilidades y un video:
MySQL ha solucionado estas vulnerabilidades en su Actualización Crítica de Oracle del mes pasado.

Se recomienda aplicar estos parches tan pronto como sea posible. Si no se puede aplicar los parches inmediatamente, se puede realizar una mitigación temporal y deshabilitar el soporte para enlaces simbólicos dentro de la configuración del servidor de base de datos: en el archivo my.cnf se puede cambiar symbolic-links = 0.

____________________________________________________
Tomado de: http://blog.segu-info.com.ar/2016/11/dos-exploit-0-day-para-mysql-y-mariadb.html#dos-exploit-0-day-para-mysql-y-mariadb
Se Respetan Derechos de Autor