Technika is a Firefox plugin that myself and pdp was toying with some months back. The original idea behind this project was to provide independent self-contained security tools based on JavaScript which can be loaded and executed from the browser. TS Framework v1.0 is almost ready for release.

If you haven’t already checked it out, get more info here.

Also, I just finished a write up on some of my thoughts around automated web application tools, now that I’ve started writing one. It’ll most likely be published on GNUCITIZEN tomorrow.

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.

Changelog

I have collected some WEB backdoors in the past to exploit vulnerable file upload facilities
and others. I think a library like this may be useful in a variety of situations.

Understanding how these backdoors work can help security administrators
implement firewalling and security policies to mitigate obvious attacks.

The package includes:

Note: readme.txt is also included in this package but not listed here.

If you have contributions please let me know so that I can add them into a later
release.

Download here.

Load Balancer Enumeration
author: david.kierznowski_at_gmail.com
http://michaeldaw.org

Table of Contents:
0. Introduction
1. Dynamic DNS
2. Proxies
2a. Cookie Analysis
2b. Web Server Configuration issues
2c. Using the TCP/IP Stack
2d. Using HTTP Date: field
3. References

0. Introduction

Load balancing (performed by a load balancer) is a type of service performed by a computer that assigns work loads to a set of networked computer servers in such a manner that the computing resources are used in an optimal manner – wikipedia

As touched upon in “http://michaeldaw.org/news/news-091006-0/”, detecting load balancing is crucial to the security of any web application, yet I have heard very little by way of security testing in this area.

This article will discuss some ideas around detecting load balancers but more importantly I will share some techniques to enumerate the web servers behind these load balancers. None of the ideas in this article are new, but offer a collection of techniques that I have often found useful.

Note: I do not presume this article to be the end all on the subject, but I hope to encourage the reader to find new and effective techniques to not only detect load balancers, but also to be able to distinctly identify the targets behind the load balancer.

1. Dynamic DNS Load Balancing

./check-dns.sh
Connecting to [www.google.com] [20] times
www.l.google.com has address 64.233.183.103
www.l.google.com has address 64.233.183.104
www.l.google.com has address 64.233.183.147
www.l.google.com has address 64.233.183.99
www.l.google.com has address 66.249.85.104
www.l.google.com has address 66.249.85.99

check-dns.sh source here.

As seen above, DNS load balancing is the easiest to spot. It is also one of the easiest to test for as each web server has an external IP address.

2. Proxies

Proxy type load balancers (i.e. Apache Tomcat, F5’s BIG-IP) typically forward connections to a cluster of web servers. This can be done sequentially, randomly or by more advanced methods such as by bandwidth utilisation etc.

Unlike DNS load balancing, proxies require a method to maintain state (as HTTP is stateless). It is because of this that our techniques in load balancing enumeration once again branch off. These include:
a. Cookie Analysis
b. Web Server Configuration issues
c. Using the TCP/IP Stack
d. Using HTTP Date: Field

2a. Cookie Analysis

This is fairly straight forward. A number of popular load balancers use cookies to maintain state and ultimately manage its connections.

F5’s BIG-IP Load Balancer demonstrates this nicely:

Set-Cookie:BIGipServer[poolname]=336268299.20480.0000;expires=Sat,01-Jan-200200:00:00
GMT;path=/

The [poolname] variable above represents an encoding (d*(256^3)+c*(256^2)+b*256+a) of the IP address and port of the server.
See http://www.nessus.org/plugins/index.php?view=viewsrc&id=20089

2b. Web Server Configuration issues

Web server configuration vulnerabilities can be used to detect load balancing and determine the internal IP addresses (in some cases) of the internal web servers. The following example demonstrates this:

GET / HTTP/1.0

HTTP/1.1 302 Object Moved
Location: http://172.16.14.25/
Server: Microsoft-IIS/5.0
Content-Type: text/html
Content-Length: 148

--snip--
This document may be found
<a HREF="http://172.16.25.140/pdf/";>here</a>
--snip--

2c. Using the TCP/IP Stack

Observing and watching IPID increments can often tip you off that multiple stacks are being used.
Example:

$ hping2 *hidden* -S -p 80 -i u1000 -c 30
HPING *hidden* (eth0 x.x.x.x): S set, 40 headers + 0 data bytes
len=46 ip=*hidden* ttl=51 DF id=58489 sport=80 flags=SA seq=0 win=24656 rtt=203.9 ms
len=46 ip=*hidden* ttl=51 DF id=16912 sport=80 flags=SA seq=2 win=24656 rtt=200.1 ms
len=46 ip=*hidden* ttl=51 DF id=58490 sport=80 flags=SA seq=3 win=24656 rtt=197.2 ms
len=46 ip=*hidden* ttl=51 DF id=16913 sport=80 flags=SA seq=4 win=24656 rtt=194.2 ms
len=46 ip=*hidden* ttl=51 DF id=58491 sport=80 flags=SA seq=5 win=24656 rtt=204.0 ms
len=46 ip=*hidden* ttl=51 DF id=16914 sport=80 flags=SA seq=7 win=24656 rtt=199.1 ms

