MFVX

Ok, there is a fix for this here . It uses a patch . I can't guarantee this patch is safe, but it seems to work fine on my Centos installation. wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2 tar -xvf cd libpam-google-authenticator-1.0 nano ignore_nofile.patch #paste the contents of the patch, then ctrl + x, Y. patch < ignore_nofile.patch make make install service sshd restart [/CODE] Then, if the user you are trying to login haven't set up his 2-step authentication with [CODE] google-authenticator [/CODE] The system will jump to password authentication.

I have enabled google-2-step authentication on /etc/pam.d/sshd , but I want to know if there is any way I can create an exception to allow some specific users to login without using this method of authentication.

Not yet. I don't want to do this kind of thing on my workplace. I'm just waiting till I go back home. EDIT: Yep, it works fine! Just a little bit dangerous to be distributed that way.

Just something cool I've found today, and might be useful to someone: XDA - Android: WiFiKill So, if you don't have and injection-capable dongle, you can use and rooted android phone to connect to the other APs and make the users look for other AP. Also, you can use usb tether to provide wireless to your notebook if your native card doesn't have the required linux drivers. Just check usb0.

Thanks for the answers, leg3nd! Man, you are really fast!

My worry is on the internet access being shared part. Lets say I have the following network: ______ The Internet -wifi-> Building Network -wire-> Someone's WIFI AP -wifi-> Attacker's Notebook -wire-> Wifi Pineapple -wifi-> Victim's PC ______ My doubt is how could the administrator of the network I'm forwarding traffic to could detect that Attacker's Notebook is doing nasty things.

Leg3nd, could you please change one more thing on the next version of the script? It would be great if you add one more variable on the "setup", so users can hard-code the gateway IP instead of trusting on "route -n" method. I did it on mine and I think it would be better for the other users. You could also add a note recommending the upgrade to sslstrip 0.9. I've had some errors with 0.8. http://www.thoughtcrime.org/software/sslstrip/ Also, I'm trying to make some kind of "fake captive portal" (a page hosted on the attacker's computer, where the victim has to enter some info or read an alert. I guess I could do that with your 2,3 and 4 attacks. When I figure that, may I PM you to incorporate on the main version of the script? Other cool thing would be some kind of selective redirect. Something like: redirect IPs 192.168.0.50 and 192.168.0.55 to a warning page when they try to visit hak5.org (Hey, fellow hak5 user, you are using a creepy-evil-poisoned AP. Be sure to use an ssh tunnel!). Now, one more question: How easy would be for the owner of the network you are using to provide internet to your victims to discover that there is an attack like this happening? How would he do that? Something besides seeing someone using high amounts of band? _ Sorry if my english seems confusing. I'm not a native speaker, but i'm working on that.

Well, on BT5 I've used MSFpath="/pentest/exploits/framework" *It is a symlink to /opt/framework/msf3 And it seems to work just fine. You disabled it through ssh, with /etc/init.d/dnsmasq stop /etc/init.d/dnsmasq disable If you are having problems with victims being unable to resolve hostnames, just replace $gatewayIP with your gateway IP, on line 142.