
2 月 31 日にスケジュールした crontab タスクにペイロードを隠すマルウェア「CronRAT」 22
ストーリー by nagazou
マルウェア 部門より
マルウェア 部門より
headless 曰く、
crontab タスクにペイロードを隠し、Web スキミングにつながる可能性のあるマルウェア「CronRAT」を発見者の Sansec が解説している (Sansec のブログ記事、 BetaNews の記事)。
CronRAT がペイロードを隠す crontab タスクは 2 月 31 日の実行がスケジュールされている。タスクに文法上の間違いはないものの実行すればエラーとなるが、スケジュールされた 2 月 31 日は決して来ないため、実行されることもない。
タスクからデコードされるペイロードは洗練された Bash プログラムであり、ランダムなチェックサムを持つバイナリプロトコルで Alibaba がホストする IP アドレスの C&C サーバーと通信する。これにより、RAT のオペレーターは任意のコードを実行可能になるという。
CronRAT はある国で最大のオンラインストアを含む複数のオンラインストアで見つかっており、いくつかのケースで サーバーサイドコードへのペイメントスキマー (Magecart) のインジェクションにつながっているそうだ。
crontab タスクに隠れたマルウェアが管理者の注意を引くことはなく、これまではセキュリティ製品の多くが Linux の cron システムをスキャンしなかったが、現在では CronRAT を検出するセキュリティ製品も増加しているようだ。
解せぬ (スコア:0)
実行されないならどんな危険なコードでも構わないと思うのだが、何が問題なんだろう?
Re:解せぬ (スコア:2, 興味深い)
割と数年前では、正味のマルウエアコードをいかに対象機に忍ばせるかに注力している雰囲気でしたが
数年前から、対象機をC&Cサイトに接続させてマルウエアのダウンロードを挿せる手法になりつつあります。
が、単純にマルウェアを通信によって端末にダウンロードをさせるとセキュリティ対策ソフトによって
検知され通信を遮断するとか駆除されるとかC&C判定されてガードされるながれなのですが
こいつも含め最先端のマルウェアは、C&Cサイト上にはマルウェアとして活動しない中間ファイルみたいな
ファイルがおかれているだけで、そいつを端末側に仕込まれているファイルを取ってくるモジュール側
(スクリプト系)がエンコードしながら変化するマルウェアに作り上げる手法をとっているので、
セキュリティ対策ソフト側(所謂次世代と呼ばれている製品でないと検知はむずかしいかも)では
なかなか検知しにくいから やべーっていってるのね。
Re:解せぬ (スコア:2)
・crontabに、「定期的に実行するbashワンライナー」を登録、さらに、「悪意のある長大なスクリプトをgzip圧縮しbase64でテキスト化し、適度に分割したものをコマンドとして、2月31日指定で登録」しておく。
・bashワンライナーは、「crontabを読み込んで2月31日のものを抽出、結合し、gzip展開してからbashに流し込んで実行」するというもの。(このワンライナーそのものも、そういう処理を行う複数行スクリプトを、gzip/base64で1行にしてる。)
・以上により、悪意のあるシェルスクリプトが定期的に実行される
という流れです。ワンライナーは正しいbashスクリプト。本体の方はコマンド実行不可な文字列ですが、実行しようとすることはないので問題ない、ということで。
Re: (スコア:0)
2月31日はバレなくするための工夫ではなく、
スクリプトのサイズを増やすための工夫ということかな。
Re: (スコア:0)
ということは2/31だけを気にしてもダメってこと?
今回はわかりやすい日付(作った人の悪ふざけ?)だっただけで
別の日付でも可能ってことか
まぁ実際にある日付だとエラーメッセージが飛ぶ可能性があるから使わないだろうってだけなのね
Re:解せぬ (スコア:1)
独自のファイルを仕込むと、身に覚えのないファイルに怪しまれる恐れがあるけど、
どうせ定期実行のためにcrontabに手を入れてる(crontabを見られたら一発でばれる)のなら、
crontabだけで仕込みが完結するようにしとけば発覚するリスクは減らせる、という判断じゃないですかね。
「crontabに埋め込む」のが先で、あとは、2月31日指定なんて妙に回りくどいことしなくても、「#で始まるコメント」形式でも使えば自由にデータ埋め込みは出来ますけど、
デコードの手間を考えると「2月31日指定を抽出」が、余計なものが混じる心配がない、ってあたりかと。
Re: (スコア:0)
管理GUIツールで消えないとか?
# 稀にコメントを消す困ったちゃんが。
Re: (スコア:0)
人間がcrontabを見れば異様な長大なbase64で一発でばれるし、そういう手口があることが周知されればセキュリティ製品でも検知できると
対処不可能な手口では全然ないわけね
Re:解せぬ (スコア:1)
Re: (スコア:0)
cronなんぞ誰も気にも留めてなかったところに実はトラップが仕掛けられるという問題だぞ。
次は設定してある日付をリモートでいじることができたらトラップカード発動!となる。
Re:解せぬ (スコア:1)
>次は設定してある日付をリモートでいじることができたらトラップカード発動!となる。
crontab -l | sed -e "s/ 31 2 / 28 2 /" > temp ; crontab -u temp ; rm temp
とか?
やったこと無いのであってるかどうかしらんけど。
Re: (スコア:0)
2月31日に設定する方法って具体的にはどーすんだろ
Re: (スコア:0)
2月31日に設定する方法って具体的にはどーすんだろ
ええ、、はい、、納期につきましては、、、
Re: (スコア:0)
$ man 5 crontab
を読むとわかるよ。
ところで、2月31日に設定すると、うっかり翌実在日 (3月1日) に実行してしまうような実装でも当て込んでるのかしら。
Re: (スコア:0)
These lines are syntactically valid, but would generate a run time error when executed. However, this will never happen as they are scheduled to run on February 31st. Instead, the actual malware code is hidden in the task names and is constructed using several layers of compression and base64 decoding.
crontabとしては文法上問題ないが、実行時エラーになる。けど実行はされない。
実際のマルウェアはbase64とか圧縮でタスク名に含まれている。
よく分からないけど、タスク名からcrontabが何かを作ってそれが実行されるのかな?
Re: (スコア:0)
実行されないならどんな危険なコードでも構わないと思うのだが、何が問題なんだろう?
ええ2月28日96時はあっても
2月31日なんてとんでもない
# そういうことじゃねぇ
Re: (スコア:0)
最初からスケジュールされた2月31日は来ないが、最初はスケジュールに入ってなかった2月31日は来る
Re: (スコア:0)
2月31日くらいなら頼み込んだらなんとか伸ばしてもらえるかもしれないけど、
2月60日とか61日とかになると次年度に食い込んでしまうのでヤバいな。
Re: (スコア:0)
「ペイロード」について調べて
tripwireでも仕掛けたら (スコア:0)
検知できるぜ
そういう問題じゃない・・・
Re: (スコア:0)
何が面白いのかわからんけど、楽しそうでイイね!