Saturday, 31 January 2015

Cuba - Internet, currency, and other things

Just a month and a bit before the United States began to open up dialogue with Cuba, my girlfriend and I took a trip to Veradero and Havana. For years, we had discussed going there and I had been wanting to visit the country for some time (as Canadians, entering and exiting Cuba is fairly uneventful), so we decided that we'd finally go.

Me (back-facing, right) wandering the streets of Havana.

I highly recommend that if you get the chance to go that you do so. If you're American and can go now, I am also envious of your alcohol and tobacco allotment--I'll explain a bit later on.

Some of the photos in this post were taken by my girlfriend (included the above).

The Internet and Mobile Phones

At least for tourists, access to the Internet was rather easy to come by but on the flip side it was not cheap. No free Wi-Fi was readily available wherever we stopped as being that the market was in control by the state, so too were all the goodies.

The Veradero airport left much to be desired too. Also this is how the West protests.
For 30 minutes of Internet access, you had to pay 4 CUC (about $4 USD). Internet can be purchased either in 30 minute or 1 hour blocks. Only cash is taken for access as you are required to speak to a person to get an access card--it should be noted that I don't recall seeing a single vending machine for anything while there.

Typical 1-hour access card. (Source)
The access card contains a one-time code you scratch for and details on how to connect to the wireless network. Upon connecting and opening your browser, you get a standard pay-wall you require identifying to. You then enter your code and the clock begins to tick away. If you disconnect from the wireless network or sign out via the pay-wall, your remaining time is valid for up to 30-days. You cannot share the code either without having the previous device disconnected.

I had no trouble accessing any Western media outlets and nor did I run into trouble viewing my favourite websites. Connecting to my home computer via SSH did not create any troubles either. However, knowing the state that Cuba is, I would not be surprised if my actions were monitored the whole time I was signed in. Having said that, my name was never attached to that code that I purchased either so in some ways I was anonymous.

I did not investigate any further what sort of setup there was but the access points were from Huawei (much like a lot of equipment I saw in Cuba).

The price may seem expensive but it is nowhere near as bad as trying to use your mobile phone. Upon my landing in Veradero, I was sent a text by my carrier, informing me that calls would be $3-4 CAD per minute and that all outgoing texts would cost me $1.50 CAD. But then the data cost came up: $20 CAD per MB--to put that into context, an Ubuntu ISO would cost me $19,500 CAD just to download.

So yeah. Stick with using the Wi-Fi there.

Currency

Cuba has two currencies: the Cuban Peso and the Cuban Convertible Peso (CUC). The Peso in itself is really meant for the locals and cannot be converted to CUCs or any other currency, but CUCs themselves can be converted to Pesos (for nationals only) or a foreign currency--including American Dollars. When we were there, we were informed that the Peso would be retired in favour of the CUC much to the delight of Cuban residents--CUCs have incredible buying power there.

You'll need cash to buy hand-made goods.
That aside, I wanted to write about acquiring the CUC notes as it is different than anywhere I've gone before and I had made a quip last week about how it was less complicated than Bitcoin.

Before leaving the country, it's considered best practice to load up on whatever your local currency may be--assuming you have a reserve currency like a Euro, US Dollar, Canadian Dollar, or Pound Sterling. At the hotel, you can bring up your money to the front desk and they will record how much money, your name, and what hotel room you had in a ledger. The exchange itself would be whatever the CUC translates into from your currency plus a fee of a few percentage points--no more than 5% I believe. This is the easiest way to do this.

However, if you end up being away from your hotel, acquiring CUCs requires you to go to a Cuban state bank branch. Upon your arrival, you will wait in line and will require your passport to retrieve any cash. They'll record your passport number in a ledger alongside your name and the amount you took out, plus the aforementioned fee.

All of these prices are in CUCs and are more or less equal to the US dollar.
It's really just that and far simpler than Bitcoin. I do however suggest not exchanging your currency back from CUCs as you'll be doubling up your fees--I did spend the $450 CAD I brought with me but I didn't exchange it all at once.

