Synology NASにランサムウェア 入口の説明は割れ、最新版でも被害の報告

DSMを最新にしていても、安心とは言い切れません。Synology NASを狙うランサムウェアC3RB3Rの入口は説明が割れ、最新版での被害の報告まで出ているからです。

Synologyは10月29日、入口を「2024年12月に修正された脆弱性」と説明しました。同じ日、中国のセキュリティ会社360は、9月の勧告にある別の2件だと報告しています。さらにSolarのインシデント対応チームは、当時最新のDSM 7.4.1-90080 Update 1で被害が出た例を挙げました。

決着はまだですが、情シスの動きは決められます。先に感染とバックアップを確認し、外からの経路を閉じて、DSMを各系の最新版へ上げる。この順番なら、どの説明が正しくても無駄になりません。

困るのは、最新版でも足りないかもしれない古い機種でしょう。

声明と報告は、入口で食い違う

Synologyの声明は短いものです。日本語版が詳細の参照先に挙げたのは2024年の勧告Synology-SA-24:20だけで、自社が9月18日に出した深刻度Criticalの勧告Synology-SA-26:13には触れていません。英語版はPHP2Shellの勧告SA-26:14も挙げています。

一方の360は、10月に入ってNASの被害の相談が続いたとして、暗号化の手口まで分析した警告を出しました。同社によると、使われたのはCerberの変種C3RB3Rです。暗号化したファイルの拡張子を.L0CK3Dに変え、フォルダごとにread-me3.txtを残します。入口については、こう書いています。

经详细排查发现，本轮攻击的切入点是两个高危远程漏洞，CVE编号分别为CVE-2026-13639和CVE-2026-13684。

韓国のKISAも10月30日、この2件を含むSA-26:13の更新を呼びかける告知を出しました。ただ、告知そのものはランサムウェアに触れていません。ChosunBizの報道を引くTokenPostによると、KISAには国内の被害の届け出が複数あり、個別の経緯や規模には答えられないとしています。

Solarの報告は、もう一段気がかりな内容です。被害に遭ったNASは、10月12日に出たばかりのDSM 7.4.1-90080 Update 1でした。もっとも、Solarは0dayの疑いと表現しつつ、最新版が攻撃されたからといって最新版に0dayがあるとは限らないと断っています。DSM本体の0dayとは認定できず、パッケージやプラグイン、認証情報、他のサービスの悪用も否定できないという立場です。侵入と更新の時刻の前後も、これから調べるとしています。

BleepingComputerの掲示板でも、入口は絞れていません。モデレーターのquietman7氏はNAS全般の話として、Windows PCが先に感染してネットワーク越しに暗号化した可能性がいちばん高いと書きました。ただ同じスレッドには、SMBをポート転送で外に開いていた被害者が、社内のノートPCを検査して問題が無かったと書いた投稿もあります。

編集部は、どれかが誤りとは限らないとみています。同じランサムウェアを複数の入口で入れている可能性があり、3者が見た被害が同じ台だとは、どれにも書いてありません。3者とも、入口の証拠までは示していません。気がかりなのは、声明だけを読んだ人が、2024年の修正を済ませた自社のNASを対象外と受け取りかねないことです。

判定の線は9月の勧告の版、上げる先は最新版

2つの勧告の修正版を並べると、ずれが見えてきます。¹

末尾の番号は、リリースノートの表記ではUpdateの番号にあたります。2024年の修正を越えていても9月の勧告の版に届いていないのは、7.2.2なら末尾が1から8、7.2.1なら6から11です。7.3.2も、末尾が3以下なら届いていません。現役の系だけに、かえって見落としやすいところでしょう。

こうしたNASは、声明の物差しなら「済み」と読めてしまい、360の物差しなら「未修正」になります。

勧告の日付にも注意が要ります。勧告が出たのは9月18日ですが、修正版そのものは6月に公開済みでした。リリースノートでは、7.4-90075が6月16日、残りの3つが6月30日です。²ですから「9月より前に更新したから未修正」とは限らず、見るのは日付ではなく番号です。

