Evilwan Logo

Introduction

It is customary in computer network terminology to name that part of the network that is outside of direct control "Wide Area Network" or WAN. The name of this domain (and website) is based on the experience that the "Internet of Things" should be considered hostile due to the presence of many threats, hence the name "evil WAN".

This site is not intended to educate the audience in all sorts of dangers that lie waiting on the worldwide network tubes, but rather to show random musings that are more or less related to cyber security.

Topics may include forensic techniques, reverse engineering thoughts, cryptographic protocols,...

Fair Warning

In the post 9/11 era it is becoming more and more dangerous by the day to share information on tools. Especially tools that can be used in ways that are, well, probably not entirely in line with your local legislation. So, before downloading any of the tools from this site, be sure that it is legal for you to do so.

Burp Extension "Naked Body"

Sometimes during a Burp session you will notice that "interesting" files are being transmitted. And you want to examine those files in more detail. E.g. you see the download of a Flash media file and want to take that file apart for further study. Or you just want to have a looksie at that funny jpeg file that was downloaded unexpectedly.

So, what's a pentester got to do to get her hands on those files? Well, look no further: Burp extension "Naked Body" will fullfill your wishes. The primary (and only) goal of this extension is to save attachments of requests or responses to your local file system. Just the naked body, no headers, no decoding, no nothing.

This file gives more details on how to download, install and use the extension. For the impatient, here is the direct link to the Burp extension file.

Burp WebSockets Extension

Description

