Hackeando WordPress para Asegurarlo

Hackeando WordPress para Asegurarlo

SPEAKER-PONENTE: Nahúm Deavila
Los ataques dirigidos a servicios web han aumentado numerosamente durante el año 2020. Cada día los cibercriminales encuentran nuevas maneras de obtener acceso no autorizado a sistemas informáticos con el objetivo de manipular la información a su favor. WordPress como uno de los CMS mas utilizados, es un blanco bastante atractivo para los cibercriminales.

Durante la charla aprenderás las principales técnicas utilizadas para hackear WordPress, así como las recomendaciones necesarias que brindaran un nivel de seguridad adicional a tus sitios web. No hay mejor manera de defenderse, que saber cómo atacara tu enemigo.

E855c170c9b2e395b96cfda6da12d8b5?s=128

WordPress Medellín

June 30, 2020
Tweet

Transcript

  1. Hackeando WordPress para Asegurarlo “Aprende como atacará tu enemigo para

    protegerte”
  2. root@user:~# whoami Nahúm Deavila root@user:~# sudo shutdown -h +60 •

    Presidente de la Corporación iSecurity Summit Colombia • Analista de Malware • Consultor e Instructor en Seguridad Informática • Asesor en Ciberseguridad del Sector Eléctrico
  3. Hacker (Hollywood) VS Hacker (Real)

  4. ¿Es Seguro WordPress?

  5. ¿Qué hace tan atractivo a WordPress? • 37% de todos

    los sitios web del mundo. • 62% del mercado de CMS. • +34.000 Plugin. • +12.000 Temas. • 37 millones de búsquedas al mes. • 51 idiomas de traducción.
  6. Datos Importantes en la Seguridad • No existe un sistemas

    totalmente seguro. • En algún momento han intentado hackearte. • Las pruebas de seguridad son necesarias. • Todos los días hay nuevas vulnerabilidades. • Toda la información es importante.
  7. Ataques Web más comunes • Fuerza Bruta • Phishing •

    Aprovechamiento de Vulnerabilidades • Ataques DoS y DDoS • Inyección de código • Interceptación de peticiones
  8. None
  9. A1: Inyección Cualquier fuente de datos puedes ser un vector

    de inyección: - Variables de entorno - Parámetros - Servicios web externos - Usuarios Tipos de inyección: - SQL - NoSQL - LDPAD - XPath - Comandos del SO - Analizadores XML - Encabezados SMTP - Consultas ORM “Cuando un interprete recibe información dañina de un atacante”
  10. ¿Cuándo es vulnerable? 1. Los datos ingresados por un usuario

    no son sanitizados. 2. Se realizan consultas dinámicas o no parametrizadas, sin codificar los parámetros. 3. Se utilizan datos dañinos para para extracción de registros sensibles.
  11. ¿Cómo puedo Mitigarlo? • Utilizar un API segura con interfaz

    parametrizada. Mediante parámetros EXECUTE IMMEDIATE o exec() • Validación de datos de entrada en el servidor. Muchas aplicaciones requieren de caracteres especiales. Pueden existir AÚN la inyección. • Utilizar LIMIT y controles SQL para evitar fuga de registros.
  12. A2: Perdida de Autenticación Vectores en validación de sesión en

    cualquier plataforma: - Fugas de información. - Ataques de diccionario. - Controles de acceso débiles. “Factores de autenticación únicos o muy débiles para el usuario”
  13. ¿Cuándo es vulnerable? 1. Contraseñas débiles, por defecto o muy

    conocidas. 2. Expone IDs en las URL. 3. Procesos débiles de recuperación de contraseñas. 4. Almacenamiento de contraseñas en plano o Hashing débiles.
  14. ¿Cómo puedo Mitigarlo? • Añadir factores de autenticación doble para

    los usuarios. • Limitar el numero de intentos y notificar al administrador. • Utilizar IDs aleatorios con gestores de sesión.
  15. A3: Exposición de Datos Sensibles Extracción de información relevante para

    el atacante: - Ataques MITM - Robo de datos en texto plano Buscaran: - Claves - Tarjetas de crédito - Datos personales - Registros importantes “El atacante interceptara todo el tráfico en busca de información valiosa”
  16. ¿Cuándo es vulnerable? 1. Transmisión de datos en texto plano.

    2. Algoritmos criptográficos débiles. 3. Reutilización de claves generadas automáticamente.
  17. ¿Cómo puedo Mitigarlo? • Cifrar los datos sensibles al almacenarlos.

    • Clasificación de datos almacenados, procesados o transmitidos. • Utilizar algoritmos o protocolos estándares y fuertes con buena gestión de claves.
  18. A7: Cross-Site Scripting (XSS) Ejecutar secuencias de comandos en el

    navegador de la victima: - XSS Reflejado - XSS Almacenado - XSS Basado en DOM Es posible: - Redirección - Inyección de Malware - Reemplazo de nodos DOM - Ataques al lado del cliente “Puede haber robo de sesión o evasión de autenticación de múltiple factor”
  19. XSS Reflejado XSS Almacenado • Se utilizan datos sin validar

    codificados en el HTML o JS de salida. • Debe haber interacción del usuario con el enlace que contiene el código. • El atacante ejecutara comandos en el navegador de la victima. • Almacena datos sin validar ni sanear. • Cualquier usuario que ingrese a la pagina afectada será victima. • El código inyectado se almacenará hasta ser removido en la pagina.
  20. ¿Cómo puedo Mitigarlo? • Utilizar frameworks seguros para codificación de

    contenido (Ruby o React JS) • Codificar los datos de requerimientos HTTP en campos de salida de HTML. • Revisar el CheatSheet de XSS en OWASP.
  21. A9: Uso de Componentes Vulnerables El atacante buscara el eslabón

    mas débil de la cadena en tu web. “Los Plugins suelen ser la causa principal de vulnerabilidades en WordPress”
  22. ¿Cuándo es vulnerable? 1. No se conocen las versiones de

    todos los componentes de la Web. 2. No hay soporte o actualizaciones para el software vulnerable. 3. No existen programas periódicos de análisis. 4. No se aplican los parches de seguridad a tiempo ni configuraciones básicas.
  23. ¿Cómo puedo Mitigarlo? • Eliminar componentes innecesarios o con uso

    demasiado reducido. • Instalar componentes exclusivamente de sitios oficiales mediante canales seguros. • Monitorear y análisis constantemente todos los componentes del sitio.
  24. Más Información… 1. Guía de Desarrollo Seguro de OWASP. 2.

    OWASP TOP 10 – Versión 2017. 3. Estándar de Verificación de Seguridad. 4. CheatSheet para Prevención de XSS. 5. Guia de pruebas de seguridad para Moviles.
  25. ¿Qué tan preparado estas para un ataque?

  26. None
  27. None
  28. ¿Por qué hackear un sitio web?

  29. Conseguir información privilegiada Almacenar Malware Crear Phishing Hacktivismo Diversión Reto

    Personal
  30. ¿Qué tan fácil es hackear un sitio web?

  31. Posibles escenarios… 1. Selección al azar. 2. Búsqueda de Vulnerabilidades.

    3. Ataque dirigido.
  32. Selección al Azar… • Análisis del estado de seguridad general.

    • Sector de interés. • Resultados esperados. • Masividad de selección DORKS Combinación de operadores y caracteres especiales para búsquedas selectivas en motores de indexación.
  33. Búsqueda de DORK Web cumple con requisitos Aprovechamiento de fallo

    - Defacement Web - Exfiltración de información - Modificación de datos - Encriptación del servidor - Incrustación de Phishing - Añadir a Botnet
  34. Búsqueda de Vulnerabilidades… Búsqueda de DORK Web cumple con requisitos

    Explotación de Vulnerabilidad Búsqueda de Exploit Pagina Web Hackeada
  35. ¿Como Funciona un Ataque Dirigido? www.mipagina.com Análisis general Segmentación de

    componentes débiles Punto de quiebre Cadena de Suministro Planeación del ataque Sitio Comprometido
  36. Para tener en cuenta… • Afectación al SEO • Suspensión

    de Hosting o dominio • Listas negras • Mala reputación de la marca • Exposición de información o datos • Secuestro de servidores
  37. Síndrome del Super Desarrollador Malo ¡Soy el mejor desarrollador! Mi

    información no es importante
  38. None
  39. None
  40. ¿Cómo Puedo Asegurar mi WordPress?

  41. Leyes del Aseguramiento - Mínimo punto de exposición - Mínimo

    privilegios posibles - Defensa en profundidad
  42. Sistema Operativo Base de Datos Plataforma Usuarios

  43. “Si eres de los que piensa que no tienes nada

    que le interese a un atacante entonces ya estás hackeado”
  44. Actualiza No es para colores y diseños más bonitos... No

    te olvides de PHP
  45. Usuarios Nada de “admin” por favor...

  46. Permisos Si ella te pide 777 déjala ir mejor...

  47. Mínimo Privilegio Configuraciones mínimas...

  48. Protección del Login Que el HTTPS sea tu aliado...

  49. Protección del “admin” Listas blancas o control de acceso...

  50. Nada de “Hackers” Plugins, temas, etc...

  51. Protección Local Vector de ataque importante...

  52. ¿Hosting “Free”? No existe nada gratis...

  53. Contraseñas ¿Cumpleaños o aniversario?

  54. F2A ¿Que carajos es eso?

  55. None
  56. Backups Primero te cansaras tú...

  57. Sentido Común El más importante...

  58. ¿Auditar o Hackear?

  59. ¿Es realmente importante? ¿pierdo el tiempo?

  60. Herramientas WP Doctor • Seguridad • Velocidad • Mejoraras

  61. None
  62. None
  63. None
  64. Enumeración de usuarios

  65. None
  66. No todos los controles son “buenos”

  67. 1.Validación de Proyecto WordPress 2.Asignación de Permisos 3.Eliminación de Componentes

    4.Creación de robots.txt 5.Eliminación de Fingerprinting 6.Búsqueda de librerías TimThumb 7.Generador de Archivo de Configuración 8.Eliminación de Versión 9.Plugins de Seguridad 10.Creación de archivos Index 11.Escaneo de Malware
  68. ¡Me han Hackeado! ¿Qué hacer?

  69. Entonces… ¿Es seguro WordPress?

  70. Espera… ¡Quiero saber más!

  71. ¿Preguntas? Nahúm Deavila nahum@isecuritysummit.org +57 300 216 3332 @nahumdeavila @c14it0n