Set Via Dnsspoof

[skimpniff]

Pineapple Hardware Version: Mark IV

Pineapple Software Version (ex: Shmoocon Beta, 1.0, etc.):2.3.1

OS used to connect to the pineapple:Backtrack 5 R2

Network layout of how your setup is connected (including IP information):default ICS via ethernet

All the tools/options that are running on the pineapple when the issue happened: DNSspoof

Is the problem repeatable (Yes/No):Yes

Anything else that was attempted to 'fix' the problem:

Greetings,

I have searched message boards galore and not found a satisfactory answer yet. I am trying to resolve the DNSspoof "loop" issue faced when using it to connect to SET. I am specifically trying to resolve this using the Wifi Pinapple Mk4. Obviously if the *example.com command is used, the redirection from SET to the legitimate page will be captured in the DNSspoof parameters thereby catching the victim in a loop and reducing the "ninja" factor of the attack. Do you have a suggestion or perhaps know of a discussion that already exists that addresses this issue successfully? I have tried using the IP address in lieu of example.com (in the DNSspoof parameters), but that does not seem to work. I have also thought about replacing the redirect address for SET to the IP vs the URL, but have not had the opportunity to try it yet. Is this idea something that would need to be attempted from a template, or is it possible to modify the cloned site created when using the "clone site" option in SET.

The setups I have used so far are:

Initiate standard SET setup for credential harvester in BT5R2, using site cloner. IP = 192.168.1.8:80

The following DNSspoof commands in Pineapple:

1. 192.168.1.8 *example.com (credential harvest success, redirect failure)
   
2. 192.168.1.8 IP Address for example.com (failure to connect to SET)
   EDIT: I realize now this wouldn't work because nobody types in the IP to navigate anywhere. (Duh).
   

Edited June 29, 2012 by skimpniff

[PineDominator]

Pineapple Hardware Version: Mark IV

Pineapple Software Version (ex: Shmoocon Beta, 1.0, etc.):2.3.1

OS used to connect to the pineapple:Backtrack 5 R2

Network layout of how your setup is connected (including IP information):default ICS via ethernet

All the tools/options that are running on the pineapple when the issue happened: DNSspoof

Is the problem repeatable (Yes/No):Yes

Anything else that was attempted to 'fix' the problem:

Greetings,

I have searched message boards galore and not found a satisfactory answer yet. I am trying to resolve the DNSspoof "loop" issue faced when using it to connect to SET. I am specifically trying to resolve this using the Wifi Pinapple Mk4. Obviously if the *example.com command is used, the redirection from SET to the legitimate page will be captured in the DNSspoof parameters thereby catching the victim in a loop and reducing the "ninja" factor of the attack. Do you have a suggestion or perhaps know of a discussion that already exists that addresses this issue successfully? I have tried using the IP address in lieu of example.com (in the DNSspoof parameters), but that does not seem to work. I have also thought about replacing the redirect address for SET to the IP vs the URL, but have not had the opportunity to try it yet. Is this idea something that would need to be attempted from a template, or is it possible to modify the cloned site created when using the "clone site" option in SET.

The setups I have used so far are:

Initiate standard SET setup for credential harvester in BT5R2, using site cloner. IP = 192.168.1.8:80

The following DNSspoof commands in Pineapple:

1. 192.168.1.8 *example.com (credential harvest success, redirect failure)
2. 192.168.1.8 IP Address for example.com (failure to connect to SET)

why are you running dnsspoof when you are using other tools that redirect test victims?

how about not redirecting everyone, just redirect what dns's you want for dnsspoot, leaving out example.com

[skimpniff]

why are you running dnsspoof when you are using other tools that redirect test victims?

how about not redirecting everyone, just redirect what dns's you want for dnsspoot, leaving out example.com

The idea is to use the pineapple for traffic analysis (or any other Pineapple salad), but have targeted users redirected to SET for exploit via the bevy of tools SET offers. This could be for a couple of reasons,

1) negating the need for spear phishing/trying to get a target to click a link (ie all attempts to get to facebook trigger an exploit)

2)facilitating a social engineering/spear phishing attack (ie an email targeting WinXP/7 users with a real link such as microsoft.com that is then redirected, vice the more complicated option of constructing a believable link to a fake server address). This would allow more attack vectors to occur simultaneously, traffic analysis and java attack for system exploit to name a couple.

Also, by using the Pineapple the attacker would not need to gain access to a specific network and negotiate any of the possible roadblocks presented, and would also be able to remote deploy the attack multiple times in multiple places with reduced setup time.

I got a reply from Dave Kennedy when I asked the same question, his response:

...no workaround as of yet, I need to rehaul the backend so that after a certain counter is hit from an IP it kills the dnsspoof portion of it by replacing the legit hacker site with the real one...and redirects back to victim. it's a bit challenging and not an easy one.. I'll get to it when I can =)

Edited June 27, 2012 by skimpniff

[PineDominator]

The idea is to use the pineapple for traffic analysis (or any other Pineapple salad), but have targeted users redirected to SET for exploit via the bevy of tools SET offers. This could be for a couple of reasons,

1) negating the need for spear phishing/trying to get a target to click a link (ie all attempts to get to facebook trigger an exploit)

2)facilitating a social engineering/spear phishing attack (ie an email targeting WinXP/7 users with a real link such as microsoft.com that is then redirected, vice the more complicated option of constructing a believable link to a fake server address). This would allow more attack vectors to occur simultaneously, traffic analysis and java attack for system exploit to name a couple.

Also, by using the Pineapple the attacker would not need to gain access to a specific network and negotiate any of the possible roadblocks presented, and would also be able to remote deploy the attack multiple times in multiple places with reduced setup time.

