[VOIPSEC] On the topic of Vishing

[J. Oquendo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Fri, 14 Jul 2006 02:28:12 -0400 Simon Horne
<s.horne at packetizer.com> wrote:

> Vishing is a major concern for SIP. Without any form of peer-
entity
> (end-to-end caller) authentication and secure call admission
mechanism
> (or the capability to support it) then there appears to be no
real
> method for addressing this incredibly major problem.

Perhaps someone companies should focus on creating a SIP based ACL
of sorts which would follow some already implemented standards (e.g
RFC's 2267).

Corporation = X
User = Y
Authserver = Z

Y (registers VOIP server) to Z using this ACL with checksumming
(MD5 or better) Z returns to Y verification token Y upon attempting
to connect to X verifies X's token with Z and the session is
established.

> As I have mentioned in previous emails that one possible solution
is
> the use of 2 factor authentication, Something I have (a PKI cert
etc)
> and something I know (username/password)

The scenario above would work more than a user/pass combo since
human factors are almost always the issue regarding compromises.
Let's use for example Bank of America's "Sitekey" scenario. Their
so called twofold method of authentication: You enter your
credentials and a picture pops up asking you for your "next" method
of authenticating based on the picture. So what is the answer? Well
based on the types of pictures I've seen them dish out they tend to
be simple, a guitar, a banana, a vase. Let Joe Simple's info become
compromised to an extent, an intruder uses the information gathered
as far as log in (user/pass) and sees a picture of a banana. Well
Joe Simple not knowing any better decides his Sitekey will be (what
else?) banana. Twofold auth based on user input is not that great
of a solution.

> Certainly using end-to-end authentication will definitely help
reduce
> the risk as the caller will have some certainty to whom they are
> calling but it is not a complete answer as the Vishers may
acquire a
> valid digital certificate which makes them appear that they are
> someone who they are not.

A "visher" wouldn't even necessarily need to acquire a valid
certificate. Again, based on experience with users and their
methods of thinking simplistically, a bogus SSL certificate can be
created by an attacker which most people would likely just hit
enter to accept.

$SSLDIR/bin/openssl req -new -x509 -keyout
${SSLDIR}/private/CAkey.pem \
      -out ${SSLDIR}/private/CAcert.pem  -config
/usr/local/ssl/openssl.cnf

Using configuration from /usr/local/ssl/openssl.cnf
Generating a 512 bit private key
writing new private key to '../private/CAkey.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
- -----
You are about to be asked to enter information that will be
incorperated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
- -----
Country Name (2 letter code) [US]:
State or Province Name (full name) [NC]:
Locality Name (eg, city) [North Carolina]:
Organization Name (eg, company) [The Open Group]:
Organizational Unit Name (eg, section) [ETIS]:
Common Name (eg, YOUR name) [sitekey.bankofamerica.com]:
Email Address []:foo at bar.org

A "Visher" can then combine using a bogus cert with the usual http
scam mails to trick the unknowing user into accepting the cert. How
many people actually take the time out to read certificate
information let alone understand it.

> This is where the importance of the second factor comes in. The
Bank
> issues the user with a user and password and this is used to
verify
> the client at the bank so their is no need to enter user/pass or
> credit card information (or in fact depending on the application
there
> so no need for an IVR system at all). Although human conditioning
may
> still be an issue, but proper education will go a long way to
resolve
> a lot of the vishing problems in VoIP.

A problem with your above mentioned scenario is again the
gullability factor with people. So the bank verifies user/pass info
along with some other cert or token but guess what? The victims
machine was compromised and the token or cert was stolen.

H235 or whatever other framework you choose to use, there are
better ways to do things without the user/pass combo. Perhaps
financial industries can find a way to do something `a-la` single
sign on with some RFID based pass generator given to account
holders when they open their accounts.

J. Oquendo
$i=pack(c5,(40*2),sqrt(7600),(unpack(c,Q)-3+1+3+3-
7),oct(104),10,oct(101));'
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkS3kSQACgkQVnroYexO+HI2sgP+Ljjsby23e8D2rgcfCrGhB5VQZlkn
7JZ8XNE/YIb9eae8wzQcM1woVE92aA0ZoyJAYn8ZyaVrcuk5G2dXdmqXkFt4YdaeHvh1
3aKmoGDiHoqGqzk+yXuwzh7M6Z/SmZPOQZhKJqnDw8bpuQva0ZwUcrIWLi07ALSEvykT
ZnGEsFg=
=gIFu
-----END PGP SIGNATURE-----




Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485