headless 曰く、

Googleが安全保障上の問題を理由に、Android OSをHuaweiに対する輸出制限から除外するよう米商務省と交渉しているとFinancial Timesが報じている(VentureBeatの記事、 Ars Technicaの記事、 The Vergeの記事、 Bloombergの記事)。

米商務省は5月15日、米国のテクノロジーを販売・移転するのに産業安全保障局(BIS)のライセンスが必要となるエンティティリストにHuaweiを追加したが、5月20日には90日間の一時的な一般ライセンス(TGL)を発行している。これにより、Huaweiは8月18日まで輸出管理規則(EAR)で制限されない米国のテクノロジーを個別のライセンスなしで入手可能となっており、今後商務省ではTGLの期限を延長するかどうかの判断を行なう。

Googleが交渉しているのは、TGLの延長またはライセンスの免除だという。Financial Timesの情報提供者によれば、GoogleがAndroidを輸出制限から除外すべきと主張する根拠は以下のようなものだ。HuaweiがAndroidを入手できなくなればHuaweiはAndroidのオープンソース部分をフォークしたハイブリッド版のAndroidを開発することになる。ハイブリッド版はGoogle版と比べてバグが多くなることが予想され、Huaweiの端末が(特に中国により)ハッキングされる可能性が高まるとのこと。

GoogleはFinancial Timesに対し、商務省の措置を確実に順守するため同省と連携しているとしたうえで、同社が注力しているのは既存のHuawei端末を利用するGoogleユーザーのセキュリティを保護することだと述べたとのことだ。

一方、FacebookがWhatsAppやInstagramを含む同社のアプリについて、Huawei製端末へのプリインストールを停止したとReutersが報じている。ReutersではHuaweiに新たな一撃が加わったと述べているが、Android Policeの記事では最近のHuaweiに関するニュースの中で、ようやくいいニュース(ゴミアプリがプリインストールされなくなる)が出てきたと評している。

