Sunday, 29 November 2015

Tassimo T-Disc Barcode Encoding

One of the things I happen to own is a Tassimo coffee machine. It's pretty good compared to a Keurig because it allows for the use of syrup and milk. I do have to admit that from an environmental standpoint, it's pretty awful however. I recommend that if you're using one that you look into recycling the pods, but in Canada it appears that TerraCycle has stated they're no longer accepting them for their programme.

A thing that I was curious about years back was the barcode system and how it worked. I was able to find this page that contained details, but it has since become removed from the Internet and is only available via the Internet Archive. Because I'd like to keep this information readily available for others to see and searchable, I've gone ahead and copied down the details written by the original author.

So going forward none of this is my own, original writing but has been mirrored here for future reference.


What sets the Tassimo apart from similar single-serve machines on the market is the encoding of the brewing parameters for beverages on the surface of the pod (T-DISC) using a barcode that has been encoded using the Interleave 2 of 5 symbology.

On this page, you will find information related to investigating the correlation between the barcodes on the T-DISCs and the operation parameters for the Tassimo.

Operation Parameters

There are five parameters that comprise a typical Tassimo beverage brewing cycle:

  1. Water Temperature
    • This parameter sets the temperature for the internal boiler prior to brewing.
  2. Cartridge Charge
    • This parameter controls how much/long for pre-soaking T-DISC contents prior to brewing.
  3. Beverage Volume
    • This parameter controls the amount of water dispensed for the beverage - depending on the type of beverage, material in the pod, etc. the actual dispensed volume will vary.
  4. Flow Rate
    • This parameter controls the flow of water through the T-DISC during brewing, measured as a percentage.
  5. Purge
    • This parameter controls the final phase of the brew cycle which is used to evacuate or flush the T-DISC. This may be short or long depending on the type of beverage.

Binary Coding

While not definitive, the Tassimo patent application suggests that the data encoded by the barcode can be broken down into 13 bits, which in turn directly control the operation parameters of the machine:

Water TempBitsDecimalParameter
10283C / 181F
11393C / 199F
Charge000fast charge w/ soak
011fast charge no soak
102slow charge w/ soak
113slow charge no soak
Purge000slow flow / short period
011slow flow / long period
102fast flow / short period
113fast flow / long period

Decoding Barcodes

Initially, the process for determining the symbology and thus encoding of the T-DISC programs was uncovered through a process of trial-and-error that began with using a hacked :CueCat barcode reader to scan the T-DISCs to determine the numbers behind them.

From this exercise, a list of six digit numbers was compiled and next used as input to a barcode generator to determine the symbology used for encoding.

By comparing generated barcodes with the corresponding T-DISC, it was discovered that Interleaved 2 of 5 symbology was being applied - a common standard.

Next, the codes were broken down into their binary equivalents to try and discern common patterns that may correspond to key parameters like volume of dispensed water.

Thursday, 26 November 2015

Comcast Breach by the Numbers

As was reported over the past few weeks, about 600,000 usernames and passwords for Comcast users were available for sale. I have come across the data since then and have decided to reveal some stats.

In the dump there were the following:
  • A CSV of e-mail addresses, customer names, and associated physical addresses (comcast_27k_emails_with_full_house_addresses.txt)
  • A CSV of usernames and passwords in plaintext (comcast_590K_users_with_plain_text_passwords.txt)
  • A SQL dump of a table containing account IDs, GUIDs, aforementioned usernames, account statuses, and passwords (comcast_vanity.sql)
Additionally, a text file containing the following:
hacked by orion, sold on Python Market 
software vuln allowed access to mail servers which contained user emails and plain text passwords lol, enjoy. Do not leak out this link or else i fucking nothing. 
Update Monday November 9,2015: Comast is full of shit.txt
Total usercount (with passwords):  590,298
comcast claims to have reset all affected accounts..and yet many of them still work just fine, LOL!
yup this was totally from phishing, comcast boxes were totally never breached!

I haven't put these into Canary yet but I have gone through the data for those who wish to know how affected people were. I also believe that based on the contents that something belonging to Comcast (or a third-party) was indeed breached contrary to their official statement.

For the record, I did not purchase the data.

The Numbers

I tweeted this a few days ago, but here are the raw numbers:
  • 590,298 usernames/e-mail addresses and passwords were included in this breach
    • 413,964 unique passwords were found within the list
    • 296,907 of those passwords appear in rockyou.txt
  • 27,262 e-mail addresses, individuals' names, and physical addresses were exposed
  • 889,627 records were listed in the SQL dump

