DEV Community: Dilver Huertas Guerrero

Explorando el paralelismo real: Python 3.14 (No-GIL) y Rust

Dilver Huertas Guerrero — Thu, 18 Dec 2025 00:01:18 +0000

Contexto

En una publicación anterior se desarrollo un código en python para generar hashes de tarjetas de crédito, con el fin de mostrar la diferencia entre integridad y confidencialidad. Igualmente, se menciona que "el código desarrollado es sólo una aproximación, dado que se puede hacer más eficiente aplicando procesamiento en paralelo". El objetivo de esta publicación es explorar el procesamiento en paralelo tanto en Python, con su última versión 3.14t que habilita paralelismo real al eliminar GIL, el cual en resumen es es un mecanismo de protección que asegura que solo un hilo de ejecución pueda ejecutar código a la vez, permitiendo simplificar la gestión de la memoria y prevenir condiciones de carrera, pero impide el verdadero paralelismo en aplicaciones multihilo, incluso en procesadores multinúcleo.

Adicionalmente se quiere introducir Rust para comparar su velocidad de procesamiento frente a Python, y más allá de eso resaltar sus capacidades como un lenguaje seguro. Rust implementa un sistema propio llamado Ownership y Borrowing (Propiedad y Préstamo) en el cual el compilador rastrea quién posee un dato en memoria, y cuando esa variable sale de su ámbito la memoria se libera inmediatamente; dando como resultado que es imposible tener errores comunes como buffer overflows, dangling pointers o double frees. También detecta las condiciones de carrera en tiempo de compilación y tiene un sistema de tipos que elimina el error del puntero nulo, al este no existe de forma nativa.

En otras palabras si el código tiene un riesgo de memoria, simplemente no compila, y teniendo en cuenta que los errores en la gestión de la memoria causan el 70 % de las vulnerabilidades, se actúa de manera preventiva en la mitigación de estas. Rust se convierte así es un lenguaje a tener en cuenta para el desarrollo de soluciones que requieran un rendimiento alto en aplicaciones críticas, como motores de browser, sistemas operativos, criptografía, drivers, entre otros.

Comparación de desempeño

A continuación se muestra el resultado del procesamiento de cálculo de hashes para python en procesamiento paralelo, rust en un solo hilo, y rust en procesamiento paralelo. El código de cada uno, se encuentra al final de este mismo post en la sección Anexos.

El siguiente gráfico detalla el rendimiento del procesamiento de los 20 lotes de datos después de implementar las técnicas de paralelismo No-GIL en Python, combinadas con la estrategia de Productor-Consumidor y batching para gestionar la alta carga de E/S. Cada barra representa el tiempo (en segundos) que tardó en procesarse, hashearse y escribirse en disco un lote de 10 millones de hashes. Se observa que la mayoría de los archivos se procesan en un rango muy estrecho de 14.2 a 14.6 segundos.

El rendimiento observado en rust en procesamiento mono-hilo muestra una diferencia fundamental en la filosofía de ejecución de ambos entornos. Mientras que la versión de Rust en un solo hilo es extremadamente rápida debido a su cercanía al hardware y la ausencia de overhead de interpretación, la versión de Python No-GIL depende totalmente de la paralelización masiva para intentar alcanzar cifras similares (en este caso en particular).

La implementación multihilo en Rust marca un punto de inflexión en el ejercicio, mientras que las versiones anteriores (Rust mono-hilo y Python No-GIL) están alrededor de los 14 segundos, la arquitectura de Productor-Consumidor optimizada en Rust muestra un rendimiento consistente, lo que indica que el software no está generando cuellos de botella, dónde ya el hardware es el que no puede ir más rápido.

Tiempos promedio por archivo y estimados para procesamiento total

	Python (1-hilo)	Rust (1-hilo)	Python (m-hilo)	Rust (m-hilo)
PROMEDIO (s)	79,47	13,81	14,48	3,49
ESTIMADO (s)	7947	1381,1	1448	349
ESTIMADO (h)	02:12:27	00:23:01	00:24:08	00:05:48

Matriz de comparación de desempeño

	Python (1-hilo)	Rust (1-hilo)	Python (m-hilo)	Rust (m-hilo)
Python (1-hilo)	100,0%	17,4%	18,2%	4,4%
Rust (1-hilo)	575,4%	100,0%	104,9%	25,2%
Python (m-hilo)	548,7%	95,4%	100,0%	24,1%
Rust (m-hilo)	2280,3%	396,3%	415,6%	100,0%

Conclusiones

El ejercicio de generación masiva de hashes de tarjetas de crédito nos permite extraer algunas conclusiones sobre los lenguajes de programación en cuestión y la gestión de recursos de hardware.

La superioridad de Rust no reside únicamente en su velocidad, sino en su filosofía de diseño, mientras que en otros lenguajes el rendimiento suele comprometer la seguridad (exponiendo al sistema a buffer overflows o condiciones de carrera), Rust mitiga preventivamente alrededor del 70% de las vulnerabilidades comunes mediante su sistema de Ownership, lo cual lo hace una alternativa a considerar.

Por otro lado, la eliminación del GIL en Python muestra que logra una mejora del 548% respecto a su versión mono-hilo, sin embargo en este caso, requiere de toda la potencia multihilo del procesador para apenas igualar lo que Rust logra con un solo núcleo. Esto subraya que, aunque Python es ahora capaz de paralelismo real, el overhead de su interpretación sigue siendo un factor importante frente a lenguajes compilados.

La versión de Rust multihilo es la opción ganadora, procesando cada lote en apenas 3.49 segundos de promedio, este código ha alcanzado el límite físico del hardware, siendo limitante la velocidad de transferencia del disco (E/S).

Para aplicaciones que requieren alta disponibilidad, seguridad de memoria y procesamiento masivo de datos, Rust es la opción lógica. Python, con su nueva versión No-GIL, reduce la brecha y se vuelve mucho más competitivo para tareas paralelas, pero Rust sigue manteniendo el liderazgo en eficiencia y protección proactiva contra vulnerabilidades.

Anexo: Código para Rust en un único hilo, Python multihilo y Rust multihilo

Rust en un único hilo

Se desarrollo el siguiente código en Rust para el cálculo de hashes de las tarjetas de crédito, ejecutando la misma funcionalidad desarrollada en python en el post anterior.

use sha2::{Sha256, Digest};
use std::fs::File;
use std::io::{BufWriter, Write};
use std::time::Instant;

    // 1. Implementación del Algoritmo de Luhn
    // A diferencia de Python, aquí trabajamos con bytes directamente, ahorrando memoria.
    fn calcular_digito_luhn(numero_str: &str) -> u32 {
        let mut suma_total = 0;

        // Iteramos los caracteres en reverso
        // .chars().rev() es un iterador perezoso (lazy), no crea una lista nueva en memoria como Python
        for (i, c) in numero_str.chars().rev().enumerate() {
            let mut digito = c.to_digit(10).unwrap(); // Convertir char a u32

            if i % 2 == 1 {
                digito *= 2;
                if digito > 9 {
                    digito -= 9;
                }
            }
            suma_total += digito;
        }

        (10 - (suma_total % 10)) % 10
    }

    // 2. Función para hashear (aplica SHA256)
    fn aplicar_sha256(numero: &str) -> String {
        let mut hasher = Sha256::new();
        hasher.update(numero.as_bytes());
        hex::encode(hasher.finalize())
    }

    fn main() -> std::io::Result<()> {
        let start_time = Instant::now();

        let numero_fijo = "491511";
        let batch_size = 10_000_000; 
        let total_limit = 1_000_000_000; 

        let mut batch_num = 1;
        let mut count = 0;

        // Bucle principal
        let mut iterador = 0..total_limit;

        loop {
            let filename = format!("hashes_batch_{}.csv", batch_num);

            // Usamos BufWriter para escribir en disco de forma eficiente (bufferizada)
            let file = File::create(&filename)?;
            let mut writer = BufWriter::new(file);

            writeln!(writer, "Número,Hash SHA-256")?; // Escribir cabecera

            for _ in 0..batch_size {
                // Obtenemos el siguiente número del iterador
                let num = match iterador.next() {
                    Some(n) => n,
                    None => break,
                };

                // Construcción del número (equivalente a str(num).zfill(9))
                // format! macro es segura y verifica tipos.
                let numero_cliente = format!("{:09}", num);
                let base = format!("{}{}", numero_fijo, numero_cliente);

                let digito_luhn = calcular_digito_luhn(&base);
                let numero_completo = format!("{}{}", base, digito_luhn);

                let hash_result = aplicar_sha256(&numero_completo);

                writeln!(writer, "{},{}", numero_completo, hash_result)?;
                count += 1;
            }

            // Asegurarse de que el buffer se vacíe a disco antes de cerrar el archivo
            writer.flush()?;

            let elapsed = start_time.elapsed();
            println!("Archivo {} completo. Total procesado: {}. Tiempo parcial: {:.2}s", 
                     batch_num, count, elapsed.as_secs_f64());

            batch_num += 1;

            // Si el iterador se agotó o alcanzamos el límite
            if count >= total_limit {
                break;
            }

            // Si el último batch fue parcial, salir para evitar un archivo vacío.
            if total_limit - (count - batch_size) < batch_size {
                 break;
            }
        }

        let duration = start_time.elapsed();
        println!("Proceso completo.");
        println!("Tiempo total de ejecución: {:.2} segundos", duration.as_secs_f64());

        Ok(())
    }

Python en procesamiento paralelo real

Ahora con la versión 3.14t se cuenta con procesamiento paralelo real, se muestra a continuación el código desarrollado.

import hashlib
import time
import os
import queue
import threading
from concurrent.futures import ThreadPoolExecutor, as_completed

# --- Funciones de lógica pura (CPU Bound) ---

def calcular_digito_luhn(numero_str):
    """Calcula el dígito verificador de Luhn."""
    digitos = [int(d) for d in numero_str][::-1]
    suma_total = 0
    for i, digito in enumerate(digitos):
        if i % 2 == 1:
            digito *= 2
            if digito > 9:
                digito -= 9
        suma_total += digito
    return (10 - (suma_total % 10)) % 10

def aplicar_sha256(numero):
    """Aplica el hash SHA-256 al número."""
    hash_obj = hashlib.sha256()
    hash_obj.update(numero.encode())
    return hash_obj.hexdigest()

# --- Función Worker para los hilos (Produce lista de listas) ---
def procesar_sub_lote(rango_numeros, numero_fijo):
    """Procesa un rango de números y devuelve los resultados."""
    resultados = []
    numero_fijo_str = str(numero_fijo)

    for num in rango_numeros:
        # Lógica de generación y hashing (CPU-bound)
        numero_cliente = str(num).zfill(9)
        base = numero_fijo_str + numero_cliente
        digito_luhn = calcular_digito_luhn(base)
        numero_completo = base + str(digito_luhn)
        hash_result = aplicar_sha256(numero_completo)

        # Guardamos en memoria temporal del hilo
        resultados.append([numero_completo, hash_result])

    return resultados

# --- Hilo Consumidor (Escritor en Disco usando F-Strings) ---
def file_writer_worker(write_queue, filename):
    """
    Hilo dedicado a escribir datos del CSV en disco.
    OPTIMIZACIÓN: Usa F-strings y buffering manual para I/O rápida.
    """
    try:
        # Usamos buffering=1024*1024 (1MB) para mejorar el rendimiento de I/O
        with open(filename, 'w', newline='', buffering=1024*1024) as file:

            # Escribir cabecera manualmente
            file.write('Número,Hash SHA-256\n')

            while True:
                # Obtener el chunk (lista de listas) de la cola.
                chunk = write_queue.get() 

                # Usamos None como valor centinela para terminar el hilo
                if chunk is None:
                    break

                # OPTIMIZACIÓN DE FORMATO: Usamos F-strings para la construcción rápida de la cadena.
                csv_lines = [f'{row[0]},{row[1]}' for row in chunk]
                data_string = '\n'.join(csv_lines) + '\n'

                # Escritura en disco del buffer gigante
                file.write(data_string)

                write_queue.task_done()

    except Exception as e:
        print(f"Error fatal en el escritor de archivos {filename}: {e}")

# --- Lógica Principal ---
def main():
    start_time = time.time()

    numero_fijo = 491511
    total_limit = 200_000_000
    batch_size_csv = 10_000_000 # Tamaño del archivo CSV

    # Tamaño del trabajo que le damos a cada hilo (Chunking)
    thread_chunk_size = 100_000 

    # Usamos todos los núcleos disponibles
    max_workers = os.cpu_count() 
    print(f"Ejecutando en Python {os.sys.version.split()[0]} (Verificar que sea 3.14t o similar)")
    print(f"Usando {max_workers} hilos para cálculo (Sin GIL).")
    print("Usando patrón Productor-Consumidor con I/O nativa optimizada.")

    count_global = 0
    batch_num = 1

    # Iteramos para crear los archivos CSV (Lotes grandes)
    for batch_start in range(0, total_limit, batch_size_csv):

        filename = f'hashes_batch_{batch_num}_py.csv'
        batch_end = min(batch_start + batch_size_csv, total_limit)

        print(f"Generando {filename} (Rango {batch_start} - {batch_end})...")
        batch_start_time = time.time()

        # 1. Creamos la cola de comunicación
        write_queue = queue.Queue()

        # 2. Iniciamos el HILO ESCRITOR (Consumidor)
        writer_thread = threading.Thread(
            target=file_writer_worker, 
            args=(write_queue, filename)
        )
        writer_thread.start()

        # --- CÁLCULO PARALELO (Productores) ---
        with ThreadPoolExecutor(max_workers=max_workers) as executor:
            futures = []

            # Dividimos el lote del CSV en tareas más pequeñas
            for chunk_start in range(batch_start, batch_end, thread_chunk_size):
                chunk_end_adjusted = min(chunk_start + thread_chunk_size, batch_end)
                rango = range(chunk_start, chunk_end_adjusted)

                # Enviamos la tarea al pool
                futures.append(executor.submit(procesar_sub_lote, rango, numero_fijo))

            # 3. Recogemos resultados FUERA DE ORDEN y los ENVIAMOS A LA COLA
            for future in as_completed(futures):
                try:
                    # El resultado es ahora una lista de listas
                    resultados_chunk = future.result() 
                    # Envía el chunk a la cola inmediatamente
                    write_queue.put(resultados_chunk)
                    count_global += len(resultados_chunk)
                except Exception as e:
                    print(f"Error en el futuro: {e}")

        # 4. Finalización del Lote: Señalar al escritor que termine
        write_queue.put(None) # Centinela de terminación
        writer_thread.join() # Esperar a que el escritor termine y cierre el archivo

        elapsed = time.time() - batch_start_time
        print(f"Archivo {batch_num} terminado en {elapsed:.2f}s. Velocidad: {batch_size_csv/elapsed:.0f} h/s")
        batch_num += 1

    end_time = time.time()
    print("Proceso completo.")
    print(f"Tiempo total: {end_time - start_time:.2f} segundos")

if __name__ == "__main__":
    main()

Rust en procesamiento paralelo

Aquí se detalla el código utilizado para habilitar el procesamiento paralelo en Rust, agregando las dependencias rayon y crossbeam_channel para tal fin.

use sha2::{Sha256, Digest};
use std::fs::File;
use std::io::{BufWriter, Write};
use std::time::Instant;
// Importamos el preludio de Rayon para tener acceso a las funciones paralelas
use rayon::prelude::*; 
// Usamos crossbeam-channel para canales de alto rendimiento
use crossbeam_channel::{unbounded, Receiver, Sender}; 

// --- CONFIGURACIÓN DE OPTIMIZACIÓN ---
// Tamaño de los lotes de datos que se envían por el canal.
// Esto reduce el overhead de la comunicación entre hilos.
const RAYON_CHUNK_SIZE: u64 = 100_000; 

// --- Funciones de lógica pura (CPU Bound) ---

fn calcular_digito_luhn(numero_str: &str) -> u32 {
    let mut suma_total = 0;
    for (i, c) in numero_str.chars().rev().enumerate() {
        let mut digito = c.to_digit(10).unwrap();
        if i % 2 == 1 {
            digito *= 2;
            if digito > 9 { digito -= 9; }
        }
        suma_total += digito;
    }
    (10 - (suma_total % 10)) % 10
}

fn aplicar_sha256(numero: &str) -> String {
    let mut hasher = Sha256::new();
    hasher.update(numero.as_bytes());
    hex::encode(hasher.finalize())
}

// --- Hilo Consumidor (Escritor en Disco) ---
// El canal ahora espera un vector de cadenas (Vec<String>)
fn writer_thread(rx: Receiver<Vec<String>>, filename: String) -> std::io::Result<()> {
    // Usamos un buffer grande (8MB)
    let file = File::create(&filename)?;
    let mut writer = BufWriter::with_capacity(8 * 1024 * 1024, file); 

    writeln!(writer, "Número,Hash SHA-256")?;

    // Consume el lote completo de resultados
    while let Ok(chunk) = rx.recv() {
        // Itera sobre el vector y escribe todas las líneas
        for linea in chunk {
            writeln!(writer, "{}", linea)?;
        }
    }

    // El BufWriter se vacía y cierra al salir del scope
    Ok(())
}