One other thing: credit cards. If you have a credit union-derived credit card in Canada, it will work--this goes the same for most banks from my country as well. If your credit card is from an American-based network like Capital One or Chase for example, it won't. This is likely to change soon under the new relationship we're seeing between the United States and Cuba.

Alcohol and tobacco

Alcohol is dirt-cheap in Cuba.  How cheap? Well, a 750 mL bottle of Havana Club 7-Year Old costs $34 CAD for me in Vancouver, but was just 8 CUC (or like mentioned before, $8 USD) at the grocery store we went to in Veradero. Earlier, when I mentioned that I was jealous of the alcohol allotment that Americans were getting, I was not kidding about it. You can get a serious amount of decent rum for the $100 limit that is being set.

Having mojitos at the same hotel Jimmy Carter once stayed at
Rum is open-poured everywhere and they make it easily accessible for you if you're a tourist. Personally, I am not a fan of Havana Club now having tried other Cuban rums but anything from the island is still the most superior of the Carribean. If you get a chance, try Santiago de Cuba or Santero, which are both just as cheap.

Foreign liquor as you might not be surprised are not cheap and seem to match the prices here at home.

Cristal and Bucanero beer.
Beer in Cuba is also easy to find but admittedly not as good. Bucanero and Cristal are the most common and at the resort we stayed at, Cristal was dominant. Foreign beers just like foreign liquor is available but the cost is significantly higher.

One of many cigars I picked up.
Tobacco while plentiful in Cuba is not as cheap as the rum and beer. Twelve cigars will run you about 85 CUCs. Having said that, the smell is awesome.

Other things

There were a few other things I can remark on that were interesting.

The stage it was sitting on was of even worse quality.
Expect to find that everything in Cuba is either hand-made or made to at least be repairable at the cheapest cost. Electrics taken on a lassez-faire sort of approach wherein it was not uncommon to find things that otherwise would never pass code back here at home. My favourite was the wooden electrical strip (pictured above) which was being used by the DJ at the resort on random nights.

The "reader" made it look like a Japanese manga. I did not look at it.
Books that were available to tourists tended to be about Cuban revolutionaries and are usually in either English, Spanish, or Russian.

The airport's only highlight was literally this.
They're also a tad more liberal about acquiring pharmaceuticals. At the Veradero airport, I had the ability to purchase Valium or Viagra without a prescription. I have to wonder how Canadian customs would have felt if I had tried to bring that back home.

Closing

I'll close off with this:

The water is nice and warm too.
About 150-200 KM from where I took this photo lied the United States. It just seemed tragic that for over half-a-century, the two countries were not on speaking terms yet were so close physically.

If you get the opportunity to visit Cuba, go. You will not have a bad time and you will want to come back.

Thursday, 22 January 2015

Taking back my money from Bitcoin -- an adventure with the BTC ATM

This opening image sums up my 'fun' with the Bitcoin ATM

Over a year ago, I had written about using the world's first Bitcoin ATM--run by Bitcoiniacs. At the time it was a pretty unique experience because never in my life have I ever had to have someone process a transaction manually for an 'automated teller machine'--not sure how this term even makes sense for what the machine does but I digress. However, I did drop $20 CAD into the machine and then promptly watched over the course of the past year and a bit the value go as high as $120--I had purchased 0.094 BTC.

To make matters even more interesting, I apparently showed up in the New York Times' website after they used a photo from that day for an article.

I'm the fellow in the centre holding a phone, wearing a black jacket
Gone is the day where there was a line up waiting to try out this new fangled ATM, a first of its kind it was touted as. I didn't need to wait 15 minutes for some guy on a laptop to its left to process my transaction as it was instead sitting idle, waiting and perhaps begging for someone to be interested in it.


However, a lot of things have changed: the machine no longer wanted to scan my palm in order to identify me. Instead, it asked for me to sign up with my mobile phone number, enter a PIN of my choice and then confirm, and then enter a six-digit number it sent via SMS. To add to that, it asked for a scan of my ID--however the ID scanner was broken and I was just asked to point whatever I identified with to the web cam above the screen.

Post-It Notes are quite professional
Also what the heck happened to the palm scanner and what did they do with that information?

