Sí, lo que acaba de leer, es así: los hackers usan búsquedas “sencillas” en Google para encontrar sitios vulnerables e invadir sistemas íntegros. Eso sucede hace ya un buen tiempo y es, de cierta forma, muy simple. Aun así, no es difícil encontrar casos de víctimas que son atacadas por descuido.
El esquema se inicia con una sencilla búsqueda en Google. Los hackers consiguen ver cuáles sitios tienen campos visibles utilizando los llamados dorks, que son los artilugios de la búsqueda refinada del sitio de búsquedas. Un ejemplo de este tipo de búsqueda es:
En este campo podemos encontrar las páginas que, en el campo de la URL, tienen el tipo de archivo php (uno de los lenguajes de programación usado en el desarrollo de sitios) y, al mismo tiempo, las palabras “product” e “id”. A partir de ahí, ya se puede anticipar lo que sucederá, ¿verdad? Un sitio que deja este tipo de datos visibles puede tener brechas abiertas para que se puedan encontrar otras informaciones delicadas.
Luego de esta, en apariencia inocente, búsqueda en Google, los hackers invaden los sitios vulnerables con el apoyo de un programa específico, que, dicho sea de paso, también es muy simple de encontrar (en las imágenes abajo los borramos y difuminamos, por supuesto) y hasta se encuentran varios tutoriales de cómo usarlo en YouTube:
SQL Injection es el nombre que se le da a la técnica de intrusión utilizada en el ataque. El programa del que hablamos más arriba utiliza una “inyección” de SQL (que es el lenguaje de búsqueda en bases de datos). Se realizan varios análisis con combinatorias de campos de la URL de manera automática (tal como se realiza en las búsquedas de Google) hasta que las páginas de error vayan brindando más informaciones sobre el banco de datos del sitio.
Así es como todo funciona a través de brechas y vulnerabilidades que otorgan acceso al banco de datos del sitio. No es que el hacker entre al panel de configuraciones al que el desarrollador tiene acceso, pero sí consigue entrar a un lugar donde todas las informaciones están almacenadas.
En el ejemplo a continuación, que es una imagen que muestra el programa en funcionamiento, podemos identificar que Target es la URL en la que se llevarán a cabo estas pruebas. El campo a la izquierda, el que tiene checkboxes (⃞), es un menú de tablas (o listas de informaciones) a la que el hacker va obteniendo acceso. Los resultados van apareciendo de forma gradual en el cuadro a la derecha. Es donde se encuentra el “oro”: e-mails, logins, contraseñas y hasta números de tarjetas de crédito.
Cuanto más antiguo sea el sitio, habrán más chances de encontrar las fallas ya que faltarán actualizaciones de seguridad. Es necesario estar constantemente alerta y prevenir problemas de desarrollo.
Las pequeñas empresas de e-commerce reciben ataques por tener un desarrollo incorrecto o insuficiente. Muchas veces, se contratan malos desarrolladores por falta de preocupación por la seguridad, lo que lleva, obviamente, a que se produzcan descuidos a la hora de prevenir problemas.
Otro descuido común es el de “Desarrollado por...” en el pie de página de los sitios. Luego de una invasión, para el hacker será muy fácil encontrar el sitio del desarrollador, por ejemplo, y recibir un menú completo de sitios desarrollados con las mismas fallas.
Muchos sitios almacenan contraseñas de manera clara, como en una planilla de Excel. ¡Esto es un terrible error! La manera correcta es utilizar hashes, que son datos confusos de manera tal que se dificulta su identificación.
Toda contraseña puede tener más de un tipo de hash y pueden ser de variados tamaños. De esta forma, se dificulta su visualización. Esto no impide que los queridos hackers también tengan acceso a las bases de traducciones de los hashes. Por eso, no se enoje con esos sitios que piden diversos tipos de caracteres a la hora de crear una contraseña.
Otra forma interesante de darse cuenta de si el almacenamiento de contraseñas de un sitio es precario es la función de “Olvidé mi contraseña”. Si el sitio envía un email con la contraseña pura y simple, significa que no cuenta con un uso mínimo de hashes.
Son esos sitios que no utilizan PagSeguro, Mercado Pago u otros métodos de recepción de pagos que son seguros. O sea, que acostumbran a guardar los datos de las tarjetas de crédito de los clientes en su base de datos.
Lo que hacen los hackers con los datos de las tarjetas de crédito es obvio: compran y/o venden los números (generalmente en listas) para robar lo que sea posible de las víctimas. Pero con las contraseñas hay más trucos: pueden probarlas en otros servicios además del sitio en el que fueron encontradas.
Si se obtuvieron credenciales de un sitio de e-commerce pequeño, por ejemplo, los hackers parten del principio de que muchas personas usan la misma contraseña en varios lugares. De esta forma, pueden conseguir ingresar a sistemas internos de empresas a partir de una contraseña de un funcionario que usó el mismo código en el sitio invadido.
Sus datos y los de sus funcionarios pueden ser vulnerables si no se cuenta con algo que es básico en cualquier problema de seguridad: conciencia. Esos consejos básicos y que quizás ya haya visto antes, pero que son justamente los que protegen contra ataques como el de SQL Injection:
¡Cambiarla siempre! De esta forma, si una exposición lo alcanza (aunque haya usado su mejor y mayor contraseña), sólo habrá perdido una única credencial.
Separe lo personal de lo profesional. ¡Y siempre alerte a sus funcionarios y colegas para hacer lo mismo! Los datos de las empresas son, al final de cuentas, unos de los bienes más buscados por la ciberdelincuencia.
Axur repudia el uso fraudulento de SQL Injection y cualquier tipo de acción criminal en línea. La intención de las informaciones que exponemos aquí es mostrar la necesidad del correcto desarrollo de sitios y de la concientización en la seguridad. La Ley de Protección de Datos Personales llegó para mostrarnos que las empresas son responsables por mantener la seguridad de las contraseñas de sus consumidores.
Eventualmente, en nuestro monitoreo de la deep y dark web o incluso en sitios de la web superficial, tenemos acceso a ese tipo de invasiones. Este monitoreo, es realizado por nuestro equipo de Threat Intelligence.