Some outright rants from a bunch of infosec practitioners.

TAG | tool



Python For Hackers

Python has reached a defacto standard in exploit development lifecycles and most of the proof of concept tools you’ll find out there are written in Python (besides the metasploit framework, which is written in Ruby). Python allows to write scripts handling with remote services, fiddling with binary data and interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a fast and easy way. The huge standard library with it’s “battery included” principle removes some of the dependency hell known from other frameworks/languages. I want to share some of my python coding experiences with you, and maybe this could give some helpful tips for your future work, to make the world a bit safer :) (PS: most of the examples are written in Python 3.x or compatible to both Python branches).


, , | Post your comment here.



Miner’s Canary Revival in IT Security


What is a Miner’s Canary?

Well, it’s a canary (these cute yellow songbirds some people have as a pet), and its main feature is that it dies before you will.

What the hack [pun intended]? And by the way… what has this to do with IT Security? Well… let me first quote Wikipedia on the birds:


, , , , , | Post your comment here.



An unpacker for Alcatel TiMOS images


I wrote a small python script that extracts the content from Alcatel .tim firmware files. It took some time staring at hex values, as well as a fair amount of guess work to figure out the file format.

, | Post your comment here.



TACACS+ module for loki

There has been, again, some development within the loki domain. Today I’m going to write about the latest module added to the suite, a module for decoding and cracking Cisco’s TACACS+.


, , | Post your comment here.



Getting 20k Inline-QR-Codes out of Burp

Lately we had to analyze QR-Codes in a pentest. Those held some random data which was used as a token for login and we wanted to know if that data was really random.


, , , , | Post your comment here.



ERNW’s Top 9 Burp Plugins

In the context of an internal evaluation, we recently had a look at most of the burp plugins available from the BApp store. The following overview represents our personal top 9 plugins, categorized in “Scanner Extensions”, “Manual Testing” and “Misc” in alphabetic order:

, | Post your comment here.



New Tool: s1ap_enum

As we continue our research in the 3GPP protocol world, there is a new tool for you to play with. It is called s1ap_enum and thats also what it does  😉

The tool itself is written in erlang, as i found no other free ASN.1 parser that is able to parse those fancy 3GPP protocol specs. It connects to an MME on sctp/36412 and tries to initiate a S1AP session by sending an S1SetupRequest PDU. To establish a S1AP session with an MME the right MCC and MNC are needed in the PLMNIdentity. The tool tries to guess the right MCC/MNC combinations. It comes with a preset of known MCC/MNC pairs from, but can try all other combinations as well.



, , , , | Post your comment here.



ASCII Protocol Scheme Generator

As we historically have a strong connection to network technologies (not surprising, given the “NW” in “ERNW” stands for “Networks”), I developed a small script to create RFC-style ASCII representations of protocol schemes. The following listing shows an example created for a fictitious protocol:

 0                   1                   2                   3  
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|             type              |              id               |
|     flags     |                   reserved                    |
|                            payload                            |


The command line to create this output is

./ 16-type 16-id 8-flags 24-reserved 32-payload

and of course the script also provides a help message which explains the parameters in detail.


Enjoy and feel free to leave feedback and comments,

Benedikt :)

, | Post your comment here.



Fresh Meat From the Coding Front

Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.


, , , , , , | Post your comment here.

With HTML 5 the current web development moves from server side generated content and layout to client side generated. Most of the so called HTML5 powered websites use JavaScript and CSS for generating beautiful looking and responsive user experiences. This ultimately leads to the point were developers want to include or request third-party resources. Unfortunately all current browsers prevent scripts to request external resources through a security feature called the Same-Origin-Policy. This policy specifies that client side code could only request resources from the domain being executed from. This means that a script from can not load a resource from via AJAX(XHR/XmlHttpRequest).

As a consequence, the W3 consortium extended the specification that a set of special headers allows  access from a cross domain via AJAX, the so called Cross-Origin Resource Sharing (CORS). These headers belong to the Access-Control-Allow-* header group. A simple example of a server response allowing to access the resource data.xml from the domain is shown below:

CORS Response

The most important header for CORS is the Access-Control-Allow-Origin header. It specifies from which domains access to the requested resource is allowed (in the previous example only scripts from the domain could access the resource). If the script was executed from another domain, the browser raises a security exception and drops the response from the server; otherwise JavaScript routines could read the response body as usual. In both cases the request was sent and reached the server. Consequently, server side actions are taking place in both situations.

To prevent this behavior, the specification includes an additional step. Before sending the actual request, a browser has to send an OPTIONS request to the resource (so called preflight request). If the browser detects (from the response of the preflight) that the actual request would conflict with the policy, the security exception is raised immediately and the original request never gets transmitted.

Additionally the OPTIONS response could include a second important header for CORS: Access-Control-Allow-Credentials.
This header allows the browser to sent authentication/identification data with the desired request (HTTP-Authentication or cookies). And the best: this works also with HTTP-Only flags :).

As you may notice, the whole security is located in the Access-Control-Allow-Origin header, which specifies from which domains client side code is allowed to access the resource’s content. The whole problem arises when developers either due to laziness or simply due to unawareness) set a wildcard value:

CORS Response Wildcard

This value allows all client side scripts to get the content of the resource (in combination with Access-Control-Allow-Credentials also to restricted resources).

That’s where I decided to create a simple proof of concept tool that turns the victim browser into a proxy for CORS enabled sites. The tool uses two parts. First, the which is used as an administrative console for the attacker to his victims. Second, the jstunnel.js which contains the client side code for connecting to the attacker’s server and for turning the browser into a proxy.

After starting the you could access the administrative console via http://localhost:8888. If no victims are connected you will see an almost empty page. Immediately after a victim executes the jstunnel.js file (maybe through a existing XSS vulnerability or because he is visiting a website controlled by you…) he will be displayed in a list on the left side. If you select a connected victim in the list, several options become available in the middle of the page:

JS Proxy


  1. Some information about the victim
  2. Create an alert popup
  3. Create a prompt
  4. Try to get the cookies of the client from the site where the jstunnel.js gets executed
  5. Use the victim as a proxy
  6. Execute JS in the victims browser
  7. View the current visible page (like screenshot, but it is rendered in your browser)

If you select the proxy option and specify a URL to proxy to, an additional port on the control server will be opened. From now on, all requests which you send to this port will be transferred to the victim and rerequested from his browser. The content of the response will be transferred back to the control server and displayed in your browser.
As an additional feature, all images being accessible by JavaScript, will be encoded in base64 and also transferred.

If you like to test it yourself:

  1. You need Python 3.x and tornado
  2. You will find a vulnerable server in the test directory

This kind of functionality is also implemented in the Browser Exploitation Framework (BeEF), but I liked to have some lightweight and simple proof of concept to demonstrate the issue.



I’ve published a video on (6.2MB) and the most current source code on GitHub. Just to be clear, the used application in the video isn’t vulnerable. I’ve patched it to get an example.


, , , | Post your comment here.

Older posts >>


Mail | Twitter | Imprint

©2010-2013 ERNW GmbH
To top