Being that I suspected I either have gone dormant with them or they just completely ditched old data, I went along with using my new account. However, it had no details about who I was and told me that I would have to send money to an address it specified and then wait for it to be confirmed.

I've used ATMs in so many countries and in every case it's a matter of inserting my card, feeding it some numbers to identify that it's actually me (hopefully), and then magically money comes out if I have enough of it in whatever currency it may be--the only thing I need to be concerned about it is if my card is compatible with the network it uses. In the Bitcoin world, you have to make sure you have your Bitcoin wallet set up on your phone or you need to bring something that can make a transaction (such as a laptop or maybe a tablet), you then need to tell your wallet to send the money to an address the ATM specifies, wait for it to be at least confirmed by at least one other address, and then magically the ATM will let you pull it out when it's good and ready.

This more or less describes Bitcoin
How long does it take to retrieve real, useful money from an actual money ATM? Well maybe a few minutes but rarely have I have I needed to spend more than 45-60 seconds to get my money out and the majority of the time is just waiting for the machine to talk to my financial institution.

With this BTC ATM? It took me 25 minutes but only once I had gone through a bunch of hoops. The only place on Earth I've experienced where real, actual money has even come close to taking as long from starting a transaction and finishing it was when I was in Cuba and had to get some extra CUCs (Cuban Convertable Pesos) as I had run out and wanted to exchange my Canadian currency for it--I've been meaning to write about being a tourist in Cuba for a while and at some point I will.

Here's how it went down step by step:

I show up at the ATM and immediately discover I have to create an account to use it. Fine. So I go through the process I had outlined earlier. Now I have an account with them and then attempt to withdraw money--it is at this point I realise I need a Bitcoin application on my mobile phone.

I downloaded the default Bitcoin application and find out that I cannot enter my private key easily so I opt to download Mycelium after searching around via Google to find one that would just let me do that. Why is it that a non-mainstream Bitcoin wallet is needed to do something as simple as enter a private key? I am sure it is doable if I connect my phone via ADB, but that's ridiculous.

In the meantime, I've left the coffee shop and gone to grab a slice of pizza from a place around the corner using real, physical money. How long did the transaction there take? Probably 2 minutes as I was having the pizza reheated in their oven.

The related apps made me raise my eyebrow a bit
OK. Great. I have downloaded the supposedly useful Bitcoin application and now managed to enter my private key. Time for me to go back to the coffee shop and extract that money.


As you can see, 8 minutes has passed since I had downloaded and installed the wallet application--and for reference, I started at around 12 PM.

Oh. But now there's a new catch: the ATM won't be able to do anything until you've had at least one confirmation. How long does it take for one to occur? Well here's what the app shows at this point:


Four minutes has passed since I sent the BTC to the address the ATM told me to. OK. What shall I do? I guess I'll go check out the comic book store around the corner and see what's new. That will occupy enough time right?


Great. I've avoided spending any real money at the comic book store and finally have a confirmation--the confirmation itself did not appear for 5 minutes after it came to be. Back to the coffee shop I go!

I do the same process again: sign in, request some money, and immediately get told that I have insufficient funds. At this point I am pretty much near "fuck this" and am considering going back to the office but I now see I have another confirmation!


OK. Let's try this again. Oh. What is this?


I have $23.24 available for me to withdraw! Finally! What time is it now? 12:45 PM? What time did I start? 12:00? Did I wait in a queue to use this thing like the last time? No? What the hell.

/r/actualmoney is going to nuts after they see this
Seriously, real money doesn't require this much effort and getting a bank account isn't this painful either.


What a fucking dumb experience this was.

Edit - 20:43 PDT:

I forgot to mention that there was a funny flaw I found in the ATM: if you enter your phone number and PIN, then wait for the SMS to come but cancel out, you can do the same process again, have it send you a code again but use the unused code from before. You cannot however reuse a code that was sent.

Monday, 19 January 2015

Discovering and remediating an active but disused botnet

On a network I help manage, we kept getting malicious DNS alerts for “luna1.pw” on an appliance we had installed. Due to the way the network was configured, we were able to see the name request coming in but no traffic activity. This was unusual because the appliance was configured to monitor all traffic but why was it not picking up anything further than what it was reporting? Why didn’t the supposed malware connect? Resolving the domain lead to an answer:



This explains why the alerts were only coming up as DNS and not capturing any traffic to the domain. The question now is: who owns it?



So the domain doesn’t exist any longer. This became even more unusual because why would malware be connecting to a non-existent domain? Did the domain become lapsed? Did the botnet get shutdown? Well, it did as it turns out that the specific malware using the domain also used other domains and were shut down.
Since the domain was no longer in the possession of anyone and I was seeing attempts to reach it, I decided that the best course of action was to acquire the domain so DNS could be controlled and to also satisfy a curiosity if the malware was still active. The domain was purchased and then immediately I pointed the domain at a server I had in a data centre operated by a friend of mine.



Using ‘tcptrack’, I was able to see that there were a number of machines still looking for this domain. They were all attempting to connect to connect to my machine on port 2009. Now we can just use ‘nc’ to listen on that port to see what is being requested.


Quite the password for this IRC server it was once being controlled by.

I then compiled a simple IRCd and then watched as they all connected.


Immediately I had hundreds of machines ready to do my bidding if I so chose. I let it sit for a bit and at its peak, I had about 325 machines. All of them were identified with their OS, country, and then a random code. Here are some statistics on where the machines were located:

  • Argentina, 5.00%
  • Brazil, 0.45%
  • Chile, 5.91%
  • Colombia, 1.36%
  • Malta, 0.45%
  • Mexico, 73.18%
  • Peru, 2.73%
  • Spain, 14.55%
  • Venezuela, 1.36%

Once satisfied with the reconnaissance, I went and pointed the domain at an internal server and discovered the location of the machine and had it remediated as usual.

An abuse complaint did however come in during the time I was investigating the issue so while the domain had since fallen out of use, someone was still monitoring it. The domain has since been pointed to the ShadowServer guys for them to remediate any machines that are still remaining.

Sunday, 21 December 2014

Remote code execution on misconfigured systems using Werkzeug

One of the most popular WSGI utility frameworks for Python is Werkzeug. It simplifies the handling of HTTP connections within your Python application but also provides a powerful debugger that permits one to execute code from within the browser.

While the provided link warns those to not enable the debugger on anything production, it is often ignored or forgotten about and ends up being enabled in the first place. It is possible to search for systems on the Internet that have the debugger enabled and execute Python code remotely.

It should be noted that this affects both the Flask and Django frameworks mainly but could be used elsewhere.

Revealing and using the debugger

Getting the debugger to reveal itself is fairly simple: cause an exception. This can be achieved by writing some faulty code or by simply making it happen yourself such as in this code example using the Flask framework:
from flask import Flask

app = Flask(__name__)

@app.route('/')
def main():
    raise

app.run(debug=True)
All you need to do is execute the above as a Python script and the following should be outputted:
$ python flasktest.py
 * Running on http://127.0.0.1:5000/
 * Restarting with reloader...
Now view the page via the URL it provides and you'll have access to the debugger as follows:


And as you can see it is pretty straightforward too:
You can view the code by highlighting over the code on the right.

Python code can be executed as if you were running the interpreter locally.

Finding affected hosts

Finding hosts is trivial using a search engine such as Google or a service like Shodan.

At the time of this writing, using Google does not net any results but previously during some research on this matter it did. It appears that any services that are indexed are being taken down fairly quickly.

If you wanted to try a Google search for the future, this search may provide a result:
intitle:"Werkzeug Debugger" "You can execute arbitrary Python code in the stack frames"
However, Shodan makes it easier to find servers that specifically run Werkzeug.

Finding servers that error out is fairly simple.
Some fine-tuning is required to find hosts that can have the code executed but they are there.

It should be noted that the debugger can be activated even without executing the HTTP server internally. Documentation exists that allows one to enable the debugger via Apache if you so dare.

It goes without saying that you should not execute any code if you run across a machine that has the debug mode enabled.

Preventing your application from being vulnerable

If you're developing an application that makes use of Werkzeug, you should avoid hard-coding a debug mode into it.

