일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- active reconnaissance
- active recon
- Leviathan
- php login page
- FTZ
- tryhackme
- SQLi
- php To Do List
- privilege escalation
- php 파일 업로드하기
- sql injection
- access control
- THM
- Server Side Request Forgery
- OS Command Injection
- overthewire
- ssrf
- over the wire
- php file upload
- php 로그인 페이지 만들기
- Cookie
- Reconnaissance
- Recon
- Cryptography
- file upload
- Authentication
- php
- War Game
- 파일 업로드 취약점
- BANDiT
- Today
- Total
R's Hacking Daily Log
Authentication - Other.Lab (2) 본문
other authentication mechanisms 취약점과 관련해 살펴본 첫 번째 lab에서는
:) stay-logged-in cookie가 사용자의 계정명과 비밀번호를 기반으로 생성
:) 유효한 계정 carlos가 있다는 걸 알고 있는 상황
:) 후보 비밀번호 list까지 갖고 있는 공격자!
공격자가 자신의 계정을 갖고 있는 상황이었기 때문에 쉽게 cookie를 얻을 수 있었고
cookie를 분석해서 stay-logged-in cookie가
1) 비밀번호를 MD5 hash
2) hash 처리한 비밀번호 앞에 " 계정명 : "
3) 2번 과정으로 만들어진 문자열 전체를 Base64 encode
와 같은 과정으로 만들어지는 걸 파악했다.
공격자는 이미 존재하는 carlos라는 계정의 cookie 값이 정확히 무엇인지는 모르지만
비밀번호 list를 갖고 있기 때문에 각각의 비밀번호를 이용한 cookie를 만들어서 다 때려 넣어보면 그만이었다.
두 번째로 살펴볼 Lab은 상황이 조금 다르다.
Lab에서 목표로 하는 바가 무엇이며 어떤 과정으로 해결할 수 있을 지 먼저 파악해 보자.
Lab - offline password cracking )
이번 lab의 최종 목표는 carlos 계정으로 로그인해서 해당 계정을 제거하는 것이다.
공격자는 carlos라는 유효한 계정이 있다는 것을 알고 있지만 비밀번호는 모르는 상태.
이전 lab에서는 비밀번호 list를 가지고 cookie를 만들어서 유효한 cookie 값을 찾아낸 방식이라면
이번에는 cookie를 구해서 cookie로부터 비밀번호를 추출해내야 하는 상황이다.
여기서 말하는 cookie는 이전 lab에서 동일한 과정으로 만들어지기 때문에
cookie를 분석하는 부분은 생략하도록 한다.
lab에서 login을 할 때 stay logged in button을 눌러주면
stay-logged-in cookie가 만들어진다는 걸을 상기시키고 넘어가자.
(이 값을 가지고 cookie가 어떻게 만들어졌는 지 분석하는 과정을 거친다.)
lab을 둘러보면 post를 작성할 수 있는 사이트로 post를 하나 골라서 들어가 보면
comment를 달 수 있는 데, 이 부분을 활용해서 stored xss 공격을 할 것이다.
일단 xss 공격을 할 수 있는 지 확인하기 위해서 간단한 popup 창을 띄워보자.
script tag를 이용해서 alert()로 " 1 "을 출력하는 스크립트를 작성해서 댓글을 남기면
성공적으로 댓글이 남겨진 걸 볼 수 있고, Back to blog 버튼을 누르면
팝업 창이 뜨는 걸 볼 수 있다.
팝업 창이 뜬다는 건 xss 취약점이 존재한다는 의미로 해석하면 된다.
공격자(wiener) 계정으로 로그인해서 exploit server 버튼을 누르면 url이라는 부분에 공격자의 server id 정보가 출력된다.
이 부분을 이용해서
comment에 스크립트를 심어둘 것이다.
이 comment를 남긴 post를 보기 위해서 다른 사용자들이 post를 클릭하는 순간
공격자의 서버로 방문한 사용자의 cookie 정보가 기록되게 하는 스크립트이다.
기록을 확인하기 위해 access log 버튼을 누르면
위에서 보이는 바와 같이 내용이 나오는 데 IP만 봐도 확연히 다른 log 하나가 눈에 들어온다.
Get method로 /secret=~~ 한 내용이 있고 그 뒤에 이어서 보면
stay-logged-in cookie 정보가 기록되어 있는 걸 볼 수 있다!!
base64 decoding을 해보니 carlos의 정보라는 걸 알 수 있고 그렇다면..!
뒤에 이어지는 문자열이 carlos의 비밀번호라는 것도 짐작할 수 있다.
john tool로 password crack을 해보니 "onceuponatime"이라는 값이 나왔다.
알아낸 carlos 계정으로 로그인을 한 다음에 하단에 보이는
Delete account 버튼을 누르면
비밀번호를 입력해서 삭제하고자 하는 여부를 한 번 더 확인한다.
비밀번호 입력해 주고 delete account 버튼을 눌러주면
성공적으로 lab을 해결한 걸 볼 수 있다!!
!! stored Xss는 공격자가 서버 어딘가에 script를 심어놓고 사용자가 어떤 action을 취했을 때 자신도 모르게
script가 실행되어 사용자 browser에서 정보를 탈취하게 되는 유형의 Xss이다.
위의 Lab에서는 comment를 이용하여 공격자가 script를 심어둔 것이고 comment를 남긴 post를 보기 위해 다른 사용자가 post를 클릭하는 것이 사용자가 취한 action이 된다.
script 내용을 보면 document.cookie라는 내용이 적혀져 있는 데 개발자 도구를 켜서 console에 입력해 보면 자신의 cookie가 출력되는 걸 확인할 수 있을 것이다.
살펴본 lab에서는 cookie가 사용자의 계정 정보로 만들어졌기 때문에
이렇게 Xss와 같은 공격으로 cookie가 탈취당하게 되면 계정이 해킹된 것과 같은 개념이기 때문에
"cookie를 어떻게 만드느냐"가 중요하게 고려해볼 부분이라는 것을 짚고 넘어가자!!
'Port Swigger > Authentication' 카테고리의 다른 글
Authentication - Other.Lab (4) (0) | 2023.05.31 |
---|---|
Authentication - Other.Lab (3) (0) | 2023.05.28 |
Authentication - Other.Lab (1) (0) | 2023.05.23 |
Authentication - 2FA.Lab(2) (0) | 2023.05.21 |
Authentication - 2FA.Lab(1) (0) | 2023.05.21 |