Bajo Ataque

Ningún equipo está a salvo de sufrir un ciberataque y, a ciencia cierta, se sabe que tarde o temprano te toca.

Este es el relato de unos hechos ocurridos en mayo de 2021, donde uno de mis equipos se ha visto “comprometido”. Se contarán los hechos tal cual son, con profundidad superficial y profunda, adecuado a todos los niveles, tanto los newbies que lleguéis a este artículo, como los grandes hackers que me examinan de continuo. Veremos: un poco de hacking, otro poco de ingeniería inversa ligera y otro poco de programación.

Administro un equipo con Windows 10 el cual tiene enchufados una serie de dispositivos físicos, debido a peticiones en las especificaciones de un proyecto de un cliente. Se encuentra conectado a un sistema domótico de control de temperaturas de tuberías, caudalímetros. condiciones de calderas, etc. Es una instalación muy compleja y antigua, instalada con módulos de control de Advantech ADAM serie 4000 (alguna vez he hablado sobre ellos), con lo que el equipo lleva un puerto serie RS-232 nativo en la placa base. El programa que monitoriza, gestiona y controla la instalación está realizado en Borland C++ para Windows, en arquitectura de 32 bits porque ya tuvimos una historia surrealista con XP, por suerte no hubo que recompilar para Windows 10. Al principio iba perfecto, pero a medida que se necesitó dar información adicional empleando otro tipo de servicios la cosa se fue complicando, hasta llegar al punto de hoy.

Lo idóneo es que ese servidor fuera Linux, pero el cliente no va a invertir absolutamente nada en su mejora ni en el cambio de las condiciones de su mantenimiento… Ya sabéis cómo va ésto.

Hemos conseguido cambiar 2 veces la máquina: la primera fue durante la instalación, que vimos que “no tiraba” con todo los sensores a controlar y fue de los primeros equipos con Windows 7 de 64 bits que instalé. Funcionó a la perfección durante 15 años, hasta que la placa base murió y tuvimos que colocarle una más actual, aprovechando el cambio para instalar Windows 10 Pro, instalar nuevos discos… Vamos, un lavado de cara considerable. En esa instalación el cliente necesitaba adicionalmente conocer los parámetros desde fuera de la instalación, con lo que se le optó por instalar un servidor web (APPSERV, no quisimos instalar IIS – Internet Information Server-, y no lo instalamos en el puerto 80, que sería lo lógico, sino en el 22225) en el equipo, y que con recordar un nombre y un puerto, pudiera acceder desde cualquier parte del mundo. Como no tiene dirección IP estática, se recurrió a un servicio de ip dinámica, duckdns.org en concreto.

Mis alumnos me han escuchado hasta la saciedad eso de NO ABRIR LOS PUERTOS AL ROUTER, en especial los de la asignatura de la DarkWeb, aunque el resto seguro que en alguna ocasión me lo habrá oído. Pero en esta instalación, realizada en una época pretérita donde lo que importaba era su funcionamiento y no tanto la ciberseguridad (¿a que os suena?), aunque me pesó considerablemente, se tuvo que hacer así, porque de no hacerlo, la navegación por los datos no sería fluida: la penúltima mejora consistía en la visualización de varias cámaras que registraban cada cierto tiempo un evento que se producía en la sala de calderas, grabando archivos a la máxima resolución que podían ser visualizados desde cualquier parte del mundo. Luego también quiso poder descargarlos, por lo que se decidió colocar un servidor SFTP, con otro puerto abierto para que las transferencias no se eternizaran.

Lo único que me dejaron colocar debido a mi obsesión por la ciberseguridad fue un antivirus con cortafuegos que fuera capaz de monitorizar todas las conexiones y parar cualquier ataque externo. Por mi propia experiencia, y hasta que encuentre otro que lo sustituya, el elegido es ESET Internet Security en modo interactivo (es una opción que pregunta, cada vez que un programa o servicio quiere conectarse a Internet, qué deseamos hacer):

  • Permitir,
  • Denegar,
  • Preguntar siempre,
  • Recordar hasta el cierre de la aplicación o
  • Crear regla y recordarla permantentemente

De esta forma, es muy fácil dejar pasar o no determinado servicio o programa, e igualmente si algo quiere entrar en el sistema. Ni que decir tiene que cuando se encuentra perfectamente configurado, prácticamente no hay que tocarlo por los siglos de los siglos.

La existencia de este artículo viene promovida precisamente por un ataque a esta máquina, en la que me encuentro la siguiente imagen:

Descifremos la captura:

ESET nos está diciendo que una aplicación del sistema (httpd.exe, el servidor de apache que se utiliza para mostrar los resultados), quiere conectarse a una dirección IP (xxx.230.xxx.111), al puerto remoto 21 de esa máquina (todos ya sabéis qué puerto es ese, es el del FTP, acrónimo de File Transfer Protocol, protocolo de transferencia de archivos). La IP la he ofuscado para que no me quitéis la diversión de tumbarme el equipo, jaja. También indica que registró este tipo de conexión hace 7 años.

¿Qué es lo primero que debemos hacer?

El cortafuegos está evitando que se descargue cualquier archivo, tendría que darle a “PERMITIR“, cosa que nadie en su sano juicio haría, jajaja.

