Twitterクラック時の個人的観測データ

2009/12/18-1

15時頃からTwitterがクラックされてました。 詳しい事はわかりませんが、個人的には大規模なDNSキャッシュポイズニングか、twitter.comのDNS権威サーバが乗っ取られたような気がします。(追記:文章公開後に色々時間をかけて考えると公開した文章の矛盾点が浮かんできました。キャッシュポイズニングじゃない気がしてきました。ということで、このエントリ、色々信用できないかも知れません。書いて公開しておいて申し訳ありませんが、各自の判断で内容を読んで下さい。)

追記:Twitterクラック事件の原因?

HTML

偽twitter.comにアクセスしたときに以下のようなHTMLが返ってきていました。 (ただし、画面内に収まるように一部改行コード追加)


<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>..:: This Web Site Has Been Hacked By Iranian Cyber Army ::.. </title>
</head>

<body bgcolor="#000000">

<p align="center">&nbsp;</p>
<p align="center"><img border="0" src="index.6.gif">
<img border="0" src="index.2.gif"><img border="0" src="index.7.gif"></p>
<p align="center"><img border="0" src="index.8.gif"></p>
<p align="center">

<a href="mailto:iranian.cyber.army@gmail.com?subject=Mowjcamp">
<img border="0" src="index.5.gif"></a></p>
<p align="center"><img border="0" src="index.3.jpg" width="43%" height="106%"></p>
<p align="center"><font face="Tahoma" size="2"><b>&nbsp;&nbsp;&nbsp;</b></font></p>
<p align="center"><b><font face="Tahoma" size="2" color="#FFFFFF">&nbsp;&#1576;
&#1606;&#1575;&#1605; &#1582;&#1583;&#1575;<br>
&#1576;&#1607; &#1593;&#1606;&#1608;&#1575;&#1606;
 &#1740;&#1705; &#1575;&#1740;&#1585;&#1575;&#1606;&#1740;
 &#1583;&#1585; &#1662;&#1575;&#1587;&#1582; &#1576;&#1607;
 &#1583;&#1582;&#1575;&#1604;&#1578; &#1607;&#1575;&#1740;
 &#1588;&#1740;&#1591;&#1606;&#1578; &#1570;&#1605;&#1740;&#1586;
 &#1575;&#1740;&#1606; &#1587;&#1585;&#1608;&#1740;&#1587; 
&#1583;&#1607;&#1606;&#1583;&#1607; &#1576;&#1607; 
&#1583;&#1587;&#1578;&#1608;&#1585; 
&#1605;&#1602;&#1575;&#1605;&#1575;&#1578; 
&#1570;&#1605;&#1585;&#1740;&#1705;&#1575;&#1740;&#1740; &#1583;&#1585; 
&#1575;&#1605;&#1608;&#1585; &#1583;&#1575;&#1582;&#1604;&#1740; 
&#1705;&#1588;&#1608;&#1585;&#1605; )&nbsp; <br>
&#1575;&#1740;&#1606; &#1587;&#1575;&#1740;&#1578; &#1576;&#1607; 
&#1593;&#1606;&#1608;&#1575;&#1606; &#1607;&#1588;&#1583;&#1575;&#1585; 
&#1607;&#1705; &#1605;&#1740; &#1588;&#1608;&#1583; <br>
&nbsp;</font></b></p>

</body>

</html>

dig結果

さらに、DNSのエントリも様々でした。 複数箇所からdigをしてみたのですが、何かDNSのqueryを出す場所によって結果が違うように見えました。

そのため、DNSキャッシュポイズニングが行われていた可能性も疑っていますが、後で調査結果が正式に出るまでは良くわかりません。 ただ、DNSキャッシュポイズニングではなく、単に時間ともにAレコードが変わったいき、キャッシュの反映具合で結果が違うだけというオチもありそうです。

でも、digの結果を見ていると、場所によっては、何か、オランダに飛ばされたりもしてますね。追記:これは、digコマンド実行時にtwitterではなくtitterとミスタイプしているのが原因でした。失礼しました。。。


