.tc .vg .gd 問題

登録/更新料金の猛烈な値上げがレジストリによって行われるという笑撃の事態に出会ったのが1年ほど前、影響は比較的小さかったとはいえ先がやばそうなので3文字 .tc を1つその時に手放しました。

しばらくしてdd24.net(Key-Systems.com)のRSSでなんだかなアナウンスが出ていると思ってましたが、なんとこの事態は今まで続いていたということを最近のアナウンスで知りました。ググってみたところ、ちょっと見ない間にもうわけわからんことになっているようです。まがりなりにもTLDなのに恐るべし…

ググって出てくるページがまとまってました。whoisも両レジストリ(?)のデータベースで内容が違ったりしているようです。

グルーレコードは大丈夫なのかとかも含めて違いを探すだけで小一時間は遊べそうですが、はちゃめちゃすぎて時間の無駄っぽいですね…そして先ほどのフォーラムに出ていたIANAのページの抜粋です。

レジストリ(誰?)の指示だとして該当ドメインのDNSのリソースレコードの変更まで禁止されて悶絶の方々も見つかります。そこにその方自身がMeridial TLDとコンタクトを取った返事として載せられていることには、「AdamsNamesを動かしていたチームはMeridial TLDを動かしているチームだ。AdamsNamesにはもうレジストリを運用するインフラも知識もない」となっています。

レジストリのバックエンド担当のdd24と同じグループのKSregistryの2013/3/11ニュースのUpdate(4/12)では「(Key-Systemsの)RRPproxyは.tcと.gdと.vgの変更、登録、トランスファーを有効にしない」となっています。これはリソースレコードの変更には特に抵触しないですね。

AdamsNamesは違法に横取りされた(されるような退職者メールアドレスの管理をしているのが一番まずいと思いますが)、Meridian TLDが勝手にAdamsNamesを名乗ってICANNのミーティングに出席したと言っています。この記事によればAdamsNamesの言い分ではKey-Systems(KSregistry)を共犯としていたようです。

先ほどのニュースには、もうひとつ5/6にKSregistryが.gdのレジストリになったと書かれています。これは.gdのSponsoring Organisationが国立のNTRCだったからできたのでしょう。

ハチャメチャながらも少し流れがわかったところで先ほどの最近のアナウンスに戻ります。”The current operator of the ccTLDs is Meridian TLD Corp.” だそうです。っておーい、どういう流れでそうなったのか、IANAだかICANNだかの見解の説明をKSRegistryなりKey-SystemsなりKeyDriveの誰かがしてくれないと、これから公式ハイジャックとかできるようになるの?とか思っちゃいます。オペレータってなんだろう。

実際にこれらのドメインを使っていた人にとって、長期間にわたる不便は本当に困ったもんだと思いますが、わけのわからないccTLDと認識されてしまった痛手も長引きそうです…DNSSEC使ったところでレジストリが簡単にハイジャックされたとなれば意味がなくなっちゃいます。インターネットが脆弱なことを示す事件がまた増えましたが、事実関係が早くちゃんと明らかにされるとよいです。

チップのバックドア

2012/5/29 18:00現在、gigazine で bingる と、顔を見るだけで判断できてしまう… ギガジン、恐ろしい…のようなSERPになっているのは私だけでしょうか。

GIGAZINE 20120529

原発や軍事用に使われている中国製シリコンチップにサイバー攻撃可能な未知のバックドアが発見される – GIGAZINE の元ネタとなっているケンブリッジ大のページLatest news on my Hardware Security Research – Sergei Skorobogatov(HTTPS Everywhereを入れている人はcam.ac.ukをはずしておかないとエラーになります 2012/5/29) や、もっと昔のだよーと書かれている Copy Protection in Modern Microcontrollers でのくらっとくる色で警告など、いずれにせよ、古いdraftなabstractをRedditに晒されたからという理由で急いでいろいろ付け加えられているようです。その後RedditはFalse news story: No Chinese backdoor in military chip「ホームルータの20%(最近もWAN側にあるのがあった!)、工業制御用の50%のコンピュータでバックドアあるし~(数字の根拠は???)、中国が源なの?そもそも軍事用チップじゃないじゃん」という趣旨のblogで盛り上がったようです。このbloggerが付け加えているように、だからといってバックドアが有るチップを軍事用に使っちゃ良いことにはならないですね。

元文の一番下に並んでいる良く見るような型番もあるリストはごく一部で、多くのマイクロコントローラ、スマートカード、セキュアメモリチップ、FPGAは脆弱だそうです(PSoCはその頃手に入らなかったのだろうか、それともこの手法ではみつからないということなのだろうか、単に載せなかっただけなのか、時系列やターゲットが整理されていないので良くわからない)….どういう展開を見せるのか、連休明けの Microsemi Corporation 界隈で何かを狙っているなんてことはないですよね。

追記: その後も

とか、この分野は実験環境を作るハードルが高めなので面白ネタの宝庫ですね。

関係ないですがきゃりーぱみゅぱみゅと耐タンパ性って微妙に似てる?

PivotXを利用されている方は最新版にアップデートするべし (was: PivotXを利用されている方は2.2.5以降へアップデートするべし CVE-2011-1035)

2011/10/8追記: WordPress TimThumb RFI Vulnerability used as Botnet Recruitment Vectorにあるようなurlがquery string上で目立つTimThumbを狙ったアクセスを頻繁に観測していますが、PivotXも2.3.0のリリースノートでさりげなく書いてあるように本体がTimThumbを搭載しています。常にリリース状況を確認して最新にされることをお勧めします。なおこの問題に脆弱なPivotXのfingerprintingも、多くのケースでそうであるようにヘッダも含めてバージョン表示を消したところで即時に可能です。

