Select Page
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 6

 

Parte 6

 

Haciendo más espacio:

 

Ubicando todas las partes en su lugar, vimos que la batería incrementa varios milímetros la altura del dispositivo completo. Y nos dimos cuenta que este tamaño podría reducirse más si pudiéramos colocar la batería al lado de la UPS. Analizando cómo se podría lograr esto, notamos que la plaqueta de la UPS tiene parte de la superficie sin contactos internos, sólo con el espacio para el conector GPIO y los tornillos. Como no vamos a usar ninguno de esos elementos, podemos cortar parte de la plaqueta y hacer espacio para la batería. En la siguiente figura, se puede ver la plaqueta cortada a la altura de la 3ra fila de perforaciones. El corte se puede hacer con una herramienta filosa pasándola una y otra vez guiados por una regla, sobre la linea que forma la tercer hilera de islas perforadas.

Fig 43 – Cortando parte de la plaqueta de la UPS.

 

Al hacer este corte, se debe tener cuidado de no dañar el cuarto LED que se encuentra en la parte inferior de la plaqueta de la UPS. Finalmente, la batería se puede colocar de esta forma:.

 

Fig 44 – Haciendo lugar para la batería.

 

Como puede verse, todavía se deben que hacer otros cambios. El conector del micro USB en la UPS, debe estar ubicado de forma que se pueda acceder desde el exterior para poder conectarlo al cargador de corriente. Así que se debe desconectar la UPS de la motherboard de la RPi y volverla a conectar con cables flexibles más largos.

En la siguiente imagen se puede ver el resultado:

Fig 45 – Separando la placa de la RPi de la UPS.

 

En la siguiente sección, mostramos el armado de todo el prototipo.

 

 

< Parte 5: Reemplazando el conector HDMIParte 7: Uniendo todas las piezas >

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 5

 

Parte 5

 

Reemplazando el conector HDMI:

 

La Raspberry Pi y la pantalla táctil tienen más conectores de alto perfil que se pueden reemplazar para reducir su tamaño. Dado que el display que utilizamos tiene interfaz de video HDMI, la idea es reemplazar el conector estándar HDMI por un conector más pequeño. Para esto se debe tener en cuenta, que la señal que va a transmitir es de un gran ancho de banda, por lo que no se debería usar cualquier cable o conector. Por este motivo, se eligieron cables planos (ribbon cables) que se utilizan dentro de los circuitos de algunos drones para transmitir las señales de las cámaras de video a sus placas principales inernas. El cable elegido fue comprado en Aliexpress. Su propósito indica: “FPV FPC Ribbon Flat Cable 0.5mm Pitch 20Pin for HDMI HDTV FPV Multicopter Aerial Photography”, es decir “Cable plano tipo cinta, de 0,5 mm de separación, de 20 pines, para HDMI y HDTV para multicópteros de fotografía aérea”.

Un detalle a considerar, es que el conector HDMI posee 19 conexiones, tales como se muestran en la siguiente figura:

.

 

Fig 32 – Pinout del conector HDMI

.

pero no pudimos conseguir cables o conectores de 19 pines. Los que conseguíamos eran de 18 0 20, por este motivo seleccionamos el de 20 pines dejando uno de los pines sin utilizar.

Los conectores y cables utilizados son estos:

Fig 33 – Conectores de cable plano y cable plano de 20 pines.

.

En primer lugar, se retira el conector HDMI de la Raspberry Pi, como se puede ver en la siguiente imagen::

Fig 34 – Conector HDMI retirado de la Raspberry Pi.

.

Después de eso, se suelda el conector de cable plano. Es muy importante notar que el paso de ambos conectores, (el retirado y el nuevo), son exactamente iguales.  De lo contrario, sería imposible soldar el nuevo.

En la siguiente imagen se puede ver el nuevo conector instalado::

Fig 35 – Nuevo conector de cable plano HDMI instalado en la RPi.

 

Dado que el conector tiene 20 pines en vez de 19, se debe decidir cuál pin no utilizar y hacer lo mismo en la plaqueta del display. Nosotros decidimos NO CONECTAR el pin 1.
A continuación, se debe realizar la misma tarea en la pantalla táctil 52Pi. La pantalla en sí está conectada y pegada a la paca principal. Como el proceso de desoldar y soldar debe hacerse con aire caliente, y esto puede dañar la pantalla, ésta debe desconectarse y desacoplarse de la placa principal.

