In our challenge, we set out to see if we can intercept a new user creation on
our bwap.test site
and change the password from what the user intentionally wanted to set it to.
Now in order for us to do this, we have to have Burp sweep running in the
background
and we do. As you can see here in just a second, is I Alt+Tab over. Now I have
intercept turned on
and I also have some information here filled out for us already ahead of time.
And the password
that I'm going to be putting in is password and I'm going to reconf- or just
confirm my password
by re-typing it and I'm going to hit create. We automatically get taken over to
Burp Suite
and you can see here that the packet is there for us to inspect before sending
it on if we want to.
Now this is where we're going to make our changes because I'm going to scroll
down here
and then zoom in for us. You can see there that because we're in HTTP with no
SSL or TLS,
we can see in plain text the actual login email and other bits of information
available to us
that is being sent through the post method of HTTP. Now this is where we're
going to go in and
start modifying because as I move over you can see that we have password and
password underscore
comp as our fields that we're wanting to modify. The password that I set is
password and I'm going
to zoom out and just add a number two to that and then go to the second one,
move over number two.
So now the password is password two and I'm going to forward that packet. If I
go back over to the
browser it says scroll down passwords did not match. What did I do? It would
probably help if I
learned to type but I went ahead and made sure that both of them match and you
could see here as I
zoom in for us real quick that the user was successfully created after I
modified that packet
and sent it forward with the updated password. So unbeknownst to me I'm wanting
to go to the login
screen and again Burp Suite is going to verify that we want to send that packet
and I'm going to go
back over and here I am at the login. Now default is B and bug but now I want
to log in with the
credentials that I as an unknowing user submitted in previous forms meaning my
password is password.
My login is Eric and I'm going to go type in P-A-S-S-W-O-R-D, scroll down and
hit log in and inside of our
Burp Suite we see here that that information has been intercepted and we're
going to forward.
Now going back over to the website we could scroll down and see invalid
credentials
meaning that the password that I intentionally set as an unsuspecting user
did not go through all the way. Wait a minute what if I now want to take evil
me and login as
the user that was supposed to be created meaning Eric and password to and I go
ahead and hit log in
we'll forward the packet from Burp Suite and the next packet go back over and
we can see that we
did log in with that modified password meaning that we successfully intercepted
the traffic
through our Burp Suite Interceptor proxy modified it and created that user. Now
we can go even
further and also take advantage of the fact in Burp Suite under our target by
expanding the top
level domain that we've been mess with so far and right here I'm highlighting
now zoom in for us
and we can see that we have user_new.php which is the actual PHP page that was
being used to
create those new users and we can see here that the packets affiliated with
that page were too post
and a get and one of them was me messing up because I don't have a spell and
the other one was us
modifying the password unbeknownst to good Eric and bad Eric is now able to log
in with those
credentials. This reinforces the fact that we do need SSL or TLS because now I
want to show you
something real quick if we go back to our page here I'm going to type in google
and just dot com
go to our proxy I'm going to forward all those packets real quick and then we
'll go in examine
them. We go under target and now we close our bwap.test folder and go to google
.com. In here
I'm going to try to do a post real quick of search and everything triggers
because they have
so much stuff going on behind the scenes and we'll search for that chicken. Yep
that's right we're
searching for every approving all the packets. Chicken and this may take a
second because it's
wanting to it's going to make me do it every single letter unless I just pause
it for a second
and then forward it. All right so now I'm going to search for the chicken. Now
you can see the
post right here this post packet that we have for HTTP against google is the
one where we
research in for the almighty chicken and you can see as we go down the actual
post itself
the gobbledygook doesn't make any sense and that's because it's not only under
SSL TLS it's also
encrypted as far as input is concerned. Now that's after we hit sin and it goes
through the
interception and goes to the actual google.com site that TLS or SSL TLS is
basically protecting
the data and transit portion of it but as we noticed on the browser itself
sorry wrong one
right there the browser itself we're seeing everything because we're right here
this is data
at rest and so burp suite is allowing us to be able to touch look manipulate at
the traffic that is
data in motion for us to potentially go through and exploit it but what does
this all look like
now that we have our solution done across the wire.