2021/12/27

Diplomatura de Desarrollo Seguro de Aplicaciones de la UNSTA 2021

En estos tres o cuatro meses he tenido el placer de ser alumno y docente de la Diplomatura de Desarrollo Seguro de Aplicaciones de la UNSTA.

 

La convocatoria

 

La organización me contactó para ver si podía dar una "charla magistral" de una hora y media de algún tema interesante y llamativo. Pensé un rato y ofrecí, en consonancia con lo que vengo haciendo últimamente, algo de seguridad de hardware. En la conversación fue creciendo y finalmente se convirtió en una materia de 9 horas.

 

Evidencia en LinkedIn
Evidencia en LinkedIn

 

Todo un desafío, nunca había dictado algo así antes. Había conversado con la organización de los cursos del Laboratorio de Sistemas Embebidos de la Facultad de Ingeniería de la Universidad de Buenos Aires (CESE, CEIoT), donde soy docente de Ciberseguridad en IoT y, no sé si seguirá existiendo, Testing de Sistemas IoT, la posibilidad de organizar una materia optativa de esta misma naturaleza, pero medio que más que ofrecerlo lo estaba pidiendo. O mejor dicho, algún tipo de "colaboración", con algunas otras personas para armarlo y que mi rol sea más "seguridad pura" que de los aspectos más técnicos del hardware. Pero debido a que es un esfuerzo infernal, son cursos orientados a alumnos de posgrado, los docentes suelen estar extremadamente ocupados y en promedio son más responsables que yo, no se sentían capacitados y no prosperó.

En las diplomaturas la ventaja es que las condiciones de aceptación de alumnos es un tanto más relajada y la exigencia general también. Un indicador sencillo es que una diplomatura como ésta o como otra que he hecho de Seguridad Bancaria, tiene una carga de 100 horas, dos a cuatro clases por materia. 

Los otros cursos tienen 15 materias de 8 clases cada una, son 24 horas cada materia, 360 horas en total. Incluso la carga semanal es un 50% mayor, dos contra tres días por semana. Cada materia suele tener unos ejercicios heavies y se espera que el trabajo práctico consuma unas 600 horas/persona, aunque no necesariamente sean todas tuyas, vale dirigir el trabajo de otras personas.

Respecto a la carga horaria del TP de esta diplomatura, calculo que si estuviste haciendo los ejercicios durante la cursada debe ser leve, pero si lo hubiera hecho completo yo solo me hubiera llevado hasta 40 horas.

Volviendo a mi participación como docente, me encontré con el siguiente FODA, un poco retrospectivo pues en ese momento aunque intuitivamente lo apliqué no lo llegué a concientizar:

Fortalezas

Experiencia en dar clases, experiencia en investigar seguridad de hardware aunque quizás de un modo un tanto esotérico, experiencia en ciberseguridad. Equipamiento de hardware apropiado.

Oportunidades

Poner a prueba el conocimiento que vengo juntando desde hace décadas. Identificar baches.

Debilidades

Conocimiento fragmentario e incompleto, desconocimiento de normas y electrónica en general. Falta de orden.

Amenazas

No llegar en tiempo y/o forma y pasar vergüenza ante los alumnos y/o la organización.

 

Preparativos

 

En las H4CK3D y en muchas charlas internas del trabajo ya había expuesto del tema de modo fragmentario y continué haciéndolo hasta antes e incluso después de las clases.

Tomé en simultáneo la materia Micro Arquitecturas y Soft Cores del CESE, que aunque no tenía relación directa, forma parte del conocimiento de base.

 

Resultados 


Tuve muy poco feedback, sin sorpresas ("te falta un poco de orden"), no tuve la sensación de haber fallado en las dos primeras clases, quizás la tercera estuvo floja pero más por mis expectativas, no sé si se notó "para afuera". Me había propuesto mostrar una demo de Secure Boot con ESP32-S pero en parte por que no llegué a hacer las pruebas y en parte por que no le encontré que fuera realmente interesante, sólo lo expliqué en términos teóricos.

