El editor de Substack falla al escribir el archivo "/etc/hosts"

• En el editor de Substack se produce un error de red al ingresar ciertas rutas del sistema
• La WAF (firewall de aplicaciones web) bloquea estas rutas para prevenir ataques de path traversal y ataques de inyección de comandos
• Se destaca la importancia de equilibrar seguridad y usabilidad
• Hace falta una mejor solución para escritores técnicos
• Se puede resolver el problema usando una ruta alternativa

---

Cuando /etc/h*sts interfiere con el editor de Substack: la aventura del filtrado de contenido web

Un misterioso error de red

• Durante la redacción de una publicación técnica sobre resolución DNS, apareció un error inesperado
• Al escribir la ruta /etc/h*sts, se produce un error de red y falla el guardado automático
• La página de estado de Substack muestra que el servicio funciona con normalidad

Comienza la investigación

• El error aparece al escribir una ruta de archivo específica; si se modifica la ruta, funciona normalmente
• Rutas como /etc/h*sts provocan errores, mientras que variantes alteradas no causan problemas

¿Qué está pasando internamente?

• En las herramientas de desarrollo del navegador se confirma una respuesta 403 Forbidden
• Cloudflare está involucrado

Entendiendo los filtros de seguridad de aplicaciones web

Explicación breve de una WAF

• Un WAF (firewall de aplicaciones web) actúa como guardia de seguridad de un sitio web
• Bloquea solicitudes sospechosas

Ataques de path traversal: por qué preocupan

• Un ataque de path traversal intenta acceder a archivos sensibles del sistema
• Rutas como /etc/h*sts pueden convertirse en objetivo de ataque

Inyección de comandos: otro problema de seguridad

• Un ataque de inyección de comandos busca inducir la ejecución de comandos del sistema
• Al mencionar rutas del sistema, el filtro puede bloquear el contenido

El misterio se profundiza: ejemplos históricos

• Se encontraron casos similares de uso de rutas en otras publicaciones de Substack
• Es posible que el comportamiento del filtrado haya cambiado en algún momento específico

Seguridad vs. usabilidad: un equilibrio delicado

• Aunque el filtro de Substack busca proteger, se convierte en un obstáculo para los escritores técnicos
• Hay margen de mejora: mensajes de error claros, reconocimiento del contenido técnico y soluciones documentadas

Revisando la respuesta HTTP

• Se confirma el código de estado 403 Forbidden a nivel de API

Mejores soluciones para plataformas de contenido técnico

1. Filtrado contextual: reconocer rutas del sistema dentro de bloques de código o discusiones técnicas
2. Mensajes de error claros: explicar que el bloqueo proviene de un filtro de seguridad en vez de mostrar “error de red”
3. Soluciones documentadas: ofrecer una forma de discutir rutas sensibles

Conclusión: la intersección entre seguridad y escritura técnica

• El problema del editor de Substack revela los desafíos complejos entre la seguridad y la redacción técnica

• Lo que para un filtro de seguridad puede parecer un patrón de ataque en realidad puede ser contenido legítimo

• Es posible resolver el problema usando una ruta alternativa

• Se invita a compartir en los comentarios experiencias similares con problemas de filtrado en otras plataformas

[GN⁺]

Comentarios de Hacker News

