Cualquier cosa que pueda hacer en una cuenta comprometida, un atacante también puede hacerlo.
Fundamentalmente, esto se debe a que Linux proporciona aislamiento entre usuarios, no entre procesos individuales que se ejecutan como el mismo usuario. Se considera que cualquier proceso que se ejecute como un usuario determinado tiene capacidades equivalentes a las de cualquier otro proceso que se ejecute con ese usuario.
¿Es cierto que el ejecutable sudo del sistema se puede eludir de esta manera?
Sí, y de otras maneras también. Si eleva los privilegios a la raíz en una cuenta sin privilegios comprometida, compromete la raíz. Si elimina los privilegios desde la raíz usando su a una cuenta sin privilegios, ¡también compromete la raíz! Nunca puede elevar los privilegios de forma segura en una cuenta que no es de confianza. Si bien es posible explotar el sistema usando PATH , también es posible secuestrar el propio proceso bash para rastrear la entrada de la tecla. Deshabilitando la ejecución con noexec Además, no es útil porque los intérpretes (bash, python, perl, etc.) seguirán ejecutándose. El noexec La opción no está y nunca ha sido diseñada como una función de seguridad, a pesar de que se promociona regularmente como tal.
Una lista incompleta de las formas en que un atacante podría secuestrar el uso de sudo o su :
-
Usando el
LD_PRELOADvariable en el proceso principal (por ejemplo,bash). -
Enganchando el proceso padre con
ptrace()oprocess_vm_writev(). -
Husmear o inyectar pulsaciones de teclas en el emulador de terminal utilizando el protocolo X11.
-
Crear alias o funciones para envolver el
sudoactual ejecutable.
Los expliqué con más detalle en mi respuesta a otra pregunta.
¿Por qué los sistemas Linux de escritorio, por defecto, están configurados de una manera tan fácil de explotar?
Elevar los privilegios en una cuenta que no es de confianza no es algo que se suponga que hacer. Sin mencionar que Linux de escritorio es una ocurrencia tardía en el gran esquema de la arquitectura general *nix. Es una falla del teatro de seguridad que repite incesantemente el mismo mal consejo, no una falla de la arquitectura de seguridad de Linux en sí. La gente dice repetidamente que use sudo para root porque muchos usuarios nuevos ejecutarán todo como root, ¡incluso sus navegadores! En este caso, es mejor usar sudo . Es dañino en el caso de que el usuario ya sea lo suficientemente inteligente como para no usar la raíz para todo.
Tenga en cuenta que sudo es altamente configurable y puede diseñarse para permitir solo ciertos comandos. Aquí es donde realmente brilla. Puede configurar sudo para que solo te permita ejecutar apt-get update como root (con o sin contraseña) y niega todo lo demás. Eso además impediría que un atacante haga otra cosa que no sea... bueno... hacer una actualización de software.
Es importante recordar que, incluso si lo configura para que solo permita ejecutar ciertos comandos como root, aún puede dispararse si incluye en la lista blanca programas que no están diseñados para ejecutarse como root a través de un usuario que no es de confianza. Vi un ejemplo de la vida real de alguien que intentaba ejecutar VeraCrypt de esta manera y expliqué por qué es inseguro. La idea era que VeraCrypt se puede ejecutar como root, por lo que debería ser seguro usar sudo para elevarlo a la raíz como un usuario no confiable y sin privilegios. ¡Resulta que la idea es defectuosa y permite una escalada de privilegios trivial!
¿La forma predeterminada de invocar sudo no debería asegurarse de que es, de hecho, el ejecutable proporcionado por el sistema (nadie va a escribir /usr/bin/sudo cada vez)?
¡Escribir la ruta completa no lo protegerá! Puede crear fácilmente una función que contenga un / inicial , y anulará el ejecutable real. Incluso si el ejecutable se aseguró de que es genuino e intentara vencer el sniffing, un proceso malicioso podría secuestrar el bash procesar y detectar pulsaciones de teclas independientemente de sudo , por lo que es imposible de detectar desde su punto de vista.
$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!
En tal entorno, parece que usar sudo es fundamentalmente inseguro y sería mejor habilitar el inicio de sesión como root e iniciar sesión en un TTY separado.
Esto es siempre el caso. Tenga en cuenta que incluso iniciar sesión en otro TTY no es perfectamente seguro. Debe utilizar SAK, la combinación de clave de atención segura, para asegurarse de que está interactuando con una sesión de inicio de sesión genuina (agetty o logind , por ejemplo). SAK es una combinación de teclas que el núcleo escucha (y, por lo tanto, no puede ser reprimida por el espacio de usuario). Cuando lo detecta, eliminará todos los procesos en el TTY actual, lo que activará la aparición de la solicitud de inicio de sesión. Si ha cambiado a un TTY genuino y no comprometido, solo hará que el aviso desaparezca y vuelva a aparecer. Si está en un TTY secuestrado, eliminará el proceso malicioso y recuperará el indicador de inicio de sesión genuino.