[VOIPSEC] On the topic of Vishing

[Simon Horne]

At 08:42 PM 14/07/2006, you wrote:
>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.

ACL is not terribly scalable. Email has adopted DKIM (which is globally 
scalable but not end to end) where domains identify themselves by way of 
PKI signatures which are verified against a public key which can be 
downloaded via a URL. With the real time nature of VoIP and to avoid the 
possible delays of downloading these certificates there should be a way to 
include these certificates on the wire for quick processing. This is 
something we are looking at implementing in H.323 (the capability is 
already there). Again, regardless, there is no way the caller can prove (to 
a reasonable extent) they are actually talking to the bank. This is were 
end-to-end authentication is important.


> > 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.

Totally agree. Perhaps, like my local bank has done, because they are sick 
of these phishing scams, started issuing a SecurID style tokens with a 
random number generator, when you go to the bank website you have to enter 
the number on the device. Certainly you can manually enter this number 
through an IVR system but the capability exists to send these type of 
information (from smart cards, RFID, etc) in a call setup message today 
without having to prompt the user but you need to have a protocol that 
support these types of security mechanisms.

> > 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.

You've missed the point completely. Yes you can generate a PKI cert quite 
simply, heck anyone can do that but you need a verified (signed) 
certificate issued by a trusted third party for it to work. Now that is a 
bit more difficult to do but not impossible. The problem with HTTPS:// and 
most web browsers is that you can accept certificates regardless of whether 
they are from trusted source (verisign etc) or not making them next to 
useless as a security enforcement method. For VoIP it doesn't have to be 
like that. You can issue CA certificates to endpoints/UAs (whether manually 
or via a VoIP message) which can be use to authenticate certificates 
presented by the other calling party.


> > 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.

Absolutely, User/pass may not be an ideal solution however unless you have 
a VoIP system that has a generic security framework (like H.235) to support 
a range of different authentication mechanisms (certificates, user/pass, 
securID code, RFID etc) then Phishing is going to be as much (if not more) 
of a problem with VoIP as it is with email.

Simon