¿Qué tipo de ataque fue este?

Question

¿Qué tipo de ataque fue este?

#1 de AndyMac (13 votos)
#2 de Lucas Kauffman (13 votos)
#3 de awesomo4000 (5 votos)

11

Así que nuestro sitio web fue pirateado, y estas son las cosas que se hicieron:

Se han cambiado algunas entradas en la base de datos. No sé si esto fue a través de inyección de SQL o acceso directo a la base de datos (solo se permite a la raíz realizar cambios en la base de datos, ¿es posible emular la raíz u obtener su contraseña?) Oa través del CMS del sitio web. Supongo que fue a través del CMS.
El código de la página de índice se cambió a una declaración dramática de éxito de piratería por parte del pirata informático.

Acabo de recibir una exploración gratuita de Qualys ( enlace ) que dice que SSL Server Allows Anonymous Authentication Vulnerability . Esto probablemente sea cierto porque cada vez que inicio sesión en FTP, me dice que algún certificado no es válido, pero siempre lo ignoro y presiono "Continuar". Estoy usando una cuenta de VPS (no compartida) en el servidor de mi empresa de alojamiento.

¿Cuáles son las primeras cosas que debería buscar para solucionar?

Editar # 1

Acabo de encontrar algunos archivos extraños agregados al servidor, incluido un "wso.php" que parecía estar accediendo a las cookies y otras cosas con las contraseñas del sistema. Luego, en la carpeta public_html encontré una nueva carpeta que no había visto antes, llamada sym , y cuando la abrí, he aquí que tenía una carpeta llamada root que era básicamente un clon recursivo de toda mi carpeta raíz y, junto a él, un .htaccess que decía lo siguiente:

 Options all 
 DirectoryIndex Sux.html 
 AddType text/plain .php 
 AddHandler server-parsed .php 
 AddType text/plain .html 
 AddHandler txt .html 
 Require None 
 Satisfy Any

Tengo algunas preguntas -

¿Eso da más pistas sobre qué tipo de ataque fue este?
¿Son estos "malos" contenidos .htaccess?
Uno de los archivos era boy.php.jpg. Dado que uno de los formularios del sitio permite a los usuarios cargar imágenes, almacena sus rutas de archivos y luego a través de un CMS respaldado por DB accede a esas imágenes cargadas, podría haber sido una inyección de SQL donde se cargó un archivo malicioso disfrazado de imagen y luego ¿Se accede como contenido regular de la página?

Mi compañía está molesta por el truco, pero debo admitir que estoy un poco entusiasmada con este misterio. (un novato total en seguridad como probablemente puedas decir)

Editar # 2

Otra actualización más. Descubrí esta página: enlace

¿Qué es esto y alguna idea de cómo funciona? Mi sitio web es uno de los que figuran en la lista, ¿quizás el shell se haya "cargado" como un archivo jpg?

Editar # 3

Por alguna razón, no se me ocurrió mencionar esto antes, pero mi base de datos MySQL ha sido pirateada: cuando navego en las tablas a través de phpMyAdmin, algunas de las columnas de ID de algunas tablas están llenas de líneas como cat /etc/pwd y %código%. ¿Significa esto que el punto de entrada fue definitivamente una inyección SQL?

web-application tls sql-injection known-vulnerabilities permissions

pregunta user961627 14.05.2013 - 10:53

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-application tls sql-injection known-vulnerabilities permissions

¿Cómo puedo auditar qué tipo de cifrado del Modo Bloqueo se está usando cuando no hay un código fuente disponible? ¿Seguridad operacional recomendada para generar el par de claves principales?

score 13 · Answer 1

Obtenga una versión limpia conocida de su sitio e identifique las diferencias entre el código correcto conocido y el código de producción actual (pirateado). Estudie cómo se han realizado los cambios y repárelos.
Actualice las contraseñas.
Solucione el problema del certificado FTP: considere usar la autenticación de 2 factores.
Encuentre una manera de escanear su código en busca de vulnerabilidades: revisión por pares o análisis automatizado.
Habilite el registro, de modo que, si esto sucede nuevamente, tenga archivos de registro. Si ya tiene un registro decente, mire los archivos a los que se accede y vea si hay inyección a través de la URL.
Considere usar un firewall de aplicación web.
Informe a su departamento legal, a la policía, a los socios, a los clientes si cree que sus datos han sido robados o comprometidos

score 13 · Answer 2

Si el único usuario en la base de datos que puede cambiar los registros es root y su CMS usa al usuario root para realizar consultas, entonces tiene un problema. Su usuario raíz no debe nunca ser utilizado por un sitio web.

Obtenga un usuario limitado que solo pueda acceder a las tablas y registros que necesita para acceder restringido con los permisos adecuados. Si él no necesita eliminar o actualizar, entonces no le dé ese acceso. Esto se conoce como el principio de privilegio mínimo:

En seguridad de la información, informática, y otros campos, la principio de privilegio mínimo (también conocido como el principio de mínimo privilegio privilegio o el principio de la menor autoridad) requiere que en un Capa de abstracción particular de un entorno informático, cada módulo (como un proceso, un usuario o un programa dependiendo del tema) debe Poder acceder solo a la información y recursos que se encuentran necesario para su legítimo fin.

También verifique que los usuarios anónimos no tengan permitido iniciar sesión en su servidor FTP, asegúrese de cambiar la configuración de ftp. Para evitar comunicaciones de texto claro, evite TLS_RSA_WITH_NULL_MD5 y TLS_RSA_WITH_NULL_SHA , ya que estas dos suites de cifrado tienen 0 Potencia clave clave simétrica.
También obtenga un servidor de syslog remoto para que al menos pueda ver las solicitudes hecho y averiguar lo que pasó.
Obtenga un servidor de seguridad de aplicación web
Instale un HIDS en su servidor como OSSEC que bloqueará a los usuarios y le avisará cuando se detecte un intento de irrumpir en su servidor.
Es posible que desee presentar una queja formal ante la policía.

Y lo más importante:

Deténgalo desde la órbita, es la única manera de estar seguro : restaurar su máquina desde una copia de seguridad, se ha comprometido y ya no se puede confiar.

score 5 · Answer 3

Lo más probable es que sea un ataque de PHP LFI (inclusión de archivos locales). La "foto" de .php.jpg en realidad contiene un código PHP válido que luego es analizado por algún otro script en su sitio que es vulnerable a LFI.

Los otros archivos que encontró se eliminaron después de la explotación después de que se explotó la vulnerabilidad de LFI.

Puedes publicar el boy.php.jpg para un análisis más detallado. Guárdelo en otro lugar en su forma original cuando publique un enlace, ya que este sitio puede modificar las imágenes publicadas y las cadenas de ataque probablemente estén en datos EXIF que pueden eliminarse.

Recomiende auditar su código .PHP y la configuración de implementación de PHP para detectar vulnerabilidades. Si bien un "firewall de aplicación web" es una buena medida, no reemplaza la necesidad de auditar su código para detectar fallas de seguridad.