The testing engine used in this particular version of Websecurify is optimized to run with the least possible amount of memory. The results of the scanner are as good as those produced by all other Websecurify variants although in some cases it may miss some statistically unlikely types of issues. This is not directly and only applicable to the iPhone version. No! Similar tradeoffs are also present even in standard desktop/server based scanners although they are usually less visible and obscured behind tones of options. The bottom line is that the scanner not only runs natively on the iOS but also works as expected.

Now this is exciting! Websecurify is the first in the world mobile web application testing technology.

If you have any suggestions, recommendations or general feedback please do let us know. You can also participate in the beta test program which will allow you to have a play with tool as we are polishing it for the official release.

The possibilities are endless.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Wether this is the real deal or simply fear mongering, I simply don’t know. It is all speculations at the moment. The only thing we can say is that it is difficult to deny the fact that computers are important and whoever has control over them has control over people lives and can influence a lot of things including politics.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

On 5th of July 2009, the GNUCITIZEN team and friends came together to perform a skydiving gig. It has been two months since that day but memories are still as clear as yesterday.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

These tools are not unfamiliar to modern day penetration testers. In fact, there are plenty of them to choose from, ranging from low-grade command line utilities to high-end frameworks. There are plenty of commercial tools as well some of which are a lot better, in terms of features and false-positives rate, when compared to open source alternatives. People often choose what they are more familiar with. I prefer to use tools that are right for the job without discriminating a particular operating system, platform, and style.

Without further ado, I would like to introduce to you yet another tool to compete in the market of automated web application security scanners (not only), released as part of our own Websecurify initiative. The tools is called Websecurify (big surprise) and it is written on the top of common web technologies, which provide significant benefit over other technologies used in open source and commercial alternative products.

Here are some of the key features of Websecurify:

1. It is 100% open source, GPL, CC product, ready to benefit the open source movement
2. The engine employs technologies, such as Web Workers, from the latest HTML5 specs
3. Most of the code is written in JavaScript but many parts can be rewritten or extended with Python, Java and C
4. The core engine can be taken out from the binary bundles and used as part of self-defending web applications. I will talk about this soon.
5. The testing and reporting mechanisms are asynchronous. This means that the report is cooking while the test is performed. It also means that decisions are taken immediately, i.e. they are not scheduled.
6. The tool is cross-platformed thanks to xulrunner
7. Everything is written with extensibility in mind
8. It can be extended in pretty much the same way you can extend Firefox and Thunderbird

There are many other features, which I am going to talk about soon.

At the moment the tool is only available as a MacOS DMG package and source code. The Windows and Linux versions will be released soon. In the future we are planning release all platform specific packages at the same time. Now is just an exception as we are mostly interested to get an early feedback. I am sure that that there will be a lot of bugs to fix and features to add/improve before we reach version 1.0.

Version 0.2 can be downloaded from www.websecurify.com or our source code repository.

If you have any feedback or you would like to contribute to this project, please do let us know. We can use any help possible.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Got the idea? No? Let me explain. What you see in the video above is an application for the iPhone which gives you detailed characteristics of properties (houses) in USA. You can either search the map or just use your GPS coordinates to get information such as price of the house, number of floors, number of rooms, pictures taken from inside the house if the house was part of any register (letting agencies etc.) before you moved in, and other interesting information.

This is the kind of information gathering you see only in the movies. I won’t be surprised if future versions of these kind of applications can pool even essential blueprints which show not only how the house was constructed from architectural point of view but also show the power and gas grids and perhaps even any other wiring such as telephone, coaxial, etc.

All of this information is also available through easily accessible APIs. Perhaps these APIs are not publicly known but anyone who can run a sniffer most certainly can get hold of the URLs and their formats. Now mash this APIs with any other tool such as one that correlates IP address to physical location (not very accurate btw) or better yet a wardriving tool and you have a infowar machine in your pocket that will make any criminal organization proud of.

This was the main purpose of my Web2.0 talk/research from two years ago. Back then I made a very simple analogy which I would like to bring once again. When the email was invented nobody even suspected that it will be used for things such as spam and malware. That was something unimaginable. Today spam is the fastest growing criminal industry and malware delivered over email is the most successful one. In summary, we cannot foresee how a technology will be used/abused. That depends on the imagination of the people.