De algún modo no logré un "relato", el poder recorrer los temas de un modo hilvanado. En las charlas que doy pego saltos, que te obligan a prestar demasiada atención, imposible a lo largo de tres clases, te olvidaste. Las charlas son para gente que eligió ir específicamente (igual alguien se ha quejado), en las clases, aunque no falte a quien le interese mucho, hay que considerar que para la mayoría es una de diez materias y no precisamente la más útil o interesante.

Otra dificultad es que de todas las otras materias he recibido capacitación, tiene un poco del ¿Para qué hacés un curso de algo que ya mayormente sabés? que ya he mencionad en otro lado y para esta materia no, todo muy fragmentario y autodidacta.



Como alumno


En mi condición de docente tuve grandes facilidades económicas para ser alumno, con lo cual no fue una elección muy difícil, en todo caso si la experiencia era mala, salía con un título de utilidad moderada. La verdad es que no conocía a nadie, ni sus cualidades o defectos, es la primera edición, aposté y salió bien.

Siempre hay alguna clase que por el tema o el modo de quien la dicta es un poco más aburrida y otra más entretenida, pero no ocurrió ninguna vez que me arrepintiera. No hubieron clases malas y sí hubieron clases muy, muy buenas, lamentablemente no tomé nota, siempre confiando en que luego se puede acceder a las presentaciones y confiando de modo completamente injustificado en mi memoria.

Hubo una cierta falta de coordinación entre las materias, algunos temas se vieron repetidos, no es tan terrible, es bueno el repaso. Pero algunos temas como que se escaparon, igual nada grave.

Si se repite, si los tiempos me dan, si me dejan, probablemente asista como oyente, esta vez tomando notas.

Las clases quedan grabadas, pero la verdad es que no me gusta ver grabaciones.

 

El trabajo práctico

 

Para quienes no estamos programando todo el día y más web, fué bastante heavy. Además llegó un poco tarde y en mi caso coincidió con que como docente tenía que terminar de preparar las clases, como alumno de otra materia en otro lado tenía que terminar su trabajo práctico, un fondo de ojo que me dejó muerto justo el día de la entrega, log4shell me dejó agotado cada día de esa semana y la anterior, el día del asado del trabajo y que dí una charla de Chain of Trust y Secure Boot en el trabajo aprovechando parte del material que había usado para las clases.

Tampoco ayudó, en mi caso, un poco de actitud liebre y tortuga, liebre en mi caso. Ya que cuento con experiencia tanto en desarrollo como en seguridad, medio que aflojé un poco. Pude haber canibalizado un trabajo práctico a medio hacer del CEIoT pero me dá un poco de vergüenza y además necesitaba hacer un reajuste mental de varios días, hace meses que no toco programación web y node.

Estaba compuesto de varias partes, una relacionada a bases de datos y enmascaramiento, otra de obtener información de una virtual vulnerable, la tercera corregir una aplicación y la cuarta,  más grande que las otra dos juntas, era hacer una API, agregarle autenticación y con tests de Postman mostrar su seguridad, todas cosas que sé hacer pero en este momento no estoy "sintonizado", mi cerebro está en FPGA.


Conclusión

 

Para decirlo del modo más corto posible, espero con ansia que se repita para que asistan las personas a las que invité en esta ocasión pero por haber sido con tan poco tiempo de aviso no pudieron asistir. Y por el lado docente, para tener la oportunidad de mejorar las clases. En términos de inversión, paga, quizás no como título pues es una Licenciatura, sujeto a interpretación, pero el resto está ok.

La profundidad y extensión de los temas fue correcta así como la calidad. Me hubiera gustado tener más feedback de mi materia.



2021/12/26

H4CK3D 2021: the missing pieces

En esta entrada dejo algunas ideas y detalles apenas enunciados en la charla, quizás ya mencionados en las entradas anteriores.

 

Tambien registro mi pena por no haber podido asistir a todas las demás charlas que hubieron tanto ese día como los restantes, no me dá el, iba a decir físico, pero en este caso vendría a ser más el virtual.

 

Los componentes del ataque 


