TAG | tool
0 Comments | Posted by Timo Schmid
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 example.com domain is shown below:
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:
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 server.py 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 server.py 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:
- Some information about the victim
- Create an alert popup
- Create a prompt
- Try to get the cookies of the client from the site where the jstunnel.js gets executed
- Use the victim as a proxy
- Execute JS in the victims browser
- 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.
If you like to test it yourself:
- You need Python 3.x and tornado
- 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.
As a lot of people were asking for, here comes the code of your badge. All You need to customize your badge, is a micro controller programmer, like the Pickit (its around 30 to 40 euros) and the build environment, MPLAB which you can get for free. Then just download the code and implement your own super cool features. Let us know what you did, the best hacks will get into the TROOPERS hall of fame (-;
Hi again and a happy new year 2013!
Lets continue were I left you the last time.
The CTL is basically a binary TLV file with 1 byte type, followed by 2 bytes length and finally the data. But as this is far to easy, some special fields omit the length field and just place the data after the type (I guess those are fields with a fixed length). Here is an example CTL file:
Red fields are the types (counting up), green fields are the length (note the missing length on some fileds) and the purple field contains the data (in this case data with a length of 8 bytes and a type 0×05, which is the signing cert serial number btw. [and yes, this is a real example; Cisco signs phone loads with this 'random' cert]).
The CTL contains a header with types from 0×01 to 0x0f which is padded with 0x0d. The same header is used for the signed files .sgn from the TFTP server later on. The header describes the file version, the header length, the certificate the file is signed by (further called Signing Cert), the corresponding Certificate Authority, the file name, the files time stamp and finally the signature. The header is followed by multiple cert entries, which again use types 0×01 to 0x0f. The cert entry contains a role field 0×04 which describes the use of the cert. We are interested in the CAPF cert (0×04) and the Call Manager cert (0×02).
0 Comments | Posted by Daniel Mende
Some of you may have heard the topic before, as we have spoken about on this years BlackHat Europe, TROOPERS12 and HES12, so this is nothing completely new, but as we’re done with responsible disclosure (finally (-; ) and all the stuff should be fixed, we’re going to publish the code that brought us there. I will split the topic into two blog posts, this one will wrap up the setup, used components and protocols, the next one [tbd. till EOY, hopefully] will get into detail on the tools and techniques we used to break the enterprise grade security.
First lets take a look on all the components involved in the setup:
As you can see in the picture, there are a lot of components and even more certificates involved. From left to right: (more…)
Today is a great day, its the day, Loki finally runs on all big operating systems. Im proud to announce the first Loki release for Windows!
There are a few things not working (yet / at all) under Windows. Those are:
- The WLCCP Module – ive not yet managed to build and link against asleap on windows [but time may help (-; ]
- TCP-MD5 Auth for BGP – This will never work, as Windows has no TCP-MD5 impl. in the kernel
- The MPLS Module – Had some hassle here with WinPcap, may be working in the future
The most testing so far was done on Windows 7 were all the other functions work as they do on Linux and Mac.
Download the installer here [1ebf2edbb0cdb631dc2704e82d9c2d778fac703d].
today im releasing a new version of our famous fuzzing framework, dizzy. The version counts 0.6 by now and youll get some brand new features!
see the CHANGELOG:
- ssl support
- server side fuzzing mode
- command output
- new dizz funktions: lambda_length, csum, lambda_csum, lambda2_csum
- recursive mutation mode
- new dizz objects: fill
- new interaction objects: null_dizz
- reconnect option
- additional fuzzing values
find the sources here (90397f9ec11c8ec3db7f14cb4d38dd39e30f9791)
Everybody who is interested in our newest tool ‘Loki’ is welcomed to head over to ERNW’s tool section and download it. Take this monster for a spin and let us know in the comments how you like it. Loki’s coding father Daniel is more than happy to answer your questions and criticism.
You don’t even know what Loki is?
In short: An advanced security testing tool for layer 3 protocols.
In long: Have a read in the Blackhat2010 presentation slides and mark TROOPERS11 in your calendar to meet the guys behind the research and for sure get a live demo of the capabilities – development is still ongoing, so prepare yourself for even more supported protocols and attack types.
And again: Talking about TROOPERS11… we’ve already selected the first round of speakers. Details to be published soon
Have a great day!