Riesgos de usar HTTP cuando confío en la red local

Suponiendo que su red local sea segura, el script / chaval / pirata informático promedio con recursos mínimos no podrá conectarse a la conexión, incluso cuando use HTTP sin cifrar. Eso no significa que el uso simple de HTTP sea seguro. Sus datos aún podrían ser capturados y registrados o modificados libremente por:

• Su ISP y su propio gobierno
• ISP y gobiernos en los países a través de los cuales se enruta su tráfico
• Cualquier persona capaz de lanzar un ataque de secuestro de ruta BGP

Y, por supuesto, cualquiera de los anteriores podría compartir los datos con terceros de su elección, o incluso darles acceso directo a su tráfico de red.

Algunos ejemplos:

Se sabe que algunos ISP inyectan JavaScript en páginas HTML. Esto podría ser publicidad o seguimiento adicional, o notificaciones personalizadas como en el caso de Comcast recientemente.

Vivo en Finlandia, y gran parte del tráfico de Internet de Finlandia se enruta a través de Suecia. En 2009, Suecia aprobó una ley que permite a la agencia de inteligencia sueca FRA monitorear todas las conexiones de Internet que cruzan la frontera. Esto significa que Suecia es tanto técnica como legalmente capaz de usar la vigilancia masiva en usuarios de internet finlandeses. También se ha informado que FRA coopera estrechamente con NSA y GCHQ, y es probable que compartan datos.

En 2013, la compañía de software de vigilancia Hacking Team orquestó un secuestro de BGP en cooperación con el gobierno italiano y una empresa de alojamiento. Podrían utilizarse fácilmente secuestros de ruta similares para acceder a las conexiones HTTP desde cualquier parte del mundo. Secuestros BGP o "fugas" no son raros. La cuenta de Twitter @bgpmon , entre otras, rastrea e informa sobre este tipo de eventos. A menudo, los eventos se atribuyen a errores de configuración y errores humanos, pero en la mayoría de los casos no es posible saberlo con seguridad. Muy a menudo, los culpables son proveedores de servicios de Internet individuales en China o países similares, y no hay garantía de que los proveedores de servicios de Internet en sí no fueran el objetivo de un pirateo.

Además de la seguridad, hay otras razones para usar HTTPS. SPDY y HTTP / 2, que son nuevas versiones de HTTP con menos sobrecarga, solo son compatibles con TLS en la mayoría de las implementaciones. Muchas tecnologías web de JavaScript también están disponibles solo para sitios web HTTPS, por ejemplo, Trabajadores de servicios y la API de ubicación.

Además de los obstáculos tecnológicos para obtener un toque en las líneas intercontinentales que realmente podrían leer los datos, el escenario que proporcionó es realmente posible. Si usa HTTP en lugar de HTTPS, sus datos viajan como texto claro de un extremo a otro, por lo que su ISP, cualquiera entre ellos y el ISP de su host de destino pueden leer o incluso modificar sus datos si realmente lo desean.

El EFF tiene un widget agradable que detalla quién puede ver qué con HTTP / S: enlace

HTTP es un protocolo intrínsecamente "confiado": contiene poca o ninguna seguridad integrada. Esto significa que es susceptible a lo siguiente:

1. Supervisión del tráfico Cualquier persona que se conecte a cualquier red que se encuentre entre el dispositivo de origen y el servidor de destino puede interceptar y leer cualquier cosa transmitida a través de HTTP.
2. Redirección y manipulación del tráfico Con poco trabajo, su tráfico podría ser redirigido a un servidor controlado por un tercero sin que usted pueda notar nada. Una vez que el tráfico ha sido redirigido, se puede leer, pero también se puede cambiar: alguien podría inyectar cualquier tipo de datos, incluido el script, en la secuencia. A menos que tenga alguna forma externa de validar lo que obtuvo a través de la conexión HTTP, no hay forma de asegurarse de que provenga de la fuente "correcta".

También hay una variedad de ataques menos obvios que podrían realizarse si usas habitualmente HTTP en lugar de HTTPS (como Ataque de redireccionamiento de URL ).

Suponiendo que un atacante ya está dentro de su red inalámbrica, debe saber que incluso sus conexiones https pueden ser rastreadas utilizando técnicas como sslstrip . La buena práctica para evitar esta técnica es crear todos sus marcadores y accesos directos utilizando la cadena https:// al principio. Si intenta acceder directamente a una página que está en la barra, por ejemplo, https://outlook.com , la conexión no puede ser víctima de sslstrip. Si solo coloca, por ejemplo, outlook.com sin usar el prefijo https, puede ser pirateado incluso en una conexión ssl y sus datos pueden ser rastreados de manera simple si hay un hacker experto en su red.

  

¿Cómo funciona sslstrip?

Una gran cantidad de sitios web están utilizando HSTS (Http Scrict Transport Security) que consisten básicamente en redirigir una simple solicitud HTTP a Un https para ser asegurado. Por ejemplo, puede notar si ingresa a outlook.com que se realiza una redirección y verá el sitio con el candado verde y usando https. Esto se debe a que el HSTS está configurado y es muy recomendable colocarlo en los sitios web. Pero en este escenario, hay una solicitud a http ... esa primera solicitud es lo que sslstrip toma para hacer "su magia". El atacante que ha hecho un MITM (Man in the middle) primero, sirve a la víctima la página en http simple y hace la conexión https al servidor real. La víctima podría notar que no hay candado verde en la barra ... pero créanme, no lo notan, por lo que es muy efectivo.

Algunos sitios, como Facebook, no se pueden deslizar porque, desde hace un tiempo, los navegadores tienen una lista interna de algunos sitios que se sabe que usan https, por lo que no importa si le pregunta al navegador por http://facebook.com , el navegador. va a preguntar directamente a https://facebook.com , por lo que no hay una solicitud inicial de HTTP y sslstrip no puede funcionar. Pero no hay demasiados sitios en las listas de ese navegador ... Supongo que los sitios deberían pagar a los navegadores para que estén en esa lista, no estoy seguro de esto. Así que esto solo afecta a "grandes sitios" como Facebook y algunos otros que son conocidos mundialmente.

Entonces, si el hacker ya está en tu red, es cuestión de tiempo para que huela algo útil. Intente proteger su primer nivel primero (para proteger su red para que se rompa). Si no es posible y el pirata informático ya está en la red, use siempre https:// en sus marcadores y accesos directos ... hace la diferencia ... créame.

Aquí hay un video más explicativo sobre sslstrip

Mi respuesta favorita a esta pregunta de WAHH:

  

los espías pueden residir:

     

1. En la red local del usuario
  
2. Dentro del departamento de TI del usuario
  
3. Dentro del ISP del usuario
  
4. En la red troncal de Internet
  
5. Dentro del ISP que aloja la aplicación
  
6. Dentro del departamento de TI que gestiona la aplicación
  

Stuttard, Dafydd; Pinto, Marcus. "La aplicación web de hackers   Manual: Cómo encontrar y explotar fallas de seguridad "(p. 169). Wiley.   Edición Kindle.

En esta respuesta, voy a suponer que los socios con los que están asociados los socios con los que el OP o el objetivo de la comunicación tienen alguna relación comercial, están en ruta sin ninguna manipulación o son un gobierno de esa ubicación. Esto significa que, en el ejemplo del banco, las siguientes partes son completamente de confianza:

• La propia red de OP y todas las partes involucradas en eso, por ejemplo, su familia.
• El propietario del OP, que tiene acceso a las líneas de comunicación en el edificio.
• El ISP del OP y todos los ISP hasta, incluido el operador de la red troncal.
• Cualquier agencia gubernamental que opere en la ubicación del OP.
• El ISP de los Bancos y todos los ISP hasta, incluido el operador de la red troncal.
• El propietario de los Bancos, que puede o no tener acceso a las líneas de comunicación.
• La red propia de los Bancos y todas las partes involucradas en eso, por ejemplo, los administradores de TI.
• Cualquier agencia gubernamental que opera en la ubicación del Banco.
• Y, finalmente, cualquier agencia gubernamental que opere en cualquier país que esté en ruta hacia la ubicación de destino, considerando que no ha ocurrido ninguna alteración de los enrutadores en ruta a la ubicación de destino, incluso si lo solicitó ese gobierno.

En seguridad, también asumo que:

• Cualquier equipo propiedad de OP es seguro.
• Cualquier equipo propiedad del banco es seguro.
• Cualquier equipo propiedad del gobierno es seguro.

La razón por la que hago estas suposiciones es para aislar los casos en los que una escucha o modificación del tráfico representa un riesgo para la seguridad, en lugar de ser una molestia para el usuario. Si un gobierno intencionalmente busca el número de tarjeta de crédito de OP, no representa ningún riesgo para el OP, porque el número de tarjeta de crédito no le dará mayor acceso al gobierno, el gobierno podría con una sola llamada telefónica capturar todo el dinero de la cuenta de OP de todos modos Lo mismo con el ISP, el ISP que modifica el tráfico para insertar publicidad, no hará ningún uso de la contraseña de Facebook de los OP de todos modos.

Otra cosa importante es evaluar si una organización puede mantener su equipo a salvo de atacantes externos. Aquí, asumo que el OP está bien informado y puede configurar sus propios enrutadores y cortafuegos de forma segura, por lo que configuro el equipo de OP para asegurar. Esto significa que cualquier equipo propiedad del OP no puede ser comprometido de forma remota. El equipo de los bancos obviamente está configurado de forma segura. Y, por supuesto, los equipos de los gobiernos que se utilizan para almacenar datos ocultos o información similar están configurados de manera aún más segura que el banco.

Teniendo en cuenta esta evaluación de confianza, esto significa que hay pocos vectores de ataque para atacar HTTP a través de una red cableada.

Los únicos vectores de ataque que puedo ver son los siguientes:

• Escuchando el cableado de publicidad accesible. Un ejemplo sería escuchar las señales ADSL de un cableado de telefonía suspendido.

• Rompiendo y entrando a las salas de equipos locales. Por ejemplo, salas de equipos propiedad del ISP o del propietario. Las salas de equipos más grandes que dan servicio a un área más grande, normalmente tienen una protección de alarma severa, guardias cercanos si no están en el sitio y alta seguridad, pero las salas de equipos locales son a menudo de seguridad débil, a veces un gabinete de rack cerrado en un sótano con cables expuestos que pueden empalmarse y escucharse sin afectar la cerradura del gabinete del bastidor.

• Piratería remota en equipos locales. El equipo del propietario para propietarios más pequeños a menudo se configura de forma insegura con contraseñas incorrectas, en algunos casos esto también se aplica al equipo ISP que es local. Un enrutador que OP contrató del ISP y no tiene ninguna capacidad de administración por parte del cliente, también podría ser sospechoso de piratear fácilmente.

• Escuchando en los enlaces inalámbricos con cifrado débil / sin cifrado que el OP no puede controlar. Esto se puede aplicar a un enlace punto a punto configurado por un ISP para salvar un área por la que es difícil enrutar cables físicos. Esto también puede aplicarse a ciertos enlaces móviles.

• Manipulación de BGP al anunciar rutas para redes que alguien no posee. Este es el único riesgo que vale la pena considerar. Algunos ISP también pueden usar métodos que evitan que personas no autorizadas anulen la disponibilidad de las redes de los ISP. Dichas soluciones de seguridad pueden incluir, pero no están limitadas, restringir el tráfico BGP de cualquier equipo propiedad del cliente.

Además de lo que indicaron algunos de los que respondieron, la mayoría de los sitios seguros (por ejemplo, el sitio web bancario, etc.), ni siquiera le permitirán acceder a contenido seguro a través de sus sitios a través de http. Por lo tanto, usar http no es una opción con estos sitios, tiene que usar https.

Puedes rastrear paquetes HTTP usando herramientas como Wireshark y es como un paseo por el parque para leer tus paquetes de datos. Un atacante puede interceptar sus paquetes de datos, modificarlos y reenviarlos. Por ejemplo: le pide a su banco que le pague: el atacante modifica este paquete y le pide al banco que le pague.

No entiendo lo que quieres decir con

  

HTTP en su red Wi-Fi.

¿No quieres acceder a Internet?