Savitech製USBオーディオドライバの脆弱性
2017/11/6 IPAはSavitech製USBオーディオドライバの脆弱性を発表しました。本脆弱性はSavitechのルート CA証明書を、ユーザーの許可なくWindowsの信頼されたルート証明機関ストアにインストールしてしまうそうです。仮にSavitechの秘密鍵が漏洩した場合、攻撃者が悪用すればウェブサイト等のなりすましや、悪意のあるソフトウェアの配布、暗号化されたデータやトラフィックの復号が行われる可能性があります。幸いなことに、現時点では秘密鍵の漏洩は確認されていないそうです。
本問題の対策として、以下のルート証明書がインストールされていれば削除する必要があります。確認方法は「スタートのプログラムとファイルを検索」に「mmc」と入力→「ファイル」→「スナップインの追加と削除」→「証明書」を選択→「ユーザーアカウント」を選択→「信頼されたルート証明期間」から該当の証明書が無いか確認します。
SaviAudio root certificate #1
有効期間: Thursday, May 31, 2012 - Tuesday, December 30, 2036
シリアル番号: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050
SaviAudio root certificate #2
有効期間: Thursday, December 31, 2015 - Tuesday, December 30, 2036
シリアル番号: 972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5
また、証明書の削除に関わらず、最新のドライバをインストールする必要があります。
GRE ( Generic Routing Encapsulation )
IPSecに引き続き、GREについても環境を作成する機会があったので整理します。GREはトンネリングプロトコルの一つです。トンネリングと言っていますが、実態はGRE機能を有効化した機器の両端でGREヘッダを付与および剥奪しています。
GREの良いところはGREを有効化した機器の経路上に存在する機器がGREヘッダに付与されたIPアドレス以外解決しなくて良いところです。下記の例だとGREヘッダの送信元 IP、宛先IPはLoopback0のIPアドレス(1.1.1.1および2.2.2.2)に設定しているため、RelayRT00はPC00/01のセグメント(192.168.0.0/24および192.168.10.0/24)のルート情報が不要になります。また、トンネリングによりマルチキャストアドレスも伝送できるため、直接接続していない場合もネイバー関係を形成することが出来ます。ただし、Loopback0のIPアドレスは解決できる必要があります。
GRERT00#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
GRERT01#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
実際にパケットキャプチャをしてみると送信元IPと宛先IPはTunnel Interfaceに割り当てたIPになりますが、GREは暗号化機能を保有していないため、実際のIPも確認できます。暗号化まで期待する場合はIPSecを組み合わせる必要があります。
Wiresharkは優秀なため、画面上部は実IPアドレスが表示されていますが、下部を見るとSrc:1.1.1.1 Dst:2.2.2.2とGREヘッダのIPアドレスが表示されます。中継機器はこの箇所を見てルーティングを行うため、内部のアドレス情報を理解する必要がありません。Arubaをはじめとした無線LANコントローラもAPとGREを形成するため、複数のSSIDとVLANを設定してもAPのアップリンクをTrunkにしなくて良いのは同じ理屈でGREヘッダだけ見て転送するからです。当然コントローラ障害時にAPが自立する場合は、APが各Vlan Tagを付与する必要があるのでアップリンクはTrunkにする必要があります。
GREの注意点として暗号化が実施されないこと、MTUが1476になるため、MTUサイズの設計を適切にする必要があります。
実際はIPSecもトンネリング技術なのですが、Ciscoの仕様でユニキャストしか伝送できないため、マルチキャストを伝送する場合はGREを使用するか、組み合わせる必要があります。個人的に拠点間でダイナミックルーティングを実現するためにIPSec+GREを使うパターンはあまり無い気がします。。設計をシンプル化したいのもありますが、大規模な環境を作る場合も一度に拠点展開することはあまりないので、拠点展開手順にStatic Routeを追加するところまで盛り込んでしまうことが多いので、、、
最終設定時の各コンフィグは以下となります。
GRERT00#
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
ip ospf network point-to-point
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.0.254 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
!
ip route 2.2.2.2 255.255.255.255 172.16.0.254
GRERT01#
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
ip ospf network point-to-point
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.10.254 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 172.16.10.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
!
ip classless
ip route 1.1.1.1 255.255.255.255 172.16.10.254
no ip http server
no ip http secure-server
RelayRT00#
interface FastEthernet0/0
ip address 172.16.0.254 255.255.255.0
!
interface FastEthernet0/1
ip address 172.16.10.254 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 172.16.0.1
ip route 2.2.2.2 255.255.255.255 172.16.10.1
IPSecとNPAT併用時の注意点
久しぶりにIPSecとNAPTを併用した環境を作ったら動作に違和感を覚えたので書き出しておきます。
PC01(172.16.0.1)からPC02(172.16.10.1)にPing疎通時、以下のACLによってIPSecの暗号化トラフィック対象としていた場合、IPSecのセッションが形成され疎通可能になります。
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
crypto map CMAP
!
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
環境作成当初、誤ってNAPTされる対象トラフィックも同一の値を設定してしまい、IPSecが形成されませんでした。
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
CERT01とWANのポイントをキャプチャすると以下のようなログが出ており、PC01のIPアドレスがCERT01のDialer interfaceのIPにNAPTされていることがわかりました。
あれ、、、CiscoってIPSecを設定している場合、ルータの処理順って暗号化トラフィックの指定のほうが早いんじゃなかったけ、、、と思って処理順序を調べてみました。
よく見るとIPSecのACLチェックは１番だけど暗号化は14番ですね、、だから暗号化前にNAPTさされてしまい、暗号化されず出力されるんですね、、、勉強になりました。
当然NAPT用のACLを変更し、IPSecの暗号化トラフィックは対象外にすれば問題なく通信が出来ました。
CERT01#show crypto isakmp sa
dst src state conn-id slot status
210.154.183.2 210.154.182.1 QM_IDLE 1002 0 ACTIVE
最終設定時の各コンフィグは以下となります。
hostname CERT01
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.183.2
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
!
interface FastEthernet0/0
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
ip address 172.16.0.254 255.255.255.0
ip nat inside
!
interface Dialer1
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy@hy.com
ppp chap password 0 hy
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname CERT02
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.182.1
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.182.1
set transform-set TSET
match address 101
!
interface FastEthernet0/0
ip address 172.16.10.254 255.255.255.0
ip nat inside
!
interface FastEthernet0/1
pppoe enable
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy1@hy.com
ppp chap password 0 hy1
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname WAN
!
username hy@hy.com password 0 hy
username hy1@hy.com password 0 hy1
!
bba-group pppoe PPP1
virtual-template 1
!
bba-group pppoe PPP2
virtual-template 2
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
pppoe enable group PPP1
!
interface FastEthernet0/1
pppoe enable group PPP2
!
interface Virtual-Template1
ip unnumbered Loopback1
peer default ip address pool POOL1
ppp authentication chap
!
interface Virtual-Template2
ip unnumbered Loopback2
peer default ip address pool POOL2
ppp authentication chap
!
ip local pool POOL1 210.154.182.1
ip local pool POOL2 210.154.183.2
DDE機能を使ったマクロレスマルウェア
DDE(Dynamic Data Exchange)とはWindowsの機能であり、各種実行ファイルを起動することが出来ます。本機能を使うことでMicrosoft Wordにおいてマクロを使わずにマルウェアを実行させる方法が公表されました。
DDE自体は便利な機能ですが、本機能を使って実行ファイルの起動許可を求める文章は、以下のようにあまりセキュリティリスクを意識させません。
この文書には、他のファイルへのリンクが含まれています。リンクされたファイルのデータでこの文書を更新しますか？
実際にトロイの木馬やボットネットなど、本機能を使ったマルウェアが存在しています。この機能はMicrosoftの正当な機能であるため、ほとんどのウィルス対策ソフトは警告やブロックをすることはありません。 本マルウェアから身を守るためには各Officeの「開いているときに自動リンクを更新する」オプションを無効にする必要があります。Word2013であれば「ファイル」→「オプション」→「詳細設定」→「全般」にあるのでチェックを外しておくか、信頼できない送信元からの文章は常に疑いましょう。
Aruba Troubleshooting CLI
Arubaのtroubleshootingで使うCLIコマンドを以下に記載します。
＃随時更新してきます。
・接続User一覧
(Controller)#show user-table verbose
・接続AP一覧
(Controller)#show ap active
・ライセンス一覧
FlagがEになっているか確認してください
(Controller)#show license verbose
・ARMのチャンネル変更履歴を表示
頻繁に変更されている場合、干渉源がないか確認してください
(Controller)#show ap arm history ap-name <ap-name>
・WLCのshow tec
(Controller)#tar logs tech-support
(Controller)#copy flash: logs.tar tftp:<tftp address> logs.tar
・APのshow tec
(Controller)#show ap tech-support ap-name <AP-name>
ISDNサービス廃止に伴うIP網への移行
将来のISDNサービスの停止に伴い、NTT東西がIP網への移行計画を正式発表しました。実際のIP網への移行開始は2024年初頭から始まり、2025年初頭までに完了させる予定だそうです。これに伴う終了サービスは以下となります。
- INSネット64
- INSネット64ライト
- INSネット1500
NTT東西は移行対応が間に合わないユーザ向けに暫定対応策を用意する予定ですが、基本的にはシステムをIP網に移行することを推奨しています。補完策自体も現行サービスと完全に同等なサービス品質にはならないそうです。
移行後のイメージは以下のとおりです。IP網に移行するうえで１番気になるのは遅延です。検証データによると現行比で1.1~4.0倍程度のデータ遅延があるそうです。現在のサービスがIP化による遅延を許容できるか検討が必要です。許容できない場合はサービス自体のリプレイスを検討する必要があります。
NTT東西は検証環境を用意しており、配送費等は別として基本的に無償で利用出来ます。実際の検証はすべてユーザで実施する必要がありますが、現状のサービスがIP化に耐えられるか、一つの指標になるかもしれません。また、以下のリンク先に一部の検証結果を記載しています。リンク先にも記載されているとおり、NTTの検証結果でもIP化による遅延が確認されています。よくよく見ると「通信可能なことが確認できました」と記載されている箇所も、注意書きで「ISDN回線利用時と比べ、処理時間が増加しています」とあります。
もともとデータ目的でINS回線を使用している場合、(金融系を除いて)バックアップ回線や低料金の変わりに低速度で問題ないサービスを利用している場合が多いため、IP化による遅延が問題ない可能性もあります。現在のサービスの許容範囲を確認し、必要であればリプレイス提案をしていく必要があります。今後MVNOに対応したLTEルータなんて出てきたら選択肢が増えていいんですけどね、、、と思いましたが結局急なサービス終了が怖くて三大キャリアを選んじゃいそうです。。。
iOS版 AnyConnectについて
現在公開されているiOS版「AnyConnect (ver.4.0.07070)」は従来の同アプリと名称が異なります。以前の同アプリは「Cisco Legacy AnyConnect」としてver.4.0.05069が配布されています。
今後、同アプリは「AnyConnect」がスタンダート版になります。新しい「Any Connect」を使用する場合、新たにインストールが必要でかつ設定や証明書も引き継がれません。また、Emailやブラウザからの証明書取得が出来なくなりました。AnyConnect UIからの手動インストールかURI handlerで取得して下さい。
「Cisco Legacy AnyConnect」と「Any Connect」の同時インストールは非推奨です。「Cisco Legacy AnyConnect」は今後メンテナンスがされないため、同アプリを利用しているクライアントには新verに移行するように調整が必要です。
SymantecのSSL/TLS事業売却について(2)
気づいたら進展していました。。。
2017/8/2にSymantecはSSL/TLS事業を含むPKI系の事業をDigCertへ売却することになりました。本件でのGoogleの対応が決まりました。
ざっくり書くと以下のようになります。
- 発効日が2016/6/1以前で有効期限が2018/3/15以前の場合は対応不要
- 発効日が2016/6/1以前で有効期限が2018/3/15以降の場合は再発行が必要
- 発効日が2016/6/1以降で有効期限が2018/9/13以前の場合は対応不要
- 発効日が2016/6/1以降で有効期限が2018/9/13以降の場合は再発行が必要
注意点として2.の場合はSymantecのCAで再発行しても問題ありませんが、4.の場合はDiGiCertの新しいCAである必要があるため、2017/12/1以降に発行が必要です。また、必ずしも再発行する必要はなく更新で対応できる場合もあります。再発行しか選択肢がないか検討して下さい。
今回の対象となる証明書はSymantecグループ全体が対象のため、下記の証明書も含まれるので注意して下さい。
緊急の対応ではないとはいえ、手間がかかることには変わりありません。気づかないうちにChomeでエラーが出てもたまらないので、今のうちに対象案件の洗い出しとコスト計算をしておいたほうが良さそうです。
WPA2の脆弱性「KRACK」
2017/10/16 WPA2の脆弱性が発表されました。本脆弱性の対象はWPA/WPA2を使うほぼすべてのデバイスが対象です。適切なアップデートを適用していない場合、攻撃者にトラフィックを解析される恐れがあるため、WiFiの使用は控えたほう良いでしょう。
特に意識してほしいのは本脆弱性は必ずしもAP側に問題があるとは限りません、一部の機能を無効化していれば影響を受けない場合があります。どちらかというと無線クライアント側での対処が必要な場合が多いと認識してください。
まず攻撃者は既存のWiFiのSSIDと同一のSSIDを持つAP設置し、標的となる人を定めます。標的となった人が本来接続したいSSIDに接続しようとしたところに、特別なパケットを送りつけることによって通信チャネルを切り替え、同一のSSIDを持つ偽WiFiへ接続先を切り替えることが可能です。
本脆弱性は攻撃対象WiFiにアクセスできる場所にいる必要があるため、遠隔からの攻撃は出来ません。ただし、AESの脆弱性ではないためパスワードの変更は意味を成しません。現状ではWPA2以上にセキュアな方式はないため、WEP等に変更するのは危険です。本脆弱性はAPだけでなく、無線クライアントもアップデートの対象です、クライアント側のアップデートを忘れないようにしましょう。また、VPNやHTTPSによって適切な暗号化をしている場合は回避できますが、暗号化が正しく実装されていないWebサイトでは偽のアクセスポイントに「SSLstrip」と呼ばれるツールを設置するだけで、ブラウザーの通信をHTTPSからHTTPに強制的に切り替えることが可能です。そのため、脆弱性に対処しているか判断できない公衆無線LAN等には接続しないほうが良いでしょう。また、VPNもVPNサーバにはトラフィックログが保存されている可能性があるため、無料のVPNサービスの利用にも注意が必要です。どちらも不安な場合はおとなしく有線LANを使うしかなさそうです。
この手の脆弱性は今後も出てくると考えられます、Iotの製品選定時は特にそうですが、パッチ提供が遅い製品や、数年でアップデートが打ち切られることが多い国内Android製品は（少なくとも）商用利用は避けたほうが良いかもしれません。
ArubaOSの場合、Mesh機能または802.11rを有効化していると脆弱性の対象になりますが、デフォルトでは無効となっています。InstanstOS(IAP)の場合はWi-Fi Uplink機能も対象になりますが、これもデフォルトでは無効です。Ciscoの場合、802.11r Fast Transitionを無効にする必要があります。デフォルト値はAireOS8.3.111.0未満が無効で、8.3.111.0以降は有効となっています。Mobility Expressでは8.2以前が無効、83.以降は有効となっています。メーカに関わらず802.11rを有効化している場合はVoipのために使用している可能性が高いため、無効化したときの影響範囲（ローミングの劣化）に注意して下さい。
主要なメーカの対応状況は以下のサイトに各リンクがまとめられています。
Aruba日本語フォーラム
いつの間にかArubaの日本語フォーラムが出来ていました。閲覧するだけならアカウントも不要で、一般的な見解ではありますが、Aruba従業員からも回答がされています。気になることがあれば調べてみると答えが見つかるかもしれません。
