Over an year ago, DocuSign was hacked (again). Initially they denied the entire thing, but eventually they had to come clean about their userbase being leaked. I think their wording was, that only email addresses were stolen, but ... given their lack of transparency I wouldn't take their word on that. Read my post about the 2017 incident.

After the May 2017 leak, I've received at least dozen emails to my DocuSign address. For the jerks pulling the userbase, it surely has been a source of joy, a gift that keeps on giving.

Couple days ago I got one of these:

Looks like a perfectly valid DocuSign you've-got-mail -announcement, except it has a really funny recipient address, DocuSign knows my real name. Also, the link won't land on DocuSign website. The Sign Invoice -link doesn't even have HTTPS-address, which is pretty much mandatory after July 24th 2018, so without a doubt it is a fake. I'm not sure if its sensible to publish the UID of CRIQQABU2AHOQ0TUYBUD or the code E1ABA59517. Doing that might bite me later, but its done already.

At the time of writing, GoDaddy took the entire target site down. Obviously, some innocent website (most likely a WordPress) got re-purposed to act as DocuSign "mirror" harvesting data of click-baitable victims and offering them malware and/or junk. GoDaddy is notorious for taking down domains and websites on a hint of a complaint, so I really cannot comprehend why anybody would want to use their services. Given their enormous size, most of their paying customers won't realize, that anybody can take any GoDaddy-hosted site down in a jiffy. But that's the way the World works, you harvest money from the unware.