Burp Professional (http://portswigger.net/) is an excellent tool for performing Web Application Vulnerability Assessments. What makes it even more useful is that the tool implements an extension API so that the user can write custom extensions for handling situations that are not provided by the standard Burp application.

A recent addition to the tool is preliminary support for WebSocket messages. Unfortunately, that support is currently limited to providing an overview of all intercepted WebSocket messages, the option to intercept and manually edit WebSocket messages and to save WebSocket messages one by one in a file (right click on a message and select to save that message to file)

This is a good start but in order to really attempt to exploit WebSocket vulnerabilities more functionality is required: that is where a the custom WS extension comes in. The extension allows to save all registered WebSocket messages in one go in one XML file, as well as providing the option to automatically modify selected messages on the fly using a custom written filter class.

The extension can be loaded in Burp after which a new application tab will become available.

The top part of that tab handles saving all recorded WebSocket messages in an XML file: the user can select which properties to include in the output and, for the actual data elements, in which format the raw data should be written in the output file. Default is base64 encoding, but other formats are available as well (including raw data)

The bottom part of the extra tab handles automatic modification of WebSocket messages. For this to work, a custom Java class has to be written that implements interface "evilwan.WSFilter" and the name of that Java class (including package name) has to be specified in the extension configuration tab. A toggle button can be clicked to activate or deactivate automatic modification of WebSocket messages.

It should be noted that every time that automated modification is activated, a new instance of the specified filter class will be used. That means that it is possible to change the filter class without the need to restart Burp.

There is however a drawback to the automated modifications. The extension implements this by activating message interception in Burp, meaning that from then on all messages will pass through the intercept interface. The WS extension will automatically forward all non-WebSocket messages and automatically forward WebSocket messages after modification by the "evilwan.WSFilter" filter. This means that traffic will be much slower when compared to disabling Burp interception. Another drawback is that automated WebSocket message modification cannot be combined with manual interception of regular HTTP(S) requests/responses.

Finally, the latest version of the extension is written specifically for Burp Professional version 1.7.15. The extension will most likely not work for any other version, including the free version. Hopefully newer releases of Burp will include the additional functionality that is provided by this extension and will therefore eliminate the need for an updated version of the extension.

For historical reasons older versions will remain available.

Legalese

In order to write the extension some reverse engineer techniques were used. As far as I know this is allowed when building a tool that is to be compatible with another application. The extension only provides information that is already present in Burp.

The various techniques that were used for building the extension:

  • years of experience writing software (also known as "lucky guesses" ;-) )
  • dumping the Burp GUI component tree, starting with the top application frame
  • Java reflection
  • Java decompiler Procyon for dumping selected class files
  • loads of beer (http://www.duvel.com/en/the-beer works best for me, YMMV)
  • ...

The extension is released under BSD license.

The files

Version 1.7.15

This version is intended for Burp Pro version 1.7.15 and will most likely not work with any other version:

Older versions

Version 1.7.05

This version is intended for Burp Pro version 1.7.05 and will most likely not work with any other version:

Version 1.7.04

This version is intended for Burp Pro version 1.7.04 and will most likely not work with any other version:

Also note the new version number schema: given that each version is tied to a unique version of Burp, it makes more sense to use the same version as Burp so that it is immediately clear which version to use.

Version 0.1.05

This version is intended for Burp Pro version 1.6.05 and will most likely not work with any other version:

Version 0.1.04

This version is intended for Burp Pro version 1.6.04 and will most likely not work with any other version:

Note that this version now includes additional code and one Perl script that should make it straightforward to modify future "minor updates" of Burp.

When a new release is published, launch that version together with the WS extension and commandline parameter "-XXX". Next proceed with a browser that goes through Burp to a website that uses WebSocket messages and make sure that Burp captures one or more WebSocket messages (verify in the WebSockets tab) Once a couple of messages are intercepted, use the WS extension to save them in a file. That file will probably not be correct, but what matters is the output that is produced on the console. That should be something along the lines (actual names depend on which Burp version is used): 

WSPacket -- init() -- _wsclazz is: burp.xyz
Foefel -- burp.xyz.f not available: modifiers = 2 (private)
Foefel -- burp.xyz.f not available: modifiers = 2 (private)
Foefel -- xyz.z[0]="editedMessage";
Foefel -- xyz.z[1]="comment";
Foefel -- xyz.z[2]="originalMessage";
Foefel -- xyz.z[3]="clientToServer";
...

Save that data in a log file (or direct the output of Burp to a log file)

Next launch the Perl script ana.pl like so: 

cat burp.log | ./ana.pl

Read the comments at the top of the Perl script for requirements and customizations.

The output of the Perl script should be something along these lines: 

    ...
    Method returning original message: a
    Method returning edited message: b
    Method returning comment: c

Use those names in Java file evilwan/WSPacket.java to modify the code for private method getAccessorMethods so that the names from the Perl script are used instead. Recompile the extension and you are good to go.

Version 0.1.03

This version is intended for Burp Pro version 1.6.03 and will most likely not work with any other version:

This version uses the new (obfuscated) Burp v1.6.03 classes. The only changes with the previous version are related to the change in names produced by the Burp obfuscation tool.

Version 0.1.02

This version is intended for Burp Pro version 1.6.02 and will most likely not work with any other version:

This version uses the new (obfuscated) Burp v1.6.02 classes. The only changes with the previous version are related to the change in names produced by the Burp obfuscation tool.

Version 0.1.01

This version is intended for Burp Pro version 1.6.01 and will most likely not work with any other version:

This version uses the new (obfuscated) Burp v1.6.01 classes. Also, a minor issue with identifying the accessor method for obtaining the URL of WebSocket messages has been fixed. Lastly, the indicator button now correctly displays the state of WebSocket interception (was reversed in previous version)

Version 0.1

This version is intended for Burp Pro version 1.6 and will most likely not work with an other version:

EventlogDumper.rb

MS-Windows systems register interesting events when they occur. The definition of interesting depends on configuration settings. E.g. it is possible (although not advisable in most cases) to register every time a file is accessed on the system. Other interesting events typically include logon and logoff, anti-virus software reporting suspect files etc.

The event data is stored on disk in several files (by default 3) but in a format that is not suited for immediate inspection by humans. The Ruby script EventlogDumper-v1.12.rb is designed to read event log files in the old format and print out the contents. For newer generations of log files, Google is your friend...

This script is intended to be used in forensics investigations of Windows systems when working on a *nix type system (e.g. when booting from a forensics live linux CD) In order to get a short help text on its usage, just launch the script without parameters.

The two main modes of operation are regular (that is: follow the chain of events) or scavenger mode, where the entire event file is scanned and all data that looks like a valid event entry is printed. That second mode will show events that have been "deleted" from the event log file.

The script output offers either multi-line or single line output per event, where the latter mode is more suited for inclusion in a timeline.

Copyright © 2017 Eddy Vanlerberghe (Mail: digit-four letter-N digit-6 at evilwan.be). All rights reserved. Last update: January 4, 2017