mechanism - SOURCE Conference
advertisement
Unified Communications
Information Loss Through the Front Door
This Federation Thing
Federation is an Old Story
• Bob wants to send Alice a message, but he only knows her email address
• Bob doesn’t have any details about Alice’s mail server or who delivers his message
• How does Bob find the path to Alice?
MX: Gluing Email Together
• DNS provides the answer; MX records bind domains together
• The two domains can find each other and exchange messages without previously
knowing anything about the other party
• This is federation
• The two domains may authenticate one another
• Each domain trusts the other to authenticate and identify their own user
Non-authoritative answer:
yahoo.com
MX preference = 1, mail exchanger = mta5.am0.yahoodns.net
yahoo.com
MX preference = 1, mail exchanger = mta6.am0.yahoodns.net
yahoo.com
MX preference = 1, mail exchanger = mta7.am0.yahoodns.net
The Many Names of IM
• Instant messaging has failed at this for many years
• Multiple networks, multiple protocols, multiple user identities
• Instant messaging vendors want to own your attention
IM Federation
• Instant messaging is finally catching up to email
• You can have a single identity and still chat with all of your friends. That’s IM
federation
• Instead of one protocol per network you now have SIP
• Or more importantly, you have XMPP
XMPP
A brief and biased primer
What is XMPP?
• The Extensible Messaging and Presence Protocol
• A layer 7 transport to build flexible protocols
• Bound to other transports including TCP and HTTP
• A structured XML document built over time where each element creates another
protocol element
• 3 main building blocks that are called stanzas
<message>
• The building block of Instant Messages in XMPP
• A message has a body
• It can also have more
• A subject
• A thread
<message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa">
<body>a simple IM message</body>
</message>
<message>
• A message can get very complicated
• It can support multiple languages, threading references, XHTML formating…
• Values can be UNICODE because the XML character encoding should be UTF-8
<message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa"
xml:lang="en">
<subject>A big example</subject>
<subject xml:lang="fr">A big example</subject>
<body>a simple IM message</body>
<body xml:lang="fr">I don’t speak French</body>
<thread parent="07a9311b">ef993107</thread>
<html xmlns="http://jabber.org/protocol/xhtml-im">
<body xmlns="http://www.w3.org/1999/xhtml">
<p>I can<span style="font-style: italic">get</span> complicated</p>
</body>
</html>
</message>
<message>
• But more importantly, it’s UDP or Push
• A message with an arbitrary <xs:any/> payload is sent to a specific address
• You may get an error response back, but it’s not required
• While <message/> began as an IM it’s a building block for any kind of protocol
<message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa">
<composing xmlns="http://jabber.org/protocol/chatstates"/>
<request xmlns="urn:xmpp:receipts"/>
</message>
<message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa">
<error type="cancel">
<gone xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
alice@yahoo.com
</gone>
</error>
</message>
<presence>
• <presence /> is multi-purpose
• It allows a resource to request access to information, to confirm or deny that
access, and to send asynchronous updates when information changes
• And just like <message> it’s a communications model for building more complex
protocols: Publish-Subscribe or Broadcast
Publish-Subscribe:
<presence from="bob@gmail.com" to="alice@yahoo.com" id="e7ff18" type="subscribe"/>
<presence from="alice@yahoo.com" to="bob@gmail.com" id="pres1" type="subscribed"/>
Update Broadcast:
<presence from="bob@gmail.com/Psi+" to="alice@yahoo.com">
<show>away</show>
<status>I am not here to take your call right now</status>
</presence>
Join the Group Channel #xmpp_chat with nickname bobryan:
<presence from="bob@gmail.com/Psi+" to="xmpp_chat@gmail.com/bobryan" id="a814df">
<x xmlns="http://jabber.org/protocol/muc"/>
</presence>
<presence>
• Presence relationships are long-lived
• Persistently stored in a database, and the server is responsible for maintaining them
• Presence relationships are one-way
• Bob may subscribe to Alice, but that doesn’t mean Alice subscribes to Bob
• This is very different than SIP, and can offer challenges in bridging the two protocols
<iq>
• IQ is Request-Response and it’s the workhorse of new XMPP interactions
• The requests have a type of get or set and must receive a response of result or error
• Requests must have at least one element in them that defines the request, and a
successful result will have elements that contain the answer
• IQs can address anything which can be named: users, user endpoints, servers,
components, channels…
<iq from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="e7ff18" type="get">
… must have an element that defines the request …
</iq>
Query the roster: <query xmlns="jabber:iq:roster"/>
Query information about an entity: <query xmlns="jabber:iq:disco#info"/>
Extensible
• XMPP started in 1999
• As such, there may be a little baggage to deal with
• 2 official collections of RFCs + “pre-standard”
• 314 registered extensions (XEPs), some with multiple versions
• But XMPP is designed for extension. It makes it really easy. It tries to advertise
everything and let the user make their own choices
So Why All the XMPP Talk?
IM is a Social Toy, Right?
Business Critical Functionality
Security’s a User Problem
Phishing & SPIM
Malware
Regulatory Compliance
Sarbanes Oxley
HIPPA
Many others…
We’re OK now
19
But IM Grew Up
• It’s now Unified Communications, and instant messaging is just a
useful after-thought
• Unified Communications market estimates*
• $100’s M in 2007, $4B in 2011
• PBX replacement lifecycle is 3-7 years
20
Meet your Next Phone
• It’s an IM client
• It’s a video phone
• It shares presentations, applications, your
desktop…
• It’s always on
• It builds on many different protocols and has
driver level access to your media devices
• And it is running on everything: your laptop,
your desktop, your desk phone, your iPad,
your mobile phone, in your web browser,
in SharePoint…
21
FinServ and the IM Clearing House
• Since 1999 banks have tried to create a single, federated IM
community
• But the bankers stayed where the money was
22
What the Private Sector Can’t Do
• For 10 years Fortune 500 companies couldn’t get the
industry to standardize
• Governments and the US Department of Defense have
spoken
23
And Hello Federation
• And the Department of Defense required what the business
community has only been able to dream about
• All instant messaging and presence systems approved for sale to
the US DoD must federate over XMPP and interoperate between
vendors
• http://www.disa.mil/Services/NetworkServices/UCCO/~/media/Files/DISA/Services/UCCO/UCR2008Change-3/12UCR08Chg3Section57.pdf
24
The Front Door
And what you can find if you open it
<stream:stream>
• The stream is the XMPP transport
• It provides flow control, error handling, and a growing number of extension protocols
• In server 2 server it is uni-directional
• Stanzas flow from Client to Server
• Each end initiates their own stream
• The bidi extension addresses this interesting design choice
• Streams inherently have insecure introduction problems; TLS is negotiated from a
clear-text beginning
Client Initiation
• Two different rule sets
• Client 2 Server, the jabber:client namespace
• Server 2 Server, the jabber:server namespace
• One version to cover more than a decade of rule changes
• Also can get “no version”
• Version=“0.9”
• This begins the “client to server” XML document
<?xml version="1.0"?>
<stream:stream xmlns="jabber:server"
xmlns:stream="http://etherx.jabber.org/streams"
from="google.com"
to="yahoo.com"
version="1.0">
Server Response
• The server starts the same way, agreeing to namespace and reversing the to and from
• The server also sends the <stream:features>, the capabilities of the server “at this
stage”
• The client selects based on capabilities, like TLS cipher suites
• And like TLS cipher suites… you can downgrade
<stream:features>
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
<compression xmlns="http://jabber.org/features/compress">
<method>zlib</method>
</compression>
<bidi xmlns="urn:xmpp:features:bidi"/>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>EXTERNAL</mechanism>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<dialback xmlns="urn:xmpp:features:dialback">
<errors/>
</dialback>
</stream:features>
What Should Happen
•
Each time an important feature is negotiated, the client must re-start the stream
(over the same transport)
•
So order for jabber:server should be:
1. <starttls/> with a <required/> and nothing else (establish stream security)
2. Client negotiates TLS and sends a new <stream:stream>
3. <mechanisms/> with a <required/> and nothing else (establish client
authentication)
4. Client negotiates SASL authentication and sends a new <stream:stream>
5. Other features as appropriate
•
But if you offer it the client can choose, and the previous slide said you can
proceed without TLS, without authentication, and without even the weak
DialBack mechanism
29
The XMPP Stream (S2S)
30
Taking Advantage of Complexity
• http://www.ldelgado.es/index.php?dir=aplicaciones/xmpploit
• Not surprisingly people get it wrong
• A requirement for encryption and no plain-text passwords is subverted even when
the server requires TLS to communicate
A Little More Clearly
<stream:stream from="gmail.com" id="79E36D297FCCA359" version="1.0" …
xmlns="jabber:client">
<stream:features>
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-tls">
<mechanism>X-GOOGLE-TOKEN</mechanism>
<mechanism>X-OAUTH2</mechanism>
</mechanisms>
</stream:features>
But even after stating that TLS and a non-password authentication mechanism
are required, gmail.com will still accept a plaintext stream authenticated with a
plaintext password.
Why Cheat When You Are Invited?
•
The front door is open
•
_xmpp-server._tcp.{the domain you’re interested in} points the way to
jabber:server handler for the domain
•
The bar to entry is hopefully a TLS implementation, a DNS entry, and a
certificate that matches your domain name… but Important Bank may not want
to talk to you
•
They will almost certainly talk to gmail.com, live.com, yahoo.com, or another
PIC (public internet cloud) provider
•
So what can we discover without directly messaging a user?
Asking the Right Questions
Narrowing the Field
Spec
RFC 3920 [2]
RFC 3921 [3]
Service Discovery [4]
Entity
Capabilities [5]
Jabber Component
Protocol [6]
Privacy Lists [7]
Simple
Communications
Blocking [8]
BOSH [9]
XMPP Over
BOSH [10]
vcard-temp [11]
Personal Eventing
Protocol [12]
Multi-User Chat [13]
Chat State
Notifications [14]
Core Server
✓
✓
Core Client
✓
✓
Advanced Server
✓
✓
Advanced Client
✓
✓
✓
✓
✓
✓
N/A
✓
N/A
✓
✓
N/A
✓
N/A
✕
✕
✓
✕
✕
✕
✓
✕
✕
✕
✓*
✕
✕
✕
✓*
✕
✕
✕
✓
✓
✕
✕
✓
✓
✕
✕
✓*
✓ **
N/A
✕
N/A
✓
XEP-114: Jabber Components
•
If we can get a component connection we have a trusted place on the XMPP
network
•
Perhaps we could brute-force passwords and gain external component status
•
Practically, this isn’t rolled out in a way that gives us a large enough target space
XEP-115: Entity Capabilities
•
Offers new nodes to Service Discovery
•
Advertised through <c/> elements in <presence> stanzas
•
Presence requires a direct message to a user and will likely pop up an
Accept/Deny dialog
XEP-163: Personal Eventing Protocol
•
The most interesting thing you can get here is GPS location changes if the client
broadcasts this data
•
Broadcast comes through <presence> stanzas
•
Presence requires a direct message to a user and will likely pop up an
Accept/Deny dialog
XEP-85: Chat State Notifications
•
Knowing that the user is typing isn’t what we’re going for
So What IS Interesting?
•
Service Discovery: walking the discovery chain tells us what the server
implements, what components are connected, and anything else that the server
decides to advertise
•
Multi-User Chat: the meta-data available about a company through channel
names, descriptions, configurations, and user lists can be staggering if the
company is indiscrete
•
Vcard-temp: it’s more useful than you think
Service Discovery: Disco#Info
•
Tell me everything I want to know about you
<iq from='example.com' to=‘bob@example.com/Psi+' type='result' id='c783849d'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='server' type='im' name='Isode M-Link 15.1v3'/>
<identity category='pubsub' type='pep'/>
<identity category='directory' type='user'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='urn:xmpp:ping'/>
<feature var='vcard-temp'/>
<feature var='http://jabber.org/protocol/commands'/>
<feature var='http://jabber.org/protocol/compress'/>
<feature var='jabber:iq:auth'/>
<feature var='jabber:iq:private'/>
<feature var='jabber:iq:version'/>
<feature var='urn:xmpp:blocking'/>
<feature var='jabber:iq:search'/>
</query>
</iq>
Service Discovery: Disco#Items
•
Tell me what other names you think I might be interested in
<iq from='example.com' to=''bob@example.com/Psi+' type='result' id='64b47a0b'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='chat.example.com' name='chat.example.com'/>
<item jid='bob@example.com'/>
</query>
</iq>
<iq from='chat.example.com' to=‘bob@example.com/Psi+' type='result' id='8d2d3db4'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='conference' name='chat.example.com' type='text'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='http://jabber.org/protocol/muc#unique'/>
</query>
</iq>
Disco#Items on a MUC Component
•
Once you know you have a conference server, you can ask for channel names
<iq from='chat.example.com' to='bob@example.com/Psi+' type='result' id='881a2076'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='water_cooler@chat.example.com' name='I am a room title.'/>
<item jid='closed@chat.example.com' name='Closed, Go Away'/>
<item jid='open@chat.example.com' name='Open Discussion'/>
</query>
</iq>
Meta-Data: Disco#Info on a Channel
•
And the channel name allows you to ask for channel configuration and channel
user lists
<iq from='closed@chat.example.com' to='bob@example.com/Psi+' type='result' id='e8e0611c'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='conference' name='Closed Channel' type='text'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='http://jabber.org/protocol/muc#unique'/>
<feature var='muc_membersonly'/>
<feature var='muc_public'/>
<feature var='muc_passwordprotected'/>
<feature var='muc_persistent'/>
<feature var='muc_nonanonymous'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'><value>http://jabber.org/protocol/muc#roominfo</value></field>
<field label='Description' var='muc#roominfo_description' type='text-single'>
<value>This is a listed, moderated, member-only, password-protected, persistent room.</value>
</field>
<field label='Subject Modifiable' var='muc#roominfo_subjectmod' type='boolean'><value>1</value></field>
<field label='Current Occupants' var='muc#roominfo_occupants' type='text-single'><value>0</value></field>
</x>
</query>
</iq>
User List: Disco#Items on a Channel
•
If you ask a channel for items, it gives you back the list of users
•
The names are not “usernames”, they’re channel nicknames
•
A user can have a different nickname per channel but clients define a more
structured experience
<iq from='open@chat.example.com' to='bob@example.com/Psi+' type='result' id='9f2584ae'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='open@chat.example.com/Swift Boddington'/>
<item jid='open@chat.example.com/dick'/>
</query>
</iq>
Swift Boddington is the swift.im client which uses the full name by default. Dick is
from Psi+ which defaults to the username.
Group Chat is About Community
• Metadata needs to be available. It helps create a useable community, and
external partners are part of that community
• Humans love meaningful names; they help drive choice and decision
• bigbank_libor_research@example.com
• “Using Bermudan SWAPTIONs to limit BIGBANK exposure”
• Does example.com do business with BIGBANK and consider them a risk?
• Other data can be just as revealing
•
•
Is a room public or private?
•
Is the room invite-only, members-only, password protected?
•
Who spends time in the room? New employees or the heads of major divisions?
And configuration can guide your actions
•
Does the channel accept XHTML input and messages from non-members?
•
Will the channel reveal full user JIDs to channel participants and is it an open channel?
•
Can you request vCard information for channel participants?
47
Group Chat Visually
48
But Getting to Users is Hard
•
•
XEP-191: Simple Communications Blocking
•
You shouldn’t be able to enumerate users based on response differentiation
•
Or tell that someone is blocking you
•
Messages, Presence Probes, and IQs should all receive the same error: serviceunavailable
To find out about a user you need to know their full JID… the JID for a connected
resource
What is a JID?
If you see
It is…
example.com
This is a domain JID, the name of an XMPP
domain
chat.example.com
This is a component, another name which
offers specific services in the domain
bob@example.com
A bare JID, the main address of a user
bob@example.com/Psi+
A full JID, this specifies a running resource.
The resource ID should be random
fx_trading@chat.example.com
A MUC channel (it’s at the MUC component)
Fx_trading@chat.example.com/bob
A nickname in a MUC channel, this doesn’t
necessarily match a username
Disco#Info on a User
Disco#Info on a …
Yields
Bare JID, valid or invalid username
Service-Unavailable
Valid username + invalid resource ID
Service-Unavailable
Valid username + valid resource ID
Full Disco#Info results for the specific
client endpoint
We can use MUC nicknames to guess at valid usernames, but to enumerate an existing
account we also require a resource ID.
Weak Resource IDs
Client
Default Resource ID Behavior
Spark
“Spark 2.6.3”
Psi+
“Psi+”, user can choose to use hostname
Pidgin
The user must type one in
Exodus
Uses hostname, offers “Home”, “Work”, and
“Exodus” as other options
Citron IM
“citron.hostname”, but user can choose to use
only the hostname
Swift
Generated random value
Google Talk
Talk.v{version + random value}
iChat
unknown
vCards and Finding Users
•
So you need to guess a user name, but at the same time guess a resource ID and
have the right client connected while you’re doing it
•
If not impossible, this is certainly not practical
•
But contact information helps you decide if you have the correct person
•
•
Email address
•
Office address
•
Position and title
•
Full name
•
Picture
And that occurs before you establish a relationship
53
vCard-temp Enumeration
“If no vCard exists or the user does not exist, the server MUST return a stanza error, which
SHOULD be either <service-unavailable/> or <item-not-found/> (but the server MUST return
the same error condition in both cases to help prevent directory harvesting attacks).”
•
•
•
Resource IDs are hard, but it’s more effective to guess once you know a JID is valid
With vcard-temp the target user does not need to be connected
Oops…
54
Conclusion
What Did We Get?
•
Without exploiting poor server implementation we found:
•
Interesting services with a possible attack surface
•
Meta-data which, in practice, is detailed and confidential
•
Clues to existing user accounts
•
A way to enumerate those accounts
•
Our test platform has a more secure default configuration than most. Those
controls can be relaxed, and learning how to tighten them further is very difficult
•
A tool is planned to make this easier to do, but at the moment it’s a jumble of
C++ code built on top of an extended copy of Swiften
56
Just How Far Can You Go?
•
HTTP generally gets you into the DMZ, and may get you to a database sitting in
the corporate network
•
XMPP gets you into the DMZ, then into the internal network, and finally right
onto the desktops and mobile devices of every user in the company
•
Unified Communications gives you not only instant messaging to play with. You
have audio and video codecs, remote desktop and app sharing protocols, tie-ins
with calendaring systems, and even the PSTN network
57
And it’s complicated
Really complicated… so even if that server says it requires TLS to continue, does it?
Thank You
Jason Bubolz
• Security Analyst at iSEC Partners
• Formerly a developer and security architect for Parlano Inc., an enterprise groupchat company, and senior development lead on Microsoft Lync Server
• jason@isecpartners.com
Rachel Engel
• Senior Security Analyst at iSEC Partners
• Former developer for Parlano Inc., an enterprise group-chat company
• rachel@isecpartners.com
59
UK Offices
North American Offices
Australian Offices
Manchester - Head Office
San Francisco
Sydney
Cheltenham
Atlanta
Edinburgh
New York
Leatherhead
Seattle
London
Thame
European Offices
Amsterdam - Netherlands
Munich – Germany
Zurich - Switzerland
Title
• Copy here
• Copy here
• Copy here
• Copy here
• Copy here
• Copy here
Title
Subtitle
• Copy here
• Copy here
• Copy here
• Copy here
Subtitle
• Copy here
• Copy here
• Copy here
• Copy here
Title (Image Slide)
Title (Table Slide)
(£m)
(£m)
%
Copy here
0
0
0
0
Heading
0
0
0
0
Copy here
0
0
0
0
Copy here
0
0
0
0
Total
0
0
0
0
Heading
Caption
