【Webサーバー(IIS)】httpヘッダーにServerのバージョンが表示されてしまう脆弱性と対策
httpヘッダーにServerバージョン情報が
表示されてしまうという脆弱性の
指摘を受けた
今回はIISで動いているWebサーバーが
該当したためIISでの対策メモ
もちろんApacheやnginxでも
それぞれ対策方法があるはず
バージョンが表示されてしまう状況の再現と対策 その1
まずは普通にIEやらChromeやらEdgeで
該当のサイトにアクセスして
F12 開発用Windowを開く
ネットワークの応答ヘッダーあたりに
Serverのバージョンが表示されている
バージョン情報を出さないようにするには
IISマネージャ
URL書き換え
規則の追加
送信規制の空の規則
一致するスコープ サーバー変数
変数名 RESPONSE_SERVER
変数値 パターンに一致する
使用 正規表現
パターン .*
と設定
バージョンが表示されてしまう状況の再現と対策 その2
通常のアクセスだけなら上記で
対応できるのだが、
意図的に400 Bad Requestを起こすと
ヘッダーにServer情報が表示されてしまう
(一例) curl -I -H "Host:" http://exsample.com HTTP/1.1 400 Bad Request Contetnt-Length: Content-Type: text /html; Server: Microsoft-HTTPAPI/X.XX Date: Mon, XX XX 2019
これは通常のアクセスであれば
IIS自身が返すServerヘッダーなので
上記の設定で対応可能だが
イレギュラーなものは
Http通信を管理するドライバーである
http.sysが返すSeverヘッダー
となるため
これを表示させないようにするには
レジストリの変更が必要
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP
に
DisableServerHeader
という値を設置し
値のデータを 1 に設定
httpサービスの再起動
net stop http /y net start w3svc
Serverヘッダーに限らず
httpヘッダーにバージョン情報を
細かにのせてしまうと
脆弱性のあるバージョンだった場合
攻撃されやすくなるということらしい
そもそもバージョンを表示させている
こと自体、なんにも対策がされていない
ことが見て取れるため攻撃対象に
なりやすい、と
なるほど、確かに言われればその通り
にしても、
だったらそんなもんIISやらApacheが
デフォルトで表示しないように
なってればいいんじゃないかと
思うのは自分だけではあるまい
【Webサーバー(IIS)】httpヘッダーにASP.NETのバージョンが表示されてしまう脆弱性と対策
httpヘッダーにASP.NETバージョン情報が
表示されてしまうという脆弱性の
指摘を受けた
実は詳しくは理解してないけど
.NETはJavaなんかと
同列のプログラムの
フレームワークだと認識している
たとえばJavaで書かれたアプリは
Apacheを使おうがIISを使おうが動くけど、
.Net系は同じMicrosoft製の
WindowsServerとIISの組み合わせ
じゃないと動かない？
ゆえに今回のケースはIISでしか
発生しないと思われる
バージョンが表示されてしまう状況の再現
状況次第とは思うけど
今回のケースでは
どうにかして
500 Internal Server Error
をだすと
応答ヘッダー部分に
X-ASPNet-Version: 4.XXXX
とバージョン情報が表示されるというもの
ちなみに関係ないけど
phpで500エラーを意図的にだすには
以下のようにするらしい
<?php
header('HTTP/1.1 500 Internal Server Error');
?>
バージョンが表示されないようにするための対策
バージョンというかそもそも
X-ASPNet-Version:
という項目自体を出さなくする
必須で表示しなければいけない
項目は決まっているので
アプリ側が許せば
それ以外の項目は基本的に
表示・非表示の制御は
できる、、、
のかもしれない(自信なし)
設定するにはweb.configの
記載を修正する
GUIが売りのIISの場合、
たいがいのことはアイコンから
設定でき、その操作が
自動的にweb.configに記述される
しかし、マニアックなこととなると
web.configを直接編集しないと
いけないらしい
web.configと一言で言っても
IIS全体のマスター？configと
その下位に位置するサイトごとの
web.configが存在し、
通常はサイトごとのほうを編集する
サイト名を右クリックしてフォルダを開く
当初、フォルダのなかにweb.configが
見当たらずかなり悩んだが
なんでもいいので設定をすれば
自動的にweb.configが作成されるらしい
web.configを開いたら
configurationの中のsystem.webの中に
以下の通りX-ASPNet-Versionを無効化する
設定を記載する
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" />
</system.web>
</configuration>
httpヘッダーには実は非常に多くの
情報が含まれていて、デフォルトの
まま表示させてしまうと
攻撃者にとって有用な情報が
多々あるというのが最近
身をもって分かってきた
一般ピーポーには
バージョンが分かったくらいでは
どうしようもないけど
玄人にしたらよい手掛かりになって
しまうのだろう
インターネットに公開している
Webサーバーを持っている限り
気をつけるに越したことはない
【Squid】リバースプロキシサーバー・SSLアクセラレータのdefaultsiteの挙動について
Squidとは
そういえば、プロキシサーバーや
リバースプロキシってなに？
って聞かれるとイマイチ
はっきり答えられない
意外といろんな仕事をしているので
一概にこれと言えないからなのかも
しれない
例えば
サーバーが複数台あったとして
今どき通信は暗号化されてて当たり前
普通にするとすべてのサーバーに
SSL証明書が必要だけど
いちばん手前にリバースプロキシ
サーバーを置いて、こいつにだけ
SSL証明書を持たせる
いったん通信をすべてリバプロで
受けて各サーバーに振り分け、と
そうすればSSL証明書は
ひとつで済むという話
このSSLアクセラレータという機能が
今回携わった案件
と言ってもリバプロとサーバーが
１対１で、それ意味あるの？
と言えなくもない状態だけど
で、このプロキシやリバースプロキシ
のなかではかなりの確率で
Squidというサービスが仕事をしている
Squid.confの設定
Squidの設定は基本的にConfigファイルを
いじることで行う
もしかしたら使いやすいコンソールなぞ
存在するのだろうか
端的に言うと、リバースプロキシとしての
機能は以下の２行に凝縮されている
と言っても過言ではないと思う
https_port 192.168.0.1:443 accel cert=certificate.pem key=key.pem defaultsite=192.168.0.2 protocol=http cache_peer 192.168.0.2 parent 80 0 no-query originserver
192.168.0.1の443ポート(https)に対してリクエストがきたら certとkeyの証明書を使ってhttps通信をしたうえで 192.168.0.2に対して80ポート(http)で転送しなさい
で、defaultsiteがどういう意味かと言うと
httpリクエストにHostがない場合にはホスト名は192.168.0.2にしなさい
という意味
具体的には192.168.0.2サーバーの
環境変数Server_nameにdefaultsiteの
値を代入している
つまり、前回・前々回の記事にも
からむけど、リダイレクト先には
https://[Server_name]/xxx
を返すので
ローカルIPが漏えいする原因となる
転送先の192.168.0.2サーバーの
Apache.confに強制的に
Server_nameの値を入れ込んで
みたところ、やはり通信上
手前にあるSquidが優先されるらしく
対策はdefaultsiteの値をホスト名と
しておくしかないらしい
defaultsiteについてまだまだいろいろ
さて、Squidはhttpsで通信を受けて
httpで転送しました、
が、転送先(192.168.0.2)からSquidに
対する通信をhttpsにする機能は
持ち合わせていない(たぶん)
https(443)の通信しか許可していない
というケースは多いはずだから
このままだとhttpが蹴られてエラーが
発生するのがお約束のコース
なので、どこかでhttpsでSquidに返す
ような仕掛けを作ってあげることが必要
今回の案件ではこともあろうに
スクラッチ開発したアプリ側に
この仕掛けを作ってあった
Server_nameが192.168.0.xxx
(ぜんぜん関係ないアドレスだけど
Squid.confのdefaultsiteと一致)
だったらhttpsで返すという設定…
ちゃんと動いている間はよかったけど
リバースプロキシを入れ替えた際に
問題が発生、アプリ様がhttpsを
返さなくなる…
なのでアプリ側の設定はとりあえず
たぶんずっと無視してApacheの機能で代用
状況証拠から推察するに
Squid2(2.6)からSquid3(3.5)に
バージョンが上がった際に、
転送先のServe_nameを
Squid.confのdefaultsiteに
書き換えるという挙動が
変更になったと思われる
確認できる限り、
Squid3.5ではServer_nameは
元のまま書き換わっていない
これを示している文献は
見つかっていないが
Squid自体がもともと
http1.0での通信をベースに
作られているということを
鑑みると一定の信憑性はあるかと
この調査だけで2～3ヶ月かかり
自宅のLinuxにもSquidを導入したりで
えらく大変だった、けど
得るものも多かったかもしれない
意図せずして自宅にWebサーバーを
構築できる日も近いかもしれない
【Webサーバー(Apache)】ローカルIPアドレスが漏えいしてしまうという脆弱性と対策について
ローカルIPがばれてしまう脆弱性への対策 Apache編
インターネットに公開している
Webサーバーについて
脆弱性の診断を受けたところ、
特定の条件下でローカルIPが露呈
されてしまう脆弱性が発見される
IISのサーバーだけでなくApacheの
サーバーでも発見された
ちなみにIISとApacheとnginxの
シェアはほとんど同じくらいらしい
ということはおのずと
対策についてもそれぞれ
覚えないといけなそうだが
これもいい機会と思っておこう
Apacheにおいての対策は
Sever_nameを指定しておくこと
httpリクエストとServer_nameの関係
Server_nameとは
Apache内で使われている環境変数のこと
一見自身のサーバー名が格納されるように
見える
http(またはhttps)://exsample.com でアクセス ↓ Server_name : exsample.com
として返してくれる
実はこれ
> HEAD /xxxx HTTP/1.1 > Host: exsample.com > User-Agent: xxxx > Accept: */*
こんなかんじで送信した
httpリクエストのHost部分を参照している
つまり
IP直打ちでアクセスすると
http://12.34.56.78 でアクセス (※グローバルアドレス) ↓ Server_name : 12.34.56.78
IPで返してくることになる
ここでhttp1.0・Hostなしで
リクエストを送信すると
> HEAD /xxxx HTTP/1.0 > Host: > User-Agent: xxxx > Accept: */*
Sever_nameはどうなるかと言うと
Server_name : 192.168.1.100
"Hostを読んで格納したいけど
空白だからローカルIPを返しとけ"
という挙動になるらしい
これがローカルIPが漏えいしてしまう理屈
Server_nameの設定
なので対策のひとつとしては
http1.0でのリクエストが来ようが
Server_nameをあらかじめ固定しておき
常に一定の値を返すこと
Apacheのconfigファイルで
変数を強制的に指定
SetEnv Server_name exsample.com または SetEnvif _ .* Server_name=exsample.com ※条件つき書式 と言ってもどんな条件でも Sever_nameをexsample.comにしろ というだけの意味
configファイルは
旧来のApacheだと
httpd.conf
というファイル名
Ubuntuに導入したApacheは
(Apache2？)
従来httpd.confでまとめられていた
configがばらけている様子
envvars
というファイルを編集するっぽい
【Webサーバー(IIS)】ローカルIPアドレスが漏えいしてしまうという脆弱性と対策について
ローカルIPがばれてしまう脆弱性への対策 IIS編
インターネットに公開している
Webサーバー(IIS)について
脆弱性の診断を受けたところ、
特定の条件下でローカルIPが露呈
されてしまう脆弱性が発見される
IISにおいての対策は
結論から言うと
バインドの設定で
ホスト名を指定すること
とはいうものの
ここまでたどり着くのは
紆余曲折あったわけで…
バインドの設定
まず試したのは
実はバインドの設定
インターネットインフォメーションサービス(IIS)マネージャー ↓ サイト ↓ (サイト名 exsample.com) ↓ バインド ↓ ホスト名 に(exsample.com)をいれる
こうするとかならず
http(またはhttps);//exsample.com
でないとアクセスできなくなる
グローバルIPでもアクセスできない
ここに問題があった
どういうわけか
同じサイトなのに
ホスト名を２つつけて
別サイトにアクセスしているかの
ような意味の分からない運用を
していたため
http://exsample.com
はつながるけど
http://test.com
はつながらない
という不具合が発生
(中身は同じサイト)
そもそもサイトにアクセスする
ときのURLをしばるだけで
対策に効果があるのか？
ということでいったんボツ
リダイレクトの設定
脆弱性が発見されたのは
実在するフォルダに対して
http://exsample.com/folder
と末尾に" / "をつけないと
そのフォルダにリダイレクト
されてしまうために起こる
というもの
なので
http://exsample.com/folder/
にアクセスされたときに
トップページにリダイレクト
されるようにしてしまおうと
考えた
まずはIISにリダイレクトが表示
されていない場合、
こんなところに設定があった
インターネットインフォメーションサービス(IIS)マネージャー ↓ サイト ↓ (サイト名 exsample.com) ↓ HTTPリダイレクト ↓ このリダイレクト先に要求をリダイレクト にトップページのURLを入力
一見うまくいったように見えた
が、肝心のトップページから
ログインする際にリダイレクトが
発生するため、
ログイン→リダイレクト→
トップページ(ログイン画面)
のループという
お粗末な状況が発生
この案もボツ
【Webサーバー(Apache・IISなど)】ローカルIPアドレスが漏えいしてしまうという脆弱性と対策について
ローカルIPがばれてしまう脆弱性
インターネットに公開している
Webサーバーについて
脆弱性の診断を受けたところ、
特定の条件下でローカルIPが露呈
されてしまう脆弱性が発見される
HTTPリクエストを送信する際、
・http1.0 で
・Hostヘッダを空白にして
・アドレスの末尾に/をつけない
という条件で発行
具体的には
curl -0 -i -H "Host:" http://test.com/sample
のような感じでhttpリクエストを送信する
curl はLinuxのコマンドのひとつ
Windowsでもパッケージがあるので
インストールすればコマンドプロンプト
から使える
ちなみにオプションは
-0 : http 1.0 を指定 -i ：リクエストヘッダを表示 -H ：リクエストヘッダを編集
すると
オブジェクトは移動しました このドキュメントは http://192.168.0.10/sample/ ここで見つかる可能性があります
などとローカルIPが表示されるというもの
まず httpリクエストの規格の理解
httpリクエストにもバージョンがあって
だいたいデフォルトでhttp1.1が適用される
httpリクエストのヘッダのなかには
Host というステータスがあり
http1.1以降は必須項目となっている
この Host を元にアクセス先のURLを
決めてたりするので当然といえば当然
ところが旧規格である http1.0 では
Host が必須ではないので空白で
リクエストを送ることもできる
Host が空白のリクエストを送信されると
Webサーバーは困ってしまい
とりあえず自身の IP をホストとして返す
これがローカルIPのため漏えいにつながる
というもの
思うに、http1.0 でリクエストが
送信されることが想定されていないために
その辺の設定がおろそかになっているのだと思う
そんな旧規格は使えないようにすれば
いいんじゃないかと言いたいところだけど
まだまだ使用しているサービスがあって
そうもいかないらしい
リダイレクトの仕組み
http://test.com/sample/
と末尾に / をつけるとそのフォルダを
指定したことになるのだけど
http://test.com/sample
と / をつけないとsampleという
ファイルを探しに行く
が、見つからない状態となる
sample という名のフォルダが実在した
場合、Webサーバーは親切？にも
sample はフォルダのことかもしれない
と判断してくれて、ファイルは
sample フォルダで見つかるかもよ！
とメッセージをだしてくれる
というリダイレクトの処理が
裏側では走っているらしい
しかし、、
とんだマニアックな指摘で
そんなとこまで対策せんでも…
と思うのも人情だけど
とあるサイトで
Webサーバーを公開することは
家のドアを開けてチンピラを呼び寄せる
ようなもの、と説明されていて
妙に納得感があった
公開する以上は常に危険に晒されている
わけであって、万全の対策が必要で
あることもまた真理
実際、同じ手口？でアクセスがあって
アラートメールがとんできていたりして
IPの身元を調べるとドイツからのアクセス
だったりした
もちろん踏み台の可能性も多分にあるが
せっかく調べてもらって
当人達には気づかないような指摘を
いただいたのだから、
ありがたく対策を講じるのが
肝要だと思うのであった
【Linux】crontabをオプションなしで起動してはいけない
crontabとはLinxのサービスのひとつ
決まった時間にタスクを実行してくれる
Windowsで言うところの
タスクスケジューラ
さて、このcrontab
コマンドのあとに
-e (編集) -l (閲覧) -r (削除)
などのオプションをつけて
起動することができ
どう考えても -r あたりはやばいことは
明白なのだけど
実はオプションなしで実行すると
場合により大変なことになる
いやいや普通オプションなしで
実行しても別に変な動きしないでしょ
と考えてしまうところだが、、
crontabの内容が書き換えられてしまう
crontab
だけで実行すると
端末側は
crontab XXXX
crontabの内容をXXXXファイルの
内容に置き換えろ
という意味になるらしい
つまり空白で実行すると
空白に書き換えろという
ことになってしまう！
どうやら Ctrl + C で
回避できるらしいけど
気づかずにエンターキーやら
適当な操作をしてしまうと