2d. Using HTTP Date: field

Discrepancies in the web server’s ‘Date:’ field.
Example:

# ./check-date.sh
Connecting to [*hidden*] [10] times
Date: Mon, 20 Nov 2006 21:30:30 GMT
Date: Mon, 20 Nov 2006 21:28:22 GMT
Date: Mon, 20 Nov 2006 21:28:23 GMT
Date: Mon, 20 Nov 2006 21:28:24 GMT
Date: Mon, 20 Nov 2006 21:30:43 GMT
Date: Mon, 20 Nov 2006 21:30:44 GMT
Date: Mon, 20 Nov 2006 21:30:45 GMT
Date: Mon, 20 Nov 2006 21:30:45 GMT
Date: Mon, 20 Nov 2006 21:30:46 GMT
Date: Mon, 20 Nov 2006 21:30:47 GMT

check-date.sh source here.

3. References:

http://content.websitegear.com/article/load_balance_dns.htm
http://en.wikipedia.org/wiki/Load_balancer
http://michaeldaw.org/news/news-091006-0/
http://www.nessus.org/plugins/index.php?view=viewsrc&id=20089
F5’s BIG-IP Load Balancer
http://www.hping.org/

Appendix

check-dns.sh Source:

#!/bin/sh

# PoC: DNS Load Balancer Check

TARGET="www.google.com"
TIMES=20

echo "Connecting to [$TARGET] [$TIMES] times";

for ((i=0; i<$TIMES; i++)); do
 host www.google.com | grep address >> ,dns.txt;
done

 cat ,dns.txt | sort -u

check-date.sh Source:

#!/bin/sh

# PoC: Grab 'Date:' field from web server

TARGET="www.microsoft.com"
TIMES=10

echo "Connecting to [$TARGET] [$TIMES] times";

for ((i=0; i<$TIMES; i++)); do
 echo -e 'HEAD / HTTP/1.0\r\n\r\n' | nc $TARGET 80 | grep 'Date:';
done

On the 11/11/06 _ANtrAX_ released a post on full-disclosure regarding a “Remote File Inclusion” vulnerability in WordPress 2.0.5 (Latest version). This vulnerability (in theory) would allow an attacker to gain access to just about any WordPress web application on the Internet. Getting worried?

Securityfocus has recently disregarded this vulnerability. They explain:
“The vulnerability described in this BID is not exploitable, as the parameter specified can not contain user-specified data. This BID is therefore being retired.”

I thought about how widely used WordPress is. The WordPress website claims: “join 473 thousand other bloggers…”. The question is what are some small things we can do to mitigate zero day vulnerabilities?

I have written a simple shell script called, “WordPress Securify v1.0a” to increase security for WordPress users but also to demonstrate some basic best practise guidelines for implementing web applications of this nature.

Let us look at what WordPress Securify currently supports:
[Step 1] Removing .txt/.html/import*.php/install*.php/upgrade*.php files…
[Step 2] Renaming default directories…
[Step 3] Changing filename wp-admin.css to $NEW_ADM_DIR.css ”
[Step 4] Remove WordPress Version

** Step 1
This step removes default content not required by WordPress following the installation or upgrade. Many web servers have been compromised in the past due to a lone script left after the installation process.

** Step 2
WordPress installations uses 3 main directories: “wp-login, wp-admin, wp-content”. Worms and trojans can easily identify and propogate when default directories like these are left unchanged. WordPress Securify allows you to choose new directories… it will then change these for you.

** Step 3
Not important from a security point of view.

** Step 4
Attackers will always seek after software types and versions for obvious reasons. It allows them to quickly Google search for vulnerabilities with your specific version. WordPress gives out this information by default. Its interesting to note that phpBB use to do this. In a later version of 2.0 the version was removed for the purposes discussed above. I would not be surprised if the WordPress developers do the same thing in a future release.

WordPress Securify currently only removes the version and not the software type. I have left this for two reasons… primarily because its late (or early) and I actually need some sleep.

Future versions of WordPress Securify will include:
>> Removing the software type
>> Rename filenames “wp-filename” to “random_filename”. (Done in v1.0b)
>> Check file and directory permissions. (Done in v1.0b)

Download WordPress Securify v1.0a.

DISCLAIMER:
This is BETA software use it at your own risk.
It is recommended that you backup your WordPress
directory before using this tool. Also note, I have only tested this with default installs of WordPress 2.0.5.

Credits:
Kafkaesqui
– http://wordpress.org/support/topic/32764#post-185346

I have been doing alot of research into JavaScript Port Scanning lately. This tool is an initial attempt to correlate my ideas into a single project.

Download the latest version of jsscan.tar.gz here.

Synopsis:
function webPingScan() {
s = new jsscanner(”192.168.1.1/30″);
s.jssWebPing();
}

