계: Input Validation and Representation

입력 검증 및 표현 문제는 메타 문자, 대체 인코딩 및 숫자 표현 때문에 발생합니다. 보안 문제는 입력을 신뢰하기 때문에 발생합니다. 문제로는 "Buffer Overflows", "Cross-Site Scripting" 공격, "SQL Injection", 그 외 여러 가지가 있습니다.

175 개 항목 찾음
취약점

Buffer Overflow: Format String (%f/%F)

Abstract
프로그램은 %f 또는 %F 부동 소수점 지정자를 포함하는 부적절한 경계 format string을 사용합니다. 예상치 않은 큰 부동 소수점 값은 프로그램이 할당된 메모리 블록 경계 외부에 데이터를 쓸 수 있게 하여 데이터가 손상되거나, 프로그램이 중단되거나 악성코드가 실행될 수 있습니다.
Explanation
Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

이 경우 부적절하게 생성된 format string으로 인해 프로그램이 할당된 메모리 경계를 넘어서 쓸 수 있습니다.

예제: 다음 코드는 f의 크기에 따라 format string 지정자 "%d %.1f ... "가 할당된 메모리의 양을 초과할 수 있으므로 buf 오버플로를 일으킵니다.


void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 787
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[41] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_format_string_%f_%F

Buffer Overflow: Off-by-One

Abstract
프로그램이 할당된 메모리의 경계를 바로 지나 쓰면 데이터가 손상되거나, 프로그램이 중단되거나 악성 코드가 실행될 수 있습니다.
Explanation
Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 off-by-one 오류가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 스택 및 힙 buffer overflow를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

예제: 다음 코드에는 off-by-one buffer overflow가 있습니다. 이는 recv가 읽은 최대 허용되는 sizeof(buf) 바이트를 반환할 때 발생합니다. 이 경우, 이후의 buf[nbytes] 역참조는 할당된 메모리 블록의 경계 외부에서 null 바이트를 씁니다.


