Erro no editor do Substack causado pela escrita do arquivo "/etc/hosts"

• No editor do Substack, ocorre um erro de rede ao inserir determinados caminhos do sistema
• O firewall de aplicação web (WAF) bloqueia esses caminhos para evitar ataques de path traversal e injeção de comandos
• O equilíbrio entre segurança e usabilidade surge como uma questão importante
• É necessária uma solução melhor para redatores técnicos
• É possível contornar o problema usando um caminho alternativo

---

Quando /etc/h*sts atrapalha o editor do Substack: a aventura da filtragem de conteúdo na web

Um misterioso erro de rede

• Durante a produção de um post técnico sobre resolução de DNS, ocorreu um erro inesperado
• Ao digitar o caminho /etc/h*sts, surgia um erro de rede e o salvamento automático falhava
• A página de status do Substack mostrava que tudo estava funcionando normalmente

O início da investigação

• O erro ocorria ao inserir um caminho de arquivo específico, mas versões alteradas do caminho funcionavam normalmente
• Caminhos como /etc/h*sts causavam erro, enquanto versões modificadas não apresentavam problema

O que está acontecendo por trás?

• Nas ferramentas de desenvolvedor do navegador, foi confirmada uma resposta 403 Forbidden
• O Cloudflare estava envolvido

Entendendo os filtros de segurança de aplicações web

Explicação rápida sobre WAF

• Um firewall de aplicação web (WAF) atua como um segurança do site
• Ele bloqueia requisições suspeitas

Ataques de path traversal: por que são preocupantes

• Um ataque de path traversal é uma tentativa de acessar arquivos sensíveis do sistema
• Caminhos como /etc/h*sts podem ser alvos desse tipo de ataque

Injeção de comandos: outro problema de segurança

• Um ataque de injeção de comandos tenta induzir a execução de comandos no sistema
• Ao mencionar caminhos do sistema, o filtro pode bloquear o conteúdo

O mistério se aprofunda: exemplos históricos

• Foram encontrados, em outros posts do Substack, casos de uso de caminhos semelhantes
• É possível que o comportamento de filtragem tenha mudado em algum momento específico

Segurança versus usabilidade: um equilíbrio delicado

• O filtro do Substack existe para proteger, mas se torna um obstáculo para redatores técnicos
• Há espaço para melhorias: mensagens de erro claras, reconhecimento de conteúdo técnico e soluções documentadas

Observando a resposta HTTP

• No nível da API, foi confirmado o código de status 403 Forbidden

Soluções melhores para plataformas de conteúdo técnico

1. Filtragem contextual: reconhecer caminhos do sistema em blocos de código ou discussões técnicas
2. Mensagens de erro claras: explicar que o bloqueio veio do filtro de segurança, em vez de mostrar apenas "erro de rede"
3. Soluções documentadas: oferecer orientações sobre como discutir caminhos sensíveis

Conclusão: o ponto de encontro entre segurança e escrita técnica

• O problema no editor do Substack revela os desafios complexos entre segurança e escrita técnica

• Algo que pode parecer um padrão de ataque para o filtro de segurança pode, na verdade, ser conteúdo legítimo

• É possível resolver o problema usando um caminho alternativo

• O autor pede, nos comentários, que outros compartilhem experiências com problemas semelhantes de filtragem em outras plataformas

[GN⁺]

Opiniões no Hacker News

