memo1240 님의 블로그

[swlug] 7주차 웹해킹 과제

memo1240 — Tue, 18 Nov 2025 13:13:28 +0900

1. 실습

1. account 접속하여 실습 링크에 있는 아이디,비밀번호로 로그인

2. 이메일 변경 패킷을 찾아 repeater로 전송

3. repeater에서 우클릭 change request method 클릭

post -> get으로 바뀜을 알 수 있음

4. 이메일을 swlug에서 test로 바꾼 후 send

5. 성공 화면

6. CSRF 공격을 사용하는 익스플로잇 서버 사용

7. body에 이메일 변경 패킷 주소와 바꾸려는 이메일 입력

8. 성공 화면

2. 과제

1. 과제 링크에 있던 아이디, 비번으로 로그인을 한다

2. 디폴트 이메일을 test 이메일로 변경해보았다

3. 이메일 변경 패킷을 잡고 실습 과정처럼 repeter을 통해 변경을 시도하였으나 변경되지 않았다

4. 익스플로잇을 통해 변경해보겠다

5. 변경 패킷에 붙어있던 토큰을 통해 이메일 변경을 시도하였다

6. 5의 공격이 통하지 않아 토큰을 빼고 시도해보았다

7. 토큰의 유효성을 보는 공격이라 당연히 통하지 않았다.

5의 코드를 다시 시도해보았다.

두 번째 시도에서 성공하였다.

[swlug] 7주차_클라우드 스터디

memo1240 — Tue, 11 Nov 2025 22:27:57 +0900

11. 요약정리 및 리소스 제거

1. VPC(사무실) : 사용자가 완전 격리된 가상 네트워크 환경을 AWS 클라우드 상에 직접 설계, 운영할 수 있도록 해 주는 서비스

2. 서브넷(부서) : VPC의 IP 주소 범위를 논리적으로 분할한 네트워크 단위

3. 인터넷 게이트웨이(사무실 출입구) : VPC에서 생성된 네트워크와 인터넷 사이의 통신을 가능하게 하는 것

4. NAT 게이트웨이(부서 주소) : 프라이빗 서브넷의 인스턴스가 아웃바운드 인터넷 접속을 할 때, 퍼블릭 IP 하나로 변환해 외부와 통신하는 게이트웨이

5. 라우팅 테이블(통행로) : 네트워크 내에서 목적지 IP 블록별로 트래픽을 어디로 보낼지 정의한 길 안내 지도

6. 보안 그룹(출입 제한) : 인스턴스 단위로 적용되는 가상 방화벽

7. 점프 서버(직원용 인포데스크) : 내부 네트워크의 중요한 시스템에 직접 접근을 통제하기 위해 마련된 중간 접속 지점

8. 웹 서버(서비스 직원) : 클라이언트로부터 HTTP 요청을 받아 정적,동적 콘텐츠를 처리, 전송하는 소프트웨어 또는 하드웨어

9. 로드 밸런서(고객용 인포) : 다수의 서버로 들어오는 네트워크 트래픽을 분산시켜, 서비스의 가용성,확장성,성능을 최적화하는 장치 또는 소프트웨어

10. RDS(사내 창고) : 관리형 관계형 데이터베이스 서비스로, 사용자가 직접 서버를 구축, 운영하지 않아도 자동으로 설치,패치,백업,모니터링 등을 수행

11. S3 버킷(외부 공용 창고) : 객체 스토리지 서비스로, 대용량 데이터 저장, 관리에 최적화

리소스 제거

생성 순서와 반대로 삭제

EC2에서 S3 관련 역할 분리 -> 역할 제거 -> S3 버킷 객체 제거 -> S3 버킷 제거 -> 데이터베이스

S3에서 버킷 객체 제거

S3 버킷 삭제

스냅샷 생성을 해제하여 데이터베이스 삭제

서브넷 그룹 삭제

옵션 그룹 중 sample만 제거

파라미터 그룹 제거

->RDS 리소스 모두 제거함

EC2의 대상 그룹, 로드밸런서 제거

인스턴스 삭제 -> EC2 리소스 제거

VPC 보안 그룹 삭제

라우팅 테이블 연결 해제 후 삭제