DocuSign is learning, slowly, but looks like the direction is correct. Their website (https://www.docusign.com/trust) has words "Transparency is essential" in it. Yup. That's right. Your mess, own it! This time they actually do own it, they published an alert ALERT:09/19/2018 @ 9.03 AM Pacific Time - New Phishing Campaign Observed Today. That's what you do when somebody pwns you and your entire userbase get stolen. Good job!

It remains to be seen, if those buggers dare to deny their next leak. So far I'm not trusting those liars, but I'm liking their new approach.

Today, I'm combining to previous post into a new one. I've written earlier about going fully Let's Encrypt and the problems I have with them. Now that I'm using them, and those certs have ridiculously short life-span, I need to keep automating all possible updates. That would include the IPMI 2.0 interface on my Supermicro SuperServer.

Since Aten, the manufacturer of the IPMI-chip chose not to make the upload of a new certificate automateable (is that a word?), I had to improvise something. I chose to emulate web browser in a simple Python-script doing first the user login via HTTP-interface, and then upload the new X.509 certificate and the appropriate private key for it. Finally the IPMI BMC will be rebooted. Now its automated!

So, the resulting script is at https://gist.github.com/HQJaTu/963db9af49d789d074ab63f52061a951. Go get it!

Toying around with RFID, tags has always been something I wanted to do, but never had the time. Contactless payment is gaining traction all around the world. The reason is very simple: it is fast and convenient for both the customer and vendor to just touch'n'go with your credit card or mobile phone on a point-of-sale.

Credit/Debit card payments are based on EMV, or Europay MasterCard and Visa, standard. See generic EMV info at https://en.wikipedia.org/wiki/EMV. Back in 2011 Visa started driving the contactless standard worldwide, and given the situation today, their efforts paid off. However, my understanding is, that at the time of writing this, regardless number of people attempting it, there are no known vulnerabilities in the contactless EMV. Finding one, would be sweet, but finding one would also be extremely hard and time consuming. So, I decided to go for something easier. MIFARE Classic.

What's this RFID, isn't it NFC?

Short answer: yes and no.

Long answer:

This infographic is courtesy of atlasRFIDstore
http://blog.atlasrfidstore.com/rfid-vs-nfc

MIFARE Classic info

Since this topic isn't especially new, I'm just posting some useful sites I found to be very useful when doing RFID-hacks:

• Finding the encryption keys:
  • https://linuskarlsson.se/blog/acr122u-mfcuk-and-mfoc-cracking-mifare-classic-on-arch-linux/
  • http://barisguvercin.com/mifare-1k-cracking/
  • https://github.com/FireFart/blog/blob/master/content/post/how-to-crack-mifare-classic-cards.md
• Cloning the tag:
  • https://gist.github.com/alphazo/3303282
  • http://www.ibuynfc.com/?cat=6
• Information about Mifare Classic encryption key hacking:
  • https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Almeida-Hacking-MIFARE-Classic-Cards-Slides.pdf
  • https://dl.packetstormsecurity.net/papers/general/cooking-with-mifare-classic-PS.pdf
• ISO/IEC 14443 Type A generations:
  • http://nfc-tools.org/index.php?title=ISO14443A

Going to eBay for the hardware

I had a real-world RFID -tag, and wanted to take a peek into it. For that to happen, I needed some hardware.

The choice for reader/writer is obvious, an ACR122. Info is at: https://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/. The thing costs almost nothing and is extremely well supported by all kinds of hacking software.

Going to GitHub for the software

All the software needed in this project can be found from GitHub:

• libusb, https://github.com/libusb/libusb
  • Some software want libusb 0.1 some 1.0. I had only 0.1 installed so I had to compile the latest also.
• libnfc, https://github.com/nfc-tools/libnfc
  • Latest installed
• MiFare Classic Universal toolKit, mfcuk, https://github.com/nfc-tools/mfcuk
  • Installed, because it has Mifare Classic DarkSide Key Recovery Tool. This is an advanced approach into cracking the encryption keys.
• mfoc, https://github.com/nfc-tools/mfoc
  • offline nested attack by Nethemba
  • This is the one, NXP tried to prevent the hack to be publicly released, see info from https://www.secureidnews.com/news-item/nxp-sues-to-prevent-hackers-from-releasing-mifare-flaws/
  • Creating an own encryption algorithm and expecting nobody to figure out how it works will work for a very short period of time. Going to a judge to prevent the information from leaking also works... if you're high on something! But on real life it works never.

All of the above software was installed with ./configure --prefix=/usr/local/rfid to avoid breaking anything already installed into the system.

Running the tools

Basic information from the tag (the actual tag UID is omitted):

# nfc-list
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
       UID (NFCID1): 11  22  33  44
      SAK (SEL_RES): 08

ATQA 00, 04 is listed in ISO/IEC 14443 Type A generations and is identified as MIFARE Classic. Goody! It's weak and hackable.

Just running mfoc to see if a slow attack can proceed:

# mfoc -O card.dmp
Found Mifare Classic 1k tag
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
UID size: single
bit frame anticollision supported
       UID (NFCID1): 11  22  33  44 
      SAK (SEL_RES): 08
Not compliant with ISO/IEC 14443-4
Not compliant with ISO/IEC 18092

Fingerprinting based on MIFARE type Identification Procedure:
MIFARE Classic 1K
MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation

And very soon, it results:

We have all sectors encrypted with the default keys..

Auth with all sectors succeeded, dumping keys to a file!

WHAAT! The card wasn't encrypted at all!
A closer look into card.dmp reveals, that there was no payload in the 1024 bytes this particular MIFARE Classic stored.

Since, the card doesn't have any payload, the application has to work based on childish assumption, that the UID of a RFID-tag cannot be changed. Nice! Because it can be set to whatever I want it to be! Like this:

# nfc-mfsetuid 11223344
NFC reader: ACS / ACR122U PICC Interface opened

Found tag with
 UID: 01234567
ATQA: 0004
 SAK: 08

My blank UID-writable tag had UID of 01 02 03 04, but I changed it into something else. Note: This is not allowed by the specs, but using very cheap eBay-hardware, obviously it can be done! Nice.

To verify my hack:
I walked into the appliation and used my clone successfully. Also, I informed the owners, that their security is ... well ... not secure. They shouldn't use UIDs as the only authentication mechanism. It's only 4 bytes and anybody in the world can use that 4-byte password. Using encrypted payload would make more sense, if MIFARE Classic wouldn't have a major security flaw in it's key generation algorithm.

This was one of the easiest hacks I've completed for years.

Year ago, I posted about CAcert root certificate being re-hashed with SHA-256 to comply with modern requirements. The obvious problem with that is, that it is not especially easy to install own certificates (or the new CAcert root) into a phone anymore.

When you try to access your mail server (or any other resource via HTTPS), the result will be something like this:

Not very cool. Getting the "Cannot Verify Server Identity" -error. This is especially bad, because in modern iOS you really don't have a clue how to get the new root cert installed and trusted. No worries! I can describe the generic process here.

Apple Configurator 2

Get it from https://itunes.apple.com/us/app/apple-configurator-2/id1037126344. Install it into your Mac. It doesn't cost anything, but will help you a lot!

If you dream on running it on a Windows/Linux/BSD, just briefly visit your nearest Mac-store and with your newly purchased Mac start over from the part "Get it from..."

Root certificate to be installed

Get a root certificate you want to distribute as trusted root CA. With the Apple Configurator 2, create a profile containing only one payload. The certificate in question.

This is what it would look like:

When that mobile profile is exported from Apple Configurator 2, you will get an unsigned .mobileconfig-file. That will work, but just give grievance during install-time about not being unsigned. If you can live with an extra notice, then just go to next step. If you cannot, get a real code-signing -certificate and sign your profile with that.

Publishing your .mobileconfig from a web server

Your precious .mobileconfig-doesn't just automatically fly into your iOS-device, you need to do some heavy lifting first.

On your favorite web-server, which can be accessed from your iOS-device and you can fully control, place the .mobileconfig-file there as a static resource and make it have content-type application/x-apple-aspen-config.

On Apache:

AddType application/x-apple-aspen-config .mobileconfig

On Nginx:

types {
    application/x-apple-aspen-config mobileconfig;
}

Testing the content-type setting with curl:

# curl --verbose "https:...."
> User-Agent: curl/7.32.0
>
< HTTP/1.1 200 OK
< Content-Type: application/x-apple-aspen-config

Install the profile into your iOS-gadget

That's simple: just whip up Mobile Safari and surf to the URL. Given the correctly set content-type, it will launch profile installer:

During the process you will need to punch in your PIN-code (if you're using one in your device). There are way too many confirmations, if you really, really, for sure want to install that particular profile. The questions are there for a very good reason. A mobile profile can contain a combination of settings that will eventually either leave you powerless to control your own device, or alternatively allow remote control of your very own device. Or both. So, be very careful when installing those mobile profiles!

Finally

Now you have your new root certificate installed and trusted. Go test it!

For those who are very brave:

My recommendation is not to do this. Do not trust me or my published files!

I have published my own .mobileconfig into the web server of this blog. The address for the profile is:
https://blog.hqcodeshop.fi/CAcert/CAcert.org%20root%20CA%20profile.mobileconfig

I'll repeat: That is there for your reference only. Do not trust me for such a security-sensitive file.

Little bit of background about having certificates

A quote from https://www.brightedge.com/blog/http-https-and-seo/:

Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”

So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.

Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and  the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.

What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.

Little bit of background about what certificates do

Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.

I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."

Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.

Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.

Little bit of background about Symantec failing to do certificates

Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:

On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.

"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"

So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:

Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.

And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.

In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.

That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.

What next?

Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.

I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
        Validity
            Not Before: Nov 25 00:00:00 2017 GMT
            Not After : Feb 23 23:59:59 2021 GMT
        Subject: CN=blog.hqcodeshop.fi

That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.

As instructed, I just re-issued the existing certificate. It resulted in:

Now, my certificate traces back to a DigiCert CA root.

That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.

I got and ad from Microsoft about a security summit they were organizing. Since it was virtual, I didn't have to travel anywhere and the agenda looked interesting, I signed up.

Quotes:

Discussion points:

• Security hygiene
  • Run patches to make your stuff up-to-date
  • Control user's access
  • Invest into your security, to make attackers ROI low enough to attack somebody else
• Security is a team sport!
  • Entire industry needs to share and participate
  • Law enforcement globally needs to participate
• Attacks are getting more sophisticated.
  • 90% of cybercrime start from a sophisticated phishing mail
  • When breached, new malware can steal domain admin's credentials and infect secured machines also.
  • Command & control traffic can utilize stolen user credentials and corporate VPN to pass trough firewall.
• Attackers are financially motivated.
  • Ransomware
  • Bitcoin mining
  • Petaya/Notpetaya being an exception, it just caused massive destruction
• Identity is the perimeter to protect
  • Things are in the cloud, there is no perimeter
  • Is the person logging in really who he/she claims to be?
  • Enabling 2-factor authentication is vital

Finally:

A brief history of CAcert.org

For almost two decades, my primary source for non-public facing X.509 certificates has been CAcert.org. They were one of the first ever orgs handing out free-of-charge certificates to anybody who wanted one. Naturally, you had to pass a simple verification to prove that you actually could control the domain you were applying a certificate for. When you did that, you could issue certificates with multiple hostnames or even wildcard certificates. And all that costing nothing!

The obvious problem with CAcert.org always was, that they were not included in any of the major web browsers. Their inclusion list at https://wiki.cacert.org/InclusionStatus is a sad read. It doesn't even have Google Chrome, the most popular browser of current time in the list. The list simply hasn't been updated during the lifetime of Chrome! On a second thought looking it bit closer, the browser inclusion status -list is an accurate statement how CAcert.org is doing today. Not so good.

Wikipedia page https://en.wikipedia.org/wiki/CAcert.org has a brief history. Their root certificate was included in initial versions of Mozilla Firefox. When CA/Browser Forum was formed back in 2005 by some of the certificate business vendors of that time to have a set of rules and policies in place regarding web site certificates and the issuence policies, they kicked pretty much everybody out by default. Commerical vendors made the cut back in, but CAcert.org simply couldn't (or wouldn't) comply with those and withdrew their application for membership. The reson for CAcert.org not being able to act on anything is that the entire org is (and has been for a long time) pretty much dead. All the key persons are simply busy doing something else.

Today, the current status of CAcert.org is, that their certs are not trusted and signed by non-accepted hash algorithms. Over an year ago, there was a blip of activity and they managed to re-sign their root certificate with SHA-256, but to me it looks like they exhausted all the energy on the actual signing and newly signed root certs were never published. I wrote a post about how to actually get your hands on the new root certificate and install that to your machines.

Today, when CA/Browser Forum is mostly controlled by Google and Mozilla, a stalled CAcert.org would not be accepted as a member and at the same time there is huge pressure to start using properly signed and hashed certificates on all web traffic, I've run out of road with CAcert.org. So, for me, it's time to move on!

A brief history of Let's Encrypt

Two years ago, the certificate business had been hit hard. I collected a number of failures in my blog post about What's wrong with HTTPS. Roughly at the same time also Electronic Frontier Foundation (EFF) saw the situation as not acceptable. Businesses wanted serious money for their certs, but were not doing an especially good job about trustworthy business practices. With help of some major players (including Mozilla Foundation, Akamai Technologies, Cisco Systems, etc.) they created a non-profit organization for the sole purpose of issuing free-of-charge certificates to anybody who wanted one called Let's Encrypt.

They managed to pull that off, in a very short period of time, they become the most prominent certificate authority in the Internet. At least their product price is right, €0 for a cert. And you can request and get as many as you want to. There are some rate limits, so you cannot denial-of-service them, but for any practical uses, you can get all your certs from them. For free!

The practical benefit for Let's Encrypt operation is, that number of web server in The Net having HTTPS enabled has been rising. Both EFF and CA/Browser Forum is strongly suggesting, that all HTTP-traffic should be encrypted, aka. HTTPS. But the obvious hurdle in achieving that, is that everybody needs to have a certificate in their web server to enable encryption. Given Let's Encrypt, now everybody can do that! EFF has stated for long time, that having secure communications shouldn't be about money, it should be about your simply wanting to do that. The obvious next move is, that in coming years CAB Forum will announce, that all web traffic MUST be encrypted. However, we're not quite yet there.

Breifly on Let's Encrypt tech

Since they wanted to disrupt the certificate business, they abandoned current operation procedures. Their target is to run the entire request/issue-process fully automated and do that in a secure manner. To achieve that, they created a completely new protocol for Automatic Certificate Management Environment, or ACME. The RFC draft can be seen at https://datatracker.ietf.org/doc/draft-ietf-acme-acme/.

Their chain of trust (taken from https://letsencrypt.org/certificates/) is bit confusing to me:

As the root certificate, they use Digital Signature Trust Co. (red line with Identrust DST Root CA X3). That's something your browser has had for years. So, ultimately they didn't have to add anything. When you request a certificate, it is issued by the intermediate authority Let's Encrypt Authority X3. And as the bottom level is your very own Server Certificate.

However, I don't undertand why there is ISRG Root X1 to double-sign all the intermediates, and signing only their OCSP-data. My computers don't have that root certificate installed. So, what's the point of that?

As a note:
This is the recommened and typical way of setting up your certificate chain, nothing funny about that. For a layman, it will strike as overly complex, but in X.509-world things are done like that for security reasons and being able to "burn" an intermediate CA in a split second and roll forward to a new one without interruptions and need to install anything to your machines.

What the actual connection between Let's Encrypt and Digital Signature Trust Co. (IdenTrust) is unclear to me. If somebody knows, please drop a comment clarifying that.

My beef with Let's Encrypt

Short version: It's run by idiots! So, Let's not.

Long version:

• Tooling is seriously bad.
  • The "official" python-based software won't work on any of my machines. And I don't want to try fixing their shit. I just let those pieces of crap rot.
• To me, Acme Inc. is heavily associated with Wile E Coyote
  • Mr. Coyote never managed to catch the Road Runners. Many times it was because the Acme Inc. manufactured equipment failed to function. https://en.wikipedia.org/wiki/Acme_Corporation
    
• Did I mention about the bad tools?
  • Every single tool I've ever laid my hands on wants to mess up my Apache and/or Nginx configuration.
  • I have a very simple rule about my configurations: DON'T TOUCH THEM! If you want to touch them, ask me first (at which point I can reject the request).
  • There seems to be no feasible way of running those crappy tools without them trying to break my configs first.
• Most 3rd-party written libraries are really bad
  • There are libraries/tools for all imaginable programming languages implementing parts/all of ACME-protocol.
  • Every single one of them are either bad or worse.
• Certificate life-span i 90 days. That's three (3) months!
  • The disruptive concept behind this is, that you need to renew your certs every 60 days (or at max 90 days). For that to happen, you will need to learn automation. Noble thought, that. Not so easy to implement for all possible usages. The good thing is, that if ever achieved, you won't have to suffer from certificates expiring without you knowing about it.
  • As an alternative, you can get a completely free-of-charge SSL certificate from Comodo, a member of Let's Encrypt, which is valid for 90 days, but you have to do it manually using Comodo's web GUI. See: https://ssl.comodo.com/free-ssl-certificate.php if you want one.
  • I won't list those commercial CAs who can issue you a 30 day trial certificate for free here, because the list is too long. So, if you just want a short-lived cert, you have been able to that for a long time.
• They're not able to issue wildcard certificates, yet.
  • This is on the works, so mentioning this is hitting them below the belt. Sorry about that.
  • From their test-API, you can get a wildcard certificate, if you really, really, really need one. It won't be trusted by your browser, but it will be a real wildcard cert.
  • Original release date for ACME v2 API in production was 27th Feb 2018, but for <insert explanation here> they were unable to make their own deadline. New schedule is during Q1/2018. See the Upcoming Features -page for details.

My solution

It's obvious, that I need to ditch the CAcert.org and the only viable one is Let's Encrypt (run by idiots). To make this bitter choice work for me, after evaluating a number of solutions, I found a reasonable/acceptable tool called acme.sh. This tool is written with Bash and it uses curl for the ACME access. The author publishes the entire package in Github, and I have my own fork of that, which doesn't have a line of code even thinking about touching my web server configurations. You can get that at https://github.com/HQJaTu/acme.sh

Since I love Rackspace for their cloud DNS. I even wrote a Rackspace API Cloud DNS -plugin for acme.sh to make my automated certificate renewals work seamlessly. After carefully removing all other options for domain verification, it is 100% obvious, that I will do all of my ACME domain verifications only via DNS. Actually, for wildcard certs, it is the only allowed approach. Also, some of the certificates I'm using are for appliance, which I carefully firewall out of the wild wild web. Those ridiculous web site verification wouldn't work for me anyway.

And for those, who are wondering, Why Rackspace Cloud DNS? The answer is simple: price. They charge for $0/domain. That is unlike most cloud/DNS service providers, who want actual money for their service. With Rackspace you'll get premium GUI, premium API, premium anycast DNS servers with the right price, free-of-charge. You will need to enter a valid credit card when you create the account, but as they state: they won't charge it unless you subscribe to a paid service. I've been running their DNS for years, and they never charged me once. (If they see this blog post, they probably will!)

What I'm anxiously waiting is the ACME v2 API release, which is due any day now. That will allow me to get my precious wildcard certificates using these new scripts.

Now that my chips are in, its just me converting my systems to use the Wile E Coyote stuff for getting/renewing certs. And I will need to add tons of automation with Bash, Perl, Ansible, Saltstack, ... whatever to keep the actual servers running as intened. Most probably, I will post some of my automations in this blog. Stay tuned for those!

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!