SpiderLabs / beef_injection_framework

Inject beef hooks into HTTP traffic and track hooked systems from cmdline
GNU General Public License v3.0
120 stars 42 forks source link

Shank Only forwarding Part of Page? #2

Open jbize opened 12 years ago

jbize commented 12 years ago

As Steve requested, I have copied our email thread into an issue here, so this first entry is in reverse order.

I'll chop out some of the extraneous signature stuff.

(Oh, and in case anyone is interested, I fixed my problem with ethN ports that weren't starting at eth0 by deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.)

The basic gist is that the shank attack isn't working for me in a VMWare Workstation 8 environment. Certain pages, the ones with very little (or very little unencrypted) content, seem to work well. Others partially work; they alert and hook, but don't render the page. Still others don't work at all.


Steve,

It's not just that some pages work and some don't, it seems relevant to the page size and the content of the first portion of the page. I believe that only the first packet of candidate pages are being forwarded, or perhaps the remaining packets are being forwarded, but aren't being reassembled.

I just set up the test with one victim. I opened FireFox on page www.exceptionalsoftware.com. It took a moment (20-30 seconds?) and I got the alert (and hooked the browser). But the page was blank (only the first packet?). (And I verified that the ARP poisoning is working.) Then I refreshed the page to load it all.

I captured this as follows:

root@bt:~# tcpdump -w shank-bize1.pcap -i eth0 -s 0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2974 packets captured
2989 packets received by filter
15 packets dropped by kernel

I have attached the file (as I believe you requested). It's 1.29 MB, so I apologize if it caused any mailer problems.

I hope this file helps you to figure out whats going on.

Thanks so much, John

PS: I'll try moving this to github issues as you request.


Subject: Re: Shank questions

Hmm sounds like a bug or two possibly, especially since some pages work and others don’t. BTW you can test ARP Poisoning on the XP boxes using:

arp -a

At the command line. You should see the IP address for the router as the same MAC as the shank host. Wonder if it's becoming "unpoisoned" somehow after the injection. If you could grab a pcap from the shank host during the process, we can look at it and see what's happening. Also let's move this conversation to the issues page on github, just paste the thread and your response over there.

Subject: RE: Shank questions

Steve and Ryan,

I still haven't generated the PCAP file, but I've made a lot more progress:

I started over with a virgin BT5R3 (Black Hat edition) VM and updated everything, then added the Ruby GEMs and paths as I indicated below.
    A big problem I had initially was that I was working with VMs that had Ethernet interfaces starting at eth1 or eth2.  Although I could add eth1 to the as a second shank arg with some problems, eth2 didn't work at all (it seemed to require an active eth1).  This affected beef and shank, but apparently not Metasploit.
    Another problem was apparently testing behind an Astaro firewall.  (I don't know why, but nothing worked.)
I set up a test VM LAN in Workstation, using a Vyatta router VM to provide an isolated LAN with NAT and DHCP.
    I need to be in an isolated environment and this seemed like a good option.
    I wasn't convinced that VMWare Workstation was poisoning NAT interfaces.
With this setup and some WinXP victims, the ARP spoofing is working well.
Example pages that hook consistently for me are:  http://www.prattlibrary.org/ and http://www.filehippo.com/

Unfortunately, it appears that the reason that most pages are hanging is that once I hit a page that matches the criteria for injection, only the first packet of the page actually reaches the browser. So for the pages that get enough content for the JavaScript to run, the rest of the page doesn't show up and the victim is left looking at a blank page. (Most injected pages don't alert or hook.) And of course, the busy indicator just cycles and says it's waiting for the server. (Other pages that should hook, just do the waiting part.) I'm using Firefox and Chrome.

Does this sound at all familiar or give you any ideas as to what could be wrong? I'm running all this on my laptop, a Dell XPS with an 8 core i7 and 16 GB RAM, so performance shouldn't be an issue.

Thanks, John


Subject: RE: Shank questions

Thanks for getting back Steve.

My day job is software developer, and tonight (and Saturday morning) my offensive security interest group meets. So I don't think I'll be able to get back to this before at least Saturday afternoon.

Did I do anything wrong with the GEM setup or BackTrack version? (It also looks like I'll need to switch to NAT interfaces instead of bridged. That won't be a problem will it?) It seems like I should be able to follow a few simple steps to a virgin BT5R3 VM to get it going.

I tried going back to BT5R2 (with everything updated), and got errors on the filter syntax, so I really suspect that something's messed up with my ruby environment.

I did try other victim hosts (volunteers). I didn't try a standalone BackTrack though.

Did you use any particular web sites for your demo?

Thanks again for getting back, I'll try to get a PCAP (via tcpdump or wireshark) when I can.

John


Subject: Re: Shank questions

Hi John,

Just a heads up we're discussing on this end. Can you open a ticket over here for it?

https://github.com/SpiderLabs/beef_injection_framework/issues

Also might help to have a pcap from an example session if you know how to grab one of those. If not let me know and I'll send over a command. Make sure you get whole packets (-s0 if you use tcpdump) when you do it.

One other question, have you tried simulating with different physical machines instead of VM's? Not sure if that's the issue but I'd be curious if it persisted out of VMWare. We used VMWare during our demo though, so not 100% on that, but it's worth a look. When I wrote thicknet, I remember VMWare did weird things to my MITM traffic. We'll play with it too.

Thanks for getting in touch, we'll figure something out :)

Steve

Subject: Shank questions

Hello Ryan and Steve,

I caught your talk at Black Hat and came away so impressed, I wanted to reproduce the shank attack it in a demo for a talk I'm giving for my company in a few weeks. Unfortunately, I'm having quite a bit of trouble and I was wondering if you could offer some help.

I installed BT5R3 and 5 victim XPs (with IE, FF, and Chrome) in VMWare Workstation, all running in bridged mode.

Installing shank on a vanilla Backtrack 5R3, I first did the following:

echo "export GEM_PATH=/var/lib/gems/1.9.2/" >> ~/.bashrc
gem install rest-client
gem install packetfu
gem install pcaprub

Then I replaced the IP addresses in shank.rb and autorun.rb to point to the attack machine.

I started beef, shank, and autorun, and then in the victims, started chrome and clicked on the "Learn more" link (https://support.google.com/chrome/bin/answer.py?hl=en&answer=165139&p=settings_sign_in). Perfect, it works every time with that page.

Unfortunately, that seems to be the only web page I've found that does work every time. Sometimes www.cnn.com works, but mostly, web pages just seem to hang.

Can you please offer any suggestions?

Thanks very much, John

nosteve commented 12 years ago

John provided a nice pcap that illustrates the issue. Ryan L is not seeing the same things on his machine, it could be VM specific, but definitely worth looking into.

Here's the pcap, shared with John's permission: http://nosteve.fastmail.net/shank-bize1.pcap

The actors:

192.168.10.16 / 00:0c:29:b0:98:5a - local victim host 74.208.224.106 / 00:0c:29:13:c3:5c - remote http server (gw mac, vmware NAT router I think)

00:0c:29:13:c6:2a - shank host

To see a normal instance of shank passing traffic, look at the GET replacement that occurs at packets 390 and 391. On L2 you'll see victim send GET to shank in 390, then in 391, you'll see shank pass it to the server, but with a modified "Accept-Encoding" line. This is normal, and necessary to preserve plaintext in the HTTP session.

Actually every packet back and forth follows that pattern (minus the modification), packet goes from victim -> shank, then shank -> server and back again - it's observable on L2. Every packet should have 2 entries.

BUT at packet number 452, this does not occur. The HTTP/1.1 packet comes in from the server, destined for the client, but it never gets modified and forwarded. shank will normally add the hook to these, but it's not happening here, shank seems to eat the packet instead. The server retransmits this same packet at 457 and 518, but neither of those are modified and forwarded. The size of these packets is 1514.

On the other hand, packet 699 and 700 show shank working correctly, adding javascript to a different HTTP/1.1 response, increasing its size from 590 unmodified to 669 with the added content. So we know it's working, just not on larger packets - maybe because we're running out of room.

Strangely, Ryan L is not seeing this behavior, so maybe there's something a little different between environments, or maybe there's some slack on one end due to a browser or OS. Not sure. As John mentioned, it seems like this condition would come up a lot, not sure why we haven't been having more trouble here. I'll dig into it more and see what's up.

jbize commented 12 years ago

Steve and Ryan. The updates to shank.rb this afternoon seem to be working very well. Thanks!