계: Input Validation and Representation

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

Header Manipulation: SMTP

Abstract

SMTP 헤더에 확인되지 않은 데이터를 포함하면 공격자가 메일 서버를 스팸 봇으로 사용하거나 메일 내용을 자신에게 누출시키는 데 사용할 수 있는 CC, BCC 등의 임의 헤더를 추가할 수 있습니다.

Explanation

SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.
1. 데이터가 신뢰할 수 없는 소스, 주로 웹 응용 프로그램의 HTTP 요청을 통해 응용 프로그램에 들어갑니다.

2. 데이터가 확인 작업을 거치지 않고 메일 서버로 전송되는 SMTP 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 SMTP Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 SMTP 헤더에 데이터를 포함합니다.
가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일 유포입니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.
예제: 다음 코드 세그먼트는 "문의처" 양식의 제목과 본문을 읽습니다.


    func handler(w http.ResponseWriter, r *http.Request) {
        subject := r.FormValue("subject")
        body := r.FormValue("body")
        auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
        to := []string{"recipient@example.net"}
        msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
        err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
        if err != nil {
            log.Fatal(err)
        }
    }

"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


  ...
  subject: [Contact us query] Page not working
  ...

하지만 헤더의 값이 확인되지 않은 사용자 입력에서 생성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악의적인 문자열을 제출하는 경우 SMTP 헤더는 다음과 같은 형식이 됩니다.


  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...

따라서 공격자는 실제로 스팸 메시지를 작성하거나 익명 전자 메일을 전송하는 등의 다양한 공격을 진행할 수 있습니다.

References

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

[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1

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

[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial

[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[7] Standards Mapping - CIS Kubernetes Benchmark complete

[8] Standards Mapping - Common Weakness Enumeration CWE ID 93

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

[10] Standards Mapping - FIPS200 SI

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

[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[14] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[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 Mobile 2014 M1 Weak Server Side Controls

[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

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

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

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

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

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 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 4.0 Requirement 6.2.4

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

[32] 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

[33] 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

[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I

[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I

[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I

[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I

[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[55] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)

desc.dataflow.golang.header_manipulation_smtp

Abstract

SMTP 헤더에 확인되지 않은 데이터를 포함하면 해커는 메일 콘텐트를 자신에게 누출하거나 메일 서버를 스팸 봇으로 이용하는 데 사용할 수 있는 CC 또는 BCC와 같은 임의의 헤더를 추가할 수 있습니다.

Explanation

SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

2. 데이터가 확인을 거치지 않고 메일 서버에 전송된 SMTP 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 SMTP Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 SMTP 헤더에 데이터를 포함합니다.

가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일의 유포에 사용됩니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.

예제: 다음 코드 세그먼트는 "문의처" 양식의 제목 및 본문을 읽습니다.


  String subject = request.getParameter("subject");
  String body = request.getParameter("body");
  MimeMessage message = new MimeMessage(session);
  message.setFrom(new InternetAddress("webform@acme.com"));
  message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
  message.setSubject("[Contact us query] " + subject);
  message.setText(body);
  Transport.send(message);

"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


  ...
  subject: [Contact us query] Page not working
  ...

하지만 헤더의 값이 확인되지 않은 사용자 입력으로 형성되기 때문에 응답은 subject에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ..."과 같은 악성 문자열을 전송하는 경우 SMTP 헤더의 형식은 다음 중 하나가 됩니다.


  ...
  subject: [Contact us query] Congratulations!! You won the lottery
  cc: victim1@mail.com,victim2@mail.com
  ...

이 경우 공격자는 스팸 메시지를 만들거나 익명 전자 메일을 전송할 수 있게 됩니다.

References

[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers

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

[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1

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

[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial

[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[9] Standards Mapping - CIS Kubernetes Benchmark complete

[10] Standards Mapping - Common Weakness Enumeration CWE ID 93

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

[12] Standards Mapping - FIPS200 SI

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

[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)

[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation

[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input

[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws

[18] Standards Mapping - OWASP Top 10 2010 A1 Injection

[19] Standards Mapping - OWASP Top 10 2013 A1 Injection

[20] Standards Mapping - OWASP Top 10 2017 A1 Injection

[21] Standards Mapping - OWASP Top 10 2021 A03 Injection

[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation

[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1

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

[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1

[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1

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

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

[34] 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

[35] 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

[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I

[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I

[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I

[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I

[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I

[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I

[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I

[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I

[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I

[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I

[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I

[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I

[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I

[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I

[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I

[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I

[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I

[57] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)

desc.dataflow.java.header_manipulation_smtp

Abstract

Explanation

SMTP Header Manipulation 취약점은 다음과 같은 경우에 발생합니다.

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

2. 데이터가 확인을 거치지 않고 메일 서버에 전송된 SMTP 헤더에 포함됩니다.

많은 소프트웨어 보안 취약점과 마찬가지로 SMTP Header Manipulation은 목적의 수단일 뿐 목적 자체는 될 수 없습니다. 이 취약점은 본질적으로 간단 명료합니다. 공격자가 악성 데이터를 취약한 응용 프로그램에 전달하고 응용 프로그램은 SMTP 헤더에 데이터를 포함합니다.

가장 일반적인 SMTP Header Manipulation 공격 중 하나는 스팸 전자 메일 유포의 사용입니다. 전자 메일의 제목과 본문을 설정하도록 허용하는 취약한 "문의처" 양식이 응용 프로그램에 있는 경우, 전자 메일이 공격을 당한 서버로부터 전송되기 때문에 공격자는 임의의 콘텐트를 설정하고 익명으로 스팸을 발송할 전자 메일 주소 목록이 포함된 CC 헤더를 삽입할 수 있습니다.

예제: 다음 코드 세그먼트는 "문의처" 양식의 제목 및 본문을 읽습니다.


$subject = $_GET['subject'];
$body =  $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);

"Page not working"과 같은 표준 영숫자로 이루어진 문자열을 요청에 따라 전송한다고 가정하면 SMTP 헤더는 다음과 같은 형식이 될 수 있습니다.


...
subject: [Contact us query] Page not working
...


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...