ls-toast

0. 서론

 이번에 제가 포스팅할 내용은 워게임이나 데모 사이트가 아닌 실제 상용 사이트에서 XSS, 그중에서 Stored-XSS를 찾는 방법을 소개하고자 합니다. 먼저 본격적인 내용에 앞서 몇가지 말씀드릴 사항이 있습니다.

1. 어떠한 목적이든 사전 허가 없이 취약점을 찾는 것은 불법입니다.
 악의적인 목적이야 당연히 불법입니다. 가끔 단순 호기심, 선의의 목적을 갖고 한다면 괜찮다고 생각하시는 분들이 있는데 불법입니다. 그러니 본 포스팅의 내용을 직접해보고 싶다면 자신이 직접 구축한 사이트나 버그 바운티를 운영 중이고 해당 버그 바운티 범위 내에 있는 사이트들을 이용하거나 사전 허가를 받고 진행하시기 바랍니다.

2. 저는 아직 초보자이며, 해당 포스팅 내용도 기초에 속한 내용입니다.
 저는 저 자신을 아직 입문자 혹은 초보자의 단계에 있다고 생각합니다. 때문에 본 포스팅의 내용도 굉장히 기초적인 방법입니다. 혹시 고급 정보를 생각하고 오셨다면 다른 글을 찾아보시는 걸 추천드립니다. 본 포스팅은 저와 같이 기초 스킬을 배우고 있으면서 버그 바운티를 갓 시작하신 분들을 위해서 작성했습니다.

3. 잘못된 내용에 대한 피드백은 언제나 환영합니다. :)
 앞서 말씀드렸듯이 저는 초보자이며, 내용도 기초적인 내용이다보니 틀린 내용이 담겨있을 수 있습니다. 이에 대한 피드백은 언제나 환영하니 꼭 알려주시면 감사하겠습니다!

1. 대상 선정

 먼저 XSS를 찾으려면 대상부터 선정해야 합니다. 대부분의 해킹 입문자분들이 '이름 있는 회사라면 취약점이 없겠지' 라고 오해하고 계시는데 그렇지 않습니다. 물론 상대적으로 규모가 작은 회사들이 좀 더 취약할 수 있겠습니다만, 사람이 코딩을 하는 이상 회사의 규모와 상관없이 취약점은 존재합니다. 사람은 실수를 하기 때문이죠. 예를 들면 특수문자 필터링을 깜빡한다던가, 개발할 때 써놨던 주석을 안 지웠다던가. 그래서 대상 선정에 굳이 규모 있는 회사들을 제외할 필요가 없습니다! 합법적인 절차를 거친다는 가정하에 어디든 상관없으니 마음 편하게 선정하시면 됩니다! 만약 그게 어렵다면 제가 몇 가지 추천드리겠습니다.

1. 그누보드(Gnuboard)
 그누보드는 오픈소스 CMS(Contents Management System)입니다. 때문에 소스가 모두 공개되어 있고 패치 내역들도 모두 공개되어 있습니다. 본인 서버에 그누보드를 구축하고 여기저기 이런저런 공격들을 시도해보기 딱 좋습니다. 취약점 찾기에 어려움을 느낀다면 소스코드를 직접 분석하면서 찾아봐도 되고 그것도 어렵다면 구버전을 설치하고 패치 내역들을 살펴보면서 이미 제보된 취약점을 직접 재현해보는 것도 좋습니다.