• La gente que configura reglas de WAF en el CDN muchas veces no entiende bien los sitios y servicios que tratan contenido técnico. No es solo problema de Cloudflare; Akamai también es parecido
  Si activas reglas básicas de prevención de inyección SQL en un sitio donde se habla de bases de datos, el sitio se rompe, y los conjuntos de reglas de inclusión de archivos bloquean cadenas como /etc/hosts, /etc/passwd
  También está el tema del equilibrio entre seguridad y usabilidad. Como no puedes saber qué servicio fue implementado de forma vulnerable, poner todas las reglas del WAF encima sí puede dar una sensación de mayor seguridad. Pero cuando un servicio bien implementado necesita hablar de conceptos técnicos, ese mismo conjunto de reglas se vuelve muy molesto
  Ajustar las reglas con precisión toma muchísimo tiempo. Arreglas que la página no cargue porque el parámetro de consulta contiene /etc/hosts, y luego resulta que ahora los recursos XHR no cargan porque /etc/hosts viene en el referrer, y después se vuelve a romper porque una librería de JS de analítica mete la URL visitada en una cookie, así que dan ganas de simplemente apagar la regla

  • No solo están la seguridad y la usabilidad; también está la economía. Muchas políticas de seguridad que parecen tontas existen por requisitos de las aseguradoras
    Si la aseguradora dice “si no hacen que los empleados cambien su contraseña cada 90 días, les subimos la prima 20%”, entonces da igual que NIST haya dejado de recomendar los cambios periódicos de contraseña hace más de 10 años y que eso sea una mala práctica: la prima igual sube
    Entonces uno suspira, implementa la política de expiración de contraseñas y escucha a los empleados quejarse de que eso es incompetencia. Como log4shell se volvió tan famoso, ya no sorprendería que las aseguradoras ahora exijan que el servidor rechace cadenas comunes de “hackeo” como /etc/hosts, /etc/passwd, jndi:
  • “Por si acaso” es la peor forma de hacer seguridad, y de hecho vuelve menos seguro a todo el sistema. Por seguridad, haces que cambien la contraseña cada mes, exiges 20 caracteres alfanuméricos y 5 símbolos, tienes que pasar toda clase de compliance de tres letras con checklists de cientos de páginas, y como sale en la lista, también hay que activar un WAF en el servidor
    Si le preguntas al CIO qué amenaza real detiene eso, lo único que recibes es una mirada en blanco
    Desde el punto de vista de ingeniería, no hay incentivo para entender a dónde va cada formulario de entrada y sanitizarlo de forma significativa. El trabajo que paga es marcar casillas y seguir, y hasta los recién llegados lo aprenden rápido. Ese tipo de organizaciones no se enfoca en mejorar la seguridad, sino en evitar la culpa después de un incidente
  • Esto parece una variante del problema de Scunthorpe, donde el filtro se aplicó de forma demasiado ingenua, agresiva y además sobre el contenido equivocado
    Puede tener sentido aplicar filtros a “otras cosas” que entran o salen del servidor, o que se transmiten entre servidores, pero no parece haber ningún beneficio de seguridad en filtrar el texto real del cuerpo que se va a mostrar como contenido de blog. Se parece bastante a un bug muy claro
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • No entiendo por qué harías filtrado de inyección SQL de campos de entrada a nivel CDN. Salvo validaciones de longitud o de tipo muy simples, como números o fechas, no hay razón para validar campos de entrada en el CDN
    El backend debería poder manejar contenido arbitrario de bytes en los campos de entrada, y no debería ser vulnerable a inyección SQL solo porque no hubo filtrado previo en la capa del CDN
  • Si es un WAF que se activa porque la cadena "/etc/hosts" aparece tal cual en cualquier parte del contenido del recurso solicitado, entonces parece bastante claramente roto

• Esto me recordó una anécdota de una plataforma de comercio electrónico. Alguien hizo una tienda web con fuga de memoria y, como parche, configuró que la app se reiniciara cuando en el log apareciera la cadena "OutOfMemoryException"
  Luego otro desarrollador quiso registrar en el log los términos de búsqueda de los clientes, y cuando alguien escribió "OutOfMemoryException" en el buscador…

  • Analizar sin cuidado logs de texto libre es una vía de abuso del sistema subestimada. Da miedo la cantidad de software que mete datos al log sin más, sin escape fuera de banda ni sanitización
  • De hecho me ha pasado varias veces por culpa de un WAF. Un usuario dejó una nota que contenía la cadena "system(...)" y el WAF la interpretó como inyección PHP, así que bloqueó la IP

