Webz

Vendor: vimeo.com Type of Vuln.: XSS SELF Status : Reported , duplicate ! PoC :

E INDIAN , CLAR

Un tutorial foarte bine detaliat si foarte bine explicat . Sper sa mai impartasesti tutorialele de pe pwnthecode haha

http://www.emisiuni-online.ro/ - ucoz http://www.clicksud.net - blogger http://www.runvideo.net/ - blogger http://www.fly-tv.ro/ - ucoz http://www.tv-play.ro/ - ucoz

A gasit exploit in Click dreapta

Macar de astepta putin sa ajunga in saptamana luminata sa ajunga in rai :(((((((((((( RIPP !!!!!!!!!!

De ce mai cauti in subdomeniile out of scope ?

wow , browser rst ? te crezi in basme ?

This is where the trouble starts. You’ve seen them. They are all over the web. Sometimes they contain valuable information or warn you before closing an important browser window. But most of the time they are really annoying and almost everybody clicks on “Ok” without really reading them. I’m talking about alert boxes. If you hear “XSS” you almost immediately think of them. And that’s a huge problem. Yes, they are a good way to show that it’s possible to to execute JavaScript on a vulnerable website. And with document.domain you also show that it is running under the sites context. But what does that mean to a website owner? He just sees an annoying box and if he doesn’t read about the dangers of XSS he won’t fully understand what it is capable of. But what can we do once we located such a flaw on a website? Stealing session cookies won’t work most of the time as they are often httponly which basically means for us that it’s not readable by JavaScript. There’s a way to abuse an XSS flaw nonetheless and I’ll show you how we can escalate it to a full blown RCE, considering we know a thing or two about the admin panel (guessing might also help sometimes). In this case we escalate our privileges from an unauthenticated remote user to www-data. The vulnerable software is described like this on wikipedia: “CMS Made Simple has a web-based admin section for theme, template, and stylesheet development, installing and updating add-on modules, configuring page content blocks, and user groups and permissions.” SSRF By default CMSMS has an activated module called “CMSPrinting”. It shows you a page in print mode. When we look at the url it’s generating we see one parameter that looks suspicious. It’s a base64 encoded string. When we decode it it shows us the following link: http://172.16.15.142/index.php?showtemplate=false That host is the IP of my lab machine and the false showtemplate parameter removes unnecessary stuff from the page. Of course I immediately tried to include a local file and a remote website. Both didn’t work unfortunately. There must be something in place to prevent us from including any website we want. When we look inside the source code we see this: You see that in order to retrieve content the decoded url parameter has to start with the root url. In my case it was http://172.16.15.142 . You already know where this is going. Since there is no slash at the end we can easily create a subdomain called 172.16.15.142 and make the cms read a file from our Server. This looks totally pointless first. We can’t execute PHP code that way and we don’t get any sensitive files. We can only mirror something from our Server to the page. But if you think about it, that’s exactly what we need to make it an… XSS You think of the alert box again, don’t you? Now you are going to be disappointed. This post is alert free. Instead we escalate it further. Since we are able to create a file on our own server that will be retrieved by the victim cms and then mirrored to the victims browser we don’t have to worry about getting caught by any XSS filter or waf. We can simply write our payload inside our local file. Here’s what it’s doing: First we use JavaScript to get the content of the Admin panel, which contains a CSRF token that has to be passed for any action the admin executes in the ACP. We then extract this key. CSRF With our obtained token and the XSS flaw we can make requests on behalf of the administrator. What we are interested in is the file upload functionality that’s also included in the standard installation. What do we do? We now have to simulate a file upload to the CMS via XSS. This can be done with an ajax post request. RCE We now upload a php file containing a reverse shell. To trigger it we create an img tag pointing to our uploaded file. And there you go. SSRF->XSS->CSRF->RCE If you have XSS on your website in almost every case your CSRF protections are useless. This can lead to account takeover, privilege escalation and also to a complete compromise of your Server. With this in mind, tell me: is an alert box really a good way to show a website owner the dangers of XSS? You decide. https://3.sendvid.com/hajs932z.mp4 Articol preluat de pe site-ul https://blog.asdizzle.com Toate drepturile rezervate asdizzle_

http://brutelogic.com.br/webgun/

http://www.gfxxtra.com/tutorials/programming/680416-angularjs-from-zero-to-hero.html

Since @brutelogic and I have had a lot of fun bypassing filters, creating challenges and finding new XSS methods and payloads in the past we thought we should try our luck on Chrome’s Auditor. You can read about the results of our research here. The bypasses we found can be used in many cases but there might be some situations where you can’t use them, for example when there’s no closing script tag or with some special chars after the actual payload like > or ?. However, there are some uncommon ways you could try. No closing script tag: When there’s no closing script tag our bypasses won’t work. They need at least one ” somewhere after the payload and </script> anywhere on the page after our injection. But there’s still a way to defeat the filter. We just have to use HTML imports. They will also be important for an uncommon bypass I’ll explain later. Their syntax is very simple: <link rel = "import" href = "/path/to/file.html"> In href we can specify any link we want as long as it doesn’t violate SOP. CORS might help here. Any link except one to a local resource is usually blocked by Chrome’s auditor. However if we use our known bypass we used with script src we are able to include a data: url. Our new payload would be <link rel = "import" href = "data:text/html&comma;&lt;script&gt;alert(document.domain)&lt;&sol;script&gt; We have to use html entities, otherwise our payload is flagged. This is possible as we are inside an href attribute now. [test] Working without being flagged This actually works in the sites context and would alert the domain name. No user interaction or closing script tag required. Local html inclusion This also relies on our link tag, but this time we play by the rules of the auditor. As I mentioned earlier we are only allowed to include local resources. The content type isn’t really important as this would also work with X-Content-Type-Options: nosniff. This gives us an interesting bypass opportunity. When we have an upload feature on the website where we want to inject our payload we can use it to upload a file with html code in its source. For example a .gif file with the content GIF89a<script>alert(1)</script> More info about that here, here and here. Even imgur would accept such a file (even though it can’t be displayed). Here’s the proof: imgur accepts this as a valid gif file Now let’s include it. We do this with <link rel = "import" href = "test.gif"> And there we go. It works! [test] Working great (DOM view) Multiple reflections That’s a whole different class of bypasses than the ones we’ve seen before. It’s not working due to an unclosed quote or the fact that the auditor trusts local resources that are passed without parameters. It is possible because the auditor sees a request with some html tags that look harmless on their own, but can be malicious if they occur more than once. This is usually achieved with script tags. A simple example where this would work is this: <a href = "INJECTION">INJECTION</a> You see, our injection is reflected two times i the same line. All we have to do now is this: \">"</script><script>alert(document.domain)-"\ What did we do here? Let me explain: First we break out of the href with \”>. The \ is required as it will escape the ” later in the script context. After that we have another “. This is going to mark the end of our string. Then we have a simple closing script tag. This won’t be recognized as malicious by the auditor as we have no starting script tag before. Now we start our new script with an opening script tag and write our payload after it. We now have to get rid of everything what’s behind our payload, otherwise we’d get a syntax error. We simply do this with a -“\. The ” will mark a new string and the \ will escape the quote that’s left of our payload. This is really hard to describe, so better see for yourself how the payload looks in the end: Some art right here Again this will alert. [click] Unfortunately this isn’t a common case. When we have multiple reflections they are often separated with newlines and other tags like here: This one looks harder, but is in fact easy We can’t use the trick we just used here. Simply because we have a newline that’s separating our payloads. So what would be a post about filter bypasses without template strings? I can’t even imagine it. As we know they allow multi-line strings which is exactly what we need here. Unfortunately the auditor knows about them and won’t allow them when there’s any character between an opening script tag and a template string. So what can we do about it? It’s really easy: ">`;alert(1)</script><script>` That way there’s no character between our template string and the script tag and we can enclose everything that would produce a syntax error. To be honest that same payload would also work on the first example of a double injection. Even a ‘ instead of the template string would. But it was a great challenge to try it with double quotes and backslashes. Here is our payload in action: [click] The ` makes it work in a multiline scenario All this is possible due to the fact that the auditor searches for the same dangerous string in a the request and response body, trusts local resources, doesn’t consider multi-injections and is not really strict to avoid false positives, which is important for a browser with such a market share. I’m sure there are some other bypasses just waiting to be found. You can try everything I showed you earlier when using this link: https://poc.asdizzle.com/auditor-tests/?mode=plain&q=INJECTION There’s different modes you can try: plain inline event image double double2 multi Have fun testing and Bye SOURCE : https://blog.asdizzle.com

Python only

Salut , ce faci ? Banned

Hah , Neo Hapsis !

dar de ce tocmai cu keyword-ul organic ? esti cumva profesor de biologie ? :>

Asta-i metoda tricky ?

Uita-te pe freelancer.com 90% din utilizatori is indieni :)))

Nu stiu d-astea man , scuze.

https://blog.penjee.com/wp-content/uploads/2015/06/fibonacci-recursion-demonstration-animation-python.gif

https://hackertarget.com/hacker-tools-mr-robot/ Prietenii stiu de ce .

Naspa pentru el.

ahhaha

var i = 0; function aprilie() { document.documentElement.style = "-webkit-transform: rotate(" + i + "deg); -moz-transform: rotate(" + i + "deg); transform: rotate(" + i + "deg); -ms-transform: rotate(" + i + "deg);"; i += 5; } setInterval(aprilie, 1000); DE AIAAAA

Recomand , e serios omul. Byte , dar nu cred ca-l vei vinde , probabil vei tot scadea din pret pana unul il va cumpara Bafta oricum.