GRINI

[MongoDB] ObjectId 란?

Grini — Sun, 27 Jun 2021 16:51:34 +0900

ObjectId 란?

MongoDB는 Document 기반 데이터베이스인데,
ObjectId는 해당 Document 내에서 유일함을 보장하는 12byte 값으로, RDBMS의 Primary key와 같다.
Primary key는 DBMS가 부여하지만, ObjectId는 클라이언트에서 생성한다는 점이 차이가 있다.

ObjectId 구조

Inc Counter은 처음 랜덤한 값에서 자동으로 Increment 되는 값이다.

Reference

https://docs.mongodb.com/manual/reference/method/ObjectId/

ObjectId — MongoDB Manual

Reference > mongo Shell Methods > Object Constructors and Methods ObjectId( )Returns a new ObjectId value. The 12-byte ObjectId value consists of:a 4-byte timestamp value, representing the ObjectId's creation, measured in seconds since the Unix epocha 5-by

docs.mongodb.com

https://developer.mongodb.com/quickstart/bson-data-types-objectid/

Quick Start: BSON Data Types - ObjectId

MongoDB provides an automatic unique identifier for the _id field in the form of an ObjectId data type.

developer.mongodb.com

https://kciter.so/posts/about-mongodb

MongoDB 이해하기

사내에서 MongoDB를 잘 쓰기위한 스터디를 하게되어 이번 기회에 관련 자료를 정리하기로 했다. MongoDB가 왜 필요한지, 더 잘사용하기 위해서 무엇이 필요한지를 중심으로 처음 MongoDB를 사용할 때

kciter.so

[HTTP] Basic Authentication _ .htpasswd

Grini — Mon, 8 Mar 2021 15:07:55 +0900

.htpasswd 파일 이란?

서버의 특정 디렉토리에 HTTP Basic Authentication을 설정하여 접근 제한할 때 필요한 파일로 사용자명과 패스워드에 대한 정보를 저장하고 있는 파일이다.

[참고] https://en.wikipedia.org/wiki/.htpasswd

.htpasswd 형식

grini:$1$0FP4wdQ8$nC4xODrh4cGLHQ8Vkmpzk1
계정ID:$해시 알고리즘 종류$솔트 값$해시된 패스워드 값

[참고]
- foswiki.org/Development/ImproveHtPaswdUserFlexibility
- httpd.apache.org/docs/current/misc/password_encryptions.html

.htpasswd 생성 방법

1. apache2-utils의 htpasswd 기능 이용

-c 옵션 : 새로운 파일을 생성하는 옵션
(파일에 데이터를 추가하기 위해서는 -c 옵션을 빼고 사용해야 한다.)

2. openSSL 이용

수동으로 .htpasswd 파일을 생성하여 출력된 값을 형식에 맞게 삽입해준다.

3. 온라인 도구 이용
https://8gwifi.org/htpasswd.jsp

[Bugbounty Study] #Account Takeover

Grini — Sat, 6 Mar 2021 02:12:34 +0900

# Account Takeover Due to Response Manipulation _ \$4100

avanishpathak46.medium.com/an-account-takeover-vulnerability-due-to-response-manipulation-e23fe629bd1

An Account Takeover Vulnerability Due to Response Manipulation.

- No doesn’t necessarily mean no.! Responses can always be manipulated

avanishpathak46.medium.com

원작자는 해당 타겟 사이트에서 이전에도 Account Takeover 취약점을 발견한 이력이 있다.

우선, 이전 글을 살펴보자.

Account Takeover 취약점이란?
공격자가 어플리케이션에 존재하는 인증 결함을 이용하여 아무런 자격 증명 없이 피해자의 계정을 무단으로 제어할 수 있는 취약점 중 하나이다.
간단히, 계정 탈취가 가능한 취약점이다.

타겟 사이트는 사용자가 등록한 이메일로 전송되는 4자리의 OTP코드를 입력하면 로그인하는 기능이 있다.
OTP 길이가 짧아 Brute-force를 시도하였으나, 10번의 잘못된 요청을 보내면 일정 시간동안 요청 가능한 수가 제한되어 있어 HTTP 429 Too Many Requests를 응답하였다.

또한, 이전의 응답 패킷에 OTP 코드가 노출되어 있는지 확인하였으나 찾을 수 없었다.

올바른 OTP 코드를 입력하였을 때 /login/signin에서 발생하는 요청은 아래와 같다.

{"email":"usermail@gmail.com", "code":XXXX} CORRECT OTP

POST 요청은 이메일 주소와 이메일로 전송된 OTP 두 가지 파라미터를 포함한다.

이때, 해당 파라미터의 이메일 주소를 다른 계정으로 하고, OTP 코드를 공격자의 이메일로 받은 값을 입력해주면 로그인된다. 이는 이메일과 OTP 코드가 느슨하게 연결되어 있고, OTP 코드가 유효한지만 검사하였기 때문이다.

{"email":"admin@example.com", "code":XXXX} CORRECT OTP

패치:

타겟 사이트는 /login/singin에서 발생하는 요청에서 email 파라미터를 제거하고, 로그인을 시도하는 사용자에게 전송된 OTP인지 확인하는 작업을 추가하여 패치하였다.

[참고]

avanishpathak46.medium.com/an-interesting-account-takeover-vulnerability-a1fbec0e01a

An Interesting Account Takeover Vulnerability

- Login feature bypassed which leads to an Interesting Account Takeover

avanishpathak46.medium.com

본문으로 돌아와서 타겟 사이트의 로그인 흐름을 간단히 설명하면 아래와 같다.

1. 타겟 서버가 4자리의 OTP 코드 이메일로 전송
2. 받은 OTP 코드를 타겟 서버에 입력할 때만 사용자의 유효성 확인
3. 유효한 코드를 가진 인증된 사용자만 사용자 계정 접근 허용

