The TwitFeeder uses the Twitter API to get the different bits and pieces of information needed to generate the enhanced RSS feed. However Twitter isn’t the only one exposing the API:

• Laconi.ca (now Status.Net) is an “Open source microblogging service” and it exposes an API which is almost 100% compatible with the Twitter API and you can see it in action on Laconi.ca sites like Identi.ca or The TWiT Army (the Status.Net wiki also contains a large list of installs)
• WordPress.org recently added support for a subset of the Twitter API

What does this mean for users? All the Twitter specific tools just became more usable, leading to more integration and less time-wasting (which is the main idea behind this site). You can use the TwitFeeder to subscribe to any site which exposes the Twitter API:

• Subscribe to one of Identi.ca’s founder: identi.ca/evan
• Subscribe to Leo Laporte on the Twit Army: army.twit.tv/leolaporte
• Subscribe to a WordPress blog (most of the blogs already have an RSS feed, but just for the fun of it): wordpress.com/decipherinfosys

More API support = Less siloed information = More fun

Programmers sidenote: there is no “official” compatibility test for the API, so you can never be sure that you are perfectly compatible – there will be always some gray areas (for example the exact link to a status message – which varies between different implementations). All you can do is to have rigorous unit tests. And code reuse either using our sources or pything-twitter to which we’ve contributed support for multiple sources.

It had to happen, didn’t it? I’ve fired up Pidgin with the microblog-purple plugin, only to get an “invalid certificate” error for twitter. I’ve quickly became nervous, since a quick digging indicated that I was getting the wrong IP address for the domain twitter.com.

My first thought was: “I’ve been compromised”. After quickly verifying my hosts file and my DNS entry, all seemed fine on the surface. My second thought was: “my DNS server was compromised”, so I’ve done the same lookup using OpenDNS and the new Google DNS, both coming up with different (but wrong) answers. Finally I’ve checked out a couple of other HTTPS sites and they seemed fine. So I took a deep breath and (putting my faith in NoScript and RequestPolicy) visited twitter.com to find the following page:

Quick analysis:

• This seems to be a “good old” defacement
• A very likely scenario is that they somehow compromised the DNS registrar account (phising, dumb password reset, etc) and changed it to point to an other IP.
• Currently I’m seeing a couple of different IPs out there for the twitter.com domain:
  • My DNS server (and OpenDNS) returns 66.147.242.88
  • Google DNS returns 74.217.128.160
• The correct address seems to be 168.143.171.84, so if you put the following line in your host file, thing should start working again (you might need to do an ipconfig /flushdns if you’re on Windows):

  168.143.171.84 twitter.com

• The above is a hackish solution, and I would recommend using it only in life-and-death situations :-p. It is the best to let Twitter handle the incident and make sure that everything is cleaned up.
• It is unclear when exactly the defacement happened, but it must have been in the last 10 hours or so. It might have been specifically targeted so that it is late in the day in the USA so that the reaction is delayed.
• According to Google Translate (Babelfish doesn’t know Arabic unfortunately) the text below the picture says:

  Ok, so I’m a big ignorant idiot. The official language of Iran is Persian (also known as Farsi or Parsi), not Arabic. Thank you to Anonymous for pointing it out. According to this article the text in the picture says:

  This site has been hacked by the Iranian Cyber Army (on the flag)

  and

  The USA thinks they control and manage internet access, but they don’t. We control and manage the internet with our power, so do not try to incite the Iranian people (under the picture)

  Some people also seem to have screenshots with English texts on them.

• The rogue server doesn’t seem to respond to any Twitter API requests, so it doesn’t seem to be that they were going after usernames and passwords (which they very well might have done, considering the number of users who click trough SSL certificate warnings), but just to be on the safe side, change your password and don’t use the same password on all the sites!

Update: As of now all seems to be back to normal and all the DNS servers return the correct IP address. I’m waiting for an explanation in Twitter (mostly because I’m interested in how it happened :-)).

Update: Twitter acknowledges the hack on their blog and say that they will provide more information as it becomes available (however they erroneously affirm that the API were working correctly – they weren’t, since they used the same DNS record to contact Twitter – in fact this is how I’ve became aware of the hack).

Bonus: what sources can you use to investigate such incidents?

• First of all, be suspicious of SSL certificate errors! I know that they (sadly) are quite common these days, but be vigilant!
• Check that the problem is not at your end. Check that you have the correct DNS server (there are a couple of malware families out there which set a custom DNS server for the machine to control the users browsing destinations). Check that the given hostname is not present in your hosts file (again, there are a couple of malware families using this method to misdirect users)
• Check what the IP address should be, by using domaintools for example (and looking at the server stats page)
• Try looking up the DNS name using several DNS servers (this might not work if your network filters DNS queries):

  # nslookup
  > set type=ANY
  > twitter.com
  ...
  > server 8.8.8.8
  > twitter.com
  ...
  > server 208.67.222.222
  > twitter.com
  ...

• An other option is to use the vURL service to fetch the suspicious webpage from different location and compare the results with what you are seeing.

Using these methods you can quickly ascertain with pretty good accuracy where the fault lies and take appropriate action. Have a safe holiday everybody!

Update:

• Read about the subject on the TrendMicro Countermeasures Blog.
• Some more links to information and the source of the defaced webpage at Hacker News.
• SANS posted about in issue in the diary.
• I’ve update the translations, thanks to Anonymous
• Twitter posted an update about the issue. It doesn’t many more details, it does however give a timeframe for the problem: between 21:46 and 23:00 PST . There are some rumors out there that somehow (phising?) the correct password to the DNS management interface was obtained and it was used to modify the records. Twitter still has the original blogpost up saying that API’s were not affected, but this is not true! If you’ve used a third party Twitter client and you’ve clicked trough the certificate warning (or maybe it doesn’t use TLS at all), your password might have been compromised. Currently there is no evidence that the rogue server was logging passwords, but until the time some forensics is done on it, there is no sure way to tell if this was the case (since it is trivial to configure a webserver such that it responds with a 404 error, while still logging the details of the request).
• Arbor Networks posted a related article.
• Sucuri has also posted about the issue. They have a nice little network monitoring / alerting system. You can also use them as a third-party information source.
• ISS X-Force (part of IBM) has also a nice writeup about the incident.
• Brian Krebs has an informative writeup on the SecurityFix blog about the issue which quotes Dyn’s (the host for the Twitter DNS) CTO as saying: “Someone logged in who purported to be a legitimate user of their [DNS] platform account and started making changes”, further strengthening the probability that a Twitter employee’s email account was broken into via some mechanism.
• There is also a lot of confusion out there, as it always is the case with (security) news. I’ve heard someone saying that “why did the DNS host allow the redirection of Twitter to a host in Iran?” – just to clarify: even though the hack was claimed by the “Iranian Cyber Army” (which might not mean anything! it could be your nerdy neighbor), the server it was redirected to was in the US.

Picture taken from pugetsoundphotowalks’ photostream with permission.

• links are made clickable
• short links are transformed to their longer variants (the DeShortify pipe is used – this means currently there is support for TinyURL and bit.ly – also, it currently processes only the first link, however – given the 140 character limit of Twitter – this doesn’t seem to be a big limitation)

To use it, go to the Twitter Content Pipe Page, enter the Twitter username you want to subscribe to, press “Run Pipe” and get the resulting RSS feed. As a structure, this pipe is rather simple – is passes the fields trough a sub-pipe and assigns them to an other field: