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.
Sunday, April 4, 2010
Monday, February 22, 2010
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.
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.
Wednesday, April 29, 2009
On unfair methods in IT security
Vladimir Katalov, the CEO of Elcomsoft (a company who mainly specializes on password recovery solutions), has written a note about their participation at InfoSecurity event. I have no intention of re-posting or quoting his message here, so that you had a chance of enjoying the origin.
I have nothing to add to his words as well, except that the inconsistence of "security through obscurity" postulate has been recognized quite long time ago.
I have nothing to add to his words as well, except that the inconsistence of "security through obscurity" postulate has been recognized quite long time ago.
Saturday, March 28, 2009
SBB 7.0 is here
SecureBlackbox 7 is out now - enjoy new exclusive features and improved performance!
SBB 7 introduces extended cryptographic token support, FIPS 140-2 compliance mode and support for elliptic curve algorithms (ECDSA and GOST).
Support for GSS-API interface in SSH components and creation of self-extracting OpenPGP executables is expected in SBB 7.1.
SBB 7 introduces extended cryptographic token support, FIPS 140-2 compliance mode and support for elliptic curve algorithms (ECDSA and GOST).
Support for GSS-API interface in SSH components and creation of self-extracting OpenPGP executables is expected in SBB 7.1.
Monday, March 9, 2009
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...
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...
Saturday, January 24, 2009
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.
Wednesday, January 21, 2009
Another stimulus to write secure applications (taken from the Washington Post):
A data breach last year at Princeton, N.J., payment processor Heartland Payment Systems may have compromised tens of millions of credit and debit card transactions, the company said today.
If accurate, such figures may make the Heartland incident one of the largest data breaches ever reported.
It is not clear at the moment what exactly has caused the breach. The paper talks about some malicious piece of software, however, it says nothing about how had this code got to the payment processing network. In any case, a lack of attention or qualification (hope, the former) of developers and security officers has resulted in serious damage for the Heartland Payment Systems' reputation.
The data stolen includes the digital information encoded onto the magnetic stripe built into the backs of credit and debit cards. Armed with this data, thieves can fashion counterfeit credit cards by imprinting the same stolen information onto fabricated cards.
Subscribe to:
Posts (Atom)