Update 25th June 2019: EBN scammers bankrupt

The text below is a comment from Mr.(?) Gorila to my previous EBN scam post, he kindly translated a German article from year 2011 to English reading audience. Given the length of the text, I'm posting the un-altered comment here. I did add the emphasis for subtitles to make the article easier to read.

Why this is important, is of course the legal precedent. EBN-scammers sued somebody and lost!
So: DO NOT PAY! You will win your case in court.

So, to repeat, the text below is not mine, but I think it being very valuable for the people following EBN scam case.

Indeed, Legal German language is very difficult to translate into English. However, in 2010 there were many German articles addressing this court decision. Language of journal articles is simpler and easier to understand. Yet that article is informative and precise enough to conwey the court ruling message to general public.

Here is a good one, with translation below (Please note, that the translation is not literal to avoid German idioms and phrases inconsistent with English language):
http://www.kostenlose-urteile.de/LG-Hamburg_309-S-6610_LG-Hamburg-zu-Branchenbuchabzocke-Eintragungsformular-Datenaktualisierung-2008-des-DAD-Deutscher-Adressdienst-erfuellt-Straftatbestand-des-Betrugs.news11513.htm

Judgement of Regional Court Hamburg (Urteil vom 14.01.2011 - 309 S 66/10)

Regional Court Hamburg on Business directory rip-off:
Registration form "Data update 2008" of the DAD German Address Service constitutes criminal offense of the fraud

Due to an overall view of the court considers the intent to be deceive

The district court Hamburg has confirmed the complaint of a customer in second instance, who had sued against the DAD Deutscher Adress Dienst. This had taken the customer into the Internet address register at www.DeutschesInternetRegister.de, without making it clear that the entry was subject to a charge. The customer should pay 2,280.04 euros for the entry. The customer hired a lawyer with whom he went to the court. There, he sued for decision that he was not required to pay and for reimbursement of his legal fees. The district court Hamburg Barmbek gave the customer right. The district court Hamburg confirmed the judgment in the appeal.

Defendant is a business directory DAD with about 1.2 million registered companies. The vast majority of the registered are of free entries, which DAD has copied from publicly available sources. The customer received a letter from DAD, entittled "Data Update 2008". The letter requested a review of the existing and updated if necessary. It was also said: "The registration and updating of your basic data is free."

Only at the end of the form was an indication of the costs

An employee of the company then entered missing data on the pre-printed form and sent it to DAD as did a large number of authorities and tradespeople. Latter the company received an invoice for 2,280.04 euros for the entry with reference to a cost indication in the lower quarter of the form (annual price of 958 EUR plus VAT).

Deception about actual costs is fraud

The district court Hamburg evaluated this in its judgment as fraud. This does not change the fact that DAD has quite specifically indicated the cost-bearing nature of the offer in the letter. Rather, it is decisive that the possible act of deception in fraud is not only the pretending of false facts or the disfiguration or concealment of existing facts. Moreover, any behavior other than deception is also considered, provided that it may provoke a mistake on the part of the other person and influence the decision to make the desired declaration of intent.

Deception exists when the victim of fraud, knowing all the circumstances, would act differently

On the other hand, it was not decisive whether the deceived person followed the care required in the course of business dealings or even acted negligently with regard to the ommission of certain contractual information. Insofar as the error on the part of the customer has been triggered by a legally relevant deception. The customers claims do not fail because the error is caused by his own negligence in dealing with advertising mail.

The nature and design of the form produce erroneous ideas

In particular, in cases where the author of a contract offers, by presentation and formulation, a kind of design, which should cause the addressee has erroneous ideas about the actual supplied parameters. A deception can be assumed even if the true character of the letter could be recognized after careful reading. This also follows from a judgment of the Federal Court of 26.04.2001, Az. 4 StR 439/00. The respective deception must have been used according to plan and was not merely a consequence, but the purpose of action.

Costs notice at the end of the form could be overlooked by the customers

According to the Federal Court of Justice, in the case of a merely misleading presentation in the offer letter, it is above all a matter of how strongly significant contractual parameters are presented, distorted or edited. In the present case of DAD, the non-binding appearance of the request for review and correction of well-known data can caused that the price will be at least overlooked by some customers.

Form gave the impression of already existing contractual relations

Finally, another indication of the intended deception was that the form had already been pre-filled with the customer's data. Such an approach was apt to give the recipient the impression that it was not a novel business relationship but that it was intended to maintain or extend an existing contractual relationship.

Simple online entries usually cost no 2,280 euros

It is also crucial that none of the addressee with a total cost of over 1,900 euros for a simple online registration have to expect. With this reasoning also the district court Heilbronn decided by resolution of 23.06.2010, Az. 3 S 19/10 in a similarly stored case.

When first information about a severe security flaw in Intel CPUs came out, it was immediately obvious, that this one is huge. This is in the scale of a meteorite hitting The Earth.

Here is just one example of what can happen, when fixed Linux kernels are deployed. I've been pumping data points from my weather station to Weather Underground for couple of years. Now this is how they are able to display my data:

If you don't see any graphs or data points there, that's my point here! WU does not work!

Yesterday I got an e-mail from them explaining the problems they're facing:

The interruption of service was related to the hot patches applied to our servers to correct the recent Intel hardware security flaws. We can say with 100% confidence that the data you share with us is completely safe. The patches required systems to be rebooted and, as these systems came back online, many of them did not boot up cleanly.

That is most definitely not the entire truth. The quality of their service at the time of writing this blog post is simply crap! Looks like Meltdown mitigation hit them harder than they anticipated.

I came back from Christmas holidays on Tuesday 2nd January and quite soon that morning our corporate chat channels were buzzing about this "Intel CPU flaw". Lot of the information came from article The mysterious case of the Linux Page Table Isolation patches. At the end, the author of the post suggests "Invest in popcorn, 2018 is going to be fun". For something written on first day of the year 2018, that is pretty well said!

