Asterisk security (sec-agree RFC 3329) SIP authentication patch

I’m in a project related to VoIP security and last weeks I was working in the Asterisk PBX server, particularly in the SIP channel.

At these phase of the project, we are working with Nokia phones. Nokia has a SIP client with an “Use security” option. I faced the problem that when I turn on that option, I can’t initiate the SIP session, or authenticate my user on the Asterisk server. The server responds with a “401 Unauthorized” that doesn’t helps too much to understand what’s the problem.

So I turned on the debugging of the SIP headers in Asterisk and I realized that with the “Use security: yes” option, the Nokia client sends a header that Asterisk doesn’t know in the SIP REGISTER packet,  “Require: sec-agree”. Researching about that header I found that it was described in the RFC 3329 (Security Mechanism Agreement for the Session Initiation Protocol), a proposed standard.

For the tests I used two Nokia phones, the Nokia N85 and the Nokia C6 over a 3G network and Asterisk 1.8.3.

Next is the SIP debugging showing the problem.


REGISTER sip:186.49.81.197:5060;transport=UDP SIP/2.0
Security-Client: digest
Via: SIP/2.0/UDP 186.8.80.243:5060;branch=z9hG4bK5dkdhp10ghhc639r0acp3td;rport
From: <sip:777105@192.168.3.7>;tag=08rthp4ku9hc6lt10acp
To: <sip:777105@192.168.3.7>
Contact: <sip:NUOaP_AEv3UUXWqCoC5S@186.8.80.243;comp=sigcomp;transport=UDP>;expires=3600
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 26600421 REGISTER
Call-ID: JAjoVfMvoIcKpgapAhUUv57Qpt0OHK
User-Agent: S60 RM-624 v 10.2.024
Max-Forwards: 70
Content-Length: 0

——————————————————————-

SIP/2.0 401 Unauthorized
v: SIP/2.0/UDP 186.8.80.243:5060;branch=z9hG4bK5dkdhp10ghhc639r0acp3td;received=186.8.80.243;rport=5060
f: <sip:777105@192.168.3.7>;tag=08rthp4ku9hc6lt10acp
t: <sip:777105@192.168.3.7>;tag=as6590bdf0
i: JAjoVfMvoIcKpgapAhUUv57Qpt0OHK
CSeq: 26600421 REGISTER
Server: Asterisk PBX 1.8.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=”asterisk”, nonce=”598159a3″
l: 0


 

Next step was studying the RFC 3329. That’s the easy part, then comes the searching and understanding of the Asterisk sources to find where in the source code was implemented the initial session authentication mechanisms to then be able to modify that to develop the support for the RFC 3329, starting with the “Require: sec-agree” header.

After all, it didn’t looks so difficult, I identified what was the “path” in the code of chan_sip.c that leads to my “401 Unauthorized” error(that generic error really didn’t help but I finally found the right chunks of code). So, an small change in sip.h, a new function in chan_sip.c to start the develop of the RFC 3329, calling that function in the right place and everything should work (that’s almost never true :P).

After compiling that, still can’t authenticate correctly. It isn’t rare that in the RFCs, even more in an RFC proposal, there are details not fully specified or who implements them doesn’t conform the standards (some M word comes to your mind?).  Now some reverse engineering was needed to know what the Nokia client expects after the first response according the RFC 3329.

After some changes in the headers of the SIP packets, it finally works!

This patch was developed and tested with Asterisk 1.8.3 and the Nokia SIP clients of both phones, one of them with Symbian S60 v3 and the other one with Symbian S60 v5 OS.

Below are the SIP headers of a correct authentication with the sec-agree required header(Use security: yes in the Nokia cellphone).


