Informe para 0 puntos EY GDS Polonia Desafío de Ciberseguridad a través de Challenge Rocket

por | |

Esta entrada se divide en dos partes. En el primero publico una descripción de vulnerabilidades que pude identificar como parte del "EY GDS Poland Cybersecurity Challenge". En el segundo, describo mis reservas sobre la forma en que se llevó a cabo ese "desafío" y por qué lo estoy haciendo.

Parte 1: errores de seguridad detectados

1. Secuencias de comandos entre sitios reflejadas

Puntuación CVSSv3: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravedad: Crítica

Hallazgo:
se ha encontrado una vulnerabilidad de secuencias de comandos entre sitios reflejada durante la prueba. Permite inyectar y ejecutar código JavaScript en el contexto de la aplicación. El código JavaScript solo lo refleja el servidor, lo que difiere de los scripts entre sitios almacenados que almacenan código en la aplicación de forma permanente. Esta vulnerabilidad se explota principalmente con el fin de secuestrar las sesiones de usuarios autenticados. También se puede utilizar para redirigir a los usuarios a sitios web maliciosos o robar llaves del usuario de la aplicación.

Prueba:
Solicitud:

GET /index.php?login=testhqw60%22%3e%3cscript%3ealert(1)%3c%2fscript%3ek9nju&psw=test&page=login HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Conexión: cerrar

respuesta:

HTTP/1.1 200 Aceptar
Fecha: Mar, 05 Ene 2021 17:04:34 GMT
Servidor: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expira: Jue, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: sin caché
Contenido-Longitud: 1248
Conexión: cerrar
Tipo de contenido: text/html; charset=UTF-8<html>
<head>
    <title>Sistema de chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">mis mensajes</a><a href="/index.php?page=new_message">Enviar mensaje</a>Cerrar<a href="/index.php?logout">sesión</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_error'>Error de inicio de sesión</div>
<form target="_self">
    <div class="container">
        <label for="login"><b>Iniciar sesión</b></label>
        <input type="text" placeholder="Enter login" name="login" id="login"
               value="testhqw60"><script>alert(1)</script>k9nju" requerido>

<label for="psw"> <b>Contraseña</b></label></div></form></div></div></body></html>

Recomendación:
El problema es el resultado de la falta de verificación de entrada adecuada y la falta de codificación de salida adecuada. Se recomienda encarecidamente incorporar reglas estrictas de desinfección de entrada y codificación de salida. Los caracteres especiales HTML como<' and="" '="">' ' necesitan ser codificados en HTML (reemplazados por ' '<' and="" '="">respectivamente) en todos los datos leídos de la entrada del usuario, bases de datos y archivos.</'> </'> Lo mismo ocurre con caracteres como " (que debe ser reemplazado por ") y ' (que debe escaparse con un signo de barra diagonal inversa ). A su vez, la desinfección estricta de entradas significa un enfoque diferente para la validación de entradas. Por ejemplo, si una variable está destinada a contener un número, es mejor comprobar si realmente es un número (como si coincide con una expresión regular ^d+$ o con una conversión de enteros) en lugar de intentar averiguar todos los posibles caracteres malos que se van a filtrar. La validación de entrada que tiene lugar en el lado del servidor es obligatoria, mientras que la validación en el lado del cliente (HTML / JavaScript, navegador web, que está controlado por el usuario) debe estar presente principalmente para fines de usabilidad, pero también para evitar los llamados scripts de sitios cruzados basados en DOM. Si cualquier variable proporcionada por el usuario se escribe en la base de datos / archivo / documento HTML sin saneamiento previo y luego se muestra de nuevo a otros usuarios, dicha vulnerabilidad se convierte en un XSS almacenado, lo que es mucho más peligroso, ya que se puede usar contra usuarios autenticados sin ninguna acción tomada de su lado. Además, por lo general, la escala de un ataque XSS almacenado es más amplia que en el caso de uno reflejado, ya que varios usuarios pueden verse afectados.

Referencias:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

2. Inyección SQL

Puntuación CVSSv3: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Gravedad: Crítica

