[KISA Academy] 2024년 버그헌팅 실습훈련 - 스타트업 연계과정 7차(판교)

Posted Oct 9, 2024 Updated Oct 18, 2024

By 호롱고양이 68 min read

시작

일단 수업 내용이나 그 외 이야기들은 이번 주 수업이 끝난 뒤에 기록하겠다

Findthegap 버그바운티 실습 준비(수요일)

타겟 : ZUICY - 쥬시 AI

해당 프로그램의 이미지, 문자, 수치 등 모든 정보를 타인에게 유출하는 행위가 엄격히 금지되며, 유출 시 법적 책임을 질 수 있습니다.이고 또한 처음에 버그바운티를 하기 전 계약서에서 과정을 블로그에 올리는 것도 금지되어있다고 하였기에 나만 소장하기로 하였다

우리 팀은 결국 팀명대로 onlyone 딱 하나의 취약점을 제출 할 수 있었다

버그 바운팅을 위해 Finthergap에서 말하는 주의사항과 openvpn을 통한 vpn 설정 및 burpsuit 설정 파일을 다운받아 설정했다

문제 발생 1

어… web 해킹일거라고 생각했는데 앱 해킹이다

뭐 일단은 수업 때 세팅 방법을 배웠으니까 그대로 따라해 보자

문제 발생 2

수업 때는 분명히 LDplayer9를 깔아서 했는데 내 환경(노트북, 데스크탑)에 깔아보니 모두 바이러스가 감지된다

그럼 실습실에 있는 컴퓨터들은 전부 방어가 풀려있는건가? 어쩐지 팀 컴퓨터 5대 중에 1대가 자꾸 메모리가 부족하다더니.. 바이러스인지 내일 가서 한번 확인해 봐야겠다

일단 혹시 몰라서 LDplayer5 버전을 설치하니 성공했다만 magisk를 세팅할 수가 없었다

결국에는 다시 처음으로…

문제 발생 3

이건 에뮬레이터 문제는 아니고 일단 내가 사용하는 삼성 갤럭시 3 노트북은 VT를 활성화 할 수 없었다

하지만 노트북으로는 UBUNTU환경 듀얼부팅으로 설치되어있기에 waydroid를 이용해 설정해 보고자 한다. 될지는 매우 미지수지만…

또한 외장하드가 자꾸 컴퓨터를 옮겨다닐 때 마다 내용물이 없어지는 현상이 있어 window 오류 검사를 해보니 역시 문제가 있었다. 이런!

오늘 한번 시도해 보려고 했는데 19시 49분인 지금까지 세팅도 불가능 했다. 역시 세팅이 반인가….

문제 발생 4

밥 먹기 전에 혹시 몰라서 바이러스 검사 돌려놨는데… 아니 뭔 일인데 이거

진짜 너무 속상하다… 나한테 왜이러는데.. 아니 심지어 최근에 깔거나 다운받은 것은 그놈의 LDplayer 밖에 없다

왜냐면 마지막으로 검사한 저번주 일요일 이후에는 집에서 5시 30분에 일어나서 7시 20분에 출발해서 9시 50분에 도착하고 수업 끝나면 6시에 집 도착하면 밖에서 밥을 먹고 오기에 3시간 걸려서 10시에 도착하기에… 컴터를 킬 일이 없었다

근데 이번에 잠깐 켜서 돌리니까 이러네 아놔

문제 발생 5

어… waydroid가 설치되다가 갑자기 멈췄다. 좀 더 두고본 뒤에도 계속 이러면 껏다가 다시 켜야할 듯 하다.

문제 해결 5

일단 waydroid는 설치가 되었는데 오류로 인해 창이 멈춘 것이였다 그냥 끄면 됨

그런데 문제가 waydroid는 wayland를 위해 만들어졌지 x11(내 환경)을 위해 만들어진 것이 아니기에 어떻게 해결할까 찾던중 다음 유튜브 영상을 발견하였다

Waydroid With ARM Support On X11: A Proper Guide (2023)!

그는 신이야!

시작할 때에는 waydroid show-full-ui 끝날 때에는 waydriod session stop

기억하기 어려울 거 같아서 그냥 스크립트로 만들었다

  
#!/bin/bash

if [ "$(whoami)" != "root" ]; then
    echo "sudo 권한이 아닙니다. 스크립트를 종료합니다."
    exit 1
fi

echo "Waydroid 커맨드 모음"
echo -e "1. waydroid 시작\n2. waydroid 종료\n3. waydroid firewall allow\n4. waydroid firewall disallow\n"
echo -n "입력 : "
read INPUT

if [ "$INPUT" == "1" ]; then
    echo "Waydroid 시작 명령어 - 왜인지 스크립트 상으로 실행이불가능해서 따로 올림

export WAYLAND_DISPLAY=mysocket
weston --socket=$WAYLAND_DISPLAY --backend=x11-backend.so --width=486 --height=1000 &
waydroid show-full-ui &
    "
    export WAYLAND_DISPLAY=mysocket
    weston --socket=$WAYLAND_DISPLAY --backend=x11-backend.so --width=486 --height=1000 &
    #waydroid show-full-ui &
elif [ "$INPUT" == "2" ]; then
    waydroid session stop
elif [ "$INPUT" == "3" ]; then
    echo "방화벽을 여는 중입니다. 잠시만 기다려 주세요"
    sudo ufw default allow FORWARD
    sudo ufw allow 53
    sudo ufw allow 67
elif [ "$INPUT" == "4" ]; then
    echo "방화벽을 닫는 중입니다. 잠시만 기다려 주세요"
    sudo ufw default deny FORWARD
    sudo ufw deny 53
    sudo ufw deny 67
else
    echo "잘못된 입력입니다"
fi

그런데 일단은 시작 부분에 문제가 있어서 좀 더 봐야할 코드다

일단 안드로이드 설치하고 magisk까지 설치하는데에는 성공했다!

문제 해결 6 - 10/10

weston에서 waydroid를 통해 android11을 설치했었는데 분명 magisk의 Zygisk가 무슨 짓을 하던 안되었었는데

놀랍게도 APP update를 하고 나서 magisk를 다시 설치했더니 installed부분이 없어져서 다시 파이썬 스크립트로 설치했더니

Zygisk가 살아났다?? 재실행을 그렇게 해도 안되더니 아놔 너무 기분이 좋다!!!!!!!!!!!

