2023/03/08

Cyberciruja 2023

Acompañando y de algún modo continuando unos artículos previos de una mezcla de forense con cyberciruja, elaboro estas reflexiones actualizadas.

La actividad cyberciruja es aparentemente sencilla, consiste en estar atento a hallar en la basura equipamiento recuperable. Esta basura puede ser la mera calle, alguien que avisa "en mi trabajo/familia" van a tirar tal cosa.

Yo he sido siempre parcialmente cyberciruja y recientemente me uní a un grupo cuya interacción me ha llevado a conclusiones parecidas y extendidas a lo que había llegado en Wipe relativo a regalar cosas.

No es fácil y puede ser antieconómico regalar cosas.

Tras unos meses en el grupo hallé un cierto comportamiento recurrente. Se han ofrecido cosas que si alguien hubiese encontrado en la calle hubiese dicho "guau! qué bueno! no entiendo por qué tiran esto, ...." y probablemente levantado, sin generar ningún interés.

Luego, tengo un TV no smart de 40 pulgadas víctima de un rayo, es muy probable que la pantalla esté intacta. Si lo dejo en la vereda y aviso, según mensajes previos de piezas equivalentes, "uh, qué pena que no estoy por ahí", debería ser muy codiciado, pero lo ofrecí y nadie lo quiso.

Hay varias otras cosas registradas en Material Cyberciruja con el estado actualizado.

¿Será que la esencia de la experiencia cyberciruja no es el objeto en sí sino el encontrarlo en la basura? ¿Será que encontrarlo en la basura lo anonimiza sin generar relación u obligación con quién lo ha tirado? ¿Será que al recibirlo se genera algún tipo de deuda y al encontrarlo tras haber sido irresponsablemente abandonado la deuda es de quien lo tiró y de algún modo al recuperarlo se logra una satisfacción de índole social/ecológica?

¿Qué pesa más, estos aspectos o lo económico?

Analizando mi propia experiencia, he hallado tirado en el centro algo raqueable de comunicaciones que no sé que es y me lo he traido a casa pese a que alguien se le paró encima y lo deformó y usa una fuente de 48v y la verdad no me sirve para nada más que haberlo abierto y estudiado 15 minutos, quizás le pueda sacar unos chips fpga algún dia... Pero si me lo hubieran ofrecido, habría pensado: "¿voy a tener tiempo para dedicarle?", muy difícilmente lo hubiera aceptado.

 

 

Actualización 2024/01/29: ver https://seguridad-agile.blogspot.com/2024/01/analisis-de-entrega-de-material.html

 

Aspectos de seguridad

 

Eh amigo, entiendo que este blog es más bien técnico y por el nombre probablemente algo de seguridad y aunque lo del cybercirujéo es técnico, hasta ahora todo lo que escribiste no es ni muy técnico ni muy de seguridad!

Ok, veamos los aspectos de seguridad...

 

Aspecto forense y la confidencialidad. 

 

En el grupo alguien necesitaba discos IDE chicos, yo tenía al menos cuatro, pero no sabía que tenían adentro, ni siquiera si eran míos los datos. No se puede dar equipamiento con memoria persistente sin antes sanitizarla.

Es por ello que en el trabajo no consigo que me cedan nada obsoleto de comunicaciones, estos equipos son destruidos por empresas certificadas por normativa.

Volviendo a los discos, al no tener mother con IDE tuve que usar un adaptador USB-IDE, pero no funcionó con ningúno. Probé con otro que tiene el conector combinado IDE/Power y sólo era compatible con dos. Les hice 


sudo dd if=/dev/zero of=/dev/hdc

 

¿Porqué /dev/zero y no "borrado forense multipass" o /dev/urandom? Pues para los ataques posibles para los mortales comunes con una pasada alcanza, hace falta equipamiento muy caro, casi diría que es medio mito el recuperar algo.

Los otros dos no los puedo dar hasta poder escribirles...

 

