GN⁺ 4시간전 | parent | ★ favorite | on: GTFOBins(gtfobins.org)
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를 실행해 일반 셸로 들어갈 수 있으면 의미가 사라짐
    • 예를 들어 sudoersbase64를 root로 실행하도록 허용해뒀을 수도 있음
      왜 그렇게 했는지는 모르겠지만, 그런 상황이라면 의도된 권한 제한을 우회해 시스템의 어떤 파일이든 읽을 수 있게 됨
      또는 Claude Codebase64 실행을 검토 없이 허용해두면 .env 같은 비밀 파일까지 읽게 열어주는 셈일 수도 있음
    • 흔한 상황은, 몇몇 도구가 root 권한으로 실행 가능하다는 것임
      sudo -l로 명시적으로 허용돼 있거나, 다른 무언가가 root로 그 도구를 호출하는 식이 많음
  • 이런 우회에 대한 완화 방법도 같이 보여주면 좋겠음
    예를 들어 more로 셸을 얻는 경우라면
    more 실행 전에 SHELL/bin/false로 설정하기
    secure modeless로 바꾸기
    sudomore를 쓴다면 NOEXEC flag 쓰기 같은 식임

    • 가장 좋은 완화책은 사용자가 읽거나 쓰면 안 되는 파일의 실제 권한을 제대로 설정하는 것임
      그 외 방식은 결국 운에 기대는 면이 큼
  • 꽤 멋지고, 예상 못 한 창의적인 접근도 보임
    예를 들어 yt-dlp 같은 건 생각도 못 했음
    그냥 깔아두는 걸 다시 생각해봐야겠음