SB, NEC 記事

piyokangoさんとこの、まとめ記事リンク

・ロシア職員関与と報じられたソフトバンク元社員の社外秘情報持ち出しについてまとめてみた (01/27)

https://piyolog.hatenadiary.jp/entry/2020/01/27/064522

・防衛装備品情報も影響を受けたNECへの不正アクセスについてまとめてみた (01/31)

https://piyolog.hatenadiary.jp/entry/2020/01/31/051958

これも手口が詳らかになれば、大いに参考になる。続報期待案件。プレス発表あり（↓）

・当社の社内サーバへの不正アクセスについて (01/31)

　https://jpn.nec.com/press/202001/20200131_01.html
　『　2016/12、初期侵入では検知できなかったが、
　　　2017/06、感染PCの隔離・調査、不正通信先の検知・遮断、
　　　2018/07、不正通信の暗号解読し、事実判明』

　検知までに半年余り、解読に一年余り掛かったものの、

　ほぼ状況は制御下にあった、と読める。

　他に未発表／未検出の重大事実が無ければ、封じ込め成功事例と言っても良さそう。

--> 02.01 追記ここから

・NECにサイバー攻撃　防衛省関連ファイル約2万7000件に不正アクセス (01/31)

　https://www.itmedia.co.jp/news/articles/2001/31/news088.html

『NECは「不正ログインを受けたことについては18年7月以降、防衛省に説明し了解を得た。NECと防衛省の1対1の話であり、情報が流出した証拠もなく、被害が出ているわけでもないので発表しなかった」と説明した』

　1/31現在で他の重大ニュースに紛れて逃げ切った格好か

　--> 02.01 追記ここまで

ここからは別件。"NEC hack"でググるとSIP PBXのこんな記事が!?（↓）

・Best Practices to Avoid Getting Hacked on the NEC SL2100 and SL1100

https://midwesttechnology.uservoice.com/knowledgebase/articles/1908274-best-practices-to-avoid-getting-hacked-on-the-nec

ベストプラクティスとして、ファイアウォールで分離、関連ポートブロック等が紹介されている。

興味深い。

・NEC SV9100 Hacked?

https://forums.whirlpool.net.au/archive/3yk406n3

WeChatやSkype等の電話的ネットサービスが使いにくい地域では、安価な長距離電話（の転送の）サービス需要があるという事だろうか。

攻撃ツール”SIPVicious”でググると、こんな記事も（↓）

・SIP サーバの不正利用に関する注意喚起 (2013/09/06)

https://www.jpcert.or.jp/at/2013/at130036.html

 　

主要ブラウザにおける TLS 1.0/1.1 無効化について、いろいろ

・Chrome UI for Deprecating Legacy TLS Versions (2019/10/01)

https://security.googleblog.com/2019/10/chrome-ui-for-deprecating-legacy-tls.html
　『we still see over 0.5% of page loads using these deprecated versions』
　意外に少ないが、段階的に移行を促す策になったようで。

日本語版はこちら（↓）

・以前の TLS バージョンのサポート終了に伴う Chrome UI の変更点 (2019/10/25)

https://developers-jp.googleblog.com/2019/10/tls-chrome-ui.html

『2020 年 1 月 13 日より、Chrome 79 以降で、TLS 1.0 または 1.1 を使用しているサイトに「Not Secure」インジケーターを表示し、ユーザーに古い設定であることを警告します。』
『2020 年 3 月に Stable チャンネルにリリースされる予定の Chrome 81 以降では、TLS 1.0 または 1.1 を使っているサイトにアクセスしようとすると、ページ全体を覆うインタースティシャル警告が表示されて接続がブロックされます』

・主要ブラウザにおける TLS 1.0/1.1 無効化について (2019/12/03)

https://www.cybertrust.co.jp/blog/ssl/regulations/disable-tls10.html

『サーバーを運用、管理する立場の皆さま
　お使いのサーバーを TLS 1.2 以上（TLS 1.2 および 1.3）に対応させておく必要があります。』

・TLS 1.0 Weak Protocol (updated 2019/02/13)

https://www.tenable.com/plugins/was/112496
　Severity: Medium
　『

説明: リモートサーバーは、非推奨のTLS 1.0プロトコルを提供します。これにより、脆弱性が生じる可能性があります。
解決: 可能であれば、廃止されたTLS 1.0プロトコルの使用を回避するために、影響を受けるアプリケーションを再構成します。

』

・TLS Version 1.1 Protocol Detection (updated 2019/11/22)

https://www.tenable.com/plugins/nessus/121010
　Severity: Info
　『

リモートサービスは、TLS 1.1を使用して暗号化された接続を受け入れます。
TLS 1.1には、現在 推奨される暗号スイートのサポートがありません。
MAC計算前の暗号化、およびGCMなどの認証された暗号化モードをサポートする暗号は、TLS 1.1では使用できません
PCI DSS v3.2では、2018年6月30日現在でもTLS 1.1が許可されていますが、TLS 1.2の使用を強くお勧めします。
現在、TLS 1.1を完全に廃止するという提案がIETFの前にあり、多くのベンダーがすでにこれを積極的に行っています。

 　』

・関連

TLS1.0, 1.1 脆弱性 (2018/09/08)
　https://akasaka-taro.blogspot.com/2018/09/tls10-11.html

Amazon CEFのiPhoneハッキング疑惑について、各種記事

状況証拠はあるが、コード等、直接的な証拠は示されていない模様。

個人的教訓と興味は次の三点

①今どきのiPhone(+iOS) & 10億人以上が使うアプリでも、深刻なバグはある。

②どのような次善策があるか?

　タイムリーなソフトのupdateは当然として、
　（iPhone自体から情報が直接漏えいしたのでないとしたら）iTunesバックアップをしない、という次善策は有りえたか? それはそれで別のリスクがあるとしても。

③仮に特注マルウェアが直接要因だったとして、これはいつコモディティ化されるか?

　当面は、新聞社を所有するような資産家の方はお気を付けください。

追加詳報を待つ。