이전의 제보처럼 OTP의 길이가 짧아 Brute-force 공격이 가장 먼저 떠올랐으나, 타겟 사이트는 엄격한 속도 제한이 설정되어 있어 10번의 잘못된 시도를 할 경우, 마찬가지로 HTTP 429 Too Many Requests을 응답하였다.

심지어 시간 지연 등 다양한 방법으로 Brute-force를 시도하였지만 같은 응답을 받았고, 응답에서 인증 코드 또한 노출되지 않아 어떤 것도 얻지 못하였다.

정상적인 로그인 흐름을 살펴보기 위해 테스트 계정인 이메일로 로그인 요청 후 Burpsuite를 이용하여 요청 패킷을 잡아 살펴보고 저장한 다음 요청을 삭제하였다.

잘못된 인증 코드를 입력하였을 경우를 살펴보니 401 Unauthorized error code를 응답받았다.

다양한 시도 끝에 응답 body에 포함된 에러 응답인 {"code":"invalid_credentials"}에 주목하였고,

해당 값을 이전에 저장해 둔 올바른 인증 코드의 응답 값으로 변경해보았다.

HTTP/1.1 401 Unauthorized -----> HTTP/1.1 200 OK
{"code":"invalid_credentials"} -----> {"verify":"true"}

그 결과, Account Takeover이 되었다.

이는 클라이언트 측 JavaScript가 수신한 응답을 기반으로 후속 요청을 발생시켜 새로운 세션 쿠키를 인증된 사용자로 설정하기 때문이다. (인증 검증은 서버 측에서 하는 것이 안전하다.)

패치:

로그인의 전체 흐름을 수정하였고, 클라이언트 측 JavaScript를 이용한 유효성 검사를 제거하였으며,

응답에 대한 사용자 입력 값을 허용하지 않아 응답이 조작되었을 경우에는 오류 메시지를 표시하도록 패치하였다.

[Bugbounty Study] #iCloud _ Stored XSS

Grini — Tue, 23 Feb 2021 00:26:28 +0900

# icloud.com Stored XSS _ \$5000

vbharad.medium.com/stored-xss-in-icloud-com-5000-998b8c4b2075

Stored XSS in icloud.com — $5000

Hello Guys hope you all are doing well, fine and healthy during this hard time.

vbharad.medium.com

원작자는 icloud.com을 타겟으로 정한 후,

CSRF, IDOR, Logic Bugs 등의 취약점을 찾기 위해 노력하다 XSS를 찾기로 결정하였다.

값을 삽입할 수 있는 다양한 곳에 페이로드를 삽입하면서 입력한 페이로드가 응답에 반영되는 페이지를 찾기 위해 많은 시도를 하였고, 결국 페이로드가 반영되는 endpoint를 발견하였다.

[ XSS 재현 방법 ]
1. https://www.icloud.com/pages 또는 https://www.icloud.com/keynotes 페이지에 접속
2. '“><img src=x onerror=alert(0)>'이름의 Pages 또는 Keynote 생성
3. 생성한 Pages 또는 Keynote를 다른 이(공동 작업자)에게 전송
4. 전송 받은 다른 이의 계정으로 pages에 접근하여 내용 수정 및 저장
5. 다시 pages로 이동 후 'Setting > Browse All Versions'로 이동
6. Browse All Version 클릭

Pages나 Keynote의 내용을 수정하면, Browse All Version에서 수정하기 전의 버전을 확인할 수 있다.
이때, Previouse Version에서 img 태그가 필터링되어 있지 않아 XSS가 발생하는 것 같다.

[PoC]

youtu.be/VQjPooskKgY

[HTTP] Header : X-Forwarded-For (XFF)

Grini — Tue, 9 Feb 2021 03:29:42 +0900

X-Forwarded-For (XFF)는 HTTP Proxy (또는 Load Balancers, Caching Server) 등을 통해 웹 서버에 접속하는 클라이언트의 IP 주소를 식별하기 위한 사실상 표준 헤더이다. (표준화된 버전은 HTTP Forwarded Header이다.)

웹 서버(또는 WAS)와 클라이언트 사이에 Proxy Server (또는 Load Balancers, Caching Server) 등의 장비가 있는 경우, 서버 접근 로그는 Proxy Server의 IP만 갖고 있기 때문에 Proxy Server의 IP를 요청한 IP로 인식하게 된다.
이때, X-Forwarded-For 헤더를 통해 웹 프로그램이 실제 요청한 클라이언트의 IP를 파악할 수 있다.

[문법]

X-Forwarded-For: <client>, <proxy1>, <proxy2>

여러 프록시들을 거칠 때, IP주소들이 차례로 열거되어 가장 오른쪽의 IP주소는 가장 마지막에 거친 프록시의 IP주소가 된다. 따라서, 첫 번째 IP주소를 통해 클라이언트 IP주소를 식별할 수 있다.

Apache나 Nginx에서 X-Forwarded-For을 사용하기 위해서는 따로 설정해주어야 한다.

# Apache
기본 로그 포맷은 %h로 Remote Address를 사용하는데 이를 %{X-Forwarded-For}i를 사용하도록 수정해주어야 한다.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
↓
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common

# Nginx

nginx.conf에 아래 구문을 추가하여 설정해주어야 한다.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

[참고] https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

[Reference]

- developer.mozilla.org/ko/docs/Web/HTTP/Headers/X-Forwarded-For

X-Forwarded-For - HTTP | MDN

