カテゴリー: Security

DNSSECとDNS update(RFC2136,nsupdate)とdelegation Let's Encryptワイルドカード証明書とDANE TLSA RRを添えて

清水 文行

締め切りより品質という記事が出ていますが、お疲れ様です。Let’s Encryptのワイルドカード証明書のサポートはとても便利になるので期待しながらDNSSECでdns-01を使った自動化の下準備をしてみます。(2018/3/14 ACME v2 and Wildcard Certificate Support is Liveということでcertbotにてワイルドカード証明書を取得しました。末尾に簡単に追記します)
続きを読む →

サーバ証明書更新 The SSL certificate will be distrusted in M70.

清水 文行

ChromeおよびブラウザコミュニティによるSymantecの証明書の順次警告、無効化問題だそうで、該当する証明書(うちで該当するのはもちろん格安なDV RapidSSL)持ってるからさっさと更新せい、というメールが証明書屋さんから何度も来ました。TLSAの更新が必要なのでそれなりにめんどかったですが、本サイトも含めて2サイトの証明書を更新いたしました。皆さんどうしているのか見ようとしたところ…
続きを読む →

ntpd – PPS discipline まずは普通に較正 編

清水 文行

A/Dコンバータでも作ろうかと秋月でセンサーを覗いているとＧＰＳ受信機キット　１ＰＰＳ出力付き　「みちびき」対応 [AE-GYSFDMAXB]なるGPSが2,200円、こっちに目を奪われました。

出力データ形式
ＮＭＥＡ０１８３Ｖ３．０１準拠
電源電圧
ＤＣ５Ｖ（３．８Ｖ～１２Ｖ）
入出力信号レベル
Ｃ－ＭＯＳロジック（３．３Ｖ）
ＵＡＲＴ通信速度
９６００ｂｐｓ（デフォルト）、４８００～１１５２００ｂｐｓ
１ＰＰＳ出力
精度±10ns Ｃ－ＭＯＳロジック（３．３Ｖ）レベル，パルス幅：１００ｍＳ（アクティブＬｏｗ）

いー感じです。 続きを読む →

Notable Changes in NSS 3.27 CA certs. - Removal of 'Equifax Secure Certificate Authority'

清水 文行

某メールサーバ宛TLSでエラー発生

確認してみます。

3つ送られた証明書の最後の証明書のi:のCA証明書が無いのでエラーになっているようです。確かにNSS 3.27で削除された(コード)ようですが念のためコピペして食わせて確認してみます。 続きを読む →

bruteblock – 非公式IPv6パッチ

清水 文行

キエフ発のbruteblockはSSHのbrute-force攻撃対策で参照されることが多いようですが、標準入力を読んでipfwのテーブルに追加(bruteblock)してくれ、テーブルから決められた時間経過後に削除(bruteblockd)してくれるというシンプルな作りのおかげで使い道は無限大、自分次第あなた次第、SMTP-AUTH, IMAP4へのあくなき挑戦や、公開していないポートへのアクセスなど、好きなトリガーを設定するだけです。

Apache HTTPDのCustomLog directiveはpiped logを出力できますし、SSHでの利用例のようにsyslogdもパイプに出力できるのでsyslogを吐くプログラムならば何でもbruteblockを利用できることになります。

続きを読む →

NTT VG230i – ひかり電話SIP <-> ISDN ゲートウェイ

清水 文行

電波時計で 2012-12-12 12:12:12 を見ようと思っていたら、過ぎてました。

あまりのショックにというわけではないですがVG230i
Server: mcas/3.0 (VG230i 2.0.0.0; B2BUA; NTTEAST/NTTWEST)
を4台ほどNTTより取り寄せ、某所で予定より早く使う必要が出たので試しにいじってみました。取り寄せる前にオンラインで取扱説明書を見ました。「テレホタイム」という言葉が存在していた10年以上前になんかよくわからんけど P-MP で申し込むんだぁ!と申込書にチェックを付けた懐かしい記憶がよみがえり、今や自分が P-MP or P-P の設定をする側の立場になれるのかと優越感には浸れるものの、知りたいSIP/2.0側の情報は「本商品は、接続後、ひかり電話ルータが自動設定サーバから取得したひかり電話の設定情報を自動的に取得します」ということしかわかりません。無いよりましそうなので気づいたことを順不同で羅列しておきます。「ひかり電話」、「自動設定サーバ」ですぐに何のことかわかる人には(にも)不要な情報だと思われます。