Microsoftがストアアプリ向けに提供している広告SDKを通じた不正広告攻撃キャンペーンが4月から発生しており、1か月以上経過しても対策は行われていないようだ(Softpediaの記事、 The Registerの記事、 Bleeping Computerの記事、 Born's Tech and Windows Worldの記事)。

不正広告攻撃の内容としては、アプリのバナー広告に触れなくてもデフォルトブラウザーでWebページが開き、「賞品が当たった」「ウイルスに感染している」などと表示されるというもの。サードパーティー開発者によるアプリだけでなく、Microsoft製のアプリや、Outlook.comなど広告の表示されるMicrosoftのWebサイトでも発生しているらしい。MSDNのフォーラムでは4月17日にアプリ開発者が報告しており、4月19日にはMSDNのコミュニティサポート担当者が広告チームに伝えると回答している。しかし、その後の更新情報はなく、開発者やユーザーから不満の声が数多く投稿されている。修正予定なしとSDKチームから聞いたとのコメントもみられる。当初の報告はドイツのユーザーからのものだったが、英国やオランダからの報告も出ているほか、4月末にはフランスでも発生していたようだ。

Microsoftコミュニティーにボランティアのモデレーターが投稿した記事によれば、不正広告ページの中にはWindows Defender SmartScreenでブロックされるものもあるが、ドメイン単位でのブロックは行われていないという。また、偽のウイルス警告ページがダウンロードページにリダイレクトする偽セキュリティアプリはMicrosoftが望ましくない可能性のあるアプリケーション(PUA)に区分しているものの、Windows Defenderがマルウェアとして検出することはないそうだ。

MicrosoftはThe Registerに対し、同社がユーザーに無断でメッセージを送ることはなく、そのようなメッセージが表示されたらブラウザーのウィンドウを閉じればいいと述べるのみで、広告SDKの問題については触れなかったとのことだ。

Anonymous Coward曰く、

4月にスタートした、株式会社ZIGが運営するVTuberファンコミュニティサイト「MeChu」で利用者のユーザー名およびメールアドレス、パスワードが漏洩する事件が発生した（ニュースリリース、Twitterでの告知、ZIPによる「お詫びとご報告」1、「お詫びとご報告」2）。

管理者向け画面のソース内に全ユーザーのものと思われるユーザー名、メールアドレス、「暗号化」されたパスワードが含まれていたというもので、パスワードはエンコードされていたものの容易に復号できたという。記事内で使用しているツールから、Base64でエンコードされていただけのものと見られている。

広告ブロック拡張機能の動作を制限するものだと批判されているChrome拡張機能プラットフォームのマニフェスト新バージョンManifest V3について、広告ブロックをだめにするのではなく、より安全にするものだとChrome拡張チームのDevlin Cronin氏が説明している(Google Security Blogの記事、 VentureBeatの記事、 The Registerの記事、 Neowinの記事)。

Manifest V3のドラフトではブロッキング用途でのWeb Request API使用が非推奨(かつ制限される可能性あり)となり、ブロッキング用にはDeclarative Net Request APIが新たに追加される。Web Request APIによるブロッキングではページコンテンツを受け取った拡張機能が広告を除去するのに対し、Declarative Net Request APIでは拡張機能からブロッキング処理内容を受け取ったChrome側が広告を除去することになる。これにより処理は高速化するが、複雑なブロッキングアルゴリズムは使用できなくなる。ルールの数も3万件に制限され、現在広く使われているルール(EasyListだけでも7万件を超える)をすべて使用できない点も批判されている。また、5月下旬にはChrome拡張開発者支援を担当するSimeon Vincent氏が企業ユーザーにはWeb Request APIのブロッキング機能を引き続き提供すると述べたことも批判の対象となった。

Cronin氏はブロッキングをWeb Request APIからDeclarative Net Request APIへ移行すべき理由としてパフォーマンス向上に加え、プライバシーの改善を挙げている。Web Request APIではユーザーの個人情報を含む可能性のあるページコンテンツへのアクセス許可を拡張機能へ与える必要がある。一方、Declarative Net Request APIでは拡張機能のリクエストに応じてChrome側でブロッキングを実行するため、拡張機能に個人情報へのアクセス許可を与える必要がなくなるとのこと。なお、ブロッキングルールについては、グローバルで最大15万件に拡大する計画をChromiumブログでVincent氏が明らかにしている。

headless曰く、

Microsoftが5月の月例更新で修正したRemote Desktop Servicesの脆弱性（CVE-2019-0708）について、影響を受ける旧バージョンWindowsにパッチを適用するよう呼び掛けている（MSRCのブログ記事、The Verge、Ars Technica、BetaNews）。

BlueKeepとも呼ばれるこの脆弱性は、悪用するとリモートからの任意コード実行が可能になるものだ。Microsoftでは脆弱性をワームに転用することが可能であり、SMBv1の脆弱性を悪用するWannaCryのようにネットワークに接続したコンピューター間での感染拡大が起こる可能性があるとしてパッチ公開時に注意喚起していた。今回改めて注意喚起したのは、5月28日にErrata Securityが公表した「BlueKeep脆弱性が修正されていないコンピューターが100万台近くインターネットに直接接続している」という調査結果がきっかけとみられる。

Microsoftによれば、現在のところワームによる攻撃は確認されていないものの、脆弱性を狙った攻撃が可能であることは間違いないという。実際には脆弱性を悪用するマルウェアが出現しない可能性もあるが、確実とはいえない。WannaCryの元になったEternalBlueエクスプロイトの場合、Microsoftがパッチを提供してから1か月後に公開されたが、さらにその1か月後にWannaCryの大規模感染が発生した。つまり、パッチの提供開始から2か月経過しても未適用の環境が多かったということになる。そのため、同様な事態になることを避けることが注意喚起の目的のようだ。

Anonymous Coward曰く、

広告配信技術などを手がけるオメガがリリースしている広告配信技術を搭載したスマートフォン向けソフトウェアキーボード（キーボードSDK）を使ったアプリで、ユーザーが入力したキーワードが同社のサーバーに無断で送信されていることが確認されたという（@rioriostのモーメント、Guestのnote）。

オメガ社によると、このキーボードSDKは背景などをカスタマイズできるソフトウェアキーボードを作成するためのSDKで、「オメガ株式会社独自の広告配信技術が搭載されている」という。これによってアプリ作成者は広告配信による利益を得ることが可能。同社は独自に取得したデータを活用した広告配信を行っているとアピールしていた（TechCrunch）。

発端はオメガのキーボードSDK営業資料がリークされたことで、「競合他社含む全てのアプリ上で起動」「入力・使用アプリ情報を収集・分析可能」との謳い文句から、事実上のキーロガーではないかとの疑惑が持ち上がり、検証が進められていた。

ソースによると、このキーボードライブラリは入力されたキーそのものではなく特定のキーワードと対象のアプリ情報を送信していたようだ。特定のキーワードには数字や英単語が多数含まれているため、結果的にパスワード、クレジットカード番号などの個人情報が収集され得る状態にあったという。

情報の無断送信が行われていたとされているのは、「ANYTYPE」や「moppyキーボード」、「USAVITCHキーボード」、「瞬間日記」、「PUSH!」、「PicoSweet」。これらのアプリでは入力内容（パスワード、クレジットカード番号などの個人情報）の収集は一切行わないとの宣言がされていた。

headless曰く、

Windowsの更新プログラムではBluetoothデバイスとのペアリングや接続ができなくなるバグも発生しているが、6月の月例更新では脆弱性のある一部のBluetoothデバイスからの接続を拒否するよう修正を行ったそうだ（KB4507623、SlashGear、Softpedia）。

該当する脆弱性CVE-2019-2102は、Bluetooth Low Energy（BLE）規格で提供されているサンプルのLong Term Key（LTK）をデバイスが実際のLTKとしてハードコードしている場合、ペアリングされたAndroidデバイスに対し近くにいる攻撃者がキーストロークを送信可能というものだ。Androidで影響を受けるのはAndroid 7.0～9で、セキュリティパッチレベル2019-06-01以降で修正（A-128843052）されている。

Microsoftによると、更新プログラムをインストールすることで、既知のキーを使用して通信を暗号化するデバイスのすべてが影響を受ける可能性があるとのこと。更新プログラムのインストール後にBluetooth接続の問題が発生した場合、デバイスの製造元に更新プログラムの有無を問い合わせるよう求めている。

この修正が含まれるのはWindows 10/Server 2016/Server 2019の累積更新プログラムおよび、Windows 8.1/Server 2012/Server 2012 R2/Embedded 8 Standardのマンスリーロールアップとセキュリティのみの更新プログラム。対象がBLEデバイス限定とは書かれていないが、Windows 7はBLEに対応していない。

Anonymous Coward曰く、

ゲームの未発表情報を次々とリークしていたTwitterユーザーに対し、任天堂の弁護士からリークをやめるよう連絡が来たそうだ。このユーザーは素性を明かしておらず、さらに自分の国籍とは異なる国、登録していない住所にいたにも関わらず、任天堂の弁護士から電話で連絡が来たという。

これを受けてこのユーザーは任天堂関連のリークは止めるとしたものの、任天堂以外のリークについては今後も行っていくと述べている模様。

Medtronicのインスリンポンプで近距離から認証なく無線アクセス可能な脆弱性(CVE-2019-10964)が見つかり、米国ではリコールが行われている(Medtronicのお知らせ、 ICSMA-19-178-01、 The Registerの記事、 SlashGearの記事)。

対象となるMiniMed 508およびMiniMed Paradigmでは無線を使用して血糖値モニターなどに接続する機能が搭載されているが、適切な認証の仕組みが実装されていない。攻撃者は脆弱性を悪用することで、近距離から無線アクセスして設定変更やインスリン投与の制御が可能になる。インスリンが過剰に投与されれば低血糖症、インスリン投与量が不足すれば高血糖症や糖尿病性ケトアシドーシスを引き起こす可能性がある。

米国内で利用する患者および医療関係者に対しては脆弱性のない製品への交換が呼びかけられており、米国外の利用者に対しては各国・地域に合わせた手順を含む通知が送られるとのこと。一部の機種では特定のソフトウェアバージョンにのみ脆弱性が存在するものの、ソフトウェア更新では対応できないようだ。

このほか、すべての利用者に対し、インスリンポンプ及び接続した機器を常に制御下に置くこと、シリアル番号を他人に知らせないこと、ポンプからの通知や警告に注意を払うこと、意図しない投与はすぐキャンセルすること、などの対策が推奨されている。

NASAのジェット推進研究所（JPL）で、ネットワーク内に無許可で設置されていたRaspberry Pi端末を経由した外部からの不正アクセスがあり、それによってJPL内の多数のデータにアクセスされるという事件が発生していたことが明らかになった（ITmedia）。

この端末は2018年4月に接続されたもので、使用目的やその設置者は不明だという。

JPLのネットワークではネットワーク内に接続する端末をデータベースに登録して管理するルールだったが、問題の端末は登録が行われていなかったという。また、それ以外にもNASAのシステムではセキュリティ的な問題が多数存在しているとも指摘されているそうだ。

NASAに対しては、昨年サイバー犯罪集団による攻撃のターゲットになっているとの報道があった（CNET Japan）。