During and after Twittergate, when a hacker broke into a few hosted email accounts and obtained a number of internal documents, I had an opportunity to spend hours speaking to the actual attacker and document how he carried out the attack. The article was called The Anatomy of The Twitter Attack, and today we unfortunately find ourselves with a sequel to that post as the Twitter DNS servers were compromised last night and the site was redirected to a defacement page.
Unlike last time, on this occasion I have not had the benefit of speaking directly to the attackers, but have spoken to a number of people within the underground security scene familiar with matters and have constructed other parts of the story from public sources. The incident last night was perpetrated by a group called the Iranian Cyber Army – and we have been told that this group is working with the Iranian government. The attack occurred at the same time as a number of other diplomatic incidents, including the escalation of diplomatic hostilities between Iran and the US/EU as well as an incursion by Iranian troops into a disputed border area containing an oil field.
The defacement was carried out by hijacking the servers hosting the DNS records for the twitter.com domain (this is the server that maps the domain name to an IP address). The attackers modified the DNS records to point to an IP address with a web server hosting the defacement page. The twitter.com domain (registered with NetworkSolutions) was not hijacked, nor were its records altered.
The DNS records for Twitter are hosted at Dyn. A company that provides DNS hosting for over 100,000 domain names and provides other services for companies. We have been told, but have yet to confirm, that the account password recovery feature was used to reset the password for the Twitter account at Dyn. When we checked the password recovery page, it contains a request to contact Dyn directly – there is no form of any type. We have not been able to confirm is there was an automated process at this page which has since been taken down.
To reset the password to gain access to the account hosting DNS records, the attacker had access to the email address associated with the account. Twitter hosts all email on Google Apps for Domain, which played a central role in the previous attack on Twitter not because of any vulnerability within the application itself, but because of a lapse in password policies which lead to a minor account being compromised, which lead to other accounts being compromised.
The attackers gained access to the Twitter account at Dyn, and changed the DNS records for Twitter.com to point to an IP address that was on the anonymous Tor network. The attackers seemed to have changed all the records at Twitter.com, including sub-domains used for the API, the status page, etc. but because of varying caching levels and the fact that some clients were using a direct IP address not all services were affected immediately.
For most users the main Twitter web application was displaying the defacement page for just under an hour.
This type of attack is not very sophisticated, but it is extremely effective. It was not a direct vulnerability with the DNS server but rather with the accounts system and email addresses. While the Twitter application was not compromised, desktop applications and websites that directly send a users username and password back to Twitter over plain HTTP would have sent this information to the attackers IP address, from where it could easily have been harvested.
The solution to similar problems revolves around the management of account passwords, especially with critical services such as DNS hosting. Further, since the status page for Twitter was hosted on the same domain as the main site, it was also inactive during the period of time that the defacement was up on the site and for a short time afterwards while Twitter responded to the attack.