Inicialmente se desconectan los cables planos que interconectan el display y la placa principal. En la siguiente imagen, se pueden ver dos cables planos desconectados:

Fig 36 – Cables planos del display 52Pi desconectados.

El proceso de despegar ambas placas, debe hacerse con mucho cuidado. El trabajo se facilita si se utiliza algún tipo de calentador de displays de celulares que elevan la temperatura a no más de 100 grados. Una vez elevada la temperatura, el pegamento se ablanda por lo que insertando una herramienta delgada entre el pegamento y la superficie de la plaqueta, se puede ir despegando con cuidado hasta hacerlo completamente.

La siguiente imagen muestra la pantalla desacoplada de la placa principal de la pantalla táctil:

Fig 37 – Display 52Pi despegado de la placa.

.

Posteriormente, el conector se quita utilizando aire caliente:

Fig 38 – Conector HDMI del display 52Pi desoldado.

De la misma forma, se instala el conector para cable plano. Se debe recordar cuál de los pines extremos del conector se decidieron dejar sin uso. En nuestro caso, eliminamos el número 1.

 

Fig 39 – Conector HDMI del display 52Pi desoldado.

Este es un buen momento para probar si el display funciona por si se deben repasar las soldaduras. Para ello, se debe conectar el cable plano entre las dos placas, la RPi y la 52Pi.

 

 

 

Fig 40 – Detalle del display HDMI conectado a la Raspberry Pi.

.

Fig 41 – Por ahora… todo funciona…

Como el conector micro USB aún no está conectado, la alimentación de la pantalla para la prueba se debe realizar con una fuente de alimentación externa.

 

El conector micro USB en el display no se eliminó porque no aumenta demasiado el perfil. Para finalizar las conexiones, se debe conectar la interfaz USB del display a la RPi. Esto permite alimentar el display y transferir los datos del touchscreen a la RPi.
Al no eliminar el micro USB del display, la forma de conectarlos es cableando una ficha micro USB macho a una de las lineas USB libres de la RPi. Esto se puede ver en la siguiente imagen:

 

 

Fig 42 – Conector micro USB cableado a la Raspberry Pi.

En la siguiente sección, mostramos cómo seguir reduciendo espacio.

 

 

< Parte 4: El turno del WiFiParte 6: Haciendo más espacio >

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 4

Parte 4

 

El turno de WiFi:

 

Como se explicó en el capítulo de Diseño, además de la interfaz WiFi incluida en el RPi, necesitábamos añadir 2 adaptadores WiFi extra. Como para mi proyecto, el dispositivo inalámbrico debe poder funcionar como estación (STA), como Access Point , como monitor y como inyector de paquetes, se seleccionó el adaptador Tenda W311M basado en el chipset Ralink RT5370. Para conectar los dos nuevos adaptadores sin contar con la la interfaz USB, se desarman los adaptadores USB y se sueldan a la RPi.

 

 Fig 25 – Adaptador WiFi USB Tenda W311M.

El proceso de desmontaje del W311M es tan simple como insertar un pequeño destornillador plano en un lado del adaptador, donde las dos mitades de la caja de plástico se unen… y separarlas:

Fig 26 – Adaptador WiFi USB Tenda W311M desarmado.

 

Una vez desmontados los componentes, la única pieza que se necesita es la pequeña placa de circuito:

 Fig 27 – Circuito del adaptador USB Tenda W311M.

 

 

Ahora, se deben conectar los dispositivos WiFi a los puertos USB pero sin los conectores USB de la RPi. Una vez que se retiran los conectores USB, el área de la placa de circuito impreso de la RPi muestra el siguiente aspecto:

Fig 28 – Zona del conector USB en la placa Raspberry Pi.

Aquí se pueden identificar 4 líneas de 4 agujeros cada una. Cada línea de 4 agujeros es la entrada de cada uno de los 4 puertos USB. El pinout se muestra de la siguiente manera:

 

 

Fig 29 – Pinout del conector USB en la placa Raspberry Pi

Por otro lado, el pinout del adaptador WiFi Tenda W311M es como se muestra en la siguiente imagen:

Fig 30 – Pinout del adaptador Tenda W311M.

 

El adaptador debe soldarse a la RPi mediante cables delgados. A continuación puede verse una imagen de los dispositivos conectados:

