マルカンオンラインショップからのカード情報漏えい~想定損害賠償額は2900万円程度か~

【限定】マルカンオンラインショップからのカード情報漏えい:
ペット用品通販サイトに不正アクセス - 閉鎖直後に被害が判明
 

ペットフードやペット用品を取り扱うマルカンは、同社通信販売サイトが不正アクセスを受け、顧客のクレジットカード情報が流出し、一部が不正に利用された可能性があることを明らかにした。

同社によれば、「マルカンオンラインショップ」に存在した脆弱性を突かれ、決済アプリケーションを改ざんされる不正アクセスを受けたもの。

2019年8月5日から2021年6月21日にかけて、同サイトでクレジットカード決済を利用した顧客1152人のクレジットカードに関する名義、番号、有効期限、セキュリティコードを窃取され、不正に利用された可能性がある。

2021年6月30日にクレジットカード会社から情報流出の可能性について指摘を受けたことで被害を認知した。

同社では、収益状況やコストの状況を踏まえ、2020年末ごろより同サイトの閉鎖を検討しており。2021年6月21日にウェブサイトを閉鎖してクレジットカード決済を停止した直後だったという。

その後実施した外部事業者による調査は同年8月20日に完了。10月5日に個人情報保護委員会へ報告、翌6日に警察へ被害を申告した。

対象となる顧客に対しては、2022年1月12日よりメールで報告と謝罪を行っており、身に覚えのない請求が行われていないか確認するよう注意を喚起した。閉鎖した同サイトについて、今後再開する予定はないとしている。

プレスリリースアーカイブ

立花書房からのカード情報漏えい~想定損害賠償額は2900万円程度か~

立花書房からのカード情報漏えい

不正アクセスでクレカ情報流出の可能性 - 警察実務書扱う出版社

警察関係者向けの実務書や法律関連書籍を出版する立花書房のウェブサイトが不正アクセスを受け、顧客に関する個人情報が外部に流出した可能性があることがわかった。

同社によると、「立花書房ウェブサイト」の脆弱性を突かれ、クレジットカード決済に用いるモジュールを改ざんされたもの。2021年9月8日にクレジットカード会社から情報流出の可能性について指摘があり、問題が判明した。

同年1月8日から8月20日にかけて顧客1144人が商品購入時に利用したクレジットカード情報を窃取され、不正に利用された可能性がある。クレジットカードの名義、番号、有効期限、セキュリティコードが含まれる。

同社では8月21日にシステムを移行しており、移行前のシステムが攻撃を受けたという。移行後は異なるサーバやアプリケーションを利用しているが、不正アクセス被害の判明を受けてクレジットカード決済を停止している。

外部事業者による調査は10月1日に終えており、12月21日に個人情報保護委員会へ報告。同日警察にも被害を申告した。対象となる顧客に対しては、年明け後となる2022年1月11日よりメールを通じて経緯を説明するとともに謝罪を行っている。

プレスリリースアーカイブ

Wiresharkによるパケット解析講座2:Wiresharkのフィルター式の表示 / Wireshark Tutorial: Display Filter Expressions

Wireshark Tutorial: Display Filter Expressions

本稿ではWiresharkがより使いやすいものになるようなヒントをお教えします。今回は、感染したWindowsホストからの悪意のあるネットワークトラフィックのpcapを確認するときに役立つと思われるフィルタ設定について説明します。

チュートリアルで利用するpcapはこちらから入手してください。

なお本チュートリアルでは、Wiresharkを効果的に使用する上での前提となるネットワークトラフィックの基本について、皆さんがすでに理解していることを前提としています。また、マルウェア感染がおこる仕組みについての基本的な理解も前提としています。

本稿は、悪意のあるネットワークトラフィックを分析する方法の包括的なチュートリアルではなく、Wiresharkの表示フィルタについてのヒントとこつをいくつか示すことを目的としています。この点についてはご了承ください。

今回のチュートリアルでは、以下について説明します。

  • 感染トラフィックの痕跡
  • Wiresharkの表示フィルタ
  • フィルタの保存
  • Web経由の感染トラフィック用フィルタ
  • 他の種類の感染トラフィック用フィルタ

感染トラフィックの痕跡