fn main() -> std::io::Result<()> {
    let start_time = Instant::now();

    let numero_fijo = "491511";
    let batch_size = 10_000_000;
    let total_limit: u64 = 200_000_000; 

    let mut batch_num = 1;

    // Iteramos por "chunks" (lotes) del tamaño de batch_size
    for start in (0..total_limit).step_by(batch_size as usize) {
        let end = std::cmp::min(start + batch_size as u64, total_limit);
        let filename = format!("hashes_batch_{}.csv", batch_num);

        println!("Procesando lote {} (Números {} a {})...", batch_num, start, end);
        let batch_start = Instant::now();

        // 1. Crear el canal MPSC (Multi-Productor, Single-Consumer)
        // El canal lleva ahora Vec<String>
        let (tx, rx): (Sender<Vec<String>>, Receiver<Vec<String>>) = unbounded();

        // 2. Iniciar el hilo de escritura (Consumidor I/O)
        let writer_handle = std::thread::spawn({
            let filename_cloned = filename.clone();
            move || writer_thread(rx, filename_cloned)
        });

        // --- INICIO DE LA SECCIÓN PARALELA (Productores CPU con Batching) ---

        // Creamos una lista de índices de inicio para los chunks de Rayon
        let chunk_starts: Vec<u64> = (start..end).step_by(RAYON_CHUNK_SIZE as usize).collect();

        // Clonamos 'tx' para que cada hilo productor pueda enviar el Vec<String>
        let tx_clone_for_rayon = tx.clone(); 

        // 3. Paralelizamos sobre los puntos de inicio de los chunks
        chunk_starts.into_par_iter()
            .for_each_with(tx_clone_for_rayon, |tx_cloned, chunk_start| {
                let chunk_end = std::cmp::min(chunk_start + RAYON_CHUNK_SIZE, end);

                // Creamos un vector para almacenar los resultados de este chunk
                let mut results: Vec<String> = Vec::with_capacity((chunk_end - chunk_start) as usize);

                // Calculamos secuencialmente dentro de este hilo para este chunk
                // Rayon garantiza que esta iteración es ejecutada por un solo hilo
                for num in chunk_start..chunk_end {
                    let numero_cliente = format!("{:09}", num);
                    let base = format!("{}{}", numero_fijo, numero_cliente);
                    let digito_luhn = calcular_digito_luhn(&base);
                    let numero_completo = format!("{}{}", base, digito_luhn);
                    let hash_result = aplicar_sha256(&numero_completo);

                    results.push(format!("{},{}", numero_completo, hash_result));
                }

                // Enviar el lote COMPLETO de resultados por el canal (bajo overhead)
                let _ = tx_cloned.send(results); 
            });

        // 4. Rayon ha terminado. Cerramos el transmisor principal para notificar al receptor.
        drop(tx); 

        // 5. Esperar a que el hilo escritor termine
        writer_handle.join().unwrap()?;

        // --- FIN DE LA SECCIÓN PARALELA Y ESCRITURA CONCURRENTE ---

        let elapsed = batch_start.elapsed();
        println!("Lote {} escrito. Tiempo: {:.2}s. Velocidad: {:.0} hashes/seg", 
                 batch_num, elapsed.as_secs_f64(), (batch_size as f64 / elapsed.as_secs_f64()));

        batch_num += 1;
    }

    let duration = start_time.elapsed();
    println!("Tiempo total de ejecución: {:.2} segundos", duration.as_secs_f64());

    Ok(())
}

DevSecOps: Modelo de madurez y alternativas de implementación

Dilver Huertas Guerrero — Mon, 27 Oct 2025 01:14:39 +0000

Introducción

Ante la necesidad de implementar prácticas seguras dentro de los flujos de desarrollo de software en las organizaciones, pueden surgir múltiples dudas: ¿Qué acciones concretas se deben llevar a cabo?, ¿Cómo se encuentra la organización frente a la adopción de prácticas seguras?, ¿Qué herramientas pueden ayudar a establecer el ecosistema de seguridad requerido? Estas y otras inquietudes pueden surgir, y a pesar de que la respuesta es especifica al contexto de cada organización, es conveniente adoptar las lecciones aprendidas que entrega la industria en la definición del mapa de ruta a seguir.

A lo largo de este post se busca dar respuesta a algunas inquietudes en el ámbito de DevSecOps, especialmente cuando una organización inicia en el camino de adopción. Se explora un modelo de madurez haciendo énfasis en las acciones iniciales que deberían llevarse a cabo y algunas alternativas de implementación a nivel técnico.

Si el término "DevSecOps" es desconocido para usted y/o su organización, le recomiendo empezar por consultar "The DevOps Guide", el cual encontrará al final en la sección de referencias.

Modelo de madurez

El DevSecOps Maturity Model (DSOMM) es un marco de referencia que permite evaluar y mejorar el nivel de madurez en la integración de prácticas de seguridad dentro del ciclo de vida DevOps, tiene como propósito ayudar a las organizaciones a incorporar la seguridad desde las etapas iniciales del desarrollo, mediante la automatización de controles, la gestión de vulnerabilidades, la revisión continua de código y la colaboración entre equipos de desarrollo, operaciones y seguridad. Este marco estructura la madurez en distintos niveles y áreas temáticas, facilitando la identificación de brechas y la definición de un plan de mejora progresivo hacia un entorno DevSecOps más seguro, ágil y sostenible.

DSOMM fue creado por miembros de la comunidad de seguridad y desarrollo de software con el propósito de establecer una guía práctica para integrar la seguridad en entornos DevOps de forma estructurada y medible. Su origen se remonta a iniciativas colaborativas impulsadas por expertos de la Open Web Application Security Project (OWASP) y profesionales independientes del ámbito de la ingeniería de software, quienes buscaban un modelo más claro para evaluar la madurez de las prácticas de seguridad automatizadas dentro de los flujos de entrega continua. Desde su publicación inicial, el DSOMM ha evolucionado gracias al aporte colectivo de la comunidad, consolidándose como una herramienta abierta y adaptable utilizada por organizaciones de distintos sectores.

Adicionalmente, cuenta con una plataforma interactiva que permite a las organizaciones evaluar de forma estructurada su nivel de madurez en la integración de prácticas de seguridad, mediante un cuestionario que cubre distintas áreas temáticas como: gestión de vulnerabilidades, automatización de pruebas, control de acceso, monitoreo y respuesta; asignando puntuaciones que reflejan el grado de implementación alcanzado. Su uso es sencillo y colaborativo, ya que permite registrar avances, comparar resultados entre equipos y visualizar gráficamente el progreso hacia niveles superiores de madurez. Además, al ser una herramienta abierta y actualizable, facilita adaptar los criterios de evaluación a las necesidades específicas de cada organización (enlace de acceso en la sección de Referencias).

Actividades a realizar para alcanzar el nivel 1 de DSOMM

Con el fin de detallar las primeras actividades que se deben validar o planificar en una organización para la adopción de prácticas de DevSecOps, se mencionan aquellas correspondientes al nivel 1 - Entendimiento básico de prácticas de seguridad:

Contar con un proceso de compilación definido automatizando pasos
Definir un proceso de despliegue
Contar con un inventario de componentes en produccción
Contar con una politica de parcheo
Contar con parcheo automatizado
Llevar a cabo modelamiento de amenazas durante el sprint planning
Comunicar los objetivos de seguridad de la organización (nivel 2)
Concientizar en seguridad a todo el personal involucrado en el desarrollo de software
Proporcionar consultoría interna en seguridad a demanda
Definir prácticas de continuidad de negocio y recuperación de desastres para componentes críticos
Implementar el 50% de las recomendaciones de marcos de referencia como OWASP ASVS - Nivel 1 (Aplicaciones web) ó OWASP MASVS (Aplicaciones móviles)
Sanitizar entradas y codificar salidas de acuerdo con el contexto
Parametrizar consultas y procedimientos almacenados
Implementar el versionamiento de artefactos
Implementar política de gestión de código fuente (nivel 2)
Implementar MFA para cuentas privilegiadas
Implementar autenticación en todos los sistemas internos
Encriptar todo el tráfico en tránsito fuera de la organización
Contar con un sistema centralizado de logs
Contar con un sistema de monitoreo y métricas básicas
Contar con umbrales establecidos de alarma para el presupuesto - nube
Recopilar métricas del sistema, especialmente de cuellos de botella
Documentar y clasificar los hallazgos de pruebas de seguridad
Tratar las vulnerabilidades con severidad alta o superior
Implementar escaneo de secretos
Mantener la intensidad por defecto de las herramientas de pruebas

El detalle de las actividades listadas, los riesgos asociados, las métricas para medir su cumplimiento, entre otros datos adicionales, puede consultarlos en el sitio oficial de DSOMM, del cual encontrará el enlace en la sección de referencias.

Alternativas de implementación con GitHub Actions

A lo largo de este post se presentan tres alternativas de implementación de prácticas de DevSecOps utilizando GitHub Actions. Esta es una herramienta de automatización integrada en GitHub que permite crear flujos de trabajo personalizados para compilar, probar y desplegar código de forma continua dentro del mismo entorno del repositorio; funciona mediante archivos de configuración en formato YAML que definen eventos, condiciones y acciones a ejecutar, facilitando la implementación de flujos de integración y despliegue continuo (CI/CD) sin necesidad de servidores externos. Su flexibilidad permite integrar fácilmente herramientas de análisis de seguridad, pruebas unitarias, despliegues automatizados y auditorías de cumplimiento, lo que la convierte en una solución completa para equipos que adoptan prácticas DevSecOps. Además, su integración nativa con GitHub y su amplio catálogo de acciones predefinidas en el marketplace la hacen altamente escalable y eficiente para proyectos de cualquier tamaño, la documentación oficial la puede consultar en el enlace al final que encontrará en la sección de referencias.

Es necesario mencionar que esta no es la única alternativa para la implementación de CI/CD, otra alternativa popular puede ser Jenkins, e incluso los principales proveedores de nube (AWS, GCP, Microsoft) disponen de otras soluciones que podría explorar. Para ello puede consultar la sección de proyectos de "The DevSec Blueprint", el enlace al final en la sección de referencias.

Alternativa 1: GitHub Actions con GitHub Advanced Security (GHAS)

GHAS es una solución integrada en GitHub que ofrece capacidades como el escaneo de código estático (CodeQL), la detección de secretos expuestos, y el análisis de dependencias para descubrir riesgos en bibliotecas de terceros, todo ello de forma automatizada y continua. Se integra de manera nativa con los flujos de trabajo de GitHub Actions, lo que facilita incorporar controles de seguridad sin interrumpir la productividad del desarrollo, proporcionando reportes centralizados, métricas de riesgo y funciones de gestión de políticas, permitiendo a los equipos de DevSecOps mantener una supervisión proactiva y mejorar su postura de seguridad desde el propio repositorio.

Debe tener en cuenta que GHAS debe estar acompañado de GitHub Enterprise Cloud (GHEC), y se ofrece en dos productos que pueden ser licenciados por aparte, y cuyo valor depende del número de colaboradores activos al mes:

GitHub Secret Protection
GitHub Code Security

Las características clave de GHAS son:

Secret scanning: Identifica y ayuda a prevenir la exposición accidental de información confidencial a través de la búsqueda de patrones predefinidos y personalizados
Code scanning: Analiza el código fuente en busca de vulnerabilidades de seguridad y errores de codificación, emplea técnicas de análisis estático
Dependabot: Herramienta automatizada de gestión de dependencias para actualizarlas a sus últimas versiones seguras

A partir de GHAS se tiene cubierto el análisis estático de código (SAST), el análisis de componentes de software (SCA) y la gestión de secretos. Una de sus ventajas es que las alertas de seguridad aparecen directamente en el Pull Request, facilitando una adopción rápida por parte de los desarrolladores. Adicionalmente, al ser una solución SaaS nativa de GitHub, la organización que lo adopte no tiene que preocuparse por el mantenimiento, actualización o escalado de las herramientas.

Sin embargo, entre sus limitaciones se encuentra que carece de capacidades nativas para análisis dinámico de código (DAST) y escaneo de contenedores. Por lo cual, si bien es un buen paso en la adopción de prácticas de DevSecOps, se debe ser consciente que esas carencias deberán cubrirse con herramientas de terceros.

Alternativa 2: GitHub Actions con herramientas SaaS

La implementación de un enfoque DevSecOps mediante GitHub Actions y herramientas SaaS permite integrar controles de seguridad automatizados en todas las fases del ciclo de desarrollo, ejecutando una supervisión continua sin afectar la agilidad del proceso. En este esquema, el análisis SAST se ejecuta con SonarCloud, evaluando la calidad y seguridad del código fuente; el análisis de componentes y dependencias SCA se gestiona con Snyk, detectando vulnerabilidades en bibliotecas externas; las pruebas dinámicas DAST se realizan con StackHawk, que simula ataques en entornos de ejecución para identificar fallos explotables; la exposición de secretos se controla mediante GitGuardian, que detecta credenciales y claves filtradas en repositorios; y finalmente, la seguridad de contenedores se refuerza también con Snyk Container, asegurando imágenes y configuraciones. En conjunto, estas herramientas coordinadas desde flujos de trabajo en GitHub Actions consolidan una arquitectura DevSecOps madura, automatizada y orientada a la prevención.

Para esta alternativa deben considerarse sus costos de licenciamiento:

SonarCloud: Desde 32 USD/mes (para 50k a 100k líneas de código)
Snyk: 25 USD/mes por desarrollador (hasta 10) paquetes más grandes hay que consultar con ventas
StackHack: 49 USD/mes por desarrollador (mínimo 20)
GitGuardian: No se entrega información, con costo para organizaciones de más de 25 desarrolladores

Entre sus ventajas destaca una mejor cobertura de seguridad, ya que permite seleccionar las soluciones líderes del mercado para cada tipo de análisis, alcanzando una detección más profunda y precisa de vulnerabilidades en código, dependencias, contenedores y configuraciones. Además, brinda una gestión centralizada y eficiente, dado que cada servicio SaaS cuenta con paneles avanzados para manejar falsos positivos, priorizar riesgos e incluso generar informes de cumplimiento normativo de manera automatizada. Sin embargo, no está libre de limitaciones: alto costo de licenciamiento, contratación simultánea de múltiples proveedores, la soberanía de los datos, pues tanto el código fuente como los resultados de los análisis se procesan y almacenan fuera de la infraestructura de la organización, lo que puede generar preocupaciones en torno a la privacidad y el control de la información.

Alternativa 3: GitHub Actions con herramientas On-Premise

La implementación de un entorno DevSecOps utilizando GitHub Actions con herramientas On-Premise permite mantener un control total sobre los datos y la infraestructura, integrando la seguridad de manera automatizada en el ciclo de vida del software sin depender de servicios externos. En esta arquitectura, el análisis SAST se realiza con Semgrep CE, una solución ligera y altamente personalizable para identificar vulnerabilidades en el código fuente; el análisis SCA combina Trivy y OWASP Dependency-Track, que detectan y gestionan vulnerabilidades en dependencias de terceros; las pruebas dinámicas DAST se ejecutan con OWASP ZAP, herramienta que simula ataques en entornos de prueba para descubrir fallos explotables; la detección de secretos expuestos se efectúa con TruffleHog, capaz de rastrear credenciales o claves sensibles en el historial del repositorio; y la seguridad de contenedores también se refuerza con Trivy, verificando imágenes y configuraciones antes del despliegue. Esta integración orquestada desde GitHub Actions ofrece una solución de seguridad integral, flexible y orientada al cumplimiento, con la ventaja de preservar la confidencialidad y soberanía de la información.

Adicionalmente, la eliminación de los costos directos de licenciamiento, ya que se emplean herramientas de código abierto que no requieren suscripciones comerciales, ofrece la soberanía de los datos, puesto que tanto el código fuente como los resultados de los análisis se procesan y almacenan dentro de la propia infraestructura de la organización, mitigando riesgos asociados al acceso por terceros o a la transferencia de información sensible a entornos externos. Finalmente, proporciona una alta capacidad de personalización, especialmente con soluciones como Semgrep CE, que permite desarrollar reglas SAST adaptadas a la lógica de negocio y a los frameworks internos, fortaleciendo la detección de vulnerabilidades específicas del contexto operativo de la organización.

Entre las limitaciones de esta alternativa deben considerarse los costos de ingeniería, ya que el equipo interno asume la responsabilidad de instalar, alojar, mantener, parchear y escalar todas las herramientas, lo que incrementa la carga técnica y administrativa. Además, la integración eficiente de los distintos sistemas requiere un orquestador de seguridad intermedio, como OWASP DefectDojo, encargado de centralizar los resultados, deduplicar hallazgos y gestionar su ciclo de vida, aunque esto añade otra capa de infraestructura compleja que también debe mantenerse. Por último, en ausencia de dicho orquestador, la gestión de hallazgos se vuelve manual y descentralizada, dificultando la priorización de vulnerabilidades y la reducción de falsos positivos, lo que puede afectar la eficiencia del proceso de aseguramiento continuo.

Conclusiones