More and more details leaked on Wednesday 3rd. The Register article Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign suggested said, that Linux kernel team named the flaw as Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT. So, they must have been mighty annoyed by this one. Urban Dictionary has a rather hilarious explanation of it.

Given the time difference between US an Europe, the information was published late on 3rd January, in form of website Meltdown and Spectre - Vulnerabilities in modern computers leak passwords and sensitive data. On Thursday 4th European time, entire Internet was full of news and speculation of these security flaws. Nobody has really confirmed this, but it looks like Intel knew about this flaw back in June 2017, for example Ubuntu-project confirms, that they received information about the flaw back in November 9th.

So, what is fuss this all about?

Since nobody really understands Kernel page-table isolation or Speculative execution, a much simper approach is needed to get a grasp of this problem (yes, you Super-Nerds understand it, I know!).
Xkcd #1938 has the best summary of this flaw that I've seen:

Mr. Daniel Miessler also has pretty good summary of the problem in his post A Simple Explanation of the Differences Between Meltdown and Spectre:

Ultimately you have two choices:

1. Have a computer, which has a serious exploitable security flaw
2. Lose some of your CPU-power

Most cases door #1 is chosen for you by your operating system vendor or cloud service provider.

A real measured effect of the fix

This is what Epic Games measured for their game Fortnite:

While looking at the graph, please remember, that Epic Games didn't choose to have the fix installed. This decision was made for them thanks to cloud computing.

There are number of similar reports all around the web, including Tim Gostony's tweet "Impact of the patch for the Intel bug on my AWS EC2 instances running Linux". It shows much les bump in the CPU-power than Epic Games' graph, but still it is there and it can be noticed.

What now?

Ok, everybody's every CPU is affected, but luckily for Meltdown mitigation you wouldn't normally run malware on your computer anyway. For Spectre, it gets scary. It mostly affects shared computers where somebody else is capable of stealing data from your instance.

The #1 thing I'll be waiting most is a physical CPU product that can be purhcased from a store which has a fix for this. Nobody has even promised anything about that. The existing software-based fixes are horrible. For example I was running Progress Quest on a Windows 93 session on a i7 laptop. After the fix, simply starting Windows 93 on a web browser it takes almost all of the CPU instead of idling like it did before the fix.

Amazon Web Services (AWS) in their original statement they said that "This is a vulnerability that has existed for more than 20 years in modern processor architectures like Intel, AMD, and ARM across servers, desktops, and mobile devices." I'm hoping, that it will take less than a decade to get it fixed.

Update 25th June 2019: EBN scammers bankrupt

Roughly an year ago I posted about EBN European Business Number scam. Now, an year later, it is one of the most commented article on my blog. At the time of posting, I was just pissed off about that stupid scam and wanted to inform and educate my readers about this and warn them for NOT to agree on their terms, nor pay anybody any money for it.

Then something that I didn't foresee or expect to happen happened: The article took off and thousands of people read it and dozens commented it. Looks like I stumbled into something big. The upcoming months proved, that this scamming corporation was operating all over Europe and doing their less-than-honest "business" of selling nothingness to unwary business owners.

Given the flood of comments, recently I found out that Raivo Laanemets, an Estonian software consultant, wrote about EBN scam back on 2015, over year before I did. Go read his blog post here. For the pointer, I'd like to thank Mr. Vaidas, who copy/pasted the comment from Mr. Laanemets' blog to mine.

This is the comment from June 2017 and contains following by Mr.(?) Gorila:

The critical claims made are:

1. Person behind all this is Adrian Wittmer
   • My comment: I'm not sure how to confirm this
2. Mentioned Adrian Wittmer is actively involved in two companies: Credit Business Resolution s.r.o. and CCF Credit Collection Factoring s.r.o.
   • My comment: I have not seen the threatening debt collector's letters, but in my previous EBN post comments, people have said, that the company doing the debt collecting is indeed Credit Collection Factoring s.r.o. from the Czech Republic
3. Czech Republic legislation is more tolerant towards fraudsters
   • My comment: I barely know parts of Finnish law, gaining understanding difference between German or Czech laws is way beyond me.
4. Regulation (EC) No 1896/2006 of the European Parliament and of the Council of 12 December 2006 creating a European order for payment procedure
   • My comment: The above mentioned regulation directs how payments of "low value" between companies. (16) says: "This would allow the court to examine prima facie the merits of the claim and inter alia to exclude clearly unfounded claims or inadmissible applications."
     Article 7 (d) and (e) define, that EBN debt collectors need to establish basis for their claim and appropriate evidence.
     Shortly: If EBN-scam can be proven as unfounded claim based on fraud, you don't have to pay.
5. Mr. Wittmer has created a money-making-machine. First he sells a non-existing "service" for European Business Number, then he acts as an enforcer to collect his own debt from customers refusing to pay.
   • My comment: Again, I'm not sure how to confirm this, but it sure looks like that!

What I found out to corroborate Mr.(?) Gorila's claims made is:

• A variation of EBN-scam has been running in Czech Republic since 1998. There is an article about the scam written in 2006.
• Articles about Intercable Verlag AG can be found back in 2003 in Swizerland.
• Intercable Verlag AG was raided by Swiss police in 2006 and placed in liquidation in 2009
• I found a ton of claims, that Mr. Wittmer was the managing director of Intercable Verlag, but was unable to verify that. I guess, I just have to assume, that the claim is true.
• Croatian authorities issued a warning against EBN scam in 2017. That binds Swiss Intercable Verlag AG into Dutch EU Business Register and German DAD Deutscher Adressdienst GmbH. That could be a proof, that same persons operate the scam.
• In September 2014 European Parliament issued a notice about on misleading offers from Deutsche Adressdienst GmbH (DAD). That document clearly states that all petitions against the DAD Gmbh have been "declared admissible".
  Shortly: You don't have to pay!

There seems to be a lot of truth in his(?) comment.

Do not pay!

When going gets tough for you, just refer to European Parliament Petition 1176/2013, Petition 1180/2013 and Petition 1556/2013 to the judge. That should make things bouncing your way.