このチュートリアルでは、「悪意のあるスパム(マルスパム)やWebトラフィックなどが大量に配信したWindowsを対象とする商用マルウェアからの感染トラフィック」をサンプルとして使用します。こうした感染では、Windowsホストがマルウェア(通常はWindows実行可能ファイル)に感染するまでに、さまざまな経路を通ることが考えられます。

こうしてさまざまな経路を通った感染トラフィックの痕跡は「IOC(侵害の痕跡)」と呼ばれます。セキュリティの専門家は、感染時にマルウェアが生成するネットワークトラフィックからこうした「感染の痕跡」情報を抽出し、見つかったURL、ドメイン名、IPアドレス、プロトコル、ポートなどの感染トラフィックの痕跡を文書に記録していきます。

Wiresharkの表示フィルタを適切に使用すると、これらの痕跡を素早く見つけることができます。

Wiresharkの表示フィルタ

本稿で説明する「Wiresharkの表示フィルタ」とは、[Packet List] ペインの上にある[Filter]ツールバーに入力するフィルタの内容を指しています。ここには、Wiresharkがpcapファイルから読み出して表示するフレーム、IPパケット、TCPセグメントをフィルタリング(絞り込み表示)するための式を入力します。


表示フィルタにテキストを入力すると、Wiresharkは、入力したテキストに基づいて候補のリストを表示します。表示フィルタの背景色が赤いとき、入力した式はまだそのままでは利用できない状態です。


この色が緑に変われば、入力内容は式として利用でき、正しく動作します。表示フィルタの背景色が黄色の場合、式は受け入れられていても、おそらく意図したとおりには動作しません。


Wiresharkの表示フィルタには、ブール式を利用できます。つまり、複数の式を指定して連結できます。一般に使用される式を次に示します。

  • 等号: ==またはeq
  • 論理積: &&またはand
  • 論理和: ||(2本の縦線)またはor

ブール式を利用した式のサンプルを次に示します。

  • ip.addr eq 192.168.10.195 and ip.addr == 192.168.10.1 
  • http.request && ip.addr == 192.168.10.195
  • http.request || http.response
  • dns.qry.name contains microsoft or dns.qry.name contains windows

ある値の除外を指定をしたい場合フィルタ式に「!=」は使用しません。たとえば「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[.]net95.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トラフィックも見つかることがあります。

  • smtp contains “From: "
  • smtp contains “Message-ID: "
  • smtp contains “Subject: "

Wiresharkの表示フィルタでは大文字と小文字が区別されることに注意してください。暗号化されていないSMTP通信でスパムボット トラフィックを検索するとき、よく「smtp contains “From: “」をフィルタ式として使用します。Using-Wireshark-diplay-filters-spambot.pcapを開いた状態で、このフィルタ式を入力してみてください。下図に示したパケットが見つかるでしょう。

SMTPトラフィックのフィルタリングしたら、表示されたフレームのいずれかを選択してTCPストリームを追跡して内容を確認してみましょう。


表示されているフレームのいずれかひとつを選択して右クリックし、表示されたコンテキストメニューで[追跡]、[TCP ストリーム]の順にクリックします。これでそのフレームに関連するSMTP通信の内容が表示されるので、スパムボットから送信された電子メールの1つ(たとえば下図の例ではericrene.malherbe@wanadoo[.]fr)が見つかります。


フィルタの保存

フィルタ式のなかには毎回入力するのが非常に面倒なものもあります。それらはフィルタ ボタンとして保存しておくことができます。Wiresharkのフィルタ バーの右側には、フィルタ ボタンを追加するための[+]ボタンがあります。


[+]をクリックして、フィルタ式をフィルタ ボタンとして保存します。以下のフィールドが表示されます。

  • Label(ラベル)
  • Filter(フィルタ)
  • Comment(コメント)

「Comment(コメント)」の記入は任意です。また、[Filter(フィルタ)]には、Wiresharkの[Filter]タスクバーに現在入力されている内容がデフォルトで設定されます。「Label (ラベル)」に入力したら、[OK]をクリックします(下図参照)。


前記の画像では、(http.request or ssl.handshake.type == 1) and !(udp.port eq 1900)というフィルタについて「basic」と入力し、基本フィルタとして保存しました。下図では、「basic」というラベルのフィルタ ボタンが、+記号の右側に表示されています。