ファームウェアのバージョンや組み合わせるNGN/フレッツ網やひかり電話ルータによって違う動作をするか、あるいはまったく動作しないかもしれません。あと下の拠点bのRV-230SEでは動作しましたが、そもそもBフレッツはVG230iの対応する動作環境とはなっていないようです。下記のDHCPに対応できていないひかり電話ルータがあるとかいう話でしょうか、それともQoS絡みでしょうか。あしからず。

  • VG230i 2.0.0.0
  • 使用したひかり電話ルータ/ホームゲートウェイ: RT-400NE 4.02(フレッツ光ネクスト)(拠点a) および RV-230SE 16.14(Bフレッツ)(拠点b)
  • 横で動作していたルータなど: 拠点a,b ともに NVR500(ATAとして) 11.00.19 および RTX1200(PPPoEおよびVLAN担当) 10.01.42
  • 「ひかり電話ルータが自動設定サーバから取得したひかり電話の設定情報を自動的に取得します」の「設定情報を自動的に取得します」とはDHCPのことらしい(((Bフレッツ版では:DHCPにてIPアドレス等を取得した場合の技術条件 -) ユーザ・網インタフェース仕様 – レイヤ3の仕様 – IPv4プロトコル)。VG230iにログされているDHCP後の「簡易設定」は意味が良くわからないのでパケット見るしかないかも。
  • ログから見るとDHCP optionは 1,3,6,51,53,54,58,59,90,120,125 が渡ってきている模様
  • ログから見るとその直後に「簡易設定」なるものをして「自動設定」が完了する模様。
  • VG230iの設定ページから自分で好きなSIPサーバを設定することはできない。
  • 端末とは「音声利用IP 通信網サービス（第2種サービスタイプ2）に接続される端末機器のうち、セッション制御用ユーザエージェント（SIP-UA）を実装するものを指す。特に、網に対して、セッションを起動する側の端末を発端末、網からセッションを起動される端末を着端末と呼ぶ。」そうです。Bフレッツ（第2種サービスタイプ1）版にも同じことが書いてあるのは第6.0版でのコピペ後の修正忘れでしょうか。

面白そうな項目など

  • アドレス重複時の対策
  • 「また、端末が利用可能なIPv4アドレスは、網に接続する際に網から割り当てられたIPv4アドレスの範囲のみで、その他のIPv4アドレスを利用した場合の動作は保証されません。」
  • 音声利用ＩＰ通信網サービス（第1種サービス）のインターフェース-ひかり電話ビジネスタイプ- では、「また、発ユーザが通知したい発番号を送信INVITEのP-Preferred-Identityに設定することで着ユーザにその番号を通知可能とします。」となっている。ビジネスでなら当たり前なことができるということか…それとも実はひかり電話でもできる?
  • 関係なさそうだけどなんかみつけたので気が向いたら読む。特開２００９－２００９８０

というわけで PPPoEパススルー している人はひかり電話ルータのDHCPサーバを使っていない人が多いでしょうから、ひかり電話ルータのDHCPサーバを動作させてVG230iに「設定情報を自動的に取得」させてあげる必要あり(PPPoEパススルーのままで動作してました)。”ngn type lanX ntt”したRTX1200やNVR500のDHCPサーバはもしかしたらVG230i用に使えるのかもしれない(*1)(確認してません)。

既にひかり電話ルータに自力でSIP接続している場合は以下のように内線設定が自動的に書き換えられてしまうので、VG230iを接続する前に受け入れ態勢を整え、ひかり電話ルータの設定を保存しておかないと半べそになります。

  • VG230iが端末登録(ユーザ網インタフェース仕様 – セッション制御(ここはセションではないのねん))するとひかり電話ルータは、「使用する」にチェックがついていて、その時点でSIPでREGISTERされていない内線を相手に明け渡し、相手のMACアドレスをその内線設定に書き込む。VG230iに対してRV-230SEはSIPユーザIDとSIPパスワードも渡したことを確認。ちゃんと網羅して確認していないがユーザIDとパスワードをブランクに設定し、あるのはMACアドレスのみにするという場合もあったように見える。
  • 気づいて別の内線に変えようとしてもMACアドレスが重複する設定はできないので、SIPクライアント側を切断(expire 0)してLANケーブルを抜くか、あるいは「使用する」のチェックを全部はずし、勝手に変更されて困った方の内線設定をあって欲しい姿に戻してから、接続してほしい方の内線設定にMACアドレスを設定してやり直す、という不毛な作業が発生します。

ISDN側にもいろいろつなげました。手近にあったTAを1台とNVR500を2台の計3台、NVR部分はなつかしのBMJ-8相当の分岐を使ってLANケーブルでバス接続、できあがった全7個のアナログ回線には計14個のRJ11 RJ45アダプタを利用しLANケーブルで家庭用電話機やモデムと接続、NVRはLANに接続、さらにTAのRS-232CのDB9ピンにもRJ45アダプタを利用した挙句にRS-232CのついているPCが離れていたので RS-232C LANコンバータ を2台使用。普段からなんでもLANケーブルで済ませるという横着のおかげでアナログ電話周りなのにLANケーブルだらけの変態試験環境になってしまいました。LANケーブルをLAN用に使っている部分はNVRのsyslog出力用と、RS-232C over IPの部分だけですね… 一部で人気の某機のようにひかり電話ルータが出力するモデムダイアルインやナンバーディスプレイ信号で誤動作することもなく(SIP機とアナログ線機で対決させては非常にかわいそうだけど)、NVRの吐くsyslogをsyslog-ngに喰わせて簡単なシェルスクリプトで自分好みのCTIになったところで満足して解体。倉庫からホコリをかぶったホームテレホンを引っ張り出してくる元気は無かったのでここで終了。発信者番号が1つに固定なのが悲しいので、全部の発信者番号で内線登録してでもなんとかするといった改善をしてくれればもう8,400円はお買い得と思われます。というか1IPアドレス1内線(ユーザ網インタフェース仕様 – セッション制御 – 端末登録 – 端末登録の制限)というひかり電話側のしょぼい制限を昔のように無くしてもらえないものだろうか…

FAXは1つのFAXモデムを、受信2回線、送信1回線で使うために TELFAX MINI P&Pというかゆいところに手が届く製品を多く作っている会社の切り替え機を使ってしましたが、ついでにここもシンプルに整理しよう。

落書きのようなものなので随時追加、修正します。読みづらくてすいません。間違いなどはコメントで教えてくださいませ。

(*1) 2017/6/8追記: 実験されたmobu様よりIPアドレスも割り振られないとのご連絡をいただきました。確かにこの状態ではSIPサーバがどこにもいないのでSIP <-> ISDNゲートウェイであるVG230iが動作する由もないのでした。

チクタック、チクタック US Navy の時計

清水 文行

tick.usno.navy.mil と tock.usno.navy.mil のntpサーバが2000年を指していた模様。正確な時間に依存しているセキュリティモデルは壊滅してしまいますね。ちょっと前にも leap second でハングする Linuxカーネルとかあったような気がします。

あと全然関係ないですが、bitsquattingの話、面白いですね。typosquattingと違って注意してタイピングしていても防げないので。いつだったかソフトエラーを目の当たりにしてしまいましたし。

チップのバックドア

清水 文行

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 界隈で何かを狙っているなんてことはないですよね。

追記: その後も

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

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

誤検知: cmdproxy.exe Trojan.Win32.Siscos.ipv

清水 文行

新しい機械をセットアップするといろいろ起きて楽しいです。WindowsでもGNU Emacsでちゃちゃちゃっと便利に済ませたいときがよくあるのでNTEmacs 23.3をぶち込んだところ、Vulnerability Scanが便利なKasperskyさんが表題の警告を表示。variant部分が3文字です。Trojan.Win32.Siscos.ipvは最近追加された亜種、詳細説明無し。Trojan.Win32.SiscosのNumber of resultsは6453だそうで。データを盗むということのようですがdetached署名でも確認してあり VirusTotalで2/43、しかも片方はsuspiciousなので誤検知ということで良さそうです。(最近出たemacs-23.4-bin-i386.zipの方は署名に使われているkey ID 0x597F9E69(0x587DE7C6597F9E69)な公開鍵がGNUの公開鍵一覧にもメジャーなキーサーバにも存在していないのでFSFに鍵無いと連絡だけしてとりあえず放置してありますが、こちらのcmdproxy.exeはどうだったんでしょうね)

シェルを呼び出してまでWindowsでEmacsを使うこともないのでさくっとquarantineしてくれちゃって良いのですが、一応困る人がいるかもしれないのでunbel32以来久々のfalse detectionの報告をしたところ、「ごめん、誤検知。次で直すね。ありがとー!(超訳)」とのお返事。

問題イベント名: BEX

清水 文行

http://technet.microsoft.com/en-us/library/cc738483(v=WS.10).aspx によれば a buffer overflow or DEP exception だそうな。ってことは例外は全部 ?EX なのか、例外は最大で26個までなのか、はたまた36個までなのか、特別例外とかいう「イベント」があったらまずくないのか、などなどBOFとでも書いておいてくれればいだくはずもない素朴な疑問はおいておいて、バイナリが正しい配布のものであることを確認して、複数のアンチウィルスでも確認、さらに可能であればそれがDEPに対応できていないことを確認した後にわざわざその実行ファイルでのDEPを無効にし、実行完了後に戻すことにします。

今回はWindows用JREインストーラ実行開始直後

JREインストーラのハッシュはどこにも見当たらないのでインストーラ本体のデジタル署名を隅々まで確認。もっともらしそう。「オンラインで解決策を確認してプログラムを終了します」をクリックすると無言のまま終了。何も無いことを確認してくれたんですね。

このインストーラに対してDEPくらい対応してよという声も複数見つかるので、では半べそですがインストーラのDEPを無効にします。 EMET があれば簡単です。’Configure System’ボタンを押し、DEP を ‘Always On’ から ‘Application Opt Out’ に格下げ。’Configure Apps’ボタンを押して jre-6uxx-windows-xxx.exe を追加、DEPのチェックをはずし、OSごとリブート。インストーラを実行してインストール完了後に’Configure Apps’で追加したものを削除して、DEPを’Always On’に戻して完了。

老舗ダウンロードサイトが勝手に独自インストーラでラップ

清水 文行

今年の8月よりCNETの老舗ダウンロードサイト Download.com が広告対象のソフト(ツールバー)の独自インストーラでオリジナルのインストーラをラップするという暴挙に出ているというFyodorさんの怒りの記事です…ちょっと前は広告対象をインストールしないと目的のソフトがインストールできないようになっていた(VLC)とか、お子様用のソフト(Kea Coloring Book)もとか、上塗りで何かとまずいですね…

追記: SourceForgeもやらかしました。

複数経路で入手したハッシュ値での確認の必要性を再認識させられます。

Comodo affiliate RA was compromised

清水 文行

Comodoより重要サイトの証明書が不正な相手に発行されたという記事。RAはどこだったんでしょうか(参考1, 参考2)。ちょっと昔のnull-prefixの証明書の話とは異なります。

How to avoid fraudulent SSLでは、失効した証明書を

  • OCSPレスポンダが提供されていてOCSPをサポートしているクライアント使用でも
    • OCSPを有効にしていない
    • OCSPレスポンダの応答がタイムアウトした場合に有効な証明書とみなすようにしている

    場合に、クライアント側が有効な証明書とみなしてしまう

  • 大手ブラウザはそのような状況用にブラックリストを更新 ⇒ 最新にせよ
  • OCSPを有効にせよ、タイムアウト時に証明書を無効として扱うようにせよ
  • EV SSLを使用せよ(いきなりサーバ側の話)(現在CAはOCSPをサポートしないといけない 参照: EV SSL Certificate Guidelines 11.1.1)

などの、サーバ証明書を売る立場での説明があります。特に今回のような大きな問題の場合は、クライアントが検証用にCRLをダウンロードするタイミングよりOCSPレスポンダへの問い合わせのタイミングのほうが早い場合が多いのでしょう。

秘密鍵がポストされてしまったようなので、ブラックリストでの対応があるクライアントは最新にアップデート、OCSPに対応している場合はタイムアウトした場合も無効となることの確認が急がれます。

参考: MS01-017

Japan Earthquake: Possible scams / malware

清水 文行

Japan Earthquake: Possible scams / malware 詐欺、マルウェアを撒くメールが発生する可能性があるのでご注意をという記事 ⇒ その後各種発生しています。詐欺メールの内容は読むに耐えません。

Tsunami in Japan…既に検索エンジンに対するポイズニングが成功しているという記事。

国内でも善意につけこむ各種詐欺

CVE-2011-0411 Plaintext injection in STARTTLS

清水 文行

多くのSMTPクライアントはサーバ証明書を検証しない -> その場合そもそもMITMがいない確認ができていないので常にcommand injectionに脆弱な状態 -> だからこの問題は見た目より大きな問題ではない。という皮肉が効いてます…今時だとスマホアプリやIoT機器(こちらはそれなりの値段で買わないと手に入らないものが多いので比較的公開されてませんが、某社製のSSLスタックを積んでたりすると…)のサーバ証明書の検証不備の脆弱性がその状態ですね。

というわけでSTARTTLSからみでSMTP over TLS以外にもしばらく後続がありそうです。