Decidimos capar los puertos abiertos, hoy día las VPN son bastante rápidas y se procede a cerrarlo todo. Paramos todos los servicios, chequeamos que no hay nada raro corriendo, es decir, que la máquina esté infectada, y una vez que el MODO PARANOICO se convence que no, se deja funcionando.

Sabemos qué han hecho: han empleado un script en javascript que lanza una conexión a un ftp anónimo para descargar un archivo de extensión php y que, de no tener ese cortafuegos, se descargaría y se ejecutaría en la máquina.

Tarea para los grandes inyectadores de código, ¿cómo lo han hecho?

Continuamos con la diversión

Si vamos a cotillear IPs ajenas, debemos ocultarnos, empleando para ello una consola de Tor, ya que nos cambia nuestra dirección IP que nos proporciona el proveedor del servicio y, usando nuestro Linux favorito (en mi caso, Lubuntu, por su ligereza y su multicapacidad), nos conectamos a esa dirección IP. Descubro que sí, que tiene un servicio de FTP en ese puerto, y además, anónimo: puedes entrar hasta el fondo sin necesidad de colocar nombre de usuario y clave. En un directorio llamado “pub”, me encuentro un archivo llamado “fuck.php”. Toda una invitación. Me lo traigo y lo abro con nano, para echarle un vistazo, y me lo mando a un equipo con Windows, para cotillearlo más tranquilamente.

La primera frase del archivo “invita” a sacar la capucha:

Imagen

Una de las muchas cosas que podemos hacer, es realizarle un escaneo de puertos a esa IP, puede que por arte del birlibirloque hay algo interesante que husmear o no. Podemos realizarlo desde la misma consola torificada o usar nuestra página favorita para encontrar las vulnerabilidades de los equipos, así que me decanto por esta última por aquello de los gráficos para insertar en este artículo:

¿Fremont? Un buen lugar para ir de vacaciones, ¿no? Por privacidad se oculta el resto del contenido.

Vamos a ver los puertos:

Wow, el 21 ya lo sabía… Pero el 22, suena interesante. Para quien no lo sepa, es el de la consola remota, ssh.

El mismo portal nos devuelve la versión que se trata:

¿Tendrá alguna vulnerabilidad? Por lo pronto, la última versión, de 2021, es la 8.6/8.6-p1, es decir, ¡¡¡tiene pinta que tenemos premio!!!!. Efectiviwonder:

Si no lo han parcheado, ahí tenemos entretenimiento.

Pero vamos a ocupaciones más mundanas. ¿Qué contiene el archivo “fuck.php”? La primera línea ya la puse antes, pero a continuación, aparece código php “puro”:

El archivo en cuestión tiene un tamaño de 122 Kb, es irreproducible en extensión, pero os puedo contar algunas cosas que, así, a primera vista, le ocurre:

  • Tiene codificado en base 64 el código fuente, es decir, la instruccion de php base64_decode(‘loquesea’) lo que hace es descodificar el contenido de esa cadena alfanumérica, que aparece inintelegible.
  • La instrucción eval, lo que hace es ejecutar lo que base64_decide descodifique.

Vale, pues si cambiamos “eval” por “echo”, nos sacará por pantalla lo susodicho:

¡¡Oh, sorpresa!!

Nos saca otro archivo php, con un segundo codificado en base 64. Procedemos igualmente, cambiamos por “echo” el “eval” y:

Lo que ocurre es que así todo puesto no se ve nada bien. Vamos a darle algo de formato:

Desgloso un poco el principio, esto daría para varias clases de programación en PHP…

set_time_limit(0);

Nos está indicando que el límite de ejecución del script lo pone a cero, que significa que no se detendrá bajo ninguna circunstancia.

error_reporting(1);

Establece que se visualicen los errores en tiempo de ejecución, para actuar en consecuencia.

$dir = getcwd();

Mete dentro de la variable denominada dir (en PHP las variables llevan el signo de dolar delante), el contenido de la función getcwd(), el cual es el directorio donde se está ejecutando PHP

$uname = @php_uname();

El uso de la @ en PHP es sinónimo de operador de control de errores. Lo que hace es ignorar cualquier mensaje de error que se pudiera obtener. Y php_uname() devuelve una descripción del sistema operativo que estamos usando.

$GLOBALS[‘accounts’] = “”;

Crea una variable global llamada accounts, vacía en primer momento.

function whereistmP():

Función destinada a encontrar el directorio temporal del sistema en el que se ejecuta el script de PHP.

Conclusiones

Evita en lo posible tener puertos abiertos en el router, así previenes un ataque a los servicios que funcionan en estos puertos. Da igual que cambies el puerto, tarde o temprano, te lo encuentran.

Protégelo todo lo que puedas. El sistema de protección que os he enseñado ha librado a muchas personas de ataques tipo Wannacry, Emotet, Ryuk…

Si el ataque se produce, documéntalo todo lo que puedas, se puede aprender muchísimo. Y ya si te haces con el programa que te quieren ejecutar, estarás viendo los pensamientos de otro (por suerte, el php no se ofusca demasiado).

Dejo para otra ocasión el análisis del código fuente, no deja de ser una práctica interesante.