My suggestion is to try something like this:
import sys
[...]
if __name__ == '__main__':
    debug = 'debug' in sys.argv
    app.run(debug=debug)
This should require you to add 'debug' to the command line arguments when running the code, allowing you to just leave it to local development.

Wednesday, 10 December 2014

The 'joke' behind the signed Sony malware

Last night, I tweeted out a series of tweets correcting the stories issued by Kaspersky and ArsTechnica regarding the origin of the signing of the malware that had infected Sony. As a result, it got picked up by a CSO Online sometime after I had gone to bed and in the morning I had a  bunch of people on Twitter asking me questions.

The origin of the story is that a researcher (who wishes to be referred to as "yosposbithc") in an IRC channel I am in had been going through the Sony data and came across some PFX files used for code signing. With luck, he had quickly determined that the password to the file was in fact the filename itself ("spe_csc").

Location:
\Cert2\USERS\AMcMillian\Sony\Projects\The Big Picture\Certificates\spe_csc.pfx


In discovering this, we were asked, "what should I sign" by him. I initially suggested just signing 'calc.exe' since that tends to be used for demonstrating any RCE vulnerabilities. However, it was then decided that using a source from Malwr that the actual attacking malware used on Sony would be used instead.

signature_is_ok
Screenshot from Kaspersky's recent article
It was uploaded to VirusTotal and then tweeted out by myself shortly after. The time between it being signed and then showing up on VirusTotal itself was something like 10 minutes. It has not been used in the wild, I doubt that the researcher executed it at all, and it in its signed form is not available for download.

Kaspersky has since updated their article with the following:

So far, we have not encountered the signed sample in the wild. We've only seen it submitted to online malware scanning services. However, the existence of this sample demonstrated that the private key was in the public domain. At that point we knew we had an extremely serious situation at hand, regardless of who was responsible for signing this malware.
Reports indicate the "researcher" reached out to the certificate authorities to get the certificate revoked after submitting the malware online. The certificate would have been revoked without the creation of new malware. There really was no need to create new malware to prove that the certificate hadn't been revoked yet.
What is said here is true. Having myself previously worked at an anti-virus vendor, I can safely say that Kaspersky more than likely got the sample from VirusTotal as that was the case for when I still worked in their industry.

https://i.imgur.com/j19qaVw.png
The certificate was revoked on December 7

However, Kaspersky erroneously reported that the certificate had yet to be revoked at the time of their writing. This was not the case as the researcher had reached out to DigiCert shortly afterwards and it was revoked on the weekend.

There is not much more to this story other than that. I do not have a copy of the certificate myself as I have chosen to not touch the Sony data. The unsigned malware itself is available from the Malwr link I previously supplied and copies of the signed malware are floating about now.

Tuesday, 25 March 2014

Namespro has seemingly poor password storage methods


Somehow I managed to lose the password to my Namespro.ca account, which I had setup at one point for managing a number of my domains. It was likely that my password manager had an incorrect entry at some point or some other silliness resulted in my inability to log in. Needless to say I needed to reset the password and so I tried…


Why am I limited to between 4 and 16 characters for my password? What logic dictated this? There are a multitude of reasons on a technical level for this sort of behaviour, so I decided to ask them to get clarification.
I noticed that you enforce a 4-16 character limitation on passwords. Could you please answer the following:
- Is this limit purely a limitation created by the forms?
- How are they being stored in your database? Is it in plaintext or some sort of cryptographic algorithm?
Very straightforward questions and something that does deserve some level of technical explanation–no? Wrong. Here’s what they sent back:
Although you have not specified, we believe you are referring to the password of your Namespro.ca account. To answer your questions:

1) The password requirement is validated by server-side algorithm.
2) Passwords are encrypted before being stored in our systems
We hope the above information is helpful to you. Please do not hesitate to contact us if you have any other questions. We will be glad to answer them for you.
“Server-side algorithm” and “passwords are encrypted” don’t tell me much. A “server-side algorithm” is what is providing the SSL connection between you and my server, but without you looking at the certificate that is fairly vague no? I decided to press a bit further:
Thanks for having gotten back to me. Could you please elaborate on this?