NAT 게이트웨이 삭제 -> 인터넷 게이트웨이 삭제 -> 탄력적 ip 주소 제거

-> 최종 VPC 제거

키 페어 삭제

-> 최종적으로 IAM 계정 삭제

[swlug] 6주차 웹해킹 과제

memo1240 — Tue, 11 Nov 2025 21:46:38 +0900

1. 실습

1. 로그인 후 My account로 접속하여 test, 1234를 입력한 후 패킷 확인

test를 드래그 한 후 add 클릭

2. 로그인 요청 패킷 분석

3. 실습 사이트의 candidate usernames의 데이터를 복사

4. candidate usernames과 candidate passwords 중 Length와 Status가 다른 한 개의 데이터를 선택하여 로그인 진행

5. 찾은 비밀번호와 아이디를 통해 로그인

2. 과제

사용자 미흡으로 인한 타사용자 비밀번호 초기화 가능성 해결 문제

사용자 계정 wiener / peter

피해자 계정 carlos

1. My account로 접속

2. intercept on 후 사용자로 로그인

3. 로그인 후 Email client로 이동

현재는 inbox가 비었음

4. 확인 후 로그아웃, 로그인 화면의 Forgot password를 통해 비밀번호 재설정

사용자 계정인 wiener입력

Email client 사이트에 비밀번호 재설정을 위한 링크가 생성됨을 확인할 수 있음

4. 비밀번호를 1234로 재설정

5. 바뀐 비밀번호로 재로그인

6. 패킷 중 비밀번호 재설정 패킷을 찾아 취약점 분석

같은 사용자임을 확인하는 토큰이 정상적으로 작동하지 않아 타인의 비밀번호를 재설정할 수 있음

7. username을 피해자 계정으로 바꾼뒤 실행

재지정한 비밀번호로 로그인됨을 알 수 있음

[5주차] 논문 분석

memo1240 — Thu, 6 Nov 2025 00:43:49 +0900

RAPPOR: Randomized Aggregatable Privacy-Preserving Ordinal Response

42852.pdf

0.58MB

Randomized Aggregatable Privacy-Preserving Ordinal Response — RAPPOR 논문 분석

클라이언트에서 무작위화(randomized response)를 적용해 로컬 차등프라이버시(Local DP)를 보장한 채로 문자열·범주형 통계를 수집하는 프레임워크입니다. Bloom 필터 + 2단계 무작위화와 LASSO 기반 해독(decoding)으로 대규모 사용자 집단에서도 쓸 만한 정확도를 확보합니다.

1. 논문 선정 이유

실무에서는 민감한 원본을 안 모으고도 집계 통계는 얻고 싶다는 요구가 계속됩니다. RAPPOR는 이 딜레마를 로컬 무작위화로 돌파합니다. 서버나 제3자를 믿지 않고, 각 사용자가 자기 단말에서 데이터를 확률적으로 뒤섞어 내보냅니다. 구글 Chrome 실사용 사례까지 언급되어 있어 연구 → 구현까지의 결과가 확연히 드러난다고 생각하여 선정하게 되었습니다.

2. 문제의식과 목표

운영자는 기능 사용률, 오류율, 악성 설정 하이재킹 등 집단 통계를 알아야 서비스를 개선할 수 있습니다. 그러나 사용자별 원본을 모으면 식별·추적 위험이 커집니다.

RAPPOR의 목표는 다음과 같습니다.

개별 사용자 수준에서 ε-차등프라이버시 보장을 제공할 것
문자열·범주형 값의 빈도/히스토그램을 장기간 수집할 것
무작위 집계가 아니라 쓸 만한 유틸리티를 낼 것.

3. 핵심 아이디어

3.1 Bloom 필터 + 2단계 무작위화

Bloom 필터화: 보고하려는 문자열을 여러 해시로 비트 배열에 표기합니다(충돌 허용). 이렇게 만들어진 비트 벡터는 원문을 직접 드러내지 않습니다.
영구(Permanent) 무작위화: 사용자가 같은 값을 반복 보고해도 매번 똑같이 보이지 않도록, 메모이제이션된 1차 랜덤화 결과를 만들어 저장합니다(연속 수집 시 링크성 저감).
순간(Instantaneous) 무작위화: 보고 시점마다 위 결과에 한 번 더 노이즈를 섞어 전송합니다(보고 횟수가 많아져도 ε 보장 악화 최소화). 두 단계 조합이 장기 수집(Longitudinal)의 프라이버시 핵심입니다.