문제 발생 7 - 마이크로소프트 계정 해킹

어이가 없네 9월 10일날 부터 오늘까지 계속 시도하고 있네 뭐하는 놈들인지…

문제 발생 8 - Zygisk 우회 실패

음.. 결국 Zygisk가 설치 되었다고 떴지만 실제로는 실행되지 않았다. 다르게 말하면 module에서는 로딩조차 되지 않았다. 파일을 로딩하는데 문제가 있는걸까?

고로 누군가 waydroid에서 zygisk를 실행할 수 있게 만들어주기 전까지는 윈도우 환경에서 LDplayer를 써야겠다

또한 나중에 친구를 통해 확인해보니 내가 깔았던 LDplayer9설치 폴더에는 분명 바이러스가 있었지만 내 친구가 보내준 설치파일에는 바이러스가 감지되지 않았다… 이게 무슨?

버그헌팅 실습훈련이 끝난 후 기록하는 수업 내용들

2일 전 버그헌팅 실습 훈련이 끝이 났고 이제 그동안 들었던 수업 내용을 정리해보자

핸드폰 녹화 25개, 44.3GB

노트북 녹화 21개, 19.7GB

다시 들으면서 복습이다

1일차 2024-10-07

팀 빌딩, 버그 헌팅 알아보기, 몸 풀기

첫 날은 각자 자기 소개 및 강사님 소개, 그리고 팀을 만들었다

강사님이 노말틱님이 강사님으로 있을 줄은 생각도 못했다. 일단 Kisa Academy에 나온 모든 강의를 신청하고 있었는데 이런 기회가!

이번 수업은 버그바운티 실습으로 실제 Findthegap에서 실제 서비스를 대상으로 버그바운티를 한는 것이다

수업을 시작하고 나서는 간단한 카드를 하나 받았는데 본인이 받은 카드에 적힌 문구를 이해하고 옆 사람과 이야기를 나눠보는 것이였다

위 사진은 우리 팀이 가져온 카드들 이였고 나는 그 중 /normal.php?c=bHM=이라는 카드를 가져가게 되었다

솔직히 난 웹 해킹에 관해서는 공부해 본 적이 전무했기에 바로 인터넷을 찾아봤는데 아무리 봐도 저 bHM=이 무엇인지 감이 잡히지 않았다

가만히 다른 사람들이 강사님을 불러서 본인이 생각한 정답을 이야기 하고 있을 때 어째 뭔가 어디서 본 듯한 문구라는 생각이 들었다

그래서 바~로 base64 디코딩을 돌려보니 ls 명령어였던 것이다!

해석해보자면 /normal.php라는 php파일에 c라는 변수가 있는데 이 변수를 통해 웹서버에서 명령어를 실행시킬 수 있는 것 같다

그리고 뒤에 base64로 복호화된 bHM=은 ls명령어니 웹 서버에서 ls명령어로 파일 리스트를 불러오게되는 공격이다

강사님께 내가 생각한 정답에 대해 확인해보니 맞았다!! 하지만 지금도 이게 무슨 공격인지는 모른다. 아마도 chatgpt에 의하면 명령어 주입(Command Injection) 혹은 원격 코드 실행(RCE, Remote Code Execution)이라고 한다

팀 빌딩

팀은 앉아있는 순서대로 만들어졌고 총 3팀이 만들어졌다

그리고 이제 팀 별로 방에 들어가서 팀원들이 가지고 있는 카드를 이용하여 공격 시나리오를 짜게 되었다. 아 물론 그 전에 먼저 서로에 대한 소개를 했다

보아하니 온 사람 중 내가 막내였다. 다른 분들은 대부분 현업자였다. 올해 초에 했던 부트캠프 때에도 그렇고 확실히 휴학을 하면서 꽤나 알차게 시간을 쓰고 있다는 생각이 들었다. 매우 만족!

우리 팀은 OnlyOne 말 그대로 딱 하나만이라도 찾아내자! 라는 목표를 가지고 있다. 스포아닌 스포를 하자면 정말로 하나를 찾아냈다

그리고 막내인 만큼 내가 발표 경험도 적고 하다보니 팀의 리더가 되었다. 이건 정말 생각도 못했지만 그래도 처음에는 아예 모르는 내용이여서 발표할 때 거의 내용을 외워서 했었다면 4회차가 되어서는 수요일이 휴일이라 그 때 찾아보기도 하고 그동안 같이 버그헌팅을 하면서 어느정도 어떻게 진행되는지 알게 되니 확실히 처음보다 훨씬 자신감이 생기고 발표 내용을 외우지 않더라도 사실상 숙지한 상태로 이야기 할 수 있었다. 내가 리더라니!

시나리오 생성

일단 우리가 가지고 있는 카드들을 한번 다시 살펴보자

<!–#exec cmd=”ls” –>

Server-Side Include(SSI) 인젝션공격이다. 서버가 HTML파일을 처리할 때 특정 명령어를 실행할 수 있도록 하는 기능인데 여기서 외부 입력(ls)을 통해 파일 목록을 출력할 수 있다

물론 ls명령어 말고 다른 모든 명령어 실행이 가능하다. 아래 나올 취약점 모두 그러하다

?message=<%25+system(“cat+/etc/passwd”)+%25>

PHP 코드 인젝션 또는 Server-Side Template Injection(SSTI)로 웹 서버에서 리눅스 시스템의 비밀번호가 담긴 /etc/passwd파일을 출력할 수 있다. 이를 통해 시스템 권한 탈취 또는 정보 유출로 이어질 수 있다

exractvalue(‘1’,concat(0x3a,(select’test’)))

SQL 인젝션으로 사용될 수 있는 쿼리 구문이다

extractvalue()함수를 사용하여 MySQL에서 XML데이터에서 값을 추출한다

그 안에 있는 concat(0x3a, (select'test'))구문에서는 concat()함수가 0x3a즉 :과 test를 합쳐서 :test라는 값을 반환하게 된다

하지만 이 때 1은 XML 데이터로 주어졌고, :test는 XPath 경로로 사용되었다. 하지만 이 구문은 유효하지 않은 XPath 경로이기 때문에, MySQL은 오류를 발생시키게 되고 오류 메세지를 통해 원하는 값을 추출할 수 있게 된다

{“$or”: [{},{“foo”:”1”}]}

MongoDB에 쿼리를 조작하여 아무 조건 없는 쿼리를 추가하거나, foo값을 주입하려는 시도이다

