일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- access control
- BANDiT
- php file upload
- tryhackme
- php To Do List
- ssrf
- Recon
- Reconnaissance
- War Game
- php 파일 업로드하기
- 파일 업로드 취약점
- active reconnaissance
- OS Command Injection
- php 로그인 페이지 만들기
- Authentication
- Leviathan
- php login page
- Cookie
- privilege escalation
- FTZ
- THM
- Server Side Request Forgery
- php
- active recon
- Cryptography
- over the wire
- file upload
- SQLi
- sql injection
- overthewire
- Today
- Total
R's Hacking Daily Log
Authentication - Other.Lab (1) 본문
대부분의 웹 사이트에서는 기본적인 로그인 기능에 더불어 사용자가 비밀번호를 잊어버렸을 때
사용할 수 있는 비밀번호 찾기 or 비밀전호 재설정과 같은 추가 기능을 제공한다.
웹 사이트는 일반적으로 로그인 페이지와 관련되어 잘 알려진 취약성을 방지하기 위해 노력을 기울이다 보니
추가적인 기능들과 관련된 취약점에 대해서는 간과하는 경우가 있다.
결과적으로 부가 기능의 허점을 이용하여 공격이 이루어질 수도 있고,
공격자가 자신의 계정을 만들 수 있는 경우에는 더더욱 많은 정보를 제공하게 되는 셈이다.
** "자신의 계정을 얻는다"는 건 허가된 사용자에게만 제공되는 페이지, 콘텐츠들이 노출되는 것이기 때문에
추가적인 공격 측면이 제공될 수 있다.
무조건 위험하다라기 보다 위험 가능성을 제공하게 된다는 것이다.
Keeping users logged in
첫 번째로 살펴볼 추가 기능은 “로그인 상태 유지”와 관련된 내용이다.
사용자는 로그인 시, 로그인 상태 유지하기와 같은 이름의 체크박스를 클릭하는 아주 간단한 행위로
브라우저가 닫힌 후에도 로그인 상태가 유지되도록 옵션을 줄 수 있다.
이러한 기능은 persistent cookie에 저장되는 remember me token을 생성함으로써 구현되는데
이 쿠키를 사용하면 로그인 과정을 우회할 수 있게 된다.
무작정 쿠키값을 예측하는 건 좋은 방안일 수 없지만 일부 사이트에서는
사용자 이름에 타임스탬프를 연결하거나 사용자의 비밀번호를 이용해 쿠키를 만드는 경우가 존재한다.
이럴 경우, 공격자가 자신의 쿠키를 기반으로 쿠키가 어떻게 만들어졌는지 분석이 가능해진다면
이러한 정보를 토대로 다른 사용자 계정의 쿠키를 만들 수 있게 될지도 모른다.
만약 공격자가 자신의 계정을 만들 수 없다고 하더라도 취약점은 여전히 존재한다.
Xss와 같은 공격을 활용하면 다른 사용자의 stay log in 쿠키를 훔칠 수 있고 훔친 쿠키 정보를 기반으로
쿠키가 어떻게 만들어지는지 알아낼 수 있다.
드문 경우에는 쿠키로부터 사용자의 비밀번호를 얻을 수 있는데,
이때 비밀번호가 hash 되어있다고 하더라도 이미 공개적으로 나와있는 리스트와 비교했을 때,
사용자의 비밀번호가 그 리스트 안에 들어있을 수도 있다.
또한 salt를 사용하지 않으면 mb5와 같이 이미 뚫린 hash는 쉽게 복호화가 가능하기 때문에
사용자의 계정과 관련된 정보를 탈취하는 것이 가능해진다.
위에서 살펴본 내용을 토대로 간단한 Lab 하나를 풀어보도록 하자.
:) lab의 목표는 공격자가 자신의 계정을 가지고 있는 경우 쿠키 정보를 분석하여 carlos의 계정으로 로그인하는 것.
:) 후보 비밀번호 리스트가 제공되기 때문에 이를 이용해 Brute force를 실행할 계획이다.
공격자의 계정을 입력하고 stay-logged-in checkbox를 클릭하면
위와 같은 packet이 만들어진다.
주목해서 볼 부분은 오른쪽에 나오는 response인데,
session & stay-logged-in cookie가 만들어지는 걸 볼 수 있다.
:) session cookie는 로그인 정보로 사용자의 정보가 검증되면 만들어지는 cookie이고
stay-logged-in cookie는 stay logged in 체크박스를 선택해서 로그인 form을 보냈을 때 만들어지는 cookie이다.
:) 로그인 검증이 되더라도 stay logged in 체크 박스를 선택하지 않으면 stay-logged-in cookie는 만들어지지 않는다.
stay-logged-in cookie 값을 Base64 decode 해봤더니 로그인할 때
사용한 wiener이라는 사용자 이름이 눈에 들어온다.
wiener에 " : "이 붙어있는 걸 보아하니 아마도 뒤에 이어지는 문자열은 비밀번호를 hash 처리한 거 같은데
대충 보니 MD5 같다.
decode 한 문자열을 가져다가 johntheripper tool을 돌려봤더니
wiener의 비밀번호는 peter라고 로그인에 사용한 계정 정보가 그대로 나왔다.
즉 stay-logged-in cookie는
1) 사용자의 비밀번호를 MD5 hash (=이걸 hash_passwd라 하면)
2) 사용자 이름 + : + hash_passwd 형태의 문자열로 만들어서
3) 2번에서 만든 문자열을 Base64 Encoding
과정을 거쳐서 만들어진다는 걸 알아냈다.
Get /my-account request를 intruder로 가져와 stay-logged-in 값을 payload 설정해 준 다음
payload는 Lab에서 제공하는 password list를 넣어주고
각각의 password가 cookie로 변신할 수 있도록 위에서 알아낸 방법으로 processing rule을 설정해 준다.
총 3가지 processing을 추가해 주면 되는데,
password에 hash 하고 "carlos:"를 앞에 붙인 다음, 문자열 전체를 base64 encode 하는 순서로 설정해줘야 한다.
password list에 들어있는 password들이 쭉~ cookie로 만들어지면서 Brute force 공격을 실행하면
유일하게 length가 다른 request 하나를 발견할 수 있다.
찾아낸 유효한 쿠키로 stay-logged-in 값을 수정해서 보내면
Lab이 성공적으로 해결된 걸 볼 수 있다.
(더불어 계정 이름이 carlos로 변경되어 있다.)
'Port Swigger > Authentication' 카테고리의 다른 글
Authentication - Other.Lab (3) (0) | 2023.05.28 |
---|---|
Authentication - Other.Lab (2) (0) | 2023.05.27 |
Authentication - 2FA.Lab(2) (0) | 2023.05.21 |
Authentication - 2FA.Lab(1) (0) | 2023.05.21 |
Authentication - Lab(2) (0) | 2023.05.11 |