Relative XSS를 이용한 Cookie & Session Cache or Overwrite

개요

[취약점 제보에 대한 개요를 작성해 주세요]
BABY 문제의 URL인 http://webhacking.kr:10010 사이트에서 발생하는 Tag Injection 기능과 MEMO Service 문제의 http://webhacking.kr:10013/favicon.ico 사이트에서 발생하는 Header Injection을 이용한 PHPSESSION Overwrite or Cache 후 webhacking.kr session 발급 Logic을 이용한 쿠키 세션 탈취

재현 과정

[취약점 재현을 하기 위한 과정을 서술해 주세요]

1. Tag Injection
   BABY 문제(http://webhacking.kr:10010/)의 경우 Tag Injection이 가능하게 됩니다. 아래의 URL로 이동시 Injection된 h1 Tag를 확인할 수 있습니다. http://webhacking.kr:10010/?inject=%3Ch1%3ETag%20Injection%3C/h1%3E
   
2. Header Injection
   MEMO Service 문제(http://webhacking.kr:10013/)의 경우 http://webhacking.kr:10013/favicon.ico의 URL에서 Header Injection이 가능합니다. 해당 http://webhacking.kr:10013/favicon.ico%0d%0afoo:%20bar URL로 요청을 하게되면 사진과 같이 Header에 사용자가 입력한 값이 들어가는 것을 확인할 수 있습니다.
   
3. webhacking.kr의 session 발급 방식
   webhacking.kr에 접속을 하면 아래의 사진과 같이 Cookie가 존재하지 않으면 Set-Cookie를 통해서 쿠키를 생성해주며
   
   이미 쿠키가 존재한다면 발급을 해주지 않습니다.
   
   또한 로그인을 할 경우도 마찬가지로 쿠키 값이 존재한다면 넘겨준 쿠키 값을 이용하여 session을 서버에서 관리해주며 쿠키가 없을 경우 서버에서 발급해 줍니다.
   ex)쿠키 값 미존재
   
   ex)쿠키 값 존재
   
4. HttpOnly FIltering
   사이트에 쿠키에는 HttpOnly가 설정되어 있어 BABY 문제에서 발생하는 Tag Injection을 이용한 XSS를 통해서 쿠키 세션 탈취가 불가능합니다.
   
   
5. HttpOnly Filtering Bypass
   하지만 Javascript를 통해서 쿠키 접근만 불가능한 것이기 때문에 앞에서 말씀드린 Header Injection을 통해서 Set-Cookie를 통해 브라우저가 webhacking,kr에서 쿠키가 생성되었다고 인식하게 만드는것은 가능하게 됩니다.
   http://webhacking.kr:10010/?inject=%3Cstyle%3E@import%20url(%22http://webhacking.kr:10013/favicon.ico%250d%250aSet-Cookie:%20PHPSESSID=payload;%22);%3C/style%3E 해당 URL을 통해서 style Tag Injection을 시도하고 import를 통해서 http://webhacking.kr:10013/favicon.ico%250d%250aSet-Cookie:%20PHPSESSID=payload; URL에 요청을 날리게 됩니다. 하지만 앞에서 말씀드린 Header Injection이 가능한 사이트에 Set-Cookie를 통해 PHPSESSID에 공격자가 원하는 값을 넣어주어 쿠키가 이미 있는 경우 Overwrite를 없는 경우 임의 쿠키로 Caching할 수 있습니다.
   정상적인 http://webhacking.kr:10010/?inject=foo의 요청
   
   악의적인 사용자로부터 클릭한 http://webhacking.kr:10010/?inject=%3Cstyle%3E@import%20url(%22http://webhacking.kr:10013/favicon.ico%250d%250aSet-Cookie:%20PHPSESSID=payload;%22);%3C/style%3E의 요청
   
   favicon.ico의 Request & Reponse
   
   Cookie가 Overwrite된 모습
   
6. Login
   해당 문제를 풀고 난 뒤 Flag를 인증하려고 하면 Login을 해야하는데 실제로 사용자의 Cookie 값을 공격자가 원하는 값으로 변조할 수 있고 해당 변조한 Cookie를 통해서 로그인을 할 경우 변조된 Cookie로 세션이 발급됩니다.
   

예상되는 취약점 발생 원인

[해당 취약점이 발생하는 예상 원인을 서술해 주세요]
로그인시 전달된 Cookie를 재사용

패치 방법

[해당 취약점을 패치하기 위한 대응 방법을 서술해 주세요]
로그인 성공시 항상 새로운 세션을 발급해줍니다.

예상 결과 및 파급력

[해당 취약점으로 인해 예상되는 결과 및 파급력을 서술해 주세요. 시나리오가 포함되어도 좋습니다.]
URL 피싱 혹은 리다이렉트를 통해 사용자의 쿠키 및 세션을 공격자가 원하는 값으로 조작하여 탈취할 수 있습니다.
또한 한번 피싱을 당했다면 해당 쿠키는 삭제 시간을 정해주지않아 PC에 삭제되지 않고 상주하기 때문에 동일한 PC를 사용한다면 지속적인 위협을 받을 수 있습니다.
또한 해당 사이트에 Stored XSS 취약점을 트리거할 수 있다면 매우 큰 파급력이 예상됩니다.

기타사항 및 레퍼런스

[그 외에 추가할 내용이 있다면 이곳에 작성해주세요.(스크린샷, 로그 등)]

• [첨부파일 / 레퍼런스]