Hallazgo:
Error de inyección SQL se encontró dentro de la aplicación. Esta vulnerabilidad permite a un atacante potencial ejecutar consultas SQL directas en la base de datos subyacente. Un atacante puede, por ejemplo, recuperar toda la información de la base de datos a la que tiene acceso el usuario actual de la base de datos. También permite desfigurar el sitio web, ejecutar XSS a través de la manipulación de datos de la base de datos o ejecutar comandos del sistema.

Prueba:
Debido al hecho de que la aplicación no utiliza la parametrización casi todos los parámetros de la aplicación son vulnerables para la inyección sql.

pedir:

GET /index.php?login=admin'or'&psw=xyz&page=login HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Conexión: cerrar

respuesta:

HTTP/1.1 302 Encontrado
Fecha: Mar, 05 Ene 2021 17:15:25 GMT
Servidor: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expira: Jue, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: sin caché
Ubicación: /index.php?loggedin
Contenido-Longitud: 666
Conexión: cerrar
Tipo de contenido: text/html; charset=UTF-8<html>
<head>
    <title>Sistema de chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">mis mensajes</a><a href="/index.php?page=new_message">Enviar mensaje</a>Cerrar<a href="/index.php?logout">sesión</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Usuario ha ha estado sesión</div></div></div></body></html>

Recomendación:
Cada carácter especial en los datos de entrada de los usuarios debe filtrarse o / y desinfectarse en el lado del servidor para evitar vulnerabilidades de inyección sql. Los valores enteros no deben tratarse como valores de cadena y deben analizarse como enteros antes de tomar medidas en ellos. El procedimiento recomendado es utilizar instrucciones preparadas (con parámetros) en todos los casos en los que las consultas de base de datos están presentes.

Referencias:
CWE-89
http://cwe.mitre.org/data/definitions/89.html
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md https://www.owasp.org/index.php/SQL_Injection OWASP

3. Scripting entre sitios almacenados

Puntuación CVSSv3: 8.0
CVSS v3 vector: AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Gravedad: Crítica

Búsqueda:
durante la prueba se han encontrado vulnerabilidades de cross site scripting almacenadas. Se explota sobre todo con el fin de secuestrar sesiones de usuarios autenticados. El problema es el resultado de la falta de verificación de entrada adecuada y la falta de codificación de salida adecuada. Un XSS almacenado tiene lugar cuando cualquier variable vulnerable proporcionada por el usuario se escribe en la base de datos o archivo y, a continuación, se muestra de nuevo a otros usuarios. Por lo tanto, XSS almacenado es mucho más peligroso, ya que se puede utilizar contra otros usuarios sin ninguna acción tomada de su lado como phishing. Puede ser extremadamente útil para infectar a los usuarios con el uso de exploits del navegador web, abusando de la confianza de la aplicación atacada.

Prueba:
Solicitud:

GET /index.php?login=testy7sfo%3cscript%3ealert(1)%3c%2fscript%3ejil46&psw=test&psw-repeat=test&page=register HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Conexión: cerrar

Respuesta con punto de ejecución:

HTTP/1.1 200 Aceptar
Fecha: Mar, 05 Ene 2021 17:25:52 GMT
Servidor: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expira: Jue, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: sin caché
Conexión: cerrar
Tipo de contenido: text/html; charset=UTF-8
Contenido-Longitud: 15252<html>
<head>
    <title>Sistema de chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">mis mensajes</a><a class="active" href="/index.php?page=new_message">Enviar mensaje</a>Cerrar<a href="/index.php?logout">sesión</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <div class='message_success'>Mensaje enviado</div>
    <form target="_self">
        <div class="container">
            <h1>Enviar nuevo mensaje</h1>
            <p>Seleccione el usuario y proporcione el texto del mensaje</p>
            <hr>

            <label for="login"><b>usuario</b></label>
            <select type="text" name="login" id="login" required="">
                                <option value="1">Admin
                                <option value="2">usuario
                                <option value="4">prrrsihv
                                <option value="5">0
                                <option value="6">0
                                <option value="7">0
                                <option value="8">0
                                <option value="9">prueba"
                                <option value="10">ykq1o3wmfv