X-Forwarded-For (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드

developer.mozilla.org

- www.lesstif.com/software-architect/proxy-client-ip-x-forwarded-for-xff-http-header-20775886.html

Proxy(프락시) 환경에서 client IP 를 얻기 위한 X-Forwarded-For(XFF) http header

X-Real-IP 헤더를 사용하는 제품일 경우 %{x-forwarded-for}i 대신 %{x-real-ip}i 사용

www.lesstif.com

[Bugbounty Study] #OTP Bypass Account Takeover

Grini — Mon, 8 Feb 2021 19:49:03 +0900

# Otp Bypass Account Takeover

logicbomb-1.medium.com/otp-bypass-account-takeover-to-admin-panel-ft-header-injection-16f2982a0136

OTP Bypass Account Takeover to Admin Panel — Ft. Header Injection

It looks like this year has great promises at least the starting is good. Already 3 bug bounty in the pipeline(just showing off:P) and…

logicbomb-1.medium.com

타겟은 정확하게 밝히지 않았고, OTP 인증이 구현되어 있는 온라인 교육 플랫폼이라는 것만 밝혔다.

OTP 기반의 로그인이 있었고, 이에 Brute Force 공격을 시도하였다.

이를 통해 IP 주소를 기반으로 속도 제한이 걸려 있다는 것을 알아냈다.

IP 주소 기반의 속도 제한은 다양한 Client IP 주소 또는 Upstream Server IP 주소로 우회가 가능하다.

IP 주소 기반 속도 제한 우회 방법?
Client가 웹 서버에 접근할 때 Proxy Server를 거쳐가는 경우,
Proxy Server는 X-Forwarded-For Header를 이용하여 웹 서버에 Client IP 주소를 전달하는데,
이때, 해당 헤더를 이용하여 IP 주소를 속일 수 있다.

[X-Forwarded-For Header] https://grini25.tistory.com/212

Burp Suite를 이용하여 아래와 같이 Brute Force 공격을 수행하였다.

Intruder 기능의 Cluster bomb를 이용하여 X-Forwarded-For 값과 OTP 값을 Brute Force 하였다.

이를 통해 OTP 기반의 로그인을 성공하였다.

로그인 성공을 통해 헤더 인젝션이 가능하다는 것이 분명해졌다.

IP 접근 제어 또는 속도 제한을 우회하는 것 외에 이것을 이용하는 다른 가능성도 있을 수 있었다.

원작자는 이전 회사에 있을 때 WordPress 관리자 인터페이스를 Client IP 주소를 기반으로 내부 IP로만 제한했었던 일을 떠올렸는데, 그 작동은 다음과 같았다.

허용된 내부 IP 주소가 헤더 값으로 입력되면,
실제 화이트리스트 목록에 없는 IP 주소와의 연결 및 제한된 페이지나 API 엔드 포인트로의 접속이 허용되더라도 Proxy는 X-Forwarded-For 값을 전달한다.

만약 X-Forwarded-F:127.0.0.1 헤더를 설정한 경우,

서버는 내부 IP에서 접속하고 있다고 판단하여 제한된 콘텐츠에 접근하는 것을 허용한다.

그러나 이를 위해서는 운이 좋아서 제한된 페이지를 찾을 수 있어야 하는데, 일반적으로 관리자 페이지/관리자 패널/민감한 엔드포인트는 찾기 어렵다.

타겟의 블로그 페이지(wp-admin)로 WordPress 관리자 인터페이스에 HTTP 요청을 시도하여 성공하였다.

~~(타겟 사이트가 WordPress 기반의 웹 사이트였던 것으로 추측된다.)~~

이제 Directory Brute Force를 수행하고 IP 기반의 제한된 엔드포인트가 더 있는지 찾는 것은 시간문제이다.
이와 같은 엔드포인트를 찾는데 유용한 리소스를 찾아 Burp Suite의 Intruder에 활용하였다.

[유용한 리소스]
https://github.com/ziadab/AdminBomber/blob/master/AdminBomber.py
https://github.com/s0md3v/Breacher/blob/master/paths.txt

다행히도 타겟의 CMS 카탈로그에는 HTTP 요청이 가능한(/cms/_admin/logon.php) 관리자 페이지가 하나 있었고, 이와 함께 수평 권한 상승에 성공하였다. (포털에 로그인하기 위해 권한이 한 단계 상승한 것은 아니다.)

예방 방법
신뢰할 수 있는 Proxy Server(또는 Load Balancers)의 IP 주소 목록을 지정한다.
만약 해당 목록에 없는 IP 주소에서 요청이 올 경우 X-Forwarded-For Header를 버린다.

Nginx는 다음과 같은 작업을 수행한다.
마지막 항목부터 시작하여 각 항목을 확인하여 신뢰할 수 있는 IP 주소 목록에 있는지 확인한다.
만약 신뢰할 수 있는 목록에 존재하지 않으면, 해당 항목 앞에 있는 모든 항목을 버린다.

1. Burp Suite Intruder _ Dictionary Attack 공격

Grini — Sat, 6 Feb 2021 23:12:57 +0900

Brup Suite의 Intruder 기능을 사용하여 관리자 페이지의 아이디와 비밀번호를 찾아보는 실습을 하였다.

관리자 페이지는 Hacker101 CTF의 PetShop Pro의 flag2를 이용하였다.

해당 문제의 관리자 페이지는 아래와 같고,

Username을 admin으로 입력하면 아래와 같이 잘못된 username이라는 메세지가 출력된다.

아마 Username을 알아낸 후, Password를 따로 알아내면 될 것이다.

Burp Suite의 Intruder을 활용하여 Username과 Password를 찾아보자.

우선, Username과 Password 값을 전송하는 Request 패킷을 Send to Intruder 한다.

Username의 값을 찾기 위해 payload position을 아래와 같이 username에 설정해준다.

username과 password의 페이로드 집합이 필요하므로 wordlist를 다운받아 로드시켜주었다.

그리고 Start attack을 눌러주면 아래와 같이 공격이 수행된다.

유효한 값은 응답 값이 다르기 때문에 Length가 다른 것을 확인하여 찾을 수 있다.

만약 Length 길이가 같은 경우에는 응답 값에 특정 문자열이 포함되어 있는지 확인하여 찾을수도 있다.

Options > Grep - Match에서 Invalid username을 추가해준 후 공격을 수행하면, 아래와 같이 지정한 값이 응답에 포함되어 있는지를 확인할 수 있다.

유효한 username의 값이 'mona'이기 때문에 Invalid username에 체크되어 있지 않다.

password도 동일한 방법으로 찾을 수 있다.

wordlist를 이용하였기 때문에 Payload type을 Simple list로 지정하였지만,

Payload type을 Brute force나 Username generator 등으로 설정하여 활용할 수도 있다.

[Reference]

- portswigger.net/support/using-burp-to-brute-force-a-login-page

Using Burp to Brute Force a Login Page

Using Burp to Brute Force a Login Page Authentication lies at the heart of an application’s protection against unauthorized access. If an attacker is ...

portswigger.net

0. Burp Suite 설치 및 사용방법

Grini — Sat, 6 Feb 2021 22:08:47 +0900

<목차>

0. 다운로드
1. 실행
2. Burp Suite 기본 설정
3. Burp Suite 기능
# Dashboard
# Target
# Proxy
# Intruder
# Repeater
# Sequencer
# Decoder
# Comparer
# Extender
4. Reference

0. 다운로드

Burp Suite는 Fiddler와 마찬가지인 웹 프록시 툴로,

서버와 클라이언트 간의 요청 및 응답 패킷을 Intercept 하는 것이 가능하여

웹 어플리케이션 테스트와 취약점 점검에 주로 사용한다.

[Burp Suite 다운로드] portswigger.net/burp

Burp Suite - Application Security Testing Software

Get Burp Suite. The class-leading vulnerability scanning, penetration testing, and web app security platform. Try for free today.

portswigger.net

다운로드 사이트에는 3가지 버전이 있는데, 나는 무료인 Community버전을 선택하였다.

Windows 64bit인 환경에 맞는 Setup파일을 다운받아 실행하여 설치를 진행하였다.

계속 Next를 클릭하고 조금만 기다리면 간단하게 설치가 완료된다.

설치가 되었으니 사용방법을 알아보도록 하자.

1. 실행

설치된 Burp Suite 실행하면 아래와 같이 저장된 프로젝트를 불러올 수도 있다.

딱히 불러올 프로젝트가 없으므로 Temporary project를 선택하였다.

프로젝트 사용법에 대해 알아보고 싶다면 아래 링크를 참고하면 된다.

portswigger.net/burp/documentation/desktop/getting-started/launching/select-project

2. Burp Suite 기본 설정

기본적으로 프록시 설정이 127.0.0.0:8080으로 되어 있다.

하지만, 8080 포트를 다른 서비스가 사용하고 있는 경우에는 사용할 수 없다.

그런 경우에는 다른 포트 번호로 변경하여 Running 시켜준다.

그 후,

브라우저에서 프록시 설정을 해주어야 패킷을 잡을 수 있다.

(Burp Suite에 설정된 포트 번호로 설정해야 한다.)

하지만, 최근 버전에서는 브라우저의 프록시 설정 없이 Intercept 할 수 있도록 지원한다.

Open browser을 클릭하면, 아래와 같이 비어있는 브라우저 창이 뜬다.

해당 브라우저를 이용하면 별도의 프록시 설정 없이 패킷을 잡을 수 있다.

패킷을 잡아보면 Request만 잡히고 Response는 잡히지 않는데,

이는 옵션에서 Responses도 Intercept 할 수 있도록 체크해주면 된다.

패킷에서 한글이 깨져있는 경우가 있다.

이는 Burp Suite에서 설정된 폰트가 한글을 지원하지 않는 폰트이기 때문임으로

User options > Display에서 한글을 지원하는 폰트로 변경하면 된다.

해당 창에서 테마를 Dark로 변경할 수도 있다.

3. Burp Suite 기능

# Dashboard

2.x 버전부터 생긴 기능으로, 대시보드를 통해 자동화된 활동을 한눈에 모니터링하고 제어할 수 있다.

대시보드의 창은 Task, Event log, Issue activity로 나누어져 있다.

Task 영역의 New scan은 Pro 버전에서만 지원하는 것으로 스캔 기능을 수행할 수 있다.
무료 버전에서는 New live task만을 지원하며, 이를 통해 실시간 크롤링이 가능하다.

Event log영역은 작업에 대한 Error, info 등의 이벤트 로그가 기록된다.

Issue activity영역은 스캔 활동에 대한 결과가 기록되는 곳으로 Pro 버전에서만 지원한다.

# Target

타겟 어플리케이션에 대한 자세한 정보를 확인할 수 있다.

현재 작업의 범위 내에 있는 타겟을 정의할 수 있고, 취약성 테스트 프로세스를 수행할 수도 있다.

1) Site map