About Humble Bundle

Couple months ago there was a real good deal in Humble Bundle for eBooks. For those of you who don't know what Humble Bundle is, it's a for-business subsidiary of IGN Entertainment (which again is a subsidiary of Ziff Davis). Unlike regular charities , which just make a plea to give money to them, Humble Bundle makes deals with software vendors to sell products which are way past their prime money-making age. Their slice of the operation is ~20% and the rest goes to software vendors and the charity of your choosing. In many cases you can choose the charity:software-split from range 0-100% and if you feel like it, you can tip Humble Bundle with something extra.

They passed $100M USD donated in September 2017. As there are costs of running the business, they raked in money more than that, but so far nobody has proved that they wouldn't actually deliver on their charity-promise. They are doing business with major corporations and if Humble Bundle would be caught red-handed, they would face a horde of lawyers suing their asses. For the time being, I choose to believe that they keep their promises and occasionally when I see something interesting in their mailing list, keep sending my money to them.

About the author, Kevin Mitnick

Ok, enough Humble Bundle, this is supposed to be about the book.
Since the deal was sweet, I went for it and paid couple € for the de-luxe bundle of security-related books (I think the actual amount was in region of 25 €). They delivered the download link for unlocked PDFs instantly after my PayPal payment was accepted. So, now I'm a proud owner of 14 books about information security.

The one book that I really wanted was the famous Art of Deception by Kevin Mitnick, a reformed bad boy who turned white-hat hacking. A warrant to arrest him was issued back in 1992 and he managed to evade FBI till February 1995. Since there was no applicable legislation in USA to convict him from the cracks he made to various US Government agencies and private corporations, US Department of Justice managed to keep him incarcerated for 4 and half years without bail or trial. When he got released to general public, a judge slapped a 7 year ban for him not to profit from selling books or movies, still on 2002 he put together this book and managed to get it published. He also published a book The Art Of Intrusion: The Real Stories Behind The Exploits Of Hackers, Intruders, And Deceivers in 2005, but it's unclear to me did he profit from them at all. Wired confirms, that the ban from profiting ended in January 2007. If anybody knows that, please drop a comment.

About the book

Well, enough of the author, this is supposed to be about the book.
The stories about social engineering tricks either Mr. Mitnick pulled off himself or the stories he describes in his book are really intriguing. But at the same time the technical details are vastly outdated, remember it was published in 2002 and stories are from 60s to 90s. Reading stories about dial-up modems, faxes and landline telephone voice mails make me laugh in the wrong place of the story. So, while reading, I was constantly thinking if it would be possible to pull off a similar feat in the modern world.

The books is written on four sections. Parts 1 and 2 are more about how social engineering works. There is always sonebody with poor awareness, either by not doing what was instructed or the instructions are missing or poorly done to begin with. Part 3 contains the "war stories" how people were fooled to say or do something they wouldn't normally do and while doing it didn't understand the value of their deed to the opposing party. To summarize, it's never a single piece of information which can compromise your organization, it's always a combination of things. To pull off such a social engineering hack, you must have detailed information about procedures and find a weak spot there. Also, most of the hacks are done to multi-site corporations. If your organization is geographically bound to a single location, it will be very hard to call in and request something "for my boss" at the remote site. My experience about small and medium sized Finnish companies is, that most people know everybody at least by name. Any incoming call would immediately raise suspicion and would question the caller's true agenda and identity.

Part 4 contains instrictions how to prevent such socical engineering attacks. For anybody not making security policies that part might be little bit boring. Here is an example of a flowchart how to train personnel:

Copyright © 2002 by Kevin D. Mitnick

Given in modern world, that government organizations don't need to pull of such hacks to get your information. You've already volunteered all of that! All they need to do is capture it from your cloud service provider's hard drive. Also, generally speaking personnel are more aware of possibility for social engineering. In his CeBIT Global Conferences 2015 video he claims, that for example dumpster diving still works. I personally wouldn't believe it. In Europe we don't need to print source code o passwords to paper and if we would be that stupid, there is a special secret-material-to-be-destroyed -paper bin at the office for such confidential waste.

Also, I remember seeing a video (... which unfortunately I was unable to locate) of Mr. Mitnick describing an assignment he got from a company, where his social engineering failed. It happened, that the receptionist knew about it. When Mr. Mitnick was requesting for a piece of information to get his assignment going forward, the receptionist actually responded: "Have you heard of Kevin Mitnick's book Art of Deception?". So, that was an example of well trained personnel to save that day. But unfortunately the book doesn't have a single example of social engineering failing. I was kinda expecting to see some of those.

About recommendations: people already knowledgeable about social engineering and feats that Mr. Mitnick pulled off don't get that much out of the book, but for everybody else, the book offers mind-opening stories, which can be reflected in everybody's real life. When somebody asks you for something they should already know, it may be time to think about social engineering.

If you have 6 minutes to spare, here is a DEF CON 23 video of Mr. Mitnick pulling off a social engineering hack, with permission from the target corporation, targeted to a pre-selected employee. They lure the poor guy to go to a website using Internet Explorer, which at the time had a known security flaw in it. That way they get a some sort of remote-access-toolkit to his computer. Nice! But not possible without the actual injection using the flaw being there.

Which anti-virus software to use on a Windows 10?

There are a number of software to choose from. Some are free, some are really good at detecting malware, some are award winning, industry recognized pieces of software and there is even one that comes with your Windows 10 installation.

For couple decades, my personal preference has been a product from F-Secure. For those of you expecting me to hand out a recommedation out of numerous F-Secure products, given the multiple computers I operate on daily basis, just picking a single specific product is not possible. Also, I'm a member of their Beta Program and run couple pieces of their software which are not flagged as production-quality.

Here is the part with a recommendation:
When Ultralight Anti-Virus (for Windows) gets released, that's the one I definitely urge you to try out. The user interface is an oddball, simple, but odd:

On an initial glance, the first question I had was: "Ok, Where are the settings? Where IS the user interface?!" But that's the beauty of the product, it has no more settings than the above screenshot contains. That's wildly out-of-the-box. Functional, yes. But something completely different. Naturally it's a F-Secure product, and they don't make any compromises with ability to detect malware. It has no firewall or plugins to your browser or anything unnecessary.

When/If the product is ever released, go check it out!

Mathy Vanhoef and Frank Piessens are both decorated security researchers from KU Leuven, Belgium. On an otherwise slow Sunday, 15th October 2017 Alex Hudson dropped a bombshell: Mr. Vanhoef and Mr. Piessens figured out a way to bend the authentication envelope, making WPA2 broken. Authors coined this as a Key Reinstallation AttaCK. Whaat?! Darn!

Looks like the release was planned carefully. OpenBSD had the fix on 1st March 2017. That's over 6 months earlier. Also Microsoft had a whiff of this flaw in the early phase as they managed to release a patch already. The complete vendor list can be seen @ cert.org. Its a sad read, that.

The information is at https://github.com/kristate/krackinfo and contains a very simple message:

Unless a known patch has been applied, assume that all WPA2 enabled Wi-fi devices are vulnerable.

Ok, that sounds really bad. To cut all the FUD and blah blah out, what's the big deal?

• This is a Wi-Fi client attack
  • Explanation: The entire KRACK thing works by spoofing as your router to your client. After the attacker manages to lure your laptop or cell phone into connecting to a fake network, it acts as a man-in-the-middle reading your transmissions.
  • You cannot hide your network information. If you transmit or read transmissions, somebody can read that. That's the bad part about radio transmissions, they travel to everyone.
  • The only way to hide your radio transmissions is to turn Wi-Fi off.
• Anybody attacking YOU needs to be in same physical area than you
  • Explanation: A random guy from The Net cannot attack you. They need to travel to where you are.
• Regardless of what, attacker will not gain your WPA password
  • Explanation: This attack is about fooling your laptop/cell phone/refridgerator to talk to a malicious wireless router. It does not extract your Wi-Fi network password while doing it.
  • So, this is almost as bad as the WEP weakness back in 2001. In that particular incident any random body could just crack their way to your network by figuring out what your password is. And then it was possible to read any captured past or future transmission. KRACK works only forwards, your historical transmissions are safe.
• If you are using TKIP or don't know if you are using it - you're doomed!
  • Explanation: TKIP, or Temporal Key Integrity Protocol is weak anyway. You shouldn't be using that in the first place!
• If you are using Android or Linux - you're most certainly doomed!
  • Explanation: The implementation in Linux (Android is a Linux, you know) is especially flawed! Attacker has easy means of forcing any client to fake router and then force your encryption key to something the attacker can predict, thus being able to read your traffic in real-time or introduce new data packets and spoof them to originating from your Linux/Android. That's bad, really bad!
• If you are not using Linux, and are using AES-encryption - you're doomed!
  • Explanation: Yes, if attacker can lure you to use the faked router, your transmissions can be read.
  • Examples of non-Linux clients include, but are not limited to: Windows, macOS, iOS.
• My router has Linux or I got my router free when I got my Internet connection and I don't know what operating system it has - you're doomed!
  • Explanation: This is not about your router. This is about attacker faking to be your router. Your router won't be attacked, but attacker will spoof traffic to it.
• If a random attacker can read all my traffic and can inject new transmissions spoofing as you, is that bad?
  • Explanation: Yes it is. Attacker can attempt to stop you from using SSL/TLS and there are number of scenarios where that can happen, so all your precious passwords, credit card numbers and other secrets can leak. However, there are number of scenarios where that is not possible. Still, if attacker has your encrypted traffic, other means of decrypting it exist.

As you can see from the above list, there are quite a few scenarios which end you in the 'you're doomed!' -state. So, assume that you are or will be!

The relevant question remains: Is there anything that can be done?
Answer is: Not really

Just wish/pray that your particular vendor releases fixed firmware sometimes soon. Most Android vendors won't.

This is a rare event: somebody is actually improving my privacy and I don't have do do anything. Nice!

Apple is introducing intelligent tracking prevention technology in upcoming Safari 11. They're pretty radical in their cookie blocking, they're "deleting even first-party cookies if it's been more than 30 days since you interacted with the website that set the cookie". Naturally corporations depending on tracking you don't much like that, but Apple's response is: Tough luck, privacy comes first. So, it's natural that advertisers don't want you to use Safari or know how to make their tracking harder.

Safari 8, 9 and 10 will block 3rd party cookies as default. You can opt out of that, but it's just ridiculous. I strongly advice against that. Nobody really needs 3rd party cookies, they are never up to no good. Couple years back a Swedish web shop I frequently purchased movies from changed their on-line payment vendor and they actually used 3rd party cookies for the payment transaction. I took a pause over 2 years before doing business with them again. Their current payment system works correctly.

Firefox allows 3rd party cookies, but there is a setting:

Same thing with Chrome, it allows 3rd party cookies, but you can disable it from well hidden setting:

What's really cool with Safari 11, that they'll move tracking protection to the next level. There is a "special" treatment for well-known 1st party cookies too. This is top notch stuff and it outperforms most add-ons and extensions. Really nice!

In my previous post, I was (not so) politely asking DocuSign to admit e-mail addresses leaking.

Finally, they did! They posted Update 5/16/2017 - Update on Malicious Campaign.

Q: What information was impacted?
A: It was a list of email addresses stored in a separate, non-core system used for service-related announcements.

That is something they should have done a week ago, but I guess we have to settle with that.

Btw. I got my hands on the payload VB:Trojan.VBS.Downloader.ACR as named by F-Secure. As many have reported before, it's a MS Word document with a macro in it. The VBA-thingie de-obfuscates a "picture" embedded into the .doc and injects that directly to memory to be executed. I really didn't want to waste the ton of time investigating the actual malware, its bad, I know that without looking. Its just another reminder of how dangerous the VBA-macros are, they can call any system call from Windows kernel and do really complex hacks, like any real executeable would do.

