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

Writer 장종민 Program webhacking.kr

WEB Informative None No Reward Last Updated: Aug 21, 2021 (4 months ago) Created: Aug 20, 2021

Weakness

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

Description

개요

[취약점 제보에 대한 개요를 작성해 주세요]
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
    image.png
  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에 사용자가 입력한 값이 들어가는 것을 확인할 수 있습니다.
    image.png
  3. webhacking.kr의 session 발급 방식
    webhacking.kr에 접속을 하면 아래의 사진과 같이 Cookie가 존재하지 않으면 Set-Cookie를 통해서 쿠키를 생성해주며
    image.png
    이미 쿠키가 존재한다면 발급을 해주지 않습니다.
    image.png
    또한 로그인을 할 경우도 마찬가지로 쿠키 값이 존재한다면 넘겨준 쿠키 값을 이용하여 session을 서버에서 관리해주며 쿠키가 없을 경우 서버에서 발급해 줍니다.
    ex)쿠키 값 미존재
    image.png
    ex)쿠키 값 존재
    image.png
  4. HttpOnly FIltering
    사이트에 쿠키에는 HttpOnly가 설정되어 있어 BABY 문제에서 발생하는 Tag Injection을 이용한 XSS를 통해서 쿠키 세션 탈취가 불가능합니다.
    image.png
    image.png
  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의 요청
    image.png
    악의적인 사용자로부터 클릭한 http://webhacking.kr:10010/?inject=%3Cstyle%3E@import%20url(%22http://webhacking.kr:10013/favicon.ico%250d%250aSet-Cookie:%20PHPSESSID=payload;%22);%3C/style%3E의 요청
    image.png
    favicon.ico의 Request & Reponse
    image.png
    Cookie가 Overwrite된 모습
    image.png
  6. Login
    해당 문제를 풀고 난 뒤 Flag를 인증하려고 하면 Login을 해야하는데 실제로 사용자의 Cookie 값을 공격자가 원하는 값으로 변조할 수 있고 해당 변조한 Cookie를 통해서 로그인을 할 경우 변조된 Cookie로 세션이 발급됩니다.
    image.png

예상되는 취약점 발생 원인

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

패치 방법

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

Impact

예상 결과 및 파급력

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

기타사항 및 레퍼런스

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

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

Timeline

장종민 submitted ticket. August 20, 2021 (4 months ago)
rubiya MANAGER changed the severity from 'Critical' to 'None'. August 21, 2021 (4 months ago)
rubiya MANAGER changed the status from 'Submitted' to 'Informative'. August 21, 2021 (4 months ago)
rubiya MANAGER changed the disclosure from 'Closed' to 'Disclosed (Full)'. August 21, 2021 (4 months ago)
rubiya MANAGER posted a comment. August 21, 2021 (4 months ago)

보상에서 제외되는 경우에 명시된 “악성 URL 클릭등의 User Interaction이 요구되는 Client Side 취약점” 항목에 해당한다고 판단하여 Close하겠습니다.

장종민 posted a comment. August 21, 2021 (4 months ago)

넵 감사합니다.