Para identificarlos e implementarlos estuve horas y horas probando, pensando, fallando, fallando y fallando. Algunas de la fallas fueron realmente estúpidas, por ejemplo intentar detectar la secuencia en el fetch o el execute. Pensá, si hay un pipeline, hay instrucciones futuras que no se van a terminar de ejecutar pues el branch las va a flushear, pero ni en el fetch ni el execute lo sabemos. Resultó el writeback el mejor lugar y quizás no empecé por ahí por que está vacío y me llevó un buen rato comprender su función.

 

¿Qué pasa con el rebote del botón?

 

Hay muy pocas probabilidades de rebote cuando es el programa el que lee el botón. A nivel del ataque, entonces no interesa, el bichito está mirando el comportamiento del programa, no de los botones. Pudo haber mirado directamente los botones y operado tambien sobre el servo, pero ya habíamos quedado en que eso lo haría mucho más detectable.

 Además queda atado a los botones, no al software que mira los botones. Ponele que hay más botones para operar con un menú, tipo las impresoras o los monitores que hacés mil cosas con cuatro botones. Mejor atarse al programa.

 

¿Qué pasa con el azar en el place and route?

 

Debido a los algoritmos utilizados, la etapa de PNR usa pseudoazar. Como todo pseudoazar (¿todo Charli? vos no sabés lo suficiente de criptografía para afirmar eso...) se puede controlar fijando la semilla, "seed". No me hizo falta ir por este lado, pero de algún modo del lado del software desactivé toda sorpresa al deshabilitar las optimizaciones.

 

Un camino no tomado

 

Había encontrado una manera medio rara pero muy compleja de conectar componentes sin pasar por la interfaz, no vale la pena pues es muy llamativo. Sin embargo sospecho que si tomamos el .bliff...


.gate SB_LUT4 I0=buttons[2] I1=icicle.rv32.execute.ebreak_out_SB_LUT4_I2_O_SB_LUT4_O_I2_SB_LUT4_O_I1_SB_LUT4_O_I3_SB_LUT4_I2_O_SB_LUT4_I3_O_SB_LUT4_I2_O[0] I2=icicle.rv32.execute.ebreak_out_SB_LUT4_I2_O_SB_LUT4_O_I2_SB_LUT4_O_I1_SB_LUT4_O_I3_SB_LUT4_I2_O_SB_LUT4_I3_O_SB_LUT4_I2_O[2] I3=icicle.leds[2] O=buttons_SB_LUT4_I0_O[0]
.attr module_not_derived 00000000000000000000000000000001
.attr src "/usr/local/bin/../share/yosys/ice40/cells_map.v:26.33-27.52"
.param LUT_INIT 0000011101110111
.gate SB_LUT4 I0=buttons[1] I1=icicle.rv32.execute.ebreak_out_SB_LUT4_I2_O_SB_LUT4_O_I2_SB_LUT4_O_I1_SB_LUT4_O_I3_SB_LUT4_I2_O_SB_LUT4_I3_O_SB_LUT4_I2_O[0] I2=icicle.rv32.execute.ebreak_out_SB_LUT4_I2_O_SB_LUT4_O_I2_SB_LUT4_O_I1_SB_LUT4_O_I3_SB_LUT4_I2_O_SB_LUT4_I3_O_SB_LUT4_I2_O[2] I3=icicle.leds[1] O=buttons_SB_LUT4_I0_1_O[3]



...sería posible agregar componentes y conexiones que no estén en el fuente Verilog, sería una mejora de un orden de magnitud al ataque y candidato a una charla para el año que viene, implica adquirir un tipo de conocimiento muy de nicho, todo lo que aprendí hasta acá es reutilizable y compartible, eso no lo sería.

 

¿Por qué querríamos no pasar por la interfaz? 

 

Para que una inspección superficial no ponga en evidencia la irregularidad. Si mirás el código fuente verás que los nombres son bien explícitos, clara ayuda para mí pero no para lo furtivo. Apuesto a que si se ponen nombre tipo cache_sync nadie se da cuenta.