Techracho

TwitterのXSS脆弱性をついたタイムライン汚染攻撃

このエントリーをはてなブックマーク Share
2010.09.21    Web, セキュリティ, 馬場   タグ: , —    baba   

本日夕方から、TwitterのXSS(Cross Site Scripting:クロスサイトスクリプティング)脆弱性を突いた攻撃がすさまじいペースで広がっています。

私もWebで見る派なので、踏んでしまいました(それによりご迷惑をおかけした方申し訳ありません)。
リツイートされたものを解除しようにもログインできず、公式ReTweetはWebでしか解除できないので困っています。

公式ReTweetの仕様上の問題点も活用した、なかなか鮮やかな手口ですね。

問題のツイートの一例が↓です。

<span class="entry-content">
	<a
		href="http://a.no/@"
		onmouseover=";$('textarea:first').val(this.innerHTML);$('.status-update-form').submit()"
		style="color:#000;background:#000;/"
		class="tweet-url web"
		rel="nofollow"
		target="_blank">
	http://a.no/@"onmouseover=";$('textarea:first').val(this.innerHTML);$('.status-update-form').submit()" style="color:#000;background:#000;/
	</a>
</span>

要するに、マウスオーバーしたら自分と同じものをつぶやくというコードですね。

肝の部分は↓です。

http://a.no/@"onmouseover=";$('textarea:first').val(this.innerHTML);$('.status-update-form').submit()" style="color:#000;background:#000;/

httpで始まる文字列はリンクに変換されますが、@の認識の仕方にバグがあったようですね。文字列の最後までがリンクURLと認識され、見事にXSSが成功しています。

それにしても驚くのが、感染の早さ。
技術的なキモは、単純なURL判定アルゴリズムのミスですが、それをTwitter上で実施するだけでここまでのスピードで広がってしまうとは、リアルタイムなTwitterの怖いところです。

Twitterなので、直接的な被害はTwitter上に限られていると思いますが、どのくらい工夫した亜種が流れているのでしょうか?

2010/09/21 22:44追記
該当のXSS脆弱性がひとまず修正されたようですね。
また、原因になっていた公式リツイートは削除されているようです。
なお、ログインする際はブラウザのキャッシュとCookieを消してからのほうが良いです。

基本的にXSSでパスワードが知られてしまうことはありませんが(ブラウザに保存していたら知りません)、メールアドレスの変更→パスワードリセット を使ってパスワードを変更することは理論上可能なので、プロフィールがおかしくなっていないかチェックしておいた方が良いですね。

2010/09/21 23:05追記
Twitter公式情報で、修正がアナウンスされています。
日本時間22:50の時点で、全世界に修正が行き渡ったようです。
http://status.twitter.com/post/1161435117/xss-attack-identified-and-patched

Windows Server でホームディレクトリ

このエントリーをはてなブックマーク Share
2010.04.15    Windows, セキュリティ, 馬場      baba   

ActiveDirectory環境下でファイルサーバにWindows Serverを使っている場合、共有フォルダや自分専用フォルダを、Z:などのドライブに割り当てると便利ですね。

共有フォルダを割り当てるには、グループポリシーの「ユーザの構成→基本設定→ドライブマップ」を使うと簡単です。

自分専用フォルダを割り当てるには、まずそのフォルダを作成しないといけないので、ログオンスクリプトと使うと良いです。

準備
\\server という名前のサーバに、usersという共有フォルダ(Unixの /home に相当)を作っておきます。
一般ユーザが書き込める権限を付けておいて下さい。

スクリプトの設定
グループポリシーの以下の場所で、ログオンスクリプトを設定できます。

ユーザの構成 → ポリシー → Windowsの設定 → スクリプト(ログオン・ログオフ) → ログオン

ここのPowerShellスクリプトで、以下のような内容のファイルを指定すると、専用フォルダが作れます。

