2020/03/31

Evitando sudo con capabilities

Tanto cuando te estás instalando herramientas de pentest como cuando alguien te pide en algún servidor que se las instales, surge el problema de los permisos, que antes se arreglaba dándole root a todo el mundo y luego mejoró, dándole sudo de un modo un poco menos indiscriminado.

Dejando de lado que tengo poca o nula experiencia configurando sudo, una de mis tantas tareas del backlog, hay muchas herramientas que no necesitan root para todas sus funciones si no para algunas muy específicas.

En el caso de pentest suele tener que ver con acceso a la red, ya sea para enviar paquetes arbitrarios salteándose las restricciones que imponen las interfaces o accediendo a la interfaz de red directamente para ver el tráfico.

Las herramientas más comunes para estos escenarios son nmap y tcpdump correspondientemente.

Existe un riesgo adicional el ejecutar estas aplicaciones con permisos adminstrativos y es que siendo aplicaciones complejas no carecen de bugs y se pueden convertir en puntos de entrada para tomar el control de tu máquina, si sos un usuario común el ataque queda más contenido que si sos root, donde el éxito lleva al control total, a menos que tengas SELinux, que es mucho más complicado y me pesa tambien no saber, cuando sea grande aprenderé SELinux.

Lo que sí sé de SELinux es que parece que es más apropiado para ambientes poco cambiantes tipo servidores, no para estaciones de trabajo.

La idea entonces es otorgar permisos granulares o capacidades a un programa tal que pueda hacer cosas reservadas a root sin ser root y ajustar los permisos de modo tal que sólo los usuarios pertenencientes a un grupo puedan ejecutarlo, manos a la obra.



Crear un grupo

$ addgroup networkaudit


Identificar los programas:

$ which nmap
/usr/bin/nmap

$ which tcpdump
/usr/sbin/tcpdump


Cambiarles el grupo:

$ chgrp networkaudit /usr/bin/nmap
$ chgrp networkaudit /usr/sbin/tcpdump


Medida extra, cambiarle los permisos:

$ chmod 750 /usr/bin/nmap
$ chmod 750 /usr/sbin/tcpdump


Setear las capabilities:


$ setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
$ setcap cap_net_raw,cap_net_admin,cap_net_bind_service+eip  \
    /usr/bin/nmap

nmap en particular necesita que lo ejecutes luego con --privileged pues como está preparado para tomar caminos alternativos si no sos root, te dice que no tenés permisos sin intentar hacerlo.

También podés poner en .profile

export NMAP_PRIVILEGED=""



wireshark te ofrece acomodar todo el instalar, pero puede ser que te olvides:






Asi que cuando ejecutes y quieras capturar te va a decir que no y cómo solucionarlo.




$ sudo dpkg-reconfigure wireshark-common

Luego, para cada usuario:

$ sudo usermod -a -G wireshark $user


Tras ejecutar las instrucciones, veamos a quien tocó:


$ getcap $( which wireshark )

nada... ok, es razonable, wireshark es un animal bastante grande, quizas hay un componente, si le preguntamos a synaptic...





...podés copiar y pegar:

$ cat << EOF | while read file; do getcap "$file"; done
> /usr/bin/capinfos
> /usr/bin/captype
> /usr/bin/dumpcap
> /usr/bin/editcap
> /usr/bin/mergecap
> /usr/bin/mmdbresolve
> /usr/bin/randpkt
> /usr/bin/rawshark
> /usr/bin/reordercap
> /usr/bin/text2pcap
> EOF


O menos chancho, le preguntas a dpkg


$ dpkg -L wireshark-common | grep bin | while read file; do \
   getcap "$file"; done


En ambos caso te trae

/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

Con lo cual te podés arreglar con:

$ setcap cap_net_admin,cap_net_raw+eip /usr/bin/dumpcap




Esto ha sido para networking, pero puede ser útil para otros contextos.

Me he servido de man capabilities y al menos:

https://peternixon.net/news/2012/01/28/configure-tcpdump-work-non-root-user-opensuse-using-file-system-capabilities/


https://diego.assencio.com/?index=e48aa7b74bd7acb76c30de0a240108c2

2020/03/29

Protector facial con muy bajos recursos y en situación de aislación





Esta experiencia que voy a compartir carece de respaldo científico, sólo estoy haciendo lo que muchas otras personas están haciendo. Para evaluar la efectividad de usar un dispositivo como este, buscá en los sitios de medicina oficial.