공격자가 비정상적인 값을 넣어 인증 우회, 데이터 유출 등의 공격을 시도할 수 있다

\/normal.php?c=bHM=

내가 받은 카드로 위에서 설명하였다

get.php?addr=http://[::]:80/

Server-Side Request Forgery(SSRF)공격으로 공격자가 IPv6(::)주소로 외부 또는 내부 네트워크로 요청을 보내도록 하는 기법이다

이 글을 쓰면서 영상 녹화된 것들을 계속 보고 있는데 정말 처음엔 너무 떨었나보다 ㅋㅋㅋ 내가 지금 들어도 긴장되는 목소리라니

우리의 시나리오는 다음과 같다

공격자가 get.php?addr=http://[::]:80/을 통해 서버에 웹쉘을 업로드 한다
ls명령어를 실행시켜 웹쉘의 위치를 탐색한다
웹쉘을 실행시켜 DB를 공격한다

사실 이미 서버에서 명령어를 실행시킬 수 있는 상황부터 다른 과정은 의미가 있을까 싶기는 하다

그리고 또한 우리가 1번공격에 대해 완전히 잘못 이해하고 있어서 위 시나리오는 잘못된 것이라고 강사님이 말씀해 주셨다

이런! 위에 내가 써놓은 코드에 관한 설명은 맞다. 시나리오가 틀린 것

강사님께서 말씀하시길 SSRF공격은 HTTP요청을 하게 하여 그 결과를 저장하는 것이라고 하셨다. 우리가 생각한 웹쉘을 서버에 업로드 하는 것은 불가능!

또한 시나리오를 만들 때에는 예를 들어 우리가 공격할 대상은 ~~은행입니다. 그래서 ~~기능을 이용할 겁니다 이런 식으로 시나리오를 만들면 더 좋다고 하셨다

다른 팀원들 발표 자료와 내용은 가지고 있지만 고것은 허락을 받지 않았기에 블로그에는 쓰지 않겠다

확실한건 다른 팀들도 진짜 잘 만들었다. 정말 저렇게만 하면 실제로 가능하겠는데? 싶을 정도였다

버그 헌팅에 관해 (수업 시작 전)

수업을 시작하기 전에 다른 팀에서 커맨드 인젝션(cat)을 통해 파일을 읽을 수 있는데 왜 http 다운로드를 또 해야하는가?라는 질문이 있었는데 분명 .txt파일과 같은 읽을 수 있는 파일이라면 가능하지만 바이너리파일이라면 cat명령어를 써도 깨져서 보이기에 http다운로드를 통해 직접 받아서 보는 방법이 따로 있는 것이라고 하셨다

또한 만약에 http다운로드 취약점이 없다면 바이너리 파일은 열람할 수 없는 것인가?라는 질문에는 만약 그럴 경우에는 base64인코딩을 통한 방법으로 파일을 텍스트 형태로 받은 후 복호화 한 뒤 리버싱 작업을 통해 볼 수 있다고 하셨다. 아니 이런 방법이?

버그 헌팅에 관해

Bug(취약점)을 찾고 Bounty(포상금)을 받는 프로그램

버그바운팅은 왜 하는가?

아예 취약점을 못 찾게 하면 해킹도 없지 않을까? 라고 생각할 수도 있지만 우리가 찾지 않는다고 해킹이 없을까? 전혀 아니다 오히려 그런 취약점들을 미리 찾아서 제거하는 것이 오히려 더 공격에 예방된다

우리는 안전하게 만들기 위해! 버그헌팅을 하는 것이다

버그를 찾으면 포상금을 주는가?

버그 : 개발자, 프로그래머가 생각하지 못했던 상황이 터지는 것

취약점 : 그 버그 중 악용할 여지가 있는 것

버그(bug)헌팅은 사실상 취약점(vulnerability)헌팅이지만 발음이 어려워서 그냥 버그헌팅 이라고 부른다고…

우리는 버그를 찾는 것이 아니라 취약점을 찾는 것이다! 만약 우리가 취약점을 찾고 보고를 하려면 이 것이 어떻게 악용될 수 있을지 시나리오도 알려주는 것이 좋다

버그 헌팅의 조건

취약점을 찾아서 해킹을 하면 돈을 준다? -> X

서로 합의(규칙)가 된 상황에서만 취약점을 찾아야지 버그헌팅이다. 만약 그 밖으로 나가게 되면 그건 이제 해킹으로 변질된 것이다

서비스의 가용성 - 실제 작동중인 서비스임으로 장애가 생기면 안된다

버그헌팅 플랫폼

Google이나 faceook에서 처음으로 버그헌팅이 생겨났지만 대기업이 아닌 중소기업은 버그헌팅을 하는데 드는 비용을 전부 감당하기 힘들기에 그것을 위한 플랫폼인 Find The Gap(한국), Hackerone(외국),bugcrowd(외국)을 통해 버그헌팅을 시작할 수 있게 되었다

하지만 아직 한국은 버그 바운팅이 그렇게 활발하지는 않다

버그 헌팅 / 모의해킹

버그헌팅 : Crowd sourced Security Testing 불특정 다수가 참가할 수 있다

장점

공격에 활용될 수 있는 취약점들만 골라서 받을 수 있다. 또한 받는 입장에서 판단할 수 있다 - 위험할 수록 페이 UP

단점

정보를 공개해야 한다. 나쁜 해커도 참여할 수 있다

모의해킹 : 선정된 인원만 참가할 수 있다

장점

정해진 인원이 참가하기에 악용될 여지가 적다. 버그헌팅에 비해 매우 안전하다

단점

인력의 수준에 따라 결과의 수준 차이가 크다
정해진 기간 안에 취약점을 찾는다. 고로 못찾는 취약점이 존재할 수 있다
정해진 취약점 항목에서만 취약점을 찾게 되기에 새로운 문제는 찾기 힘들 수도 있다

우리나라에서는 버그헌팅 또한 모의해킹처럼 시작할 때 서약을 쓰고 들어가거나 특정 인원만 받아서 한다

버그헌팅 윤리

조심해야할 케이스

다른 일반인들이 취약점을 찾고 있다는 것을 모르게 해라

취약점 기능을 찾던 중 메세지를 보내는 기능을 찾았는데 이 기능을 이용해서 일반 사용자에게 연락이 가게 된다면 문제가 생긴다!