DSOMM representa una guía práctica y abierta para que cualquier organización, sin importar su tamaño o sector, evalúe y fortalezca la integración de la seguridad dentro de sus procesos de desarrollo y operación. Su enfoque permite avanzar de manera estructurada desde un nivel básico de entendimiento hasta una cultura plenamente madura de DevSecOps, donde la seguridad se incorpora desde la planificación hasta el despliegue y la operación continua. Implementar las primeras acciones del modelo (automatizar compilaciones, definir procesos de despliegue, establecer políticas de parcheo, realizar modelamiento de amenazas y concientizar al personal) constituye un punto de partida sólido para transitar hacia prácticas más seguras, colaborativas y sostenibles. Además, no se limita a ofrecer un marco de evaluación, sino también una hoja de ruta para transformar la seguridad en un valor compartido y medible en el desarrollo de software.

Por último, las alternativas mencionadas utilizando GitHub Actions, ya sea con herramientas SaaS, On-Premise u opciones nativas de GitHub, no deben entenderse como enfoques excluyentes, sino como componentes complementarios dentro de una estrategia integral de seguridad. Cada organización puede combinar estas soluciones según su contexto, presupuesto, nivel de madurez y requisitos de cumplimiento, logrando así un equilibrio entre automatización, soberanía de datos y profundidad analítica. Integrar servicios propios de GitHub con herramientas abiertas como Semgrep, OWASP ZAP o Trivy, junto con soluciones SaaS especializadas como Snyk, SonarCloud o GitGuardian, permite construir un ecosistema DevSecOps flexible, escalable y alineado con las mejores prácticas del DSOMM, fortaleciendo la detección temprana de vulnerabilidades y promoviendo una cultura de seguridad continua en todo el ciclo de vida del software.

Referencias

The DevOps Guide
DSOMM
Documentación de GitHub Actions
Projects - The DevSec Blueprint

[Boost]

Dilver Huertas Guerrero — Sat, 05 Apr 2025 14:58:27 +0000

Dilver Huertas Guerrero

Apr 5 '25

Degradación del protocolo de comunicación en IoT mediante un ataque de hombre en el medio (MitM)

#seguridad #iot #mqtt #cybersecurity

Comments

5 min read

Degradación del protocolo de comunicación en IoT mediante un ataque de hombre en el medio (MitM)

Dilver Huertas Guerrero — Sat, 05 Apr 2025 14:54:27 +0000

Introducción

A lo largo de este post se utiliza Eclipse Mosquitto para simular el broker, cliente y suscriptor MQTT; se establece un entorno controlado para demostrar como realizar un ataque de hombre en el medio (Man-in-the-Middle MitM) utilizando Kali Linux y se muestra como causar una degradación del protocolo de comunicación utilizado por un dispositivo IoT inseguro (simulado).

Un poco de teoría

La degradación de protocolo se aprovecha de una mala práctica en ciertos sistemas IoT, en los cuales se permite que el cliente MQTT haga un cambio automático a una conexión insegura (sin TLS), si falla la conexión segura (TLS). El atacante, ubicado entre el cliente y el broker, interrumpe únicamente las conexiones seguras, obligando al cliente a comunicarse sin cifrado.

Este tipo de ataque se ejecuta de la siguiente manera:

El cliente MQTT intenta conectarse al broker por el puerto seguro (TLS).
Un atacante lanza un ataque MitM a partir de envenenamiento ARP, reenvío de IP y reglas iptables para bloquear tráfico seguro.
La conexión segura falla debido al bloqueo silencioso.
El cliente MQTT activa el cambio automático a una conexión sin cifrado.
El atacante intercepta el mensaje MQTT en texto claro.

En este punto, es conveniente preguntar: ¿Qué impacto tiene en la seguridad?. Respecto a la confidencialidad, el atacante puede ver en texto claro el contenido del mensaje publicado y el nombre del tópico MQTT, en cuanto a integridad el atacante puede inyectar mensajes falsos al broker si logra autenticarse sin TLS, y sobre la disponibilidad el dispositivo IoT, este puede actuar basado en mensajes falsificados, poniendo en riesgo el proceso que este ejecutando.

Práctica

Configuración inicial

Para la práctica se utilizaron 3 máquinas virtualizadas sobre VirtualBox, configuradas en una red interna con el modo promiscuo activado. A estas máquinas se les asigno el direccionamiento de red mostrado en la figura:

Se procede a instalar mosquitto y openssl en Alpine, en el cliente solo es necesario instalar mosquitto-clients:

Para habilitar la conexión TLS, se requiere un certificado, el cual se genera utilizando openssl y posteriormente se envía utilizando ssh a la máquina cliente:

Para establecer la conexión MQTT, se debe configurar en el archivo mosquitto.conf, en el cual se habilita el puerto 1883 sin TLS y el puerto 8883 con TLS:

Del lado del cliente, se simula un dispositivo IoT que tiene habilitada la conexión insegura en caso de fallar la conexión segura, utilizando un script en bash, estableciendo un tiempo de espera de 3 segundos antes de intentar otra opción:

Ejecución del escenario

Se inicia la ejecución del broker MQTT, observando que se encuentran habilitados ambos puertos y que está aceptando conexiones:

Del lado del cliente, se observa el envío de mensajes vía TLS

Y el suscriptor (que se encuentra en la misma máquina cliente, en una segunda terminal) recibe el mensaje de la manera esperada:

En wireshark, se observa que los datos van por el protocolo TLSv1.3:

Igualmente se puede observar que los datos de la aplicación van encriptados:

Ejecución del ataque MitM

Desde kali linux, se procede a habilitar el reenvío de paquetes y las reglas en iptables:

El primer comando permite que Kali actúe como un router, reenviando paquetes entre el cliente MQTT y el broker, el segundo asegura que no haya reglas previas que interfieran con el ataque o con el reenvío de tráfico, el tercero agrega una regla NAT que modifica la dirección IP de origen de los paquetes salientes por la interfaz eth0, permitiendo que las respuestas del broker MQTT regresen a través de Kali, esto se requiere para mantener la ilusión de una conexión directa, ocultando la presencia del atacante. Los últimos 2 comandos permiten que Kali reenvíe paquetes desde el cliente MQTT hacia el broker, y del broker hacia el cliente.

Finalmente, se debe realizar un envenenamiento de ARP, que consiste en suplantar el dispositivo en cuestión falsificando las respuestas ARP, haciendole creer al objetivo que se está comunicando con el dispositivo suplantado. En 2 terminales, se ejecuta el ataque utilizando la herramienta arpspoof tanto para el broker como para el cliente, habilitando de esa manera un ataque MitM:

Hasta este punto se ha ejecutado el ataque MitM y todo el tráfico pasa por KaliLinux, al ejecutar el script debe seguir viendo en la consola del cliente: "Mensaje enviado con TLS".

Ejecución del ataque de degradación de protocolo

Para ejecutar el ataque se debe incluir una regla que agrega un bloqueo específico a 8883 (TLS) antes de las reglas de ACCEPT (-I FORWARD 1 inserta la regla en la primera posición), obligando de esta manera a que el dispositivo cambie automáticamente hacia la conexión insegura.

Esto hace que, al ejecutar el script, y pasados los 3 segundos definidos sin poder realizar la conexión por TLS, se ejecute sin TLS:

En wireshark se puede observar que el protocolo utilizado ahora es MQTT, y en texto claro se observa tanto el tópico como el mensaje:

Mostrando que se ejecutó un ataque de degradación de protocolo, a través de un ataque MitM.

Conclusiones

El ataque de degradación de protocolo de comunicación demuestra que permitir el cambio automático a protocolos IoT sin cifrado debilita toda la arquitectura de seguridad, lo cual es usualmente permitido para facilitar la usabilidad de un producto, sin embargo, se recomienda forzar el uso exclusivo de TLS, validar el certificado del broker correctamente, utilizar autenticación mutua con certificados y monitorizar redes IoT para detectar actividades ARP sospechosas.

Instalar BeEF en Kali Linux 2024

Dilver Huertas Guerrero — Sat, 05 Oct 2024 22:41:53 +0000

The Browser Exploitation Framework

Instalación de Ruby

Desinstalar la versión de ruby actual
sudo apt remove ruby
Instalar ruby con rbenv

sudo apt update
sudo apt install -y build-essential libssl-dev libreadline-dev zlib1g-dev git
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(rbenv init - zsh)"' >> ~/.zshrc
source ~/.zshrc
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
rbenv install 3.0.3
rbenv global 3.0.3

Asegurarse que la versión correcta está en uso
ruby -v

Instalación de Browser Exploitation Framework (BeEF)

Clonar el repositorio
git clone https://github.com/beefproject/beef
Una vez clonado el repositorio, realizar los siguientes cambios en los archivos ubicados en la carpeta principal

En el archivo install, modificar la línea 107: Cambiar libncurses5-dev por libncurses-dev
En el archivo config.yaml, modificar las líneas 20 y 21 con el usuario y contraseña que quieran.

Desde la consola ejecutar el comando:
./install
Si todo se ha instalado correctamente, al final se genera el siguiente mensaje:

Para iniciar BeEF ejecutar el comando:
./beef
Pueden acceder a traves de la URL http://127.0.0.1:3000/ui/panel

Detectar, analizar y explotar vulnerabilidades utilizando herramientas de código abierto: Medición de desempeño y resultados

Dilver Huertas Guerrero — Fri, 20 Sep 2024 20:37:05 +0000

Introducción

Se dispuso una máquina virtual con Metasploitable (versión 3), la cual está diseñada para pruebas de intrusión y testing (pentest) con varias aplicaciones listas para ser atacadas. Adicionalmente, una máquina virtual con Kali Linux, con la cual se ejecutó la herramienta de escaneo de red y puertos Nmap y las herramientas de escaneo de vulnerabilidades Nessus y Greenbone CE (antes conocido como OpenVAS). A partir de este análisis se identificaron vulnerabilidades que fueron explotadas utilizando Metasploit. Se busca mostrar el proceso de detección, análisis y explotación de vulnerabilidades, así como las herramientas y técnicas de identificación de estas.

También se monitoreo la carga en la máquina victima (Metasploitable) al lanzar el escaneo de vulnerabilidades con Nessus y con GreenboneCE, y se midió el rendimiento de la red (ancho de banda y la latencia) utilizando IPERF, con el fin de determinar los escenarios de aplicación, dado que se está realizando un escaneo activo, que en entornos reales generaría alertas en los sistemas de protección.

Desarrollo

Se dispuso del escenario mostrado en la Figura 1. Ambas máquinas tienen en su configuración de red el modo Host-only adapter habilitado, de esta manera pueden comunicarse entre sí.

Figura 1. Escenario de laboratorio. Fuente: propia.

Se procede a identificar las IPs asignada a cada una de las máquinas, en la figura 2 para Kali Linux, con IP 192.168.56.4 y en la figura 3 para Metasplotable 3, con IP 192.168.56.3.

Figura 2. Ejecución de ifconfig. Fuente: propia.

Figura 3. Ejecución de ipconfig. Fuente: propia.

Escaneo de red y puertos

Se procede a identificar los servicios disponibles en Metasploitable utilizando Nmap, los cuales se muestran en la figura 4.

Figura 4. Análisis de servicios con nmap. Fuente: propia.

Se identifica que el servicio de ping esta deshabilitado, como se muestra en la figura 5. Por ellos, se procede a generar una consulta más detallada con Nmap.

Figura 5. Servicio ping deshabilitado. Fuente: propia.

La consulta detallada nmap -Pn -A -sV 192.168.56.3, indica que el sistema operativo es Windows, además de lo mostrado en la figura 6.

Figura 6. Escaneo detallado con Nmap. Fuente: propia.

El escaneo realizado con Nmap muestra los siguientes puertos abiertos y servicios detectados:

Puerto 21/tcp (FTP)
- Servicio: Microsoft FTPD
- Estado: Abierto
- Detalles adicionales: Windows_NT
Puerto 22/tcp (SSH)
- Servicio: OpenSSH 7.1
- Estado: Abierto
- Detalles adicionales: Muestra la llave pública RSA-2048 y ECDSA-521. OpenSSH utiliza el protocolo 2.0.
Puerto 80/tcp (HTTP)
- Servicio: Microsoft IIS httpd 7.5
- Estado: Abierto
- Detalles adicionales: Identifica métodos potencialmente peligrosos como TRACE, lo que podría permitir ataques de tipo Cross-Site Tracing (XST). No tiene http-title.
Puerto 4848/tcp (HTTPS - Administración)
- Servicio: Oracle GlassFish Application Server (versión 4.0)
- Estado: Abierto
- Detalles adicionales: Certificado SSL no válido desde 2023-05-13. El http-title dice “Login”. Problema reportado con el análisis XML de la ruta ‘/evox/about’.
Puerto 8080/tcp (HTTP)
- Servicio: Sun GlassFish Open Source Edition 4.0
- Estado: Abierto
- Detalles adicionales: El servidor GlassFish está ejecutándose y podría estar exponiendo métodos HTTP peligrosos, como PUT, DELETE y TRACE, lo que podría permitir la modificación de recursos en el servidor.
Puerto 8383/tcp (HTTP - Apache)
- Servicio: Apache httpd
- Estado: Abierto
Puerto 9200/tcp (HTTP)
- Servicio: Es muy probable que sea Elasticsearch, ya que este servicio utiliza frecuentemente el puerto 9200 para su API REST.
- Estado: Abierto
- Detalles adicionales: El servidor responde con 400 Bad Request cuando se intenta acceder a rutas como ‘/nice ports, Trinity.txt.bak’. El servidor responde con un JSON que contiene detalles de un servicio con nombre: "Devil Hunter Gabriel".
Puertos 49153/tcp y 49154/tcp
- Servicio: Microsoft Windows RPC
- Estado: abierto
Puerto 9200/tcp (HTTP)
- Servicio: Desconocido

Nmap también tiene la capacidad de generar informes detallados en formato XML, como se muestra en la figura 7.

Figura 7. Reporte generado con Nmap. Fuente: propia.

Medición de desempeño en el escaneo de vulnerabilidades

Para realizar la medición del desempeño de las herramientas Nessus y GCE, se utiliza Performance Monitor[1] e iperf3[2]. Primero, se procede a realizar una prueba del funcionamiento de iperf3, como se muestra en la figura 8.

Figura 8. Prueba del funcionamiento de iperf3. Fuente: propia.

Adicionalmente, se crea en Metasploitable un recopilador de datos personalizado con nombre UsoRecursosEscaneo, como se observa en la figura 9.

Figura 9. Recopilador de datos personalizado utilizando Performance Monitor. Fuente: propia.

Se configura el escaneo avanzado con Nessus, como se observa en la figura 10.

Figura 10. Escaneo avanzado de vulnerabilidades con Nessus. Fuente: propia.

Posteriormente, se ejecuta el escenario de análisis de vulnerabilidades y medición de desempeño para Nessus, como se muestra a continuación.

Figura 11. Escenario de análisis con Nessus. Fuente: propia.

Se muestran los resultados del escaneo en la figura 12.

Figura 12. Resultado del escaneo realizado con Nessus. Fuente: propia.

Se configura el escaneo avanzado (full and fast) con Greenbone CE, como se muestra en la figura 13.

Figura 13. Configuración del escaneo avanzado con GCE. Fuente: propia.

Se ejecuta el monitoreo de recursos y el escaneo de vulnerabilidades con GCE, como se muestra en la figura 14.

Figura 14. Escaneo avanzado con GCE y monitoreo.

Comparación de desempeño entre GCE y Nessus

GCE parece tener una mayor utilización de los recursos del sistema (procesador, memoria, y disco), con más fallos de página, lecturas/escrituras de páginas, y transferencias de disco; lo cual sugiere que está manejando una carga de trabajo más intensa o menos eficiente. Por otro lado, Nessus presenta más interrupciones y cambios de contexto, lo que sugiere que está manejando más eventos de hardware o procesos simultáneos, pero con menor uso general de memoria y disco.

A continuación, en la tabla 1, se muestra un resumen de las vulnerabilidades encontradas y el tiempo de ejecución, en esta última se observa que GCE toma más del doble de tiempo de ejecución que Nessus.

Tabla 1. Resumen de desempeño entre GCE y Nessus.

Variable	Nessus	GCE
Vulnerabilidades reportadas	52 (15 críticas, 19 altas, 16 medias, 2 bajas)	55 (25 altas, 27 medias, 3 bajas)
Tiempo	25 minutos 21 segundos	57 minutos 16 segundos

Nota: La clasificación que realiza Nessus y GCE difiere en sus niveles, por lo cual no es comparable directamente.

En las figuras 15 y 16 se observa el desempeño de ambas herramientas de acuerdo con la información obtenida por medio de Performance Monitor.

Figura 15. Métricas de desempeño de uso de memoria y procesador. Fuente: propia.

Figura 16. Métricas de paginamiento y uso de disco. Fuente: propia.

A continuación, se presenta un resumen de la comparación en rendimiento:

Memoria Disponible
- GCE: Promedio de 196.88 MB
- Nessus: Promedio de 191.94 MB
- Diferencia: GCE tiene una mayor media de memoria disponible, lo que podría indicar una mayor disponibilidad de recursos de memoria.
Utilización del Procesador
- GCE: 40.98%
- Nessus: 38.66%
- Diferencia: GCE muestra un uso del procesador más alto en promedio, lo que podría sugerir que está manejando una carga de trabajo más alta.
Cambios de Contexto por Segundo
- GCE: 2873.92 cambios/seg
- Nessus: 3132.20 cambios/seg
- Diferencia: Nessus tiene una tasa mayor de cambios de contexto, lo que puede indicar una mayor carga de trabajo multitarea en este entorno.
Longitud de la Cola del Procesador
- GCE: 0.78 procesos en cola
- Nessus: 0.41 procesos en cola
- Diferencia: GCE tiene una cola de procesos más larga, lo que puede indicar que el procesador estuvo más ocupado o que hubo más procesos esperando para ser ejecutados.
Page Faults/sec
- GCE: Relativamente más alto en algunos puntos, lo que puede indicar más intentos de acceder a páginas de memoria que no estaban en la memoria física.
- Nessus: Mostró menos picos de fallos de página, lo que podría indicar una mejor gestión de la memoria.
Pages/sec
- GCE: Muestra más actividad de lectura/escritura de páginas.
- Nessus: Menor cantidad de actividad en comparación con GCE.
Pool Paged Bytes
- GCE: Muestra mayor uso de bytes paginados, lo que indica más datos en memoria virtual.
- Nessus: Menor uso de bytes paginados, lo que puede indicar que menos datos se enviaron al archivo de página.
Disk Transfers/sec
- GCE: Mayor cantidad de transferencias de disco por segundo, lo que indica más actividad en el subsistema de almacenamiento.
- Nessus: Menos transferencias de disco, lo que podría indicar una menor carga de trabajo en el almacenamiento.
Interrupts/sec:
- GCE: Menor cantidad de interrupciones por segundo.
- Nessus: Mayor cantidad de interrupciones por segundo, lo que puede sugerir una mayor interacción con dispositivos de hardware o una mayor carga en la gestión de interrupciones.

También se analizó el impacto en la red utilizando iperf3, como se muestra en la figura 17.

Figura 17. Transferencia y tasa de bits utilizando iperf3. Fuente: propia.

A continuación, se presenta un análisis comparativo de los resultados obtenidos al evaluar el desempeño de GCE y Nessus, utilizando iperf3, dónde se evalúa tanto la transferencia de datos (MBytes) como la tasa de bits (Mbits/seg):

Transferencia de Datos (MBytes)
- GCE: La transferencia de datos en el caso de iperf3GCE oscila entre 10 y 665 MBytes. Se observan fluctuaciones significativas a lo largo del tiempo, con una caída abrupta alrededor de los 10 MBytes en un punto, lo que sugiere posibles interrupciones o inestabilidades en la conexión.
- Nessus: En comparación, la transferencia de datos en iperf3Nessus es más estable, con un rango de 450 a 704 MBytes. Aunque hay variaciones, son más suaves y no se presentan caídas tan dramáticas como en el caso de GCE.
Tasa de Bits (Mbits/seg)
- GCE: La tasa de bits varía considerablemente, con un máximo de 665 Mbits/seg, pero también con caídas abruptas hasta los 10 Mbits/seg. Estas caídas pueden indicar problemas temporales en la red, como congestión, interferencias o limitaciones del hardware que afectan la estabilidad del enlace.
- Nessus: Por otro lado, la tasa de bits en Nessus es mucho más constante, con valores en su mayoría por encima de los 450 Mbits/seg y un máximo de 742 Mbits/seg. Aunque también muestra algunas variaciones, la estabilidad general es mucho mayor, con una mejor capacidad para mantener tasas de bits más elevadas durante el tiempo de la prueba.
Estabilidad y Rendimiento
- GCE muestra una inestabilidad marcada, con varias caídas importantes tanto en la transferencia de datos como en la tasa de bits. Esto podría deberse a condiciones fluctuantes de la red o problemas específicos de la infraestructura que se usó para la prueba.
- Nessus, por el contrario, exhibe un comportamiento mucho más estable. Aunque tiene algunas fluctuaciones, las caídas son mucho menos severas y los valores se mantienen dentro de un rango más consistente, lo que indica un mejor rendimiento general.

Nessus presenta una red más confiable y estable con mejor capacidad para mantener altos niveles de transferencia y tasa de bits a lo largo del tiempo; mientras que GCE muestra variaciones más drásticas, lo que puede sugerir problemas de estabilidad o congestión en la red, con importantes caídas que afectaron el rendimiento general.

Si bien el desempeño de las herramientas es importante, también se debe tener en cuenta los resultados en cuanto las vulnerabilidades detectadas, dónde se observa que GCE obtiene datos más detallados e incluso encuentra credenciales para servicios abiertos, a diferencia de Nessus. En la tabla 2 se presenta un resumen.

Tabla 2. Cantidad de vulnerabilidades encontradas por tipo de tecnología.

Tecnología	Nessus	GCE
Apache	24
Apache Axis2		2
Apache Tomcat	15	16
Elasticsearch		11
FTP Server		2
Java JMX		1
Microsoft Windows LAN Manager SNMP	2
OpenSSH		6
Oracle Glassfish Server		1
SNMP Agent	1	1
SSH Server	1	2
SSL Certificate	4	4
SSL Cipher Suite	2	2
HTTP	3	1
SSL Service		5
TCP Timestamp		1

Nota. Esta clasificación fue realizada manualmente a partir de los reportes entregados por cada una de las herramientas.

De acuerdo con el análisis de las herramientas, el servicio Apache Tomcat es probablemente el que tiene la posibilidad de ser explotado, dado que ambas sugieren vulnerabilidades, revisando los informes se observa que fue detectado en el puerto 8282/tcp, sin embargo, Nmap no detecto nada expuesto en ese puerto, sino en el 8383/tcp HTTP Apache.

En la siguiente sección se procede a explotar las vulnerabilidades detectadas para Apache, utilizando Metasploit y los resultados generados por el escaneo de vulnerabilidades.

Explotación de vulnerabilidades utilizando Metasploit

En el puerto 8282 está expuesto el servicio Apache Tomcat 8.0.33, como se observa en la figura 18.

Figura 18. Servicio apache tomcat. Fuente:propia

Se procede a realizar un escaneo de directorios utilizando metasploit, como se observa en la figura 19, encontrando 4 directorios disponibles.

Figura 19. Escaneo de directorios con metasploit. Fuente: propia.

Se procede a explorar el primer directorio Axis2, dado que como se muestra en la figura 20, GCE encontró credenciales para este servicio.

Figura 20. Credenciales encontradas por GCE para el servicio Axis2.

En la figura 21, se observa que utilizando las credenciales reportadas (admin/axis2) por GCE es posible acceder al módulo web de administración.

Figura 21. Acceso al módulo web de administración de Axis2. Fuente: propia.

Adicionalmente, GCE reporto encontrar credenciales para los servicios de FTP y SSH como se observa en las figuras 22 y 23, respectivamente.

Figura 22. Credenciales para el servicio FTP. Fuente: propia.

Figura 23. Credenciales para el servicio SSH. Fuente: propia.

Se procede a acceder al servidor utilizando el servicio SSH, como se observa en la figura 24, utilizando las credenciales vagrant:vagrant.

Figura 24. Acceso al servicio SSH. Fuente: propia.

Otro directorio interesante es Manager, en el cual al intentar acceder se solicita credenciales, sin embargo, al poner credenciales erróneas, se genera un error 401, que entrega información relevante, en el cual se indica que en el archivo conf/tomcat-users.xml se encuentran las credenciales para utilizar la aplicación web, como se observa en la figura 25.

Figura 25. Página de error 401 al intentar acceder al directorio manager. Fuente: propia.

Utilizando esta información y la consola SSH previamente establecida, se procede a leer el archivo con el comando: findstr "^" "C:\Program Files\Apache Software Foundation\tomcat\apache-tomcat-8.0.33\conf\tomcat-users.xml". En este archivo se identifican las credenciales username="sploit" password="sploit" roles="manager-gui", como se observa en la figura 26.

Figura 26. Acceso al archivo tomcat-users.xml. Fuente: propia.

Adicionalmente, se procede a realizar una enumeración de usuarios en el directorio manager, como se muestra en la figura 27.

Figura 27. Enumeración de usuarios en el servicio apache tomcat. Fuente: propia.

Dado que ya se han realizado varias tareas de explotación, ahora se procede a realizar tareas de post-explotación utilizando Meterpreter [3]. Se procede a establecer una consola utilizando el exploit multi/http/tomcat_mgr_upload, como se muestra en la figura 28, obteniendo una consola con el usuario METASPLOITABLE3.

Figura 28. Estableciendo una consola con Meterpreter. Fuente: propia.

De manera similar al anterior y utilizando el mismo exploit, se procede a cambiar el payload a Windows/meterpreter/reverse_tcp, lo cual permite establecer una consola, pero con el usuario NT AUTHORITY\SYSTEM, permitiendo así tener permisos más elevados en la máquina. Esto se muestra en la figura 29.

Figura 29. Consola con un usuario de mayor privilegio. Fuente: propia.

Es posible igualmente utilizar un exploit para Axis2, con el fin de establecer la consola con Meterpreter, como se observa en la figura 30.

Figura 30. Consola utilizando un exploit para Axis2. Fuente: propia.

Ingresando a la pantalla de administración de apache tomcat, se observa que existe un servicio /struts2-rest/showcase, como se muestra en la figura 31. Este también puede aprovecharse para establecer una consola con Meterpreter, como se observa en la figura 32.

Figura 31. Servicio struts2 expuesto por apache tomcat. Fuente: propia.

Figura 32. Consola utilizando el servicio struts2. Fuente: propia.

Se registran múltiples maneras de establecer una consola utilizando Meterpreter y diferentes servicios/vulnerabilidades que permitirían continuar con tareas de post-explotación.

Conclusiones

La elección entre Nessus y Greenbone CE debe basarse en las necesidades específicas de la organización, el nivel de detalle requerido en los informes, y la capacidad del sistema para soportar el impacto del escaneo de vulnerabilidades. A continuación, se desarrollan estos puntos en detalle:

Evaluación de la calidad y la estructura de los informes de vulnerabilidades

Nessus: Los informes generados por Nessus se caracterizan por su claridad y estructura organizada. Incluyen detalles importantes como la clasificación de las vulnerabilidades en críticas, altas, medias y bajas, junto con descripciones, soluciones recomendadas y referencias adicionales. La presentación es intuitiva, facilitando la interpretación de los datos para profesionales de seguridad con diferentes niveles de experiencia. Sin embargo, puede presentar menos detalles técnicos en comparación con GCE.

Greenbone CE: Los informes de GCE tienden a ser más detallados, proporcionando información técnica profunda, incluyendo credenciales descubiertas y configuraciones específicas de los servicios. Sin embargo, esta riqueza de detalles puede hacer que los informes sean más complejos de interpretar para aquellos que no están familiarizados con el análisis de vulnerabilidades a nivel técnico.

Análisis del impacto en el rendimiento del sistema

CPU y Memoria: Durante la ejecución de escaneos, GCE mostró un mayor consumo de CPU y memoria en comparación con Nessus, lo que sugiere que maneja una carga de trabajo más intensa. Nessus, aunque presenta más interrupciones y cambios de contexto, usa menos recursos en general, lo que indica una operación más optimizada en cuanto a la gestión de memoria y procesos.

Ancho de Banda (IPERF): Las pruebas de IPERF revelaron que Nessus maneja de manera más eficiente la red, mostrando una tasa de bits más estable y una mayor consistencia en la transferencia de datos. Por otro lado, GCE presentó inestabilidades significativas, con caídas abruptas en la tasa de bits, lo que podría reflejar una mayor susceptibilidad a la congestión de la red o limitaciones de hardware.

Fortalezas y debilidades

Fortalezas de Nessus: Su capacidad para generar informes claros y organizados, junto con su menor impacto en los recursos del sistema, lo hace ideal para organizaciones que necesitan un análisis de vulnerabilidades eficiente y fácil de interpretar sin sacrificar el rendimiento del sistema.

Fortalezas de GCE: La riqueza de detalles técnicos en sus informes y su capacidad para detectar un mayor número de vulnerabilidades, incluyendo la identificación de credenciales, lo hacen una herramienta poderosa para un análisis profundo y exhaustivo.

Debilidades de Nessus: Puede omitir detalles técnicos que GCE captura, lo que podría ser un inconveniente en entornos donde se requiere un análisis profundo.

Debilidades de GCE: Su mayor consumo de recursos y la complejidad de sus informes pueden representar un desafío en ambientes donde los recursos son limitados o donde se requiere una interpretación rápida de los resultados.

Recomendaciones sobre cuándo utilizar cada herramienta

Nessus: Es recomendable en organizaciones que buscan un equilibrio entre un análisis efectivo de vulnerabilidades y la necesidad de minimizar el impacto en el rendimiento del sistema. También es adecuado para equipos con menos experiencia técnica que necesitan interpretar los resultados rápidamente.

Greenbone CE: Es ideal en situaciones donde se requiere un análisis profundo y detallado, especialmente en entornos técnicos con la capacidad de manejar su mayor demanda de recursos. También es útil cuando se necesita descubrir información crítica como credenciales de servicios o detalles específicos de configuraciones.

Referencias

[1] C. Marcho, «Windows Performance Monitor Overview - Microsoft Community Hub», https://techcommunity.microsoft.com/t5/ask-the-performance-team/windows-performance-monitor-overview/ba-p/375481.

[2] «iPerf - The ultimate speed test tool for TCP, UDP and SCTP», https://iperf.fr/.

[3] Sentinel One, «Metasploit Meterpreter: The Advanced and Powerful Payload», https://www.sentinelone.com/blog/meterpreter-advanced-powerful-metasploit-payload/.

Integridad y confidencialidad: Porque no entregar el hash de un número de tarjeta

Dilver Huertas Guerrero — Thu, 02 May 2024 02:34:26 +0000

Escenario

Usted es responsable de la ciberseguridad en su organización, y se presenta una situación en la cual proponen como medida de seguridad, entregar el hash de la tarjeta en vez del número de tarjeta en las transacciones que van hacia la aplicación móvil de su empresa. Argumentan que el hash es una operación no reversible, por lo cual, un atacante no podría obtener el dato original. Sin embargo, usted aún tiene la pregunta: ¿Es posible determinar el número de tarjeta a partir del hash?.

Algoritmos para la generación de hash

Los algoritmos de generación de hash son funciones criptográficas diseñadas para convertir datos de cualquier tamaño en un valor fijo, estos valores son únicos para cada entrada única (en realidad la cantidad de combinaciones es muy grande, pero finita, ver colisión de hash), es decir, pequeñas diferencias en los datos de entrada producirán hashes completamente diferentes. Algunos de los algoritmos más utilizados son:

MD5 (Message Digest Algorithm 5)

MD5 divide los datos en bloques de 512 bits y procesa cada bloque en un ciclo de 64 pasos, utiliza cuatro variables de 32 bits, y el resultado es un hash de 128 bits. Aunque se usa ampliamente para verificar la integridad de los datos, no se recomienda su aplicación en seguridad debido a vulnerabilidades conocidas.

SHA-1 (Secure Hash Algorithm 1)

SHA-1 procesa bloques de 512 bits y utiliza un ciclo de 80 pasos, resultando en un hash de 160 bits; fue ampliamente utilizado en protocolos de seguridad como TLS y SSL, pero ha sido reemplazado por versiones más seguras de SHA debido a debilidades en su estructura.

SHA-3 (parte de la familia SHA-2)

SHA-3 difiere significativamente en su enfoque usando la función de permutación Keccak, procesando los datos en una matriz de estado de 1600 bits y permite salidas de hash de diferentes tamaños (como 224, 256, 384, 512 bits).

SHA-256

SHA-256 procesa bloques de datos de 512 bits utilizando un ciclo de 64 pasos y produce un hash de 256 bits, es ampliamente utilizado en aplicaciones de blockchain y criptomonedas.

Blake2

Es una versión mejorada del algoritmo Blake, procesa bloques de 512 o 1024 bits y es más rápido que MD5, SHA-1 y SHA-256 en software. Ofrece alta velocidad y seguridad, es utilizado en contextos donde se requieren ambas, como en bases de datos y autenticación de software.

Whirlpool

Utiliza una matriz de estado de 512 bits y realiza un total de 10 rondas de transformaciones, el resultado es un hash de 512 bits. Es menos común que SHA o MD5, se aplica en seguridad para garantizar la integridad de los datos.

Estructura del número de tarjeta de crédito

La estructura de un número de tarjeta de crédito está estandarizada, normalmente, un número de tarjeta de crédito consta de 16 dígitos, aunque algunos sistemas como American Express usan 15 dígitos. Estos dígitos están estructurados de la siguiente manera:

Número de Identificación del Emisor (IIN): Los primeros 6 dígitos del número de la tarjeta identifican a la institución financiera que emitió la tarjeta. Los primeros 2 dígitos indican el tipo de tarjeta, como Visa, MasterCard, American Express, etc. De los dígitos 3 a 6 se cuenta con la identificación específica del banco o institución financiera que emite la tarjeta (BIN).
Número de cuenta del titular: Los dígitos siguientes hasta el penúltimo son el número de cuenta único del titular de la tarjeta, este número es asignado por la institución financiera.
Dígito de verificación: El último dígito de la tarjeta es un dígito de verificación o dígito de control, calculado a través del algoritmo de Luhn, y permite validar la autenticidad del número de tarjeta de crédito. El proceso involucra sumar y manipular los dígitos de ciertas maneras para producir un solo dígito que debe coincidir con este último número en la tarjeta.