Por algunos comentarios que me han hecho personas que han leido esto, aclaro que además está pensado para uso personal, no para personal médico, la visera te tapa la luz y la tela junta mugre. Para uso médico evidentemente esta propuesta es mejor. Comparten la ventaja del espacio libre frente a la cara.


Dicho eso, lo que comparto es cómo hacer protectores faciales con acetatos y gorras, prácticamente ninguna herramienta, sin un espacio adecuado ni tantas otras cosas que los hobbystas damos por sentado (¿quién no tiene un taladro y una remachadora, por el amor de dios?), ni siquiera mucha destreza, casi nada diría.

Llamo "acetato" al plástico transparente que todo el mundo llama acetato y que obtengo de radiografías viejas o tapas de carpetas.

Tras mucho reflexionar y hacer ensayos, algunos mentales y otros reales que involucraron cortes medidos de acetato, remaches, adhesivos y broches, en casa llegamos a una solución extremadamente sencilla que consiste en enganchar el acetato a la visera de la gorra con algo que puede ser un alambrecito.

La idea es que si tenés una gorra, un clavo, moneda, fuego y un acetato te puedas hacerte tu protector o máscara facial.

Me imagino que a otras personas se les ha ocurrido algo similar o incluso lo mismo, pero no me alcanza la vida para estar mirando todo lo que ocurre.


Con respecto a otras soluciones, las ventajas de ésta son:
  • Prácticamente no requiere uso de herramientas.
  • No requiere precisión.
  • Es sencillo reemplazar el acetato.
  • Es sencillo lavar la gorra.
  • Una vez que tenés el acetato, se arma en dos minutos
  • Queda espacio entre la cara y el acetato.

Las desventajas
  • No tiene cierre hermético por arriba, no sé si hace falta.
  • No es muy ajustable.
  • Podría rotar y caer sobre la cara en determinadas posiciones.

A evaluar
  • Parece resistente

Al final está el listado de materiales.



Proceso


Una vez obtenido el acetato, perforarlo en las esquinas con una perforadora o la cabeza de un clavo caliente. En caso de usar perforadora, podés ir haciendo pruebas apretando suave y fijándote donde va a quedar el agujero antes de hacerlo definitivo.

Hemos hecho dos tamaños distintos, brindando el más grande mayor protección lateral. Ambos tamaños se pueden usar con la misma gorra.


Perforar los puntos de anclaje en la gorra con la perforadora. Si no tenés perforadora o no entra la visera, usar un clavo y una moneda.




Link al video en youtube

Al armar los ganchos mariposa van para afuera para que no te agarren el pelo, aunque estéticamente no queden tan bien como al revés.

El recurso de la perforadora lo vengo usando desde las ganzuas descartables para la oficina

Detalles del acetato a partir de una radiografía.


El propósito de esta sección era contar como usando muy poca lavandina se podría limpiar aceptablemente, por si vas a hacer muchas limpiezas, tiene sentido que usés muy poca lavandina pues en este momento es un bien escaso.

Esto es considerando que no necesariamente contás con una bañadera o recipiente suficientemente amplio.

Una de las pruebas fue tipo una lasaña de radiografías y lavandina, pero al igual que otras pruebas, no resultaron. Aún así, compartiré lo que aprendí, igual de esto hay innumerables recursos en internet "cómo blanquear radiografía", "cómo limpiar radiografía"

Hay dos tipos de materiales de estudios médicos cuyos nombres ignoro, pero uno, el mas moderno, evidentemente tiene la imagen adentro del material, no en la superficie. La lavandina remueve sólo el material de la superficie, así que el material de las tomografías e incluso radiografías modernas no sirve.

Para determinar si sirve, poné en una zona bien oscura un micro poquitito de lavandina, esperá unos segundo y pasá la uña. Si sale algo negro, sirve.

Ponés la radiografías en agua con un chorro de lavandina, no sé cuánto es lo óptimo, cada tanto las vas moviendo para que no se peguen así circula le agua y tras varias horas de ambos lado va a salir con mayor o menor ayuda y si te cuidás de no rayarlas, mejor.

Leí por ahí que las placas de tomografías dejadas al agua mucho días se blanquean, dejé unas de prueba, con un poquito de lavandina por el denge. Aviso que pasa luego.


Precauciones con la lavandina


  • Hacé lo de la lavandina al aire libre o ventilá.
  • Fijate que donde pongas lavandina no haya habido ningún tipo de jabón, se produce un gas tóxico.

  • Si vas a hacer muchas pruebas y/o limpiezas, protegete las manos, la piel no se lleva bien con la lavandina.