On 9th and 10th of May I got really weird spam from alleging to originate from DocuSign. The attempt to lure me to hit the link was lame and I didn't believe the communication to be valid at any point. There was no DKIM-signature in the e-mail headers. I know for a fact, that real DocuSign e-mail has that in them. So, any quick analysis of the mail originating from USA and Canada was yelling SPAM! instantly.

The subject of the two first ones was "Completed: Wire Transfer Instructions for docusign Document Ready for Signature" and the third one "subpoena from WEX inc". All of them attempted to get be to download a file from an already shut down websites. All three domains used were 12 characters long .ru-domains and looked random strings to me. I don't know if the words had actual meaning, they just looked random to me. The URLs had my e-mail address Base64-encoded to allow the perps to track any incoming clicks for active e-mails.

Of course plenty of others got the same junk as me, there is a support thread at DocuSign's site: Strange email from Docusign - is it legit? In an answer to that one, the official statement says: "However, DocuSign’s core platform has not been hacked, and our customer data remains secure". In that comment thread there are other people, who don't believe that. I'm one of them.

Why would I make such a bold claim? Well... easy. The e-mail address I'm using in DocuSign is unique. I'm not using that specific address ANYWHERE else. So, people of DocuSign, explain me where the address leaked if not from your system! I guess they claim, that it leaked from one of my systems. But then again, the same thing must have happened for number of other people too. Also, I use hundreds of different addresses for this purpose, to reliably determine which system leaked my information. Any even remotely regular user has their joe.user@mail.com-address registered to dozens and dozens of systems, so they have no possible way of knowing who leaked the data, I do.

I'm urging DocuSign to step forward with a truthful statement about the breach. Their current lies I'm not bying.

Update 15th May:

DocuSign got hacked also two years ago. Same thing happened, they deny any data leakage. Without proof, I feel like throwing unfounded wild allegation here: they have been compromised for over two years now.

In the support discussion thread couple of other people complaining about same thing than I do: the e-mail address isn't being used by anything else than DocuSign, still they're receiving junk to that particular address. How come?

CAcert is my favorite source of certificates. It has been that for years. The buggy Let's Encrypt I loathe, their poorly tinkered Python-scripts won't work and after couple hours of unnecessary fixing of their bugs, the scripts decide to write to my configurations. So, those guys really don't have a clue what they're doing.

However, CAcert isn't doing much better. Their root certificate is still MD5-signed. Argh!

CAcert's claim is, that "Severe weaknesses have been found in MD5, but at present they do not open vulnerabilities for X.509 certificates". But nobody else is buying that. It's just that this international non-profit organization is light on resources and they want to get his one done right. They just don't seem to be able to squeeze a re-signed root certificate out.

Update 20th Apr 2018: There is a follow-up post about installing this into iOS-device.

Briefly on certificate hashes

A X.509 certificate needs to be signed to make sure it originated from the Certification Authority announced in the certificate. Since the root certificates are typically self-signed, they are at the end of the certification chain, there is no other authority to validate them. That's why the hash of the signature is published at the CA's website. In case the hash doesn't match, it is possible to notice that somebody modified the signature.

What others are doing: Expiring MD5 and SHA-1 hash algorithms

Apple iOS, Oct 13, 2011, About the security content of iOS 5 Software Update

CVE-ID: CVE-2011-3427

Description:
Certificates signed using the MD5 hash algorithm were accepted by iOS. This algorithm has known cryptographic weaknesses. Further research or a misconfigured certificate authority could have allowed the creation of X.509 certificates with attacker controlled values that would have been trusted by the system. This would have exposed X.509 based protocols to spoofing, man in the middle attacks, and information disclosure. This update disables support for an X.509 certificate with an MD5 hash for any use other than as a trusted root certificate.

Microsoft, Aug 13, 2013, Update for deprecation of MD5 hashing algorithm for Microsoft root certificate program

On affected releases of Microsoft Windows, security update 2862973 requires that certificates no longer use the MD5 hashing algorithm. Microsoft products or third-party products that call into the CertGetCertificateChain function will no longer trust certificates that have MD5 hashes.

Microsoft, Nov 4 2015, SHA-1 Deprecation Update

We announced that Windows will block SHA-1 signed TLS certificates starting on January 1, 2017. In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.

Google, Dec 31 2015, SHA-1 Deprecation: No Browser Left Behind

After December 31, 2015, SSL certificates that use the SHA-1 hash algorithm for their signature will be declared technology non grata on the modern Internet. .. over the course of 2016, will begin issuing warnings and eventually completely distrust connections to sites using SHA-1 signed certs.

Apple, Sep 20 2016, MacOS & Safari SHA-1 deprecation policy

Apple hasn't made any specific announcements here. The nearest we've come is a general warning in WWDC 2016 Session 706 What’s New in Security:

• SSLv3 cryptographic protocol and the RC4 symmetric cipher suite are no longer supported, starting at the end of 2016. It's recommended that you stop using the SHA-1 and 3DES cryptographic algorithms as soon as possible.

CAcert SHA-256 re-sign project

Altough CAcert guys think that there is no security flaw in MD5-signed certificates, they chose to do something about this. They managed to get the existing root certificate re-signed with SHA-2 on number of occasions. The most recent one is: root certificate re-signed. This was executed successfully on 2016-03-12

The result is kinda published, it's not publicly available, but if you're willing to go the SHA-256 project's SVN repository at http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/outputs/, the result is available.

Go there! Get it! Use it!

Installation instructions

Should I install the intermediate certificate too?

No.

The idea with web server certificates is, that you establish trust to root certificate. All certificates are issued from intermediate-CA, which certificate can be revoked at any given time. That's why the intermediate certificate needs to be deployed with the server certificate. This is something many system admins keep misunderstanding.

Which keychain / store the CAcert root certificate should be installed?