(Google Public DNSでも試してみました)

> dig @8.8.8.8 twitter.com

; <<>> DiG 9.3.4-P1 <<>> @8.8.8.8 twitter.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60222
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		2447	IN	A	74.217.128.160

;; Query time: 44 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 18 15:21:46 2009
;; MSG SIZE  rcvd: 45


> dig @8.8.8.8 twitter.com

; <<>> DiG 9.4.3-P2 <<>> @8.8.8.8 twitter.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9311
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		505	IN	A	74.217.128.160

;; Query time: 44 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 18 15:54:13 2009
;; MSG SIZE  rcvd: 45


====


> dig twitter.com

; <<>> DiG 9.3.4-P1 <<>> twitter.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56191
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		30	IN	A	66.147.242.88

;; AUTHORITY SECTION:
twitter.com.		80793	IN	NS	ns4.p26.dynect.net.
twitter.com.		80793	IN	NS	ns1.p26.dynect.net.
twitter.com.		80793	IN	NS	ns2.p26.dynect.net.
twitter.com.		80793	IN	NS	ns3.p26.dynect.net.

;; ADDITIONAL SECTION:
ns1.p26.dynect.net.	80793	IN	A	208.78.70.26
ns2.p26.dynect.net.	80793	IN	A	204.13.250.26
ns3.p26.dynect.net.	80793	IN	A	208.78.71.26
ns4.p26.dynect.net.	80793	IN	A	204.13.251.26

;; Query time: 67 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 15:57:01 2009
;; MSG SIZE  rcvd: 195


> dig twitter.com

; <<>> DiG 9.3.4-P1 <<>> twitter.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32210
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		60	IN	A	69.59.28.85
twitter.com.		60	IN	A	74.217.128.160

;; AUTHORITY SECTION:
twitter.com.		83658	IN	NS	ns4.p26.dynect.net.
twitter.com.		83658	IN	NS	ns1.p26.dynect.net.
twitter.com.		83658	IN	NS	ns2.p26.dynect.net.
twitter.com.		83658	IN	NS	ns3.p26.dynect.net.

;; ADDITIONAL SECTION:
ns1.p26.dynect.net.	83658	IN	A	208.78.70.26
ns2.p26.dynect.net.	83658	IN	A	204.13.250.26
ns3.p26.dynect.net.	83658	IN	A	208.78.71.26
ns4.p26.dynect.net.	83658	IN	A	204.13.251.26

;; Query time: 162 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 18 15:09:16 2009
;; MSG SIZE  rcvd: 211


traceroute結果



> traceroute 69.59.28.85

(前半は割愛...)
 6  ae-6.r20.tokyjp01.jp.bb.gin.ntt.net (203.105.72.153)  12.347 ms  12.384 ms  12.
336 ms
 7  ae-3.r20.osakjp01.jp.bb.gin.ntt.net (129.250.4.210)  40.696 ms  21.039 ms  21.0
66 ms
 8  as-2.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.164)  139.175 ms  121.441 ms  13
7.700 ms
 9  ae-1.r21.plalca01.us.bb.gin.ntt.net (129.250.5.32)  121.949 ms  123.432 ms  133
.590 ms
10  * * *
11  66.192.245.58 (66.192.245.58)  202.493 ms  202.501 ms  202.468 ms
12  ae-7-1.cr01.clt.carohosting.com (216.54.211.242)  201.916 ms
    ae-8-1.cr01.clt.carohosting.com (216.54.211.246)  207.869 ms
    ae-7-1.cr01.clt.carohosting.com (216.54.211.242)  198.906 ms
13  ve2.ds01.clt.carohosting.com (76.76.1.10)  203.838 ms
    ve1.ds01.clt.carohosting.com (76.76.1.6)  200.558 ms
    ve2.ds01.clt.carohosting.com (76.76.1.10)  199.285 ms
14  server32.hosthat.com (69.59.28.85)  209.756 ms  205.305 ms  205.906 ms


