Encrypting SMS messages and phone calls on Android

Much of our daily lives are contained within our smartphones and computers.  Email, text messages, and phone calls all contain bits and pieces of information that, in the wrong hands, could harm our privacy.  Unfortunately many people either don’t understand how vulnerable their data is when sent across the Internet (or another commercial circuit) or just don’t care.  While I don’t have much to say for the crowd in the latter category (can’t fix stupid) I do try to help people in the prior category understand that any network outside of their control is fair game for pilfering and that basic protections need to be taken to protect themselves.  While I’m not going to dig into how data can be intercepted (there are plenty of articles out there on the subject) I would like to talk about how one can use tools to protect their data when using an Android smartphone.

Until recently email was the only easily-encrypted mode of communication.  Most people didn’t have the means of encrypting their phone conversations and certainly not their SMS messages (unless you happen to be using a SME-PED, but those things are terrible in other ways).  Now, Whisper Systems have released two open source programs that allow you to protect your communications.  The first is called “RedPhone”.  This program encrypts your phone conversations and allows you to converse securely.  The second program is called “TextSecure” and encrypts text messages using authenticated, asymmetrical encryption.

I like the way TextSecure manages keys and allows you to verify the user’s key directly so you can establish trust.  RedPhone appears to use the trust in the phone number for authentication.  RedPhone also provides encryption opportunities when the distant party also has RedPhone on their device which is a nice feature that I wish TextSecure also provided.  Both of these programs are very easy to use and need very little configuration.

TextSecure also provides an encrypted container for all your text messages so that your text messages are secure if the attacker has physical access to the device.

And OpenPGP is still a great option for protecting your email communications but that is a topic for later.

Port scanning /0 using insecure embedded devices

Someone sent me a link to the Port scanning /0 using insecure embedded devices article that was recently published.  Describing the Carna Botnet, this project aimed to prove (or disprove) the hypothesis that there were one hundred thousand open systems on the Internet in which to make a botnet.  I choose to use the word “open” and not “vulnerable” because we aren’t talking about systems that have some sort of unpatched bug that allows access.  This researcher only used unsecure telnet sessions to create his botnet.

Because this was for research, no long lasting effects were created by the deployed software but that isn’t to say that other software couldn’t be introduced in a similar manner as was discovered during the experiment.  It is believed that most of these open systems are appliances (printers, network devices, etc) which could yield other interesting developments if the software was malicious.  This is a good read with lots of data provided inside the article.  A good read for anyone interested in information security.

The Security Benefits of RPM Packaging

Reblogged from Red Hat Security:

RPM Package Manager (RPM) was created to deliver software to workstations and servers. Besides being an efficient software delivery mechanism, RPM also provides security features that assist system administrators with managing their software and trusting the code that is going into their infrastructure.

What is an RPM?

RPM is a package management system that bundles software source code or binaries together for easy installation on a computer.

Read more… 906 more words

What Evernote did correctly.

Yesterday I wrote about a little about Evernote being hacked and how it was bad that I could not remove their software from my device.  Today I’d like to commend them for storing my password correctly in the first place.  All too often companies store passwords in plaintext which make it trivial for hackers to use if (and when) they are stolen.  The email I received from Evernote stated:

...were able to gain access to Evernote user information, which includes
usernames, email addresses associated with Evernote accounts and encrypted
passwords. Even though this information was accessed, the passwords stored
by Evernote are protected by one-way encryption. (In technical terms, they
are hashed and salted.)

Perfect!  Hashed passwords are almost impossible to reverse (unless the  hashing algorithm is weak (see my earlier post on the use of SHA-1) and the original password isn’t in a rainbow table making it somewhat easier to figure out what the hash says).  LinkedIn’s attack last year brought to light the dangers of using weak hashing algorithms (as well as social engineering).

In today’s world passwords should be stored using a SHA-2 (or SHA-3 if you can find it) algorithm with a sufficiently large key (like SHA-512).  The larger the key the longer you can expect the passwords to be protected.

When attackers are looking to find the weakest link in the chain in order to gain access to data passwords stored on a system should be the easiest to protect.  Unfortunately not everyone has gotten the message.  Have you verified your hashes today?

The dangers of mandatory software on smartphones

I awoke this morning to find an email from Evernote, the company that has the product of the same name for note taking, saying that they had been hacked and that I should change my password.  T-Mobile installs this software, along with many other pieces of software, on my smartphone by default and does not allow the customer to remove it.  Luckily the attack against this product was not against the individual installations of the software but rather against the parent server where all the information is stored.

Unfortunately having unwanted software installed on phones is a security problem.  The basic rule is that if the software isn’t installed on one’s computer then the software cannot be used as an attack vector.  My first smartphone came loaded with five pieces of software that I could not remove.  The Galaxy S that I purchased last November came with thirty-nine.  And that was just the pieces of software that are visible.  Last year we heard about CarrierIQ being installed on nearly every smartphone in America.  This software had some very scary features that could allow the cellphone carrier, the software owner, or anyone else able to break into the software, access to everything contained within the phone and every message sent and received (including key strokes).

There’s another price to be paid for this mandatory software.  Updates need to be downloaded and installed which take up space on the smartphone and uses up valuable bandwidth.  With cellphone companies complaining about usage of their wireless networks it seems silly that some of this is required by the companies themselves.

So what to do about this problem?  Cellphone companies should stop preventing users from removing software from their phones.  If they want to load up the device with lots of software that they feel the user might like that’s fine but keeping people from removing that software is wrong.  If the companies won’t stop this bad practice on their own then perhaps if they get enough complaints from customers then they will change their practices.  I guess the only other option is rooting our phones or just purchasing them outright.  Still it shouldn’t be so difficult to maintain a secure computing environment.  And with privacy and so much money at stake the problem will only get worse.

Removing dependencies when using yum

A forthcoming article on the Red Hat Security Blog got me to ask the question: is it possible to have yum remove dependencies when uninstalling packages?  The answer is a somewhat surprising “yes”!  The functionality is turned off by default for a good reason but that’s no reason why everyone should have it off.  A little perspective here is probably due…

If a piece of software isn’t installed on your system then it can’t be used as a vector of attack.  That’s a simple thought, really.  If I don’t have Apache, for instance, installed then it cannot be used as a means of gaining unauthorized access to my system.  So when removing a package it would be nice to be able to remove the package’s dependencies as well so that no extra software is left on the system.  In the past I’ve had to go back through logs to see what was actually pulled in to know what I could remove.  Now that I know the switch things will be much easier.

Well, it might not actually be that simple.  Giving software a set of logical rules to use to determine whether or not a piece of software can be removed isn’t that simple.  Yum’s implementation isn’t bullet-proof either.  I give the following example:

$ sudo yum remove cqrlog
Resolving Dependencies
--> Running transaction check
---> Package cqrlog.x86_64 0:1.5.2-2.fc18 will be erased
--> Finished Dependency Resolution
--> Finding unneeded leftover dependencies
---> Marking mysql-server to be removed - no longer needed by cqrlog
---> Marking trustedqsl to be removed - no longer needed by cqrlog
---> Marking mysql to be removed - no longer needed by cqrlog
---> Marking hamlib to be removed - no longer needed by cqrlog
---> Marking perl-DBD-MySQL to be removed - no longer needed by mysql-server
---> Marking wxBase to be removed - no longer needed by trustedqsl
---> Marking tqsllib to be removed - no longer needed by trustedqsl
---> Marking wxGTK to be removed - no longer needed by trustedqsl
Found and removing 8 unneeded dependencies

CQRLog has several dependencies including mysql-server and openssl-devel.  You don’t see openssl-devel being targeted for removal because it’s in use by another package.  But what about mysql-server?  That is a package that could be needed all on it’s own.  Had I actually needed mysql-server and hadn’t been paying attention that package would have been removed and things could have broken on my system.

So using this functionality in yum should come with some caution.  You must be a diligent systems administrator and watch what you are doing instead of just hitting that ‘y’ key when asked if this is what you really want to do.

I actually looked for this functionality a while back and now it is found, surprisingly, right under my nose for a while.  A quick read of the man page for yum.conf shows:

clean_requirements_on_remove When removing packages (by removal,
update or obsoletion) go through each package's dependencies. If
any of them are no longer required by any other package then also
mark them to be removed.  Boolean (1, 0, True, False, yes, no) 
Defaults to False

Adding this switch to the yum.conf file added the functionality immediately.  Testing has proved positive that the functionality works as advertised as well.  I, for one, will be using this feature on all of my systems that I administer as I dislike having packages just laying around needing updates and not doing anything.  Having packages just laying about is a potential security hazard and this should help reduce the amount of “stuff” one has on their system.

Hashing Algorithm: Is your GPG configuration secure?

If your email messages are being signed using SHA-1 you may not be getting the security you think you are.  Attacks on the hashing algorithm have caused much pain to those that use it.  Luckily SHA-2 is available and hopefully we’ll start seeing SHA-3 out in the world soon.

You’ve probably already seen SHA-2 in the wild designated as SHA-224, SHA-256, SHA-384, and SHA-512.  Because of the weaknesses found in SHA-1 it’s important to not use that algorithm any longer.  That means when you generate hashes you shouldn’t use sha1sum but rather one of the SHA-2 tools: sha224sum, sha256sum, sha384sum, or sha512sum.  Depending on the length of time you need to protect the data the strength of the hash will be important.  A larger key will be more secure for a longer period of time than a shorter one.

GNU Privacy Guard (GPG) has a default of using SHA-1, however, unless you manually select another algorithm in your gpg.conf file (usually found in ~/.gnupg).  To use something other than the default you should add the following lines:

personal-cipher-preferences AES256 TWOFISH AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
personal-compress-preferences ZLIB BZIP2 ZIP

These lines establish not only the preferences for which algorithms to use (for cipher, digest (hashing), and compression) but also in what order to use them.  You can determine what algorithms are available to you by asking GPG in the command line:

$ gpg --version
...
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

GPG will show specifically what is supported based on what’s built into the code when the package was built.

Using the proper algorithm is important for maintaining a secure communications environment so do your research and use something  in which you feel comfortable.

Red Hat Secure Development Videos

Reblogged from Red Hat Security:

Red Hat products are used by many organizations in some of the most secure computing environments in the world. We have relationships and collaborations with many U.S. Government agencies, stock exchanges, banks, and health care companies. As a result, the topic of secure coding is discussed both internally and with our partners and customers on a regular basis in an effort to create the needed resources to make secure coding an everyday practice.

Read more… 110 more words

Something that might be of interest to the development community.

Closed-source security solutions

by cthoyes (Flickr) – CC BY-NC-ND

The recent report of someone finding backdoors in Barracuda Networks’ firewall and VPN products didn’t surprise me much.  What else do you expect from a closed-source solution?  I mean really, when are people going to stop trusting black-box solutions?  Security is always a trust issue no matter what aspect you are looking at.  Why would you trust something with your security without knowing exactly what it does and how it works?

Open source solutions are completely different.  You can look inside, see how things work, make changes if you like, and trust the solution works the way you expect it to.  You aren’t trusting the company that is selling it to you but rather you are trusting yourself or your own people.  Why would you want it any other way?

Not a new PGP key

Earlier I announced a new PGP key.  The decision was made based on my inability to correctly revoke certain uids on my key.  I finally figured out my problem and have revoked many of the uids on my key that no longer valid or were no longer being used.  So I hope no one wrote off my old key just yet.  I’ve had it for a while and I kinda like it.  You may want to update it from either my website (see top of the page on this site) or via one of the many keyservers.  Sorry for the noise.