3.2 해독(Decoding)

서버는 수집된 비트들을 가설검정 + 최소제곱 + LASSO 회귀를 섞은 절차로 풀어 상위 문자열(heavy hitters)의 빈도를 추정합니다. 이에 클라이언트는 강한 익명성을 지키고, 운영자는 집단의 분포를 얻습니다.

4. 이게 ‘차등프라이버시’로 왜 안전한가

RAPPOR는 로컬 모델에서 각 보고가 ε-차등프라이버시를 만족함을 이론적으로 제시합니다. 전통적인 단일 무작위화만으로는 반복 조사 시 프라이버시가 약화되는데, RAPPOR는 영구+순간의 2단계로 반복 수집에서도 보장을 유지하는 설계를 채택합니다. 신뢰할 제3자 불요 또한 중요한 차별점입니다.

5. 결과·사례

시뮬레이션과 실데이터 두 건(Windows 프로세스, Chrome 설정 수집)으로 구현했습니다. 상위 항목을 안정적으로 복원하면서도 개별적인 부분은 보호됨을 알 수 있었습니다. Chrome에서는 사용자가 옵트인한 텔레메트리에서 악성 설정 하이재킹 탐지에 기여한 바를 알 수 있었습니다.

6. 한계와 장점

장점:

(1) 클라이언트 단에서 프라이버시를 보장하므로 데이터 유출·권한 남용 리스크를 구조적으로 낮춥니다.

(2) 문자열·범주 통계에 강하며, 장기 수집에 맞춘 설계입니다.

(3) 구현·운영이 비교적 단순하고, 대규모 배포 경험이 있습니다.
한계:

(1) 꼬리 항목(희소 문자열) 탐지는 어렵습니다.

(2) 파라미터(해시 수, 비트 길이, 보고 확률)를 잘못 잡으면 복원 성능이 크게 하락합니다.

8. 느낀 점

읽으면서 통계는 크게 보되, 개인은 작게 본다는 원칙이 설계에 얼마나 구체적으로 녹을 수 있는지 체감했다. 무엇보다 장기 수집에서의 링크성 문제를 2단계 무작위화로 풀어낸 부분이 인상적이었다. 결과적으로 운영자는 개선에 필요한 숲의 윤곽을 얻고, 사용자는 나무로 특정되지 않는다는 약속을 받았다. 현업에서는 RAPPOR 같은 로컬 DP 수집을 1차선으로 깔고, 필요에 따라 서버 측 집계에 추가 노이즈나 버킷팅을 더하는 이중 방어선이 현실적 대안이 될 것 같다고 생각했다.

[slwug] 6주차 클라우드 스터디

memo1240 — Tue, 4 Nov 2025 23:01:55 +0900

1. 관계형 데이터베이스 서버(RDS)

RDS란?

AWS가 제공하는 관리형 관계형 데이터베이스 서비스로, 사용자가 직접 서버를 구축, 운영하지 않아도 자동으로 설치,패치,백업,모니터링 등을 수업해줌.

RDS 시스템

데이터베이스 엔진 : 실제 데이터베이스 본체를 가리킴
파라미터 그룹 : 주로 데이터베이스 엔진 고유의 설정을 수행함
옵션 그룹 : 주로 RDS 고유의 설정을 수행함
서브넷 그룹 : 여러 개의 가용 영역에 분산 배치할 때 이용되는 설정

데이터베이스 서버 생성 흐름

파라미터 그룹 생성 -> 옵션 그룹 생성 -> 서브넷 그룹 생성 -> 데이터베이스 생성

1. 파라미터 그룹 생성

특정 엔진의 설정 값을 모아 관리하는 템플릿

2. 옵션 그룹 생성

RDS 엔진에 추가 기능을 플러그인 형태로 묶어 관리하는 설정 모음

3. 서브넷 그룹 생성

4. 데이터베이스 생성

표준생성 -> mysql로 생성

강의 자료와 같은 db가 없어서 기본값으로 진행

