ソース：
How I Hacked my College ERP App ! | by Dingus (Amol Verma) | Jul, 2023 | Medium
脆弱性タイプ：IDOR 他
内容：
アプリに 4 つの大きなバグを発見しました —
1. ハードコードされた秘密の保管
2. ログイン バイパス — これにより、認証プロセスがバイパスされ、どの生徒のアカウントにもログインできるようになりました
3. IDOR (安全でない直接オブジェクト参照) — これは重要なもので、これによってデータベース内のあらゆるものを確認できます。生徒の詳細、料金の詳細、出席の詳細、図書館の詳細、成績の詳細などを見ることができました。 このアプリには、6 つの異なる提携大学の学生に関する情報が含まれていました。 彼らの情報をすべて取得できました!
4. レート制限なし — サーバーに対して行われたリクエストにレート制限がないことがわかりました。これは小さなバグのように見えますが、上記のバグと組み合わせると最も致命的です。
バグ-1 ハードコードされた秘密の保存:
バグを見つけるための最初のルールは、ソース コード内で秘密またはハードコードされたパスワード、ユーザー名、トークン、およびその他の機密情報を探すことです。私はまさにそれを実行し、「Bearer」トークンを見つけました。
Bearer Token の漏洩
Bearer Token は、アプリへのユーザーの認証に使用されるトークンです。基本的には、ユーザーの認証後にアプリへのアクセスを許可するためにサーバーから受け取るトークンです。
これは小さな勝利のように見えるかもしれませんが、最大の勝利です。
このため、 *アプリは本当に誰かをログインさせているのか?という疑問が生じました。 それとも単なる見せ物ですか?*
次の脆弱性に進みましょう!
バグ-2 ログインバイパス:
これは興味深いもので、最初に別のアカウントにログインしようとしたときに、アプリがすべての努力が拒否されて。しかしその後、私が探していた「応答操作」と呼ばれるテクニックを試してみました。それが実を結びました。
説明すると、
ユーザーがユーザー名とパスワードを入力して「ログイン」をクリックすると、それらの資格情報がサーバーに送信され、実際にデータベースに存在するかどうかがわかります。 一致する場合、サーバーは 200 ステータス コードまたは成功メッセージをクライアントに送り返します。そうでない場合、サーバーは 405 ステータス コードまたはエラー メッセージで応答します。クライアントはサーバーからこの情報を受け取り、ユーザーをログインさせるか、資格情報が間違っている場合はエラーを表示します。
しかし、被害者のアカウントにログインしようとしているときに、サーバーから受信したこの応答を変更して、405 ステータス コード/エラー メッセージを 200 ステータス コード/成功メッセージに手動で変更できたらどうでしょうか? 私はまさにそれをやりました。被害者のアカウントにログインしました！
これで、アプリが許可する被害者の名前で何でもできるようになりました。 次は、、
バグ-3 IDOR:
ソースコードの静的分析中に、いくつかの API ルートがあり、それらは基本的にユーザーの料金詳細、マーク詳細、出席詳細、図書館詳細を取得するものであることがわかりました。 しかし、それは私に誰かの詳細を取得させることになりました、どうやって？
APIルート
私の大学名簿番号から被害者のロール番号に変更 単純に、API ルートで URL パラメーターの値を変更しました (たとえば、 Stud_ld )、結果は次のとおりでした。
学生プロフィール詳細の漏洩 (そのユーザーのあらゆる情報が含まれます)
料金明細の漏洩
ライブラリ詳細の漏洩
これだけの詳細情報をソーシャル エンジニアリングと組み合わせると、文字通り誰でもなりすますことができます。
バグ — 4 レート制限がないバグ :
このバグは、サーバーに対して行われるリクエストの数に制限がない場合に発生します。これは非常に小さなバグのように思えますが、API ルートのパラメータで StudentRollNo を順番にブルート フォースできたらどうなるでしょうか?
そうです、それは 6 つの大学のデータベース全体を漏洩することになります !!!!
さあ、点と点を結びましょう。
すべてを評価して結論を出しましょう。 私が以前に提起した奇妙な質問を覚えていますか?
*アプリは本当に誰かをログインさせていますか? それともただの見せかけですか?*
さあ、真実の瞬間を迎えましょう。 これらのバグはすべて、たった 1 つの問題によって発生しました。なぜなら……
「大学 ERP アプリにはログイン機能がありません!」
ショックを受けましたか？ 魅了されましたか？ 私もそうでした。もう一度説明しますが、 Bug-1 で見つかった資格情報は、サーバーから情報を取得するために使用される唯一のものであり、パスワードではありません 。 では、なぜログインページがあるのでしょうか? わかりました、説明しますが、そのためにはアプリの動作を確認する必要があります —
1. アプリは最初にロール番号とパスワードを検証してチェックします。
2. 正しい場合、 ハードコードされたベアラー トークン を使用してデータベースから学生に関する情報を受け取り、ユーザーをログインさせます。その情報は、ユーザーが再度ログアウトするまでアプリに保存されます。
3. 次に、アプリはそのハードコードされた資格情報を使用して、料金、ライブラリなどの詳細を取得します 。
これの欠陥を見つけることができますか? そうです、 ここでハードコードされた認証情報を使用する必要はありません。
サーバーからその生徒に関する情報を取得するために 。
生徒がログインすると、サーバーはその生徒専用の固有のトークンを生成し、それを介して情報を取得し、生徒がログアウトするときにトークンを破棄する必要があります。 開発中にアプリの認証と認可が最優先で行われることが重要です。
このアプリを保護するには、すべてのコードを最初から作成する必要があります。
ほなほな。