主に技術面紹介記事を挙げておきます。

・Amazon CEOのiPhoneハッキング疑惑についてまとめてみた (01/24)

https://piyolog.hatenadiary.jp/entry/2020/01/24/070652

『

• ベゾス氏が被害を受けたとされる個人端末はiPhone X A1901。
• FTIコンサルティングのフォレンジックではバックアップデータ暗号化への対応を行った記述*5が存在し、MotherboardはiTunesバックアップとその関連データの抽出を中心に解析が行われた可能性を指摘している。
• FTIコンサルティングのレポートの結論でも「NSO Groupのツールが使用された」とする断定的な表現は行われていない。スパイウェアや直接関連する証跡は示されておらず、送信データ急増と不可解な2通のメッセージを含む状況証拠より、専門家が可能性を指摘するにとどまっている。またPegasusは国家が使用するスパイウェアとして出した一例であり、Hacking TeamのGalileoの言及もある。

...

不可解な事象② 皇太子から届いたビデオファイル

• 2019年5月1日、WhatsAppを通じてベゾス氏宛に皇太子から届いたビデオファイルが発端と指摘されている。
• ビデオファイルはMP4ファイルで4.22MBだった。このファイル自体から悪性の痕跡となるデータは確認されていない。
• ファイルは暗号化されたダウンローダーより届いたもので、WhatsAppの仕様もあって取得されたコンテンツを解読し、ビデオのほかに悪性コード等が存在するかは確認できなかった。
• 参考情報としてWhatsAppは2019年5月13日に深刻な脆弱性（CVE-2019-3568）が存在するとして、修正対応を行っていた。この際、脆弱性悪用の関与が報じられていたのがNSO Groupだった。ただし、この時は発端となったのはURL付きのSMSで、今回の動画ファイルを参照させるというものではなかった

』 

・How could Jeff Bezos’ iPhone Hack Be Prevented (01/24)

　https://www.mobileiron.com/en/blog/jeff-bezos-iphone-hacking-explained

『私の推測によると、使用されたエクスプロイトはおそらくこれ（CVE-2019-11931）でした

・CVE-2019-11931 Detail 　https : //nvd.nist.gov/vuln/detail/CVE-2019-11931　概要: 特別に細工されたMP4ファイルをWhatsAppユーザーに送信することにより、WhatsAppでスタックベースのバッファオーバーフローが引き起こされる可能性がある。DoSまたはRCE(Remote Code Execution)を引き起こす可能性あり。

一般的なソーシャルアプリWhatsAppがiOS App Storeから合法的にダウンロードされ、マルウェアインプラントのPegasusスパイウェアが悪用の一環としてアプリにひそかに添付されたようです。実際のハッキングの時点では、ペガサススパイウェアはアプリ評価ソリューションによってゼロデイとして検出されなかった可能性があります。

このエクスプロイトが進化するとすぐに、MobileIron Threat Defense （MTD）があれば、特権の昇格（EoP）の脅威、システムの改ざん、ファイルシステムの変更の脅威が検出されたことでしょう。エクスプロイトがデバイスレベルに進化すると、MTDやMobileiron UEMは、RCE完了後のjailbreak状態も検出したことでしょう。（訳注、仮定法過去完了で自社製品をアピール） 会社のセキュリティポリシーが許すなら、セキュリティチームがWhatsAppバンドル、またはMTD管理コンソール内で構成されたWhatsAppの特定のバージョンをブラックリストに登録することをお勧めします。
ベゾス氏の携帯電話に統合されたエンドポイント管理またはモバイル脅威防御ソリューションがインストールされていなかったため、この攻撃を潜在的に阻止できませんでした。』

WhatsAppのもう一つの深刻な脆弱性と言えばこれ（↓）

・WhatsAppの脆弱性CVE-2019-3568についてまとめてみた (2019/05/15)

　https://piyolog.hatenadiary.jp/entry/2019/05/15/063000

『影響: VOIPのバッファオーバーフローの脆弱性。細工されたSRTCPパケットが標的の電話番号へ送信されるとリモートで任意のコードが実行される恐れ

対策: 最新版へのversion up。スパイウェアが入り込んでいた場合アップデートでクリアになるかは不明。

• 標的への攻撃は電話をかけるだけ。対象が電話に出る必要はなく不在着信だけで攻撃が成功する。
• 攻撃をする電話発信は通信履歴から消えてしまう場合もある。
• Financial TimesなどはNSO Groupが開発する「Pegusus」にこの脆弱性が利用されていたと報道。

』

出典元のBBC記事曰く『「非常に厳密に制御されたサンドボックスでアプリを実行するため、iOSではアプリを攻撃ルートとして使用することは制限されています」とWoodward教授は述べています。 「攻撃はWhatsAppの単なる破損であると考えていますが、分析はまだ進行中です。』

・How Jeff Bezos’ iPhone X Was Hacked (01/22)

https://www.nytimes.com/2020/01/22/technology/jeff-bezos-hack-iphone.html

※機械翻訳

https://translate.google.com/translate?hl=ja&sl=en&u=https://www.nytimes.com/2020/01/22/technology/jeff-bezos-hack-iphone.html&prev=search

『 使用されたマルウェアの種類など、電話への侵入については多くの技術的な謎が残っています。

モハメッド王子のアカウントからベゾス氏に送信されたビデオファイルを含むWhatsAppメッセージ …

彼に送信されたファイルを開いたかどうかについては詳述されていません ... 一部のマルウェアはファイルをクリックすることなくインストール可能 …

…

New York Timesが入手したレポートと追加のメモによると、14バイトの小さな悪意のあるコードの塊を含む無害に見えるビデオファイルを含む2018年5月のメッセージは、青天の霹靂でした。Bezos氏のiPhoneは、その後24時間で大量のデータの送信を開始し、通常のデータ使用量よりも約29,000％増加しました。

』

※今日の英語、晴天の霹靂 : come out of the blue

・Did Saudi Arabia hack the phone of Amazon CEO Jeff Bezos? (01/23)

