All right, guys, welcome back.
In the last video we have talked about the theory part behind certificate pinning or the approach behind
certificate pinning and this video over here.
We will now take a look how it really works.
So we will do the practical exercises regarding to certificate pinning.
You will learn how certificate pinning works, how we can identify it, and even more how we can patch
it.
So this is the purpose of this video over here.
So therefore let's go, let's switch to Ubuntu VM and then let's have a look into this one.
All right guys, here we are now at our Ubuntu VM and we start with a very basic clean setup over here.
So we didn't perform our man in the middle attack yet.
Neither do we have the burp suite running, nor do we have any IP type ruleset we even didn't plan it
in.
So this interface is not available right now.
The reason for this is the following.
If you get an application from the developer and this one is performing a certificate pinning, you
are facing a lot of problems.
But the problem you definitely do not want to face is having a broken application just by design and
this happens quite a lot.
So you get an application from the developer and you run it without any modified network components
in here and it just doesn't work.
This could also be the case for my apps.
I mean, they might be not that well programmed.
I'm not sure about this one.
Therefore, my pro advice is if you get an application, then just test it on an yeah non man in the
middling network.
We can perform this pretty easily.
All we need to do is plugging in our use p two Ethernet adapter by having our access point running.
So if you plug this in, there we go.
Let's see, this interface is not up yet.
Maybe now it's up.
All right, now we've got our our access point running and this access point is routing the traffic
through our Ubuntu VM into the Internet.
But there's nothing in between.
This is an internet connection and if the application doesn't work over here, then we have a problem
or not.
We the developer has the problem.
All right, so let's make sure that this application works regularly without any modification.
And therefore, let's take our real advice.
Sorry, device.
This one over here and then and let's open screen copy.
And there we go.
Okay.
And now let's instead this application, you can find this application in the attachment of this section
over here and it's named let's find out the true about this one anymore.
Well, yes, of course I named it certificate pinning underscore hash.
So this application is regarding to certificate pinning with the hash approach.
In the next video, we take a look at the the approach regarding to having a raw certificate in there.
Okay.
All right.
So let's install this application.
There we go.
And here we can see these nice neon colors, which is now, I guess pretty up to date.
So it's it hasn't fancy UI, I guess.
Let's see, we are opening it and here we have certificate pinning, certificate pinning, sender request.
All right.
And let's perform this request and we have an error pinning that failed.
We have an attacker?
Nope, not yet.
We didn't perform anything.
But this smartphone has no internet connection, so this application is assuming there's an attacker
in between us, and therefore the connection got aborted.
So we can fix this pretty easily.
We go into the home screen, then into settings wi fi, and then we simply connect to our tp-link access
point over here.
All right.
The obtaining an IP address, and now we are connected.
Nice.
And let's get back into this one and let's see the send request.
There we go.
Successful.
We have now an Internet connection.
No etiquette in between us.
And we get this text and this domain is for use in illustrative illustrative sorry examples in documents.
So that's a text from example dot com.
And this text is being printed out over here if there is no man in the middle happening.
All right.
Okay.
Before we perform our man in the middle set up.
Let's have a look with Wireshark, because in our setup, we are forwarding single ports into the burp
suite so we can forward port 84, four, three or whatever part we like.
It might be the case that this application over here is using a different port than 80 and 443.
For example 8443887331 or whatever else.
And so let's have a look with Wireshark, and then we can forward all these ports into our burp suite,
and then we do not miss anything.
All righty.
Okay, so, and let's type this here and sudo wireshark.
There's an E missing.
There we go.
And now let's select this interface, bring the app in foreground, and then we hit send request.
So here we have now the stream recorded in Wireshark, but it's regarding through TLS 1.3.
And if you go into this one, right click and follow TCP stream, then we can see this one here is being
encrypted.
This is what we have talked about, how HTTPS works.
All right.
We cannot see anything in here beside the domain.
And this one over here, that's the domain.
And this one is before the encryption happening because the this the application needs to connect to
the host to transfer all these certificates, public keys, encrypted, symmetric key and all this stuff.
Therefore, the domain is visible even in https.
All right.
Now we know this application is communicating with example dot com and this is the IP we see over here.
Let's verify this real quick.
Host example dot com.
There we go.
93 184 216 34.
All right.
And to make sure that this application is only communicating by a port four, four, three, we we can
apply some filters in Wireshark.
So that's pretty great.
If we go into this one now, we can click onto package which has the destination set to nine three,
84 and so on.
We can hit the right mouse button, apply a filter, select it.
Now we've got all the, all the packages with this IP address as the destination host and now we can
add some and end filter.
So we applying this filter the IP destination to this one together with TCP IP destination port, this
one equals equals four, four, three.
All right.
Now we can see nothing has changed.
These are now all connections regarding to this IP address and this destination port.
We can also filter for not this destination port and now we get nothing.
This means all connections regarding to this host are based on four for three at least what we have
sniffed.
If I do some analysis, I let this application run for quite a while, let's say 20 minutes clicking
all around, try to make every request I can and then I record everything over here.
And yeah, have a look how many connections we have related to which ports.
All right.
To make sure that this one is working properly.
Let's run this once again with this filter being enabled.
And now let's go into the smartphone, opening Chrome within a new Incognito tab.
And now we are performing an HTTP request because HTTP is not related to destination port for three
OC.
So http example dot com.
This should be now fetch because we are looking for IP destination this address but not destination
port 443.
This should be port 80 and now be visible.
Let's hit enter.
There we go.
Here we have our connections.
So the filter is working.
And yeah, if we sniff the traffic of this mobile application, not the browser and this one over here
for quite a while, then we can be sure that we fetch everything.
So the whole task regarding to this one is identifying all the connections the smartphone is making
with this application.
All right, we can close this one.
And now we are sure that it's only connecting to four, four, three.
Now let's establish our man in the middle set up.
So what do we need?
We need our burp suite first running.
It's within tools.
Burp suite.
Okay.
We create a temporary project, we use the default settings.
And then we go into proxy options.
We select this interface edit and then we select 1042 0.1.
If you click okay, we can see we are still missing the invisible proxy flag and this is very important
flag.
Otherwise these packages will not be re forwarded.
So we enable also this one here.
Now we have our burp suite running on this interface.
The thing we need to do right now is forwarding all these packages regarding to HTTP and HTTPS Destination
Port eight and 4.3 to this proxy over here.
And we can do this with our yeah.
Well, famous IP table rule.
So let's set this up.
And therefore we simply close this one over here.
We are opening a new terminal and then we need root privileges.
Now we want to create a new IP table rule in the table, not network address translation, which means
swapping out IP addresses in a package.
We want to append a new rule.
Therefore the A and we want to create a new pre routing rule, which means if we get in package on this
interface, we want to reroute it.
Instead of going directly into the internet, we want to reroute it into our burp suite.
This one over here.
1042 zero 188.
Exactly.
All right, now we need to define the package type.
So the protocol is regarding to TCP and the destination port is regarding to four, four, three.
If this is the case, then we want to reroute it to our destination and we can do this by appending
dash chain the NAT Destination Network Address.
Translation Switch out the destination address of this package if it arrives at our interface and we
want to switch the address to destination ten for the 20.188.
If this was a little bit fast for you, I have prepared a whole video where we go into this syntax very
deep, so we will figure out what every parameter does over here.
All right.
Now we are forwarding every HTTP request, but let's also append HTTP within Wireshark.
We have seen this application is not using any different ports, so we should see every traffic right
now if we can intercept it.
So let's close this here.
Let's put the burp suite beside.
That's good.
And now.
Now we have established our man in the Middle Connection.
Let's hit this button.
Send request and pinning that fail.
Do we have an attacker?
Yeah.
This time we do have.
So within the dashboard, we can also see TLS connection to example dot com fail.
So if you click on this one, we can see the second notification and third.
So I get a feeling that this is really related to our setup.
Okay.
So this application is somehow data mining that it's not being connected to the correct server.
So there's an attacker in between this.
This could be the reason if you haven't installed the certificate.
So this application or this smartphone might not be aware of our authority of this burp suite.
So therefore, let's make sure that the certificate is known to the smartphone and it's being trusted.
We can verify this by going into these settings, then security, then encryption and credentials and
trust the credentials user parts which is enabled.
So this smartphone definitely trusts our burp suite over here.
And let's make let's be sure if you're opening this web browser, a new incognito tab and let's open
https example dot com.
Yes.
Within the burp suite we can now see it's highlighted orange.
And this is our request.
It's an https request for four three.
So this seems to be work.
Sorry, this seems to be working right now.
All right.
So our certificate is known to the smartphone and is being trusted.
But this application, this really paranoid application in this one over here, it doesn't trust us
for whatever reason.
So if you click send request.
No, it doesn't accept our certificate over here.
And therefore this application needs to have some kind of comparison regarding to the real certificate
and this one over here, the fake certificate.
And therefore, we have to reverse this application and we have to figure out how this is being implemented.
Let's go into this.
Okay.
So we close this one over here and also this one.
And now, yeah, let's take this application from the downloads directory and put it into the app's
directory so we create a new one certificate pinning, underscore hash.
All right.
And so now we could use Shadi X, Shadi excuse me or text to Char, whatever you like.
When I played around with this application, I had problems regarding to all, so it might be the reason
that we are running screen copy the burp suite and then another Java application so you might run out
of memory regarding to your Java instance, I'm not sure if this is the reason behind this, but yeah,
let's, let's try this.
So let's see if we is handling this form.
If this doesn't work, then we will fall back to the eclipse approach.
I also like the eclipse approach.
If you have some large projects, I mean this one here, that's not a large project.
But yeah, it doesn't hurt to use the eclipse approach.
Also for smaller projects.
Alrighty.
Okay.
So the first thing I like to do is checking the manifest and resources android manifest.
Okay.
So let's see.
We are having the internet permission.
I mean, of course it makes an web service request.
Therefore we need this permission and then we have one activity and this is also the launch activity.
So our code will happen over here.
We do not have any other stuff right now.
All right.
If we go to the right, we can see this one over here.
Android network security config.
We will take a look at this later on.
So the network security config is it's a really nice approach to perform a certificate pinning so we
can define what type of pinning we want to perform the whole certificate itself or just regarding to
the fingerprints of the public key.
And we can also define certain domains.
So this configuration file should be enough to perform a certificate.
Pinning, therefore, should be enough as a developer to only rely on the network security config.
But the real world is different.
The real world is using libraries, which is absolutely fine, and these libraries also have their own
certificate pinning approaches.
So most of the time you will find this network security config and certificate pinning approach in the
library that is being used.
In this case, we can also identify the library on the package names on the left.
So this one is the OC Edge Group three library and this one is very popular.
So I guess 40% of my applications I face are regarding to this library.
So yeah, if you can patch this one then you are pretty good to go.
And even if you face another library, I mean the approach is the same.
So we have these two approaches, fingerprint and raw certificate OC OC.
So this was a lot of input right now let's recap this a little bit.
We have a file called Network Security Config, and this one is being used to establish a certificate
pinning, but it might be not enough to only patch it over here because developers also might implement
their own certificate pinning in the Java code.
Alrighty.
Let's try to find the certificate pinning within the Java code and then we will get back to this file
over here.
OC OC.
So you know what, I guess let's simply start over here before we dive into the Java code, let's simply
have a first look into this one.
I guess this approach is a little bit easier than directly diving into the Java code.
So where can we find this file?
It's within the XML directory and it's named network security context.
So it's a resource, maybe XML network security config.
There we go.
Okay.
This looks absolutely nice.
We've got our included subdomain example dot com.
So that's the domain that's being pinned.
All right.
And then we have a PIN set OC Digest Shop 256 and then we have three hashes.
So this one here is base64 encoded.
We can see this at the or identify this at the equal sign at the end, this padding.
So let's take this value and simply try decoding it by 64.
Dash DX doesn't look that promising, so let's pipe it through x 60.
All right.
So this seems to be some hash and this is an SHA 256 hash.
Yes.
Okay.
So now is the question, what is this hash over here and how it is being generated?
Because if you want to patch it, we need to understand where this hash come from.
Otherwise, we we do not know what to do and how to create our own hash over here.
Okay.
We can find this out by taking a look at the certificate from example dot com.
So let's have a look into this.
We are using open SSL.
So open SSL, it's an amazing command line tool and we can do a lot of stuff.
Also we can fetch the certificate from example dot com and that's the certificate that's being pinned.
So we need to have our information stored in there, right?
Absolutely.
Let's have a look.
Okay.
So we are using open SSL with the SE client command.
That's the yeah.
That's the client command that is making a connection to our target.
And we also want to provide the parameter show certs and so we want to print out the certificates of
our target and our target we need to connect to this one is example dot com on part 443 because these
are the certificates that's being pinned and let's see.
Okay, looks good.
We can close this one, not implement it.
We don't care about this one.
Now let's see what we have here.
All right.
It looks a little bit strange.
Absolutely.
If you are not familiar with S with open SSL, it might look even worse.
So that was also the case for me.
But I guess we do not need to understand everything in here.
Okay.
So let's have a look into this one together.
What do we have here?
We are having three deaths, so we are having three certificates.
The first one here is from the desert.
The desert.
It's known authority and it's entrusted authority.
So this is the route car that's creating or signing other certificates.
Then we are having another certificate and this one it's again from the desert.
So we are having two certificates now from the desert.
All right.
So we will we will have a look into this one later on.
But for now, we just we just keep in mind we're having a route car and also an another certificate
from the desert.
And then we are having a third certificate and this one over here.
And finally, this is something we know.
This is regarding to example dot org.
Did we call example dot org.
Okay.
It's regarding to the same.
So example dot org and example dot com.
All right, so these are our three certificates right now.
Why do we have three?
The reason for this is the following.
And therefore, let's do this on the graphic tablet, because.
Yeah, then it's easier to explain what's happening over here.
Okay.
So here we are back on the graphic tablet and now the question, what's going on over here and what's
what's up with example dot com?
Why do we have three certificates?
One should be enough.
Right.
So if this one has been signed by a non authority, why do we need two additional ones?
And the reason for this is the following.
The first one is from the desert and it's the root.
Okay, so this one over here.
All right.
This root has also its public and private key, but now they have some really hard regulations regarding
to this one.
So a root ca it's a very important certificate.
If this one, the private key for this one gets lost, the Internet would be absolutely in danger.
Therefore, this private key.
Needs to be absolutely super protected.
So we need a really strong lock over here.
This one maybe even better.
So, yeah, like this one over here.
Okay.
So this is it wouldn't be very amused if this route car cuts compromised.
This is something we definitely need to avoid.
Otherwise, the Internet is broken.
Therefore, the research is not putting the car on an on an additional risk.
And the G cert is creating something called intermediate cert.
This one over here.
This is our second cert.
This cert is not that hard regulated like a rusia.
Having a rusia is a lot of trouble and losing it would be absolutely dangerous.
They create another cert.
This one.
This is the intermediate cert and this one is our our second cert.
So this is also being created by DG Cert and this one is now being signed by the private key from this
one over here, the Rusia.
If this one over here, this second certificate gets signed with the with the private key from the root
certificate, then this is exactly as trustworthy as this one over here.
So both are absolutely trustworthy right now.
So we are having an intermediate certificate which is as trustworthy as the root ca regarding to our
authority over here, regarding to the third.
All right.
The nice thing about this one is and this one has, of course, a new private key.
And this one over here.
This is, of course, also a private key, which is all pretty secure.
But it does need to be hold that secure anymore.
So this one over here has some hard regulations.
This one also needs to kept safe.
But it's not that hard anymore because if this certificate gets compromised, we can revoke it via the
root certificate.
So now by having the second certificate, we have way less pressure right now.
So at this point can be now used to sign additional certificates.
For example, our third one, which is this one and this one is now our third certificate and this one
is finally regarding to our domain example dot com.
So now this certificate gets signed by the private key from the intermediate certificate by this one
here.
And by having this chain we can now establish this trust relationship.
So it goes from top down.
This one absolutely being trusted.
This one also trusted because signed with this key.
And now this one is also being trusted because it has been signed by known on legit authority over here.
All right.
That's the reason why we are having three certificates.
And this one here is called certificate chain.
So like this one over here, this doesn't look like a chain, but nevertheless.
So this is called a certificate chain.
Okay.
And the whole concept of this chain is, yeah, having this root certificate in a safe place and still
building and trust relationship by having an intermediate certificate over here.
Now the certificate has been signed here.
We have our our signature now.
All right.
And this is now being trusted, signed by DG Third.
All right.
So that's the reason why we're having three certificates.
Perfect.
Now, we have understood this over here.
Even if you do not understand the oppressors, excellent output.
But we also do not need to do this.
All right.
Okay, so let's get back to our Ubuntu VM.
Okay, so here we are back at Ubuntu VM and now we know why we have three certificates over here.
We've got our root certificate and this one then we've got now our intermediate certificate which is
this one and we've got our certificate which is regarding to the application itself and this one over
here example dot org.
So the root certificate has created or signed an intermediate certificate and this one is now being
signed by this certificate and therefore it's being trusted already.
Nice.
We can also see those certificates in this output over here.
We've got this nice tech begin certificate and and certificate and this one here, this is an base64
encoded output.
So this is in p m format.
PM simply means having an ASCII representation in Base64.
The other format we encounter out there is the E, which simply means and binary representation of this
certificate.
And so the file endings of certificates are just regarding to the representation of them.
Alrighty.
So here we have our first one, then we've got our second one and here we have our third one.
But the order is different and this one is the root.
Okay, here we have our intermediate certificate and this means this is now the certificate of this
application, this one over here.
So let's copy this out and have a look how we can.
How can we display this one over here?
So we start at the end and go up to the begin.
We would vice versa.
And then let's see, I'm opening a new terminal and we go into certificate pinning, underscore hash,
and here we create now a new text file which is certificate PEM.
All right.
I mean, simply copy paste this output into this file over here, and that's all.
Now we can close this file.
Now we close this file, and we simply opening it with the file browser.
All right, here we have now our certificate pan.
If you perform a file on this and let's see.
Then it also says it's an PEM certificate and this is on Linux system, not just regarding to on file
ending because this doesn't matter, it's regarding to the file structure itself.
So even if you would, right, rename this one in cert dot pen to cert, dot and bin, for example,
and perform a file command once again.
Then we can see it still being a PEM certificate.
All right.
And let's let's undo this.
So from bin back to PEM.
Okay.
The easiest way to view this file is simply double clicking it.
So yeah, by performing double click we can see this right now.
We can see verified by the user and the identity is example dot org.
Now let's make this a little bit larger because there's a lot of stuff in there.
If you click on details, we can also see when it expires.
So at this stage, this certificate needs to be renewed, otherwise it won't be accepted anymore.
This is very important for the administration of this infrastructure that the app keeps track of this
phone over here.
Okay.
So here we can see country, state and so on.
Issue issuer Digicel.
Okay, and here we have now a certificate fingerprint.
Oh, this looks absolutely promising.
We've got the sub one and MD5 hash.
So this one here is some kind of fingerprint of this whole certificate.
We will have a quick look into what the hash is in a moment.
But for now, let's let's look over this file over here.
Okay.
Next, we also get this public key info and this one, this is now the public key of this certificate.
We can see it has an Irish algorithm cos these are the key parameters, we've got a key size and this
one is a fingerprint of this key and this one is the public key in a byte representation.
Okay, next, let's see, we've got some subject 25th name.
So this certificate is also being accepted, for example, dot org or com.
This is why we do not get certificates error.
Alrighty.
So let's see what else inside the certificate over here.
So let's see.
Yes, this signature.
This is the last most important part over here.
The signature has been created with the private key of the GCF.
So now by having the public key of the G set, we can verify if this certificate has been redesigned
by DG Cert.
So this is the this is maybe the most important part over here.
This will prove that this certificate has been signed by a non authority.
So in a moment we will figure out why it's not possible to spoof or fake the certificate over here.
But for now, let's do a quick recap.
So at the end we've got the signature over here and this will prove that this certificate has been signed
by a non authority with the private key of the authority.
All right, then, if you go up, we can see we have two fingerprints.
One is the certificate fingerprint and this one over here, and one is the public key info.
And this also has a fingerprint.
And this one over here.
Okay.
So now is the question.
If these are the fingerprints that's being checked in our application, then we need to know how these
are being built, because otherwise we cannot create them for our own certificate.
And then we can also not replace these values.
Okay.
But before we dive into this, let's first have a look at what the fingerprint is.
And you can really think of an fingerprint like yeah, like we humans have this.
So a fingerprint for us as a human as being an identifier for us as a person.
And it's the same for this certificate over here.
So a fingerprint is some kind of identifier and this one is being built up on the hash.
In this case, we have two hashes over here.
We've got two SHA, one hash and also an MD5 hash.
These are just different algorithms, but the hash principle is the same.
And therefore, let's first figure out what the hash is because then we can understand what these values
over here mean, and then we can figure out how we can build them by our own.
Don't worry, we do this on a very high level and in a very short amount of time.
All righty.
Okay.
Let's switch back to the graphic tablet and have a look into this.
All right.
So here we are now back on our graphic tablet.
And now let's have a look into how an hash function works, because if we understand what an hash function
does, then we can understand everything in our cert pinning approach.
We will know why an attacker is not able to spoof or fake and hold cert.
We will also know why these hashes are being pinned.
And last but not least, we will learn how we can create our own hashes based on the birth certificate,
that we can replace them with the original one, and afterwards we can manage the middle.
This application sounds absolutely perfect, right?
Therefore, let's have a look into this one.
There are a lot of approaches out there trying to explain what the hash function does, and most of
them are regarding to colors.
But in my opinion, Bob Ross is the only one who should play around with colors.
And therefore I like to go with a different approach and this one over here.
So we do this very visually on a high level.
This might be not 100% accurate, but if you get this point of the hash function over here, that's
all it matters right now.
Okay.
So therefore, let's have a look.
All right.
So let's start over here.
And it's already mentioned we do this very visually.
You might think what in a moment, but let me try to explain this afterwards.
Okay.
So we start by having an apple and this one over here.
All right.
And this is a very well-drawn apple, I guess.
Yes.
Maybe the best I have ever drawn so far.
All righty.
Below this apple we've got now our hash function.
And in this case, and this one is being a mixer.
And let's see how good this works out.
Okay.
I guess that's okay.
This is now our hash function.
And below this hash function we have our output and we start as output here in the glass.
Okay, so let's do this over here.
If you take our app and we put this into the mixer and then the mixer later on, the hash function is
performing a bunch of stuff.
So in this case, the mixers making juice out of this apple and we get this as an output over here.
Here we have now a purchase.
So this one over here.
This is apple juice.
All right.
And this is the principle about the hash function.
I mean, not making choose, but having the following approach.
If we have our input and we put it into an hash function, we get back an output.
And so far so good.
But most important point in the hash function, we cannot go back.
So it's absolutely impossible to get back from our output back to this input.
In this case, I never, ever be able to make an apple out of this juice bag again.
I'm not sure about you, but for me this is definitely not possible.
And this is exactly the principle about the hash function.
It's an one way operation.
We have an input over here.
We perform a bunch of operations and we get back an output, but we cannot get back from the output
back to this input over here.
This is not possible within the hash function.
It would be possible if this one has been encrypted, symmetric or asymmetric, but that's not the case
over here.
So in hash function is not some kind of encryption.
This is an it's an hash function.
And yet these terms encryption and hash gets often mixed together, which is completely wrong.
All right.
Encryption means we can get back to the input by having the key asymmetric encryption, whatever.
But in hash function, we cannot go back.
And this principle, it can come super handy.
For example, let's say if you have a web application and this web application over here, this has
now two input fields.
One is regarding to the user name and one is regarding to the password.
Okay?
And now the administrator has this task to study passwords in a secure way, which means even the administrator
is not allowed to view them.
Therefore, we cannot use some kind of encryption.
Otherwise the administrator can simply decrypt them and get back the clear text passwords.
And this is exactly when hash function is super helpful.
So let's say we've got this database over here.
So this is now not a glass anymore and this is now the database that's being stored or storing those
passwords.
All righty.
This is our database.
And all we need to do right now is the following.
So we're taking this password of the user and we put this into an hash function, this one over here.
Then we get back our output and this is now the hash.
And instead of storing the clear text password, we are now storing the hash in this database over here.
So this is now the hash of this user over here.
This means if we cannot get back to the clear text password, we can also not see what's what's the
real password of this user over here.
All right.
But now the question, how can we make sure that the user has entered the correct password and the approach?
I mean, it's pretty simple.
If the user enters now and password, for example, test, then all we need to do is we need to put
this password into this hash function into the same hash function over here.
And then we compare those two outputs.
In this case, we can see this one is green and this one is some kind of purple, let's call it purple,
which means these are definitely completely different colors.
And it's also the same for these hashes.
So these hashes are not even close being identical, which means the user has obviously entered the
wrong password and we can now verify this, even if we do not know the clear text password of this user,
which is super amazing, right?
Absolutely.
So I guess this example isn't that bad as I've thought it was at the beginning.
Let's stick to this one with the web application and therefore, let's make a separation over here.
And now let's get back to the second important part about the hash function.
The second important part about the hash function is the following.
And let's say in this output here and this one, this is the password t s dx So now if the user enters
the password over here test, there's only a little difference in this password, only just one single
letter.
And now the second important part about the hash is that no matter how identical they are, if they
are not being completely identical, the output looks absolutely different.
And so because we could have assumed over here that the first part might be identical, and this one
over here is T.
S and also this one over here is T.
S.
So this part could have been identical, but not within a hash function.
Even if you changed one single bit.
And then in an input value we get back and completely different output.
And this is why this hash function is that useful regarding to certificate pinning, for example, let's
say we have our certificate now we are hashing certain values in the certificate and we stored these
hashes.
We can now make sure if a certificate is being represented by comparing these hashes with the one of
the other certificate.
If this one is the certificate we are expecting or not, in case of not, then we can abort this connection.
And these are exactly these hashes that's being compared.
Therefore, let's have now a look into our certificate pinning approach over here and how this all applies
regarding to these hashes.
But keep this picture in mind and this one over here regarding to the apple and the truth, because
this can come handy if you want to analyze or understand what our certificate pinning approach does
already.
Okay.
So now let's take this this hashing approach back to our certificate pinning and let's figure out what
these fingerprints means and also why it's not possible to faking cert.
All righty.
Okay.
So we have seen our certificate before.
This one over here.
And this one consists of very important fields.
One, for example, is the common name.
The common name is simply just the domain name where this certificate has been created for.
In our case, it's simply trust.
Example dot org.
All right.
So far, so good.
Next, we have also seen that this certificate includes a public key and this one over here.
And we now also know why this is the case.
The public key will be sent to the client and this public key will be later used to encrypt a secret
which has been created by the client.
So the client is sending back the encrypted secret and only the person who is having the private key.
In this case, the server is able to decrypt this package and receive this symmetric key afterwards.
The whole connection will be encrypted with this symmetric key over here.
So this is the reason why the certificate also includes a public key.
Then we have also seen this fingerprint of this public key and now things starts to get interesting.
So what is this fingerprint?
So the fingerprint is simply just our public key, which has been put into an hashing function, this
one over here.
So if you take our public key and we put it into this hashing function, we get back this output hash,
for example, and this is now the fingerprint of our public key.
We have learned before, if you change only one single bit in this input, the fingerprint or the output
over here will be completely different.
So by having this value over here, we can simply recognize or compare if this public key is exactly
the one we are expecting right now.
So this is now the fingerprint of the public key, some kind of identifier for this one.
The reason why we are using a hash and not just the whole public key is a hash is way smaller.
So what we do is we simply create an hash of this public key and now we are pending this hash into the
certificate.
So this is the identifier of this public key over here.
Therefore, let's do this.
So we take this one over here and now we append this also into our certificate.
All right, last but not least, we have this signature, and this one is maybe the most important part
over this whole certificate.
The signature has been created with the private key of the desert.
So this is the proof that this certificate is now being trusted by a non authority.
This also means by having the public key of the cert, we can now verify if this signature has been
really created with the private key of the jigsaw.
The public key is pre delivered on our smartphone.
So this is a known authority and we have a lot of non authorities, public keys in our smartphone over
here.
All right.
So this is what our certificate looks like right now.
Okay.
So, I mean, this is our certificate on a very high level.
There's a lot of more stuff included over here.
But these are now the most important fields for us right now.
All right.
Okay.
Now, let's talk about faking or spoofing a certificate.
Why is this not possible?
Let's say we have an attacker and this one over here, and the attacker is now creating its own certificate
in this one.
So the attacker wants to create a certificate, for example, dot org.
All right.
This is absolutely no problem.
We can create a certificate for whatever common name we like.
Therefore, let's copy paste this into our certificate.
From.
There we go.
Now we're having a certificate, for example, dot org.
Next, we need some kind of public key because this public key will be used to encrypt the symmetric
key afterwards.
And therefore, we cannot simply use this one over here because if we copy paste this one in our certificate,
let's do this then.
The client is encrypting the secret with this public key, and we are not having the corresponding private
key for this one.
Therefore, we are not able to decrypt this package afterwards.
So this is bad and therefore we need to create our own public key.
And we put this public key into this one over here because then we also have this private key and we
can decrypt this package afterwards.
All righty.
So let's change this over here in our public key right now.
Okay.
But this also means we need to provide our fingerprint for this public key over here.
But that's also no problem.
Right?
So we simply take our hash function over here and now we put our public key into this hash function.
Then we receive an output.
And this one over here, and this is now the fingerprint of our public key.
I mean, of course, it's completely different because our public key is different.
So we take this output right now, this one over here, and we append this into our certificate.
All right.
We are now having a public key and the corresponding fingerprint.
Okay, next, let's see.
We've got the signature over here.
And let's also copy paste this into our certificate and see if this works out okay.
And now we have created the certificate over here.
And this should work right now, should it?
Well, no.
The reason for this is the signature.
The signature will be built over the whole certificate.
Over this whole certificate over here.
And this is in very strong cryptographic algorithms that's happening over here.
We do not dive too deep into this, but this signature will verify that these data are correct.
So that's the reason why the authority has signed the certificate over here.
So the authority has put a signature under this certificate.
And now if we change some data in the certificate, like on the right, the signature doesn't match
the certificate anymore.
Therefore, the signature does not apply to the values over here.
And this certificate will not be accepted by any client right now, because by having the public key
of this authority, this is that authority right now, we can verify if the signature is correct regarding
to the whole certificate.
And on the right it isn't because we have changed a lot of values and we need to change these values
because otherwise we are not able to use the certificate.
So this is the reason why we cannot simply clone fake or spoof certificate over here with different
values, and therefore we need to create our own certificate, which has not been signed by a known
authority.
But then we need to make the application to trust us.
So how is this pinning approach working right now?
Let's have look into this one.
Okay.
So on the top right, we have now our self signed certificate as an attacker.
Let's have look how the certificate pinning approach regarding to those fingerprints because if we understand
how these values getting checked or being generated, then we might be able to replace them.
All righty.
And let's have a look.
Let's say we've got our smartphone over here and this smartphone is trying to connect to this server.
The server is now assumed to be example dot org and therefore the server is representing the certificate.
This one over here.
Okay.
So we can see this is exactly the same certificate that the client expects to have.
Now, let's see what the client can pin in this certificate over here.
So we have seen two fingerprints.
One was regarding to the whole certificate, and this one is simply just putting the whole certificate.
And this one over here into an hashing algorithm shows.
And this output could now look like follow.
Okay.
If we now take this output into our client application, we can then make sure if this certificate is
the correct or the one we are expecting right now, because we have also learned if you just flip one
single bit in this whole certificate and for example, this bit over here, then the whole output will
be different.
So if this certificate will be now verified, so we put this certificate into this hashing algorithm
shows the output over here and this one is now completely different.
And now the application can simply check this.
So the application is expecting this value over here, but it gets this value and this means the certificate
is not the one we are expecting right now.
Therefore, we are terminating this connection to this server over here.
So this is one possibility to check if this certificate is the corresponding we are expecting right
now.
The other one is regarding to the public key of this certificate.
So if you take this public key into this hashing function, then we generate a fingerprint of this public
key, and now we can take this fingerprint of this public key over here into our client application
so this one gets copied into our client application.
Now, if you're facing a certificate with this public key over here, we can be also sure that this
is the certificate we are expecting right now, because otherwise, if the attacker leaves this original
public key in this application, I mean, this is the one that's being used to encrypt the symmetric
key that has been created by the client.
We have extensively talked about this in the HTTPS section.
Therefore, the attacker needs to replace this value, otherwise he doesn't get any value out of this
connection over here.
Therefore, if you check this public key, we can be sure.
Okay, this is the certificate we want to have to create our own fingerprints.
Right now.
All we need to do is we need to take this attacker certificate and we need to place this whole certificate
into this hashing algorithms.
Or we only need to put the public key into this hashing algorithm algorithms.
These are the two fingerprints that can be checked in this application over here.
The last example is checking this whole certificate so we can also apply this whole certificate into
this client application and then we can verify if this one over here is the one we are matching at the
server.
So these are the main two approaches checking the fingerprints of an old certificate or only the public
key, or putting an old certificate into an client application.
All right.
Okay.
Last but not least, there's this question.
Why should we only check the public key and not the whole certificate regarding to the fingerprint?
The reason for this is the following.
The certificate will expire in the in the near future.
So I guess regarding to official certificates, they last for one or two years only.
And now if we fingerprint the whole certificate so every single bit in the certificate, we also need
to update our application.
Otherwise the certificate pinning will fail because we have changed and value in our certificate the
expiration date.
Therefore, the output of this hash will be completely different.
Okay, so we have learned a lot over here.
We have seen what the hash function is, why is it useful?
And we have also seen why we cannot simply fake or spoofing certificate.
We have also talked about depending on certificate.
So while we are having several different approaches to PIN certificate and also that the developer has
the possibility to include this whole certificate into its application.
All right.
So this was a lot right now, before we finish this video, let's have a quick look on how these hash
sums being generated, the one of the public key and the fingerprint of the solid certificate, because
then you can also perform this approach for your birth certificate on your own.
But we will also discuss this together in the next video.
All righty.
Okay.
Therefore, let's switch back to the Ubuntu VM and have a look into this.
How these hashes being generated.
And let's go.
Okay.
So here we have back at the Ubuntu VM.
Now let's have a look into the certificate file and how these hashes being generated.
We start with the first one, which is regarding to the whole certificate.
This one over here, the certificate fingerprint.
So here we have the SHA1 hash of the certificate and here we have the MD5 hash of the certificate.
These are different algorithms, but the input was the same.
The certificate file over here.
Let's have a look how we can calculate this on our own.
So we go to this directory.
But the certificate has been stored.
It's within EPS and certificate pinning.
Underscore hash and here we have it.
Yes.
Alright.
Now we take open SSL or we're using open SSL to take this whole certificate and perform our fingerprinting
action.
So we take the certificate into our hashing algorithms and then we we hopefully get back the same values
over here.
So we type in open SSL and then we are using the X 509 parameter because that's a parameter to interact
with certificates.
And let's have a look at the help because we might not remember all those parameters right now.
Okay, we have our end file.
This is our certificate.
We've got an input format.
Let's see where this one directly above me need to provide that.
This one is in PEM certificate.
And then let's see this one over here, the fingerprint.
All right, these are all the parameters we need right now, and therefore, let's do this.
So let me make this a little bit larger.
Okay?
Open SSL x 509, then we have fingerprint, we've got this in file, our cert file and as in form,
we have PEM.
There we go.
We've got the SHA one fingerprint at the top and the certificate is also being printed out.
If you do not want to have this, we simply provide the parameter.
No out and there we go.
Now we only have this hash, let's see in 0828 and it ends with C A to a if you check this and zero
A to eight, see a to a.
Okay, now we know how this hash is being calculated.
Nice.
So this is the hash regarding to the fingerprint.
We can also do this for MD5 by just simply switching the algorithms.
Maybe let's also do this real quick.
So all we need to do is we simply need to append the algorithm we want to use in this case, dash MD5.
Let's do this real quick.
Okay, so here we are back at our command and if we use this once again, but this time we want to apply
an algorithms and the file.
Okay.
Let's see.
There we go.
Now we have the MD5 fingerprint, a three kb a1ed7.
We receive a1ed7.
So I'm only comparing the beginning and the ending of those hashes because yeah.
Then I'm pretty sure that this matches.
Of course, it can be the case that it's super lucky that an attacker has provided in cert with the
beginning and ending of those values.
But yeah, not regarding to this example over here.
Now let's have a look at the fingerprint of our public key and this one over here.
So here we have our public key info.
And here we have the fingerprint of our public key.
Okay.
So one of these two hashes might be the one that's being pinned over here in our network security config.
Therefore, let's also check the generation of this public key and then compare these values with them
over here.
All right, so let's see.
The public key.
The first thing we need to do is we need to extract the public key from this certificate.
I mean, what we can do is the following.
We could simply take the certificate and yeah, copy paste these values into a single file.
But that's not an approach for us right now.
I mean, we are lazy and we are hackers.
There has to be a different way and the different way is absolutely correct.
Open SSL.
So let's see.
Now we want to have the public key separated from this certificate file.
Therefore, let's have a look.
Openness is l.
We want to perform some actions with the certificate.
Therefore we have the x 509 parameter and by performing dash dash help.
Let's have a look into this one.
And there we go.
In pub key output, the public key.
So this command will output this public key in this certificate.
So Ultima S is an x 509 as in file.
We have still our certificate of pan.
The inform is the pan and we want to print out the public key.
There we have it.
This is the public key and the certificate.
Now we only want to have this public key.
Therefore we provide the parameter no out and here we have it.
Now we can save this in a separate file pop key.
All right, now we have extracted this public key.
Super easy, right?
Okay.
So now is the same position.
We perform the same actions once again on this public key file.
Absolutely.
But unfortunately, that's not the case.
So this public key is in different file as the certificate.
We can also verify this over here.
If you perform a file on our public key, we can see this is now ASCII text.
And if you perform a file on our certificate of Pan, we can see this is now an PEM certificate.
So in our approach we have seen before there is no such an option for inserting in public key as an
input file.
It's only regarding to the R and PM.
And so to calculate the fingerprint of public key, we have to take a look once again into the certificate
and here we can see we have some key algorithm errors.
So instead of using open as is L x 509, we now need to use open SSL RSA.
Therefore let's have a look into this one.
Open SSL.
Ah, as a help.
Okay.
We've gotten in form, we can see the RPM, but that's not the case.
And there we go.
Public key.
Expect a public key as an input file.
This is exactly what we want to have.
So what we need to do is we need to use open SSL, RSA.
Then we have our end file, which is now the public key and the inform.
Sorry, I got confused for a second.
No.
In form we are using public in.
So it's also a little bit confusing for me right now.
All right.
And the out form, this is something we can provide.
We want to have the out form as a binary format.
All right.
Okay, let's see.
Yeah, there we go.
This is now the public key in a binary format.
We can now use open SSL once again to apply our hash sum about these binary values.
So if we print them out, we can see them over here 30, 82 and so on.
And these are the same.
32, 30, 82, and so on.
All right.
These are exactly the same values over here.
This step has been correct.
Nice.
Okay, so now we can apply our SHA1 sum or what?
This binary content over here of the binary content of this public key.
Instead of using 60, we are now using open SSL once again.
And now we want to have the digest of this aggregate most.
So this will provide an SHA1 sum over this content.
Let's see.
There we go.
This is now our our SHA1 sum.
Okay, let's verify this value.
There we go.
5ea5e4.
If you put them side by side.
5ea5e4.
And it ends with f693f693.
All right, nice.
This is how we can calculate those values, the public key fingerprint and also the fingerprint over
the whole certificate.
You will find this information also, of course, in your cheat sheet.
So you do not have to watch back this whole video.
You can find them over here.
Now, let's compare these values with the one we have seen in the network security config.
So what we need to do is we simply need to apply our base64 encoding afterwards.
But first, let's have a look.
If these are really SHA1 hashes and let's have a look and there we go.
We've got now SHA 256 hashes.
Instead of using SHA one, we need to provide an SHA 256 hash.
Okay, that's not a big deal.
All we need to do is simply changing sha one to cha 256.
There we have it.
Now, let's also perform base64 encoding format about this one.
Okay.
If you simply append now base64 into this one, this won't work because the base64 will also include
the text over here standard in the equal sign and stuff like this.
Therefore we need to extract this value and also perform this base64 encoding about this value.
And we can do this by simply providing this parameter dash binary.
Let's verify this real quick.
Here is now this output.
Let's check this real quick.
We pipe this to 16.
Here we have now our key.
We can see this over here.
That's the correct one.
And now we can use instead of x 60, we can use base 64 to encode this.
This is now our hash that needs to be verified.
So this struggle we have by doing this command over here are the following.
We need to provide the correct algorithms.
Okay, that's not a big deal.
But we also need to keep in mind that the basics before encoding of this output over here should be
not about this whole stuff like standard in equal sign and so on.
It should be just about this value.
And therefore we need to have this parameter in here which prints out only the binary content which
is listed over here by performing afterwards.
Some basics before sorry, this one over this value.
Then we get back our real hash.
So this one over here is the final command we want to use to calculate our base64 encoded fingerprint.
Alrighty.
Okay.
And now let's take this value and have a look into the network security config.
Let's see RN to nine you a equal.
This is exactly this value.
But maybe let's be sure that this is really this value.
Yeah, let's paste it in here.
So that's the copy paste that value.
And if we compare them now let's show the pure man comparison.
So just above.
It looks perfect.
Yes.
So this is definitely the hash that's being pinned.
All right.
Fantastic.
We now know how this has just been generated.
We can calculate this by ourselves and we could simply replace this over here to bypass certificate
pinning.
Right.
And fortunately, there's one last thing we need to discuss right now, and then we have it done this
topic.
Okay.
So if you take a look back into the network security config and this one over here, these are now the
hashes that's being fingerprinted.
This one is the hash from example dot com.
This might be the hash of the intermediate certificate and this might be the hash of the route certificate.
Okay.
If we create our own certificate or if we are having our own certificate, the burp suite, then we
could simply delete them over here and just simply replace it over here.
Don't worry, we will do this in the next video, just on a practical exercise together.
All right.
But the problem with this file over here is the following.
The Android system has changed quite a lot, and it has changed pretty heavily regarding to the network
security config in version seven and higher.
This means we are now having the following problem.
If you take a look at the network security config in the Android developer documentation, let's do
this here.
Network security conflict Android.
So here we have a quick introduction into this file and we will also discuss this in the next video.
More in detail.
I just want to show you the following.
The network security config has been changed and let's see if we go into a network security config.
There we go.
The default configuration for apps targeting Android seven up to 8.1, but also here, nine and higher
is following the application's only trust certificates that are being stored in the system storage.
So this does exclude our burp suite certificate which has been stored in the user storage.
Of course, by having root privileges, we can take our birth certificate and put it into the system
storage.
But this course is designed to work most of the time without root.
Therefore, what's the solution for not having privileges?
And this one is mentioned here.
We have to overwrite the network security config with this one over here.
But these texts to also trust the user storage in our smartphone over here.
So it won't be only enough to simply overwrite these values here with the one of the burp suite, the
fingerprint of the burp suite certificate.
We need to apply or need to introduce the user storage, the user certificate storage also to this application.
And therefore, we have to change the network security config to this one over here.
And now you might ask yourself the question, why have we done this whole approach, figuring out how
this fingerprints are being generated, performing this on ourself and replacing them in the application,
when we can simply just use this network configuration and get rid of the certificate pinning.
The reason for this is that the developer often uses an additional certificate pinning in their applications,
and this is also the case over here.
So if you go back into JD X and then have a look into the main activity.
And this one.
And then we can see over here we have those hashes also included in the Java code.
So everything you have learned so far is very important because yes, within the network security config,
we do not have to adjust those hashes.
So over here we can simply take the approach from the Android developer documentation, this one over
here and place this into our network security config.
Then the password certificate will be accepted perfectly fine.
But now if you have to deal with the certificate pinning, that's also introduced in each Java code
like this one over here.
In this one, we now need to replace these values with our fingerprints.
So in this case, we have three of them.
And what we can do is we can simply replace all of them with the one of the burp suite.
As already mentioned, we do this in the next video together.
Feel free to also start on your own right now.
And yeah, if you want to perform this exercise by yourself.
But this is the reason why we got through this whole theory part right now to understand how these hashes
are being generated, that we can deal with them if we find them in the Java code.
If there is no hash in this Java code over here, then you can simply just overwrite the network security
config and we are good to go already.
Okay.
So now we are finally at the end of this video, which is now pretty long.
Absolutely sorry for this one, but I'd like to provide you as much information as possible, because
if you book this course, you deserve to learn everything that's required and even something which happens
behind the scenes.
Therefore, you are now perfectly prepared with the theory part about certificate pinning.
In the next two videos, we will do practical exercises.
Let you get familiar with this one and then you are pretty good to go to get rid of all the certificate
paintings out there.
All righty.
Okay.
So therefore, I'm looking to forward to see you in the next video.