Ingeniería Social

 

¿Será que el objeto "regalado" vale menos que el "ganado"?

Alguien dijo algo tipo "el regalo de algún modo te tiene que costar", de acuerdo. ¿qué sería entonces cuando en lugar de tirar algo a la basura, lo ofrecés'. Evidentemente no prima "me cuesta", sino el alivio de no tirarlo, en realidad sería "me hacés el favor de aceptarme esto pues me conflictúa tirarlo?".

De hecho, las empresas hacen donaciones diversas pero movidas por el retorno, que puede ser reducción de impuestos o publicidad.

Tambien está la protección ante la ingeniería social, uno sospecha un engaño. Un pariente de un amigo que era docente de la Facultad de Psicología de la UBA hizo un experimento con sus alumnos. Se pusieron en la puerta y ofrecieron billetes de 10 pesos a cambio de 7 pesos y nadie aceptó.

Yo no tengo para nada estos mecanismos, ofrecieron un equipo que tiene una FPGA adentro (otro día otra entrada), un thinclient (otro día otra entrada) y un lector de tarjetas (otro día otra entrada) y los acepté sin dudar.

 

Hardware Security Live Cycle

 

Esto no tiene que ver con la idea principal de la nota, pero recordá que habías reclamado por el aspecto de seguridad del hardware. Dicen los que saben que la cadena de suministro del hardware es:

  • IP Owner/fábrica
  • Ensamblado del PCB
  • Integración del sistema
  • Usuario final
  • Reciclador/basura

Y que las principales amenazas de seguridad al hardware son:

  • Remarcación, cambiarle la especificación de hogareño a industrial.
  • Clonado, una empresa copia el producto de otra.
  • Con defectos, una pieza no pasa el control de calidad y se vende igual.
  • Sobreproducción, la fábrica hace más componentes que los acordados y los vende por su lado.
  • Reciclado, que consiste en usar como nuevos componentes resultantes del fin del ciclo de vida anterior.

El cyberciruja de algún modo participa de ambas últimas, no de mala fé, no intenta usar o vender componentes recuperados como si fueran nuevos, pero en términos de safety (la seguridad no de la información, "security", sino la del mundo físico) el usar componentes rescatados, ya sea por el uso previo o por la técnica de recuperación, atenta contra las probabilidades de que el sistema no falle.

 

Ideas finales

 

¿Puede ser que lo que descarta un cyberciruja, al menos instintivamente, sea visto por los demás cybercirujas como algo que ya no puede ser recuperado?

Actualizando mi estado cyberciruja actual, pienso que:

Me parece que es ineficiente dedicarle tantas horas de esfuerzo a recuperar un equipo, esas horas de trabajo generarían más valor en un trabajo renumerado.


En términos de conciencia social, seguramente sería más productivo ir a ayudar en una villa a implementar o corregir en los tendidos cloacales o de suministro de agua o electricidad. O ayudar a personas en condición de calle.


 

2023/03/06

VirtualBox con Secure Boot

Hago esta nota más para no tener que buscar y recordar. Tomé todo de [1] y [2] y le pongo un poco de mi sabor, pues tengo mezcla con otro tema. De paso queda en spanish.


Tengo una máquina en modo dual boot con Windows 10 y bitlocker por un lado y Ubuntu 22 por el otro. En Windows 10, aparentemente por bitlocker, las virtuales con VirtualBox cada tanto le hacen tirar un BSOD. Mitiga un poco bajar en Execution Cap (de la virtual a usar, Settings -> System -> Processor -> Execution Cap) hasta el piso de lo verde, evitar hacer operaciones intensivas de disco y darle mucha memoria para que evite swappear, pero no alcanza, no puedo tener un BSOD en medio de una charla o taller.

Cuando instalé VirtualBox en Ubuntu, me encontré con un diálogo que nunca había visto, debido a que tiene activado Secure Boot.

