Category Archives: Information Security

Security: It’s all about trust!

In the past few days, I had a few discussions and readings that made me think about the importance of the concept of trust in security and in our life more generally speaking.

Think about it. All we do in security management, in training, in penetration testing, in patching or with monitoring is because we don’t trust our employees, our colleagues, our customers, our suppliers or our competitors. That’s why we often have 3 levels of controls, each level controlling the others so we suppose we will always have at least one person who will do the “right” thing. In our line of work, it makes sense.

But how far should we go? When do we start to trust? When do we make this leap of faith in humanity?

I worked with pretty paranoid people (for a reason, not the pathological ones) using their own operating system (Based on reviewed and modified NetBSD source code) on air gap networks. They also had RFID chip in the printer’s paper in order to trigger an alarm if you leave the facility with printed information. Other electromagnetically wiped and physically destroyed (with presses) any hard disk in end-of-life. Some requires 10 months of thorough investigation and background check before letting someone work on their systems. I worked with people having private investigators watching their security guards to ensure they were totally honest (and it wasn’t the case all the time). In the security community, you will easily found people who will not trust any software to handle their very sensitive information as they might always have a backdoor. And it is the same with hardware. And they are right to be suspicious as we found vulnerabilities and backdoors in nearly any system or application. Firmware corrupted by the government of the country manufacturing the processors or motherboards or spyware built-in from the start at the manufacturer’s government request. Routers, operating systems, firewalls, remote access applications, switches, phone equipment, and so on. There is a very long list of known backdoor, Trojan horses, spywares and so on discovered in widely used systems. You can imagine the length of the list of the one we don’t know about (yet).

If we talk about people, it’s even worse. Belgian Secret Services have published a quick card to warn travellers in some specific sensitive industry on how prevent information leakage while being out of the country. The warning is not restricted to the usual suspects (like Korea, Russia, China or USA) but also to our European “friends”. Economic espionage is written in the bylaws of many European country’s intelligence services. According to our States’ Security services, if you belong to the targeted categories of people, the question is not anymore “if” you will be victim of spies but “when”. Humans can be manipulated, blackmailed, bought, threatened, seduced, just pick one. We are no more reliable than the rest.

I know it sounds crazy, even paranoid! Unfortunately it’s just the world as it is.

So, how do we function knowing we can trust nothing and no one?

Obviously, we tend to create redundancies, to multiply the controls and the levels of control. In large organisation you may easily have more than 5 levels of control (Operational control, security, risk management, internal audit, external auditors, compliance, and so on). Even though, we still manage to have incidents. This still doesn’t answer my first question: When do we start to trust?

For me, trusting is part of the risk management process. It also meets the intelligence gathering process of evaluating your information, your sources and how reliable they are. We trust and we verify. We evaluate continuously the level of trust we can grant to our systems and our people. The higher the stakes, the higher our level of paranoia should be. Also, as usual, we must balance between the risk of doing it and the cost of not doing it. If I don’t trust my suppliers, my employees, what will be the cost for my company, my business?

What’s also important is to know that we trust. There is a clear difference between believing without knowing and believing with the consciousness of the fact that we make a leap of faith. The difference resides in the decision. I don’t believe because I do, I believe because I have decided that it is the best choice to make.

Let me take an example: in my car, if I believe that a green light for me means that cars coming from other directions will stop at the red light, without doubting that or even having the conscience it is a belief, I will never pay attention to the other cars. If I understand it is a belief, I can adjust my behaviour and check (monitor, watch) other cars to see if they are compliant with this belief (and obviously hit the brakes if they are not).

On the other hand, I should also give a little trust to my car manufacturer and have confidence in the fact the brakes will stop my car when I hit them. Else, I won’t dare to drive anymore. As always, we need to find the right balance and we need to do it consciously in order to function effectively.

So, question everything and take sound decisions, knowing that you don’t know for sure.

1 Fortune 500 out of 3 hasn’t define SPF for its email communications

Once upon a time you were expecting an important email from a friend or a company you were dealing with. While it was crucial and highly time sensitive, it unfortunately went directly to your spam folder and it took you hours to realize it. You can even be happy you did.

