Closed minanagehsalalma closed 4 years ago
Please, just stick with the one issue I closed earlier or just DM me on twitter
just DM me on twitter
@makuga01 But i don't use Twitter!
Hmm so what do you think about this ?
That you don't understand how csrf works :d By the way you should create twitter asap since there is sooo much security knowledge there
That you don't understand how csrf works :
Lol it's not just csrf but csrf + dns rebinding for the sake of bypassing SOP.
there is sooo much security knowledge there
Who said that you need an account to browse it ?
You still didn't tell me about what you think of this .
Have you checked the article?
At least try it before saying it won't work.
It works and will always work if the site doesn't check for the refer header and if the browser is vulnerable to rebinding.
@makuga01 here is the most comprehensive article about dns rebinding you could ever found on the web
So now what do you think about adding that tunnel? Almost all the features in here has been done before in other repos but the tunnel thing no one have did it before.
I still don't understand where is that csrf you talked about earlier...
https://github.com/nccgroup/singularity <- this works pretty well on browsers, I created dnsfookup to help in exploitation of mainly server-side bugs Anyways what tunnel are you talking about?
I still don't understand where is that csrf you talked about earlier...
@makuga01 CSRF stands for cross site request forgery
And is prevented by SOP : same site policy.
which means any kind of trying to perform actions on a site on a different origin is considered a CSRF
now every site uses tokens so you can't make any requests without including these tokens.
Keep in mind that SOP prevents get requests only not get.
So attackers use dns rebinding to bypass SOP and grab the token to send a successful post request.
CSRF can be used in too ways 1- if the user is already logged in you can take advantage of that and the browser will send the cookies on the behave of the user like the user requested the site.
2-if the user isn't logged in but the target site is on local level which means only the user who have access to and we will use his browser as a proxy in case if that target site uses a weak password or doesn't require one.
I know about it.
Anyways what tunnel are you talking about?
tunneling feature for more control and monitoring if everything is going as it should that's in case of CSRF just like A command and control server (C&C server)
and since both of that project and yours an application of dns rebinding...there should be no difference and it should work normally.
Huh , got it ?
You didn't have to throw a definition of csrf at me :d
Good luck with accomplishing your csrf case 1 with dns rebinding btw I don't believe that it's possible
You didn't have to throw a definition of csrf at me :d
You are the one who keeped saying it won't work that you made think you don't know what it means.
I don't believe that it's possible
Really !!! Come on ! You must be kidding ... after all the links that i sent you and the vids and inages and all that text that i typed and you still don't think it will work ?
I am fucking sure that you didn't even bother hovering your mouse oover the freakin links ! And all you say it won't work blah blah.
The simplest thing you can do is 1- log in into your freackin router 2- create a link using your tool that points to the router ip 3- out a js that site that tries to access an page that requires auth 4- watch it fuckin work and stop saying anything without trying or researching about it !!!!!
@makuga01
Something is not right with this dude... he is annoying me too in my dns rebind repo...
Something is not right with this dude... he is annoying me
Lol really ? I am just giving out suggestions.
Just a default login screen of my router, nothing unexpected - just dns rebinding, no 1337 csrfs happening unfortunately :( The cookies weren't sent because gel0.space doesn't match IP of my router so yeah... I looked at everything you sent me and you are not making lot of sense here
You are saying that when A - malicious website that wants to steal your info B - router adress X - dns rebinding adress and I make successful request from A via X to B that the B cookies would be sent along????
The image and video from pwnfunction you sent me talks just about classic csrf, no rebinding, no special stuff, just classic A->B request
On the other hand https://sinister.ly/Thread-DNS-Rebinding-Attack this talks about dns rebinding attack in browser, you go from A via X to B - no B cookies, again just clear dns rebinding attack (the other article is pretty much about the same thing)
Sorry but I don't understand what are you trying to prove here and you won't do that with swearing in github issues and ending a sentence with five exclamation points
Just a default login screen of my router, nothing unexpected - just dns rebinding, no 1337 csrfs happening unfortunately :( The cookies weren't sent because gel0.space doesn't match IP of my router
Really ?
Can you show me the js that you putted in there ? I am sure that you are doing it wrong even ask @h43z and he will tell you
you go from A via X to B - no B cookies, again just clear dns rebinding attack (the other article is pretty much about the same thing)
Because it's the router who stays logged in routers ? Just check https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
You clearly don't understand how cookies work.
@minanagehsalalma
The thing is in Scope of cookies section in the link you sent me
And please stop spamming on mine or @h43z's repos because it truly is hella annoying :D if you feel like you've got a great idea but nobody understands you, just fork a repo, tweak it to do the thing you want and publish it. It's not that hard 😁
I think this is the part where I have to tell you @makuga01 "YoU aRe WrOnG!!!1" lol this guy.
@h43z :( please explain I don't understand
The thing is in Scope of cookies section in the link you sent me
Yup i think you got it. The url refer isn't what it makes it work but where it goes what makes it work .... the browser sends the cookies to the target url and it have nothing to do with where it came from .. it would only matter if the target site checks for the refer header
Huh , where the js code you used ? Make sure that you include the tokens if there is any.
"YoU aRe WrOnG!!!1"
@makuga01 see i have told yo :::)
So when I am logged in let's say my smart home and I get there via rebinding I should be still logged(I mean in the rebinding response)
rebinding response
@makuga01 Yup... open chrome network tab from the dev tools .. and watch the cookies being sent with the url request headers.
No cookies so far :( Trying with singularity on localhost with php session cookies
This is the successful request
No cookies so far
I don't see the requested url in the pic if its local host then there should be just 127.0.0.1 in the pic without anything else so the request goes to it ... use the normal url one just as the article i sent before not this merged url ... also what code do you have on that server ? Where do you make send the request to ?
Better test it on a simple http server with a login.
@makuga01 here you go
@makuga01 here too...
In a Cross-Site Websocket Hijacking vulnerability we abuse the fact that when making any connection to a website, even with a different origin, the cookies for that destination are sent regardless the conflict between the origins, that's how we have CSRF (Cross-Site Request Forgery). Since websocket does not have any kind of origin check by it self (no SOP) the developer should do the origin check when the initial http request for Protocol-Upgrade has been sent. But of course they don't!
With dns rebinding ... SOP is mostly useless.
I think you have no idea what you are talking about (or reading somewhere on the internet). The websocket article is not about dns rebinding at all.
Cookies are bound to the origin that set it! If it was an IP that set it they will be bound to that, if it was "localhost" it will be localhost AND NOT eg. 127.0.0.1 or 192.168.1.x. The same goes for a domain. localhost != 127.0.0.1 != google.com
@h43z just let him be... There is no point in arguing with him. If he wants to be the greatest hacker of all just let him. Don't lose time explaining something to someone who has no intention in understanding
The websocket article is not about dns rebinding at all.
@h43z Not really. .. the article was in my feed and i commented it here cause he mentioned cookies being sent to the target website which @makuga01 says can't be true...
And as you know dns rebinding = no SOP
Which the same thing in the article.
localhost != 127.0.0.1 != google.com
Yup but the browser sends the cookies to the target website not to the attacker so what i said still correct.
someone who has no intention in understanding
Lol you described yourself in a sentence.
@h43z according to what you said csrf doesn't exist... lol you are so funny.
Lol you described yourself in a sentence
Then don't lose time and do not create any more comments or issues here
Thank you!
Yours truly, @makuga01
Then don't lose time and do not create any more comments or issues here
@makuga01 lol dude you are the one who said it won't work while there is a terrrm and a name for it.
The websocket article is not about dns rebinding at all.
@h43z Not really. .. the article was in my feed and i commented it here cause he mentioned cookies being sent to the target website which @makuga01 says can't be true...
That is NOT what @makuga01 said! Cookies exist and work.
And as you know dns rebinding = no SOP
If you do a dns rebinding attack on a google.com page to an IP 1.1.1.1 THE GOOGLE COOKIES WILL N O T BE SENT TO 1.1.1.1. The cookies that were created on 1.1.1.1 will be sent!
If you do a dns rebinding attack on a google.com page to an IP 1.1.1.1 THE GOOGLE COOKIES WILL N O T BE SENT TO 1.1.1.1.
That's what i am fuckin trying to say.... 1.1.1.1 cookies will be sent to 1.1.1.1 ! To perform whatever the fuck action that you put in that post request.
That is NOT what @makuga01 said!
No he did ... just read the comments again... after i told him to login then try to csrf he said cookies were not sent and can't be sent .. and
I don't believe that it's possible
Just a default login screen of my router, nothing unexpected - just dns rebinding, no 1337 csrfs happening unfortunately :( The cookies weren't sent because gel0.space doesn't match IP of my router so yeah... I looked at everything you sent me and you are not making lot of sense here
If what you are saying would work, the world would be in flames now sweat_smile
https://github.com/makuga01/dnsFookup/issues/1#issuecomment-611778147
@makuga01 @h43z i think you both owe me something.
The problem is you have no idea what you are talking about most of the time. Your sentences are 99% gibberish. No one understands what you want to say. You quote this link and that forum and some video. You are unable to communicate in any meaningful matter. And on top of that you are a little retarded cunt.
And on top of that you are a little retarded cunt.
@h43z oh Thanks for your politeness.
You are unable to communicate in any meaningful matter.
I have said CSRF what else do you need me to say it's more than enough for everyone to get what i am trying to say.
https://sinister.ly/Thread-DNS-Rebinding-Attack
Especially this one
What do you think ?
Also if you still think the cookies won't work on csrf https://i.ibb.co/Trv1GzT/images-q-tbn-ANd9-Gc-QGXAt5-Ux-Mk2-AA-EOz7-Ym-Kr-6c-WTjr2hl3-HO4-CGFDTq-RHLpo8s8-usqp-CAU.png
If it's not enough then watch this https://youtu.be/eWEgUcHPle0