브라우저에서 방문한 모든 URL이 개별 항목으로 기록되어

각 항목에 대한 전체 요청 및 응답에 대한 전체 세부사항을 볼 수 있다.

도메인, 디렉토리, 파일, 매개변수로 구분된 URL 및 내용을 계층적 트리 형식으로 보여준다.

분기를 확장하면 자세한 내용을 볼 수 있다.

필터 표시창을 클릭하면 디스플레이 필터 옵션이 열린다.

관심 있는 콘텐츠만 나타내도록 일부 항목을 숨기거나 표시하도록 필터링할 수 있다.

Site map에 너무 많은 항목이 있는 경우, 타겟 사이트만을 분석하는데 어려울 수 있다.

이때, request type의 필터를 통해 in-scope items만 볼 수 있도록 설정한 후,

'오른쪽 마우스'를 클릭하여 타겟 사이트를 scope에 추가해주면 지정된 사이트에 대한 정보만 볼 수 있다.

2) Scope

공격하려는 대상의 범위에 대해 설정할 수 있다.

Include in scope 영역은 범위 내 표시고, Exclude in scope는 범위 내 차단이다.

공격하려는 대상 범위를 설정한 후 아래와 같이 Proxy에서 설정해주면,

공격하려는 범위에 대해서만 Intercept할 수 있다.