void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 129, CWE ID 131, CWE ID 193, CWE ID 787, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [3] CWE ID 020, [12] CWE ID 787
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [3] CWE ID 020, [2] CWE ID 787
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [4] CWE ID 020, [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [4] CWE ID 020, [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [6] CWE ID 020, [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1, Rule 18-0-5
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[42] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805, Risky Resource Management - CWE ID 129, Risky Resource Management - CWE ID 131
[43] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 131
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[66] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_off_by_one

Buffer Overflow: Signed Comparison

Abstract
프로그램이 부호 있는 비교를 사용하여 부호가 없이 나중에 처리되는 값을 확인합니다. 이로 인해 프로그램이 할당된 메모리 블록 경계 외부에 쓸 수 있게 되고, 따라서 데이터가 손상되거나, 프로그램이 중단되거나 악성코드가 실행될 수 있습니다.
Explanation
Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

예제: 다음 코드는 getInputLength()에서 읽은 신뢰할 수 없는 값이 대상 버퍼 output의 크기보다 작은지 확인하여 off-by-one buffer overflow를 막습니다. 그러나 len과 MAX의 비교에 부호가 있으므로 len이 음수인 경우 부호 없는 인수가 memcpy()로 변환되면 매우 큰 양수가 됩니다.


void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 195, CWE ID 805
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[16] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[17] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[20] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[21] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[22] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[23] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[40] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.internal.cpp.buffer_overflow_signed_comparison

Client-Side Template Injection

Abstract
사용자 제어 데이터가 템플릿 엔진의 템플릿으로 사용되어 공격자가 템플릿 컨텍스트에 액세스하고 경우에 따라 브라우저에서 악성 코드를 삽입 및 실행할 수 있습니다.
Explanation
템플릿 엔진은 동적 데이터를 사용하여 콘텐트를 렌더링하는 데 사용됩니다. 이 컨텍스트 데이터는 일반적으로 사용자에 의해 제어되고 웹 페이지, 전자 메일 등을 생성하는 템플릿을 통해 서식이 지정됩니다. 템플릿 엔진을 사용하면 조건절, 루프 등과 같은 코드 생성과 함께 컨텍스트 데이터를 처리함으로써 템플릿에 강력한 언어 식을 사용하여 동적 컨텐츠를 렌더링할 수 있습니다. 공격자가 렌더링될 템플릿을 제어할 수 있는 경우 컨텍스트 데이터를 노출하는 식을 삽입하거나 브라우저에서 악성 코드를 실행할 수도 있습니다.

예제 1: 다음 예제는 템플릿이 URL에서 검색되고 AngularJS로 정보를 렌더링하는 데 사용되는 방법을 보여줍니다.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}


이 경우 $stateParams.expression은 잠재적으로 사용자 제어 데이터를 사용하고, 이를 지정된 컨텍스트에서 사용될 템플릿으로 평가합니다. 이로 인해 악의적인 사용자가 브라우저 내에서 원하는 코드를 임의로 실행하여 실행 대상 컨텍스트에 대한 정보를 검색하거나, 응용 프로그램이 생성되는 방법에 대한 추가 정보를 찾거나, 이를 완전한 XSS 공격으로 변환할 수 있습니다.
References
[1] AngularJS Security Guide Google
desc.dataflow.javascript.client_side_template_injection

ColdFusion Bad Practices: Unauthorized Include

Abstract
페이지에 포함된 파일의 경로를 지정하도록 확인되지 않은 사용자 입력을 허용하면 공격자가 서버에 악성 코드를 삽입하거나 민감한 파일을 볼 수 있습니다.
Explanation
Unauthorized include 취약점은 다음 경우에 발생합니다.

1. 데이터가 신뢰할 수 없는 소스, 주로 웹 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터는 <cfinclude> 태그의 template 속성을 지정하는 문자열의 일부입니다.
예제: 다음 코드는 웹 폼의 입력을 사용하여 사용자의 홈페이지를 포맷하는 데 사용되는 특수 파일에 대한 경로를 생성합니다. 프로그래머는 공격자가 "../../users/wileyh/malicious" 등의 악성 파일 이름을 제공하여 응용 프로그램이 공격자의 홈 디렉터리에 있는 파일의 내용을 포함하고 실행하게 만들 가능성을 고려하지 않았습니다. 


<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">
<cfinclude> 태그에 포함된 파일을 지정할 수 있도록 허용된 경우, 공격자는 응용 프로그램으로 하여금 서버의 파일 시스템에 있는 거의 모든 파일 내용을 현재 페이지에 포함시키도록 할 수 있습니다. 이 기능은 최소한 두 가지의 중요한 방법으로 이용할 수 있습니다. 공격자가 사용자의 홈 디렉터리 또는 일반 업로드 디렉터리와 같은 서버의 파일 시스템에 있는 위치에 기록할 수 있는 경우, 응용 프로그램으로 하여금 서버에서 실행될 페이지에 악의적으로 조작된 파일을 포함하도록 할 수 있습니다. 서버의 파일 시스템에 대한 쓰기 접근 권한이 없더라도 공격자는 서버에 파일의 경로를 지정하여 민감한 정보 또는 개인 정보에 대한 접근 권한을 얻을 수 있습니다.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 94
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.unauthorized_include

Command Injection

Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 레지스트리 키 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...
Example 1의 코드는 레지스트리 항목 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 레지스트리에서 읽은 값을 확인하지 않기 때문에 공격자가 레지스트리 키 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 일부 임시 파일을 삭제하는 것을 허용하는 관리용 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 SXPG_COMMAND_EXECUTE_LONG 함수 모듈은 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 CALL 'SYSTEM'에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 CALL 'SYSTEM' 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 구성 파일의 입력을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...
Example 1의 코드는 구성 파일 configStream의 내용을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 파일에서 읽은 값을 확인하지 않기 때문에 공격자가 해당 값을 제어할 수 있는 경우, 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 fscommand() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 fscommnd()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


        ...
        fscommand("exec", "make");
        ...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 fscommand() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.actionscript.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


이때 문제는 프로그램이 BackupTypeField에 대해 검증을 수행하지 않는다는 점입니다. 일반적으로 Process.Start() 함수는 여러 명령을 실행하지 않지만, 이 경우에는 프로그램이 Process.Start()에 대한 단일 호출로 여러 명령을 실행하기 위해 먼저 cmd.exe 셸을 실행합니다. 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자에게 시스템의 암호를 업데이트할 수 있는 인터페이스에 대한 액세스를 제공하는 웹 응용 프로그램의 일부입니다. 이 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 다음에서처럼 update.exe 명령을 실행하는 것입니다.


...
Process.Start("update.exe");
...


여기서 문제는 프로그램이 절대 경로를 지정하지 않아 Process.start() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 update.exe라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 update.exe는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.dotnet.command_injection
Abstract
확인되지 않은 사용자 입력이 포함된 명령을 수행하면 응용 프로그램이 공격자 대신 그 역할을 하게 됩니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이런 경우, 주로 공격자가 명시적으로 실행되는 명령을 제어하는 첫 번째 시나리오가 관심의 대상이 됩니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열의 일부입니다.


3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음의 간단한 프로그램은 파일 이름을 명령줄 인수로 받아 파일의 내용을 사용자에게 표시합니다. 프로그램은 교육 중인 시스템 관리자에게 권한 있는 시스템 파일을 수정하거나 시스템을 손상시킬 수 있는 능력을 부여하지 않으면서 시스템 파일을 검사할 수 있는 학습 도구로 사용하기 위한 것이기 때문에 setuid root로 설치됩니다.


int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}


프로그램이 root 권한으로 실행되기 때문에 system() 호출도 root 권한으로 실행됩니다. 사용자가 표준 파일 이름을 지정하는 경우 호출은 예상대로 동작합니다. 하지만 공격자가 ";rm -rf /" 형식의 문자열을 전달하면 system() 호출은 인수가 없어 cat을 실행할 수 없고 루트 파티션을 침범하여 루트 파티션의 내용을 재귀적으로 삭제합니다.

예제 2: 권한 있는 프로그램에서 발췌한 다음 코드는 환경 변수 $APPHOME을 사용하여 응용 프로그램의 설치 디렉터리를 결정한 다음 해당 디렉터리에서 초기화 스크립트를 실행합니다.


	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...
Example 1에서처럼, 이 예제의 코드도 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 이 예제에서 공격자는 환경 변수 $APPHOME을 수정하여 INITCMD의 악성 버전이 들어 있는 다른 경로를 지정할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에 공격자는 환경 변수를 제어하여 응용 프로그램이 악성 코드를 실행하도록 만들 수 있습니다.

공격자는 환경 변수를 사용하여 프로그램이 호출하는 명령을 제어하므로 이 예제는 환경의 영향이 명시적입니다. 이번에는 공격자가 명령이 해석되는 방식을 변경할 때 어떤 일이 발생하는지 살펴 보겠습니다.

예제 3: 다음 코드는 사용자가 암호를 변경할 수 있는 웹 기반 CGI 유틸리티에서 발췌한 것입니다. NIS의 암호 업데이트 프로세스에는 /var/yp 디렉터리에서 make를 실행하는 일이 포함됩니다. 프로그램이 암호 레코드를 업데이트하기 때문에 setuid root가 설치되었습니다.

프로그램은 다음과 같이 make를 호출합니다.


system("cd /var/yp && make &> /dev/null");


앞의 예제와 달리, 이 예제의 명령은 하드코드되어 있기 때문에 공격자가 system()에 전달되는 인수를 제어할 수 없습니다. 하지만 프로그램이 make의 절대 경로를 지정하지 않고 명령을 호출하기 전에 환경 변수를 초기화하지 않기 때문에 공격자가 make라는 악성 바이너리를 가리키도록 $PATH 변수를 수정하여 셸 프롬프트에서 CGI 스크립트를 실행할 수 있습니다. 프로그램이 setuid root를 설치했으므로 공격자가 만든 make가 이제 root 권한으로 실행됩니다.

Windows에서는 또 다른 위험이 존재합니다.

예제 4:_spawn() 패밀리의 함수 중 하나를 호출하여 CreateProcess()를 호출하거나 직접 호출하는 경우에는 실행 파일 또는 경로의 공백에 주의해야 합니다.


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...


공백에 대한 CreateProcess()의 구문 분석 방식에 따라 운영 체제가 첫 번째로 실행하려는 실행 파일은 MyApplication.exe가 아니라 Program.exe가 됩니다. 따라서 공격자가 시스템에 Program.exe라고 하는 악성 응용 프로그램을 설치하면 Program Files 디렉터리를 사용하여 CreateProcess()를 잘못 호출하는 모든 프로그램에서 의도된 응용 프로그램이 아니라 이 악성 응용 프로그램이 실행됩니다.

환경(environment)은 프로그램 내에서 시스템 명령을 실행할 때 중요한 역할을 합니다. system(), exec() 및 CreateProcess()와 같은 함수는 자신을 호출하는 프로그램의 환경을 사용하므로 공격자가 호출 동작에 영향을 줄 수 있는 기회가 생깁니다.
desc.dataflow.cpp.command_injection
Abstract
절대 경로를 지정하지 않고 명령을 실행하면 공격자가 $PATH 또는 프로그램 실행 환경의 다른 측면을 변경하는 방법으로 프로그램을 사용하여 악성 바이너리를 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램에 대한 매개 변수를 제어할 수 있습니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

여기서 공격자가 환경 변수를 변경하거나 검색 경로 앞부분에 악성 실행 파일을 삽입하여 명령의 의미를 변경할 수 있는 두 번째 시나리오를 중점적으로 다루겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 공격자가 응용 프로그램의 환경을 수정합니다.

2. 응용 프로그램이 절대 경로를 지정하거나 실행 중인 바이너리를 확인하지 않고 명령을 실행합니다.



3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 이 예제는 공격자가 명령이 해석되는 방법을 변경할 수 있는 경우 일어나는 결과를 보여줍니다. 이 코드는 사용자가 암호를 변경할 수 있는 웹 기반 CGI 유틸리티에서 발췌한 것입니다. NIS의 암호 업데이트 프로세스에는 /var/yp 디렉터리에서 make를 실행하는 일이 포함됩니다. 프로그램이 암호 레코드를 업데이트하기에 setuid root가 설치되었습니다.

프로그램은 다음과 같이 make를 호출합니다.


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
                               length of command-line
                               run-unit-id
                               stack-size
                               flags


이 예제의 명령은 하드코드되었으므로 공격자가 CBL_EXEC_RUN_UNIT에 전달된 인수를 제어할 수 없습니다. 그러나 프로그램이 make에 대한 절대 경로를 지정하지 않고 명령을 호출하기 전에 환경 변수를 초기화하지 않기 때문에 공격자는 $PATH 변수를 make라는 악성 바이너리를 가리키도록 수정하고 셸 프롬프트에서 CGI 스크립트를 실행할 수 있습니다. 또한 프로그램에 setuid root가 설치되었기 때문에 공격자의 make 버전은 이제 root 권한으로 실행됩니다.

예제 2: 다음 코드는 환경 변수를 사용하여 pdfprint 명령으로 인쇄할 파일이 포함된 임시 디렉터리를 결정합니다.


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
             ws-temp-dir DELIMITED SPACE
             "/" DELIMITED SIZE
             ws-pdf-filename DELIMITED SPACE
             x"00" DELIMITED SIZE
             INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


이전 예제와 마찬가지로 이 명령은 하드코드되었습니다. 그러나 프로그램이 pdfprint에 대한 절대 경로를 지정하지 않기 때문에 공격자는 악성 바이너리를 가리키도록 $PATH 변수를 수정할 수 있습니다. 게다가 DELIMITED SPACE 구문이 ws-temp-dir 및 ws-pdf-filename에 공간이 포함되는 것을 방지하지만 여기에 셸 메타 문자(예: &&)가 포함되어 있을 수 있습니다.
desc.semantic.cobol.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드를 사용하면 공격자는 cmd 요청 매개 변수를 통해 임의의 명령을 지정할 수 있습니다.


    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...
desc.dataflow.cfml.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경할 수 있습니다. 즉, 공격자가 실행되는 명령을 명시적으로 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행되는 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴 보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 시스템 유틸리티의 다음 코드는 시스템 속성 APPHOME을 사용하여 유틸리티가 설치된 디렉터리를 확인한 다음 지정된 디렉터리의 상대 경로를 기준으로 하여 초기화 스크립트를 실행합니다.


	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.
desc.dataflow.dart.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴 보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제: 다음 코드는 사용자 컨트롤러 명령을 사용합니다.


  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()
desc.dataflow.golang.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
System.Runtime.getRuntime().exec("make");
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

모바일 환경에서는 command injection과 같은 전형적인 취약점이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 4: 다음 코드는 Android 인텐트에서 실행할 명령을 읽습니다.


...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...


루팅된 장치에서 악성 응용 프로그램은 공격 대상 응용 프로그램이 수퍼 사용자 권한을 사용하여 임의의 명령을 실행하도록 강제 지정할 수 있습니다.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 환경 변수 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작하도록 설계된 관리 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);