https://www.techradar.com/news/saudi-arabia-reportedly-hacked-jeff-bezos-phone

※機械翻訳

https://translate.google.com/translate?hl=ja&sl=en&u=https://www.techradar.com/news/saudi-arabia-reportedly-hacked-jeff-bezos-phone&prev=search

『サウジアラビアの将来の王がアマゾンの創始者を標的にすることに個人的に関与したかもしれないという啓示は、ウォールストリートとシリコンバレーの両方からの反発をもたらす可能性があります。 真実ならば、王国を経済的に変革する彼の計画の一部として、より多くの西洋人投資家をサウジアラビアに連れて行くモハメッド・ビン・サルマンの努力を損なう可能性もあります。』

露見しなければ、或いは重要案件なら（他の国でも）起こりうることか。

記事、いろいろ 01/23

手元のメルマガ記事他。後で読む。リンク化省略

・指紋認証は「ゼラチン指」で突破できるのか？（2020年版）【前編】(01/22)

　https://internet.watch.impress.co.jp/docs/review/1227629.html

・iPhoneの指紋認証を「ゼラチン指」で突破！………じゃあ「指紋認証は弱い」と言えるのか？
　～指紋認証は「ゼラチン指」で突破できるのか？（2020年版）【後編】～ (01/24)
　https://internet.watch.impress.co.jp/docs/review/1227634.html
  『

結果は、実験した5つのiPhoneすべてで認証突破に成功した。
とはいうものの、実は今回成功したのは、テストした5人の指紋のうちの1人（私）だけ。
「ゼラチン指」では、企業向けの指紋認証装置は全く突破できなかった

DDS社の場合、特徴点、凹凸だけでなく、人が持つ誘電率を測定して、人間の誘電率と大きく異なる物質だと反応しないようにしている

スマホの画面ロックには、パスコードや9つの点を結ぶパターンロックなどもあるが、満員電車などでは背後から覗き見られるリスクがある。

  』

・対応遅れで被害を拡大、インシデント対応を外部専門家に任せるべき理由
　http://rd.itmedia.jp/2CKl

・“攻撃の自動化”であらわになる従来型WAFの限界、受動的対策から脱却するには
　http://rd.itmedia.jp/2CJU

・移行が進むハイブリッドクラウド、Azure環境特有のセキュリティ課題の解決策は
　http://rd.itmedia.jp/2CK3

・Office 365対策からサーバ対策まで、金融／保険業6社に学ぶサイバー攻撃対策
　http://rd.itmedia.jp/2CKv

・Office 365にも必要なデータ保護対策、“安心・安全”な業務環境の実現法は？
　http://rd.itmedia.jp/2CKH

・クラウド最大の脅威？　攻撃者を招き入れる「アクセス権限の誤設定」の防ぎ方
　http://rd.itmedia.jp/2CKJ

・2020年版セキュリティレポート：攻撃手法のトレンドと警戒すべきポイント
　http://rd.itmedia.jp/2CKq

・Office 365にも必要なデータ保護対策、“安心・安全”な業務環境の実現法は？
　http://rd.itmedia.jp/2CKH

・パブリッククラウド保護の7ステップ：データ分散によるリスクと回避策とは？
　http://rd.itmedia.jp/2CKs

・現地任せは禁物、海外拠点のガバナンス向上に欠かせない3つの機能とは？
　http://rd.itmedia.jp/2CKe

・海賊版が使われることも……、海外拠点のリスクが分かる「ICTチェックリスト」
　http://rd.itmedia.jp/2CKc

・海外で増すシャドーITの懸念、クラウドサービス単位のリスクをどう可視化する？
　http://rd.itmedia.jp/2CK9

・海外拠点のマルウェア感染を回避、グローバルセキュリティに必要な2つの可視化
　http://rd.itmedia.jp/2CKd

・「Amazon S3」の“うっかり”設定ミスを防ぐ「IAM Access Analyzer」とは
　http://rd.itmedia.jp/2CJF

・最新グローバルセキュリティ調査から学ぶ、サイバー攻撃の動向と対策
　http://rd.itmedia.jp/2CJM

メモ、Microsoftが過去14年間・2億5000万件分の露出

・Microsoftが過去14年間・2億5000万件分のカスタマーサービスの記録をネット上に流出させてしまったことが判明 (01/23)

https://gigazine.net/news/20200123-microsoft-css-data-leak/

・Report: 250 million Microsoft customer service and support records exposed on the web (01/22)

https://www.comparitech.com/blog/information-security/microsoft-customer-service-data-leak/

タイムラインは、

『 December 28, 2019 – The databases were indexed by search engine BinaryEdge

December 29, 2019 – Diachenko discovered the databases and immediately notified Microsoft.

December 30-31, 2019 – Microsoft secured the servers and data. Diachenko and Microsoft continued the investigation and remediation process.

Jan 21, 2020 – Microsoft disclosed additional details about the exposure as a result of the investigation.

』

で、通知～基本対応済まで２日、通知～発表まで約3週間。

・Microsoft Security Shocker As 250 Million Customer Records Exposed Online (01/22)

https://www.forbes.com/sites/daveywinder/2020/01/22/microsoft-security-shocker-as-250-million-customer-records-exposed-online/

※機械翻訳から抜粋、編集（↓）

https://translate.google.com/translate?hl=ja&sl=en&u=https://www.forbes.com/sites/daveywinder/2020/01/22/microsoft-security-shocker-as-250-million-customer-records-exposed-online/&prev=search

『　巨大なテクノロジー企業でさえ、データとストレージを正しく管理することがどれだけ難しいかを示している

…

他の組織が同様状況に陥ることを、どのように避けられるでしょうか。

データが保存されている環境ではよくある間違い。

セキュリティグループは、誰がどこから（またはどのデバイス）にアクセスできるかを決定するファイアウォールルールを設定します。

これらはすべて、セキュリティグループが意図したとおりに機能するようにするために、定期的に監査する必要がある。

そうでない場合、構成の誤りを検出するメカニズムを導入する必要がある。