Fig 31 – Adaptadores WiFi soldados a la RPi.

 

De más está decir, que las conexiones deben hacerse respetando el pinout, es decir, cada adaptador WiFi debe cablearse a la RPi conectando Vcc con Vcc, D- con D-, D+ con D+ y GND con GND. Tal como se ve en la Fig. 31.

 

 

En la sección siguiente, mostramos cómo conectar el display touch screen.

 

 

< Parte 3: Perdiendo pesoParte 5: Reemplazando el conector HDMI >

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 2

Parte 2

 

Diseño:

 

Con el fin de reducir al máximo el tamaño del hardware, Juan y yo encontramos este gran tutorial (Diet Raspberry Pi) de Phillip Burgess. La plauqueta final del proyecto de Burguess se ve así:

 

Fig 8 – “La Diet Pi Raspberry Pi” de Phillip Burgess

Inicialmente decidimos seguir el tutorial pero como todavía el tamaño resultaba grande, fuimos poco más allá. Por ejemplo, nosotros no necesitamos los conectores USB, los de audio o el de la cámara.

Si tenemos en cuenta que los tamaños relativos de los componentes más grandes son como se muestran en la siguiente imagen:

 

 

Fig 9 – Componentes del proyecto

Nuestra intención era ubicarlos de forma de ocupar el menor espacio posible, en dos planos, como se ve en la siguiente figura:

Fig 10 – Distribución de los componentes.

Según el dibujo, la RPi 3, la UPS y la batería se colocarán en un plano, y la pantalla táctil HDMI en el otro.

 

 

Ya está planteado el diseño, ahora es el momento de poner manos a la obra…

 

 

< Parte 1: MotivaciónParte 3: Perdiendo peso (Raspberry Pi) >

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 3

Parte 3

 

Perdiendo peso

#1 – Raspberry Pi:

La primera tarea consiste en quitar las partes innecesarias de la Raspberry Pi. El tutorial Diet Raspberry Pi tiene una explicación muy clara sobre cómo hacerlo. Esto es lo que hicimos. La mejor forma de retirar los componentes es mediante un soldador de aire caliente.

Las siguientes fotos muestran el modelo completo de la Raspberry Pi B:

 Fig 11 – La Raspberry Pi B completa

 

Lo primero que se dee hacer es quitar los conectores USB.

Fig 12 – La Raspberry Pi sin los conectores USB.

 

Luego quitamos el conector Ethernet:

Fig 13 – La Raspberry Pi sin el conector Ethernet

 

Luego se retira el conector GPIO:

Fig 14 – La Raspberry Pi sin el conector GPIO

 

Y como tampoco necesitamos la cámara ni los puertos de audio, los quitamos también:

Fig 15 – La Raspberry Pi sin conectores.

Después de cada tarea de eliminación, es importante comprobar si la Raspberry Pi sigue funcionando o si se ha producido algún daño durante el proceso. Como todavía el conector de alimentación mini USB y el conector HDMI están en su lugar, se puede probar si la RPi bootea normalmene. Simplemente se debe conectar la tarjeta SD, el adaptador de power y un monitor HDMI y verificar simplemente si bootea. Si no es así, se deberían buscar cortocircuitos, componentes quemados o pistas cortadas en la plaqueta.
Una vez retirados los puertos USB y hasta que se conecte la pantalla táctil, no hay forma de verificar las entradas del teclado y mouse. Así que, si el RRi arranca normalmente, se debe vivir con la incertidumbre de si funciona o no el subsistema de entradas hasta conectar la pantalla táctil.

 

#2 UPS

Las mismas tareas que se hicieron con la RPi se deberán hacer con la UPS Geek worm. Si bien la UPS fue diseñada para funcionar conectada al puerto GPIO de la RPi, sólo se utilizan 8 conexiones que serán las que deberán cablearse para el presente proyecto. El dispositivo completo se muestra en la siguiente imagen:

 

Fig 16 – UPS Geek work original.

 

La idea es quitar el conector GPIO de la placa UPS, alinear ambas plaquetas en el mismo plano y cablear las 8 conexiones necesarias entre ellas:

 Fig 17 – Sujetando la plaqueta de la UPS para desoldar el GPIO.

 

 

 

El resultado es la reducción en la altura total del espacio que ocupa la plaqueta:

 Fig 18 – La UPS Geek worm sin el conector GPIO.