Wiresharkにおける標準的なフィルタ設定として、以下のフィルタ ボタンを作成しています。

  • basic (http.request or ssl.handshake.type == 1) and !(udp.port eq 1900)
  • basic+ (http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002) and !(udp.port eq 1900)
  • basic+DNS (http.request or ssl.handshake.type == 1 or tcp.flags eq 0x0002 or dns) and !(udp.port eq 1900)

宿泊予約仲介プラットフォームの責任 東京地判令元.9.5(平28ワ32620)

この世で最も忌み嫌う宿泊予約仲介プラットフォーム

宿泊予約仲介プラットフォームの責任 東京地判令元.9.5(平28ワ32620)

私がこの世で最も忌み嫌う宿泊予約仲介プラットフォームはエクスぺデイア(Expedia)です。

2016年にイスラエルに訪問した際、エクスペディアで宿を予約したのだが、エクスペディアで予約後直接宿とやり取りが必要というクソな仕様で、イスラエル訪問初日に宿なしの憂き目にあった。

イスラエルから日本のエクスペディアのコールセンターに電話しても出てくるのはカタコトの日本語を話す中国人で埒が明かず、結局hotels.com(たぶん)で当日予約をして宿を確保した。オンライン宿泊予約プラットフォームで海外の宿を当日予約したのはこれが初体験であった。

日本帰国後にエクスペディアにクレームを入れるが返金されることはなく、頭にきて退会したのだが、退会後にエクスペディアから「ありがとうございました。今後ともよろしくお願いします。」という意味不明というか、小バカにされた感のメッセージを受けたことを今でも覚えている。

利用者が「静かな部屋」をリクエストして部屋を予約したが実態と異なっていたとして,利用者が予約仲介プラットフォーム事業者の責任を追及した事案があったので、転載しておく。

こんなしょーもない内容で訴えるのかと思ったが、案の定原告の主張は退けられた模様。

ーー

事案の概要

Xは,Yが運営する宿泊施設予約サイト(本件サイト,Booking.com)を通じてマカオのaホテル(本件ホテル)を予約した。その際,「特別リクエスト」欄に「quiet room」と記載した。

Xが実際に本件ホテルに赴いたところ,仮囲いがあって工事中であり,Xは「静かな部屋」ではないとしてその場でキャンセルして宿泊しなかったが,当日キャンセルに当たるとして全額(816香港ドル)が決済された。その後,Xは,本件ホテルと直接交渉のために2度に渡って本件ホテルに赴いた。

Xは,Yに対し,特別リクエストを正確に伝達して仲介すべき債務の履行を怠ったことは債務不履行または不法行為にあたるなどとして,交渉のための航空運賃,支払うこととなった本件ホテルの宿泊費(キャンセル料)等の合計約20万円の損害賠償を求めた。なお,本人訴訟のようである。

ここで取り上げる争点

債務不履行または不法行為の成否

裁判所の判断

裁判所は本件ウェブサイトの位置づけについて次のように認定した。

本件ウェブサイトは,サイトを閲覧した顧客が,客室予約の手続を行うことのできるオンライン・プラットフォームであり,利用者は,無料で本件ウェブサイトを利用することができ,本件ウェブサイトを通じて予約が完了した時点以降,Yは,予約情報を宿泊施設に伝達し,利用者に予約確認書メールを宿泊施設に代わって送信し,利用者と宿泊施設との仲介のみを務めるものとされている

次のように述べてYの責任を否定した。

Xは,Yが本件ウェブサイトに,本件ホテルの周りには仮囲いがあって工事中であるとの情報を掲載しなかったことがXの利益を侵害し,不法行為に当たると主張する。しかし,上記ア(ア)の約定(注:上記認定)を見ても,Yにおいて,本件ホテルの場所や宿泊料といった一般的な情報を超えて,本件ホテルが,X固有の特別なリクエストにすぎない「静かな部屋」に対応することのできる状況にあるのか否かについてまで,本件ウェブサイトに情報を掲載して提供する法的義務が生じるとはいえず,他に,そのような法的義務が生じることを基礎付ける事情も認められない。よって,この点に関するXの主張は理由がない。
また,Xは,Yが予約内容を正確に仲介すべき債務を負っていたと主張する。この主張が,予約内容を正確に伝達すべき債務であるという趣旨であれば,Xが入力した他の予約情報が本件ホテルに伝達されていながら,特別リクエストのみ伝達されていないということは想定し難いのであるから,Yは予約内容を伝達する債務を履行したといえる。また,上記の主張が,Yにおいて,本件ホテルに対し,Xが静かな部屋を要望している旨を伝えて,本件ホテルに何らかの対処を求めるべき債務があるとの趣旨であるとしても,上記イのとおり,Yの債務は予約の伝達と予約確認書メールの送信に尽きるのであって,それ以上に,Yが,本件ホテルに対し,Xの特別リクエストに応じた対処を求めるべき債務が存在するものとはいえない。よって,この点に関するXの主張も理由がない