The same goes for the Web2.0 meme. The more we use it, the more ways we will find to abuse it. However it is also important to say that the more we use it the more accustomed we will become to it. Therefore, when the shit hits the fan there will be very little that we can do.

The reason I am bringing this up is not because I would like to start even more FUD around the Web2.0 mem but it is time for us to stop looking into the technical aspects and start thinking in terms of technologies that affect normal people. Sometimes, we just lack the realism and we fail to spot the obvious problems.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The conflict seems to be resolved now to one degree or another but it is interesting to observe the whole situation and also draw important conclusions. Therefore, I’ve got several points I would like to bring to the table:

1. More examples of similar nature will follow. Keep an eye on Facebook, Apple AppStore, Firefox and other platforms that allow 3rd-party components to be displayed, downloaded and executed.
2. As I mentioned before, a malicious piece of JavaScript code (even an obvious obfuscation) can be quite easily smuggled into harmlessly looking Firefox extensions. If I may speculate, the situation is the same for other similar platforms.
3. Unless platform vendors do something about it, they could become the next hot spot for all sorts of interesting malware.

It is also very interesting to see the extend to which extension developers will go in order to protect their userbase. After all, larger userbase equals more money. And with more people looking to quickly cache in, the battlefield is truly changing for better or worse.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Later on, during the CONFidence 2008 event in Krakow I met a bunch of people who claimed that they already sell exploits to various UK companies and the figures that they were making were outstanding. To give you a clue, given the pound dollar difference at that time, you could have made 6 times more than what ZDI and other similar programs can offer you for a top range exploit. This is already better than a top salary in UK.

Same year, different event… I saw an interesting presentation by Robert McArdle from Trend Micro. The presentation was titled Fighting web Based, Profit-Driven Threats. On one of his slides, Robert commented that cybercrime is becoming more profitable than the drug cartels. Perhaps you wont be able to make as much money from carding as you might expect but you can do quite well selling visualized stuff, such as exploits and exploit toolkits.

Present times, DojoSec Monthly Briefings… Matthew Watchinski from Sourcefire VRT talked about a PDF 0day spreading around Xmas time. The exploit took a couple of good months for Adobe to fix it. The author sold it for 75K to a unknown 3rd-party in China according to Matthew. The vulnerability was also relatively easy to find and required very little experience to exploit.

All of this leads to the very obvious conclusion which is that at present times cybercrime is a flourishing industry. Soon, there will be even more recruits coming to join the dark-side forces of the cybercrime cartels. They will do it for the money!

No more free bugs you say? I say that you are leading people to become the next generation of cyber menace. Perhaps you forgot that the information security community was built on and thrived because of a simple but fundamental principle: knowledge must be free.

Sell The Bugs

Regardless how good these figures may sound to you, you need to take a step back and think really well what you are getting into. Here are a few points that you need to consider before selling exploits:

• Cybercrime is not a joke – If you get caught selling exploits to a dodgy 3rd-party you may end up with a prison sentence longer than the sentence of a child molester. If you live in US or UK you could be charged and treated as a terrorist which will completely destroy not only your life but the life of your closes people.
• TAX man problems – Oh Yes! Unjustifiable incomes could get you in trouble with the TAX man. The TAX man will hunt you and hurt you.
• Broken legs and other broken parts of the body – You have no idea to whom you are selling to. Tomorrow you may wake up with broken legs and twice as poorer as the day before.
• Even worse – People will kill for a lot less than 75K. Keep that in mind.

In my humble opinion, exploit brokerage is a risky business. There is an unquantifiable risk associated with this practice and that is only due to the high price of exploits which are sold today.

Exploit Sweatshop

Nevertheless, it is just silly to believe that no one is producing and selling exploits in a large scale. Do you remember the numerous gaming sweatshops which sprung up like wild mushrooms after the recent heavy rains in 3rd-world countries? I recall seeing a documentary on a typical day in a Chinese WoW sweatshop. I remember I saw a room full of almost naked people, numerous PCs hooked up into a gigantic DIY network spreading across the entire floor. Most of the WoW accounts were fully automated, running from virtualized platforms.

The aim was simple: a) develop many characters in a semi-automated fashion by killing small animals and other things around the WoW world and b) sell the characters plus other artifacts to western buyers for a substantial amount of money. All of this can be achieved for as little as $70 a month per person. This is a remarkable business model which works extremely well.