게시판이 있다고 여기에 우리가 배운 알람을 띄우는 페이로드를 넣게 되었을 때 실제 운영하는 사이트를 사용하는 사용자에게 뜨게 된다면 문제가 생긴다!

취약점을 찾을 때에는 알고 사용해라!

서비스에 장애가 생기지 않게 해라

rm -rf /… 이건 말 안해도…

또한 DB를 건드릴 수 있을 때 테스트 데이터를 만들어서 하거나 본인 것이 아닌 일반 사용자들의 데이터를 지우거나 덮어씌우지 마라

고로 가능하면 본인이 만든 자동화 툴이 아니라면 어떤 작업을 하게 될지 모르니 쓰지 않는 것이 좋다

남의 정보 Dump 금지

당연하겠지만 만약에 비인가 취약점을 발견하게 되어 개인정보를 보거나 다운받을 수 있게 된다면 본인 혹은 팀원의 정보를 Dump해서 보고서를 작성하여라

혹여나 본인 계정을 만들 수 없는 상황이라면 랜덤한 사람의 정보를 이용해라, 당연하지만 절대로 보고서 외에 다른 이에게는 보내선 안된다. 아무리 친한 사람이나 가족이여도 금물!

타겟 도메인 잘 확인하기

우리가 취약점을 찾는 도메인이 아닌 다른 도메인을 공격하면 절대 안된다! 정말로 타겟인지 아닌지 꼭 확인하면서 찾을 것! 가능하면 Burpsuite에서 scope기능을 사용하는 것이 좋다

몸풀기

강사님이 만든 테스트 사이트에서 취약점을 찾는 것!

ctf.segfaulthub.com:9191사이트에서 버그헌팅을 하는 것이였다

나는 첫날까지만 해도 아무것도 아는 것이 없었기에 리더가 되었지만서도 깎두기로서 팀원이 찾은 취약점을 보고서로 만들어서 제출하는 역할을 맡았다

아쉽게도 우리는 파일 다운로드 취약점을 찾아냈지만 이미 다른 팀에서 제출한 거였다! 이런!

끝난 뒤 다같이 모여서 그동안 찾은 취약점들을 공유하고 강사님께서 우리가 찾지 못한 취약점을 알려주셨다

이렇게 버그헌팅 실습훈련의 첫날이 끝났다!!

2일차 2024-10-08

we can do it (몇가지 사례)

취약점은 어디에나 있지만 우리가 찾지 못했던 것이다

Shopify

로그아웃 후에 세션이 만료되지 않아서 이런 쿠키를 재사용 할 수 있었던 취약점

한국에서는 이런 사례로 버그바운티를 받기는 어려울지도..?

버그바운티 보고서를 제출할 때에는 이러한 취약점을 통해 공격자가 어떻게 문제를 일으킬 수 있는지에 관해 적어서 제출하면 좋다

deriv

메일로 서브 도메인을 탈취 가능함, 서브도메인 테이크오버

사용되고 있지 않은 subdomain 탈취, 피싱 메일 공격 등에 활용할 수 있다

사이트에 들어가게 되면 그 사이트에 수많은 이미지, gif, 자바스크립트 등의 리소스를 받아오기 위해 여러 도메인을 거치는데 만약 사이트를 만들었을 때 사용한 도메인을 더이상 쓰지 않아 팔게 되었을 때 서버 코드 상에서 지우지 않았다면 공격자가 그 도메인을 사서 본인 서버를 구축해 악성 코드가 담긴 리소스를 넘겨주게 된다면, 사이트를 열 때마다 악성코드가 실행된다

3회차에 더 자세히!

SideFX

XSS 취약점 - 요거는 찾으려고 하면 어떻게든 찾을 수 있는 경우가 많기 때문에 보통 버그헌팅에서는 받아주지 않곤 한다

만 보고서를 한번 찔러볼 필요는 있다. 특히나 이것을 이용해서 정말로 공격을 할 수 있다는 것을 보여준다면 버그바운티를 받을 수 있다

보통 XSS를 찾게 되면 alert를 띄우고 말지만 이 케이스에서는 정말로 XSS를 통해 사용자의 페이지를 통해서 세션 ID를 탈취하는데 성공해서 버그바운티를 받게 되었다

팀별 사례 조사

요거는 따로 내 하드에 저장

정보수집

그냥 아는 모든 기술을 사용하는 것이 아니라 효과적으로 취약점을 찾기 위해 정보 수집을 한다

서브 도메인 테이크오버, robots.txt와 같이 정보를 찾아보기만 함으로써도 취약점을 찾을 수도 있다

서브 도메인 테이크오버는 소스들의 주소에 들어갔을 때 404가 아니라 페이지 없음이 뜬다면 도메인을 사서 바로 공격할 수도 있는 취약점이다

robots.txt에서는 그럴 일을 거의 없겠다만 만약 관리자 페이지가 써있고 그 페이지에서 로그인 우회 취약점을 찾게 된다면 매우 큰 버그바운티를 받을 수도 있다

어떻게 해야하는가?

타겟 스코프(표면) 수집

도메인을 확보하는 것

자동화 툴 :

SubDomainizer
- 페이지에서 나오는 링크들을 분석, javascript를 분석해서 나오는 하드코딩 된 페스워트, 크레덴셜 등을 알려준다
subscraper
- 브루트포스를 통해 그냥 전체 다 스캔한다
Amass
- 원래는 포트스캔 툴로 주로 쓰지만 도메인 검색에도 쓰인다

하지만 우리나라에서는 자동화 툴 쓰지 말자… 불편해 한다고… 외국에서는 오케이!

구글 이용 :

구글 검색 연산자를 사용하는 방법
- 예시) site:dyson.com
- site:도메인 -삭제도메인 -삭제도메인2

강사님께서 원리만 안다면 만들 수 있을것이라고 하셔서 한번 쉬는 시간동안 만들어봤다

일단은 그냥 간단히 만든거라 도메인 제외는 없다

FDWGSD.py

  
#Find Domain With Google Search Engine

print('''
███████╗██████╗ ██╗    ██╗ ██████╗ ███████╗██████╗ 
██╔════╝██╔══██╗██║    ██║██╔════╝ ██╔════╝██╔══██╗
█████╗  ██║  ██║██║ █╗ ██║██║  ███╗███████╗██║  ██║
██╔══╝  ██║  ██║██║███╗██║██║   ██║╚════██║██║  ██║
██║     ██████╔╝╚███╔███╔╝╚██████╔╝███████║██████╔╝
╚═╝     ╚═════╝  ╚══╝╚══╝  ╚═════╝ ╚══════╝╚═════╝ 
''')

