Hola, es algún tipo de trabajo ético donde hay algún contrato en medio?
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#1
Dudas y pedidos generales / Re:Buscando a un técnico en penetración o pentesting
Agosto 25, 2023, 06:51:52 PM #2
Dudas y pedidos generales / Re:Ciberseguridad
Junio 26, 2023, 06:35:58 PMNo tienes permitido ver enlaces. Registrate o Entra a tu cuentainformativo, quiero arrancar con ciberseguridad
Primero enfócate en el área de la ciberseguridad que quieras aprender, por ejemplo: Desarrollo de aplicaciones, Bases de Datos, Redes y sistemas, IA, etc. Cuando aprendas y seas hábil en alguna de esas áreas entonces comienza a preocuparte por la ciberseguridad ya que no puedes entender un problema si no sabes porqué se produce, es como querer aprender a encontrar fallas a los motores de automóviles sin saber mecánica.
Saludos.
#3
Dudas y pedidos generales / Re:recomendaciones web scraping
Junio 15, 2023, 09:45:54 PM
Te recomiendo dos cosas, aprender nodejs y Aqua intelij.
Saludos.
Saludos.
#4
Noticias Informáticas / ChatGPT expone conversaciones de otros usuarios
Mayo 20, 2023, 04:31:24 PM
Hola, acá les dejo un artículo que hice sobre cómo ChatGPT expone conversaciones de otros usuarios:
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
En este artículo se expone cómo ChatGPT expone información confidencial accediendo al espacio de la memoria cache manipulada por la misma IA, evadiendo controles de seguridad básicos que fueron entrenados en el mismo lenguaje.
Saludos.
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
En este artículo se expone cómo ChatGPT expone información confidencial accediendo al espacio de la memoria cache manipulada por la misma IA, evadiendo controles de seguridad básicos que fueron entrenados en el mismo lenguaje.
Saludos.
#5
Dudas y pedidos generales / Re:ayuda laptop ordenador bloqueado
Abril 23, 2023, 08:20:25 PM
Kali no es un sistema productivo y estable como para ser instalado en un equipo y hacer uso diario de el, kali está diseñado para tareas de pentesting usando la portabilidad, si quieres instalar un sistema como corresponde en tu equipo te recomiendo un sistema productivo que esté diseñado para trabajar de manera instalada como por ejemplo ubuntu, fedora o arch. Recuerda que kali está basado en ubuntu pero con modificaciones y paquetes inestables y con poco soporte para hardware moderno, por eso te recomiendo mejor usar ubuntu e instalar las herramientas que necesites vía apt ya que en la práctica jamás utilizarás todas las herramientas que viene instalado, por eso su filosofía es ser portable, para que tengas todo lo que puedas necesitar pero no para que lo tengas instalado haciendo espacio.
Otra posibilidad es que lo uses virtualizado, pero si tienes pocos recursos de ram y cpu puedes usar la imagen de docker: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta , ya que esta imagen no se virtualiza, simplemente se ejecuta en jail reutilizando tu mismo kernel, asi que no ocupará mas memoria ni cpu de lo que tu equipo ya está utilizando actualmente, simplemente instalas la imagen, creas un contenedor, lo hechas a correr y ejecutas su shell y listo, ahi tendrás todas las herramientas de kali disponible en cualquier distribución de linux, aunque por temas de performance te recomiendo mejor que instales los paquetes que necesitas en tu sistema base solamente.
Si aun te quedan dudas mira este video:
Otra posibilidad es que lo uses virtualizado, pero si tienes pocos recursos de ram y cpu puedes usar la imagen de docker: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta , ya que esta imagen no se virtualiza, simplemente se ejecuta en jail reutilizando tu mismo kernel, asi que no ocupará mas memoria ni cpu de lo que tu equipo ya está utilizando actualmente, simplemente instalas la imagen, creas un contenedor, lo hechas a correr y ejecutas su shell y listo, ahi tendrás todas las herramientas de kali disponible en cualquier distribución de linux, aunque por temas de performance te recomiendo mejor que instales los paquetes que necesitas en tu sistema base solamente.
Si aun te quedan dudas mira este video:
#6
Dudas y pedidos generales / Re: Duda con código en JQuery
Febrero 13, 2023, 04:28:45 PM
Hola, no deberías estar estudiando sobre tecnología obsoleta, hace muchos años que se dejó de usar jquery, por ahi por la época de flash cuando apareció html5. Deberías aprender a utilizar javascript puro a traves de la manipulación del DOM.
De todas maneras tu código tienes malas prácticas y tiene XSS ya que "'<tr id="row'+p+'">..." la variable "p" no está escapada en htmlentities por lo cual puede ser susceptible a XSS y tener problemas de seguridad, en ves de eso debes fabricar los nodos con document.createElement y asignarle el valor con innerText ya que el DOM de javascript escapa de forma automática los valores y propiedades, escribir html dentro de javascrpt en texto plano es una muy mala práctica, en los años 2000 se hacía eso pero hoy se recomienda utilizar nodos y templates, por ejemplo:
Tampoco deberías utilizar ajax, hoy en día existe el estandar ES6 y tienes disponible la función fetch asincrónica, no necesitas agregar carga adiconal al navegador, hoy en día los navegadores están muy estandarizados, ya no se necesitan frameworks como jquery cuando se usaba internet explorer 6.
De todas maneras tu código tienes malas prácticas y tiene XSS ya que "'<tr id="row'+p+'">..." la variable "p" no está escapada en htmlentities por lo cual puede ser susceptible a XSS y tener problemas de seguridad, en ves de eso debes fabricar los nodos con document.createElement y asignarle el valor con innerText ya que el DOM de javascript escapa de forma automática los valores y propiedades, escribir html dentro de javascrpt en texto plano es una muy mala práctica, en los años 2000 se hacía eso pero hoy se recomienda utilizar nodos y templates, por ejemplo:
Tampoco deberías utilizar ajax, hoy en día existe el estandar ES6 y tienes disponible la función fetch asincrónica, no necesitas agregar carga adiconal al navegador, hoy en día los navegadores están muy estandarizados, ya no se necesitan frameworks como jquery cuando se usaba internet explorer 6.
#7
Noticias Informáticas / Re: Microsoft Teams almacena tokens de autentificación en texto claro
Septiembre 14, 2022, 11:56:11 PM
Estoy de acuerdo con la resolución de Microsoft, utilizar un navegador web no lo hará menos riesgoso que utilizar la aplicación ya que los tokens de intercambio y las cookies de sesión también se almacenan en archivos que son fáciles de obtener si tienes acceso al equipo físico.
Este no es un problema de la aplicación como tal sino del Sistema Operativo ya que a diferencia de otros sistemas como Android, iOS, OSX, Linux con Flathub o Snap, las aplicaciones no se encuentran aisladas ni existe un bus de comunicación transversal entre ellas, por lo cual cualquier malware que infecte a un equipo windows podría escalar a obtener cualquier información de cualquier aplicación instalada por el usuario, pero eso es un problema de diseño de Windows y no de la aplicación de Teams ya que lo mismo se podría decir de casi cualquier aplicación de escritorio ya que por mas resguardo o encriptación tengan los datos almacenados se van a tener que desencriptar en algún momento y la llave debería almacenarse dentro del mismo espacio de la aplicación, por lo cual, aunque los datos se encuentren encriptados la llave para desencriptar seguiría expuesta, asi que no hay sentido de aplicar una encriptación a nivel de almacenamiento a menos que exista un sistema de gestión seguro de claves como es el caso del keyring de OSX, Android, iOS o Gnome y Kade en Linux.
Por este mismo motivo los archivos de la aplicación de Gmail, configuraciones de IIS, ODBC y similares no tienen un mecanismo de encriptación nativo de datos de resguardo en disco y en SQL Server es completamente opcional, por lo cual, que no venga habilitado de fábrica no lo hace inmediatamente una aplicación vulnerable, lo mismo sucede con la encriptación de disco a nivel de sistema operativo, como es el caso de Windows cuando encripta el directorio del usuario o en Linux cuando se encripta el home de manera nativa a traves de Luks, que estos sistemas de cifrado de disco no vengan habilitados por defecto no quiere decir que inmediatamente deban tener un CVE asignados.
Creo que el equipo de ciberseguridad de Vectra Protect no tiene muy claro sus definiciones de seguridad aplicativa. Esto es similar a cuando abres las herramientas de desarrollo del navegador WEB y puedes ver tus contraseñas en texto plano viajando en la pestaña de red, eso es normal porque eres tu mismo el que tiene acceso a tu propio equipo y a tu propio navegador, sería diferente si un atacante pudiera tener acceso a observar ese tráfico de manera remota a traves de alguna vulnerabilidad del navegador WEB o del mismo sitio WEB, en este caso sería una vulnerabilidad si un atacante lograse obtener los tokens de intercambio de la aplicación de Teams de forma remota a traves de alguna vulnerabilidad propia de Teams, pero no es así, primero se requiere escalar privilegios y vulnerar el propio Sistema Operativo y luego acceder a los datos de cualquier aplicación instalada, por lo cual, tanto el riesgo de la vulnerabilidad como el resguardo de los datos pertenecen a una capa inferior la cual le corresponde al propio Sistema Operativo y no a la aplicación como tal, lo que si se puede hacer es hardenizar a modo de disminución de riesgo pero nunca podrás evitar que roben la sesión de una aplicación si ya estás infectado y el atacante ya tiene acceso a tu equipo.
Este no es un problema de la aplicación como tal sino del Sistema Operativo ya que a diferencia de otros sistemas como Android, iOS, OSX, Linux con Flathub o Snap, las aplicaciones no se encuentran aisladas ni existe un bus de comunicación transversal entre ellas, por lo cual cualquier malware que infecte a un equipo windows podría escalar a obtener cualquier información de cualquier aplicación instalada por el usuario, pero eso es un problema de diseño de Windows y no de la aplicación de Teams ya que lo mismo se podría decir de casi cualquier aplicación de escritorio ya que por mas resguardo o encriptación tengan los datos almacenados se van a tener que desencriptar en algún momento y la llave debería almacenarse dentro del mismo espacio de la aplicación, por lo cual, aunque los datos se encuentren encriptados la llave para desencriptar seguiría expuesta, asi que no hay sentido de aplicar una encriptación a nivel de almacenamiento a menos que exista un sistema de gestión seguro de claves como es el caso del keyring de OSX, Android, iOS o Gnome y Kade en Linux.
Por este mismo motivo los archivos de la aplicación de Gmail, configuraciones de IIS, ODBC y similares no tienen un mecanismo de encriptación nativo de datos de resguardo en disco y en SQL Server es completamente opcional, por lo cual, que no venga habilitado de fábrica no lo hace inmediatamente una aplicación vulnerable, lo mismo sucede con la encriptación de disco a nivel de sistema operativo, como es el caso de Windows cuando encripta el directorio del usuario o en Linux cuando se encripta el home de manera nativa a traves de Luks, que estos sistemas de cifrado de disco no vengan habilitados por defecto no quiere decir que inmediatamente deban tener un CVE asignados.
Creo que el equipo de ciberseguridad de Vectra Protect no tiene muy claro sus definiciones de seguridad aplicativa. Esto es similar a cuando abres las herramientas de desarrollo del navegador WEB y puedes ver tus contraseñas en texto plano viajando en la pestaña de red, eso es normal porque eres tu mismo el que tiene acceso a tu propio equipo y a tu propio navegador, sería diferente si un atacante pudiera tener acceso a observar ese tráfico de manera remota a traves de alguna vulnerabilidad del navegador WEB o del mismo sitio WEB, en este caso sería una vulnerabilidad si un atacante lograse obtener los tokens de intercambio de la aplicación de Teams de forma remota a traves de alguna vulnerabilidad propia de Teams, pero no es así, primero se requiere escalar privilegios y vulnerar el propio Sistema Operativo y luego acceder a los datos de cualquier aplicación instalada, por lo cual, tanto el riesgo de la vulnerabilidad como el resguardo de los datos pertenecen a una capa inferior la cual le corresponde al propio Sistema Operativo y no a la aplicación como tal, lo que si se puede hacer es hardenizar a modo de disminución de riesgo pero nunca podrás evitar que roben la sesión de una aplicación si ya estás infectado y el atacante ya tiene acceso a tu equipo.
#8
Ideas y Sugerencias / Re: Laburos en IT
Septiembre 14, 2022, 05:29:58 PM
Me parece super buena idea, de hecho debería existir un subforo solo para eso, a muchos les servirían.
#9
Seguridad web y en servidores / Re: XSS por POST
Septiembre 12, 2022, 01:12:54 PMNo tienes permitido ver enlaces. Registrate o Entra a tu cuenta
muy bueno,
pero entonces lo que quieres decir es que por el formulario normal no se puede poner el xss?
solo es capturando el valor con el tamperdata?
Un XSS es independiente si va via get, post, put, delete, etc, tampoco depende de un software en particular, de hecho un atacante no necesita que todas sus victimas tengan instalado el tamper data o el burpsuite, lo que importa es lo que el servidor recibe y lo que retorna, en otras palabras lo único que hay que hacer es que alguien pueda enviar involuntariamente una solicitud http (sin importar el método) y que en algún input pueda contener algún código malicioso que pueda ser retornado por el servidor con cabecera content type de tipo html, entonces, por ejemplo, podrás enviar una etiqueta <script> para que te lo retorne el mismo servidor y esta se ejecute, esto permite que si un usuario accede a algún html tuyo y este tiene instrucciones de redireccionar al usuario hacia una url (sin importar si es get o post) su navegador pueda ejecutar la instrucción que tu desees, como por ejemplo, obtener la cookie de sesion y enviarla hacia otro servidor si es que la cookie lo permite (debido al flag httponly).
Dale un vistazo a estos links:
- No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
- No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
#10
Seguridad web y en servidores / Re: express.js vs apache2
Septiembre 12, 2022, 01:01:53 PM
Hola, de todas maneras te conviene más nodejs, por otro lado no te vas a salvar de utilizar apache o nginx ya que para publicar servicios productivos en node necesitas hacerlo pasar por un proxy inverso productivo, en otras palabras, no puedes exponer un servicio express directamente hacia internet ya que sería una falta de seguridad importante debido a que express no es un servidor web productivo como si lo es apache o nginx, express no tiene todas las consideraciones de seguridad necesarias como por ejemplo la cantidad de conexiones máximas soportadas por ip o multifork.
Por otro lado, con respecto a php v/s node, la gran mayoria de las empresas hoy en dia abandonaron php en pos de nuevas arquitecturas modernas (o semi modernas porque ya llevan muchos años) como el uso de microservicios o en conjunto a una arquitectura hexagonal dependiendo de la escalabilidad y disponibilidad que se necesite, mas aun cuando se habla de servicios en la nube, en estos casos lo más utilizado y la mejor desicion es el uso de nodejs o java spring en conjunto a otras tecnologías de apoyo. php es un lenguaje que no fue diseñado para los tiempos de hoy, si se utiliza mucho pero no es un lenguaje moderno, es como perl, aun se usa pero no es un lenguaje para crear grandes aplicaciones productivas.
Un ejemplo muy práctico es que en el módulo de php para apache cada ves que un usuario quiere solicitar ver la pagina principal este llama al índice de php y este incluye las dependencias de conexión a la base de datos, carga el core de la aplicaicón con un monton de librerias más, filtros, procesadores, carga de modelos de datos, etc, al final terminas cargando a la memoria ram decenas de archivos php por cada peticion http, eso debes multiplicarlo por la cantidad de visitas que tengas, imagina una conexion a la db con decenas de consultas sql con una decena de carga de archivos y luego liberar todo eso al finalizar el script, php depende demasiado del uso del disco duro y de la red, el uso de io, cpu y memoria ram es exageradamente alta con respecto a cualquier otro lenguaje, por ejemplo, nodejs se ejecuta y carga en memoria todas las clases y modulos una única ves, luego por cada petición http solamente las ejecuta, pero no las tiene que volver a cargar o a definir, lo mismo sucede con aplicaciones java, python, etc, por ejemplo, para montar un sitio web informativo para una empresa que tiene una cantidad de visitas moderadas necesitas una maquina de por lo menos 1gb de memoria ram únicamente para hacer funcionar wordpress, en cambio una pagina informativa en node o en java te puede costar no mas de 50 o 100 mb de ram, a demás php no tiene soporte multithread, tampoco tiene un sistema de paquetes moderno y de gran uso como npm en nodejs, maven con java, pip con python o dev con dart.
En fin, por internet podrás encontrar miles de artículos sobre las deficiencias de php y yo como desarrollador de php desde hace 15 años pero también como desarrollador de nodejs y java spring desde hace como 6 años te digo que hoy en dia no vale la pena aprender php + mysql + apache, en ves de eso puedes aprender postgres o mariadb o nodejs con nosql, nginx, docker, apps client side con reactjs o angular o vue, algun framework css como bootstrap 5, etc.
Saludos.
Por otro lado, con respecto a php v/s node, la gran mayoria de las empresas hoy en dia abandonaron php en pos de nuevas arquitecturas modernas (o semi modernas porque ya llevan muchos años) como el uso de microservicios o en conjunto a una arquitectura hexagonal dependiendo de la escalabilidad y disponibilidad que se necesite, mas aun cuando se habla de servicios en la nube, en estos casos lo más utilizado y la mejor desicion es el uso de nodejs o java spring en conjunto a otras tecnologías de apoyo. php es un lenguaje que no fue diseñado para los tiempos de hoy, si se utiliza mucho pero no es un lenguaje moderno, es como perl, aun se usa pero no es un lenguaje para crear grandes aplicaciones productivas.
Un ejemplo muy práctico es que en el módulo de php para apache cada ves que un usuario quiere solicitar ver la pagina principal este llama al índice de php y este incluye las dependencias de conexión a la base de datos, carga el core de la aplicaicón con un monton de librerias más, filtros, procesadores, carga de modelos de datos, etc, al final terminas cargando a la memoria ram decenas de archivos php por cada peticion http, eso debes multiplicarlo por la cantidad de visitas que tengas, imagina una conexion a la db con decenas de consultas sql con una decena de carga de archivos y luego liberar todo eso al finalizar el script, php depende demasiado del uso del disco duro y de la red, el uso de io, cpu y memoria ram es exageradamente alta con respecto a cualquier otro lenguaje, por ejemplo, nodejs se ejecuta y carga en memoria todas las clases y modulos una única ves, luego por cada petición http solamente las ejecuta, pero no las tiene que volver a cargar o a definir, lo mismo sucede con aplicaciones java, python, etc, por ejemplo, para montar un sitio web informativo para una empresa que tiene una cantidad de visitas moderadas necesitas una maquina de por lo menos 1gb de memoria ram únicamente para hacer funcionar wordpress, en cambio una pagina informativa en node o en java te puede costar no mas de 50 o 100 mb de ram, a demás php no tiene soporte multithread, tampoco tiene un sistema de paquetes moderno y de gran uso como npm en nodejs, maven con java, pip con python o dev con dart.
En fin, por internet podrás encontrar miles de artículos sobre las deficiencias de php y yo como desarrollador de php desde hace 15 años pero también como desarrollador de nodejs y java spring desde hace como 6 años te digo que hoy en dia no vale la pena aprender php + mysql + apache, en ves de eso puedes aprender postgres o mariadb o nodejs con nosql, nginx, docker, apps client side con reactjs o angular o vue, algun framework css como bootstrap 5, etc.
Saludos.
#11
Noticias Informáticas / Vulnerabilidades críticas en SAP obliga a realizar actualizaciones de emergencia
Marzo 15, 2022, 07:04:59 PM
No tienes permitido ver enlaces.
Registrate o Entra a tu cuenta
Esto sucede principalmente debido a que SAP utiliza de manera nativa una versión vulnerable de Log4J, específicamente aquella que es vulnerable a la ejecución de código remoto debido al mal manejo del interpretador JDNI (CVE-2021-44228 o Log4Shell).
* CVE-2021-44228 de severidad crítica, con una puntuación CVSS3 de 10. Esta se debe a un fallo en las características de configuración JDNI, el cual no valida los parámetros de entrada de los mensajes o parámetros de los logs. Esto permitiría a un atacante acceder a permisos de configuración y control de los logs con el objetivo de realizar ejecución remota de código (RCE) en el sistema afectado.
* CVE-2022-24396 de severidad crítica, con una puntuación CVSS3 de 9.3. Esta vulnerabilidad se debe a un fallo en el componente de diagnóstico que permitiría a un atacante autenticado con mínimos privilegios realizar un escalamiento de privilegios u obtener información sensible.
* CVE-2022-26101 de severidad alta, con una puntuación CVSS3 de 8.2. Esta vulnerabilidad se debe a una falla en un componente desconocido el cual no valida los datos de entrada del usuario. Esto permitiría a un atacante enviar peticiones maliciosas con el objetivo de ejecutar código JavaScript (XSS).
No confundir que la vulnerabilidad Log4Shell (CVE-2021-44228) sea relativamente antigua, esto no quiere decir que algunos software aun hagan uso de el como es en el caso de SAP, en otras palabras, SAP cuenta con la vulnerabilidad reciente de que incluye este componente vulnerable.
Este riesgo es preocupante debido a que un atacante que logre acceder al servicio de SAP sin la necesidad de autenticarse podría ejecutar comandos dentro del servidor donde se encuentre esta solucón.
Pero, ¿esto quiere decir que si se encuentra dentro de una red local el riesgo disminuye?: la respuesta es si pero no lo suficiente. A lo largo de los años se han habido presedentes de ataques realizados por personal interno en diferentes compañías grandes y pequeñas en Chile y tampoco son casos aislados, este tipo de incidencias ocurren con mayor frecuencia de lo pensado.
Los desastres no curren sin más, son el resultado de una serie de sucedos que conllevan a una incidencia de proporciones mayores que pueden afectar no solamente a la contabilidad de una compañía sino también a posibles problemas legales y de pérdida de imagen corporativa.
Técnicamente hablando un atacante podría realizar una solicitud HTTP al servidor de SAP y enviar un paquete malicioso con código de ejecución, permitiendo al atacante, por ejemplo conectar a la base de datos y modificar información como credenciales de acceso o datos de contabilidad, también podría descargar software malicioso de tipo Troyano y tomar control del servidor o infectar la infraestructura con malware de tipo Ransomware.
Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.
La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.
Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Esto sucede principalmente debido a que SAP utiliza de manera nativa una versión vulnerable de Log4J, específicamente aquella que es vulnerable a la ejecución de código remoto debido al mal manejo del interpretador JDNI (CVE-2021-44228 o Log4Shell).
* CVE-2021-44228 de severidad crítica, con una puntuación CVSS3 de 10. Esta se debe a un fallo en las características de configuración JDNI, el cual no valida los parámetros de entrada de los mensajes o parámetros de los logs. Esto permitiría a un atacante acceder a permisos de configuración y control de los logs con el objetivo de realizar ejecución remota de código (RCE) en el sistema afectado.
* CVE-2022-24396 de severidad crítica, con una puntuación CVSS3 de 9.3. Esta vulnerabilidad se debe a un fallo en el componente de diagnóstico que permitiría a un atacante autenticado con mínimos privilegios realizar un escalamiento de privilegios u obtener información sensible.
* CVE-2022-26101 de severidad alta, con una puntuación CVSS3 de 8.2. Esta vulnerabilidad se debe a una falla en un componente desconocido el cual no valida los datos de entrada del usuario. Esto permitiría a un atacante enviar peticiones maliciosas con el objetivo de ejecutar código JavaScript (XSS).
No confundir que la vulnerabilidad Log4Shell (CVE-2021-44228) sea relativamente antigua, esto no quiere decir que algunos software aun hagan uso de el como es en el caso de SAP, en otras palabras, SAP cuenta con la vulnerabilidad reciente de que incluye este componente vulnerable.
Este riesgo es preocupante debido a que un atacante que logre acceder al servicio de SAP sin la necesidad de autenticarse podría ejecutar comandos dentro del servidor donde se encuentre esta solucón.
Pero, ¿esto quiere decir que si se encuentra dentro de una red local el riesgo disminuye?: la respuesta es si pero no lo suficiente. A lo largo de los años se han habido presedentes de ataques realizados por personal interno en diferentes compañías grandes y pequeñas en Chile y tampoco son casos aislados, este tipo de incidencias ocurren con mayor frecuencia de lo pensado.
Los desastres no curren sin más, son el resultado de una serie de sucedos que conllevan a una incidencia de proporciones mayores que pueden afectar no solamente a la contabilidad de una compañía sino también a posibles problemas legales y de pérdida de imagen corporativa.
Técnicamente hablando un atacante podría realizar una solicitud HTTP al servidor de SAP y enviar un paquete malicioso con código de ejecución, permitiendo al atacante, por ejemplo conectar a la base de datos y modificar información como credenciales de acceso o datos de contabilidad, también podría descargar software malicioso de tipo Troyano y tomar control del servidor o infectar la infraestructura con malware de tipo Ransomware.
Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.
La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.
Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
#12
Noticias Informáticas / Re: 1Password eleva el premio más alto de sus Bug Bounty a $ 1 millón
Marzo 13, 2022, 09:10:42 PM
El único problema es que bugcrowd tiene una pésima moderación, muy dificilmente dan una vulnerabilidad como válida, a pesar de que el vendor asuma el problema. Si estuviera en hackerone sería otra historia.
#13
Noticias Informáticas / Ejecución de código en Mozilla Firefox 97.0.2 (CVE-2022-26485)
Marzo 11, 2022, 08:58:53 PM
No tienes permitido ver enlaces.
Registrate o Entra a tu cuenta
Se publicó un problema de seguridad crítico en Mozilla Firefox 97.0.2 el cual permite la ejecución de código remoto, esto quiere decir que con tan solo visitar un sitio WEB malicioso, un atacante podría ejecutar comandos en el Sistema Operativo ya que esta vulnerabilidad también impacta en el mecanismo de seguridad de Sandboxing que protege al navegador frente a la ejecución de código.
Un usuario podría exponer todos sus datos de usuario tales como contraseñas, sesiones guardadas y datos de otras aplicaciones instaladas en el Sistema Operativo.
Mozilla ha categorizado dos vulnerabilidades asociadas con los siguientes nombres:
* CVE-2022-26485: Use-after-free in XSLT parameter processing
* CVE-2022-26486: Use-after-free in WebGPU IPC Framework
Esta vulnerabilidad aun se encuentra en entrega del puntaje CVSS, pero de todas maneras se ha confirmado la ejecución remota de código, por lo cual cabe esperar que su puntaje sea muy alto, muy cerca de 9.0 o 10.0.
Esta vulnerabilidad tiene dos impactos directos, uno se refiere a que es posible ejecutar comandos del lado del equipo del usuario y el otro es la posibilidad de escapar de la Sandbox de Mozilla Firefox, pero ¿a que se refiere?.
Ejecución de código: Use-after-free es un tipo de vulnerabilidad categorizado por la CWE que consiste en la reutilización de un puntero en memoria después de haber sido limpiada, este problema puede llevar a un atacante a inyectar bytes en memoria dentro del Sistema Operativo e indicar la ejecución de algún comando como por ejemplo el Bash del Sistema en Linux, Powershell en Windows y similares. Esto podría causar por ejemplo que un atacante indique al navegador WEB de Mozilla Firefox que descargue un ejecutable malicioso y lo ejecute sin previo aviso o consentimiento del usuario.
Evasión de la sandbox: Para evitar este tipo de problemas todo navegador WEB moderno cuenta con un mecanismo de protección de Sandboxing el cual consiste en la aislación (siolación) tanto de la memoria como del proceso, en otras palabras, cada pestaña se ejecuta en un Worker diferente, de esta manera una vulnerabilidad dentro de un proceso dificilmente podría escalar a ejecutar algo dentro del mismo Sistema Operativo, pero este mecanismo de seguridad también fue evadido. Hay que recordar que los mecanismos de Sandboxing son únicamente sistemas mitigantes que intentan evitar problemas de seguridad pero no corrigen los problemas de raiz, por lo cual es muy normal ver en distintas ocasiones como estas sandboxing son evadidas en distintos navegadores WEB.
La conclusión es que un atacante podría crear un sitio WEB malicioso o simplemente hackear alguno ya existene e ingresar y código que al ser visitado podría hacer que el usuario se infecte con un malware, por ejemplo, un Ransomware o Troyano, el cual permite al atacante tomar control y manipular el equipo de la víctima y hacer robo de información como contraseñas y datos de tarjetas bancarias.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Se publicó un problema de seguridad crítico en Mozilla Firefox 97.0.2 el cual permite la ejecución de código remoto, esto quiere decir que con tan solo visitar un sitio WEB malicioso, un atacante podría ejecutar comandos en el Sistema Operativo ya que esta vulnerabilidad también impacta en el mecanismo de seguridad de Sandboxing que protege al navegador frente a la ejecución de código.
Un usuario podría exponer todos sus datos de usuario tales como contraseñas, sesiones guardadas y datos de otras aplicaciones instaladas en el Sistema Operativo.
Mozilla ha categorizado dos vulnerabilidades asociadas con los siguientes nombres:
* CVE-2022-26485: Use-after-free in XSLT parameter processing
* CVE-2022-26486: Use-after-free in WebGPU IPC Framework
Esta vulnerabilidad aun se encuentra en entrega del puntaje CVSS, pero de todas maneras se ha confirmado la ejecución remota de código, por lo cual cabe esperar que su puntaje sea muy alto, muy cerca de 9.0 o 10.0.
Esta vulnerabilidad tiene dos impactos directos, uno se refiere a que es posible ejecutar comandos del lado del equipo del usuario y el otro es la posibilidad de escapar de la Sandbox de Mozilla Firefox, pero ¿a que se refiere?.
Ejecución de código: Use-after-free es un tipo de vulnerabilidad categorizado por la CWE que consiste en la reutilización de un puntero en memoria después de haber sido limpiada, este problema puede llevar a un atacante a inyectar bytes en memoria dentro del Sistema Operativo e indicar la ejecución de algún comando como por ejemplo el Bash del Sistema en Linux, Powershell en Windows y similares. Esto podría causar por ejemplo que un atacante indique al navegador WEB de Mozilla Firefox que descargue un ejecutable malicioso y lo ejecute sin previo aviso o consentimiento del usuario.
Evasión de la sandbox: Para evitar este tipo de problemas todo navegador WEB moderno cuenta con un mecanismo de protección de Sandboxing el cual consiste en la aislación (siolación) tanto de la memoria como del proceso, en otras palabras, cada pestaña se ejecuta en un Worker diferente, de esta manera una vulnerabilidad dentro de un proceso dificilmente podría escalar a ejecutar algo dentro del mismo Sistema Operativo, pero este mecanismo de seguridad también fue evadido. Hay que recordar que los mecanismos de Sandboxing son únicamente sistemas mitigantes que intentan evitar problemas de seguridad pero no corrigen los problemas de raiz, por lo cual es muy normal ver en distintas ocasiones como estas sandboxing son evadidas en distintos navegadores WEB.
La conclusión es que un atacante podría crear un sitio WEB malicioso o simplemente hackear alguno ya existene e ingresar y código que al ser visitado podría hacer que el usuario se infecte con un malware, por ejemplo, un Ransomware o Troyano, el cual permite al atacante tomar control y manipular el equipo de la víctima y hacer robo de información como contraseñas y datos de tarjetas bancarias.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
#14
Noticias Informáticas / Ejecución de código en Microsoft Exchange Server 2019 (CVE-2022-23277)
Marzo 11, 2022, 08:55:08 PM
No tienes permitido ver enlaces.
Registrate o Entra a tu cuenta
Se publicó un problema de seguridad crítico en Microsoft Exchange 2019 el cual permite la ejecución de código remoto, esto quiere decir que un atacante desde internet tiene la posibilidad de acceder a la información interna del servicio de correos, modificar o eliminar información, también podría ejecutar comandos sin autorización dentro del Sistema Operativo.
Desde Microsoft indican que ya existe una prueba de concepto que permite explotar esta vulnerabilidad, por lo cual pueden existir atacantes que ya lo estén aprovechando en servidores vulnerables.
El título de la vulnerabilidad indica que es posible la ejecución de código, pero ¿cómo es esto posible?: Realmente no es un problema de desbordamiento de memoria o un puntero mal gestionado, sino mas bien de elevación de privilegios debido a un problema en el control de la autorización de ciertas funcionalidades que permiten a un usuario sin privilegios tener un rol máximo permitiendo así realizar cambios sobre la consola de configuración de Microsoft Exchange y ejecutar comandos de manera directa sobre el Sistema Operativo que lo aloja.
Por lo cual ¿que podría hacer un atacante con esto?: Básicamente acceder a cualquier información alojada en el servidor ya que debemos recordar que Microsoft Exchange tiene la pésima práctica de seguridad de utilizar un usuario con privilegios elevados dentro del Sistema Operativo (NT AUTHORITYSYSTEM), en ves de ejecutarse con algún usuario restringido únicamente para Microsoft Exchange. Esto permite que un atacante no solo pueda acceder a los datos alojados sino también intentar acceder a otros servidores dentro de la misma red impactando así a la infraestructura de la compañía.
Debemos recordar también que en muchas ocaciones se envían contraseñas y documentos confidenciales por correo electrónico y todos estos datos pueden serse afectados, más aun cuando estas contraseñas son reutilizadas en otros sistemas, los cuales permitan a un atacante tomar control de toda la infraestructura de la compañía como por ejemplo, el Active Directory.
Recomendaciones a los usuarios
Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.
La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.
Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.
Como última recomendación, se debe recordar que el correo electrónico no es un canal 100% seguro, por lo cual se debe evitar el envío de credenciales o información crítica a traves de este medio, pero en caso contrario se recomienda eliminar estos correos al momento de recibirlos y realizar un limpiado periódico de los posibles mensajes que pudiesen ser perjudiciales en una filtración de datos.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Se publicó un problema de seguridad crítico en Microsoft Exchange 2019 el cual permite la ejecución de código remoto, esto quiere decir que un atacante desde internet tiene la posibilidad de acceder a la información interna del servicio de correos, modificar o eliminar información, también podría ejecutar comandos sin autorización dentro del Sistema Operativo.
Desde Microsoft indican que ya existe una prueba de concepto que permite explotar esta vulnerabilidad, por lo cual pueden existir atacantes que ya lo estén aprovechando en servidores vulnerables.
El título de la vulnerabilidad indica que es posible la ejecución de código, pero ¿cómo es esto posible?: Realmente no es un problema de desbordamiento de memoria o un puntero mal gestionado, sino mas bien de elevación de privilegios debido a un problema en el control de la autorización de ciertas funcionalidades que permiten a un usuario sin privilegios tener un rol máximo permitiendo así realizar cambios sobre la consola de configuración de Microsoft Exchange y ejecutar comandos de manera directa sobre el Sistema Operativo que lo aloja.
Por lo cual ¿que podría hacer un atacante con esto?: Básicamente acceder a cualquier información alojada en el servidor ya que debemos recordar que Microsoft Exchange tiene la pésima práctica de seguridad de utilizar un usuario con privilegios elevados dentro del Sistema Operativo (NT AUTHORITYSYSTEM), en ves de ejecutarse con algún usuario restringido únicamente para Microsoft Exchange. Esto permite que un atacante no solo pueda acceder a los datos alojados sino también intentar acceder a otros servidores dentro de la misma red impactando así a la infraestructura de la compañía.
Debemos recordar también que en muchas ocaciones se envían contraseñas y documentos confidenciales por correo electrónico y todos estos datos pueden serse afectados, más aun cuando estas contraseñas son reutilizadas en otros sistemas, los cuales permitan a un atacante tomar control de toda la infraestructura de la compañía como por ejemplo, el Active Directory.
Recomendaciones a los usuarios
Primero que nada esta vulnerabilidad ha sido solucionada hace muy poco, asi que la recomendación es muy clara, se debe actualizar el Software vulnerable lo antes posible para evitar una incidencia mayor.
La actualización de un Sistema no solamente cuenta con cambios a nivel de experiencia de usuario sino también de seguridad, por eso se recomienda mantener los sistemas y aplicaciones siempre actualizados.
Como segunda medida, como esta vulnerabilidad puede ser aprovechada de manera remota, se recomienda realizar un análisis de sistema o forense a la brevedad para determinar sin en la actualidad existió algún ataque que haya podido afectar a los datos confidenciales de los correos almacenados, si este fuese el caso se recomienda activar un procedimiento de seguridad para el cambio de credenciales de manera masiva de los sistemas de la compañía.
Como última recomendación, se debe recordar que el correo electrónico no es un canal 100% seguro, por lo cual se debe evitar el envío de credenciales o información crítica a traves de este medio, pero en caso contrario se recomienda eliminar estos correos al momento de recibirlos y realizar un limpiado periódico de los posibles mensajes que pudiesen ser perjudiciales en una filtración de datos.
Fuente: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
#15
Dudas y pedidos generales / Re: ¿Como instalar Linux en una PC con Ryzen 3 3200g?
Noviembre 04, 2021, 02:10:45 AM
Hola, cual es el error o problema que genera? tienes el mensaje de error? o se queda en blanco?, por lo general el mismo arranque de linux te dice cual es el problema y con ese identificador se puede buscar la posible solución. Hasta ahora no he sabido que linux tiene problemas con los procesadores amd, por lo contrario, en muchas comunidades linux recomiendan usar cpu amd en ves de intel por temas de compatibilidad.
#16
Dudas y pedidos generales / Re: Páginas de paga
Noviembre 02, 2021, 07:44:33 PM
Hola, no se entiende bien, pero ¿que datos te refieres?, datos de la base de datos?, del código fuente?, de archivos?, de que lugar?. El sitio es tuyo? o quieres vulnerar un sitio que no es tuyo y robarle su información?
#17
Dudas y pedidos generales / Re: HTML con css y js
Noviembre 01, 2021, 05:51:38 PM
Muy facil, agrega un padding al body de la altura igual al buscador y pon el buscador con tu position fixed al inicio de la página, esto hará que la pagina web no pueda subir mas allá que el mismo buscador.
Saludos.
Saludos.
#18
Otros lenguajes / Consultoría - Cómo solucionar un XSS
Noviembre 01, 2021, 05:29:54 PM
Bienvenidos Underc0ders!. Para dedicarse a la seguridad de manera profesional no solamente basta con saber encontrar un XSS sino también es necesario saber porque se produce y como darle una solución, ya que en muchas ocaciones nos toca hablar con el dueño de la aplicación WEB y nos pide consejos y estos no pueden estar fundados en la ignorancia. Por eso quiero comentarles como aconsejar a alguien sobre como solucionar un XSS y como darle su importancia.
Estructura
Cuando encuentras un XSS es importante saber que el dueño de la aplicación no es el experto en seguridad sino tu mismo, por lo cual el dueño puede que entienda menos de la mitad de lo que le digas, por eso es importante ser muy claro y estructurado al momento de detallar un XSS:
Generalmente en el resumen del hallazgo debes incluir el tipo de vulnerabilidad, normalmente categorizado junto al nivel de riesgo y esto lo puedes obtener a traves de diferentes estándares tales como la CVSS ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y la CWE ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) ya que será tu palabra contra el dueño de la aplicación, por lo cual siempre es buena idea apegarse a los estándares.
Recomendaciones
Acá va el problema: el cliente tiene un sitio WEB que cuenta con una vulnerabilidad de tipo XSS Reflejado ( CWE 80 No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y el cliente necesita una recomendación. He escuchado a muchas personas recomendar lo siguiente de manera equivocada:
Pero, ¿Porqué están errados?: Para comenzar, impedir o filtrar el ingreso de caracteres especiales en los campos es una recomendación demasiado genérica y va a depender del tamaño y de la arquitectura de la aplicación. Como podemos observar, el CWE es 80 ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y no 79 ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ), hay una gran diferencia ya que el CWE-79 indica que es un problema de caracteres de entrada y el CWE-80 indica que es un problema de salida.
Cuando ingresas contenido HTML en un campo y este se refleja en el código fuente resolutante de la respuesta del sitio WEB (response) entonces tenemos un problema de datos de salida y no de entrada, pero ¿porqué no filtrar los caracteres en la entrada para evitar tener problemas en los datos de salida?: porque no todas las aplicaciones funcionan igual y esto dependerá de su arquitectura, por ejemplo: Supongamos que nuestro sistema tiene una versión WEB y una version movil, si filtro los caracteres especiales en la entrada de datos para convertirlos en entidades HTML para que se guarde en la base de datos entonces cuando la aplicación móvil vaya a solicitar estos datos vendrán con escapes HTML pero las aplicaciones móviles nativas no usan HTML asi que se verán caracteres extraños basura en el contenido. No todo lo que esté en una base de datos significa que se desplegará en una aplicación WEB o móvil o de escritorio, sea nativa o híbrida, por esto es muy importante tener en mente el siguiente concepto:
Ningún dato de entrada debe ser filtrado a menos que sea un filtro de datos por concepto de definición de capa de negocio y datos, o sea, si mi valor a ingresar debe ser siempre un número positivo entonces eso si se puede filtrar, si el nombre debe tener una longitud máxima entonces esto debe ser controlado y filtrado, pero si no hay nada que impida que alguien ingrese un caracter especial en una caja de descripción entonces para que filtrar, por lo contrario, un buen desarrollo debe poder funcionar de manera segura con cualquier tipo de caracter especial, por ejemplo, este foro permite caracteres especiales para el nombre de usuario o la caja del contenido del post y no quiere decir que se deban eliminar todos los caracteres especiales para hacerlo mas seguro.
Si eres un profesional y encontraste un buen XSS pero aconsejas filtrar los campos de entrada te puede hacer quedar como ignorante en el campo del desarrollo de la solución y puede que pierdan la confianza en ti y sin que te lo digan.
¿Porqué no es bueno recomendar que se solucione del lado del WAF creando reglas que impidan los XSS?: Porque un WAF es solamente un agente mitigante pero no un solucionador de problemas, puede que para alguien sea mas dificil llegar al XSS pero el agujero de seguridad con el riesgo aun van a seguir existiendo, los riesgos se reducen pero no se eliminan, por lo cual no se considera una solución sino una mitigación y esto es parte de dos planes de trabajo: La mitigación al corto plazo y la solución al mediano/largo plazo.
Entonces, ¿cual es la mejor recomendación?:
Crear un plan de mitigación al corto plazo sonde se mitigue a traves de diferentes agentes dependiendo los que tenga el dueño de la aplicación WEB (Web Application Firewall), por ejemplo, el WAF para mitigar los ataques WEB, un Firewall para evitar la llegada de paquetes maliciosos a la infraestructura, evitar pivoting y esas cosas.
Crear un plan de solución al mediano/largo plazo que incluya corrección de código fuente del lado del desarrollo y acá entra algo de conocimiento de Arquitectura aplicativa:
En el caso de ser una aplicatión WEB monolítica ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) se debe recomendar crear un escapado de datos de salida en el punto vulnerable y ojo, existen varias maneras de hacerlo según sea el caso ya que va a depender en que lugar del código resultante se realiza la impresión de la variable vulnerable con el XSS, pero antes de explicar esto es necesario entender otra cosa: ¿Qué es una secuencia de escape de caracteres?.
Pues bien, digamos que tenemos un String entre comillas dobles así:
¿Que sucede si el valor de esta palabra contiene una comilla doble?
Pues, lo que sucede es que se rompe la cadena de texto ya que las comillas dobles declaran el valor, todo lo que esté dentro es parte del texto, pero cuando le pones una comilla doble lo estás interrumpiendo indicando que se está cerrando la declaración, o sea, que la palabra ya ha terminado, entonces, que sucede con el texto restante, en este caso podrías hacer dos textos o inyectar algo entremedio, por ejemplo usando la frase: Palabra" + algo + "acá
Y bueno, se produce una inyección de código malicioso entre una declaración de tipo texto. Esto mismo sucede en muchos lugares, como verán, no estoy hablando de un lenguaje de programación en particular ya que cada lenguaje utiliza su propia sintaxis y su propia manera de escapar los caracteres.
Entonces, para evitar que suceda una inyección se creó algo universal llamado "Secuencia de escape de caracteres" los cuales se añaden al caracter especial para que este forme parte de la cadena de texto y no que lo rompa, por ejemplo, en javascript es el backslash "\", por ejemplo:
Esto le indica al motor interpretador de Javascript que el caracter que sigue después del backslash será parte del texto en ves de interpretarse como un quiebre del string. En batch el caracter de escape es el "^" y el "%%", en bash es el backslash, en SQL es el backslash, en Javascript es el backslash y en HTML es la Entidad HTML! ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ).
Asi que, en nuestro XSS pueden haber dos situaciones muy comunes, que el código esté imprimiendose dentro de una etiqueta Javascript o dentro del mismo HTML y en cambos casos se necesitarán usar diferentes tipos de secuencia de escape, por ejemplo:
Donde $valor_escapado será igual al texto de salida escapado, esto quiere decir que cada caracter especial podrá ser reemplazado por valores de escape unicode o hexadecimal (definido por el estandar de Javascript ES6), por ejemplo:
Pero, ¿con que función se escapa?: Eso dependerá del lenguaje de programación o del framework que estés utilizando, cada lenguaje o framework tiene distintas maneras de aplicar este filtrado y de ahi la importancia de entender de desarrollo de software, comprender lo que estás analizando, mas allá de ver un simple XSS.
Ahora vamos con el código HTML, su secuencia de escape está definido por el estandar mismo de la W3C: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta , por lo cual enocntramos las siguientes equivalencias:
Entonces, si el problema estuviera en código HTML debería ser escapado de la siguiente manera:
Hay personas que aplican un filtro html para todo el código, pero esto no escapa contenido Javascript, por ejemplo, en javascrpt puedes inyectar código con un backslash, pero HTML no tiene un escape para backslash porque para HTML ese caracter no es peligroso pero para Javascript si, lo mismo sucede cuando intentas romper una secuencia con un salto de línea, por otro lado un tag html en javascript no le pasa nada pero a HTML si. Asi que, cada lenguaje en cada trozo de código debe llevar su propia secuencia de escape de caracteres o podrás terminar abriendo una vulnerabilidad donde antes no lo había.
Pero, en aplicaciones con separación de capas (no monolíoticas) hay que indicar que esto se debe hacer del lado del código que expone la información, o sea la capa de presentación ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ), y ojo, no se les vaya a ocurrir decirle a alguien que debe escapar absolutamente todo, ya que va a depender de muchas cosas, por ejemplo, un servicio REST que expone datos a traves de código Json tiene su propia secuencia de escape de caracteres y esto generalmente se maneja de manera automática dependiendo del lenguaje y framework de programación.
Asi que, ahora si estamos medianamente listos para dar una buena recomendación:
Como verán, la recomendación es corta, pero va al grano y con todo el tecnicismo que necesita el dueño de la aplicación, es muy diferente a decir "hay que filtrar los datos de entrada" y ya.
A modo de conocimiento general, en algunas ocaciones, a demás de recomendar solucionar el XSS también se le recomienda sobre migrar de tecnología a una mas segura, por ejemplo, si el desarrollo WEB no utiliza un framework, sino que está hecho a mano con archivos php o jsp tirados en el servidor, entonces se le dice que al largo plazo va a ser mejor migrar a un framework de desarrollo mas seguro como Codeigniter, Laravel o Spring boot ya que estos frameworks manejan de manera automática los problemas de tipo inyección como los XSS o Inyección SQL debido a que nunca programas código a mano, sino que te apoyas en clases y templates, donde las consultas SQL ya no se realizan directamente sino que usas clases y el framework traduce esas clases a consultas SQL parametrizadas y ya no programas variables directamente sobre HTML sino que programas sobre un sistema de plantillas que traduce tu código a código escapado de manera automática como es el caso de Jinja para Django de Python, Thymeleaf para Spring Boot de Java y Razor para MVC de .NET.
Como ya habrán notado, esto no solo aplica para los XSS sino para cualquier tipo de vulnerabilidad de tipo inyección, esto incluye Inyecciones SQL e Inyección de Comandos, Inyección XML, Inyección LDAP y similares.
Cuando el dueño de una aplicación pregunta como solucionar un problema, por lo general no se lo pregunta a la persona de al lado, sino que se lo pregunta al que encontró el problema y estará esperando a que entiendas como ayudarlo pero si no sabes en que lenguaje está hecho o no tienes los fundamentos básicos de desarrollo entonces va a ser dificil dar una recomendación certera, incluso puede que estés dando una recomendación erronea y que en el futuro tengan problemas aun mas graves y les hagas perder el tiempo, me ha tocado ver esos casos y no es muy agradable decirle a una persona que lo que hizo a modo de corrección realmente no sirve y que va a tener que volver a programar sus soluciones.
Espero les pueda ayudar un poco a ampliar el vocabulario se seguridad informática. Saludos.
Estructura
Cuando encuentras un XSS es importante saber que el dueño de la aplicación no es el experto en seguridad sino tu mismo, por lo cual el dueño puede que entienda menos de la mitad de lo que le digas, por eso es importante ser muy claro y estructurado al momento de detallar un XSS:
- Resumen del hallazgo
- Cómo replicar el problema (PoC) (ojo, no te están pidiendo mostrar un alert, sino replicar un impacto real)
- Porqué es un riesgo de seguridad (impacto)
- Cuales son las mejores recomendciones
Generalmente en el resumen del hallazgo debes incluir el tipo de vulnerabilidad, normalmente categorizado junto al nivel de riesgo y esto lo puedes obtener a traves de diferentes estándares tales como la CVSS ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y la CWE ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) ya que será tu palabra contra el dueño de la aplicación, por lo cual siempre es buena idea apegarse a los estándares.
Recomendaciones
Acá va el problema: el cliente tiene un sitio WEB que cuenta con una vulnerabilidad de tipo XSS Reflejado ( CWE 80 No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y el cliente necesita una recomendación. He escuchado a muchas personas recomendar lo siguiente de manera equivocada:
- Impedir el ingreso de caracteres especiales en los campos
- Filtrar los caracteres especiales evitando que en el input se ingresen etiquetas HTML
- Crear una regla en el WAF para evitar los XSS
Pero, ¿Porqué están errados?: Para comenzar, impedir o filtrar el ingreso de caracteres especiales en los campos es una recomendación demasiado genérica y va a depender del tamaño y de la arquitectura de la aplicación. Como podemos observar, el CWE es 80 ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) y no 79 ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ), hay una gran diferencia ya que el CWE-79 indica que es un problema de caracteres de entrada y el CWE-80 indica que es un problema de salida.
Cuando ingresas contenido HTML en un campo y este se refleja en el código fuente resolutante de la respuesta del sitio WEB (response) entonces tenemos un problema de datos de salida y no de entrada, pero ¿porqué no filtrar los caracteres en la entrada para evitar tener problemas en los datos de salida?: porque no todas las aplicaciones funcionan igual y esto dependerá de su arquitectura, por ejemplo: Supongamos que nuestro sistema tiene una versión WEB y una version movil, si filtro los caracteres especiales en la entrada de datos para convertirlos en entidades HTML para que se guarde en la base de datos entonces cuando la aplicación móvil vaya a solicitar estos datos vendrán con escapes HTML pero las aplicaciones móviles nativas no usan HTML asi que se verán caracteres extraños basura en el contenido. No todo lo que esté en una base de datos significa que se desplegará en una aplicación WEB o móvil o de escritorio, sea nativa o híbrida, por esto es muy importante tener en mente el siguiente concepto:
Ningún dato de entrada debe ser filtrado a menos que sea un filtro de datos por concepto de definición de capa de negocio y datos, o sea, si mi valor a ingresar debe ser siempre un número positivo entonces eso si se puede filtrar, si el nombre debe tener una longitud máxima entonces esto debe ser controlado y filtrado, pero si no hay nada que impida que alguien ingrese un caracter especial en una caja de descripción entonces para que filtrar, por lo contrario, un buen desarrollo debe poder funcionar de manera segura con cualquier tipo de caracter especial, por ejemplo, este foro permite caracteres especiales para el nombre de usuario o la caja del contenido del post y no quiere decir que se deban eliminar todos los caracteres especiales para hacerlo mas seguro.
Si eres un profesional y encontraste un buen XSS pero aconsejas filtrar los campos de entrada te puede hacer quedar como ignorante en el campo del desarrollo de la solución y puede que pierdan la confianza en ti y sin que te lo digan.
¿Porqué no es bueno recomendar que se solucione del lado del WAF creando reglas que impidan los XSS?: Porque un WAF es solamente un agente mitigante pero no un solucionador de problemas, puede que para alguien sea mas dificil llegar al XSS pero el agujero de seguridad con el riesgo aun van a seguir existiendo, los riesgos se reducen pero no se eliminan, por lo cual no se considera una solución sino una mitigación y esto es parte de dos planes de trabajo: La mitigación al corto plazo y la solución al mediano/largo plazo.
Entonces, ¿cual es la mejor recomendación?:
Crear un plan de mitigación al corto plazo sonde se mitigue a traves de diferentes agentes dependiendo los que tenga el dueño de la aplicación WEB (Web Application Firewall), por ejemplo, el WAF para mitigar los ataques WEB, un Firewall para evitar la llegada de paquetes maliciosos a la infraestructura, evitar pivoting y esas cosas.
Crear un plan de solución al mediano/largo plazo que incluya corrección de código fuente del lado del desarrollo y acá entra algo de conocimiento de Arquitectura aplicativa:
En el caso de ser una aplicatión WEB monolítica ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ) se debe recomendar crear un escapado de datos de salida en el punto vulnerable y ojo, existen varias maneras de hacerlo según sea el caso ya que va a depender en que lugar del código resultante se realiza la impresión de la variable vulnerable con el XSS, pero antes de explicar esto es necesario entender otra cosa: ¿Qué es una secuencia de escape de caracteres?.
Pues bien, digamos que tenemos un String entre comillas dobles así:
¿Que sucede si el valor de esta palabra contiene una comilla doble?
Pues, lo que sucede es que se rompe la cadena de texto ya que las comillas dobles declaran el valor, todo lo que esté dentro es parte del texto, pero cuando le pones una comilla doble lo estás interrumpiendo indicando que se está cerrando la declaración, o sea, que la palabra ya ha terminado, entonces, que sucede con el texto restante, en este caso podrías hacer dos textos o inyectar algo entremedio, por ejemplo usando la frase: Palabra" + algo + "acá
Y bueno, se produce una inyección de código malicioso entre una declaración de tipo texto. Esto mismo sucede en muchos lugares, como verán, no estoy hablando de un lenguaje de programación en particular ya que cada lenguaje utiliza su propia sintaxis y su propia manera de escapar los caracteres.
Entonces, para evitar que suceda una inyección se creó algo universal llamado "Secuencia de escape de caracteres" los cuales se añaden al caracter especial para que este forme parte de la cadena de texto y no que lo rompa, por ejemplo, en javascript es el backslash "\", por ejemplo:
Esto le indica al motor interpretador de Javascript que el caracter que sigue después del backslash será parte del texto en ves de interpretarse como un quiebre del string. En batch el caracter de escape es el "^" y el "%%", en bash es el backslash, en SQL es el backslash, en Javascript es el backslash y en HTML es la Entidad HTML! ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ).
Asi que, en nuestro XSS pueden haber dos situaciones muy comunes, que el código esté imprimiendose dentro de una etiqueta Javascript o dentro del mismo HTML y en cambos casos se necesitarán usar diferentes tipos de secuencia de escape, por ejemplo:
Donde $valor_escapado será igual al texto de salida escapado, esto quiere decir que cada caracter especial podrá ser reemplazado por valores de escape unicode o hexadecimal (definido por el estandar de Javascript ES6), por ejemplo:
Pero, ¿con que función se escapa?: Eso dependerá del lenguaje de programación o del framework que estés utilizando, cada lenguaje o framework tiene distintas maneras de aplicar este filtrado y de ahi la importancia de entender de desarrollo de software, comprender lo que estás analizando, mas allá de ver un simple XSS.
Ahora vamos con el código HTML, su secuencia de escape está definido por el estandar mismo de la W3C: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta , por lo cual enocntramos las siguientes equivalencias:
Valor/ | Entidad que lo reemplaza |
< | < |
> | > |
' | ' |
" | " |
Entonces, si el problema estuviera en código HTML debería ser escapado de la siguiente manera:
Hay personas que aplican un filtro html para todo el código, pero esto no escapa contenido Javascript, por ejemplo, en javascrpt puedes inyectar código con un backslash, pero HTML no tiene un escape para backslash porque para HTML ese caracter no es peligroso pero para Javascript si, lo mismo sucede cuando intentas romper una secuencia con un salto de línea, por otro lado un tag html en javascript no le pasa nada pero a HTML si. Asi que, cada lenguaje en cada trozo de código debe llevar su propia secuencia de escape de caracteres o podrás terminar abriendo una vulnerabilidad donde antes no lo había.
Pero, en aplicaciones con separación de capas (no monolíoticas) hay que indicar que esto se debe hacer del lado del código que expone la información, o sea la capa de presentación ( No tienes permitido ver enlaces. Registrate o Entra a tu cuenta ), y ojo, no se les vaya a ocurrir decirle a alguien que debe escapar absolutamente todo, ya que va a depender de muchas cosas, por ejemplo, un servicio REST que expone datos a traves de código Json tiene su propia secuencia de escape de caracteres y esto generalmente se maneja de manera automática dependiendo del lenguaje y framework de programación.
Asi que, ahora si estamos medianamente listos para dar una buena recomendación:
CitarA modo de solución al mediano/largo plazo se recomienda aplicar la secuencia de escape de caracteres utilizando el estandar de Entidades HTML declarado por W3C en capa de presentación, únicamente sobre el parámetro afectado.
Como verán, la recomendación es corta, pero va al grano y con todo el tecnicismo que necesita el dueño de la aplicación, es muy diferente a decir "hay que filtrar los datos de entrada" y ya.
A modo de conocimiento general, en algunas ocaciones, a demás de recomendar solucionar el XSS también se le recomienda sobre migrar de tecnología a una mas segura, por ejemplo, si el desarrollo WEB no utiliza un framework, sino que está hecho a mano con archivos php o jsp tirados en el servidor, entonces se le dice que al largo plazo va a ser mejor migrar a un framework de desarrollo mas seguro como Codeigniter, Laravel o Spring boot ya que estos frameworks manejan de manera automática los problemas de tipo inyección como los XSS o Inyección SQL debido a que nunca programas código a mano, sino que te apoyas en clases y templates, donde las consultas SQL ya no se realizan directamente sino que usas clases y el framework traduce esas clases a consultas SQL parametrizadas y ya no programas variables directamente sobre HTML sino que programas sobre un sistema de plantillas que traduce tu código a código escapado de manera automática como es el caso de Jinja para Django de Python, Thymeleaf para Spring Boot de Java y Razor para MVC de .NET.
Como ya habrán notado, esto no solo aplica para los XSS sino para cualquier tipo de vulnerabilidad de tipo inyección, esto incluye Inyecciones SQL e Inyección de Comandos, Inyección XML, Inyección LDAP y similares.
Cuando el dueño de una aplicación pregunta como solucionar un problema, por lo general no se lo pregunta a la persona de al lado, sino que se lo pregunta al que encontró el problema y estará esperando a que entiendas como ayudarlo pero si no sabes en que lenguaje está hecho o no tienes los fundamentos básicos de desarrollo entonces va a ser dificil dar una recomendación certera, incluso puede que estés dando una recomendación erronea y que en el futuro tengan problemas aun mas graves y les hagas perder el tiempo, me ha tocado ver esos casos y no es muy agradable decirle a una persona que lo que hizo a modo de corrección realmente no sirve y que va a tener que volver a programar sus soluciones.
Espero les pueda ayudar un poco a ampliar el vocabulario se seguridad informática. Saludos.
#19
QA (Quality Assurance) / Re: Pruebas automatizadas con Postman
Noviembre 01, 2021, 04:26:48 PM
Para las pruebas automatizadas utilizo los mismos módulos de pruebas incluidas en las mismas aplicaciones y si no las tengo las fabrico en base al swagger o la documentación.
Muchas personas usan postman para documentar y testear las apis en diferentes ambientes y está bien, pero creo que para el trabajo de un proyecto estas pruebas deberían ir en el área de pruebas. Node, Java y similares ya tienen módulos para hacer este tipo de pruebas, por ejemplo Android Studio ya lo integra de manera nativa.
Muchas personas usan postman para documentar y testear las apis en diferentes ambientes y está bien, pero creo que para el trabajo de un proyecto estas pruebas deberían ir en el área de pruebas. Node, Java y similares ya tienen módulos para hacer este tipo de pruebas, por ejemplo Android Studio ya lo integra de manera nativa.
#20
Dudas y pedidos generales / Re: Ayuda JSP
Octubre 31, 2021, 03:14:26 PM
Realmente ya casi nadie programa directamente en jsp+servlet+jsf, son tecnologías que ya están casi obsoletas (hablando por la combinación completa).
Si vas a dedicarte a programar en java te recomiendo que comiences con el framework Spring Boot + Thymeleaf. En youtube hay un canal que me gusta mucho que se llama "Spring gurú" y hay muchisima información al respecto. Si tienes alguna duda la puedes ir haciendo en el mismo foro.
Una pregunta, ¿ya tienes conocimientos previos en programación?, porque utilizar Spring requiere del manejo de algunos conceptos que no son básicos, como separación de capas, perisstencia, modelamiento DTO, security y demás. De todas maneras en jsp+servlet tendrías que llegar a lo mismo pero de manera mas manual, en cambio el framework ya te ayuda mucho a estructurar y automatizar.
Saludos.
Si vas a dedicarte a programar en java te recomiendo que comiences con el framework Spring Boot + Thymeleaf. En youtube hay un canal que me gusta mucho que se llama "Spring gurú" y hay muchisima información al respecto. Si tienes alguna duda la puedes ir haciendo en el mismo foro.
Una pregunta, ¿ya tienes conocimientos previos en programación?, porque utilizar Spring requiere del manejo de algunos conceptos que no son básicos, como separación de capas, perisstencia, modelamiento DTO, security y demás. De todas maneras en jsp+servlet tendrías que llegar a lo mismo pero de manera mas manual, en cambio el framework ya te ayuda mucho a estructurar y automatizar.
Saludos.