構成の誤りが検出された場合は、修正できるようにセキュリティスタッフにすぐに通知する必要がある。

』

メモ、三菱電機 情報漏えいの件

--> 01/23追記・編集

piyokangoさんのまとめ（↓）

・ログ消去もされていた三菱電機の不正アクセスについてまとめてみた (01/20～)

https://piyolog.hatenadiary.jp/entry/2020/01/20/172436

まだ報道からは見えてこない、個人的興味は次の三点
①セキュリティ製品のupdateを行っていれば、どの程度拡大を防げたか?
　これだけの規模なら、複数の脆弱性を個々のkill chain突破で段階的に悪用と推察。
　それぞれ、どのような内容だったか?
②三菱関連会社が販売するセキュリティ製品だとどうだったか?
③PCの不審な動作で気づいた、とはどんな動作か?

・ラック、企業を狙う標的型攻撃について注意喚起、無償の痕跡調査ツール「FalconNest」の利用を推奨 (01/22)

https://internet.watch.impress.co.jp/docs/news/1230752.html

『攻撃対象になりうるドメインコントローラーやサーバーを対象に、FalconNestによる調査を定期的に実施することで、標的型攻撃の痕跡を初期段階で発見できる可能性が高まる...

なお、FalconNestの利用にあたっては、ユーザー登録が必要になる。 』

--> 01/22

・三菱電機へのサイバー攻撃にみる、正確な報道の困難さ (01/21)

https://news.yahoo.co.jp/byline/yamamotoichiro/20200121-00159790/
　本報道検証が分かりやすい。

『その大手メーカーを単独で狙うようなハッキングに対しては無力であり、万全とはとても言えない』と言って経営が納得するか?
『「社内調査に時間がかかった」というより「流出してしまった情報が何であるかすら把握できないぐらい、気づくのが遅れた」ことを意味するならば、この問題を報じる側も相当なリテラシーの高さでないと正確な報道はむつかしいのでは』

不正アクセスの原因となった製品名は「ノーコメント」とする日経BP、
他には「トレンドマイクロ」としている記事も見られます。

・【まとめ】トレンドマイクロ・三菱電機 不正アクセス年表(URL付き) (01/15)

http://blog.livedoor.jp/blackwingcat/archives/1993184.html

　トレンドマイクロが複数回侵入され、脆弱性修正は後手になり、
　（それが決定的かハッキリしないが）三菱電機事件が起きた経過のまとめ

・CVE-2019-18187 Detail (2019/10/28-31)

https://nvd.nist.gov/vuln/detail/CVE-2019-18187

『トレンドマイクロのOfficeScanバージョン11.0およびXG（12.0）は、ディレクトリトラバーサルの脆弱性を利用して、任意のzipファイルからウイルスバスターCorp.サーバー上の特定のフォルダにファイルを抽出する攻撃者によって悪用される可能性があり、リモートコード実行（RCE）につながる可能性があります。 リモートプロセスの実行はWebサービスアカウントにバインドされており、使用するWebプラットフォームによっては、許可が制限されている場合があります。 攻撃を試みるには、ユーザー認証が必要です。
... Base Score: 7.5 HIGH　』（機械翻訳）

HIGH以上のものは原則対応、というのがベストプラクティス。
万一対応できない場合、リスク分析・判断～決裁～次善策 等、どの程度やってたのか?

・ウイルスバスターに脆弱性情報、悪用攻撃が発生 (2019/10/28)

https://japan.zdnet.com/article/35144536/

『管理サーバーにアクセスできるクライアント端末を操作できることも条件 ...
　攻撃者が外部から遠隔で直接的に該当製品のサーバーにあるファイルを変更できるものではない』
でも、ここまでの侵害が起きた。社内のシステム管理PCが先に侵害され、さらにそこに至るための他の侵害もあった、と考えるのが自然だろう。それぞれ公表されれば、大いに参考になると思うのだが。。。

 --> 02/13 追記

・不正アクセスによる個人情報と企業機密の流出可能性について（第3報）(02/12)

http://www.mitsubishielectric.co.jp/news/2020/0212-b.pdf

・複数の Trend Micro 製品におけるパストラバーサルの脆弱性 (2019/09/11)

https://jvndb.jvn.jp/ja/contents/2019/JVNDB-2019-003323.html

CVSS v3, v2から抜粋、、

『

攻撃条件の複雑さ: 低

攻撃前の認証要否: 不要

攻撃に必要な特権レベル: 不要

利用者の関与: 不要

』

読み物、ソーシャルメディアのリスク対策

・SNS上で企業のプレゼンスを守るための4つの対策 (2018.07.11)

https://blog.global.fujitsu.com/jp/2018-07-11/09/

・企業のソーシャルメディア安全運用術：乗っ取り・スパム・誤送信を防ぐために (2015.07)

https://mypage.otsuka-shokai.co.jp/contents/business-oyakudachi/it-security-course/2015/201507.html

Xiaomi Redmi 5 のデータ収集・送信を止めるには

◆XiaomiによるRedmi 5でのデータ収集の停止

1.設定アプリケーションを起動します
2.次に、[システムとデバイス]セクションまでスクロールします
3. [追加設定]オプションをタップします 
4.上部のプライバシーオプションをタップします

さて、これらのデータ収集機能はオプションですが、以下の埋め込みビデオのようにそれらをすべて無効にする方法を紹介します。

1.一番下までスクロールします
2.ユーザーエクスペリエンスプログラムのトグルをタップしてオプトアウトします
3.[診断データを自動的に送信]をタップしてオプトアウトします 
4.広告サービスオプションをタップします
5.そして、ここでトグルをタップして、パーソナライズされた広告の推奨をオプトアウトします
6.プライバシーページに戻る 
7.使用アクセス権を持つアプリをタップします
8.使用しておらず、慣れていないアプリケーションへのアクセスをオフにします（ただし、アプリまたはサービスがクラッシュした場合は、ここに戻ってその特定のアプリケーションを有効にします）
9.最後にもう一度プライバシーセクションに戻ります
10.[場所]オプションをタップします
11.ナビゲーションなどに使用しない限り、ロケーションアクセスオプションを無効にします。