Bases de datos de números de identificación bancaria

El número de identificación bancaria (BIN), es utilizado en el sistema de tarjetas (crédito/débito) para identificar la institución que emitió la tarjeta al titular y sus características. Existen bases de datos que se utilizan para identificar rápidamente la institución que emitió una tarjeta de crédito o débito a partir de la secuencia de dígitos 3 a 6. En la red podemos encontrar algunos sitios que permiten acceder a una lista de BIN, como se muestra en las siguientes imágenes.

En bincheck.io se encuentran BIN de 90 bancos en Colombia (según el sitio):

En iinbinlist.com se presenta algo similar:

Igualmente en bankbinlist.com:

Con las consultas de BIN mostradas anteriormente, se quiere evidenciar que estos son datos que pueden ser conocidos fácilmente por un atacante, sin embargo, también es necesario tener en cuenta que son una parte fundamental del ecosistema de pagos electrónicos, facilitando la comunicación y la seguridad entre las instituciones financieras, comerciantes y consumidores.

Respondiendo la pregunta

Después de la teoría, vuelve la pregunta: ¿Es posible determinar el número de tarjeta a partir del hash?. Supongamos que un atacante ha obtenido los datos de la transacción y esta contiene el hash sha-256 del número de tarjeta. Sabemos ya, que el IIN (los primeros 6 dígitos) dependen de la franquicia, el banco y segmento de clientes, que pueden ser conocidos, ya sea a través de alguna base de datos o adquiriendo un producto de la entidad a atacar. También, el último digito (de verificación) pueden ser calculado utilizando el algoritmo de Luhn. Es decir que de los 16 dígitos, tiene que averiguar 9 dígitos para obtener el número correspondiente al hash de la tarjeta, el atacante no tiene otra pista, y procede a utilizar fuerza bruta.

Para los 9 dígitos del número de cuenta (posiciones 7 a 15), hay 10⁹ combinaciones posibles (desde 000000000 hasta 999999999). Se procede a generar el siguiente código en python que generará los hash de los números de tarjeta de manera secuencial, tomando un IIN encontrado en las bases de datos (491511), esto a manera de ejemplo. Para ello se definen tres funciones, una que permite calcular el digito de verificación de acuerdo al algoritmo de luhn, otra que genera las combinaciones posibles a partir de un IIN fijo, y finalmente la que calcula el hash sha-256 de cada potencial número de tarjeta. En la función main se genera un archivo csv por cada 10 millones de hash generados (correspondientes al 1% del procesamiento).

import hashlib
import time
import csv

def calcular_digito_luhn(numero):
    digitos = [int(d) for d in str(numero)][::-1]
    suma_total = 0
    for i, digito in enumerate(digitos):
        if i % 2 == 1:
            digito *= 2
            if digito > 9:
                digito -= 9
        suma_total += digito
    return (10 - (suma_total % 10)) % 10

def generar_combinaciones(numero_fijo):
    numero_fijo = str(numero_fijo)
    # Rango de números para generar desde 0 hasta 999999999
    for num in range(1000000000):
        # Convertir el número a cadena y rellenar con ceros para tener siempre 9 dígitos
        numero_cliente = str(num).zfill(9)
        numero = numero_fijo + numero_cliente
        digito_luhn = calcular_digito_luhn(numero)
        numero_completo = numero + str(digito_luhn)
        yield numero_completo

def aplicar_sha256(numero):
    hash_obj = hashlib.sha256()
    hash_obj.update(numero.encode())
    return hash_obj.hexdigest()

def main():
    start_time = time.time()
    combinaciones = generar_combinaciones(491511)
    count = 0
    batch_num = 1

    # Crear el archivo CSV inicial
    while True:
        with open(f'hashes_batch_{batch_num}.csv', 'w', newline='') as file:
            writer = csv.writer(file)
            writer.writerow(['Número', 'Hash SHA-256'])
            for _ in range(10000000):
                try:
                    numero = next(combinaciones)
                except StopIteration:
                    break
                hash_result = aplicar_sha256(numero)
                writer.writerow([numero, hash_result])
                count += 1

            # Comprobación de finalización
            if count % 10000000 != 0 or count == 0:
                break

        print(f"Archivo {batch_num} completo con 10,000,000 hashes. Tiempo parcial: {time.time() - start_time:.2f} segundos")
        batch_num += 1

    end_time = time.time()
    print("Proceso completo.")
    print("Tiempo total de ejecución: {:.2f} segundos".format(end_time - start_time))

if __name__ == "__main__":
    main()

Hay que mencionar que el código desarrollado es sólo una aproximación, dado que se puede hacer más eficiente aplicando procesamiento en paralelo, realizando operaciones de escritura en disco de manera menos frecuente, reduciendo la llamadas a funciones, entre otras estrategias. Adicionalmente, el código será ejecutado en un equipo de computo de uso común.

A continuación se observa la captura de la ejecución realizada para los primeros 200 millones de combinaciones, suficiente para obtener los datos requeridos.

A modo de ejemplo, se muestra el resultado parcial del último archivo generado:

En la siguiente imagen, se observa el tiempo que toma generar cada archivo de 10 millones de hashes:

De acuerdo a los datos mostrados, en promedio la generación de un archivo con 10 millones de números y su correspondiente hash toma 79.47 segundos. Tomando como base que cada archivo requiera de 80 segundos de procesamiento, en total se requieren alrededor de 2 horas 15 minutos para completar todo el procesamiento, lo cual desde el punto de vista de un atacante es asumible. Cada banco tiene varios IIN, el esfuerzo que implica calcular los hashes para cada uno de estos tampoco sería un limitante.

Conclusiones

Como se pudo observar, entregar el hash de un número de tarjeta no constituye una medida de seguridad, a pesar que la operación para su cálculo no es reversible, dado que no impide conocer el dato original cuando se tienen pistas sobre este.
Se debe tener en cuenta, que de los pilares de la seguridad de la información, las operaciones hash están diseñadas para evaluar la integridad de los datos, no la confidencialidad. Aplicar los conocimientos y herramientas de manera adecuada, es el primer paso para una operación segura, no sólo en el mundo cibernético.

Análisis dinámico de aplicaciones web con OWASP ZAP

Dilver Huertas Guerrero — Mon, 25 Sep 2023 00:33:56 +0000

Introducción

La seguridad en aplicaciones web se ha convertido en un aspecto crítico en la actualidad, ya que cada vez más empresas y organizaciones dependen de estas para proporcionar servicios e interactuar con sus usuarios. Sin embargo, la creciente complejidad de estas aplicaciones también ha abierto nuevas puertas a las amenazas cibernéticas. En este contexto, es fundamental llevar a cabo análisis de seguridad exhaustivos para identificar y mitigar posibles riesgos.

En este post, se explora el análisis dinámico de aplicaciones web utilizando una herramienta de código abierto ampliamente reconocida: OWASP ZAP (Zed Attack Proxy). A modo de ejemplo se llevará a cabo el análisis de dos aplicaciones web intencionalmente vulnerables: Damn Vulnerable Web Application (DVWA) y OWASP Juice Shop.

El análisis dinámico permitirá identificar posibles vulnerabilidades en estas aplicaciones, evaluar su resistencia a ataques comunes y proporcionar recomendaciones para mejorar su seguridad. Además, se destacan las capacidades de OWASP ZAP como una herramienta esencial para cualquier persona interesada en la seguridad de aplicaciones web.

Se detallan los pasos clave para llevar a cabo un análisis dinámico de aplicaciones web con OWASP ZAP, desde la configuración inicial hasta la identificación de vulnerabilidades y la generación de informes detallados. También se analizan algunos de los resultados obtenidos en DVWA y OWASP Juice Shop para comprender mejor las amenazas a las que se enfrentan las aplicaciones web en la actualidad.

El objetivo es promover la conciencia sobre la importancia de la seguridad de las aplicaciones web y proporcionar a los profesionales de la seguridad y desarrolladores de aplicaciones una visión general de cómo utilizar OWASP ZAP para proteger sus aplicaciones contra amenazas cibernéticas. La seguridad es un proceso continuo, y el análisis dinámico de aplicaciones web desempeña un papel crucial en la identificación y mitigación de riesgos.

Finalmente, se debe recordar que este tipo de análisis solamente se realiza sobre aplicaciones e infraestructura propia o con la debida autorización de aquellos que sean responsables. Un escaneo de vulnerabilidades no autorizado constituye un delito informático, en Colombia particularmente puede acarrear penas de prisión y multas (Ley 1273 de 2009) [1].

Desarrollo

Herramientas

Despliegue de DVWA

Para desplegar DVWA sobre Kali Linux se sigue la guía disponible en GoLinuxCloud [2].

Se debe configurar DVWA con el usuario y contraseña que se creará en la base de datos MySQL.

Después de instalar MySQL, se debe crear el usuario en la base de datos con las mismas credenciales del punto anterior.

Se requiere instalar PHP, para este caso ya estaba instalada la versión 8.2, lo cual puede comprobarse con el comando php -version. Después deben instalarse las librerías.

Finalmente, se debe configurar el servidor apache

Se inicia el servicio de apache con el siguiente comando:

sudo service apache2 start

Para acceder a DVWA debe dirigirse con el navegador web a la dirección http://127.0.0.1/dvwa/. Una vez allí, debe dar click en "Create/Reset Database" y utilizar las credencias admin@password para terminar la configuración.

OWASP ZAP

OWASP ZAP es una herramienta de código abierto ampliamente reconocida y respaldada por la comunidad de seguridad. Actúa como un proxy entre el navegador web y la aplicación objetivo, lo que permite interceptar y manipular las solicitudes y respuestas HTTP/HTTPS, facilitando la identificación de vulnerabilidades y el análisis de tráfico. Puede realizar un escaneo automático de la aplicación web para descubrir vulnerabilidades comunes, como inyecciones SQL, cross-site scripting (XSS), cross-site request forgery (CSRF) y muchas otras, permitiendo el ahorro de tiempo y esfuerzo en comparación con las pruebas manuales.

Esta herramienta permite configurar y controlar las exploraciones de manera efectiva, ver resultados y generar informes detallados. Es posible escribir scripts personalizados en varios lenguajes (como JavaScript, Python y Groovy) para automatizar tareas específicas de prueba y personalizar el análisis de seguridad. También permite el manejo de sesiones de usuario, lo que facilita la prueba de vulnerabilidades que pueden depender del estado de la sesión, como el acceso no autorizado. Genera informes detallados que documentan las vulnerabilidades encontradas, su impacto potencial y las recomendaciones para su corrección. Estos informes son valiosos para comunicar los riesgos a los equipos de desarrollo.

Adicionalmente ZAP es altamente programable y se puede integrar en flujos de trabajo CI/CD (Integración Continua/Entrega Continua) para realizar pruebas de seguridad automáticamente en cada versión de una aplicación web.

Para realizar su instalación en Kali Linux se sigue la guía disponible en https://www.kali.org/tools/zaproxy/. Solamente debe ejecutarse el comando:

sudo apt install zaproxy

Una vez instalado, se observa una interfaz similar a la mostrada en la imagen:

Habilitar HTTPS en Apache

Para generar e instalar el certificado SSL se puede seguir la guía disponible en DigitalOcean [3]. Se configura la información del certificado dependiendo del caso:

Una vez instalado el certificado, se puede acceder al sitio a través de https. Tenga en cuenta que no se ha configurado para que el sitio web obligue a que el tráfico http vaya a través de https, por lo cual ambos protocolos siguen disponibles.

Ejecución de los análisis

Análisis sobre DVWA

DVWA permite practicar sobre algunas de las vulnerabilidades web más comunes, y configurar el nivel de seguridad general que presentarán cada uno de los retos.

Se realizaron varias pruebas, cambiando el modo de ZAP entre estándar y ataque, el nivel se seguridad en DVWA y el protocolo de comunicación (http/https). A continuación se resume la cantidad de vulnerabilidades encontradas para cada caso.

Análisis	Seguridad	Protocolo	Medio	Bajo	Informacional
estándar	baja	http	4	5	3
ataque	baja	http	5	5	3
estándar	imposible	http	4	5	3
ataque	imposible	http	5	5	3
estándar	imposible	https	5	7	4
ataque	imposible	https	5	7	4

Se observa que no hay diferencia al realizar el análisis con OWASP ZAP cambiando el nivel de seguridad de DVWA. El modo ataque identifica una vulnerabilidad de nivel medio adicional al modo estándar, la cual es Directory Browsing https://www.zaproxy.org/docs/alerts/0/.

La otra vulnerabilidad de tipo medio con la confianza más alta (18.8%) fue Content Security Policy (CSP) Header Not Set https://www.zaproxy.org/docs/alerts/10038/.

Utilizando el protocolo https se identifican dos alertas adicionales de tipo bajo: Cookie Without Secure Flag https://www.zaproxy.org/docs/alerts/10011/ y Strict-Transport-Security Header https://www.zaproxy.org/docs/alerts/10035/. También se identifico una alerta adicional de tipo informacional: Re-examine Cache-control Directives https://www.zaproxy.org/docs/alerts/10015/.

Análisis sobre OWASP Juice Shop

En un servidor en una red local controlada se realizó la instalación de OWASP Juice Shop https://owasp.org/www-project-juice-shop/. Posteriormente se realizó el análisis con ZAP obteniendo el siguiente resultado:

Análisis	Alto	Medio	Bajo	Informacional
estándar	1	4	4	2
ataque	2	4	4	3

Se identifican las vulnerabilidades de nivel alto Cloud Metadata Potentially Exposed https://www.zaproxy.org/docs/alerts/90034/ y SQL Injection https://www.zaproxy.org/docs/alerts/40018/. La vulnerabilidad media con la confianza más alta fue Session ID in URL Rewrite
https://www.zaproxy.org/docs/alerts/3/.

Explicación sobre algunas de las vulnerabilidades encontradas

A continuación se explican algunas de las vulnerabilidades encontradas a partir de los análisis realizados con OWASP ZAP. Igualmente puede consultar el OWASP TOP 10 https://owasp.org/www-project-top-ten/, dónde se explican las 10 vulnerabilidades más comunes en aplicaciones web.

Directory Browsing (Exploración de Directorios) ocurre cuando un atacante puede navegar a través de los directorios en un servidor web para acceder a archivos y directorios que no deberían ser públicos. Esto puede exponer datos confidenciales y facilitar ataques adicionales, por ello se debe configurar adecuadamente el servidor web para deshabilitar la exploración de directorios y asegurarse de que los directorios y archivos sensibles no sean accesibles públicamente.

Content Security Policy Header (Encabezado de Política de Seguridad de Contenido) es un mecanismo de seguridad que ayuda a prevenir ataques de scripts entre sitios (XSS) y otras amenazas relacionadas con la ejecución de código en el navegador. Sin CSP, un atacante podría ejecutar scripts maliciosos en el navegador de un usuario, lo que podría llevar al robo de información confidencial o la toma de control de cuentas.

La alerta Cookie Without Secure Flag (Cookie sin la Bandera Secure) indica que las cookies son vulnerables cuando no se establece la bandera "Secure". Esto significa que pueden enviarse a través de conexiones no seguras (HTTP) en lugar de conexiones seguras (HTTPS), lo que las hace vulnerables a ataques de interceptación. Un atacante que intercepta una cookie no segura podría robar sesiones de usuario, lo que permitiría la toma de control de cuentas.

Strict-Transport-Security Header (Encabezado de Seguridad de Transporte Estricto) garantiza que una aplicación web solo se cargue a través de conexiones seguras HTTPS, lo que evita que los usuarios accedan a la aplicación a través de HTTP no seguro. Los atacantes podrían forzar a los usuarios a utilizar conexiones HTTP e interceptar los mensajes.

Re-examine Cache-control Directives (Reexaminar Directivas Cache-control) es una vulnerabilidad que se refiere a la incorrecta configuración de las directivas de control de caché en las respuestas del servidor. Esto puede permitir a un atacante acceder a información obsoleta o confidencial en el caché del navegador, lo que podría llevar a la exposición de información confidencial.

Cloud Metadata Potentially Exposed (Posible Exposición de Metadatos en la Nube) es una vulnerabilidad que ocurre cuando una aplicación en la nube expone accidentalmente información de metadatos de la instancia, lo que podría incluir claves de acceso u otra información confidencial, lo que podría llevar a un compromiso de la infraestructura en la nube.

SQL Injection (Inyección SQL) es una vulnerabilidad en la que los atacantes insertan comandos SQL maliciosos en las entradas de una aplicación para manipular la base de datos subyacente. Esto puede permitir la extracción, modificación o eliminación de datos de la base de datos, lo cual puede llevar a la exposición de datos confidenciales, la corrupción de datos y la toma de control del sistema de base de datos. Para prevenir la inyección SQL, se deben utilizar consultas parametrizadas o funciones de escape de entrada de datos y se debe validar y sanitizar las entradas del usuario.

La alerta Session ID in URL Rewrite (Reescritura del ID de Sesión en la URL) indica que al colocar identificadores de sesión en la URL, un atacante podría obtener acceso no autorizado si intercepta la URL o si se produce un reenvío, haciendo posible robar sesiones de usuario y tomar el control de cuentas. Por lo cual se debe almacenar los identificadores de sesión de forma segura en cookies en lugar de incluirlos en la URL, lo cual ayuda a prevenir este tipo de ataque.

