Mozillaでは、個人情報流出の発生したWebサイトにFirefoxでアクセスした際、その旨をユーザーに通知する機能の開発を進めているそうだ(Firefox Nightly Newsの記事、 The Registerの記事、 BleepingComputerの記事、 GitHub - BreachAlerts)。

この機能はアカウント情報流出を確認できるWebサイト「Have I been pwned?」のAPIを利用したものだ。現在、Firefox 58/59に拡張機能として追加可能なプロトタイプがGitHubで公開されている。目標としては個人情報流出の被害が最近発生したWebサイトを訪問するユーザーに情報提供し、ユーザーが希望すれば電子メールでの通知サービスも利用可能にすることとなっている。

ただし、プロトタイプではadobe.comやlinkedin.comのように、個人情報流出の発生から時間が経ったWebサイトでも通知が表示されるという。また、電子メールでの通知サービスを利用する場合、電子メールアドレスがHave I been pwned?に送られることになるため、プライバシーの問題が懸念される。このプロジェクトはまだ初期の段階だが、ユーザーのプライバシーに影響を与えずに有益な機能を提供する方法の模索が行われているようだ。

Intelの第6〜8世代CoreプロセッサやXeon、Pentium、Celeronプロセッサなどに脆弱性が発見された（Intel、4gamer）。

Intelの最近のCPUには「Intel Management Engine」などの管理機構が搭載されているが、今回の脆弱性はそれらに関するもののようだ。これによって外部からシステムを遠隔操作される可能性があるという（US-CERTの発表）。

Intelは対応として「intel-sa-00086 検出ツール」という使用しているシステムに脆弱性があるかどうかを判断できるツールを公開した。ただ、このツールでは脆弱性があるかどうかの判断のみが可能で、修正にはPCやマザーボードメーカーが提供するファームウェアアップデートが必要だという。