#3 Uniendo la RPi y la UPS

Habiendo adelgazado ambas plaquetas, ahora se debe proceder a interconectarlas. Dado que se quitaron los conectores GPIO de ambas, se deberán cablear a mano. Ambos dispositivos alineados se muestran en la siguiente imagen:

Fig 19 – Vista superior de la Raspberry Pi y de la UPS.

Fig 20 – Vista inferior de la Raspberry Pi y de la UPS.

No pudimos encontrar ningún circuito de la la placa UPS Geek worm online, así que, haciendo un poco de ingeniería inversa, encontramos que sólo los primeros 8 pines (números del 1 al 8 del GPIO) están conectados entre ambas placas. Aquí se muestran los pines que se conectan:

 

Fig 21 – Pines a conectar entre la Raspberry Pi y la UPS Geek worm.

 

Entonces, para conectar los pines 1 → 1, 2→ 2, …, 8 → 8; entre las dos plaquetas ubicadas en el mismo plano, decidimos cablearlas de la siguiente forma:

 

 Fig 22 – Cableado entre la Raspberry Pi y la UPS Geek worm.

 

 

Primero pegamos ambas plaquetas con cinta de papel a los niveles de los agujeros para asegurarnos de que ambos paneles estém en el mismo plano. Después, se sueldan 4 alambres de cada lado como se puede ver en las siguientes imágenes:

Fig 23 – Vista de la Raspberry Pi y la UPS Geek worm unidas.

 

Fig 24 – Vista superior de la Raspberry Pi y la UPS Geek worm soldadas.

 

NOTA: Este diseño se cambió más tarde. Esto se hizo porque necesitábamos alinear el conector USB de power de la UPS con el orificio del gabinete. Por este motivo, la RPi y la UPS se separaron entre sí unos milímetros. Este cambio se muestra más adelante en este documento.

 

 

< Parte 2: DiseñoParte 4: El turno de WiFi >

 

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Prototipo portátil WiFi basado en RPi – Parte 6

Prototipo portátil WiFi basado en RPi – Parte 1

Parte 1

 

Motivación:

 

Hace un tiempo vengo desarrollando algunos proyectos de ciberseguridad basados en dispositivos portátiles que gestionan tráfico WiFi. Para las primeras etapas o PoCs de cada proyecto utilicé máquinas virtuales y dongles USB WiFi. Pero luego de las pruebas en VMs quise probar los dispositivos en el mundo real.

Para construir los prototipos, pasé bastante tiempo buscando placas de desarrollo que puedan ser parecidas al dispositivo final y que puedan ser utilizadas en el mundo real. Como no pude encontrar ningún dispositivo 100% adecuado, decidí construir mi propio prototipo de hardware basado en componentes comerciales. Para esto, sabía que iba a tener que sumergirme en el hardware, quitando y agregando componentes. Después de muchos años de haber cambiado el soldador por el teclado, mi toque con la soldadura quedó perdido en el tiempo. Y como sabía que necesitaba bastante trabajo de este tipo, le pedí a mi sobrino Juan Carlos que me ayudara. Juan es un verdadero experto en soldadura de piezas tan minúsculas que es imposible verlas a simple vista. Aceptó, así que comenzamos este proyecto juntos.

Mi principal objetivo fue el de construir un prototipo portátil para probar mis propios proyectos. Fue tanto trabajo y los problemas que tuvimos que resolver, que decidimos publicar este tutorial por si alguno de ustedes quisieran utilizarlo en cualquier otra aplicación que requiera un hardware similar.

Es muy importante aclararles que la construcción del dispositivo es 100% casera. Esto tiene la ventaja de que los costos son muy bajos pero la desventaja de que puede ser inestable y que haya que retocar soldaduras cada tanto. Habiendo hecho esta advertencia, comenzamos con el tutorial.

El dispositivo completo debía incluir una motherboard capaz de ejecutar Linux, con una CPU, una RAM, varios adaptadores WiFi, una pantalla táctil, un sistema de batería con posibilidad de carga y un botón de encendido/apagado.

El diagrama de bloques del dispositivo proyectado se puede ver en la siguiente figura:

Fig 1 – Diagrama en bloques del proyecto.

 

Las características mínimas del dispositivo son las siguientes:

– CPU basada en ARM.
– Capacidad para manejar dispositivos USB.
– 3 dispositivos WiFi.
– Una pantalla touch screen.
– Batería y cargador.