이전에 만들었던 vpc가 뜨지 않아 vpc 또한 디폴트 값으로 진행

위 두개의 설정을 제외하고 강의 자료와 같은 구성으로 DB 생성함

5. 작동 확인하기

웹 접속 -> MySQL 명령어 설치 (sudo yum -y install mysql 명령어 실행

-> MySQL 통신 (mysql ping -u admin -p -h)

2. 스토리지

데이터를 오랫동안 저장하는 것을 목적으로 제공되는 데이터 저장 장소

S3란?

AWS의 객체 스토리지 서비스로, 대용량 데이터 저장, 관리에 최적화되어 있음

버킷 : 최상위 컨테이너, 리전 단위 생성
객체 : 파일 + 메타데이터, 키로 식별
버전 관리 : 동일 키의 이전 버전 보존
라이프사이클 정책 : 객체를 자동으로 다른 스토리지 클래스로 전환하거나 삭제

1. S3 버킷 생성

2. 역할을 생성해 EC2에 적용하기

wep01,02의 역할 변경

3. 작동 확인하기

웹 서버 접속 -> 파일 생성 -> S3 업로드

이 이후 파일 생성이 제대로 되지 않아 이후 실습이 막혔다. 파일 작성 후 저장하는 부분이 진행되지 않는다. 팀원들과 함께 논의가 필요한 부분인 것 같다.

[swlug] 5주차 웹해킹 과제

memo1240 — Tue, 4 Nov 2025 13:00:51 +0900

1. XSS 실습

1. burp suite 설정

Target에서 Scope settings을 클릭하고 Add를 눌러 문제 사이트의 패킷만 받을 수 있도록 주소를 추가함 (사진에는 https 밖에 없지만 https,http 모두 추가해야함)

2. proxy-HTTP history를 클릭하고 filter에서 위와 같이 설정함

3. 블로그 내 포스트 하단 댓글을 작성함

4. Post Comment를 누르기 전 intercept on으로 바꿔주고 댓글을 등록함

5. 댓글을 등록하면 comment 부분에 댓글 내용이 들어간 것을 볼 수 있음

6. 이 comment 부분에 스크립트 코드를 넣은 후 forward를 실행.

실습 사이트에 댓글이 작성된 것을 볼 수 있고, 댓글을 작성한 포스트로 이동한다는 경고창이 뜨는 것을 볼 수 있음

2. 과제

이 랩에는 검색 기능에 반영된 간단한 교차 사이트 스크립팅 취약점이 포함되어 있습니다.
랩의 문제를 해결하려면 경고 기능을 호출하는 크로스 사이트 스크립팅 공격을 수행하세요.

1) 일단 아무거나 검색을 해본다

1) Stored XSS

: 공격자는 게시글, 쪽지, 댓글 등등 여러 곳에 자바스크립트 코드를 입력하여 작성해 놓는다.

공격을 당하는 사람은 해당 웹 페이지를 열 때 숨겨진 자바 스크립트 코드가 실행되어 공격당하게 된다.
가장 대표적인 공격 코드는
<script>alert(1)</script> 를 삽입하는 것이고, 이것 이외에도 여러가지 공격이 존재한다.
자세한것은 xss cheat sheet를 참고하면 좋다. https://mslilsunshine.tistory.com/21

1. XSS 공격 기법 : Cross-site Scripting

#XSS란 무엇인가?*워게임 사이트나 가상환경에서 실행해보기 바람..클라이언트에 대한 취약점을 이용해서 javascript, html 언어 등을 이용하고 있는 불특정 다수를 공격할 수 있다.공격자가 악의적

mslilsunshine.tistory.com

2) 이에 검색 창에 <script>alert(1)</script>를 삽입한 후 실행하였다.

3) Search를 실행하면 alert(1)이 실행되므로 경고창을 띄울 수 있다.

[4주차] 논문분석

memo1240 — Thu, 30 Oct 2025 12:12:54 +0900

1610.05755v4.pdf

0.50MB

누가 정답을 가르쳤는지 숨기는 법 — PATE 논문 분석

