Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/401 Thanks!
Hello, C.C.C., I'm Tanya Miller,
and I'll be talking about unhatched,
which are matters for better password
cracking.
So the core of my
talk is my research into
how to automate boring stuff
for checking passwords, online systems
and improve password cracking
attacks against offline passwords.
The idea is to contribute and create
elements that are reusable that can
be simply integrated into other tools
like metal sport or any other tool
with openness and
usability in mind.
So let's start first with the psychology
of passwords. What kind of passwords
exist?
First, there are some default passwords
or default back doors that somebody
was smart enough to integrate into our
system like roots support admin and so
on.
They are real passwords because
people need a system to remember
a password.
Each of you has a system how he creates
a password, how he remembers
the password. Right.
So people use combinations,
mutations, they add words, they
have their own ways
and they are pseudo random passwords
because you cannot say that a password is
truly random in
case in some special cases maybe.
But something like this, if somebody can
memorize this one, that's awesome.
But usually I can't.
And that's why we have systems to
remember passwords.
So the talk is split
into two problems.
The first problem is the boring one.
So we put the interesting thing in the
back.
The first problem is how to check systems
for default passwords on network devices
like Rodgerson switches,
how to check for embedded back doors,
big doors, not in the case of programatic
or big doors, but backdoor passwords
that somebody left an account.
And the third one is how to obtain data
from automated attacks.
So,
oops, the
boring problem here is default passwords
from devices.
Each of you has a router at home or
some other type of device.
Usually they can be configured for
a default password.
That problem usually is manifested
in production via some kind of a
forgotten device.
In a situation. We need wireless right
now. Just leave a device and let's get
it working in testing systems
like somebody there is a database.
There is one username
and password combination that is for the
database admin, other one for the sys
admin and the second one never gets
changed or with sloppy configurations.
That's a boring problem.
The mildly interesting problems are big
passwords and collection of data
of attacks in the wild.
So if you want to collect
default user and password pairs,
the one of the ideas
I did was just simply scrape all default
pastoralist's. So I would like to first
thank all the nice guys from Fener Elite
certain at liquid matrix decks
need security, override Ditlev
their password lists of default devices
on the net
they're called, and of course organized
and weighted by occurrence, which is
useful to test if a simple device
has forgotten passwords.
Ordering collected
data by occurrence is the only
useful metric we have for analysis
of default standard passwords.
If you have an idea for a better one,
I would like to hear because if a
username and password pair is more common
like admin, admin or admin without a
password, it will simply float to the
top and it will be tested sooner.
So this saves time.
Other metrics can be by vendor
or by device, but that usually doesn't
cover a use case.
We want to have, for instance, testing
for forgotten devices, testing for a week
devices, and somebody will say,
why would you want to test online
devices? What if somebody has failed to
Ben or SSA jugaad?
Well, they certainly then
they didn't leave the default
passwords in place.
The code for this simple thing is
available on GitHub.
You can use it. And also it is available
and metal support framework as
default user password services and hash,
if you trust me, maintenance of the
this part.
The mildly interesting problem are hard
coded back doors.
There is an interesting story.
I obtained the B storage device,
which is sun storage device,
that after some time
there was this interesting
post on the net that somebody found
embedded back Dorson HP storage devices.
And guess what? I tried the default
username Higbee support and the password
birgersson lead.
And you can of course access
the administration part Valerius
at this year's blackhead posted that
almost all airport security controls.
Like access control devices
that say that enable
opening of doors or who is registered
on the floor from the staff or like
things like the Morphos atomizer, which
is a device that scans for narcotics or
explosives when they swab you,
that they have integrated back
doors. Those are the usernames and
passwords. And of course, all of those
devices are networked.
Unfortunately, the trend of
embedding usernames and passwords
as big doors is starting to
take more and more,
uh, more and more trends.
For instance, how many of you
know about the last year's
leak of our popular
VPN firewall antispam
vendor, which embedded multiple
backdoor accounts into their devices,
for instance? The best part was my
MySQL database
with a default user product and the
password, which was blank with
a remote S.A.G.
with remote
access capability.
Does anybody remember that?
Well, the problem is that
this is starting to
be a bigger and bigger problem, for
instance,
those kind of devices cannot enjoy any
privilege of being secure.
I cannot believe that somebody would want
to use them. I would like to say at
least people start auditing stuff
that you own.
But when I say own, I don't mean
own as in a bad stuff.
But please first consult your lawyers,
your local laws, because that
can bring you all sorts of trouble.
The third one is for online attacks
is how to collect data sets from
attackers.
If you want to collect
data that is used on online attacks,
for instance, what about let's
use one interesting part of this
is you can use BOT, which collects
data from SSA honeypots.
So if you run keep or some other honeypot
technology, please ship data to them.
It will be more than useful.
And that enables you to collect
information on public facing brute force
attacks.
And when you download all
the username and password combinations
that are used, you start to see some
interesting patterns.
For instance,
very popular with the high number of
hits is rude and
let's say and let it be anonymous.
A router vendor name plus four to six.
When you Google it, it's not a default
password you cannot find.
It is a default password.
The second one is Eurail of a popular
ISP, plus some random
string.
Third one is twice the research
cooperation STEM and some other
combinations that you cannot find
as default starting passwords
of some systems.
Now, there is an interesting question.
How those big doors or did somebody
have an inside info on how to break some
systems and just simply tries everything?
Let's not jump to conclusions, but I
would ask all of you that are interested
in such things just to take a look at the
public facing attack data and you might
find some interesting stuff in there.
Why are we losing on this front?
Because let's be simple.
We can't have one centralized repository
that will collect all non Back-Door data,
all known backdoor passwords, online
passwords.
When you take a look at any tool
that has some password lists for testing,
you'll see that you cannot find from
where that list came, who created
it for what to use case.
Why should you use it?
There is no exploratory data that will
say from
how the password list was created
and there is no way you can integrate it
mostly with other tools and there is no
updates and so on.
Reading full of requests of GitHub is not
an idea when you want to see how
something end up ended up in the one
tool.
This is a manual process and as you see,
this part is boring.
Nobody can be bothered to add
passwords or maintain those lists.
So I am really have highest
regard for people that maintain those
lists because somebody has
to do it.
And I would like to just say one thing.
We need a centralized repository of that
stuff.
Let's maintain one repository, not six
repositories of those data that are not
connected.
Let's enable it to be easily integrated
in tools and let's enable
the data to be vetted.
So if you want to work on this, just
contact me and we'll figure something out
from the boring part to the interesting
part, how to speed up cracking
for a non pseudo random passwords.
Let's first find out how people create
passwords. That's the question.
If you can see how somebody creates his
password, then
you can probably create a better attack.
Why should you want to do that?
Because that's also connected
to another thing.
You want to create word lists or other
data that is targeted for specific
class of users.
For instance, if somebody wants to take
people here, he'll use
security activism,
31 Citrix and other keywords
and data derived from that to enable his
attack.
So what choice do we have when we
want to crack a lot of cash, when
we want to crack passwords first is
always the simple one and always the most
fun one. Build a faster cracking machine
like multiple use multiple
processors, building clusters and
so on.
The second way is to simply attack
the algorithm.
For instance, before algorithm was
known to be that you can break it
with a pen on a piece of paper.
Third one is bypassing,
which means use something like the hash
tags, differential power analysis, or do
all the things that NSA does to simply
obtain the password somehow from the
machine without any interaction
on cracking the real password.
The third one is just brute
force the password to
a smarter attack.
Then people use the word less than the
rule files.
Then they use time memory trail of
attacks.
Like rainbow tables,
then they use Markov attacks, mask
attacks, fingerprint attacks or something
else.
So with a mandatory exclusive reference,
people create passwords like this right
past phrases.
How can you crack it with a normal tool?
It's a little bit more difficult, right?
So I wanted to create something that you
can write something like this, which is
an actual real file that will say,
oh, just palmitate, all four
words from a word list and let's see what
comes out of it.
Right.
The idea behind that was a data driven
approach. So
how do you learn how people create
passwords? First you need data
and data is,
believe it or not, hard to find the net,
at least quality data.
Some of the nice people on the Internet
contributed to a lot of good research
data, which means clean passwords
with occurences.
There should be raw or all
plaintext, not just a snippet or some
fish parts,
which means that you need that your
choices are really limited.
The learning set was 32 million
passwords. That means 14 million unique
passwords, which were all
Cyrillic, Greek and other lettering
was dropped out because I
didn't want to include those languages
in the learning process because I don't
know them real well.
And the three biggest lists
that were available was RockYou,
BBB and Yahoo!
Lists. Anybody that does research
password research knows those lists as
popular public lists.
The verification data was two sets of
lists. The first one was LinkedIn, which
is the second biggest leak after RockYou,
and third one was from elite hackers
Carter Cissie Hack five and MySpace
pages.
The idea was, first, let's
use a machine learning algorithm and
figure something out, which failed
miserably,
and after that
I created something called sieving, which
is the following idea.
Just create a classifier for each
identifier to identify the password.
Plus, you cannot, uh,
classify all passwords.
You can't figure out how all passwords
are created. Let's just see a subset,
the classified that can identify a
subset.
And then for each of the classes, grade
one classifier decide
which ones are probably the most
correct ones, which ones were
right, and then dump everything in a
format that enables analysis.
These are some paired classes
that identified weak patterns, like just
repeating some letters on the keyboard,
keyboard patterns.
Some really passes the
thought that were really strong, really
keyboard patterns and the pursuit of
random password you saw on the first
three or four slides was actually
a keyboard pattern.
It looks like a really strong password,
but it's created by just following
keys in a sequential way
on the keyboard.
There also you can see all kinds of
stuff, mutation.
That's anything that changes the word
change over into zero,
change into one and so on or combination.
Just combine a few words, combine a few
elements, or just simply
use elements.
When you're receiving, each of those
classifiers can be iterated and
you can tear password's apart.
The second problem is how to identify
languages. For instance, if you say
security, you know that it's popular
in all languages. But how can you say if
you say something like bludge,
which is what is that?
How can you identify that word?
So if you want a good word list, you
simply can't rely on things
that are available.
First off, Google and Gramme corpuses
are too big.
Same thing as with spelling they
spell, which fail on one thing.
People don't create passwords by using
grammatically correct sentences.
There's all kinds of stuff.
For instance, info
about
things from a popular series like names
of characters, names of
places from popular books
or so on.
So one ideal source is Wikipedia,
because Wikipedia has
all kinds of articles
that are not really
bound by language.
Right.
So I dumped English, German,
Croatian, France, Spanish, Italian
and Dutch Wikipedia.
And this created the big
password list that can be used to
identify characters and
to improve on Wikipedia.
Google has Wikipedia
has about eighty four main categories
that identified, and they use those
categories to scrape fifty first results
from Google to improve
on the Wikipedia dump
to enable you to create password
lists from Google searches.
I created a small script called Je
Wordlist, which will scrape top
and Google results based on Keywords
or Google Docs or Google Hex, how
you want to call them, which you can
enter.
This will also create the word list based
on the currents that you can just simply
pipe into a password
cracking tool or anything else that you
want. So why do you need this?
Because usually if you use that,
it will be more effective than if
you use a generic word list.
If you're attacking security researchers,
you can use, for instance,
dead data, which will have specific
specific information or specific keywords
that they might use.
Right.
And of course, you can recurse
you can take the
resultant list and then recurse on that
and create an even bigger list.
That's an iterative approach.
First you I'd known
elements with the sieving algorithm
you create a rule is the composition
and you collect all the data.
How do people how a person created
the password, what words did he use?
What numbers, what replacement's, what
mutation's, everything.
If you have something that is unknown
story, to analyze it later and create a
new classifier, and
when you're done, you have a set of
classifiers, an algorithm that can
classified.
In practice, this looks like this, so
you put something that looks like a
strong password and it will tell you it's
a keyboard pattern, if you look
at your keyboard, you'll see that
somebody just typed sequential
keys on the keyboard, pressed shift,
for instance. Other weak patterns can be
identified and you can see how people
create them or a complicated password.
Something like this will
be disassembled and you will identify
all the elements of the password, which
can be written down as a rule
for hash like this.
So this here that you see
is a genuine rule for the hash
tool that can that can be executed.
And it will result in
using, for instance, number one for
is a dictionary of
numbers like the four dictionary
length. Eleven is all words that are
have length. Eleven are a
replacement to replace I with
one, replace all with zero
and Starland four is
a dictionary with all strings
of length.
Four in the data mining process.
When the sieving algorithm classify the
passwords, I collected all the data.
For instance, all the numbers that were
four in length were collected and
after that you have a word list that is
based on the currents over the top
used numbers.
How people what's the probability
that somebody will use the number?
Rules are supposed to be expressive in
a hash and you can use
any combination of word lists, strings,
generators, any combination
that you want to
generate, candidate passwords.
You can add replacements, you can add
uppercase with or without permutations.
For instance, if you want to
have a password and if you
want to change as to five,
will you change all SS?
Will you change? None will change only
the first one or only the second one.
If you want to palmitate, you don't have
to write multiple rules to describe such
process. You just have to say one flag
and it will be permitted to all possible
permutations of replacement.
And also you can write on like
python functions or expressions.
The benefit of an
hash rules is that you can use any word
list you like.
You have ones that are shipped with
hash that are generated
by data mining on the 32 million
passwords that you can use
Google Wordlist to create.
Additional passwords
that are made by scraping
some keywords from Google or you can use
your own. I suggest you combine
the first two methods scraping results
from Google with word list and
using the ones that are shipped with
unhitch.
The use case here is pretty simple.
The tool was created to be able to
execute rule files
and you can type it into any popular
password cracking programs like John
Draper Hesketh or something like that.
The interesting part here is if you look
at GitHub, which I think some of you are
already doing, you'll see that probably
it's the most hideous code you have ever
seen.
But if there are some Python ninjas
here that know how to make it faster, I'm
open for suggestions.
The interesting part is that I used Tipi,
which thanks to the creators of Pappi,
that actually enabled pretty
much faster runtime for the algorithm.
Some results are
don't get it out.
Throw a few words later about
comparison of results.
If you was a normal brute force and
program, it will usually uncover
some amount of passwords in the same
amount of time.
I used 24 hours as
measuring element.
And what did I do?
I used unhappy with
the Google Word list and use the Google
Word list to generate a word list
that is scraped top
10 pages based on this here,
keywords like LinkedIn, like business
recruiting, networking, job contacts,
and use that list in combination
with the data mined list from.
And you can see that you can get at least
20 percent better results if you
add that approach.
Why?
Because brute forcing.
Brute force enables
you to uncover lots more
short passwords.
Is a complex, so this tool
will fail if you have a password that
looks pseudo random.
But if you have a password that is
based on combinations, mutations like
the ones I showed before,
then that kind of approach really helps.
If you see here longer passwords
are pretty much better uncovered
by this approach.
First off, I don't think that
unhatched is better than John Draper hash
gater hash kill, those tools are awesome.
And solar designer Hauschka team and
a gateway from a hash kill
do an extremely awesome job
is just use the right tool for the right
job this year.
Sounds maybe a bit complicated, but
you can find on GitHub the example
files. You can find all the rural files
and you can just simply execute them and
it will do its magic.
Those are two different use cases
still, if you have a GPU
cluster going GPU
is the king or if you have a
FPGA board or something like that,
if you want to test for slow hashes,
like decrypt script the
CDF too, and you can't afford
a large amount of comparisons
because the cracking process is slow,
then try this approach and
maybe it will help.
This also helps with passphrase, as
you know, a part of a base phrase.
You know how the first frails was
generated. How many words does it have?
You can pretty much simply
brute force it then or in
custom testing or in custom tools.
One thing I see, the data centric
approaches are really interesting,
try to experiment and build something
interesting when I mean build,
please don't be evil.
It's available on GitHub.
It's simple to use.
Try it out.
And of course, contributors and
researchers are welcome.
And of course, I was a bit
shorter. So you can have more time for
Q&A because if somebody is really
interested in this topic, I think he
has some questions to ask.
So you have my Twitter account here.
You have my email, you have the GitHub
link and.
I'm open for questions.
Thank you very much for the talk
for Christmas, please line up in front of
the microphones in the room.
Are there any questions from the
Internet?
No, there are no quotes from the
Internet. OK.
Questions and comments in a room.
On a five, yeah, sure.
You said that you had trouble using
machine learning algorithm.
I'm just wondering if you could explain
or elaborate why that was.
That was because machine learning
algorithms were
things I tested weren't really well
suited because there are really many
classes of passwords.
So it's the classic problem of
overtraining. You train your machine
learning algorithm to figure out one
part of the story, like one
class learned passwords and then it will
fail. And the other one, the one
the one thing you can do is
try something like random forests.
But they didn't give enough good
classification.
Or the second thing you can do is like
something like a committee of the
machines.
Solving algorithms is
pretty much inspired by committee of the
machines and random forest approach
because it is much simpler
to build a classifier for a type of
password because you can then also
get contributions from types of how
people create passwords.
You can get pretty much
more complex ideas into
how to classify passwords.
For instance, what if somebody creates a
passphrase and then takes
every first letter from
the passphrase?
How will you classify that?
But with deceiving algorithm, you
can classify that pretty much more easily
because you can write a classifier that
will give a result for that and give
you a probability score.
Is it better or is it not better than
something else? Right.
But does your sieving algorithm assume
that the classes of password are
independent?
Yeah, the classes
are independent because somebody
just combines elements.
Somebody uses keyboard pattern and
somebody uses combine to replace
replace this character.
Somebody just uses the words and
replaces a couple of words.
Those are all independent classes.
That that that's why it's pretty much
simpler to do it.
Microphone one, hi.
Uh, I was wondering if unhatched
also takes an account like specific
target attributes, like, uh,
native language, like,
ah, uh,
and other things.
And, uh,
you could also use use a tool
to scrape there are the targets website
or something like that to added to the
word list. Yeah.
And make it more target specific.
And is it capable of doing that.
The first part is the machine
learning part which I did was
based on this dictionary, English, German
creation, France, Spanish, Italian
and Dutch.
So the rules are derived by those
main classes.
The are scraping.
You can do with the G word list tool that
is enabled.
You can write the Google Docs, for
instance, you can write and keywords
and that sites column
something like N.L.
and you can add multiple entries of
keywords with site ANEL and
this will just and tell him scraped
up hundred sites and you will get a word
list that is only Dutch based for
those keywords.
It works Knutsford, so you won't
have any problems.
You can use the resultant word lists
from G word list with
the UN hash tool.
So that's the point that we want
to take here. You can scrape the results
from the net, you can scrape it with uh,
g wordlist that uses a Google.
You can use all Google Docs that you
want, for instance,
uh, redacting, reducing
search to a certain country, reducing it
to a set of keywords,
telling it OK, scraped up five hundred
sites and then
you can use it on the rules that are
freely available.
And and, uh, one more thing about
implementing password policies.
You can see on a site like they have this
policy, like you need to use one
capital, one
special character or things like that.
This is also implemented.
Or should we just write right regex
to filter out the
passwords in the list?
First off, you can filter of rules.
It is pretty simple to to see which
rules don't, uh, are not
covered by the password
classes or by the password policy.
You see, by the length you can see if it
has a replacement or not, if it requires
one special character, you can reverse
grep only those rules that don't have
a specific character.
Right.
So you can pretty much custom
design it for any kind of attack you want
that. That was the point behind Danesh,
uh, that you can adapt it to any kind
of use case that you want.
It's as I said before,
it's not a replacement for
John to refresh kit or anything else.
Those are awesome tools for brute force
and for their right.
But this is more interesting.
If you want to do an attack on a
passphrase on a slow hash,
if you want to just test a specific
set of words like you have a word
list that is medical
in nature and you want to you have
a pen test on a, uh, for instance,
on a medical facility and
you want to use medical specific words.
You can just use the word list, describe
them, and then use it with on
hash rules, right?
Yes. It would be nice to see a Web based
implementation of wordlist generator
telling me I should make clouds cracking
service right.
Or in the cloud the word generation,
which is less generally.
OK, good idea
people.
If you would like to leave the room,
please do that more quietly.
It's not that hard microphone
for last question.
Uh, thank you for the talk.
Uh, quick question.
You short for one instance of performance
gain of 23 percent if you run any other
instances and do you have any metrics
for possible performance gains?
OK, the possible performance
gains are really hard to measure
correctly. That's why I said I don't
think this is better than John or Hesketh
or anything else, because it depends
on the person, at least again, if some,
for instance, uh, those were
general pastoralists.
And as I said, the research data is hard
to obtain because they are not really
large pastoralists with occurrences
that have an equal
number of good users
that are, uh.
That are, how shall I say,
conscious, security conscious that use
hard passwords and a normal type
of users.
So I use 24
hours as a metric because you need to do
a lot of experiments.
Each experiments,
each experiment lasts for a day.
And that's probably the time somebody's
testing without the cluster will just try
it without all week passwords.
Right.
That that's why I used
big password lists and testing.
For instance, LinkedIn, for instance,
uh uh, for instance,
Yahoo! Password lists, hackers
and so on.
Thank you.
Thanks a lot, Tony.
Please give them give give them a lot of
applause for this talk, because was
pretty great.