En mi caso particular, no necesitaba ninguno de los siguientes dispositivos:

– Adaptador ethernet.
– Cámara.
– Audio.
– Otros dispositivos USB.

 

Idea:

Para cumplir con los requisitos del prototipo, seleccionamos y compramos los siguientes componentes:

– 1 Raspberry Pi 3 B (U$S 36.00) .
– 1 microSD card, clase 10, 32 GB (U$S 6.00).
– 1 800×480 HDMI 5” Capacitive Touch Screen Display (U$S 45.00).
– 1 Batería y cargador de baterías, Geek worm UPS Hat Module para Raspberry Pi 3.7V, 2500 mAh (U$S 15.00).
– 2 Dongles Tenda USB WiFi W311M (U$S 8.00).
– 2 Conectores para cable plano de 0.5mm de separación (U$S 3.00).
– 1 FPV FPC cable plano de 0.5mm de separación, de 20 pines y de 5 cm de largo para HDMI (U$S 1.00).

El costo total de los materiales es de aproximadamente U$S 114.00

 

Como todos saben, las Raspberry PI son una de las placas SBC más populares del mundo. Se utilizan para muchos proyectos como prototipos e incluso de producción. Se pueden encontrar muy fácilmente en muchos comercios de electrónica y en infinidad de sitios online. También existen online un gran número de complementos, proyectos y tutoriales, por lo que es muy fácil crear nuevos basados en los están publicados. Esa es la razón principal por la que decidimos elegir Raspberry Pi como hardware central para nuestro proyecto.

 

Primeros Pasos:

Nuestro primer paso fue el de unir todas las partes y hacerlas funcionar. El objetivo fue el de comprobar que todo funciona y que la selección de las partes fue la correcta. Los componentes necesarios para el prototipo se muestran en las siguientes imágenes:

Fig 2 – Raspberry Pi 3 B

Fig 3 – TFT Touch Screen Display

Fig 4 – Geek worm UPS RPi Hat

Fig 5 – Adaptador Tenda WiFI USB.

En la siguiente figura, se muestran todos los componentes conectados y funcionando:

Fig 6Primer intento por conectar todo y hacerlo funcionar.

Esta disposición es adecuada para realizar pruebas en el laboratorio, pero no es posible transportar el dispositivo para pruebas de campo.

 

El segundo intento fue diseñar y construir una caja capaz de contener todos los elementos. El resultado se muestra en las siguiente imagen:

Fig 7 – Segundo intento para instalar todo en una caja

 

Gonzalo, quien me llevó al mundo de las impresoras 3D, diseñó, imprimió y armó este proyecto de gabinete que pudiera alojar todos los elementos del prototipo. El tamaño mínimo que pudimos alcanzar fue de 165mm x 95mm x 50mm (6 ½” x 3¾” x 2”). Este no es precisamente un tamaño de bolsillo o que sea muy portátil que digamos…. Es por esto que iniciamos con Juan el proyecto de reducción del hardware.

 

 

En las siguientes partes del tutorial muestran todos los pasos que llevamos adelante para lograr la reducción y la construcción de un prototipo como el que necesitábamos, que fuera realmente portátil.

 

Parte 2: Diseño >

 

 

Nota por Carlos Benitez y Juan Carlos Ferro

 

Carlos Benitez es un reconocido experto en seguridad de la información.
Teamviewer hackeado

Teamviewer hackeado

Ya la existencia de Teamviewer en nuestras redes era difícil de tragar para quienes trabajamos en ciberseguridad, cuánto más lo será ahora que la empresa reconoce que fueron hackeados.
En una nota publicada en la revista Der Spiegel la empresa reconoce que en el año 2016 fue inflitrada por grupos de hackers probablemente chinos.

La noticia fría, reza que Teamviewer fue ciberatacada en 2016 pero que no se informó del incidente en ese momento, ya que ellos consideraban que no se comprometieron datos de los usuarios. También es cierto que para esa fecha, no estaba todavía en vigencia la GDPR a través de la cual, hubiesen estado obligados a informar el incidente.Como bien se sabe, Teamviewer produce el software homónimo cuyo propósito es el de RDT (Remote Desktop Tool = Herramienta de Escritorio Remoto), que nos permite trabajar en nuestra máquina, desde nuestras casas, como si estuviésemos sentados en nuestro escritorio.