その他に,Xは消費者契約法10条,景表法違反なども主張していたが,いずれも退けられている。

アジア各地の大東亜戦争戦跡


2019年8/15はタイのバンコクにいたため、数日遅れましたが、本日8/18に靖国神社に参拝に行ってきました。

大東亜戦争で亡くなった方々のことを思うと、今の平和な生活にあらためて感謝せねばと強く感じます。

感謝するだけでは足りないと感じ、タイミングが合えばアジア各地にある大東亜戦争の戦跡にも少しずつ訪問しています。

まだいけていない部分も多いのですが、少し整理してみたいと思います。


■■行ったところ■■

・2000年:関東軍七三一部隊関連(中国・ハルピン)

・2001年:毒ガス関連(広島県大久野島)

・2005年:泰緬鉄道関連(タイ・カンチャナブリ)

・2005年:日本軍慰霊塔(タイ・カンチャナブリ)

・2013年:マッキンレー丘舎跡(さくら兵営)(フィリピン・マニラ)

・2018年:ヤンゴン日本人墓地(ミャンマー・ヤンゴン)

・2021年:人吉海軍航空基地(熊本県)

■■今後行ってみたいところ■■

泰緬鉄道のミャンマー側(ミャンマー・モン州)

ガダルカナル島(ソロモン諸島)

ブーゲンビル島ブイン(パプアニューギニア)
 ⇒映画「連合艦隊」で登場

ラバウル(パプアニューギニア)
 ⇒映画「あゝ決戦航空隊」で登場

ウエワク(パプアニューギニア)
 ⇒ゲーム「提督の決断」に登場

トラック諸島(ミクロネシア連邦)
 ⇒ゲーム「提督の決断」に登場

コタバル(マレーシア)

抑留日本兵建築物(キルギス・タムガ)

インパール作戦関連(インド・ロトパチン村)

移民資料館(ブラジル・サンパウロ)

マバラカット(フィリピン)
 ⇒映画「あゝ決戦航空隊」で登場

海軍博物館(米国:ワシントンDC)

産業博物館(英国:マンチェスター)

山本五十六記念館(新潟県長岡市)

修武台記念館(航空自衛隊入間基地内)

知覧特攻基地(鹿児島県南九州市)



■■その他戦跡巡りに役立ちそうなサイト■■

帝國陸海軍現存兵器保有國一覧

Go! Go! キョロちゃん !!!

太平洋の戦跡を訪ねて

戦跡の歩き方

【逆ギレ!?】ウェブページの不具合を指摘したら逆に訴えられた件(転載)


「ウェブページのソース閲覧はハッキング」、情報漏洩を指摘した人物をミズーリ州知事が起訴する意向

ミズーリ州のマイク・パーソン知事が、州が管理するウェブサイトで教職員の個人情報が暗号化もされずに閲覧可能な状態になっているのを発見・報告したジャーナリスト、ジョシュ・ルノー氏を起訴する意向を示しています。

2021年秋、St. Louis Post-Dispatch紙の記者として活動しているルノー氏は州教育委員会(Department of Elementary and Secondary Education:DESE)のサイトを閲覧中に、ウェブページのソースコード上に10万人以上の学校教師、学校管理者、カウンセラーの社会保障番号が平文で記述されているのを発見、公表はせず、国にこの問題を報告しました。

その後、問題がすべて解決されたのを待って、ルノー氏はこれを記事化しました。おかげで、州当局には直接な被害は発生することもありませんでした。