Conclusiones

En este post se explora el análisis dinámico de aplicaciones web mediante ejemplos prácticos con Damn Vulnerable Web Application (DVWA) y OWASP Juice Shop, se muestra como OWASP ZAP puede identificar vulnerabilidades, evaluar la resistencia a ataques comunes y proporcionar recomendaciones para mejorar la seguridad de las aplicaciones web.

En los análisis realizados en DVWA, se observó que cambiar el nivel de seguridad de la aplicación no tuvo un impacto significativo en la detección de vulnerabilidades por parte de OWASP ZAP. Sin embargo, el modo de ataque identificó una vulnerabilidad adicional en comparación con el modo estándar.

En OWASP Juice Shop, se identificaron vulnerabilidades de nivel alto, medio y bajo. Estas vulnerabilidades incluyeron Cloud Metadata Potentially Exposed, SQL Injection y Session ID in URL Rewrite. Estos resultados resaltan la importancia de evaluar y corregir activamente las vulnerabilidades en las aplicaciones web.

Las vulnerabilidades identificadas, como Directory Browsing, Content Security Policy Header Not Set y Cookie Without Secure Flag, son ejemplos de riesgos comunes en aplicaciones web que pueden poner en peligro la seguridad de los datos y la privacidad de los usuarios.

La seguridad de las aplicaciones web es un proceso continuo y dinámico. Además de utilizar herramientas como OWASP ZAP, es esencial seguir las mejores prácticas de seguridad, mantenerse actualizado sobre las amenazas cibernéticas y garantizar que las aplicaciones estén protegidas adecuadamente.

Referencias

[1] Avance Jurídico Casa Editorial Ltda., “Leyes desde 1992 - Vigencia expresa y control de constitucionalidad [LEY_1273_2009],” Avance Jurídico Casa Editorial Ltda., Senado De La República De Colombia. http://secretariasenado.gov.co/senado/basedoc/ley_1273_2009.html

[2] T. Gidraph, “Install DVWA on Kali Linux (Step-by-Step) | GoLinuxCloud,” GoLinuxCloud, Oct. 2021, [En línea]. Disponible: https://www.golinuxcloud.com/install-dvwa-kali-linux/
‌
[3] A. Wan, “How To Create a SSL Certificate on Apache for Debian 8,” DigitalOcean, Jun. 2015, [En línea]. Disponible: https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-debian-8
‌

Identificando vulnerabilidades en código fuente a través de análisis estático con SonarQube

Dilver Huertas Guerrero — Wed, 13 Sep 2023 21:33:19 +0000

Introducción

La seguridad de las aplicaciones es una preocupación creciente en la era digital, ya que el uso de estas tecnologías es cada vez mayor, y por lo tanto también incrementan los riesgos asociados con la presencia de vulnerabilidades en el código fuente. Tales vulnerabilidades pueden convertirse en puertas de entrada para ciberataques y amenazar la integridad, confidencialidad y disponibilidad de datos críticos.

En este contexto, la identificación temprana de vulnerabilidades en el código fuente se ha convertido en una práctica esencial para garantizar la seguridad de las aplicaciones y sistemas. Una de las herramientas utilizadas para esa tarea es SonarQube, una plataforma de análisis estático de código que permite a los desarrolladores y equipos de seguridad, examinar de manera exhaustiva el código fuente en busca de debilidades.

Este post tiene como objetivo mostrar la utilidad de SonarQube en la identificación y corrección de vulnerabilidades, se hace un recorrido por su instalación, uso y algunas características clave (métricas). A modo de ejemplo se realiza el proceso de remediación de vulnerabilidades en dos proyectos desarrollados en distintos lenguajes, haciendo uso de key vault para introducir la idea de administración segura de claves y secretos.

Desarrollo

El laboratorio se desarrolla en tres partes: primero se realiza la revisión de conceptos previos, después se instalan las herramientas requeridas, por último se lleva a cabo la identificación de vulnerabilidades con SonarQube.

Conceptos previos

Métricas en SonarQube

SonarQube es una plataforma ampliamente utilizada para evaluar y mejorar la calidad del código fuente en proyectos de desarrollo de software. Proporciona una serie de métricas que ayudan a identificar problemas en el código y tomar medidas para remediarlos, en la guía de usuario se explican en detalle [1]. A continuación se resumen algunas:

Detección de errores (Reliability): SonarQube detecta errores potenciales en el código, como el acceso a variables no inicializadas o la división por cero. El objetivo es eliminar defectos antes de que causen problemas en tiempo de ejecución.
Reglas de calidad del código (Maintainability): SonarQube incluye una serie de reglas predefinidas que evalúan el cumplimiento de buenas prácticas de codificación, como el uso de nombres descriptivos de variables o la gestión adecuada de excepciones. El objetivo es mejorar la legibilidad y la mantenibilidad del código.
Seguridad (Security): Identifica problemas de seguridad en el código, ya sean vulnerabilidades conocidas o malas prácticas que podrían exponer el sistema a ataques. El objetivo es fortalecer la seguridad del software.
Revisión de seguridad (Security Review): Identifica potenciales problemas de seguridad en el código (hotspots), que podrían facilitar la ejecución de ataques. El objetivo es fortalecer la seguridad del software.
Cobertura de código (Coverage): Esta métrica mide la proporción del código fuente que ha sido ejecutada por pruebas automatizadas. El objetivo es garantizar que la mayoría del código esté cubierto por pruebas para reducir la probabilidad de errores no detectados.
Duplicación de código (Duplications): Mide la cantidad de código duplicado en el proyecto. El objetivo es reducir la duplicación, ya que aumenta la complejidad y el mantenimiento del código.

Este laboratorio se enfoca en los puntos 3 y 4, relacionados directamente con la seguridad. El punto 5 (Coverage) requiere de configuración adicional dependiendo del lenguaje de desarrollo, lo cual puede ser consultado en la documentación oficial disponible en https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/test-coverage/overview/.

Lenguajes disponibles en la versión comunitaria de SonarQube

De acuerdo a la documentación oficial de SonarQube [2], la versión comunitaria permite realizar escaneo en 21 lenguajes distintos, los cuales se listan en la siguiente tabla:

Lenguajes
Azure Resource Manager	HTML	Ruby
CloudFormation	Java	Scala
C#	JavaScript	Secrets
CSS	Kotlin	Terraform
Docker	Kubernetes	TypeScript
Flex	PHP	VB.NET
Go	Python	XML

Key vault

Un Key Vault (bóveda de claves) es un servicio de administración de claves y secretos que se utiliza para proteger información confidencial, tales como: contraseñas, certificados, claves de cifrado y otros datos sensibles. De acuerdo a la documentación de Azure Key Vault [3], entre sus características encontramos:

Almacenamiento Seguro: Los Key Vaults están diseñados para proporcionar un entorno altamente seguro para almacenar y gestionar secretos y claves criptográficas. Utilizan técnicas de cifrado avanzadas y protocolos de seguridad para proteger los datos almacenados.
Gestión Centralizada: Un Key Vault permite centralizar la gestión de claves y secretos en un solo lugar. Esto simplifica la administración y reduce los riesgos asociados con la dispersión de información confidencial en múltiples ubicaciones.
Auditoría y Registro: Proporciona registros de auditoría detallados para rastrear quién accede a los secretos y claves, cuándo lo hacen y qué acciones realizan. Esto es esencial para cumplir con los requisitos de conformidad y detectar actividades sospechosas.
Integración con Aplicaciones: Los Key Vaults se pueden integrar fácilmente con aplicaciones y servicios en la nube, permitiendo que estos accedan a secretos y claves de manera segura. Esto evita la necesidad de almacenar información sensible en el código fuente de la aplicación.
Rotación Automatizada: Un Key Vault facilita la rotación automática de claves y secretos, lo que mejora la seguridad al garantizar que las claves no estén en uso durante períodos prolongados.
Control de Acceso Granular: Los administradores pueden definir políticas de control de acceso detalladas para especificar quién tiene permiso para acceder a qué secretos y claves, y bajo qué circunstancias.
Integración con Herramientas de DevOps: Los Key Vaults se pueden integrar con herramientas de desarrollo y operaciones (DevOps) para automatizar la gestión de secretos y claves en el ciclo de vida de las aplicaciones.

En términos de seguridad un Key Vault es esencial para mejorar la seguridad en la nube y proteger información confidencial de la siguiente manera:

Protección contra Amenazas Internas y Externas: Al centralizar la gestión de claves y secretos, un Key Vault ayuda a proteger los datos confidenciales contra amenazas tanto internas como externas. Esto incluye el acceso no autorizado y el robo de datos.
Conformidad Regulatoria: Los Key Vaults permiten cumplir con regulaciones de seguridad y privacidad al proporcionar un control riguroso sobre el acceso y la auditoría de los secretos y claves.
Reducción de Riesgos: La rotación automática de claves y secretos reduce el riesgo de que las claves sean comprometidas debido a la exposición prolongada.
Simplificación de la Gestión de Claves: Facilita la gestión de claves y secretos en entornos complejos de nube y reduce la carga operativa.
Integración Segura: Permite a las aplicaciones acceder a secretos y claves de manera segura sin almacenar información sensible en el código fuente.

Instalación de herramientas

Para disponer de SonarQube, se ofrecen dos opciones en la web oficial: descargar un archivo zip ó ejecutarlo utilizando Docker. Para este laboratorio se llevó a cabo la instalación utilizando la segunda opción. En caso de no contar con Docker, puede instalarse siguiendo la guía disponible en https://docs.docker.com/desktop/install/windows-install/.

Desde la consola de Powershell puede instalar y ejecutar SonarQube utilizando el siguiente comando:

docker run -d --name sonarqube -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -p 9000:9000 sonarqube:latest

Si todo ha funcionado correctamente, desde Docker Desktop podrá observar el contenedor de SonarQube corriendo de manera similar a la mostrada en la siguiente imagen:

Utilizando el navegador web, debe dirigirse a la URL http://localhost:9000. Si es la primera vez que utiliza SonarQube le aparecerá una pantalla de login, las credenciales son admin/admin, se le solicitará asignar una nueva contraseña. Una vez ingrese verá una pantalla como la que se muestra a continuación:

Identificando vulnerabilidades con SonarQube

Se realizará el análisis de 2 proyectos con las siguientes características:

Proyecto	Lenguajes	Tipo	Repositorio
Damn Vulnerable Web Application	PHP/MySQL	Web	https://github.com/digininja/DVWA
ParticipAR	Kotlin	Móvil	https://github.com/djhuertasg/ParticipAR

DVWA

DVWA es una aplicación web intencionalmente vulnerable. Se realiza la descarga del código en zip, y se procede a crear el proyecto en SonarQube.

Como método de análisis se selecciona la opción local, para lo cual se debe generar un token como se muestra a continuación:

Posteriormente se selecciona entre las herramientas de construcción automatizada de código u otro y el sistema operativo desde el cual se esta ejecutando el análisis. Adicionalmente, antes de ejecutar el escaneo, se debe descargar el escáner y añadirlo al path, cómo se muestra en las imágenes:

Una vez se tenga todo configurado, se procede a lanzar la ejecución del análisis desde Powershell, ubicado en la carpeta del proyecto a analizar con la siguiente línea de código:

sonar-scanner.bat -D"sonar.projectKey=DVWA" -D"sonar.sources=." -D"sonar.host.url=http://localhost:9000" -D"sonar.token=sqp_6479b25b30a19dff8cd009d3d4bcc9f478b799f3"

Tenga en cuenta que en una implementación en un ambiente real, el token debe mantenerse secreto, a fin de evitar el uso no autorizado de recursos.

Una vez ejecutado el análisis se obtiene el resultado mostrado a continuación:

En el detalle de las vulnerabilidades de seguridad, se encuentran las siguientes:

Ambas vulnerabilidades están asociadas a 'código quemado', es decir, credenciales que se dejaron en el código (en este caso de base de datos), lo cual va en contra de los lineamientos de desarrollo seguro. Para cada una de las vulnerabilidades SonarQube detalla cuál es el problema (indicando el archivo y línea de código correspondiente), por qué es un problema y cómo se puede solucionar.

A continuación se muestra el código vulnerable en el archivo compose.yml

Una opción para resolver esta vulnerabilidad es utilizar un key vault, suponiendo que contamos con uno, se ajusta el código como se muestra en la imagen:

A continuación se muestra el código vulnerable en el archivo test.php

Suponiendo el uso de un key vault, se ajusta el código como se muestra a continuación:

Realizados los ajustes, se procede a ejecutar nuevamente el análisis en SonarQube, obteniendo cero vulnerabilidades.

ParticipAR

ParticipAR es una aplicación móvil desarrollada en Kotlin para la plataforma android.

Se procede a crear el proyecto en SonarQube.

De manera similar se procede a ejecutar el análisis:

Se observa que SonarQube no identifica vulnerabilidades, pero si hotspots.

Se identifica que no se obliga a ejecutar conexiones seguras, lo cual en versiones menores a Android 9 podría llevar el uso de protocolos no cifrados. También se muestran alertas referentes a permisos para realizar backup, utilizar la cámara y acceder a la ubicación del dispositivo.

Se modifica el archivo AndroidManifest.xml para deshabilitar el uso de protocolos inseguros y backup.

Dado que la aplicación requiere los permisos de cámara y ubicación, se procede a declararlos seguros, como se observa en la imagen:

Una vez realizados esos ajustes, se procede a ejecutar el análisis nuevamente, obteniendo cero hotspots.

Conclusiones

La identificación temprana de vulnerabilidades en el código fuente es esencial para garantizar la seguridad de las aplicaciones y sistemas, SonarQube es una herramienta versátil para automatizar esa tarea, proporcionando métricas, identificando el código a corregir y sugiriendo las remediaciones a realizar.

El uso de un Key Vault es fundamental para la gestión segura de claves y secretos, lo que contribuye a proteger información confidencial y reducir los riesgos asociados con la exposición de datos sensibles.

Se debe integrar la seguridad en el ciclo de desarrollo de software, a través de prácticas de operaciones de desarrollo seguras (DevSecOps).

Referencias

[1] “An overview of the key concepts used within SonarQube.” SonarQube 10.2. Accedido el 13 de septiembre de 2023. [En línea]. Disponible: https://docs.sonarsource.com/sonarqube/latest/user-guide/concepts/

[2] “Languages overview”. SonarQube 10.2. Accedido el 13 de septiembre de 2023. [En línea]. Disponible: https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/languages/overview/

[3] “Azure Key Vault documentation”. Microsoft Learn: Build skills that open doors in your career. Accedido el 13 de septiembre de 2023. [En línea]. Disponible: https://docs.microsoft.com/en-us/azure/key-vault/

Parte 2 - Descubrimiento de vulnerabilidades en redes IP

Dilver Huertas Guerrero — Sat, 09 Sep 2023 04:17:48 +0000

Introducción

La seguridad de la información se ha convertido en un aspecto crítico para empresas, organizaciones y particulares. Las redes IP (Protocolo de Internet) habilitan la comunicación entre dispositivos y por ello son un objetivo atractivo para posibles ataques cibernéticos, por lo tanto la identificación y mitigación de vulnerabilidades en estas redes se ha vuelto esencial para proteger la integridad, confidencialidad y disponibilidad de los sistemas y datos.

En este contexto, herramientas de evaluación de vulnerabilidades como Nessus Essentials y OpenVAS han emergido como aliados poderosos en la identificación de estas, las cuales permiten a los profesionales de seguridad y administradores de sistemas escanear, detectar y analizar posibles debilidades en redes IP, sistemas operativos y aplicaciones. Al identificar estas vulnerabilidades antes de que los atacantes puedan explotarlas, las organizaciones pueden tomar medidas preventivas para fortalecer su postura de seguridad.

Este post se centra en la utilización de Nessus Essentials y OpenVAS como soluciones de código abierto para el descubrimiento de vulnerabilidades en redes IP. Se exploran sus características, capacidades y metodologías para llevar a cabo análisis de seguridad en redes, y como pueden contribuir a una estrategia efectiva de gestión de vulnerabilidades. Para ello se utilizarán 2 redes: La primera será la red desplegada en la parte 1 (Configurando una red básica para aprender sobre gestión de vulnerabilidades) [1] agregando una máquina adicional con Metasploitable. La segunda es una red con dispositivos reales conectados a un punto de acceso preparado para tal fin. Con ello se busca una comprensión más profunda de la importancia del descubrimiento de vulnerabilidades en redes IP, así como las herramientas y técnicas disponibles para llevar a cabo este proceso.

Por último, se debe resaltar que el post pretende enseñar sobre estas herramientas para su uso adecuado, se aclara que realizar un escaneo de vulnerabilidades no autorizado en una red constituye un delito informático. En Colombia, de enero a octubre de 2022, se presentaron 54.121 denuncias por delitos informáticos [2]. Esto puede acarrear penas de prisión y multas (Ley 1273 de 2009) [3].

Desarrollo

Para este ejercicio se mencionan las direcciones IP utilizadas a modo de contexto, estas pueden cambiar dependiendo de la configuración del escenario de prueba particular, para conocerlas se debe utilizar el comando ipconfig en Windows ó el comando ifconfig en Linux.