Similarly, all you need is a bunch of programmers from India, China, or Eastern Europe to code up fuzzers and run them against as many software products as possible. At the end of the day memory corruption exploits a relative easy to detect. All you need is a crash caused by putting far too many 0×41 in a buffer. The crash is already an indication that something is wrong. It requires a bit of manual work to figure out whether the crash is exploitable. From personal experience, and by looking into the work of my peers, it takes approximately 10 days to develop a crash into an exploit. Most of the times, the exploitability factor of a crash is apparent and therefore no time needs to be wasted. Other times, a crash can be archived for future investigation when it could become exploitable given it meets the necessary conditions.

Perhaps you can do all that by paying someone as little as $70 a month as it is the case with WoW sweatshops. That is 3 times less than what I am paying for just hosting. Therefore, I most certainly can afford to hire 3-4 people right now and even double their salaries, but let’s do the maths:

# average exploit price: $5000
# number of people to hire: 5
# average monthly salary: $100
# job specs: write fuzzers

5 * 100 = $500 # a month expenses
5000 / 500 = 10 # months worth of work

Heck, I can even put this bill on my credit card and pay as little as $50 a month. The chances that I will sell an exploit for $5K in the next 10 months are pretty high. $5K is only if I go with a legitimate company. I can probably make 6 times more by selling it to a dodgy 3rd-party. The only thing I need to worry about is the risk.

Some Final Words

Finally, I know that a lot of people are into the security business because of all the romanticism and the myths surrounding the hacker figure. Things look different once you become the hacker and your day job and lifestyle are surrounded by hacking and breaking into systems of any sort. There is nothing romantic about it.

So, don’t get into trouble for the wrong reasons. If you are young and you need advice what to do with your career, contact us or contact any one who has been into this industry long enough to give you a good and sensible advice. Just don’t jump onto the No free bugs! bandwagon.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The version inside the new code repository is very different from the version you’ve seen before. The main difference is that while the old version is basically a collection of scripts, the new version implements its own shell (wrapper around bash) which does the heavily lifting and also introduces some funky programming mechanisms. For example, now you can create jeriko scripts like this:

#/usr/bin/env jeriko
# do my jeriko commands here
foreach-input | add-targets
generate-scan-batch | run-in-parallel

This is perhaps the simplest possible script you can write but you see that the jeriko shell could turn into a quite powerful feature. The shell is also a good starting point for many penetration testing jobs as it does some environment checking and preconfigures some defaults for you. The other good news is that you don’t have to learn a new programming language. Your bash skills are good for jeriko too.

Just keep in mind that jeriko is merely an experiment. However, I realize that it has already become quite useful for some people. So, if you enjoy playing with bash scripts, and you you feel adventurous, please join us and make this project happen.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

This post is merely a summary of my research work on how to build a better exploitation framework ala metasploit-style.

The Problem

Metasploit is great but there are three things that makes the framework sometimes inconvenient: it’s size, it’s dependency of the ruby platform and of course it’s speed. It will be great if for example we can take a single exploit (or a set of exploits) out of the framework and compile it into a standalone executable. On the advantage side, this type of solution will also allow us to ship the framework as a payload to already compromised systems and use it from there as a stepping stone for further propagation. It will also allows us to run exploits from compromised embedded devices as long as we can compile for their architecture, which is pretty cool.

I understand that it is possible to bundle the entire framework plus the ruby environment into one executable but such a solution is simply not elegant enough and not fully cross-platformed.

Introduction

Back in the days when Metasploit was written in Perl, there were a few other frameworks trying to do similar things but in C and C++. A solution based on C or C++ is a lot more interesting as it allows us to compile standalone versions of the framework and use them as we wish. It simply makes the framework very good for embedding and also quite suitable for delivering it as a payload to the systems we would like to compromise.

Nowadays, a C and C++ solution is often doomed to failure. The reason for this is because when building a framework you can easily get into a situation where you need to solve a pretty complicated problem. Both C and C++ lack the dynamicism and the degree of expression available in languages such as perl, python and ruby and therefore, while they remain very suitable for low level stuff, they start to loose their grounds when it is needed to build something that is more abstract and high level.

Some Solutions