No tomé nota bien de qué ofrecía o pedía, algo de una clave para UEFI o similar. Le dije que no, probablemente cancelé cerrando la terminal pues no me dejaba de otra manera. Luego, aun desinstalando y volviendo a instalar no volvió a ofrecerlo, así que no pude documentar.

 

Como efecto colateral me hizo reingresar la key de bitlocker al reiniciar, eso es, tras arruinarme el grub, de ahí en más, arranca directo con Windows.

Esto no es gran problema, cuando quiero arrancar con linux invoco el menú de boot del firmware que reconoce la partición UEFI Ubuntu, con eso se carga el grub y de ahí Ubuntu o si quisiera Windows.


Yendo a lo importante, al intentar ejecutar VirtualBox falla con un mensaje parecido a

 

modprobe vboxdrv failed. Please use 'dmesg' to find out why.
 

dmesg dice:

 

kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7

 

Buscando en internet llegué, tras varios artículos y respuestas diciendo "desactivá Secure Boot", que estupidéz, a uno que aunque bastante viejito es correcto.

Lo que dice es que si tenés Secure Boot, el kernel no te va a dejar insertar módulos que no estén firmados y brinda una manera de firmarlos. No voy a intentar explicar el detalle por que tengo una intuición pero no claridad.

Mi intuición es, para que un módulo esté firmado, hay que hacerlo con un secreto. Ese secreto hay que cargarlo en alguna zona protegida.

 

Esto genera el secreto:

 

$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VBox Cert/"

 

Esto firma el módulo con el secreto:

 

$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vboxdrv)

 

En mi caso la expansión es:

 

$ sudo /usr/src/linux-headers-5.15.0-48-generic/scripts/sign-file sha256 ./MOK.priv ./MOK.der /lib/modules/5.15.0-48-generic/updates/dkms/vboxdrv.ko

 

Lo mismo para hay que hacer para vboxnetflt.

Esto inicia el proceso de guardar el secreto en la zona protegida, es registrar la key con Secure Boot, te pide un secreto que establece la cadena de confianza rumbo al siguiente paso:

 

$ sudo mokutil --import MOK.der

 

Reiniciás:

 

$ shutdown -r now

 

Todo lo que sigue es la finalización del proceso de guardar el secreto.

Te aparecen unas pantallas ascii azul con un menú sencillo, en este elegís qué vas a hacer

 

Perform MOK management

+-----------------------+
|     Continue Boot     |
|      Enroll MOK       |
| Enroll key from disk  |
| Enroll hash from disk |
+-----------------------+

 

Te permite ver el secreto a registrar o continuar, continuar


[Enroll MOK]

+------------+
| View key 0 |
|  Continue  |
+------------+

 

¿Está usted seguro?

 

Enroll the key(s)?

+---+
|No |
|Yes|
+---+

 

Te pide el password que ingresaste previamente:


Enroll the key(s)?

+-------------------+
| Password:         |
+-------------------+

 

Listo

 

The system must now be rebooted

+--+
|OK|
+--+

 

Con esto se puede comprobar si está enrolado:

 

$ mokutil --test-key MOK.der
MOK.der is already enrolled
 

Con esto listás las keys:

 

$ mokutil --list-enrolled | grep -e "\[key" -e Issuer


[key 1]
        Issuer: C=GB, ST=Isle of Man, L=Douglas,
        O=Canonical Ltd.,
        CN=Canonical Ltd. Master Certificate Authority
[key 2]
        Issuer: CN=mint Secure Boot Module Signature key
[key 3]
        Issuer: CN=VBox Cert




Ese MOK.priv lo podés borrar del sistema tras resguardarlo, por ejemplo dentro del mismo keepass donde guardás las otras claves, en el campo de comentario. Al DER lo pasás antes a ascii con base64.




[1] https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur

[2] https://sourceware.org/systemtap/wiki/SecureBoot