Hacker News new | past | comments | ask | show | jobs | submit login
900 social insurance numbers stolen from Revenue Canada via Heartbleed (cbc.ca)
119 points by rpledge on April 14, 2014 | hide | past | favorite | 56 comments



Oops, I submitted a duplicate of this. (Upvoted yours)

Vulnerability was disclosed on Monday, April 7th. CRA website was shutdown on Wednesday, April 9th. Didn't take long for the baddies to take PoCs and point them at vulnerable sites.

Any other high-value sites that took more than a day to patch should take this as a warning.


I wonder if the data was stolen after or before the vulnerability was disclosed.

On the other side of it, I think it's really great that they've been able to determine exactly what was stolen from this so that they can attempt to repair any damages.


For those who don't know, SIN = social insurance number. Similar to US SSN.


Or the UK NIN / National Insurance Number.


I was about to make a call to Jesus, and see how this could happen.


Considering the significance of the vulnerability, the only thing I can say is the government is extremely lucky that the number is only 900. For Canadians, SIN numbers are about as critical as it gets.


tl;dr: "We are currently going through the painstaking process of analyzing other fragments of data, some that may relate to businesses, that were also removed." The agency says those affected will be contacted via registered letters, and that any attempts to contact a taxpayer via email or telephone are fraudulent.


Is this the only reported case of malicious use of Heartbleed so far? (Besides US government agencies allegedly)

If so, is it safe to say that this crisis was dealt with rather well? Or is it just too early to know how many sites were actually attacked?


It seems that a typical website doesn't have the capability to know if the exploit was used against them, unless they are logging and able to analyze all IP communications to and from their servers.


Wonderful timing that this vulnerability popped up smack in the middle of tax time, eh?


Presumably the numbers were stolen along with associated identity information. The numbers can be easily guessed; they are created with a simple algorithm.


How would they know this? Presumably they would have to log the entirety of IP communications with their services.


The CRA is the most competent organization in all of Canada, public or private. They probably log every packet.

Worst case scenario they are looking into streams of suspicious behavior, like Russian IPs attempting to validate the SINs somewhere else, like at a bank.


Agreed. I had the pleasure of calling CRA last month to sort out a problem. I spent an afternoon trying to piece together all these letters, payments, refunds, etc, and what exactly went wrong.

Anyway, I call, and it was the closest thing to magic I've ever seen. I give reception my SIN, and ask for the woman that signed the letter I received. I'm on hold for only 10 or 20 seconds, the woman answers, and greets me with my name. I didn't say more than a couple of sentences explaining the issue, and she says she'll check her computer, taps a button and poof she knows everything. Literally a few more seconds, and everything is sorted, and a cheque is being mailed.

I was almost speechless, I was expecting a 30 minute call between departments, explaining numbers, CRA scratching their heads since this was taking place across multiple provinces, and then me having to physically mail in a variety of personal information. Instead, it was a 1 or 2 minute call with an incredibly friendly woman, and she was so organized, it's like she spent the day preparing for me to call in advance. And, to reiterate, this was the woman that signed the original letter I received, not someone from support or customer service.

Now, the CRA website is a nightmare, but talking to them on the phone was the most impressive service I've ever encountered.


Why do you say that the CRA is the most competent organization in all of Canada? Not doubting that it could be or anything I was more wondering on what basis you made that claim.


I have a pretty complex tax life, I know many accountants and tax lawyers, my uncle was an Auditor for the Auditor General's office, my mom used to work for the CRA, I've spoken to them multiple times.

Every single interaction with them and every single person I know that has to deal with them has been nothing but mindblowingly professional. Even on the phone, they are exceptionally good at getting to the point IMMEDIATELY but without the normal "this isn't the right department" BS that every other Canadian government agency has.

It's hard to even think of a number two. The Supreme Court maybe? Elections Canada? Ellis Don?


A few years ago the CRA messed up a tax return of mine and credited my payments to the next year. I got a letter from them saying your tax bill of $11k has not been paid, please pay it, and here are some interest payments due, also you have $11k in credit for next year.

So I called them up, waited on hold for 5 minutes. I spoke with a CRA rep who said "Yup, we screwed up. Fixed". And it was fixed. Total time to fix an $11K screw up? 15 minutes. Try that with any other organization.


They are at least more competent than this department who lost an unencrypted drive with 583,000 SIN#'ers http://o.canada.com/news/national/federal-government-loses-h...


General question: the leaked data in the heartbeat packets is encrypted, correct? If the service doesn't use perfect forward secrecy they would definitely be able to decrypt those packets to see what was leaked. What if they did use PFS?


Depending on how the exploit is written it can be encrypted or unencrypted. If the heartbeat is sent before the TLS handshake is finished, then the memory contents will be sent in the clear. If it is sent after the handshake is finished (meaning all crypto stuff has been agreed on by both sides) then the data will be encrypted. This also makes Heartbleed very hard to detect on the wire in general.


That is a really good question! I would only be guessing at whether or not they have PFS or not. On the one hand, it leaves the past vulnerable in case a breach happened, but on the other it makes diagnosing what much harder in cases like this.


Actually now I'm not sure if heartbeats are encrypted:

"It is irrelevant whether your system can even support some of the cipher suites in the list, because the Heartbeat request that triggers the vulnerability is sent before any encryption takes place."

http://www.hut3.net/blog/cns---networks-security/2014/04/14/...


Interesting. So this leads me to believe that they do record every packet.


Heartbleed doesn't just leak keys. It leaks random bits of memory, which can contain anything - private keys, encrypted data, unencrypted data, whatever happens to pop out. Problem is you can repeat the attack very quickly until the data you want - say, unencrypted SINs - comes out.


I know, and I'm not sure how this is relevant to my question.

I was specifically wondering if a) the heartbeat messages which leak data (keys or whatever) are encrypted or not, and b) if they are, and PFS was used, is it even possible for someone to audit a full packet capture for heartbeat attacks.


Easy: check the access logs for all those people who logged in in a given timeframe and assume these are pwnd.


That would be substantially higher than 900.


They were likely doing full packet capture and in my experience it's not as rare or difficult are you might think. At my place of employment we're doing it on much more mundane and less sensitive services with up to 4 weeks of buffer in some places.

Even at a previous job back in the late 90's we were doing full pcap of our gov't department's T1 to the internet.

Products from companies like Netscout and VSS make this pretty straightforward.


The rareness assumption comes about given that the general response to the exploit is a complete blindness to the possibility that it was exploited before it gained public awareness: There seems to be a complete lack of ability by almost all players to "go back in time" and detect exploits.

I imagine a government agency, particularly dealing with revenue, might be a primary user of such a tool, though.


Most enterprise security tools could pick this up the night it became a CVE, or IBM QRadar could.... http://securityintelligence.com/heartbleed-vulnerability-sec...


I have had friends who work at the CRA. Apparently they are pretty good at monitoring activity.

For instance, one guy looked up the information attached to his SIN. Something like an hour later RCMP showed up, and escorted the fellow out of the building.


If they were that good they would have patched heartbleed a lot sooner.


Actually they did close the web services quite early. It is likely they are not the only ones with a similar problem, only they did notice the bug was being exploited and did act and communicate on it.

And you don't really expect them to blindly patch things right away do you?


You'd imagine that this is probably a place that you'd want to track all communications.


I'm going to assume they calculated this by simply counting the amounts of returns filed/logins done during the time the exploit was announced to being patched and wrote them off as compromised.

Maybe the Canadian government should walk down to the CSEC offices and ask them hey can you guys stop conspiring with the rest of the 5 Eyes Alliance to sabotage IETF standards


How can you steal a number?

Here's a number: 147334572. Have I stolen it?

This is yet another alarming signal that the whole idea that your SSN/SIN or credit card number is somehow secret and can be used for authentication is flawed. We need to work on fixing this. At the very least, we should stop talking about "stolen numbers". And even if the breach in question resulted in attackers gaining access to names + numbers (unclear from the article), it should not cause any serious consequences.


