Should you be parnoid with a voice response systems? ( hell yes! )

From a security standpoint, the telephone usage  while dialing up to a bank customer service center  is greatly overlooked.

The common practice of entering digits while dialing or access your account  with a bank by phone system, or voicemail, insurance company, etc...... should not be taken lightly.

Most of today modern systems have a IVR/IVRS ( Interactive Voice Response System  ) systems that "improves" you access to account information , and eliminates human interaction , but put's your  at risk. We use these in a regular duty/roles/function.

e.g ( a typical  IVR menu.. I bold some sensitive details )

1. dial # 1 for ingles or #2 for spanish
2. dial your  4 digit pin
3. dial the last 4 of your SSN
4. dial your DoB
5. dial 1 to get your balance
6. dial 2 to speaker to a customer service representative
7. dial 9 or hangup to complete this call 
8. or dial # to return to the start of the menu

This is good for the banks/hospitals/insurance companies/onlineshopping outlets, but the end-user needs to be aware that this is not secure.   Even the banks reps have you provide even more account details, by requesting more information about you. This place more sensitive data out in the air and over the call paths.

e.g ( a typical dialog of an unsecured transmissions to bank XYZ )

Hello , I'm Jane at Bank Blah Blah your today's customer-service representative
I need you to tell me your security code or password
can you provide your mother maiden name
Can you confirm your zipcode that's on-file
Can you give me the account digits
Thank you , now how can I help you ?

Yes, we provide all of the above and don't bat an eye & never suspect that evil joe is capturing your transmission.

My parents for example, hate using the phone and internet  for conducting ANY business & they have valid reasons. They are also old and afraid of technology, which is another story.

1st the digits you transfer to the IVRs are  typically in the media path and can be capture and decoded with ease. So a hacker ( unethical ) could gather your information. This means any of the following;

• SSN
• DOB
• ACT#
• PIN
• CreditCard #
• CVV code
• zipcode 
• etc.....

Yes with analog trunk or  VoIP trunk systems, the DTMF tones can easily be captured. So think twice when you dial your bank up and the potential harm that could come about if a MiTM captures your details.

The same holds true for a voicemail system. Entering your account details on a call to a IVR is about as secure as you " saying it our loud  & in the open on a  business  NYC street corner in uptown Manhattan " ;)

NOTE: When I was younger and dumb, we regularly capture DTMF tones from various VoiceMail access systems  when I was communication specialist in the military. And then we would hack a person VoiceMail or delete messages for fun ;) 

We would also intercept random numbers and calls to ensure COMSEC was being used.






http://en.wikipedia.org/wiki/Communications_security 
"loose lips sinks  ships !"

Nobody in a military outfit would discuss a classified pending military operation over an unsecured phone or radio, but to a lesser degree, we pass out our personnel details over a phone without thinking twice.

NOTE: Most of the banks, provide a calling_party number lookups to see if the number is present in the personnel account, but this with someone gathering the last 4 of the SSN , DOB, ACT#, etc...... but your still exposing critical information.

The best system would be fully-enclosed and 100% secured from end-2-end , but the TDM and SIP trunks to include the gateways would be un-secured & if no encryption was provided end-2-end. Also you have NO IDEAL if encryption is/was  used for any paths or legs of that call.

The diagram below will show you a typical multi-call path and the risk at each leg is very high. You call might terminate thru 3 or more carriers or nodes.

e.g

So any path between you and the IVR is at risk of tapping. The ole hollywood movies with the guy on the telephone pole wiretapping a call is now made even simpler with VoIP.

Now for the bad news, we have no way to know the  security that used on call unless you had  your own STU or similar device on the call  & at both ends of the call ( caller and called parties )

note: Read about a STU here; http://en.wikipedia.org/wiki/STU-III

So we know that's not going to happen, so you are S%#$T our of luck.

Even a facsimile transmission can be capture and decode to reveal  the document details. So that application form you fill out and fax in with your details, can be decode with ease. This means any of the following;

 DOB
 SSN
 address
 place of employment
 etc......

Your at risk & the sad thing, the Public Telephone Network is probably bigger than the Internet.

A few common voip security tools/method

