¿Cómo pueden Twitter y GitHub estar seguros de que no han sido pirateados?

No pueden estar seguros. De hecho, nunca puede estar seguro de que no haya sido hackeado. Pero un examen minucioso puede hacer que usted concluya que es más o menos probable.

Las declaraciones de Twitter solo dicen que no hay indicios de un hackeo. Eso no excluye la posibilidad de que fueron pirateados, y al instar a sus usuarios a cambiar sus contraseñas, lo admiten implícitamente.

En cuanto a GitHub, la redacción es un poco más categórica. Pero creo que forzar un restablecimiento de contraseña muestra que entienden los riesgos involucrados.

Una cosa más a tener en cuenta es que en ambos casos, la fuga se produjo en un sistema de registro puramente interno. No hay indicios de que usuarios de terceros hayan tenido acceso a este sistema. Los sistemas de registro interno rara vez se exponen externamente, y solo se consultan internamente cuando un sistema necesita solución de problemas. Esa es también probablemente la razón por la que este error pasó desapercibido durante meses: las entradas de registro singulares en algún lugar de lo que probablemente es una cantidad gigantesca de otras declaraciones, por lo general no se notan a menos que estén justo al lado o en medio de las declaraciones que se necesitan para Depurar otras entradas.

Twitter también descubrió recientemente el error, lo que significa que es poco probable que personas ajenas a la empresa se hayan percatado de este error antes de que lo hiciera Twitter, y mucho menos que hayan descubierto y ejecutado un ataque para recuperarlos.

Es difícil demostrar que es negativo.

Entonces, ¿cómo se demuestra positivo? En este caso: ¿cómo probar un ataque desde el exterior? Normalmente, hay varios sistemas implementados para monitorear diferentes formas de ataques, violaciones o accesos. Estos pueden ser firewalls, sistemas de detección de intrusos, SIEMs y una variedad de sistemas de monitoreo y registro. En las redes actuales, cada componente tiene algún tipo de monitoreo o permite el monitoreo a través de herramientas de terceros como Check_MK.

Por lo tanto, cada paso del camino, desde el borde de la red corporativa hasta la máquina que contenía la valiosa información en sí, está en alguna forma o forma monitoreada. Estos registros, según la red y las políticas corporativas, se analizan periódicamente. Los sistemas de análisis pueden distinguir entre el tráfico o el comportamiento esperado e inesperado. El comportamiento esperado / no esperado es, por ejemplo, el acceso a archivos.

Los archivos de registro internos generalmente se consideran datos confidenciales, por lo que el acceso a los archivos probablemente también se supervise. Si alguien que no forma parte de un determinado grupo de usuarios intenta copiar / acceder a un archivo de registro interno, probablemente se haya registrado como un comportamiento inesperado o incluso prohibido. Si un posible adversario pudiera suplantar a alguien con los derechos para acceder a este archivo, también se habría registrado, pero como comportamiento esperado.

En teoría, es posible que un atacante pueda superar todos los controles de seguridad, explotar vulnerabilidades de 0 días, no dejar rastro en cada registro de cada componente, el IDS, el SIEM, etc., copiar el archivo de registro interno y compilarlo. afuera, pero es muy poco probable.

Mi suposición es , que después de que se descubrió el archivo de registro, todos estos registros se analizaron minuciosamente para tratar de demostrar si hubo un ataque desde el exterior. Los analistas no encontraron datos sospechosos y, por lo tanto, llegaron a la conclusión de que con casi absoluta certeza no hubo ataques desde el exterior. Y esto, en realidad, lo que se ve en el comunicado de prensa de Twitter (ver el comentario de Florin Coada). Una vez más, supongo: el comunicado de prensa de GitHub tenía un lenguaje más estricto para detener las especulaciones si había un hack. (Realmente no funcionó.;)

^{Por supuesto, también es posible que Twitter y GitHub no tengan dichos controles de seguridad, pero realmente espero que no.}

Supongo que tienen registros de acceso para casi cualquier cosa que suceda en sus servidores, pueden verificar si alguien accedió al archivo, cuándo fue eso, con qué alias se conectó, su dirección IP de origen, etc. ellos mismos que todo acceso fue por empleados legítimos que pueden decir con confianza que no han sido hackeados. Tenga en cuenta que esto no garantiza que no sean pirateados, solo que todas las pruebas apuntan en esa dirección.

La respuesta es muy simple. En ninguna parte afirman estar seguros. De hecho, implícitamente te dicen que en realidad podría haber una violación de dos maneras:

1. Dicen que "no hay razón para creer que hubo" o "no hay evidencia de" una violación. La falta de evidencia podría simplemente significar que el intruso (s) cubrió sus huellas.
2. Le imploran que cambie su contraseña, solo para estar en el lado seguro. Esto implica que no pueden garantizar que no se haya producido ninguna infracción.

Mi interpretación de, especialmente de la declaración de GitHub más audaz, es que quieren decir que el hecho de que las contraseñas se pusieron en el archivo de registro no es el resultado de un ataque de piratería, sino el resultado de un desarrollador que introduce el código de depuración. por accidente en la producción. Esto es relevante ya que un atacante podría haber introducido esta funcionalidad para recopilar contraseñas para capturarlas más tarde.

No hay garantía de que nunca hayan sido hackeados y nunca lo serán, pero este incidente es independiente de los intentos de piratería.

Las grandes empresas como esta deberían tener muchos servidores y, por lo tanto, todo el acceso externo se enruta a través de un bastion host (significado externo no desde dentro de la jaula / sala del servidor real). El bastión podría haber dicho que el registro se haya configurado de manera que transmita todos los comandos de la red externa a los servidores operativos. Los comandos, si están registrados, podrían usarse fácilmente para decir si alguien abrió un archivo con vim, por ejemplo, y eso resolvería la pregunta de si un usuario había sido hackeado. El acceso SSH también se registra para que un IP "bueno" conocido pueda ser filtrado para un usuario y cualquier entrada sospechosa o extraña pueda ser examinada por TI y si una entrada no ha podido ser explicada, eso constituiría una violación. De lo contrario, el servidor sería "seguro" y no habría tanta necesidad de preocuparse con respecto a este asunto.

Lo que realmente están diciendo es que están 100% seguros de que efectivamente hubo una violación de la seguridad. Accidentalmente. Probablemente. Y por ellos mismos. El resto es brillo.

Pueden ver al individuo de manera diferente, como un empleado, pero yo no. Un buen hacker trabaja desde adentro y gana confianza. NSA? FSB?

Nunca deben tener acceso de texto simple a nuestras contraseñas. No es así como funciona el acceso con contraseña. Las implicaciones son que ahora depende de usted cambiar esa contraseña en cualquier lugar que la use. Supongamos que la contraseña ahora es conocida por todos.