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 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.
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.
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.
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.
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
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.
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
/ \
No comments:
Post a Comment