print("ᓚᘏᗢ\n")

import requests
from bs4 import BeautifulSoup
from urllib.parse import quote



# 검색할 쿼리 (예: 'Python 구글 검색')
query = 'site:google'
query_encoded = quote(query)  # 쿼리를 URL에 맞게 인코딩

# 구글 검색 URL
url = f"https://www.google.com/search?q={query_encoded}"

# HTTP 요청 헤더 설정 (봇으로 인식되지 않도록 일반 브라우저처럼 보이게 설정)
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36"
}

# HTTP GET 요청 보내기
response = requests.get(url, headers=headers)

# 요청이 성공했는지 확인
if response.status_code == 200:
    # BeautifulSoup으로 HTML 파싱
    soup = BeautifulSoup(response.text, 'html.parser')

    # 검색 결과를 추출 (예: 검색 결과 제목과 링크)
    for i, result in enumerate(soup.select('div.yuRUbf a'), start=1):
        #title = result.get_text()
        link = result['href']
        print(f"{link}\n")
        #print(f"{i}. {title}\n   {link}\n") 
else:
    print(f"Error: {response.status_code}")

앱에서 도메인을 찾을 때에는?

apkleaks
- 앱 안에 있는 앱서버의 주소를 찾아내는 것

그런데 요거는 한국 앱에서는 하도 코드가 스파게티라서 잘 안된다고 한다

환경 정보 수집

Port, 서비스 확보하기

포트스캔
- 시스템의 서비스를 이해하기 위해서 진행
- mysql, apache, OS 정보 등
- 버전 정보 -> CVE 검색을 통해 활용

Tool

플랫폼 환경 정보

CMS
- Content Management System
- 카페24, 워드프레스, 그누보드
DB
Framework
Library

플랫폼 환경정보 수집 툴

wappalyzer 크롬 확장 툴을 통해 어느정도 환경정보를 알아낼 수 있다. 100% 신뢰할 수는 없지만 그래도 꽤나 쓸모있는 툴이다

플랫폼 환경 정보 활용

CVE 검색
Library 경로 정보 활용 - 게시판 데모 취약점 등
Open source / COTS 분석 활용

서비스 정보 수집

서비스 사전 조사

직접 방문해보기
- 서비스, 기능 확인 및 리스팅

취약점 찾기에 바로 돌입하기 보다 직접 사용해보며 전체적인 그림을 그려보기

공격자 입장에서 생각하기

서비스 리소스 조사 : open source일 때

소스 코드 내 경로 확인
- 사용하고 있는 라이브러리 정보를 알게 된다면 직접 설치하거나 github 업데이트 정보를 보고 취약점을 찾을 수 있다

서비스 리소스 조사 : 유료 상용 프로그램 (COTS)

DEMO를 설정해 보기
- 예를 들어 free trial 같은거

서비스 리소스 조사 : 회사 자체 계발 프로그램

tool (있을법한 파일을 전부 떄려넣는 방식)
- getallurls (gau)
- feroxbuster
wordlists.assetnote.io에 있는 리스트를 커스텀해서 리소스를 조사할 수 있다
Burp Suite의 Content Discovery 기능 - 하지만 유료기능

Wayback Machine

과거에 있던 페이지들을 스냅샷 해서 저장해 놓은 사이트

옛날과 지금을 비교해서 만약 401 Error(권한 없음)이 발견된다면 옛날에는 과연 어땠을까? 하고 wayback machine을 통해 확인하여 취약점을 찾을 단서가 될 수도 있다

waymore 라는 자동화 툴도 있다

리소스 조사를 할 때 중점적으로 봐야하는 파일들

DB 설정 파일
- 만약 노출되어있다면 바로 다운받기, 그 안에는 비밀번호 등의 중요 정보가 있다
Admin Page
Useless Page
- 사용하지 않는 페이지(테스트 페이지 등)

파라미터를 알아내는 툴

리소스를 알아냈을 때 그 리소스에서는 어떤 파라미터를 사용하는지 알아내기 위한 툴이다

한국에서는 X

정리해두어야 하는 정보

서버에 데이터를 어떻게 보내고 요청하는지

RESTful
Param

사용자 권한 무엇을 못하고 무엇을 할 수 있는지

관리자
일반 사용자

환경 정보

서비스 플랫폼 환경
서버 종류
사용하는 라이브러리
프레임워크

환경 세팅

Ldplayer 설치
magisk delta 설치
불필요한 su 파일 삭제
Zygisk를 통한 우회
루팅 우회 성공
Burpsuite와 에뮬레이터에 인증서 설치

간단하게 하자면 위와 같다

하지만 문제발생에도 적었듯 그 과정에서 좀 많은 문제를 마주할 수 있다

아니 근데 다시 생각해봐도 왜 내가 설치한 LDplayer는 바이러스가 있었는지 이해가 안되네

3일차 2024-10-09

원래는 금융감독원에 버그바운팅을 하려고 했으나 처음하는 우리에게는 어려울 것이라고 생각해 ZUICY로 변경하였다

First Blood

가장 먼저 취약점을 찾은 사람

취약점을 찾을 때 모든걸 때려보면서 취약점을 찾는 것이 아니라 우리는 시나리오를 생각하면서 취약점을 찾아보는 것이 좋다. 어쩌피 떄려넣는건 자동화 툴이 더 잘하니까

타겟

이 때는 타겟의 설명과 어떤 도메인들을 건드릴 수 있는지, 어떻게 접속하고 Burpsuit를 설정하는 방법 등을 이야기 했다

자세한건 버그바운팅 서약에 따라 금물!

웹 캐시 취약점 (Web Cache Vuln)

cache : 임시 데이터

예를 들어 넷플릭스(미국서버)를 볼 때 영화 데이터가 미국에서 한국으로 날아오는데 그 선은 해저 케이블을 통해 길게 되어있어 데이터 이동하는데 시간이 많이 걸려 영화를 고화질로 보는데 문제가 있다

그래서 넷플릭스는 우리나라에 cache 서버를 여러군데 설치해놨다

이 cache 서버는 사람들이 자주 열람하는 컨텐츠들을 저장해 놓는 임시 서버이다