What's in the SQL dump?

Interestingly, the SQL table has the following columns:

  • account_id
  • guid
  • vanityName
  • enabled
  • suspended
  • migration_status
  • migrated
  • migration_password
When you see that Comcast is denying that they suffered a breach and then the attacker claiming that they breached a mail server, you have to wonder what the truth is here when you see a SQL database including details like account IDs, something about migration (to another system maybe?), and the status of the account. There's allegations that this data may have came from a third-party, so perhaps there is some truth in all of this for Comcast, but what was the actual source?

I was curious how many actual customers were affected by this breach so I did two things: I looked for how many accounts were marked as "enabled" and then how many were marked as "suspended", plus a few extra things to see what was going on. 

Here's how it all broke down:

  • Of the 889,627 accounts listed in the dump, 851,093 accounts were marked as "enabled"
    • Only 7 of those accounts were marked as "suspended"
  • 889,555 of all accounts have been marked as "migrated"
  • The passwords in the password file matches the number of entries in this database where the passwords were not marked as null (590,298)
The numbers here makes it quite clear that Comcast or a third-party with access to the data suffered a breach.

Where are people affected the most?

In the 27,262 customer addresses and e-mails exposed, 5,994 unique ZIP codes were represented--there are about 43,000 across the whole United States. These were the top-ten ZIP codes that had customers affected:
  1. 80202 - Denver, CO (58 customers)
  2. 55303 - Anoka, MN (57 customers)
  3. 15601 - Greensburg, PA (54 customers)
  4. 37214 - Nashville, TN (52 customers)
  5. 17331 - Hanover, PA (47 customers)
  6. 26003 - Wheeling, NV (45 customers)
  7. 15301 and 46350 - Washington, PA and La Porte, IN (44 customers)
  8. 19464 and 21014 - Pottstown, PA and Bel Air, MD (42 customers)
  9. 77702 - Beaumont, TX (40 customers)
  10. 02703 and 17701 - Attleboro, MA and Williamsport, PA (37 customers)

Of those 27,262 customers, 3,256 of them had their passwords exposed in the password list--assuming that their e-mail addresses' local-parts can be correlated to the "vanityName" field.

I have created a map that will let you see who's affected. There are some weird quirks due to problems with ZIP codes not matching up with their respective cities, so keep that in mind.


As stated already, Comcast or a third-party was breached and this data was exposed. Comcast owes an explanation to its customers.

I'll be placing the e-mail addresses on Canary as soon as possible. 

Friday, 20 November 2015

Internet Identity and actually being effective with threat intelligence

A few weeks ago, I wrote about my problem with threat intelligence. It's sort of the new hotness in the cyber security sector as instead of actually trying to fix problems, we have new companies emerging to tell you that they cannot help you more than scream that the sky is falling.

Last week, I received a curious e-mail from a company based outside of Seattle called "Internet Identity" or "IID": 
Subject: Requesting assistance: Fraud placed on
Date: 2015-11-11 15:24
From: IID SIRT <>

Sir or Ma'am,

We are contacting you on behalf of our client Chase Bank to notify 
you that your website,, has been compromised and a phishing 
page has been hidden in one or more of its directories.

I work with an Internet security company based in Washington State 
called Internet Identity, and am contracted by our client to assist 
in mitigating the attacks targeting their customers.

The files in question can be found at the following location:

canary [.] pw/view/?item=c1aa76c1226a80bdf050e0d7d14f1ff7

Should you have any questions or concerns, please call our 24/7 
Security Team at the phone number listed below. Simply reference 
the case number and any one of my colleagues will be able to help.

Thank you very much for your time.

Best regards,

Security Incident Response Team
I responded to them with a short, one-sentence e-mail asking if they had bothered to read the "About" page on the website. Clearly the e-mail sent to me indicated that they were under the impression that I was somehow breached myself. They then went to send a clarification e-mail:
Subject: Stolen Credentials
Date: 2015-11-11 15:51
From: IID SIRT <>


We are working on behalf of Chase Bank in order to remove the stolen 
credentials at the following URL:


The credentials posted here have been fraudulently acquired and need 
to be removed as soon as possible.

Please take action to suspend this account or remove the offending 

Please let us know if you need any further information.  We greatly 
appreciate your prompt attention to this issue and request that you 
advise us regarding what actions you take.


Security Incident Response Team
To which I replied:
Subject: Re: Stolen Credentials
Date: 2015-11-11 15:57
From: Colin Keigher <>


