531 개 항목 찾음

취약점

Access Control: LDAP

Abstract

적절한 access control 없이 사용자가 제어하는 값을 포함하는 LDAP 문을 실행하면 공격자가 허가 받지 않은 디렉터리 항목에 접근할 수 있습니다.

Explanation

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.

2. 데이터는 LDAP 쿼리에서 데이터 값을 지정하는 데 사용됩니다.
예제 1: 현재 인증된 사용자의 직원 ID가 클라이언트 쪽 인터페이스에 의한 각 요청으로 자동 제출됩니다. 다음 코드는 LDAP 쿼리를 생성하기 전에 허용 목록을 사용하여 직원 이름을 정확하게 검증합니다. 이 검증은 LDAP injection 취약점을 예방하지만 코드가 취약해질 수 있습니다.


static string AllowlistVerify(string name) {
    Regex pattern = new Regex(@"^[a-zA-Z\-\.']+$");
    if (pattern.IsMatch(name)) {
        return name;
    }
    return null;
}

...
string verifiedName = AllowlistVerify(managerName.Text.trim());
if(verifiedName != null) {
    DirectorySearcher src = new DirectorySearcher("(manager=" + verifiedName + ")");
    src.SearchRoot = de;
    src.SearchScope = SearchScope.Subtree;

    foreach(SearchResult res in src.FindAll()) {
        ...
    }
}

문제는 개발자가 공격자가 empName의 다른 값을 제공할 경우 발생될 일에 대해 고려하지 못했다는 점입니다. 인터페이스에서 현재 사용자의 직원 ID를 자동으로 제공하지만 공격자는 악의적인 요청의 일부로 다른 값을 제공할 수 있습니다. 이 예제의 코드가 익명의 바인딩에서 쿼리를 실행하므로 현재 인증된 사용자의 ID와 관계 없이 올바른 직원 ID에 대한 디렉터리 항목을 반환할 것입니다.

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3

[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1

[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1

[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality

[5] Standards Mapping - CIS Kubernetes Benchmark complete

[6] Standards Mapping - Common Weakness Enumeration CWE ID 639

[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863

[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-001084, CCI-002165

[9] Standards Mapping - FIPS200 AC

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

[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)

[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement

[13] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control

[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference

[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References

[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References

[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control

[18] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control

[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.2 General Access Control Design (L1 L2 L3), 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3)

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

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

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

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4

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

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8

[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8

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

[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control

[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls

[34] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863

[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.1 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3480.1 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3480.1 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3480.1 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3480.1 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3480.1 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3480.1 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-002360 CAT II

[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001540 CAT I, APSC-DV-002360 CAT II

[56] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)

[57] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization

desc.dataflow.dotnet.access_control_ldap

Abstract

적절한 access control 없이 사용자가 제어하는 값을 포함하는 LDAP 문을 실행하면 공격자가 허가 받지 않은 디렉터리 항목에 접근할 수 있습니다.

Explanation

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.

2. 데이터는 LDAP 쿼리에서 데이터 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 LDAP 쿼리를 생성하기 전에 허용 목록을 사용하여 소켓에서 읽은 직원 이름을 검증합니다. 이 검증은 LDAP injection 취약점을 예방하지만 코드가 취약해질 수 있습니다.


char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

문제는 개발자가 공격자가 username의 다른 값을 제공할 경우 발생될 일에 대해 고려하지 못했다는 점입니다. 이 예제의 코드가 익명의 바인딩에서 쿼리를 실행하므로 현재 인증된 사용자의 ID와 관계 없이 올바른 직원 ID에 대한 디렉터리 항목을 반환할 것입니다.