for cpature dialed numbers using DTMF :  tshark -R 'rtpevent'
( https://www.wireshark.org/ )

faxscan or fax decoder for capturing T.38 modem transmission ( http://www.vocal.com/specialties/t-38-image-extraction-library/ )

faxTap ( http://www.netgencommunications.com/ )

wireshark/tshark for RTP streams analysis
( https://www.wireshark.org/ )
 
poing media grabber


In conclusions most enterprise site2site voip systems have much ease with securing calls end-2-end due to the nature of less devices out of control of the operator. You have less devices and can actually encrypted the path end-2-end ( phone-2-phone or between VoiceGateways )

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- socpuppets ---dot---com

    ^    ^
=( &  ! )=
      @
      /   \

Juniper Proposal sets IKE/IPSEC

When building VPNs on SRX platforms, you need to be aware of the built-in proposal sets. Juniper has 3 canned proposal-sets  known simply as;

basic
standard
compatible

basic offers DES with  DH-group1 and SHA1 or MD5 authentication

NOTE: I never recommend the above for a VPN

standard offers  slightly better and more proposals such as 3DES DH-group2 with sha1 or AES128 DHGRP2 and SHA1

NOTE: This is the minimum accept proposals that should be used IMHO

compatible offers  a few more options
                       3DES with DH-group2 SHA1
                       3DES with DH-group2 MD5
                        DES DH-group2 SHA1
                        DES DH-group2 md5


You need to be aware that the difference proposal sets, and the availability within each when using ipsec-vpn


Ideally, you should craft your own proposal and define these for your ike and ipsec proposals

set security ike proposal AES128-SHA128-DH5 authentication-method pre-shared-keys
set security ike proposal AES128-SHA128-DH5 dh-group group5
set security ike proposal AES128-SHA128-DH5 authentication-algorithm sha-128
set security ike proposal AES128-SHA128-DH5 encryption-algorithm aes-128-cbc
set security ike proposal AES128-SHA128-DH5 lifetime-seconds 28800
~                                                                     

 set security ike proposal AES192-SHA192-DH5 authentication-method pre-shared-keys
set security ike proposal AES192-SHA192-DH5 dh-group group5
set security ike proposal AES192-SHA192-DH5 authentication-algorithm sha-192
set security ike proposal AES192-SHA192-DH5 encryption-algorithm aes-192-cbc
set security ike proposal AES192-SHA192-DH5 lifetime-seconds 28800


and

set security ipsec proposal ESP-AES128-SHA256 protocol esp
set security ipsec proposal ESP-AES128-SHA256 authentication-algorithm hmac-SHA256-128
set security ipsec proposal ESP-AES128-SHA256 encryption-algorithm aes-128-cbc
set security ipsec proposal ESP-AES128-SHA256 lifetime-seconds 3600
~
set security ipsec proposal ESP-AES256-SHA192protocol esp
set security ipsec proposal ESP-AES256-SHA192 authentication-algorithm hmac-SHA256-192
set security ipsec proposal ESP-AES256-SHA192 encryption-algorithm aes-192-cbc
set security ipsec proposal ESP-AES256-SHA192 lifetime-seconds 3600


For DF-groups, you should strive for  DH-group14 or  higher & if the far-end peer supports it.

Try to avoid   dh-group 1 and 2 . Even dh-group5 should not be used but that's the minimum accept group  to avoid interoperability. Almost all security vpn devices supports dh-group5. For PFS, enable it when you can and if you need 100% security. PFS will ensure all new key-generation is not done from previous phase keys.

Even if some one knew your PSK for example, they could not break your encryption without brute-force and that would take million of years to do.

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- socpuppets ---dot---com

    ^    ^
=( #  # )=
      @
      /   \

Using ssh keys for signing data files by socpuppets

With PGP, we can  sign files for identification & authenticity.

This involves sharing the PGP public-key thru a keyserver or distributing the key via some other method ( email, http website, busines card,etc...). It also requires you to build a PGP keypair and manage the keypair.

Most systems  like a unix server,  has ssh already enabled or in use. And most of these same systems have users with a keypair created ( RSA | DSA ) or they can easily create ssh keys.

So why not just use  ssh?

Will I will show you just how you can sign/verify a file, by just using our ssh  keys


1st

You need to convert "your public key" into a "PEM" format. The best means for doing this, is by using the openssl utility.

(  the user that will  signed the data  )

openssl rsa -pubout -in ~kfelix/.ssh/id_rsa  -outform pem > ~kfelix/.ssh/rsa_pub.pem 

2nd
You can now take the newly made pem-format file,  copy and send it to others systems or users. It's public so you don't have to worry about securing the file.

You could send it via  email, ftp, or even via scp. In some case you could build a HTTP server within your enterprise system and have users update and publish keys locally ( this would be like a goto  key-server & self-managed ;) )

I 've built system like this in past lives  & when ever one needs to verify datafile signatures, they just  launch a  browser at the http keyserver and grab the sender public-key. You could easily modify your company directory in a sharepoint and allow for a user to publish his/her public-ssh-key into the sharepoint

3rd

Now we craft a "pem" format file against  our "private-key" we keep this key 100% secure & private. It's the private-key,  so  let's protect it.

(  the user that will  signed the data  )

openssl rsa -in ~~kfelix/.ssh/id_rsa -outform pem > rsa_priv.pem

Okay now just how all of this works? I will show you.

The sender will use his private-key to sign the date-file and then distribute the key, signature and data-file to the recipient(s).

Now we will  sign our datafile named file and create a signature named file.sign

openssl dgst -sha1 -sign ~kfelix/.ssh/rsa_priv.pem -keyform PEM  file > file.sign

And  the recipient will reverse the steps, but this time by using the provided public-key against the data file. He or She will now know if the datafile is authenticated.

openssl dgst -sha1 -verify ./rsa_pub.pem -keyform PEM  -signature file.sign file


NOTE: This requires the  recipient to know the  "previous" hashing format ( sha1 digest )   that was used earlier by the sender.  If  the public provided-key (pem formatted ) was tampered or the file was tampered with. The  verification process will fail. Likewise , if the wrong digest was used on the verification end, it will fail.

Keypoints for taking away

• if the  public-key was tampered with or modified in transit, the  signature verification will fail ( common errors displayed  unable to load key file   | Verification Failure )

• using the ssh-public-key allows for quick signature verification with out having to craft a set of  keys via PGP & per users

• This methods does not rely on public-keyserver,  and is great for systems that are closed from  the internet  such a fully contained private network

• Users understanding of PGP ( GNU gpg ) is not require, but it does require one to craft a PEM format key. The same PEM format key can be used for all other ssh operations

NOTE: If the keypair was crafted as a DSA key, just change the "rsa" to "dsa", in any of the examples above


 Yeap, that's how easy it could be with using ssh keypairs for signing datafiles

Here's a few screenshots from my server SOC1 and a enduser.

( converting a key to PEM format )

( signing data )  

( verification )  

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- socpuppets ---dot---com

    ^    ^
=( #  # )=
      @
      /   \

USBOTG a quick view of options

The universal  USB adapter that plugs into a USB mini type B plug offers you some great advantages. It's known as a USBOTG ( USB On-The-Go )

You can attach a common  USB thumb-drives for quick access or backup for files. Great if your in a pinch, and need to move files between a Laptop and Tablet and you have no internet or bluetooth is  just plain to slow.

Remember that the filesystem-type must be supported in the Android OS kermel ( linux ). So don't try to  mount a  Apple or Encrypt FS to your Andorid tablet.

You can use the General > Storage tab for monitoring the device size and to validate androids see the  unit

or just use cli to see the mount point

Another option, if your bluetooth key board is not charged-up or you have no bluetooth keyboard. You can attach a  USB keyboard with easy to  your tablet. Here's my  "rollup" style keyboard attach to a Galaxy Pro.

NOTE: This option is much cheaper than most Bluetooth keyboards imho ( USBOTG +  USB-keyboard ). You could buy this setup for under 35.00 usd.


You can even use your USB-2-Serial adapter for configuring a cisco, juniper, fortinet or other  devices that  has serial access. A few serial tool apps are available in the google playstore YMMV on what ones work on your Android device

Lastly, a generic USB-ethernet adapters should work if the kernel recognize the brand. So a tablet could easily be able to  connect to a LAN for wired access. This also open up the possibilities for forensic gathering, hacking,  vulnerability testing from a tablet & to both wired and wireless devices.
https://www.blackhat.com/us-14/training/android-application-hacking-pentesting-mobile-apps.html

note: I was not as successful with using  most Samsung Phones and the usb2otg on androidOS version less than 4.4.2 and specially with the keyboard. Also don't try to hook up a ext-cdrom or ext-hdd to your Android Devices unless these devices use an "externally" power source.

Also my Nexus10 tablet fail to see anything on the USBOTG, which I found very strange and disappointing


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  +  - )=
       o 
      /  \

Installing a threat profile cisco ASA IPS

In this post we will look at attaching a predefined threat profile for the cisco IPS. 1st let's look a sensor with the default "none" threat profile.

Next here's the list of  threat-profile that are shown via the list threat-profile cmd

The defaults of Data_Center , Edge,  SCADA & Web_Applications exists.

So we will apply the  Edge to our sensor and recheck that the configuration was applied.

NOTE: as you can see, the  virtual sensor vs0 has the defined threat profile  "Edge" attached to the signature definition "sig0"


And lastly, if you have a standby ASA, don't forget to make the same changes  on this unit.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  +  - )=
       o 
      /  \

My SixXS ipv6 tunnel setup attempts

SixXS  has been a major player within the  IPv6 tunneling creation, with over 40+ pops worldwide accept africa, they have one the biggest tunnel-broker service outside of  Hurricane Electric.  You can find more here;   https://www.sixxs.net/


When you 1st go to the account creation page you have to fill out a  multi-line  account request to include  your ful-name EUI format phone #, address etc... Most of this is populated in their WHOIS server that they manage.

Once you get your account acceptance email, than you will have to wait approx 1 -2 days for approval.

and;

note: The one negative about  SixXS, if you loose your "usernanme" you can not conduct a simple  password recovery. You need to supply the  username and  email-address for recovery. HE does not have the  limitation btw.


After approval, you can select a tunnel and pop for servicing the tunnel.  The tunnel pop selection should be based on distance to the PoP from your service router or firewall. But you should click on the pop to see and get details of the pop. Look at the establishment date, number or prefix and type of prefixes served from that pop.

( example chi equinix location )

note: I circled key items to review above


After, you have selected the pop and have  supplied your tunnel information, than you can proceed with  configuration of your end device.

As of today's date, I still have not been successful in obtaining a Ipv6 tunnel via SixXS. And y 1st attempt was done like 2 months ago.

Stay tune.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  +  - )=
       o 
      /  \

A look at the Fortinet beta program

Fortinet has been offering  a beta program for development of their FortiOS software. This beta program is suppose to help identify bugs and features improvements prior to introduction of new features and functions in a major code release.

To Participate you must have a fortinet firewall that's under contract as listed by their agreement cause;

Anybody can  submit  a request  and entrance into the beta program or forward arequest to another user. The beta team will review to see if they meet the criteria under their acceptance cause.

Once you have been accepted, you can now download code for  your registered devices.

It's advise able not to install beta-code on production critical devices.


Beta code is just that Beta. So expect mis-behavior and performance impacts. So YMMV and use at your risk surely applies here. If your network become unstable or breaks, don't blame fortinet.


Once you have download the code and upgraded a unit, your system will state the build as being beta.

NOTE: The code will not expire nor have any limitations

To be a good beta tester , you should develop a plan to record events and create  a diary  of events and issues that you find. By doing so and contacting the beta admins and forums, you can now gain information and provide your findings to the team & beta community.

It's crucial to complain to the team on both  positive or negative findings so they can be made aware of issues that you find.

http://support.fortinet.com/forum/

Without the feedback, they will not know of any issues that you may have found. I don't know of any other  security provider that offers a beta release and welcomes a selected group of testers invited to the general public.


Ken Felix
Freelance Network/Security Engineer
kfelix -<a-t>  socpuppets-<d-o-t>- com