ただし、勧告の版は判定の線にすぎません。10月12日に7.2.1以上の各系で新しい更新が出ていて、ノートの記述は「Fixed security vulnerabilities.」だけで中身が分かりません。上げるなら各系の最新版まで上げておきたいところです。

「古いDSM」という言葉も、読み違えやすいでしょう。声明の英語版はDSM 7.2、7.1、7.0、6.2を保守終了の版と明記しています。現役のつもりで使っている7.2.2のNASも、Synologyの言う「古い」側です。最新版まで上げたあとは、7.3以上へ移る計画も立てておくと安心です。

パスワードの強さにも頼れません。9月の2件はSynologyの採点でCVSS 9.8、ベクターはPR:N、UI:Nです。認証も利用者の操作も要らない前提の点数で、2要素認証を入れているから後回しでよい、とは考えないほうがよいでしょう。

更新の合図をKEVに頼っている会社も、今回は待てません。米CISAのKEVには、10月29日版の時点で、9月の2件も2024年の勧告の3件も載っていないからです。

自動更新も万能ではありません。日本語版の声明は自動アップデートも勧めますが、「新しいアップデートをインストールするかどうかを決定させてください」の設定なら通知だけで止まります。「最新のアップデートを自動的にインストール」にしていても、新しいメジャーバージョンには上がりません。

うちの会社のNASは、機種と経路で急ぎ度が変わる

同じ台数でも、外から届くかどうかで順番は入れ替わります。編集部なら次のように分けます。

いちばん重いのは4行目です。Synologyの一覧で数えると、最後に上げられるDSMが7.1の機種は42、6.2の機種は43ありました。DS1515+やDS415+、DS215+など、型番の末尾が13〜15の世代を中心に7.1で止まります。

7.1の延長サポートは2025年6月に終わり、9月の勧告の表にも載っていません。もっとも、7.1.1-42962-9や6.2.4-25556-8までは上げられるので、そこまでは上げます。ただ、360の説明が正しければ、それでは足りないかもしれません。だから、外に出さない運用へ切り替え、買い替えの稟議をすぐ始めるのが現実的な線でしょう。DSM 7.2-64570系と7.0も自分の系に9月の版が無いので、上がる機種なら7.2.1以上へ移します。

外からの経路は、ルーターのポート転送だけではありません。QuickConnectも、ポート転送なしでインターネットからNASに届く仕組みです。Synologyは、DSMをリモートで管理するならVPN経由を勧めています。編集部なら、感染の確認と更新が終わるまでQuickConnectも止め、修正版の入らない機種では止めたままにします。

暗号化への備えは、スナップショットと切り離したバックアップ

更新で閉じられるのは入口だけで、暗号化されたファイルは戻りません。TokenPostが報じた脅迫文の要求は0.036960ビットコインで、5日を過ぎると倍になるそうです。360は「不要支付赎金」と支払わないよう強く求めています。

1つ目の備えは、Snapshot Replicationのイミュータブル スナップショットです。保護期間の間は、いかなる方法でも削除できないとSynologyは説明しています。推奨の期間は7〜14日で、Btrfsのボリュームが要ります。

ただ、使える機種は限られます。Synologyの対応機種の一覧に、7.1以下で止まる機種は1台もありません。DS920+やDS923+、DS1621+は載っていますが、DS918+は載っていません。

イミュータブルでなくても、スナップショットで助かった例はあります。掲示板のDS1621+の被害者は、12の共有フォルダのうち4つにあった毎日のスナップショットは無事で、そこから復元したと書いています。裏を返せば、残りの8つはスナップショットからは戻せなかったのです。共有フォルダのスナップショットにはBtrfsが要るので、DS215+のように対応しない機種では、切り離したバックアップが頼りになります。

