Security Is... Issue 2

Occasionally, one happens to find themselves in the situations that look quite unpromising... yet, even having been eaten one always have at least two ways to escape ;).

Security Is...

Our company launches a "Security Is..." series of weekly thematic comic strips. The main goal of the series is dethroning a popular fear that information security is something extremely complex, and showing that that "intricate security stuff" is in fact pretty much close to the basic things in our life that we come across every other day. We also hope that our little effort will help people start "thinking securely", that is essential in today's realities.

We would be thankful to everyone for sharing the pictures with your family, friends and co-workers - let's populate the idea of "living securely" together!

Security versus Usability

I've been watching yet another Air Crash Investigation movie on NG yesterday. The film was dedicated to DC9 crash in Detroit (August 1987). The first thing that impressed me much was that the crash was very similar to MD82 crash in Barajas two years ago (August 2008). In both cases the pilots did not extend flaps and slats for taking off. In both cases an aircraft failed to gain enough lift and crashed in seconds after takeoff.

The second thing I'd like to mention here is a principal one. The system that must have warned the pilots about bad takeoff configuration was turned off. Moreover, it has been turned off far before takeoff, and it has been turned off intentionally. The investigation has shown that the warning system was designed quite badly; it used to fire false "bad takeoff configuration" alarms in irrelevant situations. It was also discovered that it was a "good practice" amongst DC9 pilots to turn that system off just to prevent annoying false alarms. Thus, when the aircraft was accelerating down the runway, there was no advisor to let the pilots know that the aircraft is not ready to take off.

That was obviously a usability issue. The system was too annoying, so most of the pilots decided to turn it off just to save their ears from that zz-zz-zz-zz humming (even though turning it off caused a real risk for their lives).

So what do you want from a user (a skilled one or a dummy -- it doesn't matter) who is forced to scramble through that firewall warnings, antivirus software warnings, SSL certificate verification prompts, phishing or "dangerous site" warnings, ...? All that warnings (and correct answers to them) are vital for the PC to remain secure. However, a user does not want to think about security. All they want is to solve their problems: connect to an office via SSH, check mail at Google, download some new game to play. All that warnings just prevent them from solving their problems effectively; besides (and it is quite important) they will be able to resolve the problems simply by accepting everything asked by the protecting software. "Do you trust this certificate?" - "Sure I do, let me get in faster". "This distribution is not signed by the vendor. Should we run it?" - "WTF, that's a brand new Doom VII, you MUST run it!". And so on.

What I intend to say is that users will react similarly to DC9 pilots until security software stops annoying them. It is silly to ask users myriad of vital security-related questions a day and expect them to answer to each of those questions thoroughly. As a matter of fact, most of home PC security software is more or less perfect. However, a user is the weakest link in the chain and can make castle walls disappear with a single mouse click.

Because of all these, the strategic direction of IT security concepts (and, as a result, security software) is quite clear for me. It's all about usability. The perfect "secure system of the future" does all the security at the background, invisibly to the user. This might seem impossible in today environment (as all the today security depends on the trust relations in the end, and the user is the final instance to define trust), but it is the only way to make the things more or less secure. It is an absolute requirement to exclude the user from being involved into the process of making security-related decisions.

Big Red Brother (and his buddy) are Watching You

What would you say about the software that silently installs another piece of software from third-party vendor to your computer, which, in turn, collects information regarding your computer's security features (the presence and version of firewall, anti-virus software etc.) and requires Internet connection (!) to be available?

The software is called Adobe Flash Player extension for Firefox; the silently installed third-party tool is McAfee Security Scan Plus. That's it -- having installed a minor extension to a browser, you get a system-wide trojan curios piece of software installed to your PC.

Leaving aside the moral and legislative aspects of such scheme (and please don't say it's just business -- similar schemes were neglected even by Russian gangsters in 1990ths), just wish to warn you to be careful with these. Nobody knows what exactly information collects and sends out the installed tool, neither what is the purpose of collecting such information.

Autoinfect

The invention of autorun (and, similarly, autoplay) feature, in the form it exists today, is one of the biggest platform developers' mistake. A feature with doubtful impact, it has become an easy mechanism for malicious software to reproduce itself. Desktops in Internet cafes and copy centers proved to be excellent friendly hubs where viruses and trojans use to spawn.

What is quite beyond my understanding is that at the same time the very most of the flash drives released today do not promote a write protection switch! This forces me to use my good old 128Mb Chinese noname in public places (such as e-cafes or hotels), as neither of my newer ones provides write resisting capabilities.

As raw criticism is not that constructive, I will explain my own point of view on how autorun should have been implemented correctly (if it should have been):
- Never, NEVER runs without prior OS notification (stating the name of the file, the vendor etc.). If invoked under administrator account, OS displays another dialog proposing to run it under guest account.
- No binaries (neither unmanaged nor managed), no scripts. DHTML (runs in default browser), maybe Silverlight or Flash. "Web" security policy.
- Turned off by default.

It is necessary to understand that autorun is the easiest way to run unknown code on the machine. By simply inserting the untrusted (not yours or write-unprotected) flash card or CD into the drive you can stuff your PC with a swarm of parasites. No further actions are needed. Just keep in mind that someone might silently plug his malicious tiny flash into your notebook's USB when you are drinking your martini at the airport. So the best choice in today environment would consist of three basic rules:

I. Turn autorun off and forget about it.

II. Use a USB flash card with write protection switch and disable writing wherever possible. It would be ideal to only enable writing when inserting the card into your computer.

III. Wherever possible, use "passive" approach to file distribution. Ask your friend to copy down the files you need from his computer to his flash disk; disallow writing on that disk before inserting it to your computer. The same rule applies to the reverse process: copy down the files your friend needs to your flash disk and disallow writing before inserting it to your friend's computer. Such approach will help protect your computer from infecting with the viruses living in your friend's computer, and your friend's one with the viruses living in yours.

Following these three simple rules above will decrease the speed of epidemic spread and make your computer (and the computers of your mates) healthier.

The future of IT security

The situation in the field of informational security is very far from the perfection today. The main problem is that it's just too complex, while a lots of people, mostly unprofessional, are forced to deal with it. Not understanding the potential effects and risks completely, they often prefer to ignore non-important or too sophisticated details (from their point of view), rather than to set up the things as they need to be.

As an example, let's recall the security subsystem available in Windows 2000. The OS itself provided a powerful mechanism for access rights management, multi-user features, flexible PKI support etc. However, most of the users of this system preferred to work with Administrator privileges, negating most of the security features provided by the system and making the core of the system open for external intrusions. What's the reason? The proper configuration of security subsystem involved non-trivial manipulations from a user. It was much easier for him to add himself to the administrators group and throw all the problems away. I am glad to see the progress made in this field by Microsoft in subsequent versions of their OS.

That's why it is obvious for me that the main trend in IT security for the middle-term future is directed to simplification of the interfaces of security subsystems. The unrelated people do not have to deal with e.g. certificate management, web site authenticity confirmation (does anybody read the text displayed on that strange popup in the browser?), or choosing between explicit and implicit TLS modes when connecting to their favorite FTP archives. Transparency of the security subsystems is the main goal for the future. The people only need to be confident that the data they store in their PC's are safe, just as they are confident about the safety of their money on a bank account.

Public Key Cryptography for Boy Scouts

Let’s imagine that someone (let’s call her Sophie – actually, we can use any desired name, but I would be pleased to use a name of my favorite actress – hope, she would be too :)) is willing to send you something quite sensitive – let it be an old map of the treasure island where captain Flint has hidden his chest full of golden coins. As a true woman, Sophie wishes to ask you – her brave knight – to sail to that island, fight the dragon and bring the treasure to her (I am not sure if there actually was a dragon, but the girls do like that sort of things, so we imagine that the monster is there :)).

However, there’s one problem: a river stands between you and Sophie. The only way for her to send you a map is to use the services of a boat driven by an old one-legged guy with a parrot on his shoulder, and this guy appears not to be that honest. The boat is quite small for two, so neither she nor you can accompany the map in its transfer across the river.

As you are a smart guy, a real knight, you quickly find a solution. Sophie should take a box with a lock, put a map there, close the lock and send the box to you via the boat. Once the box is here, you’ll open the lock and get the map. A great idea, isn’t it? Well, let’s try. Sophie finds the appropriate box, locks it with a key and calls the boat. But… wait a minute. You need the key to open the lock. But the key is on Sophie’s side, and obviously she cannot use the boat to transfer it to you.