Lo que vas a necesitar


Materiales:
  • Gorra con visera.
  • Acetato.
  • Alambre o gancho mariposa.

Herramientas:
  • Perforadora o 
  • Clavo, moneda y fuego.

En caso de obtener el acetato de una radiografía:
  • Contenedor.
  • Cepillo para ropa.
  • Lavandina.
  • Aire libre o ventilación.

Si querés compartir por pantalla esto:



Bienvenidas modificaciones y sugerencias.

Gracias a la participación y paciencia de https://lanilunatejidos.blogspot.com/

2020/03/21

Consideraciones de ciberseguridad y coronavirus

Con el asunto de las cuarentenas de coronavirus, comparto algunas reflexiones, algunas con conocimiento de causa, algunas de mi sentido común ciberseguro resultado de mi profesión. Pese a que me había prometido evitar las notas poco técnicas y teñidas de opinión como va a ser esta, me parece que la situación lo amerita.

Esto no es una guía o manual de trabajo y estudio remoto, sólo algunas ideas rápidas que pueden ser útiles. Al no ser muy técnica tambien está orientada más al usuario final que a quien deba armar soluciones.

Cuando digo conferencia me refiero de modo genérico a conferencia, charla, clase, reunión o lo que sea en que varios participantes intercambian streams de audio y video, provenientes de una cámara o de la pantalla.

Si en el correr de los días de la cuarentena ocurre algo interesante, actualizaré.

Primero lo más evidente:

Atención al phishing y las estafas



Han habido estafas que se han aprovechado incluso de las torres gemelas, esta es una oportunidad tan buena como cualquier otra.




Servidores de conferencias


¿Propio o ajeno? ¿cloud u on premise? Si te lo instalás en tu propio servidor (que puede ser cualquier máquina, sólo hace falta que tenga IP pública, no necesariamente fija), el problema que tenés es que ante un ataque dirigido probablemente seas presa fácil, pero ante esquemas de vigilancia generalizada estás mejor, sobre todo si el tráfico está cifrado. Un ataque a un servidor ajeno en cloud tiene la ventaja de que probablemente afecte a innumerables otras personas y empresas, con lo cual el impacto se distribuye, si no sos importante, vas a estar abajo en la lista de explotación.


El cifrado puede ser:

Inexistente: cualquiera con acceso al tráfico que conozca los protocolos y formatos utilizados puede escuchar.

Entre servidor y cliente: el servidor determina las keys utilizadas, es su elección inspeccionar o grabar las conversaciones.

End-to-end, esto es, entre cada cliente: el servidor no entiende las conversaciones.

Sin duda el cifrado aumenta la latencia y el procesamiento, no sé si lo hace de modo significativo.

Lo más probable es que no te importe mucho y termines en google algo o zoom.

Documentos compartidos


Quizás antes no tenías que hacerlo tanto, pero seguramente ahora sí, compartir documentos con terceros. Fijate que hay opciones de acceso, evitá como la peste "todo el mundo" y "cualquiera con acceso al link", a menos que sea tu propósito.

Tambien reducí el acceso de "total" a "lectura" o "comentarios" según corresponda y explorá la posibilidad que al menos google ofrece de no permitir copiar ni salvar, pero no cuentes con eso, siempre se pueden sacar fotos de pantalla desde la compu o afuera.

Tené en cuenta que al estar accediendo a un documento compartido otras personas que accedan simultáneamente te verán y quizás no querías divulgar esa información.

Redes sociales y chats


Imaginate que estás compartiendo tu pantalla con gente de tu organización y de otra y alguien de la otra organización es muy infla pies y alguien de la tuya te hace un comentario al respecto. Y aparece abajo a la derecha el mensajito "qué pesado que es Estaban!!". ¡Qué momento incómodo!


Mitigación: desactivar notificaciones.

Mitigación: virtualizar, el uso de una máquina virtual en una conferencia tiene el efecto colateral extra de evitar los popups con mensajes si tenés las cuentas separadas.

La responsabilidad


Cuando entré a mi trabajo de ciberseguridad, que en ese momento se llamaba de otra manera, una de las primeras cosas que me enseñaron en los pasillos fue: "Siempre cuidate el trasero". No fué exactamente con esas palabras, te podrás imaginar...


Si tu organización te da unas herramientas de acceso remoto, usá esas y no otras, si algo sale mal, siempre podés decir "yo seguí los lineamientos dictados". Puede parecer señal de cortedad de entendederas, pero que tu astucia no te haga ser instrumento de un ataque.

