Search the Community
Showing results for tags 'macos'.
Found 3 results
ICS on macOS: There and back again Apple likes to hard code the subnet (192.168.2.1) that is used on its implementation of Internet Connection Sharing (ICS). I don't know why; best I can figure is that somehow allows them to more reliably prevent the client network to access any resources on the host network. This is something that can be prevented on other ICS setups with a firewall rule. Which brings me to another point. Apple likes to change firewalls. Apple likes to change everything. They recently switched to PF and a lot of the guides online are from before this change. So we've established something here. Apple changes things. And we can't stop them from changing things. So what do we do? Accounting for Change One thing has remained consistent in their various iterations of ICS. They use the subnet 188.8.131.52/24. This gives us 1 constant, and if we've learned our lesson, we also know that it may not stay constant. So let me backup. *ahem* We have zero constants. But we can plan for this one constant changing. Apple needs this base principle (a subnet) on which to build its ICS implementation. Think of a single stream in the woods that recursively branches out into thousands. In order to catalog the various species in the stream, it would not be wise to visit and collect samples from every stream. This would be inefficient. It would better serve you, your time and your study to head to the one stream whence all others came. The source. This subnet is the one stream and any changes Apple makes will use it. And even if it changes it, it's still only one change we have to account for. Knowing this, we can start to look at this problem from another perspective. We can stop visiting individual streams and concede that our network must in the 192.168.2.1/24 range. What does that mean for Pineapple users? It means you can't access the Pineapple on 172.16.42.1 anymore. Is this a bad thing? Meh. It's a thing. For sure. I'd posit it's even a good thing. If we leave our pineapples on the default network, we eliminate the guesswork needed for anyone hunting pineapple. Yes, those people exists. And the tools necessary to do so bank on the fact that you haven't changed your default settings. See here. Is there a simple solution? Just move the pineapple to a different network! How? Depending on the version of the Pineapple, you can use WiFi or Ethernet or Etherner-over-USB to make the initial connection to the Pineapple over SSH on 172.16.42.1. Once you're in: # This one could be anything you want. It's what you'll use to connect after the reboot uci set network.lan.ipaddr='192.168.2.10' # This is where the Pineapple will get it's Internet from. uci set network.lan.gateway='192.168.2.1' uci commit && reboot That's it. Once you've rebooted, you can access the web interface and SSH like you would at 172.16.42.1, but if you used my configuration settings from above, you can access it from 192.168.2.10. What if Apple changes the subnet? Then you only have two values to change. Be sure to actually turn on ICS from the Mac's System Preferences > Sharing Pane.
Ding ding, it's payload time This is a two stages payload. First you use the 'injector' that will install a small bash script which is a wrapper for sudo. The script will store the passwords. Second, you use the 'cleaner' to get the passwords back and clean the backdoor. So basically, you get access to a computer running MacOS or Linux (you can config the payload by setting mac=true) and you install the backdoor. A couple of hours/days/weeks later you comme back, grab the passwords and erase traces. Easy Link: https://github.com/oXis/bashbunny-payloads/tree/master/payloads/library/credentials/SudoBackdoor I'll submit a pull request but first I need people to test this on MacOS and Linux. It works on my Linux Mint. Ninja!
Hi, I just received my Bash Bunny a few days ago and I've been tinkering around with it. It seems, to me, to be quite buggy: - Windows does not recognise the RNDIS interface at all. Not on Windows 7, not on Windows 10. - On MacOS, the ethernet interface *sometimes* works, sometimes it doesn't. When it does work, *sometimes* it is possible to connect to the Bunny using, quite often, SSH doesn't start up even though FTP and other services are running. This even after a few minutes waiting. - The serial interface often conflicts with having network & storage together, resulting in nothing happening or giving only access to storage. (I did this by adding "SERIAL" to the standard payloads already on the Bunny) - Using the manuals found online for network sharing (MacOS Internet sharing through 172.16.64.64), I cannot access the internet from the Bunny, so I cannot update it. On Windows, that's entirely out of the question as Windows does not even recognise the RNDIS network device. Windows gives the following message on the RNDIS driver: The drivers for this device are not installed. (Code 28) There are no compatible drivers for this device. To find a driver for this device, click Update Driver.