1) When you mean “server-side algorithm”, do you mean that the password length is limited by it? Can you elaborate on what this “algorithm” is? Is it what limits you from storing the passwords beyond 16 characters? Are there any starting characters that are not permissible?
2) What method of encryption do you use for storing the password? DES, 3DES, MD5, BCrypt, ROT13? Is it something else? Do you employ a per-user salt or a global salt?
These two questions are once again pretty straightforward–although throwing “ROT13″ into the mix might seem snarky. Why did your engineers decide that four to sixteen characters is an acceptable length and what do you use to ensure that the passwords are stored correctly? Sadly Namespro didn’t want to give up that information but instead tried to go this route:
Unfortunately, we cannot disclose the actual process on how we protect our data and passwords. However, we can say that the 16 characters limit was a decision by our engineers and all front end implementations are simply an extension of that decision. You can also use any letters, numbers and characters you wish and in any combinations. Please be assured in our 10+ years of operation, there has not been any security compromise on our client’s accounts. This may be one of the reasons why clients such as:
++++++++++
http://whois.cira.ca/public?domaine=rcmp.ca
++++++++++
use our services.
Let’s extract what we’ve learnt from Namespro based on the conversation so far:
  • Passwords are stored within the server using a “server-side algorithm” that “encrypts the passwords” but for whatever reason the developers of the back-end saw it fit to limit user to a password length of anywhere between four and sixteen characters.
  • Namespro believes that giving any details about itself and its storing of passwords could lead to a potential compromise even though the choice of algorithm provided if done correctly would unlikely lead to it and if in the event there is a compromise that the knowledge of the password storage mechanism probably wouldn’t really matter anyway.
  • That its impeccable record of not getting breached and having clients like the RCMP being used to endorse their services should be enough to calm my fears.
Here’s my opinion on what I think based on the conversation thus far:
  • Passwords are limited from 4-16 characters either due to a limitation in their database, the cryptographic storage method used, or some sort of silliness in their code; whatever that may be.
  • They’re afraid to admit that they have inadequate password storage and would rather tell me to leave than to address the issue at hand. They hide behind the statement that informing me of their storage method would lead to compromise, but lots of organisations have informed their users in the past.
  • Namespro believes that they have “police-grade security” thanks to clients like the RCMP being in their list.
After having discussed further with Namespro, I got the following:
Thank you for your comments. We appreciate them and have forwarded them to our management team for review. However, at this time, we do not believe there is any further information we can provide. We fully understand some user’s concern about security and our response is again that we have never had a security incident with our accounts. Our goal is indeed to continue to strengthen our security as we go along but the manner and time frame on how this is achieved is the sole responsibility of our management team and engineering team.
Not having an incident ever does not excuse poor password management. Having an account with another registrar, I decided to ask them what they do to store passwords. Their response? While not ideal, they told me that they were using SHA256 with a per-user salt and no real limits on password length. This is far better than what I am getting from Namespro.

So I tossed this response back:
Please let your management know that I have spoken with another registrar that I conduct business with and they were more than happy to let me know how they store their passwords. If you’re concerned about sharing this information with the public then it is apparent that you do not have these details stored securely.
And got this back:
We regret to hear about your point of view, although drawing such conclusion about our password security is premature in our opinion. Again, password policy is not 100% based on security alone, there are other operation consideration. If you require any assist with domain transfers, we will be more than glad to assist. Once again, we apologize it does not work out, and are prepared to serve you again in the future if you change your decision. Have a nice day.
Needless to say, Namespro is telling me that they don’t care. If you’re a customer with Namespro: leave.

Addendum:

It was pointed out to me that I didn’t differentiate between them hashing or encrypting passwords. This was on purpose as I assume that based on their responses they’re not hashing at all but using some sort of two-way method.

Friday, 14 March 2014

Tracking users via wireless networking at BSides Vancouver

BSides Vancouver 2014 has come and gone and it went off really well. I gave a presentation on Canary and had a good time overall. One thing I did do this year was keep track of the users who were sitting in the presentation room using Wi-Fi and Bluetooth.



"Scroll of Sheep" was created based on the idea borrowed from DEFCON's very own Wall of Sheep, but instead of harvesting passwords and the like from Wi-Fi networks, it scanned for enabled Wi-Fi and Bluetooth devices within one section of the conference.

It would listen in on 100 packets via Wi-Fi and do a sweep via Bluetooth every three seconds and keep track of it via a SQL database. All that was stored was the device MAC, a time stamp, and an SSID if found.

Reception of it was well-received and now I have some statistics and other data to share!

Hardware and software

Some fairly off the shelf hardware was used:


  • Laptop computer

  • LCD monitior

  • Alfa-based USB Wi-Fi adapter

  • Yagi antenna mounted on camera tripod



In addition to the above, a standard point-of-sale receipt printer was added and connected via parallel cable. Inside of the printer it had about 70 metres of receipt paper. Each day, a new roll was added to allow for proper measuring of how much paper was used--more on this later.


Even Bobby Tables showed up


The software that powered it was mostly through the use of Airmon-ng with Scapy providing the interface. You may wish to check out the source code of the software I wrote as it also incorporated a web-based display for statistics in addition to printing the data on to a receipt printer.

Statistics

Here are the requirements for how things were tracked:

  • New access points were added and then ignored for the rest of the day.

  • Probes from client devices were only counted as new if they had not shown up in the last five minutes.

  • Bluetooth devices fell into the same category.



It should be noted that not much in the way of Bluetooth data was acquired (we're talking less than a handful both days) so the data has since been discarded.





Most of the activity was really in the early part of the morning due to it being the start of the conference. As the days wore on, the number of new client devices continued to drop.



The above graph shows that while Apple devices were most popular, they were outnumbered overall. I was not keeping track of operating systems, but it was surprising to see Blackberry devices this high. With better OUI data, I am sure I could have gotten far better results.

Something that should be kept in mind is that while this antenna was aimed directly at the main conference hall, data from devices not belonging to conference goers was likely in the mix--attendance was no more than 200, but 330 devices were counted on average each day. Having said that, we did have command of the entirety of the hotel's conference space and it was likely that some people had more than one device. I'd wager that 80% of the data was likely the conference attendees.

Paper

As mentioned earlier, a receipt printer was used and each day it had available about 70 metres of paper. The idea behind the printer was borrowed from Chaos Computer Congress, where a receipt printer like the one I am using was used to print out tweets that discussed the conference.



While the "paper out" light was on, there was indeed paper inside. Nobody managed to get it to spit out control characters to make it cut the paper or go into a continuous spool--this was completely possible as I had not done any filtering via the interface. Bobby Tables made an appearance on here as well too.



My girlfriend was on hand on the second day and decided to figure out how much paper had been spat out. Her approach was to just outright measure it whereas mine was to figure it out by weighing what has been printed.

Her answer was that 25 metres had been printed on day 1, but did not measure for day 2 as it was still spooling.

However, weighing the paper proved to be problematic as while I do have a scale, it's meant to measure things in pounds and kilograms, and we're likely dealing with less than a pound here--a kitchen scale would work much better. But there was one way, determine how many lines were printed.

Here's what I figured out and what I already knew:


  • Day 1 had 143 access points, 6 Bluetooth devices, and 670 client entries.

  • Day 2 had 102 access points, 5 Bluetooth devices, and 711 client entries.

  • Two lines maximum for access points, three lines for clients and Bluetooth.

  • Five lines of space between each new entry.



What this means is that on day 1, 6,397 lines were spat out and on day 2, it was 6,442. At this point, I can measure the length of each line (4 mm) and then tell you that 25.59 metres of paper was used on the first day and then 25.77 on the second. Even if I had gone and kept a single roll, I would have not ran out. One interesting fact is that the fastest a garden snail has gone at is 0.0034 m/s, which means that the printer was spitting out paper at around a third faster than that.

I guess I should have ran with my girlfriend's answer all along as I had assumed more--something like 30 metres on each day.

Closing

Next year I plan to keep track of AP encryption and get the OUI data a bit more polished. It would be nice to know if those who are tethering at the conference are bothering to encrypt their links.

A little bit more about what else was found in the data set may be written later.