Instalación de herramientas

Metasploitable es una máquina virtual configurada para contener múltiples vulnerabilidades de seguridad conocidas, se utiliza en laboratorios de análisis de vulnerabilidades y pruebas de penetración para propósitos educativos y de investigación. Además es útil para aprender como explotar y remediar vulnerabilidades en un entorno controlado y ético, lo que ayuda a mejorar las habilidades en la identificación y mitigación de amenazas de seguridad. Para instalar Metasploitable puede seguir la guía disponible en GeeksforGeeks [4].

Nessus Essentials es una herramienta gratuita que se utiliza para identificar y evaluar vulnerabilidades en sistemas informáticos y redes. Aunque es limitada (permite escanear hasta 16 IP) en comparación con las versiones de pago de Nessus, Nessus Essentials ofrece capacidades esenciales para ayudar a las organizaciones a mejorar la seguridad de sus activos digitales al escanear en busca de posibles debilidades y proporcionar informes de vulnerabilidades. Para su instalación, se descarga de la página oficial de Tenable [5]. Una vez instalado se puede acceder desde la misma máquina (en este caso kali linux) utilizando el navegador y dirigiéndose a https://kali:8834/, o desde otra máquina con la IP y puerto 8834.

OpenVAS (Sistema Abierto de Análisis de Vulnerabilidades) es otra herramienta de escaneo de vulnerabilidades de código abierto que se utiliza para identificar debilidades en sistemas informáticos y redes. Permite a las organizaciones realizar escaneos de seguridad en busca de posibles amenazas y vulnerabilidades, lo que ayuda a mejorar la seguridad de los activos digitales. OpenVAS es altamente configurable y puede adaptarse a las necesidades específicas de seguridad de una organización. Para instalarlo, se descarga la ova de VirtualBox (también esta la opción de VMWare) y se sigue la guía de instalación, ambas están disponibles en la web oficial [6]. Una vez se instala OpenVAS, se puede acceder utilizando el navegador, la dirección web dependerá de la red, en este caso para la red virtual ir a https://10.0.2.5, y para la red con dispositivos reales ir a https://192.168.40.243. Como recomendación, solamente se debe habilitar en la configuración de la máquina virtual el adaptador de red que se necesite dependiendo del escenario.

Habilitar las máquinas virtuales para acceder a la red del host (para la prueba en la red con dispositivos reales)

En VMWare se debe configurar un segundo adaptador de red (en la parte 1 se configuró un primer adaptador en red NAT) para cada máquina virtual de tipo Bridged Adapter como se observa a continuación:

Adicionalmente, se debe habilitar en el firewall de la máquina host la comunicación entre la IP del host y la red configurada para la prueba, de manera similar a como se observa en la imagen.

Identificación de vulnerabilidades en la red de máquinas virtuales con Nessus Essentials y OpenVAS

Descubrimiento de host (Host Discovery)

Se configura el descubrimiento de host en Nessus Essentials con las IP de las máquinas virtuales.

En la siguiente imagen se observa el resultado obtenido por Nessus.

Se configura el descubrimiento de host en OpenVAS, en el menú desplegable Scan Config

Las IP de las máquinas virtuales se añaden de forma manual, seleccionando como lista de puertos All TCP and Nmap top 1000 UDP. En el reporte de OpenVAS se observa que no encontró ningún host.

Escaneo básico de red (Basic Network Scan)

Se configura el escaneo básico de red en Nessus Essentials con las IP de las máquinas virtuales.

En la siguiente imagen se observa el resumen del número de vulnerabilidades encontradas para cada host de acuerdo a su nivel (crítico, alto, medio, bajo, informativo). Como es de esperarse la mayoría de vulnerabilidades fueron encontradas para la IP 10.0.2.6 (la cual corresponde a Metasploitable).

En la tabla se resume el número de vulnerabilidades encontradas

IP	CRITICAL	HIGH	MEDIUM	LOW	INFO
10.0.2.4	0	1	1	0	48
10.0.2.6	9	6	19	7	78
10.0.2.15	0	0	0	0	18

Por otro lado, en el reporte de OpenVAS se observa que no encontró ningún host, y por tanto no identificó ninguna vulnerabilidad.

Escaneo avanzado (Advanced Scan)

En la siguiente tabla se resumen los factores de riesgo encontrados con Nessus Essentials, como es de esperarse la máquina con Metasploitable presenta múltiples vulnerabilidades críticas, altas, medias y bajas.

IP	CRITICAL	HIGH	MEDIUM	LOW	INFO
10.0.2.6	10	6	18	7	75
10.0.2.15	0	0	0	0	18

En la imagen se muestra el resumen de las vulnerabilidades críticas y altas para la máquina con Metasploitable.

En la siguiente imagen se observa el resultado de los escaneos realizados con OpenVAS, donde solo se detectaron vulnerabilidades utilizando la configuración Full and fast.

En la siguiente tabla se relaciona el resumen de las vulnerabilidades encontradas:

Host	High	Medium	Low
10.0.2.6 METASPLOITABLE	26	42	6
10.0.2.15	0	0	2
10.0.2.4	0	0	2
Total: 3	26	42	10

Para metasploitable, las vulnerabilidades fueron encontradas en los siguientes puertos: 514/tcp, 3306/tcp, 5432/tcp, 21/tcp, 8009/tcp, 80/tcp, 22/tcp 3632/tcp, 513/tcp, 6200/tcp, 5900/tcp, 8787/tcp, 8180/tcp, general/tcp, 6667/tcp, 1524/tcp, 512/tcp, 2121/tcp.

Identificación de vulnerabilidades en una red real con Nessus Essentials y OpenVAS

Descubrimiento de host (Host Discovery)

Realizando el descubrimiento de host con Nessus Essentials se encontraron los siguientes dispositivos:

IP
192.168.40.1
192.168.40.240
192.168.40.241
192.168.40.242
192.168.40.243
192.168.40.245
192.168.40.246
192.168.40.247
192.168.40.249
192.168.40.250
192.168.40.251
192.168.40.252
192.168.40.254

Mientras con OpenVAS no encontró ningún host para este caso.

Escaneo básico de red (Basic Network Scan )

En la siguiente imagen se observa el resultado de realizar un escaneo básico de la red con Nessus Essentials, con un tiempo de procesamiento de 32 minutos.

La herramienta encontró las vulnerabilidades mostradas en la siguiente tabla:

IP	HIGH	MEDIUM	LOW	INFO
192.168.40.1	0	2	4	27
192.168.40.240	0	0	0	3
192.168.40.243	0	2	0	25
192.168.40.245	1	1	0	48
192.168.40.246	0	2	0	31
192.168.40.247	0	3	0	24
192.168.40.249	0	2	0	19
192.168.40.251	0	0	0	4
192.168.40.254	0	4	0	37

Por su lado, OpenVAS no encontró ningún host para este caso.

Escaneo avanzado (Advanced Scan)

En la siguiente imagen se observa el resultado de realizar un escaneo avanzado de la red con Nessus Essentials, en este caso la duración fue de 18 minutos.

En la siguiente tabla se observa el detalle de todas la vulnerabilidades encontradas:

IP	HIGH	MEDIUM	LOW	INFO
192.168.40.1	0	2	4	28
192.168.40.240	0	0	0	6
192.168.40.241	0	2	0	26
192.168.40.242	0	1	0	26
192.168.40.243	0	2	0	25
192.168.40.245	1	1	0	49
192.168.40.246	0	2	0	31
192.168.40.247	0	3	0	45
192.168.40.249	0	2	0	19
192.168.40.250	0	0	0	15
192.168.40.251	0	1	0	19
192.168.40.252	0	0	0	22
192.168.40.254	0	5	0	37

En el caso de OpenVAS se encontraron 5 vulnerabilidades de clasificación alta, 16 de clasificación media y 16 de clasificación baja, como se muestra a continuación:

Host	High	Medium	Low
192.168.40.247	1	0	2
192.168.40.243	1	0	0
192.168.40.254 ACDC	1	2	2
192.168.40.242	1	3	1
192.168.40.1	1	8	3
192.168.40.249	0	1	1
192.168.40.251	0	1	1
192.168.40.246 LAPTOP-7CDBNT53	0	1	1
192.168.40.250	0	0	2
192.168.40.245	0	0	2
192.168.40.252	0	0	1
Total: 11	5	16	16

En la siguiente tabla se presenta el detalle de las vulnerabilidades de clasificación alta:

IP	PORT	Vulnerability Detection Result
192.168.40.247	443/tcp	It was possible to login using the following credentials (username:password): admin:admin
192.168.40.243	443/tcp	It was possible to login using the following credentials (username:password): admin:admin
192.168.40.254	8834/tcp	VMware Spring Cloud Function is prone to a remote code execution (RCE) vulnerability.
192.168.40.242	1043/tcp	Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol: TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
192.168.40.1	general/tcp	MikroTik RouterOS is prone to a denial of service (DoS) vulnerability in the SMB server.

Vulnerabilidades encontradas e identificación de CVE relevantes

CVE (Common Vulnerabilities and Exposures) es un sistema de identificación y estandarización de vulnerabilidades informáticas. Cada CVE es un identificador único que se asigna a una vulnerabilidad específica y se utiliza en todo el mundo para rastrear y comunicar problemas de seguridad de manera consistente. MITRE Corporation es la organización detrás de la creación y gestión de este sistema, así como de otras actividades relacionadas con la seguridad y la tecnología. Los CVE pueden ser consultados en la página oficial de MITRE https://cve.mitre.org/index.html.

Para la máquina con Metasploitable en la red virtual, se identificaron las siguientes vulnerabilidades de clasificación crítica y alta:

Apache Tomcat AJP Connector Request Injection (Ghostcat): Esta vulnerabilidad permite a un atacante inyectar solicitudes maliciosas a través del conector AJP de Apache Tomcat, lo que podría resultar en la exposición de archivos confidenciales o la ejecución de código.
Bind Shell Backdoor Detection: Se trata de una detección de la presencia de una puerta trasera (backdoor) que permite a un atacante obtener acceso no autorizado al sistema comprometido.
Debian OpenSSH/OpenSSL Package Random Number Generator Weakness: Esta vulnerabilidad implica una debilidad en el generador de números aleatorios utilizado por los paquetes OpenSSH y OpenSSL en el sistema Debian, lo que podría facilitar ataques criptográficos.
Multiple Vendor DNS Query ID Field Prediction Cache Poisoning: Está relacionada con la predicción del campo de identificación en las consultas DNS, lo que podría conducir a ataques de envenenamiento de caché DNS en múltiples sistemas.
NFS Exported Share Information Disclosure: Permite la revelación de información confidencial relacionada con comparticiones de archivos exportadas a través del protocolo NFS (Network File System).
SSL Version 2 and 3 Protocol Detection: Implica la detección de las versiones obsoletas y potencialmente inseguras de los protocolos SSL (Secure Sockets Layer) en el sistema.
Unix Operating System Unsupported Version Detection: Se refiere a la detección de versiones no compatibles o desactualizadas del sistema operativo Unix, que podrían ser susceptibles a vulnerabilidades conocidas.
UnrealIRCd Backdoor Detection: Identifica la presencia de una puerta trasera en UnrealIRCd, un servidor de IRC, que podría permitir el control no autorizado del sistema.
VNC Server 'password' Password: Esta vulnerabilidad implica el uso de contraseñas débiles en un servidor VNC (Virtual Network Computing), lo que podría facilitar el acceso no autorizado.
ISC BIND Service Downgrade / Reflected DoS: Relacionada con el servicio ISC BIND DNS, esta vulnerabilidad puede ser explotada para realizar ataques de denegación de servicio (DoS) o downgrade de versiones.
NFS Shares World Readable: Esta vulnerabilidad se refiere a compartir archivos NFS que tienen permisos de lectura globales, lo que podría exponer datos sensibles.
SSL Medium Strength Cipher Suites Supported (SWEET32): Identifica la compatibilidad con suites de cifrado de fuerza media en la capa SSL/TLS, que pueden ser susceptibles a ataques de SWEET32.
Samba Badlock Vulnerability: Hace referencia a una vulnerabilidad conocida como Badlock en el servicio Samba, que podría permitir a un atacante obtener control sobre sistemas afectados.
rlogin Service Detection: Detecta la presencia del servicio rlogin, que puede tener vulnerabilidades de seguridad si no se configura adecuadamente.
rsh Service Detection: Similar a la detección del servicio rlogin, esta identificación se refiere al servicio rsh y sus posibles vulnerabilidades si se configura de manera incorrecta.

Para la red con dispositivos reales, Nessus Essentials identifico un factor de riesgo alto en el dispositivo con IP 192.168.40.245, tanto en el escaneo básico como en el avanzado. Este riesgo se debe a la versión de OpenJDK (17.0.6) instalada, la cual presenta múltiples vulnerabilidades, como se detalla en https://openjdk.org/groups/vulnerability/advisories/2023-04-18. En resumen un atacante con acceso a la red a través de http, https o tls podría:

Tener acceso no autorizado a datos accesibles
Modificar datos críticos
Causar bloqueos definitivos o recurrentes

Esta vulnerabilidad tiene varios CVE asociados: CVE-2023-21930, CVE-2023-21937, CVE-2023-21938, CVE-2023-21939, CVE-2023-21954, CVE-2023-21967, CVE-2023-21968.

Por su lado, OpenVAS en la red con dispositivos reales encontró 5 vulnerabilidades de clasificación alta. 2 de estas son asociadas a la configuración de credenciales por defecto (admin:admin) para máquinas que ejecutan OpenVAS. Las tres vulnerabilidades restantes consisten en:

Vulnerabilidad de ejecución remota de código (RCE) en VMware Spring Cloud Function: Permite a un atacante ejecutar código de forma remota en el sistema. Esto podría llevar a un acceso no autorizado y control total sobre el servidor afectado, lo que representa un grave riesgo de seguridad. CVE asociado: CVE-2022-22963.
Aceptación de suites de cifrado vulnerables a través del protocolo TLSv1.2 (SWEET32): Se ha identificado que el servicio en cuestión acepta suites de cifrado débiles a través del protocolo TLSv1.2. Entre estas suites vulnerables se encuentra TLS_RSA_WITH_3DES_EDE_CBC_SHA, que es propensa a ataques como SWEET32. Esto podría exponer la comunicación a riesgos de seguridad y se recomienda deshabilitar estas suites. CVE asociados: CVE-2016-2183, CVE-2016-6329 y CVE-2020-12872.
Vulnerabilidad de denegación de servicio (DoS) en el servidor SMB de MikroTik RouterOS: MikroTik RouterOS presenta una vulnerabilidad que permite llevar a cabo ataques de denegación de servicio (DoS) en el servidor SMB. Esto podría resultar en la interrupción del servicio y la inaccesibilidad de recursos compartidos, lo que puede afectar la operatividad de la red o sistema afectado. CVE asociado: CVE-2020-11881.

Vulnerabilidades comunes

Algunas vulnerabilidades que pueden encontrarse son:

SQL Injection: Es un ataque donde insertan código SQL malicioso en una entrada de usuario, permitiéndole manipular una base de datos y acceder o modificar datos sensibles [7].
Header Injection: Es un ataque donde insertan datos maliciosos en encabezados HTTP, lo que puede llevar a comportamientos no deseados en una aplicación web [8].
Directory Listing: Es un ataque donde se exploran directorios de un servidor web para obtener información sobre los archivos y carpetas en el servidor, lo que puede revelar información sensible [9].
Shell Injection: Es un ataque donde insertan comandos maliciosos en una aplicación web para ejecutar operaciones en el sistema operativo subyacente [10].
Cross Site Scripting (XSS): Es un ataque donde se inyectan scripts maliciosos en una página web que luego son ejecutados por los navegadores de los usuarios, permitiendo la obtención de información confidencial [11].
File Inclusion: Es un ataque donde se logra incluir archivos maliciosos en una aplicación web, a menudo aprovechando vulnerabilidades en la inclusión de archivos [12].
File Disclosure: Es un ataque sonde se accede y revela archivos sensibles o confidenciales en un servidor web, a menudo a través de vulnerabilidades de seguridad [13].
Command Execution Detection: Se refiere a la detección de intentos de ejecución de comandos maliciosos en una aplicación web para prevenir ataques como la inyección de comandos [14].
Backup Files Disclosure: Es un ataque donde se obtiene acceso a copias de seguridad de archivos sensibles, lo que puede exponer información confidencial [15].
CRLF Injection: Es un ataque donde se inserta caracteres de retorno de carro y avance de línea en datos de entrada para manipular la salida HTTP [16].
SEL Injection (Security-Enhanced Linux Injection): Es un ataque donde se explotan vulnerabilidades en el sistema SELinux para obtener acceso no autorizado a recursos del sistema [17].
XPath Injection: Es un ataque donde se manipulan consultas XPath en aplicaciones web para obtener acceso no autorizado a datos XML o realizar operaciones maliciosas [18].
SSL Medium Strength Cipher Suites Supported: Este mensaje indica que un servidor web admite suites de cifrado SSL de fuerza media, lo que podría exponer la comunicación a riesgos de seguridad. Este no es un ataque en sí, pero es un problema de configuración de seguridad [19].

