DevSecOps｜技術顧問｜旅＆ファッション＆コーヒー＆ワイン好き｜#ETH 推し｜スキルセット→https://xitter.cf/t.co/RASeWQ7cPs｜雑食サロン→https://xitter.cf/t.co/hMNjBGvWBv｜雑食TV→https://xitter.cf/t.co/KYB6ox7bKL｜Instagram→https://xitter.cf/t.co/I7ffc6DfQJ
DMはビジネスに関するお問い合わせのみ対応しております。
Joined June 2010
- Tweets24.8K
- Following322
- Followers36.8K
- Likes105K
Pinned Tweet
日本という国は改めて考えてみると本当に天国みたいなところだと思うんですよね。
・安全で衛生レベルも非常に高い(水道水が普通に飲める時点ですごい)。
・公共も民間もあらゆるサービスの平均的な質が高い(クール宅配便が数百円で利用できるとか凄すぎるｗ)。
・医療レベルが高いのに医療費は十分にリーズナブル(国民皆保険のおかげ)。
・ご飯がほぼ何でも美味しい上にリーズナブル。
・ほとんどの人が基本的に穏やかで親切。
・自然がいっぱい＆四季があるので各地域の各季節それぞれの風景や行事を楽しめる。
・漫画/アニメ/音楽/映画などの国産の大衆向けコンテンツの質と量が凄すぎる。
・(特に都市部は)公共交通機関と徒歩でほぼどこでも行ける。
・(特に東京は)色々な娯楽がとてつもなく充実している。
・ビザ無しで大抵の国に旅行できる。
もちろんよくない点も多々あるとは思いますが、不満ばかり言ってないでこういう国に生まれた幸運をフルに活用して思い切りエンジョイしないと絶対に損だよなあと思う昨今であります😄
ちなみに攻撃はまだ終わっていない可能性がありまして、ハッカー集団の言っていることが事実ならば、今度は各ユーザーのローカル端末の色々な機密情報やプライベート情報が人質になっているようですね。
これも当然身代金要求をGMOさんは拒否するでしょうし(当然そうすべき)、そうなると数万人レベルでの機密情報(電話番号や住所とかとは比較にならないレベルの超重要情報や絶対に人に見られたくない性癖の情報など)がネットに流出する可能性があるわけで、なかなか前代未聞の事態になってきたなあと。
他人事ではないので、お金関係はもちろんですが、我々も自分の端末内の絶対に人に見られたくないものは早めに整理した方が良さげですね💦
これはGMOさんを攻撃した(と自称している)ハッカー集団からの声明ですが、この内容が本当だとすると、お名前ドットコムデスクトップクラウドには「初歩的 かつ 非常に大きな」脆弱性が存在していたみたいですね。
僕は現在はLinux系が専門なので知りませんでしたが、
・WindowsのRDPでは、管理者がリモートログインした際に接続先の端末に認証情報が残り、その端末の管理者権限を持つユーザーに窃取・悪用される可能性がある
ようですね。(とんでもない仕様なのでこれはまずMicrosoftが悪いw)
そのため、RDPによる信頼度の低い端末への接続においては、Restricted Admin Modeなどを設定して認証情報を保護する必要があるのだそうです。
この保護はActive DirectoryのGPOとかで割と簡単に設定できるようで、そしてこのRDPの脆弱性に関しては割と広く知られている初歩的なものみたいですね。
ところが、GMOさんの管理チームは何らかの理由でこの設定やっていなかったか、もしくは単に失念してしまったのかなと。
この設定漏れにより、保守担当者がRDPでユーザーのVPSに接続した際に管理者アカウントの認証情報が漏洩し、VPS内で管理者権限を持つ攻撃者がその認証情報を取得してActive Directory全体の管理者に昇格し、他の顧客のVPSにマルウェアをばら撒いた、という展開のようですね。
そしてもう一点「ドライブリダイレクション」という記述がありますが、この機能が有効になっていると、RDPのリモート側からローカル端末のファイルを読み書きできてしまうのだそうです。(これもとんでもない仕様ですがｗ)
なのでこの機能を悪用するとユーザーのVPSからローカル端末に対してマルウェアを配置することが可能になるわけですが、ハッカー集団の情報が事実ならば、お名前ドットコムデスクトップクラウドさんでは2019年からずっとこの機能が有効化されていたようです。
これも何か理由があってそうしたのかもしれませんが、事実だとしたらなんでそんな恐ろしい機能をONにしていたのかなと😅
これらを考慮すると、先ほどGMOさんが発表した第4報の
「民間事業者単独の防御・事後対応のみでは、国境を越えて暗躍する高度なサイバー犯罪集団による国民資産の略奪を根絶することは困難です。」
の部分に関してはちょっと同意しかねる部分が出てきますね。
個人的な見解としては
「あなた方のサービス、WindowsのRDPを使ってサービスを管理するなら誰でも当然のように知っておくべき初歩的な脆弱性を、長期に渡って放置していてそこを攻撃されただけですよね？」
という感想になってしまいます笑😅
まあハッカー集団が本当のことを言ってると確定したわけではないですが、サービスは全く新規に作り直すとのことなので、他の企業さんの今後の参考のためにもGMOさん側からも詳細な攻撃情報を出してほしいとこですね。
普段Windows使わないので色々と学びになりました。やっぱりLinuxがいいですね笑
これはGMOさんを攻撃した(と自称している)ハッカー集団からの声明ですが、この内容が本当だとすると、お名前ドットコムデスクトップクラウドには「初歩的 かつ 非常に大きな」脆弱性が存在していたみたいですね。
僕は現在はLinux系が専門なので知りませんでしたが、
・WindowsのRDPでは、管理者がリモートログインした際に接続先の端末に認証情報が残り、その端末の管理者権限を持つユーザーに窃取・悪用される可能性がある
ようですね。(とんでもない仕様なのでこれはまずMicrosoftが悪いw)
そのため、RDPによる信頼度の低い端末への接続においては、Restricted Admin Modeなどを設定して認証情報を保護する必要があるのだそうです。
この保護はActive DirectoryのGPOとかで割と簡単に設定できるようで、そしてこのRDPの脆弱性に関しては割と広く知られている初歩的なものみたいですね。
ところが、GMOさんの管理チームは何らかの理由でこの設定やっていなかったか、もしくは単に失念してしまったのかなと。
この設定漏れにより、保守担当者がRDPでユーザーのVPSに接続した際に管理者アカウントの認証情報が漏洩し、VPS内で管理者権限を持つ攻撃者がその認証情報を取得してActive Directory全体の管理者に昇格し、他の顧客のVPSにマルウェアをばら撒いた、という展開のようですね。
そしてもう一点「ドライブリダイレクション」という記述がありますが、この機能が有効になっていると、RDPのリモート側からローカル端末のファイルを読み書きできてしまうのだそうです。(これもとんでもない仕様ですがｗ)
なのでこの機能を悪用するとユーザーのVPSからローカル端末に対してマルウェアを配置することが可能になるわけですが、ハッカー集団の情報が事実ならば、お名前ドットコムデスクトップクラウドさんでは2019年からずっとこの機能が有効化されていたようです。
これも何か理由があってそうしたのかもしれませんが、事実だとしたらなんでそんな恐ろしい機能をONにしていたのかなと😅
これらを考慮すると、先ほどGMOさんが発表した第4報の
「民間事業者単独の防御・事後対応のみでは、国境を越えて暗躍する高度なサイバー犯罪集団による国民資産の略奪を根絶することは困難です。」
の部分に関してはちょっと同意しかねる部分が出てきますね。
個人的な見解としては
「あなた方のサービス、WindowsのRDPを使ってサービスを管理するなら誰でも当然のように知っておくべき初歩的な脆弱性を、長期に渡って放置していてそこを攻撃されただけですよね？」
という感想になってしまいます笑😅
まあハッカー集団が本当のことを言ってると確定したわけではないですが、サービスは全く新規に作り直すとのことなので、他の企業さんの今後の参考のためにもGMOさん側からも詳細な攻撃情報を出してほしいとこですね。
普段Windows使わないので色々と学びになりました。やっぱりLinuxがいいですね笑
ざっと読んでみましたが、現時点でやれる対応としてはほぼほぼベストなのではないかなと。
初動が遅すぎた感はありますが、「既存のサービスの改修ではなく新サービスを開発して移行」「ユーザーの損失の全額補填(条件はあるみたいですが)」とかは非常によいと思いますね。
(前者は恐らくエンジニアからの強い提案もあったのかなと思いますが。多分アーキテクチャやセキュリティ的に以前から色々と問題が指摘されていたのかなと)
そして「脅迫があった」ことを認めた上で「身代金は払わない」とキッパリ宣言したのもよいと思います。
ここら辺はKADOKAWAさんとは大きく違いますね笑
身代金払っちゃう企業があるからサイバー攻撃がどんどん激化してしまうわけなので、GMOさんみたいな大企業が明確に拒否するのは社会にとって大切かなと。
まあとは言うものの、FXという「ギャンブル」をさらに自動取引で実行するという相当にリスキーな行為を助長するようなサービスを維持することが、本当に社会にとって必要なのかどうかは微妙なとこではありますが笑😅
【お知らせ】お客様へのお見舞金のお支払いと不正取引による損失の補償について
能動的サイバー防御に関する措置の実施に向け、政府関係機関へ要請開始しました。
詳しくはこちらをご覧ください👇️
group.gmo/info/alert/2026102…
GMOの「お名前.com デスクトップクラウド」へのハッキングの件、まだ全貌は分かっていませんが「攻撃者からGMOグループに対する脅迫が実際にあった可能性」は割と高そうな気はしますね。
個々のユーザーのFX口座に侵入できたとしても、攻撃者がそれによって直接的な金銭的利益を得るのは難しい＆コスパが悪いので、「ユーザーの資産を溶かされたくなかったら身代金を払え」とGMO側を脅迫する方が合理的なんですよね。
もちろん実際に脅迫があったとしても企業側にはそれを公表する義務はないのですが、不正アクセスされていることをユーザーおよび世の中に対してもっと迅速に公開していたら被害規模を小さくできた可能性はあったわけで。
こちらの朝日の記事の信憑性に関しては何とも言えませんが、これを見る限りユーザーのFX口座への攻撃は21日夕方には発生していたのに対して、GMOからの発表があったのは22日の17時。
この発表が遅すぎたのではないかという点は今後かなり厳しく突っ込まれるのではないでしょうか。
いずれにしてもこの一件と先日のinfoQの不正アクセスの件を併せて「セキュリティに強い企業」としてのGMOさんの評価はかなり毀損されてしまったかなと。
GMOさんの中に非常にレベルの高いセキュリティエンジニアが在籍されていることは間違いないですが、「凄いエンジニアがいる」ことと「その人たちのスキルや経験を実際のサービスに反映する」ことはまた別でありまして、GMOさんは後者があまりうまくいっていないみたいですね😅
asahi.com/articles/ASVBQ436F…
今回のPHP脆弱性問題で恐らく多くのエンジニアが認識したと思うのですが、
・OSSのメンテナーの居住地は欧米が中心
・そのため脆弱性パッチの公開時間は欧米のエンジニアが活動しやすい時間帯に設定されることが一般的
・その時間帯は日本では夜遅くか深夜である。
・AIの進歩により今後も即時の緊急対応が必要な脆弱性はかなりのペースで発見され続ける可能性が高い。
・つまり今回と同様な「深夜の緊急の脆弱性対応」が日本において定常化してしまう可能性が非常に高くなっている。
という由々しき状況なんですよね。
この問題に関して、OSSの未知の脆弱性発見のペースをコントロールすることは不可能ですが、「エンジニアの深夜対応の負担をできるだけ減らす」ことは可能なわけです。
なので各企業さんはコンテナ化やテストの自動化やCI/CDパイプラインの整備やOSSの新しいバージョンへの早期の追随という「脆弱性発見時の対応作業をできるだけ楽にするための改修作業」にちゃんとお金と時間を投資しないといかんですよね。それはコントロール可能なわけですから。
それをやろうとしない企業さんからはエンジニアはどんどん離脱した方がいいですし、そういう企業さんがサイバー攻撃で消えてくれた方が日本全体のセキュリティレベルは向上するわけなので笑、睡眠時間を削ってまで守ってあげる必要はないかなあというのが私の見解です😅
「過去にGitHubでの情報漏洩が発生したのでGitHubは使用禁止。Self-ManagedのGitLabを使用せよ」というルールのご企業様の案件に参画したことがありまして。
(協力会社の人がGitHubの自分の公開リポジトリにソースコードをアップしちゃったのだとか)
しかしこの類の問題はGitLabを自分たちでホストしても防止できませんし、むしろクラウドのマネージドサービスを使わないことで保守コストやセキュリティリスクが高まってしまうのですが、会社の偉い方たちにはそういった理屈は理解してもらえなかったようで。
そして結果として現在Self-ManagedのGitLabは即日の緊急対応が必要なレベルの脆弱性が連続して発見されているので、僕はもう案件離れているのですがこれ多分チームの皆さん対応面倒だろうなあと。
(コード化してある＆デプロイスクリプトも作ってあるのでバージョンを変更してコマンドを実行すればいいだけではあるのですがタイミングによっては深夜の緊急対応になってしまうので)
クラウドサービスを使うのが絶対に正解というわけではないですが、セルフホストするとこういう緊急の脆弱性対応を毎回自分たちで頑張らないといけなくなるので、よほどの理由がない限りは「巨人の肩に乗る」のが無難だと思いますね😅
まあとにかく、技術の分からない人たちを技術的な決定に介入させてはいけません笑
itmedia.co.jp/news/article/2…
今回のPHPの脆弱性に対する復旧速度や対応コストは、そのサービスがどういう構成になっているかに大きく左右されるんですよね。
1. ECS Fargateなどのコンテナベースでサービスをホストしている＆PHPの新しいバージョンに追随し続けている＆CI/CDパイプラインも整備されていてテストもしっかり書いてある環境の場合：
- PHPの脆弱性に対応したDockerイメージが公式から提供されれば迅速に対応できる。対象となるDockerfileのパッチバージョンを更新して変更をコミットするだけでよい。CIを実行してテストが通ればCDを実行して対応完了。早ければ30分以内で対応が完了する。
2. EC2などのVMベースでサービスをホストしている or PHPのバージョンが古すぎる or テストが書かれていない環境の場合：
- コンテナと比べると更新の手数が多くなりがち(AMI等の更新まで自動化できているようなサービスは少ない)。PHPのバージョンが古すぎるとそもそもパッチが提供されないのでPHPのマイナーバージョンまたはメジャーバージョンを更新する必要があるがその際にWebフレームワークや依存パッケージその他が対応できていなかったりするとアプリケーションの大幅な改修も必要になる。テストが書かれていないと手動で各機能を動作確認することになるので復旧までさらに時間がかかる。
要するに1のようなモダンな構成 かつ 新しいバージョンへの追随を地道にやっていたサービスへの影響は小さい。
その逆に2のような構成のサービスだと復旧まで数日〜数週間以上必要になる可能性が普通にありますね。(そもそもサービスの再開を諦めるというケースも割と多発しそう)
まあ新しいバージョンへの追随作業というのは後回しにされがちなのですが、一国の首相がSNSでアラートするような歴史に残るインシデントが発生したことで、会社の上の人達を説得しやすくなったのは良かったのではないかなと😅
ここ最近のサイバー攻撃の被害激増により改めてセキュリティエンジニアという職種が注目されていますが、セキュリティ分野「だけ」を専門にするかどうかはよく考えてみた方がいいとは思いますねー。
例えば小〜中規模ITベンチャーさんとかだと、セキュリティだけの作業は定常的な業務量がそこまで多くならないので、セキュリティエンジニアは単体の職種として成立しずらいんですよね。(バックエンドやインフラの担当者がセキュリティ業務を兼務するケースが大半であり通常はそれで十分)
ある程度の規模の事業会社さんとかでも、セキュリティ周りの定常的な作業量はそこまで大きくならないので、情シスさんがベンダーの協力のもと他の業務をやりながらセキュリティ周りも兼務するという感じになるのが一般的なので、ここでも単体の職種になりづらいわけです。
なので必然的にセキュリティエンジニアはセキュリティ専業の企業さんで働くことが多くなるとは思いますが、それはつまりフロントエンドやバックエンドと比較して「活躍できる場所の選択肢がかなり限定される」ということになるわけで。
そして全体の求人数がそれほど多くならない＆働く先の企業が限定されがちということは「業務委託案件もかなり少ない」ということなので、フリーランス志向の方にはあまり向いていないということになりますし。(ここら辺はフリーランス案件サイトとかで確認するとすぐ分かると思います)
なのでセキュリティ方面に関心のある若手の皆さんへのおすすめとしては
・まずはバックエンドやインフラを専門にしてそれらの職種で十分なキャリアを確立しつつ、そこにセキュリティ方面の知識や経験をプラスしていく
・十分キャリアが安定した後で、それでもどうしてもセキュリティ分野を単体で深く掘りたくなったらセキュリティ単体のエンジニアへのジョブチェンジを検討する。
という方式が無難なのではないかなと。
nginxの脆弱性が話題になってますが、APIサーバーを作る際にnginxのようなHTTPサーバーを前段に配置する必要がないのもGoの大きなメリットの一つですよね。
Goのメリットをざっとまとめると
・コンパイル後のバイナリサイズが非常に小さくなる(コンテナイメージも小さくなる)
・シングルバイナリでホストできる(コンテナイメージに含めるライブラリを最小限にできるので脆弱性リスクが軽減される)
・nginx等のHTTPサーバーやgunicornのようなアプリケーションサーバーが不要(構成が単純化されるので保守が楽＆脆弱性リスクも軽減される)
・学習コストが低い
・静的型付け言語である
・並列処理に強い
・エコシステムが確立されていて寿命も長そう
という感じになるかなと。
そしてこういった点を総合的かつ客観的に考慮すると、現時点でバックエンドのAPIサーバーの開発言語のファーストチョイスはGoになるというのが僕の見解です。
フロントエンドとバックエンドの言語を統一して初期の開発効率を高めることが重視される場合はTypeScriptという選択もあり得るとは思いますが、サービスが成長するとフロントエンドとバックエンドは分業体制になるのが一般的なので、長い目で見るとやはりGoが一番「無難」かなと。
security-next.com/191645
古着に関する知見が色々と溜まってきたので「メンズ向けの東京のおすすめ古着屋さん(主に非アメカジ系)」という記事を書いてみましたー😄
いわゆる一般的なアメカジ以外の古着にも興味ある方には結構面白い内容だと思うので読んでみてください♪
note.com/poly_soft/n/n13d886…
技術力が非常に高いことで知られているエムスリーさんで不正アクセスによるデータ漏洩が発生したようですねー😳
エムスリーさんほどのテック系企業なら相当強固なセキュリティ対策が実施されていたはずなので、それでも突破されたというのはどういう侵入経路だったのか個人的にはかなり興味深いなと。
そしてそれはそれとして、こういった情報をPDFで出すのはあまりよろしくないですね。
この不正アクセスの影響を受ける方たちがパソコンで見るとは限らないので、どういう端末でも見やすいようにHTMLで公開するのが基本だと思いますが、PDFにしちゃってるあたりを見るとインシデント対応時のマニュアルや体制が意外と整備されてないのかなと。
サイバー攻撃を完全に防ぐことはできないですが、不正アクセスされたあとの対応に初歩的な不備があると世間からの信頼度がさらに低下してしまうので、今の時代はそこら辺もしっかりやっておかないとですよね。
corporate.m3.com/assets.ctfa…
ソースネクストさんのデータ流出事件、発表を見る限りどうやら「ユーザーのパスワードを平文で保存」していた可能性が極めて高そうですねー。
ソースネクストさんは自社製のセキュリティソフトとかも販売しているので、これは事業の信頼性に対する致命的な一撃になってしまうのではないかと。
セキュリティ系企業が脆弱性を放置して不正アクセスされてしまったことも問題ではありますが、「パスワードを平文で保存」は、見落としとかではなく完全な怠慢なわけなので。
初期仕様を引きずってしまったのだとしても、DBに保存されている既存の平文パスワードをハッシュ化する作業とバックエンドのコードの改修は工数をかけて順序を踏めば確実に対応できるものなので、その対応を怠ったというのはちょっと言い訳が効かないですよね。
最近のセキュリティ系ニュースの中で一番衝撃的でした笑
sourcenext.com/support/i/202…
AWSのLambda Web Functionが話題になってますが、Lambdaという名前が付いてはいるもののこれはもうFaaSではなくPaaSですね。
なのでGoogle CloudのGAE Standard等が役割としては共通する部分が多いと思うのでユースケースに関してはそこから考えるのがよいのかなと。
GAE Standard等のPaaSは
・比較的シンプルなスタンドアロンのサービスを開発や保守の手間をできるだけ小さくしてホストしたい
・スパイクアクセスへの対応が必須
という場合に適しているというのが僕の認識ですが、規模の大きいWebサービスでは前者のニーズはあまり発生しないので、となると大規模AWS環境におけるユースケースとしては後者が本命ということになりそうな気はします。
ECS Fargateだとスパイクアクセスにはどうしても対応できない(スケールが遅すぎる)ので、スパイクが予測される時間帯に合わせて事前にタスク数を増やしてスパイクが終わったら元に戻すという非常に面倒な対応が必要になるのですが、Lambda Web Functionでそのペインを解消できるようならかなり魅力的ではあるかなと。
ただし現時点では「Private APIとしては使えない(常にPublic。PrivateLinkも使えない)」、「ランタイムはNode.jsのみ」という色々な制限があるので、大規模サービスでの実戦投入は他社さんでの実例を見てからというのが無難そうではあります。
aws.amazon.com/jp/about-aws/…