3) Issue definitions

Burp Scanner에서 탐지할 수 있는 모든 문제의 정의 목록을 확인할 수 있다.

# Proxy

가장 많이 사용할 기능으로,

브라우저와 웹 서버 간의 모든 요청 및 응답을 가로채 훔쳐보고, 수정할 수 있다.

1) Intercept

브라우저와 웹 서버 간 HTTP 및 Websocket 메세지를 가로채 표시하는데,
가로챈 모든 메세지를 모니터링 및 수정할 수 있다.

Forward - 요청/응답 편집 후 서버 또는 브라우저로 전송
Drop - 서버 또는 브라우저로 전달되지 않도록 메시지 삭제
Intercept is on/off - 이 버튼을 사용하여 모든 가로채기를 켜거나 끔
Action - 현재 표시된 메시지에 대해 수행할 수 있는 동작 메뉴 표시
Open Browser - 별도의 프록시 설정 없이 Intercept 가능한 브라우저 창 켜짐

2) HTTP history

Burp Proxy를 통과한 모든 요청 및 응답에 대한 전체 기록이 저장되어 있다.
패킷 선택 후 요청 및 응답 탭에서 전체 메세지를 확인할 수 있다.
기록된 목록에 대한 필터링 및 주석을 설정하여 정보 관리가 가능하다.

3) WebSockets history

Brup Proxy를 통과한 모든 WebSockets 메세지 기록이 저장되어 있다.

HTTP history와 마찬가지로 기록된 목록에 대해 필터링 및 주석을 설정할 수 있다.

(나는 WebSocket 통신을 하지 않았기 때문에 아무런 패킷이 잡혀있지 않다.)

4) Options

Proxy listeners, HTTP 요청 및 응답 인터셉트, WebSocket 메세지 인터셉트,

응답 수정, 일치 및 교체, TLS 통과, 기타 옵션을 설정할 수 있다.

Proxy listeners - listeners 중 하나를 프록시 서버로 사용하도록 설정할 수 있다.
(Burp Proxy는 listeners를 사용하여 브라우저의 HTTP 요청을 수신한다.)
Intercept Client Requests - 클라이언트 요청 메세지 인터셉트에 대한 규칙을 지정할 수 있다.
Intercept Server Responses - 서버 응답 패킷 인터셉트에 대한 규칙을 지정할 수 있다.
Intercept WebSockets Messages - WebSocket 메세지의 인터셉트 여부를 개별적으로 설정할 수 있다.
Response Modification - 자동 응답 수정을 통해 다양한 작업을 수행할 수 있다.
Match and Replace - Proxy를 통해 전달되는 요청 및 응답의 일부를 자동으로 변경하는 데 사용한다.
TLS Pass Through - TLS 연결을 통해 직접 전달할 대상 웹 서버를 지정하는 데 사용한다.
Miscellaneous - Proxy 동작의 특정 세부 정보를 제어하는 옵션을 설정할 수 있다.

# Intruder

자동화된 사용자 지정 공격을 수행하기 위한 도구이다.

어플리케이션을 테스트할 때 발생하는 모든 종류의 작업을 자동화하는 데 사용할 수 있다.

즉, Brute Force 공격 및 Fuzzing을 수행할 수 있다.

1) Target

공격을 위한 타겟 서버의 세부 정보를 구성하는 데 사용한다.

Host - 타겟 서버의 hostname이나 IP 주소 값
Port - HTTP/S 서비스 port 번호
Use HTTPS - 타겟 서버의 HTTPS 사용 유무 체크

2) Positions

페이로드 삽입 위치 구성 및 페이로드가 할당되는 공격 유형을 결정하는 데 사용한다.

오른쪽의 버튼을 통해 페이로드 삽입 위치에 대한 구성을 설정할 수 있다.

(§로 둘러싸인 부분이 페이로드로 설정된 것이다.)

Add § - request template에서 페이로드 위치 추가
Clear § - request template에서 모든 페이로드 위치 제거
Auto § - 유효한 위치를 추측하여 그에 맞게 페이로드를 배치
Refresh - 필요시 request template 편집기의 구문 색상 표시 새로고침
Clear - 전체 request template 삭제

Burp Intruder는 Sniper, Battering ram, Pitchfork, Cluster bomb와 같은 다양한 공격을 지원한다.

(공격에 대입할 페이로드 집합을 설정해야 한다.)

Sniper - 단일 페이로드 집합이 사용되며, 정의된 각 위치에 차례로 페이로드를 삽입한다.
(첫 번째 위치의 삽입이 끝나면, 두 번째 위치 순으로 삽입.)

Battering ram - 단일 페이로드 집합이 사용되며, 정의된 모든 위치에 동일한 페이로드를 삽입한다.

Pitchfork - 단일 이상의 페이로드 집합이 사용되어, 각 정의된 위치의 개수(최대 8개)만큼 사용된다.
각 페이로드가 정의된 위치에 동시에 삽입된다.

예시) ?id=§this_is_id§&passwd=§this_is_password§
- payload set 1 {admin, test, a, b}, payload set 2 {pass, passwd, asdf}
?id=admin&passwd=pass
?id=test&passwd=passwd
?id=a&passwd=asdf
...

Cluster bomb - 단일 이상의 페이로드 집합이 사용되어, 각 정의된 위치의 개수(최대 8개)만큼 사용된다.
각 페이로드 집합을 순서대로 반복하여 모든 페이로드의 조합을 테스트한다.

