Exploits como software Unix philosophy

Destruir siempre ha sido como norma general menos complejo que construir. Eso dicen pero no es cierto siempre. Algunas personas dicen aquello de que «destruir es divertido para el que sabe construir» posiblemente por aquello de que saben lo que cuestan las cosas.

Quien crea un software para solucionar algún problema tiene también que pensar la forma de construir el software para que sea «usable» por terceros. El que crea un exploit para atacar un fallo, una vulnerabilidad está creando una solución igualmente pero suelen ser pruebas de concepto para demostrar algo.

Creo que no son comparables las exigencias de un software de un grupo de programadores/as a las que se le exigen a quien crea un exploit (ninguna exigencia salvo la de reproducir un bug muchas veces).

Los exploits están siempre en cada pequeño fragmento de un gran programa. Muchas veces un exploit es una función de un gran programa y poco más.

Escribir exploits normalmente es la cosa más sencilla del mundo y por el contrario se piensa que es lo más difícil de hacer. La mayoría (evidentemente no todos) de lo exploits son simples PoCs cuando se escriben (Pruebas de conceptos escritos en algún lenguaje de scripting).

Explotar cosas está escrito en mil y un lenguajes. Y normalmente mal escrito (no necesita por ejemplo ser escalable o soportado en el tiempo, se hace contra algo concreto).

Resulta que encuentras un fallo en algo. Entonces escribes un pequeño programa que te permita reproducir el error, el bug. Eso normalmente y dependiendo del bug lo haces con lo que pillas y tienes más a mano (python, bash, perl, lua, … también c leñes con gcc como compilador)

Crear software de verdad para que lo usen miles, millones de personas supone pasar QAs (quality assurances), auditorías de seguridad, cumplir con legislaciones de diferentes países, hacerlo usable en el mínimo de pasos, …

De modo que no es tontería afirmar que los exploits son posiblemente el software más Unix philosophy existente muchas veces :).

La Filosofía UNIX supone crear programas rápidos, simples, con poca intervención por parte del usuario, o en caso de necesitarla, esta se produzca al principio o lo más mínima posible.

Pequeños programas son cada una de las funciones a las que haces frente.

Pongo de ejemplo la simple obtención de un archivo de un servidor ftp (un código que suelo emplear algunas veces para descargar mods músicales del servidor ftp ftp.scene.org). Aquí el código python:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import ftplib
import sys

lenArgs=len(sys.argv)
ftp = ftplib.FTP()


# Función para comprobar si se ha introducido el número necesario de los argumentos necesarios
def ftpCheckArgs():
	if lenArgs == 7:
		global ftpServer
		global ftpPort
		global ftpLogin
		global ftpPasswd
		global ftpPath
		global ftpFile

		ftpServer = sys.argv[1]
		ftpPort = sys.argv[2]
		ftpLogin = sys.argv[3]
		ftpPasswd = sys.argv[4]
		ftpPath = sys.argv[5]
		ftpFile = sys.argv[6]
		return 1
	else:
		return 0

# Función para cargar en variables los argumentos introducidos
def ftpLoadArgs():
	ftpServer = sys.argv[1]
	ftpPort = sys.argv[2]
	ftpLogin = sys.argv[3]
	ftpPasswd = sys.argv[4]
	ftpPath = sys.argv[5]
	ftpFile = sys.argv[6]

# Función para contectar al servidor y el puerto. Usando login y password. Luego path y file.
def ftpConnect(server, port, login, passwd, path, file):
	ftp.connect(server, port)
	ftp.login(login, passwd)
	ftp.cwd(path)
	ftp.retrbinary("RETR " + file ,open(file, 'wb').write)



# El programa

if ftpCheckArgs(): # si la función ftpCheckArgs retorna 1 es true y entra
	ftpLoadArgs() # carga las variables con los argumentos dados
	ftpConnect(ftpServer, ftpPort, ftpLogin, ftpPasswd, ftpPath, ftpFile) # conecta y descarga el archivo
else:
	print ("Example: ftpGetFile ftp.scene.org 21 anonymous anonymous@anonymous.com /pub/music/artists/awesome aurora.zip")

No está bien programado pero me sirve. Y sirve para descargar algún archivo si se tienen las credenciales. Se pasan los parámetros y lo tienes.

Un script python para descargar un archivo. Nada de otro mundo pero algo que al mismo tiempo permite usarse como exploit para algunos modelos de impresoras Konica Minolta.

Básicamente el mismo script (con alguna comprobación) que te permite un transversal directory FTP.

Para usarlo como xploit solo se ha de meter un parámetro con churro. Ejemplo: «../../../../../../boot.ini»

Y bueno. Es solo un ejemplo sin mucha importancia (pero tenía que poner un ejemplo).

El tema es que muchas veces esos scripts que hacemos para automatizar tareas terminan sirviendo para explotar fallos de seguridad. Cada programa tiene dentro de si muchos otros.

Y sinceramente pienso muchas veces que los exploits son muy del rollo filosofía unix por aquello de que tienen que hacer algo, una sola cosa y hacerla bien. Son pequeños programas normalmente para demostrar y reproducir vulnerabilidades, no tan diferentes a los programas como cat que tiene que poder concatenar archivos, wc contar letras, caracteres, lineas, … o echo que tiene que imprimir algo (en pantalla por defecto).

Son tan simples los exploits (normalmente, no siempre) que alterar su código para automatizar tareas es trivial. Básicamente sacar a parámetros las variables pertinentes.

Si tengo que «romper una lanza» pro gente que trabaja en el mundo de la seguridad diré que lo más complejo no es crear el script de prueba de concepto. Lo más complejo es encontrar los fallos, el concepto. Por eso creo que son 2 mundos diferentes pero que de algún modo caminan juntos para un objetivo: mejor software, software más seguro.

Y aunque pienso que no se exige lo mismo en cuanto al software no cabe duda que el curro del mundillo de «los/las seguratas informáticos» es digno también y su trabajo no es al final de cuenta para que lo use la gente como el que usa el firefox para navegar.

Y hasta aquí la reflexión sin moraleja impactante.

Saludos cordiales.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

20 − 16 =