Security, should be a every second/minute thing!

In this blog, I will share some ideals on how you can keep your data secured, by using real life cases that I ran into last year.

Securing data, is something we typically over look in our day to day lives. Sometimes we have serious human flaw, and don’t realize that we are not using secure practices,  & within our engagement over the internet.

Case# 1

How many of us does  shopping &  ordering over a phone line  & pass sensitive information over a media like a fix phone wire, cellular or even worst a  VoIP phone connection?

In the latter, this could easily be intercepted,  & by any man in middle and decoded with ease.

Case# 2

My parents sent me a new bank account  application thru their email. The application was a scanned as a pdf , & within this application  was my, their's   SSN, DOB, & Driver_license information. They had no clue,  that the email system was not secured delivery channel for sensitive information.

Case# 3

A friend of mine had a vm  image that was compromised , and he wanted me to analyze it. He ftp the already compromised vm-image which included sensitive customer information such as; passwords and accounts, etc........

Okay enough examples, in almost all of these examples, we have the means to secure data at rest or in transit. 

#1

The VoIP call would be the most challenging, since we don’t have access & controls over the call paths, nor  from a end-2-end point of view. As a matter of fact, non-VoIP originating calls, could actually be going of VoIP trunks between gateways.

So the same security concerns with  writing down passwords, & account details, applies here. Anybody in the middle of a ip segments, could very well intercept your information from your audio track.

So the next time, you call your bank for support, and they are asking for pin/id/ssn/act/dob information, just remember; “that could be intercept if any part of that call is going over the public internet space”.

No different if the FBI tap your line with a telephone butt set. Unless your making a call with some type of encryption device ( aka in the military it was called a STU phone  or Secured Terminal ) , than any part of your call be capture with ease.

Now how would you know if it was transversing the internet? Will you will never really know.

Having the ability to use  end2end secured RTP is a long way from now, & is broken if you are not terminating to a VoIP caller. You can read more about secure RTP here.

http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol

I personally see public VoIP calls moving to a public-key type encryption  scheme between VoIP callers. Where you  would publish a public key. And any  caller regardless if it's VoIP-2-non-VoIP , or VoIP-2-VoIP, will 1st gather your  public key, and if the call is setup as a "VoIP-2-VoIP", the systems would deploy some type of simple encryption for the callers.  Maybe this would be something we will see in the future.

These two guys  who are my hero btw, (  Snowden and Jullian )   should have taught us one thing; " that you can't trust anybody and even your own government ".  

It's scary to think of what the  CIA  might be doing towards it's our own people. And with them ( CIA )  being busted for their spying practices,  I'm  betting more business will start to take-off within the private sector and for providing simple encryption services for the John Qpublic. 

#2

Take cases #2, there’s numerous methods  that could have secured this data. I personally like using  openssl, so let see how we could have secured  these precious data files using a common  available utility ( openssl )

Openssl support a host of encryption ciphers. You can acquire these by execution of the openssl command with the keyword  of ciphers.

e.g

openssl  ciphers

By picking and using a strong cipher, and then  by applying some basic encryption process to the data file. We  can ensure that the contents are secured. In this next snapshot, I’m using blowfish and securing a simple txt file  that would be attached to a email.

( encrypting a file w/OpenSSl )

For the pass-phrases, you need a string or multiples of words in the passphrase, for it to be secured. The strongest encryption ciphers, but with a weak passphrase, would discredit any security benefits from the strong ciphers.  ( your as strongest as your weakness link ….should come in mind! ). 

A simple method for creating strong pass-phrases that are easy to remember, is to use a sentence from maybe one of your favorite novel, a melody,  biblical quote, or something  that’s personal to you & that only you would know.

e.g

Jack and Jill ran up  the hill

Or

My wife and I first meet at Delaney Pub on  King street 

Or

Greater love has no one than this, that he lay down his life for his friends

Or

Verily, Allah will not change the condition of a people until they change what is in themselves

( All are simple and effective & most important, easy to remember  )

As the content of the data becomes more valuable, you need to choose a stronger passphrase. The above  5 pass-phrases would be fine for maybe a home user, securing his or her data files,  but these are  unacceptable for securing  a military special ops plan, or securing our nuclear bomb codes J. But all of the above, would be easy to remember by the author.

(  I guess someone could torture you into handing out your passphrase, but the strength of these would be acceptable against  most common brute force  password guessing  attacks or guess )

By using some simple manipulation and substitutions,  we could  enhance these;

e.g ( take a reversed  approach )

“Jack and Jill ran up  the hill”

  now becomes  ;

“hill the up ran Jill and Jack”

e.g  ( substitutions )

“J@ck and J!ll r@n up  the h!ll”

e.g ( up and shifted to the right )

Iwfo wjr I9pp 5wj 8- 6u4 u9pp

When using openssl, we should always add a salt, by using the –salt option on the cmd line during the encryption process.

e.g

openssl bf-cbc –in file2.txt –out file2.txt-enc –salt

To understand  what a salt does, see my earlier post on salting a password and the benefits of such.

This script will demonstrate a basic random  salt by using  $RANDOM;

( script )

#!/bin/bash

#

#   md5 password generator and salt example

#

F=100

#

COUNTER=0

while [ $COUNTER -lt $F ] ;

do

  echo " Demo a random salt+passwd using openssl "

  echo ""

  openssl passwd  -1 -salt $RANDOM $1

  echo " Password counter # $COUNTER "

  sleep 1;

   let COUNTER=COUNTER+1

done

#

NOTE: Once we have the data encrypted, we can now use our –d option to decrypted the data & by suppling the  original passphrase, we can now revert the data back to it's original format.

Another option  that would  have been just as good, would have been to deploy  PGP. You can read more about PGP here from one of my earlier blog.
http://socpuppet.blogspot.com/2013/05/a-quick-look-pgp-and-encryption.html

#3

For case #3, the static vm-image, we could also have used  the openssl encryption  for this datafile,  but we could also have relied on the  native  encryption support within the  vm hostOS server.

Vmware and qemu , both offers diskimage encryption. And almost all modern OSes support encrypted folder, volumes or filesystems. And then we have full disk encryption, which would not be applicable here for case #3, but something else to think about.

Qemu qcow2 has supported the basic AES-128 encryption for any qcow2 formatted images for awhile. It’s easy to convert a image for this encryption cipher, as shown below.

Once encrypted, it would require the  password for decryption;

So any  data regardless of  the type, should be reviewed to prevent it from being compromised. This includes virtual diskimages. Data at rest, storage or in-transient should always be reviewed and any risk analyzed.

My motto has always been; " if the file or machine  was lost or compromised, how much do you have at risk "

As we move into 2014, we should see an upturn with  consumer end-points and security services. With so many eyes watching and only god know what they are doing with the information that they are collecting,  it's up to you to take your security into your own hands. 

Security should be no different than your home, you are on the clock 24x7 365days to ensure you use  best & common safety in your adventures over the internet.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   ^  ^  )=

          o

       /     \