[...]
value="14">testgl11i"> <script>alert(1)</script> y9e06
                                <option 
[…]</select></div></form></div></div></body></html>

Recomendación:
Se recomienda encarecidamente incorporar reglas estrictas de desinfección de entrada y codificación de salida. Los caracteres especiales HTML como<' and="" '="">' ' necesitan ser codificados en HTML (reemplazados por ' '<' and="" '="">respectivamente) en todos los datos leídos de la entrada del usuario, bases de datos y archivos.</'> </'> Lo mismo ocurre con caracteres como " (que debe ser reemplazado por ") y ' (que debe escaparse con un signo de barra diagonal inversa ). A su vez, la desinfección estricta de entradas significa un enfoque diferente para la validación de entradas. Por ejemplo, si una variable está destinada a contener un número, es mejor comprobar si realmente es un número (como si coincide con una expresión regular ^d+$ o con una conversión de enteros) en lugar de intentar averiguar todos los posibles caracteres malos que se van a filtrar. La validación de entrada que tiene lugar tanto en el lado del servidor como en el lado del cliente es obligatoria. La validación en el lado del cliente (HTML/JavaScript, explorador web, que está controlado por el usuario) evita que se produzcan secuencias de comandos entre sitios basadas en DOM. La validación en el sitio del servidor impide que se activen las secuencias de comandos entre sitios estándar (no DOM). Si la seguridad se basa únicamente en la validación del lado cliente, no es difícil para el atacante crear una interfaz alternativa y enviar datos diseñados de forma malintencionada al servidor, omitiendo correctamente este tipo de mecanismo. Siempre es necesario implementar una validación de entrada estricta tanto en el servidor como en el lado cliente de forma independiente. Si cualquier variable proporcionada por el usuario se escribe en la base de datos / archivo y, a continuación, se muestra de nuevo a otros usuarios, dicha vulnerabilidad se convierte en un XSS almacenado, que es mucho más peligroso, ya que se puede utilizar contra los usuarios autenticados sin ninguna acción tomada por su lado. También la escala de un ataque XSS almacenado es generalmente más amplia que en caso de reflejado.

Referencias:
CWE-79
http://cwe.mitre.org/data/definitions/79.html
OWASP
http://www.owasp.org/index.php/Cross_Site_Scripting
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md

4. Omisión de autorización

Puntuación CVSSv3: 8.8
CVSS v3 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Gravedad: Alta

Hallazgo:
Se ha revelado que la aplicación tiene una implementación de autorización deficiente. Un usuario que conoce la ruta de acceso directa al recurso o una dirección URL para llamar a una función determinada, puede tener acceso a ella sin tener la concesión de roles adecuada. La omisión de autorización permite ejecutar determinadas acciones sin tener permisos para hacerlo. Por ejemplo, un usuario no autorizado puede ejecutar funciones administrativas como agregar otro administrador de usuario.

Prueba:
Usando url directa para el mensaje, cualquiera puede leer un mensaje que no le pertenece simplemente cambiando el id del mensaje en la url: http://192.168.140.129/index.php?page=messages&message =
1

Recomendación:
Cada solicitud a un recurso o una función debe comprobarse correctamente si el usuario que invocó esta acción tiene los permisos adecuados. La implementación del mecanismo como el ACL (lista de control de acceso) con las entradas por el URL/el módulo/la función y la directiva predeterminada de la NEGACIÓN se recomienda altamente.

Referencias:
CWE-285
http://cwe.mitre.org/data/definitions/285.html
OWASP
https://www.owasp.org/index.php/Broken_Access_Control
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Access_Control_Cheat_Sheet.md

5. Credenciales de usuario predeterminadas o fáciles de adivinar

Puntuación CVSSv3: 8.6
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Gravedad: Alta

Búsqueda:
las credenciales de usuario predeterminadas o fáciles de adivinar son muy peligrosas para la seguridad de la aplicación. Un atacante sin mucho esfuerzo puede obtener acceso a la sección privada de la aplicación. La contraseña adivinada/agrietada se puede usar para iniciar sesión en la sección privada de la aplicación y los ataques dinámicos a los usuarios autorizados. Ahora un atacante tiene un área mucho más amplia para explotar la aplicación.