My preference is always to install new root certs into system-wide keychain / store. That way any human users (me and possibly others) or system/daemon users get the new cert at once.

macOS

For this to work, you'll need

• root access to your Mac
• old MD5 signed root cert
• new SHA-2 signed root cert

First disable trust to the old cert:

security remove-trusted-cert -d CAcert-root.crt 

Remove the old cert by it's signature:

security delete-certificate \
 -Z 135CEC36F49CB8E93B1AB270CD80884676CE8F33 \
 /Library/Keychains/System.keychain

Add and trust the new cert:

security add-trusted-cert -d -r trustRoot \
 -k /Library/Keychains/System.keychain \
 root_256.crt

The important point in macOS is to remember, that adding a root certificate to keychain doesn't make it trusted. You'll need to implicitly tell an added certificate, that you trust it too. That's kinda weird, but ... some smart guy at Apple designed that so.

Windows

For this to work, you'll need

• administrator access to your Windows
• new SHA-2 signed root cert

Remove MD5-signed:

certutil -delstore Root 135CEC36F49CB8E93B1AB270CD80884676CE8F33

Add and trust the new cert:

certutil -addstore Root root_256.crt

Linux

Ah, there are too many distros out there.

Any typical approach would be to place the file into /etc/pki/tls/certs/ and symlink the certificate's OpenSSL hash 99d0fa06.0 into it.

iOS

... This one I'll get back in a later post.

Update 2nd December 2017:
After receiving comments to this blog post, I started doing more digging and there is a new blog post about EBN scam.

Today I got yet another snail mail scam as a printed letter. It looks like this:

The scammers are claiming, that they are missing my corporate VAT ID. Hm. That's strange. All the other information they got from Finnish Business Registry (ytj.fi). But as they are missing my valuable VAT-number, I'll need to fill it into a pre-filled form and add a binding signature. I'm not exactly sure, what exactly should I do with this form after signing it, but such a form was sent to me.

Caution! Scam here is in the monotype-font part (see above page 2):

Order: We hereby confirm the accuracy of our company' s data as per the information given above and we hereby place an order with DAD GmbH (Publisher) to publish them in a graphically highlighted form on www.e-b-n.eu according to the general terms and conditions printed overleaf.

We accept the advertisement' s annual costs of 890 Euro, which are payable in advance upon receipt of the invoice. We acknowledge that the contract is valid for the next three years and subsequently will be automatically extended annually unless we provide a written notice requesting termination of the contract, this being no later than three months before the expiration of the contract's term.

We are only able to revoke the contract by registered letter within fourteen days of the order date; whereby the date of postage is decisive. We authorize the Publisher to use contents found on our website for the layout of our insertion.

We acknowledge Hamburg-Mitte as place of performance and jurisdiction and that German law is solely applicable. We confirm that prior to this order placement we had no business relationship with the Publisher. We agree that our company's data will be stored electronically.

Whoa! That's a long and difficult to read. All that easier to miss the part with "We accept the advertisement' s annual costs of 890 Euro, which are payable in advance upon receipt of the invoice". Oh! I thought this was some kind of "final reminder", not an order nor invoice.

There is an actual website http://e-b-n.eu/ with all collected publicly available business information in it.

To make this scam more believable, scammers added actual addresses and phone numbers in Hamburg, Germany. I don't know if neither of them are legit. I do know, that German business registry doesn't have Commercial Register, Companies' Section, Hamburg Local Court, Record No. 88115 with name of European Business Register. Actually, that record number belongs to somebody completely innocent. Also the German VAT ID of 813739877 seems to belong to somebody, but I don't know how to do a lookup on German VAT IDs, so I don't know whose VAT ID it is.