REGISTER sips:186.49.36.94:5061 SIP/2.0
Security-Client: digest
Via: SIP/2.0/TLS 186.8.11.29:5060;branch=z9hG4bK50q5ipb39dhc6qmh05agheq;rport
From: <sips:777102@192.168.3.7>;tag=qdglipen7lhc6pmb05ag
To: <sips:777102@192.168.3.7>
Contact: <sips:hENV9tphWV12kyyBp_Eu@186.8.11.29;comp=sigcomp>;expires=3600
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 125824 REGISTER
Call-ID: GbVppr_goIej-05l20bxRgRfZQF9Of
User-Agent: (C) RM-334 11.047
Max-Forwards: 70
Content-Length: 0

——————————————————————-

SIP/2.0 494 Security Agreement Required
v: SIP/2.0/TLS 186.8.11.29:5060;branch=z9hG4bK50q5ipb39dhc6qmh05agheq;received=186.8.11.29;rport=48731
f: <sips:777102@192.168.3.7>;tag=qdglipen7lhc6pmb05ag
t: <sips:777102@192.168.3.7>;tag=as73012a25
i: GbVppr_goIej-05l20bxRgRfZQF9Of
CSeq: 125824 REGISTER
Server: Asterisk PBX 1.8.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=”asterisk”, nonce=”398fd2bd”
Security-Server: digest
l: 0

——————————————————————-

REGISTER sips:186.49.36.94:5061 SIP/2.0
Security-Client: digest
Via: SIP/2.0/TLS 186.8.11.29:5060;branch=z9hG4bK9rimuh3f8j4rth27b5ivkr3;rport
Security-Verify: digest;d-ver=”dc66a64bd5eb97c807185d6d5ac9d9ef”
From: <sips:777102@192.168.3.7>;tag=qdglipen7lhc6pmb05ag
To: <sips:777102@192.168.3.7>
Contact: <sips:hENV9tphWV12kyyBp_Eu@186.8.11.29;comp=sigcomp>;expires=3600
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 125825 REGISTER
Call-ID: GbVppr_goIej-05l20bxRgRfZQF9Of
User-Agent: (C) RM-334 11.047
Max-Forwards: 70
Authorization: Digest realm=”asterisk”,nonce=”398fd2bd”,algorithm=MD5,username=”777102″,uri=”sips:186.49.36.94:5061″,response=”47d2f9ee5812dfd703d70c1f1645aa06″
Content-Length: 0

——————————————————————-

SIP/2.0 200 OK
v: SIP/2.0/TLS 186.8.11.29:5060;branch=z9hG4bK9rimuh3f8j4rth27b5ivkr3;received=186.8.11.29;rport=48731
f: <sips:777102@192.168.3.7>;tag=qdglipen7lhc6pmb05ag
t: <sips:777102@192.168.3.7>;tag=as73012a25
i: GbVppr_goIej-05l20bxRgRfZQF9Of
CSeq: 125825 REGISTER
Server: Asterisk PBX 1.8.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
k: replaces, timer
Expires: 3600
m: <sips:hENV9tphWV12kyyBp_Eu@186.8.11.29;comp=sigcomp>;expires=3600
Date: Fri, 04 Mar 2011 06:16:48 GMT
l: 0


 

My apologies for one detail, you might have noticed that the first debugging headers(401 error) was over an UDP transport and the last ones was using TLS. I had the headers with the error saved but not the ones when it worked, so now I went to the log to copy the working headers but as since several days I’m using TLS as the transport for the authentication and signaling in Asterisk, I don’t have a working headers over UDP to paste here. I’m sure that you are going to understand the same although this detail.

 

Now important comments regarding this Asterisk 1.8.3 patch to support the “sec-agree” according the RFC 3329. It’s far away of being the complete implementation of the RFC 3329 for Asterisk. It’s only the part of the protocol when the negotiation is client initiated and with the most basic authentication (MD5 digest) just hardcoded to work with the Nokia SIP clients default parameters. Despite that, it’s well commented and explained in the source code where are the harcoded strings and where the changes should be done to continue the develop of the RFC 3329 patch. So, it doesn’t represents a real security improvement to the security of Nokia VoIP clients with Asterisk, although allows all Nokia VoIP clients to connect with Asterisk using the “Use security” option. The value of this patch could be as a starting point to continue developing the RFC 3329 support in Asterisk.

 