이때 문제는 프로그램에서 사용자로부터 읽어들인 backuptype 매개 변수가 있는지 확인하지도 이를 검증하지도 않는다는 점입니다. 셸을 호출하면 여러 명령을 실행하도록 허용할 수 있으며, 응용 프로그램의 속성 때문에 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 따라서 공격자가 삽입하는 명령도 모두 이러한 권한으로 실행됩니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 child_process.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.javascript.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
$result = shell_exec("make");
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.php.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제: 다음 코드는 신뢰할 수 있는 데이터로 호출될 경우 공격자가 제어하는 시스템 명령을 실행하는 T-SQL 저장 프로시저를 정의합니다.


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
result = os.system("make");
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 os.system() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.python.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 일부 임시 파일을 삭제하는 것을 허용하는 관리용 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. Kernel.spawn을 통해 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
system("make")
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Kernel.system() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.ruby.command_injection
Abstract
확인되지 않은 사용자 입력이 있는 명령을 실행하면 응용 프로그램이 공격자 대신 악의적인 명령을 실행하는 결과가 발생할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

여기서는, 공격자가 환경 변수를 변경하거나 악성 실행 파일을 검색 경로에 삽입하여 명령의 의미를 변경할 수 있는 두 번째 시나리오를 중점적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 공격자가 응용 프로그램의 환경을 수정합니다.