Keeping all of the above in mind I started putting words into practice. In the spirit of a zen monk, I started thinking which parts of the metasploit framework are most valuable to a penetration tester so that they can be branched out. As it happens, the obvious answer is: the exploits. The Auxiliary modules are great but they represent functionalities which are already available in other tools. So, the first idea was to take the exploits and payloads out and rewrite them into something that is more suitable.

I decided to see for myself if I can prototype a simple exploitation framework in C++ that all it should so is to implement several abstract interfaces for exploit development, a a class with common methods for payloads (empty of course) and of course a simple interface to run an exploit with a payload against a target. All of this was achieved in a hello world fashion exploiting a simple stack overflow on a proggie from the command line and of course without the need to circumvent any protection mechanisms in place.

Although I was pleased with the result of the prototype, I was not convinced that this is a good enough solution. Programming in C++ is fun, especially when you haven’t done it for a couple of years, but still not as practicle as I would like it to be. We can most certainly build a DSL on the top of C and C++ by using Preprocessor Directives but when you are developing an exploit you want to make the process as painless as possible and C directives are only making it worse when hunting for a bug in the exploit. Not to mention that compiling something every time you make a change is not cool at all.

Being a pythonist and knowing the python mantra inside out, I thought that it should be possible to write all of the exploits and payloads in python and convert them into C or C++ at later stage as long as I stick to using a minimal set of the language features which can be directly translated with regexes and some basic parsing. After all, python looks like an executable pseudo code. Luckily for me, such a solution already exists and it is called shedskin.

Now shedskin is a lot more than a simple python to C++ translator. Not only it can convert a python program to C++ source but it also implements all of python’s builtins and it has support for some of python’s most useful modules such as re and socket. On the top of that, it is trivial to implement additional modules to the shedskin framework in python. This is a product I will happily pay for!

Analysis

I played quite a lot with the shedskin compiler tweaking things as I go. Although the parser is pretty advanced there are some restrictions enforced on the language. All of them are nicely covered in the shedskin’s tutorial.

It was time to see if I do need the advanced python features for developing the exploits. I run through all Metasploit payloads and exploits and a pattern started to emerge. The majority of the exploits were pretty basic. They all came down to the following algorithm more or less:

1. Select an exploit
2. Pack a structure/payload that will be sent over a socket or will be dumped into a file
3. Send/Save the payload

Obviously, there is no need for python sugar to implement that.

The Design

I did quite a lot of work investigating the best approach to tackle the problem of creating a good enough exploitation framework and I came up with the following basic idea:

We start with the same basic building blocks as found in metasploit. We need abstract classes for Exploits and Shellcodes and also classes that implement them to define more functional classes such as those that needs to be implemented when writing remote exploits for example (socket stuff). We use the basic python capabilities keeping shedskin in mind. As I mentioned, shedskin is quite advanced so most of the functionalities can be implemented without even taking it into consideration at all.

That will provide the core of the framework. All of the exploits now can be written on the top of this. The exploits themselves should reuse as much as of the builtin methods as possible as that their portability will be guaranteed.

A layer above that, we write as much as python sugar as we want. We simply don’t care how we are going to write it because that part of the framework doesn’t have to be compiled.

In summary, we layer the whole thing like this:

• Layer 01. Core Exploit Development Classes implementing the most basic set of python features
• Layer 02. Exploits implementing the Core Exploit Development Classes
• Layer 03. Python sugar to glue it all together

Conclusion

So, it is possible to write a good and well-designed exploitation framework in python that allows exploits to be separated and compiled in standalone native executables. Not only that, but we do not sacrifice from the dynamicism of the python language as while the core will be written in basic python, the rest will be as dynamic as we want. Imho, this is all possible due to python’s mantra that there should be one– and preferably only one –obvious way to do it. It just makes it easier to write briliant tools such as shedskin.

Although I am quite excited to start writing such a beast right a way, I am going to pass this time. I am starting to learn to say NO because I’ve got far too many things on my plate already. However, if anyone is interested in working on this, I will be very happy to facilitate the project as much as I can and give a hand where necessary.

I am very interested to hear your opinion and I am even more interested to get the opinion of the Metasploit team as they have a lot more experience in coding exploitation frameworks than me.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