By googling the VAT ID, I found pretty much the same letter sent to Italian doctors "Registro Italiano Medici: attenzione alla modulistica". There is a scanned PDF of the letter. Funnily, it has the same German VAT ID, and Mrs. Daniela Kunst as the managing director of EuroMedi (http://euromedi.eu/). The price is bit cheaper, only 877 €. Also the website is hosted in the exactly same IP-address in Köln, Germany. Also, there is Deutsche Internet Kartei and Internet Register Österreich with same VAT ID and managing director, but on a different server.

Based on a report by (Caution: European Central Register of VAT Registration Numbers is a scam) German law firm, this scam has been going on since 2013. So, looks like their business is lucrative and nobody seems to be able to stop them.

In the previous part we established that any certificate authority can issue a certificate to any website, even if the website admin doesn't want them to do that. This post is about technical measures attempting to monitor certificate authorities' actions.

Details that need to be addressed somehow

A certificate lifecycle is very simple. One is issued by a CA, it is used by a server and eventually it expires. When things go sideways, the server administrator may want to revoke an otherwise valid and good certificate, so there needs to be a mechanism to handle a single special case. So, two actions: issuance and revocation. Everything else is handled by itself.

To monitor certificate issuance and revocation, following requirements apply:

• Monitor when somebody issues a certificate for your website
  • Preferably everybody in the entire Internet needs to know about this instantly. You decide if the issuance is good or bad thing.
• Man-in-the-middle using a fake certificate
  • When a subset of users is being targeted, clients need to know that the certificate being offered doesn't belong to the server the certificate supposedly is for.
• No trusted parties
  • This is something we learned from X-Files (the TV-show), trust no one! Any possible parties needed in verification must be assumed to be offering false information, or alternatively it needs to be digitally tamper-proof.
• Instant deployment of a new certificate
  • When you setup a server and a certificate to it, how do you notify everybody about that? Preferably no notification is needed.
• No need to modify servers
  • How is the actual server setup done. What parts you need to add there. Preferably none.
• No additional requests during connection
  • When a client requests data from your server, which additional requests to another parties are needed? Preferably none. Remember, that this type of additional request need to succeed in a split-second to make the decision wheter to open a connection to a requested server or not.

(This list is actually "borrowed" from certificate transparency tech comparison. Its just so comprehensive, so I had no other option than to use it.)

Certificate revoke list, aka. CRL

This is what we have since dawn of SSL. The idea is to go request the issuing CA and see if an already issued valid certificate is revoked. This information is published in a revocation list. The obvious problem is that revocation information doesn't happen instantly, and actually most browsers don't ever check a CRL.

To distribute the CRL-information, an issued certificate is supposed to have an URL to CRL (typically they do) and a client is supposed to be downloading that data periodically (typically they don't). In reality that doesn't work, as nobody wants to spend their precious time and bandwidth for downloading a ever-growing list of bad certs. To address that, there is a modern approach, Online Certificate Status Protocol or OCSP. It is supposed to be much faster operation with minimal bandwidth usage.

Neither of these really work well because of the need for an additional request. Also OCSP has a major fault, that a reply can be stored and "played back" on a query, so the reliability is more than questionable.

Certificate Transparency

This is the newest one and it has a good chance of becoming the commonly accepted method for tracking certificate issuers' actions. There is an RFC 6962 defining Certificate Transparency and the source code is distributed as open-source allowing anybody to see how it works and do their own audit on it. Originally the project is initiated by Google, but number of CAs already accepted the technology including Symantec, Digicert. and Globalsign. One reason for wide adoption is, that Google (the author of Chrome browser), made an ultimatum, that the seriously expensive Extended Validation certificates need to have CT signature in them for Chrome to accept them as valid.

Internally CT works with a Merkle hash tree, something that BitCoin uses internally. So, it is safe to say, that this technolocy is a blockchain. Blockchain as a tech is quite new, but robust and reliable. The good thing about Certificate Transparency is, that this tech supports all requirements from above list. All a browser needs to do is periodically load the CT logs and during a connection, read the CT-signature from server's certificate, and based on that a browser can instantly verify or decline the server's certificate.

As mentioned, Certificate Transparency needs to be supported by your browser. Being a Google project, of course Chrome does support CT since version 35. Mozilla Firefox has announced support for CT, but at the time of writing there is no implementation yet. Microsoft doesn't support CT and they announced that that they're doing something of their own for IE11, naturally their new Edge browser doesn't support CT either. So that pretty much lands Chrome being the only browser really supporting this. The good thing is, that there exists many server-to-server monitors, for example Certificate Transparency Monitor.

Not accounting for poor browser support, another weakness CT has is that every certification authority has to include CT-signature in their issued certificates and publish their CT logs to general public.

DANE

DNS-based Authentication of Named Entities, or DANE is the first serious attempt to enforce certificate's ownership. The tech is described in RFC 6698 and multiple accompanying RFCs to clarify details of it's implementation. However, DANE hasn't received much public acceptance.

This is how Wikipedia defines DANE: "DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work."

As the above definition says, for DANE to work, a prerequisite is functioning DNSSEC. Nobody has that! Some stats at http://rick.eng.br/dnssecstat/ show that the situation is horrible. So, no DNSSEC, no DANE. Also DANE fails on two other things: additional requests are needed to DNS during connection and you need to trust the DNS-server response. DNS data can be forged or poisoned, so there's that.

Pinning

Certificate pinning, or HTTP Public Key Pinning is an extension header of a HTTP-response. This is yet another Google-project, but its not widely adopoted. The idea for the web server to send public key information on every response, then the web browser is supposed to locally store the information for specified time. Then any subsequent responses from that same server are supposed to have the same information in them what was cached before. Weakness is that, the initial request needs to go to the real server. If your traffic was "man-in-the-middled" already at that point, you won't get any warnings.

Pinning is supported in Chrome and Firefox, but as Microsoft nor Apple support this, it is missing from IE, Edge and Safari. There is a funny mistake in Microsoft Edge's feature list as it states Firefox not supporting pinning, but Firefox was one of the early browsers supporting this feature.

Weaknesses here are, that it requires changes both on server and client sides. Also, when the certificate is legitimately changed, there really isn't a sensible mechanism to inform about that.

Collecting every web server certificate, aka that thing Google is doing

As you may remember from part 2 of this series, most of the rogue certificates issued are for Google services. So, they're fighting this by collecting all the certificates they see. They have a massive army of bots crawling web servers all the time. Google is also publishing their findings in a Certificate Transparency log for any interested parties to see. As mentioned before, there are publicly available non-Google services monitoring the CT-logs for abnormal changes.

This is very simple idea, if you see your certificate listed there, the certificate was issued by your request or somebody else's. It should be rather simple task to determine which one was it.

Anybody can use the human interface at Google Transparency Report site.

The future?

None of these technologies is really either useful, or widely adopted by major vendors. Fact remains: due to number of past incidents Certificate Authorities need to be monitored, supervised and publicly scrutineered. The best thing to attempt is to add some transparency to their actions. Which technology that would be is yet to be seend. What worries me is Apple's and Microsoft's total ignorance for this matter. I guess they'll need to be targeted first to wake up from their deep sleep.

This is the last part of my HTTPS-series. First part was about basics of trusted certificates and second part part was about misappropriation of trust.

In the previous part we established the fact, that for HTTPS to work as intended, you as a web browser user need to trust your browser vendor's decision to trust the certificate authorities issuing the certificates to web server maintainers. This post is about when things go wrong, the chain-of-trust is broken and organization's actions are deemed not so trustworthy.

Known CA security incidents in chronological order:

• 2010 (multiple incidents): Key Internet operator VeriSign hit by hackers
  • There isn't much information available on this, but they disclosed this on their quarterly report.
  • "Are we finally ready to accept that the certificate system is completely broken?"
    - Bruce Schneier, on his blog
• March 2011: Hackers target Google, Skype with rogue SSL certificates
  • Comodo was cracked, and certificates for orgs like Google were issued without them knowing about it.
• August 2011: Hackers stole Google SSL certificate, Dutch firm admits
  • DigiNotar was cracked and Google certificates were created. Later DigiNotar went bankcrupt as they reputation was gone.
• December 2013: French Government ANSSI responsible of a MITM against Google SSL-TLS
  • French CA issuing Google certificates
• July 2014: Indian government agency issues fake Google certificates
  • This is really bad! A government agency in India issuing Google certificates. I'd understand a company doing that, but government... no.
• December 2014: Turkish Certificate Authority screwup leads to attempted Google impersonation
  • Turkish CA issuing Google certificates
• March 2015: Google to drop China’s CNNIC Root Certificate Authority after trust breach
  • A Chinese CA issuing Google certificates.
• September 2015: Symantec employees fired for issuing rogue HTTPS certificate for Google
  • Inside job at Symantec, guys wanted to issue Google certificates
• October 2016: Distrusting New WoSign and StartCom Certificates (on Mozilla and on Google)
  • WoSign issued certificate for GitHub, yet another inside job.

As you already figured out the pattern. Anybody can issue any certificate for anybody. This many-to-many pattern isn't very trustworthy. Also, there seems to be more activity during the past two years or so, there is clearly more interest in gaining access to somebody's certificate.

In part 1 of my HTTPS-series it was established, that a X.509 certificate cannot identify the server. Now that cert-business sells certificates with a claim, that they have "verified" the request and the owner is who they claim to be, the above list tells another story. Nasty things happen when there is no verification, no real customer, but a malicious act of issuing a certificate for own cracking purposes.

Other acts of mistrust:

• January 2015: Gogo Inflight Internet serves up 'man-in-the-middle' with fake SSL
  • Inflight service provider goes man-in-the-middle on purpose. Of course all bad deeds can be wrapped into good intentions, they wanted to "protect the bandwidth usage".
• February 2015: Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections
  • Lenovo laptops were pre-installed with a certificate used for snooping your HTTPS-traffic. The thing is: if anybody can inject a trusted root certificate to your computer, you won't notice that somebody is reading your encrypted traffic.
• November 2015: Dell does a Superfish, ships PCs with easily cloneable root certificates
  • Yet another pre-installed certificate making man-in-the-middle. Every computer had same PKI installed making anybody able to eavesdrop your carefully encrypted traffic.

These acts are as evil, altough different by nature, but target the same thing: to gain access to your encypted data.

Ok, what's the risk here?

In practice, what is the threat here? What are those "nasty things" that can happen?

The incidents where new computers had a pre-installed trusted certificate, or your traffic was forced via man-in-the-middle -proxy are easier to address. Without you realizing it, all your encrypted traffic is directed to a party faking to be your intended target. Man-in-the-middle just de-crypts your passwords and credit card numbers and passes the traffic forward to the real target server acting as you. So, there is an obvious direct risk, that your traffic isn't secure at all.

Somebody issuing a trusted rogue Google certificate is bit more complex. A certificate itself isn't too dangerous, but in a scenario where the outgoing traffic from your computer is re-directed to a rogue server having the certificate you won't be able to tell the difference. How somebody's traffic can be redirected can be done locally, by changing your DNS-settings or remotely attacking the DNS-server your're using. Both cases are seen in real life. Nevertheless, it is almost impossible to know that such a change has been made and you go to a fake "google" server, enter your password without realizing, that somebody else is in possession of your login credentials. These cases haven't been publicly reported, but if anybody manages to pull that one off, it would be really really bad. Ultimately, there is only indirect risk, that you may lose your secure data.

Ok, this insecurity is horrible, isn't there anything we can do?

Yes.

There are a number of technical innovations trying to govern the certificates. However, none of them are widespread nor commonly accepted. This leaves everybody at the mercy of certificate authorities and their actions.

I'll address those technical measures in my final part of this HTTPS-series.

Three years ago I was inspired by Scofield (or Mr. Harri Hursti) when he claimed that SSL is broken and it cannot be fixed. See the post for details. In reality tech can be fixed, my previous HTTPS-post is about shortcomings and fixes of TLS-encryption. This time I'm writing about another type of HTTPS-shortcoming, trust. This is between humans and is much much harder to fix.

Ok, most users don't see the difference between HTTP and HTTPS. They simply don't pay any attemtion if their address-bar has the lock in it or not. Those rare who do make the distinction between encrypted and non-encrypted web sites are blissfully ignorant about the inner workings of HTTPS. They don't understand the concept of a X.509 certificate nor the need for one. A certificate is needed to (I'm quoting Wikipedia article here) certify the ownership of a public key by the named subject of the certificate. The ownership of a key is important, it is used to make sure the communication parties are the same who initiated the connection. Without that, the security could be easily breached with a man-in-the-middle -attack.

What the certificate isn't designed is to identify nor verify the certificate holder. Technically, the certificate has a suitable field name subject. In HTTPS-certificate, it contains the hostname (or domainname in a wildcard certificate) of the server a secured connection is initiated to. If a certificate is used on a different server, the hostname used for connection and issued in the certificate won't match, and the lock won't "lock" or "go green" depending on your choice of a web browser.

The part where trust comes into play, is because the system is built so, that somebody issues the certificate. There is a chain of certificates to follow up to a root certificate to somebody who has authority to issue them. Any newly generated certificate is untrusted by your browser by default, unless the issuer root certificate is pre-added to your browser. That's where the certificate business (read: money) is. A certificate issuer has gone trough the hard work of pre-installing their certificate to all commonly used web browsers so that some website owner can come in and purchase a certificate from them and it will work and be trusted by any website visitors. What happens here is, you as the website visitor implicitly trust the website you are visiting, because somebody you don't know said they're who they announce themselves to be and they promised to be ok when asked about it. Of course browser and operating system companies play along with this, they do their due diligence and accept requests to distribute those root certificates to establish trust between the issuer and a website.

That's a bold request! Why should I trust somebody whose name is Verisign or Thawte or TeliaSonera, whom I know nothing about! No reason. But that's how security in Internet works.

This is the first part of a three part series addressing HTTPS and it's (in)security. Next part is about misappropriation of trust. Third part is about (failed) attempts to supervise trusted authorities.