Conclusiones

La seguridad de la información es esencial debido a la creciente importancia de las redes IP en la comunicación de dispositivos, lo que las convierte en un objetivo atractivo para los ataques cibernéticos.

Por ello herramientas de evaluación de vulnerabilidades como Nessus Essentials y OpenVAS desempeñan un papel crucial en la identificación y mitigación de vulnerabilidades en redes IP, sistemas operativos y aplicaciones. Estas permiten a los profesionales de seguridad y administradores de sistemas detectar debilidades antes de que los atacantes las exploten.

En el proceso de identificación de vulnerabilidades, se llevaron a cabo escaneos tanto en un entorno de máquinas virtuales como en una red real. Estos escaneos revelaron una serie de vulnerabilidades críticas, altas, medias y bajas en los dispositivos evaluados.

Es importante recordar que realizar escaneos de vulnerabilidades en una red sin autorización constituye un delito informático y puede tener graves consecuencias legales. Se enfatiza la importancia de utilizar estas herramientas de manera ética.

Referencias

[1] D. H. Guerrero. “Parte 1 - Configurando una red básica para aprender sobre gestión de vulnerabilidades”. DEV Community. Accedido el 2 de septiembre de 2023. [En línea]. Disponible: https://dev.to/djhuertasg/parte-1-configurando-una-red-basica-para-aprender-sobre-gestion-de-vulnerabilidades-4dn1

[2] “Los ciberataques suman 54.121 casos en lo que va del año y han crecido más de 20%”. Diario La República. Accedido el 7 de septiembre de 2023. [En línea]. Disponible: https://www.larepublica.co/empresas/los-ciberataques-suman-54-121-casos-en-lo-que-va-del-ano-y-han-crecido-mas-de-20-3509163

[3] “Leyes desde 1992 - Vigencia expresa y control de constitucionalidad [LEY_1273_2009]”. SECRETARÍA GENERAL DEL SENADO. Accedido el 7 de septiembre de 2023. [En línea]. Disponible: http://secretariasenado.gov.co/senado/basedoc/ley_1273_2009.html

[4] “How to install Metasploitable 2 in VirtualBox - GeeksforGeeks”. GeeksforGeeks. Accedido el 7 de septiembre de 2023. [En línea]. Disponible: https://www.geeksforgeeks.org/how-to-install-metasploitable-2-in-virtualbox/

[5] “Tenable Nessus Essentials Vulnerability Scanner”. Tenable®. Accedido el 7 de septiembre de 2023. [En línea]. Disponible: https://www.tenable.com/products/nessus/nessus-essentials

[6] “Greenbone Enterprise TRIAL 14 days for free - Greenbone”. Greenbone. Accedido el 7 de septiembre de 2023. [En línea]. Disponible: https://www.greenbone.net/en/testnow/

[7] "SQL Injection," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/7948277

[8] "Header Injection Attacks," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/5594942

[9] "Directory Listing Vulnerability in Web Servers," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/7570151

[10] "Shell Injection Attacks and Mitigation Techniques in Web Applications," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/7962300

[11] "Cross-Site Scripting (XSS) Attacks and Defenses," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/5574142

[12] "File Inclusion Vulnerabilities in Web Applications: Detection and Prevention," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/5190739

[13] "File Disclosure Vulnerabilities in Web Applications," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/7510910

[14] "Command Execution Detection in Web Applications," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/6567437

[15] "Security Risks in Web Servers: File Backups Disclosure," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/6307265

[16] "HTTP Response Splitting Attacks," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/5319394

[17] "Toward a Safer System With Security Enhanced Linux", Van‘t Oever, D., & de Wit, J. J. (2006).

[18] "XPath Injection Attacks and Defenses," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/6695912

[19] "Security Risks in SSL/TLS Implementations," IEEE Xplore, [Online]. Disponible en: https://ieeexplore.ieee.org/abstract/document/6283483

Parte 1 - Configurando una red básica para aprender sobre gestión de vulnerabilidades

Dilver Huertas Guerrero — Sun, 27 Aug 2023 04:21:06 +0000

Introducción

En este post se ponen en práctica conceptos técnicos y conocimientos básicos que son necesarios para el alistamiento de una infraestructura para la gestión de vulnerabilidades. Se realiza el despliegue de servicios inseguros (http,ftp) y seguros (https,sftp,vpn), con el objetivo de inspeccionar puertos y analizar tráfico en la red de servidores propuesta. Este laboratorio hace parte de una serie de desafíos que se irán adelantando con el fin de probar diferentes tecnologías y herramientas de hacking ético.

Desarrollo

Paso 1: Configurar la red

Para desarrollar el laboratorio se utiliza la herramienta de virtualización VirtualBox, y se configuran las máquinas en modo adaptador de puente con DHCP habilitado. Con esta configuración, cada máquina virtual se trata como una máquina separada en su red real, lo que significa que las máquinas host, cualquier máquina virtual y cualquier otro dispositivo en la red pueden comunicarse entre sí, además las máquinas virtuales tienen acceso a Internet. Para realizar la configuración requerida puede seguir la guía disponible en [1].

Se configura una red como la mostrada a continuación:

Servidor 1:

OS: Kali linux 2023.2
IP: 10.0.2.4/24

Servidor 2:

CentOS Stream 9
IP: 10.0.2.15/24

Las dos máquinas fueron descargadas del sitio https://www.linuxvmimages.com/, lo cual facilita la configuración de la red ya que vienen listas para ser importadas en VirtualBox. Para facilitar el paso de archivos entre el host y las máquinas virtuales se habilita la funcionalidad de carpeta compartida. En caso de que se no le permita acceder a la carpeta, debe agregar el usuario de cada máquina al grupo vboxsf, lo cual se hace con el comando:

sudo usermod -aG vboxsf $(whoami)

Paso 2: Verificar conectividad

Se verifica la conectividad entre los dos servidores utilizando el comando ping

Para ambos casos se observa un éxito del 100% en la transmisión de paquetes, el cual comprueba la comunicación entre servidores a través del protocolo IP enviando paquetes ICPM.

Paso 3 y Paso 4: Escaneo de puertos con NMAP

Desde el servidor 1 se realiza el escaneo a nivel local y hacia internet utilizando la herramienta NMAP.

En la ejecución se utiliza la opción -Pn, esto para indicarle a NMAP que ignore la detección de hosts y realice el escaneo sin realizar ninguna prueba de ping. Cuando se utiliza esta opción, la herramienta no intentará determinar si el host objetivo está en línea, esto significa que asumirá que el host objetivo está en línea y procederá a escanear los puertos especificados sin realizar una comprobación previa.

Nmap en LAN

En el servidor 1 se observan abiertos los puertos abiertos por XAMPP (21, 80, 443, 3306).

En el servidor 2 se observa abierto el puerto 22, el cual es utilizado por el protocolo SSH. En el puerto 9090 se observa cerrado el puerto 9090, este esta siendo utilizado por zeus, un software de balanceo de carga.

Nmap en sitios de internet

Para el sitio scanme.nmap.org se observan abiertos los puertos 22 y 25. El puerto 25 fue utilizado para la transferencia de correo, en este momento no se recomienda su uso dado que no tiene un mecanismo de seguridad. Actualmente el puerto 587 es el canal de transmisión por defecto para SMTP, ya que proporciona una transmisión segura del correo electrónico mediante el cifrado STARTTLS.

Para el sitio tryhackme.com se observan abiertos los puertos 25, 80, 443 y 8080.

Paso 5: Habilitar servicios http y ftp

Se realiza la descarga de XAMPP desde el sitio oficial https://www.apachefriends.org/download.html y se instala en el servidor 1 utilizando los siguientes comandos:

chmod +x xampp-linux-x64-8.2.4-0-installer.run
./xampp-linux-x64-8.2.4-0-installer.run

Para iniciar el servicio se utiliza el comando:

sudo /opt/lampp/lampp start services

Para comprobar que ha sido instalado con éxito utilizar el navegador e ir al localhost (127.0.0.1) como se observa en la imagen:

Con esto se realizará la interceptación de tráfico http y ftp.

Paso 6: Interceptar tráfico http con Wireshark

Para interceptar tráfico con wireshark desde el servidor 1 se utiliza la interface eth0.

Se realiza la navegación desde el servidor 2 al servidor 1, a través de la dirección web 10.0.2.4, y se explora manualmente para generar tráfico de red.

Se obtiene la traza de 177 paquetes.

Se identifica en el trafico de red el uso de los siguientes protocolos: HTTP, HTTP/XML, TCP. Como es de esperar, no hay tráfico cifrado. Adicionalmente se identifica la siguiente alerta en el tráfico TCP: "TCP window specified by the receiver is now completely full" (ver la sección de Conclusiones para el análisis).

Paso 7: Habilitar el servicio ftp

Para habilitar el servicio ftp se siguen los pasos en el manual de instalación de XAMPP disponibles en el mismo sitio web local http://localhost/dashboard/docs/transfer-files-ftp.html.

Para abrir el panel de configuración de xampp se utiliza el siguiente comando:

sudo /opt/lampp/manager-linux-x64.run

Asegurarse que el servicio ProFTPD esta corriendo como se observa en la imagen:

El usuario y contraseña son los mismos que se utilizan para acceder al servidor 1.

Paso 8: Conexión al servidor ftp utilizando lftp

Desde el servidor 2 se realiza la conexión ftp, utilizando la herramienta lftp, la cual es un cliente de línea de comandos que permite la transferencia de archivos a través de múltiples protocolos.
En la imagen se observa el uso de lftp:

Paso 9: Interceptar tráfico ftp

Para interceptar el tráfico ftp se utiliza Wireshark. Se crea un directorio test y después se borra para generar tráfico de red como se observa en la imagen:

Se identifica el uso de los protocolos: ARP, DHCP, DNS, FTP, FTP-DATA, TCP y TLSv1.2.

Se observa que el usuario y contraseña van en texto plano a través del protocolo FTP:

Igualmente se conocen los comandos ejecutados por el usuario:

El protocolo FTP permite conocer todo lo que realice el usuario ya que va en texto plano, por lo cual nunca debe ser utilizado en un servicio real.

Paso 10: Interceptar tráfico en una VPN

Para este paso se realiza la configuración de 2 VPN, la primera desde el servidor 1 hacia internet utilizando winscribe https://windscribe.com/ y la segunda entre los servidores de la red local utilizando openvpn https://openvpn.net/.

Interceptar tráfico desde el servidor 1 hacia internet

Con windscribe se establece una conexión vpn, como se observa en la imagen:

Windscribe ofrece los protocolos: Wireguard, UDP, TCP, Stealth y WStunnel. Para mayor información sobre el protocolo wireguard consultar la página https://www.wireguard.com/.

En wireshark se observa el uso de los protocolos: ARP, TCP, TLSv1.2 y Wireguard. Probando la conexión a un sitio internet inseguro (http), vemos que en wireshark que no se ve esa conexión.

Todo el tráfico queda encapsulado en el protocolo Wireguard.

Establecer el canal seguro entre servidores locales

Para configurar la vpn se utiliza OpenVPN. El servidor 1 como server y el servidor 2 como cliente siguiendo la guía disponible en [2].

Se configura el servidor VPN como se muestra en la imagen.

Los parámetros de configuración son:

Dirección IP: 10.0.2.4
Puerto: 1194
Protocolo: UDP
DNS: /etc/resolv.conf

Del lado del cliente se debe instalar EPEL en CentOS, para lo cual se sigue la guía disponible en [3]. EPEL es un repositorio de software con aplicaciones de terceros para sistemas Red Hat y derivados.

Para instalar el gestor de red se utiliza el comando:

sudo dnf install NetworkManager-openvpn

Para ejecutar la conexión vpn se utiliza el comando:

sudo openvpn /etc/openvpn/client/client.conf

En la imagen se observa que la conexión vpn se realizo de manera exitosa (Initialization Sequence Completed).

Interceptar tráfico http y ftp

En la interceptación de tráfico ftp se observa que se utilizan los protocolos ARP, DNS, OpenVPN, SSL, TCP, TLSv1.2 y TLSv1.3. Por lo cual el tráfico FTP va encapsulado en el protocolo OpenVPN.

En la interceptación de trafico http se observa que se utilizan los protocolos ARP, DHCP, ICMPv6, OpenVPN y SSL. Por lo cual el tráfico HTTP va encapsulado en el protocolo OpenVPN.

Paso 11 y 12: Establecer conexiones seguras HTTPS y SFTP, e interceptar el tráfico

HTTPS

Para establecer la conexión https se sigue la guía disponible en [4]. Se configura como se muestra en la imagen:

Los parámetros de configuración del certificado son:

Country Name: CO
State or Province Name: Antioquia
Locality Name: Medellin
Organization Name: ITM
Common Name: localhost

Al probar la conexión https desde el servidor 2, se observa que el certificado utiliza el protocolo TLS 1.3 con cifrado AES 128.

Al interceptar el trafico se observa el uso de los protocolos TCP y TLSv1.3. Se observa también la alerta "TCP Window Full".

SFTP

Para establecer la conexión sftp, se utilizo la guía disponible en [5]. En la imagen se observa la conexión utilizando el comando sftp.

Con wireshark se observa el uso de los protocolos ARP, DHCP, SSH y TCP.

Conclusiones

A lo largo del ejercicio se observa que es posible establecer una red para realizar la prueba de protocolos inseguros y seguros, además de ver el tráfico e identificar vulnerabilidades utilizando software libre.

Se muestra que el uso de protocolos inseguros como http y ftp debe evitarse, ya que el tráfico puede ser interceptado y leído dado que se encuentra en texto plano. Esto inclusive en servicios que se utilicen solamente dentro de una red local, ya que un atacante que penetre las medidas de seguridad perimetrales podría hacer fácil uso de los datos.

La alerta "TCP window specified by the receiver is now completely full" se refiere a una condición que ocurre en una conexión TCP cuando el receptor del tráfico informa al emisor que su ventana de recepción está completamente llena. Esto significa que el receptor no puede aceptar más datos en ese momento porque su memoria para almacenar los datos entrantes está llena.

En términos de ciberseguridad, esta alerta puede ser útil para identificar posibles problemas de congestión en la red o incluso ataques de denegación de servicio (DoS) en los que un atacante podría inundar una conexión TCP. En algunos casos, esta alerta podría indicar una vulnerabilidad en la forma en que un sistema maneja los datos entrantes, lo cual podría ser utilizado para ejecutar código malicioso en el sistema receptor o realizar otras acciones maliciosas. En un ataque avanzado, una ventana de recepción llena podría utilizarse como parte de una cadena de ataques para aprovechar debilidades en la infraestructura de red y sistemas.

Tanto el uso de una VPN como la implementación de conexiones seguras (HTTPS y SFTP) utilizando certificados tienen sus propias ventajas y desventajas. La elección dependerá de los requisitos específicos de seguridad y el contexto de uso.

Una VPN cifra todo el tráfico entre el cliente y el servidor, protegiendo múltiples tipos de tráfico, no solo HTTP y FTP, lo que la hace útil para aplicaciones más diversas. Permiten el acceso seguro a redes internas desde ubicaciones remotas y puede ocultar la dirección IP real del usuario, proporcionando cierto grado de anonimato. Sin embargo pueden ser complejas de configurar y mantener, requieren recursos técnicos y suelen implicar costos adicionales en términos de hardware, software y recursos humanos. Además el tráfico puede sufrir cierta degradación del rendimiento debido al cifrado y la encapsulación.

Las conexiones seguras (https y sftp) están diseñadas específicamente para proteger tipos de tráfico individuales, lo que puede llevar a un rendimiento mejorado en comparación con una VPN. Son ampliamente adoptados y admitidos por la mayoría de los navegadores y aplicaciones de servidor FTP. Por otro lado, deben ser configurados individualmente y no ocultan la dirección IP real del usuario, por lo que no proporcionan anonimato.

A través del ejercicio se estableció un proceso paso a paso que buscar servir de guía a cualquier entusiasta de la ciberseguridad, y que servirá de base para la ejecución de laboratorios posteriores.

Referencias

[1] "Cómo conectar en red dos máquinas virtuales con VirtualBox - Noticias Movil". Noticias Movil. https://noticiasmoviles.com/como-conectar-en-red-dos-maquinas-virtuales-con-virtualbox/ (accedido el 27 de agosto de 2023).

[2] alu. "How to set up a Linux VPN server (Beginner’s Guide)". Average Linux User. https://averagelinuxuser.com/linux-vpn-server/ (accedido el 27 de agosto de 2023).

[3] "How to enable the EPEL repository in CentOS 9 Stream". Unix / Linux the admins Tutorials. https://unixcop.com/enable-epel-repository-centos-9-stream/ (accedido el 27 de agosto de 2023).

[4] "XAMPP: uso de certificados SSL en localhost - Syloper". Syloper | Desarrollo de software a medida. https://www.syloper.com/blog/servidores/xampp-certificados-ssl-localhost/ (accedido el 27 de agosto de 2023).

[5] "Cómo instalar y utilizar SFTP en servidores Linux - HowtoForge". HowtoForge. https://howtoforge.es/como-instalar-y-utilizar-sftp-en-servidores-linux/ (accedido el 27 de agosto de 2023).