Its been a long time, since i released the last version of pytacle, but now the time has come. Here is alpha2 with some new features:
– Support of RTLSDR sticks
– Possibility to scan for cells around you
– Changed the code to generate real KCs (but as nobody noticed the wrong KCs i guess you were good with the others 😉
Im also planning to address hopping channels in the future, but ive not made it far enough in my DSP lecture, yet 😉
Find the new version here.
Also see this post for requirements.
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 example.com can not load a resource from google.com 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 example.com domain is shown below:
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 example.com 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:
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.
As an additional feature, all images being accessible by JavaScript, will be encoded in base64 and also transferred.
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.
This is the first part of an article that will give an overview of known vulnerabilities and potential attack vectors against commonly used Virtual Private Network (VPN) protocols and technologies. This post will cover vulnerabilities and mitigation controls of the Point-to-Point Tunneling Protocol (PPTP) and IPsec. The second post will cover SSL-based VPNs like OpenVPN and the Secure Socket Tunneling Protocol (SSTP). As surveillance of Internet communications has become an important issue, besides the traditional goals of information security, typically referred as  confidentiality, integrity and authenticity, another security goal has become explicitly desirable: Perfect Forward Secrecy (PFS). PFS may be achieved if the initial session-key agreement generates unique keys for each session. This ensures that even if the private key would be compromised, older sessions (that one may have captured) can’t be decrypted. The concept of PFS will be covered in the second post. Continue reading “Vulnerabilities & attack vectors of VPNs (Pt 1)”
A recent post describing some nasty vulnerabilities in HP multifunction devices (MFDs) brings back memories of a presentation Micele and I gave at Troopers11 on MFD security. The published vulnerabilities are highly relevant  (such as unauthenticated retrieval of administrative credentials) and reminded me of some of the basic recommendations we gave. MFD vulnerabilities are regularly discovered, and it is often basic stuff such as hardcoded $SECRET_INFORMATION (don’t get me wrong here, I fully appreciate the quality of the published research, but it is just surprising — let’s go with this attribute 😉 — that those types of vulnerabilities still occur that often). Yet many environments do not patch their MFDs or implement other controls. As it is not an option to not use MFDs (they are already present in pretty much every environment, and the vast majority of vendors periodically suffer from vulnerabilities), let’s recall some of our recommendations as those would have mitigated the risk resulting from the published vulnerability:
Isolation & Filtering: Think about a dedicated MFD segment, where only ports required for printing are allowed incoming. I suppose 80/8080 would not have been in that list.
Patching: Yes, also MFDs need to be patched. Sounds trivial, yet it does not happen in many environments.
One recommendation we did not come up with initially are dedicated VIP MFDs, but this is something we have actually observed in the interim. As the MFDs process a good part of the information in your environment — hence also sensitive information — some environments have dedicated VIP MFDs, which are only used by/exposed to board members or the like. (As a side note, many MFDs also save all print jobs on the internal hard drive and do not retrieve them in a secure way. For example, we also mentioned in our presentation that the main MFD once used in our office kept copies of everything ever printed/scanned/faxed on it)
During one of our last projects in a large environment we encountered an interesting flaw. Although it was not possible to exploit it in this particular context, it’s worth to be mentioned here. The finding was about Cross-Site Request Forgery, a quite well-known attack that forces a user to execute unintended actions within the authenticated context of a web application. With a little help of social engineering (like sending a link via email, chat, embedded code in documents, etc…) an attacker may force the user to execute actions of the attacker’s choice. Continue reading “Cross-Site Request Forgery with Cross-Origin Resource Sharing”
So we got these shiny new BlackBerry Q10 and Z10 device laying on the desk one morning. It’s my first BlackBerry, I have to admit, but never the less, the hole wushy GUI and touchy glass stuff wasn’t my main concern, instead i took a look at the stuff going on while you connect the phone (do i have to call it blackberry? its a phone, isn’t it?) to your computer.
When teaching courses on topics like Reverse Engineering or Malware Analysis we always emphasize the need to minimize unneeded work. Because reversing an unknown binary is a time consuming and complex process, tools that simplify the RE process are invaluable when working under time pressure. In this blogpost series I will present multiple tools and techniques that can help to reverse an unknown binary. Please note that these articles do not contain cutting edge research but rather target at newcomers. However, I hope to also provide some useful and interesting information for moreexperienced practitioners. Continue reading “Reverse Engineering Tools Part 1: BinDiff”
After his great presentations on IPv6 Extensions Headers and security problems related to fragmentation we had invited Antonios Atlasis to Heidelberg to give  this workshop at ERNW. It was a great experience with many fruitful discussions between the participants (mostly security practitioners from very large organizations planning to have their Internet edge IPv6 enabled within the next 6-12 months) and him/us. Antonios thankfully decided to make his slides and scripts available for those interested in further research on the topics (it should be noted that the scripts have not been tested thoroughly and he’s happy to receive feedback of any kind at antoniosDOTatlasisDOTgmailDOTcom). Today Marc (Heuse) gives his workshop on pentesting in the IPv6 age. Hopefully such events help to move things into the right direction in the IPv6 security space…
In the course of a current virtualization research project, I was reviewing a lot of documentation on hypervisor security. While “hypervisor security” is a very wide field, hypervisor breakouts are usually one of the most (intensely) discussed topics. I don’t want to go down the road of rating the risk of hypervisor breakouts and giving appropriate recommendations (even though we do this on a regular base which, surprisingly often, leads to almost religious debates. I know I say this way too often:I’ll cover this topic in a future post ;)), but share a few observations of analyzing well-known examples of vulnerabilities that led to guest-to-host-escape scenarios. The following table provides an overview of the vulnerabilities in question: Continue reading “Analysis of Hypervisor Breakouts”
