Subject: [Sip] SSLstrip: Implications for SIPS and our imaginary padlock icon?

From: Dean Willis <[email-masked]>
Date: Mon, 23 Feb 2009 10:33:07 -0600

I've often railed about how using "sips:" doesn't really prove  
anything to the user, since the connection is not end-to-end and  
downstream elements might be lying about what they are doing.

Apparently a similar attack is possible on https, when augmented with  
a (very) little social engineering. I'm pretty sure this trick would  
fool me occasionally, and my mother wouldn't stand a chance.

See:

http://www.forbes.com/2009/02/18/black-hat-hackers-technology-security_0218_blackhat.html

A poignant quote:

> The fundamental lesson of his encryption-stripping attack, says  
> Marlinspike, is that the protections on the Web's "secure" pages are  
> really just as weak as any page that can impersonate that security.  
> "The real answer is to encrypt everything," Marlinspike says. "When  
> you have a secure protocol that depends on an insecure protocol,  
> that's a problem."

So, what are the implications for the SIP world?

--
Dean

---

From: Theo Zourzouvillys <[email-masked]>
Date: Mon, 23 Feb 2009 17:45:01 +0000

> So, what are the implications for the SIP world?

Well, for starters vendors need to make sure any UI that represents
"this call is secure" display can't be subject to the favicon.ico
trick some browsers have.  think:

  Call-Info: <http://evil.attacker.com/padlock.jpg>;purpose=icon

SIP UIs also need to ensure that they can't fall for other
display-name tricks, i.e:

  From: "HSBC Bank"
<sips:m[email-masked]>;tag=xxx

(it would appear the phone on my desk will indeed fall for something like this)

The SSLstrip attack relies on a MITM being able to modify a HTTP
response *before* getting to the HTTPS page (i.e, rewriting the links
a user would normally click, such as "<a
href="https://login.hsbc.co.uk">My Account</a>").

A parallel to this attack in SIP is if a SIPS URI is first learnt
through a non TLS requests, which upgrades to TLS and uses a UI hack
like the one above, or even redirect to a sips URI hosted on the
attackers server (resulting in a padlock, all be it the wrong one),
which then forwarded the call to le bank.  again, this is partially a
UI design issue, and we need to ensure that UAC vendors display who
the certificate has been issued to [1] as well at the identty of the
remote endpoint.

Luckily for us, the same sort of attack will be far harder in SIP once
DNSSEC is in place (if it ever is :)) in the end to end model, as we
use NAPTR for indicating the transport, this there is no risk of
rewriting the response, as it will come through TLS even when non sips
call in a "secured" domain;  HTTPS doesn't have this.  a User typing
in "[email-masked]" will - at least in the end to end model -
result in a NAPTR RRset for hsbc.co.uk's SRV records and only TLS
transports (assuming a bank was sensible and only has TLS transports),
which results in another (secured by DNSSEC) SRV lookup lookup for
their proxies, which then is sent via TLS to them.

The worry comes when a user types "sip:[email-masked]" which
goes over TCP/UDP (non TLS) to a service provider, which then could
return a 302 to sips:[email-masked], as then we fall into the
same trap as the SSLstrip MITM attack.

In other words, a SIP call initiated over a non TLS transport can
never be "upgraded" (via, for example, a 3xx) to TLS without being
subject to this (albeit lack of user-awareness/UI design) attack.

 ~ Theo

1 - Although this has some issues too, obviously.

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk

Sent from: Bicester Oxfordshire United Kingdom.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Feb 2009 08:23:30 -0800

At Mon, 23 Feb 2009 10:33:07 -0600,
> So, what are the implications for the SIP world?

Uh, none? 

This is the whole reason why you need to start with secure references
and not allow opportunistic upgrade.

-Ekr