예시) ?id=§this_is_id§&passwd=§this_is_password§
- payload set 1 {admin, test, a, b}, payload set 2 {pass, passwd, asdf}
?id=admin&passwd=pass
?id=admin&passwd=passwd
?id=admin&passwd=asdf
?id=test&passwd=pass
...

3) Payloads

하나 이상의 페이로드 집합을 구성하는 데 사용되며,

집합 개수는 Positions 탭에서 설정한 공격 유형에 따라 달라진다.

Payload Sets - 하나 이상의 페이로드 집합 정의
Payload Options - 페이로드로 사용되는 문자열의 단순 목록 구성
Payload Processing - 각 페이로드가 사용되기 전 다양한 처리 작업을 수행하는 규칙 정의
Payload Encoding - HTTP 요청 내에서 안전한 전송을 위한 URL encoding 설정

4) Options

공격에 영향을 미치는 옵션을 구성하는 데 사용한다.

Request Headers - 공격 중에 구성된 request header 업데이트 여부 제어
Request Engine - 공격 수행 시 HTTP 요청 수행 엔진 제어
Attack results - Attack results에 캡처되는 정보 제어
Grep - Match - 지정된 표현식이 포함된 결과 항목 플래그 추가 가능
Grep - Extract - 유용한 정보를 공격 결과 테이블로 추출 가능
Grep - Payloads - 사용된 페이로드 값이 응답 값에 포함되었는지 여부 결과 항목 플래그 추가
Redirections - 공격 수행 시 Burp의 Redirection 처리 방법 제어

Send to Intruder을 클릭하면 자동으로 위의 값들이 설정되어 쉽게 사용할 수 있다.

[Intruder 실습] grini25.tistory.com/210?category=858418

# Repeater

개별 HTTP 요청을 변경 및 재발급하여 어플리케이션의 응답을 분석할 수 있다.

요청을 수정하여 계속 발행할 수 있어 매개 변수값을 변경하거나 발행 순서를 변경하여 요청함으로써,

입력 값에 의한 취약점 발생을 테스트하는 데 사용할 수 있다.

Send to Repeater을 클릭하면 세부 사항이 간단히 설정되어 쉽게 사용할 수 있다.

요청을 보낼 준비가 되면 Send를 클릭하여 서버로 요청 값을 전송하고,

서버로부터 받은 응답은 Response를 통해 볼 수 있다.

각 Repeater tab은 요청에 대한 기록을 유지하므로 < / >를 이용하여 전/후의 요청 및 응답을 확인할 수 있다.
drop-down 버튼을 이용하면 번호를 통해 빠르게 이동할 수도 있다.

Repeater의 Tab은 다음과 같이 관리할 수 있다.

Double-Clicking - Tab의 이름 변경
Dragging - Tab의 순서 변경
... Clicking - 새 Tab 생성
x Clicking - Tab 닫기

# Sequencer

웹 어플리케이션에서 제공하는 값의 임의성을 분석하기 위한 기능이다.

세션 토큰, CSRF 방지 토큰, 암호 재설정 토큰 등과 같이 랜덤 한 중요한 데이터를 테스트할 수 있다.

1) Live capture

타겟 웹 어플리케이션에서 생성되는 토큰을 캡처하여, 샘플 토큰 목록을 생성하고 분석하여 결과를 출력한다.

분석을 원하는 패킷에 Send to Sequencer를 하면 Select Live Capture Request에 항목이 추가된다.

Token Location Within Response는 어플리케이션의 응답 내에서 토큰이 나타나는 위치를 선택할 수 있다.

즉, 사용자에게 캡처에 사용할 항목을 선택하게 한다.

Cookie - 응답으로 쿠키가 설정된 경우, 분석할 쿠키 선택 가능
Form fields - 응답에 HTML 양식 필드가 있는 경우, 분석할 양식 필드 값 선택 가능
Custom location - 사용자의 임의로 항목 정의 가능

Live Capture Options는 라이브 캡처 수행 시 HTTP 요청 및 토큰 수집에 사용되는 엔진을 제어 설정할 수 있다.

Nuber of threads - 실시간 캡처가 동시에 서버에 보낼 수 있는 요청 수
Throttle between requests - 모든 요청 전 지연 시간 (과부하 방지 or 은밀한 요청에 유용)
Ignore token whose length deviates by _ charaters - 지정한 평균 토큰 길이 벗어나는 토큰 무시 설정

모든 설정이 끝난 후, Start live capture를 누르면 라이브 캡처가 시작되며,

라이브 캡처 중에는 토큰 수, requests 수 및 네트워크 오류 수를 progress bar로 보여준다.

라이브 캡처 진행 중 다음의 옵션을 사용할 수 있다.

Pause/Resume - 캡처 일시적 중단 및 재시작
Stop - 캡처 영구적 중지
Copy tokens - 현재 캡처된 토큰 클립보드에 복사
Save tokens - 현재 캡처된 토큰 파일에 저장
Auto analyze - 토큰 자동 분석 수행, 라이브 캡처 중 결과 주기적 업데이트
Analyze now - 최소 100개의 토큰이 캡처되면 Burp가 현재 샘플을 분석 후 결과 업데이트

2) Manual load

이미 생성된 토큰 샘플(Live Capture / Intruder 이용)을 불러와 샘플에 대한 통계 분석을 수행할 수 있다.

3) Analysis options

토큰에 대한 처리 방법과 분석하는 동안 사용하는 테스트 유형을 설정할 수 있다.

Token Handling은 분석 중 토큰 처리 방법을 제어할 수 있다.

Pad short tokens at Start/End - 각 토큰의 시작/끝 패딩 적용 여부 선택
Pad with - 패딩에 사용될 문자 지정(보통 "0")
Base64-decode before analyzing - 토큰이 Base64 인코딩 된 경우 분석 전 디코딩 설정

