弊社では、従業員ID用の新しいカードプリンターを入手しました。少し高価で、マグストリップとEMVチップの両方を印刷できるため、バックグラウンドを実行する必要がありました。 EMVチップについては十分に理解していませんが、デビットカードのマグストリップを複製して完全に機能するクローンを作成するのは非常に簡単であることがわかりました。私が保存したいものは何でも保存するだけでなく。それで、カードデータを盲目的に受け入れることのリスクは何かについて考えさせられました。明らかに、プログラマーはすべての入力をサニタイズする必要がありますが、見落としがあった場合はどうでしょうか。そして、誰かが処理/請求システムでカードを実行し、カードに埋め込まれたコードを実行させるエクスプロイトを見つけました。 特定のPHPスクリプトが画像のexifデータの処理を試みたときに侵害され始めた またはその他の入力のサニタイズに失敗したシナリオと同じように。使用できる文字と長さにはトラックによって制限があるため、マグストリップ。前述のように、EMVチップの内部動作はわかりませんが、より多くの可能性がある可能性があります。
それで、私が興味を持っていたいくつかの質問があります。悪意のあるカードを介してシステムを危険にさらしたり混乱させたりすることは可能ですか?このシナリオはすでに検討されており、POS /販売ベンダーはこれを防ぐために特定の手順を実行していますか?
私が再販/サポートしているPOS製品について私が知っていることは、支払いのためにクレジットカードを使用するときに、探している文字の数が設定されていることです。
一般的な意味で、次のようなものを探しています。
したがって、システムはこの形式のデータを必要としています
[Card number][Expiration][Security Code]
ストライプには他の情報がありますが、簡単な例を説明しようとしています。
また、私の例では、古い磁気ストライプのみのカードを参照して、欠けたカードについては言及していません。
それで、私のPOSシステムが23桁(16 + 4 + 3)を期待していて、カードプリンターで偽のカードを作ったとしましょう。机のすぐ隣に1つあります。しかし、私は情報の順序を台無しにします。
の代わりに [Card number][Expiration][Security Code]
私がやります
[Security Code] [Card number] [Expiration]
システムは私が提供した情報を引き続き取得しますが、ほとんどの場合、「無効なカード番号」のようなメッセージが返されます。
だから私の偽のカードを正しい情報の順序でやり直してください。店に行ってカードを試してみてください。問題なく動作します。
カードの最後に私のペイロードを含めることにします。 2つのことのうちの1つが起こるだろうという私の考え:
カードは正常に通過し、システムは、承認のためにクレジットカード会社に提出するために探していた24桁の数字を受け取りました。
磁気ストライプの桁数が標準セットと一致しなかったため、POSはカードを受け入れませんでした。
#2私は野生で起こるのを見てきました。私の会社がサポートしているチェーン店は、大きな大学の隣にあります。大学ではIDカードを配布していますが、学生が利用できるクレジットカードでもあります。カードを使って物を購入したり、大学でサービスを受けたり(本などをチェックしたり)することができます。
磁気ストライプカードには、最大3トラックの情報があります。クレジットカードの取引には2つのトラックが使用されます。 1つのトラックを使用できますが、「トラック1とトラック2」のトランザクションではなかったため、販売者は追加料金を支払います。
「XXXX大学のカードは手動で入力しないと機能しない」という問題で店主から頻繁に電話があった後、大学に行ってカードを見せてもらい、スワイプして情報がどのように配置されているかを確認しました。磁気ストライプに。彼らは私の要求で少し投げ返されましたが、彼らは問題を理解し、大学のITスタッフが私を見た後、彼らの前でテストを行いました。
彼らはカードのトラック3に学生ID情報を入れていました。したがって、私がサポートしているPOSシステムは、トラック1、トラック2、およびトラック3を読み取り、情報が多すぎるためにカードを受け入れませんでした。
この問題を解決するために、トラック3の情報を読み取らないようにプログラムする必要があった店舗のMSR(磁気ストライプリーダー)。
それが1つのPOS製品での私の経験でした。そこには何百ものPOS製品があり、「X」桁の数字だけを受け入れるのが標準的な方法だと思います。
これが可能であれば、「弱点」は、カード情報を銀行に送信して承認を受けるための支払いゲートウェイだと思います。
POSコンピュータ---->ペイメントゲートウェイ---->カード所有者の銀行
ペイメントゲートウェイは、データをどのように受け取るかという構文を設定します。
彼らは私の例とは異なる方法を好むかもしれません
[Card number][Expiration][Security Code]
したがって、これを悪用することを考えた場合、SQLインジェクション攻撃と同様に、支払いゲートウェイがどこを探すべきかを推測します。 PGはかなり強化されたシステムであるため、構文に[〜#〜] not [〜#〜]であるものはすべて許容されないと思います。
ハッキングは理論的には可能です。あなたが遭遇する問題は、あなたが多くの未知のものを扱っているということです。カードデータがどのように読み取られ、検証されるかがわかりません。また、データのどのようなサニテーションが実行されているかもわかりません。データを適切にサニタイズしているシステムに悪意のあるカードが読み込まれると、悪意のあるペイロード全体が支払い処理業者に渡される可能性があります。彼らが何が起こっているのかを理解し、警察の報告を提出するために店をフォローアップするのは難しいことではありません。 Luhn Algorithm を使用して、ストアで検証をすばやく検証することもできます。これは基本的に、番号が正当であることを確認するための簡単な方法です。
運が良ければPOS端末の侵害に成功した場合は、データをオフロードする必要があります。ターゲットとホームデポの違反により、数千万のカード番号が蓄積されました。データをオフロードする簡単な方法はありません。どういうわけか、クレジットカードのトラックに番号をロードし直しますか?または、POSデバイスにファイルをサードパーティのWebサイトにアップロードさせようとすることもできますが、PCI-DSS要件により、厳格なファイアウォールルールが規定されています。これにより、POSシステムがインターネットにアクセスできる可能性は非常に低くなります。上記のハッキングの場合、攻撃者はジャンプボックスを使用してネットワークセグメントを切り替える必要がありました。
犯罪者は非常に優秀なビジネスマンであり、これは報酬に対して過度のレベルのリスクを追加します。リモートでPOSセグメントを突破しようとする方がはるかに安全です。彼らは利用可能なツールをより細かく制御でき、オリジンをマスクするための信じられないほど効果的な方法を持っています。