Prueba:
Pentester encontró una contraseña débil en la aplicación. Además, la aplicación utiliza un método de hash md5 débil.

paso hash de inicio de sesión
admin d8578edf8458ce06fbc5bb76a58c5ca4 qwerty
usuario 7815696ecbf1c96e6894b779456d330e asd

Recomendación:
Se debe cambiar toda la contraseña predeterminada de la aplicación. La aplicación también debe emplear la directiva de contraseñas seguras.

Referencias:
https://www.owasp.org/index.php/Insecure_Configuration_Management OWASP

6. Datos confidenciales enviados a través de un canal sin cifrar

Puntuación CVSSv3: 7.5
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Gravedad: Alta

Búsqueda:
esta vulnerabilidad se produce cuando se envían datos confidenciales a través del protocolo HTTP que no implementa ningún cifrado de datos. Cualquier dato que se envíe a través de este canal es susceptible de olfato y manipulación.

Prueba:
Las contraseñas se envían utilizando un canal sin cifrar utilizando el método peligroso – obtener el tipo de solicitud:

Solicitud utilizada para registrar al usuario, enviada a través de http:

GET /index.php? login=aaaa&psw=aaaa&psw-repeat=aaaa&page=register HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=register
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Conexión: cerrar

Solicitud utilizada para iniciar sesión como usuario, enviada a través de http:

GET /index.php? login=test&psw=test&page=login HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: adminer_version=4.7.8; PHPSESSID=142f35v6q107q5krpj1ma23ki1
Conexión: cerrar

Recomendación:
Se debe implementar el protocolo HTTPS para proteger los datos confidenciales. Tenga en cuenta también que cuando se implementará el protocolo HTTPS, las cookies deben protegerse con el indicador Secure. Esto evita el envío de cookies a través de HTTP.

Referencias:
CWE-319
http://cwe.mitre.org/data/definitions/319.html
OWASP
https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.md

7. Mensajes de error detallados

Puntuación CVSSv3: 6,5
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Gravedad: Media

Búsqueda:
Durante la prueba se ha revelado que en caso de algunas solicitudes, el servidor lanza una excepción de error. El mensaje de excepción puede contener una gran cantidad de información técnica detallada, incluidos nombres de archivo, rutas de acceso absolutas, pero también bibliotecas, clases y métodos utilizados. Esta información puede ser crucial para llevar a cabo otros ataques críticos (como lectura arbitraria de archivos, ejecución de código o ataques específicos de la plataforma). Dicha información detallada debe estar disponible solo para los desarrolladores de aplicaciones y los administradores de sistemas y nunca debe revelarse al usuario final.

Prueba:
Solicitud:

GET /index.php?login=admin'%20or%20'1'&psw=xyz&page=login HTTP/1.1
Anfitrión: 192.168.140.129
Solicitudes de actualización inseguras: 1
Agente de usuario: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/89.0.4356.6 Safari/537.36
Aceptar: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Árbitro: http://192.168.140.129/index.php?page=login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73
Conexión: cerrar

respuesta:

HTTP/1.1 200 Aceptar
Fecha: Mar, 05 Ene 2021 17:13:52 GMT
Servidor: Apache/2.4.6 (CentOS) PHP/5.4.16
X-Powered-By: PHP/5.4.16
Expira: Jue, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: sin caché
Contenido-Longitud: 753
Conexión: cerrar
Tipo de contenido: text/html; charset=UTF-8<html>
<head>
    <title>Sistema de chat interno</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div style="width:600px; margin: 0 auto; text-align: center">
    <a href="/">
        <img src="ey-logo.png" height="72" alt="EY">
    </a>
    <div style="margin-top:50px;">
                <nav>
              <a href="/index.php?page=messages">mis mensajes</a><a href="/index.php?page=new_message">Enviar mensaje</a>Cerrar<a href="/index.php?logout">sesión</a>
              
              
          </nav>
          </div>
    <div style="margin-top:20px;">
      <br />