한 줄 핵심: 민감 데이터로 학습한 여러 교사(teacher) 모델의 예측을 노이즈를 섞은 집계로 합쳐서 학생(student) 모델을 가르치면, 학생은 개별 교사·개별 샘플의 흔적 없이 지식을 전수받음. 이 절차는 차등프라이버시(DP)를 만족하도록 분석되었고, 실제 벤치마크에서 품질–프라이버시의 균형이 검증되었음.

1. 논문 선정 이유

실제 시스템에서 개인 데이터로부터 학습하되, 개인 흔적을 남기지 않는 모델을 만들려면 학습 절차 자체가 바뀌어야 합니다. PATE는 복잡한 신경망 내부를 뜯어고치지 않고도, 교사 앙상블 + 노이즈 투표라는 직관적인 구조로 강한 형식적 보장(차등프라이버시)을 제공함. 이후 확장판(PATE 2018)은 클래스가 많은 대규모 태스크로 스케일하는 방법까지 다뤄, 연구·산업 모두에서 레퍼런스로 자리 잡았음.

2. 배경과 목표

딥러닝 모델은 종종 훈련 데이터의 라벨·패턴을 과도하게 기억해 멤버십 추론/재식별 공격에 노출됨. PATE의 목표는 (a) 민감 데이터를 직접 공개하지 않고도, (b) 학생 모델이 쓸 만한 정확도를 얻도록 하면서, (c) 전체 과정에 대해 (ε, δ)-DP 보장을 제공하는 것. 핵심 발상은 지식을 전수하되, 누가 말했는지는 모르게 함.

3. 핵심 아이디어 — 교사 앙상블의 노이즈 집계

교사 모델 학습: 민감 데이터셋을 서로 겹치지 않게 분할하여 여러 교사 모델을 각각 학습함. 각 교사는 자신의 파티션만 봄.
노이즈가 섞인 투표: 라벨이 필요한 공개(또는 합성) 데이터 샘플에 대해 교사들의 예측을 투표로 모으고, 여기에 라플라스/가우시안 노이즈를 더해 최다득표 클래스만 학생에 제공합니다(정답 라벨처럼 사용). 이때 노이즈 크기·응답 횟수에 따라 프라이버시 예산이 소모됨.
학생 학습: 학생은 교사 개별 내부/파라미터를 전혀 보지 않고, 오직 집계된(익명화된) 라벨로 학습. 결과적으로 단일 개인·단일 교사의 영향력이 묻히며, 이 과정 전체가 차등프라이버시로 분석됨.

스케일 업(PATE 2018): 교사 간 합의가 약한 경우에는 무응답하거나, 더 집중적인(Concentrated/Rényi) 노이즈를 쓰는 GNMax 같은 집계로 오염(노이즈) 대비 정보량을 끌어올림. 클래스 수가 많거나 데이터 품질이 들쭉날쭉해도 더 타이트한 DP 보장을 얻도록 설계됨.

4. 실험과 관찰

MNIST, SVHN 등에서 학생 모델이 유의미한 정확도를 달성하면서 공개 가능한 ε 범위의 DP 보장을 가짐.
준지도(semisupervised) 설정을 활용해, 라벨 비용/프라이버시 비용을 아끼면서 성능을 유지함.
투표 응답 횟수가 늘어날수록 프라이버시 예산을 더 쓰게 되므로, 질문을 아끼고 정밀한 집계를 쓰는 운영 전략이 중요함.

5. 강점과 한계점

강점:

학습 알고리즘에 블랙박스로 붙일 수 있어 적용이 쉬움.
형식적 보장이 깔끔하고, 라벨 보호가 중요한 도메인에 특히 적합함.
확장판이 제시한 선택적 응답/집중 노이즈로 대규모로도 운용 가능함.

한계:

교사 수·데이터 분할 품질이 낮으면 투표 신뢰도가 떨어져 노이즈에 취약함.
응답 횟수 관리를 잘못하면 ε가 급격히 커짐.
공정성 편향 등 2차 효과에 유의해야 함(후속 연구가 공정성 이슈를 지적).

6. 느낀 점

