Nombres de usuarios y passwords de personal de Apple, Google, IBM, Oracle y Samsung, al descubierto

Lo cierto es que en este blog hemos escrito muchas líneas con consejos para los usuarios y sus contraseñas: cómo elegir una buena contraseña, cada cuánto cambiarlas, dónde y cómo almacenarlas, etc., pero nunca habíamos hecho demasiado foco hacia el entorno corporativo en cuanto a su almacenaje y tratamiento, ya que, como se suele decir, es como el valor en la mili, “se le supone”.

Pero como cada día nos demuestra la actualidad, las suposiciones muchas veces son falacias en sí mismas. Y es que leemos que Radu Dragusin, científico de la computación de FindZebra y profesor adjunto de la Universidad de Copenhague, ha tenido acceso a 100.000 nombres de usuario y sus respectivas contraseñas que el Instituto de Ingeniería en Eléctrica y Electrónica (también llamado para acortar IEEE debido a sus siglas en inglés) tenía almacenados, y evidentemente mal protegidos, en uno de sus servidores FTP.

ESET España - Nombres de usuarios y passwords de personal de Apple, Google, IBM, Oracle y Samsung, al descubierto

Los datos han estado a disposición de cualquier internauta al menos durante un mes antes de su descubrimiento. Según dice Dragusin, “los registros del servidor Web nunca deben estar a disposición del público, ya que por lo general contienen información que puede ser utilizada para identificar a los usuarios. Sin embargo, en este caso es mucho peor, ya que 411.308 de los registros de entrada contienen nombres de usuario y contraseña. De estos parece que hay 99.979 nombres de usuario únicos”.

Los miembros del IEEE cuyos datos se han visto comprometidos pertenecen a organizaciones tan importantes -y a la vez delicadas- como Apple, Google, IBM, Oracle y Samsung, así como a investigadores de la NASA y miembros de la Universidad de Standford, entre otras organizaciones e instituciones. Uno de los datos almacenados en dicho fichero es la dirección IP del usuario, por lo que se ha podido saber que los afectados se encuentran en todo el mundo, aunque la mayoría se concentran en América del Norte, Europa y la India.

Lo peor de todo no es que este científico haya accedido a esta información, sino que según Dragusin, el error más grande -y a la vez el más simple- es que los administradores del sitio del IEEE no aplicaron medidas restrictivas de acceso a los registros de su servidor web. Así que se los ha encontrado este científico, pero podríamos haber sido alguno de nosotros o alguien con peores intenciones.

Porque la verdad es que todo ha quedado en un susto, ya que Dragusin amablemente notificó del hecho a los responsables y esto les ha permitido arreglar el problema, al menos de forma parcial.

Cuidadín con el sitio donde guardamos los datos…

Tal y como empezábamos este artículo, no vamos a suponer nada más. Hay grandes profesionales trabajando como administradores de sistemas, jefes de seguridad corporativa o directores de informática. Pero también hay personas que empiezan y que quizá todavía no están muy al tanto de las medidas a adoptar para evitar riesgos. Y también hay muchos desarrolladores o emprendedores que se montan su propio negocio online… Así que para los que empezáis os dejamos unos consejos muy básicos de seguridad para proteger datos en entornos corporativos. No están todos los que son, pero si son todos los que están ;-).

Si tenemos nuestra información en un servidor interno, hay que recordar que el primer paso que deberíamos dar es crear una política de contraseñas realmente efectiva, con permisos estructurados y gestión de grupos, donde cada usuario sólo tenga acceso a aquello que le compete, y sea consciente de su responsabilidad y obligación de proteger su clave de acceso. He visto sitios donde la clave de acceso estaba escrita en un post-it pegado en la pantalla, y también he asistido muchas veces a la lamentable escena de alguien preguntando en alto en una sala: “Oye, ¿cuál es la clave de la semana?”, y el que la sabía, contestar, también en voz alta… seguido de un montón de gente apuntándola en un post-it para sustituir la de la semana anterior… No voy a hacer más comentarios al respecto.