2つ目は、切り離したバックアップです。360は、バックアップはふだんNASとの接続を切っておくよう勧めています。Synologyの案内は、3-2-1のルールに沿ってHyper BackupでオフサイトのNASかクラウドへ置く形です。同じNASの中の複製や、つなぎっぱなしのUSBディスクは数えません。

見落としやすいのが、NASそのものがバックアップ先になっている会社です。たとえばSynology Active Backup for Microsoft 365は、自社のNASへ置く形でした（Microsoft 365バックアップ製品の地図）。これだと、原本は無事でもバックアップだけが暗号化されかねません。別のNASへ複製しているなら、複製先でもイミュータブル スナップショットを有効にできます。

決着していないこと

ここまでの判断は、次の点が分からないままでも変わらないように組みました。

• どの入口の被害が多いのかは分かりません。Synologyも360も、被害の台数を示していません。
• 声明は、2024年の勧告にある3件のどれを指すのかを示していません。
• 9月の勧告の表に無い7.2、7.1、6.2が影響を受けないのか、修正が出ないだけなのかも書かれていません。
• 英語版の声明は、PHP2Shellの影響の調査の中で今回の攻撃を見つけたと書いています。関係そのものについて、韓国の報道は確認されていないとしています。
• 日本国内の被害の公表と、汎用の復号の手段は、10月30日の時点で見つかりませんでした。

NASの台帳から始める段取り

1. 部署や拠点で買ったNAS、バックアップ先に置いたNASまで含めて一覧にします。「コントロール パネル」の「情報センター」で機種とDSMの版を控え、上の表と比べます。
2. ルーターのポート転送の全行とUPnP、「外部アクセス」のQuickConnectを見ます。5000、5001、445番は既定の例で、番号を変えたNASもあります。外から届くものは閉じます。別の拠点のNASは、閉じる前にVPNか現地の手順を用意します。
3. .L0CK3D（0はゼロ）と.LOCK3D、read-me3.txtを検索します。覚えのない管理者アカウントとタスクも見ます。
4. 全部の共有フォルダでスナップショットのスケジュールと、切り離したバックアップの最後の日付を確認します。無ければ、ここで取ります。
5. 3番で何も見つからなかったNASを、「更新と復元」から各系の最新版へ更新します。「更新」の設定が通知だけになっていないかも、ここで見ておきます。リリースノートによると通知が来ない場合もあるので、版の番号で確かめます。
6. Web StationやWordPressなどを入れているNASは、「パッケージ センター」でPHPも更新します。PHP2Shellの修正はDSMとは別で、SA-26:14によるとPHP 7.3に修正版はありません。DSM 6.2より前は、Synologyはパッケージの停止を勧めています。経緯はphp2shellの1週間の図解にまとめています。

順番には理由があります。DSMの更新は入れたあとで元に戻せず、リリースノートにも以前の版へ戻せないとあります。感染中のNASを更新して再起動すれば、証拠も失いかねません。

だから3番で見つかったら、そこで止めます。更新も再起動もせず、ファイルとスナップショットを消さずに、ネットワークを切ります。バックアップと複製のジョブも止めましょう。

ネットワークを切っても、NASの上で暗号化が続いていることがあります。すぐSynologyのサポートか対応の専門家へ連絡します。Synologyの手引きは最初に隔離を挙げ、切れないときは電源を落とすよう書く一方で、電源を切ると揮発性メモリの証拠を失うとも注意しています。Solarも、再インストールや痕跡の消去をせず、専門のチームへ連絡するよう求めています。

動いている暗号化プロセスのメモリから鍵を取り出せたという報告も、GitHubのc3rb3r-rescueにあります。作者の報告で、再現は確認していません。それでも、電源を落とさない理由にはなるでしょう。個人データが入っていたら、個人情報保護委員会への報告の要否も確認します。

2つの修正版の間にいるNASが、社内に何台あるか。今日それに答えられれば、どの説明が正しかったかが後で分かっても、慌てずに済むはずです。