◆出典

・How to Stop the Xiaomi Redmi 5 from Collecting and Sending Data (2018/06/15)
　https://www.androidexplained.com/redmi-5-stop-data-collection/

読み物、いろいろ

・クラウドバックアップの課題を解消する新しいアプローチとは？
　https://japan.zdnet.com/extra/arcserve_201910/35143825/

・グローバルシャドーITがリスクに! どうする? 海外拠点全体のガバナンス
　https://japan.zdnet.com/paper/30001177/30003293/

・【調査資料】Office 365移行に関する問題点と、解決のための５つの提案
　https://japan.zdnet.com/paper/20171868/30003234/

・「2つの可視化」が重要に! どうする? 海外拠点全体のWebセキュリティ対策 (2019/12/06)

https://japan.zdnet.com/paper/30001177/30003294/

・マルチクラウドユーザーが陥りやすい、新たな「サイロ化」の罠 (2019/12/09)

https://japan.zdnet.com/paper/30001187/30003314/

・New Android Threat: Facebook, WeChat Apps Have Failed To Patch Known Security Risks (2019/11/21)
　https://www.forbes.com/sites/zakdoffman/2019/11/21/google-security-failure-2-billion-facebook-wechat-apps-at-risk-from-hackers-report/

　https://translate.google.com/translate?sl=en&tl=ja&u=https%3A%2F%2Fwww.forbes.com%2Fsites%2Fzakdoffman%2F2019%2F11%2F21%2Fgoogle-security-failure-2-billion-facebook-wechat-apps-at-risk-from-hackers-report%2F

・Old Security Flaws Still Exist in New Android Apps
　https://www.cpomagazine.com/cyber-security/old-security-flaws-still-exist-in-new-android-apps/

　https://translate.google.com/translate?sl=en&tl=ja&u=https%3A%2F%2Fwww.cpomagazine.com%2Fcyber-security%2Fold-security-flaws-still-exist-in-new-android-apps%2F

スマートテレビをNessusでスキャンしてみた

手元のTVをNessusでスキャンしてみた。

SSL関連のものは、オレオレ証明書だったり、暗号強度が不十分だったりで、外との通信に使われない限り、問題視することもないだろう。

他も一つ一つググりながら対策を見ると、『ベンダーからupdate入手・適用せよ』の他に『外部との通信を適切にブロックせよ』というのもあって、「ホームIoTのセキュリティ対策」が必要ですね。

◆その他、関連の読み物

・スマートテレビに犯罪者はどうやって侵入しようとしているのか (2019.12.04)

　https://eset-info.canon-its.jp/malware_info/special/detail/191204.html

　具体策、こっち(↓)が参考になった　　　　　　　　　　　　　　

・Top tips for protecting your Smart TV (2018/10/01)

　https://www.welivesecurity.com/2018/10/01/protecting-your-smart-tv/

機械翻訳　https://translate.google.com/translate?sl=en&tl=ja&u=https%3A%2F%2Fwww.welivesecurity.com%2F2018%2F10%2F01%2Fprotecting-your-smart-tv%2F
1–ルーターの資格情報を保護する
2-ネットワークとデバイスを並べ替える
3-スマートTVの構成
4-最新のアップデートをインストールする
5-完全なセキュリティソリューションを使用する
6-注意してアプリケーションをダウンロードする
7-ストリーミングを注意して使用する

・Androidはウイルスに狙われやすい？必要なセキュリティ対策は？ (2019.11.07)

　https://eset-info.canon-its.jp/malware_info/special/detail/191107.html

・スマートフォンがマルウェア感染した場合の5つの兆候 (2016.02.16)

　https://eset-info.canon-its.jp/malware_info/special/detail/160216.html

　『多くの不正アプリはシステムコンポーネントを偽装する』

　

やはりベンダーさんが「工場出荷時のシステムコンポーネントの一覧」を提供してほしいなぁ。

前述TVはOS Versionでググっても情報が限られているようです。

Xiaomi端末から不要アプリを削除する

カメラは評判通りの素晴らしさです。これまで私が使ってきた旧世代的スマホでは、こんなに奇麗には撮れませんでした。

なのにbloatwareと呼ぶのもなんですが、アプリの削除について、以下にメモしておきます。
文中のカッコ書き番号は、「参考サイト」で見出し番号から辿れるようにしておきます。

◆準備

Xiaomiデバイスで以下の順に
1.設定→デバイス情報→MIUIバージョンを7回タップ
　すると「今あなたは"開発者"になりました」の旨、表示。

2.設定→システムとデバイス：追加設定→開発者向けオプション
　USBデバッグを　On。
　※途中 MI Cloudの利用は回避

3.適当なVMとデバイスをUSB接続し、
　Xiaomi ADB/Fastboot Tools(*2)を起動。
　※アンインストーラーにアンインストール可能なリストが現れる

◆アンインストール

いきなりアンインストールは行わず、disableして様子を見る事に。
参考サイト（*1）のアプリが無い事をダブルチェック。

図、残りのEnabledなApp一覧（2/15更新）　

WMServiceもDisableして様子見中。

---> 01/18 追記ここから

Games, Facebook, WPS Office, Netflix も画面タップでアンインストール。

次の無効化済みソフトが、アップデート後 復活していたので、アンインストール
　Mi Video  com.miui.videoplayer
　Weather   com.miui.weather2

---> 01/18 追記ここまで

アンインストールすべきでないものを参考サイト(*4)に書いておいた。

◆disable設定後、トラヒックモニタリング

上位にraspi APを配して、tcpdumpで記録。

・操作とアクセス先
　と言っても偶然その時にアクセスが発生している可能性も残るのですが、、、