2. 네이버
 네이버는 공식적으로 버그 바운티 프로그램을 운영하고 있습니다. (https://bugbounty.naver.com/ko/) 자세한 내용은 해당 페이지에 들어가서 살펴보시면 됩니다. 워낙 이름 있다보니 취약점이 없을 거라 생각하기 쉽지만 제공하는 서비스가 많다 보니 잘 찾다 보면 툭툭 나오기도 합니다. 특히 새로운 기능이나 서비스 쪽에서는 꼭 1,2개 이상은 나오니까 한번 시도해보는 것도 나쁘지 않습니다.

3. 리디북스
 리디북스 역시 공식적으로 버그 바운티 프로그램을 운영하고 있습니다. (https://ridi.dev/bounty.html) 역시 자세한 내용은 해당 페이지에 들어가서 살펴보시면 됩니다. 버그 바운티 운영 초창기에는 꽤 많은 취약점이 나왔지만 화이트해커분들의 수 많은 관심(?) 덕분에 지금은 찾기가 꽤 어려워졌습니다. 한 가지 제가 느낀 점을 추가하자면 리디북스가 네이버보다 리워드 금액도 높고 첫 제보 시 RIDI PAPER PRO를 준다는 점이 아주 좋습니다! :)

4. 자신이 구축한 사이트
 이건 본 포스팅 주제(실제 상용 사이트에서 XSS 찾기)와 좀 맞지 않은 대상이긴 한데 공부하기엔 꽤 좋습니다. 본인이 직접 사이트를 구축하면서 기본적인 웹 지식을 쌓을 수 있고 그걸 직접 테스트 해보면서 기초적인 보안 기법을 적용해보고 그걸 또 우회해보고 더 좋은 보안 기법을 적용해보고 반복하는 겁니다. 만약 큰 도움이 되지 않는 다고 생각된다면 자신과 뜻이 맞는 친구들과 함께 서로가 구축한 사이트를 서로가 취약점을 찾아보는 것도 괜찮습니다.

2. 공격할 곳 찾기

 대상은 선정했으니 이제 본격적으로 공격할 곳을 찾아야합니다. 공격 시도할 곳을 간단하게 말씀드리면 '값을 넘길 수 있는 곳 어디든' 입니다. 예를 들어 게시판이라고 했을 때 사용자가 서버에 값을 넘길 수 있는 곳은 게시글 제목, 내용, 태그, 첨부파일, 첨부파일명, 닉네임 등이 있는데 이 부분이 전부 공격 시도할 곳이라고 보시면 됩니다. 이 외에도 개발자 도구를 띄워서 <input type="hidden"> 인 친구들도 value 값을 직접 수정해서 넘기는 방법도 있습니다.

3. XSS 찾는 방법

 이제 대상과 공격할 곳은 다 정했으니 공격 시도만 하면 됩니다. XSS 기초를 공부하고 오신 분들이라면 사용자 입력값으로 <script> alert(1) </script> 같은걸 넣고 시도해보실 텐데 틀린 건 아닙니다. 실제로 저 구문이 먹히는 곳도 꽤 있습니다. 다만 워낙 기초적인 공격법이다 보니 안 먹히는 경우가 꽤 많습니다. 물론 제가 소개해드릴 방법도 기초적인 방법이지만.. <script> alert(1) </script>에 비하면 쪼오오끔 더 효율적인 방법입니다. 일단 필요한 게 2가지가 있습니다.

1. 개발자 도구(F12) 콘솔 탭

2. " ' < > [ ] ; : , . / ? ! @ # $ % ^ & * ( ) _ + | \ ` ~ { } (이 외의 특문을 추가해도 괜찮습니다.)

 이제 공격할 사이트로 이동 한 뒤 개발자 도구 콘솔 탭을 열고 2번에 있는 특수문자들을 복사해서 사용자 입력 값 부분(제목, 내용, 댓글 등)에 붙여 넣기 한 뒤 서버에 전송해봅니다.

 전송 후 위의 사진처럼 콘솔에 아무것도 안찍히는 경우라면 특수문자에 대한 필터링이 존재한다는 뜻이고 이럴 경우 제가 설명드리는 기초적인 방법으로는 XSS가 불가능하다고 보시면 됩니다. 그럼 만약에 특수문자에 대한 필터링이 존재하지 않을 경우엔 어떻게 될까요?

 위와 같은 화면을 보실 수 있을겁니다. 위 사진은 제가 실제로 제보한 XSS 취약점 내용입니다. 보시면 SyntaxError와 함께 우측에 회색으로 링크가 걸리는데 해당 링크를 타고 넘어가 보면 아래와 같은 사진이 나옵니다.

 위 처럼 링크를 클릭하면 SyntaxError가 발생한 부분을 보여줍니다. 보시면 제가 입력한 특문이 그대로 들어갔고 맨 앞에 있는 더블 쿼터(")로 인해 title="" 이 되면서 뒷부분이 전부 SyntaxError가 난 것을 볼 수 있습니다. 그렇다면 사용자 입력값을 "; 임의의 코드 로 고친다면 사용자가 입력한 임의의 코드가 실행됩니다. 이걸 악용한다면 공격자는 해당 페이지를 조회한 모든 사용자의 세션 값을 탈취하거나 특정 사이트로 리다이렉트 시키는 등 다양한 공격을 시도할 수 있습니다. 아니면 이번 신천지 사이트 해킹 사건처럼 아래와 같이 alert를 발생시킬 수 도 있겠죠. :)

 글을 다 쓰고 보니 XSS에 대한 내용도 안쓰고 포스팅을 했네요. XSS에 대한 내용은 다음 포스팅 때 다루기로 하겠습니다. 너무 기초적인 방법이라서 실망하신 분들도 많았을 것 같은데.. 의외로 이 방법만 갖고도 취약점이 제법 나오는 편입니다! 저처럼 버그 바운티를 갓 입문하신 분들은 이 방법을 한번 써보시면서 좀 더 고급 스킬들을 익히신다면 아마 나름 쏠쏠한 용돈벌이가 가능하지 않을까 싶습니다 ㅋㅋ 다들 버그 바운티로 쏠쏠한 용돈 벌이에 도전해보세요 :)

 매번 '앞으로 열심히 포스팅하겠습니다!'라고 글을 마무리해놓고 포스팅 1도 하지 않은 의지박약한 토스트가 글또와 함께 돌아왔습니다.. 이번엔 진짜로 어쩔 수 없이 열심히 포스팅하겠습니다.

글또?

 글또란 '글 쓰는 또라이'라는 글쓰기 모임으로 개발자분들이 꾸준하게 글을 쓰고자 만든 모임입니다. 진행 방식은 학술 스터디와 비슷합니다.

1. 인원을 모집한다
2. OT를 진행한다
3. Deposit을 걷는다
4. 일정 기간 내로 포스팅을 하고 다른 사람들의 글에 대한 리뷰 및 피드백을 진행한다
5. 4번을 안 하면 일정 금액을 Deposit에서 깎는다
6. 활동 기간이 끝나면 남은 Deposit을 돌려준다.

 학술 스터디와 다른 점은 Deposit이 살짝 세다는 점과 '학술 활동'대신 '글쓰기'라는 점입니다. 사실 제가 이 모임에 들어온 이유가 Deposit을 이용해 강제성을 부여한다는 점이었는데 이전에 제 포스팅을 보면 아시겠지만 강제성이 없으니 바쁘다는 핑계로 글을 잘 안 쓰는 그런 안 좋은 모습을 보여드렸는데.. 글또를 통해서 개선해 나가고자 합니다 ㅎㅎ

 물론 단순히 강제성을 부여한다는 점 때문에 시작한 건 아닙니다. 강제성이야 어떤 방법을 쓰던 굳이 글또같은 모임이 아니더라도 해결할 수 있습니다. 친구에게 부탁해서 2주 1포스팅 확인만 해달라 하고 만약 그 약속을 못 지키면 친구한테 벌금을 지불하는 형식으로 해결할 수 있고 만약 수동 체크가 귀찮으면 스크립트(...)를 짜서 확인하는 방법도 있습니다. 하지만 타인의 피드백, 그것도 여러 사람들에게 피드백을 받을 수 있다는 것은 매우 흔치 않은 기회라고 생각합니다. 피드백을 받으면 아무래도 제 글이 더 깔끔해지고 전달력도 올라가겠죠! 이제 컨설턴트가 된 만큼 제가 알고 있는 지식을 남에게 잘 전달하는 능력이 필수라고 생각하는 저에게 글또라는 모임이 아주 딱 맞는 것 같아 시작하게 됐습니다.

포스팅 주제

 포스팅 주제는 지금과 크게 다르지 않을겁니다. 다만 지금까지는 기술 관련 포스팅만 했다면 이제는 서브로 행사 후기, 프로젝트 경험, 대외활동, 후배 양성기(?) 등과 같은 경험담도 한번 써볼까 합니다.

계획 및 다짐

1. 최소한 글또 Deposit은 돌려받자!

 네 저는 돈이 좋습니다. 돈이 최고야! 내 Deposit! 내 돈! 꼬박꼬박 포스팅하고 피드백해서 원금 손실은 막을 거야!

2. 많이 쓰지는 못해도 많이 읽기라도 하자!

 이번에 회사에서 첫 프로젝트를 경험해봤는데 개인 시간이 매우 부족하다는 걸 느꼈습니다. 그래서 솔직히 다른 분들처럼 1주 1포스팅이나 1주 2포스팅 같은 건 자신 없습니다. 글쓰기 실력은 글을 많이 써봐야 늘어난다던데 그럴 수 없으니 잘 써진 글이라도 많이 봐야겠습니다. 실제로 글또에 올라온 글들을 보면 저보다 훨씬 글을 잘 쓰시는 분들이 넘쳐나서 ㅎㅎ 

3. 피드백은 적극적으로 반영하자!

 글 쓰기  실력이 부족한 만큼 웬만한 피드백은 모두 반영할 예정입니다. 물론 한 번에 바꾸기 어려운 내용도 있겠지만 노력해보겠습니다.

4. 바쁘다고 대충 쓰지 말자!

 1번이 중요하긴 하지만(...) 그렇다고 Deposit 지키겠다고 퀄리티 낮은 글을 쓸 생각은 없습니다. 돈이 중요하긴 하지만 저는 글쓰기 실력을 향상하는 게 더 중요합니다. 그래서.. 이걸로 좀 고민되는 부분이 생기긴 했습니다.

고민

 사실 포스팅할 내용은 많습니다. 일단 문제 풀이 글만 해도 2,30개는 쌓여있고 프로젝트 정리 글도 제목만 써놓고 내용은 빈칸인 상태고.. 밀린 포스팅이나 머릿속에 구상 중인 포스팅은 넘쳐있어서 포스팅 주제에 대한 걱정은 없는데 문제는 퀄리티입니다. 일단 문제 풀이(Write-up) 글이 메인인데 지금 퀄리티로는 글또에 제출하기 좀 무리가 있다고 생각합니다. 그래서 이걸 문제 풀이 포스팅의 작성 방식을 바꿔야 할지.. 아니면 글또용 글과 개인 블로그 글을 나눠서 포스팅할지 고민입니다. 다음 2주 동안 한번 고민을 해봐야겠네요.

오랜만의 포스팅입니다!

원래부터 좀 바쁘긴 했지만 최근 들어 더더욱 바빠졌기 때문에 짧은 포스팅도 할 시간이 없었습니다.

그래서 이참에 제가 왜 바빴는지, 앞으로 계획은 어떻게 되는지 간단하게 설명드리는 글을 포스팅하려고 합니다 ㅋㅋ

1. 취업

 일단 제가 더더욱 바빠진 가장 큰 이유입니다. 작년 하반기 내내 취업 준비를 하다가 안타깝게도 공채시즌때 지원했던 회사들은 모두 광탈하고 다음 시즌 취업 준비를 하던 중 고맙게도 지인의 추천으로 지원하게된 회사에 최종 합격을 하게되어 1월 부터 회사를 다니기 시작했습니다. 대기업은 아니지만 보안 업계에선 이름있는 회사 중 한곳에 다니고 있습니다. 제가 예전부터 다니고 싶던 회사였던지라 저에겐 아주 좋은 일이지요. 그런데 회사가 한참 바쁠때 들어간지라.. 퇴근후엔 씻고 바로 기절하고 그러느라 바빴습니다 흑흑.. 다행히 이제 바쁜게 끝나서 여유가 좀 생긴 편입니다.

2. 여행

 위에서 적었지만 공채 시즌에 넣었던 서류가 다 떨어져서 다음 시즌을 준비하기 전에 여행을 다녀와야겠다 싶어서 12월 중순즈음 6박 7일간 무계획 즉흥 제주도 여행을 다녀왔습니다. 제 인생을 통틀어서 가장 힘들었던 일을 여름에 겪은 뒤로 꼭 가야겠다 다짐했는데 바빠서 미루고 미루다가 갔다왔습니다. 첫날 비행기, 첫날 숙소, 렌트카를 제외하면 전부다 즉흥으로 움직였습니다. 그러다가 새로운 사람들도 만나고 그 중에 몇몇 사람들은 지금까지 연락하고 지낼정도로 소중한 인연이 되었습니다! 여러모로 아주 좋은 여행이었죠 ㅋㅋ

3. 후배 양성(?)

 제가 항상 바쁘게 사는 이유중 하나입니다. 이름은 거창한데 그냥 전역 후 부터 지금까지 쭉 보안에 관심있는 학교 후배들에게 공부 방향이나 진로 상담, 질문 같은거 받아주면서 가이드가 되는 역할을 맡고 있습니다. 제 실력이 누굴 가르칠만한 실력은 아니지만 갓 입문한 친구들에겐 나름 큰 도움이 되는듯하여 지금까지 쭉 해오고 있습니다. 제가 보안 공부를 시작할때 보안 공부 하시는 대부분의 선배님들이 군대나 졸업 등의 문제로 없던 상황이라 보안 공부에서 삽질을 좀 했었는데 적어도 제 후배들한테는 그런 삽질을 경험시키고 싶지 않았고 최대한 효율적인 방법으로 단기간에 실력을 키울 수 있도록 환경을 제공해주고 싶었습니다. 그래서 지금까지 이러고 있습니다. 후배들 입장에서는 졸업한 고학번 선배가 부담스럽겠지만..ㅋㅋㅋㅋ

4. 서버 관리

 저는 게임을 굉장히 좋아합니다. 아마 제가 갖고 있는 정품 게임을 다 합치면 200개? 300개?쯤 될정도로 좋아하는데 2년전부터 모 게임에 푹빠지게되었고 해당 게임의 국내 최대 규모의 커뮤니티에서 서버 관리자로 있는 상태입니다. 단순 서버 관리부터 업데이트, 오류 수정까지 하는 일인데 최근들어 좀 문제가 많이 발생해서 바빴습니다. 물론 위의 3가지 항목으로 인해 저를 제외한 다른 관리자들이 더 열일을 했지만요.

5. 스터디

 취업 준비 일환으로 알고리즘 스터디를 진행중이었는데 이걸 2개 돌리고 있습니다. 취업 후에는 바빠서 불참한적이 더 많지만.. 그 전까지는 매주 여러가지 알고리즘 문제를 풀고 스터디 진행하고 그랬었습니다. 하하 아마 회사일 바쁜게 끝나서 다음주부터는 다시 정상적으로 스터디를 진행하지 않을까 싶습니다. 취업했는데 왜 굳이 하냐고 생각하실 수 있지만 향후 이직하게 된다면 필요할거라 생각해서 유지할 생각입니다. 일종의 플랜B를 대비하는 거라고 보시면 될것 같습니다.

 여기까지가 제 근황이었습니다. 앞으로의 계획은 아직 세우고 있긴합니다만 지금까지 결정된건 운동과 보안 공부, 버그 바운티 정도..? 사실 아직까지 회사에 완벽하게 적응한건 아니라서 잘 모르겠습니다 ㅋㅋ 일단 제 큰 목표는 올해는 회사다니면서 기초를 다지고 내년부터는 본격적으로 대회 본선 진출이나 입상을 목표로 뛰지 않을까 싶습니다 ㅎㅎ 아, 그리고 블로그 관리도 다시 시작할 예정입니다. 여전히 바쁘겠지만 어떻게든 시간을 쪼개고 쪼개서라도 포스팅하려고 노력해보겠습니다.

늦었지만 다들 새해 복 많이 받으시고 좋은일만 있으시길 바라겠습니다! :)

 문제를 클릭하면 위와 같이 id를 입력하는 부분이 있고 제출 버튼이 있습니다. 일단 기본값인 admin을 그대로 냅두고 제출 버튼을 누르면 you are not admin이라는 문구가 출력됩니다. 일단 다시 메인 페이지로 돌아와서 admin대신 a만 입력해보고 제출을 누르면

 위와 같이 hello a가 출력되고 로그아웃 버튼이 생깁니다. 이 상태에서 쿠키값을 확인해보면 아래와 같습니다.

 BASE64로 보이는 값이 userid에 들어가 있고 해당 값을 디코딩해보면 md5 값이 나옵니다. 그 값을 복호화 해보면 'a' 라는 값이 나옵니다.