There is no merit in discussing how this has been done and for what purposes but this incident is yet another proof that the attack landscape is rapidly changing and moving towards web enabled infrastructures and the client-side. Soon or later almost every website will be equipped with social capabilities (google’s own opensocial and friendconnect platforms) and than simple persistent XSS attacks will turn into quite nasty problems.

Time will tell!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Recently I had to communicate with a MSSQL server on a pentesting job. For that purpose I’ve downloaded sqsh. Unfortunately the tool failed with a linking error. So I decided to go and download the sources and compile. I did that but the build failed because my environment was lacking certain unusual environment variables the tool needed to build successfully. Alright, running out of time, I decided to check whether there are other tools for SQL server. I found dbishell which is a tool written in perl. I run the tool for Sybase backend but it complained that I am missing libraries. So I downloaded the dbi sybase perl libraries and installed them. I run the tool again but it failed with an error. It couldn’t display the error because I was lacking another perl library.

Ok, that was ridiculous and I desperately needed a solution. So I came up with something I do not normally do. I checked PHP’s sybase integration online and I found that it is relatively straightforward to communicate with MSSQL backends from PHP scripts. I wrote a simple script to bruteforce the login with several passwords I had at hand. Once I found the login, lucky me, I wrote another script, again in PHP, just to dump various information from the database such as other database users and their hashes. Lucky me!

In summary, I spent ridiculous amount of time trying to make established frameworks and tools to work while I could have saved all the hustle and started with PHP from the beginning.

The reason I am telling you this story is because I have an important message convey here: Tools are just Tools! If metasploit cannot exploit the vulnerability perhaps you can create something yourself. If nessus fails to detect a problem, perhaps there is another approach you should use to handle the situation. We often start a new framework or tool and suddenly decide that it should handle all situations. Well that is virtually impossible! The situation always change.

So, don’t stick to a single tool just because it works 80% of the time. And don’t waste time trying to make the tool work in the rest 20%. It is pointless, especially when you are dealing with frameworks. There are a lot more solutions out there you can employ to solve your particular problem. These solutions may not be elegant and perhaps they are written in something as unconventional as brainfuck, but they are solutions nevertheless.

Remember, tools solve problems! If a tool cannot solve the problem it is no longer a tool. It is a useless blob!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Anyway, now you have a few more scripts at your disposal. The most notable changes are the ability to discover service versions via extract-services, the ability to discover and generate URLs from services which offer HTTP (courtesy of generate-url-batch, expand-url-credentials and expand-url-dirs) and the ability to grab screenshots of all web servers via scan-browsers.

Personally, I find the scan-browsers script extremely useful. Let’s say that you encounter a bunch of web servers but you don’t know what they are for. You can fire the browser and start executing URLs one after another but that will take time and you can easily get confused. Instead of doing that you can do the following:

$ generate-url-batch | scan-browsers

This command will iterate over each discovered HTTP server and take a screenshot of the front page. The script can be safely executed even in environments which do not have the X server installed. In fact, you do not need it at all, because the script relies on a virtual framebuffer server.

After the command completes, you will have your current working directory populated with the screen grabs. Now you can use your default picture viewer to see all web servers quite rapidly. This script is also handy in pentests when you need to take evidence of particular vulnerable web servers/applications.

Although Jeriko is already useful, I am planning to totally redesign the platform. Future versions will have more granular control over the pentesting process and the ability to automate large chunks of boring activities.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

We often laugh when a new buzzword makes its rounds in the media but the matter of fact is that buzzwords are important. In essence, buzzwords are just terminology which happens to be used extensively by the media. I find it funny to follow rants of people who are obviously against buzzwords but they make use of buzzwords themselves. If you are against them, just don’t use them. I am curious to see how you are going to find a common language with the rest of the world.

Here are a few examples of security buzzwords which are considered an everyday terminology nowadays:

• Null Pointer Dereference
• Cross-site Scripting
• Rebinding Attacks
• Botnets
• Storm Worm
• Virtualized Rootkits
• there are tones more…

They are buzzwords because at some point they were virtually all over the Web. Today’s buzzword is Conficker. If you find something new and intriguing it most certainly will become a buzzword. Is that really that bad?

Q&A with the Public

