TAG | python
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.
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.
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].
Finally it’s here!
pytacle is a tool inspired by tentacle. It automates the task of sniffing GSM frames of the air, extracting the key exchange, feeding kraken with the key material and finally decode/decrypt the voice data. All You need is a USRP (or similar) to capture the GSM band and a kraken instance with the berlin tables (only about 2TB )
I’ve posted a preview before, take a look at the video to see the tool in action.
The tool is early alpha, so it’s working (for me ), but it’s neither rock stable nor packaged in any way. But still, I’ll be happy to get bug reports.
BTW, talking about Telco security: There will be another TelcoSecDay on 03/12/2013 at next year’s Troopers! We’ve already some quite interesting talks confirmed.
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)
3 Comments | Posted by Timo Schmid
In a .NET environment WCF services can use the proprietary WCF binary XML protocol described here. Microsoft uses this protocol to save some time parsing the transmitted XML data. If you have to (pen-) test such services, it would be nice to read (and modify) the communication between (for example) clients and servers. One possibility is Fiddler.
Fiddler’s strengths include its extensibility and its WCF binary plugins. Sadly, these plugins can only decode and display the binary content as XML text.
Our first tool of choice for webapp pentests (Burp Suite) has also a plugin feature, and one can also find plugins for decoding (and encoding XML back to) WCF binary streams. But all WCF binary plugins out there are based on the .NET library which means one either has to work on MS Windows or with Mono. Another disadvantage is the validation and auto-correction feature of such libraries… not very useful for penetration testing
That’s why we decided to write a small python library according to Microsoft’s Open Specification which enables us to decode and encode WCF binary streams. The library has a rudimentary commandline interface for converting XML to WCF binary and vice versa, as well as a plugin for our python-to-Burp plugin (pyBurp).
One of our favorite tools for conducting penetration tests (especially, but not only, web application tests) is Portswiggers’s Burp Suite. Burp allows to extend its features by writing own plugins. But because Burp is written in Java, it only supports Java classes as plugins. Additionally, Burp only allows to use one plugin at the same time which has to be loaded on start-up.
Now we have written a Burp-Python proxy (called pyBurp) which adds some features to the plugin system:
- write plugins in Python
- load and unload plugins at every time
- load multiple plugins
today I’ll give a short preview of my newest tool, pytacle. It is simply a little helper program to control gnuradio/airprobe/kraken/some_other_tools, convert their input/output and to find a use able clear/cipher text combination to break A5/1. In the end it should record, crack and decode/play a gsm phone call with ~5 mouse clicks.
Take a look at this video:
The code is not available yet, as its not finished the recording and cracking part are working, but the decoding doesn’t. I need to put some more time into the code, but there isn’t much spare in that time of the year
Another day, another tool
Today I’m proudly releasing the first version of apnbf, a small python script designed for enumerating valid APNs (Access Point Name) on a GTP-C speaking device. It tries to establish a new PDP session with the endpoint via sending a createPDPContextRequest. This request needs to include a valid APN, so one can easily distinguish from a valid APN (which will be answered with a createPDPContextResponse) and an invalid APN (which will be answered with an error indication message). In addition the tool also parses the error indication and displays the reason (which should be “Missing or unknown APN” in case of an invalid APN).
Don’t waste time, get the source here (5a122f198ea35b1501bc3859fd7e87aa57ef853a)
So, after having a completely new release yesterday, we will stay with already known but updated software today. You might have heard of gtp_scan before, which is a small python script for scanning mainly 3G and 4G devices and detecting GTP (GPRS Tunneling Protocol) enabled ports. As GTP is transported via UDP and we all know, UDP scanning is a pain, the tool uses the GTP build-in echo mechanism to detect GTP speaking ports. Since the last version I’ve implemented some new features:
- Support of complete GTP spectrum (GTP-C, GTP-U, GTP’)
- Support for scanning on SCTP
- Improved result output, including validity check of response packages
Find the sources here (bbdcc8888ebb4739025395f8c1c253fa5fd2bb15).
have a nice one.