一つの鍵が三つの扉を開けた。ハッカーはティービングの開発者一人の接続キーで開発倉庫に入り、そこから見つけた別の鍵でサービスが動く運用システムまで侵入した。そこで拾ったIDとパスワードで利用者情報が入った金庫を開けた。3日かかった。
科学技術情報通信部の官民合同調査団は3日、ティービングの侵害事故に関する調査結果を公表した。5月29日から31日までの3日間、ハッカーは開発者の接続キー1つで開発システムと運用システムを順に突破し、アカウント3954万件分の情報を持ち出した。
調査団は3日の記者会見で、開発者端末9台をフォレンジック分析し、セキュリティ機器やデータベース（DB）、システム接続記録を突き合わせて、ハッカーの移動経路を5段階で復元した。その過程では、ハッカーの手口以上に、止められたはずの瞬間が何度もあったことが明らかになった。
◆発端はCPU100％の警報
事故が表面化したきっかけは、ハッキング検知ではなくサーバーの過負荷だった。5月30日午後6時、ティービングのDBサーバーの作業量が急増し、CPU使用率が100％まで跳ね上がった。異常兆候の通知が鳴り、ティービングは当該作業を遮断した。
原因を調べる過程で、ティービングは許可を受けていない誰かが内部サーバーに入り、利用者情報を照会していた事実を把握した。6月1日に韓国インターネット振興院（KISA）へ通報し、科学技術情報通信部は翌日に現地調査に入り、6月3日に官民合同調査団を立ち上げた。調査団がたどってみると、ハッカーは警報が鳴る1日前からすでに社内システムに接続していた。
◆1段階目、盗んだ鍵で開発倉庫に入る
5月29日午後2時42分。ハッカーはティービングの開発者1人の「開発環境接続キー」を持って開発環境に入った。
開発環境とは、ソースコードを保管し、複数の開発者が共同で修正する作業空間だ。建物でいえば設計図が積まれた図面室にあたる。入るには開発者ごとに発行された接続キーが必要だ。ハッカーはその鍵を事前に盗んでいた。
侵入したハッカーは、アクセス可能な開発プロジェクト361件をすべて持ち出した。容量は30.35ギガバイト。最初は14件だけ抜き出し、2回目の攻撃で全部を奪った。プロジェクトには、利用者向けレコメンドや検索アルゴリズム、会員管理と認証体系、決済管理、有料サービス運営など、ティービングを支える核心技術が含まれていた。
ここで最初の問題が表面化する。ティービングはすべての開発者に全プロジェクトへのアクセス権限を与えていた。本来は業務に必要な最小限だけを開くのが原則だが、ティービングでは開発者一人の鍵があれば361件すべてが見られた。ハッカーにとっては、鍵一本がそのままマスターキーだった。
◆2段階目、ソースコードに埋め込まれた「万能鍵」43本
持ち出したソースコードを調べたハッカーは、さらに大きな宝を見つけた。サービスが実際に動く「運用環境」に入るための接続キーだった。運用環境はクラウドサービス（AWS）でサーバーを借りて使う空間で、図面室ではなく実際の建物にあたる。
調査団が数えたところ、361件のプロジェクトの中に運用環境接続キーが43本も含まれていた。41本はソースコード内にそのまま記載されており（ハードコーディング）、3本はプログラム設定値に暗号化されないまま平文で保存されていた。開発の便宜のために鍵をコードに書き込み、別の金庫に移していなかったのだ。家の鍵を玄関前の植木鉢の下に置いていたら、植木鉢ごと盗まれたようなものだ。
ティービングはハードコーディングの問題を知らなかったわけではない。2024年の模擬ハッキングで、接続キーがソースコードにそのまま露出していると指摘されていた。しかし修正しなかった。調査団は「キー管理体系が整備されていれば開発環境への侵入を遮断でき、運用環境にも入れなかったはずだ」と判断した。
◆3段階目、運用システムに入りDBパスワードを拾う
5月29日午後3時15分。開発環境に入って33分後、ハッカーは運用環境に足を踏み入れた。確保した43本のキーの権限を一つずつ確認し、情報を抜き出す経路を探した。
調査団は、43本のうち2本が実際の攻撃に使われたことを確認した。1本は大規模データの加工・分析やクラウド保存領域へのアクセスが可能なキー、もう1本は仮想サーバーを新規に作成できるキーだった。どちらも開発者ノートパソコンに保存されていた。
運用環境を探っていたハッカーは、決定的な情報を手にした。利用者情報が入ったDBにアクセスする管理者アカウントのIDとパスワードが、暗号化されないまま平文で保存されていたのだ。
◆4段階目、1回目の試行は警報にかかる
5月30日午前9時22分。ハッカーはクラウド保存領域に情報流出用の攻撃ツールを仕込んだ。自作したスクリプト20種類だった。保存領域につながるDBへ接続し、利用者情報の抜き取りを始めた。
大量照会でDBサーバーの作業量が急増し、午後6時にCPU使用率が100％まで跳ね上がった。警報が発報され、ティービングが作業を止めた。ハッカーが大量データを一気に抜き出そうとしてサーバーを過負荷状態に追い込んだのだ。1回目の試行はここで止まった。
問題は、ティービングがその警報をハッキングとして認識できなかったことだ。調査団によると、ティービングはCPU負荷のような単純な指標しか見ておらず、ネットワークとデータの流れをリアルタイムで監視して異常行為を捕捉する仕組みがなかった。許可されたIPだけを入れるようにしたり、多要素認証（MFA）を求めるアクセス制御方針もなかった。サーバーが苦しんでいる兆候は見えたが、誰がなぜ苦しめているのかは見えていなかった。
◆5段階目、静かに再び…CPU10％で24GB
ハッカーは諦めなかった。5月31日の日曜日、午後7時、方法を変えて戻ってきた。
前に確保した2本目のキー、仮想サーバーを作成できるキーを使った。運用環境内に自分専用の仮想サーバーを立て、それを流出経路として利用した。DB内の利用者情報をそのサーバーに丸ごと移し、24ギガバイトを外部サーバーへ送った。作業が終わると仮想サーバーを削除し、痕跡を消した。午後7時から10時20分まで、3時間20分かかった。
今回は警報は鳴らなかった。調査団が当時のCPU占有率を確認したところ、10％以内に保たれていた。前日の警報に引っかかった経験を踏まえ、サーバー負荷を意図的に低く保ちながら少しずつ抜き取ったとみられる。ハッカーは防御体制の限界を見抜き、その下をくぐり抜けた。情報は外部サーバーに渡った。
◆最初の鍵はどう盗まれたのか――最後まで不明
5段階の出発点、つまり開発者接続キーをどう盗んだのかは、最後まで解明できなかった。
調査団は5つのシナリオを想定して精密調査を行った。対象開発者の会社用・個人用メールを調べてフィッシングメールを受け取ったか確認し、開発者端末9台（ノートパソコン8台、PC1台）をフォレンジックしてマルウェアを探した。ソフトウェアの開発・配布過程に悪意あるコードが紛れ込んだのか（サプライチェーン攻撃）、社員同士で接続キーを不正共有したのか、VPN機器の脆弱性が突破されたのかも調べた。どれも確認できなかった。
理由は証拠不足だ。ティービングのVPN接続記録は6日分しか保存されていなかった。新たに導入した機器にログ管理方針がきちんと適用されていなかったためだ。開発環境の接続記録は90日分残っていたが、鍵が盗まれた時点がそれより前なら、痕跡はすでに消えていた可能性がある。ハッカーがいつから鍵を持っていたのか、誰にも分からない。
フォレンジックでは別の事実も明らかになった。開発者8人の端末で、開発環境接続キー37本、運用環境接続キー52本が暗号化されずに保存されていた。社内メッセンジャーで鍵をやり取りした形跡も確認された。調査団は、鍵の発行・使用・変更・廃棄と定期点検のための管理手続き自体が存在しなかったと指摘した。
◆何が流出したのか
流出規模はアカウント3954万件だ。ログイン可能なアクティブアカウントが2206万件、1年以上未接続の休眠アカウントが850万件、退会したが法律により保管中だったアカウントが887万件、テスト用アカウントが11万件である。
アカウントの状態に応じた区分（出所＝科学技術情報通信部）
一人が複数アカウントを作れる構造のため重複が含まれており、1人で13件のアカウントを持っていた例もあった。登録経路別では、ネイバー・カカオ・アップルなどSNSの簡易登録が2247万件で最も多く、CJ ONE統合会員が863万件、ティービング独自登録が726万件だった。
登録方式に応じた区分（出所＝科学技術情報通信部）
持ち出された情報は20項目、70種類にのぼる。ID、氏名、生年月日、性別、携帯電話番号、メールアドレス、本人確認情報（CI）、プロフィール名、決済履歴、提携サービス情報などだ。CIは住民登録番号の代わりに個人を識別する固有値で、有料決済や成人認証の際に生成される。
CIがあるアカウント1904万件（重複除去後1324万件）は平均11項目が流出し、CIがないアカウント2040万件は平均5項目が流出した。CIのないアカウントには、氏名が数字で入力されていたり、メールアドレスが誤って入力されていたりする不正確なデータも多かった。
暗号化の有無が被害を分けた。会員パスワードは復号できない一方向方式で暗号化されており、ハッカーは解読できない。返金口座番号とプロフィールロック番号も暗号化された状態で流出した。一方、携帯電話番号の末尾とメールアドレスのID部分は暗号化されていたが、復号可能な暗号化キーまで一緒に流出した。調査団は平文流出と同じ水準と見なした。鍵はかけたが、その鍵を錠前のそばに掛けておいたようなものだ。
これまでに流出情報を悪用した被害やダークウェブでの取引の兆候は確認されていない。ただし調査団は、電話番号とメールアドレスがスミッシングやボイスフィッシング、ダークウェブ取引に使われる可能性があるとみて、リアルタイム監視を強化した。正確な個人情報流出規模は、個人情報保護委員会が別途公表する。
◆なぜ止められなかったのか――4人、14時間、放置された警告
調査団が指摘した根本原因は、技術よりも人と体制にあった。
ティービングの役職員は265人で、そのうち開発者が149人だ。情報保護の専任人員は外部委託を除けば4人ほどだった。開発者37人に対し、セキュリティ担当1人という計算だ。調査団は、その人数では常時のセキュリティ監視、脆弱性点検、異常行為の監視を同時にこなすのは難しいと見た。
危機対応も遅かった。5月30日午後6時に異常兆候が発生したが、侵害事故対応を統括するべき情報保護専任組織と最高責任者（CISO）に状況が共有されたのは、約14時間後の31日午前10時10分だった。その間、ハッカーは2回目の攻撃を準備していた。部門間の情報伝達と協力体制が不十分だったと調査団は指摘した。
業務用PCへのウイルス対策ソフトの導入や最新バージョン管理といった基本的なセキュリティ点検も疎かだった。ティービングの独自情報保護指針で定められていた事項だった。
◆通報も遅れた――過料、そして変わる法律
法令違反も確認された。情報通信網法は、侵害事故を認知してから24時間以内に通報するよう定めている。ティービングは認知時点を5月31日午後3時9分と申告したが、調査団は情報セキュリティチームに状況が伝達された同日午前10時10分を認知時点と判断した。実際の通報は6月1日午後3時8分で、24時間を超えていた。3000万ウォン以下の過料の対象となる。
科学技術情報通信部はティービングに対し、9月中に再発防止の履行計画を提出させ、10～12月の履行状況を来年1月から点検する。不十分なら是正命令を出す。
制度も変わる。9月11日に施行される改正個人情報保護法は、反復的または故意・重過失による大規模流出に、売上高の最大10％までの懲罰的課徴金を科せるようにした。
10月1日に施行される改正情報通信網法は、主要企業にセキュリティ人員と予算の拡充を義務づけ、政府がハッキングの兆候を把握した場合には企業の通報前でも調査を開始できるようにする。再発防止策を不誠実に履行した場合には、履行強制金も科される。
◆ティービングの謝罪と補償
チェ・ジュヒティービング代表は同日説明会を開き、「お客様に大きなご心配と不安をおかけしたことを心よりおわび申し上げる」とし、「調査結果を謙虚に受け止め、是正措置と再発防止対策を最後まで履行する」と述べた。
補償は、ハッキング・フィッシング安心保険1年分（1人当たり最大300万ウォン）、ティービングポイント5000ウォン、プレミアム視聴環境へのアップグレード、ウェーブ・CGV割引クーポンのいずれかだ。7日から30日まで申請すれば、翌月6日から適用される。ティービングは2030年までに情報保護投資を直近5年の4倍に、今年30億ウォンのセキュリティ支出を120億ウォン水準へ増やし、セキュリティ人員も5年以内に3倍に拡充するとした。
◆他社が心に留めるべき5つ
ティービング事故に技術的な新規性はない。調査団の指摘を逆に読めば、そのまま予防策になる。
接続キーはコードの外に置かなければならない。鍵は別の金庫（シークレット管理ツール）に保管し、コードには金庫を開ける手順だけを残す方式だ。キーは定期的に変更し、誰がいつ使ったかの履歴も残さなければならない。
権限は必要な分だけ与えるべきだ。開発者1人が全プロジェクトを見られるなら、鍵1本がマスターキーになる。プロジェクト別、役割別にアクセスを分ければ、一か所が破られても被害はその範囲で止まる。
監視は負荷ではなく流れを見るべきだ。CPU使用率だけでは、ハッカーが速度を落とした瞬間を見逃す。平時と異なる大量照会、見慣れないIPの接続、新たに生じた仮想サーバーなど、行為そのものを捉える仕組みと、許可済みIPや多要素認証で入り口を高くすべきだ。
記録は長く残す必要がある。6日分の接続記録では事故原因を追えない。調査も再発防止もログから始まる。
警告は直してこそ警告だ。2024年の模擬ハッキングが見つけた脆弱性をその時点で修正していれば、事故は違う形だったはずだ。脆弱性を見つけることと直すことを一つの束として管理する体制が必要だ。
◆利用者が今すべきこと
パスワードは復号不可能な状態で流出したが、氏名、電話番号、メールアドレス、生年月日も一緒に漏れた。詐欺犯が個別に合わせたメッセージを送るには十分だ。「ティービング補償申請」「アカウントセキュリティ点検」を名目にした短信やメールのリンクは開かず、補償申請はティービングアプリや公式サイトから直接行うべきだ。
ティービングと同じパスワードを他サービスでも使っていたなら、変更した方が安全だ。通信会社や金融機関の名義盗用防止サービスを有効にしておけば、流出情報を使った回線開設や融資申請の試みを防ぐのに役立つ。