Some Twitter clients are vulnerable to DNS attacks

The Twitter blog implies that the name twitter.com was taken over. There are two scenarios under which a Twitter client will provide its user’s password to an attacker who has pointed the name ‘twitter.com’ to his machine.

The first is that the client uses “http basic auth” unencrypted with the HTTP protocol instead of HTTPS. If that’s the case, the client will always unrestrictedly give the username and password to whatever host is at twitter.com, and in this process it performs no verification of the host’s authenticity.

The second scenario is that the client uses HTTPS, but fails to also require and examine a trusted certificate of authenticity from the target host as part of the protocol. If the last part is skipped, though the HTTPS request will be encrypted for transit, the client has not verified the authenticity of twitter.com. Unfortunately, this certificate handling part can be sometimes tricky for developers to get right.

Originally, Twitter had no support for HTTPS, and the Twitter REST API to this day permits dumb HTTP basic authentication. Twitter’s own programming examples still show the URL “http://twitter.com/…”. So this, coupled with error-prone HTTPS certificate implementations in clients makes me expect there to be more than a few Twitter clients vulnerable to DNS attacks. Some may reveal your password to the first “twitter.com” that comes along.

Thus, if there was a DNS takeover of twitter.com, passwords were potentially compromised.

Without more detail from Twitter or the hackers, however, we don’t really know what’s happened. It could be that hackers didn’t actually get the DNS name “twitter.com”. It could be that all the vunerable Twitter clients happened to be off during the time of the attack. It could be that the attackers didn’t think to log the incoming http requests containing passwords and only wanted to add their greetings page and email address to twitter.com.

Comments welcome.

tag:masonlee.org,2010:
tag:telephonographic.net,2010:
tag:borange.com,2010:
tag:textie.me,2010:

This is RFC4151, The “tag” URI Scheme”

Abstract

1. Overview

1.1. References

2. Technical Specification

2.1. Namespace

2.2. Namespaced rssCloud XML Publisher’s Schema


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://rssboard.org/2009/xsd/rss2.0"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 version="0.9">

 <xs:element name="cloud">
  <xs:complexType>

   <xs:annotation>
    <xs:documentation>Specifies a web service that supports the rssCloud interface which can be implemented in HTTP-POST, XML-RPC or SOAP 1.1. Its purpose is to allow processes to register with a cloud to be notified of updates to the channel, implementing a lightweight publish-subscribe protocol for XML resources.</xs:documentation>
   </xs:annotation>
   <xs:attribute name="domain" type="xs:string" use="required"/>
   <xs:attribute name="port" type="xs:positiveInteger" use="required"/>
   <xs:attribute name="path" type="xs:string" use="required"/>
   <xs:attribute name="registerProcedure" type="xs:string"
use="required"/>

   <xs:attribute name="protocol" use="required"/>

    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="xml-rpc"/>
      <xs:enumeration value="http-post"/>
      <xs:enumeration value="soap"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
</xs:schema>


2.3. Use in Atom

2.4. Use in RSS

3. Examples

3.1. Atom Example

At one point, about 45 minutes in, the group starts talking about the now famous(?) incident-turned-thought-experiment where Robert Scoble had used Plaxo to scrape an email address off one of his friend’s Facebook profile (Michael Arrington’s).

The basic problem is this: If Arrington had his way, Scoble would be able to enter Arrington’s secret email address into Gmail, because Arrington trusts Gmail. But Scoble wouldn’t be able to enter the secret email address into Plaxo, because Arrington doesn’t trust Plaxo.

To achieve this programmatically, we’d want a data-sharing framework set up whereby the secret email address would be wrapped a protective permissions blanket that would automatically prevent unwanted people from seeing it and using it. Only too bad the Gillmor Group didn’t talk about how this permission system would work, because I think the devil is in the details. Such a system would be an example of Digital Rights Management (“Code is Law!”); and through this system Arrington avoids having to take Scoble to court because the secret email address manages itself. Don’t we all love DRM?

So what might the DRM permission system look like? I was thinking about one straw man proposal and it got me cringing: What if it were a white-list. Then Arrington could block Plaxo? But how would it work when Scoble wants to enter Arrington’s secret email address into some completely new web system that Arrington doesn’t know whether he trusts or not? ((i.e. Can he play his dvd on linux? no.)) It doesn’t work.

Worse, take the white-list straw man into the future with an analogy for distributed computer systems: What happens if Scoble leaves the galaxy with Arrington’s protected secret, and meets an alien email system that purports to be able to send email privately AND faster than light. Scoble trusts it, and boy, what a great way to call home! But is he allowed to enter Arrington’s secret address? Or does he have to wait 22 million light years to get an updated permission set from Arrington? The white-list straw man doesn’t scale, and it impedes progress.

Hopefully the Gillmor Group will be telling us about DRM that does work soon.

Seems to me that the most useful permission system would allow for a sort of weighted transitive trust network. Returning finally to the original incident about the facebook-scraped email, here are my two cents: If someone provides you with their email address, the typical understanding is one of transitive trust: “Here’s my email address, I want you to have it. Use whatever software you use, but protect my data like you’d protect your own.” In this light at least, Scoble wasn’t wrong; he was just using his address book software.

Privacy == Can of worms.

Graham told me he’s left the ending open at this point. Here’s what I’d like to see: The door opens, and standing there in the film is the viewer’s own digital twin, custom rendered using Google image search while the movie was streamed to the viewer over the net. Well, you’ll just have to see it. And that’s no spoiler. Pass the link around, too, so this movie gets made.