Un dato técnico de importancia es que, según informan los responsables de Temviewer, sus sistemas fueron infectados con el malware Winnti, un troyano tan, pero tan elaborado que se lo considera APT (Advanced Persistent Threat = Amenaza Avanzada Persistente).

Si bien el malware, parece haber nacido en 2010, viene creciendo, desarrollándose y madurando. Esa maduración le permitió saltar de la irresistible plataforma Windows, a Linux. Esto sucedió en el 2015, cuando infectó los sistemas de una empresa de videojuegos. Los grupos que parecen estar detrás de este malware serían los APT10 o APT17. Como se puede ver en las referencias, ambos grupos han sido relacionados con el estado chino.

Ok, ahora ¿cuál la diferencia entre RDTs (Remote Desktop Tools) y RATs (Remote Access Tools -o Trojans-)? Todos tenemos terror a los RATs, pero dejamos que existan los RDTs que nos piden instalar los usuarios, no? Bueno, les cuento que la diferencia es sólo semántica. Todas son herramientas que le dan acceso remoto total a un equipo desde el exterior, para un usuario… o para un intruso. Temviewer entonces, ¿es un RDT… o un RAT? Que un usuario instale y utilice por su cuenta, sin control del administrador, una herramienta como estas, compromete seriamente la seguridad de la red, por lo que realmente no hay diferencias. Es una herramienta tan poderosa como peligrosa.

En algunos sectores, como el de salud, se reconoce que la principal amenaza hoy en día ya no es el ransomware, sino los túneles que abren los intrusos por https para pasar inadvertidos. ¿Y si son los usuarios los que instalan túneles por https sin control de los administradores? ¿Y si además, el software utilizado fue “mejorado” inadvertidamente por alguno de los grupos de APT que mencionamos anteriormente, cuando estuvieron de “visita” en los servidores de Teamviewer en 2016?

Casualmente, en ese momento, muchos usuarios reportaron que sus computadoras (con Teamviewer instalado y activo) fueron accedidas por hackers que intentaron robar dinero de sus cuentas de PayPal o comprar productos desde sus cuentas de eBay. Los responsables de Teamviewer declararon en su momento, que no hubo ninguna intrusión, y que los incidentes fueron producidos porque los atacantes le robaron sus contraseñas a los usuarios. Como la culpa es siempre de los usuarios, esto no pasó a mayores.
Pero Les Luthiers responderían a esto… “Carámba! qué coincidencia…!”

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Cayendo en la trampa del Fallback…

Cayendo en la trampa del Fallback…

La empresa china eyeDisk desarrolló lo que prometía ser un pendrive “inhackeable“[1] y terminó siendo tan inseguro como cualquiera, por el inocente agregado de un fallback.

Todos los que estamos en este negocio, conocemos las dimensiones de seguridad de la información. Las 3 principales son: confidencialidad, disponibilidad e integridad. Nuestra tarea desde seguridad, es la de definir el esfuero y los recursos para protegerlas adecuadamente. Pero dependiendo del contexto y del negocio o la misión particular, a veces no todas las dimensiones se deben proteger de la misma forma.

 

Un caso extremo:

En el caso de las redes OT, a través de las que se controlan procesos industriales, la dimensión más importante a proteger es la disponibilidad. Muy especialmente en infraestructuras críticas. La interrupción de un servicio o proceso industrial no sólo puede llegar a costar muchísimo dinero, sino que además puede provocar gravísimos daños en el equipamiento o hasta en el medio ambiente. Es por esto que todas las medidas de protección van a estar enfocadas en que la disponibilidad sea lo más invulnerable posible. Integridad y confidencialidad se dejan en segundo plano.

 

Un caso intermedio:

Al desarrollar sistemas de protección, muchas veces se establecen, diseñan e implementan estrategias de vías o caminos alternativos para el caso que algún componente falle. Es el esquema de “fallback” o “plan B” en el que a veces se deben establecer relaciones de compromiso en las que se pierden o degradan algunas características de seguridad para mantener otras.

