FLISOL 2019

He tenido la oportunidad asistir a medias a dos flisoles y de dar una charla en ambas, paso a compartir la experiencia y las notas de la charla.

Avellaneda

Sólo pude asistir a la de Marcos Russo de centrux de Docker, me hubiera gustado que fuera más demo que presentación, entendiendo que habiendo conectividad dudosa se complica preparar el entorno para hacerla off-line.

CABA

Sólo pude asistir a la de Tor, que se convirtió más en meetup que la exposición planeada por que ocurrió una turbia circunstancia que impidió que quienes iban a exponer pudieran hacerlo. Pese a que no tengo información completa de lo que ocurrió, por lo cual no voy a decir nada más que lo que voy a decir, mi intuición me dice que fué un acto de malicia intencional.

Charla de ponderación y clasificación de vulnerabilidades

El objetivo como siempre es estimular el pensamiento atacante/defensor propio de la seguridad de la información, con la variedad de tener herramientas no tan subjetivas para evaluar como lidiar con la vulnerabilidades.

No voy a transcribir el contenido completo, ni pegar la presentación, es más bien un machete con las ideas principales y los links, útil para quien asistió y no tomó nota o por si la diera otra vez (lo dudo, la dí seis veces en el trabajo, ya me aburrió y creo que ya asistieron todas las personas a las que les podía interesar) tengas elementos para evaluar si te interesa asistir.


Dado el tiempo disponible de sólo la mitad no pude hacer los ejercicios que hago en el trabajo pero mejor, no creo que quienes están buena parte del día en el evento se aguanten dos horas de este tema.

Algunas definiciones

Falla: comportamiento no previsto

Amenaza: algo que puede dañar

Vulnerabilidad: defecto en un sistema que lo deja expuesto ante una amenaza

Vulnerabilidad: es una falla explotable




Riesgo: probabilidad de que el daño se produzca

Y esta es el primer acercamiento a medir una Vulnerabilidad:

Riesgo = Amenaza * Vulnerabilidad

Gestión de riesgo

• Mitigar
• Asumir
• Transferir
• Evitar
• Ignorar (*)
• No gestionar (*)

Las dos últimas no figuran en los libros pero si en la realidad y se las suele confundir con "Asumir".

Una pisca de teoría de Seguridad de la Información

• Confidencialidad
• Integridad
• Disponibilidad

Esas tres palabrìtas son la base de la S.I., como armonìa, melodía y ritmo para la música y nos llevan al segundo acercamiento a medir algo:

Riesgo = consecuencia * probabilidad

Riesgo = (C + I + D) *(amenaza * exposición)

Se le da un valor entre 0 y 1 a cada aspecto.

Algunos métodos útiles para reflexionar

 

DREAD

Damage – how bad would an attack be?
Reproducibility – how easy is it to reproduce the attack?
Exploitability – how much work is it to launch the attack?
Affected users – how many people will be impacted?
Discoverability – how easy is it to discover the threat?



Se le pone a cada item un valor de 1 a 10.

Lo usó Microsoft hasta 2008.


Más detalles:  https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model)

STRIDE

Threat	Desired property
Spoofing	Authenticity
Tampering	Integrity
Repudiation	Non-repudiability
Information disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

Fijage que en la columna de atributos deseados aparecen Confidencialidad, Integridad y Disponibilidad, sumándose autenticación, autorización y no repudio, que forman los seis conceptos básicos de la S.I.


Mas detalles: https://en.wikipedia.org/wiki/STRIDE_(security)

Detección de vulnerabilidades

• Modelado
• attack tree, data flow, stride, que pasa si...
• Pentesting
• white vs gray vs black box
• perimetral (automática, infraestructura)
• Análisis estático de código
• in the wild
• reportes ajenos

 CVSS V3

Y por fín, la medición actual, a leer:

https://www.first.org/cvss/calculator/3.0

Esta dividido en tres regiones:

Base: es la calificación de la vulnerabilidad "en el aire", sin relación con lo que la rodea, es atemporal, una vez definida no debería cambiar salvo se descubra un error.

Temporal: es una modificación introducida por la evolución en el tiempo de los exploits que hayan, la confirmación y corrección oficial

