R's Hacking Daily Log

Lab - Web shell upload via obfuscated file extension 이번 Lab에서는 파일 확장자와 관련된 파일 업로드 공격을 살펴볼 것이다. 이전에 살펴본 Lab은 :) 파일 업로드가 제한되는 장소(= directory)를 우회하는 directory traversal :) file type 제한을 우회하는 Content-type header 등을 활용해 공격했다면 이번 Lab에서는 파일 확장자에 대해 다뤄볼 예정! ** 파일 확장자란, 파일명 뒤에 명시되는 값으로 파일이 어떤 종류의 파일인지를 나타내주는 역할을 한다. 흔히 텍스트 파일은 txt, 사진은 png & jpg, 그밖에 html, css, js, php, c, exe 등 ".file_extension"과 같은 형태로..

Lab - Web shell Upload via path traversal 파일 업로드에 대해 살펴볼 3번째 Lab은 path traversal 공격과 연관되어 있다. ** path traversal Directory Traversal Directory Traversal이란? file path traversal이라고도 불리는, 공격자가 application에서 돌아가는 서버의 임의 파일을 읽을 수 있도록 하는 웹 보안 취약점이다. application의 code와 data, back-end system에 대한 자 10halip1ap-47.tistory.com 사용자가 파일을 업로드하면 고정된 경로로 파일이 저장되는 데 이번 Lab에서는 고정 경로에서 php file이 실행되지 않는다. 그렇기 때문에 se..

Lab - Web shell upload via Content-type restriction bypass 이번에 Lab에서는 파일을 업로드할 때 서버에서 요구하는 확장자가 만족되어야 하는 상황을 보여준다. 앞선 Lab에 했던 거처럼 php 파일을 사용해서 upload 하면 오직 image\jpeg & image\png인 유형의 파일만을 허용한다는 문구가 나온다. 문구를 자세히 보면 "application/octet-stream은 허용되지 않는다"는 부분에서 힌트를 얻을 수 있다. 파일을 업로드할 때 보낸 packet을 보면 위와 같이 content-disposition header가 작성되는 걸 볼 수 있다. avatar 파일을 제출한 사람이 누구인지, csrf token과 업로드한 파일 정보를 각각 나..

File upload vulnerabilities 파일 업로드 취약점이란, 파일명, 확장자, 크기, 내용과 같은 것들을 충분하게 검증하지 않고 사용자가 서버 파일 시스템에 파일을 업로드할 수 있는 취약점을 얘기한다. 파일명, 크기, 파일 확장자 등을 제대로 검사하지 않는 경우, :) 동일한 이름의 파일을 업로드하여 서버에 있던 중요한 파일 내용을 덮어쓰기 :) 쓸데없이 디스크 공간을 차지하면서 Dos 공격을 수행 :) 이미지를 업로드하는 기능을 활용해 이미지가 아닌 임의의 코드 파일을 업로드 또한, server side script 파일을 업로드하게 된다면 원격 코드 실행(RCE) 공격도 가능하며 directory traversal 취약점이 있는 경우에는 예기치 않은 경로에 공격자가 파일을 업로드할 수도..

Lab - User ID controlled by request parameter with password disclosure 지금까지 access control과 관련된 대표적인 Horizontal & Vertical privilege escalation Lab을 풀어보았다. 이번 글에서는 추가적으로 간단히 살펴볼 만한 Lab을 풀어보고자 한다! 첫 번째 Lab은 Horizontal escalation에서 Vertical escalation으로의 전환을 다루는 내용이다. Lab으로 들어가서 로그인을 하면 현재 로그인한 계정의 비밀번호가 제공되는 걸 확인할 수 있다. 접근 제어가 적절하게 이루어져 이 페이지에 사용자 본인만 접근할 수 있다면 문제가 되지 않지만 그렇지 못한 경우를 보여주고자 하는 것이 이..

Lab - User Id controlled by request parameter with data leakage in redirect Horizontal privilege escalation에 대한 마지막 Lab을 살펴보자. 앞에서와 비슷하게 parameter를 활용하기 때문에 carlos의 parameter 값을 알아내는 과정이 필요하다. wiener:peter로 로그인을 해주면 동일하게 api를 확인할 수 있다. 이때 url에서 볼 수 있듯이 id parameter 값이 현재 로그인된 계정이름으로 되어있다. 이 값을 carlos를 수정하면 어떻게 될까? 싶어 해봤더니 허가되지 않은 계정은 resource에 접근 불가하게 처리되기 때문에 login page로 redirection 되는 걸 볼 수 있다..

Lab - User Id controlled by request parameter, with unpredictable user IDs ) 저번 글에 이어서 Horizontal escalation과 관련된 Lab을 풀어보자!! 이번 Lab에서도 parameter로 전달되는 값으로 사용자 계정 페이지에 접근할 수 있는 데 그 형태가 조금 다르다. wiener:peter 계정으로 로그인하면 앞에서 살펴본 lab과 동일하게 api key를 확인할 수 있다. 달라진 점이 있다면 url에서 볼 수 있듯이 id parameter가 사용자 계정명이 아니라 GUID라는 것..!! ** GUID란, globally unique identifier의 줄임말로 사진에서와 같이 총 {8-4-4-4-12}로 32개의 16진수로 ..

Horizontal Privilege Escalation Horizontal privilege escalation은 사용자가 권한 수준이 같은 다른 사용자에게 속한 resource에 접근할 수 있을 때 발생한다. Vertical privilege escalaction은 자신에게 주어진 권한보다 높은 권한을 탈취하는 것이라면 Horizontal privilege escalation은 자신과 동일한 수준의 권한인 다른 사용자의 권한을 탈취하는 것이다. 동일한 수준의 권한을 얻어서 무슨 이득이 있지? 싶을 수 있지만 권한 수준이 어떻든 다른 사람의 권한을 얻는다는 건 그 사람에게만 허용되는 데이터나 기능에 접근 가능해진다는 의미이기 때문에 노출되면 안되는 정보를 제공하게 될 수 있다. ** 카드 번호나 사용자..