요청이 오면 빠르게 응답하기 위해 서버와 클라리언트 사이에 응답의 사본을 저장하고 이를 전달하는 것

요즘은 사이트를 만들면 나도 모르게 서버 앞에 cache 서버가 적용되어있는 경우가 많다

캐싱되는 장소들

cache 서버
프론트 서버
웹서버 내부
브라우저

어떻게 똑같은 요청이라는 것을 알까? Web Cache Work

요청 url? 요청 헤더 분석? 정적 페이지만?

Cache Keys

캐시 키는 캐시 프로그램, 서버마다 다르게 구성하여 이것을 통해 같은 요청인지 구분하게 된다

예를들어

Cache key:https | GET | naver.com | /intro.html

Cache Keys 로 설정되어있지 않은 것

Cache unkeyed: User-Agent, Cookie

WEB Cache Poisoning

나쁜 응답이 캐시되게 만들고, 이용자들이 이 캐시를 가져가게 만드는 공격

이름 그대로 캐시 오염 공격

unkeyed 데이터 찾기
Bad Cache Store
Response 확인

Cache key는 이미 사용되고 있는 캐시이기에 unkeyed데이터에 스크립트를 삽입하여 이루어진다

Response에서 x-Cache : miss, Hit 이 나온다면 cache 서버를 사용하고 있다는 것을 알 수 있다

unkeyed 데이터 중 응답에 영향을 주는 데이터를 찾아본다 -> Reflected XSS

Param Miner를 이용해서 요청 헤더에서 자주 사용하는 데이터들을 때려넣어서 정말로 사용중인 파라미터를 찾게 되면 cache poisoning을 할 수 있다

unkeyed 데이터를 찾았다면 값에 script를 삽입해 볼 수 있다

주의

Cache Poisoning 테스트를 할 때는 자기의 Cache key로 테스트해야한다, 그냥 일반 페이지에 악성 스크립트를 캐시하면 안된다

GET 요청을 보낼 떼 /?test=1과 같이 자기의 캐시키로 테스트해야한다

보통은 이 방법은 보고서를 안 받아주지만 공격을 증명할 수 있다면 오케이

WEB Cache Deception (WCD)

WEB Cache Poisoning : 공격자가 악의적인 스크립트를 캐시 서버에 저장하고 이용자가 가져가는 방식
WEB Cache Deception : 이용자들의 개인정보가 Cache 되게 만들고 공격자가 가져가는 방식

일반적으로는 정적 페이지가 캐시되지 개인정보 수정 페이지와 같은 동적 페이지는 캐시가 되지 않는다

그렇기에 WEB Cache Deception을 수행하려면 Rewrite라는 기능이 서버에 켜져있어야한다

Rewrite

확장자가 없이 요청되는 페이지가 이 기능을 사용한 것이다

서버에서 요청이 들어온 URL을 매핑해서 응답해준다

예시

/main/index/exploit.css 라는 파일을 검색한다고 했을 때

rewrite ^(/main/.*)/$/$1.php last;와 같이 규칙이 생성되어있다면 php파일이 아니기에 404 not found가 뜨는 것이 정상인데

rewrite ^(/main/.*)/.*$/$1.php last;와 같이 규칙이 생성되어있다면 /main/index.php를 응답하는 경우가 있다

이렇게 되면 마이페이지에 있는 데이터도 css 즉 정적 페이지에 있는 데이터라고 속여서 cache 서버가 캐시를 하게 만들 수 있다

공격자가 /main/mypage/exploit.css를 피해자한테 전달
피해자가 링크를 클릭 했을 때 /main/mypage.php를 서버에 요청하게 되고 캐시에 /main/mypage/exploit.css로 캐시됨
공격자가 /main/mypage/exploit.css에 접근 후 피해자의 정보를 탈취

chatgpt 계정 탈취

SOP

Same-origin Policy

자바 스크립트로 로드된 다른 출처의 리소스에 접근할 수 없다. (img,video,script src 제외)

예를 들어 사이트를 만들고 a.html파일을 만들었다고 했을 때 <src img>테그를 쓸 수 있는데 여기서 다른 페이지의 이미지를 가져오는 것은 가능하지만 자바스크립트로 로드된 페이지에 자바 스크립트로 접근할 수 없다는 의미이다

만약에 해커가 hack.com이라는 서버를 만들어서 hack.com/phishing.php라는 페이지를 만들고 그 안에 <script>테그가 들어있다고 했을 때 이 <script>테그에는 예를 들어 naver.com 페이지에 있는 민감한 정보를 가지고 와서 공격자 사이트로 데이터를 보내는 악성 스크립트를 만들고 피해자한테 이 페이지를 보내면 피해자의 컴퓨터에서 naver.com에 있는 민감한 정보들이 공격자의 서버로 전송된다

이제 이 문제를 브라우저에서 막기로 했다

다른 출처에서 온 데이터를 불러오게 되면 (예시에서는 naver.com) 공격자 페이지의

  
function reqListener(){
  location='https://naver.com/log?key='+this.responseText;
};

위 코드에서 this.responseText;부분을 실행할 때 오류가 발생한다

SOP의 기준? 같은 출처의 기준?

domain
scheme - 프로토콜 (http, https)
port

위 3가지가 같으면 같은 출처

예시

http://test.com:80/main/test.html

위 페이지에서 로드된 리소스에 접근할 수 있는 페이지는?

http://tesT.com:80/main/admin.html
http://test.com:8080/main/super.html
https://test.com:80/main/sectret.html
http://naver.com/main/mypage.html

정답은 4이다

하지만 브라우저 개발자들이 SOP를 만들고 나서 개발자들이 다른 출처에 있는 스크립트를 가져다 쓰지 못하게 되자 CORS라는 규칙을 만들게 된다

CORS

Cross-Origin Resource Sharing

서로 다른 도메인에서의 리소스 허가

ACAO 헤더를 추가하기로 했다

this.response 할 때

지금 응답하는 이 정보들을 접근해서 사용해도 되는 도메인들을 Acess-Control-Allow-Origin 헤더에 넣어서 응답한다

웹 브라우저

웹 브라우저에서는 ACAO 헤더를 참고해서 지금 페이지의 도메인이 이 리소스에 접근해도 되는지 판단하고 컨트롤한다

취약점 발생 1