Token Analysis는 문자와 비트 레벨의 테스트에서 수행되는 분석 유형을 제어할 수 있다.

# Decoder

데이터 암/복호화 및 해시 형식으로 변환할 수 있는 기능이다.

휴리스틱(heuristic) 알고리즘을 사용하고 있어 여러 암호화 형식을 지능적으로 인식할 수 있다.

drop-down 목록을 이용하여 필요한 변환을 선택하여 변환하면 된다.

Smart decode는 아래 값이 인코딩 된 것으로 보이는 데이터를 찾아 내용을 자동적으로 디코딩하는 옵션이다.

위와 같이 데이터를 직접 입력하는 것도 가능하지만,

인/디코딩하고자 하는 데이터를 선택하여 Send to Decoder으로 이용하는 것도 가능하다.

# Comparer

두 데이터(요청, 응답 등) 간의 비교를 수행하므로,

다른 입력에 대한 응답을 비교하는 데 유용하게 사용할 수 있다.

비교하고자 하는 값(Request/Reponse)을 복사 + 붙여넣기 하거나,

파일을 로드하거나, Send to Comparer으로 Comparer에 값을 전송하여 데이터를 로드할 수 있다.

비교할 두 가지 데이터가 선택되면,
Words, Bytes 중 하나의 비교 형식을 선택하여 비교할 수 있다.

Words Comparer

단어 단위의 비교로, 비교 된 항목 간의 차이점이 단어 수준에 존재할 때 유용한 방식이다.

Bytes Comparer

바이트 단위의 비교로, 비교 된 항목 간의 차이점이 바이트 레벨에 존재하는 경우 유용한 방식이다.

# Extender

자체 또는 타사 코드를 사용하여 기능을 확장할 수 있다.
확장 기능에 대해 Extensions, BApp Store, APIs, Options에서 설치 및 사용하고 관리할 수 있다.

1) Extensions

설치된 모든 확장 기능을 확인할 수 있으며, 추가, 제거, 재정렬(Up/Down) 할 수 있다.

Details탭에서 해당 확장 기능 정보를 확인할 수 있고,

Extension loaded를 체크하면 확장을 활성화할지 비활성화할지 선택할 수 있다.
Output탭에서 확장 기능의 표준 출력 스트림 세부 사항을 확인할 수있다.
Errors탭에서 표준 오류 스트림 정보를 확인할 수 있다.

2) BApp Store

Burp Suite 사용자가 작성한 Burp 확장 기능이 있다.
사용 가능한 BApps를 확인하여, 설치하여 사용할 수 있다.

3) APIs

Burp 확장 기능을 개발하는 데 사용할 수 있는 API에 대한 세부 정보를 확인할 수 있다.

실행 중인 Burp 버전에서 사용할 수 있는 API 정보가 표시되어 있다.

Save interface files 및 Save Javadoc files는

확장 기능을 개발할 때 사용할 수 있도록 코드를 로컬 사본으로 저장하는 기능이다.

4) Options

확장 설정, Java 환경, Python 환경, Ruby 환경에 대한 설정 옵션이 있다.

Settings - 시작 시 확장을 어떻게 처리할 것인지 설정
(시작 시 자동으로 재로드할 것인지, BApp 자동으로 업데이트할 것인지)

Java environment - Java로 작성된 확장 기능 실행을 위한 환경 구성 설정
확장 프로그램에서 라이브러리를 사용하는 경우 라이브러리를 로드할 폴더를 지정할 수 있다.

Python environment - Python으로 작성된 확장 기능 실행을 위한 환경 구성 설정
Python 확장 기능을 사용하려면 Jython*을 다운로드 받고 경로를 설정해야 한다.
Jython* : Java로 구현된 Python 인터프리터

Ruby environment - Ruby로 작성된 확장 기능 실행을 위한 환경 구성 설정
Ruby 확장 기능을 사용하려면 JRuby*를 다운로드 받고 경로를 설정해야 한다.
JRuby* : Java로 구현된 Ruby 인터프리터

아래는 확장 개발에 필요한 공식 정보 페이지이다.

Burp 확장 도구 개발은 Python, Ruby, Java를 통해 개발할 수 있다.

[Burp Suite Extender] portswigger.net/burp/extender

[How to install Jython/JRuby] portswigger.net/support/how-to-install-an-extension-in-burp-suite

[Burp Extender Tools] github.com/alphaSeclab/awesome-burp-suite/blob/master/Readme_en.md

4. Reference

- portswigger.net/burp/documentation/contents

Burp Suite documentation - contents

Documentation Desktop editions Getting started Next steps ...

portswigger.net

- portswigger.net/burp/documentation/desktop/penetration-testing

How to use Burp Suite for penetration testing

The sections below describe the essentials of how to use Burp Suite within your web application testing workflow. For help with installing and launching ...

portswigger.net

- www.techpanther.in/search/label/Burp Suite

Techpanther

Blog about Computer Tricks , Cyber security , Windows Server , Cloud Computing , Linux

www.techpanther.in

[Python] sys.stderr.write(f"ERROR: {exc}") 해결 방법

Grini — Sun, 31 Jan 2021 00:37:37 +0900

pip install --upgrade pip 명령어를 실행하는 중 다음과 같은 에러가 발생하였다.

[해결 방법]

python3
\$ wget https://bootstrap.pypa.io/3.5/get-pip.py
\$ python3 get-pip.py

python2
\$ wget https://bootstrap.pypa.io/2.7/get-pip.py
\$ python get-pip.py

get-pip.py란?

사용자가 파이썬 환경에서 pip, setuptools, wheel을 설치할 수 있게 하는 bootstrapping script이다.

