Securelist.com-XSSおよびSQLインジェクションの脆弱性

画像画像

みなさんこんにちは!

Securelist.comはカスペルスキーによって開発されています。 このサイトには、LKの従業員が投稿するブログがあり、登録した一般ユーザーがコメントできます。 論評には評価があります。 すべてのユーザーコメントの評価が100以上になると、ユーザーはブロガーのステータスを受け取り、ブログに投稿できます。 そして、私がそこに登録したら...





[免責事項]

以下に説明するすべてのアクションは、情報提供のみを目的としています。 サイトで見つかったすべての脆弱性がポータル管理者に通知されました。 サイトのスクリーンショットを撮るために、 snusmumrikハブユーザーの peeep.usサービスを使用しました 。 ヘルプとサポートをしてくれたポータルR3AL.RUのチームに感謝します。



[Xss]

登録後、XSS脆弱性の標準テストを実施することにしました。 私はアラート付きのJSスクリプトを挿入し、それが機能しました 、つまり [ログイン]フィールドには、XSSに対するフィルタリングはありませんでした。

ためらうことなく、スニファーを挿入し、いくつかのブログにコメントして、待ち始めました。 Snifferは約1か月間サイトにハングアップしました。 この間、サイトへの91個のアカウントを傍受することができました。 サイトをさらに詳しく見てみましょう。

1)ユーザーがログインとパスワードを入力します

2)サイトは、次の形式のユーザーパラメーターのCookie(VLUserkaspru)に書き込みます。

id:19DEShash

idはユーザー識別子です(リンク:securelist.com/en/userinfo/idにあります)。

19DEShash-salt = 19の標準PHP DESハッシュ

3)サイトの任意のページに移動すると、スクリプトはユーザーのCookieを取得し(「:」で)2つの部分に分割し、データベースからユーザーのパスワードを選択します(id = id)。データベースのパスワードハッシュとCookieハッシュ値を比較します。

つまり、Cookieを1回傍受することで、いつでもサイトにアクセスできます(またはハッシュを削除できます)。

データベースにパスワードがどのように保存されているかを調べることにしました。 確認するのは非常に簡単でした-[パスワードを忘れた場合]リンクをクリックすると、電子メールでオープンパスワードが届きます。 つまり、データベース内のパスワードはハッシュではなくオープンに保存されます。

アカウントにログインした後、メールを変更してパスワードをリセットできることがわかりました。 メールの変更を確認するために、リンクは新しいメールのみになりました=>任意のアカウントでメールを変更し、確認し、パスワードを明確な形式で返すことができます。

LCスタッフのCookieを傍受したため、ブログのコントロールパネルにアクセスできました。 彼女はこのように見えた:

画像

内部からのステータスが「管理者」であるユーザープロファイルの表示:

画像

いくつかのテストを行った後、ブログのテキストもフィルターされていないことがわかりました=> HTML / JSコードを挿入できます(たとえば、悪用)。

ブログ編集ページは次のようになります。

画像

投稿ヘッダーフィールドもフィルタリングされず、タイトルがメインに表示されます=>少し改ざんすることができます:

画像 画像

まあ、またはそう:

画像 画像

そして特にHabrahabrにとって

Cookieを傍受できた興味深いIDのリスト:

69-Dmitry Bestuzhev、エキスパート、カスペルスキー

72-セルゲイ・ゴロバノフ、カスペルスキーラボ、エキスパート

81-Maria Namestnikova、エキスパート、カスペルスキー

82-カスペルスキーラボ、エキスパート、ユーリ・ナメストニコフ

85-タティアナ・ニキティナ、ブロガー

1052-管理者博士

7053-アレクサンダーゴステフ、カスペルスキーラボ、エキスパート



[SQLインジェクション]

時間が経ち、脆弱性についてサイト管理者に通知したかったのですが、フィルタリングのCookie設定を確認することにしました。 そして、idはフィルタリングされないことが判明しました!

Cookieのさまざまなパラメーターを置き換えると、ブラインドSQLインジェクションがあることがわかりました。

12345)AND 1 = 2-:ハッシュ

このオプションでは、アカウントへのアクセスは許可されませんでしたが、

12345)AND 1 = 1-:ハッシュ

ログインしたユーザーとしてログインしました。

数時間かけて通常のブラインド出力を達成しました。 その結果、私は受け取った:

12345)AND 1 = 1 AND(SELECT ascii(substring(version()、1,1)))> 100-:ハッシュ

SQLを知っている人は、ここでバージョンc 100の最初の文字のASCIIコードを比較していることを簡単に理解できます。100を超える場合、ユーザーになり(AND TRUE AND TRUE)、そうでなければ、私はゲストになります(AND TRUE AND FALSE) 。 異なる値を代入することで、文字のASCIIコードを見つけて、それを文字に変換できます。

サーバーで実行されているPostgreSQLは最新バージョンではありません。

INFORMATION_SCHEMA.TABLESからラベルを取得します。

12345)AND 1 = 1 AND(SELECT ascii(substring(table_name、1,1))from INFORMATION_SCHEMA.TABLES LIMIT 1 OFFSET 1)> 100-:ハッシュ

そのため、テーブルの名前を表示し始めましたが、最初のテーブルの名前しか印刷できず、脆弱性は機能しなくなりました(おそらく、管理者がログを焼きましたが、誰かがささやいたという事実を排除しません)。



最近、 XSS for Beginnersという新しいエントリが securelist.comに登場しました。 =)

XSSの脆弱性はまだ修正されていませんが、サポートへの手紙とLCの苦情および提案書へのメッセージを送信しました(必要なすべての対策が講じられたと回答しました)。 たぶん、この投稿は管理者に最終的に脆弱性を閉じることを強制するでしょう。



UPD:注意! これは、PRサイト、会社、または製品ではありません。

UPD2:トピック:

魔法のトリプティクまたはKAVからの有害なアドバイス (この記事は私の研究の前に登場しましたが、ごく最近知りました)。



All Articles