결국 userid에 있는 base64는 입력된 문자를 md5로 변환하고 해당 값을 다시 base64로 인코딩 해준것이죠. 일단 대충 알았으니 입력 값을 바꿔서 테스트 해봅니다.

 입력값을 aa로 변경해서 확인해보면 앞부분이 이전 'a'만 입력했을 때와 동일하다는 것을 확인할 수 있습니다. base64를 디코딩 해보면 아까 확인했던 'a'의 md5 값이 연속해서 2번 찍혀있는 것을 확인할 수 있습니다. 그럼 결국 userid는 입력된 문자열의 각 문자마다 md5값을 구해서 그걸 이어 붙인 뒤 해당 값 전체를 base64로 인코딩 한것이라는 것을 알 수 있습니다. 저희는 admin으로 로그인(?)해야하니 admin의 각 문자들을 md5 값으로 변환해주고 해당 값들을 모두 붙인뒤 base64로 인코딩하여 userid 부분에 넣어주면 끝!

md5(a) = 0cc175b9c0f1b6a831c399e269772661
md5(d) = 8277e0910d750195b448797616e091ad
md5(m) = 6f8f57715090da2632453988d9a1501b
md5(i) = 865c0c0b4ab0e063e5caa3387c1a8741
md5(n) = 7b8b965ad4bca0e41ab51de7b31363a1