I got a reply from Dave Kennedy when I asked the same question, his response:

...no workaround as of yet, I need to rehaul the backend so that after a certain counter is hit from an IP it kills the dnsspoof portion of it by replacing the legit hacker site with the real one...and redirects back to victim. it's a bit challenging and not an easy one.. I'll get to it when I can =)

I see.

I was thinking that why are we using dnsspoof when redirecting everything? "172.16.42.1 *" especially when the device remembers the actual ip address and completely bypasses dns and any rolls you want them to connect to, an iptable rule should redirect everyone to 172.16.42.1

I think It would be cool to have a module/built-in-tool that could check the dhcp list of users connected to the pineapple and indevidually set iptable rules to redirect them to 172.16.42.1 and a way to black/white list, as well as settings to undo the redirect after a condition is met and a way for other modules/tools to communicate to enable/disable all or one client.

I believe this would work.

Edited June 27, 2012 by petertfm

[skimpniff]

I see.

I was thinking that why are we using dnsspoof when redirecting everything? "172.16.42.1 *" especially when the device remembers the actual ip address and completely bypasses dns and any rolls you want them to connect to, an iptable rule should redirect everyone to 172.16.42.1

I think It would be cool to have a module/built-in-tool that could check the dhcp list of users connected to the pineapple and indevidually set iptable rules to redirect them to 172.16.42.1 and a way to black/white list, as well as settings to undo the redirect after a condition is met and a way for other modules/tools to communicate to enable/disable all or one client.

I believe this would work.

Yea, all regular traffic would be running through the pineapple "business-as-usual" on the 172 network, having whatever pineapple salad you want fed to it. DNSspoof would be on, but only to grab example.com and throw it over to the MITM machine hooked up via ethernet (in this case: 192.168.1.8 *example.com) for SET to work it's magic (via port 80 where SET establishes it's own server) then throw it back into the wild with a new passenger (Java exploit) or a little lighter (captured creds).

As for a pineapple tool to help, would it be feasible to have the pineapple (DNSspoof) determine if the user was already spoofed and not repeat the spoof (like Dave mentioned)? For example:

target A connects to WifiPineapple and tries to got to example.com.

DNSspoof recognizes example.com and sends target A to 192.168.1.x (SET).

SET exploits target A and redirects to example.com.

DNSspoof detects target A has already been spoofed and ignores Target A allowing target A to connect to real example.com.

target A updates status on example.com, complaining about how slow WifiPineapple is, but at least its free internet.

Hilarity ensues.

The exploits work now, and if the operator were to disable DNSspoof after the exploit, the target would go about their merry way unaware. As it stands now, when the target is redirected from SET, a "page not available" shows because of being caught in the web again. The ideal situation would be to not have to manually disable DNSspoof so you can catch more than one phish and allow the process to remain automated.

Edited June 27, 2012 by skimpniff

[skimpniff]

Ok, so I have found some interesting and relevant items while poking around the SET config folders. I thought I'd post what I found here, partly because it is relevant to the topic and partly because I have seen the question "Where does SET put the cloned site" in half a dozen posts across the web.

Disclaimer: This is for Backtrack5 R2

So first, when you use the site cloner option in SET, the cloned site html file used for the exploit is:

/pentest/exploits/set/src/program_junk/web_clone/index.html

Second, the config file for SET that dictates which web templates to use and where to redirect the victim if a particular template is used (including web cloner) is:

/pentest/exploits/set/src/html/templates/template.py

For applicability of this post, the existing templates (for facebook at least) appear to be a little out of date so I recommend running an exploit of your choice and selecting site cloner for the site of your choice. Then navigate to option one above, copy the index.html file to the template folder relative to the site you just cloned. If you are using a page that already has an existing template, just copy it overate[/b]. If you are going to make your own template folder, don't forget to append the template.py file appropriately.

Next is theory at this point because I haven't actually tried a full test, but I have tried stages independently and I believe it will work. Once I confirm or deny I'll update the post.

In the template.py file the last line of each template command tells SET to redirect to the actual website after executing the script and uses the full URL (ie "http://www.facebook.com"). If the last line is changed to the IP address instead of the URL, SET will successfully send the browser to the correct website via the IP vice the URL, preventing DNSspoof from looping it back around to SET again.

If this solution alone still doesn't work, I'll try changing the DNSspoof command from

192.168.1.x *facebook.com

to

192.168.1.x http://www.facebook.com

192.168.1.x www.facebook.com

This way, even if the IP is converted to the URL by the browser, it should still work because the IP addresses for facebook all navigate to https://www.facebook.com.

If anyone tries this before I get a chance to, please confirm or deny success.

UPDATE: No luck so far.

Edited June 29, 2012 by skimpniff

[skimpniff]

So it has been almost a year since this post went up originally. I have played with this off and on since but still have not come up with a solution. Has anyone else found a way?

This problem is not limited to when the Pineapple is connected via ethernet to the box running SET. I have had the Pineapple connected via WAN/LAN on my home network with my laptop connected wirelessly and gotten the same result.

To recap the problem:

DNSspoof on the pineapple config = 192.168.1.4 *.example.com

SET running on 192.168.1.4

1. Client associates to pineapple, navigates to example.com (123.45.678.9)
2. Pineapple redirects request to 192.168.1.4
3. SET runs exploit
4. SET redirects client to example.com (123.45.678.9)
5. Pineapple redirects to 192.168.1.4

Desired effect:

1. Client associates to pineapple, navigates to example.com (123.45.678.9)
2. Pineapple redirects request to 192.168.1.4
3. SET runs exploit
4. SET redirects client to example.com (123.45.678.9)
5. Client connects to example.com (123.45.678.9)

Any ideas for a solution would be greatly appreciated.