香川県の物産館のwebサイトが不正アクセスで停止 個人情報への影響は不明
香川県の物産館「栗林庵」がwebサイトの不正アクセスを受け、現在運営を停止している。
香川県によると、問題が判明したのは1月18日。
栗林庵のwebサイトがアクセス不可能な状態が確認されており、調査が開始された。
同サイトの保守管理業者の調べでは、原因は第三者からの不正アクセスが行われたことによるものという。
現時点での調査では、オンラインショップ利用者の個人情報流出に関わる事実は確認されていないという。
栗林庵のwebサイトは現在運営を停止。
再開については、被害詳細の調査および安全性が確保された後に予定されているとのこと。
スキンケア製品取り扱い「ビーグレンHP」に不正アクセス、46,702名分のカード情報流出
スキンケア製品を取り扱うビバリーグレンラボラトリーズ株式会社は2022年1月25日、同社が運営する「ビーグレンHP」（https://www.bglen.net）に第三者からの不正アクセスがあり、顧客のクレジットカード情報が流出した可能性が判明したと発表した。
これは2021年6月10日に、一部のクレジットカード会社から「ビーグレンHP」を利用した顧客のカード情報の流出懸念について連絡があり、社内調査を進めるとともに、第三者調査機関による調査を行ったところ、当該サイトのシステムの一部脆弱性を突いたことによる第三者の不正アクセスで、顧客が入力した個人情報を取得し外部に送信するプログラムが不正に配置されたことが原因で、顧客のカード情報が流出し、一部顧客のカード情報が不正利用された可能性を11月22日に完了した調査機関の調査結果で確認したというもの。
オーガニック食品を取り扱う通信販売サイト「ココシーズンズオンラインショップ」が不正アクセスを受け、顧客のクレジットカード情報が流出し、不正に利用された可能性があることがわかった。
同サイトを運営するかわたによれば、2021年3月26日から同年8月19日にかけて同サイトで商品を購入した顧客303人分のクレジットカード情報が外部に流出し、不正に利用された可能性があるという。
同サイトのシステムの脆弱性が突かれたことによる不正アクセスにより、ペイメントアプリケーションの改ざんが行われ、クレジットカードの名義、番号、有効期限、セキュリティコードなどが窃取された。2021年9月3日にクレジットカード会社から情報流出の可能性について指摘があり、問題が判明した。
外部事業者による調査は9月28日に完了。10月7日に個人情報保護委員会への報告を行い、10月11日に警察へ被害申告を行った。対象となる顧客に対しては、2022年1月17日よりメールや書面を通じて経緯の報告や謝罪を行っている。
旧「馬野化学容器株式会社ネットショップ」に不正アクセス、191名分のカード情報が流出
馬野化学容器株式会社は2022年1月、同社が運営する旧「馬野化学容器株式会社ネットショップ」に第三者からの不正アクセスがあり、顧客のクレジットカード情報が漏えいした可能性が判明したと発表した。
これは2021年2月25日に、一部のクレジットカード会社から旧「馬野化学容器株式会社ネットショップ」を利用した顧客のカード情報の漏えい懸念について連絡があり、第三者調査機関による調査を行ったところ、当該サイトのシステムの一部の脆弱性を突いた第三者の不正アクセスでペイメントアプリケーションの改ざんが行われたことが原因で、購入者のカード情報が漏えいし、一部顧客のカード情報が不正利用された可能性を、2021年7月29日に完了した調査結果で確認したというもの。なお当該サイトでは2021年2月19日に、カートシステムの切替えに伴いカード決済を停止していた。
ペットフードやペット用品を取り扱うマルカンは、同社通信販売サイトが不正アクセスを受け、顧客のクレジットカード情報が流出し、一部が不正に利用された可能性があることを明らかにした。
同社によれば、「マルカンオンラインショップ」に存在した脆弱性を突かれ、決済アプリケーションを改ざんされる不正アクセスを受けたもの。
2019年8月5日から2021年6月21日にかけて、同サイトでクレジットカード決済を利用した顧客1152人のクレジットカードに関する名義、番号、有効期限、セキュリティコードを窃取され、不正に利用された可能性がある。
2021年6月30日にクレジットカード会社から情報流出の可能性について指摘を受けたことで被害を認知した。
同社では、収益状況やコストの状況を踏まえ、2020年末ごろより同サイトの閉鎖を検討しており。2021年6月21日にウェブサイトを閉鎖してクレジットカード決済を停止した直後だったという。
その後実施した外部事業者による調査は同年8月20日に完了。10月5日に個人情報保護委員会へ報告、翌6日に警察へ被害を申告した。
対象となる顧客に対しては、2022年1月12日よりメールで報告と謝罪を行っており、身に覚えのない請求が行われていないか確認するよう注意を喚起した。閉鎖した同サイトについて、今後再開する予定はないとしている。
不正アクセスでクレカ情報流出の可能性 - 警察実務書扱う出版社
警察関係者向けの実務書や法律関連書籍を出版する立花書房のウェブサイトが不正アクセスを受け、顧客に関する個人情報が外部に流出した可能性があることがわかった。
同社によると、「立花書房ウェブサイト」の脆弱性を突かれ、クレジットカード決済に用いるモジュールを改ざんされたもの。2021年9月8日にクレジットカード会社から情報流出の可能性について指摘があり、問題が判明した。
同年1月8日から8月20日にかけて顧客1144人が商品購入時に利用したクレジットカード情報を窃取され、不正に利用された可能性がある。クレジットカードの名義、番号、有効期限、セキュリティコードが含まれる。
同社では8月21日にシステムを移行しており、移行前のシステムが攻撃を受けたという。移行後は異なるサーバやアプリケーションを利用しているが、不正アクセス被害の判明を受けてクレジットカード決済を停止している。
外部事業者による調査は10月1日に終えており、12月21日に個人情報保護委員会へ報告。同日警察にも被害を申告した。対象となる顧客に対しては、年明け後となる2022年1月11日よりメールを通じて経緯を説明するとともに謝罪を行っている。
本稿ではWiresharkがより使いやすいものになるようなヒントをお教えします。今回は､感染したWindowsホストからの悪意のあるネットワークトラフィックのpcapを確認するときに役立つと思われるフィルタ設定について説明します。
チュートリアルで利用するpcapはこちらから入手してください。
なお本チュートリアルでは､Wiresharkを効果的に使用する上での前提となるネットワークトラフィックの基本について､皆さんがすでに理解していることを前提としています。また、マルウェア感染がおこる仕組みについての基本的な理解も前提としています。
本稿は、悪意のあるネットワークトラフィックを分析する方法の包括的なチュートリアルではなく､Wiresharkの表示フィルタについてのヒントとこつをいくつか示すことを目的としています｡この点についてはご了承ください。
今回のチュートリアルでは、以下について説明します。
感染トラフィックの痕跡
このチュートリアルでは、「悪意のあるスパム(マルスパム)やWebトラフィックなどが大量に配信したWindowsを対象とする商用マルウェアからの感染トラフィック」をサンプルとして使用します。こうした感染では、Windowsホストがマルウェア(通常はWindows実行可能ファイル)に感染するまでに､さまざまな経路を通ることが考えられます。
こうしてさまざまな経路を通った感染トラフィックの痕跡は「IOC(侵害の痕跡)」と呼ばれます。セキュリティの専門家は､感染時にマルウェアが生成するネットワークトラフィックからこうした「感染の痕跡」情報を抽出し､見つかったURL、ドメイン名、IPアドレス、プロトコル、ポートなどの感染トラフィックの痕跡を文書に記録していきます。
Wiresharkの表示フィルタを適切に使用すると、これらの痕跡を素早く見つけることができます。
Wiresharkの表示フィルタ
本稿で説明する「Wiresharkの表示フィルタ」とは、[Packet List] ペインの上にある[Filter]ツールバーに入力するフィルタの内容を指しています。ここには、Wiresharkがpcapファイルから読み出して表示するフレーム、IPパケット、TCPセグメントをフィルタリング(絞り込み表示)するための式を入力します。
表示フィルタにテキストを入力すると、Wiresharkは、入力したテキストに基づいて候補のリストを表示します。表示フィルタの背景色が赤いとき､入力した式はまだそのままでは利用できない状態です。
この色が緑に変われば、入力内容は式として利用でき、正しく動作します。表示フィルタの背景色が黄色の場合、式は受け入れられていても、おそらく意図したとおりには動作しません。
Wiresharkの表示フィルタには、ブール式を利用できます｡つまり､複数の式を指定して連結できます。一般に使用される式を次に示します。
ブール式を利用した式のサンプルを次に示します。
ある値の除外を指定をしたい場合フィルタ式に「!=」は使用しません。たとえば「IPアドレス192.168.10.1を含まないすべてのトラフィックを指定する」場合のフィルタ式は「!(ip.addr eq 192.168.10.1)」です｡「ip.addr != 192.168.10.1」と指定すると正しく動作しません。
Web経由の感染トラフィック用フィルタ
pcapでWebトラフィックをすばやく確認する方法として、次のフィルタ式をよく利用します。
http.request or ssl.handshake.type == 1
「http.request」はHTTPリクエストのURLを検出し､「ssl.handshake.type == 1」はHTTPSまたはSSL/TLSトラフィックで使用されているドメイン名を検出します。
前回のチュートリアルで使った pcap サンプル(traffic-for-wireshark-column-setup.pcap)には、2018年8月に「college.usatoday[.]com」からユーザーがURLを表示したときに生成されたWebトラフィックが含まれています。またpcapの内容からユーザーはWindows 10コンピュータでMicrosoftのEdge Webブラウザを使用していることが確認できます。「http.request or ssl.handshake.type == 1」でフィルタリングすれば、このWebトラフィックのイベントのフローが表示されました。
今回のチュートリアルの1つめのサンプル Using-Wireshark-diplay-filters-Emotet-with-IcedID.pcap には､Windows 7ホスト上で生成したトラフィックのパケット キャプチャ ファイルが含まれています｡その中には､感染トラフィックとは無関係な通常通信で生成されるUDPポート1900番(1900/udp)経由のHTTPリクエストもあります。
1900/udp経由のHTTPトラフィックはSSDP(Simple Service Discovery Protocol)が生成しているもので､SSDPはプラグ アンド プレイ デバイス検出に使用されているプロトコルです｡
この1900/udpの通信はいわゆる一般的なwebトラフィックとは関連しないものなので､表示されてほしくありません｡そこで､前回のチュートリアルで指定した「http.request or ssl.handshake.type ==1」だけでなく､次の複合フィルタ式でこの不要なHTTPリクエストを除外することにしましょう。
Using-Wireshark-diplay-filters-Emotet-with-IcedID.pcap をWiresharkで開き､[Filter]ツールバーに次の式を入力してください｡
(http.request or ssl.handshake.type == 1) and !(udp.port eq 1900)
なお､次のフィルタ式でも同じ結果を得ることができます。
(http.request or ssl.handshake.type == 1) and !(ssdp)
このようにSSDPによる活動をフィルタリングして除外することで､感染Windows 7ホストのpcapに含まれる感染に関連したトラフィックをより確認しやすくなります。
下図は今開いたUsing-Wireshark-diplay-filters-Emotet-with-IcedID.pcapからのもので､Windows 7ホストでの2018年12月3日のEmotetの活動とIcedIDの感染トラフィックを示しています。
この図では、SSDPリクエストを含むWebトラフィックがフィルタリングして表示されています。
下図は、同じpcapでSSDPリクエストを除外してWebトラフィックをフィルタリングした場合を示しています｡これにより､感染活動をより明確に表示できます。
上図から、感染トラフィックの痕跡の一部を確認できますが､ここには表示されていない痕跡もあります。場合によっては、感染したホストが、オフラインのサーバーやTCP接続を拒否するサーバーに接続を試みていた可能性もあるのです。こうした接続試行の様子は、フィルタに「tcp.flags eq 0x0002」を追加してTCP SYNセグメントを含めれば表示することができます。
ではファイルUsing-Wireshark-diplay-filters-Emotet-with-IcedID.pcapに､今度は次のフィルタを適用してみましょう。
(http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002) and !(udp.port eq 1900)
検索対象にTCP SYNセグメントを含めると、図8に示すように､TCPポート8443番(8443/tcp)経由でIPアドレス217.164.2[.]133に接続しようとする感染ホストの様子が明らかになります。
他の種類の感染トラフィック用フィルタ
場合によっては、感染後のトラフィックがwebベースではないトラフィックを使い､コマンド アンド コントロール(C2)サーバーに接続しようとすることがあります｡これらのC2サーバーは IPアドレスを使って直接ホスティングされる場合と、ドメイン名をもつサーバーにホスティングされる場合があります。たとえばNanocoreリモート アクセス ツール(RAT)由来のC2トラフィックなどのように､感染後の活動がHTTPでもなければHTTPS/SSL/TLSトラフィックでもないものがあります。
このため､C2サーバーが利用するドメインがトラフィック内でアクティブになっているかどうかをpcapで確認することを目的に､DNS活動もフィルタに追加することがよくあります。これを追加すると以下のフィルタ式になります。
(http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002 or dns) and !(udp.port eq 1900)
では､Wiresharkで新しいサンプルファイルUsing-Wireshark-diplay-filters-Nanocore-RAT.pcapを開き､上記の式でフィルタリングをしてください｡
下図は、上記のフィルタ式を使用してpcapを確認したところです。ここから､脆弱なWindowsホストに感染するため､www.mercedes-club-bg[.]comからNanocore RAT実行可能ファイルがダウンロードされていることがわかります。この最初のダウンロードに続き、185.163.45[.]48に名前解決されるfranex.sytes[.]net、95.213.251[.]165に名前解決されるfranexserve.duckdns[.]orgに対してTCP接続が試みられています。
下図は、DNSクエリとTCPトラフィックの相関関係を示しています。
一部の感染トラフィックは、Wiresharkによって容易にデコードできる、一般的なプロトコルを使用しています。下図はサンプルファイルUsing-Wireshark-diplay-filters-FTP-malware.pcapをWiresharkで開いたところで､このマルウェア実行可能ファイルが原因で発生する感染後のFTPトラフィックを示しています。
DNSトラフィックやTCP SYNフラグもチェックする標準的なWebトラフィック検索用フィルタを指定すれば、ftp.totallyanonymous[.]comに対するDNSクエリの後に、TCPポート21およびその他のTCPポートを経由したトラフィックも見つかります。
FTPトラフィックの場合、表示フィルタにftpと指定することができます(下図参照)。このpcapをftpでフィルタリングすると、感染したWindowsホストがtotallyanonymous.comでFTPアカウントにログインし、fc32.exeおよびo32.exeという名前のファイルを取得していることがわかります。
下図に示すように、後のFTPトラフィックまでスクロールしていくと、ほぼ毎分FTPサーバーに送信される6R7MELYD6という名前のファイルが見つかります。さらに調べると、6R7MELYD6には、感染したWindowsホストから窃取したパスワード データが含まれていることがわかります。
マルウェアは、悪意のあるトラフィックとしてFTP以外の一般的なプロトコルも使用することがあります。
スパムボット マルウェアは､毎分数十件から数百件の電子メール メッセージを送信することを目的としたスパムボットに感染ホストを変えてしまいます。特徴として、いくつかのDNSリクエストがさまざまな電子メール サーバーに送られた後、25/tcp、465/tcp、587/tcp、または電子メール トラフィックに関連するそれ以外のTCPポートでSMTPトラフィックが発生します。
このフィルタ式を再度試してみましょう。
今度は､サンプルファイルUsing-Wireshark-diplay-filters-spambot.pcapを開いて､次のフィルタ式を適用してみてください｡
(http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002 or dns) and !(udp.port eq 1900)
スパムボット トラフィックを確認すると、メール サーバーに対するDNSクエリと、前述した、SMTP関連ポートに対するTCPトラフィックが見つかります。
smtpをフィルタ式として使用してみましょう｡ここからいくつかのことがわかります。まず､STARTTLSを見つけても、おそらくは暗号化されたSMTPトラフィックなので電子メール データを確認することはできません。
ここ数年、スパムボットの電子メール トラフィックは、ほとんどが暗号化されたSMTPです。ですが、以下のような電子メールの一般的な見出しで文字列を検索すると、暗号化されていないSMTPトラフィックも見つかることがあります。
Wiresharkの表示フィルタでは大文字と小文字が区別されることに注意してください。暗号化されていないSMTP通信でスパムボット トラフィックを検索するとき、よく「smtp contains “From: “」をフィルタ式として使用します。Using-Wireshark-diplay-filters-spambot.pcapを開いた状態で､このフィルタ式を入力してみてください｡下図に示したパケットが見つかるでしょう｡
SMTPトラフィックのフィルタリングしたら､表示されたフレームのいずれかを選択してTCPストリームを追跡して内容を確認してみましょう｡
表示されているフレームのいずれかひとつを選択して右クリックし､表示されたコンテキストメニューで[追跡]､[TCP ストリーム]の順にクリックします｡これでそのフレームに関連するSMTP通信の内容が表示されるので､スパムボットから送信された電子メールの1つ(たとえば下図の例ではericrene.malherbe@wanadoo[.]fr)が見つかります。
フィルタの保存
フィルタ式のなかには毎回入力するのが非常に面倒なものもあります｡それらはフィルタ ボタンとして保存しておくことができます。Wiresharkのフィルタ バーの右側には､フィルタ ボタンを追加するための[+]ボタンがあります。
[+]をクリックして、フィルタ式をフィルタ ボタンとして保存します。以下のフィールドが表示されます。
「Comment(コメント)」の記入は任意です。また、[Filter(フィルタ)]には、Wiresharkの[Filter]タスクバーに現在入力されている内容がデフォルトで設定されます。「Label (ラベル)」に入力したら、[OK]をクリックします(下図参照)。
前記の画像では、(http.request or ssl.handshake.type == 1) and !(udp.port eq 1900)というフィルタについて「basic」と入力し、基本フィルタとして保存しました。下図では、「basic」というラベルのフィルタ ボタンが、+記号の右側に表示されています。
Wiresharkにおける標準的なフィルタ設定として、以下のフィルタ ボタンを作成しています。
宿泊予約仲介プラットフォームの責任 東京地判令元.9.5（平28ワ32620）
私がこの世で最も忌み嫌う宿泊予約仲介プラットフォームはエクスぺデイア(Expedia)です。
2016年にイスラエルに訪問した際、エクスペディアで宿を予約したのだが、エクスペディアで予約後直接宿とやり取りが必要というクソな仕様で、イスラエル訪問初日に宿なしの憂き目にあった。
イスラエルから日本のエクスペディアのコールセンターに電話しても出てくるのはカタコトの日本語を話す中国人で埒が明かず、結局hotels.com(たぶん)で当日予約をして宿を確保した。オンライン宿泊予約プラットフォームで海外の宿を当日予約したのはこれが初体験であった。
日本帰国後にエクスペディアにクレームを入れるが返金されることはなく、頭にきて退会したのだが、退会後にエクスペディアから「ありがとうございました。今後ともよろしくお願いします。」という意味不明というか、小バカにされた感のメッセージを受けたことを今でも覚えている。
利用者が「静かな部屋」をリクエストして部屋を予約したが実態と異なっていたとして，利用者が予約仲介プラットフォーム事業者の責任を追及した事案があったので、転載しておく。
こんなしょーもない内容で訴えるのかと思ったが、案の定原告の主張は退けられた模様。
ーー
Ｘは，Ｙが運営する宿泊施設予約サイト（本件サイト，Booking.com）を通じてマカオのａホテル（本件ホテル）を予約した。その際，「特別リクエスト」欄に「quiet room」と記載した。
Ｘが実際に本件ホテルに赴いたところ，仮囲いがあって工事中であり，Ｘは「静かな部屋」ではないとしてその場でキャンセルして宿泊しなかったが，当日キャンセルに当たるとして全額（816香港ドル）が決済された。その後，Ｘは，本件ホテルと直接交渉のために２度に渡って本件ホテルに赴いた。
Ｘは，Ｙに対し，特別リクエストを正確に伝達して仲介すべき債務の履行を怠ったことは債務不履行または不法行為にあたるなどとして，交渉のための航空運賃，支払うこととなった本件ホテルの宿泊費（キャンセル料）等の合計約20万円の損害賠償を求めた。なお，本人訴訟のようである。
債務不履行または不法行為の成否
裁判所は本件ウェブサイトの位置づけについて次のように認定した。
本件ウェブサイトは，サイトを閲覧した顧客が，客室予約の手続を行うことのできるオンライン・プラットフォームであり，利用者は，無料で本件ウェブサイトを利用することができ，本件ウェブサイトを通じて予約が完了した時点以降，Ｙは，予約情報を宿泊施設に伝達し，利用者に予約確認書メールを宿泊施設に代わって送信し，利用者と宿泊施設との仲介のみを務めるものとされている。
次のように述べてＹの責任を否定した。
Ｘは，Ｙが本件ウェブサイトに，本件ホテルの周りには仮囲いがあって工事中であるとの情報を掲載しなかったことがＸの利益を侵害し，不法行為に当たると主張する。しかし，上記ア（ア）の約定（注：上記認定）を見ても，Ｙにおいて，本件ホテルの場所や宿泊料といった一般的な情報を超えて，本件ホテルが，Ｘ固有の特別なリクエストにすぎない「静かな部屋」に対応することのできる状況にあるのか否かについてまで，本件ウェブサイトに情報を掲載して提供する法的義務が生じるとはいえず，他に，そのような法的義務が生じることを基礎付ける事情も認められない。よって，この点に関するＸの主張は理由がない。
また，Ｘは，Ｙが予約内容を正確に仲介すべき債務を負っていたと主張する。この主張が，予約内容を正確に伝達すべき債務であるという趣旨であれば，Ｘが入力した他の予約情報が本件ホテルに伝達されていながら，特別リクエストのみ伝達されていないということは想定し難いのであるから，Ｙは予約内容を伝達する債務を履行したといえる。また，上記の主張が，Ｙにおいて，本件ホテルに対し，Ｘが静かな部屋を要望している旨を伝えて，本件ホテルに何らかの対処を求めるべき債務があるとの趣旨であるとしても，上記イのとおり，Ｙの債務は予約の伝達と予約確認書メールの送信に尽きるのであって，それ以上に，Ｙが，本件ホテルに対し，Ｘの特別リクエストに応じた対処を求めるべき債務が存在するものとはいえない。よって，この点に関するＸの主張も理由がない
その他に，Ｘは消費者契約法10条，景表法違反なども主張していたが，いずれも退けられている。
