"/etc/hosts" 파일 작성으로 인한 Substack 에디터 오류 발생

 (scalewithlee.substack.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Substack 에디터에서 특정 시스템 경로를 입력할 때 네트워크 오류가 발생함
  • 웹 애플리케이션 방화벽(WAF) 가 이러한 경로를 차단하는 이유는 경로 탐색 공격 및 명령어 삽입 공격 방지 때문임
  • 보안과 사용성 사이의 균형이 중요한 문제로 부각됨
  • 기술 작가를 위한 더 나은 해결책이 필요함
  • 대체 경로를 사용하여 문제를 해결할 수 있음

/etc/h*sts가 Substack 에디터를 방해할 때: 웹 콘텐츠 필터링의 모험

신비로운 네트워크 오류

  • DNS 해상도에 대한 기술 포스트 작업 중 예상치 못한 오류 발생
  • /etc/h*sts 경로 입력 시 네트워크 오류 발생, 자동 저장 실패
  • Substack의 상태 페이지는 정상 작동 중임을 보여줌

조사 시작

  • 특정 파일 경로 입력 시 오류 발생, 경로 변형 시 정상 작동
  • /etc/h*sts와 같은 경로는 오류를 일으키고, 변형된 경로는 문제 없음

내부에서 무슨 일이 일어나고 있는가?

  • 브라우저 개발자 도구에서 403 Forbidden 응답 확인
  • Cloudflare가 관련되어 있음

웹 애플리케이션 보안 필터 이해하기

WAF 간단 설명

  • 웹 애플리케이션 방화벽(WAF) 는 웹사이트의 보안 경비원 역할
  • 의심스러운 요청을 차단함

경로 탐색 공격: 주의 이유

  • 경로 탐색 공격은 민감한 시스템 파일에 접근하려는 시도
  • /etc/h*sts와 같은 경로는 공격 대상이 될 수 있음

명령어 삽입: 또 다른 보안 문제

  • 명령어 삽입 공격은 시스템 명령어 실행을 유도
  • 시스템 경로 언급 시 필터가 차단할 수 있음

신비가 깊어지다: 역사적 예

  • 다른 Substack 포스트에서 유사한 경로 사용 사례 발견
  • 필터링 동작이 특정 시점에 변경되었을 가능성

보안 대 사용성: 미묘한 균형

  • Substack의 필터는 보호를 위한 것이지만, 기술 작가에게는 장애물이 됨
  • 개선의 여지가 있음: 명확한 오류 메시지, 기술적 내용 인식, 문서화된 해결책 제공

HTTP 응답 살펴보기

  • API 수준에서 403 Forbidden 상태 코드 확인

기술 콘텐츠 플랫폼을 위한 더 나은 해결책

  1. 맥락적 필터링: 코드 블록이나 기술 토론에서 시스템 경로 인식
  2. 명확한 오류 메시지: "네트워크 오류" 대신 보안 필터로 인한 차단 설명
  3. 문서화된 해결책: 민감한 경로 논의 방법 제공

결론: 보안과 기술 작문의 교차점

  • Substack 에디터의 문제는 보안과 기술 작문의 복잡한 도전 과제를 드러냄

  • 보안 필터에 의해 공격 패턴으로 보일 수 있는 것이 실제로는 합법적인 콘텐츠일 수 있음

  • 대체 경로를 사용하여 문제 해결 가능

  • 유사한 필터링 문제를 다른 플랫폼에서 겪은 경험이 있는지 댓글로 공유 요청

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • CDN에서 WAF 규칙을 설정하는 사람들이 기술 콘텐츠를 다루는 사이트와 서비스를 제대로 이해하지 못하는 경우가 많음. Cloudflare만의 문제가 아니라 Akamai도 비슷함
    데이터베이스를 논의하는 사이트에서 기본 SQL 인젝션 방지 규칙을 켜면 사이트가 깨지고, 파일 포함 규칙셋은 /etc/hosts, /etc/passwd 같은 문자열을 차단함
    보안과 사용성 사이의 균형이라는 면도 있긴 함. 어떤 서비스가 취약하게 구현됐는지 알 수 없으니 모든 WAF 규칙을 얹으면 더 안전해지는 측면은 있음. 다만 안전하게 구현된 서비스가 기술 개념을 논의해야 할 때 같은 규칙셋이 매우 성가셔짐
    규칙을 세밀하게 조정하는 데 시간이 많이 듦. 쿼리 매개변수에 /etc/hosts가 있어서 페이지가 안 뜨는 걸 고치면, 이제 참조자에 /etc/hosts가 들어가서 XHR 리소스가 안 뜨고, 그다음엔 분석용 JS 라이브러리가 방문 URL을 쿠키에 넣어서 또 깨지는 식이라 그냥 규칙을 꺼버리고 싶어짐

    • 보안과 사용성뿐 아니라 경제성도 있음. 겉보기엔 멍청한 보안 정책이 보험사 요구 때문에 생기는 경우가 많음
      보험사가 “직원 비밀번호를 90일마다 바꾸게 하지 않으면 보험료를 20% 올리겠다”고 하면, NIST가 10년도 더 전에 정기 비밀번호 변경을 권장하지 않도록 바꿨고 그게 나쁜 관행이라고 아무리 맞는 말을 해도 보험료는 오름
      그래서 한숨 쉬며 비밀번호 만료 정책을 구현하고, 무능하다고 불평하는 직원들의 말을 듣게 됨. log4shell이 워낙 유명해졌으니 이제 보험사들이 /etc/hosts, /etc/passwd, jndi: 같은 흔한 “해킹 문자열”을 서버가 거부해야 한다고 요구해도 놀랍지 않음
    • “혹시 모르니까”는 최악의 보안 방식이고, 전체 시스템을 오히려 덜 안전하게 만듦. 안전을 위해 비밀번호를 매달 바꾸고, 20자의 영숫자와 기호 5개를 요구하고, 수백 페이지짜리 체크리스트가 딸린 온갖 3글자 컴플라이언스를 통과해야 하며, 체크리스트에 있으니 서버에 WAF도 켜야 하는 식임
      CIO에게 이게 실제로 어떤 위협을 막는지 물으면 멍한 표정만 돌아옴
      엔지니어 입장에선 각 입력 폼이 어디로 가는지 이해하고 의미 있는 방식으로 정화하는 데 힘쓸 유인이 없음. 돈 받는 일은 체크박스를 채우고 넘어가는 것이고, 신입도 금방 그걸 배움. 이런 조직은 보안을 개선하는 게 아니라 침해 사고가 난 뒤 책임을 피하는 데 집중함
    • 이건 필터를 너무 순진하고 공격적으로, 게다가 엉뚱한 콘텐츠에 적용한 Scunthorpe 문제의 변형처럼 보임
      서버로 오가거나 서버들 사이에서 전달되는 “다른 것들”에 필터를 적용하는 건 말이 될 수 있지만, 블로그 콘텐츠로 표시될 실제 텍스트 본문을 필터링해 얻는 보안 이점은 없어 보임. 꽤 명확한 버그에 가깝다고 봄
      https://en.wikipedia.org/wiki/Scunthorpe_problem
    • CDN 레벨에서 입력 필드의 SQL 인젝션 필터링을 왜 하는지 이해가 안 됨. 길이나 간단한 타입 검증, 예컨대 숫자나 날짜 정도를 제외하면 입력 필드 검증을 CDN에서 할 이유가 없음
      백엔드는 입력 필드의 임의 바이트 내용을 처리할 수 있어야 하고, CDN 계층의 사전 필터링이 없다고 해서 SQL 인젝션에 취약해서는 안 됨
    • 요청한 리소스의 콘텐츠 어디에든 문자열 "/etc/hosts"가 그대로 들어갔다고 트리거되는 WAF라면, 꽤 명백하게 망가진 것 같음

  • 한 전자상거래 플랫폼 일화가 떠오름. 누군가 메모리 누수가 있는 웹숍을 만들었고, 우회책으로 로그에 "OutOfMemoryException" 문자열이 나타나면 앱을 재시작하게 해둠
    그러다 다른 개발자가 고객 검색어를 로그로 남기고 싶어 했고, 누군가 검색창에 "OutOfMemoryException"을 입력하면…

    • 자유 형식 텍스트 로그를 부주의하게 분석하는 건 과소평가된 시스템 악용 경로임. 대역 외 이스케이프나 정화 없이 데이터를 무작정 로그에 남기는 소프트웨어가 많아서 무서움
    • 실제로 WAF 때문에 이런 일을 몇 번 겪음. 사용자가 "system(...)" 문자열이 들어간 메모를 남겼는데 WAF가 PHP 인젝션으로 판단해서 IP 차단을 걸었음

  • /etc//hosts나 /etc/./hosts도 막는지 궁금함. 이런 식의 두더지 잡기는 실패할 수밖에 없음
    이런 걸 만든 사람들은 공격자가 자기들보다 더 똑똑하고 집요하다는 걸 알아야 하고, 검증된 보안 방식, 예컨대 신뢰할 수 없는 입력을 실행하지 않는 것에만 의존해야 함

    • 맞음. 이런 건 Fortune 500에서 흔한 필수 체크박스처럼 보임. 웹 애플리케이션 방화벽은 꼭 있어야 하고, 규칙이 뭔지는 중요하지 않으며 몇 개만 있으면 됨
      한 번은 SQL 데이터베이스를 쓰지 않는 애플리케이션에 SQL 인젝션 공격을 막기 위해 WAF가 필요하다는 말을 들은 적도 있음
      반박하면 늘 “다층 방어” 강의를 듣게 되고, 매주 목요일 아침 책상을 한 번 두드리고 제자리에서 세 바퀴 도는 게 더 효과적이라고 말하면 정말 미친 사람 보듯 함. 매주 그렇게 했고 해킹당한 적 없으니, 다층 방어 아닌가. 해가 될 건 없잖음
    • 나쁜 것 열거하기는 지는 전략임. 1995년에 첫 직장을 시작하고 5분쯤 지나서 이미 나쁜 아이디어라는 걸 알았음
    • 방금 Substack에 계정을 만들어 테스트해봤는데 이미 문제를 고쳤거나 WAF를 완전히 꺼둔 듯함
    • 그게 왜 어려운지 모르겠음. 문자열의 절대 경로를 얻는 기능은 거의 모든 언어 표준 라이브러리에 있음. 슬래시가 들어간 문자열을 찾아 해석해보면 됨
      와일드카드 해석은 더 까다롭지만 금지 파일 목록이 있으면 충분히 가능함
      https://nodejs.org/api/path.html#pathresolvepaths
      수정: C의 realpath는 동작이 약간 달라 링크를 바꿈
    • 전담 공격자를 막지 못하면 보안 솔루션은 가치가 없는 걸까? 많은 WAF 규칙은 기성 취약점 스캐너의 탐색 요청을 막는 데 쓰임

  • 기술 작가를 위해 Substack이 이 상황을 어떻게 개선할 수 있냐고?
    어떤 주제든, 심지어 멍청한 WAF를 트리거할 문자열까지 다룰 수 있는 글 편집 엔드포인트에 돌멩이만큼 멍청한 웹 애플리케이션 방화벽을 붙이지 않으면 됨
    웹 개발 포럼이 XSS 필터를 붙여서 회원들이 XSS에 대해 말하지 못하게 만드는 것과 같음. 콘텐츠를 제대로 이스케이프하는 법을 배워야 함

    • 보안 인증을 통과하려면 WAF를 돌려야 하는 입장임. 오픈소스 WAF는 modsecurity와 베타 후속인 coraza 정도뿐임
      이들은 멍청하고, OWASP의 coreruleset이라는 읽기 힘든 쓰레기 더미를 사용할 뿐임
    • 사이버보안 담당자를 고용해야 함. 없는 것 같음

  • 이 사례가 웹 보안에서 보호와 사용성 사이의 흥미로운 긴장을 보여준다는 말에는 동의하기 어려움. 이건 그냥 버그이고, 그것도 멍청한 버그임. 더 잘 알아야 할 사람들이 모른다는 걸 보여줄 뿐임
    보안과 사용성 사이의 긴장은 실제로 있지만, 이건 그게 아님. 보통은 좋은 보안을 구현해 사용자를 불편하게 만드는 식의 절충임. 2단계 인증, 3번 실패 후 잠금, DoS 방지를 위한 속도 제한처럼 보안을 높이면 사용자 경험이 나빠지고, 사용자 경험을 높이면 보안이 낮아지는 관계임
    이건 둘 다 아님. 나쁜 보안이면서 나쁜 사용자 경험임. 어디에 긴장이 있다는 건지 모르겠음

    • 일반적으로 모든 엔드포인트에 WAF를 일괄 적용한 뒤 이런 문제가 생길 때 선택적으로 제거하는 건 유용한 보안 관행이라고 봄. 특히 플러그인이 붙은 Wordpress 같은 제3자 소프트웨어를 호스팅할 때 모든 공개 엔드포인트를 하나하나 평가하는 건 훨씬 더 어려움
    • PHP 3 시절이 떠오름. PHP가 SQL 인젝션을 일괄적으로 막겠다며 URL 요청 내용을 “정화”하곤 했던 것 같고, 아니면 공유 호스팅에서 자주 켜던 설정이었을 수도 있음
      물론 PHP 사이트 작성자들은 금방 이를 알아냈고 여러 우회 기법이 쓰였으며, 전체적으로는 그런 “정화”가 없었을 때보다 더 나쁜 결과를 낳았을 가능성이 큼

  • 예전에 한 번 당한 뒤, “네트워크 오류”라는 말을 보자마자 원인이 바로 떠올랐음
    경쟁 프로그래밍 팀을 가르칠 때 반 학생의 절반이 풀이를 제출하면 빈 페이지를 받았고, 한 시간 디버깅 끝에 코드에 나타나면 403을 일으키는 몇 가지 C++ 타입과 키워드로 좁혔는데 모두 JavaScript에서도 의미가 있는 것들이었음
    은행에서 일할 때도 Python 파일을 제출해야 하는 API가 있었는데, 대부분의 Python 파일은 403이 나고 짧은 파일은 통과했음. 몇 시간 디버깅 끝에 코드에 가끔 등장하는 키워드 하나로 좁혔음
    몇 달 뒤 새 클라우드 환경에서도 같은 일이 있었고 또 몇 시간을 태움. 두 번째 이후 동료가 배포 스크립트에 403을 받으면 "HAHAHA YOU'VE BEEN WAFFED"를 출력하게 해줬고, 예상보다 훨씬 자주 그 오류를 봐서 지금도 고마움

    • 그게 Cloudflare였는지, 아니면 다른 WAF였는지 기억나는지 궁금함

  • 우리 애플리케이션에서도 비슷한 일을 겪음. 내부 레드팀이 XSS와 다른 인젝션 공격 시도가 들어간 데이터를 게시하고 있었음
    공격 자체는 성공하지 않았지만, 그 항목들이 존재한다는 이유로 회사 방화벽이 해당 페이로드가 포함된 네트워크 요청을 막아 내부 관리자 페이지가 로드되지 않았음. 결국 실패한 XSS 공격이 효과적인 DoS 공격이 되어버림

  • 오래된 것이 다시 새로워진 셈임. 예전엔 이런 걸 Scunthorpe 문제라고 불렀음
    https://en.m.wikipedia.org/wiki/Scunthorpe_problem

    • 예전 Eve Online 포럼에서 cockpit이라는 단어가 항상 c***pit으로 바뀌던 게 기억남. 꽤 웃겼음
    • 최근 미국 정부 웹사이트에서 “diversity”, “equity”, “inclusion” 같은 단어를 지운 일도 떠오름
      생물학, 금융, 지질학에 대해 쓰고 있으면? 그냥 운이 없는 것임
      똑똑하고 선의가 있는 사람이 써도 멍청한 필터링은 충분히 나쁨
    • 이제 이 Substack 사례를 위키백과 문서에 추가할 때가 됨

  • 어젯밤 OpenRouter에서도 비슷한 문제를 만났음. OpenRouter는 여러 LLM을 하나의 엔드포인트에서 쓸 수 있게 해주는 “교환기”식 서비스라 훌륭한데, 어젯밤 원시 HTML을 여러 방식으로 처리하는 데 어떤 모델이 좋은지 시험해보기 시작했음
    그런데 OpenRouter API가 Cloudflare로 보호되고 있어서, POST 요청 본문에 특정 원시 HTML과 JavaScript 조각이 들어가면 모든 요청은 아니지만 많은 요청이 차단됨. 같은 프롬프트를 OpenAI나 Anthropic에 직접 보내면 문제없음
    무료 모델이라면 악용 방지를 강하게 거는 걸 이해하겠지만, 이건 상용 모델로 과금되는 요청이라 더 거슬림

    • 신고했는지 궁금함

  • 예전에 이 문제를 겪었고 엄청 답답했음. "Network error" 때문에 몇 달 동안 작성해둔 글을 업데이트하지 못했는데, 편집으로 글이 길어져서 그런 줄 알고 원인을 못 찾았음
    지원팀에 연락하는 것도 AI 챗봇 때문에 어려웠고, 겨우 사람에게 닿았을 때도 그들의 “기술 지원”은 합리적인 시간 안에 들여다볼 생각이 없어 보였음
    Twitter의 어떤 사람이 멍청한 보안 로직을 건드리는 마법 문자열 가능성을 제안하고 나서야 문제를 찾았고, 마침내 글을 수정할 수 있었음

답변달기