• Muitas vezes, as pessoas que configuram regras de WAF em CDNs não entendem direito sites e serviços que lidam com conteúdo técnico. Não é um problema só da Cloudflare; a Akamai é parecida
  Se você ativa regras básicas de prevenção contra SQL injection em um site que discute bancos de dados, o site quebra; e conjuntos de regras de inclusão de arquivos bloqueiam strings como /etc/hosts e /etc/passwd
  Também há o aspecto do equilíbrio entre segurança e usabilidade. Como não dá para saber qual serviço foi implementado de forma vulnerável, empilhar todas as regras de WAF torna tudo mais seguro em certo sentido. Mas, quando um serviço implementado com segurança precisa discutir conceitos técnicos, o mesmo conjunto de regras fica muito incômodo
  Ajustar regras de forma refinada toma muito tempo. Você corrige o caso em que a página não carrega porque há /etc/hosts em um parâmetro de query; aí um recurso XHR deixa de carregar porque o referer contém /etc/hosts; depois uma biblioteca JS de analytics coloca a URL visitada em um cookie e quebra de novo. Dá vontade simplesmente de desligar as regras

  • Além de segurança e usabilidade, há também a viabilidade econômica. Muitas políticas de segurança que parecem idiotas por fora surgem por exigência das seguradoras
    Se a seguradora diz: “se vocês não fizerem os funcionários trocarem a senha a cada 90 dias, vamos aumentar o prêmio em 20%”, por mais correto que seja dizer que o NIST mudou há mais de 10 anos para deixar de recomendar troca periódica de senhas e que isso é uma prática ruim, o prêmio sobe mesmo assim
    Então você suspira, implementa uma política de expiração de senhas e ouve funcionários reclamarem que você é incompetente. Como o log4shell ficou famoso demais, não seria surpreendente se agora seguradoras exigissem que servidores rejeitem “strings de hacking” comuns como /etc/hosts, /etc/passwd e jndi:
  • “Só por via das dúvidas” é a pior abordagem de segurança e acaba tornando o sistema como um todo menos seguro. É aquele caso de trocar a senha todo mês em nome da segurança, exigir 20 caracteres alfanuméricos e 5 símbolos, passar por todo tipo de compliance de três letras com checklists de centenas de páginas e, como está no checklist, também ativar um WAF no servidor
    Quando você pergunta ao CIO qual ameaça real isso bloqueia, só recebe um olhar vazio
    Do ponto de vista do engenheiro, não há incentivo para entender para onde cada formulário de entrada vai e sanitizá-lo de forma significativa. O trabalho pago é marcar a caixinha e seguir em frente, e até um recém-contratado aprende isso rápido. Organizações assim não se concentram em melhorar a segurança, mas em evitar responsabilidade depois de um incidente
  • Isto parece uma variação do problema de Scunthorpe, em que o filtro é ingênuo demais, agressivo demais e ainda aplicado ao conteúdo errado
    Pode fazer sentido aplicar filtros a “outras coisas” que entram e saem do servidor ou são transmitidas entre servidores, mas não vejo benefício de segurança em filtrar o corpo de texto real que será exibido como conteúdo de blog. Para mim, é algo bem próximo de um bug claro
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • Não entendo por que fazer filtragem de SQL injection em campos de entrada no nível da CDN. Exceto por validações simples de comprimento ou tipo, como números ou datas, não há motivo para validar campos de entrada na CDN
    O backend deve conseguir lidar com conteúdo arbitrário em bytes nos campos de entrada, e não deve ser vulnerável a SQL injection só porque não há pré-filtragem na camada da CDN
  • Se for um WAF acionado porque a string "/etc/hosts" aparece literalmente em qualquer parte do conteúdo do recurso solicitado, ele parece estar obviamente quebrado

• Isso me lembra uma história de uma plataforma de e-commerce. Alguém criou uma loja web com vazamento de memória e, como contorno, configurou a aplicação para reiniciar quando a string "OutOfMemoryException" aparecesse nos logs
  Então outro desenvolvedor quis registrar nos logs os termos de busca dos clientes, e quando alguém digitava "OutOfMemoryException" na caixa de busca…

  • Analisar logs de texto livre de forma descuidada é um vetor de abuso de sistema subestimado. Assusta a quantidade de software que simplesmente joga dados nos logs sem escape fora de banda nem sanitização
  • Já passei por isso algumas vezes por causa de WAF. Um usuário deixou uma nota contendo a string "system(...)", e o WAF interpretou como injeção de PHP e bloqueou o IP