• セキュリティスキャン
• 　05:28:27.911212 IP 9tpro.40576 > 161.117.97.169.443:
• 　05:31:53.863714 IP 9tpro.47980 > 161.117.96.220.443:
• アプリを管理
• 　05:32:41.040942 IP 9tpro.49908 > 31.13.82.1.443:（edge-star-shv-01-nrt1.facebook.com）:
• テーマ
• 　05:36:13.615951 IP 9tpro.38778 > 47.88.216.202.443:
• アプリ情報
• 　05:38:51.270767 IP 9tpro.48287 > 172.217.161.74.443: UDP (nrt20s09-in-f10.1e100.net)
• プライバシーポリシー
• 　05:44:45.376614 IP 9tpro.38920 > 172.217.25.106.443: (nrt13s51-in-f106.1e100.net)
• SIM挿入
• 　05:50:49.604603 IP 9tpro.38930 > 172.217.25.106.443: (nrt13s51-in-f106.1e100.net)
• システムアプリアップデーター
• 　05:55:08.934297 IP 9tpro.37536 > 47.74.233.137.443:
• 壁紙 
• 　05:59:12.892563 IP 9tpro.38990 > 47.88.216.202.443: 
• 壁紙
• 　05:59:12.893150 IP 9tpro.47566 > 103.208.1.44.80: 
• SIM挿入&指紋追加登録後の電源オフ→オン時
• 　06:02:57.562357 IP 9tpro.42352 > 161.117.71.89.443:   
• SIM挿入&指紋追加登録後の電源オフ→オン時
• 　06:02:59.997131 IP 9tpro.37478 > 47.74.170.156.5222:  
• Gmail設定
• 　06:44:30.442075 IP 9tpro.41684 > 172.217.25.77.443:

　名前解決（逆引き）したdestination host名をカッコ書きした。

　逆引きが定義されていないdestinationが多い。

　06:02:59に発生したport:5222へのアクセスも気味悪い。

・名前解決
　手元のデバイスがdnsに照会したリストと件数（Xiaomi関連のみ抜粋）

  1 t3.market.mi-img.com.
  1 thm.market.intl.xiaomi.com.
  2 sa.api.intl.miui.com.
  3 find.api.micloud.xiaomi.net.
  4 privacy.mi.com.
  7 t5.market.mi-img.com.
  8 api.zhuti.intl.xiaomi.com.
  8 global.market.xiaomi.com.
  8 www.miui.com.
30 api.ad.intl.xiaomi.com.
40 data.mistat.intl.xiaomi.com.

　最後の「40」のサイトへは
　数分おきに HTTPS CONNECTメソッドで通信している。

　Gmail アカウント設定後に三度、HTTP POSTメソッドもやらかしている。

　対処については、参考サイト(*3)に詳しいが、今日はここまでとしておきます(01/13)

◆参考にしたところ、一覧

https://akasaka-taro.blogspot.com/2020/01/xiaomi.html

Xiaomi端末から不要アプリを削除する為の参考サイト

手順まとめ（↓）

Xiaomi端末から不要アプリを削除する (2020/01/13)

https://akasaka-taro.blogspot.com/2020/01/xiaomi_13.html　（以上、2021/07/22追記）

以下、対象アプリ、ツール等の参考サイトメモ

*1 Preinstalled Malware

・Preinstalled Malware Targeting Mobile Users
　https://blog.checkpoint.com/2017/03/10/preinstalled-malware-targeting-mobile-users/　
　『

The malicious apps were not part of the official ROM supplied by the vendor, and were added somewhere along the supply chain.

Six of the malware instances were added by a malicious actor to the device’s ROM using system privileges, meaning they couldn’t be removed by the user and the device had to be re-flashed.

… snip …

Xiaomi Redmi : com.yongfu.wenjianjiaguanli

Xiaomi Mi 4i : com.sds.android.ttpod

』

・マルウェア警告：ほとんどの40スマートフォンにプリインストールされています (2017/11)
　https://ja.xiaomitoday.it/allerta-malware-preinstallato-su-quasi-40-smartphone.html

・Vulnerability in Xiaomi Pre-Installed Security App (2019.04.04)

https://research.checkpoint.com/2019/vulnerability-in-xiaomi-pre-installed-security-app/

『

   it was the pre-installed security app,‘Guard Provider’ (com.miui.guardprovider) ...

Briefly put, due to the unsecured nature of the network traffic to and from Guard Provider, a threat actor could connect to the same Wi-Fi network as the victim and carry out a Man-in-the-Middle (MiTM) attack. Then, as part of a third-party SDK update, he could disable malware protections and inject any rogue code he chooses such to steal data, implant ransomware or tracking or install any other kind of malware.

Check Point responsibly disclosed this vulnerability to Xiaomi, which released a patch shortly after.

』

・Xiaomi Mi 9 いろいろ
　https://akasaka-taro.blogspot.com/2019/08/xiaomi-mi-9.html

https://bey.jp/?p=37414『adups（バックドアを仕掛けている会社）のIPアドレスは（略）』 

https://forum.xda-developers.com/redmi-note-3/help/discussions-plz-dev-look-analyst-t3463321『AnalyticsCore.apk = com.miui.analytics』

サイトの中には、ショッキングな見出しも有る気もするが、心配になってきたので、不要なプリインストールソフトは削除しておこう、と考えた次第。

*2 Xiaomi ADB/Fastboot Tools

アンインストールの為のツールと、アンインストール対象アプリについて

・Androidでプリインストールアプリを強制的に削除する方法! 消せない標準ソフトもアンインストール/無効化できる (2018/09/04-2019/05/30)
　https://sp7pc.com/google/android/31027#toc1

・Androidアプリのパッケージ名を調べる方法! Google PlayやapkのアプリケーションID確認しよう (2018/05/26-2019/05/26)
　https://sp7pc.com/google/android/31029

・Xiaomiデバイスでシステムアプリをアンインストールする方法（ルートなし）(2019/11/04)
　https://ja.xiaomitoday.it/come-disinstallare-app-di-sistema-su-dispositivi-xiaomi-no-root.html
　削除アプリ例が豊富。ADBで削除する際、便利そうなコマンド一覧もある。
　この方が標準的アプリの削除対象としているのは、次の通り。