ACAO 헤더를 쓸 때 참조하는 사이트가 늘어날 수록 계속 추가해줘야해서 귀찮아서 ACAO 헤더에 와일드카드를 넣어버리게 된다

Access-Control-Allow-Origin:*

SOP가 없을 때와 같은 상황이 되었다

하지만 이렇게 하면 쿠키를 제외한 모든 것을 보내주게 되는데 쿠키가 없다면 타 도메인의 마이페이지에서 중요 정보를 가져오지 못하는 문제가 생긴다

그래서 이번에는 ACAC (Access-Control-Credentials) 헤더의 값을 true로 응답해서 쿠키값을 가지고 올 수 있게 되었다

Access-Control-Allow-Origin: [Origin Header Vlue]
Access-Control-Credentials: true

만 대신에 이렇게 하면 다시 와일드카드는 쓸 수 없게 된다

결국 다시 하나씩 등록해야하는것

이것을 또 우회하기 위해 요청 헤더의 Origin값을 자동으로 ACAO 헤더값에 넣도록 만들어버렸다. 사실상 *와 같은 것

결국 또 이렇게 되면 SOP가 없을 때와 같은 상황이…

그리고 다시 한번 처음에 문제가 되었던 취약점이 되살아났기에 ACAO 헤더에서 동적으로 Origin을 가져다쓰지 않게 되었다고…

취약점 발생 2

개발하는 입장에서는 아직 도메인이 없을 때 만약에 Origin 헤더가 null이면 그냥 허용해 줄 수 있도록 브라우저에서 설정되어있는데 여기서 또 문제가 발생했다

원래는 burpsuite로 직접 찍어보지 않는 한 Origin 헤더를 변경할 수 없지만 iframe 에서의 요청은 피해자 컴퓨터에서 Origin 헤더를 null로 세팅할 수 있었다

iframe을 이용하면 또 우회가 되었던것..

취약점 발생 3

이제는 화이트리스트 기반의 필터링을 하기로 했다

test.com 도메인의 하위에 있는건 전부 CORS 정책을 허용하도록 설정했지만 또 문제가 생겼다

공격자가 badtest.com을 등록하고 공격하게 되면 뒤에 부분이 test.com으로 같기에 공격에 성공하기도 하였다

CORS 잘못된 설정으로 민감 정보 유출 가능성

CORS 취약점이 없다면?

같은 도메인, 허용하는 도메인에서 XSS 취약점을 찾으면 된다

강의 이후

이후에는 계속해서 타겟(Zuicy)에서의 취약점을 찾고 발표하는 시간을 가졌다

우리팀은 아직 하나도 찾지 못했다!

그런데 정말 신기한게 XSS나 CORS와 같은 특별한 기술과 관련된 취약점 보다는 파라미터 변조와 같은 되게 쉽게 도전할 수 있는, 처음 내가 볼 때는 모르겠지만 남이 한번 딱 시범을 보여주면 “아니 나도 저기 보고있었는데?” 싶은 그런 간단한 부분에서 큰 취약점들이 나왔다

와 어케찾았담

3일차 끝!

4일차 2024-10-10

마지막 날이자 팀명이 제 값을 한 날

취약점을 보고할 때에는 취약점을 찾게 된 경로를 상세하게 적어서 제출하는게 좋다

아무리 읽는 사람이 개발자라고 해도 설명은 필요하니까

그리고 또 너무 자세하게 (진짜 무슨 웹사이트를 킨다, 로그인 버튼을 누른다 정도의 자세함)는 쓸 필요 없음

물론 취약점과 관련된 거라면 필요하지만

취약점 인지 아닌지 판별하는 것은 간단하다, 본인이 생각했을 때 공격자(해커)가 악용할 수 있을 것 같다! 하면 그게 취약점이다

IDOR

Insecure Direct Object Reference

즉 부적절한 인가 취약점 혹은 비인가 취약점

우리가 못하는 것을 할 수 있다면 IDOR이다

예를 들어 우리가 다른 사람 개인정보를 볼 수 있다던가 다른 사람의 게시물을 삭제 및 수정이 가능한다면 그것이 바로 IDOR이다

이것을 찾기 위해서는 가장 처음 우리가 서비스에서 무엇을 할 수 있는지 무엇을 할 수 없는지 서비스 로직을 파악해 놓는 것이 필요하다

인가 취약점을 찾을 때는 서버측에서 데이터가 영향이 가는지 클라이언트쪽에서의 응답값 변조로 인해 생긴 취약점인지를 잘 파악해서 보고서를 작성해야 한다

인가 취약점은 주로 파라미터 변조 또는 URL 직접 접근을 통해 일어난다

URL직접 접근 사례

로그인을 누르면 OTP번호를 입력하는 페이지가 있는데 서버에서는 일단 로그인과 비밀번호를 받으면 세션을 만들어놓게 되는 상황이 있었다

이 상황에서 URL을 변조하여 dashboard로 이동했더니 OTP 우회에 성공하게 되었던 사례를 설명해 주셨다

Hackerone 사례

Attachment disclosure via summary report

summary 레포트를 통해 다른 사람의 첨부 파일을 볼 수 있다

파라미터를 변조해서 다른 사람의 첨부파일을 볼 수 있었고 바운티가 15000달러였다

세상에 20555550원이라니

이유라고 한다면 누구나 쉽게 변조하여 취약점을 이용할 수 있기에 바운티가 높았다고 한다

Delete anyone’s content spotlight remotely.

다른 사람의 글을 삭제하는 취약점

본인 포스트에서 삭제 버튼을 누르고 다른 사람의 포스트 ID로 바꾸면 다른 사람의 포스트가 삭제되는 취약점

이것도 15000$

참고로 한국보다는 외국이 버그바운티는 훨씬 크다

Subdomain Taker

subdomain : 하위 도메인

예를 들어 naver.com이 있을 때 mail.naver.com이 바로 subdomain이다

유형 1 (연결된 링크에 도메인 없음)

우리가 웹 페이지를 하나 만들었다고 해보자

그 웹 페이지에는 다음과 같은 자바스크립트 하나를 로드하는 코드가 있다

  
<script src="https://aaa.com/test.js"></script>

그런데 나중에 aaa.com 도메인을 삭제했지만 웹 페이지에 있는 위 코드 지우는 것을 까먹었다면?

해커가 aaa.com이라는 도메인을 구매해서 test.js라는 이름의 악성 코드를 올릴 수도 있다