이 논문을 읽고, 정답을 알려주되, 누가 알려줬는지는 감춘다는 단순한 발상이 프라이버시를 이렇게 멀리 끌고 갈 수 있음을 실감했다. 모델의 내부를 복잡하게 바꾸기보다 학습 프로토콜을 디자인해서 정보 흐름을 통제한다는 점이 특히 인상적이었다. 현업에서는 DP-SGD처럼 파이프라인 안쪽을 바꾸는 방법과, PATE처럼 라벨 수급 단계를 바꾸는 방법을 혼합하면 도메인·조직 여건에 맞는 현실적인 프라이버시–성능 균형을 찾기 좋을 것 같다.

[swlug] 5주차 클라우드 스터디

memo1240 — Wed, 29 Oct 2025 14:30:19 +0900

점프서버란?

내부 네트워크의 중요한 시스템에 직접 접근을 통제하기 위해 마련된 중간 접속 지점이다.

internet -> 퍼블릭 서브넷: 점프 서버 -> 프라이빗 서브넷 : 내부 서버

1. 단일 진입점 : 내부망에 대한 SSH, RDP 접근을 한 대의 점프 서버로만 허용

2. 접근 제어 강화 : 인증,인가,로그 기록 짐중 관리로 보안 사고 대비

3. 네트워크 분리 : 퍼블릭 섯브넷에 배치하여 외부와 내부망을 완전히 분리

SSH란?

네트워크 상에서 안전하게 원격 로그인, 명령어 실행, 파일 전송을 위해 설계된 암호화 프로토콜

- 생성 내용

1. 이름 : SSH 접속에 이용하는 키의 이름 [개인 이름]
2. 파일 형식 : SSH 접속 형식 [pem]

1. 키 페어 생성

2. 점프 서버 준비하기

웹 서버란?

클라이언트로부터 HTTP 요청을 받아서 정적,동적 콘텐츠를 처리,전송하는 소프트,하드웨어

1. HTTP 요청 수신 : 클라이언트가 보낸 GET,POST 등 요청을 받음

2. 콘텐츠 제공 : HTML, CSS, JS, 이미지 같은 정적 파일 또는 어플 로직을 실행해 생성된 동적 콘텐츠 반환

3. 상태 관리 : 세션,쿠키를 통해 사용자 상태 유지

3. 웹 서버 준비하기

점프 서버와 비교

점프 서버는 시스템 관리자가 가끔 이용.
웹 서버는 웹 서비스 사용자가 항상 연결을 시도함

점프 서버는 인터넷에서 직접 연결
웹 서버는 로드 밸런서를 통해 간접 연결됨

4. 접속 확인하기

다단계 연결 : 다단계 연결 설정은 config라는 이름의 파일을 생성하고 그 안에 기술함.

이 파일은 비밀 키 파일과 마찬가지로 홈 디렉터리의 .ssh 폴더에 저장함.

홈 디렉토리에 .pem 파일 복사

파일에 권한 할당

점프서버 접속

웹 서버 접속

[swlug] 4주차 웹해킹 과제

memo1240 — Tue, 28 Oct 2025 12:50:37 +0900

실습문제

목표

업로드 기능을 이용해 서버가 쓰는 위치와 파일명을 통제하여, flag라는 이름의 파일을 업로드 디렉터리에 만들고 웹에서 직접 열어 FLAG{...}를 획득한다.

1) 기능 파악 & 소스 확인

view-source를 통해 index.php를 확인한다.

문제의 경로를 알아내야함 파일 업로드시 flag획득

필터링은 ", <, >, /만 제거한다. 점(.), 백슬래시(\), 등은 허용.
업로드 성공 후 같은 경로/파일명으로 다시 fopen(...,"w") + fwrite($flag):
⇒ 파일 내용이 전부 FLAG로 바뀜(확실한 정보 유출 버그).
파일 경로는 ./{upload_dir}/{filename} 형태. {upload_dir}는 난수/토큰 디렉터리라서 값을 먼저 알아야 브라우저로 접근 가능.

2) 에러를 이용한 업로드 경로 노출

브라우저에서 평범히 업로드하면 경로를 모른다.
의도적으로 아주 긴 파일명으로 업로드해 PHP 경고를 유도한다.

Burp 등 프록시에서 Content-Disposition의 filename=(매우 긴 문자열)로 수정.
업로드 시 “File name too long” 경고가 뜨면서 정확한 서버 경로가 노출된다.