You are sitting on the shore and thinking. You understand that Sophie should be able to close the lock and you should be able to open it, but the key should never be transferred across the river. And suddenly you get it! The solution is really simple. You will take a box with a self-closing lock, similar to the one shown on the picture at the left, and send the box to Sophie with an open lock, leaving the key in your pocket. Once Sophie receives the box, she puts the map there and pushes down the shackle. Now she can freely send the box with that strange guy, as she knows that he can’t open the lock without having a key.

An attentive reader may propose the following solution: let Sophie lock the box with a key and send the box with a boat. When the box arrives to the other side, let she call the boat once again and ask the guy to transfer the key. Well, yes, this solution will work (actually, it even suits one of the core principles of cryptography – never store a key along with encrypted data). However, you will not be able to use the same box or lock again, and who knows how many old maps Sophie is going to find? Besides, this solution is not applicable in the digital world, where an old one-legged guy can always do a copy of whatever he transfers and unlock the box once he gets the key.

The above story describes a method that cryptographers call public key (or asymmetric) encryption. In every public key cryptosystem a key consists of two halves called public key and private key. Public key is publicly available, while a private one should be kept in a safe place by its owner. Everyone can encrypt data with a public key, but only the one who possesses the private key will be able to decrypt it. In our case, the open lock is a public key, and the key in the pocket is a private key.

Let’s consider another situation. You and Sophie wish to send letters to each other across the river, and, as you are really a romantic couple, the number of letters is expected to be quite big. Of course, you can use the above scheme with a box with a self-closing lock. However, there will appear two disadvantages of such a scheme applied to our romantic task. First, you will need two boxes (a first one to transfer letters from Sophie to you and a second one – from you to Sophie). Second, a boat will have to do twice more trips across the river than the actual number of letters transferred (there is an extra “dummy” transfer of an empty open box for each letter). This is not critical if the transfers are free of charge, but I am pretty sure that the guy’s parrot eats plenty of corn and that’s why the transfers are performed on a paid basis.

Now that you are not a greenhorn in public key encryption, a reasonable idea comes to your mind quite fast. You will take a box with a lock that can be both opened and closed with the same key (see the picture at the left), and two identical keys that fit it. Then you will ask Sophie to send you an empty box with an open self-closing lock, exactly the same as you used to transfer the map. Once the box is here, you will put one of the two keys inside, close the lock and send it back to your girlfriend. She will open the box using her key and get the key that you’ve put inside. Now – voila - you have a box with a lock and two keys that fit that lock, one on your side and another on Sophie’s side, and you can start exchanging the letters using this box. A box with a self-closing lock is not needed anymore, so Sophie can put it aside.

The second case is a classic key exchange example. A general key exchange method allows two (or more) parties to set up a shared key by communicating over insecure data channel. A lot of key exchange methods are based on public key cryptosystems. The above case is based on public key encryption scheme; however, underlying encryption algorithm is not a requirement though. In modern cryptography key exchange algorithms serve a very important task of sharing a symmetric cipher key between peers using extraordinary strength provided by the asymmetric algorithms.

To be continued...

Secure File Transfer Protocols

There are two widely used secure file transfer protocols that are confused quite often. The talk is about SFTP and FTPS. Although the purposes (and the names ;)) of the protocols are quite similar, they are rather different and, what is important, incompatible with each other. I will concern the main differences between the protocols in this article.

SFTP (SSH file transfer protocol) runs as a subsystem on top of secure SSH channel. All the traffic is always encrypted, the security is guaranteed by the underlying SSH protocol.

FTPS (FTP over SSL/TLS) is an improved version of classic FTP protocol, where TCP connection is optionally secured with SSL. In all other aspects the protocol is compatible with good old FTP.

What is interesting is that neither "SFTP" nor "FTPS" is an official name of the corresponding protocol. There’s even no “complete” standard for SFTP – all the versions of this protocol are only available as internet-drafts. FTP over SSL is particularly defined in RFC 2228, however, most of existing implementations offer much more features than are defined in that RFC (for instance, “implicit FTP” term was invented by the developers of one of the FTPS products, such a term has been never officially defined). Thus, both protocols are actually standards de facto, but not de jure. This fact causes a lot of (in)compatibility problems between different software implementations.

Let’s shortly consider the differences and the features common for both protocols.

1. Transport