>find "pm " tmp-web.txt | find /v ".xiaomi." | find /v ".miui." | find /v ".mi" 
---------- TMP-WEB.TXT
pm uninstall -k-ユーザー0 com.android.browser
pm uninstall -k-ユーザー0 com.android.calendar
pm uninstall -k-ユーザー0 com.android.email
pm uninstall -k --user 0 com.android.soundrecorder
pm uninstall -k --user 0 com.google.android.apps.docs
pm uninstall -k --user 0 com.google.android.gm
pm uninstall -k-ユーザー0 com.google.android.music
pm uninstall -k-ユーザー0 com.google.android.videos
pm uninstall -k-ユーザー0 com.google.android.apps.photos
pm uninstall -k-ユーザー0 com.google.android.marvin.talkback
pm uninstall -k --user 0 com.facebook.appmanager
pm uninstall -k --user 0 com.facebook.services
pm uninstall -k --user 0 com.facebook.system

ここまでやるか。

・More apps to remove #69 (2019/09/11)

https://github.com/Szaki/XiaomiADBFastbootTools/issues/69

さらに削除可能なアプリ例

『WMService is some kind of analytics thing.

Weather is useless if you remove their default widget and don't use the Weather app.』

『 "Gallery;com.miui.gallery",                      
　"WMService;com.miui.wmsvc",
　"Weather;com.miui.weather2",
　"NextPay;com.miui.nextpay",
　"MiSound;com.miui.misound",
　"MiPlayClient;com.xiaomi.miplay_client",
　"mi_connect_service;com.xiaomi.mi_connect_service",
　"XiaomiAccount;com.xiaomi.account"
』

・New Removable and Non-Removable Bloatware in MIUI 11 (2019.11)
　https://www.reddit.com/r/Xiaomi/comments/dseq28/new_removable_and_nonremovable_bloatware_in_miui/

・How to get rid of the Mi Bloatware pre-installed without flashing/root? (2019/09/29)
　https://forum.xda-developers.com/k20-pro/help/how-to-rid-mi-bloatware-pre-installed-t3975121
　com.google.android.musicまでもアンインストール。
　そこまでするかなぁ。参考リスト的に挙げておく。

・Xiaomi端末の便利な管理ツール「Xiaomi ADB/Fastboot Tools」(2019/09/19)
　https://ahogehopping.hatenablog.com/entry/xiaomi-adb-fastboot-tools

・Szaki/XiaomiADBFastbootTools
　https://github.com/Szaki/XiaomiADBFastbootTools

一応チェックすると、
https://www.virustotal.com/gui/url/a3616b17f297ef3ecbf764644b71394b297124d0ee141fd7797c22af8bcbe6b5/detection   unratedな6件を除き、目下 100%のベンダーで clean との評価　

*3 その他

事後策など

・Calls Home.. (to The Maintainers) (2018/03/22)
　https://xiaomi.eu/community/threads/calls-home-to-the-maintainers.43699/
　data.mistat.intl.xiaomi.com と ccc.sys.miui.com への定期通信を止める。
　Netguard（rootの要らないfirewall app）の紹介と、
　hostsファイルへの書き込みアイデア。参考になります。

*4 アンインストールすべきでないApp

・「セキュリティ～」はアンインストールするとブート時に無限ループするとの記載が多い

・「パッケージインストーラー」も安易にアンインストールするべからず。

・Disabled package installer, stuck in bootloop (2017/08/25)

https://forum.xda-developers.com/android/help/disabled-package-installer-stuck-t3662033

・How do I disable App Vault in MIUI? (2018/08/09)

https://www.quora.com/How-do-I-disable-App-Vault-in-MIUI

ここに記載の「アプリ保管庫」は無効化しようとすると、「アップデートの受信ができなくなる」旨の警告表示。有効なままにして思案中。

--> 12.02追記

・Power detector: com.xiaomi.powerchecker は削除しない

Xiaomi Super bloatware List 2020
https://lucacesarano.medium.com/xiaomi-super-bloatware-list-2020-db38ace9e9e1

『But since this is Miui and there are eternal troubles, with the application settings configured in the background. I will not touch and do not advise you.』

・System Apps Updater: com.xiaomi.discover は削除しない

Debloating (removing bloatware) applications from MIUI
https://devcondition.com/article/removing-unneeded-miui-applications/

『URGENT CLEAR_DATA + FREEZ com.xiaomi.discover System app updater Gizmo, for updating, first of all, MIUI applications: browser, downloads, notes, etc., etc. But it can hook other applications. Decide for yourself. I do not delete, but FREEZe. Periodically including, to check for updates.』

・Battery & performance: com.miui.powerkeeper

Xiaomi Mi 9T Pro、対応バンド

Xiaomi Mi 9T Pro （Redmi K20 PROのグローバル版）について

4G

  1(2100), 3(1800), 5(850), 7(2600), 8(900), 20(800), 38(2600), 40(2300)
  2(1900), 4(1700/2100), 28(700)  ... ref. *1

  1/3/5/7/8/20/38/40 ... ref. *2

参考
*1  Xiaomi Mi 9T Pro Global Dual SIM TD-LTE 128GB M1903F11G
　　(Xiaomi Raphael) - Frequency Bands and Network Compatibility
*1  Xiaomi Mi 9T Pro (telektlist)
*2  Xiaomi Mi 9T Proのスペック、対応バンド、価格、特徴！（ガルマックス）

China Unicom Hong Kong のSIM

中国大陸(中国聯通 = China Unicom)
　　4G・LTE Band1(2100)・Band3(1800)
　香港(3HK/3香港)
　　4G・LTE Band1(2100)・Band3(1800)・Band7(2600)

　Frequencies used on China Unicom Network in China (Wikipedia)
　『1800 MHz (GSM/LTE), 2100 MHz (HSPA+/LTE)』
　なので、9T Pro、SIM、Carrierとの帯域マッチングは問題なさそう。

　参考

・【中国聯通香港】 China Unicom 4G LTE 中国大陸 香港7日間 2GBデータプリペイドSIM [並行輸入品] (Amazon)