<b>Error grave:</b>llamada a una función miembro fetch() en un objeto no en <b>/var/www/html/login.php</b> en línea <b>7</b><br /></div></div></body></html>

Recomendación:
No se deben proporcionar errores detallados a los usuarios finales. En su lugar, se deben proporcionar páginas de error estáticas descriptivas. La causa del error debe investigarse dentro del código.

Referencias:
OWASP
https://www.owasp.org/index.php/Information_Leakage
CWE-209
http://cwe.mitre.org/data/definitions/209.html
CWE-200: Information Exposure http://cwe.mitre.org/data/definitions/200.html

Kingdom: Environment http://www.hpenterprisesecurity.com/vulncat/en/vulncat/intro.html

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Error_Handling_Cheat_Sheet.md

8. Divulgación de información

Puntuación CVSSv3: 5.3
CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Gravedad: Baja

Búsqueda:
la vulnerabilidad de divulgación de información se produce cuando la aplicación filtra información confidencial de alguna manera. Por ejemplo, se expone la configuración del servidor o de la aplicación. La gravedad de este problema depende de la información que se filtre.

Prueba:
Los archivos que se indican a continuación no deben ser de acceso público: http://192.168.140.129/info.php

http://192.168.140.129/adminer.php

Divulgación del servidor y la versión en el
encabezado: Servidor: Apache/2.4.6 (CentOS) PHP/5.4.16

Software usado y divulgación de la versión en la
cookie: Cookie: PHPSESSID=0f9k9rgvdg5lqfpvuhem70eo73; adminer_version=4.7.8

Recomendación:
No se debe filtrar ninguna información adicional. Sólo la información que el usuario necesita debe estar disponible / proporcionado.

Referencias:
CWE-200
http://cwe.mitre.org/data/definitions/200.html
OWASP
https://www.owasp.org/index.php/Information_Leakage
https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure

Parte 2 – Objeciones a "EY GDS UK Cybersecurity Challenge via Challenge Rocket"

A veces, como parte de mis conocimientos y habilidades, particigo en todo tipo de cursos, capacitaciones y desafíos de seguridad. Uno de ellos fue el "EY GDS Poland Cybersecurity Challenge" organizado en el https://challengerocket.com/ey-cybersecurity-challenge/. De acuerdo con la descripción, consistió en la realización de una auditoría de seguridad – citando a los organizadores de "Linux y portal web". A su vez, se debe crear un informe sobre la base de sus resultados. Contenía una descripción de las vulnerabilidades encontradas que amenazan la seguridad del sistema y recomendaciones sobre cómo aumentar el nivel general de seguridad. Se observó que la notificación debía ser breve, concisa y contener una breve descripción de las vulnerabilidades y pruebas de su existencia. Es decir, se puede decir que todo debía llevarse a cabo de acuerdo con el procedimiento estándar para la realización de pruebas de penetración.

La imagen real de la competición y la actitud de los organizadores ante la cuestión de aclarar las dudas relacionadas con ella me sorprendió de una manera un poco positiva. Mi informe fue calificado con 0 puntos, sobre todo, citando a los miembros del jurado "los resultados del escáner no son un informe de pentest".

La imagen tiene un atributo alt vacío; archivo denominado image-7-1024x96.png

Esta es una evaluación hiriente para mí, y traté de aclarar este tema con mayor precisión (causa probable en el punto 6 de las reservas), pero, en resumen, además de los correos electrónicos semanales (durante casi un mes), como – "algún día podemos responder allí", no recibí una explicación.

La imagen tiene un atributo alt vacío; archivo denominado image-5.png
La imagen tiene un atributo alt vacío; archivo denominado image-6.png

De ahí esta entrada, en la que comparto un informe con el «jefe de landja» y mis reservas sobre su organización y forma de aplicación. Hubo algunas deficiencias.