And the end of the story, the Asterisk 1.8.3 patch to support the RFC 3329 (only an initial approach).


diff -r channels/chan_sip.c ../asterisk-1.8.3/channels/chan_sip.c
9926,9951d9925
< /*! \brief Respond with minimum sec-agree negotiotion */
< static int transmit_response_with_sec_agree(struct sip_pvt *p, const char *msg, const struct sip_request *req, const char *randdata, enum xmittype reliable, const char *header, int stale)
< {
<   struct sip_request resp;
<   char tmp[512];
<   int seqno = 0;
<
<   if (reliable && (sscanf(get_header(req, “CSeq”), “%30d “, &seqno) != 1)) {
<       ast_log(LOG_WARNING, “Unable to determine sequence number from ‘%s’\n”, get_header(req, “CSeq”));
<       return -1;
<   }
<   /* Choose Realm */
<   get_realm(p, req);
<
<   /*
<       Digest algorithm and security server are hardcoded to be compatible with Nokia SIP client default parameters.
<       According to RFC3329 they must be dinamically negotiated.
<   */
<   snprintf(tmp, sizeof(tmp), “Digest algorithm=MD5, realm=\”%s\”, nonce=\”%s\”%s”, p->realm, randdata, stale ? “, stale=true” : “”);
<   respprep(&resp, p, msg, req);
<   add_header(&resp, header, tmp);
<   add_header(&resp, “Security-Server”, “digest”);
<   append_history(p, “AuthChal”, “Auth challenge sent for %s – nc %d”, p->username, p->noncecount);
<   return send_response(p, &resp, reliable, seqno);
< }
<
13426,13433d13399
<       if(!strcmp(get_header(req, “Require”), sip_options[18].text)){//18 corresponds to sec-agree in sip.h
<           /* Here comes the RFC3329 negotiation in the case where the client initates the security agreement*/
<           /* We have no auth, so issue challenge and request authentication */
<           set_nonce_randdata(p, 1); /* Create nonce for challenge */
<           transmit_response_with_sec_agree(p, “494 Security Agreement Required”, req, p->randdata, reliable, respheader, 0);
<           sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
<           return AUTH_CHALLENGE_SENT;
<       }

diff -r channels/sip/include/sip.h ../asterisk-1.8.3/channels/sip/include/sip.h
1758c1758
<   { SIP_OPT_SEC_AGREE,    SUPPORTED,  “sec-agree” },

>   { SIP_OPT_SEC_AGREE,    NOT_SUPPORTED,  “sec_agree” },


 

Download Asterisk 1.8.3 sec-agree RFC 3329 patch.

 

 

 

 

 

 

 

 

1 Comment

Aardvark Topsites PHP 5.2.1 security vulnerabilities disclosure

Some months ago, working in a site with Aardvark Topsites PHP application, I found a couple of information disclosure vulnerabilities and an HTML injection(Cross-site scripting) vulnerability.

.

Now I have some time and after some emails with the application developer I decided to report it and publish here.

.

There are easy to fix bugs and I hope that helps to improve this application security.

.

All of them are caused by lack of input verification and sanitization.

.

Affected versions: 5.2.1 and older

Publishing disclosure date: April 2009

.

Exploit details:

.


.

HTML Injection / XSS

(up to version 5.2.0)
For example, is possible to inject a link to any URL with any anchor text.

POC: /index.php?a=search&q=psstt+security”><a+href%3Dhttp%3A%2F%2Fwebsec.id3as.com>Web-Application-Security

.

Information Disclosure 1

(up to version 5.2.1)
Disclosure of full path of the application sources when you put a negative number at the ‘start’ parameter.

POC: /index.php?a=search&q=psstt&start=-4

.

Information Disclosure 2

(up to version 5.2.0)
Disclosure of full path of the application sources and some source code too when you put an non-existent user at ‘u’ parameter.

POC: /index.php?a=rate&u=nonexistentuser

.


, , , , ,

2 Comments