Entorno: es la aplicación en un entorno particular y considerando los requerimientos relativos a CID.

La clave de este tema es entender que el nucleo está conformado por el impacto en la Confidencialidad, Integridad y Disponibilidad.

Clasificación

 

Para mi hay distintas categorías de clasificación:

"Muertas", o sea, es un amontonamiento de información histórica y "Vivas", se van adaptando al momento, priorizan según algún criterio de frecuencia y éxito.

• Muertas
• Taxonomías 
• Seven Kingdoms 
• CWE
• Enumeraciones
• CVE
• Bugtraq
• Full Disclosure
• 
  
• Vivas 
• CWE-25 (zombie, no se actualiza desde 2011)
• OWASP Top Ten
• Web
• Mobile
• IoT

Rehacer una imagen live

El otro día el ProfMatías preguntó en el chat de CaFeLUG como no montar los discos rígidos en una máquina arrancada con puppy linux pues tenía el requerimiento institucional de que los alumnos no puedan tocar el windows presente.

Una idea propuesta fue virtualizar, pero también tenía la restricción de hardware incapaz.

Otra usar una distro de tipo forense, que no monta por default los discos.

Otra modifar la imagen, desde poner un script al arranque que desmonte hasta que ni siquiera pueda montarlos, pasando por que no los monte.


Esto es lo que hice para preparar el terreno para lo último. Asumo que algo sabés de administración linux y que tenés mucha curiosidad e iniciativa, así que no entro en detalles menores como por ejemplo cómo y qué editar de syslinux.conf, ni explico nada que puedas hallar en man xxx y entiendo que cuando ejecutes unsquashfs y te diga que no está, llames a tu gestor de software y te lo instales.

Si incluyo los pasos concretos obvios como el wget, es para que esto sirva como base para un script genérico que en algún momento githubearé.

Los programas necesarios

• wget
• mount
• mkisofs
• unsquashfs
• mksquashfs
• editor de texto preferido

La estructura de directorios

• old/
• rebuild/
• puppy_xenialpup64_7.5/
• zdrv_xenialpup64_7.5/
• new/
• xenialpup64-7.5-uefi.iso
• xenialpup64-7.5-uefi-new.iso

Los pasos a seguir

• Copiar todos los archivos de la imagen original a la nueva imagen
• Descomprimir los squashfs presentes
• Modificar los archivos deseados
• Reconstruir los squashfs
• Rehacer la imagen

Manos a la obra

Crear estructura de directorios

Una carpetita para el live original, otra para el que queremos como resultado

mkdir old new

Obtener imagen

wget  \
http://distro.ibiblio.org/puppylinux/puppy-xenial/64/xenialpup64-7.5-uefi.iso \
-o xenialpup64-7.5-uefi.iso

Montar la imagen

Para poder acceder a los elementos de la imagen.

sudo mount -t iso9660 -o loop xenialpup64-7.5-uefi.iso old

Terminar de crear los directorios faltantes

 