SFTP runs over secure SSH channel. Moreover, one can establish several parallel SFTP connections through a single SSH (and TCP) connection. Moreover, one can additionally run a remote shell through the same SSH channel. Security of FTPS is optionally guaranteed by SSL/TLS protocol. Each FTPS connection requires a separate TCP connection to be established to the same server. Besides, transfer of a file requires a separate TCP connection, called data connection. FTPS works in either active (client opens a listening data port and server connects to it) or passive (vice versa) mode.

2. Security features.

Obviously, security features of the both file transfer protocols rely on security features of the underlying security protocols. Both SSH and SSL provide the following security features: server authentication (mandatory in both protocols), client authentication (optional in SSL, mandatory in SSH), strong key exchange, data encryption and integrity protection. Strengths of the algorithms used in both protocols are approximately the same. However, unlike SSL, which allows only certificate-based peer authentication, SSH provides support for a number of possible client authentication methods, such as password-based, keyboard-interactive and public key-based.

3. File transfer features.

In general, SFTP is more flexible than FTPS. In particular, SFTP provides access to remote files as if they were local (via Open/Read/Write/Close functions), emulating free access to them. Besides, SFTP declares a standardized way for file attributes requests. It is known that FTP does not provide a unified way to request a file list; the developers of FTP clients are forced to implement reading of dozens of different file list formats to make their implementations compatible with as many existing servers as possible. Actually, there’s a reason for it – FTP originally has been designed as human-readable protocol, not machine-readable.

4. Firewall friendliness.

FTP is known to be not a firewall-friendly protocol. This is caused by the necessity of establishing a second connection for data transfer. This fact resulted in invention of different secure/insecure mode switches (such as PROT and CCC commands) and other crutches. As SFTP does not require secondary connections, it does not have problems with proxies and firewalls.

5. Extensibility.

Both protocols can be extended with new commands.

As you see, there are much more reasons for using SFTP rather than FTPS. There are only two features that may put SFTP behind FTPS:
* SSL provides standardized support for X.509 certificate authentication. SSH does not support X.509 certificates natively, making PKI infrastructure hardly used with SFTP.
* FTPS provides independent encryption modes for control and data channels, what might be suitable for logging and monitoring purposes.

If you are interested in more details about the differences between SFTP and FTPS, please see the following article.

Besides FTPS and SFTP, there do exist other, more complex, transfer protocols, such as OFTP. However, due to low popularity and specifics of use of such protocols, comparing them to mainstream FTPS and SFTP protocols is not correct enough. I will concern OFTP and its main features in one of the future posts.

On the significance of authentication

As I said in the very first post, many developers think that it is very easy to make their software applications secure. One should take a software component that implements the necessary security protocol, plug it to the application and have the application robust, reliable and secure. Though such straightforward approach may work for simple applications, it is very dangerous to use it for securing complex systems. Why dangerous? Because it only gives the illusion of security. You think that your system is secure, while it actually isn’t.

Let’s consider TLS. What can you say about it? TLS is a transport-layer protocol that secures TCP data by encrypting it with robust industry-standard algorithms. A malicious person who intercepts network traffic sees just a sequence of meaningless characters and not the original message.

"Encryption" word sounds like a spell for many people. "If my data is encrypted, no one can read it." Thinking this way is a fatal flaw. No one can read it if the key is in safe place.

Besides encryption, TLS offers a pack of other security services that are often ignored. One of them is server authentication.

Basically, to authenticate someone is to ensure that this someone is the person he pretends to be. When I was ten, I authenticated my friend Michael by three consecutive knocks on the door. The bank guard authenticates the officer by comparing his face to the photo on his PhotoID. Your computer authenticates you by prompting you to provide your account name and password.

In TLS, authentication is performed with the use of digital certificates. Each TLS-capable server has an associated certificate which contains information about its owner, such as host name (or IP address), organization name and its geographic location. Certificates are issued by a trusted insitutions called certification authorities (CA). Three widely used certification authorities are Thawte, Verisign and Comodo.

CA is not required to be a worldwide organization with thousands of employees. To be exact, any person who has a computer can become a CA and issue certificates. However, who will trust them? If my friend Michael told about three secret knocks to everyone, would I consider the knocker to be trusted?

How the authentication is performed? Besides the certificate, the server possesses a corresponding entity called a private key (which can be imagined like a very long binary sequence). Certificate and private key are complementary entities that can be used to perform complementary cryptographic operations. Private key can be used for signing data, while the corresponding certificate can be used for validating the correctness of such signatures. Certificate can be used for data encryption, while only the corresponding private key is able to decrypt data encrypted with such a certificate.