• Fico curioso se /etc//hosts ou /etc/./hosts também são bloqueados. Esse tipo de jogo de whack-a-mole está fadado ao fracasso
  Quem cria isso precisa entender que atacantes são mais inteligentes e persistentes do que eles, e deve depender apenas de práticas de segurança comprovadas, como não executar entradas não confiáveis

  • Sim. Isso parece uma daquelas caixinhas obrigatórias comuns em Fortune 500. É preciso ter um firewall de aplicação web, não importa quais sejam as regras; basta haver algumas
    Uma vez me disseram que uma aplicação que nem usava banco de dados SQL precisava de um WAF para impedir ataques de SQL injection
    Quando você contesta, sempre recebe uma palestra sobre “defesa em profundidade”; e, se você disser que bater uma vez na mesa toda quinta-feira de manhã e dar três voltas no próprio eixo seria mais eficaz, eles olham para você como se você fosse realmente louco. Fiz isso toda semana e nunca fui hackeado, então não é defesa em profundidade? Não faz mal nenhum, certo?
  • Enumerar coisas ruins é uma estratégia perdedora. Cerca de 5 minutos depois de começar meu primeiro emprego, em 1995, eu já sabia que era uma má ideia
  • Acabei de criar uma conta no Substack para testar e parece que eles já corrigiram o problema ou desligaram completamente o WAF
  • Não entendo por que isso seria difícil. Quase todas as bibliotecas padrão de linguagens têm uma função para obter o caminho absoluto de uma string. É só procurar strings com barras e tentar interpretá-las
    A interpretação de wildcards é mais complicada, mas, se houver uma lista de arquivos proibidos, é perfeitamente viável
    https://nodejs.org/api/path.html#pathresolvepaths
    Edit: o realpath em C se comporta de forma um pouco diferente, seguindo links
  • Se uma solução de segurança não consegue impedir um atacante dedicado, ela não tem valor? Muitas regras de WAF são usadas para bloquear requisições de sondagem de scanners de vulnerabilidades prontos para uso

• Como o Substack poderia melhorar essa situação para autores técnicos?
  Bastaria não colocar um firewall de aplicação web burro como uma pedra no endpoint de edição de textos, que precisa permitir abordar qualquer assunto — até strings que acionem um WAF idiota.
  É como um fórum de desenvolvimento web colocar um filtro de XSS e impedir que os membros falem sobre XSS. Eles precisam aprender a escapar conteúdo corretamente.

  • Para passar por certificações de segurança, eles precisam rodar um WAF. Os WAFs open source basicamente se resumem ao modsecurity e ao sucessor beta coraza.
    Eles são burros e apenas usam aquele monte de lixo difícil de ler do OWASP chamado coreruleset.
  • Eles precisam contratar alguém de cibersegurança. Parece que não têm.

• É difícil concordar com a ideia de que este caso mostra uma tensão interessante entre proteção e usabilidade na segurança web. Isso é só um bug — e um bug idiota. Só mostra que pessoas que deveriam saber mais não sabem.
  A tensão entre segurança e usabilidade existe de fato, mas não é isso aqui. Em geral, é uma troca em que se implementa boa segurança e se incomoda o usuário: autenticação em dois fatores, bloqueio após 3 tentativas, limitação de taxa para evitar DoS. Ao aumentar a segurança, a experiência do usuário piora; ao melhorar a experiência, a segurança diminui.
  Isto não é nem uma coisa nem outra. É segurança ruim e experiência de usuário ruim. Não sei onde estaria a tensão.

  • Em geral, acho uma prática de segurança útil aplicar WAF indiscriminadamente a todos os endpoints e depois removê-lo seletivamente quando surgem problemas assim. Especialmente ao hospedar software de terceiros como Wordpress com plugins, é muito mais difícil avaliar um por um todos os endpoints públicos.
  • Isso me lembra a época do PHP 3. Acho que o PHP tentava impedir SQL injection de forma generalizada “sanitizando” o conteúdo de requisições de URL — ou talvez fosse uma configuração que hospedagens compartilhadas costumavam ativar.
    Claro que os autores de sites em PHP logo descobriram isso, várias técnicas de contorno passaram a ser usadas e, no geral, é bem provável que essa “sanitização” tenha produzido resultados piores do que se ela não existisse.

