저미 보안공부

Pay1oad 1st Semester CTF · Digital Forensics + Reverse Engineering · 출제자 직접 작성 라이트업 안녕하세요. 이번 CTF에서 제가 출제한 마지막 문제, Silent Assistant를 정리합니다. 이 문제는 얼마 전 읽은 뉴스에서 아이디어가 시작됐습니다. AI 기능을 내세운 가짜 크롬 확장 프로그램으로, 정상 AI 도구로 위장해 배포됐는데, 실제로는 사용자 데이터를 수집해 서버로 유출됐다는 기사였습니다. 이 기사를 기반으로 AI 도구를 쓰는 순간이 유출 트리거가 되는 시나리오를 작성해 보고 싶었습니다. 따라서, 이번 문제는 AI 코딩 도구에 등록된 악성 MCP 서버가 공급망 공격의 통로가 되는 상황을 디스크 이미지(E01) 한 장으로 재구성하는 문제입..

Pay1oad 1st Semester CTF · Forensics(Memory Analysis) · 출제자 직접 작성 라이트업 안녕하세요. 이번에는 Pay1oad 1기 CTF의 메모리 분석 문제 Ghost Process를 정리합니다. 약 2GB짜리 Windows 메모리 덤프 하나가 주어지고, 그 안에 숨은 악성 프로세스와 플래그를 찾는 문제입니다. 0. 문제 개요- 문제명: Ghost Process- 카테고리: Memory Analysis- 시나리오: 공격자가 악성 파일을 실행했다. 현장에서 수거된 메모리 덤프를 분석하여 악성 프로세스를 찾고 숨겨진 플래그를 찾아라.- 핵심 프로세스: svch0st.exe - payload 형태: Base64 문자열 1. 의심 프로세스 식별도구: Volatility 3..

Pay1oad 1st Semester CTF · Forensics(침해사고 분석) · 출제자 직접 작성 라이트업 안녕하세요. 이번에는 Pay1oad 1기 CTF에서 침해사고 분석 파트로 출제한 Knock Knock 문제를 정리해 봅니다. 단일 아티팩트 하나만 파면 끝나는 문제가 아니라, 두 개의 서로 다른 아티팩트(이벤트 로그 + 패킷 캡처)를 '시간'이라는 공통 키로 엮어야 답이 나오는 문제입니다. 0. 문제 개요- 문제명: Knock Knock- 카테고리: 침해사고 분석- 배포파일: Security.evtx, capture.pcap- 시나리오: 공격자가 내부 서버에 침투한 정황이 포착되었다. 어떤 계정으로 침투했는지 확인하고, 침투 이후 다운로드한 파일명을 찾아라. pcap에 HTTP 요청이 약 ..

2026 Pay1oad 1st Semester CTF · Forensics(Steganography) · 출제자 직접 작성 라이트업 안녕하세요2026 Pay1oad 1st CTF에서 포렌식 파트로 출제한 Just Trick 문제의 출제 의도와 풀이를 정리해 봅니다. 이름 그대로 암호화처럼 보이게 만든 트릭이 핵심인 문제입니다. 1. 문제 개요- 문제명: Just Trick- 카테고리: Steganography- 시나리오: 이미지 너머에 숨겨진 진실을 찾아 플래그를 획득하세요! Pay1oad{flag} 2. 배포 파일 명세- 포맷: PNG- 임베드 위치: PNG IEND 청크 이후- 임베드 포맷: ZIP (Local File Header 50 4B 03 04)- 내부 파일: flag.txt- 암호화 방식..

이번 글은 지금까지 점검·수정해온 Pay1oad 서비스를 실제 서버에 배포하고, 코드를 고친 뒤 재배포하는 과정을 정리한 기록입니다. 백엔드는 AWS EC2에 직접 올리고, 프론트는 Vercel로 배포했습니다. 1. 전체 구성- 백엔드: AWS EC2 (Ubuntu 24.04) + Nginx 리버스 프록시 + PostgreSQL - 프론트: Vercel- 도메인: 가비아 DNS → pay1oad.xyz- HTTPS: certbot 흐름은 "사용자 → pay1oad.xyz(Vercel) → API 요청 → api.pay1oad.xyz(EC2 Nginx → Spring Boot:8000)" 입니다. 2. 백엔드 배포 (EC2)2.1 인스턴스 준비리전을 기본값(시드니)에서 서울로 바꾸고 EC2를 생성했습니다..