Si hay alguna actividad que no podés hacer o es muy incómodo o te lleva mucho tiempo de modo remoto sin violar las reglas de la organización, no la hagas, mala suerte, elevá y que la organización resuelva.

Que no te pase como a alguien que me contaron que puso su número personal de celular en el contestador del trabajo como contacto de emergencia siendo una persona sin rango ni responsabilidad por que el dueño no puso el suyo.

Registro


¿Vas a querer que lo ocurrido quede registrado o no? Si así lo deseás, no olvidés revisar y activar las opciones que la plataforma te brinde. Está bueno hacer algunos ensayos hasta dominar esas opciones a encontrarte con que perdiste el registro.

Si perdés le registro, decimos que afecta a la Disponibilidad de la Información.

Si no deseás que haya registro, no hagas la actividad, ya que no importa lo que la aplicación te prometa, que no almacena, que borra, con una simple cámara de video apuntando a la pantalla de cualquier participante va a haber registro.

La Confidencialidad de la Información abarca al registro no deseado, una vez que ésta es comprometida, tambien lo es el registro. Si te preocupa la confidencialidad sobremanera, no hagas la actividad.


Amo de mis silencios, esclavo de mis palabras.


Pérdida colateral de información


Tenés que detectar toda la información que estás compartiendo, evaluar que aporta compartirla y en qué te afecta. Si no aporta, aunque no te afecte, no la compartas, no sabés si en el futuro lo puede, ese banderín de tu partido o tu arco iris de respeto de género se te puede cobrar si los vientos cambian.

...o el afiche de New Kids on The Block...


La experiencia más imporante de pérdida accidental de información que he presenciado es que es común mostrar en pantallas compartidas en vivo credenciales, por lo general de acceso a alguna aplicación o a la plataforma de conferencias.


Mitigación: usar keepass o similar, que permite copiar y pegar url, usuario y clave sin que se muestren en pantalla y además tras unos segundos se borra del portapapeles el dato, reduciendo la posibilidad de pegarlo accidentalmente luego. Es lo mejor ya que las claves están cifradas y la ventana de ataque dura desde que se copia el dato en el portapapeles hasta unos pocos segundos despues.


Mitigación: esta es la más, usar fondo del mismo color que la letra para que no se vea accidentalmente. Es un excelente ejemplo de camouflage, seguridad por oscuridad. Aunque es increiblemente inseguro, es muy efectivo contra el escenario de exposición accidental, observá:

Usuario: el usuario
Clave: la clave

Ahora pintá el texto, si no está pintado no se vé, no sale en capturas de pantalla, videos, streaming. Este invento se debe a la gente de CESE/CAPSE/CEIoT.

Un aspecto extra de pérdida de información es que estás mostrando los contenidos de tu máquina. He visto varias veces que alguien busca en su sistema de archivos algo para mostrar y de paso vemos nombres de proyectos y empresas que quizás no era la idea mostrar.



Mitigación: armar una máquina virtual con la información necesaria para la conferencia. Si algo falta, suspender el modo compartido, transferirlo y retomar.


Otro aspecto es qué estás mostrando en el fondo de tu cámara o el ruido ambiental del micrófono. Podés estar revelando información personal, caras de familiares, gustos, composición familiar.

Mitigación: elegir el fondo de cámara, acordar si es posible con el resto de las personas habitantes que no se acerquen ni manifiesten. Ya sé que en lugares pequeños o en ciertas circunstancias de cuidado con niños se dificulta, pero la idea es hacer la evaluación aunque luego no puedas cumplir.

Hay un reflejo que he notado que es ocultar rápido lo que ha sido expuesto accidentalmente. No tiene mucho sentido, si hay registro basta pausar y con que haya quedado en al menos un cuadro, ha sido perdido.

Hay que cambiar las credenciales.

Más sobre esto he escrito en antes y antes.

En pocas palabras...

  • Evaluar la información que se va a compartir de modo directo e indirecto.
  • Usar protección de credenciales.
  • Actuar ante detección de falla.
  • Virtualizar para reducir exposición de información.
  • No correr riesgos que no te paguen.

 

Reflexión final


Nunca olvides que los grandes líderes y empresarios VIAJAN para resolver sus chanchullos, esto no es sólo por la ventaja del cara a cara, donde pueden seguir el lenguaje corporal, si no por que tienen el control real sobre la situación, pueden tener conversaciones realmente confidenciales y sin registro.

Por más que exista un producto carísimo que provea confidencialidad, no olvides que no lo hiciste vos, por que te dedicás a otra cosa y aunque te dedicaras probablemente lo harías mal.