Sin embargo, confío en que mis malas experiencias sean el resultado de una "serie de eventos desafortunados" y no de una falta de buena voluntad. Cierro las reservas en forma de lista y espero que sirvan en el ciclo de William Edwards Deming:

  1. Toda la diversión era limitada a veces – 2h. En mi opinión, este es muy poco tiempo para llevar a cabo 2 pruebas de penetración y preparar sobre la base de un informe completo.
  2. Participar en la cabecera de la segunda era descargar y montar una imagen de dos VMs (utilizando el tiempo disponible 2h). Esto no siempre es posible por razones técnicas prosaicas. En mi opinión, sería más fácil para los involucrados si se pudiera acceder a las máquinas a través de una VPNa y los participantes no tuvieran que configurarlas de su lado.
  3. El límite de 2h podría omitirse injustamente: acceder a las tareas mediante la creación de una cuenta para datos falsos. El único punto de protección contra esto era la disposición en el reglamento: "4. Cada Participante puede inscribirse en el Concurso y realizar las tareas del Concurso una sola vez. Después de comenzar la prueba, el Participante debe completarla dentro del límite de tiempo dado. Una vez completada la prueba, no será posible volver a tomarla. Los participantes que intenten inscribirse en el Concurso desde múltiples cuentas y realizar la prueba más de una vez serán descalificados.". La plataforma no protege contra tales acciones. Es como si dijeras que no necesitas crear aplicaciones seguras porque hackearlas es ilegal.
  4. Las contraseñas de acceso no funcionaban o eran inerroneive a una de las máquinas. Después de informar de esto, recibí esta respuesta: "cuando se trata de acceder a la máquina, es posible que haya utilizado los datos incorrectos de una manera inapropiada. Es completamente diferente a una máquina y mucho más acceso que la otra". No estoy en condiciones de decir la validez de esta opinión. Seguí los pasos en el manual y traté de usar las contraseñas dadas en ellos. Recibí información de otros participantes de que también dieron "crayves" no funcionó. Se podría acceder a la máquina de una manera diferente, a través del servicio ftp. Sólo entonces, ¿por qué una instrucción engañosa?
  5. En el "portal web" se cosía un script, que contactaba con un servidor web externo llamado "ey-logger". Se trataba de una situación extraña, ya que llamaba en el momento del registro en el "portal web" y le enviaba el nombre de usuario y la contraseña utilizados. Además, al hacerlo, accedió a la dirección IP de las personas involucradas en el juego. ¿Alguien ha cosido un keylogger malicioso en la aplicación? Evalué este problema como un remanente de las pruebas, que se encontró allí accidentalmente. Sin embargo, el organizador declaró que estaba allí intencionalmente: " mientras que en términos de script – no es un script de prueba, pero deliberadamente "extraño" buscando script con la vulnerabilidad de XSS-Persistance (que es una de las vulnerabilidades de seguridad que se detectarán. La dirección no es para el servidor EY, sino para una maquinilla de afeitar insignificante y no funcional en Azura.".
  6. Después de completar la prueba de penetración y hacer clic en el campo next-to-go para incluir el informe, resultó que esto solo se puede hacer en una ventana que acepta texto no cifrado, sin ningún formato. Por lo tanto, el informe final estaba desprovisto de legibilidad y la posibilidad de adjuntar gráficos. Creo que esta puede haber sido la razón por la que mi informe podría haberse malinterpretado como un «resultado del escáner». No he podido explicar esto hasta el final, porque, como he dicho, no he recibido ninguna respuesta sustantiva desde hace un mes.
  7. El organizador no publicó los resultados del desafío en tiempo regular. Después de pasar el tiempo regular y preguntar cuándo aparecerán los resultados, cambió sufragentemente las fechas en los términos y condiciones:
Antes de informar de un incumplimiento del plazo legal
Después de informar de un incumplimiento del plazo legal

8. El organizador reveló los nombres de los participantes, a pesar del hecho de que esto no sucederá en el reglamento – "4. Los resultados obtenidos por los Participantes en el Concurso se publicarán después de la finalización del Concurso sin publicar los nombres y apellidos de los Participantes. ¿Es una violación del RGPD?

¡Felicidades al ganador y le deseamos éxito continuo! 🙂

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach (zero spamu!). Dodatkowo otrzymasz, moją prywatną listę 15 najbardziej przydatnych narzędzi (wraz z krótkim opisem), których używam przy testach penetracyjnych.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Marcar el Enlace permanente.

Deja una respuesta

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