Un ejemplo de esto es el sistema de cifrado de la telefonía celular. Cuando se establece una comunicación entre teléfonos celulares, la información viaja cifrada. Esto se hace para que nadie que tenga un receptor de radio en la frecuencia de emisión de la comunicación, pueda interceptar fácilmente las conversaciones. El sistema de cifrado que se usa en GSM es la familia A5. Sin entrar en la discusión de las vulnerabilidades particulares de estos algoritmos (tanto A5/1 como A5/2 fueron rotos), es importante mencionar que la familia está compuesta por 5 miembros: A5/0, A5/1, A5/2, A5/3 y A5/4.

Cada algoritmo posee mayores fortalezas de cifrado que el anterior y, como consecuencia, de consumo de recursos. A pesar de que muchas veces no lo notamos por las deficiencias de las redes, en realidad los sistemas celulares están diseñados para que las comunicaciones nunca se interrumpan. Entonces, el uso de algoritmos de cifrado más fuertes, está íntimamente relacionado con contar con muy buena señal en los dispositivos. ¿Qué pasa entonces si estamos en una condición de baja señal? El sistema tiene varias instancias de fallback, en las que los algoritmos de cifrado se van degradando para no perder la comunicación. En el caso de tener muy baja señal, nuestros celulares bajan hasta el modo A5/0 en el que la comunicación no se cifra en absoluto. En este caso, alguien podría escuchar nuestras conversaciones.

Pero el negocio manda. Es decir, en telefonía celular, si bien no es tan crítico como en el caso de sistemas industriales, la dimensión que más se preserva es la de disponibilidad. ¿La razón? es más que obvia: segundo que el sistema no funciona, segundo que no se factura…

El fallback que implica la degradación de la privacidad está incorporado por diseño con toda la intención de que sea así.

 

Un caso erróneo:

Ahora bien, cuando se diseña un dispositivo cuyo principal objetivo es preservar la confidencialidad. Cuando se anuncia con bombos y platillos que el sistema es absolutamente “inhackeable“, se deben tomar ciertos recaudos. La firma china eyeDisk desarrolló por la modalidad de crowdfunding un pendrive que incorpora la sofisticada tecnología de lectura de iris para asegurar la confidencialidad de los datos que él se almacenen.

Según sus especificaciones, el acceso a los datos sólo puede hacerse mediante la lectura de iris del dueño. Teniendo en cuenta que el sistema de lectura de iris es resistente a la lectura de imágenes o fotografías, la empresa parecía haber creado el perfecto “for your eyes only“…

Sin embargo, David Lodge, de PenTestPartners, descubrió recientemente que si bien la resistencia a ataques de lectura de iris es real, el fallback del sistema compromete completamente la confidencialidad tan promocionada. Si la lectura de iris falla, se puede desbloquear el contenido del pendrive con una contraseña provista por el usuario al momento de la configuración.

Resulta que investigando la manera en la que se transfieren los datos, el investigador descubrió que internamente, la contraseña almacenada se transfiere via USB desde el dispositivo a la PC antes de la validación y en texto plano!!! Por esta razón, con sólo un poco de conocimientos y esfuerzo, es posible obtenerla y usarla…

 

Usando fallbacks

Hay veces que sinceramente no entiendo la forma en la que se diseñan los sistemas. En el caso de eyeDisk “el” argumento de venta del producto es la imposibilidad de que sea hackeado. El usuario debería quedarse 100% tranquilo de que si pierde un pendrive con información valiosa, nadie tendría forma de recuperarla mientras el pendrive no vuelva a encontrarse con el ojo del dueño. El concepto es muy bueno…!!! ¿qué necesidad hay entonces de crear un fallback que permita al usuario desbloquear el pendrive haciendo un bypass de la principal protección del sistema, la lectura del iris? ¿para qué dar esa vuelta más innecesaria cuando al hacerlo se destruye por completo el concepto inicial?

Al pensar, diseñar y construir dispositivos o sistemas, se los dota a éstos de un objetivo. Si se hacen bien las cosas, ese sistema deberia cumplir perfectamente con su objetivo y hacer sólamente eso, la razón para la cual fue diseñado. Esto es lo que diferencia a un producto líder de uno del montón, el hacer muy bien su trabajo. El error se comete cuando se intentan agregar objetivos o funciones extra, y es en esa diversificación innecesaria, cuando lo que se hacía muy bien en principio bien, se termina diluyendo.