I have a question to the public. Dear Reader, what do you call a script injection exploit which happens withing the boundaries of the browser’s chrome?

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Jokes aside, tools like this one are quite helpful to brainstorm new ideas. If you ever do research inspired by our buzzword generator, please give us a credit. That way we will know that the tool is actually useful.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The reason we had to come up with something like this is because most of our projects are dispersed across several Google Code repositories, personal SVNs and many other places. We have started so many ideas in the past that now it is hard to keep track of everything. Also, many people ask us for the source codes of old projects and we simply don’t know where to point them to.

Not everything is added yet. I will continue to put stuff in as they come!

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

It is mostly persistence that plays a role. Most of the researchers I know have almost zero knowledge on the subjects they dive into. The knowledge builds up with the time and by being more persistent on the topic of exploration regardless of its difficulty level.

Simply put, the more time you spend on something, the higher the chances to find oddities. It sound quite logical, don’t you think? Countless of examples already exist to prove my point.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The shell is defacto the interface to your operating system. Over the years it has turned into a very powerful machinery heavily used by programmers, hackers and system designers around the world. It is simply the ultimate environment. There are plenty of tools to support it. It is remotely accessible. It is simple, yet extremely powerful.

Because I am quite aware of the power the shell provides, every time I see another pen-testing framework which implements its own shell (obviously a lot less powerful in nature) or anything else shell incompatible, I am shaking my head in disapproval. Where are my pipes? Should I ignore the plethora of good pen-testing tools sitting on my box just to use your custom shell. Obviously, not!

Penetration testing frameworks today turn into unmaintainable monsters: abstractions, and deep inheritance all over the place; dependency nightmares and monolithic cores which no longer interact with the shell so nicely. They try to be the ultimate framework but fail immensely as they cannot be what the shell and the OS already is (i.e. a framework) simply because there are a lot less man-hours put into them and they are a lot less diverse in terms of code and originality.

Over the last couple of days I was busy with putting a small set of command line utills in the spirit of some of my previous two experiments in the same sphere of study: Infocrobes and Bashitsu. The toolkit (also known as Jeriko) currently resides within our random source code repository which contains random codez which hasn’t materialized fully yet.

The reason I wrote it is because it was fun but most of all I wanted to showcase that quite many advanced things can be achieved with a few bash scripts wrapping around common pen-testing tools. For the rest of this article we will explore some of the features of this toolkit and discuss how it can be extended upon (as it is no where near complete but it is a good start, imho) and used in various quite basic pen-testing scenarios.

Let’s start with the common stuff: automation of port-scanning and vulnerability assessment. We will start by adding some targets:

$ mkdir pen-test
$ cd pen-test
$ targets-add target.com
$ targets-add << EOF
more-targets.com
10.10.10.10
10.10.20.0/24
EOF

Now we have a bunch of targets. You can also remove targets by executing the targets-rem script which usage is exactly like the targets-add script.

Once we have a bunch of targets we might want to expand them into usable IP addresses/ranges. Keep in mind that our targets list is a mixture of domain names, ip addresses and CIDR ranges. We are going to use another tool part of the collection which will convert all of this into something that we can use:

generate-ip-batch

This tool actually wraps around nmap and outputs everything onto the screen. It is not useful unless we pipe it into something. We are going to use another script for that: generate-scan-batch. This script will execute generate-ip-batch and pipe out a list of commands for performing the basic penetration tests. The list will look something like this:

scan-ports-tcp-full [ip]
scan-ports-udp-full [ip]
scan-vulnerabilities [ip]

Ok, this can be piped now into our run-in-parallel tool which obviously runs things in parallel in order to speed up the process. This is how we do it:

$ generate-scan-batch | run-in-parallel

We can customize the run-in-parallel script by either by modifying .jerikorc resource file or by going the bash way like this:

$ RUN_IN_PARALLEL_MAX_PROCESS=32 generate-scan-batch | run-in-parallel

Luckily for us we can also supply this information as command line arguments like this:

$ generate-scan-batch | run-in-parallel 32

If you read the source of run-in-parallel script you will see that it is no more then 40 lines of code packed with quite a lot of power. This is what the shell gives you - excellent way to manage processes.

Once all tasks are completed, we should have several work files into our directory. We can now parse them with a set of basic command line utilities which are prefixed with extract-. In order to extract open services from both gnmap and nbe files we use extract-services-gnmap and extract-services-nbe respectively, like this:

$ cat *.nbe | extract-services-nbe

How about exacting all services that has something to do with SSL? This is how we do it:

$ cat *.nbe | grep -i ssl | extract-services-nbe

That was easy but we might want to correlate all results. It is easy once you know shell scripting. The following script does it for us.

$ extract-services

Basic indeed! Let's now mirror the front-page of all HTTP servers. We might want to do some analysis on the results. This is how we do it:

$ cat *.nbe | grep -i http | extract-services-nbe | awk -F, '{ print "http://"$1":"$2 }' | scan-urls

This will mirror only the front-page we can do a lot more. How about making a copy of the first 10 levels? This is how we do it:

$ cat *.nbe | grep -i http | extract-services-nbe | awk -F, '{ print "http://"$1":"$2 }' | WGET_URL_SCAN_METHOD="-l10" scan-urls

Alright! Now we have mirrored all HTTP servers. Let's analyze them:

$ find ./ -type f -exec cat '{}' ';' | extract-emails

This will give us all emails that we have encountered. How about retrieving everything that looks like IP address which we can add to our targets list:

$ find ./ -type f -exec cat '{}' ';' | extract-ips

There are many more utilities which can extract things from files. We can even look for name/title looking strings and feed them to our whois scripts in order to find more about the organization we are pen-testing. This is how we do it:

$ find ./ -type f -exec cat '{}' ';' | extract-names | scan-whois

Easy! Once we've done the basic analysis and we have identified several issues and other things and we have the permission to go further we can autopwn all targets. This is how we do it:

$ autopwn-services

This tool simply wraps around metasploit's msfconsole. However, because msfconsole is yet another shell we might want to send the entire process back into session from which we can detach. This is useful for many reasons and this is how we do it:

$ session-start autopwn-services

If we press CTRL+AD we can detach and continue with our normal pentesting tasks until all services are fully exploited. Then we can resume by doing the following:

$ session-list
$ session-resume [name]

The output of the autopwn session will be saved, which is great as we might want to do further parsing abd later-stage analysis on the data.

There is a room for a lot more tools to be written. For example we can quite easily put ettercap/tcpdump into use for capturing browser cookies off the air and feeding all the information into a simple command line tool which will switch us to a different browser session depending on our choice. We don't need to write yet another framework for this. Most features already come by default and can be used if you know how.

Keep always in mind the following: don't write something someone else has already written for you unless this other product is complete crap and it needs replacement. Also, think whether your tool integrates nicely with other tools. The more integrated it is, the more it will be used in combination with others. And this is quite important.

So yes! You don't need to write everything from scratch. You don't need to mimic screen, script, wget or any other common tool unless you have no other choice. The ultimate pen-testing framework already exists within the most basic components of your operating system.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Why is this interesting? Well, it is interesting to Python developers/hackers only. The fact is that there are a few HTTPS-enabled proxies with tamperable capabilities for Python. However, none of them are actually easy to use or even reliable enough for my likings. Not to mention that none of them were designed to be extended upon. While it is true that my code hasn’t bee fully tested, and there were some tiny issues already reported (to be fixed soon), I find the code a lot easier to work with as you will see later in this post.

So, let’s make a proxy. First, you need to get the httpservers.py file from here. Make sure that you get the latest version from the SVN. Let’s start with a simple example:

import httpservers
import SocketServer

class Handler(httpservers.SimpleObservableProxyHTTPRequestHandler):
	def observe_request(self, data):
		print '>>', repr(data)[:100] # observe browser requests
		return data

	def observe_response(self, data):
		print '<<', repr(data)[:100] # observer server responses
		return data

class Server(SocketServer.ThreadingMixIn, httpservers.SimpleObservableProxyHTTPServer):
	pass

print 'Starting server on localhost:8080...'
srv = Server(('localhost', 8080), Handler, '/path/to/cert/file')
srv.serve_forever()

In order to make this work you need to generate a self-signed certificate like this:

openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

...and replace '/path/to/cert/file' with the path to the certificate.

If you execute the above snippet, you should be able to get the proxy running on port 8080. Every request that you send will be outputted on the screen with the prefix >>, while every server response will be prefixed with <<. Keep in mind that I am not displaying the complete request/response (repr(data)[:100], only the first 100 characters) because I don't want to clog my screen with too much data.

