Ransom email scam - How to mass extort bitcoins via spam campaign
Thursday, May 2. 2019
I've been receiving couple of these already:
Hello!
This is important information for you!
Some months ago I hacked your OS and got full access to your account one-of-my-emails@redacted
On day of hack your account one-of-my-emails@redacted has password: m7wgwpr7
So, you can change the password, yes.. Or already changed... But my malware intercepts it every time.
How I made it:
In the software of the router, through which you went online, was a vulnerability. I used it...
If you interested you can read about it: CVE-2019-1663 - a vulnerability in the web-based management interface of the Cisco routers. I just hacked this router and placed my malicious code on it. When you went online, my trojan was installed on the OS of your device.
After that, I made a full backup of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a not big amount of btc to unlock. But I looked at the sites that you regularly visit, and I was shocked by what I saw!!! I'm talk you about sites for adults.
I want to say - you are a BIG pervert. Your fantasy is shifted far away from the normal course!
And I got an idea.... I made a screenshot of the adult sites where you have fun (do you understand what it is about, huh?). After that, I made a screenshot of your joys (using the camera of your device) and glued them together. Turned out amazing! You are so spectacular!
I'm know that you would not like to show these screenshots to your friends, relatives or colleagues.
I think $748 is a very, very small amount for my silence. Besides, I have been spying on you for so long, having spent a lot of time!
Pay ONLY in Bitcoins!
Note: That is only the beginning of long rambling to make me convinced this is for real.
The good thing is, that I finally found my lost password. As stated in the scam mail, it is: m7wgwpr7
Wait a minute! Nobody should post their passwords publicly! No worries, I'll post all of mine. You can find them from https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt As a careful Internet user, I only use passwords from that one million -list.
Also, thank you for informing me about a security flaw allowing remote code execution in my Cisco RV110W Wireless-N VPN Firewall, Cisco RV130W Wireless-N Multifunction VPN Router or Cisco RV215W Wireless-N VPN Router. I don't know exactly which one of those I have. I may need to re-read CVE-2019-1663 Detail again for details.
Good thing you mentioned, that you are capable of intercepting my attempts of changing my account password. I'm too scared to use Internet anywhere else than through my Cisco <whatever the model was> router. I'll never use my cell phone, office network or any public Wi-Fi for Internet access.
Nice job on finding the camera in one of my desktop PCs. I personally haven't found any in them yet!
Also I'm happy to know, that now somebody has backups of all my Windowses, Macs and Linuxes I use on regular basis. Including my NAS, that's nearly 20 terabytes of data! Transferring all that out of my Internet connections without me noticing anything is really a feat. Congrats on that one!
PS. Are you for real! 
I've been receiving couple of these already:
Hello!
This is important information for you!
Some months ago I hacked your OS and got full access to your account one-of-my-emails@redacted
On day of hack your account one-of-my-emails@redacted has password: m7wgwpr7
So, you can change the password, yes.. Or already changed... But my malware intercepts it every time.
How I made it:
In the software of the router, through which you went online, was a vulnerability. I used it...
If you interested you can read about it: CVE-2019-1663 - a vulnerability in the web-based management interface of the Cisco routers. I just hacked this router and placed my malicious code on it. When you went online, my trojan was installed on the OS of your device.
After that, I made a full backup of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a not big amount of btc to unlock. But I looked at the sites that you regularly visit, and I was shocked by what I saw!!! I'm talk you about sites for adults.
I want to say - you are a BIG pervert. Your fantasy is shifted far away from the normal course!
And I got an idea.... I made a screenshot of the adult sites where you have fun (do you understand what it is about, huh?). After that, I made a screenshot of your joys (using the camera of your device) and glued them together. Turned out amazing! You are so spectacular!
I'm know that you would not like to show these screenshots to your friends, relatives or colleagues.
I think $748 is a very, very small amount for my silence. Besides, I have been spying on you for so long, having spent a lot of time!
Pay ONLY in Bitcoins!
Note: That is only the beginning of long rambling to make me convinced this is for real.
The good thing is, that I finally found my lost password. As stated in the scam mail, it is: m7wgwpr7
Wait a minute! Nobody should post their passwords publicly! No worries, I'll post all of mine. You can find them from https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt As a careful Internet user, I only use passwords from that one million -list.
Also, thank you for informing me about a security flaw allowing remote code execution in my Cisco RV110W Wireless-N VPN Firewall, Cisco RV130W Wireless-N Multifunction VPN Router or Cisco RV215W Wireless-N VPN Router. I don't know exactly which one of those I have. I may need to re-read CVE-2019-1663 Detail again for details.
Good thing you mentioned, that you are capable of intercepting my attempts of changing my account password. I'm too scared to use Internet anywhere else than through my Cisco <whatever the model was> router. I'll never use my cell phone, office network or any public Wi-Fi for Internet access.
Nice job on finding the camera in one of my desktop PCs. I personally haven't found any in them yet!
Also I'm happy to know, that now somebody has backups of all my Windowses, Macs and Linuxes I use on regular basis. Including my NAS, that's nearly 20 terabytes of data! Transferring all that out of my Internet connections without me noticing anything is really a feat. Congrats on that one!
PS. Are you for real!
StackExchange flair received
Monday, March 11. 2019
Whoa! I finally hit the long awaited 200 point mark in Stack Overflow. The good part about that is, Stack Exchange starts publishing a public badge they'll call "flair". They do this to make it possible for me to publicly boast about my prowess. To get some public boasting going on, my flair looks like this:
All of you Peeping Toms out there, I'll save you couple keystrokes of googling: My 
public user profile is at https://stackexchange.com/users/1684769/hqjatu
Whoa! I finally hit the long awaited 200 point mark in Stack Overflow. The good part about that is, Stack Exchange starts publishing a public badge they'll call "flair". They do this to make it possible for me to publicly boast about my prowess. To get some public boasting going on, my flair looks like this:
All of you Peeping Toms out there, I'll save you couple keystrokes of googling: My public user profile is at https://stackexchange.com/users/1684769/hqjatu
Facebook security flaw - New accounts created on my email
Thursday, October 18. 2018
Couple days ago 8pm, I got an email from Facebook. Personally, I think face book is a criminal organization and want absolutely nothing to do with the idiots. Given the nature of the email, I started investigating:
Yeah, right. Like I would create an account there. And if I would, I wouldn't use any of my proper emails. Their information gathering from non-users is criminal and they do know pretty much everything there is to know about me. Still, I wouldn't give them anything too easily.
I did confirm the time. I wasn't even using a computer when above mail was received. So, I'm claiming, it wasn't me!
Things started getting really weird, when these arrived:
Somebody from New Jersey, USA had reset the password for this newly created account. How nice of them! 
Also, there was some trouble logging in. Well that can happen, when you're hacking.
Given the option in the mail, I did click the "If you didn't do this, please secure your account". The first thing they want from me is my phone number. Again, they need to steal that information from me, I'm not going to GIVE it to them. Without verified mobile number, face-jerks let me do nothing. I cannot report the security incident. I cannot request closing the account. There is absolutely no options before entering my phone number. Nobody at super-smart face book anticipated things like this to happen. I really love their service design there! 
Just to make sure, I did check my email logins at my service provider. No suspicious activity there. I did reply to security@facebookmail.com regarding this security incident, but I really don't have my hopes up. If somewhere there's a nipple visible or just regular business presentation, then the jerks at FB will censor the material in 5 minutes. When something really serious happens, they don't care. Their only motivator is the stock price. Visible nipples can threaten their revenues, security incidents to so much.
My guess is, that after their last incident (see: Relax, just 30 million Facebook accounts were compromised after all), there is lot of people wanting to crack the site. To me it looks like, somebody is progressing with the attempt and using my mail account at it.
Couple days ago 8pm, I got an email from Facebook. Personally, I think face book is a criminal organization and want absolutely nothing to do with the idiots. Given the nature of the email, I started investigating:
Yeah, right. Like I would create an account there. And if I would, I wouldn't use any of my proper emails. Their information gathering from non-users is criminal and they do know pretty much everything there is to know about me. Still, I wouldn't give them anything too easily.
I did confirm the time. I wasn't even using a computer when above mail was received. So, I'm claiming, it wasn't me!
Things started getting really weird, when these arrived:
Somebody from New Jersey, USA had reset the password for this newly created account. How nice of them!
Also, there was some trouble logging in. Well that can happen, when you're hacking.
Given the option in the mail, I did click the "If you didn't do this, please secure your account". The first thing they want from me is my phone number. Again, they need to steal that information from me, I'm not going to GIVE it to them. Without verified mobile number, face-jerks let me do nothing. I cannot report the security incident. I cannot request closing the account. There is absolutely no options before entering my phone number. Nobody at super-smart face book anticipated things like this to happen. I really love their service design there!
Just to make sure, I did check my email logins at my service provider. No suspicious activity there. I did reply to security@facebookmail.com regarding this security incident, but I really don't have my hopes up. If somewhere there's a nipple visible or just regular business presentation, then the jerks at FB will censor the material in 5 minutes. When something really serious happens, they don't care. Their only motivator is the stock price. Visible nipples can threaten their revenues, security incidents to so much.
My guess is, that after their last incident (see: Relax, just 30 million Facebook accounts were compromised after all), there is lot of people wanting to crack the site. To me it looks like, somebody is progressing with the attempt and using my mail account at it.
DocuSign hacked: Fallout of leaked E-mail addresses
Sunday, September 23. 2018
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.
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.
Automating IPMI 2.0 management Let's Encrypt certificate update
Thursday, July 12. 2018
RFID Mifare Classic "clone"
Saturday, April 21. 2018
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:
- Cloning the tag:
- Information about Mifare Classic encryption key hacking:
- ISO/IEC 14443 Type A generations:
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.
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:
- Cloning the tag:
- Information about Mifare Classic encryption key hacking:
- ISO/IEC 14443 Type A generations:
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.
iPhone Mobile Profile for a new CA root certificate - Case CAcert.org
Friday, April 20. 2018
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.
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.
Replacing Symantec certificates
Monday, March 19. 2018
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.
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.
Microsoft Virtual Security Summit
Wednesday, March 14. 2018
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.
The screenshot has Jim Moeller and Michael Melone from Microsoft and the summit host Josephine Cheng.
Quotes:
Question:
What's worse then being a victim of a cyber crime?
Answer:
Not knowing about it.
- Shawn Anderson, Microsoft
"Security is not a product, it's a technique."
- Michael Melone, Microsoft
"It's kinda like outrunning a bear. I don't have to be the fastest person, I just have to be faster than Mike."
- Jim Moeller, Microsoft, about infosec referring to Michael Melone sitting next to him
"At the end of the day, these types of crimes are borderless"
- Patti Chrzan, Microsoft
Discussion points:
There were a number of professionals speaking in this three hour session. I saw these couple of themes popping up constantly:
- 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:
Was it worth spending 3 hours? Oh yes! There were mandatory commercials for Microsoft products, but getting the update from people who work in the security field daily was definitely valuable. Given my personal interest in the field, lot of the talks were targeted towards non-security professionals. However, the infosec professionals managed to keep the talks interesting enough with their fresh information directly from the trenches.
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:
- Michael Melone, Microsoft
- Jim Moeller, Microsoft, about infosec referring to Michael Melone sitting next to him
- Patti Chrzan, Microsoft
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:
Goodbye CAcert.org - Welcome Let's Encrypt!
Sunday, March 11. 2018
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!
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
- 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!
EBN European Business Number scam - Part 3 - Gorila's findings
Friday, March 2. 2018
Intel CPU bug: Meltdown aftermath, Part 2
Sunday, January 14. 2018
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.
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.
Intel CPU bug: Meltdown aftermath - Investing into popcorn for 2018
Monday, January 8. 2018
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:
- Have a computer, which has a serious exploitable security flaw
- 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.
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:
- Have a computer, which has a serious exploitable security flaw
- 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.
EBN European Business Number scam - Part 2 - Do not pay!
Saturday, December 2. 2017
Book club: The Art of Deception: Controlling the Human Element of Security
Sunday, November 19. 2017
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.
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.
Now, beyond any doubt I know answers to two crucial questions:
1. Who is behind the EBN fraud?
and
2. Why the Debt Recovery business has relocated to Czech Republic?
1. Who is behind the EBN fraud
After short investigation of two debt recovery companies who are sending threatening letters to the victims of EBN fraud I have found out that the man behind the EBN fraud is a notorious fraudster Adrian Wittmer. Wittmer is well known as the CEO of Intercable Verlag AG and was involved internationally in many similar frauds.
He was prosecuted by the Swiss Police and his company in Germany was closed after the Police raid. He has relocated his business into Czech Republic which is more tolerant towards fraudsters.
Adrian Wittmer is a founder of at least five fraudulent companies in Czech Republic; two of them are still active whilst the other three were closed. All companies allegedly have no employees and negligible turnover More information about these companies you may find from public data of the Czech Business Register. (https://www.detail.cz/osoba/adrian-wittmer-varsavska-715-36-praha/Hmp7dwW27XI/).
2. Why the Debt Recovery business has relocated to Czech Republic.
In Germany, as well in the EU, debt recovery is legally regulated and must be carried out according to the law, in accordance to the Regulation (EC) No 1896/2006. This regulation describes payment procedure for claims not contested by the defendant. This regulation simplifies, speeds up and reduces the costs of litigation in cases involving more than one EU country. The problem for DAD/EBN is that procedure procedure applies just to cases where the claim is not contested.
In case of the defendants’ complaint the matter ends up at the court which would judge against DAD in accordance to German Laws and Judgement of the German Supreme court which has rendered EBN fraud impracticable in Germany. Therefore, DAD is keen to settle accounts out of the court, but German legislation opposes any other than the lawful debt recovery.
In the past some attempts have ended by the police investigation and imprisonment for 2,5 years (Mr. Wilk and Mr. Schnell from Rostock, Germany). Therefore, the illegal part of the busies is relocated to Czech Republic which favors fraudsters, or at least, doesn’t persecute them.
Two active companies founded and owned by Adrian Wittmer Credit Business Resolution s.r.o. CCF Credit Collection Factoring s.r.o are now sending threatening letters, representing themselves as acting on behalf of EBN/DAD. In reality, they are doing the second illegal part in the fraud which is punishable by the German laws. Hence DAD/EBN have relocated that part of the busies into Czech Republic.
EBN in Hamburg is just the first stage in the business: harvesting signatures, issuing invoices and is sending payment reminders. They do just the part which is not prosecuted in Germany by the Criminal Police. What they do is bordering on matters punishable by the German laws but remain at the safe side. Therefore, we may conclude that the whole EBN fraud is illegal according to the German laws and presents no treat to those who have returned signed forms to DAD. DO NOT PAY – Just ignore them and enjoy ongoing vacations.