※해당 포스트에 나온 취약점은 제가 찾은게 아닌 다른분이 제보한 취약점입니다.

[Github Link]
https://github.com/gnuboard/gnuboard5/commit/764cb349575e4a9d7d8e0bc43eaa918cfaed70e4

 이 취약점은 그누보드 하단에 있는 '회사소개', '개인정보처리방침', '서비스이용약관' 등에서 발생하는 취약점입니다. 패치된 코드를 보시면 아시겠지만 크게 '작성'과 '조회'부분으로 나눌 수 있습니다. adm/contentform.php 와 adm/contentformupdate.php가 '작성'에 해당하는 부분이고 bbs/content.php가 '조회'에 해당하는 부분입니다.

 먼저 contentform.php 를 확인해보면 '태그 필터링 사용'에 해당하는 부분을 통으로 주석처리해서 날립니다. 이를 통해 글 작성시 태그 필터링 옵션 선택을 불가능하게 만들 수 있습니다. (아래 이미지 참고)

 contentformupdate.php 를 확인해보면 '태그 필터링 사용'에 대한 값을 담고 있는 co_tag_filter_use 변수에 삼항 연산자를 이용해 무조건 참을 넣어주는 것을 확인할 수 있습니다. 결국 내용 작성시 보안을 위해 '태그 필터링' 사용 희망 여부에 관계 없이 그냥 통으로 선택지를 날리고 강제로 '태그 필터링'을 해주는 패치입니다. 여기에 추가적인 안전장치를 하나 더 해주는데 그게 content.php 부분입니다.

 content.php는 관리자가 아닌 일반 유저들이 조회할때 사용되는 페이지입니다. 해당 페이지를 로드할때 강제로 co_tag_filter_use부분을 1로 변경해줍니다. 아마 필터링 사용 여부를 선택할 수 있는 부분을 날렸어도 파라미터 변조로 강제로 거짓(0)값을 넣어줄 경우를 대비해서 위의 코드를 추가해준게 아닌가 싶습니다. 결국 작성/조회시 강제로 '태그 필터링'을 사용하게 만드는 패치로 볼 수 있겠습니다.

 이를 직접 확인해보기 위해 관리자 계정으로 로그인해서 해당 내용을 작성할때 간단한 테스트용 스크립트를 이용해봤습니다.