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.

Introduction


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
000cold
011warm
10283C / 181F
11393C / 199F
Charge000fast charge w/ soak
011fast charge no soak
102slow charge w/ soak
113slow charge no soak
Volume0000050ml
0001160ml
0010270ml
0011380ml
0100490ml
01015100ml
01106110ml
01117130ml
10008150ml
10019170ml
101010190ml
101111210ml
110012230ml
110113250ml
111014275ml
111115300ml
Flow000030%
001140%
010250%
011360%
100470%
101580%
110690%
1117100%
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 will....do 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.

Closing


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 canary.pw
Date: 2015-11-11 15:24
From: IID SIRT <alert@internetidentity.com>
To: support@canary.pw

Sir or Ma'am,

We are contacting you on behalf of our client Chase Bank to notify 
you that your website, canary.pw, 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 <alert@internetidentity.com>
To: support@canary.pw

Team,

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

https://canary.pw/view/?item=c1aa76c1226a80bdf050e0d7d14f1ff7

[...]

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 
webpage.

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.

Regards,

Security Incident Response Team
To which I replied:
Subject: Re: Stolen Credentials
Date: 2015-11-11 15:57
From: Colin Keigher <colin@keigher.ca>
To: IID SIRT <alert@internetidentity.com>

Hello,

You are contacting another threat intelligence service. Please read the 
"About" page (https://canary.pw/about/):

> 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.

Thanks,
Colin
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.