So far, so good. Notice that observe_request and observe_response methods return the received data like that: return data. This is very important! These methods not only can sniff the data but they can modify it on the fly. For example, we can inject additional JavaScript for each server response by doing something similar to this:

def observe_response(self, data):
	return data + '<script>/* javascript here */</script>'

The example above is not complete because we don't want to append the string to each response but only to those that have mime type of text/html. Nevertheless you get the picture.

The good thing about observe_request and observe_response methods is that they both operate on raw data, i.e. they use the actual data that is sent through the server and client sockets. There is no intermediate layer in between. This is very powerful as we can guarantee that our modifications are not modified by code which tries to be RFC compliant for example. In that respect we can completely screw up the requests and responses. This is important if we want to write some kind of a fuzzer or even a tool that deal with data at socket level. This feature actually lacks from most proxies and this is the reason why I tried to implement it in mine.

Because we deal with raw data, we need to parse it in order to get the useful bits and pieces out of it (of course only if we need to). This is quite simple. Future versions of my code will contain a helper method to do this but for now you can use something like this:

import StringIO
...
...
	fp = StringIO.StringIO(data)

	request_line = fp.readline()
	headers = self.MessageClass(fp)
	data = fp.read()
	...
	print self.headers['host'] # will print the host

...and we print the Host header. I told you that this is going to be easy.

This is pretty much it. There is no point of explaining further because the implementation is self-explanatory.

Due to high-load of projects and other internal developments we are looking to expand our team with 1-2 new editors. If you feel that you can contribute to this blog and our community, do not hesitate to get in touch with us.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

http://www.gnucitizen.org/static/blog/2009/02/httpservers.py

I am quite pleased with the end result! Although my proxy hasn’t been heavily tested, I find the code lot better when compared to Dave Aitel’s SpikeProxy (sorry Dave :)) and extending/adding functionalities is actually piece of cake.

I need to mention that the code is heavily inspired by various source codes found on the Internet via Google. Actually all SSL MITM Proxy code for python available today are absolute crap. Codez are either broken or you need to be a rocket scientist in order to understand them. Nevertheless, these sources proved to be quite helpful when I was stuck. And I was stuck many times.

My module also contains stubs for creating all kinds of HTTP servers. It follows a simple design pattern introduced by Python’s built-in SocketServer, therefore the code is very pythonic. I need to mention that I used monkey patching only once and it can be removed as it is unimportant. So overall, the module should be pretty clean although there is a room for improvement.

Have a look at the code and if you can contribute with fixes and improvements that will be great. Just let me know.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

So you receive one of these phone calls. The girl on the other end presents herself as Jessica Smith. The company has to do something with financing. The conversation goes as usual. She explains that she is calling in regards to a recent well known court case in UK in which major banks were made to return to their customers various service charges they have collected over the years, plus the reflective 8% of interest for up to £1000. She will send you the forms, which you have to fill in and send back. The background noise from her side hints a busy call center. It feels legitimate. In fact, it feels like you are getting a call from your bank. All that you have do is to give away just your address and full name and this is only because of the data protection act as you are kindly informed on the phone.

Most people will happily give away all the information. A reasonable person should ask for confirmation that the person on the other end is in fact entitled to receive personal information. Unfortunately, most of the time you cannot get such confirmation because in order to confirm that they need to get your details to unlock your details even though the organization that is calling you is completely legitimate and they already have your details. Complicated! So you get into this very awkward, twisted situation where there is no way out.

The best way to deal with it is to ask the person on the other end to give you their details. Then you have to do some research and if all looks good you can pretty much trusted them to a degree, depending on your likings. It is not very convenient, is it?

The problem here is in the process. Situations like the one described above happen every day and this is the problem. We get used to the process in the system. Obviously the system is flawed and as such it can be used for illegitimate purposes quite easily. I imagine a typical identity theft attack may unfold like this:

1. Ring a random number. Simulate background noise from call center. Tell the victim whole a lot of crap about the data protection act and how you really care about it but unfortunately you have to get their name and address.
2. Send them mail. This stage softens the next cold call.
3. Ring them again. Get more information.
4. Repeat all steps until you are satisfied!

Nigerian scammers are way behind similar attacks, which imho should be a lot more successful.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores