CAPTCHA problems, so capture stands for completely automated public Turing Test to tell computers and
humans apart.
But you didn't know that, did you?
So basically it's implemented to distinguish users and any entity that makes automated requests.
So there are several capture types, such as visual aural, arithmetic and so forth and so on, but
the most known ones of these is the visual one.
So many times capture is an image, it contains a human readable text or maybe some numbers or recognizable
image the user must solve in order to prove he is not a bot.
And boy, doesn't it feel good to know that you're not a bot, so capture is not in authentication control,
but by using a captcha can be a very efficient way to mitigate against the enumeration of attacks and
any process that submitting that can be automated within Web application.
So capture images don't protect against a pure brute force thing and just put a layer of complexity
over the form on which they are added.
So that means that you can generally see Captive's implemented and log in registration as well as reset
and forgot forms, so this will barely protect against account takeover, username enumeration and fake
accounts creation.
But let me show you this.
So open up Caleigh and login to be web.
And from the drop down menu, open captcha bypassing.
And this is a capture contained authentication form.
So this time I'm going to do only high level, so change the level of high.
And there's no difference in The View.
OK, so let's see the page source and see if there's anything interesting.
So this is the form that contains a capture and the capture image is included in an iFrame.
The source page is a capture box, and this page contains the produced capture image.
OK.
So now open burp in interception mode.
And I will make the browser have a better view of the screen, and now we can enable Foxe proxy.
So now we need to understand the behavior of the form and capture.
So there may be an implementation problem here.
OK, so I'm going to enter the right values into input fields, B bug and the capture text.
And while the request is in you so forward it.
And here's the response now, let's have a look at the response, it contains a successful Log-in message.
All right, so this message comes up when everything is correct, so forward it.
Now, after we get the response or capture contained, iFrame sends the request to get a new capture
image.
And a source of the iFrame sends a new request to the image page.
And the new image is presented on the page.
So this new CAPTA image request will always perform the exact same way.
So now let's try the wrong log in information.
Right, capture text.
Forward the request.
Now, look at what we have.
A new message, and this time only the capture was true.
OK, so forward it and the rest.
And now the true login information and type of wrong captcha text.
And a new message appears and says, incorrect capture.
And forward the rest.
Now, this time, I'm going to fill in all of the fields with wrong values and forward the request.
Let's look at the message it comes back in correct capture.
So we can understand that at first checks capture then the login information, right?
And for the rest.
All right, so now we're ready to shape our attack, so I'm going to perform a replay attack and I'm
going to get a capture image and then I will try further requests with it.
So I will assume that I don't know, login credentials and created a dictionary file before.
And I fill the form with a correct capture and send.
Now the request is in burb.
And before forwarding it, send it to reporter and intruder.
Then for.
And look at the response, so the application checks the capture, but the credentials fail.
So forward it to the browser.
OK, so now we're at the critical point.
I'm going to drop this new cap to request.
So there are no more requests after this.
Now open the repeater tab.
And send it again.
And the response still says invalid credentials.
That means that the capture is still valid.
So let's prove it one more time with false credentials.
And sure enough, still the same.
OK, so now go to the intruder tab.
I've already told you about these tabs, right?
So go to the positions tab, clear the parameters and add username and password as parameters.
Then the attack type is cluster bomb.
And here we have just a two payload said one for username and one for password.
Payloads set one is a simple test.
Quick to load the word list that we created in a previous lesson, and she was it.
And do it for the payloads, too, as well.
So now open the options tab.
You don't need to change anything here and scroll down to grep match section.
Now, clear these input's.
Now we need to provide a message to differentiate the successful Longines.
And that message happens to be here, so copy that.
Then added here.
And Casey, give me a second to have a look, see if we missed anything.
No, I don't think there's anything that we need to configure anymore, so if you're ready, I'm ready.
Let's start the attack.
And the requests start to list in the attack window.
Let's wait for it to finish.
All right, so our base request is just like that and the associated response.
As you can see, so now let's go to this line.
Look at the response.
And sure enough, we are successfully logged in.
OK, so now let's see, because we can quickly check the code, so let's open up your terminal and Vukovich
bypass at all page.
So this line checks the security level, if the level is high or medium, then it will execute the following
lines.
Which compares the capture value sent by the user and the value in the session variable capture.
And as you can see, there is no code to assign a new value to the capture variable in session.
So you see, this is the main problem.
This new value adds in a separate request.
And that's what helps us to replay the correct capture in the session variable.