半年１回の更新を目指すよう心がけます。
日記？ムリっ。
半年１回の更新を目指すよう心がけます。
W32.Welchia.Worm(symantec)だか
WORM_MSBLAST.D(TREND MICRO)だと思われるが、
ICMP Echo と TCP/80 へのアクセスが大量にログに残ってる。
このワーム、MS03-007を突くらしいのだが、
GET / HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; DigExt) Host: xxx.xxx.xxx.xxx Connection: Keep-Alive
というログしか残っておらず、とても攻撃には見えない。
そんなもんなんでしょうか？それとも取りこぼしてるんでしょうか？
_ totoro [んとんと、私の持ってるシステムなら、出ますよ（ぉぃ]
_ totoro [アドレスを、コソッと教えて頂ければ、コソッと結果を出します]
_ みゃー [IPV6の広い海におぼれそうになるよねぇ〜（ごぼごぼ]
_ bun [礼状もありませんし、totoroさんにこれ以上不正アクセスをさせるわけにはいかないので(笑)]
_ bun [ウチでは、2^80個もらったアドレスのうち３個しか使ってないので、おぼれることはないかと。]
_ totoro [2^80個もIP貰ったんですか？ v6 Over v4使えば、無敵じゃないですか・・・。 2^10で良いので、分けて..]
_ bun [https://www.iijmio.jp/guide/ipv6/ これで /48 もらいました。]
_ totoro [うがぁ！IIJ関係じゃないですか！ ソニー信者の私に、裏切れと？]
_ bun [bit-drive もくれますよ。http://www.v6.bit-drive.ne.jp/]
_ totoro [早速申し込んでみました。 64K個も、何に使いましょうかねぇ・・・。]
mod_security で、POST データのログを取得しようとした。
$ tar xvfz mod_security_1.5.tar.gz
# /usr/sbin/apxs -cia mod_security_1.5/apache2/mod_security.c
# vi /etc/httpd/conf.d/security.conf
LoadModule security_module modules/mod_security.so
<IfModule mod_security.c>
SecAuditEngine On
SecFilterDefaultAction "pass,log"
SecAuditLog logs/audit_log
</IfModule>
# service httpd restart
いろいろアクセスしてみる。
192.168.0.1 -> 192.168.0.2:80
# cat /var/log/httpd/audit_log
========================================
Request: 192.168.0.1 - - [[30/ 6月/2003:15:40:46 +0900]] "POST /cgi-bin/a.cgi HTTP/1.0" 200 4
Handler: cgi-script
----------------------------------------
POST /cgi-bin/a.cgi HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: ja
Content-Type: multipart/form-data; boundary=---------------------------7d3190242804ba
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 192.168.0.2
Content-Length: 243
Connection: Keep-Alive
Pragma: no-cache
-----------------------------7d3190242804ba
Content-Disposition: form-data; name="foo"
var
うむ、いい感じ。
というメモが手元にあるのだが、今 mod_ssl-1.6 で試してみたがちっともうまくいかない。２ヶ月も前のことなので、何かコツがあったのかどうかも思い出せない。全然「うむ、いい感じ。」じゃないし。
ここのサーバにも仕掛けてあったんですが、全くログが取れてませんでしたとさ(;´Д`)
2003-09-04 追記: 一応動作しました。
2007-08-30 : Ver 2.1 でやってみた。
単に whois サーバの指定をしてなかっただけでした。
$ whois 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -h whois.apnic.net [Querying whois.apnic.net] [whois.apnic.net] % [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inet6num: 2001:xxxx:xxxx::/48 : :
APNIC Whois Databaseで検索しても出てきますね。無知っぷりをさらしてしまった。
ソースをいじってログが取れるようにしてみたけど、これが原因なのかどうかも不明。
--- mod_security-1.6/apache2/mod_security.c 2003-09-04 13:56:48.000000000 +0900 +++ mod_security-1.6/apache2/mod_security.c 2003-09-04 13:57:04.000000000 +0900 @@ -187,7 +187,7 @@
typedef struct { char *buffer; - char *sofar; +// char *sofar; long length; long remaining; } request_body;
「うむ、微妙な感じ。」
ちなみに、ログはこんな感じで残ってます。
======================================== Request: xxx.xxx.xxx.xxx - - [[04/ 9月/2003:14:24:14 +0900]] "POST /tdiary/ HTTP/1.1" 200 209 Handler: cgi-script ---------------------------------------- POST /tdiary/ HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */* Referer: http://www.devnull.jp/tdiary/?date=20030904 Accept-Language: ja Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Host: www.devnull.jp Content-Length: 138 Connection: Keep-Alive Cache-Control: no-cache Cookie: tdiary=%A4%DF%A4%E3%A1%BC&
date=20030904&name=%A4%DF%A4%E3%A1%BC&mail=&body=%A4%D3%A4%DF%A4%E7%A1%C1%A4%F3BY%A4%BD%A4%CE%A4%D4%A1%BC%C9%F7%CC%A3&comment=%C5%EA%B9%C6
HTTP/1.1 200 OK Set-Cookie: tdiary=%A4%DF%A4%E3%A1%BC&; path=/tdiary/; expires=Wed, 03 Dec 2003 05:24:14 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/html
少し前に作ったツール。proxy サーバとして動作し、ブラウザからの HTTP リクエストを受け取り、書き換えて送信するためのものです。HTTPS の場合でも、復号して書き換えることができます。(スクリーンショット)
Java で書いたので、JRE が必要です。GUI には eclipse の SWT を使ったので、SWT ライブラリが必要です。
注意: 非常に中途半端な出来です。近くにいる人に使ってもらってバグとか要望を出してもらっていたんですが、ラーメンとそばとスパゲッティが混じってしまうくらい汚くなってしまい、メンテナンスは諦めました。そんな状態ですので、今後これに手を入れることはないでしょう。ただこのまま捨ててしまうのは勿体無いので晒します。ひょっとすると新しく作り直すという形で要望を反映させられるかもしれませんが、まったく未定です。
あとで試してみると言っておいて忘れてたのを、ここみて思い出した。まだまだ発展途上で、今すぐどうにかなるものでもなさそう。プラグインという形でいろいろと機能を増やしていくようなので、Java の勉強に何か作ってみるのも良いかと。
id:nakatakaより。こちらは Perl で何か作ったようで。公開予定はないそうですが、予定外の公開は？
読冊日記より。アメリカの女子高生が科学的な検証をしたそうです。
私も 「5 秒ルール」で育ってきましたが、「3 秒ルール」な文化の人からすると「汚ね〜」だとか(笑)
エラーメッセージが出なくともアプリケーションの挙動からアプリケーション内で使ってる SQL 文を推測する、という話だと思うんだけど。
上と同じような話。１日に出てたけど、メモし忘れてました。
リバースプロキシとして動作する HTTP サーバ。設定ファイルでパターンを指定しておいて、そのパターンにマッチする HTTP リクエストが来ると、その接続を切断してくれたり、指定しておいたコマンドを実行してくれたりする。mod_secury も同じようなことができるけど Apache 専用なのに対して、これはどんな HTTPD でも使えるでしょう。プラグインという形で機能追加ができるあたりも気に入った。こりゃ便利。
ソースを見ると、HTTP リクエスト丸ごと保存しておいてくれそうなんだけど、どうやるのかな？ ソースを見る前にマニュアルを見ましょう＞自分
第5回 Webアプリケーションの検査テクニック（1）ということで、Web アプリケーションの検査手法です。自動検査ツールでは検査しきれない部分があるという話と、手動検査で使える補助ツールとして Achilles の紹介です。
ここのページにもリンクしてくださっている、sPortRedirector も紹介されています。
nakatakaの日記より。上に書いた WebScarab がこの XML シグネチャを使う。用意されているシグネチャもそれぞれのシグネチャの内容も十分とはいえないが、XML で書いておくと後々の再利用が容易なので、とりあえずこの形式に従って書いておいても損は無いだろう。
31-Sep-2003 付け(?)で、Odysseus 2 - Beta 5 が出てました。Odysseus はほとんど使い込んでないので、何が変わったのかよくわかりません。ChangeLog をご覧ください。
バージョンアップ。body を含まない POST や PUT メソッドのリクエストを受け取ったときに、タイムアウトまで待たずに切断されるようになりました。
ちょっと今読んでる時間がないので、URL だけメモ。
There Is More to Securing Web Services Systems Than WS-Security
What IIS Security?
資料が公開されました。http://www.port139.co.jp/cakeoff.htm
単なる言い訳なので、port139ml ではなくここでこそっと書きます。
自分では相当悩んだつもりだったんですが、まだまだ悩みたりなかったようです。 ログから不正なアクセスを探す、という行為を日常的にやっているわけではなかったので、理論上はこうすればできるという観点から入らざるを得ず、現実離れしているところが多々あったと反省しています。 今回現場のみなさんの話をいろいろ聞けたので、それを踏まえて順次アップデートしていきます。
全ての攻撃を完璧に見つけ出すためには、全てのデータを保存しておかないとだめだろう、という意識は変わりません。しかし、特定の攻撃だけに絞って考えると必ずしも全てのデータが必要なわけではないです。これがまとまると、サイトの重要度・規模・許容できるリスク・予算に応じてどこまで実施するかを選択できるはずなので、普段攻撃診断しながらも考えてみます。
これくらいしかまともなネタがなかったので、溜めてました。
ネタ元は、Forensic Log Parsing with Microsoft's LogParser。ログファイルを分析させて SQL インターフェースで結果を取得できる。IIS のログに限らず、IISW3C・NCSA・IIS・ODBC・BIN・IISMSID・HTTPERR・URLSCAN・CSV・W3C・EVT などに対応している。
Version 2.0 は単品で、Version 2.1 は IIS 6.0 Resource Kit Tools に付属されて配布されている。
_ TOTORO [当日、いろいろと教えてくださいね。 わたし、素人なもので・・・]
_ B-) [講師、おつかれさまでございました。m(_ _)m]
_ bun [こそっとは許されないらしい Д]
_ Fumi-pooh [待ち合わせに遅刻してしまいましてゴメンナサイです^^;やっぱり現場は大変なんですねぇ。休憩中の雑談でも、Webアプリ..]
_ みゃー [待ち合わせに遅刻したのはわたしのせーでごめんにょろ♪つーかコクティすごい資料だったね。感心したっ！やるときゃやるねぇ..]
_ やまにょん [遅ればせながらこんにちは。こっそり遊びに来てたのですがコメントし難くて・・・。講師お疲れ様でした。また冴えたお話を聞..]
高木浩光＠茨城県つくば市さんよりコメントを頂きました。私の話した手法だけでは、確かに見つけられない攻撃がありました。
一点、
国分氏の講演では、セッションハイジャックを見つける方法として、「Set-Cookie: で発行したセッションIDと異なる Cookie: が送られてきた場合を探す」ということが述べられているが、攻撃者は、そもそも Set-Cookie: を発生させるようなアクセス（通常、これはパスワード送信時に起きる）をすることなしに、最初から直接に、他人用のセッションIDを Cookie: としたリクエストを送信するのだから、この方法では検出できないだろう。
正規のアクセスでは、Set-Cookie: で発行された内容が、
Cookie: として送信されてくるはずです。
Set-Cookie: が発生していないのに、セッションID が Cookie: として送信され
てくるのは、不審なアクセスとして検出できるのではないでしょうか。
ただ、その後に述べられている「同じユーザを判別できない」状態では机上の空論であることは間違いありません。
公開されていないディスカッションの中で、「事故後に『個人情報の流出はありません」とすぐ発表が出せるわけがない』と話しましたが、どのような調査をした結果そういう結論にたどり着いたのかさらに興味がわきました。
サイトの公開以降正規のユーザを含め誰もアクセスしてないとかなんでしょうか？
Note。実際の中身までは追いかけられていません。
_ みゃー [日記風味な週記なのか、週記風味な日記なのかどっちでせう（ｗ]
_ bun [開店キャンペーンってことで。そろそろ持ちネタを出し尽くす頃なので、じきに落ち着きます。]
_ あいのり日記 [勝手に推測なんですが、対象が IIS じゃないと攻撃コードがこないとか・・・？]
_ bun [おっ、確かに IIS には SEARCH とか来ているので、もしかするとそうなのかも。どっか空きグローバル IP ア..]