Since the dawn of the internet’s email, spams are a nightmare to deal with on a daily basis. The impact on the overall Internet traffic was so huge that technologies and standards have been developed to specifically prevent this burden. Amongst those, one of the easiest to implement and yet very efficient is called SPF, Sender Policy Framework.
Basically, SPF is a way to inform mail servers on the Internet about the legit servers from which the emails from your Internet domain are supposed to come. For IT guys, it is easy to configure as it is just an additional entry to your DNS records stating the name or IP addresses of the mail servers you are using to send your emails.
I will skip the technical details as you can find all the information you need on Wikipedia (https://en.wikipedia.org/wiki/Sender_Policy_Framework) and as I will soon write another article on the subject to provide a few guidelines on how to mitigate this risk, as this is a risk for your companies.
Put you in an entrepreneur shoes and think about it. Nowadays, emails are one of the most used communication mean between customers and suppliers. If your emails are going into the spam folders even one time out of ten, you might lose customers. As spams are a plague for email services, most companies, and even more ISPs, have implemented strong anti-spam technologies. Amongst these, checking SPF record is likely number one. If you have a Gmail or an Outlook account, they use SPF, DKIM or DMARC (I’ll come back to these standards in the next article) to prevent spam and to ensure their messages are reaching their destination. So we would expect large corporation do the same to ensure their communication reach their goal.
As I discovered that some of our clients (amongst which some large enterprises) forgot to implement SPF, I was wondering how often this happen in a larger sample of large companies. Hence, I decided to write a little Python script to check SPF and DMARC records for the Fortune 500 Internet domains.

SPF usage in Fortune 500 To keep it simple, I fed the program with the 2015’s list of Fortune 500 companies and their website and checked whether there was mail servers defines to receive email and if there was a SPF or DMARC record existing in their DNS. Here are the results:

Out of the 500 companies, I removed 39 from the statistics as there was no email server defined to receive emails. It is likely that these companies (or groups) use other domain names to send and receive external emails. On the 461 remaining companies, 333 (72,27%) have a SPF record in their DNS. Meaning 27,77% do not use it. Amongst the Top 500 companies, with Billions of $ in revenue and huge IT and risk management department, this really doesn’t make sense. Even more when we know the cost of such measure: maximum 1 or 2 hours of work for one person. Finding a better quick-win than this one will be a challenge.

One of the possible explanations might be that large companies have often complex structures with dissolved responsibilities and use heavy risk management and security framework in which such little “details” are often not mentioned as they are not considered as a risk for the sacro-saint Confidentiality, Integrity and Availability triad. While, from my point of view, and I guess you will share it, anything that might prevent the company to achieve its objectives must be considered as a risk, even if it doesn’t fit into the model. Everything must come from the business strategy and its processes. One of the biggest challenges in risk management is to keep the alignment between the business processes, their risks and the technical measures implemented.
Conclusion, if your company hasn’t define its SPF record, you know what you have to do and, on a larger picture, don’t trust the framework and the checklists. They are useful but they aren’t tailored for your business so they will miss some important risks. The best level of security are achieved when there is a good communication between the business and the supporting department and that everyone share the same goal, is empowered and understand how the business is done.

The excel sheet with the results is available here: SPF-survey

Cost effective One-Time Password solution: How to install yubico’s plugin on Freeradius

If you want One Time Password authentication for your website or your VPN, Yubico propose some cost effective solutions with its yubikeys and its related free open source softwares. In this article we will focus on the Yubikey OTP and its use with Yubico’s RLM plugin for freeradius.

In this case, we will assume you will use the Yubico OTP keys originally provided with your yubico token and hence, the Yubicloud OTP validation service. In a future article, we’ll explain how to configure your own validation server and your own Key Storage Module.

As the point is to be cost effective, no need to spend all your money on this solution. The token will cost you about 30 or 40 Euro depending on the features you need and you can install the Freeradius on a Raspbian for a 40€ Raspberry Pi (or on any Debian server).

As Yubico’s website is not really the most user friendly companion to make this happen, here is a verbatim on how to do it.

I assume you have a Debian Wheezy installed and ready and that you are logged in. As I don’t know if you are using sudo or just su, I will put the command lines as if they were issued for a root user:

1st, we need to install freeradius and a few perl libraries

apt-get install freeradius
apt-get install perl
apt-get install perl-modules
apt-get install libanyevent-perl liburi-perl libanyevent-http-perl libuuid-tiny-perl libdigest-hmac-perl libcrypt-cbc-perl libcrypt-Blowfish-perl

Then we need to download and install the Yubico perl client

wget https://github.com/Yubico/yubico-perl-client/archive/master.zip
unzip master.zip 
cd yubico-perl-client-master/
perl Makefile.PL
make
make install

after what we can download and install Yubiko’s RLM

wget https://github.com/Yubico/rlm-yubico/archive/master.zip
unzip master.zip.1 
cd rlm-yubico-master/
make install

When the software is installed, we need to configure radius to use the plugin. Pay attention, there is a typo in Yubico’s instructions (a _ must be replaced by a -)

First edit the perl module coniguration

vi /etc/freeradius/modules/perl

and add the following line:

module = /usr/share/rlm-yubico/rlm_yubico.pl

at the same time you can remove the module= … sample … line.

Then you must edit the default configuration of freeradius

vi /etc/freeradius/sites-available/default

and add “perl” (without quotes) to a line by itself in the “authorize” section. It needs to occur early on, at least before “files” then add “perl” to a line by itself in the “post-auth” section.

Then, finally, you must add the Yubiko’s dictionary

vi /etc/freeradius/dictionary

by adding the following line:

$INCLUDE /usr/share/rlm-yubico/dictionary

Notice the difference between rlm-yubico (here) and rlm_yubico (as mentionned in Yubiko’s instructions)

You just need to restart the freeradius server.

service freeradius restart

OK, the first part is done. We need now to configure it.

Before starting editing configuration files, we need to generate a shared symmetric key for use with the Yubico Web Services. In order to do that, we must go to a Yubiko website  allowing you to generate that key:  https://upgrade.yubico.com/getapikey/

There, we will need to authenticate ourself using our Yubikey One-Time Password and provide our e-mail address as a reference. You type your email address and then click on the OTP field and press the button of your Yubikey. You will automatically receivve a screen with a message similar to this one:

Congratulations! Please find below your client identity and client API key.

Client ID: 12345
Secret key: +azAZx123AZaABCDEFGHaAbcdeZ=

Be sure to protect the secret. If you need to generate more client id/keys for your different applications, please come back.

Note that it may take up until 5 minutes until all validation servers know about your newly generated client.

Pretty easy isn’t it?
First we will edit the RLM configuration file:

vi /etc/yubico/rlm/ykrlm-config.cfg

The file will look like that when you will have edited the bold parts:

#
# Settings for FreeRADIUS authentication of users using YubiKeys.
#

# Length in characters of the public ID part of Yubikeys
#$id_len = 12;

# List of URLs to use for YubiKey OTP validation
# By default rlm_yubico will target the YubiCloud sync pool:
#$verify_urls = [
# "https://api.yubico.com/wsapi/2.0/verify",
# "https://api2.yubico.com/wsapi/2.0/verify",
# "https://api3.yubico.com/wsapi/2.0/verify",
# "https://api4.yubico.com/wsapi/2.0/verify",
# "https://api5.yubico.com/wsapi/2.0/verify",
#];
#
# It can easily be configured to use a different pool, like a server
# running on localhost:
#$verify_urls = [ "http://127.0.0.1/wsapi/2.0/verify" ];

# Client ID and API key for use with the YubiKey validation service.
# For use with the YubiCloud, you can get an API key here:
# https://upgrade.yubico.com/getapikey/
#$client_id = 12345;
#$api_key = "+azAZx123AZaABCDEFGHaAbcdeZ=";

# If set to 1, a user with no YubiKey assigned can authenticate using
# any valid YubiKey OTP, which will then cause that key to be assigned
# to the user.
#$allow_auto_provisioning = 1;

# If set to 1, allows a user to omit the username when logging in with
# an already provisioned YubiKey.
#$allow_userless_login = 0;

# Defines who is required to provide a YubiKey OTP when logging in.
# The available levels are:
# 0 = Permissive. OTPs are not required to authenticate, by anyone.
#
# 1 = Require when provisioned. OTPs are required by all users that
# have a YubiKey assigned to them.
#
# 2 = Always require. OTPs are required by all users. If no YubiKey
# has been assigned, that user cannot log in, unless auto-provisioning
# is enabled.
#
$security_level = 2;

# Sets the location of a file containing username to YubiKey mappings.
# Each line of this file should start with a username, followed by : and
# then a comma separated list of public IDs. Lines starting with # or blank
# lines are ignored.
$mapping_file = "/etc/yubico/rlm/ykmapping";

Notice: you can already see how we can configure the RLM to use a local validation server instead of the Yubicloud servers.

Now, we just have to edit the list of users and map the user with one or more yubikey. This is done by editing /etc/yubico/rlm/ykmapping (as we defined it in the config file).

vi /etc/yubico/rlm/ykmapping

We provide the userid and the public identity of the Yubikey(s) of the user. If a user, like JaneDoe hereafter can use more than one Yubikey, we must separate the public identity of the Yubikey by a , (comma). Pay attention NOT to leave a blank between the : and the public ID in the file.

If you don’t know where to find the public identity of your yubikey, you can find it using:

  • the Yubikey personnalization tool: the Yubikey OTP tab should display a Public Identity field with the value in modhex – you just need to remove the whitespace between the letters)
  • Yubico’s OTP demo website (https://demo.yubico.com/). When trying the Single-Factor authentication, you will get to a “Congratulation” page with a “Technical details” button. If you click on it you will find your identity under the Parameters section, at the line starting with identity=.

Once edited, the file should look like that:

# Maps usernames to YubiKeys.
# Each line should contain a username followed by a :, then followed by a
# comma separated list of YubiKey public IDs.
#
# For example:
#user1:cccccccccccd,ccccccccccce
johndoe:vvefgfhjjrgf
janedoe:vvefgfhjjrgh,vvefgfhjjrgr

Then you might have to edit the Freeradius server’s configuration to allow you client to connect to it and define a shared secret. This is done by editing the client.conf file in /etc/freeradius directory. Just add your client configuration into the file (there is plenty of examples in the file itself). As an example it could be:

client 192.168.0.0/24 {
 secret = RadiusPassword
 shortname = private-network
}

In order to allow us to test the server, we allow the entire subnet to send requests to the Radius server.

By default the Freeradius server will listen to the UDP port 1812. If you want to change that, you might need to edit the radiusd.conf file.

Then you need to configure your user in the freeradius users file and add, for example, a cleartext password for the user:

johndoe            Cleartext-Password := "HisPassword"
janedoe            Cleartext-Password := "HerPassword"

Consequently, johndoe & janedoe will have to type their password before pushing the button on the yubikey to add their OTP in the password field.

Also, depending of the system you will use for authentication, you might need to specify the Radius service type. VPN solution mostly use the Login Service-Type. Consequently, in the users file you will need to specify the type for the users that will use the OTP.

johndoe            Cleartext-Password := "HisPassword"
                   Service-Type = Login-User

Notice: the start of the next line for the user’s definition must be a tabulation.

For johndoe, a password will then start with HisPasswordvvefgfhjjrgf********************** where HisPassword is the password typed by johndoe, vvefgfhjjrgf the Public ID sent has the first part of the OTP when you press the Yubikey’s button then the ************** is the crypted unique 32 characters string generated at that moment by the Yubikey. For more details on what is a Yubikey’s OTP composed of, you can refer to OTP’s explained on Yubico developer’s site.

When it’s done, you need to restart the freeradius server:

service freeradius restart

You can check the server response by configuring your authentication system or using a Radius testing tool (like NTRadPing from Mastersoft – it’s free).

That’s it.