Operation n

Well its finally happened; pdp released the first version of Technika!

In a nutshell, Technika is like a “security distribution of Linux” originating from GreaseMonkey. Although, the original code was based on GreaseMonkey, pdp had a bad night where he couldn’t sleep and decided to completely re-write most of the original GM functions - nutcase :)

I think he will agree that we have spent more time bouncing around ideas regarding this project then actually coding it.

We want to provide a packaged set of security scripts that will plugin into the Technika framework. These scripts can be for web application testing, fuzzing, tool plugins (i.e. script that outputs results to an external program on the your local filesystem), we hope the security community will embrace the power and flexability such a tool has to offer.

We realised the potential of Technika when we got involved in a discussion surrounding the current automated web application tools. All of the ones I have seen utilise a language outside the browser. I have seen Perl, Ruby, Python and C testing tools, all of which require external libraries and other malacki to get working. Why not utilise the browser? The work has already been done.

Nuff said, enjoy.

I know it’s been around 2 weeks since my last post but I have been involved in some really cool research and development with pdp (architect).

Whats coming:
We will be releasing “Technika”. What is it? You will have to wait and see…

I will also be updating the XSS MindMap project for those who found this useful, I have.

Anurag Agarwal released a really interesting paper discussing a technique to break the browser same origin restriction.

This reminded me of my “JavaScript External Scanner” technique, where we use “script src=” and DHTML to request remote .js files for fingerprinting and port scanning. Anurag has taken this a step further.

The attack is fairly simple. We use the same technique as jsescanner but request a remote program rather then a .js file. This program can be anything we like, as long as our output is valid JavaScript.

This is certainly a nice find. The security implications of this are dire but are still somewhat restrictive (from what I can see). Remote programs can be executed on a remote web server but the malicious program will still not have DOM access across other domains as our output is restricted to the current domain the attack was launched from.

A nice proof of concept example is available here.

It is interesting to note when playing with the onUnload event handler, that both Firefox and IE make requests and retrieve responses whilst the DOM is still set on the previous domain.

This got me toying with the idea of a timing attack to bypass the same-origin policy. The basic idea behind this attack is utilising the difference in timing between the DOM and the browser’s network API. I did not succeed in this endeavor but the concept was cool. Bringing race condition vulnerabilities to the browser context would truly open the *nyx boys eyes.

What I did find was that it is possible to kill IE7 :)

DNS Pinning hacks seem unreliable and very targetted. I am in search of something more flexible and powerful to enable cross-domain, bi-directional XSS capabilities. For now these lie in compromising browser plugins (Greasemonkey scripts etc), or in third party applications.

WordPress Securify Plugin (WPSec)

Table of Contents:
Introduction
Installation
Development Documentation
Download

Introduction

WordPress has become one of the the most popular open source blogging software packages on the net. One of the reasons for its popularity is its powerful plugin API.

WordPress Securify (WPSec) is a security plugin for WordPress. Every hour the tests specified within WPSec will be executed. A count of “warnings” is displayed in the top right of the WordPress Admin panel. The security feature list currently supports 3 tests:

• WordPress Version Check
• Admin Panel SSL Check
• WordPress Default Admin username check

It is fairly trivial to add security tests to this project. I am sure the project will move quickly as feedback and new tests are submitted and contributed. The first version of this plugin is mainly to get the framework working (although useful nonetheless). The next release will include an email alert system.

As a side note this plugin was already really useful with the recent WordPress version release fun.

Intallation

NOTE: Please perform backups before you do anything. This is a BETA release meaning it may contain bugs. I do not recommend running this plugin unless you are a fairly advanced user.
To install WPSec, simply untar the package in the wp-content/plugins directory (eg: tar -zxvf wp-securify.tar.gz)

Development Documentation

Writing additional tests for WPSec
WPSec was designed to be modular; meaning that you can contribute additional “securify tests” without to much hastle. In fact, I would encourage it. If the test is useful it will be added to a later release. The author has the option to take credit for the test or to remain anonymous.

Basic WPSec test layout
A WPSec test consists of:

• The actual test code ([plugins-dir]/securify/tests/wps-$TESTNAME)
  • It must contain a WPSec database entry to allow other features of WPSec to function.
  • The database entry must include values: (test,testval) where test is the testname and testval is either ‘true’ (securified) or ‘false’ (vulnerable).
• Add the test into securify.php

Note: When in doubt use the existing tests as a guideline.

Download

The package can be downloaded here.