Reino: API Abuse

Un API es un contrato entre un autor de llamada y un receptor de llamada. Las formas de abuso de API más comunes los produce el autor de llamada cuando no consigue atender su fin de este contrato. Por ejemplo, si un programa no consigue llamar chdir() después de llamar chroot(), se viola el contrato que especifica cómo cambiar el directorio de origen activo de una forma segura. Otro buen ejemplo de un abuso de manual es esperar que el receptor devuelva una información de DNS de confianza al autor de llamada. En este caso, el autor de llamada abusa el API del receptor haciendo determinadas suposiciones sobre su comportamiento (que el valor de retorno se puede usar con fines de autenticación). También se puede violar el contrato entre el autor de llamada y el receptor desde el otro lado. Por ejemplo, si un codificador envía SecureRandom y devuelve un valor no aleatorio, se viola el contrato.

Often Misused: Authentication

Abstract

Los atacantes pueden reemplazar las entradas DNS. Por motivos de seguridad, no confíe en nombres DNS.

Explanation

Muchos servidores DNS son susceptibles de sufrir ataques, por eso debe suponer que su software se ejecutará alguna vez en un entorno con un servidor DNS afectado. Si los atacantes están autorizados a hacer actualizaciones de DNS (a veces denominado envenenamiento de la caché del DNS), pueden redirigir su tráfico de red a través de sus equipos o hacer que parezca que sus direcciones IP forman parte de su dominio. No base la seguridad de su sistema en nombres DNS.
Ejemplo: el siguiente ejemplo de código utiliza una búsqueda DNS para determinar si una solicitud entrante es de un host de confianza o no. Si un atacante es capaz de dañar la caché DNS, puede obtener un estatus de confianza.


 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

Las direcciones IP son más confiables que los nombres DNS, pero también se pueden reemplazar. Los atacantes pueden falsificar fácilmente las direcciones IP de origen de los paquetes que envían, aunque los paquetes de respuesta volverán a la dirección IP falsificada. Para ver los paquetes de respuesta, el atacante tiene que examinar el tráfico entre el equipo víctima y la dirección IP falsificada. A fin de completar el examen necesario, los atacantes normalmente intentan ubicarse en la misma subred que el equipo víctima. Los atacantes podrían ser capaces de evitar este requisito empleando enrutamiento de origen, aunque el enrutamiento de origen esté deshabilitado actualmente en gran parte de Internet. En resumen, la verificación de las direcciones IP puede ser una parte útil de un esquema de autenticación, pero no debe ser el único factor necesario para la autenticación.

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877

[3] Standards Mapping - FIPS200 IA

[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)

[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-11 Trusted Path, SC-23 Session Authenticity

[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication

[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization

[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1

[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management

[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management

[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management

[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management

[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication

[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I

[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I

[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I

[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I

[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[38] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)

[39] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.semantic.dotnet.often_misused_authentication

Abstract

La función getlogin() es fácil de reemplazar. Por eso, no confíe en el nombre que devuelva.

Explanation

Se supone que la función getlogin() devuelve una cadena que contiene el nombre del usuario registrado actualmente en el terminal. Sin embargo, un atacante podría hacer que getlogin() devuelva el nombre de todos los usuarios registrado en el equipo. No confíe en el nombre devuelto por getlogin() cuando tome decisiones relacionadas con la seguridad.
Ejemplo 1: el código siguiente se basa en getlogin() para determinar si un usuario es de confianza o no. Es fácil de subvertir.


 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }