Mason Lee

Here’s an article on CNET about last night’s Twitter hacking. Apparently Twitter’s DNS “was compromised”. CNET states that it is “unlikely that [any Twitter] accounts were compromised”. I don’t have many details for this attack, but if it’s a DNS takeover, I question that assertion.

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.

I guess I’ll start over here at setting up some keys for the new year:

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

This is RFC4151, The “tag” URI Scheme”

Status of this Document

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