How can you steal a name?

Here's a name: jwr. Have I stolen it?

This is yet another alarming signal that the whole idea that your colloquial identifying information (name, phone, SSN/SIN, credit card number) is somehow a natural resource that anyone can use as they like. We need to work on fixing this. At the very least, we should stop pretending that identifiers are just tags that anyone can use without consequence. And even if the breach in question resulted in no harm done (those associated with the identifiers suffer no direct liabilities), it should not be treated lightly.

Possession of particular identifiers cannot be brushed off as "it's just a number" et al. You picked 14334572 precisely because it is not meaningful to anyone; short of such particular & peculiar use, we don't pick and retain numbers (or other identifiers) for no good reason. Out of a given range, the odds of picking 14334572 is very very small...if it happens to have a particular social meaning, and you possess it along with other information which likewise has an odd lack of meaninglessness, then you have malicious intent constituting "stolen numbers".

Don't pretend information is meaningless. We're not dealing with the Library Of Babel here.


I think you (and some others who are downvoting my comment) are missing the point.

You having a 'jwr' string does not enable you to do much — you can't use it to gain access to anything, no one will ask you for this string to authenticate you, you can't use it to pay for services. So if you "stole" it (or produced it out of thin air), it would not be a problem.

Now, I picked 14334572 specifically because it looks like a social security number (and might, for all I know, actually correspond to one). The point here was that you can't 'possess' a number, and you can't 'steal' one. You can steal complete personal information (that includes the number), but that is not what the original article was about.

My main point was that the real problem is with the whole idea of social security numbers (and credit card numbers) being both public identifiers (which is fine) and authentication tokens (which is not). If they were just public identifiers, then "stealing" a list of such numbers would not be a problem for anyone. It is the embedded trust we place in those numbers that causes us problems. SSNs are not secret key material, and treating them as such causes all kinds of issues.

As a side note: looking at the downvotes, I am increasingly worried about knee-jerk reactions here. I am finding that unless I craft my comment carefully and surround it with disclaimers, it will get misread. This is worrying, because it leads to watered-down and needlessly verbose discourse, words playing the role of guards against all the detail-pickers out there.


This is a more sensible expression of the concern. Your initial post was easily confused with a common ill-advised perspective.

I might not be able to do much with "jwr", but I could build an entire profitable identity around your SSN.

Your real concern is that identifiers and authentication must be separate and treated as such, while in practice one number/string is used for both purposes - hence the concern of "stealing numbers", as having the identifier means having the authentication. Insofar as there may be a separate authenticating token, all too often it is so weak that the identifier is used as part of the authentication; having the identifier may be enough for access, or enough that deducing the remaining authentication token may be fairly trivial (say, a 4-digit PIN); this being tax day in the USA, we're quite aware that many tax returns will be fraudulent, requesting large refunds based on mere possession of a SSN identifier and a smattering of other public data. We should be using real cryptographic private keys of substantial length for authentication, leaving the public identifier public so that having one (or a slew) gets one nowhere without the hard-to-obtain authentication tokens.

As for the downvotes and the need to craft comments carefully: yes, the need for careful wording is the norm. We're trying to cram a lot of information and opinion into a very small space, which will be read very quickly by a great many people of wildly varying perspectives interpreting the post, making it very easy to misinterpret intent (doesn't help that there are a lot of dumb & ill-advised posts, setting expectations quite low). The greatest problem is refining short easily-read posts to withstand accusations which demand encyclopedic thoroughness. One of my motivations for prolific posting around the 'net is precisely to exercise & refine my ability to post views in a concise & persuasive manner (and if that gets bizarrely construed as "he must have multiple accounts, know a lot of people, and persuades others to downvote opposing views" then I must be getting somewhere with that ability).


Actually, ctdonath is pretty well known for using multiple accounts and getting friends to downvote people who disagree with his posts (and to upvote his own). I'd advise against replying to him, as he will try to get you hellbanned.


