キャリアの企業データベースからの情報漏洩の調査

印象的な車両を所有しているロシアの大手航空会社から連絡がありました。 その顧客は、数十の物流会社と企業です。 その活動範囲は、CIS諸国の国境をはるかに超えています。 各車には、座標、燃料消費量、および他の多くのインジケータに関するデータを発送センターに送信する監視システムが装備されています。



単一のセンターから、貨物の座標に関する情報が顧客に分岐します。 すべてが自動モードで動作します。 配送管理の利便性のために、サービスの費用には、商品の場所を顧客に知らせるサービスが含まれます。







お問い合わせの理由は、運送業者の貨物に関する情報を販売するいくつかのインターネットリソースの活動でした。 物流会社または当社の運送業者の別のクライアントが、競合他社を含む誰でもその商品に関するデータを取得できることを喜んで知ることはありません。



技術的な観点から、貨物に関する情報は2つの方法で取得できます。

1つ目は運送業者のウェブサイトにあり、2つめのより複雑なものは物流情報システム(顧客のACS)を運送業者の拠点に直接接続することです。 キャリアのデータベース(DB)に対する顧客ACSのすべてのリクエストは、一連のストアドプロシージャを通じて実装されます。 アクセスを管理するために、各クライアントには、必要な権限と権限のセットを持つ自分のアカウントが割り当てられます。







運送業者の専門家は、貨物の場所に関するデータに加えて、データベースから他の情報が漏洩する可能性があることを理解していました。 誰がどのような目的でそれらを使用するかは不明ですが、警戒すべきです。 おそらく、そのようなサイトの顧客は、競合他社だけでなく、代替制御チャネルを希望するキャリアの顧客自身である可能性があります。 また、トラックに関する情報は、たとえばドライバーとの合意によって、貨物を非公式に「後ろに」取り付けることができた人々にとって興味深いかもしれません。 明らかな情報漏洩があり、私たちの仕事はその組織化の方法を見つけることでした。



まず、これらの盗まれた売り手が提供する情報を分析しました。 彼らのサービスの範囲は非常に広いことが判明しました。 個人でも余裕のある非常にリーズナブルなお金で、現時点で特定のトラックや貨物の場所に関する情報を取得できます。 貨物または車両を追跡するように登録すると、十分なお金がある頻度で電子メールまたはSMSでデータを受信できます。



調査を継続するために、「テスト購入」方式を選択しました。 これらの犯罪リソースの1つに登録し、トラックコーディネートの数十件のリクエストに対して支払いを行いました。 各リクエストを計画する際に、キャリアの中央データベースへの呼び出しのソースを追跡することを計画しました。



ベースの構造を確認した後、車両の座標に関する情報はベースのテーブルまたはビューから取得できることに気付きました。 飛行中の会社のトラックの1つを選択し、ディスパッチセンターのデータセンターの管理者に、トラックの座標に関するデータを含むテーブルとビューへの呼び出しのトレースを含めるように依頼しました。 次の3時間で、不正なWebサイトで10件のリクエストを行い、リクエストごとにGPS座標を受け取りました。 各リクエストのデータは、わずか1秒の遅延で届きました。 この3時間の間に、約70メガバイトのテキストマガジンが入力されました。 私たちはオフィスに行ってそれらを分析しましたが、そこでは適切なツールがあり、ベース管理者はそのままでした。



分析中に、リクエストに応じたデータがオンラインになり、バックアップからのリーク、または手動モードでのリクエストの処理に関するバージョンが記録されていることがわかりました。 リクエスト後1秒以内に、情報を「マージ」する外部クライアントに関するデータがトレースに表示されることを望みました。 分析の結果は期待はずれでした。標準DBMSツールによって作成されたトレースでは、テーブル呼び出しとビューに関する情報がありましたが、トラックに対する特定のデータ要求に関する情報はありませんでした。 1秒間に200を超えるテーブルとビューの呼び出しがあり、リクエストに応じて行われた呼び出しを区別することはできませんでした。



テーブルまたはビューへの特定の呼び出しの内容を提供する追加のツールが必要です。 多くのツールはトラフィック内のSQLクエリなどを分析できますが、この場合、ストアドプロシージャから同じサーバー上のデータベースへの要求を傍受できるだけでなく、その内容を「解析」できるソフトウェアが必要でした。



一時的に使用するために、このようなツールをすばやく見つけて同意したのは良いことです。 このソリューション(InfoSphere Guardium)は、データベースサーバー上のソフトウェアエージェントを直接使用して、ストアドプロシージャからの要求を分析できます。 「オンザフライ」でリクエストの分析を実行すると、システムは必要なすべてのデータを取得できます。 夜間の設置および構成作業の後、「左」のリソースでトラックに対して10回のデータ要求を再度実行しました。 今回は、分析システムに組み込まれたフィルタリング方法のおかげで、12のアカウントのリストを取得し、各リクエスト後1秒以内にトラックの座標のデータが「飛んだ」ようになりました。 これらのアカウントの背後には、通信事業者の顧客のいずれかのACSがあります。 タスクは、クライアントのどの特定のACSがサイドにデータを送信するかを決定するために発生しました。このために、個々の「タグ」を設定する方法を使用しました。



データベース管理者と一緒に、これらのストアドプロシージャをわずかに変更し、それを使用して識別された12個のアカウントがデータベースからデータを取得しました。 変更は1つの目標を追求しました-アカウントに応じて、トラックの座標を個別に調整します。 12の自動制御システムのそれぞれについて、最後の2桁が異なる個々の座標が形成され、送信したすべての値は慎重に特別なジャーナルに保存されました。 犯罪現場から「タグ付き」座標を受け取った私たちは、ラベル発行雑誌に目を向け、データをマージするACSを特定することができました。



さて、微妙な瞬間が訪れました-さらなる調査のために、クライアントACSからのデータが必要でした。 これは、クライアントが少なくとも部分的に問題の本質に専念する必要があることを意味しました。 さらに、このACSの管理者がデータをマージすると、すべてのトレースをカバーできます。 非常に慎重に行動する必要がありました。 状況は成功しました、なぜなら 運送業者のセキュリティサービスと、主要なロジスティクスオペレーターであるこのクライアントのレベルでの協力について合意に達しました。 顧客のセキュリティサービスは、ACSサーバーログを提供することに同意しました。 ログ分析により、タグ付きデータを受信する唯一のアカウントが得られました。 アカウントは、物流会社の従業員のいずれかに属していました。 彼に次に起こったことは沈黙している。 主なものは、目標が達成されたことです-盗まれたデータの販売は停止しました。



All Articles