Sex, Candies and Bookmarklet Exploits
I have been involved in a number of interesting projects in the last four months. They are about to be released to one degree or another very soon, although the actual dates are uncertain. So, In this post I am planning to speculate on future trends and technologies to appear in the Web Application Security world. In particular, I am going to share my thoughts, views, tips and ideas on developing web exploits with JavaScript, Firefox and Technika.
As you probably know if you have been following this blog, Technika is a browser-based attack framework which was primarily developed to enable better browser automation. The first release was sort of a Greasemonkey clone with better features and cleaner implementation. Technika was used to develop several inbrowser/inline exploits, which were sort of an eye opener for me and several colleges who tested them out.
Inbrowser/Inline exploit is a malicious code that works straight from the browser without the need of a third party software. Its purpose is to attack the remote application or server either by planting a persistent cross-site scripting payload, composing payload for non-persistent cross-site scripting attack or directly exploiting a vulnerability. Because the exploit works from the browser, you don't have to care about authentication, session management, encryption, etc. The purpose of the inbrowser/inline exploit is to easy exploitative penetration testing tasks and help discover vulnerabilities in web applications quicker.
It took some time to figure out how these exploits needs to be written and what technology they need to be based on. I thought of writing something like a framework that works in a similar way to Metasploit, but I eventually gave up the idea. The beauty of the web is that one can quickly write applications and services by reusing other applications and services, sort of mashing up different parts. To me that was a good approach which I through can be implemented to test web applications as well. I thought that, so far, the only browser automation technology that works in a similar way across all browsers is the bookmarklet.
Bookmarklets are similar to User Scripts but they lack the automation features that Greasemonkey provides. In that respect, you have to click on the bookmarklet every time you want to load it. This is sort of limiting. Greasemonkey, on the other hand, works in Firefox only, which means that you cannot reuse user scripts in Internet Explorer and Opera. So, both technologies have their advantages and disadvantage. However, to me bookmarklets are much better solution because they work in all browsers as long as you handle the various browser quirks.
I took Technika and I redesigned its purpose and eventually Technika's core functionalities. I came up with a browser extension which is very lite and easy to use. It works with Firebug for writing and testing bookmarklets and it provides the same degree of automation as Greasemonkey. In simple words, you can tag a bookmarklet as autorunable with the autorun keyword and the browser will execute it on every page you visit. Keep in mind that once you write a bookmarklet you can port it to IE and Opera as well. Although, for now, IE and Opera cannot automate bookmarklet execution, your code will be executed across several platforms, which I believe is very good.
By using Technika, you can stack various base components before running the bookmarklet of your choice. You can configure it to load AttackAPI, jQuery, Prototype and some other libraries on every page you visit. Bookmarklets that are executed after that can use the loaded features to do whatever they are supposed to do. To cut the story short, you can use this approach to create rich application frameworks on the top of the browser.
This was the beginning of a another project which name I will keep secret for now. The project was created for security experts to test and develop web exploits in an easy and concise way. It makes use of the latest AttackAPI, jQuery and several other modules. In simple words, by using this framework, you can easily create an Interactive SQL Injection exploit for a particular application that works from the browser. Because the browser handles the authentication, the session management, the encryption and even the transport (proxies, tor), exploit developers can concentrate on the real thing. They can concentrate on how to supply the payload and get the result back and easily bind this mechanism to an interactive SQL shell, for example. The project will be released very soon, so keep an eye on the GNUCITIZEN website.
Some of you may ask: but we have Metasploit... why do we need another framework for putting exploits together? With all my respect to its developers, in general, the Metasploit framework lacks the functionalities to quickly write web exploits. It is great for remote and wireless eploitation and it can definitely be used for attacking web applications, but generally, it is not designed to be used for this. The web is a system which is quite different. If you haven't dealt with web application security testing before, I can tell you one thing from personal experience, it is not easy to automate everything.
So, give Technika a try. See how it works. Meanwhile, I expect to see some comments if possible. IMHO, exploit development for Web Applications can be less painful with the approach I discussed in this article.
I had a look on milw0rm exploit repository. Most of the exploits there are web application related. A friend of my mine gave the new framework a private test and ported 10 of the latest molw0rm exploits in one hour. Not too bad!
Archived Comments
Sven Vetsch / Disenchant
hei guys my stuff work and they are awesome. check them out.... sort of showing off, but, that was not my intention, indeed, there are some exploits ported and for sure they will get on this website as soon as the framework is completed.