Operation n

Archive for November, 2006

CSRF with MS Word

November 24th, 2006

Update: 15/12:
CSRF in MS Word part II
Update 28/11:
It is interesting to note that MS Word 2003 will actually warn the user. Obviously, someone at Microsoft saw the potential for badness here. Good stuff.

Microsoft Word has been plagued with vulnerabilities in the past. Therefore, mail servers often restrict email with the .doc extension. However, with applications like Microsoft SharePoint which allows sharing of content between users, the door is opened just slightly to allow for deviance. This article demonstrates using Microsoft Word in Cross Site Request Forgery (CSRF) Attacks.

Our attack vector is found in exploiting MSWord’s frame capabilities: By creating malicious frames in a document and pointing them to a malicious URL, we can exploit multiple, persistent CSRF vulnerabilities (and possibly the browser). The cool part? This all happens transparently with no warnings to the user. Also, this IMG tag can be hidden within a document which means that our malicious code is executed everytime the document is opened. Furthermore, an attacker can use either 302 redirects or modify the infected HTML file to alter his/her targets array. This means our payload can be updated from the attackers end.

This is how we do it:

1. Create new document
2. Goto Insert > Format > Frames >
3. Right Click on the frame > Frame Properties >
4. Set hyperlink to our exploit page which contains malicious IMG tags.

An example target HTML file can be seen below:

<html>
<body>
<img src="http://non-existent/login.php?changepass=123&verify=123" alt=""  />
</body>
</html>

Obviously curious about how MS Word communicates, I sniffed the connection:

GET /login.php?changepass=123&verify=123 HTTP/1.1
Accept: */*
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Host: non-existent
Connection: Keep-Alive
Cookie: blah

As we can see, it is using Internet Explorer to fetch these pages. With some creativity other exploitation techniques may be possible (i.e. ActiveX exploitation). However, attacks are limited due to scripting being disabled by default. Thus we see that MS Word can be used to launch multiple, persistent (well almost) CSRF attacks.

Tested using: MS Word 2000.
Expect a part 2 :)

Browser Referrer Insecurities

November 23rd, 2006

Comments(2)

HTTP is the application-layer protocol that most web pages are transferred with. As part of HTTP, requests can include a “Referer” (sic) header that tells the server which page the user was on that initiated the request. Servers use this information to track users’ paths through the site and possibly provide additional features. This preference controls when to send the Referer header - kb.mozillazine.org

Many web applications and frameworks rely on referrer information for statistics and some (unwisely) even rely on it for security.

An example of an HTTP request including the referrer field can be seen in the following example:

Cache-Control: private
Date: Thu, 23 Nov 2006 15:47:01 GMT
Server: GWS/2.1
Content-Type: text/html
Content-Type: text/html; charset=ISO-8859-1
Client-Date: Thu, 23 Nov 2006 15:47:01 GMT
Proxy-Connection: close
Set-Cookie: Removed
Title: Google
Referer=http://google.co.uk/

Some other examples:

Referer: http://www.google.com.br/search?q=*Hidden for privacy*&hl=pt-BR
Referer: http://mail.google.com/mail/?ik=*Hidden for
privacy*&view=cv&search=cat&cat=hacking&th=*Hidden for privacy*

Privacy is the most obvious security concern here. Anonymous proxies can obviously be used to mask the source IP address of the user, however, information in the URL (i.e. base64 encoded information etc) in some cases may still create a privacy breech.

Additional information disclosure such as internal hostnames, intranet server names etc can also be leaked. Could you imagine this on an enterprise level? Who knows what information your internal users are leaking out to the Internet? I bet Google has loads of infinite information regarding user’s internal networks.

I remember previous versions of PHPBB use to use session IDs in the URL - I think this has changed now. Web applications still using session IDs in the URL are putting user accounts in danger.

In an interesting way, this issue is the original history hack.

Moral of the story? I think developers are using alternate forms of session management now (i.e. cookies, hidden form fields), however, I am still very surprised that browsers have not implemented a, “disable referrer for external sites.” We know that disabling the referrer altogether can cause problems for some web applications, so why not meet half way?

Currently, Firefox supports the following:
0 - Never send the Referer header.
1 - Send the Referer header when clicking on a link.
2 - Send the Referer header when clicking on a link or loading an image. (Default)
(These settings can be found at: about:config for Firefox users)

As for Internet Explorer users… who knows. I would think another solution would be to restrict the Referrer field at the proxy or firewall which I think a number of security solutions now support.

Load Balancer Enumeration

November 20th, 2006

Comments(8)

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

WordPress Securify

November 13th, 2006

Comments(2)

Update: 17/Jan/06 - WordPress Securify Plugin Released.
Update: 18/Nov/06 - Wordpress Securify v1.0b released
Changes include:
- Added Pre-Check functions to prevent overwriting important values.
- Added file/directory permission check
- Added function to change filenames with wp- extension.
- Added additional sanitity checks.

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

Georgi Guninski Retires

November 12th, 2006

Comments(3)

Georgi Guninski sent an email to Full Disclosure today, claiming that he will be retiring from the public security scene.

Pre-meditating the question of why, he writes, “if one needs to ask for a reason: got old, got somewhat tired.”

Georgi has made excellent contributions to the security community for some time now. He has released loads of exploits and his work is quoted in dozens of hacking and security books.

The email ended giving advice to future hackers… something in his final words got me thinking:

“*) fame is worthless.” he wrote.

We all know how many hours we sit in front of our computers, coding, researching and studying. It is a passion and a love. Georgi’s and many others research, have helped secure systems across the globe. How have these men been honoured for their work? I don’t see a noble prize of 10 years of security contributions, and I truly believe there should be one.