trufflesecurity/of-cors타이포스쿼팅 도메인과 브라우저 서비스 워커를 사용하여 버그 바운티 대상의 내부 네트워크를 탐색하는 자동화된 CORS 설정 오류 발견 도구
of-CORS는 Truffle Security의 도구 모음으로, 타입스쿼팅을 사용하여 버그 바운티 대상의 내부 네트워크에서 CORS 잘못된 구성을 식별하고 악용합니다.
자세한 내용은 https://trufflesecurity.com/blog/of-CORS에서 확인할 수 있습니다.
of-CORS는 Django와 Django Rest Framework 위에 구축된 Python3 웹 애플리케이션입니다. 설정 및 구성이 완료되면 of-CORS는 애플리케이션을 방문하는 모든 피해자의 브라우저에 브라우저 서비스 워커를 자동으로 등록합니다. 이 서비스 워커는 내부 네트워크에서 CORS 잘못된 구성을 발견하기 위해 사전 구성된 내부 도메인 목록에 HTTP 요청을 보냅니다. 이러한 요청의 결과(성공 여부에 관계없이)는 API를 통해 of-CORS 인스턴스로 다시 제출됩니다.
피해자의 브라우저에 서비스 워커가 등록되면 JavaScript 페이로드가 브라우저를 of-CORS가 원래 접속하려고 했을 것이라고 판단한 페이지로 리디렉션합니다.
수집된 결과는 이후 of-CORS 애플리케이션에서 사용할 수 있는 미니멀리즘 대시보드에서 볼 수 있습니다.
다음 단계를 통해 자체 배포 환경에서 of-CORS를 설정할 수 있습니다.
of-CORS 설정의 복잡성(특히 SSL/TLS, DNS 및 와일드카드 요청 허용 관련 문제)으로 인해 애플리케이션 스택에 두 개의 클라우드 제공업체(Heroku 및 Cloudflare)를 사용하며 Terraform을 사용하여 해당 구성을 자동화합니다.
대상 회사의 내부 직원이 방문할 가능성이 높은 도메인을 구매하는 것부터 시작하세요. 내부 도메인의 타이포스쿼트 도메인을 구매하는 것을 권장합니다. 복사-붙여넣기 오류가 좋은 시작점인 경우가 많습니다.
예를 들어 테스트 중인 회사가 내부 도메인에 uberinternal.com을 사용하는 경우 berinternal.com을 구매하여 내부 직원의 브라우저 트래픽을 수신하기 시작할 수 있습니다.
of-CORS는 와일드카드 DNS 요청을 수신 및 라우팅하고 SSL/TLS 연결을 종료하기 위해 Cloudflare를 사용합니다.
DNS가 of-CORS와 올바르게 작동하려면 활성 Cloudflare 계정이 필요합니다. Cloudflare 계정이 있으면 API 키를 생성해야 합니다(여기 대시보드에서 가능).
API 키는 영역 및 DNS 레코드를 추가, 삭제, 구성할 수 있는 충분한 권한이 있어야 합니다. 이는 API 토큰 생성 페이지에서 다음 권한을 선택하여 달성할 수 있습니다:
올바른 권한으로 API 토큰을 생성한 후 다음 단계로 진행할 수 있습니다.
of-CORS는 쉬운 애플리케이션 배포 및 호스팅을 위해 Heroku를 사용합니다.
of-CORS 애플리케이션 스택을 실행하려면 활성 Heroku 계정이 필요합니다. 계정이 있으면 Heroku CLI(명령줄 인터페이스) 도구를 설치해야 합니다. CLI가 설치되면 다음 명령을 사용하여 인증된 CLI 세션을 시작할 수 있습니다:
heroku login
그런 다음 다음 명령을 실행하여 CLI가 성공적으로 인증되었는지 확인할 수 있습니다:
heroku whoami
Terraform과 함께 사용하기 위해 Heroku CLI를 인증하는 방법에 대한 자세한 문서는 여기에서 찾을 수 있습니다.
인프라에 필요한 API 키가 설정되고 준비되었으므로 배포를 위해 of-CORS를 구성할 차례입니다. 다음 예제 YAML 구성 파일의 내용을 살펴보세요(저장소에서 찾을 수 있음):
terraform:
# You must change this to a unique string that is a valid Heroku app name
heroku_app_name: best-of-cors
# Fill this out with your Cloudflare API token
cloudflare_api_token: this-is-my-api-token
hosts:
# This can be an arbitrary string, but must be unique as a direct descendant of hosts
testing:
host_domain: 127.0.0.1:8080
redirect_domain: google.com
targets:
- enable-cors.org
- example.com
배포를 위해 이 형식의 새 구성 YAML 파일을 만들어야 합니다.
terraform 섹션에서 heroku_app_name을 계정에 고유한 Heroku 호환 앱 이름으로 설정하세요. 또한 위 섹션에서 생성한 Cloudflare API 키를 cloudflare_api_token 지시문 아래에 추가해야 합니다.
hosts 섹션은 of-CORS가 트래픽을 수신할 것으로 예상되는 도메인과 웹 방문자가 도착했을 때 수행할 작업을 정의하는 곳입니다. 예를 들어, 대상 회사가 두 개의 내부 도메인(myinternalcorp1.com 및 myinternalcorp2.com)을 사용한다고 가정해 보겠습니다. 직원이 실수로 방문할 것으로 예상하여 yinternalcorp1.com 도메인을 구매했습니다. 이 경우 hosts를 다음과 같이 구성해야 합니다:
hosts:
testing_1:
host_domain: yinternalcorp1.com
redirect_domain: myinternalcorp1.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
여기서 host_domain은 트래픽을 수신할 것으로 예상되는 도메인(즉, 구매한 도메인)입니다. redirect_domain은 피해자가 페이로드가 실행된 후 리디렉션될 도메인을 정의합니다. targets는 피해자가 of-CORS를 방문할 때 페이로드가 실행될 도메인을 지정합니다.
yinternalcorp2.com도 구매했고 방문 시 공격을 실행하도록 of-CORS를 구성하려는 경우 hosts 섹션은 다음과 같이 업데이트될 수 있습니다:
hosts:
testing_1:
host_domain: yinternalcorp1.com
redirect_domain: myinternalcorp1.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
testing_2:
host_domain: yinternalcorp2.com
redirect_domain: myinternalcorp2.com
targets:
- myinternalcorp1.com
- myinternalcorp2.com
이제 피해자가 실수로 yinternalcorp1.com 또는 yinternalcorp2.com를 방문하면 myinternalcorp1.com 및 myinternalcorp2.com에서 CORS 잘못된 구성을 열거하는 페이로드가 실행되고 피해자의 브라우저는 올바른 도메인으로 리디렉션됩니다.
Docker 옵션을 사용하면 Terraform, Heroku, Python을 설치할 필요가 없습니다. yaml 파일의 올바른 경로를 설정하여 다음 명령을 실행하기만 하면 됩니다:
docker run -v $PWD/config.yml:/config.yml -it --rm trufflesecurity/of-cors
of-CORS 배포는 Terraform에 의존합니다. 여기의 지침에 따라 Terraform을 설치할 수 있습니다. 설치가 완료되면 terraform 바이너리가 시스템의 PATH에서 사용 가능해야 합니다.
of-CORS 배포는 Python3에도 의존합니다. 시스템의 PATH에 설치되어 사용 가능한지 확인하세요.
클라우드 제공업체에 대한 인증이 완료되고 of-CORS 구성 파일이 준비되었으면 이제 배포를 진행할 수 있습니다.
먼저 Terraform을 초기화해야 합니다. 이 명령은 소스 코드 루트 디렉터리에서 실행해야 합니다:
cd terraform && terraform init && cd ../
구성 파일이 /tmp/of_cors_config.yml에 있다고 가정해 보겠습니다. 그런 다음 다음 명령을 실행하여 모든 of-CORS 인프라를 가동합니다(bash에서 명령이 실행된다고 가정). 이 명령은 실행하는 데 5~10분이 소요될 수 있으니 인내심을 가지고 기다려 주세요!
또한 대규모 열거의 경우 Heroku가 리소스 부족을 겪는 경우가 많습니다. 이는 알려진 문제이며, 수정에 도움을 주시면 감사하겠습니다. 가능한 향후 수정 사항으로는 직접 열거 내용을 업로드할 수 있도록 하는 기능, Heroku Dyno 크기 증가, Sublist3r 또는 다른 열거 도구로 전환하는 방법 등이 있습니다.
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
CONFIG_FILE=/tmp/of_cors_config.yml make deploy_and_configure
참고 사항 - Heroku 인프라가 가동되고 동시에 콘솔에 즉시 액세스할 때 경합 조건이 발생할 수 있습니다. 이 마지막 make deploy_and_configure 명령이 실패하면 몇 분간 기다렸다가 다시 실행해 보세요.
deploy_and_configure 명령 실행이 완료되면 다음이 준비됩니다...
of-CORSof-CORS 배포가 트래픽을 수신할 준비가 되기 위해 마지막으로 해야 할 일은 구매한 도메인 이름이 Cloudflare를 권위 있는 DNS 서버로 사용하도록 구성하는 것입니다. Cloudflare에는 이 작업을 수행하는 방법에 대한 자세한 가이드가 있습니다.
다음 단계를 통해 소프트웨어가 올바르게 실행되고 있는지 확인하세요. 이 섹션에서는 hackersofhollywood.com 도메인 아래에 설정된 of-CORS 인스턴스를 예로 사용하겠습니다.
먼저 도메인의 SOA 레코드가 Cloudflare를 가리키는지 확인합니다:
dig soa <domain>
아래와 같이 hackersofhollywood.com의 SOA 레코드가 Cloudflare 네임서버를 올바르게 가리키는 것을 확인할 수 있습니다:
그런 다음 Cloudflare 계정을 검토하여 hackersofhollywood.com 및 *.hackersofhollywood.com 모두에 대해 Heroku 도메인을 가리키는 CNAME 콘텐츠가 포함된 DNS 레코드가 설정되었는지 확인합니다. 이는 Cloudflare 웹 UI의 DNS 섹션에서 수행됩니다:
다음 단계는 Heroku가 이 두 CNAME 레코드를 통해 트래픽을 수신하도록 구성되었는지 확인하는 것입니다. 이는 Heroku 웹 UI의 Settings -> Domains에서 확인할 수 있습니다:
확실히 Heroku에 적절한 DNS 대상을 사용하여 구성된 두 개의 도메인 이름이 있으며 이러한 대상이 Cloudflare의 CNAME 레코드에 올바르게 반영되어 있습니다.
그런 다음 다음 명령을 실행하여 of-CORS의 결과 뷰어 페이지로 인증된 브라우저 세션을 열 수 있습니다:
CONFIG_FILE=<path_to_config_file> make open_heroku_console
그러면 브라우저에 빈 대시보드가 표시됩니다:
마지막으로 CORS 잘못된 구성 프로빙이 성공적으로 실행되는지 테스트할 수 있습니다. 구성 중 하나의 기본 도메인(예: https://hackersofhollywood.com)으로 브라우저를 열고 페이지가 몇 초 후에 리디렉션되는지 확인합니다:
이제 대시보드 페이지로 다시 이동하여 Success 필터를 Unknown으로 변경하고 Submit Query 버튼을 누릅니다. 그러면 많은 결과가 채워진 것을 볼 수 있습니다:
덫이 설정되었습니다! 이제 편안히 앉아 휴식을 취하며 피해자들이 맛있는 작은 도메인을 우연히 발견하기를 기다리기만 하면 됩니다.
다음 명령을 사용하여 인증된 브라우저 세션에서 모든 결과를 보고 쿼리할 수 있습니다:
CONFIG_FILE=<path_to_config_file> make open_heroku_console
of-CORS 구성 파일은 공격이 실행되는 도메인의 유연한 추가 및 제거를 지원하도록 설계되었습니다. 구성 파일의 hosts 섹션 내용을 업데이트하고 프로비저닝 스크립트를 다시 실행하기만 하면 됩니다:
source venv/bin/activate
CONFIG_FILE=/tmp/of_cors_config.yml make deploy_and_configure