• Depois de passar por isso uma vez no passado, assim que vi “erro de rede” a causa me veio imediatamente à cabeça.
  Quando eu ensinava uma equipe de programação competitiva, metade dos alunos recebia uma página em branco ao enviar a solução e, após uma hora depurando, reduzimos o problema a alguns tipos e palavras-chave de C++ que causavam 403 quando apareciam no código — todos eles também tinham significado em JavaScript.
  Quando eu trabalhava em um banco, também havia uma API para a qual precisávamos enviar arquivos Python, mas a maioria dos arquivos Python dava 403 e arquivos curtos passavam. Depois de horas depurando, reduzimos o problema a uma palavra-chave que aparecia ocasionalmente no código.
  Alguns meses depois, a mesma coisa aconteceu em um novo ambiente de nuvem e lá se foram mais algumas horas. Depois da segunda vez, um colega fez o script de deploy imprimir "HAHAHA YOU'VE BEEN WAFFED" quando recebesse 403, e sou grato até hoje, porque vimos esse erro com muito mais frequência do que eu esperava.

  • Fico curioso se você lembra se era Cloudflare ou algum outro WAF.

• Passamos por algo parecido na nossa aplicação. A red team interna estava publicando dados que continham tentativas de XSS e outros ataques de injeção.
  Os ataques em si não tiveram sucesso, mas, só pelo fato de esses itens existirem, o firewall da empresa bloqueava as requisições de rede que continham aquele payload, e a página interna de administração não carregava. No fim, uma tentativa fracassada de XSS virou um ataque DoS eficaz.

• O velho voltou a ser novo. Antigamente chamavam isso de problema de Scunthorpe.
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Lembro que, nos antigos fóruns do Eve Online, a palavra cockpit sempre virava c***pit. Era bem engraçado.
  • Também me lembrei do episódio recente em que sites do governo dos EUA removeram palavras como “diversity”, “equity” e “inclusion”.
    E se você estiver escrevendo sobre biologia, finanças ou geologia? Azar o seu.
    Filtragem burra já é ruim o bastante mesmo quando escrita por pessoas inteligentes e bem-intencionadas.
  • Já está na hora de adicionar este caso do Substack ao artigo da Wikipédia.

• Ontem à noite encontrei um problema parecido também no OpenRouter. O OpenRouter é ótimo por ser um serviço no estilo “central de troca” que permite usar vários LLMs a partir de um único endpoint, e ontem à noite comecei a testar quais modelos eram bons para lidar com HTML bruto de várias maneiras.
  Só que a API do OpenRouter é protegida pelo Cloudflare, então, quando o corpo de uma requisição POST continha certos trechos de HTML bruto e JavaScript, muitas requisições eram bloqueadas — não todas, mas muitas. Enviar o mesmo prompt diretamente para a OpenAI ou a Anthropic não causava problema.
  Eu entenderia aplicar prevenção de abuso de forma mais agressiva em modelos gratuitos, mas isso incomoda mais porque eram requisições cobradas para modelos comerciais.

  • Fico curioso se você reportou isso.

• Já passei por esse problema antes e foi extremamente frustrante. Por causa de "Network error", não consegui atualizar um texto que vinha escrevendo havia meses, e não encontrei a causa porque achei que era por o artigo ter ficado mais longo com as edições.
  Entrar em contato com o suporte também foi difícil por causa do chatbot de IA e, quando finalmente consegui falar com uma pessoa, o “suporte técnico” deles não parecia disposto a investigar em um prazo razoável.
  Só depois que alguém no Twitter sugeriu a possibilidade de uma string mágica estar acionando uma lógica de segurança idiota é que encontrei o problema e, finalmente, consegui editar o texto.