しかしこの、本来なら州から感謝状の1枚も贈られてよいはずの行動に対して、パーソン知事は何を思ったのかルノー氏を「ウェブサイトをハッキングした」として犯罪者扱いし、起訴する意向を示しています。さらに州教育委員会のマギー・ヴァンデヴェン氏も、教育関係者への配布文書のなかで「ある人物がウェブページにおけるソースコードの暗号化を解除し、少なくとも3人の教育関係者の記録を持ち出し、その社会保障番号を閲覧した」と述べました。

一般的にウェブページのソースコードは平文で記述され、誰でもブラウザーのメニューからソースコードを表示閲覧できます。しかし、知事と教育委員会の理屈では、自分が所有していないウェブサイトで、その(誰でも見ることができる)HTMLソースを見ると、その人は悪意あるハッカーとみなされてしまうことになります。

St. Louis Post-Dispatch紙はこの問題に対し、FBIが州当局に対し問題はウェブサイトの不適切な設定で情報が閲覧可能になっていたことであり、ルノー氏の行為は「ネットワーク侵害にはあたらない」と助言したと報じています。また紙が入手した公文書からは、教育委員会のヴァンデヴェン氏が、当初はルノー氏に脆弱性の発見と未然の解決に至ったことを感謝するつもりだったことがわかっています。ヴァンデヴェン氏は知事に面会したときに考えを翻したようです。

知事がこのようなおかしな判断に固執するのは、どうやら知事が任命する法的監督機関であるハイウェイパトロールが、St. Louis Post-Dispatch紙の記事に関する調査を実施し検察に引き渡した報告を根拠としているようです。知事は検察への報告があった翌々日から、検察に対してルノー氏と新聞社をコンピューター改ざんに関連する州法を適用して起訴すべきだと主張しているとのことです。

パーソン知事は会見で、ルノー氏の行動を「他人の家のドアロックをピッキングで開けて勝手に入り込むような行為」とたとえて非難しました。しかし、実際にはピッキング(暗号を解除する)行為などはおこなわれておらず、適切なたとえとは言えないでしょう。むしろ最初から「全開のドアの前を通りがかったら、人に見られたら困るであろうものが目の前にデデンと置かれていた」というほうが適切です。

ルノー氏にしてみれば、チャック全開で歩いてきた人に「開いてますよ」とこっそり教えたら逆ギレされたような展開はまったくつまらないはず。知事と教育委員会は周囲の(まともな)意見にもっと耳を傾けるべきかも知れません。

東証1部上場 応用地質のグループ会社KCSのサイトが不正アクセスによりフィッシングサイトとなる


東証1部上場 応用地質のグループ会社が不正アクセスによる改ざん被害、フィッシングサイトとなった形跡:

東証1部上場企業の応用地質株式会社は2022年1月28日、同社グループ会社の株式会社ケー・シー・エス(KCS)のWebサイトへの不正アクセスによる改ざんについて発表した。

応用地質によると、KCSのWebサイトが改ざんされフィッシングサイトとなった形跡が確認されたため、当該サイトを停止し、ネットワークを切断してサーバ内の状態を調査を開始し、今後も接続ログなどの確認を行う。また現在は、専門会社の協力を得て、当該サイトの復旧作業を実施しており、一部公開の状態となっている。

応用地質によると、外部回線の切断が早期に行われたため閲覧者へのフィッシング被害はないと考えているとのこと。

プレスリリースアーカイブ

積水ハウスグループで「再び」Emotet感染


積水ハウスグループで再び「Emotet」感染を確認:

積水ハウス株式会社は2022年1月28日、同社グループ従業員を装った不審メールについて発表した。

同社によると、同社グループの一部のパソコンが「Emotet」に感染し、同社グループ従業員を装った不審メールが、同社グループ従業員とメール連絡を行った複数人に送信されたことが確認されたという。

同社では不審メールは同社グループ(*****sekisuihouse.co.jp等)と異なるメールアドレスから送信されていることを確認しており、不審メールを受信した場合は、添付ファイルの開封や本文中のURLをクリックしないよう呼びかけている。

同社では2020年9月28日にも、同社グループの一部のパソコンが「Emotet」に感染した旨を公表アーカイブ)していた。

同社グループではこれまで、ウイルス対策として不審メールのブロックなどを進めてきたが、今後はより一層の情報セキュリティ対策の強化を推進するとのこと。

プレスリリースアーカイブ