[Asterisk-Users] SIP security

[trixter aka Bret McDanel]

On Wed, 2006-01-04 at 10:00 +0100, Olle E Johansson wrote:
> Tomislav Parcina wrote:
> > I have * server that has public IP. Some users with their softphones 
> > (and other with hardphones) need to connect to that * server and call 
> > out thrue Zap lines. As far as I know when someone tries to authenticate 
> > to * server using SIP protocol, he sends data in plain text format. 
> > Right? How can I protect * server from snifers?
> > 
> > I would like to use SJphone softphone for above purpose.
> > 
> > 
> 
> All SIp authentications are done with MD5 basic digest, not with plain 
> text auth. Plain text auth was remove from SIP a long time ago.

[long, contains dry math, boring addition follows]

to add to this, given the state of MD5 and its 'security' or lack
thereof, its a bit over simplistic to just say md5 without adding that
its actually 3 md5 hashes...   Precomputing is harder (but not
impossible) because of the way its done.  The nonce makes it a little
harder - although the nonce is known even by an attacker ...

basically its   
AUTH1 = md5(username:sip.proxy.com:password)
AUTH2 = md5(REGISTER:$URI)
final = md5($AUTH1:$NONCE:$AUTH2)

AUTH2 is fairly easy to precompute, AUTH1 would change with each
attempted password.  MD5 has collissions more readily available than
advertised.  A collission is where two strings result in the same hash
ie  md5(string1) == md5(string2).  this means that it is *possible* (but
unlikely under normal circumstances) for someone to guess a 2nd password
that would evaluate to the same AUTH1.  

It would be far more likely that someone would just try to brute force
(rainbow tables are not likely to be helpful in this example) the
password.  MD5 is a fairly fast algorithm, however the fact that it
would take effectivly 2 md5 hashes computed you have slowed them down.
Zombie machines could be used to speed this up, and it is possible that
using MD5 for sip auth it could be brute forced, the probative value of
a single account is not likely to justify such an attack.  A specific
account might, it depends ...

Choosing strong passwords helps in this regards (forces the brute force
algorithm to be really brute force instead of just a dictionary attack).
I would suggest longer passwords, every additional character adds to the
overall strength, and basically makes it take longer to exhaust the
keyspace.  I would also suggest assigned passwords.  With sip you set
and forget, so users dont need to know what their password really is.

If you have 96 characters valid for each position and the password is 8
characters that is 96 to the 8th power, if you goto 14 character
passwords (assuming the auth system supports it) you have 96 to the 14th
power.  A much larger space to attempt to brute force.  If you drop the
valid chars down to [a-z][A-Z][0-9] omiting all the other common chars
on a keyboard at 14 chars you would still be looking at 62^^14 a
daunting number.  A pc should be able to go through all of those
combinations in approx 4,000,000,000,000 years.  An exhaustive search of
that would be impossible, even though statistically over time on
multiple accounts you will do it on average in half that time.  Even
with a million node zombie network it would still take way longer than
the account would be valid for.  

Now if users get to pick passwords that can be cut dramatically becuase
a user sometime is going to use a dictionary based password.  With a
large enough dictionary and enough zombies an account could in theory be
cracked every day.  

HOWEVER this implies that the attacker could *also* sniff the SIP data
to the server.  This may be easier than you think, there are a lot of
colo facilities and NAPs where people colo systems that dont do good
network security simply because it costs money (the routers, switches,
etc cant process as much data because they are busy doing the extra
compares - NAPs generally are worse about this than colo data centers
but YMMV).  

So the fault in how the attacker is getting the data may not even be
yours, but none-the-less they can sniff.  If that happens *and* if they
have a large enough zombie network *and* they care enough to do this
*and* you have weak passwords on your system then there is a potential
problem.  I think it more likely they would attempt to break into the
system that is doing this itself rather than via sniffing SIP auth
messages.

Side note: doesnt the IAX protocol allow an AUTH request to be sent with
no username and will match against all accounts for the supplied
password?  And if no password is given as well it matches against any
user with no password (giving weight to a user named 'guest')?  That
would seem a far more likely attack than sniffing SIP headers.

-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
UK +44 870 340 4605   Germany +49 801 777 555 3402
US +1 360 207 0479 or +1 516 687 5200
FreeWorldDialup: 635378
http://www.sacaug.org/ Sacramento Asterisk Users Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060104/74ba7ca1/attachment.pgp