이런 일은 보통 회사에서는 팀 단위로 작업을 하기 때문에 내가 작성한 코드가 아니면 혹은 다른 사람한테서 인수인계 받은 코드라면 모르고 있을 확률이 높기 때문에 생기는 취약점이라고 한다

Hackerone 사례

Broken Link Takeover from kubernetes.io docs

kubernetes라는 사이트에서 링크를 클릭했을 때 없는 도메인이 발견되어 바로 공격에 사용이 가능했던 취약점

유형 2 (CNAME)

CNAME : 일종의 별칭

예를 들어 강사님의 웹사이트인 academy.segfaulthub.com이라는 도메인으로 들어가게 되면 segfaultacademy.teachable.com으로 이동된다

보통은 이런건 직접 연결하는 것이 아니라 플랫폼에서 팔고 있다 한다

쉽게 말해 우리가 네이버에 계정을 만들면 카페를 만들 수가 있는데 이런 식으로 플랫폼(naver)에서 만들수 있다

강사님은 teachable이라는 사이트에서 도메인을 받아왔고 원래 링크는 segfaultacademy.teachable.com이지만 이름을 바꾸고 싶어서 CNAME을 걸어서 academy.segfaulthub.com으로 연결되게 해놓으셨다

tistory에도 같은 기능이 있어 만약에 이름을 바꾸고 싶다면 도메인을 사서 CNAME을 정해줄 수 있다

하지만 이제 segfaultacademy.teachable.com을 그만 운영하려고 teachable에서 탈퇴했는데 CNAME이 등록된 것을 까먹고 그냥 방치하게 되면?

공격자가 teachable에 가입해서 segfaultacademy.teachable.com으로 도메인을 등록하게 되면 사용자들이 academy.segfaulthub.com으로 들어오면 공격자의 사이트로 이동하게 된다

security-flashcards에서 되게 귀엽게 그림으로 과정을 표현해 놓았다, 하지만 유료라는 사실

Hackerone 사례

Subdomain Takeover of brand.zen.ly

도메인 탈취

자동화 툴

그냥 사이트의 모든 링크를 클릭해 보고 unreachable이 뜬다면 도메인을 사서 바로 취약점을 제보할 수도 있다

그를 위한 툴이 바로 subjack이다

This repository has been archived by the owner on Jan 7, 2024. It is now read-only.

더 이상 관리를 안하기는 한다, 애초에 관리할 이유도 없긴 하지?

IMG_7744 부터

팀에서 찾은 것 (OnlyOne)

IDOR 즉 비인가 취약점을 발견했다

사실 내가 팀장이라고는 하나 버그바운티 (웹, 앱 해킹)은 배워본 적이 전무했던지라 4일차까지 와서야 그동안 6시간 왕복하면서 찾아본 정보들로 간신히 따라갈 수 있었기에 이 취약점을 찾는데에는 거의 도움이 되지 못했다

다음번에 또 기회가 되서 실습훈련을 하게 된다면 그 때에는 조금 더 잘 할 수 있을지도?

팀원분들 감사합니다! 즐거운 4일이였다지요

보고서 관련 이야기

취약점의 위치 : 어디를 고처야 하는지

공격을 재현하여 보고서 제출

또한 해커가 할 수 있는 공격 시나리오를 보여주면 좋다

캡쳐를 뜰 때에는 폰트 크게

마무리

이렇게 총 5일(수요일은 휴일) 동안의 실습 훈련이 끝났다

솔직히 왕복 6시간 때문에 아침 5시에 일어나서 준비하고 집에 오면 10시여서 꽤나 힘들기는 했지만 배우는 내용들이 너무 재밌어서 다음에 또 할 수 있겠냐고 한다면 무조건 한다

버그바운티라고 그냥 이름만 들어봤었는데 이번 기회에 제대로 배워보니 너무 즐거웠다

팀원의 조장이 되어서 아예 아는 내용이 없었음에도 발표도 해보고 직접 취약점도 보고서로 제출해보고 솔직히 이정도로 많이 배운적이 있나 싶다

끝!

추후 일정

어우 최근에 갑자기 삘받아서 KISA Academy에 있는 과정 중에 흥미로워 보이는 것들을 전부 신청했더니 시간표가 뭔가 많아졌다. 공부할 것이 이제 5개다

뭔가 서순이 잘못된 것 같지만 이것을 기록하는 오늘부터 버그헌팅 실습훈련 초급과정이 시작된다

이론을 배우고 실습을 했어야했는데! 살짝 아쉽달까?

그래도 다음번(아마도 공익근무중일 때이겠지만)에 또 기회가 된다면 이번에는 조금 더 잘 할 수 있을 것같다

잘못된 정보가 있다면 언제든 알려주세요~

ᓚᘏᗢ

KISA, 보안

Bug Bounty

This post is licensed under CC BY 4.0 by the author.

시작

Findthegap 버그바운티 실습 준비(수요일)

문제 발생 1

문제 발생 2

문제 발생 3

문제 발생 4

문제 발생 5

문제 해결 5

문제 해결 6 - 10/10

문제 발생 7 - 마이크로소프트 계정 해킹

문제 발생 8 - Zygisk 우회 실패

버그헌팅 실습훈련이 끝난 후 기록하는 수업 내용들

1일차 2024-10-07

팀 빌딩

시나리오 생성

버그 헌팅에 관해 (수업 시작 전)

버그 헌팅에 관해

버그바운팅은 왜 하는가?

버그를 찾으면 포상금을 주는가?

버그 헌팅의 조건

버그헌팅 플랫폼

버그 헌팅 / 모의해킹

버그헌팅 윤리

몸풀기

2일차 2024-10-08

we can do it (몇가지 사례)

팀별 사례 조사

정보수집

타겟 스코프(표면) 수집

환경 정보 수집

서비스 정보 수집

정리해두어야 하는 정보

환경 세팅

3일차 2024-10-09

First Blood

타겟

웹 캐시 취약점 (Web Cache Vuln)

어떻게 똑같은 요청이라는 것을 알까? Web Cache Work

WEB Cache Poisoning

WEB Cache Deception (WCD)

SOP

CORS

취약점 발생 1

취약점 발생 2

취약점 발생 3

CORS 취약점이 없다면?

강의 이후

4일차 2024-10-10

IDOR

Subdomain Taker

팀에서 찾은 것 (OnlyOne)

보고서 관련 이야기

마무리

추후 일정

Trending Tags