Por no recordar el caso de este individuo que fue entrevistado para la BBC y se colocó justo delante de donde tenía apuntadas las contraseñas corporativas en su pared… Bueno, menos mal que eran del Wi-Fi 😉

ESET España - Nombres de usuarios y passwords de personal de Apple, Google, IBM, Oracle y Samsung, al descubierto

Asimismo, el servidor (tanto interno como servidor web) debe tener instalado un buen cortafuegos (firewall) que no permita más conexiones que los puestos internos de la empresa y de aquellos dispositivos móviles que pertenezcan a usuarios en movilidad autorizados. Y si dispone de temporizador, es interesante establecer un horario de acceso y bloqueo: muchos ataques se producen cuando no hay nadie en la empresa vigilando la actividad del servidor.

Tampoco se debe utilizar esta máquina para navegar por Internet, ni para leer el correo. El servidor de datos no debe permitir conexiones de nadie que no esté dentro de nuestra red local (intranet) o pertenezca al grupo de usuarios con permiso para conectarse desde fuera de ella, y, por supuesto, jamás debería ser el servidor web al mismo tiempo que servidor de datos. Aunque… de todo hemos visto.

Además, es muy recomendable, tanto en el servidor de datos como en el servidor web, deshabilitar todos los servicios que no sean necesarios, como TELNET, FTP (puertos 20 y 21), SNMTP, HTTP (puerto 80), o los que procedan, sin olvidar los del escritorio remoto. Tampoco es mala idea deshabilitar todos los protocolos de comunicaciones que no sean de verdad necesarios, como el UDP, y dejar solamente el TCP. En resumen, se trata de cerrar todos los puertos que no tienen ninguna utilidad en el servidor porque no se usan.

Hay que tener en cuenta que hay muchas formas de intentar extraer datos de un servidor web, pero para todas ellas, salvo agujeros graves de seguridad del sistema operativo o del programa servidor, el atacante necesita conocer un usuario válido y su clave de acceso. Y como siempre decimos, el eslabón más débil de la cadena suelen ser los propios usuarios… o los administradores.

El siguiente paso será limitar los privilegios del usuario por defecto (anonymous) que los servidores suelen utilizar para responder a las llamadas del exterior. Este usuario genérico solamente debe tener permisos de lectura en el área donde residan los datos de la web, y ocasionalmente, permisos de ejecución de ficheros de comandos u otro tipo de ejecutables, como CGI, servlets, scripts, etc., si los hay. En resumen, se trata de que si alguien consigue entrar en el servidor utilizando ese usuario, no pueda conseguir con él nada distinto de lo que conseguiría operando normalmente con un navegador.

Por lo tanto, si tienes una web que utiliza bases de datos y almacena registros, esta información debería alojarse en otra máquina, pero nunca en la misma que sirve a la red. Además, también te recomendamos que no utilices el usuario administrador para acceder a este servidor: es mejor crear un usuario específico para estos fines, que no pertenezca al grupo de administradores, con una buena y robusta clave de acceso (al menos, de 8 a 10 caracteres alfanuméricos aleatorios incluyendo símbolos) que tenga privilegios lo más restringidos que sea posible: lo justo para mantener la operativa normal y, a poder ser, que sean solo de modificación, no de borrado (con ánimo de evitar errores). Y, por supuesto, debe tener permisos de acceso a las tablas del sistema.

Por supuesto, contar con una solución de seguridad tanto en las estaciones de trabajo como a nivel perimetral es fundamental para evitar que se ejecuten códigos maliciosos que puedan robar información confidencial de la empresa.

Para terminar, también recomendamos la revisión del registro de logs y de los ficheros de inicios de sesión de los servidores y del firewall, simplemente para confirmar que no ha habido accesos a horas extrañas ni de máquinas desconocidas.

Y si tienes algún problema, solo desearte que el que lo descubra sea tan buena persona como Dragusin ;-).

Yolanda Ruiz Hervás
@yolandaruiz

Múltiples vulnerabilidades críticas en dispositivos móviles