$user = $env:USERNAME
$dir = “\\server\users\$user”
if (-not (test-path $dir)) {
mkdir $dir
icacls $dir /inheritance:r /grant:r $user”:f”
}
net use z: $dir

ポイントは icacls の行です。
/inheritance:r を指定することで、親フォルダからの継承を外し、アクセス権を削除します。
そしてgrant:r を指定することで、自分だけはフルアクセス権を入手できます。

若干面倒ですが、これでセキュリティもOKですね。
(もっと良い方法があったら知りたい・・・)

ActiveDirectoryでパスワードを変更できなくて困った

このエントリーをはてなブックマーク Share
2010.02.27    Windows, セキュリティ, 馬場   タグ: —    baba   

ActiveDirectory環境で、一般ユーザがクライアントPCでパスワードを変更するには、Ctrl+Alt+Deleteを押します。

ここでパスワードの変更を選べばパスワードが変更できるはずですが、

パスワードを変更できませんでした。新しいパスワードとして指定された値は、パスワードの長さ、複雑さ、または履歴に関するドメインの要件を満たしていません。

と言われてしまうことがあります。

この場合は、以下を試してみます。

「Windows2008」などの、複雑さの要件を満たすパスワードを入れてみる

これでOKなら、グループポリシー「パスワードは複雑性の要件を満たす必要がある」が原因です。
嫌なら、これを無効にします。

これでもだめなら、「パスワードの変更禁止期間」が邪魔をしている可能性があります。

デフォルトでは、1週間程度のパスワード変更禁止期間が設定されていて、1日2回変更しようとすると上記のエラーが出るようです。

Default Domain Policyなどで「パスワード変更禁止期間」を0日に設定すれば直りそうです。

どういうわけだか、パスワードのポリシーだけはドメインコントローラーのポリシーが適用されることもあるような、そんな挙動をするので、Default Domain PolicyとDefault Domain Controller Policyの両方で
・パスワード変更禁止期間 → 0日
・パスワードの履歴を保存する → 無効
と設定しておくと良いと思います。

もちろん、ユーザの設定で「ユーザはパスワードを変更できない」にチェックが入っていないか確認し、gpupdate /force を実行するか再起動しておく必要があります。

SET NAMESが危険な理由のおさらい

このエントリーをはてなブックマーク Share
2010.02.17    PHP, セキュリティ, 馬場   タグ: —    baba   

1年くらい前に社内MLに投げた、「MySQLでSET NAMESを使ってはいけない理由」をコピペしてみます。手抜きです、はい。
赤字は注釈です。


今更ながら、「MySQLで SET NAMES を使ってはいけない」の根拠のお話です。

下記のPHPスクリプトでは、入力値を元にSQL文を生成し、検索クエリを投げています。
※sqltestというDBには、カラムnameを持つuserテーブルが存在します。

GETで渡された値はきちんとmysql_real_escape_stringをかけているので、SQLインジェクションは出来ないように見えます。
しかし、
http://localhost/sqltest/index.php?name=%95%5c’%20OR%201=1%20–%20
にアクセスすると、全部のデータが見えてしまいます。
下にあるPHPスクリプトを、localhost/sqltest/index.php として配置してください。

“SET NAMES SJIS” を実行すると、MySQLのエンコードがShift-JISになりますが、mysql_real_escape_stringはUTF-8のまま動作します。
16進数で 95 5c 27 20 は、
UTF-8: (謎の文字)(バックスラッシュ)(シングルコーテーション)(スペース)
Shift-JIS: (表)(シングルコーテーション)(スペース)
になります。
mysql_real_escape_stringは、バックスラッシュとシングルコーテーションそれぞれをエスケープします。
95 5c 5c 5c 27 20
MySQLは、Shift-JISとして動作するので、 (表)(\)(\)(シングルコーテーション)(スペース) と認識します。
つまり、\が一つ余分に入ることで、入力値のシングルコーテーションがエスケープされなくなります。