• Me pregunto si también bloquea /etc//hosts o /etc/./hosts. Este tipo de juego de golpear topos está condenado al fracaso
  Quienes construyen estas cosas deberían entender que el atacante es más inteligente y más persistente que ellos, y que solo deberían confiar en métodos de seguridad probados, por ejemplo no ejecutar entradas no confiables

  • Sí. Esto parece una casilla obligatoria muy común en empresas Fortune 500. Tiene que haber un firewall de aplicaciones web, no importa cuáles sean las reglas, con que haya algunas basta
    Una vez incluso me dijeron que hacía falta un WAF para detener ataques de inyección SQL en una aplicación que no usa una base de datos SQL
    Si respondes, siempre te dan la charla de “defensa en profundidad”, y si dices que sería más efectivo golpear el escritorio una vez cada jueves por la mañana y dar tres vueltas en tu lugar, te miran como si estuvieras loco. Como lo hice todas las semanas y nunca me hackearon, entonces también es defensa en profundidad. No hace daño, ¿no?
  • Enumerar cosas malas es una estrategia perdedora. Como a los 5 minutos de empezar mi primer trabajo en 1995 ya sabía que era una mala idea
  • Acabo de crear una cuenta en Substack para probarlo, y parece que ya arreglaron el problema o apagaron el WAF por completo
  • No entiendo por qué sería difícil. Casi todas las bibliotecas estándar de los lenguajes tienen una función para obtener la ruta absoluta de una cadena. Bastaría con buscar cadenas que tengan slashes e intentar resolverlas
    Interpretar comodines es más complicado, pero si tienes una lista de archivos prohibidos, sigue siendo perfectamente posible
    https://nodejs.org/api/path.html#pathresolvepaths
    Edit: realpath de C funciona un poco distinto, así que cambié el enlace
  • ¿Una solución de seguridad no vale si no puede detener a un atacante dedicado? Muchas reglas de WAF se usan para bloquear solicitudes de reconocimiento de escáneres de vulnerabilidades ya existentes

• ¿Cómo podría Substack mejorar esta situación para los escritores técnicos?
  Fácil: no poniéndole un firewall de aplicaciones web tan tonto como una piedra a un endpoint de edición que tiene que poder manejar cualquier tema, incluso cadenas que activen un WAF tonto
  Es como si un foro de desarrollo web pusiera un filtro XSS para que sus miembros no pudieran hablar sobre XSS. Deberían aprender a escapar correctamente el contenido

  • Para pasar certificaciones de seguridad, están en una posición donde tienen que usar un WAF. Entre los WAF de código abierto, prácticamente solo están modsecurity y su sucesor en beta, coraza
    Son tontos y básicamente solo usan ese montón ilegible de basura de OWASP llamado coreruleset
  • Necesitan contratar a alguien de ciberseguridad. Parece que no lo tienen

• Me cuesta estar de acuerdo con la idea de que este caso muestra una tensión interesante entre protección y usabilidad en seguridad web. Esto solo es un bug, y además un bug tonto. Lo único que demuestra es que gente que debería saber más no sabe
  La tensión entre seguridad y usabilidad sí existe, pero esto no es eso. Normalmente se trata de compromisos donde implementas buena seguridad y haces más incómoda la vida del usuario. Autenticación en dos pasos, bloqueo tras 3 intentos fallidos, limitación de velocidad para prevenir DoS: al subir la seguridad, empeora la experiencia de usuario; al mejorar la experiencia, baja la seguridad
  Esto no es ninguna de las dos. Es mala seguridad y mala experiencia de usuario. No veo dónde estaría la tensión

  • En general, creo que aplicar un WAF de forma global a todos los endpoints y luego quitarlo selectivamente cuando aparecen problemas como este sí es una práctica de seguridad útil. Sobre todo cuando hospedas software de terceros como Wordpress con plugins, evaluar uno por uno todos los endpoints públicos es mucho más difícil
  • Me recuerda a la era de PHP 3. Creo que PHP intentaba bloquear de forma global la inyección SQL “saneando” el contenido de las solicitudes URL, o quizá era una configuración que se activaba mucho en hosting compartido
    Claro, quienes escribían sitios en PHP pronto se dieron cuenta, aparecieron varias técnicas para saltárselo y, en conjunto, probablemente produjo peores resultados que no tener ese tipo de “saneamiento”

