サーバ証明書の発行を検知、初期状態のWordPressに侵入する手口が横行 28
ストーリー by nagazou
ご注意 部門より
ご注意 部門より
サーバ証明書の発行を悪用し、WordPressで作られたサイトをターゲットにする攻撃が指摘されている（The Daily Swig、matsuu序二段さんのツイート）。
The Daily Swig の記事によれば、この攻撃はCertificate Transparency（CT）システムを悪用したもの。CTでは不正な証明書を迅速に発見するため、証明書を直ちに公開ログに記録することが義務づけられている。今回指摘されている攻撃では、悪意のあるハッカーが先の公開ログを監視し、WordPressの新規ドメインを検出すると即座にアクセス、初期インストール状態のWordPressにバックドアを仕掛けるという手法であるようだ。
この攻撃により、TLS証明書が要求されてから数秒から数分のうちにサイトがハッキングされたという証言も複数出てきているとのこと。証明書認証局のLet's EncryptのJosh Aas氏は「もし攻撃者がCT公開ログを直接監視しているのであれば、新しい証明書エントリをいち早く確認可能であり、攻撃を成功させるための時間的余裕を与えてしまうことになる。（中略）安全が確保されるまではWordPressによる新規サイト公開は避けるべきだろう」と述べている。
The Daily Swig の記事によれば、この攻撃はCertificate Transparency（CT）システムを悪用したもの。CTでは不正な証明書を迅速に発見するため、証明書を直ちに公開ログに記録することが義務づけられている。今回指摘されている攻撃では、悪意のあるハッカーが先の公開ログを監視し、WordPressの新規ドメインを検出すると即座にアクセス、初期インストール状態のWordPressにバックドアを仕掛けるという手法であるようだ。
この攻撃により、TLS証明書が要求されてから数秒から数分のうちにサイトがハッキングされたという証言も複数出てきているとのこと。証明書認証局のLet's EncryptのJosh Aas氏は「もし攻撃者がCT公開ログを直接監視しているのであれば、新しい証明書エントリをいち早く確認可能であり、攻撃を成功させるための時間的余裕を与えてしまうことになる。（中略）安全が確保されるまではWordPressによる新規サイト公開は避けるべきだろう」と述べている。
Let's encryptとは関係なくwordpressは狙われてる？ (スコア:1)
最近apache入れてLet's encryptでssl設定。その後wordpressをインストールしました。
この記事を見てlogを確かめてみました。わずか数日の間ですが、30ぐらいのip addressから /XXX/wp-includes/wlwmanifest.xml への謎の大量アクセスが確認できました（XXXはblog web wordpress wp 2020 2019 …など）同じIPから数時間ずらしてアクセスを試みているようで、手ぐすねを引いてwpのインストールを待ってる感じです。
ただ、この攻撃の内1件はLet's encrypt以前に行われておりまして、Let's encrypt入れないから大丈夫というわけではないかもしれません。
aptのログでapacheとcertbot(Let's encryptで使う)のインストール時間が確認できるのですが、apacheを入れて1時間後にはトップディレクトリに所属不明のIPからのアクセスがあり、その数分後にwpを狙った攻撃が確認できました。これはcertbotを入れる前です。
ちなみに私自身のwpは、SSL化後、トップディレクトリをbasic認証。wpのファイルを展開後、ブラウザアクセスしてインストール完了。ただのまぐれなのですが、安全にインストールできたと思います。basic認証を設定したのは、単に完成前のブログを他人に見られるのが嫌だったからなのですが…
よくわからん (スコア:0)
WordPressは初期インストール状態だと脆弱でインストール後に設定を変更する手順が必要ってこと？
だとしたらそこを改善すべきような
Re:よくわからん (スコア:5, 参考になる)
・WordPressを設定するためには、公開URLを確定する必要がある(virtualHostなどで複数のURLからアクセス可能な状況でも、設定と違うURLからアクセスすると怒られる。httpとhttpsも区別される)ので、httpsで公開するサイトを作るためには、WordPressを設定する前に、証明書の設定が必要
・WordPressの初期状態でアクセスすると「DB設定やパスワード登録などを行う初期設定画面」が出るので、その段階でアクセスできれば誰にでも好き勝手できる(推測ですが、攻撃者は、パスワード登録して利用開始→不正ファイルアップロード→設定クリアして初期状態に戻す、という対応をしてるんじゃないでしょうか)
という鶏と卵状態ですね。
設定の簡便さのために「インストール後の最初のアクセスでパスワードを登録する」のは、WordPressに限らずよく見かける初期状態ですが、
従来は、そんな状態のURLが外部に漏れることもないし攻撃されることないだろう、と高をくくっていたのが
CTにより、その段階のサイトを素早く見つけることができてしまう、と…
対策としては、
案1・まずオレオレ証明書を入れ、WordPressの設定を済ませてから、Let's Encryptの証明書取得に切り替える
案2・http設定でWordPressの設定を済ませてから、Let's Encryptの証明書取得し、https設定に切り替える(tweetにドメインの変更はトラブルの元とありますが、同名ドメインでのhttp→https移行は支援プラグインなどがあり、まず問題は起きません)
とかですかね。
Re: (スコア:0)
一番手っ取り早いのはApache/nginxへの登録時に一緒にBASIC認証を入れるとかじゃないかな
# WordPressユーザがそんなことできるのかは知らん
Re:よくわからん (スコア:1)
いや何らかのアクセス制限を行うとLet's EncryptのHTTP-01認証のアクセスも通らなくなるので、証明書を取れなくなってしまうというのっがミソ
Re: (スコア:0)
/.well-known/acme-challenge/ だけオープンしとけば通るのでは
Re: (スコア:0)
WordPressは何かと狙われやすいので割と初期から管理系があるwp-adminにはBASIC認証とIP制限かけて
DBのID/Passとかが書かれているwp-config.phpは初期設定のディレクトリの親ディレクトリに入れるってのは、結構前からWordPressの入門系サイトにもよく書かれている内容ですので
理解せずとも猿真似で出来るユーザーはいるかと・・・
※その程度を理解できないユーザーがサーバを公開することについては別な問題と言うことで
Re: (スコア:0)
なにはともあれ、まずWebサーバーへアクセスできるマシンやIPアドレスを限定すべきでしょう。
その後の設定とか準備したあとに公開していい状態になるわけで、初期状態で最初から全世界に公開しておくっておかしすぎて理解できない。
ひょっとしてWeb界隈では手順として普通なのか？
Re:よくわからん (スコア:2)
Let's Encryptのドメイン所有者確認(HTTPチャレンジ)では、
Let's Encrypt側から指示されたファイルをWebサーバに置く必要があるので、
IPアドレス制限なりBASIC認証なりをかける場合は、
そのファイル置き場所は誰でもアクセス可能にする、という一手間が発生します。
DNSチャレンジならWebサーバ非公開でも問題ありませんが、HTTPチャレンジよりもはるかに設定が面倒。
まあ、結局のところ、問題の起きない正しい方法はありますが、それなりに手間が入り組んでるので、
初心者でも簡単に設定できるとサイト管理の心得がない人が手を出して
穴を開けてる、ってことでしょうね。
Re: (スコア:0)
オレオレ証明書ってクライアント側の判断用でクライアント側がＯＫならアクセスできるのでは？
クライアント側を制限するときは、オレオレ個人証明書でないの？
Re: (スコア:0)
オレオレ証明書ならCT公開ログに記録されることが無いので、CT公開ログを監視しているだけの攻撃者には気付かれることが無い、というだけのことでしょ
もちろん理想的には Wordpress の設定完了まではアクセス可能なクライアントを制限するべきだけど、CT公開ログから検知されるのを防ぐだけならこの方法でできる。
Re:よくわからん (スコア:2)
PHPが使えるVPSとかにうｐして直叩きするんです。ページが読み込まれると初期設定が始まります。事前にパスワードをファイルに書いて含めておくとかDBをいじって書き込むとか、VPSにVPNで繋ぐような気の利いたことは中々できません。
危なくないのかって? ……。
Re: (スコア:0)
VPSでも認証ぐらいかけられるでしょ
Re:よくわからん (スコア:2)
初期パスワードでログインされちゃうとかかねぇ。だとすると、WordPress側での改善はしづらい部分かも。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
初期パスワードをインストーラーでランダムに発生させてもダメ？
Re: (スコア:0)
ランダムに生成したパスワードをサイト管理者のみに伝える汎用的な方法がない
Re:よくわからん (スコア:1)
WordPress インストール、で検索して最初にヒットしたページからたらい回されて辿り着いたWordPress のインストール [wordpress.org]を流し読みすると、
パスワードの設定の前にブラウザからアクセスしてインストールスクリプトを実行、なる手順が出てくるね…。
初心者でも簡単にセットアップ出来るように作ったあまり、初心者には危険すぎる手順になっちゃったのかな。
1. ドメイン名を準備
2. 外部からアクセス可能な空っぽのWebサーバを立ち上げてlet's encrypt
3. Webサーバに証明書をきっちり設定する
4. Webサーバの外部からのアクセスを禁止に
5. WordPressのスクリプトを展開
6. ローカルから繋げてブラウザでWordPressのインストールスクリプトを実行
7. 十分に安全な設定にしてから、再び外部からのアクセスを許可
という手順が要る。
最初のツイートとかを見ると、WordPressはURL設定に敏感なので、セットアップ後にURLを変えるのは面倒くさいらしいので。
だとすると、6でsshのポートフォワードなりを使いたくなるけど、ちょっと面倒くさそうかな。
プロクシをフォワードするのが楽かな。
あと、いずれにせよ潜在的に危険な手順だけど、
WordPressを展開→let's encrypt→WordPressの初期セットアップ
よりは、
let's encrypt→WordPressを展開→WordPressの初期セットアップ
の方が短時間とは言えバレるまでにラグがあるし危険な状態の時間が短い分だけかなりマシかな? と思ったけど、そんな事はないか。
攻撃者側は、登録されたのを見かけた時点で、次はWordPressが展開されるかも知れない、と鬼のようにアクセスを繰り返し始めたら良いだけなので。
Re: (スコア:0)
サーバー証明書を入手できた時点で、アクセス可能なIPアドレスを制限するとか。
共用サーバーとかVPSとかだとIPアドレス制限ができなかったり知識が必要だったりするけど、
AWSやAzureだったら、あんまり知識無くてもできるし。
Re: (スコア:0)
> サーバー証明書を入手できた時点
がCTでほぼ即座に突き止められてしまうから間に合わないわけで
Re: (スコア:0)
上の手順では、その時点ではまだ WordPress 入ってないでしょ
Re: (スコア:0)
というか、 #4251956 の手順が前提なら #4252048 が言ってるのはまんま 手順4. のことでは
Re: (スコア:0)
AWSならALBにACMの証明書入れればいいじゃない？
# Azureは知らん
Re: (スコア:0)
初期状態のまま公開するなよって話じゃないの？
知らんけど。
Wordpressなら仕方ない (スコア:0)
Wordpressは今でも採用してるページが非常に多いから攻撃のターゲットにもなりやすい。
日々脆弱性が見つかってるから常に情報アップデートしてメンテナンスしてく必要があり手間がかかる。
脆弱性データベース [jvndb.jvn.jp]。現段階で3000件以上登録。
＃簡単に構築できて継続的にメンテナンス費用取れるから、攻撃成功されてもダメージの少ない公立学校など（からの注文で作られるページ）によく採用されてる
笑い事ではないが笑ってしまった (スコア:0)
>公開ログを監視し、WordPressの新規ドメインを検出すると即座にアクセス
監視に慣れてるなぁとw
Re: (スコア:0)
> 監視に慣れてるなぁとw
え？サーバ監視を人力でやってるんですか？暇なの？
こんなのスクリプトで自動処理ですよ。だから即座に検出できるし、即座に攻撃できる。サーバー監視もサーバー攻撃も、どちらもスクリプト設置して放置するだけ。
Re: (スコア:0)
人力の発想自体まるでなかったが…そうかそう思っちゃう人居るのか。
手口を考えた人はかしこい (スコア:0)
セットアップ中で脆弱性がある可能性が高い新規サイトを狙う効率的な方法が発見された感じ
WordPressだけじゃなく、他の脆弱性もまとめて狙えば、もっと効率よくなるのでは？