Un análisis de cómo vulneraron mi servidor de pruebas de PostgresSQL y cómo proteger tu 
Tags: postgres, pgminer
Published: 2021-09-20 07:49:40

*Un análisis de cómo vulneraron mi servidor de pruebas de PostgresSQL y cómo proteger tu instalación si eres nuevo con este motor de base de datos.* 

Recientemente inicié a trabajar con una base de datos PostgreSQL fuera del ambiente seguro de los contenedores, esto On Promise en un servidor virtual, ya se la saben primero hago explotar mis experimentos en casa y ya luego al mundo laboral.
No han pasado menos de tres días que empecé y me había percatado de que la CPU estaba al máximo y se me creaban una serie procesos que consumían todos los núcleos. 

Sin comprender porque sucedía el día de hoy empecé a indagar por cuenta propia y descubrí una “vulnerabilidad” del propio gestor, **_“PgMiner Botnet Attacks PostgreSQL”_** hasta este punto debo reconocer lo noob que vengo siendo y el pecado de la inocencia, mi experiencia se desarrolla más en Percona con base MySQL.

Después de estar leyendo diversos artículos de cómo deshacerme de este _“Malware”_ llegué a las entradas de _Sanchistsharman_ [**Investigation into Postgres malware (hack?) - DEV Community**](https://dev.to/sanchitsharma/investigation-into-postgres-malware-hack-2ai0), pero antes de describir todo esto te explico. 
Siempre que instalo un nuevo servidor Linux por defecto va Glances and Htop para tener una vista más clara se los procesos que se están ejecutando. 

**UFW to Rescue**

El proveedor actual no nos da un firewall administrable así que lo primero que realicé fue habilitar ufw, actualmente trabajo con Ubuntu Server 20.04.

En este punto dejo abierto solo los puertos que requiero para administrar el servidor. 
Una vez aplicadas las reglas al firewall procedí a deshabilitar el logueo de usuario postgresql y revocar los accesos a las bases de datos. 

Como siguiente punto cambiar el puerto 5432 por uno diferente, esto lo recomiendo para todos los servicios a excepción de los puertos 80 y 443, el resto de los servicios puede ser cambiado. 
En este punto tanto el uso de la CPU como de la Memoria había disminuido. 

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w2mtz7mjl8nes3exwsi5.png)

Lo mismo de agradecido hasta ahora con las conexiones al servidor

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xwgmrx3ws2z4397mo5xs.png)


Te recomiendo seguir esta guía [Cómo configurar un firewall con UFW en Ubuntu 20.04 | DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-20-04-es)

Posteriormente regresando al post de Sanchistsharman me he puesto a leerlo todo y trate de entender el cómo lo había hecho. 

En mi caso particular estoy trabajando con la versión 12 del motor y el manual no funcionó como tal sin embargo al navegar en _/var/lib/postgresql/12_ había encontrado un **“binario llamado k”** pero lo que el indicaba en el manual no. 

Retrocedí un directorio y ejecuté el comando ls -f para mostrar los archivos ocultos y me encontré con el siguiente archivo **_.systemd-private-2OossFop8vSbHI1fjSzMJoolZfE29S.sh_** cuyo contenido no es más que una cade hasheada a base 64

A continuación la imagen

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mtdgu6vtfoo69jnjpxgo.png)
 
Acorde a lo que indica el post de sanchistsharma hay que navegar en los directorios del archivo ya desencriptado para removerlo.
 
Después de una batalla de tres horas así luce nuevamente mi servidor de pruebas 

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ydsuagxi00ij5qawkqgm.png)

**Conclusiones.** 

Después de esta vulnerabilidad recomendaría que, aunque tengas una instalación en Windows revisaras el estado de tus procesos (así sea para pruebas), si vas a trabajar con un servidor fuera de contenedores: 

* Cambiar los puertos, deshabilitar el logueo para el usuario postgresql y crear otro rol que pueda administrar el motor

* Utilizar una contraseña de más de 16 caracteres algo como wt2Ut/rF)asd3412-*--x~FZ.!*V((k4ry podría ayudar

* No dar por sentado que la instalación por defecto mitigará errores o vulnerabilidades, así sea la última versión. 

* Linux es un sistema seguro, los errores los comete el administrador *sorry*

* Aventurarse a trabajar y aprender cosas nuevas es divertido dentro de un entorno seguro, cuando vayas a producción asegúrate de haber aprendido todo y conocer realmente la tecnología que vas a implementar y sus vulnerabilidades, hoy lo aprendí a la mala. 

* Siempre pregúntate ¿qué pasó aquí? Y cómo poderlo resolver, recuerda que en producción se vuelve más complicado, ten ese espíritu de batalla e investigación. 

* Duerme a tus horas. 

*Referencias*

* [Using strace to Debug Stuck Celery Tasks](https://www.caktusgroup.com/blog/2013/10/30/using-strace-debug-stuck-celery-tasks/)
* [PgMiner Botnet Attacks PostgreSQL Databases to Install a Cryptocurrency Miner](https://gbhackers.com/pgminer-botnet-postgresql/)
* [PGMiner, Innovative Monero-Mining Botnet, Surprises Researchers] (https://threatpost.com/pgminer-monero-mining-botnet/162209/)
* [In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pg_execute_server_program' group to execute arbitrary code in the context of the database's operating system user.] (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9193)
* [CVE-2019-9193 PostgreSQL in NetApp Products] (https://security.netapp.com/advisory/ntap-20190502-0003/)
* [PGMiner: New Cryptocurrency Mining Botnet Delivered via PostgreSQL](https://unit42.paloaltonetworks.com/pgminer-postgresql-cryptocurrency-mining-botnet/)
* []()