• Después de haber sufrido esto una vez, en cuanto vi “network error” ya se me vino a la cabeza la causa
  Cuando enseñaba a un equipo de programación competitiva, la mitad de la clase recibía una página en blanco al enviar sus soluciones, y tras una hora depurando lo reduje a unos cuantos tipos y palabras clave de C++ que provocaban un 403 si aparecían en el código; todas también tenían significado en JavaScript
  Cuando trabajaba en un banco, también había una API a la que tenías que subir archivos Python, pero la mayoría devolvía 403 y los archivos cortos sí pasaban. Tras varias horas de depuración, lo reduje a una sola palabra clave que a veces aparecía en el código
  Unos meses después volvió a pasar en un entorno nuevo en la nube y otra vez perdí varias horas. Después de la segunda vez, un compañero hizo que el script de despliegue mostrara "HAHAHA YOU'VE BEEN WAFFED" cuando recibía un 403, y hasta hoy se lo agradezco porque vi ese error muchísimo más seguido de lo esperado

  • Me pregunto si recuerdas si era Cloudflare o algún otro WAF

• En nuestra aplicación también vivimos algo parecido. El red team interno estaba publicando datos que incluían intentos de XSS y otros ataques de inyección
  El ataque en sí no tuvo éxito, pero el simple hecho de que esas entradas existieran hizo que el firewall de la empresa bloqueara las solicitudes de red que incluían ese payload, así que la página interna de administración no cargaba. Al final, un ataque XSS fallido terminó convirtiéndose en un ataque DoS efectivo

• Lo viejo vuelve a ser nuevo. Antes a esto se le llamaba el problema de Scunthorpe
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Me acuerdo de que en los viejos foros de Eve Online la palabra cockpit siempre se convertía en c***pit. Era bastante gracioso
  • También me hace pensar en cuando recientemente borraron palabras como “diversity”, “equity” e “inclusion” de sitios web del gobierno de EE. UU.
    ¿Estás escribiendo sobre biología, finanzas o geología? Pues mala suerte
    Incluso cuando lo hace alguien inteligente y con buenas intenciones, el filtrado tonto sigue siendo bastante malo
  • Ya es hora de agregar este caso de Substack al artículo de Wikipedia

• Anoche me topé con un problema parecido también en OpenRouter. OpenRouter es un excelente servicio tipo “switchboard” que te deja usar varios LLM desde un solo endpoint, y anoche empecé a probar qué modelos eran buenos para procesar HTML crudo de distintas maneras
  Pero la API de OpenRouter está protegida por Cloudflare, así que si en el cuerpo del POST metes ciertos fragmentos de HTML y JavaScript en crudo, no se bloquean todas las solicitudes, pero sí muchas. Si mandas el mismo prompt directamente a OpenAI o Anthropic, no hay problema
  Entendería poner protecciones fuertes contra abuso en modelos gratuitos, pero esto molesta más porque son solicitudes cobradas sobre modelos comerciales

  • Me pregunto si lo reportaste

• Ya había pasado por esto antes y fue desesperante. Por culpa de "Network error" no pude actualizar durante meses un artículo que había escrito, porque creía que el problema era que las ediciones lo estaban haciendo demasiado largo y no lograba encontrar la causa
  Incluso contactar al soporte fue difícil por el chatbot de IA, y cuando por fin logré llegar a una persona, su “soporte técnico” no parecía tener intención de revisarlo en un plazo razonable
  Solo encontré el problema cuando alguien en Twitter sugirió la posibilidad de una cadena mágica que estuviera activando una lógica de seguridad tonta, y por fin pude editar el artículo