You funny. I've only one account, know nobody on HN, and don't know squat about hellbanning except that it exists. I'm quite amused that anyone would impute such influence & power to me, even as a joke.


Ironically the person behind the account that made those accusations is certainly guilty of at least some of the things he accused you of. Probably a nice example of some good projection. (That account was created just for that post, so at the very least the person behind it is creating multiple accounts.)


> How can you steal a number?

The same way someone might "steal" your password. All data can be encoded as a number.

> the whole idea that your SSN/SIN or credit card number is somehow secret and can be used for authentication is flawed.

I don't disagree, but "how can you steal a number?" isn't a valid argument for your assertion.


I agree that the short and commonly used numbers that are often considered to be proof of ID are no longer suitable. When a computer can easily guess every possible combination of numbers in a set in seconds, it's not really sensible to use it for validation.

However, even if we all had a unique 4096 bit private key with which we identified ourselves, it would still essentially be a number and it would certainly be able to be stolen. Stealing a number is more or less the same as stealing a private key or stealing a classified electronic document - it's the unauthorised access and copying of information. Society has broadly come to accept that this is considered stealing.


"Stealing" a number does not exist. Learning what the number relates to by way of breaking the law should be.


You're arguing about the definition of the word steal, and your definition is not the widely accepted one. You're facing a long and uphill struggle.


> This is yet another alarming signal that the whole idea that your SSN/SIN or credit card number is somehow secret and can be used for authentication is flawed.

Secret information is required for practical authentication. Some examples:

Private keys (ssh, gpg, SSL/TLS certs, bitcoin wallets)

passwords

session ids

api secrets

auth tokens


I believe you don't often write down your private keys, passwords, api secrets or auth tokens on paper forms that you then submit to various institutions you have no control over, right?

As a comparison, your SSN is used all over the place, you will need to disclose it regularly (rent an apartment and your landlord is likely to request a credit check, you'll give him your SSN). A number of people and institutions will have access to it. It is not a secret. It should not be used for authentication and no one should assume it somehow secret, because it is not.


Semantics doesn't really help when everyone understands the meaning anyway. No one is going to read this and think 'Oh no, those poor people don't have their SINs anymore!'

That said, the SIN in Canada is actually meant to be kept secret between you, your employer(s), the CRA, and a few other situations[1]. You should never give it to anyone else, write it down anywhere, etc. I memorized mine long ago and keep the actual card locked in a box somewhere, and I never give it out except to the government or new employers.

[1] http://www.servicecanada.gc.ca/eng/sin/protect/provide.shtml


In Canada you can refuse to give someone your SIN for non-government purposes ... in theory. I was once refused an apartment sublet once when I did this. I had to come back with evidence that the landlord had no legal right to collect the SIN. That and the strong implication I was capable and willing to file a complaint.

People use all sorts of zany things to try to prove identity. I think public education is the first line of defence against the misuse of things like SSN/SIN.


More specifically - you can't refuse to give your SIN to a financial institution or to your employer (as for 99% of Canadians those are their main sources of income, and because those entities need to submit information to the government regarding your income for tax purposes).

For most other things though you can refuse to disclose it (i.e. telecom providers, debt-only financial institutions like credit card providers)


I didn't think it was so much a 'you have the right to refuse' as much as it was 'it's illegal to ask' for situations not related to taxes and payroll and stuff like that.


In terms of being used for authentication, CRA and other online services usually require SIN + DOB + Postal Code, and then they mail you a 4-digit PIN to the address they have on file.

Hilariously enough, if you call them, you can change the address on file if you have SIN + DOB, making the "PIN" pointless (and irritating, since you have to wait several weeks)


They have updated now to work with some of the banks.

Still a pain to get it setup, but once you are setup it is much better now.



As a matter of principle, it's true that a number cannot be stolen. On the other hand, in some contexts obtaining a copy of a secret number can allow a thief to steal a resource such as money, which definitely can be stolen. I'm not quite sure what to use instead of the shorthand 'stole Social Security numbers'; while strictly inaccurate, better alternative phrasings don't immediately jump to mind.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: