Home » Posts filed under security

DMail And The False Sense Of Security

Email is around  since several decades. Nevertheless, it is still one of the most used form of communication, especially in business. Therefore the security of an email message is really important.

Over the years, different methods have been implemented. Lately also the guys behind Delicious have implemented their solution, starting a new service called DMail. The claim is:

Self-Destructing Email
Finally, sent email has a delete button
At present, the service is in Beta version, and it's free, so I've tried it to understand how it works.

I have to admit it: I was pretty skeptical... and I was right. But first things first.

How It Works

Let's start by saying that it works only on top of GMail (not even Inbox) and only with Google Chrome/Chromium. In fact, by clicking on the button "Try it now!", you are redirected to the extension page in the Chrome Web Store.

Once installed, you can see the DMail logo on the top-right part of the GMail screen. The same logo appear in the compose window near the enable slider and the combo to choose the expiring time.


You can write your email and send it like you normally do, but what happens is that the message is not sent to the recipient but it's stored in a DMail server in a encrypted form (or so they say).

The addressee receives an email with a link to the message that is unencrypted on the fly just for him. When the time expires or if the sender decides to destroy the message, the link will show the following message:


Message Unavailable
This message is no longer available for viewing..
It seems cool, right? Uhm, not so sure...

Security?

Let's see where the pitfalls are. First, the mail with the link to the encrypted message is (obviously) unencrypted and it contains the codes (KEY and CLIENT) that I suppose are used to decode the message. This means that, if the email is transmitted over an insecure connection, the message should be considered compromised.

Moreover, the email can be forwarded - and also from the forwarded email is possible to access the message.

You can argue that once the message has expired, no one is able to see it. This is also what Snapchat promised, right? The countermeasures are quite simple. You can save the page with the message from your web browser or take a screenshot or a photo. And make the destroyed message live forever.

Besides, you must remember that you messages lay on someone else's computer that can be compromised and your data be stolen.

Conclusions

To me, this service is pretty useless. The idea is good but, at present, I don't think the right technology exists to provide what they promise in a really secure way.
, , Friday, July 31, 2015 No comments
Labels: , ,

Cookies And The Law

On June the 2nd, a new Italian law about cookies took effect. Basically it imposes:
  • to notify the user about the usage of so called technical cookies, and
  • to ask the permission to use profiling cookies (and blocking them until this permission is accorded).
For bloggers (like me) whom do not own the platform where their contents are published, this is quite troublesome since I don't think I'm able to stop anything that is delivered by Google (that is the kind provider of this virtual place).

By the way, I think that, if someone is concerned about privacy violations made through cookies, he can simply disable them in his browser. Here there are the instructions for the most common browsers:
By the way, cookies are just one among many ways to track users. Below there is a small (and incomplete) list.

Local Storage

This feature, introduced by HTML5, allows a website to save some data on your PC to be recalled later. If now you are thinking that this is what cookies are for, you are right. There is only one small difference: cookies are meant to be used by the server, while local storage is managed client side only.

But this is not a big protection, since with JavaScript is quite easy to transfer local storage information to the server.

Flash Cookies

Videos, apps and animations based on this old technology are gradually disappearing, however Adobe Flash is still widely used and its cache can be used to store information. So even if regular cookies are deleted, they can be recreated from this cache.

You can protect yourself with this Firefox add on that deletes Flash cookies when you close the browser (I don't know if there is something similar for other browsers).

Images

No, I'm not joking. Images generated on the fly by the server and the usage of the entity tag (ETag) to deal with cache invalidation can be used as a extremely persistent cookie.

The main defense you can adopt against this threat is to always use private mode navigation (or incognito mode) in your browser.

Evercookie

There is also a proof of concept that uses all the above methods and many other in order to create an immortal cookie. More information about evercookie at this link.

Your Browser

Every browser provides some information to the servers it connects to, like the underlying operating system, the screen resolution, the number of installed addons, the system fonts, etc. All these data can be used to create a fingerprint of your browser that is suitable for tracking.

You can learn more in this article on the EFF website.

Conclusions

Blocking regular cookies is just a resolution that doesn't fix the problem of being tracked in our habits. This is a more general problem that a law enforced by a single nation cannot solve.
, , Thursday, June 11, 2015 No comments
Labels: , ,

3 Ways To Open A Lock - Part 3

This is the third and last part of a series (first post, second post).

Simply Asking For The Key

Although in the real life it's unlikely that a thief asks you for the key of your home, in the digital world this is the most common and successful type of attack. The technical name is phishing and, according to Wikipedia,
[It] is the attempt to acquire sensitive information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.
I'm pretty sure that you have received at least one email from a bank that asked you to check the movements of your credit card. In the email there was a link to a fake website very similar to the bank's one. By logging in you simply give your password to a scammer.

The thing that makes possible this kind of attacks is called social engineering and it does its best in the internet era, even if it has been used probably since the dawn of time. It consist in a series of techniques that aims to make the victim perform actions that normally he wouldn't have done.

The fake email from the bank (or from Facebook, etc.) is similar to trawling. But there is also a technique called spear phishing which targets a specific person. To do this, the attacker starts to collect as many information as he can about the victim, included his mother maiden name and the name of his first pet ;-)

Unfortunately, sometimes attacks are a little more direct.


Image from xkcd licensed under a Creative Commons Attribution-NonCommercial 2.5 License.
Thursday, April 02, 2015 No comments
Labels:

3 Ways To Open A Lock - Part 2

In the previous post, I've talked about guessing your password. Now I'm gonna cover another case.

Stealing Your Key

Now you have a super secure password and you feel calm and safe, right? But thieves are in ambush. Whenever you use your password in an app or online site, they can steal it: this is a man-in-the-middle attack.

Man In The Middle Attack

It can be possible if your credentials are transmitted in plain text through a unencrypted connection (for example the WiFi of hotels or airports) but there are some situations where it succeeds even over a secure connection (SSL/TLS).

Of course, your password can also be stolen if the thief can access a website database. You may argue that if someone has the access to a server content, it should not care about passwords: all your data are in his hands. This is not completely true: hackers know that many people use the same password across different services, so, for example, knowing your email password can lead them to access also your bank account. This is why it's a good practice to use a different password for every service.

Nowadays, I don't think any online service is crazy enough to save password in plain text. Simple hashing has been quite common in the past years, until someone discovered that it can be overtaken by hash dictionaries and rainbow tables. For this reason, a bit of salt has been added to plain hashing. Salting, in this situation, means adding few random characters (called "salt") to passwords before hashing. To increase security, salts are stored in a separate database.

In any case, a weak password can easily be discovered, no matter the server security, so the suggestion is always the same: use strong passwords!
Monday, March 23, 2015 No comments
Labels:

The Worst Problems Of IoT

Internet of Things
Security and privacy. Well, this post could have ended here, but since I'm a bit talkative (just a bit), I'll try to argument.

First of all, Internet of Thing

[...] is the network of physical objects or "things" embedded with electronics, software, sensors and connectivity to enable it to achieve greater value and service by exchanging data with the manufacturer, operator and/or other connected devices.
This short description should be enough to make you understand why privacy is a serious issue. If you don't feel the risk, just think that smart TVs send everything you say to a remote data center - and some of them don't even encrypt it.

The security risk needs some more explanations. Since embedded devices are usually not so powerful (mainly for a matter of cost), it's not possible to apply all the best practices needed to ensure a top level of security.

In addition, as new exploits and security flaws come out, those devices should be updated, but the producer may decide to not provide patches for devices considered too old. This is what happens today with many smartphone producers that don't distribute new Android versions for relatively old devices.

Don't get me wrong, I'm sure that IoT can improve our houses and be wealthy for the environment. But, this should not make us forget the other aspects.

Suggested read: An Internet of Things that do what they’re told
, Wednesday, March 18, 2015 No comments
Labels: ,

3 Ways To Open A Lock - Part 1

If someone wants to open your lock, he has three ways:
  • use lockpicking tools;
  • steal your key;
  • ask you for the key.
But, you may say, what does this has to do with computer science? I'm glad you asked. A password in the virtual world is exactly like a key in real life. And this similitude continues also when someone wants to enter your bank account (or inbox, or Google account or...).

Lockpicking

Lockpicking Tools
The virtual equivalent of lockpicking tools is the classic way of guessing the password. There are two main ways to do this: brute-force and dictionary based.

The latter is quite simple. Hackers and crackers have big lists of common passwords and other words ready to use. If this attack is not successful, there is the brute-force.

The dumb version simply composes passwords by evaluating all combinations of uppercase and lowercase letters, numbers, and special characters (hyphen, underscore, percent, etc.). This method it's proven to succeed, soon or later. The issue for an attacker here is the time needed to check all the combinations that can be in the order of (billion) years.

But there is a fastest way. When people creates a password, digits are usually grouped together and at the end of a word. For example it's uncommon to have a password like "8such3fun" while "suchfun83" is more common.

Another pattern often used is to capitalize the first letter of common words (e.g. "SuchFun83") or use numbers to substitute some letters (e.g. "5uchFun83"). Using a combined attack brute-force and dictionary-based is quite easy to guess this kind of password.

If now you are wondering how strong is your password, there are a couple of sites that can answer your question:
  • How Secure Is My Password tells you how long it will take to an attacker to crack your password, considering a combined brute force & dictionary attack
  • The Password Meter is a little less accurate, since it only considers length and characters variability, but it suggests some rules to create really strong passwords
While playing with the above sites (or any other password checker), do not enter your real passwords, because they can be stolen by the website itself or during the transmission (if sent in plain text).
Monday, February 16, 2015 No comments
Labels:

Should We Forget IT Security?

In the last months, a high number of security flaws has been reported. Starting from bugs in the management of SSL/TLS protocol (Apple and GNU), continuing with Heartbleed, Shellshock, BadUSB up to POODLE, just few days ago.

So now you may ask: what the hell is happening here? Why are there so many threats in such a short time? Are today developers less skilled than their predecessors?

Well, I simply think that we are looking at the wrong side. Many of the above bugs are there from years and nobody reported them (even if I think that they have been used by someone for illegal purposes).

But lately, there is a great request for security. The reason is simple: the amount of money that every day flows through internet. This is why the attention to security has grown so dramatically and thus the number of bugs being found.

So, what should we expect from next months? In my opinion, even more security flaws will be disclosed. And this is a really good thing.
Sunday, October 19, 2014 No comments
Labels:

ShellShock: Impact On Average People

In the previous post, I've written about the ShellShock vulnerability in a general way. Now I want to talk about how this vulnerability can impact all the average internet users.

So the question is: what can you do to protect yourself when surfing the web? The same good old things.

Check Your Router

As said in the previous post, there is a remote possibility that your router (if you have one) is vulnerable. To understand if you are at risk, the best thing to do is  is to take a look at the producer website. If you are lucky enough, a patch is already available. In any case, you should try before you trust.

Offline tests:

Online tests (not recommended - it's not a good thing to let someone know that your router can be attacked):

Use An Updated Browser

Since ShellShock vulnerability can be used to inject malicious code in trusted websites, this probably will result on several tries to take advantage of old and new known browser breaches. If you keep your browser always up to date, you'll be less vulnerable. Avoiding Internet Explorer is a good solution too.

Something should be said also for two products that usually act as plugins for the browser: Java and Flash. There are plenty of exploits based on vulnerability of these two products so it's better to disable them by default and allow their execution only if they are really needed.

Use An Updated OS

I know that you feel comfortable with Windows XP but you should know that Microsoft is not providing security patches anymore. This means that every vulnerability being discovered will never be fixed.

[If you feel comfortable with Windows Vista, please contact a doctor <grin />]

Use An Updated Antivirus

Nowadays AVs are smart enough to detect a wide range of malicious web attacks, even unknown ones with their heuristic algorithms.

There are plenty of good free and non-free antivirus out there: pick one and install it. An average AV is better than no AV.

 This suggestion is basically for Windows and Adroid users but Mac addicted should worry too.

Conclusions

As you can see, all the above suggestions give you  more or less the same hint: keep everything up to date. This is because security is a process. This means that there is nothing that can be considered truly attack proof except if it is turned off and with the cable (or the battery) unplugged.
, , , Saturday, October 04, 2014 No comments
Labels: , , ,

ShellShock, What I've Understood

Disclaimer: I'm not a security specialist; if you are running a webserver, please consider asking a qualified technician.

If last week you have been to Mars, maybe you haven't heard about the new security issue named ShellShock (CVE-2014-6271), claimed to be even more dangerous than HeartBleed.

In few words, it's a vulnerability in the Burn Again Shell (bash) in all Unix-derived systems (Linux, BSD and MacOS) [and maybe Windows too] that can be triggered via a remote call to a web server that uses CGIs. The following is a simple method to understand if your system is vulnerable (taken from here):

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"

env X="() { :;} ; echo busted" `which bash` -c "echo completed"

Run these two commands from a shell; if you read "busted", your system is vulnerable.

Obviously, the preferred targets for attacks based on this vulnerability are the webservers directly connected to internet. And this don't mean only those that run large companies websites, but also embedded devices, such as routers and IP cams.

Embedded Systems: Not So Bad

Due to the limited power of the hardware, embedded systems usually don't have the standard bash binary but use the shell functions provided by BusyBox that is not vulnerable.

This is true for many embedded devices but not for all; for this reason, if you own one of those,  I suggest you to verify with the producer or by yourself, if you are skilled enough.

Webservers: Pretty Bad

I'll assume that your system is correctly configured: since this vulnerability does not involve privilege escalation, all the commands being executed by the exploiter will run with the same privileges of the webserver application and its CGIs. Of course, if Apache is running with root permissions, you are in big troubles even if your system is not vulnerable, but this is a different story.

That said, this vulnerability can be tapped in five ways.
  1. Making the server slow or unavailable, for example running busy loops or filling the memory with an infinite series of forks.
  2. Stealing your data (restricted pages on the website and databases).
  3. Deleting all data accessible from webserver and CGIs (webpages and databases): you can mitigate this risk with frequent backups.
  4. Being used for a DOS attack against other sites.
  5. Injecting malicious scripts or redirecting the visitors to malicious sites. This is the worst scenario: with sed or awk it is quite simple to change every HTML page (but also JavaScript files or Python CGIs) to inoculate code that can take advantage of some browser vulnerability - or simply deface your homepage.
To add some more fear, some of the above can be combined to increase the damage.

Conclusions

ShellShock is a vulnerability that should not be underestimated but probably it's not so bad as it has been reported. Many embedded systems, that are more likely to not receive an update, are not affected. And nowadays many technologies other than CGI are used.

Now, if you are asking if there is something that average people can do to mitigate the risk, you'll have to read this post for the answer.
, , , Monday, September 29, 2014 No comments
Labels: , , ,

Has Open Source Failed?

Image taken from here
This week has been pretty embarrassing for GNU/Linux estimators. According to ArsTechnica a bug has been found on the GnuTLS library. Basically the authenticity of SSL/TLS certificates was not granted (a similar issue has been found recently on Apple iOS - I mentioned it here).

This bug is present since 2005 (a century in computer science) and it seems to affect a wide range of devices - not only PCs.

During these days I've read several commentators pointing their fingers against the open source philosophy. Probably they are the same people that exult when an error is found on Wikipedia.

To those, I just want to remind that, for example, inside Windows XP Professional there are still 44 unpatched vulnerabilities and a couple of them are present since 2003 (two centuries in computer science).

What we can say is that software - every software - has bugs (by design, let me say). What makes the difference is the speed in fixing them once they have been discovered. And in this case the open source community has been very fast.

So, if you are asking me if open source is perfect, I have to say no. But, in my opinion, is better than closed source under many points of view. And bug fixing is one of them.
, , , Saturday, March 08, 2014 No comments
Labels: , , ,

Indentation Matters

Last week my colleague +Daniele Veneroni told me: "You chose the wrong timing to write a post about the usefulness of goto. Have you heard what happened to Apple?" To make it short, there was a vulnerability into the validation of SSL/TLS connections in iOS devices. According to Sophos, this is the broken code:

. . .
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
    goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;  /* MISTAKE! THIS LINE SHOULD NOT BE HERE */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

err = sslRawVerify(...);
. . .

The error is probably a result of a bad copy 'n' paste, not the goto itself. Nonetheless if that line would have been correctly positioned (i.e. at the same level of the if statements), it would be immediately clear to everyone looking the code that something was wrong.

This event gives me the opportunity to talk about something that I consider very important when writing code: the coding style.

Matters of Style

Believe me, I've seen code less readable than this!
When there are at least two people working on the same code, the first thing that can cause problems is the coding style. Tabs versus white spaces, bracket placing, naming style, case, and, over all, indentation.

What is the purpose of the indentation? To make more readable the code. And why you should use descriptive names for variables and functions? For the same reason: readability. Your code should not only be executed by a processor, but also understood by other programmers.

And other programmers are full of laziness, impatience and hubris just like you. So they don't want to read every single row of your code just to add a trivial feature. This is true both in the open and the closed source worlds because if your code is not easy to maintain, it will be abandoned or someone will decide that is cheaper to rewrite it.

My Choices

I have to admit it. Often in the past I've used two-characters indentation and CamelCase names for functions and variables (you know, once I was also known as Mr Pascal).

But now those days are over. What I've decided to do some years ago is to use a different style for every programming language: so, for example, for Python I use PEP8. For C there are at least ten different styles, each one with his supporters (or should I call them ultras?). After a short research I decided for the Linux Kernel coding style.

If you read the document, you'll find that every choice is there for a good reason and the main guideline is always the readability. Because, as Guido Van Rossum said:

code is read much more often than it is written
, , , , , Monday, March 03, 2014 No comments
Labels: , , , , ,