we're gonna talk about cross site scripting
session related attacks. Remember, you can do
at any layer, and the best way to take advantage of hijacking is when you have some sort of disconnect between the layers.
If we're doing a layer to toe layer three attack, we attack the Mac address because it's not mapped perfectly to the I P address. If we're doing a layer three toe layer four attack, we're not mapped perfectly between those, and we don't have a really, really tight link because of the
basically the abstraction in the layers.
Then when we do cross site scripting and other session attacks were doing the exact same thing over again. What we're saying is there's this loose coupling between, say, the U R L
and the data inside of the U. R L. Between the application and the cookie. There's this little separation in there that as ah, penetration tester we're going to take advantage of If there is a weakness in that particular application, we should be testing for cross site scripting
in our Web application testing. But we bring it up
here because we want to talk about it from a hijacking perspective. So what is cross site scripting? Well,
the attack leverages a script. Where is that script? While that script is served by a malicious or compromise server Web application? Here, take this. In other words, we've attacked the Web server itself.
And once we've attacked that Web server, we've put data there that the client then retrieves.
What we're doing is we're trying to achieve a client side
attack and inject a client side script into that browser. But it's got to be in a place where that client can get to it.
what we're trying to really do in the cross site scripting is to hijack their session, and the session variable that we want
Remember, a cookie is just a substitute for the authentication mechanism. Hi, I'm Dean. And here's my password.
Well, Web Server doesn't really want to mess with any of that stuff, So what it says is, Oh, yeah, that's really good. I have you in my database. Let's not keep on making you submit that every single time. What we'll do is we'll hand you back something that's unique about you for this particular time. This cookie and that represents
the fact that you've established authentication with us,
and now we're gonna go from there.
The user name and password hopefully was encrypted when it was transmitted. But
that doesn't mean that the session cookie
is going to be protected as it's passed around. Now there are two kinds of persistent other two kinds of cross site scripting is the persistent and the non persistent.
Generically, the persistent attack occurs when a malicious, when the malicious code is stored on the server
or the Web application and then the custard, then the end user. The target retreats it a non persistent. It occurs when the malicious code is injected into the server Web application by the user, usually through some sort of channel of email.
Okay, so let's look at the persistent a little bit. So we've got some sort of Web site out there that allows posting of tax G in a Web to a world that's pretty much everything. So it's got a forum
or a message board, and it allows us to put that up there, and what the attacker does is they get there before the user does, and they say,
it's going to be some sort of HTML and Java script. It could be something else. This is posted to the Web site, and what happens is is we wait for the end user to show up. The user comes to the website, they trust the website, and then when they get there,
they render that attack code because their browser actually pulls it down.
And at that moment in time, what they're doing is they're stealing the cookie.
So here's your little script snippet in here.
The attacker can use the stolen cookie, the hijack, this session.
So in this case, what they do is they redirect that data that says, Hey, when you came to this site, we gave you a cookie. Now give that cookie back to us because we want it for something else.
And so now what happens is instead of giving it back to the Web server that you think you're doing it too, you're giving it back to another address,
and then you've got a persistent
attack sitting on a server that redirects you to another location or actually redirect some of your data, which is that cookie back to that other location That's why it's a cross site scripting. It's across different sites, a non persistent cross site scripting. Okay, now what happens is
in this case, we have to make sure that the servers a little bit miss configured and what it said. What we say is that that this requires a site that not check the u R L for malicious input.
So okay, so what happens? Well before that? What happens is, is the victim was sent an email. We're relying on that social engineering aspect of Oh, I recognize this girl. I'll go ahead and do that, and the victim looks at the normal link to the website. They think that it's there, but there's these added variables to the end,
And what happens is that you are l redirects the victim to another site, which is the bad guy site,
so that it reflects the malicious code off of example dot com
and uses that session that was created with example dot com to pass that information over to the bad guy site.
So when we talk about non persistent were reflecting it back.
There's also the http reefer attack. So when I go to a site
I say, Oh, I've been here and it says here, go to this other site.
Oh, I'll click on that. I'll click this other link and I'll go to the next site over here,
this site that I'm now going to says, Hey, where'd you come from? I want to give people credit or I want to give the website credit.
Hey, where'd you come from? Did you get authenticated
with the session cookie or something else?
So what happens is it answers the question, which is a
we're supposed to do, refers It answers the question. Who sent it to my site?
On the refer you are l is included in that request that comes across another words. This site says, Oh, you came from there because it gets brought along with it. When it gets brought along with it,
what could it look like? Well, it could be evil. Stipe.
So a lot of pay sites, by the way, rely on the reefer information for secure access to the site. They don't generate their own session here. They rely on the session that was created over there to make this session good.
Now, if the referring. You are l can be determined by the attacker. They can bypass the security and get right to the pay site. So what they can say is
I'm not gonna go there. Do my authentication mechanism get redirected to hear what's gonna happen is is I can see that. Oh, maybe I'll capture that information is it flows across here that's coming back into my into my website. I can see that redirect that's actually being created. And what I'll do is I'll capture that information
and instead of authenticating there, then I'll just go straight to here
in that reefer attack. What we can say is, Hi, I'm coming from there when I actually never did.
Let's go back a 2nd 4 man in the middle and kind of get ourselves an anchor point here. What is a man in the middle attack?
the attacker convinces
toe pass the traffic
It may be like in our diagram right here. We've got a wireless access point that both work stations should be going directly to the gateway.
as the man in the middle, What we do is we convince them that this is not the best route to the wireless interface right here. The best route to this is through us. If this was ah, wireless access point, if we were looking at this, we might use a tool like
in wireless. We would use something like a pineapple and a pineapple would basically impersonate this gateway
in order to do this wireless. But wirelessly, by the way, which we'll talk about in the wireless section, we have to get closer to the work station so that our signal is stronger than the original gateway there.
All we're doing is we're convincing that
person or that application that we are the next logical step in the equation.
There's also a man in the browser attacks, and this is, ah, hijacking attack on. What we're trying to do is we're trying to
act is a proxy. So in this case, we said What? We're going to be the best way to get to that wireless connection in this case, what we did is we said, Well, the best way to get to that Web server is through us as a proxy server.
So a man in the browser hijack intercepts the calls
on the target on the victim's browser,
and normally what we do is we give that victim some sort of Trojan resource. Now what's really cool about this is man in the browser tax. Don't have to be really complex. If you go into any browser that you have, and you look at the options within it. What you'll see is that there is a setting for proxy servers.
If I can convince your browser or you
to install this one little tweak to the configuration off instead of going directly to the Web, go to me as your proxy server because I'm better at that.
Then you will refer all traffic through me
through my proxy server and then what I will do, by the way, as I will pass it on and get to inspect all of that traffic.
Next is a session fixation attack.
What is your session? I d
How is that generated?
It's usually part of the U. R. L.
So now what we want to do is instead of
making that user go directly to that site
through social engineering, what we'll do is we'll say we are that site again. This is kind of like our browser in the middle attack. We are That site here is that you are l and you click it. And what happens is you say I'm going to pass all the data
to that particular website.
So what happens is is I'll say, give me your user name and password and I'm gonna give you back a session. I d
I don't give you back the session idea. What I do is I turn around here and I say hi. Um, here's my user name and password. Give me a session. I d. Now I have what it appears to be your session I d and I pass it back to you. I sit in the middle of this attack
and I usually look at what your session I d is and capture that information.
The target's gonna click on the link, and they're gonna log in because they think that they're logging in there, but they're logging in through me to get there, the Attackers sends the same link, accesses the same site and gets all the data that they want.
Now. What we could do is we could pray upon the fact that some
are not long enough and random enough and big enough.
And how we would do that is we would guess at all the different session I. D. S.
Now, if it's really, really long session, I d That's going to be very expensive and it's gonna be very time consuming. But if the application is weak at generating those session ideas, we can keep on trying every single session I d. If there's a predictability in that session, I d. That we go from session I d number one
the 1000 to 2000 to 3000
and we see a pattern in there than what we can do is we can say Okay, well, my session I d or the last session I d. That was there. They're handing them out once every five minutes. So what I'm gonna do is I'm gonna guess that this session I d right here
so we can brute force it with no knowledge whatsoever and just try every single different number in the sequence or recon. Be predictive about it in our brute forcing