Ya sé, ya sé que vos y yo somos perejiles, pero los fenómenos mejor se comprenden en las situaciones extremas.


Resolución de problemas sin google.

o los senderos que se bifurcan.

El problemo



Me hallaba instalando MCUXpresso que es una IDE basada en eclipse para desarrollo de sistemas embebidos de NXP para poder programar la mimxrt1020-evk que NXP me regaló. El instalador es un archivo armado con Makeself.



El inicio del instalador

Este archivo es una concatenación entre un enorme comprimido y un encabezado que hace unas verificaciones, descomprime y ejecuta lo que hay en el comprimido.



El inicio del payload binario

En este caso en particular, supongo que usa apt/dpkg para instalar dependencias y dejar todo prolijito. Al final llama a las configuraciones pendientes y tiene una falla que hace meses que está ahí y nunca me había molestado, hasta ahora.


Tomá nota del exit status 6

Momento de decisión: buscar situaciones parecidas con google (no) o escarbar por mis propios medios (si).

Podemos ver que el paquete es kismet y que tiene que ver con un usuario inexistente. Tambien podemos ver que más que una instalación de MCUXpresso es una reinstalación (unpacking xxxx over xxxx) y no vemos que fué lo que instaló, claro, las dependencias ya quedaron en el primer intento y recién se me ocurrió documentar luego.

Me imagino que cuando instalé kismet me mandé alguna macana con los usuarios y kismet ofrece ajustar los permisos para que algunos usuarios puedan hacer cosas que normalmente requieren privilegios sin tener que usar root o sudo.

En los scripts debe haber una linea como:

dpkg -i JLink_Linux_x86_64.deb mcuxpressoide-11.1.1_3241.x86_64.deb

que al final dispara una acción que lleva a ese error.

Para comprobarlo debería descomprimir el payload o instalar y observarlo mientras esté descomprimido, pero prefiero suponer que no tengo acceso o que el instalador está tomando medidas defensivas, también me obliga a entender como funciona Makeself que aunque no debe ser muy misterioso me resulta completamente carente de interés, Makeself es circunstancial, es más productivo aprender del sistema común.


Momento de decisión: analizar y modificar al instalador (no) o replicar comportamiento (si).



Necesito reproducir el comando mínimo con el mismo resultado. No me preguntes de dónde lo sé, evidentemente es el humus estratificado de mi mente, pero sé que:

sudo dpkg --configure kismet

debería servir y así es:




El siguiente paso es ver que archivos está abriendo con strace

sudo strace -f -eopen dpkg --configure kismet

Trae dos cosas interesantes:



Fijate que coincide el 6 con el 6 de la captura.


Un archivo interesante para mirar



Agregando que nos muestre las lecturas:

sudo strace -f -eopen -eread dpkg --configure kismet


Tomá nota del GET kismet/install-users

En los read() de arriba, se ve pasar el nombre del usuario inexistente. Esa forma de letrita por letrita primero apuesto a que es indicio de un pipeline entre procesos. Pero no lo pude reproducir, así que quizás sea algo tipo expect, un proceso pasándole letritas a otro interactivo.


Volviendo al archivo interesante, /var/lib/dpkg/info/kismet.postinst, este hace una llamada que coincide con el GET de más arriba:



Ahí le agregamos a continuación de usermod:

echo "########### group $GROUP x $x "

y ahora tenemos:


El siguiente paso es comprender como funciona db_* para modificar el usuario.

Al inicio se incluye /usr/share/debconf/confmodule, dentro de ese archivo vemos los comandos disponibles:
 

Hay tantos debconf que no podemos menos que preguntar a man debconf de qué se trata:





Para ver debconf-devel hay que instalar debconf-doc.


Momento de decisión: esto tendría que habérseme ocurrido en el primer momento: puedo desinstalar kismet (no), agregar el usuario faltante para que termine la instalación (no) o seguir por este camino (si).


Leemos superficialmente man debconf-devel y deducimos que con db_set nos arreglamos:


. /usr/share/debconf/confmodule
db_get kismet/install-users
echo $RET
db_set kismet/install-users XXXXXX
db_get kismet/install-users
echo $RET



Me vas a tener que creer que primero dice un usuario y luego otro

Apuesto a que el instalador ahora anda:


Gané, me anoto quitar ese echo.




Queda entonces para que google le responda al próximo que no quiera pensar mucho:

dpkg: error processing package
subprocess installed post-installation script returned error exit status 6
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code