~~(나는 우분투에 pip가 기본적으로 설치돼 있었는데, 뭔가 제대로 설치가 안되어 있던 것일까..?;;)~~

[Bugbounty Study] #Vimeo _ SSRF

Grini — Wed, 27 Jan 2021 20:53:00 +0900

# uploading process SSRF _ \$100 + \$4,900

medium.com/@dPhoeniixx/vimeo-upload-function-ssrf-7466d8630437

Vimeo upload function SSRF

TL;DR

medium.com

해당 글은 Vimeo 동영상 업로드 과정에서의 SSRF 취약점에 대한 글이다.

~~이 취약점 제보를 통해 총 두 번의 Bounty를 받았다.~~

해당 글의 타겟인 Vimeo는 직접 제작한 동영상을 업로드 및 공유할 수 있는 사이트로,

로컬에 저장되어 있는 파일뿐만 아니라 드롭박스나 Google Drive 등 다양한 방식으로 업로드할 수 있다.

BurpSuite를 이용하여 Google Drive로의 동영상 업로드 요청을 확인하였다.

Upload Request

동영상 파일이 저장되어 있는 URL과 Google authorization값을 전송하는 것을 볼 수 있는데,

이는 백엔드 서버가 해당 값으로 구글 드라이브의 파일에 접근해 가져오기 위한 값이다.

백엔드 서버에서 어떤 일이 발생하는지 알아보기 위해 동영상 다운로드를 요청한 후 WireShark로 패킷을 확인하였다.

HTTP Stream Of Download Request

패킷의 Range, Content-Range 같은 일반적이지 않은 헤더를 통해 어떤 일이 발생하는지 알 수 있다.

대부분 동영상의 크기가 크기 때문에 Vimeo가 전체 파일을 한 번에 요청하지 않는다고 추측할 수 있다.

만약, 동영상의 크기가 작으면 전체 파일을 요청할 것이고, 크면 전체 파일이 될 때까지 파일의 부분을 요청할 것이다.

Normal Upload Process

[Upload Process]
1. 동영상 업로드 요청 (Client -> Backend Server)
2. 동영상 크기 확인을 위한 0Byte 데이터 요청 (Backend Server -> hoster.com)
3. Content-Range값을 통해 동영상 크기 응답 (hoster.com -> Backend Server)
4. 동영상 데이터 요청 (Backend Server -> hoster.com)
5. 동영상 데이터와 함께 요청 완료 응답 (hoster.com -> Backend Server)
6. 파일 인코딩 검사를 통해 동영상 파일 여부 확인 후 사용자 프로필로 전달 (Backend Server)

[Header Range, Content-Range] https://developer.mozilla.org/ko/docs/Web/HTTP/Range_requests
[HTTP 206 State Code] https://developer.mozilla.org/ko/docs/Web/HTTP/Status/206

서버가 파일의 크기를 확인하는 요청을 보낸 다음, 만약 단일 연결으로 전송할 만큼 파일의 크기가 작으면 전체 파일을 요청할 것이다.

이 부분에서 원작자는 서버에서 Backend Server가 요청한 만큼의 데이터보다 적은 양의 데이터로 응답하면 어떻게 될지 궁금하였고, 이를 위해 Python으로 웹 서버를 구축하여 테스트하였다.

전체 파일의 길이는 554321B이지만 Vimeo에서 전체 파일을 요청할 때 8228B만 응답하였다.

로그를 통해 Vimeo Server에서 8228B만큼 저장하여 8228-554321 범위의 남은 파일을 요청한 것을 확인할 수 있다. 이런 경우 서버가 Vimeo에 Redirect 응답을 보내면 SSRF로 이어질 수 있다.

Redirect Responed Process

[Redirect Responed Process]
1. 동영상 업로드 요청 (Client -> Backend Server)
2. 동영상 크기 확인을 위한 0Byte 데이터 요청 (Backend Server -> evil.com)
3. Content-Range값을 통해 동영상 크기 응답 (evil.com -> Backend Server)
4. 동영상 데이터 요청 (Backend Server -> evil.com)
5. 8228Byte의 동영상 데이터와 함께 요청 완료 응답 (evil.com -> Backend Server)
6. 파일이 응답받은 크기가 아니므로 나머지 데이터 요청 (Backend Server -> evil.com)
7. http://evil.com/Hello.txt로 Redirect 응답 (evil.com -> Backend Server)
8. Backend Server가 Redirect되어 http://evil.com/Hello.txt로 접근
9. Hello.txt의 내용과 함께 요청 완료 응답 (evil.com -> Backend Server)
10. 파일이 응답받은 크기가 아니므로 나머지 데이터 요청 (Backend Server -> evil.com)
11. 나머지의 동영상 데이터와 함께 요청 완료 응답 (evil.com -> Backend Server)
12. Backend Server는 받은 파일의 크기가 더 크지만 부족하지 않으므로 넘어간 후 받은 파일 병합
(파일의 8228 offset은 Backend Server가 Redirect 된 evil.com/Hello.txt의 데이터로, FIRST_8228_BYTES_OF_VIDEO_FILE + Helloworld!zzz + REST_BYTES_OF_THE_VIDEO_FILE과 같이 보일 것이다.)

몇몇 웹 서버에서 공격을 재현하는 것은 제한적이어서 공격을 수행하기 위해 서버를 구축하여 실행하였다.

구축한 서버를 통해 공격이 제대로 동작하는 것을 확인하였다.

(참고: 업로드된 파일을 다운로드할 수 있어 쉽게 SSRF를 확인할 수 있다.)

[Exploit]
1. 구축한 서버에 대한 정보 수집
2. 서버가 구글 인스턴스임을 확인하여 인스턴스 메타데이터 검색
3. 응답할 Redirect 주소 변경
(http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token)
4. 공격 재현
5. 컴퓨팅 엔진 API access token 얻음

[Exploit 결과]