2. 응용 프로그램은 절대 경로 지정 또는 수행하는 이진 파일 확인 등의 작업을 거치지 않고 명령을 실행합니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 


def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경에서 명령을 실행하면 공격자 대신 응용 프로그램이 악의적인 명령을 실행할 수 있습니다.
Explanation
Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

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

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.


	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...
Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.


...
$result = shell_exec("make");
...


여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.
desc.dataflow.vb.command_injection

Command Injection: GitHub Actions

Abstract
GitHub Action 실행 스크립트에서 특정 GitHub Action 표현식을 직접 참조하면 시스템이 명령 주입에 취약해집니다.
Explanation
실행 스크립트에서 GitHub Action 표현식에 대한 직접 참조는 동적으로 생성됩니다. 이 경우 입력 제어 권한이 있는 모든 사용자가 명령 주입을 사용하여 시스템을 손상시킬 수 있습니다.

예제 1: GitHub Action의 다음 코드는 실행 스크립트의 표현식을 직접 참조하므로 시스템이 명령 주입에 노출됩니다.


    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...


해당 작업이 실행되면 github.event.pull_request.title 값이 나타내는 모든 코드를 포함하여 셸 스크립트가 동적으로 실행됩니다. github.event.pull_request.title에 악성 실행 코드가 포함되어 있으면 이 작업에서 악성 코드가 실행되므로 명령이 주입됩니다.

References
[1] Security Hardening for GitHub Actions - Good Practices for Mitigating Script Injection Attacks
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 77, CWE ID 78
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [11] CWE ID 078
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [10] CWE ID 078
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [5] CWE ID 078, [25] CWE ID 077
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A1 Injection
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.8 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.2 File Execution Requirements (L1 L2 L3), 12.3.5 File Execution Requirements (L1 L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[27] Standards Mapping - OWASP Mobile 2024 M2 Inadequate Supply Chain Security
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[41] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.structural.yaml.command_injection_github_actions