▲

GTFOBins

 (gtfobins.org)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Unix 바이너리 목록을 기능별로 정리해 두었고, 각 바이너리에서 가능한 동작을 상세 페이지와 앵커 링크로 바로 연결해 둠
  • 반복적으로 붙는 분류는 Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load, Privilege escalation이며 일부 항목에는 Bind shell도 함께 붙음
  • File read와 Shell은 매우 넓게 분포하고, dd·sed·sqlite3 같은 도구는 읽기와 쓰기를 함께 가져 단순 조회형 도구와의 경계가 흐려짐
  • apt·git·journalctl·systemctl 같은 도구는 Command와 Inherit를 자주 포함하고, bee·pipx·sqlmap·vim 계열처럼 네트워크 전송과 셸 동작을 함께 가진 다기능 바이너리도 반복적으로 나타남
  • Privilege escalation은 별도 링크가 붙은 일부 바이너리에 한정되어 나타나며, 7z부터 zypper까지 이어지는 폭넓은 목록이 일반 도구의 동작 조합 차이를 한눈에 드러냄

대표 기능 분포

다기능 바이너리

네트워크, 셸, 라이브러리 로드

권한 상승 항목

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 댓글들에서 헷갈려하는 것 같아서, 이게 보안/CTF 문맥에서 언제 쓰이는지 예를 들면 이렇다
    제한된 셸이나 일부 명령/바이너리만 실행 가능한 환경에서, 보통 인자는 꽤 자유롭게 넣을 수 있음
    그때 GTFOBins를 이용하면 파일 읽기/쓰기나 명령 실행까지 이어서 제한된 컨텍스트를 탈출해 셸을 얻을 수 있음
    누군가 sudo를 열어두거나 GTFOBin에 SUID bit를 줬다면, 설정한 사람도 몰랐던 방식으로 민감한 파일을 읽거나 쓰고 권한 있는 명령을 실행할 수도 있음

    • 이런 건 claude-code 같은 도구에도 꽤 해당됨
      권한 처리가 block-list와 allow-list 중심이라 꽤 원시적인 편임
      한 세션에서 실수로 Claude에 powershell 권한을 준 적이 있는데, 그 뒤로 git 같은 도구가 막히면 같은 일을 하는 powershell 스크립트를 써서 실행하며 막힌 권한을 우회하더라
      정상적인 시스템이라면 powershell을 일반 allow-list에 넣진 않겠지만, 도구별 허용 수준의 틈이 있으면 이 페이지의 기법들로 충분히 돌아갈 수 있어 보임
    • 권한 상승 중재를 한다는 일부 엔터프라이즈 보안 소프트웨어도 비슷하게 위험할 수 있음
      한 회사에서 본 배포 방식은 관리자가 넣은 allowlist의 프로그램은 비밀번호 없이 sudo로 실행되게 만들었고, 처음부터 vim, bash 같은 범용 도구들이 들어가 있었음
      재택근무하던 입장에선 오히려 다행이라 느꼈는데, 내 컴퓨터를 "보호"한다던 이 소프트웨어가 잠깐 자리 비우고 화면 잠금을 잊었을 때 누가 와서 뭔가 실행하기 훨씬 쉬운 상태로 만들었기 때문임
    • 이건 결국 restricted shell이 실제로는 얼마나 안 막히는지 보여주는 꽤 포괄적인 가이드처럼 보임
    • 구체적인 예도 있음
      몇 년 전 지원팀이 tcpdump로 네트워크 캡처를 해야 해서, 빨리 처리하려고 인자를 어느 정도 열어둔 sudo 규칙을 넣었음
      포트나 NIC가 바뀔 수 있으니 그땐 그게 자연스러워 보였지만, 사실 tcpdump의 -z 옵션으로 압축 명령을 지정할 수 있어서 거기에 "특별한" 명령을 넣으면 서버를 그대로 장악할 수 있음
      sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
      사소해 보이지만 이런 건 정말 놓치기 쉬움
      요즘은 apparmor 같은 계층이 이런 위험을 줄여주기도 하지만, 그만큼 다른 골칫거리도 생기고 여전히 잘못 설정하기 쉬움
    • 이걸 보고 있으니, AI가 샌드박스 우회법을 학습하도록 정리된 목록 같다는 생각도 듦

  • 마지막으로 이런 비슷한 걸 써본 건 1995년쯤 Windows 3.11이 깔린 중등학교 컴퓨터였음
    승인된 몇 개 앱만 실행되도록 막아놨는데 그중 하나가 Word였음
    Word에서는 매크로를 쓰고 shell로 다른 앱을 실행할 수 있었음
    그래서 몇 개 앱만 보이던 잠긴 컴퓨터가 사실상 뭐든 실행 가능한 상태가 됐음
    당시엔 꽤 짜릿했고, 그 이후로는 비슷한 일을 거의 못 봤음
    가끔 상점이나 쇼핑몰의 터치 정보 디스플레이에서 kiosk mode 탈출이 가능하다는 얘기를 보는데, 그것도 비슷한 부류 같음

  • restic - Shell, Command, Upload를 보니, 백업을 root로 돌리지 않게 손본 게 조금은 정당화되는 느낌임
    대신 일반 사용자로 실행하되 read-all-files capability만 주고 로그인 셸은 없앴음
    물론 데스크톱에서는 과할 수도 있고, 거기까지 뚫린 공격자라면 어차피 거의 모든 파일을 읽고 백업에 백도어를 심을 수도 있음
    [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

    • 제약을 보면 그냥 "그럼 우회용 헬퍼를 하나 써서 돌아가면 되지"라고 판단하는 LLM의 성향이, 예전 세계의 가정을 꽤 무너뜨리는 것 같음
      원격 인간 공격자, 원격 봇 공격자, 어느 정도는 로컬 인간 공격자까지는 대응법이 있지만, 로컬에서 스스로 코드를 쓰는 봇 공격자는 예전보다 훨씬 더 신경 써야 할 대상이 됐음
      이건 악성코드와도 카테고리가 완전히 같진 않음
      나도 컨테이너를 관련 경계로 보고 내부 프로세스를 전부 root로 돌리게 만든 적이 있는데, LLM이 끼면 OS 레벨 보안이 갑자기 더 중요해진 건지, 아니면 오히려 무의미해진 건지 판단이 잘 안 섬

  • 헷갈리는데, 이건 cat이 없을 때 cat /path/to/input-file 대신 base64 /path/to/input-file | base64 --decode를 쓰라는 뜻인가
    아니면 base64 /path/to/input-file | base64 --decode가 파일 읽기 권한 자체를 우회한다는 뜻인가

    • 전자 쪽이 맞음
      호출된 프로세스는 보통 그걸 실행한 사용자의 권한을 그대로 물려받고, setuid bit가 있을 때만 예외가 생김
      요지는 표준 Unix 도구를 꺼서 공격자의 lateral movement를 막으려는 환경에서, 다른 도구로 같은 일을 할 수 있다는 데 있음
    • 블랙리스트 기반 명령 제한으로 권한을 막는 방식은 원래부터 잘 안 통했고 지금도 마찬가지라는 뜻임
    • 후자가 아니라 전자임
      권한 자체를 뚫는 게 아니라, 몇 개 명령만 허용된 제한 셸에서 같은 결과를 다른 바이너리로 내는 이야기임
      이런 건 CTF에서 정말 흔함
    • 다만 읽을 수 없는 파일이 있고, 대신 root로 base64 실행이 가능하다면 이야기가 달라짐
      root 권한으로 base64를 돌려 파일 내용을 base64로 인코딩하고, 그 출력을 다른 base64 프로세스로 디코드하면 결국 파일 내용을 볼 수 있음
      결과적으로는 단계만 늘어난 cat과 같음
    • 그럴 거면 tar 파이프가 더 가볍지 않나 싶기도 함

  • 예전에 이런 도구 중 하나의 유지보수자였는데, 누가 그걸로 셸을 따는 걸 보니 웃기더라
    창의적이고 재밌고, 자료로서도 좋음

  • hackthebox.eu 할 때 이걸 아주 많이 써먹었음

  • GTFOBins는 나온 지 꽤 됐고, AI 이전부터 유용한 자료였음

    • 그래서 앞으로가 더 걱정됨
      AI가 유용한 이유 자체가 결국 이미 존재하는 이런 자료들을 끌어올 수 있기 때문임

  • base64가 목록에 있는 걸 보니 잘 이해가 안 됨
    내 생각엔 그건 사용자가 이미 접근 가능한 파일을 읽는 것밖엔 못 할 텐데, 내가 착각하는 건가
    아니면 오설정된 시스템의 로컬 보안 제한 우회라는 설명이 내가 이해한 뜻과 다른 건가

    • 핵심은, 잘못 설정된 제한 셸이나 명령 접근만 주어진 경우에도 저 목록의 도구로 그 사용자가 원래 비제한 환경에서 가졌을 접근 범위 일부를 되찾을 수 있다는 데 있음
      가장 단순한 예로 기본 셸을 rbash로 바꿔놨더라도 사용자가 그냥 bash를 실행해 일반 셸로 들어갈 수 있으면 의미가 사라짐
    • 예를 들어 sudoers가 base64를 root로 실행하도록 허용해뒀을 수도 있음
      왜 그렇게 했는지는 모르겠지만, 그런 상황이라면 의도된 권한 제한을 우회해 시스템의 어떤 파일이든 읽을 수 있게 됨
      또는 Claude Code에 base64 실행을 검토 없이 허용해두면 .env 같은 비밀 파일까지 읽게 열어주는 셈일 수도 있음
    • 흔한 상황은, 몇몇 도구가 root 권한으로 실행 가능하다는 것임
      sudo -l로 명시적으로 허용돼 있거나, 다른 무언가가 root로 그 도구를 호출하는 식이 많음

  • 이런 우회에 대한 완화 방법도 같이 보여주면 좋겠음
    예를 들어 more로 셸을 얻는 경우라면
    more 실행 전에 SHELL을 /bin/false로 설정하기
    secure mode의 less로 바꾸기
    sudo로 more를 쓴다면 NOEXEC flag 쓰기 같은 식임

    • 가장 좋은 완화책은 사용자가 읽거나 쓰면 안 되는 파일의 실제 권한을 제대로 설정하는 것임
      그 외 방식은 결국 운에 기대는 면이 큼

  • 꽤 멋지고, 예상 못 한 창의적인 접근도 보임
    예를 들어 yt-dlp 같은 건 생각도 못 했음
    그냥 깔아두는 걸 다시 생각해봐야겠음

답변달기