China Unicom品は『周波数帯域【4G】1,800Mhz、2,600Mhz』とされている。
　　↓　都度、要注意・要確認
・4G高速データ通信 中国本土31省と香港で7日利用可能 プリペイドSIM (Amazon)  

T-Mobile

4G LTE band 2/4/5/12/66/71, N260, N261
　LycamobileのSIMは　LTE Band 2/4/12で、問題無し

　参考
　　・T-Mobile network frequencies & technology
　関連
　　・アメリカ・ハワイSIM lycamobile 30日LTE4GB (2018/08/17)
　　　https://akasaka-taro.blogspot.com/2018/08/sim.html

Windows7 や2008のESU (Extended Security Updates)について

◆正攻法

こちら
　↓
・Windows7 ESUのアクティベーション方法が公開されていました (2019/12/18)
　http://mitomoha.hatenablog.com/entry/2019/12/18/013521

元記事はこちら
　↓
・How to get Extended Security Updates for eligible Windows devices (2019/10/17)
　https://techcommunity.microsoft.com/t5/windows-it-pro-blog/how-to-get-extended-security-updates-for-eligible-windows/ba-p/917807

◆0patchのmicropatch

・0patch、Windows 7/Server 2008のサポート終了後もサードパーティーパッチを提供する計画 (09/22)
　https://security.srad.jp/story/19/09/22/1037218/

『0patchのマイクロパッチは常駐プログラム「0patch Agent」により、実行中のプロセスに対して直接適用される。パッチ適用に再起動は必要なく、適用の有無も切り替え可能だ。』

と、『仮想パッチ記事』よりも、動作原理が明快に示されている点は好印象。
安定性や、ライセンス上問題無いのか、これからの記事を待つ。

『0patchのパッチ作成計画としては、Windowsの月例更新に合わせて出されるMicrosoftのセキュリティアドバイザリからWindows 7/Server 2008にも適用されそうな脆弱性を特定し、Windows 10の更新プログラムの変更部分から同じコードがWindows 7/Server 2008にも存在するかどうかを確認する。あとはPOCの収集とマイクロパッチの作成を行い、POCによるテストとその他の副作用に関するテストを経てパッチをリリースするとのこと。』

本家はこちら
　↓
・0patch
　https://0patch.com/

MS17-010の頃 既に、こんな記事も
　↓
　https://twitter.com/0patch/status/864819472615571456

『We've just produced a micropatch for #shadowbrokers EsteemAudit! Organizations with Windows Server 2003 and Windows XP, we got your back.』

ホームIoTのセキュリティ対策

◆目的

１．自宅で TV、スマホ、PC、その他まとめて Sophos UTMの傘で保護。
２．直結ISPやマンションのスーパーマニアからのプライバシ保護（クラウドSPからの保護は残課題）。

◆環境

こんな環境整備をやってみた。

◆前提

1. ラズパイ起動時に、Sophos UTMとの間で、SSL-VPNセッションを自動的に確立し、
　ラズパイがSSL-VPNクライアントとして動作済みとします。

関連
・OpenVPN linux client automatically at boot、メモ
　https://akasaka-taro.blogspot.com/2019/12/openvpn-linux-client-automatically-at.html

2. さらにラズパイををAccess Point化して
　各ホームデバイスからインターネットアクセス可能とします。

関連
・raspberry pi を access point 化 (2018/01/09)
　https://akasaka-taro.blogspot.com/2018/06/raspiap.html

3. ラズパイに有線LANアダプタを追加、eth1として稼働済みとします。
　TVは やはり有線接続することにしました。

関連
・有線LANアダプタ、ラズパイ（Debian系）用
　https://akasaka-taro.blogspot.com/2020/01/landebian.html

◆起動スクリプト

『前提』が整ったら、残るはmasquerading等の設定。
『raspberry pi を access point 化』でも触れた起動スクリプトを、以下の通り変更。

iw phy0 interface add mon0 type monitor; ifconfig mon0 up

dnsmasq --interface=eth1  --except-interface=lo --bind-interfaces --dhcp-range=$DHCP-ETH01,12h --server=$DNS-ETH01

dnsmasq --interface=wlan0 --except-interface=lo --bind-interfaces --dhcp-range=$DHCP-WLAN0,12h --server=$DNS-WLAN0

sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

iptables -A FORWARD -i tun0  -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o tun0  -j ACCEPT

iptables -A FORWARD -i tun0  -o eth1  -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1  -o tun0  -j ACCEPT

sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

sysctl -w net.ipv6.conf.all.disable_ipv6=1 && sysctl -w net.ipv6.conf.default.disable_ipv6=1

/usr/sbin/route add    -net $UTM-NET gw $MANSION-ROUTER eth0
/usr/sbin/route delete default gw $MANSION-ROUTER eth0
/usr/sbin/route add    default gw $SSL-VPN-ADDR-IN-UTM tun0

cat /etc/resolv.conf.new > /etc/resolv.conf

※上記変数について

$DHCP-ETH01: ケーブル接続クライアント向けにeth1で割り当てるDHCPレンジ
$DNS-ETH01: 上記レンジのDNSサーバIP
$DHCP-WLAN0: Wi-Fiクライアント向けにwlan0で割り当てるDHCPレンジ
$DNS-WLAN0: 上記レンジのDNSサーバIP
$MANSION-ROUTER: マンションの（直結・上位の）ルータIP
$SSL-VPN-ADDR-IN-UTM: UTM自身に割り当てられたSSL-VPNのIP

◆その他、追加設定

/etc/resolv.conf が書き換わらないようにする（今回の環境では、dnsmasqのDNS設定がクライアントに反映されるので、必須でもないのだが、念のため）。

1. # vi /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile
dns = none # この行を追加

2. # systemctl restart NetworkManager

参考
・[RHEL7]/etc/resolv.conf 強制上書き無効 (2017/10/20)
　https://qiita.com/a-hiroyuki/items/559ccde6d948d31af939