05-28-2013, 10:22 AM
Hi!
First of all, Atom, everybody,
Thanks for feedback this clear and straight but still constructive.
Well, let’s start from organizational part. For sure, we f***ed up the organizational part. There are a lot of reasons to this, most of them “we wanted to make something awesome†gone terribly wrong with contractors and we had to make everything in a very short timeframe from the beginning, like website, scoreboard, uploading and processing on a trashy, nearly dead hardware. From contestants point of view that was a huge fail and we are not going to deny it. From some other point: we had no sleep at all for several days trying to make the contest up and running, and in the end we somehow managed things to be ok.
About patterns and hints
Actually, the approach with lot’s of same plaintexts and strictly defined themes was an attempt to compensate hardware requirements for participants. To create a way to successfully crack hashes not only by using lots of calculation power, but to think and analyze given data. And despite the small number of contestants several small two-player or even lonegunman’s teams were able to compete and crack more than half of all tasks. Call it bad or good, that was a thing we intentionally choose to give a try.
The hints. They are a lot of them in real life. Pentesting you are always working with some company in some industry with different fields of expertise: it can be a depository, holding or power station, oil refinery … not mentioning the obvious like banks, shops, etc. Any generic headquarter office user use “more†common passwords and if you get closer to “workersâ€, engineers, operators and so on you’ll start to meet a lot of “specific†patterns in people’s passwords. When we are fighting with some important hash we are not bruteforcing, we are trying to create some targeted wordlists for mutation. To add that not only specifics is crucial but language too, transliterated and different layout passwords are very common and could hardly be guessed without hint in contest.
In collision of this two approaches predictable and limited plaintexts appeared at contest. Now we can see that we definitely liked it as an experiment, but will we keep the _same_ approach next year? We’ll see and more importantly, not only you, we hope others will mention their views on this.
Yes, it was too much connected to patterns and your critics is eligible. Some part of the _cracking_ itself was ruined. Immediate idea how to patch current approach is to add much more themes of smaller sizes and don’t use duplicate plaintexts between algorithms. What do you all think, will it make a big difference?
About teams
The huge and separate topic is about complete domination of top teams. In case of contest: How it is possible to control the real amount of team members or individual efforts? Or maybe how people can introduce more teams like top one’s?
To be honest, I see it as feature of subculture right now and this is a nice thing.
Things that didn’t get to production of hashrunner
We discussed adding non-obvious (khm, real life) ways of acquiring hashes, like sql injections, rce’s, lfi’s, binary exploits, running post exploitation tools, but this would led us to even more shifted focus from hash cracking even though we thought of giving away scripts and exploits for this.
More, during pentest you don’t need to crack all the hashes you acquired. It’s always about privileged user one’s (most of the time). We planned to add several “Administrator†hashes to some packs that logically (in case of real pentest) should have brought you the points for all pack (as you compromised the system), but again, that will not be fair in case of hash cracking contest. The only way this could be ok, if we add dozens of different input packs for contest.
Outro
Broken hashes (i.e. blind sqli’s struggling with special chars or developer bugs), locally forced to use or used hashing algorithms (hashcat introduced GOST support) and newly introduced ones (skein was in the initial list of contest, keccak get there). That’s for start about the improvements not mentioning your teamwork and we hope fun.
At last,
First thing we did preparing a contest – a decision to make things different and to experiment.
And again,
Thank you for feedback,
hashrunner team
First of all, Atom, everybody,
Thanks for feedback this clear and straight but still constructive.
Well, let’s start from organizational part. For sure, we f***ed up the organizational part. There are a lot of reasons to this, most of them “we wanted to make something awesome†gone terribly wrong with contractors and we had to make everything in a very short timeframe from the beginning, like website, scoreboard, uploading and processing on a trashy, nearly dead hardware. From contestants point of view that was a huge fail and we are not going to deny it. From some other point: we had no sleep at all for several days trying to make the contest up and running, and in the end we somehow managed things to be ok.
About patterns and hints
Actually, the approach with lot’s of same plaintexts and strictly defined themes was an attempt to compensate hardware requirements for participants. To create a way to successfully crack hashes not only by using lots of calculation power, but to think and analyze given data. And despite the small number of contestants several small two-player or even lonegunman’s teams were able to compete and crack more than half of all tasks. Call it bad or good, that was a thing we intentionally choose to give a try.
The hints. They are a lot of them in real life. Pentesting you are always working with some company in some industry with different fields of expertise: it can be a depository, holding or power station, oil refinery … not mentioning the obvious like banks, shops, etc. Any generic headquarter office user use “more†common passwords and if you get closer to “workersâ€, engineers, operators and so on you’ll start to meet a lot of “specific†patterns in people’s passwords. When we are fighting with some important hash we are not bruteforcing, we are trying to create some targeted wordlists for mutation. To add that not only specifics is crucial but language too, transliterated and different layout passwords are very common and could hardly be guessed without hint in contest.
In collision of this two approaches predictable and limited plaintexts appeared at contest. Now we can see that we definitely liked it as an experiment, but will we keep the _same_ approach next year? We’ll see and more importantly, not only you, we hope others will mention their views on this.
Yes, it was too much connected to patterns and your critics is eligible. Some part of the _cracking_ itself was ruined. Immediate idea how to patch current approach is to add much more themes of smaller sizes and don’t use duplicate plaintexts between algorithms. What do you all think, will it make a big difference?
About teams
The huge and separate topic is about complete domination of top teams. In case of contest: How it is possible to control the real amount of team members or individual efforts? Or maybe how people can introduce more teams like top one’s?
To be honest, I see it as feature of subculture right now and this is a nice thing.
Things that didn’t get to production of hashrunner
We discussed adding non-obvious (khm, real life) ways of acquiring hashes, like sql injections, rce’s, lfi’s, binary exploits, running post exploitation tools, but this would led us to even more shifted focus from hash cracking even though we thought of giving away scripts and exploits for this.
More, during pentest you don’t need to crack all the hashes you acquired. It’s always about privileged user one’s (most of the time). We planned to add several “Administrator†hashes to some packs that logically (in case of real pentest) should have brought you the points for all pack (as you compromised the system), but again, that will not be fair in case of hash cracking contest. The only way this could be ok, if we add dozens of different input packs for contest.
Outro
Broken hashes (i.e. blind sqli’s struggling with special chars or developer bugs), locally forced to use or used hashing algorithms (hashcat introduced GOST support) and newly introduced ones (skein was in the initial list of contest, keccak get there). That’s for start about the improvements not mentioning your teamwork and we hope fun.
At last,
First thing we did preparing a contest – a decision to make things different and to experiment.
And again,
Thank you for feedback,
hashrunner team