Rootme.org - CRLF

문제

• 로그인 페이지가 나온다.
• 로그인 로그가 출력되있다.
• admin이 로그인 했었다.

풀이

• resources에 HTTP sumuggling이 나와있어서 관련 문제인줄 알았지만
  • 아무리 고민해도 써먹을 상황이 아니었다.
  • 관리자가 지속적으로 로그인 request를 요청하는 상황이라면
  • 해당 request를 조작해서 response를 내 쪽에 보내는? 그런 말도안되는 망상을 해봤지만..
  • 관리자는 이후로 로그인 시도를 하지 않았다..
• 로그 인젝션이었다
  • 한참 고민하다가 로그 관련되서 취약점을 검색해보니 로그인젝션이 나왔다.
  • 찜찜했지만 로그인젝션으로 admin authenticationed를 남겨주니 성공

알게된 것

• HTTP Smuggling
  • 프론트 서버(프록시) ---- 백엔드 서버로 구성되어있을 경우에 적용 가능한 취약점
  • HTTP 헤더에서 request의 끝을 구분해주는 필드가 ContentLength와 Transfer encoding 이렇게 두가지가 존재하는데
  • request에 이 두개가 동시에 삽입되어있고, 프론트 백엔드 서버가 CL로 해석할지 TE로 해석할지 방식이 다르게 적용되있을때
  • 이를 이용해 이후 다른 피해자의 request를 조작할 수 있게되는 취약점이다.
  • 예를 들어 CL - TE 라고 하면
    • content length=20
      transfer encoding=chunked
      1\r\n
      test\r\n
      0\r\n
      smuggle //여기까지 body 전체 크기가 20이라고 칠때

       - front에서는 content length= 20 이므로 "smuggle"까지 전체를 백엔드에 전달한다.
        - 하지만 백엔드는 te=chunked 방식이므로 0\r\n으로 끝을 판단하게 되고
        - smuggle은 백엔드 캐시에 남게된다.
        - 이것은 이후에 들어오는 요청의 맨앞에 붙게된다.
        -따라서 다른 피해자가 request를 했다면
        - `smuggleGET /index.php HTTP/1.1` 이렇게 헤더가 조작된다.