이 경로 중 4b0e87... 같은 부분이 실제 웹에서 접근 가능한 업로드 디렉터리 이름이다.
이제 우리는 https://webhacking.kr/challenge/web-19/4b0e87.../파일명 형태로 접근할 수 있다.

3) 파일명 통제: ‘flag’ 파일 만들기

경로를 알았으니, 이제 파일명을 flag로 해서 업로드한다.

4) FLAG 획득

이제 브라우저에서 다음을 연다:

https://webhacking.kr/challenge/web-19/<노출된_upload_dir>/flag

그러면 FLAG{error_msg_is_more_useful_than_you_think}가 출력된다.

error_msg_is_more_userful_than_you_think

실습과제

/etc/passwd를 확인하여 문제해결

burp suite 설정 후 블로그를 새로고침하고 수집된 패킷 확인

(위 사진은 블로그 내 보이는 이미지를 의미)

이미지 패킷 하나를 선택하여 Repeater로 전달

filename을 변경하여 /etc/passwd 파일 내용을 확인함

변경전 -> 4.jpg 변경후 -> ../../../../../../../etc/passwd

filename을 /etc/passwd를 확인하는 경로로 변경함

filename 변경 후 블로그를 새로고침하면 문제가 해결됨을 알 수 있음

[swlug] 3주차 웹해킹 과제

memo1240 — Mon, 29 Sep 2025 13:05:10 +0900

수업 실습

1. Lab: OS command injection, simple case

개요

제품 상세 페이지의 Check stock 기능이 사용자 입력을 포함한 셸 명령을 실행한다. storeId 자리에 명령 연결 연산자를 붙이면 명령 삽입이 가능하다. 랩 목표는 whoami 실행 결과를 응답에서 확인하는 것.

재현 절차

상품 상세 화면에서 드롭다운(지점 선택) 옆 Check stock 클릭 → 요청 가로채기.
요청 바디에 productId와 storeId가 포함됨을 확인.
productId=3&storeId=1
주입: storeId 뒤에 파이프(|)로 whoami 연결.
productId=3&storeId=1|whoami
응답 확인

페이로드 요약

기본: storeId=1|whoami
우회: 1;whoami, 1&&whoami, 1|id
공백 필터 시: 1|$(whoami) 또는 1|echo${IFS}$(whoami)

실습 과제

2. Lab: Blind OS command injection with time delays

개요

피드백 제출 기능이 블라인드 명령 삽입에 취약하다. 출력은 안 보이므로 응답 지연(10초)으로 취약점을 증명한다.

엔드포인트 및 파라미터

피드백 폼에는 name, email, subject, message 필드가 있으며, 이 값들이 서버 측 셸 명령 조합에 사용된다.

기준(베이스라인) 확인

정상 값으로 제출하면 즉시 “Thank you for submitting feedback!” 메시지가 뜬다.

주입 및 시간 지연 유발

이메일 필드에 명령 연결자를 붙여 전송(URLEncoding 필수):

email=admin%40gmail.com%3Bsleep%2010

또는

email=admin%40gmail.com%26%26sleep%2010
email=admin%40gmail.com%7Cping%20-c%2010%20127.0.0.1

요청을 보내면 페이지 내용은 동일하게 보이지만 약 10초 지연 후 성공 메시지가 나타난다. 이것으로 랩이 해결된다.

우회 팁

공백 필터: sleep${IFS}10 → ...%3Bsleep%24%7BIFS%7D10
;가 막히면 && 또는 |
특정 필드가 검증되면 name/subject/message로 필드 교체

3. 핵심 원인(두 랩 공통)

서버가 사용자 입력을 문자열로 이어붙인 셸 명령에 넘긴다.

cmd = "stockchecker " + productId + " " + storeId
# 혹은
cmd = "mail -s '" + subject + "' " + email + " < /tmp/msg"
system(cmd)

연산자(|, ;, &&)가 해석되어 동일 권한 컨텍스트에서 추가 명령이 실행된다. (두 랩 화면·응답 결과가 이를 뒷받침)

4. 대응 방안(요약)

셸 호출 지양, 라이브러리/API 호출 사용(인자 배열 사용)
입력값 화이트리스트·검증(특수문자 제거/거부)
명령 실행 필요 시 명령어와 인자 분리해 전달, 최소권한 원칙 적용