It is obvious that unlike the certificate that is publicly available, the private key must be kept in secret by its possessor.

To authenticate himself to the client, the server uses his private key to sign an arbitrary chunk of data provided by the client. The client then uses server’s certificate to validate the correctness of the signature. As nobody else knows is supposed to know the private key of the server, correctness of the signature ensures that you are talking either to a real server or to someone who has stolen his private key. I do not consider the latter here, this case will be discussed in future posts.

TLS also provides support for client authentication. It works exactly in the same way with the only difference that the client signs the data and the server verifies the correctness of his signature using client’s certificate.

The problem with TLS is that a lot of people who use it think that encryption is its primary feature, while authentication is a secondary one. It is absolutely not correct! There’s no sense in locking the safe if the guard opens it for everyone who asks him about it. If your application does not care about server authentication, it is vulnerable to a dozen of different attacks. One of the most common and easy-to-use attacks based on the lack of authentication is server substitution. Someone just creates a fake server in the network that identifies himself as the original server (there’s a million ways to do this, I omit the exact how-to. Just keep in mind that it is much easier than it might appear at first glance). As no authentication is performed, you will never understand that you are talking to the wrong server. What is worse, the illusion of security is preserved. You are using TLS, so you are secure, aren’t you?

The security of the overall system is defined by the security of its weakest component. There’s no sense in locking the door if the window is open.

Why authentication is often ignored by the developers? I think there are three general reasons for this.

First, authentication is not something one can touch. Encryption is an obvious thing. Authentication is not as transparent as encryption. Besides, 8 persons of 10 consider that “security” is equal to “encryption”.

Second, implementing correct authentication procedure is not an easy task. Some developers (and PM’s/CTO’s as well) consider this task too expensive and do not want to spend a lot of time in implementing it correctly. “Everything works fine without it, so why do we have to postpone the release date of our product for two months for the sake of the feature that no one will have a chance to see?”. Was it a long time ago you’ve heard about 10000 credit card number hijacking the last time? It is likely that their system “worked fine” too.

The third one, the lightmost reason, is the [absolutely reasonable] wish of developer to make the software as much user-friendly as possible. Authentication often requires interaction to the user. Sometimes it is necessary to ask user if he trusts the particular web site or application, sometimes another warning should be displayed. Some developers think that this will bother user. Will not the user be bothered by the stolen password database?

Authentication of the remote is absolutely necessary. The most impenetrable door will provide no help if everyone has a key to unlock it. The most progressive encryption algorithm is worth nothing if you are exchanging encrypted data with a wrong person.

The general principle of information security

Implementation of any security-related function in any project should be done according to the following principle: the system is secure if the cost of hacking it is greater than the benefits of the result of the hacking.

The amendment. And the cost of implementing such function for the developer is cheaper than the worst consequences of the disclosure of secured information.

There’s no sense in building a multi-level data protection system if the data being protected is a high scores file of a computer game (unless it’s good old Digger game, of course ;) ). It is unwise to use 56 bit DES keys to protect the personal data of bank customers.

Any protection should be adequate to the data it protects.

Intro

Good evening,

My name is Innokentiy Ivanov, I am the manager of EldoS SecureBlackbox product – a comprehensive library of security-related software components. For six years we helped thousands of our customers all over the world to successfully integrate security features into their software products.

Unfortunately, in our work we faced with quite an unpleasant fact. It turned out that the heads of many companies and separate software projects have a kind of superficial understanding of data protection and information security problems. In particular, they suppose that adding third-party security components is enough to make their product secure. They delegate the task of implementing security features to the ordinary programmers, in the belief that this task is no more complex than any other basic subtask of the project. They are wrong. Integrating security features to a project requires a good understanding of this task and certain level of skills in information security field. The developer responsible for adding security to the project should clearly understand what exactly security problems he has to solve, and which ways of solving them are the optimal ones. If the person responsible for security in your project does not have such skills, you have a chance to get the illusion of security.

The purpose of this blog is the consideration of the most typical mistakes and misconceptions related to integration of security features to software products. I hope it will be useful to the managers of the products containing security modules, as well as to the developers responsible for implementing those modules in robust and safe way.

So, let's start building safe and secure world.