Usage:
s = new jsscanner(”IP/Range”);
s.jssWebPing(); OR
s.jssWebScript(); OR
s.jssWebImage();

TODO:
+ Complete jssWebScript Scanner (Half done)
Add Additional Fingerprints
see: http://michaeldaw.org/projects/jsescanner/
+ Write jssWebImage Scanner (DONE)
Add OS Fingerprints
see: http://www.spidynamics.com/spilabs/js-port-scan/
+ Add port selection
Include Browser Port Restrictions
see: http://michaeldaw.org/projects/web_browser_port_restrictions/
+ Add some validation

Credits:
pdp (http://gnucitizen.org)
I hope to incorporate this project into pdp’s AttackAPI at some point.
It currently uses AttackAPI’s IP Calculator script.

Internet Explorer:

Anything goes. I need to look into this more.

Opera 9:

Resticts access to Ports 22,25,53 and 110. All other services seem accessible, I need to do more work here – It was interesting to note that my CPU was cranked up to 100% when requesting a restricted port. A “-1″ port will cause Opera to wrap to 65535 (although this could be the default). Its late and I’m going to bed.

Firefox (tested on 1.5.0.7):

Restricts common services such as Telnet and SSH. However, it allows most services. Some of the more interesting ports allowed include:

Service | Port
bootps | 67/tcp
snmp | 161/tcp
netbios-ns | 137/tcp
netbios-dgm | 138/tcp
microsoft-ds | 445/tcp
ldaps | 636/tcp # Firefox blocks ldap (unencrypted version)
imaps | 993/tcp # Firefox blocks imap (unencrypted version)
pop3s | 995/tcp
socks | 1080/tcp
nessusd | 1241/tcp
ms-sql-s | 1433/tcp
ms-sql-m | 1434/tcp
oracle TNS | 1521/tcp
mysql | 3306/tcp
RDP | 3389/tcp
postgresql | 5432/tcp

1. IMG Scanner – using (img src=)
http://www.gnucitizen.org/projects/javascript-port-scanner/
http://www.spidynamics.com/spilabs/js-port-scan/

Limitations:
This is a nice technique for scanning but can be easily mitigated by disallowing external images. This effectively breaks both scanners (tested in Firefox). This includes SPI Dynamics PING feature. You can turn off external images as follows (instructions for Firefox):
> Tools
> Options
> Click “for the originating Web Site only”

2. XML Port Scanning – Haven’t looked into this to much
http://www.sift.com.au/36/172/xml-port-scanning-bypassing-restrictive-perimeter-firewalls.htm

3. JSEScanner – using (script src=)
http://michaeldaw.org/projects/jsescanner/

4. JSWebPing – using iframes
http://michaeldaw.org/projects/jswebping/

JavaScript Web Ping
Author: david.kierznowski_at_gmail.com
http://michaeldaw.org

The Idea:
1. We setup an Iframe
2. We dynamically load our target address with a timeout
3. If the document is loaded, we flag the host as being up.
4. If the host is down, the timeout is reached and we flag the host as down.

This concept can also be extended to perform port scanning for open web services.

Also see:
http://michaeldaw.org/projects/jsescanner/
http://www.gnucitizen.org/projects/javascript-port-scanner/
http://www.spidynamics.com/spilabs/js-port-scan/

The source for the tool is available here
The full tool is available here

JavaScript External File Scanner (JSEScanner)
Author: david.kierznowski_at_gmail.com
http://michaeldaw.org

JSEScanner is a simple idea:
1. Use uses <script src=”"> to request a JavaScript file.
2. Use typeof to verify its existence.
3. Use result in fingerprint.

This technique can be used to enumerate internal web servers and/or applications via a clients browser. It is limited in that it can only detect web servers as it uses <script src=”"> for connections and relies on detecting JavaScript functions for callback.

It is possible to add Iframe Timeouts to extend its port scanning capabilities. However, this is nothing new. I may add it later.

This tool was inspired by Spidynamics recent IMG based JavaScript port scanner (or was this Jeremiah Grossman’s idea…?).

Due to the limitations of client-side scanning, additional techniques are required to produce more accurate results. I can see a JavaScript Scanning Suite on its way. I wouldn’t be surprised if it were named, “jmap”.

Please email fingerprints as you play around.

Fingerprinting Web Server Software:
Device | JavaScript File | Valid JavaScript Function
Linksys Wireless Router | Gozila.js | LogButton_check
IIS ASP.NET | $JSVALDIR/$VER/WebUIValidation.js | ValidatorUpdateDisplay

Note: See http://michaeldaw.org/projects/asp-auditor-v2/ for more information regarding ASP.NET’s JS Validate directories.

Fingerprint Applications on Web Servers:
Device | JavaScript File | Valid JavaScript Function
TWiki | /pub/TWiki/TWikiJavascripts/twiki.js | initForm
bblog | /bblogg/bblog/script/index.js | removeFocusBorders
wordpress | /wp-admin/xfn.js | GetElementsWithClassName

The source for the tool is available here