2011/2/19追記: CVE-2011-1035, Vulnerability Note VU#175068


2011/2/14: PivotX 2.2.4がリリースされても告知が無く、SourceForgeにもリリースのアーカイブファイルがアップロードされないのでどうなっているのか見てたところ、フォーラムで開発チームからいくつか発言が出てきました。

2.2.4は緊急セキュリティ修正、そしてまもなく2.2.4での修正による悪影響を修正した2.2.5が出てくるそうです2011/2/17早朝に2.2.5リリースされました。SourceForgeにも置かれています。実際に攻撃があったことが複数報告されています。開発チームは詳細の公開を望んでいないようですが、結構誰でもすぐにわかってしまうかも…というかそもそも攻撃が現在進行形であるようなので可及的速やかに2.2.4、そしてリリースされ次第2.2.5以降にアップデートする必要があることになります。 http://pivotx.net/ の下の方にある最新情報を軒並み注意しておくとよろしいかと思います。アップデートだけではなく images/ と pivotx/templates/ を含むすべてのフォルダにmalwareが置かれていないことも要確認です。必要の無いファイルがある場合はダッシュボードに注意をうながすメッセージが出るようですが、出ないからと安心してしまわないようにしたいものです。全員のユーザ名が予測困難なものであることの確認とパスワードの変更を検討された方がよろしいかもしれません。

直接この問題とは関係無く、admin,system,pivotxなどの容易なユーザ名や、簡単にblogエントリから推測できるようなユーザ名は使用しないことを周知するとよろしいです。またCSRFはかわせないですがscript kiddieによる外部からのpivotx/index.phpへの直接攻撃には、例えばApache HTTPDで10.1.2.128/25,192.168.0.0/16からしかログインできないようにして良い状況でサーバ設定ファイルが変更できるのであれば

さらに403では無くてリダイレクトさせるには追加で

.htaccessしか使えない場合はyourblogdir/pivotx/.htaccessファイルを作成して

(yourblogdirはそれぞれの環境に合わせて)程度の制限をしておいても良いかもしれません。くどいようですがCSRFはこれでは防げません。pivotx/index.phpを利用した直接攻撃だけに対する限定的な緩和策で、基本は常に最新版へのアップデートです。

なおこの問題に脆弱なPivotXのfingerprintingは、多くのケースでそうであるようにヘッダも含めてバージョン表示を消そうとも即時に可能です。


2011/2/22:

から、google.com.tr の検索語 “inurl:jp pivotx” のSERPがReferer:の攻撃を観測しましたよ。

2011/2/17早朝:2.2.5がリリースされてSourceForgeにも置かれました。

2011/2/16朝:pivotx.netさきほど復活しました。

2011/2/15現在:pivotx.netがある共有サーバがダウンしてSourceForgeでも2.2.4以降のリリースとしてのアーカイブは入手方法がありませんが、SVNにコミットされたリリース前版は入手可能です:

  • http://sourceforge.net/projects/pivot-weblog/develop
  • http://web.archive.org/web/20160416045740/http://book.pivotx.net/page/1-2 trunk は現在2.3pre-alphaだそうなので、2.2系利用中の方は2.2.xのbranchが良いかと思います。SVN無しでもSorceForgeのレポジトリからのtar機能も一応使えます。リリース前なのでバージョン表記の変更が入ってませんが、 svn co した場合は pivotx/lib.php の $Rev$ が 3505 以降になっているはずです。なおリリースのアーカイブに含まれるextentionsは別途取得となります。gettextの.poファイルはPixotXの実行時に必要ありません。
    • svn co https://pivot-weblog.svn.sourceforge.net/svnroot/pivot-weblog/branches/2.2.x 2.2.x
    • http://pivot-weblog.svn.sourceforge.net/viewvc/pivot-weblog/branches/2.2.x/

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

CVE-2011-0411 Plaintext command injection in STARTTLSはこちら


Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。


CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。

この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。

表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。

表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、

  • 対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
  • 先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
  • 次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
  • 再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。

となります。(悲しいことにrenegotiationしないと続行できない状況の場合、いまだRFC5746非対応であるIE(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)

その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。

クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているようにhttps://ssltls.de/で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。

ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…

例えばOpenSSLのChangeLogを見ると、

となっていて、またFreeBSD Security Advisories2009/12/3 FreeBSD-SA-09:15.sslでは

となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。

さらにApache HTTPD 2.2.15のChangeLogでは、

となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。

Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在


FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。


FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。


OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
 + Apache HTTPD(mod_ssl) 2.2系列全部
の場合は

  • 表題のエラーコンソールログは表示される(RFC5746非対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)

OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
 + Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は

     

  • 表題のエラーコンソールログは表示されない(RFC5746対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)

要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
 + Apache HTTPD 2.2.15以降の2.2系列、
    あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、

     

  • 表題のエラーコンソールログは当然表示される(RFC5746非対応)
  • CVE-2009-3555に対しては * 脆弱である *
          (クライアントがinitiateした場合のrenegotiationを拒否しているだけ)

まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952

FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。

最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。

あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。


Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。

  1. Opera,Firefoxは結構前からペンギンさんが表示される。
  2. KB980436が適用されたWindows Vistaではペンギンさんは表示される。
  3. KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
  4. Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
  5. HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。

次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。

なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって

で再起動すればサーバ(IISなど)が、そして

で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。

その他の参考リンク