You are contacting another threat intelligence service. Please read the 
"About" page (

> Canary is an open-sourced project created for members of the security 
> community to share and distribute information relating to data loss. Data 
> is sourced from a variety of sources through community members. The goal 
> is to allow for researchers and organisations to better understand and 
> react to data loss.
> What is collected for this website are documents from various 
> document-sharing websites, Internet forums, and social media that may or may 
> not contain data that is not intended for the general public but otherwise 
> has. The intention is to allow individuals, organisations, and researchers to 
> be able to identify where exposed data is being posted and what history it 
> may or may not have with other leaks. The idea is to ensure data integrity 
> and to dispel any ambiguity about information that is out there.

Please contact the affected individuals in the dump that was posted to change 
their passwords as that is what makes most sense--do you not agree?

This information was retrieved from Pastebin in September 2015 and was not 
"frauduently acquired" by us. We monitor several websites for information that 
has been posted.

And then left it at that. There was no response or anything from them. The solution for this company's client was simple: change the password. The cat is already out of the bag, right? How are you going to put that genie back in the bottle?

But nope. It appears that either IID is either run by completely inept individuals who don't get the concept of addressing actual threats or they're attempting to make themselves look like they're worth the amount of money they charge to their clients by going and harassing my hosting provider, telling them I am hosting "fraudulently acquired" material. They're not really addressing any sort of "threat" here by trying to scrub the Internet of anything: have they not heard of the "Streisand effect"?

Yes. The data was probably "fraudulently acquired" as someone probably breached some bankers' association website and then dumped the contents on Pastebin for all to see. My software picked up on it, put it up on Canary, and now it's there so we can track future breaches. For a company like IID, the concept of what I am doing should be pretty basic if they're going to make claims like this on their website:
Our Threat Intelligence team continuously validates and processes incoming data, adding classifications and attributes for context, and then pursuing organic intelligence that adds further value to the data. In collaboration with security researchers and experts around the world, our team can turn a whirlwind of incidental blips into a coherent, actionable assessment.

Whenever our investigators find a suspicious event, file or situation, they quickly validate and verify the symptom, identify and analyze malware and malicious campaigns, and conduct background reputation checks on any associated IP, domain and URL. The team can monitor Denial of Service attacks and provide intelligence to affected customer targets, or perform network forensics to identify compromised hosts throughout an organization using DNS log data.
Or maybe how they explain their acquisition of threat intelligence data through their service:
Security analysis depends on compiled and correlated emerging threat data to stay ahead, but investigating threat indicators has been a tedious manual process.

Dossier provides contextual information about a potential threat so you can make informed decisions about defensive actions. And it’s so fast and effective, you end up with lots more time to do your job.
So here's a question for IID: was it your organization that decided that a password posted on the Internet for everyone to see should be removed from wherever you find it to justify how much you charge your clients or was it your client that made the "informed decision" to then tell you to act as Internet police? Based on your Glassdoor reviews, I can safely assume the answer here.

Here's a pro-tip from someone who enjoys working with breach data and actually can provide "informed decisions" you can make based on them: think that the password has been exposed to the Internet for all to see? Change it and don't get upset at seeing it posted elsewhere; instead get pissed off at whoever lead to having your data exposed in the first place.

IID demonstrates the problem with threat intelligence: justifying charging your clients for your services. What good is a threat intelligence service like this company if all they're going to do is let you keep your passwords as is and then just go and police the data off of the Internet; it doesn't work that way and any service provider that tells you that they can scrub all instances of any specific data is outright lying.

For the hell of it, I decided to do something with the original data that they complained about.

In the sample, there were 6,147 accounts listed off. Of those accounts, none of the passwords repeated so we're off to a good start. How many of the passwords have existed in previous dumps? Well, if we use our good friend 'rockyou.txt', which contains about 14.3 million unique passwords from a database dump from half-a-decade back, we can determine that 1,484 passwords (24%) had appeared in previous dumps.

Of those 6,147 accounts, 52 of them belonged to IID's client, Chase Bank--or about 1% of the total. If I take the list of the Chase users and compare them to the passwords from the password list that were found in the dump, 24 of them had matches, meaning that almost half (46%) of their affected client's users have used passwords that have been found elsewhere.

This means that IID has completely idiotic policies for handling database breaches, leading them to be more of a threat to their clients than the data that is leaked themselves. They have no clue about breaches and are dealing with matters in a way that cannot scale at all.

As a result of the idiocy displayed by IID, I've gone about doing two things.

Firstly, the data has been reposted to Canary in a redacted form, where the passwords have been replaced with their MD5 equivalents and a notice has been placed at the top of the sample indicating what has happened (this is policy going forward). If they take issue with the e-mails being posted here, then IID is being outright malicious and is in my opinion looking to take out a potential competitor that does their work for free. IID is more than welcome to prove my opinion wrong here however.

Secondly, I am in the midst of migrating my host off of the hosting provider and am placing it elsewhere. I don't have time to waste dealing with inept companies that don't understand the data that they're working with. IID had spent time on my website reading the contents and yet still opted to go down this avenue.

IID is no longer welcomed to use Canary going forward. Should the company take exception to this, they're more than welcome to contact me.

Wednesday, 21 October 2015

Deobfuscating malware droppers written in VBScript

Once in a while I run across malware that drops itself via a macro embedded into a Microsoft Word DocX file, written in Visual Basic script. These payloads are fairly common and have been documented in a number of places. However, I noticed in one instance that the payload it was retrieving was encoded somehow with the macro doing the decoding.

If you're not sure what the document I am referring to looks like, here's a screenshot of what you should expect if you were to open it in Word or LibreOffice.

I've opted to not share the whole source code for the payload here but I am writing this as a primer for retrieving the data should you be interested in it. I've removed references to the keys and location of the payload but again this writeup should provide more than enough information.

It's pretty straightforward to decipher what the URL is so you can download the payload. It will look a lot like this when you do so:
IsDwQV = "httEeDxPbOZhstcWp://"
dlBSaKVPUZeUffK = Replace(IsDwQV, "EeDxPbOZhstcW", "")

vJPIYmKkzEidc = dlBSaKVPUZeUffK + "" + "file.da" + "t"
As we can see, the URL is really "" so all one has to do is retrieve it normally and have the payload. This isn't new to this type of attack, but what is different here is that you'll need to look for an additional line to decode the file. An example of what we're looking for is here:
PTIEIYzefrUBrv.Write auRPAIQxRBuNVNs(ZlOton(AsWLAJsjgp), "mal" + "wa" + "rek" + "ey")
Again, just as straightforward as earlier, we just need to combine the second argument in this function to form the key "malwarekey".

Now that we've gone and figured out the payload's URL and the key, we'll want to see how the payload is decoded. It goes through two processes: the first where reorders the contents of the file and the second where it performs a XOR on each byte.

The reordering function looks a lot like this (keep in mind, the variables and function names will change to avoid detection but the patterns will remain mostly the same):
Function auRPAIQxRBuNVNs(gZZoRIEiqkagc, CIKkGOaWM)
Dim vJPIYmKkzEidc
vJPIYmKkzEidc = ""
Dim yjiyoPGJqpm
yjiyoPGJqpm = 2 - 1
Dim RpKxIaBse
RpKxIaBse = 1
For RpKxIaBse = 1 To Len(gZZoRIEiqkagc)
PhnHyZVCyES = Mid(CIKkGOaWM, yjiyoPGJqpm, 1)
vJPIYmKkzEidc = vJPIYmKkzEidc & Chr(Asc(Mid(gZZoRIEiqkagc, RpKxIaBse, 1)) Xor Asc(PhnHyZVCyES))
yjiyoPGJqpm = yjiyoPGJqpm + 1
If Len(CIKkGOaWM) < yjiyoPGJqpm Then yjiyoPGJqpm = 1

End Function
The XOR function then will look like this:
Function ZlOton(ODkdfygTwl)
Dim XvZDYBA, ZazVWW, SyyWJefcxs, eauVLHixkVU, cQdAHb, WGHeGPbgR
Dim myjfHUNidfOgtQ
ZazVWW = (&H3EF + 2892 - &HF3A)
SyyWJefcxs = (&H3EF + 2892 - &HF3A)
myjfHUNidfOgtQ = LenB(ODkdfygTwl)
Do While XvZDYBA <= myjfHUNidfOgtQ
WGHeGPbgR = WGHeGPbgR & Chr(AscB(MidB(ODkdfygTwl, XvZDYBA, 1)))
SyyWJefcxs = SyyWJefcxs + 1
If SyyWJefcxs > 300 Then
cQdAHb = cQdAHb & WGHeGPbgR
WGHeGPbgR = ""
SyyWJefcxs = (&H3EF + 2892 - &HF3A)
ZazVWW = ZazVWW + 1
If ZazVWW > 40 * (&H20 + 1142 - &H491) Then
eauVLHixkVU = eauVLHixkVU & cQdAHb
cQdAHb = ""
ZazVWW = 1
End If
End If
ZlOton = eauVLHixkVU & cQdAHb & WGHeGPbgR
End Function
The reorder function is easy to clean up, so I've gone ahead and written it like so:
Function reorder(filedata)
Dim var1, var2, var3, var4, var5, var6
var1 = 1
var2 = 1
var3 = 1
Do While var1 <= LenB(filedata)
var6 = var6 & Chr(AscB(MidB(filedata, var1, 1)))
var1 = var1 + 1
var3 = var3 + 1
If var3 > 300 Then
var5 = var5 & var6
var6 = ""
var3 = 1
var2 = var2 + 1
If var2 > 200 Then
var4 = var4 & var5
var5 = ""
var2 = 1
End If
End If
reorder = var4 & var5 & var6
End Function
Once we've cleaned this all up we can now determine that the function does absolutely nothing and is there to really obfuscate it further. The data that goes through this function comes out as the same, so it's really just a time-waster. However, the data is still encoded so I did go ahead and clean up the second function as so:
Function decodexor(filedata, filekey)
Dim var1
var1 = ""
Dim var2
var2 = 2 - 1
Dim var3
var3 = 1
For var3 = 1 To Len(filedata)
var4 = Mid(filekey, var2, 1)
var1 = var1 & Chr(Asc(Mid(filedata, var3, 1)) Xor Asc(var4))
var2 = var2 + 1
If Len(filekey) < var2 Then var2 = 1

decodexor = var1
End Function
Okay. So this code does in fact do something and now tells us that it's a straightforward XOR of the data. We can now just rewrite this script into Python line to line.

I've made it available via this Github Gist and per below:
from sys import argv

filename = argv[1]
malwarekey = argv[2]

def dexor(filedata, filekey):
    var1 = ''
    var2 = 0
    var4 = ''
    for x in xrange(0, len(filedata)):
        var4 = filekey[var2]
        var1 = var1 + chr(ord(filedata[x]) ^ ord(var4))
        var2 += 1
        if var2 >= len(filekey):
            var2 = 0
    return var1

if __name__ == '__main__':
    data = open(filename, 'rb').read()
    print dexor(filedata=data, filekey=malwarekey)
You'll want to ignore the fact that this Python function is really a terrible mirror copy of the original, but works one-to-one like the original VBScript; there are of course better ways to write this.

Once happy, we can run it like so:
$ python file.dat malwarekey > file.exe
$ file file.exe 
file.exe: PE32 executable (GUI) Intel 80386, for MS Windows
Now we have the file decoded and can execute it within whatever sandbox we'd like!

Wednesday, 7 October 2015

An open response to Veiltower and Edsard Ravelli's Kickstarter update

An update was posted on the Veiltower Kickstarter earlier today. This was in response to the furor expressed by myself and many others on Twitter since yesterday morning. As a result of this response and as a follow up to my previous entry, I've opted to opine on the response.
Dear Backers,
Edsard here, developer of Veiltower. Our project has now been active on Kickstarter for over 24 hours. To say that it has been overwhelming is a major understatement.
On the one hand we’ve been receiving a lot of praise - particularly from friends, colleagues and business partners who know us - and on the other hand there has been criticism directed at our project from a few people in the information security community. 
The criticism was primarily directed at one thing; the ‘100% secure’ statement on our Kickstarter page. Information security officers will always tell you that nothing can be infinitely 100% secure. And that is true. But frankly this is, in my honest opinion, a theoretical debate. For instance ‘PGP’-encrypting technology for e-mail is great, but 99% of people on the planet don’t use it. Why? 

This isn't amateur hour: the fact that you tried to enter the cyber security space with what appears to be inadequate knowledge and research should be enough to warrant scorn and ridicule over the use of the term "100% secure".

Trying to also pass off praise from friends, colleagues, and business partners in face of this valid criticism is akin to a child receiving praise from their parent after having achieved a failing grade in school. The opinion of the parent is not going to change the outcome of the child's inability to perform.

The reason why information security professionals who are adept at their jobs frown upon "100% secure" statements is that it is impossible to have such a thing. If your device was even remotely capable of providing this, you wouldn't be selling it at $159 but instead for much, much more. By using that statement, you've put yourself in a league of many other failures who've gone and made such a remark and then later found to be far from secure.

The problem with information security isn't a device or application problem: it's a human one. The human problem--or as I like to call it, the "Layer 8 Problem"--is the primary culprit behind breaches, malware infections, and scams. With infections and scams, users tend to fail to keep their machines up to date or do not take a critical look at what they're being presented with. You fail to understand this but have no problem going about stating that a simple VPN and "secure" access point is going to solve everything.

I am ignoring your PGP question because if you truly understood the problem you're facing you would have not asked that.
If you want to secure yourself as a tech-savvy person you would setup a solution in your home with a strong firewall, strong Wi-Fi encryption, and add into the mix a VPN both on your system at home as on all of your devices. You will configure and maintain them daily, spend the effort and remain vigilant at all the time. Simple. But most of you, and the majority of internet users, neither have the time or the experience to set this up, let alone maintain it. 
And that’s what the Veiltower concept is all about. It’s about combining existing and proven methods in a way that’s easy for ‘Average Joe’. The real threat to our security – as stands today – is the complexity of use and the lack of usability. We don’t use ‘PGP’ because it’s perceived as complex. 
The "real threat to our security" is not just the complexity of it or that humans make mistakes, it is also the fact that people like you try and sell half-baked solutions. I come across many, many products on a constant basis in my line of work where the vendors promise that it will do this with minimal cost on resources. For every one good security product out there, there are umpteen that are complete garbage and are backed by individuals like yourself. I rarely if ever endorse a product but I have no problem calling one "garbage" when I see it--and yours comes under that category.

When you go on Kickstarter claiming "100% secure" then go on Twitter and claim that you're just stating this for the common layperson, you're being deceitful and demeaning. It doesn't matter if you're talking to an information security professional or a common user: you tell the truth. Making security easier for users is something that all of us should try and do, but we do it in a way that doesn't require us to talk down to them--like you are--and also doesn't involve us manipulating them by making outright lies--such as claiming "100% secure".

Also, while I won't explain the problem with PGP in this response, I will explain the problem with your example. PGP is not something that you'd use to secure a network or computer but instead it's something to secure data. PGP won't stop malware, won't stop data leaks on networks, and won't prevent the human problem. This is a really an inadequate example on your part and I am not sure why you'd want to use this other than you have no clue which is really what I think is going on here.
And that is what I have focused on for the past 12 years; taking something very complex and making it easy to use. For example in 2001 at KPN (biggest Dutch carrier) I created a simple way to connect via ‘GPRS’ – because they understood that without usability nobody would use their service. I introduced automatic carrier detection and Wi-Fi (including automatic authentication to various hotspot providers) into the Vodafone Connection Manager worldwide in 2005 and 2006, although it seemed like it couldn’t be done because Wi-Fi was a ‘competing technology’ to their mobile data offering. In 2009 I created a solution for Best-Buy that would do both GSM and CDMA (2 competing technologies used by AT&T and Verizon) and switch a user from one network to the other, based on the best coverage for that user at that location - without the consumer having to do anything. 
Veil Systems is not based around a small group. It’s about a collection of idealistic people from the US, UK, Ukraine, Argentina, The Netherlands, Switzerland, Germany and Russia that came together – all bringing their own expertise – to create Veiltower. Our goal: help stop cyber-crime and protect the people that need protecting. 
Great. I am glad that you have this team and experience behind you: why are you just pointing out yourself, a designer, and a logistics person in the Kickstarter instead of you know maybe people who are behind the development of this project? You claim to have people scattered all over the Americas and Europe yet only focus on yourself and two people from the Detroit area. When you cite these countries, are they the actors in your videos or are they actually the main people behind the project?
We received comments about the lack of technical specs on our Kickstarter page. We did this deliberately. In our experience most of you don’t care about the various technical ‘flavours’ which could have been used. EAP-TLS vs. EAP-TTLS vs. EAP-FAST or 256-bit symmetric key vs. 2048-bit asymmetric key or Broadcom vs. Intel chipsets or why 256Mb is enough instead of 512Mb or Debian vs. OpenBSD vs. openSUSE. Every one of them have pro’s and con’s. That creates an infinite debate without end. In the end; it’s a ‘flavour’. You – the people we have built Veiltower for - just want it to work. You just want it to protect you. We knew, well in advance, that with adding a lot of tech specs we would scare you off or run the risk of our story would end up in a technical debate. And that is not what this should be about. 
You're essentially telling everyone that you'd rather create a blackbox rather than give any level of specifications on the product? This makes no sense considering even other Kickstarters like your own have referenced such things. Also, calling encryption symmetries as "flavours" is woefully ignorant and just demonstrates a lack of technical depth that you have.
Is Veiltower is finished product that has undergone every possible certification and validation process? No! It’s a prototype that we have developed, tested and that works. Can it be improved? Always! And that’s exactly why we are on Kickstarter. The funding will allow us, as part of our 6 month process, to do the types of improvements, certification and validation tests that the information security community – rightfully – demands from a finished product.  
Whoa. Stop the fuck right there.

So what you're telling us is that Veiltower has not gone under every possible certification and validation process, but you had the audacity to claim that it is "100% secure"? What sort of validation tests do you plan to take on this? What sort of certification? Can you elaborate on how you tested the device?
Note: If we don’t achieve our funding goal. Nobody pays anything. And if we achieve our funding goal and we don’t deliver we also refund your money. We have stated this on our Kickstarter page very clearly. 
This opens up a question for me: how are you going to continue to guarantee support for the product after raising all the money? The reason why I ask this is that in 2013, your prior company, Diginext claimed bankruptcy, leaving the organization owing almost half-a-million Euro.

If your product is as good as you claim it to be, you would not be going to Kickstarter for getting it launched because you'd have investors crawling all over you for what would be considered the Holy Grail of Cyber Security. Your business plan to use Kickstarter and your earlier bankruptcy does not seem to add up in my books as something that will work long-term for users.
Let’s do this!
Edsard Ravelli
Let's say we don't do this and instead end the Kickstarter. You're making yourself look like a fool and you're tarnishing the names of two other individuals who do not deserve to be part of your failure.

Tuesday, 6 October 2015

Veiltower: a misleading plastic jungle of deception

Once again we have another Kickstarter that claims that it is 100% secure, un-breachable, and uses unheard of cryptography. Introducing "VeilTower", a plastic jungle of deception.

As indicated in my opening, I've dealt with this sort of claim before where erroneous claims about the product's capabilities were made in a Kickstarter. In this case, we're being told of the following capabilities in the device using terms like "military-grade" which tend to set off alarms:
Some of the most security conscious organizations in the world have been using what’s called 802.1x with great success. That’s what we’re using. The encryption currently in use for typical consumers is 256 bit encryption. We’re utilizing 2048 bit encryption. We wanted to give consumers a product with military-grade technology.
Veiltower also makes your digital presence anonymous by masking your traffic and connected devices with it's state of the art embedded VPN (Virtual Private Network) solution.
It goes on further in an update that was posted after they were confronted online to explain its "100% secure" statement:
Some have questioned whether its not too bold of a statement to claim Veiltower provides 100% security. And that is a very fair question.
The simple reality is that almost anything can be cracked/hacked if enough effort is put in and over the years various standards (remember the heartbleed bug?) contained, in hindsight, vulnerabilities.
So to our knowledge, the encryption we use in Veiltower is secure! That's until one day we, and many other Access Point providers that employ the same encryption, are proven wrong.
For the techs:
VPN: Strong Swan IKEv2
This of course after this tweet was made at me:

Needless to say it started quite the Twitter conversation so I am going to condense everything I know about them and additionally opine on the matter.

To start off here, no product no matter its claims can go and say that what they do and or provide is 100% secure and is immune to breaches. Anyone who makes such a claim is either being intentionally deceptive or has zero clue about what they're talking about. In this case, I think that's more of the latter as based on the background of the individual leading this project, as he does not appear to have ever worked on anything cyber security-related.

Veiltower (also known as Veil Systems) has a bit of a history and this is not their first Kickstarter either. It has since been removed but did manage to create a PNG mirror of the campaign draft which was penned around November 2014. They did tweet aggressively leading up to the date they expected to launch everything but for some unspecified reason, Kickstarter did not accept the submission so they promised to regroup and launch again later in the year.

However, after the last tweet, they made no quip about the Kickstarter campaign and just proceeded to share videos that they had already made. Additionally, the product was slightly different than what we are seeing now as they were also promising NAS functionality and an IP camera in addition to the "security" features we're seeing today.

Physically the products are similar except that there is a glowing, device shaped like a bowling pin that would have had the IP camera at the top. The campaign however appears to provide more details on the inner guts the device which is something I found lacking in the current campaign.

They're also providing the specifications in this old campaign.
Which again is sorely missing from the campaign.

However, something didn't add up: how is the PCB larger than the above disc in the guts image? If we look at a photo of the rear of the unit, you'll notice that the device doesn't even have ports that match the board.
This sort of reminds me of the Sever thing because it was revealed to me in conversation with some people close to the project that the board didn't match the case itself. What's going on here? Well without details on the specs of the unit in the current campaign, I guess we'll never know.

One thing to add: I call this a "misleading plastic jungle of deception" for good reason: they make the following claim about the antenna design:

A friend of mine is an avid ham radio operator and he informed me that the antenna slant wouldn't be enough to incur a polarization shift, meaning that the benefit from this design would be non-existent.

In any event, based on the hardware details from the previous Kickstarter and the lack of details in the current, it doesn't really bode well for this device at least from a physical standpoint. Any claims about its abilities to improve your overall Internet experience will be exaggerated at best.

Perhaps it's worth learning a bit about who's behind it: really there is one but it seems like there is quite a bit of discord going on behind the scenes as evident in these tweets.

I am guessing that after the exchange had started earlier (the crypto one from earlier was by this "social media guru"), Edsard Ravelli, the founder or leader behind this project decided to get involved and effectively sack the person behind the Twitter account--it should be assumed that the 802.1x encryption remark was made by the removed individual. I think that it is a bit fair to talk about the person behind this project.

Edsard hails from Amsterdam and appears to have been involved with the project from the start. He has claimed via his LinkedIn to once have been CEO and Founder of a company called DigiNext, but left in Autumn 2014, a year and a half after founding Veil Systems--I was not able to procure details on what happened with DigiNext but I can safely tell you that their website has a lot of broken links. Additionally he also has a software patent to his name, depicting some sort of update mechanism that reeks of similarity to every other software updater out there.

Veiltower mentions two other employees in the Kickstarter: Eric Stebel and Kris Caryl. Eric is cited as being the "Lead Designer" for the project, but judging based on his website, he's likely involved in the creation of the physical case of the device and not the electronics itself--however I will admit that Eric has done some cool stuff. I was not able to get much in the way on Kris other than her being cited as a Veiltower's logistics person.

Noticed something peculiar? Not a single person with an information security, software development, or hardware design background is cited. And here they are making claims about having a product that is 100% secure.

Of course, Edsard was okay in citing that it was okay to claim this because he's trying to lay it out to the laymen:

Edsard's excuse here is that it's acceptable to lie in the Kickstarter because he's trying to "appeal to consumers who [are] technology illiterate". By that logic, Volkswagen should be off the hook because consumers wouldn't notice the difference between the government-mandated emissions testing and "real world situations".

He continues to say that he had details posted on Facebook weeks before with over 5,000 followers where nobody made a quip about the claims. This is completely idiotic to claim and I am not even going to entertain the idea of writing here about why.

Going back to employees, Veiltower has gone out of their way to hire freelancers using Elance. Since April 2014, they have spent $38,002 USD across 29 different freelancing job requests--or about $1,300 on average per request. In contrast to their $250,000 goal on Kickstarter, the money spent on Elance would account for 15% of what they need to raise. How much is Edsard paying himself, Eric, and Kris? At a minimum, if these two have worked a year for Veil Systems at a wage of $8.12/hour, they'd each account for $16,952 ignoring things like sick days or other labour aspects. Times two, that's 14% of the campaign costs, meaning that around 30% is just for labour--this is a huge assumption too.

It should also be noted that none of the freelance requests were for anything technical and appeared to be solely marketing-related.

There's also no indication that there are other employees with Veil Systems as the name does not link to any other employees on LinkedIn other than Edsard himself.

One of the rewards is a white Veiltower for 1,999 people at a cost of $159. To meet that goal of $250,000, they need to get over three-quarters of that amount in order to cross that threshold required for a Kickstarter payout. But makes me wonder: does $250,000 cover all the salaries and development costs incurred?

If this was a product that was worth funding, a Kickstarter campaign would have not been ever needed. I tend to believe that the vast majority of campaigns out there are for ideas that are not marketable at all and just pander to a niche market. There are exceptions to this rule but it's a very short list of them.

Edsard has claimed that tomorrow he'll have some answers so we shall wait and see!

Friday, 2 October 2015

How Patreon made themselves a hole

As you might have heard, Patreon was breached and had its database and code dumped on the Internet. Canary has a copy of all e-mails and they are now all searchable.

I wrote this elsewhere, but this is how Patreon created a problem for themselves.

It's pretty easy to enable debug within Werkzeug but it isn't enabled by default. It's also not by default listening on "" but rather instead by default "".

Here's exactly what they did in the code (this is straight from the dump):
    web_app.debug = patreon.config.debug'', port=args.port, use_reloader=False)
Then in the patreon.config.debug string, it had a true statement:
debug = True
Whoever enabled this server wouldn't have fed arguments to enable it as it was hard-coded into the application. All someone had to do was just type "python" and the server would be ready to go with debug-mode enabled.

Detectify Labs wrote a blog entry and linked to a previous one of mine. Don't enable debug on Internet-facing servers and if you can help it don't enable it to listen on "" either.