I’ve said it many times over in the talks I’ve given both at conferences and during meetings, the devices we carry betray a wealth of information about us without us even knowing.

Projects like Jassegar leverage this to masquerade as trusted wifi networks, and yet these issues remain.

And worse still are present in other standards beyond WiFi.

Enter Snoopy-NG, this is a suite of tools mostly authored in python which orchestrate the passive collection of the data our wireless devices are constantly screaming out into the Ether.

If you’ve ever spoken to me at a conference or on site, chances are you’ve seen my “bag of toys”; the reasons for this are for demonstration purposes.

There’s nothing I’ve found more powerful than giving a practical demonstration of an issue; be it process or security issues at fault (Please consider this the next time you raise a bug on a project’s tracker, and provide as much detail as you can screencasts are very useful).

So in this train of thought; following the announcement of RasPi2, it was time to add another tool / toy to the arsenal.

And so went the “rehashing” of some of the older tools, cases etc…

This was not without its issues however, seems if you try to draw more power than the Pi2 can provide it leads to some odd behaviour.

I took to the Raspi forums though the discussion appears to yield nothing but “you’ve got PSU problems”.

In the end the Atheros WiFi is now using a USB-Y adapter (hence the two use A cables attaching to the battery pack), as I’ve little time to waste on the debate of what a “non crappy” PSU is despite giving complete examples of all types of power supplies used in the diagnosis of the issues at hand, which appear to have been ignored.

Now running on Raspbian a git clone of Snoopy-ng was taken, depedencies installed and some modifications to /etc/rc.local to have snoopy-ng run at startup, and we’ve got a fully functional “drone unit”, though currently reliant on the old “blinken lights” to produce confidence in the running of Snoopy (the WiFi LED will blink in approx 30 second intervals whilst in monitor mode).

Currently this has had some 24hrs of stable data collection, with the only interuptions to uptime being the change between wall socket and battery power when moving around.

I would really be intrested in seeing a USB battery pack which can also take a “trickle charge” to aid in mobility, sort of a mini UPS if you will.

What’s next? maybe the USB Armory which looks quiet promissing; I’m also looking to add BadUSB, HackRF to the “bag of toys”.

I’ve also been looking at SDR on and off, particuarly instrested in the POCSAG Pager network which seems to be another clear text protocol, aswell as 802.15.4 (Xbee / Zigbee) which appears to be making itself into traffic controll systems and is again completely open.

Why you may ask would these things make it into the “bag of toys”?

I reffer back to my previous point of practical examples, unless you can demonstrably show people why something is insecure / broken they have little interest / time / money in fixing the issue at hand, if you want results far better to show someone the problem and work with them on the fix.

You can of course change the OS on the Utlite pro to things such as Kali and Arch assault the caveat being if you want to install on the mSATA and not run from the sdcard you’re going to need to use the serial connection.

My USB -> Serial adapter has a male connector, the connector for the Utilite also provides a male DB9 connection … so an adapter is on order.

Topology

1

[LAN Router] --- [ Utilite Pro ] --- [ ISP Router ]

So as can be seen here I’m sitting the device inline, with the intent to have it route traffic between the LAN and WAN, as an asside I also plan to use the WiFi to provide Wireless access disbaling the ISP equipment, also to allow segmented guest access for visitors etc / captive portal, but that’s a far off from solid plan at the moment

Suricata

The packages available from the ubuntu arm repos are 1.x and I want the new 2.x builds (Archassault however took my feedback and have built the 2.x packages) so in the interim to receiving the required equipment to install Arch on arm all the prototyping will need to use the unbuntu install.

NOTE The intention is to run in IPS mode, however IDS is suitable to complete the integration with logstash and kibana

Get some event data

Configure your SSHD for keyonly authentication, and harden to your preferences and then just expose SSH to the internet for a few hours; I’m not kidding here within ~12 hours I’d logged well over 1K attempted logins enough for suricata to log some ET COMPROMISED Known Compromised or Hostile Host Traffic group events.

This will take some time to start up, note that if you want to load in an existing log set, add start_position => "beginning" to the file {} declaration before starting logstash, after the back loading has completed I recomend you to remove this line, as it defaults to “end” and logstash tracks it’s position in the file if you leave this as beginning however it will always start at the beginning of the log and take a long time to startup needlessly

I’ve spent the last 2 days working 15hrs plus on this, and this is during some nasty Jet Lag courtesy of my return trip from Percona Live 2014, as the code keeps being pulled down for some reason I have mirrored some effective P.o.C code at github NOTE: This is not my own code I am only mirroring it, use at your own risk etc etc …

As for UEFI / EFI ? Don’t even get me started there nothing I have spent long evening hours looking into works for kali, not using the fedora shim nothing at this time; I’m very annoyed at this and will post again once I arrive to a resolution.

In the interim CaptTofu release some interesting material on leveraging Docker to test PXC deploys, he’s even go so far to produce some Ansible playbooks for the deployment process; I’ve been helping to work in some respect on the Ansible side and I can see a lot of potential in docker aswell as a lot of issues (it is a very young project it reminds me a lot of OpenStack hack in the diablo RC days), I encourage you to check this out.

Early warning This is a satirical blog post, with colourful language of which the sole intent is to troll automated scanners and script kiddies, those of a disposition nature should stop reading now.

Shortly after watching @chrisjohnriley’s Defcon 21 talk defense by numbers,
I began thinking how I could implement so of the methods within nginx, taking them to another level by trolling and generally pissing off anyone scanning the server.

Some background on this nginx server does nothing but bounce old domains, and links to their appropriate place on this blog, so it’s out of the way not something you’d typically see attacked en mass.

(seriously I see one or two hits from search engines on the instance, except recently China Telecom must LOVE my blog, 500K requests in an hour … aww shucks guys I love you too)

So let us start with response codes, because 400 response codes are so last century right? I really can’t see why the 7xx-rfc isn’t already a standard.

So I opted for responding to automated scans of my nginx instance with the 793 response code; helpfully letting the scanner know that the Zombie Apocalypse has occured where the instance is located and that I care not of their scans as I’m either shambling along biting everyone within reach and incoherently moaning, or I’m too busy trying to not get my ass zombified.

Zombie apocolypse is serious business; they should appreciate my early warning!

Providing this sorely needed public service is this small nginx server block after my main server block handling all valid requests.

if only those scanners could fully appreciate the midi tones of Rick Astley melodic symphony soothing them to sleep in the wake of the end of all things via Zombie Apocolypse … alas we wonder do calculators dream?

Yup no hostnames were being sent as part of the request, so China telecom doesn’t love my blog afterall … well screw you guys! I thought we had something but you were just a fake …

but wait there’s more just as the sweet verses dictate; we’re never going to give you up, so if you’re making so many requests in such a short time you must want to stay connected to me for as long as possible, it’s ok I’ve got you covered.