Es que hasta este momento no los conocíamos, son los que hay en old/*.sfs sin la extensión.


mkdir -p rebuild/puppy_xenialpup64_7.5 rebuild/zdrv_xenialpup64_7.5

Copiar todo de la iso a la nueva imagen

Para tener lo mismo que tiene la live original

sudo cp -a old/* new

Luego los *.sfs serán actualizados.

Desplegar los squashsfs

Hay que tomar cada *.sfs y descomprimirlo para poder hacer modificaciones en el sistema de archivo que será montado cuando inicie la live.


cd rebuild

cd puppy_xenialpup64_7.5/
unsquashfs ../../old/puppy_xenialpup64_7.5.sfs 

cd ..

cd zdrv_xenialpup64_7.5/
unsquashfs ../../old/zdrv_xenialpup64_7.5.sfs 
cd ..

Acciones incrementales

Primera iteración

Modifiqué syslinux.conf para que ofrezca una sola opción de boot. Los squashfs se rehacen sin modificarlos, en este momento sólo nos interesa que funcione el proceso.

Antes...

...despues

Segunda iteración

Recomprimí los squashfs agregando un archivito testigo con touch.

Charly was there...

Tercera iteración

Poniendo en isolinux.cfg:

prompt 0
NOESCAPE 1

desactiva el acceso al boot prompt, lo que permitiría arrancar en single mode y nos jodería todas la demás medidas que tomemos.

De todos modos puppy arranca con el usuario root, haría falta un poco de hardening, quizas sea más fácil usar otra distro.

Pendiente

Lo que dejo sin hacer es:

• Desactivar automount
• Hallar y desactivar el automount, obvio.
• Poner el driver de los discos en /etc/modprobe.d/blacklist.conf, mmmh, puede llevarse algo que haga falta.
• un script al incio desmontando todo, mmh, sucio, sucio, ProfMatías.
• Poner los permisos correctos
• La verdad es que ni me fijé, quizás haciendo todo como root.
• Sigo sin fijarme, hice todo como root.
• Ver por que mi  puppy_xenialpup64_7.5.sfs queda tanto más grande que la original.
• Me imagino que debe ser alguna opción de compresión.

Quizás lo haga uno de estos días.

Reconstruir imagen

 

Borrar y reconstruir los squashfs, pero sólo los que hayan sido modificados.



rm new/puppy_xenialpup64_7.5.sfs

mksquashfs \
    rebuild/puppy_xenialpup64_7.5/squashfs-root \
    new/puppy_xenialpup64_7.5.sfs

rm new/zdrv_xenialpup64_7.5.sfs

mksquashfs \
    rebuild/zdrv_xenialpup64_7.5/squashfs-root \
    new/zdrv_xenialpup64_7.5.sfs


cd new

sudo mkisofs -o ../xenialpup64-7.5-uefi-new.iso \
        -r -J -no-emul-boot -boot-load-size 4 \
        -b isolinux.bin -c boot.catalog \
        -boot-info-table .

sudo umount mnt

Y listo, arrancar con la vm y repetir todo hasta que salga lo que queremos.

 

Python Productivity for Zynq tutorial@SPL2019

SPL2019 es una conferencia de lógica programable, de la cual me enteré en la lista de embebidos.

Me hubiese gustado asistir pero tiene poco y nada que ver con mi trabajo, así que no tengo punto de negociación para ausentarme tantos días.

Además tengo una alta ignoracia en el tema y aunque seguro que iba a aprender mucho si asistía, al no ponerlo rápidamente en práctica pronto se me iba a disipar.

Pero, habían varios workshops, uno de los cuales aposté estuviera al alcance de mis limitadas facultades.

• WS1 (Xilinx, English):
  FPGA-based Accelerated Cloud Computing with AWS EC2 F1 and SDAccel 
• WS2 (Xilinx, English):
  PYNQ: Python Productivity for Zynq
• WS3 (UAM, Spanish):
  FPGA SoC design from a higher level of abstraction: SDSoC and HLS 
• WS4 (Satellogic, Spanish):
  Testbenchs in Python: COCOTB

Lo dictó un señor, Parimal Patel que la tiene muy clara y explica muy bien, además de participar del proyecto activamente.

La placa utilizada para las prácticas fue la PYNQ-Z2 que obviamente, es rosa.


Se parece a la Parallella de la que tanto vengo hablando en que tiene un Zynq 70x0, pero un poquito más power, un 7020 en lugar de un 7010. Además no tiene el chip característico de la Parallella, que son los 16 cores del chip Epiphany. Extra tiene... mejor pongo una tabla comparativa:

 

	PYNQ-Z2	Parallella
Características
Zynq	7020	7010
RAM [MB]	512	1024
Flash [MB]	16	(*)
SDCard	si	si
Ethernet 1Gb	si	si
USB 2.0 host	si	si
Audio	si	hdmi?
HDMI out	si	si
HDMI in	si	no
Epiphany	no	si
Power [v]	7-12	5 (**)
Raspberry Pi	si
Arduino shield	si
Porcupine (***)		si
PMOD	2	1 (***)
JTAG	?	si (***)
Raspberry Pi Camera		si
Switches, botones y leds	2+4+4
Status proyecto	Vivo	Muerto

(*) No me queda claro por la documentación, tiene entre 32 y 128 Mb dice, pero no sé si se adhieren a que Mb es Mbit.
(**) La Parallella es excepcionalmente fastidiosa con la alimentación.
(***) Lo que tiene la Parallella es el Porcupine, que provee además de un PMOD, un JTAG y la interfaz para la cámara de la Raspberry Pi, "240 backside pins and a peak bandwidth of 50 Gbps". Entiendo que las interfaces de la PYNQ son todas lentas, o sea si quisiera sacar video en tiempo real o sería por ethernet o USB.



Volviendo a la PYNQ-Z2, como se puede ver, tiene los conectores de Arduino y Raspberry, lo que sumando a los PMOD+Grove o Arduino+Grove, permite adosarle una cantidad infernal de accesorios con gran sencillez.

Tambien es la más barata (u$s120) de las otras placas soportadas oficialmente por PYNQ. Nos chismorreó Patel que en unos tres meses (agosto 2019) sale una ZCU no tan cara como la ZCU104 u$s800 (y ni te digo la ZCU111 u$s8000), pero no sé si más que esta.

¿Y cómo funciona esto?

Yo entiendo que entendí, pero por la dudas no voy a entrar en mucho detalles por si me he confundido no esparcir errores. Intentaré ser breve y preciso y para la información posta RTFM. Si alguien que sabe encuentra algún error, me avisa por favor.

Tenemos los overlays, que proveen en la PL una serie de componentes comunes. Por ejemplo el overlay "base.bit" tiene los conectores para PMOD, Arduino Shield, Raspberry Pi y video HDMI.

Lo que tienen en común es que usan IOP (Input Output Processors), en este caso son MicroBlazes para parametrizar en tiempo de pre-ejecución que hay en los pines en lugar de que estén hardcodeado en el bitstream. Luego, durante la ejecución lo implementan.

Los IOPs son "soft processors", se implementan en la PL si hacen falta, en contraste con los cores ARM que están al costadito y que siempre están.

Dicho de otra manera, entre los buses SPI, UART o GPIO y el componente externo en sí, en lugar de ya estar configurado, tiene una capa que se adapta programáticamente. Entiendo que esto sólo debe funcionar con interfaces de baja velocidad, pues el IOP no deja de ser una CPU y siempre va a ser más lenta que un circuito combinacional y unos pocos flip-flops.

El modo de trabajar es en cierto modo como usar un Arduino con Firmata, usado por Processing o algo parecido, Scratch. El micro Arduino en un caso, el MicroBlaze en este, no hace procesamiento, sólo el pasaje de señales de los pines físicos al procesador "real", en el caso de Firmata la PC donde tenés Processing, en este los cores de la Zynq 7020.

Concretamente, si leo un termómetro en PMODA y quiero mostrar en un OLED en PMODB, el valor pasa por el core ARM, mientras que con VHDL se podría pasar directamente, pero perdiendo la flexibilidad y implicando mayor conocimiento por parte de quien implemente.

Está claro que esto está orientado a la gente que sabe programar y tiene una idea no muy profunda de hardware, que el lo que dice el proyecto, ningún engaño.

Un ejercicio que hicimos con Facundo, que fué el que dictó en SASE 2017 el workshop de EDU-CIAA-NXP multicore y me tocó de compañerito es este:


from pynq.overlays.base import BaseOverlay
from pynq.lib.pmod import Pmod_OLED
from pynq.lib.pmod import Grove
from pynq.lib.pmod import PMOD_GROVE_G4

from time import sleep

base = BaseOverlay(“base.bit”)

oled = Pmod_OLED(base.PMODA)
oled.clear()

temp = Grove_TMP(base.PMODB, PMOD_GROVE_G4)

while 1:
    temperature = temp.read()
    oled.write(temperature)
    sleep(1)

Ojo, puede ser que en el dibujito estén invertidos PMODA y PMODB y sin duda en oled.write() había algo más, probablemente un format() cerquita de temperature.

Por otro lado, en contraposición y recuperando la independiencia del FPGA, está otro overlay, "logictools.bit" que implementa varios "generadores". El procesamiento está en la FPGA, pero el core ARM le dice que va a hacer mediante una magia que no me atrevo a describir y que entiendo modifica las LUTs sueltas, no reenviando el bitstream completo. En cierto modo es como si vía Firmata se le enviara un programa a un módulo wifi ESP8266 para que lo ejecute independientemente.

No lo practicamos, así que cuento así nomas los generadores:

Boolean generator

es para armar circuitos combinacionales. Se le provee una o más funciones lógicas tipo

LD2 = PB3 ^ PB0

y mágicamente LD2 será una salida función de las entradas PB0 y PB3

Pattern generator

es para armar patrones, se le provee con un json parecido a esto:

up_counter = {
  ‘signal’ : [
    [‘stimulus’,
        {‘name’: ‘bit0’, ‘pin’:’D0’, ‘wave’: ‘lh’ * 8 },
        {‘name’: ‘bit1’, ‘pin’:’D1’, ‘wave’: ‘l.h.’ * 4 },
        {‘name’: ‘bit2’, ‘pin’:’D2’, ‘wave’: ‘l...h...’ * 2},
        etc
    ]
  ]
}

FSM generator

Se determinan unas entradas, unas salidas y la tabla de transiciones y... ocurre.

Trace analyzer

Se utiliza para capturar las entradas y salidas. En los ejemplos vistos se usa para ver lo que hacen los generadores.


En el caso de PYNQ hay una capa extra, que es Jupyter que permite que la interfaz sea web, usando un concepto llamado "notebooks", cuando sepa más, si lo llega a ocurrir, contaré.

Seguro que se debe poder usar desde una terminal pero no lo puedo afirmar hasta que le eche mano otra vez a una placa y haga las pruebas pertinentes o lo lea accidentalmente en la sección "Running from the command line".



La idea es que uno hace o consigue un overlay, implementa o consigue los c-drivers, implementa o consigue los wrappers, arma un cuaderno y tiene así un proyecto.

Si uno no agrega nada nuevo, usando uno de los overlays base.bit o logictools.bit puede hacer un montón de cosas sin bajarse de IPython.

 

¿Por qué me interesa?

Esta placa me interesa particularmente por el HDMI in, pues se puede tomar la salida de la computadora, pasarla por la placa, hacerle algún proceso y volcarla en la pantalla, para aprender a hacer cosas como:

• Prender leds de colores detrás del monitor dependiendo de la imagen que haya, se lo llama ....
• Agregar cosas a la imagen, como pueden ser letras.
• Botón de pausa, pero perdiendo los frames mientras dure ésta.
• Sacar fotos a la imagen.
• Grabar el video.

Tambien, a mi backlog de proyectos inalcanzables le agrego el port de PYNQ a la Parallella, que sorprendentemente se llamará... ¡ParaPYNQ! y sin ninguna sorpresa me llevará mucho tiempo iniciar, si es que lo hago. Patel está al tanto de mi propósito y me ha ofrecido apoyo, así que... tengo que hacerlo.

Dos sitios con mucha info y código:

http://www.pynq.io/

https://github.com/xilinx/pynq

Jugando con los rayos 3: sacándole el alma al cadáver

Habíamos quedado en que no podía leer confiablemente el firmware con la pinza soic8, que tras soldar implementando SPI con GPIO algo se leía, que son la interfaz SPI no sólo nada se leía sino que entiendo no era posible operar, que en el proceso de estar independizando la alimentación a la flash y emprolijando, el router terminó de morir sin poder diagnosticar los motivos. A todo eso se llega por el índice.

Trasca, al extraer el chip se cortó el pin de Vcc. Entiendo que sólo con herramientas muy muy especializadas podría revertir este daño, pero aún así lo intentaré.

Corrección del pin

La idea es comer el encapsulado con un torno de mano hasta exponer lo suficiente del pin para soldar algo. Esto es ignorando si luego si puede soldar con el estaño/plomo que tengo y la temperatura.

He visto una experiencia pero no es lo que he conseguido, esa exposición de pistas internas, sospecho que no las hay por ser un chip tan chico

Resultado

Debí haber usado en lugar de la fresa más chica que tenía, la mecha más chica, durante un instante estuvo expuesto algo que podía ser el pin, casi casi lo suficiente, pero quise aumentar levemente la superficie y puff, casi desapareció, no le pude soldar nada.

Por este lado no voy a poder responder la pregunta motivadora de todo esto:



¿Por qué no tengo el password del firmware oficial si yo no cambié el firmware?