오늘은 공격은 안 통했는데 코드를 손봐야 하는 사례입니다. 인증 우회는 재현되지 않았고 보호 데이터도 노출되지 않았습니다. 그런데도 보호 라우트가 비로그인 요청에 HTTP/2 200 + HTML shell을 반환하는 구조는 그대로 두기 어렵습니다. "공격이 성공하지 않았다"가 "안전하다"는 결론은 아니기 때문입니다. 1. 점검 개요- 대상: hxxps://www.pay1oad.xyz- 방식: 외부 관찰 기반 블랙박스 (Burp Suite, OWASP ZAP)- 계정: 비로그인, 일반 회원, 관리자- 범위: 게시글 상세, Content 라우트, 관리자 부원관리- 주요 점검: CVE-2025-29927 방식 헤더 조작, X-Forwarded-Host 조작, 보호 라우트 직접 접근, 관리자 API 재전송 외..

이번에는 React가 절반은 막아주지만 절반은 그대로 통과시키는 어드민 페이지의 입력 검증 결함 이야기입니다. javascript: 같은 위험한 스킴은 React가 자동으로 막아주지만, hxxps://evil.com 같은 형식상 정상인 외부 URL은 그대로 통과합니다. 백엔드에 URL 검증이 없으면 그게 곧 피싱 발판이 됩니다. Open Redirect란, 사이트가 받은 URL 입력을 검증 없이 그대로 이동에 사용해, 사용자를 임의의 외부 사이트로 보내버리는 결함입니다. 신뢰하는 도메인에서 시작한 클릭이 공격자가 정한 피싱 사이트로 이동하기 때문에, 흔히 피싱 공격의 발판으로 쓰입니다. URL 형식 검증과 도메인 화이트리스트로 막는 것이 일반적입니다. 1. 취약점 개요문제의 원인은 어드민 페이지의 지원..

오늘은 sanitization 같지만 실제로는 sanitization이 아닌 코드가 어떻게 credentials: 'include'와 만나 계정 탈취로 이어지는지 살펴봅니다. (2)편에서는 서버가 이메일을 무방비로 받아들이는 Mass Assignment가 주제였다면, 이번 글은 같은 결과(ATO)에 도달하는 다른 출발점 — 프론트엔드의 불완전한 sanitization — 에 관한 이야기입니다. Sanitization 은 사용자가 입력한 데이터에서 위험한 부분을 제거하거나 무력화시키는 작업입니다. 예를 들어 누군가 같은 걸 본문에 적었다면, 이걸 그대로 다른 사용자의 브라우저에 띄우는 순간 onerror 안의 자바스크립트가 실행됩니다. Sanitizer는 이런 위험한 속성(onerror 등)이나 태그( ..

오늘은 단일 취약점으로는 작아 보이지만, Stored XSS와 결합했을 때 관리자 권한까지 통째로 넘어가는 위험천만한 시나리오와 이를 막기 위한 시큐어 코딩 방법을 알아봅니다. 1. 취약점 개요문제의 원인은 프로필 수정 API가 사용자 이메일을 아무런 추가 인증(현재 비밀번호 확인, 이메일 링크 인증 등) 없이 즉시 바꿔주기 때문에 발생합니다.- 취약점명: Mass Assignment via Email Field로 인한 계정 탈취 - 대상: PATCH /v1/users/me - 유형: CWE-915 (Mass Assignment) + CWE-79 (Stored XSS) 연계- 심각도: Critical 1.1 취약점 설명PATCH /v1/users/me는 프로필 수정 API인데, 클라이언트가 보낸 ema..

오늘은 웹 애플리케이션에서 가장 빈번하게 발생하면서도 치명적인 위협 중 하나인 '파일 제출/업로드 기능의 결함'을 분석하고, 이를 AWS EC2 환경에서 어떻게 성공적으로 패치하고 재검증했는지 그 과정을 공유하고자 합니다. 프로젝트나 실무에서 파일 업로드 기능을 구현할 때 "설마 파일 이름으로 공격하겠어?" 하고 방심하기 쉬운 부분들을 짚어보겠습니다. 1. 기존 코드의 취약점과 위험한 공격 시나리오 6가지 기존 코드는 클라이언트가 보낸 원본 파일명(file.getOriginalFilename())을 파일시스템 경로에 그대로 노출하고 있었고, 입력 검증 단계에서도 점(.)의 개수만 확인하는 한계가 있었습니다. 이로 인해 발생할 수 있는 치명적인 시나리오들은 다음과 같습니다. ① 경로 탈출 (Path T..