Jump to content

Skinny

Active Members
  • Posts

    150
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by Skinny

  1. I'm not sure I follow what you mean by daisy chaining a second non-PoE switch. 

    The laptop isn't taking any power from the PoE switch, but it is most definitely causing an imbalance on the line. The connection from switch to phone it extremely fragile in this case. If I disturb the line at all by plugging into the Tx or Rx side of the passive tap, the phone momentarily drops off the network. When stability returns to the line and the phone recovers, the capturing laptop has problems and will not see the traffic or will only see it sporadically.

    The new design places some blocking capacitors on the tapped conductors in an effort to keep any inadvertent DC draw occurring due to the presence of the laptop. So far this solution has worked.There are a few more cases I'd like to test to make sure the solution is as robust as I hope.

    To replicate the problem I'm seeing, try to capture traffic using the Throwing Star LAN tap with a gigabit VoIP phone connected to a gigabit PoE switch.

  2. Has anyone used a passive network tap (i.e. throwing star tap or diy) to capture traffic while connected to a gigabit PoE switch? I'm targeting a VoIP phone and am getting spotty results. Here are the details:

    • Phone: Grandstream GXP2130
    • Switch: Netgear GS108PE
    • Tap: Similar schematic to the throwing star tap

    The phone boots just fine using PoE with the tap in line and negotiates a stable 10/100 Mbps connection as expected. When plugging into the receive side of the tap, the phone drops the network connection momentarily but recovers. It's inconsistent but sometimes I can capture a small amount of traffic in Wireshark. On the transmit side, I get absolutely nothing. 

    If I disconnect the phone from the PoE ports and plug it into the regular gigabit ports, I have more success. Both transmit and receive can be captured, but the phone has be powered from a normal wall power outlet for this to occur. 

    I'm curious if anyone else has had the same experience? I would really like to be able to capture traffic while the phone is plugged into the PoE port.

    Also, if you have a PoE switch that is not gigabit, do you have similar issues? 

    Thanks for any help at all!

    -Skinny

  3. It's been a slow month for devices but here is the latest update:

    • Nook Color (BNRV200)
    • Apple iPhone 5s (ME305LL/A)

    The Nook's behavior was unexpected. After associating with the Pineapple, it sent a deauthentication packet to kick itself off the Pineapple after not finding a way to reach a particular Barnes & Noble website. It couldn't find the website because I normally use the Pineapple in a manner that doesn't not let the client have an outside connection.

    You can find the updated spreadsheet here:

    https://docs.google.com/spreadsheets/d/1VO0VSm6n79BndK2KMqmokSVlPaOMQQAH0vkEyQRZIxY/edit?usp=sharing

    • Upvote 1
  4. Hi Guys,

    A friend of mine just started a physical security business and his first line of products are lockpicks. Each pick is made of spring steal and is hand polished. He's even got a set where the handles are hand wrapped in paracord.

    parapicks_small.jpg

    He's been putting a lot of hard work into these things. If your interested you can see his stuff at http://darkmetalfabrication.com/

    If you'd just like to tell him they look cool, check him out on twitter: @darkmetalfab

  5. Be careful in your assumptions. Not every bad actor cares about the encrypted traffic. Some of them do not care for banking information, the latest Facebook update, or the last email received. The information and capabilities that the Pineapple can provide can be leveraged to devastating effect in malicious hands.

    Not all sites of interest have SSL encryption. Someone's browsing habits can help establish a pattern of life. Not to mention can be fantastic fodder for blackmail. If an attacker gets a room in a hotel next to a the room of a prominent politician and said politician happens to have a certain taste in sexually deviant websites, associating his or her MAC address with salacious photos can cripple a career. If you give this presentation to an audience, ask them if they would approve of their significant other knowing their browsing history for the past 2 weeks.

    In addition, a MAC address associated with an individual's name makes for a great tracking mechanism. Retail stores have toyed with targeted advertising to your phone based on the MAC address that walks in to an establishment. With a handful of pineapples, I could keep track of when you leave home, when you arrive at work, when you arrive at the gym, or when you visit your mistress. If I set them up correctly and place them well enough, I might be able to get your phone to associate through the pineapple before you arrive at any of these places thus following your browsing habits at these places.

    Another interesting fact is that you can use the Pineapple to force newer phones to give up the SSIDs they've associated with (older phones would do this automatically). If you tell me you've never been to "X" establishment / city / country and the Pineapple makes your phone spit out SSIDs from a particular region or area, you're busted. The great thing is I can do this without letting you connect to the Pineapple at all.

    I use the Pineapple on a daily basis and depend on people walking out the door and not shutting off WiFi before they leave their house. For my specific application, I just want the device to talk. I don't care what the client device sends, as long as it stays connected and makes packets. The Pineapple enables this activity. If I can achieve this, I win.

    Know that there are many edge cases. 95% of the Pineapple's use falls neatly into the infosec / pentest arena it was meant for, but there are plenty of other esoteric ways of leveraging this device that can have serious consequences for a victim.

    Good luck with your presentation.

  6. Three more models to update the list:

    • LG G Watch R
    • Apple iPhone 5s
    • Apple iWatch

    The LG G Watch R has a fairly interesting past. When initial consumers bought the product, it didn't have WiFi. An update enabled the capability later. Some people are still unaware of the capability. The device I came across had never been connected to an access point before, so the Pineapple had nothing to entice it with. 

    The iWatch was interesting because it deauthenticated from the Pineapple after being connected for about 30 seconds. By deauthenticated I mean it actually sent a deauthentication packet to the Pineapple. I've seen this on a number of iOS 10 devices. It appears that in order to keep it connected, you must make sure the Pineapple is providing an Internet connection. After the device can reach out over the Internet, it has no problem remaining connected.

    https://docs.google.com/spreadsheets/d/1VO0VSm6n79BndK2KMqmokSVlPaOMQQAH0vkEyQRZIxY/edit?usp=sharing

    • Upvote 1
  7. The following models have been added to the list.

    • Apple iPod 4th Generation
    • LG G4
    • Samsung Galaxy S7

    In addition, I've added the OUI for each device. I'm not giving the full address for reasons of privacy. I'm including the OUI because sometimes you might want to know what device you're chasing. The OUI will certainly tell you the manufacturer, but specific matching OUIs can let you know the model as well. For instance, an OUI may tell you that a device is an Apple from a simple Internet search, but I've been able to look back over my own records to tell that a specific OUI belongs not only to Apple but that it belongs to iWatches. Once again, here's the link:

    https://docs.google.com/spreadsheets/d/1VO0VSm6n79BndK2KMqmokSVlPaOMQQAH0vkEyQRZIxY/edit?usp=sharing

    • Upvote 1
  8. Had an interesting time today with a LG cellphone. Perhaps some of you are familiar with this phenomenon but it was new to me. The owner of the LG had disabled WiFi on the phone but had his location services (gps positioning) services set to high. The location service overrode his WiFi settings and began sending out probe request broadcast packets to help with its location efforts. When you checked the WiFi settings, they clearly showed the service was off.

    We solved this mystery with Wireshark. As soon as he put his location service on a less aggressive setting or completely off, the probe requests stopped. So, if you don't want your MAC address to be broadcast, be sure to tone done the positioning system on your mobile device.

  9. I run into quite a few WiFi clients throughout the week and each one reacts differently to the Pineapple's strategies of ensnaring clients. I've started to record these differences by characterizing the mobile device and the options needed for the Pineapple to be successful. The fruition of those efforts can be found here:

    http://skinnyrd.com/clients-react-to-the-wifi-pineapple/

    This article explains my process and results. However, if you just want to see the results, they are here:

    https://docs.google.com/spreadsheets/d/1VO0VSm6n79BndK2KMqmokSVlPaOMQQAH0vkEyQRZIxY/edit?usp=sharing

    This document will continually be updated with mobile devices, so check back occasionally to get updates. My most recent update to the document, iPhone 6s, didn't make the article.

    • Upvote 3
  10. Just a follow up on this. It turns out that the device in question had a profile pushed to it that made it aware of the WPA2 encrypted AP, but that push never gave the device any credentials to authenticate with the AP. So as far as the device knew, it thought that SSID was genuinely an open access point to begin with. Once I gave the device the opportunity to connect with the same SSID, it grabbed it right away. 

    After looking at the packet capture, this explanation totally lines up with what I was seeing. The device never attempted the four-way handshake. It went straight into open authentication.

    The Moral of the Story: If your company controls mobile devices from a cloud based system and they push preferred network lists to the mobile devices with the name of secure APs, they also need to give those phones the credentials for those APs for mutual, secure authentication. Otherwise the device may assume the APs on the list are open and will fall for a tricky pineapple.

    • Upvote 2
  11. 6 hours ago, Foxtrot said:

    A packet capture of this behaviour would be incredibly interesting. What device was this? 

    I plan on taking a capture as I have a small window of opportunity with the device, however sadly I can't reveal what the device is. Which also means I can't give out the pcap, but I will let everyone know in general terms what is happening in the packet capture. Sorry, but its the best I can do in this situation.

  12. I had a unique experience today targeting a mobile device. The Pineapple was setup with all the options running on PineAP. The mobile device beaconed out an SSID that happened to be the SSID of an AP that has WPA2 encryption.

    The Pineapple then very dutifully captured the SSID and replayed it. To my utter surprise the mobile device connected to the Pineapple. This unique association was verified with 2 other pieces of equipment to make sure we were seeing things correctly.

    In general, this doesn't happen, at least, this is the first time I've seen it happen. The WPA2 4-way handshake process is there to ensure that both the client and the AP mutually recognize each other. The process is just as much to show the client that the AP is the correct AP as much as it is for the AP to find out if the client is a legitimate client.

    I've heard @Darren Kitchen and @Sebkinne say on several videos that WiFi can be implemented differently from vendor to vendor; it was just interesting to see that in action today. Just know that some devices will respond positively to the Pineapple even if the SSID you are spoofing normally uses WPA2. It's always worth a shot. You might get lucky.

    • Upvote 3
  13. Hope it continues to work for you. I'm not sure about the mobile phone issue. I once did an 8 hour assessment with the Nano using my phone to control it. A couple of times during the day I lost access. During those times I would just put my phone down and wait about 15 minutes. Eventually, I would have access to the page again and the Nano never stopped the entire time. 

    I'm not sure why you're phone is behaving differently. Instead of accessing the management AP, try to get on through one of the spoofed SSIDs. It's all part of the same network. You should be able to still access the management page.

  14. The antenna ports on one side of my Tetra were starting to get loose today, so I decided to investigate. Turns out there is a lock washer that is supposed to be gripping the nut. That washer was turned around so that the teeth were facing the plastic as shown here.

    P_20160911_171500.jpg

    All that needed to happen was to turn the washer around so that the teeth face the nut. The problem was just on 1 side of the Tetra. I tested it and it looks like the new configuration held better. Also, you don't need to take the housing off the Tetra to do this as there are support posts for the nut on the opposite side (which is a fantastic design thought). However while I had it open, I found out why it's not called the Mark VI :grin:

    P_20160911_171930.jpg

  15. As stated, if you are running it with your PC, make sure you use the Y connector cable provided to supply enough current to the Pineapple.

    As far as accessing the wireless management AP, once you are connected, make sure when you go to the browser that you put the appropriate port number at the end of the IP address.

    172.16.42.1:1471

    When you say you are doing a bunch of stuff, what do you mean? What process are running? Are you running PineAP? If so, do you have options set to Aggressive? Are you trying to do Recon at the same time? 

    It is possible to overtax the Pineapple or cause service issues due to any of the following:

    1. Not having enough power (usually a current draw issue)
    2. Adding too many modules on the internal flash memory so that you run out of space
    3. Adding too many USB devices (back to number 1)

    Take some pictures of your setup and let me know how you're using the Pineapple and I'll try to reproduce it.

  16. 15 hours ago, coyotlgw said:

    So This works like the MkV where it quietly claims to be whomever you are asking for, but then why do I need to broadcast SSIDs if I cannot see them and the clients just join whatever i ask to join as the Pineapple?

    If the SSIDs are in the Pineapple, they should be broadcasting. Spin up Wireshark with your wireless interface in monitor mode and sniff the packets. That will let you know for sure if there are being broadcast and what those broadcasts look like. I've found that sometimes laptops and mobile devices have a hard time displaying multiple SSIDs coming from a device with the same MAC but usually they show one or two. 

    Another thing to check is your Target MAC. If it's not FF:FF:FF:FF:FF:FF or the mac of your target, you could have problems seeing the SSIDs.

    Secondly, not all devices will connect to the Pineapple in the way your laptop did. Some devices don't send probe requests embedded with SSIDs. Some devices send out broadcasts that ask access points to relay what SSIDs are assigned to them. In those cases you'll want to lure a targeted device by broadcasting a smart list of open access point SSIDs.

    • Upvote 1
  17. I knew that WiFi implementations were different from manufacturer to manufacturer but yesterday I got to see it at the packet level. The question I wanted to answer was the following:

    After a device send outs a probe request or a broadcast, how long does the Pineapple have to send an SSID the device is looking for?

    Round 1: The first experiment was carried out with a Motorola Moto E tracfone. The phone's preferred network list (PNL) was preloaded with 4 common SSIDs. The pineapple had about 200 SSIDs in it's list. PineAP was running.

    Initially, I turned on all of PineAPs options to force the phone to connect, but after sifting through the packets, I noticed that before the Pineapple had broadcast the phone's intended SSID, the phone had already connected to the Pineapple. Going back, I did the experiment again but this time just checked Allow Associations (No Broadcast SSID or Beacon Response). The packets showed that all the phone did was send out a probe request to everyone with the SSID it was looking for. With only the Allow Association option checked, the Pineapple sent back a Probe Response validating that it was that SSID. The association followed.

    Classically, this is how the Pineapple is supposed to work.

    ANS 1) So in these cases, the pineapple is always watching for and will respond immediately to a probe request with an SSID tagged along with it. Even if the pineapple is in the middle of broadcasting a huge list of SSIDs, it will stop and service this probe request with a matching SSID to ensnare the client.

    Round 2: The second experiment was carried out using an Amazon Kindle Fire (the cheap model). In this case Allow Associations was not enough to cause an association because the Fire did not broadcast out a probe request with an SSID but just a probe request with a Broadcast. It was asking for all the other APs to respond with their SSID. It was performing a roll call.

    I'm told this is the reason Beacon Response was created, so I turned it on without activating Broadcast SSID. In hindsight, this was silly, because Beacon Response can not respond if you aren't allowing SSIDs to be broadcast in the first place. The result was that nothing was sent out, so nothing happened.

    For kicks though, I flipped it around and turned on Broadcast SSID but did not allow Beacon Response. The results were interesting. The Fire finally saw the SSID it was looking for and sent a Probe Request directed at the Pineapple. The Pineapple responded with a Probe Response, but then the Fire never took it further. After waiting awhile, the Fire sent out the same Probe Request but it refused to authenticate to the Pineapple. It was as if the Fire didn't believe the Pineapple to be it's true AP.

    As soon as Beacon Response was activated, things changed quickly. After the initial Probe Request from the Fire, the Pineapple absolutely hammered the Fire was probe responses. There were hundreds of  repeat responses. This overwhelming onslaught convinced the Fire that this was the correct AP. The Fire authenticated.

    ANS 2) Unlike the Motorola, the Fire responded only after seeing the SSID it was interested in. Another interesting tidbit is that the Fire has a broadcast interval of 10s. This is pretty short, so it would preclude me from being able to find out if the Fire would react to a pineapple responding 45s after a broadcast. As it is, response times came just seconds after a request.

    Conclusion

    More testing is needed but I can see from just these two devices what the outcome will probably be. Since each manufacturer has its own way to implement WiFi, there will most likely be a range of responses. You'll probably have devices that will respond to the pineapple because they are always listening for a probe request and others, in an effort to save battery, that may only listen in certain intervals. The way forward for me will be to look back over my archive and see what devices are more common in the environments I've been encountering and learn how those devices operate under test conditions. At least now I know how to run the test. 

     

    • Upvote 1
  18. Results from Yesterday's Questions

    Here's a followup from yesterday. My setup for this experiment was screwed up. Everything is corrected now. The Pineapple broadcasts SSIDs in the following order. Names starting with:

    1) Special Characters

    2) Numbers

    3) Capital letters

    4) Lower-case letters

    The rate of broadcast is also a bit more encouraging than yesterday. I get roughly 175 SSIDs per second in the Normal interval mode. It looks as though I am receiving every Beacon frame from the Pineapple. I know this because there is no random nature to the SSIDs being broadcast. Everything is being received as outlined above.

    So if you have an SSID bank of 3000 names, it will take appoximately 17 seconds to broadcast everything on the list. The Low interval came in at about 115 SSIDs per second and the Aggressive was a blistering 275 per second.

    Why Does Any of This Matter?

    Lets say you are targeting a specific mobile device. That device will send out a probe request once every 30 seconds to 20 minutes depending on the device. My hypothesis is that when that request goes out, you have a certain amount of time to respond. If the list of SSIDs is too large, I think you might miss that window. Therefore, there would be a certain list size that is optimal that will be based on the amount of time devices are willing to wait for a response. 

    Of course, I could be wrong. I may find out that many devices are always listening, therefore it wouldn't matter when you responded with the correct SSID. Intuitively though, this feels wrong because my daily experience tells me that most devices seem to finally attach to the Pineapple during or in sequence with their probe request interval.

    Next Steps

    For my next trick I'm hoping to see if I can experimentally identify the longest time a range of devices is willing to wait for a probe response. I'll let you know how it goes.

    • Upvote 2
  19. I'm doing a bit of research using Wireshark to examine the behavior of the Tetra in different modes of operation. I'm getting results, but I don't trust that my equipment is reacting fast enough to the packets being broadcast. Can anyone tell me the rate at which the broadcast packets occur (number / sec) when the Pool Interval is set to Normal and the order the SSIDs are broadcast. With my Wireshark capture it indicates a rate of roughly 40 packets per second.

    Also, from the packet capture it looks as though the SSIDs start out broadcasting alphabetically, but as the capture progresses, SSIDs begin to get broadcast more randomly. The randomness is what makes me think I'm not seeing everything.

    If I'm not seeing everything, this brings up a bigger question. Can the devices being targeted in the wild keep up with all those broadcasts? Would it be better to start slowing down the Pool Interval for a more productive chance at snagging a targeted client? All fun things I hope to explore.

    Edit: If you're curious about the other two settings, I'm currently getting 7 to 10 SSIDs broadcast per second at the low interval and approximately 100 per second at Aggressive.

    • Upvote 1
  20. In the process of working with the Pineapple Nano this morning, Windows 10 had a nasty little oddity waiting for me with Internet Connection Sharing (ICS). I thought I'd make everyone aware of the strangeness and the solution. 

    The Problem

    Windows 10 ICS would not allow the Pineapple to connect through my windows box. After repeated attempts at a solution, I found that Windows 10 was deceiving me. When I looked at the adapter settings, the IP address would appear as one thing and in the command terminal, it would appear as a completely different address.

    Win10_ICS_fix01.png

    The Fix

    The fix to this is to first click the Advanced... button at the bottom right of the IPv4 Properties box. After clicking, it should look like this:

    Win10_ICS_fix02.png

    Highlight the 192.168..... address and click remove. Next, click ok twice and close the IPv4 settings box. Finally, right click on the Ethernet adapter governing the Pineapple and disable the adapter.

    Win10_ICS_fix03.png

    Then right click on it again and Enable the adapter. The correct IP address should stick and ICS should work once again.

    How Does this Happen?

    Whenever I have finished using the Pineapple on my Windows box, I always turn off ICS. For some reason if the Pineapple is plugged back in and you go through the ICS setup process again, windows seems to give you the IP it wants you to have for ICS and let you keep the IP address you specified earlier for the device. It's a bit strange. 

    If you leave ICS on after using the Pineapple, upon reconnecting the Pineapple, everything seems to work fine.

    Anyway, I hope this proves to be helpful to someone. Have a great day!

    • Upvote 2
×
×
  • Create New...