Summary:	ASTERISK-03674: Asterisk security problem: authorized SIP users can fake any callerid!
Reporter:	deti (deti)	Labels:
Date Opened:	2005-03-11 18:04:47.000-0600	Date Closed:	2011-06-07 14:10:30
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Registration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.c.diff
Description:	exploiting asterisk's inability to verify an incoming SIP message from an UA: Once you are registered with asterisk you're credentials have been authenticated and your IP address is kept in a list of registered clients. Now you can invite other parties (this makes you a user in sip.conf terminology) and you can get called (this in turn makes you a peer in sip.conf terminlogy). The problem is now: If you call with an invalid callerid and valid authentication credentials you cannot be verified as an user so asterisk continues to search for a matching peer (see function check_user_full in chan_sip.c). A suitable peer can be found as soon as your IP address is known to asterisk. What now happens is that asterisk allows you to invite (call) another party as authenticated user even if you are just verified as a peer (which should only receive calls). My conclusion: check_user_full sould be fixed to make sure a valid user can be found if SIP methods like invite are processed. ****** ADDITIONAL INFORMATION ****** This is a preliminary fix for the exploit identified in my last postings. By far it would be better to fix the find_user call to look for both, first for an username in the Proxy-Authorization-header and if there is none then look for a From-header. We even should set an environment variable (which can be used for dialplans) to return the auth username.
Comments:	By: () 2005-03-11 18:06:00.000-0600 what are your sip.conf settings? Is autocreatepeer on? By: nick (nick) 2005-03-11 18:44:44.000-0600 NOT major. By: Tilghman Lesher (tilghman) 2005-03-11 23:02:47.000-0600 I fail to see how this is an exploit.  You've said first that the SIP user needs to be authorized.  Once at that point, it is the system administrator's choice whether to allow the user to set their own custom callerid or to hardcode a callerid in sip.conf.  Where is the exploit in this? By: Mark Spencer (markster) 2005-03-11 23:43:15.000-0600 Unfortunately SIP does not have an authentication method which appropriately addresses the differentiation of a user/peer.  Therefore, it is a requirement that peers can actually place calls as well as receive them.  If you don't want them placing them, give them an empty context. By: deti (deti) 2005-03-12 03:49:51.000-0600 autocreatepeer is off and default context in sip.conf is a dead end. Problem: callerid= and accountcode= works ONLY for USERs and not for peers. So all callerids in invites from peers cannot be rewritten. This is no bug? edited on: 03-12-05 04:12 edited on: 03-12-05 04:12 By: Mark Spencer (markster) 2005-03-12 10:44:05.000-0600 accountcode and callerid are already supported for peers (at least in CVS head).  If you want real separation between authentication and callerid, DON'T RUN SIP, use IAX instead. By: Olle Johansson (oej) 2005-03-13 09:21:31.000-0600 Markster: SIP authentication includes a username which is the SIP authentication user name, check the digest header! So SIP actually separates Caller ID (From: ) from account user name, but Asterisk does not follow the standards in this regard. It is on my list of things to solve and I had this partially supported in chan_sip2. So you are wrong, SIP really differentiates between account name (user-id in digest: header) and caller id - even though asterisk does not. ;-) By: Olle Johansson (oej) 2005-03-13 09:21:50.000-0600 Re-closing this, waiting for future patches.