マルチバイト非対応のエスケープ関数を使うのと同じ理屈で、SET NAMES は危険です。
基本的に文字コード中に5Cが入るShift-JISが危険ですが、他の文字コードでも似たようなことが起こる可能性があります。
mysql_set_charset(’SJIS’);
なら、mysql_real_escape_stringもShift-JISとして動作するようになるので、安全です。


<html>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>SQLテストページ</title>
<head>
</head>
<body>

<form action="<?php echo $_SERVER['SCRIPT_NAME'];?>">
	<input type="text" name="name" />
	<input type="submit" value="search" />
</form>

<?php
	//DBに接続
	if (! $db = mysql_connect('localhost', 'sqltest', 'sqltest'))
	{
		echo 'CONNECT ERROR';
		exit;
	}
	mysql_select_db('sqltest', $db);

	mysql_query('SET NAMES SJIS');
//	mysql_set_charset('SJIS');

	//SQLを生成
	$name = mysql_real_escape_string($_REQUEST['name']);
	$sql = "SELECT * FROM user WHERE name='$name'";
	echo $sql . '<br />';

	//実行
	if (! $res = mysql_query($sql))
	{
		echo "QUERY ERROR <br />";
		echo mysql_error();
		exit;
	}

	echo "<pre>";
	while ($row = mysql_fetch_array($res)) {
		print_r($row);
	}
	echo "</pre>";
?>

</body>
</html>

Windowsのアクセス権を初期化

このエントリーをはてなブックマーク Share
2009.06.16    Windows, セキュリティ, 馬場   タグ: , —    baba   

Windowsのフォルダアクセス制限は複雑です。

サーバの共有フォルダにユーザごとのフォルダを作成し、それぞれに排他的なアクセス権を与える、という運用はよくあると思います。
その場合、サーバのHDD交換などの事情で全フォルダを丸ごとコピーする場合などに、サーバ管理者でさえもアクセスできないという問題があります。

Linuxならrootで全部アクセスできるのですが、Windowsでは、Administratorsグループでも、アクセス許可を取得していないとアクセスできません。
アクセス許可を取得するには、所有者の操作が必要ですが、管理者権限で一括でやりたいものです。

このような場合、多少強引ですが、所有者を強引に変更してしまいましょう。
以下、Vista / 7 / Server 2008 / Server 2008 R2 などのOSで、管理者権限でログインしている人が、自マシン内のフォルダの所有権を変更する手順です。

プロパティを開く

プロパティを開く

セキュリティタブの詳細設定を開く

セキュリティタブの詳細設定を開く

所有者の編集

所有者の編集

所有者の編集を開く

所有者の編集を開く

所有者の編集

所有者の編集

新しい所有者を入力

新しい所有者を入力

完了

完了

以上の操作で、アクセス権をリセットに近いことができます。
本当はこんなことやらずに運用をしっかりすれば良いのですが・・・

ノートン先生

このエントリーをはてなブックマーク Share
2009.03.04    Windows, セキュリティ, ネットワーク, 馬場   タグ: —    baba   

家族のPCにNorton Internet Security 2009体験版を入れてみたところ、Shurikenでのメール送受信が出来なくなりました。
POP3S/SMTPSは使えるのですが、POP/SMTPが使えない状態です。インストール直後は平気だったのに、ウィルススキャンをしたらだめになったとか。

110番と25番許可にしたり、ファイアウォールの一番上に全部許可のルール入れたり、アプリケーション制御で信頼するアプリに登録したり、ファイアウォールオフにしたり、ノートン先生丸ごとオフにしたり、色々やっても解決せず、

再起動したら直りました。謎。

やっぱり僕はKasperskyが好きです。高いけど。

COPYRIGHT [C] 2009 BEYOND PERSPECTIVE SOLUTIONS LTD. ALL RIGHTS RESERVED.