Windows 8以降でEMETを使用する場合や、Windows 10 Fall Creators UpdateのWindows Defender Exploit Protectionを使用する場合、「必須ASLR」を有効にしても適切なランダム化が行われないとして、CERT/CCが問題の詳細と緩和策を公開している(Vulnerability Notes Database VU#817544、 BetaNewsの記事、 BleepingComputerの記事、 Will Dormann氏のツイート)。

モジュールに割り当てるメモリーアドレスをランダム化して攻撃者によるデータの悪用を困難にするASRLだが、Windowsの既定では「/DYNAMICBASE」オプションを使用してコンパイルされた(ASLRの適用をオプトインした)モジュールにのみ適用される。必須ASLRを有効にするとオプトインしていないモジュールにもASLRを強制することが可能となるが、エントロピーを確保するにはボトムアップ型のメモリー割り当てでベースアドレスをランダム化する「ボトムアップASLR」も重要だ。

Windows 8以降では必須ASLR/ボトムアップASLRがOSの機能に組み込まれているため、EMET/Exploit Protectionはオプションをレジストリに設定する機能のみを提供する。設定が格納されるレジストリ値は「HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel」の「MitigationOptions」という値なのだが、EMET/Exploit Protectionともにデフォルトではこの値が作成されない。

Exploit Protectionのデフォルトでは必須ASLRが「既定でオフにする」、ボトムアップASLRが「既定でオンにする」に設定されている。必須ASLRはMitigationOptionsが存在しなければオフになるため問題ないが、ボトムアップASLRはUI上の表示に反してオフになっている。CERT/CCでは有効な設定を含む.regファイルの内容を公開しているが、Exploit ProtectionでボトムアップASLRをいったんオフにし、再度オンにすることで有効なレジストリ値をセットすることも可能だ。なお、「既定値を使用する(<オン>)」を選択した場合は有効なレジストリ値がセットされないので注意が必要だ。

あるAnonymous Coward 曰く、

シャープのロボット掃除機「COCOROBO」シリーズに、セッション管理不備の脆弱性が確認されたとのこと（JVN#76382932 ロボット家電 COCOROBO におけるセッション管理不備の脆弱性）。

この問題を利用することで、同一LAN内の第三者が別のユーザーに成りすまして製品にアクセスできる可能性があるという。すでに修正済みファームウェアが公開されているとのことで、アップデートが推奨されている。

さまざまな航空会社で採用されているジェット旅客機「Boeing 757」にはサイバー攻撃に対する脆弱性があるという（Avionics、Sputnik、Slashdot）。

米国土安全保障省（DHS）がセキュリティ関連イベントで発表したもので、2016年9月に調査を行った時点では遠隔から同機のシステムへの侵入や外部からの操作に成功していたという。システムへのアクセスにはRF無線通信を使用したようだ。

ただ、航空機のシステムの脆弱性修正には非常にコストがかかるという問題があるようだ。そのため、外部からの攻撃を想定していない旧型の航空機については脆弱性が放置されたままになっているという。

Kaspersky Labは16日、同社の製品が原因で米国家安全保障局(NSA)の機密情報がロシア側へ渡ったと10月に報じられた件について、調査結果を発表した(Securelistの記事、 Ars Technicaの記事、 V3の記事)。

Kaspersky Labでは10月下旬、機密情報流出の原因となったNSA契約スタッフとされる人物の自宅PCが多数のマルウェアに感染していたことや、NSAのマルウェアが検出されたためにサンプルとして同社へ送られた7-ZipアーカイブにNSAの機密情報ファイルやソースコードも格納されていたことなどを含む調査結果を事前発表していた(過去記事)。今回の発表はさらに踏み込んだ内容となっている。

閉じたまぶたの上にブラックオリーブなどを載せ、iPhone XのFace IDに目が開いていると誤認識させるという実験動画を顔認証アプリ「ZoOm」の開発元FaceTecが公開している(動画[1]、 [2]、 FOODBEASTの記事)。

iPhone Xでは画面注視認識機能がデフォルトで有効になっており、Face IDを使用する際に目が開き、意識して画面を見ているかどうかを識別する。これにより、眠っている間に無断でロック解除されることを回避できるとされる。画面注視認識機能は設定で無効化することも可能だが、当然ながら実験では有効に設定されている。

Microsoftは14日、Windows 10 バージョン1511の更新プログラム提供期限を6か月間延長することを明らかにした(Windows for IT Prosの記事、 Neowinの記事、 On MSFTの記事、 Windows Centralの記事)。

バージョン1511は2015年11月に一般リリースされたWindows 10初の大規模アップデートで、10月10日のサポート終了が予定されていた。サポート期間の延長は「サービスとしてのWindows」への移行がまだ完了していない企業に時間的な余裕を提供するためとのことで、Windows 10 EnterpriseとWindows 10 Educationが対象となる。

Windows for IT Prosの記事では2018年4月まで延長とのみ記載されているが、月例更新が提供される第2火曜日の4月10日に最後の更新プログラムが提供されるとみられる。なお、Windowsライフサイクルのファクトシートでは、現在のところ2017年10月10日サポート終了のまま更新されていない。また、バージョン1607(Anniversary Update)のサポート終了は「2018 年 3 月 (仮)」となっている。このままではバージョン1511よりも先にサポートが終了することになるが、今後変更される可能性もある。

総務省が暗号化されていない公衆無線LANアクセスポイントを規制する方針だと報じられている（産経新聞）。

暗号化されていない公衆無線LANでは、第三者が通信内容を盗み見できる可能性があるといった問題点がある。そのため、今年中に課題をまとめ、来年度に公衆無線LAN事業者向けのガイドラインを改定するという。

なお、産経新聞の記事では「パスワード不要の公衆無線LANアクセスポイントを原則として規制」とされているが、パスワード不要という点が問題なのではなく、暗号化されない無線LANを問題視している模様。

headless曰く、

Googleは一般ユーザー向けのAndroidアプリでユーザー補助サービスの使用を禁止する方針のようだ（Android Police、The Next Web、9to5Google、Global Accessibility News）。

Googleでは「ユーザー補助サービスへのバインド（BIND_ACCESSIBILITY_SERVICE）」パーミッションを要求するアプリの開発者に対し、障害を持つユーザーを補助する目的でユーザー補助サービスを使用しているかどうかの確認を求める通知を送っているそうだ。このパーミッションを要求する場合、それがどのように障害を持つ人の役に立つのかをユーザーに説明する必要があり、30日以内に対処しなければGoogle Playから削除されるという。このほかの対処法としてはパーミッション要求を削除するか、アプリの公開を取りやめるかという選択肢が提示されているとのこと。

Androidのユーザー補助サービスを使用すると別のアプリに表示されているテキストやユーザーの操作内容などを取得できるなど大幅に機能を拡張できる一方、セキュリティリスクも高まることになる。Android DevelopersサイトのAPI解説にユーザー補助サービスの使用目的を制約する記述はもともとなかったが、最近になって障害を持つユーザーを補助する目的でのみ使用するべきとの記述が追加されている。「Building Accessibility Service」にも同様の記述が最近追加されているが、ユーザー補助サービスによる機能追加が役立つ場面として、自動車を運転している時や子供の世話をしている時、非常に騒がしいパーティーに出席している時といった例も挙げられている。

産業技術総合研究所（産総研、AIST）が開発した「AISTパスワード認証方式」および「AIST匿名パスワード認証方式」が国際標準化された（産総研の発表、PC Watch）。

「AISTパスワード認証方式」はパスワードだけで認証を行える技術で、ISO/IEC 11770-4:2017として標準化された。また、「AIST匿名パスワード認証方式」はユーザーを特定せずに特定の権限や属性を有していることを認証できる技術で、「ISO/IEC 20009-4:2017」として標準化された。

AISTパスワード認証方式は、既存の認証方式と比べて少ない計算量で認証を実現できるのが特徴。また、AIST匿名パスワード認証方式は容易に匿名で権限の認証ができるため、プライバシーの確保などに有用だという。

headless曰く、

ウイルス対策プログラムの「検疫」機能を悪用し、ローカルでの権限昇格を可能にする攻撃手法「#AVGater」について、オーストリアのITセキュリティプロフェッショナルで考案者のFlorian Bogner氏が解説している（#bogner.sh、Ars Technica）。

攻撃の仕組みは管理者権限でサービスを実行するターゲットアプリケーションのDLLと同名の攻撃用DLLを検疫から復元する際に、ディレクトリジャンクションを利用して正規のDLLを置き換えるというものだ。攻撃の流れとしては、ターゲットのインストールフォルダーと同名のフォルダーに攻撃用DLLを格納しておき、ウイルス対策プログラムに検出させて検疫に送る。このフォルダーをターゲットのインストールフォルダーのディレクトリジャンクションと置き換え、攻撃用DLLを復元すればターゲットのDLLが置き換えられる。あとはシステムを再起動すればサービスが起動して攻撃用DLLを読み込み、「DllMain」が管理者権限で実行されることになる。

ウイルス対策プログラムが検疫からファイルを復元する処理はSYSTEM権限で実行されるため、標準ユーザーでも特権の必要な場所にファイルを書き込むことが可能になる。Emsisoft Anti-MalwareとMalwarebytes 3（いずれも既に対策済み）を使用した実験では、ウイルス対策プログラム自体の「version.dll」を攻撃用DLLに置き換えてコードを実行することに成功したという。Kaspersky（こちらも対策済み）の場合はクラッシュして実行できなかったようだが、別のサービスのDLLは置き換え可能だったとのこと。

Bogner氏が問題をAVベンダーへ報告したのは昨年のことで、既にディレクトリジャンクションへの復元をブロックするなどの対策が進められているようだ。記事では上述の3社のほか、Trend MicroとCheck Point（ZoneAlarm）、IKARUS Security Softwareが対策済みベンダーとして挙げられている。今回の研究結果は10日にオーストリアで開催されたIT-SECX 2017で発表されている。

なお、Windows 10（バージョン1709）のWindows Defenderでは復元時にUACのダイアログボックスが表示され、ディレクトリジャンクションへの復元もできなかった。何年も前の古いバージョンのAVGでもディレクトリジャンクションへの復元ができないなど、復元時の動作はウイルス対策プログラムごとに異なるようだ。

あるAnonymous Coward 曰く、

米国テキサス州で11月5日、教会で銃を乱射して子供を含む26人の命を奪った銃乱射事件が起きたが、米FBI（連邦捜査局）はこの犯人が所有していたiPhoneのロックを解除できなかったことが話題になっている（iPhone Mania、nrp、The Washington Post、Slashdot）。

犯罪事件の容疑者が使用していたiPhoneのロック解除についてはたびたび話題となっており、過去には捜査目的で容疑者のiPhone 5sやiPhone 5cのロックを解除したという事例がある。しかし、今回はロック解除ができなかったようだ。担当捜査官は「私はその端末が何かを語るつもりはない。買おうとする人物がみな悪人だなどとは言いたくはないから」と説明し、暗号化技術に対する批判もあったようだ。こうしたことから、スマートフォンの暗号化解除議論が再燃しそうな様相を見せている。

ただ、今回FBIはAppleに対してロック解除を依頼しなかったとも報じられており、FBIの行動に批判的な意見もある。48時間以内にAppleと連絡を取り合っていれば解除できた可能性があるというものだ。専門家は犯人の端末がTouchID対応のiPhoneであったならば、FBIが事件発生2日以内に死者の指を使って解除を試みていれば、解除に成功していた可能性は高いとしている。

GoogleはAndroidの「KRACK」脆弱性を11月のセキュリティパッチで修正しているが、Nexus/PixelデバイスにはKRACK対策を含むパッチが12月まで提供されないそうだ(Ars Technicaの記事)。

10月に公表されたKRACK(Key Reinstallation AttaCK)はWPA2の脆弱性で、偽アクセスポイントを使用してWi-FiクライアントにWPA/WPA2の暗号鍵を再インストールさせることで通信内容の復号が可能になる。wpa_supplicant 2.4以降を使用するバージョンのLinuxへの影響が特に大きいとされ、Androidでは6.0以降のすべてのバージョンにおける影響が大きいとして注意喚起されていた。

GoogleがAndroidのKRACK脆弱性を修正したのはセキュリティパッチレベル2017-11-06だが、11月に提供されるNexus/Pixelデバイス向けのセキュリティパッチはレベル2017-11-05までとなっている。その結果、OEMメーカーがKRACK対策パッチを続々と提供するのに対し、GoogleブランドのすべてのAndroidデバイスは12月まで対策されないことになる。これについてArs Technicaの記事では、KRACK脆弱性のAndroidに対する影響は大したことがないと指摘する。

maia 曰く、

米国土安全保障省(DHS)は米運輸保安庁(TSA)による空港の保安検査で武器や爆発物を発見できるかどうかの覆面調査を時々行っているが、最新の調査で約8割が検出されなかったという(Daily Mail Onlineの記事)。

今年の6月下旬にミネアポリス-セントポール国際空港で行われた調査では18個中17個を検出できず、失敗率約94％だったので少しは改善したかもしれない。2015年の覆面調査では70個中67個通過したので失敗率は約96％だった。

ちなみに2015年に米国の空港では銃2,653丁が発見されており、その83％は弾が装填されていたという。

今回の調査結果は非公表であり、ABC Newsが関係者に失敗率は80%程度かと尋ねたところ、「そんなものだ」との回答を得たとのこと。TSAでは空港の保安検査場で発見した武器の数を毎週ブログで公表しており、ほぼ毎週80丁前後の銃が発見されている。50丁を下回る週は少なく、150丁を超える週もある。2016年に保安検査場で発見した銃の数は3,391丁で、83%(2,815丁)が装填されていたとのことだ。