En sistemas muy complejos, con muchos componentes y escenarios posibles, en los que se debe tener siempre una respuesta válida, son necesarios los fallbacks. Pero éstos deben estar bien pensados. Porque sino, podríamos sin darnos cuenta, caer en la trampa del fallback, instalando por ejemplo un botón que abra la puerta de calle de nuestras casas desde el exterior, por si nos olvidamos el token de la cerradura electrónica que acabamos de instalar en nuestra nueva puerta blindada…

 

[1] Perdón por el término, pero fue lo mejor que pude traducir la palabra original del fabricante, es decir: “Unhackable”…

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Nueva sección: Tutoriales

Nueva sección: Tutoriales

Se agrega al blog una sección de Tutoriales.

En esa sección se voy a publicar básicamente dos tipos de notas. Uno, paso a paso de cómo resolver problemas cuyas soluciones son muy difíciles de hallar en la web. El otro, formas locas de cómo hacer cosas de las que no hay información en la web.

Empiezo con un tutorial sobre cómo resolver un problema de booteo de FreeNAS. Encontrar la solución me costó varias horas habiéndome paseado por decenas de blogs y tutoriales. En la mitad, las condiciones de error no eran exáctamente la misma que el mío. En la otra mitad, las soluciones eran incorrectas. Después de horas de prueba y error llegué a solucionarlo,  así que decidí compartirlo.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Qué hacer cuando se corrompe un pendrive de booteo de FreeNAS

Qué hacer cuando se corrompe un pendrive de booteo de FreeNAS

Hace un tiempo intenté regenerar uno de los dos pendrives de mi FreeNAS y al intentar bootear, el sistema se trabó en el grub en modo de rescate.

Lo que aprentemente sucedió es que uno de los dos pendrives quedó corrupto, seguramente el sector de booteo. El resultado fue que el FreeNAS no volvió a bootear.

Para solucionarlo, me maté buscando en decenas de blogs y tutoriales y por más que los seguí a todos, no hubo forma de que el server volviera a bootear.
Finalmente, y basado en este blog, logré recuperar el pendrive y bootear el FreeNAS sin perder la configuración de los discos y, por lo tanto, los archivos.
Les dejo los pasos por si les ocurre lo mismo.

 

1- Bajar el FreeNAS Installer y flashear un pendrive.

2- Conectar los dos pendrives, el nuevo FreeNAS Installer y el viejo FreeNAS en dos interfases USB.

3- Bootear el sistema con el FreeNAS Installer.

 

4- Ir a “2 Shell

5- Dentro del shell, ejecutar el siguiente comando:

# zpool import

Debería mostrarse la lista de dispositivos USB y seguramente el dispositivo de booteo estará en modo DEGRADED.


NAME                                            STATE      READ  WRITE CKSUM
Pool00                                          ONLINE       0     0     0
  freenas-boot                                 DEGRADED      0     0     0
    gptid/32793a9a-d545-11e7-bf07-bc5ff4aa74ab  ONLINE       0     0     0
    gptid/33528494-d545-11e7-bf07-bc5ff4aa74ab  ONLINE       0     0     0
    gptid/342e9d9f-d545-11e7-bf07-bc5ff4aa74ab  ONLINE       0     0     0
    gptid/34eeccb2-d545-11e7-bf07-bc5ff4aa74ab  ONLINE       0     0     0

 

6- Ejecutar:

# zpool import -f freenas-boot

Esta operación puede demorar varios minutos

 

7- Para verificar que el pendrive se está regenerando, se puede ejecutar

# zpool status -v

Esta operación también puede tardar varios minutos….. (aparece en estado “resilvering”, es decir, reconstruyendo el espejado entre los pendrives).

 

8- Una vez que termine, ejecutar:

# zpool scrub freenas-boot

Hasta que no termine de hacer el resilvering, no nos va a dejar hacer el scrub. El comando scrub (restregar) analiza los discos en busca de problemas de integridad en los datos.

 

9- Una vez que finalize el scrub, al hacer # zpool status, van a aparecer algunos dispositivos en modo UNAVAILABLE. Ejecutar lo siguente por cada dispositivo UNAVAILABLE que aparezca:

# zpool detach freenas-boot <UNAVAILABLE #ID>

 

10- Finalizados los detach, ejecutar:

# zpool scrub freenas-boot

 

11- Finalmente, reiniciar con:

# reboot

 

12- Para bootear, seleccionar el USB donde está el freenas-boot regenerado.

 

Yo así pude recuperar mi FreeNAS 11.1, espero que les haya servido, hasta la próxima!

 
 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.