治ったときのdig結果



> dig twitter.com

; <<>> DiG 9.4.3-P2 <<>> twitter.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13730
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;twitter.com.			IN	A

;; ANSWER SECTION:
twitter.com.		300	IN	A	128.121.146.100
twitter.com.		300	IN	A	128.121.243.228

;; AUTHORITY SECTION:
twitter.com.		9713	IN	NS	ns1.p26.dynect.net.
twitter.com.		9713	IN	NS	ns3.p26.dynect.net.
twitter.com.		9713	IN	NS	ns4.p26.dynect.net.
twitter.com.		9713	IN	NS	ns2.p26.dynect.net.

;; ADDITIONAL SECTION:
ns1.p26.dynect.net.	9643	IN	A	208.78.70.26
ns2.p26.dynect.net.	9643	IN	A	204.13.250.26
ns3.p26.dynect.net.	9643	IN	A	208.78.71.26
ns4.p26.dynect.net.	9643	IN	A	204.13.251.26

;; Query time: 57 msec
;; SERVER: 203.178.136.62#53(203.178.136.62)
;; WHEN: Fri Dec 18 16:06:14 2009
;; MSG SIZE  rcvd: 211


各ユーザがパスワードを即座に変更すべきか?

一部では「パスワードを即座に変更した方が良い」と言われていますが、私は変更していません。 今回の件は、恐らくtwitterのWebサーバ本体やデータベースなどが攻撃されたというよりは、DNS側が狙われたので、各ユーザのパスワードは関係が無い気がします。

また、もし万が一、本体がやられていた場合、Twitterの運営会社が安全確認を終了するまでは、パスワード変更用のモジュールに細工が行われた、焦ったユーザの平文パスワードが漏洩する可能性がある気がします。 クラッカーは、システム内に保存されている暗号化されたパスワードを頑張って解くよりも、平文パスワードを取得するために、乗っ取ったコンピュータのパスワード変更機能(passwdコマンドなど)や、sshやsshdなどを真っ先に置き換えることが多い気がします。

「偽Twitterにアクセスしちゃった」とか「Twitterクライアントが自動的にパスワード送ったかも」という不安がある人がいるかも知れませんが、Digest認証だと恐らく平文の生パスワードは偽サイトに送信されてません(Basic認証を使ってAPIを叩いていたら恐らくアウトですが。あー、でもBasic認証でTwitter APIを使えと解説しているWebサイトが色々ありますね。。。)。

追記:Twitter API直叩きの場合はBasic認証のみで(通常API利用だとDigest認証は使えない)、OAuthを使ってクライアント名が出るクライアントに関してはOAuthが内部でDigest認証をしているようです。 OAuth http://oauth.net/core/1.0/#auth_headerid:sendさん、ありがとうございます!。。。。何か、そういえば昔Twitter APIを一度試してみた時に、Basic認証しか出来ないのでTwitter API使うの止めた気がしてきました。。。あと、もう一つ気になってるのが、DNSキャッシュポイズイングだと世界中が同時にというのは難しいというか無理だよなぁというのと、digの結果でAuthorityが「ns1.muntinternet.net」になってる場合があるところです。一昨年ぐらいにレジストラに電話をかけてオペレータを騙してDNS権威サーバを変えてしまったという事件があるようですが、それ系ですか???でも、見る場所によって結果が変わったリしてるのも気になります。何だったんですかね???

(追記2:あ。。。一つ目のdigがtwitterではなくtitterになってるので変な話になってるんですね。。。失礼しました。u_sibさんありがとうございます!ということで、authorityは変わってなかったんですね。)

ただ、これは私の個人的な考えなので、他人に強制するつもりはありません。 各自が考えて行動することをお勧めします。

DNSセキュリティの良い啓蒙かも

でも、もしかしたら、今回の事件はDNSSECなどに関連するDNSセキュリティ啓蒙活動として今後は良い事例になるのかも。。。(不謹慎ですね。すみません。。。)

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!